0

HTTP/1.1 (永続的な接続) で、クライアントに次の HTTP リクエストを送信するように促す「シグナル」は何ですか? Content-Length 以外に何かありますか?

ファイル間で TCP トラフィックをブリッジする単純なゲートウェイを構築しようとしています。私は2つのアプリを持っています:

  • 「サーバー」はソケットを開き、接続を待ちます。接続が確立されると、取得したすべてを出力ファイルに転送すると同時に、入力ファイルからすべてをソケットに転送します。
  • 「クライアント」は、上記の出力ファイルの内容を待ち、サーバーに接続してデータを送信し、受信したデータを上記の入力ファイルに書き戻します。

つまり、ソケットを介して取得したものはすべて、ファイルを介して別のソケットにリダイレクトされ、その逆も同様です。

私の知る限り、これは完全に透過的であるはずですが、永続的な接続は期待どおりに機能しません。

私は Firefox でテストしています - 何が起こるかというと、FF は 2 つの GET を送信し、2 つの応答を受け取ります。しかし、それはただそこに座って、まだすべてのデータを受信して​​いないかのように待機します... 5 秒後 (サーバーは "Keep-Alive: timeout=5" で応答するため、これに適合します)、一方の側が接続を閉じて、それを再確立し、再びスタックしたときにいくつかのファイルの送信を続けます。

WireShark で聞いてみましたが、異常は見つかりませんでした。何が起こっているのですか？

更新: 以下は WireShark ログのスクリーンショットです。TCP 接続が閉じられた後、HTTP 接続が送信されるのが遅すぎることを示しています (時間に注意してください)。私のログから判断すると、すぐに送信されました。この不一致の理由は何か分かりますか? どういうわけかソケットを「フラッシュ」する必要がありますか? 私はPythonを使用しています。

WireShark ログ

4

2 に答える 2

1

データの長さ/終わりをクライアントに「通知」するのは、Content-Length または Chunked-Encoding (または接続が閉じられている場合) のいずれかです。

HTTP データが受信された後、ブラウザーはしばらくの間 tcp/ip 接続を開いたままにして、同じ tcp/ip 接続を介して同じサーバーへのさらなる要求を許可します。

于 2011-08-09T11:16:04.320 に答える
1

「信号」はありません。クライアントは、準備ができたときに次の要求を送信します。

しかし、その後はただそこに座って、まだすべてのデータを受信して​​いないかのように待機します。

そのため、まだすべてのデータを受信して​​いない可能性があります。入ってきたら正確に書いていますか？バッファをフラッシュしますか？

于 2011-08-09T11:44:42.020 に答える