簡單的 HTTP 調用，為什么時延這么大？

1. 背景

最近項目測試遇到個奇怪的現象，在測試環(huán)境通過 Apache HttpClient 調用后端的 HTTP 服務，平均耗時居然接近 39.2ms?？赡苣阏б豢从X得這不是很正常嗎，有什么好奇怪的?其實不然，我再來說下一些基本信息，該后端的 HTTP 服務并沒有什么業(yè)務邏輯，只是將一段字符串轉成大寫然后返回，字符串長度也僅只有 100 字符，另外網絡 ping 延時只有 1.9ms左右。因此，理論上該調用耗時應該在 2-3ms 左右，但為什么平均耗時 39.2ms 呢?

由于工作原因，調用耗時的問題，對我來說，已經見怪不怪了，經常會幫業(yè)務解決內部 RPC 框架調用超時的相關問題，但是 HTTP 調用耗時***次遇到。不過，排查問題的套路是一樣的。主要方法論無外乎由外而內、至上而下等排查方法。我們先來看看外圍的一些指標，看能否發(fā)現蛛絲馬跡。

2. 外圍指標

2.1 系統(tǒng)指標

主要看外圍的一些系統(tǒng)指標(注意：調用與被調用的機器都要看)。例如負載、CPU。只需一個 top 命令就能一覽無余。

因此，確認了下 CPU 和負載都很空閑。由于當時沒有截圖，這里就不放圖了。

2.2 進程指標

Java 程序進程指標主要看 GC、線程堆棧情況(注意：調用與被調用的機器都要看)。

Young GC 都非常少，而且耗時也在 10ms 以內，因此沒有長時間的 STW。

因為平均調用時間 39.2ms，比較大，如果耗時是代碼導致，線程堆棧應該能發(fā)現點啥?？戳酥笠粺o所獲，服務的相關線程堆棧主要表現是線程池的線程在等任務，這就意味著線程并不忙。

是不是感覺黔驢技窮了，接下來該怎么辦呢?

3. 本地復現

如果本地(本地是 MAC 系統(tǒng))能復現，對排查問題也是極好的。

因此在本地使用 Apache HttpClient 寫了個簡單 Test 程序，直接調用后端的 HTTP 服務，發(fā)現平均耗時在 55ms 左右。咦，怎么跟測試環(huán)境 39.2ms 的結果有點區(qū)別。主要是本地與測試環(huán)境的后端的 HTTP 服務機器跨地區(qū)了，ping 時延在 26ms 左右，所以延時增大了。不過本地確實也是存在問題的，因為ping 時延是 26ms，后端 HTTP 服務邏輯簡單，幾乎不耗時，因此本地調用平均耗時應該在 26ms 左右，為什么是 55ms?

是不是越來越迷惑，一頭霧水，不知如何下手?

期間懷疑過 Apache HttpClient 是不是有什么地方使用的不對，因此使用 JDK 自帶的 HttpURLConnection 寫了簡單的程序，做了測試，結果一樣。

4. 診斷

4.1 定位

其實從外圍的系統(tǒng)指標、進程指標，以及本地復現來看，大致能夠斷定不是程序上的原因。那 TCP 協(xié)議層面呢?

有網絡編程經驗的同學一定知道 TCP 什么參數會引起這個現象。對，你猜的沒錯，就是 TCP_NODELAY。

那調用方和被調用方哪邊的程序沒有設置呢?

調用方使用的是 Apache HttpClient ，tcpNoDelay 默認設置的就是 true。我們再來看看被調用方，也就是我們的后端 HTTP 服務，這個 HTTP 服務用的是 JDK自帶的 HttpServer

HttpServer server = HttpServer.create(new InetSocketAddress(config.getPort()), BACKLOGS); 

居然沒看到直接設置 tcpNoDelay 接口，翻了下源碼。哦，原來在這里，在 ServerConfig 的類中有這段靜態(tài)塊，用來獲取啟動參數，默認 ServerConfig.noDelay 為 false。

static { 
 
AccessController.doPrivileged(new PrivilegedAction() { 
 
public Void run() { 
 
ServerConfig.idleInterval = Long.getLong("sun.net.httpserver.idleInterval", 30L) * 1000L; 
 
ServerConfig.clockTick = Integer.getInteger("sun.net.httpserver.clockTick", 10000); 
 
ServerConfig.maxIdleConnections = Integer.getInteger("sun.net.httpserver.maxIdleConnections", 200); 
 
ServerConfig.drainAmount = Long.getLong("sun.net.httpserver.drainAmount", 65536L); 
 
ServerConfig.maxReqHeaders = Integer.getInteger("sun.net.httpserver.maxReqHeaders", 200); 
 
ServerConfig.maxReqTime = Long.getLong("sun.net.httpserver.maxReqTime", -1L); 
 
ServerConfig.maxRspTime = Long.getLong("sun.net.httpserver.maxRspTime", -1L); 
 
ServerConfig.timerMillis = Long.getLong("sun.net.httpserver.timerMillis", 1000L); 
 
ServerConfig.debug = Boolean.getBoolean("sun.net.httpserver.debug"); 
 
ServerConfig.noDelay = Boolean.getBoolean("sun.net.httpserver.nodelay"); 
 
return null; 
 
} 
 
}); 
 
} 

4.2 驗證

在后端 HTTP 服務，加上啟動"-Dsun.net.httpserver.nodelay=true"參數，再試試。效果很明顯，平均耗時從39.2ms 降到 2.8ms。

問題是解決了，但是到這里如果你就此止步，那就太便宜了這個案例了，簡直暴殄天物。因為還有一堆疑惑等著你呢?

• 為什么加了 TCP_NODELAY ，時延就從 39.2ms 降低到 2.8ms?
• 為什么本地測試的平均時延是 55ms，而不是 ping 的時延 26ms?
• TCP 協(xié)議究竟是怎么發(fā)送數據包的?

來，我們接著乘熱打鐵。

5. 解惑

5.1 TCP_NODELAY 何許人也?

在 Socket 編程中，TCP_NODELAY 選項是用來控制是否開啟 Nagle 算法。在 Java 中，為 ture 表示關閉 Nagle 算法，為 false 表示打開 Nagle 算法。你一定會問 Nagle 算法是什么?

5.2 Nagle 算法是什么鬼?

Nagle 算法是一種通過減少通過網絡發(fā)送的數據包數量來提高 TCP/IP 網絡效率的方法。它使用發(fā)明人 John Nagle 的名字來命名的，John Nagle 在 1984 年***用這個算法來嘗試解決福特汽車公司的網絡擁塞問題。

試想如果應用程序每次產生 1 個字節(jié)的數據，然后這 1 個字節(jié)數據又以網絡數據包的形式發(fā)送到遠端服務器，那么就很容易導致網絡由于太多的數據包而過載。在這種典型情況下，傳送一個只擁有1個字節(jié)有效數據的數據包，卻要花費 40 個字節(jié)長包頭(即 IP 頭部 20 字節(jié) + TCP 頭部 20 字節(jié))的額外開銷，這種有效載荷(payload)的利用率是極其低下。

Nagle 算法的內容比較簡單，以下是偽代碼：

if there is new data to send 
 
if the window size >= MSS and available data is >= MSS 
 
send complete MSS segment now 
 
else 
 
if there is unconfirmed data still in the pipe 
 
enqueue data in the buffer until an acknowledge is received 
 
else 
 
send data immediately 
 
end if 
 
end if 
 
end if 

具體的做法就是：

• 如果發(fā)送內容大于等于 1 個 MSS， 立即發(fā)送;
• 如果之前沒有包未被 ACK， 立即發(fā)送;
• 如果之前有包未被 ACK， 緩存發(fā)送內容;
• 如果收到 ACK， 立即發(fā)送緩存的內容。(MSS 為 TCP 數據包每次能夠傳輸的***數據分段)

5.3 Delayed ACK 又是什么玩意?

大家都知道 TCP 協(xié)議為了保證傳輸的可靠性，規(guī)定在接受到數據包時需要向對方發(fā)送一個確認。只是單純的發(fā)送一個確認，代價會比較高(IP 頭部 20 字節(jié) + TCP 頭部 20 字節(jié))。TCP Delayed ACK(延遲確認)就是為了努力改善網絡性能，來解決這個問題的，它將幾個 ACK 響應組合合在一起成為單個響應，或者將 ACK 響應與響應數據一起發(fā)送給對方，從而減少協(xié)議開銷。

具體的做法是：

• 當有響應數據要發(fā)送時，ACK 會隨響應數據立即發(fā)送給對方;
• 如果沒有響應數據，ACK 將會延遲發(fā)送，以等待看是否有響應數據可以一起發(fā)送。在 Linux 系統(tǒng)中，默認這個延遲時間是 40ms;
• 如果在等待發(fā)送 ACK 期間，對方的第二個數據包又到達了，這時要立即發(fā)送 ACK。但是如果對方的三個數據包相繼到達，第三個數據段到達時是否立即發(fā)送 ACK，則取決于以上兩條。

