High Performance Browser Networking

一部（？）に需要があったようなので、再掲。

実はまだ全部読んでおらず、物理層やトランスポート層の話を脱してアプリケーション層というかHTTPに来た所。

僕が主に興味を惹かれたのはTCP周りの話なので、その辺だけまとめる。読んだ本の要約？というのは、ヘタしたら著作権侵害というか内容そのものの引写しになってしまいそうで難しい。

話の前提

• TCPは不安定で細い回線を前提として元々作られたプロトコルなので、現代の比較的安定した太い回線の上では非効率な部分が多々ある
• アプリケーションがデータ送り始める前にいわゆる3-way handshakeのための通信をえっちらおっちらやらないといけない。ここにかかる時間は、いかに帯域が広くともレイテンシに引っ張られてしまう。
  • この部分のロスはいわゆるHTTP keepaliveで回避できる、のだが...
• そうしてhandshakeした後にまたえっちらおっちらcongestion window sizeを広げていかなかればいけない。要は初めからモリモリ帯域を使うことは出来ない。
  • せっかく広げたwindow sizeも、当然ながら新しいconnectionを張ればまた最初からやり直し
  • keepaliveしてても、しばらく通信してなければwindow sizeは縮められてまた一からやり直し
  • keepaliveは3-way handshakeのコスト「だけ」を減らすものであって銀の弾丸ではない

TCP Fast Open

簡単に言うと、3-way handshakeの間についでにデータ送っちゃえばいいよねーっていうのがTCP Fast Open。Linuxで対応しているのは3.7以降。ClientとServerが両方対応してないといけないため実際にモリモリ使えるようになるのはしばらく後だと思われるが、Google調べによるとこれだけでWeb Pageのロード時間を平均10%削減できるそうな。特にkeepaliveできない事情のある環境で効果がありそう。

SSR (Slow-Start Restart)

簡単に言うと、keepaliveしててもしばらく通信がなかったらcongestion window sizeをresetしてやるぜ！ネットワークの状況変わってるかもしれねえからな！という機能。keepaliveを利用しており、かつ輻輳が少ない環境ではこれは逆にoffになっていた方が効率はよいと思われる。お手元のLinuxでenableかどうかは以下のコマンドで。

sysctl net.ipv4.tcp_slow_start_after_idle

Window Scaling (RFC 1323)

簡単に言うと、最大65535byteと決まっているTCPのwindow sizeを最大1GB(!)までくぱーさせちゃおうぜ！っていう話。これは既に多くのOSでデフォルトONになっているらしいが、中間のネットワーク機器がオプションを外してしまう場合があるらしい。お手元のLinuxでenableかどうかは以下のコマンドで。

sysctl net.ipv4.tcp_window_scaling

PRR (Propotional Rate Reduction)

簡単に言うと、packet lossが発生した時に縮めたwindow sizeをオリジナルのアルゴリズム(AIMD)より素早くrecoverさせるためのアルゴリズム、の名前。Linux3.2以降でデフォルト。packet lossがあった場合のレイテンシを従来に比べて平均3-10%削減できる、そうな。これもGoogle調べ。

色々あるんですなあ。

じゃあの。