この Wireshark の問題は数時間私を悩ませています。一体何が起こっているのでしょうか?
192.168.2.100 は静的ファイルを提供している Apache サーバーです。
192.168.2.196 はファイルをダウンロードする組み込みクライアントです。
192.168.2.196 は正常にファイルをダウンロードしているように見えますが、その後 192.168.2.100 を無視し始め、そのため接続が停止し、最終的に終了するのでしょうか?
これは正しいでしょうか、そしてなぜクライアントはこれを行っているのでしょうか?
答え1
この症状は、クライアント側の受信処理のボトルネックがあることを明確に示しています。
トレースは、クライアント ネットワーク スタック (明らかに LwIP) の受信バッファがいっぱいになっていることを示しています。具体的には、一連のパケットがサーバーから受信されるにつれて、クライアントからの確認応答のウィンドウ サイズが縮小し、受信バッファが完全にいっぱいになり、データの送信を停止するように要求する「ZeroWindow」がクライアントからサーバーに送信されます。
これは通常、ソケットから読み取るアプリケーションが、ネットワーク スタックが到着するパケットに対応できるほどの速度で受信バッファーを排出していないことを示します。
サーバーからの頻繁な再送信とクライアントからの遅延した ACK の組み合わせは、クライアントの状態がネットワーク スタック内の下位レベルの受信パケット処理にも悪影響を及ぼしていることを示唆しています。
クライアント ホストが組み込みデバイスであると述べ、アプリが lwip_read() でブロックされているように見えるともコメントしています。待機は、別の IO または CPU リソース、またはスケジュールのボトルネックによって、読み取りスレッドがファイル転送に追いつくのに十分な CPU 時間を確保できない可能性があることを示唆しています。ただし、遅延した ACK は、より広範な問題がある可能性を示唆しています。組み込みデバイスについての詳細がわからないと、さらにトラブルシューティングを行うことは困難です。
LwIPには、ネットワーク呼び出しのサービスに関する特別な制約があり、実装に適用される可能性があります。このLwIPの落とし穴のページ。
この情報が問題解決に役立つことを願っています。