0

Microchip 組み込みプラットフォームで動作する Web サーバーをデバッグしています。組み込み部分は関係ありませんが、ファームウェア ソースにより、すべての TCP/IP 通信のコーディングを完全に制御できます。

特に Internet Explorer では、サーバーのコンテンツをレンダリングする前に必要なすべての GET 要求の間に 3 ～ 10 秒の遅延があります。サイトに初めてアクセスし、何もキャッシュされていない場合、通常、取得するファイル (htm、css、js) は約 5 つあるため、ユーザーがページを表示するまでに 15 秒以上かかります。

Wireshark のキャプチャは、Web サーバーが各接続要求を受信するとすぐに応答するため、遅延を引き起こしているのは間違いなくクライアントであることを示しています。接続が完了し、両側が FIN/ACK を送信した後、クライアントが次の SYN を送信して次の GET に接続する前に、少なくとも 3 秒の一時停止が見られます。SYN から FIN/ACK への完全な接続には問題がなく、0.5 秒もかかりません。

最終 ACK パケットの ack 番号がそれに応じて増加するため、各側が相手側の FIN フラグに ACK を送信していることを確認しました。クライアントの MAC アドレスに関連するすべてのトラフィックを表示するようにキャプチャを拡張しましたが、遅延中には何もありません。

何が起こっているのか誰にも分かりますか？HTTPヘッダーなどのサーバー側でこれが発生しますか? 助けてくれてありがとう。

4

1 に答える 1

1

問題は、Web サーバーがリッスンしている TCP ソケットを 1 つしか実行していないことにあると判断しました。

Internet Explorer などのクライアントは、おそらく独立したスレッドを使用して、ファイルを並行して取得するために複数の同時要求を作成できることを明確に期待しています。1 つのスレッドが 1 つのリッスン ソケットを占有している場合、2 番目のスレッドが 2 番目のファイルを取得しようとすると、最初のスレッドがソケットを解放するまで待機する必要があります。2 番目のスレッドの最初の接続試行が失敗した場合、再試行する前に 3 秒後にタイムアウトする必要があるようです。

アルゴリズムはタイムアウトするため、リッスン状態に戻る前にソケットが 0.5 秒だけ占有されていても問題ありません。2 番目のスレッドはタイムアウトになるまで再試行しないため、ファイル要求間の遅延が生じます。

クライアントには、2 番目のファイル要求を最初のスレッドに渡す洗練された機能がありません。最初のスレッドは、ソケットが再び使用可能になったことを認識するのに最適な位置にあります。このような機能は、私のような場合にスループットを最適化できます。

于 2013-02-24T16:33:42.100 に答える