以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

Mike Belshe「HTTP Speed+Mobilityレビュー」

斜め読み

belshe.com 2012.3.29のエントリ

Comments on Microsoft’s SPDY Proposal « Mike's Lookout

MSがIETFへ出したHTTP Speed+Mobilityへ、SPDYの仕様の作者の一人による項目別の寸評

  • MS案とSPDYの違い等がピンポイントで分かって有益
以下斜め読んだ内容
  • MS案ではコア部分はSPDYそのまま
    • SPDYから取り込まれてるもの
      • 多重化
      • リクエストの優先順位コントロール
      • 圧縮
    • フレームのシンタックスもSPDYそのまま
      • SYN_STREAM
      • SYN_RESET
      • SYN_REPLY
      • HEADERS
  • SPDYはwebsocketより古い歴史
  • 「HTTP Speed+Mobility」では、シンタックスをwebsocketに似たものへ修正してる
    • プロトコル面でSPDYと違いを生み出す変更ではない
    • この修正でSPDYと他のWebテクノロジーとの類似性が強まった
  • シンタックスか。他のプロトコルとのシンメトリーか
    • 自分はシンメトリーを重視する派
  • websocketsのシンタックスはSPDYより複雑、だと思う
    • まあこれは枝葉の話
  • MSの提案は成程と思うし、こういう動きがMSから出ること自体うれしい
  • MS案ではFlow Controlを削除された
    • クライアントから10ストリーム投げたとする。そのうちの１つが詰まったしたときに、flow controlが実装されてないと困る
      • 全部のストリームを終了させてメモリを解放する。もしくは、残りのストリームも詰まらせるか。２つの道しかない
    • TCPのflow controlとSPDYのflow controlは別物
    • SPDYの初期ドラフトではFlow Controlがなかった
    • SPDYを実装してみて始めた得た知見
      • flow controlが必須であり、パフォーマンスにも優れ、シンプルになる.
      • 従来のプロトコルの理論からは得られなかった知見
  • 実装しないと分からない話もある
  • HTTPの仕様はオプションの山
    • pipelining
    • chunked upload
    • absolute uri
    • オプションになると実装されず、利用されないという流れができる
  • MS案にはベンチマークがない
    • MS案の本当の所の性能がわからない
  • MS案ではヘッダ圧縮がオプションに修正されてる
  • MS案ではSETTINGSフレームが削除されてる
    • これはMSの失点だと思う
    • SPDYのスペックではクライアントから際限なくリクエスト投げれる
    • サーバー側ではクライアントからのリクエストを制限してたい場合がある。
    • サーバー側からSPDY接続を制限するためにSETTINGSフレーム使う
  • MS案ではserver pushがオプション扱い
    • SPDYでもserver pushは色々意見分かれてる
    • 削除派の言うことにも一理ある
    • だが「オプション扱い」という案はケリの付け方として最悪
    • 削除しないでオプション扱いにするのは、実装への負担が大きくなり、何もよい結果をもたらさない可能性だってある
    • MS案の作者は、server push=オプション使いでメリットあるよ、と謳ってるが。裏付けになるデータ、ベンチマークない
  • MS案ではIP poolingが削除
    • MSはベンチマークもデータも実装の詳細諸々が一切出してないから
    • しかも削除した理由が不明瞭
    • SPDYにとって、ip poolはパフォーマンス改良とネットワーク効率アップにとって重要
    • ベンチマークがあれば、ip pool削除のメリットが測定可能な形で示される
    • おそらく、モバイル環境ではMS案はSPDYより遅くなるはず
  • MS案でSPDYコア部分が取り込まれてる点は、HTTP2.0でSPDYのコア部分は取り込まれることが有望な証拠
  • MS案からSPDYに出されてる懸念点は尤もなもの
  • MSはMS案について十分テストや検証してないのは明確
    • SPDY側は、その点色々データ揃えてる
    • なので意見の異なる部分はそのデータをもとにあっさり収束するはず
  • コメント欄
    • Q：圧縮+ssl暗号化環境になるのでデバッグ超大変。デバッグ用にヘッダ圧縮をオフにする機能はメリットあると思うが。
    • A：デバッグ目的でヘッダ圧縮をオプション扱いにするのは、一理ある。
    • Q：SPDY=SSL必須もMS案との違いでは？
      • SSLはうちのサーバーのスペックからすると大変。さらにSSLは証明書まわりが大変
      • DNSSECが普及すれば話が変わるが、そんな未来がまだやってきてない
      • end to endのセキュリティを提供するのは大事だが、プロトコルレベルで強制するんじゃなくサイトオーナーの裁量に任せる考えの方が好き
    • A：誤解あり。SPDYのスペックではSSLは強制されない。SSLにすべきだと思うが、その辺は利用者にゆだねられてる
    • Q：TLS強制だとCA認証まわりが大変
    • A：「実装必須ただし利用は自由」という位置づけで全く使われず消えた技術がたくさんある。Pipeliningとかchunked uploads。
      • With specific regard to compression, we know that only about 70% of compress-able content is compressed. The rest is just sad, because it hurts the net, it hurts the users, and it hurts the sites. If we let header compression be optional, I see no reason why it wouldn’t end up like the myriad of mandatory-but-optional features that went before and are no longer usable.Regarding your objections on TLS – there was a time people said an entire HTTP stack was too much for small embedded devices. It’s just not true anymore. Also – keep in mind you don’t need general CA support for all TLS in embedded devices. Bake in the cert you expect on your server with an infinite lifetime and be done with it. If you’re not worried about authentication (or were otherwise willing to settle with HTTP anyway), you’re done.At the end of the day, we shouldn’t decide yes-or-no for security based on technical principles for small devices. We should be deciding for security because we think its necessary for users or not. I think it is necessary, and it is clear that when it is optional, too many people don’t know better and opt out – creating the unsecured world we live in now.
    • Q：圧縮にgzip使ってるけど、gzipより速いの最近いくつかある。 Snappy、QuickLZ、LZO
    • A：「速い」は多義的で何を指してるのかわからないが。。。
      • ファイル圧縮時間、データ転送時間、ファイル解答時間。
      • ちゃんとしたベンチマークみたことないから、検討してない。もし検討したとしてもパテント系で面倒なら避ける