HTTP/2 Rapid Reset Attack Impacting F5 NGINX Products - 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
これからドンドン使われていくSNIについて
SNIとは元々SSL通信は1つのIPアドレスに対して、1つの証明書が前提になっていました。というのもSSLでは暗号化されているため、1つのIPアドレスに対して複数の証明書を持っていた場合、リクエストが来たときにどの証明書を使えばいいか判断できないからです。 しかしこれだとどう考えてもつらいことが分かります。昨今の流れとして常時SSL通信が当たり前の世界になりつつあります。すべてのドメインに対して全てのIPアドレスを用意するのは特にIPv4では現実的ではありません。 そもそもHTTPではVirtual Hostを使って、1つのIPアドレスで複数のドメインのサイトを扱うことがとても一般的です。 そこで有用なのがSNIです。SNIは最初の通信時に今から通信したいサーバーネームをサーバーに平文で渡すことで、通信したいSSL証明書を指定できます。 SNIを使うことでHTTPのVirtual Host
NginxがHTTP2サーバプッシュに対応したので試す - ASnoKaze blog
追記 [nginx-announce] nginx-1.13.9 http://mailman.nginx.org/pipermail/nginx-announce/2018/000207.html 1.13.9でサーバプッシュがサポートされました 先程、Nginxでサーバプッシュをサポートするコミットが入ったので試す。 HTTP/2: server push. http://hg.nginx.org/nginx/rev/641306096f5b ビルド $ git clone https://github.com/nginx/nginx.git $ cd ./nginx $ ./auto/configure --with-http_ssl_module --with-http_v2_module $ make $ sudo make install #一旦インストールしてしまう 設定 一
Gaurun Powered by HTTP/2 | メルカリエンジニアリング
SREチームの@cubicdaiyaです。つい先日メルカリでOSSとして開発・公開しているスマホアプリ向けのプッシュ通知用ゲートウェイサーバであるGaurunがGCM、APNsともにHTTP/2を利用したプッシュ通知に対応したので紹介します。 github.com ちなみにロゴも出来ました。 Gaurun〜A general push notification server in Go〜 繰り返しになりますが、GaurunはメルカリでOSSとして開発・公開しているスマホアプリ向けのプッシュ通知用ゲートウェイサーバです。GCMやAPNsへのプッシュ通知処理をHTTP + JSONベースの非同期処理APIでラップして大量のプッシュ通知を素早く送信することができるのが特徴です。 github.com メルカリのプッシュ通知のシステムもこのGaurunにより構築されています。クライアントとの通信に
HAProxyでHTTP/2のTLS終端する際のALPN設定 - ASnoKaze blog
HAProxy 1.5でALPNに対応していた。 HTTP/2 over TLSの通信を、HAProxyでTLSを終端することで、TLS対応を行わないであろうVarnishなどでもh2c接続が可能となる。 (HAProxy自体のhttp2対応はまだ先) 今回はバックエンドにNginxをh2cでリッスンさせて試してみた 構成 構成としては以下の図のとおりである。 HAproxyはTLSの終端のみを行い、中身のメッセージをそのままバックエンドに送信する。この時HAProxyはHTTP/2の処理は行わない。 バックエンドのNginxはh2cのダイレクトで通信を受け付ける。 HAProxyの設定 bindでalpn h2を指定する if { ssl_fc_alpn -i h2 }で、h2ならh2cのバックエンドへ、そうでなければhttp/1.1のバックエンドへ (opensslのバージョンが足りな
はてなで新しくWebサービスを作るときのインフラの作り方 - Hatena Developer Blog
この記事ははてなデベロッパーアドベントカレンダーを始めます - Hatena Developer Blogの17日目の記事です．昨日は id:yashigani_w の Promiseを学ぶためにSwiftでPromiseを実装してみた話 - yashigani?.days でした． こんにちは、はてなの id:wtatsuru です。はてなのインフラ全般をみています。 はてなでは、しばしば新サービスを構築する機会があります。正式サービスもあれば、はてラボ のような実験的サービス、内部の Microserviceの一部になっているものなど多種多様なものがあります。新規サービスのインフラを構築する際は、最小構成でありつつ後のスケールやメンテナンスを考えた仕組みを作っていくことになります。この記事では、2015年12月現在のはてなでの標準的な構成を紹介していきます。 新サービスの最小構成 こち
HTTP2 時代のサーバサイドアーキテクチャ考察 - Block Rockin’ Codes
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
nginxのリクエストボディのバッファリングに関する問題とその改善策 - Qiita
nginxのデフォルトの動作ではクライアントから受け取ったリクエストボディをメモリにバッファリングするようになっています。 このメモリバッファのサイズはclient_body_buffer_sizeで変更することができ、リクエストボディのサイズがこのバッファのサイズを越えた場合はclient_body_temp_pathにファイルとして書き出されます。 ログレベルがwarn以上の場合はエラーログにa client request body is buffered ...という警告が出ます。 2015/03/29 14:02:20 [warn] 6965#0: *1 a client request body is buffered to a temporary file /etc/nginx/client_body_temp/0000000001, client: x.x.x.x, ser
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
