各個HTTP GET文件請求之間的瀏覽器延遲

Question

我在調試運行在Microchip嵌入式平臺上的Web服務器。除了固件源允許我完全控制編碼所有TCP/IP通信之外，嵌入式部分不應相關。

特別是在Internet Explorer中，呈現服務器內容之前所需的所有GET請求之間的延遲時間均爲3到10秒。當它第一次訪問網站並且沒有任何內容被緩存時，通常有大約5個文件需要檢索（htm，css，js），所以在用戶看到頁面前15秒以上。

Wireshark捕獲表明，它肯定是引入延遲的客戶端，因爲Web服務器在收到每個連接請求後立即響應。連接完成後雙方都發送了FIN/ACK，這是我看到客戶端發送下一個SYN連接下一個GET之前的最少3秒暫停時間。從SYN到FIN/ACK的完整連接沒有問題，需要半秒鐘。

我驗證了每一方都確認對方的FIN標誌，因爲其最終ACK分組的確認號相應增加。我甚至擴大了捕獲範圍，以顯示涉及客戶端MAC地址的所有流量，並且在延遲期間沒有任何類型的流量。

任何人有一個想法發生了什麼？ HTTP頭文件等任何服務器端會導致這種情況嗎？謝謝你的幫助。

Answer 1

我確定問題在於Web服務器只運行一個偵聽TCP套接字。

Internet Explorer等客戶端顯然希望能夠使多個併發請求並行檢索文件，這很可能使用獨立線程。當一個線程佔用一個監聽套接字時，第二個嘗試獲取第二個文件的線程必須等到第一個線程釋放套接字爲止。當第二個線程的第一次連接嘗試失敗時，似乎必須在3秒後超時才能再次嘗試。

由於算法超時，在返回到監聽狀態之前，套接字僅佔用半秒無關緊要。第二個線程在超時之前不會再嘗試，因此文件請求之間的延遲。

客戶端沒有把第二個文件請求轉交給第一個線程的複雜性，第一個線程處於最好的位置，意識到套接字可以再次使用。這樣的功能可以優化諸如我的情況下的吞吐量。