web-dev-qa-db-ja.com

PSH、ACKフラグを使用した一連の再送信の意味（および誤った再送信）

私はサーバー192.168.0.2にいて、192.168.0.1へのHTTP呼び出しを行いたいと思います（どちらのサーバーもRPisであり、Linux（raspbian）を実行しています）。

curl -XGET http://192.168.0.1:8081/api

192.168.0.1（私が呼んでいる）のAPIは私のものであり（a Pythonに基づいたスクリプトbottleに基づく）、ほとんどの場合機能します。不思議なことにハングします。その結果、上記のcurlコールがハングし、タイムアウトになります。

APIが応答しないときに192.168.0.1（受信サーバー、APIをホストするサーバー）でtcpdumpを実行しましたが、wireshark分析は、呼び出しが開始された直後にいくつかの再送信を示しています。

enter image description here

通常、そのような動作の原因は何ですか？（「通常の」原因がある場合）。

注1：必要に応じて、APIを変更して、Webサーバーパーツのデータをより多く記録するようにしますが、ハングの再現できない性質のため、それはその障害（他の部分（スレッド）が正常に機能し、スレッドのクラッシュはありません）。

注2：サーバーを再起動すると（おそらくスクリプト自体も再起動します（これは、マシンを再起動するためです））、問題が解決します。

linuxnetworkingwiresharktcpdump
5
WoJ

PSH、ACKフラグを使用した一連の再送信の意味（および誤った再送信の戻り）は何ですか？

通常、そのような行動の原因は何ですか？ （「通常の」原因がある場合）。

PSH ACK Wiresharkトレース

（また参照ServerFault-接続中のPHA ACK）

ACKは、ACKを使用してパケットを送信するマシンが、他のマシンから受信したデータを確認していることを意味します。 TCPでは、接続が確立されると、どちらかの側から送信されたすべてのパケットに、すでに確認済みのデータを単に再確認している場合でも、ACKが含まれます。

PSHは、受信側のマシンのTCP実装が、受信したデータを、データを読み取るコード（プログラム、またはプログラムで使用されるライブラリ）にまだ提供していない場合） TCPの公式仕様であるRFC 793を引用すると、次のようになります。

接続上を流れるデータは、オクテットのストリームと考えることができます。送信ユーザーは、各SEND呼び出しで、その呼び出し（および前の呼び出し）のデータを、Pushフラグの設定により、すぐに受信ユーザーにプッシュする必要があるかどうかを示します。

送信TCPは、送信側ユーザーからデータを収集し、そのデータを自分の都合の良いときにセグメントに送信することが許可されています。Push関数が通知されるまで、送信されていないすべてのデータを送信する必要があります。受信TCPはプッシュフラグを確認します。送信側からのデータを待ってはなりませんTCP受信側のプロセスにデータを渡す前に。

偽の再送信

誤った再送信が見られる場合は、受信者が確認パケットを送信したにもかかわらず、送信者はパケットが失われたと考えて再送信したことを意味します。

考えられる原因

  • サーバーマシンとクライアントマシンの間の設定ミス
  • TCPパケットのホップパスに沿った任意の送信者と受信者の間の設定ミス
  • パケットをブロックするファイアウォールルールまたはパケットフィルター

追加のトラブルシューティング

  • これが発生した場合もサーバーログを確認してください
  • サーバーでWiresharkを使用してTCPトレースを実行し、問題が発生したときにこれらのパケットがどのように見えるかを確認します
6
Pimp Juice IT