以前 (2.6.31 まで?) は以下の挙動*1。 最初のペイロードを受信するまで SYN_RECV ステート クライアントの ACK (TCP ハンドシェイクの最後のパケット) を受信していたとしても、SYN-ACK を送り続ける 190 秒たったら、サーバ側は TCP 接続確立失敗と認識 クライアントは SYN-ACK を送ってるから接続できてるつもり TCP の仕様的にどうなの、って話はわかる。ただ、IP 層はパケットロスの可能性があるわけで、インターネットを使っていて、この挙動で問題があるとしたら、それはアプリケーションのバグだと思うけど。一方で、 LAN 上でパケットロスが (ほぼ) 起こらない前提で作ってたら困ることがあるのかなー。Ubuntu の BTS で話が出てるのは、そういうケース (特定のハードウェアロードバランサと TCP_DEFER_ACCEPT を使う Apac

HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の２点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、１プロセス１コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション