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 Server Push
That way we can see whether Chrome would retrieve the image pushed by the / handler when we request /. I started tailoring main.go: // handleImage is the handler for serving `/image.svg`. // // It does nothing more than taking the byte array that // defines our SVG image and sending it downstream. func handleImage(w http.ResponseWriter, r *http.Request) { var err error w.Header().Set("Content-Type
手っ取り早くウェブアプリケーションにOAuth2認証を導入する - その手の平は尻もつかめるさ
bitly/oauth2_proxyを用いて，ウェブアプリケーションに手っ取り早くOAuth2認証を導入するという話です． oauth2_proxyは良い感じでOAuth2による認証を肩代わりしてくれる君で，何らかのリバースプロキシの認証機構と組み合わせて利用すると簡単にOAuth2ログインを実現することができます． 今回は例としてKibanaにGoogleのOAuth2ログインを導入してみたいと思います． 構成 Kibana bitly/oauth2_proxy nginx +------+ +-------+ +--------------+ +--------+ | | | | ----auth----> | | | | | user | --request--> | nginx | | oauth2_proxy | <--auth--> | Google | | | | | <--
Nginxで、リクエストを複製するmirrorモジュールが標準搭載された - ASnoKaze blog
[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを
NginxでWebサーバ間をトレースするrequest_id - Qiita
$request_id Nginx 1.11.0 以降に限りますが、リクエスト毎に発番されるIDの変数として $request_id が追加されたようです。 http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_id この変数を利用することにより、Nginxコアだけでサービス間のトレースを簡単に行うことが可能になります。 シンプルな例 以下のように、$request_idをログに含めるだけでリクエスト毎のIDを記録できます。 http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "
Update: Using Free Let’s Encrypt SSL/TLS Certificates with NGINX - NGINX
Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better
新しい圧縮アルゴリズムBrotliをnginxで試す - Qiita
BrotliはGoogleが最近公開した新しい圧縮アルゴリズムとその実装です。zopfliと違って従来のよく利用されているdeflateアルゴリズムと互換性はありませんが、deflateアルゴリズムと同じくくらい高速でなおかつ圧縮率がさらに向上しているのが特徴です。 今回はこのBrotliによるコンテンツ圧縮をnginxで利用する方法について紹介します。 ngx_brotli ngx_brotliはngx_http_gzip_moduleおよびngx_http_gzip_static_moduleのbrotli版に相当するnginxモジュールです。以下のようにnginxでgzip圧縮をしたことがある人ならなんとなくどう使うかわかるディレクティブがあります。（ディレクティブはほかにもいろいろとあります。詳しくはngx_brotliのREADME.mdを参照して下さい） ディレクティブ名 値
なんか重いウェブサーバはディスクアクセスが遅いことが原因だったのでそれを解決した話 - Qiita
GMOクラウド ALTUSにフラッシュディスクが追加されていました（2018年8月29日追記） 少し前からですが、GMOクラウドのディスクでフラッシュディスク（SSD）が選択できるようになっていました。 この記事を書いたとき（2015年）の状況は再現できないですが、恐らくディスクアクセスに関する悩みからは開放されそうですね。 はじめに これまでの経緯はこちらにあります。 マルチコアサーバがなんか重い時に原因究明しかけていました。 管理に携わっているサーバが「なんか重い」症状に陥った件についての解決編です。 LAがちょくちょくあがって問題認識 対象サーバはマルチコアでコア別に見ると特定のコアで普段からiowaitが高い ddやfioなどでディスク負荷を掛けるとめっちゃ重い という状態でした。 調査 サポセンからの連絡 GMOのクラウドを使っていますがここサポートセンターは優しいです。ddとf
mruby in HTTP server - connect HTTP/1 with HTTP/2 servers - // Speaker Deck
モノリス開発の名残から脱却、マルチプロダクト開発における多様な開発者のニーズに応える使い勝手と 堅牢性を追求した認可基盤刷新の過程と工夫
nginxをWebSocketのリバースプロキシとして使う - the glue
経緯 WebSocketを使ったアプリケーションを作ったが、ポートが80しか使えない nginxでどっちも80に流したい ポイント / はまり所 WebSocketのプロキシにはUpgradeヘッダ(HTTP 1.1)への対応が必要 Upgradeヘッダへの対応は nginx v1.3.13以降 参考: WebSocket proxying 厳しい条件から先に書く デフォルトだと30秒通信がないと切断される（！） nginxでリバースプロキシしているときだけ一定時間で接続が切れるので何かと思えば、 普通のHTTPの通信と同様に30秒（だったはず）通信がなかった場合はタイムアウトってことで自動でコネクションを切ってくれていたみたい。 ping/pongを30s以内にやればいいんだろうけど、とりあえず5分に設定。 config server { listen *:80 default_serv
Inside NGINX: How We Designed for Performance & Scale
NGINX leads the pack in web performance, and it’s all due to the way the software is designed. Whereas many web servers and application servers use a simple threaded or process‑based architecture, NGINX stands out with a sophisticated event‑driven architecture that enables it to scale to hundreds of thousands of concurrent connections on modern hardware. The Inside NGINX infographic drills down fr
Socket Sharding in NGINX Release 1.9.1
F5 Sites DevCentral Connect & learn in our hosted community F5 Labs The latest threat intel and research to help protect your apps MyF5 Your key to everything F5, including support, registration keys, and subscriptions Partner Central Research and support for partners LearnF5 Guidance, insights, and how to use F5 products Contact F5 Contact F5 Sales Talk to an F5 sales representative Contact F5 Su
Redirecting to ssl-config.mozilla.org...
Mozilla SSL Configuration Generator Redirecting to the updated SSL Configuration Generator…
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Advanced nginx in mercari - How to handle over 1,200,000 HTTPS Reqs/Min
nginxのパフォーマンスチューニング
ngx_dynamic_upstreamでnginxのアップストリームを動的に変更する - Qiita
HTTP/1.1 -> SPDY/3.1 -> HTTP/2
NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くした
Sass を今すぐ実務で使おうよ！ « LINE Engineers' Blog
Making HTTPS Fast(er) - nginx.conf
