debiancdn

AWS, Content Delivery Network and Debian

タグアーカイブ: tcp

TCP window controlが肝な話

クラウドはクラウドというくらいでネットワークの先に資源があり、そこにたどり着かない限りなんにもならない。そして、世の中遠くのネットワーク資源を使うための工夫は数限りなくある。

B2B的な、通信相手が固定されているなら、AsperaでもSteelheadでもSkeedでも好きなものを使えばいいのだが、マスが相手となるとそうは行かない。TCPを使うしか事実上ない。もっというとHTTP+TCP(よくてHTTPS)をどうするかということに注力するしかない。

で、基礎知識としてはTCP Windowコントロールとなる。自分のブログで “TCP window” で検索→https://debiancdn.wordpress.com/?s=TCP+window すると、けっこう頻繁にTCP Windowコントロールのことを書いているな。。

とはいえパイプ計算機について書いたことがなかったようだ。

SWITCH – For universities – Network & Internet – University Network – Tools – Throughput Calculator (TCP)

Bandwidth-delay Product and buffer size BDP (8.1 Mbit/sec, 80.0 ms) = 0.08 MByte required tcp buffer to reach 8.1 Mbps with RTT of 80.0 ms >= 82.9 KByte maximum throughput with a TCP window of 12 KByte and RTT of 80.0 ms <= 1.17 Mbit/sec. Further readings about network performance in eduPERT knowledge base

まあいわゆるLong-Fat Pipe問題は昔からあるのでいまよんでもおもしろいものがある。また、自分で書いてもいいのだが、かぶってもどうしょうもないので、参考になるものをはっておく

Amazon ELBをうまくつかうには、KeepAliveを有効にしよう。Timeoutは60秒よりだいぶ長くしよう。その背景。

鯖管のメモ帳: AWSのELBでHealthyHostCountが0になるという記事の中で

■AWSのELBとApacheを使う際の注意点

・Timeoutは120以上が推奨

・ApacheのKeepAliveは有効にすべし。ELBとの接続効率があがる。

という形ですでにやるべきことは書いてあるのが、なぜそうなるか。。(いそがしい人は後は読まなくてok!)

根本的な理由としては、ELBはTCPを単にリレーしているのではなくて、アプリケーションレイヤのプロキシであることによるものが大きい。ELBはバックエンドのEC2との間で無通信の場合でも60秒はセッションを維持する。

ELBはTCP Persistent Connectionを提供し、webサーバとの間のTCPセッションをつかいまわすことによってTCPのハンドシェイク時間を削減して高速化している。

webサーバのTimeoutを60秒より短かくするとどうなるか。どうかするとあわれなELBはwebサーバから切られたことを知らず、TCPセッションを使おうとして失敗することもある。折角ハンドシェイクをとばして高速化できるチャンスを逃してしまうことになる。

じゃあなんでELBでないフツーのサイトやフツーのロードバランサで構成するwebサイトにおいて「KeepAliveを無効にして、Timeoutは短かく(たとえば5秒)しよう」という言説が流れているのか。

これは、クライアントがずっとコネクションをはりっぱなしにする傾向があるから。

HTTP keep-alive connection timeouts « FastMail.FM Weblog というすばらしい記事によると、

  • Opera 11.11 – 120 seconds
  • Chrome 13 – at least 300 seconds (server closed after 300 second timeout)
  • IE 9 – 60 seconds (changeable in the registry, appears to apply to IE 8/9 as well though the page only mentions IE 5/6/7)
  • Firefox 4 – 115 seconds (changeable in about:config with network.http.keep-alive.timeout preference)

といった具合。ほとんどのwebサイトにおいては、いくら通信が高速化されるとはいえ100秒も通信維持されても困ることばかりだろう。

「数千数万のクライアントからのコネクションを維持したままだとサーバのメモリを食って死んでしまう」→「ならば、そんなクライアントとは手を切るぜ」→「そのためには..」という常識がうまれた。

ELBはトラフィックが増えれば自在にリソースを変更するすぐれもの。そもそもELBがTCPのセッションを維持するのにどんだけメモリを食っていようが、そんなことはユーザの知ったことではない。そこが普通のロードバランサとは違う。

ELBをサーバとクライアントの間において、コネクションを維持したらどうなる? クライアントががんばって用意しているHTTP keepaliveはELBとの間で維持して、サーバはELBとのコネクションだけを考えればいいから、高速化する。

というわけで、ELBを使わない手はないし、その機能を生かすためにwebサーバはTCP keepaliveを有効にしてTimeoutを120秒にするのがいいのでした。

ELBの扱えるTCP portは25,80, 443 or 1024 to 65535

これもまた知られてないシリーズか。
ELBの扱えるTCP portは25,80, 443 or 1024 to 65535。
そして、違うportにアクセスしてもICMPでrefuseを通知したりはしない。