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

Shigeki Ohtsu @jovi0608

@Jxck_ なんで DC 内で TLS 使わないの？ GFEもTの Reverse Proxy もTLSほどいて、ふり先ロジック等入れてバックエンドもTLSよ(NSA対策も必要だから）。DC内通信なら自分でCA立ててPKI構築できるのでクライアント側より自由度は高くなるのに。

lef/HAYASHI, Tatsuya @lef

@jovi0608 @Jxck_ まあ、独自CAをまともに運用できる組織が世界にどれだけあるかといわれると…。:-D

Shigeki Ohtsu @jovi0608

@lef いや自社内DCのサーバ間でのPKIならCSPは関係ないから、ポリシー的には楽なはず。任意の期間で大量に発行でき、SDNやコンテナのデプロイとも連動も可能だし、不特定多数へのOVの発行よりよっぽど楽じゃないでしょうか？

Shigeki Ohtsu @jovi0608

@yosuke_furukawa そういう場合は ALT-SVC で動的に切り替えするのよ。バックエンド間での同期は必要だけど。

Shigeki Ohtsu @jovi0608

@yosuke_furukawa あと GOAWAY による graceful shutdown もね。 http2.github.io/http2-spec/#GO… この2つでエンドポイント間の通信切り替えを安全に行えることを狙っています。（くどいけどバックエンドのデータ同期は別問題ね）

Yosuke Furukawa @yosuke_furukawa

@jovi0608 まだあまり理解しきれていないんですが、ALT-SVC使うと中継する所で、他のホストに振り分ける事ができると。クライアントが接続している情報はバックエンドで別途同期するとして、接続時とは別のホストにつながったとしてもpushはできるはず、という事ですかね?

Shigeki Ohtsu @jovi0608

@yosuke_furukawa ALT-SVC/graceful shutdown はコネクションを安全に切り替える仕組み。pushをすごく気にしているみたいだけど、pushにはフェーズがあり、ストリームをPushPromiseで予約していた場合とかので救えない場合もある。

Shigeki Ohtsu @jovi0608

@yosuke_furukawa PushPromiseで予約していない場合はそもそもまだリクエストが来ていないので、切り替え後の CORS などの制限次第かな。

Yosuke Furukawa @yosuke_furukawa

@jovi0608 なるほど！pushを出したのは接続を保持したままにしないといけないからそうしてたんですが、元々の疑問はdisposableなものとの相性が気になっていたんで、それは ALT-SVC/GO-AWAYでgracefulに切り替える仕組みがあるっていうことですね。

Yosuke Furukawa @yosuke_furukawa

@jovi0608 その上で、Pushに限って言えば「段階によっては切り替わると救えないケースがある」と、PushPromiseで予約してたら無理だよっていう事ですね。理解しました。

Shigeki Ohtsu @jovi0608

@jovi0608 そうそう。gracefull は twitter からの要請で入った機能だから。彼らがバックエンドを切り替えする時は きちんとリクエストをストップさせてから新しいサーバに切り替えるようにして、取りこぼしがないように気を付けてるみたいね。

Shigeki Ohtsu @jovi0608

@yosuke_furukawa そういう時はサーバが予約ストリームを把握しているから、きちっと push stream を出してから ALT-SVC -> graceful shutdown っていう手順じゃないかな。

Yosuke Furukawa @yosuke_furukawa

@jovi0608 "予約するよ"って言われている状態だったらちゃんと一回は返してあげないとその段階で切れると無理っていう事ですね。なるほどなるほど。後はどうやってバックエンド同期するかというのはまた一つ別なテーマですね。流行りのMQ系の出番ですかね。

Shigeki Ohtsu @jovi0608

@yosuke_furukawa GCP のライブマイグレーションのすごさを見ると、その辺のバックエンドの同期技術ももっと低レイヤーでできているんじゃないかなぁと想像したりもするわ。 qiita.com/kazunori279/it…

koichik @koichik

@jovi0608 @Jxck_ 元々がBIG-IPなんかで終端してDC内ではTLS使ってない環境にHTTP/2導入するとしたら裏側はどうするの？って質問から始まってるので、なんでって聞かれると「今使ってないから」って答えになっちゃいますかね。

koichik @koichik

@jovi0608 @Jxck_ なので、もし裏側でもTLS使うべしということならそれでもいいのですが、でもNSA対策という話ならHTTP/2関係なく今すぐ裏側のHTTPS Everywhereも進むべきですよね？（身の回りでは）表側でさえなかなか進んでないけれど。。。

Jxck @Jxck_

@jovi0608 @koichik DC 内も TLS 運用になっていくんですかねぇ、本文にも書きましたが超大規模なとこはそこまでいけても、中規模くらいのところってそれが現実的なのかあまりわかってないです。もしそこも踏まえてやるならやっぱ全 https/2 で良いかもですが。

lef/HAYASHI, Tatsuya @lef

@jovi0608 はい。そう思います。思うのですが、それが多くのDCでオペレーションで出来るとはあまり思えないのです。一部の先端的なDCならやっててもおかしくない気がします。自動化のための証明書管理とかと合わせて今後普及する可能性はありそう。

Shigeki Ohtsu @jovi0608

@koichik あっ、別にTLSにすべしと主張しているわけじゃないです。NSA関係なくても h2(TLS)->Proxy->h2(TLS)の構成も現実的に検討して、取りうる選択肢じゃないかと言っているだけなんです。

Shigeki Ohtsu @jovi0608

@Jxck_ 現実感の有無を言うなら、クライアントーフロント部が全てTLS運用になるのかどうかも同様だと思う。、フロント部にHTTP/2を導入して大きくTLS運用に舵とりしたわけだから、バックエンドのTLS化も選択肢だと思う。もちろん全面導入するかどうかの判断は別だけど。

Jxck @Jxck_

@jovi0608 なるほど。ただ、 TLS 化に進んでいるのはインターネットであって、 DC 内は他にも暗号化したいものがあり TLS より下層で別途 IPsec etc な方かなと思っていたんですが、その場合でもやっぱり DC 内 TLS 運用はありえそうでしょうか？

Shigeki Ohtsu @jovi0608

@Jxck_ DC内のメッシュ的なサーバ間通信に双方向認証のIPSecを使うという判断は、僕にとっては非常に驚き。一方向のTLSの方がよっぽど楽だと思うけど。

Jxck @Jxck_

@jovi0608 なるほど。 TLS 運用して C ---> https/2 ---> P ---> https/2 ---> S の線も考えらるんですねぇ。ありがとうございます。

Jxck @Jxck_

@jovi0608 そうすると、コメントでもらったんですが、 nginx が upstream http2 をサポートしない(多分ほどくという意味)という方針だと厳しそうですね。forum.nginx.org/read.php?2,256…

Tatsuhiro Tsujikawa @tatsuhiro_t

@Jxck_ @jovi0608 そういう人にはnghttpx :)