H2O version 1.4.0 released with outstanding support for forward secrecy and load balancing (and the experimental mruby handler)
H2O version 1.4.0 released with outstanding support for forward secrecy and load balancing (and the experimental mruby handler) Today I am happy to announce the release of the H2O HTTP/2 server version 1.4.0. There have been a few changes and bug fixes from version 1.3.1 (that showed big performance improvements over the older generations of HTTP servers without support for request prioritization)
HTTP/2時代のバックエンド通信検討メモ - ぼちぼち日記
1. はじめに、 今朝、こんな返事を元に kazuho さんとIPsec/TLS等バックエンド通信について議論する機会を得ました。 せっかくだから現時点での自分の考えを整理してメモとして残しておきます。 普段ちゃんとしたストーリをもったエントリーしか書いていないのですが、今回は時間がないのでちゃんとした論理的文章になっていないメモ程度のものです、あしからず。 以下、フロント側に HTTP/2 を導入した場合のバックエンド通信をどう考えるかのメモです。 2. 性能的観点 フロントにHTTP/2を導入したということは、ブラウザのHTTP HoLブロック解消が目的の一つだと思う。HTTP/2の多重化通信によってクライアントからこれまで以上の同時リクエストをさばかないといけない（だいたい初期値は同時100接続ぐらいに制限されていると思う）。 他方バックエンド側通信は、クライアント側がブラウザではな
HTTP/2から見えるTLS事情 - あどけない話
これは HTTP/2 アドベントカレンダー19日目の記事です。 この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。 実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。 このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
