為什么得到Http請求和響應太晚了

Question

我正在使用http post方法向Http Server URL發送請求。

請求和響應之間的時間差大約為60秒，但根據服務器團隊，一旦請求到達，他們將發送響應7秒。

我不認為網絡在服務器端需要剩余53秒的時間才能到達數據包，因此可能出現問題。

在此應用程序中，我們在客戶端和服務器之間使用同步通信。 請提供以下詳細信息。

1. 是因為服務器以比服務器能夠處理的更快的速度發送請求。 在這種情況下，很多時候客戶端以3秒的間隔獲取請求，而服務器需要7秒來處理此問題。
2. 什么是網絡緩沖區。 網絡級別有兩個緩沖區，一個位於客戶端，另一個位於服務器位置。
3. 如果服務器無法以相同的速度處理客戶端發送的請求，則所有請求都會在客戶端緩沖區緩沖，如果有更多的請求待處理，則會發生什么情況，而不是該緩沖區的最大大小。
4. 如果我們處於客戶端並且無法控制服務器，那么提高性能的替代方法是什么？

編輯：當我在網絡中使用wireshark來捕獲網絡日志時，我發現它實際上是我的應用程序發送到服務器后20秒內在wireshark中進行了學習。 這種延遲背后的原因是什么？ 什么原因可能是請求在網絡中出現20秒實際發送延遲的可能原因。

Answer 1

關於您的編輯，以幫助您理解。 網絡遵循稱為開源互通（OSI）的模型。 該模型分為七個不同的層，所有層都具有一個功能。

這些圖層在這里：

Wireshark檢測位於第3層的數據包 。這是由路由器處理的。 網絡接口卡（NIC）獲取分配的數據並將其轉換為數據包以通過線路發送。

Wireshark的將不會檢測數據包，直到你的網卡已經轉換成在路由器處理數據包 。

您看到一旦將其轉換為數據包，它包含以下信息：

• 4個包含版本的位（IPV4或IPV6）
• 4包含Internet標頭的位。
• 8包含服務類型或服務質量和優先級的位。
• 16個包含字節數據包長度的位。
• 16包含標識標記的位，以幫助從Fragments重建數據包 。
• 3位，第一個是零，后跟一個標志，表示允許Fragment或Not。 和數量。
• 13包含片段偏移的位，用於標識原始位置的字段。
• 8個包含生存時間（TTL）和跨路由器跳數的位 。
• 8個包含協議的位（TCP，UDP，ICMP等）
• 16個包含Header Checksum的位
• 32個包含源IP地址的位
• 32包含目標IP地址的位

這些是創建此類數據包時創建的關鍵160位。

這是什么意思？

嗯，你知道Wireshark需要20秒才能檢測到你的數據包。 因此，我們知道你的應用程序需要20秒才能真正構建這個數據包。

我們知道服務器還需要重建此數據包，以便它可以處理數據並可能發送請求。

我們還知道路由器就像一個交通警察，通過互聯網或本地網絡發送您的數據。

嗯，這增加了相當多的推論？ 但是我要去哪里？

你有一個名為： tracert的實用程序

平均而言，需要一到兩毫秒的路由請求才能通過五到六英尺的電纜，所以如果它產生一到兩毫秒的初始跳，但是第二跳在二十三毫秒內被觸發，那么你可以使用一個簡單的公式：

6 * 20

根據我們tracert的當前速度，我們可以估計持續時間。 這是一種非常通用的方法，但存在精確准確的工具。 但跳越多，到達目的地所需的時間就越多。 你也會越多。

從客戶端到服務器之間怎么樣？

• 局域網（LAN）：網絡的內部效率是由於每個網絡協議，設備和物理中位數的優化。 網絡管理員必須快速測量可靠性; 以及網絡生成的所有流量。 因此，設備吞吐量和物理中值很重要。 您不希望將十輛車合並到單車道隧道中，這可能會產生同樣適用於網絡的瓶頸。

• 廣域網（WAN）：這實際上是與Internet的連接，即雲。 可以這樣想：您的計算機在局域網上，路由器到WAN。 然后你的ISP可能有一個局域網，然后它的WAN開放到更大的分發設施。 它一直在工作，直到它到達互聯網。

雖然怎么辦？

你知道現在之間有什么，但我能做些什么？

那么，當您生成服務時，您顯然希望確保您的代碼精簡且高效。 因為效率在速度上至關重要。 因此，改變緩沖區大小，傳輸速率等可以大大改善您的應用。

顯然，好的代碼實踐會有所幫助。

我的代碼雖然堅如磐石？