5.4 Nagle 與 Delayed ACK 一起會發(fā)生什么化學反應?

Nagle 與 Delayed ACK 都能提高網絡傳輸的效率，但在一起會好心辦壞事。例如，以下這個場景：

A 和 B 進行數據傳輸 : A 運行 Nagle 算法，B 運行 Delayed ACK 算法。

如果 A 向 B 發(fā)一個數據包，B 由于 Delayed ACK 不會立即響應。而 A 使用 Nagle 算法，A 就會一直等 B 的 ACK，ACK 不來一直不發(fā)送第二個數據包，如果這兩個數據包是應對同一個請求，那這個請求就會被耽誤了 40ms。

5.5 抓個包玩玩吧

我們來抓個包驗證下吧，在后端HTTP服務上執(zhí)行以下腳本，就可以輕松完成抓***程。

sudo tcpdump -i eth0 tcp and host 10.48.159.165 -s 0 -w traffic.pcap 

如下圖，這是使用 Wireshark 分析包內容的展示，紅框內是一個完整的 POST 請求處理過程，看 130 序號和 149 序號之間相差 40ms(0.1859 - 0.1448 = 0.0411s = 41ms)，這個就是 Nagle 與 Delayed ACK 一起發(fā)送的化學反應，其中 10.48.159.165 運行的是 Delayed ACK，10.22.29.180 運行的是 Nagle 算法。10.22.29.180 在等 ACK，而 10.48.159.165 觸發(fā)了 Delayed ACK，這樣傻傻等了 40ms。

這也就解釋了為什么測試環(huán)境耗時是 39.2ms，因為大部分都被 Delayed ACK 的 40ms 給耽誤了。

但是本地復現時，為什么本地測試的平均時延是 55ms，而不是 ping 的時延 26ms?我們也來抓個包吧。

如下圖，紅框內是一個完整的 POST 請求處理過程，看 8 序號和 9 序號之間相差 25ms 左右，再減去網絡延時約是ping延時的一半 13ms，因此 Delayed Ack 約 12ms 左右(由于本地是 MAC 系統(tǒng)與 Linux 有些差異)。

1. Linux 使用的是 /proc/sys/net/ipv4/tcp_delack_min 這個系統(tǒng)配置來控制 Delayed ACK 的時間，Linux 默認是 40ms;

2. MAC 是通過 net.inet.tcp.delayed_ack 系統(tǒng)配置來控制 Delayed ACK 的。

delayed_ack=0 responds after every packet (OFF) delayed_ack=1 always employs delayed ack, 6 packets can get 1 ack delayed_ack=2 immediate ack after 2nd packet, 2 packets per ack (Compatibility Mode) delayed_ack=3 should auto detect when to employ delayed ack, 4packets per ack. (DEFAULT)設置為 0 表示禁止延遲 ACK，設置為 1 表示總是延遲 ACK，設置為 2 表示每兩個數據包回復一個 ACK，設置為 3 表示系統(tǒng)自動探測回復 ACK 的時機。

5.6 為什么 TCP_NODELAY 能夠解決問題?

TCPNODELAY 關閉了 Nagle 算法，即使上個數據包的 ACK 沒有到達，也會發(fā)送下個數據包，進而打破 Delayed ACK 造成的影響。一般在網絡編程中，強烈建議開啟 TCPNODELAY，來提升響應速度。

當然也可以通過 Delayed ACK 相關系統(tǒng)的配置來解決問題，但由于需要修改機器配置，很不方便，因此，這種方式不太推薦。

6. 總結

本文是從一個簡單的 HTTP 調用，時延比較大而引發(fā)的一次問題排查過程。過程中，首先由外而內的分析了相關問題，然后定位問題并驗證解決方案。***刨根問底對 TCP 傳輸的中的 Nagle 與 Delayed ACK 做了全面的講解，更加透測的剖析了該問題案例。

作者：滌生，姓名殷琦，目前就職于某大型互聯網公司基礎架構部，主要負責微服務框架、服務治理、Serverless 相關工作。 《高可用可伸縮微服務架構：基于Dubbo、Spring Cloud和Service Mesh》的作者之一。

網頁標題：簡單的 HTTP 調用，為什么時延這么大？
網站鏈接：http://bm7419.com/news/103240.html

成都網站建設公司_創(chuàng)新互聯，為您提供App開發(fā)、網站建設、電子商務、做網站、網站策劃、移動網站建設

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