TCPの受信フロー制御
正常なリンク上でTCPが一時停止するのはなぜ？
受信側システムは、アプリケーションが読み取るまでTCPデータを保持します。受信領域に空きがなくなると、ゼロウィンドウを通知することがあります。送信側はその制限に従い、現在のウィンドウ情報を得るためにプローブを送ります。読み取りによってウィンドウが再び開くことはありますが、プローブだけでは処理が停止したアプリケーションを修復できません。これらは一般的な概念であり、製品の測定値や一定の復旧時間を示すものではありません。
バッファ
データは、アプリケーションが読み取る前にシステムバッファ内で待機することがあります。
フィードバック
受信側は、自身の受信上限を送信側に通知します。
再開放
読み取りによって受信領域に空きが生じ、プローブによって現在のウィンドウ状態を確認できます。
どの接続で、どのエンドポイントがゼロを通知しているかを記録します。
ウィンドウの変化を、アプリケーションの読み取りログやリソースログと時系列で突き合わせます。
許可されたテストで、継続的な読み取りと読み取りを遅らせた場合を比較します。
選定・検証チェックリスト — 展開
| 確認項目 | 確認する内容 | 検証方法 |
|---|---|---|
| 接続 | エンドポイントと方向 | アドレスとポートの組を記録 |
| 受信側 | アプリケーションが読み取り中 | アプリケーションログとバッファ状態を比較 |
| 復旧 | ウィンドウが実際に再開放 | プローブ、更新、再開したデータ送信を突き合わせる |
機器はオンラインでリンクランプも点灯しているのに、送信アプリケーションが一時停止しているように見えることがあります。キャプチャではゼロウィンドウが報告されるかもしれません。これは必ずしも、ケーブルの断線やスイッチの帯域幅がゼロであることを意味しません。TCPの受信側が、一時的に受信領域に空きがないことを相手側に伝えている可能性があります。その理由を理解するには、ネットワークへの到着からシステムのバッファリング、アプリケーションによる読み取りまでの経路を追います。
ネットワークポートへの到着は、経路の終点ではない
産業用ゲートウェイ、シリアルデバイスサーバー、監視用コンピューターは、TCPを使ってデータを交換することがあります。TCPは順序が保証されたバイトストリームを提供し、それらのバイトを温度記録、状態メッセージ、コマンドのどれとして扱うかはアプリケーションが決めます。Ethernetによるフレームの配送で完了するのは、経路の一部にすぎません。
システムはTCPデータを受信すると、プロトコルに従って検査し、受け入れ可能なデータをその接続の受信バッファに格納して、アプリケーションが読み取るのを待ちます。郵便物の受付を考えてみてください。受付カウンターへの配達は、受取人が荷物を開封して処理したことを意味しません。この例えは保管と消費を区別するためのものです。実際のシステムでは、シーケンス番号、ウィンドウ情報、メモリ状態が管理されています。
アプリケーションがディスクへの書き込みを待っていたり、前のメッセージを処理していたり、読み取りスレッドを実行するようスケジューリングしていなかったりすると、データが蓄積することがあります。正常なネットワークカードやスイッチでも、アプリケーションに代わってそのバイト列を読み取ることはできません。ポートのトラフィックだけを見ていると、経路の末端で行われるソフトウェア処理を見落とすおそれがあります。
受信ウィンドウは何の容量を通知するのか？
TCPヘッダーには、受信側が現在受け入れる意思のあるデータ範囲を通知するウィンドウフィールドがあります。この値はバッファリングとシステムのポリシーに依存します。機器の未使用の物理メモリ量と一致するとは限らず、スイッチの出力キューの空き領域でもありません。ゼロウィンドウは、その方向では現在、新たなデータを受け入れる受信ウィンドウに空きがないことを意味します。
ゲートウェイが監視用コンピューターに収集記録を継続的に送信しているとします。そのアプリケーションの読み取りが遅くなると、システムは通知するウィンドウを縮小し、最終的にゼロを通知することがあります。送信側は、新しいデータを無制限に送り続けるのではなく、その制限に従う必要があります。接続の逆方向には独立した状態があります。一方のゼロウィンドウだけでは、双方向のすべてのやり取りが停止したとは判断できません。
キャプチャツールには、生のウィンドウ値が表示される場合と、ウィンドウスケールオプションを考慮した計算値が表示される場合があります。ウィンドウスケーリングは接続確立時にネゴシエーションされ、より大きな受信ウィンドウを使用できるようにします。ゼロ以外の値を解釈する前に、ハンドシェイクと表示方法を確認してください。ゼロをスケーリングしてもゼロのままであり、一時停止の理解に数式の演習は必要ありません。
確認応答とウィンドウサイズを区別するのはなぜ？
TCPの確認応答番号は、受信側が次に期待するバイトのシーケンス番号を表し、送信側が連続して確認応答されたデータを追跡できるようにします。ウィンドウは、受信側が次に受け入れる意思のある範囲を表します。一方は先行するデータをどこまで受信したかを示し、もう一方は今後の受信に関するものです。両者は一緒に現れますが、目的は異なります。
受信側システムは、ゼロを通知しながら、受け入れたデータに確認応答を返すことができます。そのバイト列は、アプリケーションにまだ読み取られず、バッファ内にあるかもしれません。また、TCPの確認応答は、業務処理の成功を示すものでもありません。データベースのレコードがコミットされたか、コマンドが受理されたかを確認するには、アプリケーションレベルの応答が必要です。
同様に、確認応答番号が変わらないからといって、直ちにパケット損失が証明されるわけではありません。方向、ウィンドウの変化、送信内容、タイミングを併せて調べてください。1つの事象の中で再送、重複確認応答、ゼロウィンドウが発生することはありますが、キャプチャツールの色付きラベルは、それぞれ独立した診断結果ではありません。
ゼロウィンドウの後にプローブするのはなぜ？
受信側アプリケーションが再び読み取ると、システムは利用可能なウィンドウを通知することがあります。その更新通知は、転送中に失われる可能性があります。受信側が更新をすでに送ったと考えている一方で、送信側が何も送らず永久に待ち続けると、双方が相手を待つ状態になり得ます。TCPは、相手側の現在のウィンドウ状態を再び取得するために、ゼロウィンドウプローブを規定しています。
送信側は、プロトコルの要件と実装に従ってプローブを送るタイミングを決め、受信側は現在の状態を示す確認応答を返します。プローブはアプリケーションのデータ転送再開を意味せず、アプリケーションが読み取りを始めたことも証明しません。通知されるウィンドウがゼロの間は、通常の新規データ送信は引き続き制限されます。プローブ間隔とリソース管理は実装に依存するため、1回のキャプチャから製品に共通するタイミングパラメーターを確定することはできません。
プローブによって、まったく読み取りを行わないアプリケーションの停止状態を自動的に解消することはできません。TCPは接続の維持とプローブの動作を規定していますが、OSのポリシー、アプリケーションのタイムアウト、機器のリソース制限も結果に影響します。ゼロウィンドウの接続は決して切断されない、あるいは一定時間後に必ず復旧すると約束してはいけません。
Ethernet PAUSEフレームとはどう違うのか？
TCPの受信ウィンドウは、接続のエンドポイント間で行われるトランスポート層のフィードバックです。Ethernet PAUSEフレームは、隣接リンク上での送信の一時停止を要求します。スイッチキューの輻輳と、ホストアプリケーションの読み取りの遅さは、どちらもトラフィックを遅くすることがありますが、発生箇所、フィードバックの宛先、観測できるフィールドが異なります。
帯域幅がより大きいスイッチでも、ソケットを読み取らないアプリケーションの復旧は保証できません。逆に、ホストの受信ウィンドウが正常でも、中間経路に輻輳がないことの証明にはなりません。インターフェースのエラーや廃棄、経路の負荷は、ホストのバッファ、プロセス負荷、アプリケーションログとは分けて調査してください。
シリアルデバイスサーバーでは、シリアル側の速度、TCP接続、内部バッファリングを区別してください。ネットワーク側の制限中もシリアルデータが到着し続けるか、バッファが満杯になるとどうなるかは、実際のモデル、ファームウェア、フロー制御の設定に依存します。TCPに対応しているだけでは、無制限のシリアル入力を損失なく処理できるとはいえません。
事象を説明できる証拠を収集する
まず、ゼロを通知している接続と方向を特定し、エンドポイントのアドレス、ポート、機器とアプリケーションのバージョンを記録します。ハンドシェイクと事象の前後のトラフィックを調べます。受信ウィンドウ、確認応答番号、プローブ、ウィンドウの再開放を、同じ時系列上で比較してください。Zero Windowラベルのスクリーンショットだけでなく、キャプチャそのものを保存します。
その時系列を受信側のアプリケーションログと突き合わせます。アプリケーションは読み取っていたでしょうか。ディスク、データベース処理、別のスレッドを待っていたでしょうか。システムリソースに異常はなかったでしょうか。送信側がデータを生成し続けている場合は、そのキューと業務処理のタイムアウトも調べます。滞留を送信側に移しても、根本的な処理の問題は解決しません。
許可された環境で、管理された少量のデータによるテストを行い、継続的な読み取りと一時的に読み取りを遅らせた場合を比較すれば、通知されるウィンドウがそれに応じて変化するかを確認できます。診断ラベルを消すために、重要な本番プロセスを停止したり、むやみにバッファを拡大したり、タイムアウトを無効にしたりしないでください。バッファリングは滞留が表面化する時点を遅らせることはできますが、持続的な処理能力の不足には引き続き対処が必要です。
各問題を適切な段階に位置付ける
ゼロウィンドウが最も直接的に示すのは、受信側が通知する受信上限です。調査の手掛かりにはなりますが、アプリケーションが遅くなった理由を証明するものではありません。ネットワークポートへの到着、TCPのバッファリング、アプリケーションによる読み取り、業務処理という4つの段階をつなげて考えてください。この区別は、ネットワーク経路、システムリソース、アプリケーションロジックのどこを調べるべきかの判断に役立ちます。
FCTELEが公開しているマネージド産業用スイッチの情報は、産業用Ethernetのアクセスと転送を対象としています。実際のインターフェース、管理機能、対応能力については、該当する製品資料を確認してください。本ガイドは、一般的なTCPの動作を特定モデルの内部設計として示すものではなく、バッファ容量や復旧時間を創作するものでもありません。機器の選定や是正作業には、エンドポイントのプロトコル詳細、製品資料、現場での検証が必要です。
参考資料
RFC 9293：ゼロウィンドウプローブ;Microsoft：TCPのウィンドウとスケーリング;LinuxのTCPインターフェースとバッファリング;FCTELEのマネージド産業用スイッチ情報。一般的な模式図であり、製品の測定結果ではありません。
以下の中国語技術記事から翻訳： 中国語の原文記事を読む.
よくある質問
ゼロウィンドウはケーブルの断線を意味しますか？
いいえ。これはTCPのエンドポイントが通知する受信上限です。経路だけでなく、アプリケーションによる読み取りとシステム状態も調べてください。
TCPの確認応答は業務処理の完了を証明しますか？
いいえ。システムが受け入れたバイト列を、アプリケーションがまだ消費も処理もしていない可能性があります。
プローブで、処理が停止したアプリケーションを修復できますか？
いいえ。プローブは現在のウィンドウ情報を取得します。読み取り処理が停止したままの場合は、その処理自体を調査する必要があります。
適用範囲と参考資料
一般的なTCPの概念であり、特定製品の回路や測定されたタイミングを示すものではありません。