如果您認為您的代碼不是此時的問題，或者您托管和創建服務的方法，那么這些因素可能是原因：

• 本地機器可能會產生過多的喋喋不休，因此需要更長的時間。
• 本地網絡產生過多的喋喋不休或低效/低吞吐量。
• 您的要求是長途旅行，所以時間推遲。
• 您的Internet服務提供商可能具有掃描這些數據包的硬件防火牆，代理等。
• 您的服務器可能有過多的請求或Host方法效率不高。

這些是變量的一大塊。 您可以嘗試的只是重構服務並確保您的服務器以最有效的方式托管它。 否則，您將希望獲得一個信息技術團隊，這是至關重要的。

但要記住這一點，您的體驗可能會比與此服務接口的其他客戶更好或更差。

我假設您部署在一個位置，並且您可能處於遠離服務器的幾個狀態。

工具：

命令行：

• 平
• TRACERT

網絡和協議分析儀：

• Fiddler（HTTP / HTTPS）：查看Fiddler是否顯示任何HTTP狀態代碼以進行故障排除。
• Wireshark：將分析您的網絡流量，這可以幫助持續時間。

還有其他實用程序可用於實際緩解和測試網絡速度，甚至是其他位置，只有谷歌“網絡工具”。 福祿克有一些。

希望這能解釋為什么Wireshark甚至可能需要20秒才能在網絡上顯示數據包。

希望有所幫助。

Answer 2

使用Wireshark在線路上間隔60秒捕獲您的請求和響應，並將其發送給服務器團隊。 他們可以通過捕獲來回應，顯示請求和響應接近7秒。 那很棒！ 將它們發送給網絡團隊。

另一方面，跟蹤可能表明延遲在您的代碼中。 您的結束可能存在某種限制或延遲，導致請求在很長一段時間內離開您的流程。 Wireshark跟蹤也可以告訴你。

Answer 3

TCP / IP流將控制您擔心的大部分內容。

“發送請求的速度比服務器無法處理”

不，你永遠不會比使用TCP會話時更快地向服務器發送任何內容。 傳輸流被引導並且不可能比服務器可以處理的更快地發送。

“什么是網絡緩沖區”

TCP / IP通信中包含兩個隊列緩沖區，一個發送緩沖區和一個接收緩沖區。

當你進行send()調用時，它實際上並沒有發送任何內容，它只會將數據排入發送緩沖區，並將返回給你，你嘗試發送的字節數實際上已經放入隊列中發送。 如果它返回的次數少於你試圖發送的次數，則意味着你必須等待才能發送其余部分，因為緩沖區已滿。

這就是你如何控制流量，你知道你是否想要發送太快的東西是你的提示。 只要有數據要發送，嘗試保持緩沖區已滿，但不要忽略這樣一個事實，即並非所有內容都適合緩沖區，您必須稍后重試。

recv()也有自己的緩沖區。 該命令實際上並不接收任何內容，數據已經被接收， recv()只會從接收緩沖區中讀取它。 使用阻塞套接字（默認）時，如果緩沖區為空，則recv()將掛起，等待新數據到達。 如果連接已終止或者您嘗試將其與非阻塞套接字一起使用，則recv()將僅返回0。

如果忘記recv()並且接收緩沖區已滿，那也沒關系。 對等體將無法繼續發送，因為send()將開始向它們返回0，但只要注意send()返回值，任何時候都不會丟失數據。

據我所知，默認情況下，所有系統的緩沖區大小均為64KB，用於發送或接收。 有一些命令可以調整這個緩沖區大小，但是它並不是很有趣。 如果您需要更大的緩沖區，請在您的應用程序中進行。

“如果我們處於客戶端並且無法控制服務器，那么提高性能的替代方法是什么？”

它不是一個有效的問題，你不能這樣做。 我認為您可能在HTTP請求中犯了一些錯誤，特別是考慮到您正在進行POST請求。

在執行POST請求時，您的HTTP標頭將包含兩個標頭，這些標頭通常只能在服務器HTTP響應標頭上看到：Content-Type和Content-Length。 它們在執行POST時非常重要，如果其中一個丟失或錯誤，HTTP會話可能會掛起幾秒鍾或者根本不會成功。

HTTP的另一個重要方面是HTTP 1.0和HTTP 1.1之間最重要的區別：HTTP 1.0不支持Keep-Alive 。 初學者更容易處理HTTP 1.0，因為使用HTTP 1.0，您連接，發送您的請求，服務器應答並終止連接，這意味着您已完成下載服務器響應。 使用HTTP 1.1，默認情況下不會發生。 連接保持打開狀態，直到超時。 您必須注意HTTP響應標頭Content-Length和count字節，以便知道服務器是否結束了發送您請求的內容。

