私はサーバー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
分析は、呼び出しが開始された直後にいくつかの再送信を示しています。
通常、そのような動作の原因は何ですか?(「通常の」原因がある場合)。
注1:必要に応じて、APIを変更して、Webサーバーパーツのデータをより多く記録するようにしますが、ハングの再現できない性質のため、それはその障害(他の部分(スレッド)が正常に機能し、スレッドのクラッシュはありません)。
注2:サーバーを再起動すると(おそらくスクリプト自体も再起動します(これは、マシンを再起動するためです))、問題が解決します。
PSH、ACKフラグを使用した一連の再送信の意味(および誤った再送信の戻り)は何ですか?
通常、そのような行動の原因は何ですか? (「通常の」原因がある場合)。
(また参照ServerFault-接続中のPHA ACK)
ACKは、ACKを使用してパケットを送信するマシンが、他のマシンから受信したデータを確認していることを意味します。 TCPでは、接続が確立されると、どちらかの側から送信されたすべてのパケットに、すでに確認済みのデータを単に再確認している場合でも、ACKが含まれます。
PSHは、受信側のマシンのTCP実装が、受信したデータを、データを読み取るコード(プログラム、またはプログラムで使用されるライブラリ)にまだ提供していない場合) TCPの公式仕様であるRFC 793を引用すると、次のようになります。
接続上を流れるデータは、オクテットのストリームと考えることができます。送信ユーザーは、各SEND呼び出しで、その呼び出し(および前の呼び出し)のデータを、Pushフラグの設定により、すぐに受信ユーザーにプッシュする必要があるかどうかを示します。
送信TCPは、送信側ユーザーからデータを収集し、そのデータを自分の都合の良いときにセグメントに送信することが許可されています。Push関数が通知されるまで、送信されていないすべてのデータを送信する必要があります。受信TCPはプッシュフラグを確認します。送信側からのデータを待ってはなりませんTCP受信側のプロセスにデータを渡す前に。
誤った再送信が見られる場合は、受信者が確認パケットを送信したにもかかわらず、送信者はパケットが失われたと考えて再送信したことを意味します。