Introducing gRPC Support with NGINX 1.13.10 – NGINX Community Blog
Today, we’re excited to share the first native support for gRPC traffic, released in NGINX Open Source 1.13.10. NGINX Plus Release 15 includes gRPC support as well as the support for HTTP/2 server push introduced in NGINX 1.13.9. NGINX can already proxy gRPC TCP connections. With this new capability, you can terminate, inspect, and route gRPC method calls. You can use it to: Publish a gRPC service
Nginxのリバースプロキシでバックエンドとhttp2通信する - ASnoKaze blog
以前書いたとおり、ApacheではリバースプロキシでバックエンドとHTTP2通信することができます。 asnokaze.hatenablog.com Nginxの場合は、開発者のメーリングリストでGoogleの人が書いてる「ngx_http_v2_upstream」パッチを利用することでバックエンド(upstream)とHTTP2通信することが出来るようになります。 パッチ [PATCH 01 of 14] Output chain: propagate last_buf flag to c->send_chain() [PATCH 02 of 14] Upstream keepalive: preserve c->data [PATCH 03 of 14] HTTP/2: add debug logging of control frames [PATCH 04 of 14] HTTP/
H2O x mrubyで人はどれだけ幸せになれるのか
4. Copyright © DeNA Co.,Ltd. All Rights Reserved. H2Oとは ! https://h2o.examp1e.net/ ! Google翻訳いわく ! おおむねこの通りです（⾚字部分を除いて） ! みんな⼤好き某kazuho sanが開発 ! 現在の最新verはv2.2.0-beta1 4 H2Oは、古い世代のWebサーバーと⽐較して、 CPU使⽤率が低いユーザーに迅速な応答を提供する、 新しい世代のHTTPサーバーです。 基盤から設計されたサーバーは、優先コンテンツ配信と サーバープッシュを含むHTTP / 2機能をフルに活⽤し、 Webサイトの訪問者に有望な経験を提供します。
remote_addrとかx-forwarded-forとかx-real-ipとか - Carpe Diem
背景 ECSでNginxのコンテナをプロキシとして立てたところ、APIサーバのアクセスログのクライアントIPがNginxのコンテナIPになっていたのでその修正をしたのがきっかけです。 環境 Nginx 1.10.2 Docker1.12.1 構成 Client -> ELB -> Nginx -> API という構成とします。 ネットでよく見る情報 set_real_ip_from 172.31.0.0/16; real_ip_header X-Forwarded-For; を追加する、とか proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; を追加する、とかどれがどれだか分かりにくいので１つ１つ説明していきます。 用語説明 remote_
Nginx with dynamic upstreams - Tenzer.dk
Posted on July 26, 2015. Reading time: 5 minutes I recently made a setup at work where I had a Nginx server facing the user, which would forward requests to a service running behind an AWS Elastic Load Balancer (aka. ELB). That in itself doesn't sound like a difficult task, you just find the hostname for the ELB and point Nginx at it with a proxy_pass statement like this, right? location / { proxy
リアルタイム通信環境の(一部)構成紹介 : DSAS開発者の部屋
こんにちは。 今回は、当社で稼働させているリアルタイム通信環境について、ご紹介させて頂きます。 ご紹介する環境に対する要件は、以下となります。 ・ゲーム内の期間限定イベントで使用し、イベント開催中のみサーバを稼働 ・リアルタイム通信。プロトコルは、websocket を使用 ・同じチームに所属するユーザを同じサーバへ接続 ・とりあえずいっぱいスケールできるように(笑 最後の要件は冗談で、実際にはちゃんとした数値を頂いているのですが、このような環境構築を依頼されましたので、AWS 上で以下にあるような構成を考えてみました。 構成図 ※ 主要なサーバのみを抜粋 ELB 外部のクライアントから、websocket な接続を受け付けます。 http(s) モードでは、websocket の通信確立に必要なヘッダが消去されてしまうため、tcp モードを使用しています。 tcp モードを有効にすると、
調べなきゃ寝れない！と調べたら余計に寝れなくなったソケットの話 - Qiita
なるほど、最近ソケット通信、ソケット通信と言ってるのはUNIXドメインソケットの事か！ UNIXドメインソケットって何がいいの？ Performance Analysis of Various Mechanisms for Inter-process Communicationに素晴らしい検証があった。 It was hypothesized that pipes would have the highest throughtput due to its limited functionality, since it is half-duplex, but this was not true. For almost all of the data sizes transferred, Unix domain sockets performed better than both TCP so
nginxのproxy_read_timeoutはupstreamにも注意 - noob
proxy_read_timeoutが思ったような挙動ではなかったので実験してみた． 想定していた挙動 こんな設定のnginxに対して upstream server_pool_a { server web001:80 max_fails=3 fail_timeout=30s; server web002:80 max_fails=3 fail_timeout=30s; } proxy_read_timeout 60 無限ループするようなCGIをプロキシさせたら web001にリクエスト ↓ 60秒以内にレスポンスが完了しない ↓ 504 Gateway Time-out 発生 となると思っていた． 実際の挙動 ところが実際には以下のような挙動だった． web001にリクエスト ↓ 60秒以内にレスポンスが完了しない ↓ web002にリクエスト ↓ 60秒以内にレスポンスが完了しない ↓
NginxでリバースプロキシをKeepAliveしたときの性能検証 - Qiita
Nginx + Luaを用いた、ハイパフォーマンスで動的なプロキシサーバを考察中です。 そのための施策の一つとして 上流サーバへのアクセスをKeepAliveする という方法がありますが その際、プロキシサーバにどの程度性能に変化があるのかを調査してみました。 リバースプロキシのkeepalive設定 前提条件として Nginx > 1.1.4 が必要。 upstreamに keepalive というattributeがあるのでそれを設定します。 それと同時に、プロキシヘッダーにHTTP/1.1設定などを行いましょう。 ちなみにproxy_passだけだとkeepaliveできないようです。upstream必須。 あと、もちろんバックエンドサーバ側もkeepalive設定しておきます。 upstream http_backend { server oreore.micro.service;
Syn の独り言 : mod_proxy_balancer と nginx の Load Balancer 機能の夜明けはちかいぜよ - livedoor Blog（ブログ）
June 21, 201223:29 カテゴリOS / Middlewareネットワーク mod_proxy_balancer と nginx の Load Balancer 機能の夜明けはちかいぜよ 以前、Apache の mod_proxy_balancer と nginx のLoad Balancer の機能比較を行ってから 2年がたってしまった。 その間、両者とも Load Balancer としての機能が追加されてしまったので再比較。 ってか、比較するまでもなく機能面だけでみると両方とも私が必要としている２個の機能を 実装してしまった。 まず、least connections アルゴリズムによる負荷分散。 これは現時点の接続数が最も少ないワーカー（通常は web サーバー） に処理を割り振るというもの。 代表的な負荷分散アルゴリズムの `round-robbin' と比較して、
lua-nginx-module の紹介 ならびに Nginx+Lua+Redisによる動的なリバースプロキシの実装案 - hibomaの日記
Nginxは非常に強力なhttpdですが、独自のモジュールを実装しようとするとこれまた非常に敷居が高い印象です。 追記 この記事よりも前に http://openresty.org/#DynamicRoutingBasedOnRedis でほとんど同じ内容のエントリが書かれていました。こちらも参照ください モジュールの開発はむずかしい まず開発用のドキュメントはほとんどありません。必然 既存のモジュールをお手本としますが、コメントも少ないのでソースだけが頼りです。 {ファイル,ネットワーク} I/O を伴う処理では、Nginxのノンブロッキング/イベントドリブンのアーキテクチャにのっとってコールバックを駆使したCで実装する必要があり、LLで育ったゆとり脳では太刀打ちできませんでした lua-nginx-module が代わりになるかも なんらかのNginxモジュールを開発しなければならない
フロント/バックのreverse proxy構成で、指定秒数以内に必ずレスポンスを返す方法 - （ひ）メモ
目的 フロントがHTTPリクエストを受けて、バックエンドのアプリケーションサーバにreverse proxyするような構成において、指定秒数以内に何かしらのレスポンスを返したい。 200が返せない場合は、処理を打ち切って500を返したい。 背景 フロントでApacheやNginxをreverse proxyとして使っている場合、バックエンドが無応答になってしまうと、クライアントにレスポンスが返るのはデフォルトで数十〜数百秒後(ApacheのTimeoutのデフォルトは300秒、Nginxのproxy_read_timeoutのデフォルトは60秒)になってしまいます。 通常のWebサービスではこのオーダーのタイムアウトでもいいのかもしれませんが、数秒以内に(エラーでもいいので)レスポンスを返すことが求められる環境も存在します。(最近、特に多いのではないでしょうか:P) もちろんバックエンドが
nginxで認証用proxyサーバを作成
nginxと言えば、言わずと知れた高速なwebサーバ+ロードバランサです。 とにかく軽量で高速なので、apacheをこれに置き換えて高速化という話もよく聞くようになって来ました。 先日、このnginxとmemcacheを組み合わせてセッション認証サーバを構築したので、それについて書こうと思います。 今回作るシステムは、静的コンテンツを配信するサーバがすでにあり、 ・認証機構（ログイン画面）を追加 ・変更を最小限に抑えて開発 ・スケールアウトしやすい ・アクセス数が多いので、できるだけ処理を軽くする ことを目的とします。 この手のシステムは、既存システムに手を入れるのが普通ですが、既存システムでプログラムが動かないことには話になりません。 という事で、認証機構を追加したプロキシサーバを作成することで実現したいと思います。 仮に、PHPのみを使用して実装する場合は、下記のように出来ます。 ・ロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - cfsego/nginx-limit-upstream: limit the number of connections to upstream for NGINX
GitHub - anomalizer/ngx_aws_auth: nginx module to proxy to authenticated AWS services
宁波逼拘旅行社
VMware Tanzu Blog | VMware Tanzu