同樣重要的是要注意並非所有服務器都支持HTTP 1.0。 您可以發出HTTP 1.0請求，但無論如何它都會響應，使用Keep-Alives和您不期望的所有內容。 在一個完美的世界，它不應該發生，但確實如此。

你的錯誤可能在這方面。 Sinse你說你的請求正好花了60秒，我懷疑是因為它超時了。 您可能已經收到了所有必需的內容，但是應用程序沒有正確處理，而是掛起，直到服務器終止連接。

Answer 4

在點號1：

在你的第1點，我相信你的意思是'1。 是由於客戶端發送....'和'在這種情況下，很多時候客戶端正在以間隔獲得響應....'。

在第3點：

• 服務器計算機通常是比客戶端計算機更強大的計算機，因此“如果服務器無法以與客戶端發送的速度相同的速度處理請求”，則情況非常少見。 如果我沒記錯的話，HTTP服務器會先“先到先服務”，而你正在調用的請求緩沖區將是服務器端而不是客戶端的隊列。 我從未聽說過“所有請求都在客戶端緩沖區緩沖”。

• 時間服務器響應速度通常很快但是返回給您的時間結果（客戶端）更多地與原始請求正在執行的操作有關，無論是僅檢索靜態html文件，還是檢索大圖像或文檔，或必須在數據庫服務器上執行繁重的查詢等。

• 您是唯一向服務器提交HTTP請求的客戶端嗎？ 可能不是。 該服務器機器是否僅包含HTTP服務器？ 請記住，服務器正在或將要處理來自多個客戶端的請求，這可能是有時延遲響應的另一個因素，即使服務器可以同時處理多個請求，也取決於其他請求正在執行的操作。 由於多個請求而無法響應的HTTP服務器的極端示例是服務器處於[分布式]拒絕服務攻擊之下。

• 您是否有任何防火牆保護HTTP服務器或保護HTTP服務器所在的網絡？ 擁有防火牆規則或網絡入侵檢測系統可能會延遲請求/響應時間。

• 以下可能是另一個因素：“請求在網絡中出現的可能原因是20秒實際發送延遲。” 它被稱為“網絡擁塞”，通常發生在路由器級別。

在第4點：

• 一旦您丟棄或消除與第3點相關的因素，您可以通過以下方式提高績效：

• 首先，所有其他不是延遲的主要因素，找出你期望的響應時間。

• 其次，確保您在合理的條件/環境下有一個合理的准確度量。 我認為HTTP服務器不應該受到責備。

• 第三，如果仍然遇到延遲，您（或其他人）將需要查看路由器的配置，防火牆配置以及您的html頁面代碼（如果有）或您的Web應用程序（如果有）。

編輯：

嘗試ping您的HTTP服務器以了解網絡往返時間。

這是一個例子; 我確實提交了這個命令：

ping www.yahoo.com

從客戶端PC上的MS-DOS窗口。

1）注意往返如何采用aprox 0.5秒或更短（0.5秒= 500毫秒）。 我在美國東海岸，雅虎很可能會以美國西部成本（我不確定）。

2）注意每次往返並不總是相同的長度，但變化很小。

3）從我的本地PC到像Yahoo.com這樣的世界級暴露服務器，中間有幾個請求，路由器和防火牆，響應時間甚至不到1秒。 這意味着如果網絡和服務器配置正確，很少會導致延遲，這意味着在將頁面或應用程序歸咎於HTTP服務器之前，應對其進行徹底檢查/檢查。

4）當我從瀏覽器提交請求http://www.yahoo.com時 ，加載頁面肯定花了0.5秒多一點，我認為因為頁面中的所有html元素和廣告，但HTTP服務器響應是可能0.5秒。

Answer 5

在第4點：對於大量數據，在線路上花費的時間量可能很大。 如果您的服務器支持它，您可能希望在發送之前壓縮內容。

Answer 6

嘗試檢查您的DNS配置，我認為這可能是一個問題。 在您的瀏覽器或腳本發出請求之前，需要將域名解析為IP地址。

您可以通過向位於Windows中的主機文件添加其他信息來輕松檢查：

C：\\ WINDOWS \\ SYSTEM32 \\ DRIVERS \\ ETC \\主機

或者在linux系統中：

\\等\\主機

要檢查有關域和IP地址的信息，請嘗試使用nslookup（Windows和Linux OS上的相同命令）