Shigeki Ohtsu @jovi0608 @Jxck_ なんで DC 内で TLS 使わないの? GFEもTの Reverse Proxy もTLSほどいて、ふり先ロジック等入れてバックエンドもTLSよ(NSA対策も必要だから)。DC内通信なら自分でCA立ててPKI構築できるのでクライアント側より自由度は高くなるのに。
![HTTP2 時代のサーバサイドアーキテクチャフィードバック](https://cdn-ak-scissors.b.st-hatena.com/image/square/4c91731cfe2f08fb998777dfd60ddda0fe0bf37f/height=288;version=1;width=512/https%3A%2F%2Fs.tgstc.com%2Fogp3%2F7da3ff4c6bf84fa5ec80fae19bfa96c4-1200x630.jpeg)
Shigeki Ohtsu @jovi0608 @Jxck_ なんで DC 内で TLS 使わないの? GFEもTの Reverse Proxy もTLSほどいて、ふり先ロジック等入れてバックエンドもTLSよ(NSA対策も必要だから)。DC内通信なら自分でCA立ててPKI構築できるのでクライアント側より自由度は高くなるのに。
ストリームによる多重化 2つ目の特徴は「ストリーム」です。従来のHTTPでは、リクエストとレスポンスの組を1つずつしか同時に送受信できないことが、パフォーマンス上のボトルネックになっています。この問題を改善するべくHTTP/1.1では新たにパイプラインが導入されましたが、一部のレスポンスに時間がかかるような場面でレスポンスが詰まってしまう問題などがあり、広く使われてはいません。そこで、HTTP/2では1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることでこの問題に取り組んでいます。 1つの接続上に作られた複数のストリーム上では、複数のフレームを同時並行で転送できます。例えば、あるストリーム上ではリクエストにあたるフレームが送信中でも、別のストリームではレスポンスにあたるフレームを受信するといったことが可能になります。これにより、全体的なパフォーマンスが向上します。 ヘッダー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く