サーバーがSYNパケットに応答してSYN / ACKパケットを送信しないのはなぜですか

最近、当社のWebサイトを閲覧するMacおよびLinuxユーザーに限定されているTCP接続の問題に気づきました。

ユーザーの観点からは、Webサイトへの非常に長い接続時間（> 11秒）として表示されます。

私たちはこの問題の技術的な特徴を追跡することができましたが、なぜそれが起こっているのか、どうやってそれを修正するのかがわかりません。

基本的に、クライアントのマシンはSYN接続を送信してTCP接続を確立し、Webサーバーはそれを受信しますが、SYN / ACKパケットで応答しません。クライアントが多くのSYNパケットを送信した後、サーバーは最終的にSYN / ACKパケットで応答し、接続の残りの部分はすべて問題ありません。

そして、もちろん、問題のキッカー：それは断続的であり、常に発生するわけではありません（ただし、10〜30％の時間で発生します）

OSとしてFedora 12 Linuxを使用し、WebサーバーとしてNginxを使用しています。

Wireshark分析のスクリーンショット

更新：

クライアントでウィンドウスケーリングをオフにすると、問題が発生しなくなりました。今、私はちょうどサーバー側の解像度が必要です（すべてのクライアントがこれを行うことはできません）

最終更新：

解決策は、公開されているサーバーでTCPウィンドウのスケーリング と TCPタイムスタンプの両方をオフにすることでした。

これとまったく同じ問題がありました。TCPタイムスタンプを無効にするだけで問題は解決しました。

sysctl -w net.ipv4.tcp_timestamps=0

この変更を永続的にするには、にエントリを作成し/etc/sysctl.confます。

TCPウィンドウスケールオプションを無効にする場合は十分注意してください。このオプションは、インターネット上で最大のパフォーマンスを提供するために重要です。ラウンドトリップ時間が（基本的にpingと同じ）55ミリ秒を超える場合、10メガビット/秒の接続を持つユーザーは次善の転送を行います。

同じNATの背後に複数のデバイスがあるときに、この問題に本当に気付きました。タイムスタンプフィールドにまったく異なる値を入力しているため、AndroidデバイスとOSXマシンのタイムスタンプを同時に表示するサーバーが混乱している可能性があります。

私の場合、次のコマンドにより、LinuxサーバーからのSYN / ACK応答が欠落する問題が修正されました。

sysctl -w net.ipv4.tcp_tw_recycle=0

TCPタイムスタンプは高性能（PAWS、ウィンドウスケーリングなど）に役立つため、TCPタイムスタンプを無効にするよりも正しいと思います。

上のドキュメントtcp_tw_recycleを明示的には、多くのNATルータは、タイムスタンプを保存し、同じIPからのタイムスタンプが一致していないようので、中にキックを足として、それを有効にすることを推奨されていないと述べています。

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.

ただ疑問に思うが、SYNパケット（フレーム＃539;受け入れられたもの）の場合、WSおよびTSVフィールドが「情報」列にないのはなぜですか？

WSはTCPウィンドウスケーリングであり、TSVはタイムスタンプ値です。両方ともtcp.optionsフィールドの下にあり、Wiresharkが存在する場合はそれらを表示する必要があります。クライアントのTCP / IPスタックが8回目の試行で異なるSYNパケットを再送信した可能性があり、それが突然確認された理由でしたか？

フレーム539の内部値を教えてください。SYN / ACKは、WSが有効になっていないSYNパケットに対して常に送信されますか？

まったく同じ問題に遭遇しました（syn-ackを送信せずにサーバーに固定するのにかなり時間がかかりました）。

「解決策は、一般からアクセス可能なサーバーでtcpウィンドウのスケーリングとtcpタイムスタンプをオフにすることでした。」

Ansisが述べたことを続けるために、ファイアウォールがTCP Windows Scalingをサポートしていないときにこのような問題を見てきました。これら2つのホスト間にあるメーカー/モデルのファイアウォールは何ですか？

不足しているSYN / ACKは、ファイアウォールのSYNFLOOD保護の制限が低すぎることが原因である可能性があります。サーバーユーザーへの接続の数によって異なります。spdyを使用すると、接続の数が減り、net.ipv4.tcp_timestampsオフにしても効果がない場合に役立ちます。

これは、バックログがいっぱいのときのリスニングTCPソケットの動作です。

Ngnixでは、バックログ引数をリッスンして構成に設定できます：http ://wiki.nginx.org/HttpCoreModule#listen

80 backlog = numをリッスンします

numを1024などのデフォルトより大きい値に設定してみてください。

完全なリッスンキューが実際にあなたの問題であるという保証はありませんが、これは最初に確認するのが良いことです。

Linux TCPクライアントが3回の試行後にSYNパケットを変更し、Window Scalingオプションを削除することを発見しました。カーネル開発者は、これがインターネットの接続障害の一般的な原因であると考えたと思います

これらのクライアントが11秒後に接続を管理する理由を説明します（ウィンドウレスTCP SYNは、デフォルト設定での簡単なテストで9秒後に発生します）

私も同様の問題を抱えていましたが、私の場合、誤って計算されたのはTCPチェックサムでした。クライアントはvethの背後にあり、ethtool -K veth0 rx off tx offを実行するとうまくいきました。