HTTP2 時代のサーバサイドアーキテクチャフィードバック

Jxck @Jxck_

@tatsuhiro_t @jovi0608 はやく Nginx 並のシェアとってください！！！１

Shigeki Ohtsu @jovi0608

@Jxck_ @tatsuhiro_t nginxの件は、バックエンド側のTTLがフロントより小さくHoLブロック耐性があるので、単に優先順位の問題だと思う。また振り分けロジックが必要な場合も多いので最初はnghttp2をフックするようなカスタムモジュールになるんじゃないかな。

Jxck @Jxck_

@jovi0608 @tatsuhiro_t nginx-nghttp-module vs nginx-h2o-module 胸熱な流れw

Kazuho Oku @kazuho

アプリケーションサーバにpush可能なコンテンツを置かないだろうし、リバースプロキシは複数のTCP接続からのリクエストを単一のTCPに重畳して流すので、H2 pushはアプリケーションサーバとの間では使わない形になるかなと htn.to/rwP4Re

Kazuho Oku @kazuho

上流接続を、下流接続のTCPとは異なる単位でまとめないと、特にDC内をHTTPSにする場合は速度やレイテンシ的な問題が発生するでしょうね

Yosuke Furukawa @yosuke_furukawa

@kazuho うーむ、そうするとServiceWorkerでのpush通知をhttp2 pushを使って実現するのはできなくなりますね。プッシュ通知したい情報はアプリが一番知っているはずですし。もしくはリバプロがもっと役割が増える形になるんですかね。

Kazuho Oku @kazuho

@yosuke_furukawa リバプロの役割が増えるか、それようのhttpdを立てるんでしょうね。iojsとかで

Jxck @Jxck_

@kazuho それはアプリからの Push 指示は Link ヘッダで十分という意味でしょうか？それともアプリは Push に関与しないという意味でしょうか？

Kazuho Oku @kazuho

@Jxck_ Linkヘッダで十分ではないですが、アプリケーションサーバとHTTP/2接続するとしても、現状と同様、複数のクライアントからのリクエストを重畳するアプローチを取り続けるだろうし、その場合アプリサーバからH2 pushすることはできないだろう。という意味です

Jxck @Jxck_

@kazuho アップストリームと HTTP/2 接続ができているなら Push ができないということは無いと思うのですが、そこがよくわかりません。どういう意味でしょうか？

Kazuho Oku @kazuho

@Jxck_ 「リバースプロキシは複数のTCP接続からのリクエストを単一のTCPに重畳して流す」ようにしないと、特に上流との接続をTLSで保護する場合、上流との接続切断のオーバーヘッドが大きくなりすぎます。一方、重畳するとpushがどのクライアントに対するものだったか判別不能に

Tatsuhiro Tsujikawa @tatsuhiro_t

@kazuho @Jxck_ proxyは上流と下流のストリームidの組を知っているとすると上流からのpush promiseを行き先の下流へ流せるかも

Jxck @Jxck_

@kazuho ああ、なるほど。 HTTP2 の多重化じゃなくて、それを TCP でさらに束ねた時、複数コネクションでの一意な stream id が無いとダメということですか。それは考えてませんでした。うーん、 Google とかどうしてるんだろう。。

Tatsuhiro Tsujikawa @tatsuhiro_t

@Jxck_ @jovi0608 ただしngttpxにホストやパスで振り分ける機能はないですけどね今のところ

Kazuho Oku @kazuho

@Jxck_ そもそもpush使ってなry

bokko @cubicdaiya

nginxのSPDY実装でもserver pushは実装されてないし、http/2サポートするようになってもやっぱりserver pushは実装されないんじやないかしら？あくまでhttp/2ターミネーションのみになる気がしてる。

Jxck @Jxck_

@kazuho link での push って実際そこまでかなとは思うんですが、 ws over http2 とか grpc や service worker 向けみたいなものを考えると、 Push 自体をどうやって可能にするかは考えておく価値があるかなと思ってます。

Kazuho Oku @kazuho

Jxckさんの記事で触れられてたLinkヘッダでpushするの遅すぎる件は同感だし、そのへんはh2 httpdの設定でプッシュするコンテンツを指定する形がいいんじゃないかとは思ってます。プッシュにどれほどの意味があるかというのはさておき

Tatsuhiro Tsujikawa @tatsuhiro_t

@kazuho @Jxck_ アプリケーションサーバーがh2を話すと仮定してリクエストHEADERSのstream idに対してPPすると考えてました。

Kazuho Oku @kazuho

@Jxck_ long-polling的な用途で言うと、リバプロがクライアントとの接続断を検知した時にアプリケーションサーバに通知する方法もなかったりしますし、通知用途では別FQDNにサーバを用意するほうが現実的かなぁと

Tatsuhiro Tsujikawa @tatsuhiro_t

@jovi0608 @Jxck_ 低遅延のバックエンドではh1でも十分という意見もあるかも。grpcみたいなのがバックにいるとだめだけど

Jxck @Jxck_

@kazuho Push をコンテンツ配信の一部としては考えないということですよね。まあそれはなんとなくわかります。じゃあ今度 Push クラスタみたいなものってどうやって組むんだろうという話になりそうな気もしますね。そういうのは h3 の話につながるのかもですが。

Kazuho Oku @kazuho

JavaやiojsのアプリケーションサーバはH2に移行できるだろうけど、他の言語も移行するの/移項するメリットあるの？

Jxck @Jxck_

まあそういうの全て踏まえた上で「本当に HTTP2 に移行する必要あるのか？」については、まだまだちゃんと議論がいるよねというのはある。

Tatsuhiro Tsujikawa @tatsuhiro_t

@kazuho @Jxck_ ホップ毎の設定はだめですね。確かに。