懵了！簡單的HTTP調用，時延竟如此大？
最近項目測試遇到個奇怪的現象，在測試環境通過 Apache HTTP Client 調用后端的 HTTP 服務，平均耗時居然接近 39.2ms。
圖片來自 Pexels
可能乍一看覺得這不是很正常嗎，有什么好奇怪的?其實不然，我再來說下一些基本信息。
該后端的 HTTP 服務并沒有什么業務邏輯，只是將一段字符串轉成大寫然后返回，字符串長度也僅只有 100 字符，另外網絡 Ping 延時只有 1.9ms左右。
因此，理論上該調用耗時應該在 2-3ms 左右，但為什么平均耗時 39.2ms 呢?
調用時延
Ping 時延
由于工作原因，調用耗時的問題，對我來說，已經見怪不怪了，經常會幫業務解決內部 RPC 框架調用超時的相關問題，但是 HTTP 調用耗時是第一次遇到。
不過，排查問題的套路是一樣的。主要方法論無外乎由外而內、自上而下等排查方法。我們先來看看外圍的一些指標，看能否發現蛛絲馬跡。
外圍指標
系統指標
主要看外圍的一些系統指標(注意：調用與被調用的機器都要看)。例如負載、CPU。只需一個 Top 命令就能一覽無余。
因此，確認了下 CPU 和負載都很空閑。由于當時沒有截圖，這里就不放圖了。
進程指標
Java 程序進程指標主要看 GC、線程堆棧情況(注意：調用與被調用的機器都要看)。
Young GC 都非常少，而且耗時也在 10ms 以內，因此沒有長時間的 STW。
因為平均調用時間 39.2ms，比較大，如果耗時是代碼導致，線程堆棧應該能發現點啥。
看了之后一無所獲，服務的相關線程堆棧主要表現是線程池的線程在等任務，這就意味著線程并不忙。
是不是感覺黔驢技窮了，接下來該怎么辦呢?
本地復現
如果本地(本地是 MAC 系統)能復現，對排查問題也是極好的。
因此在本地使用 Apache HTTP Client 寫了個簡單 Test 程序，直接調用后端的 HTTP 服務，發現平均耗時在 55ms 左右。
咦，怎么跟測試環境 39.2ms 的結果有點區別。主要是本地與測試環境的后端的 HTTP 服務機器跨地區了，Ping 時延在 26ms 左右，所以延時增大了。
不過本地確實也是存在問題的，因為 Ping 時延是 26ms，后端 HTTP 服務邏輯簡單，幾乎不耗時，因此本地調用平均耗時應該在 26ms 左右，為什么是 55ms?
是不是越來越迷惑，一頭霧水，不知如何下手?期間懷疑過 Apache HTTP Client 是不是有什么地方使用的不對。
因此使用 JDK 自帶的 HttpURLConnection 寫了簡單的程序，做了測試，結果一樣。
診斷
定位
其實從外圍的系統指標、進程指標，以及本地復現來看，大致能夠斷定不是程序上的原因。那 TCP 協議層面呢?
有網絡編程經驗的同學一定知道 TCP 什么參數會引起這個現象。對，你猜的沒錯，就是 TCP_NODELAY。
那調用方和被調用方哪邊的程序沒有設置呢?調用方使用的是 Apache Http Client ，tcpNoDelay 默認設置的就是 True。
我們再來看看被調用方，也就是我們的后端 HTTP 服務，這個 HTTP 服務用的是 JDK 自帶的 HttpServer：
- HttpServer server = HttpServer.create(new InetSocketAddress(config.getPort()), BACKLOGS);
居然沒看到直接設置 tcpNoDelay 接口，翻了下源碼。哦，原來在這里。
在 ServerConfig 的類中有這段靜態塊，用來獲取啟動參數，默認 ServerConfig.noDelay 為 false：
- static {
- AccessController.doPrivileged(new PrivilegedAction<Void>() {
- 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;
- }
- });
- }
驗證
在后端 HTTP 服務，加上啟動"-Dsun.net.httpserver.nodelay=true"參數再試試。
效果很明顯，平均耗時從 39.2ms 降到 2.8ms：
優化后調用時延
問題是解決了，但是到這里如果你就此止步，那就太便宜了這個案例了，簡直暴殄天物。
因為還有一堆疑惑等著你呢：
- 為什么加了 TCP_NODELAY ，時延就從 39.2ms 降低到 2.8ms?
- 為什么本地測試的平均時延是 55ms，而不是 Ping 的時延 26ms?
- TCP 協議究竟是怎么發送數據包的?
來，我們接著趁熱打鐵。
解惑
①TCP_NODELAY 何許人也?
在 Socket 編程中，TCP_NODELAY 選項是用來控制是否開啟 Nagle 算法。
在 Java 中，為 Ture 表示關閉 Nagle 算法，為 False 表示打開 Nagle 算法。你一定會問 Nagle 算法是什么?
②Nagle 算法是什么鬼?
Nagle 算法是一種通過減少通過網絡發送的數據包數量來提高 TCP/IP 網絡效率的方法。
它使用發明人 John Nagle 的名字來命名的，John Nagle 在 1984 年首次用這個算法來嘗試解決福特汽車公司的網絡擁塞問題。
試想如果應用程序每次產生 1 個字節的數據，然后這 1 個字節數據又以網絡數據包的形式發送到遠端服務器，那么就很容易導致網絡由于太多的數據包而過載。
在這種典型情況下，傳送一個只擁有 1 個字節有效數據的數據包，卻要花費 40 個字節長包頭(即 IP 頭部 20 字節+TCP 頭部 20 字節)的額外開銷，這種有效載荷(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
具體的做法就是：
- 如果發送內容大于等于 1 個 MSS，立即發送。
- 如果之前沒有包未被 ACK，立即發送。
- 如果之前有包未被 ACK，緩存發送內容。
- 如果收到 ACK，立即發送緩存的內容。(MSS 為 TCP 數據包每次能夠傳輸的最大數據分段)
③Delayed ACK 又是什么玩意?
大家都知道 TCP 協議為了保證傳輸的可靠性，規定在接受到數據包時需要向對方發送一個確認。
只是單純的發送一個確認，代價會比較高(IP 頭部 20 字節+TCP 頭部 20 字節)。
TCP Delayed ACK(延遲確認)就是為了努力改善網絡性能，來解決這個問題的。
它將幾個 ACK 響應組合合在一起成為單個響應，或者將 ACK 響應與響應數據一起發送給對方，從而減少協議開銷。
具體的做法是：
- 當有響應數據要發送時，ACK 會隨響應數據立即發送給對方。
- 如果沒有響應數據，ACK 將會延遲發送，以等待看是否有響應數據可以一起發送。在 Linux 系統中，默認這個延遲時間是 40ms。
- 如果在等待發送 ACK 期間，對方的第二個數據包又到達了，這時要立即發送 ACK。
但是如果對方的三個數據包相繼到達，第三個數據段到達時是否立即發送 ACK，則取決于以上兩條。
④Nagle 與 Delayed ACK 一起會發生什么化學反應?
Nagle 與 Delayed ACK 都能提高網絡傳輸的效率，但在一起會好心辦壞事。
例如，以下這個場景，A 和 B 進行數據傳輸 : A 運行 Nagle 算法，B 運行 Delayed ACK 算法。
如果 A 向 B 發一個數據包，B 由于 Delayed ACK 不會立即響應。而 A 使用 Nagle 算法，A 就會一直等 B 的 ACK，ACK 不來一直不發送第二個數據包，如果這兩個數據包是應對同一個請求，那這個請求就會被耽誤了 40ms。
⑤抓個包玩玩吧
我們來抓個包驗證下吧，在后端 HTTP 服務上執行以下腳本，就可以輕松完成抓包過程。
- 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 一起發送的化學反應。
其中 10.48.159.165 運行的是 Delayed ACK，10.22.29.180 運行的是 Nagle 算法。
10.22.29.180 在等 ACK，而 10.48.159.165 觸發了 Delayed ACK，這樣傻傻等了 40ms。
這也就解釋了為什么測試環境耗時是 39.2ms，因為大部分都被 Delayed ACK 的 40ms 給耽誤了。
但是本地復現時，為什么本地測試的平均時延是 55ms，而不是 Ping 的時延 26ms?我們也來抓個包吧。
如下圖，紅框內是一個完整的 POST 請求處理過程，看 8 序號和 9 序號之間相差 25ms 左右，再減去網絡延時約是 Ping 延時的一半 13ms。
本地環境數據包分析
因此 Delayed Ack 約 12ms 左右(由于本地是 MAC 系統與 Linux 有些差異)。
- Linux 使用的是 /proc/sys/net/ipv4/tcp_delack_min 這個系統配置來控制 Delayed ACK 的時間，Linux 默認是 40ms；
- 2. MAC 是通過 net.inet.tcp.delayed_ack 系統配置來控制 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 表示系統自動探測回復 ACK 的時機。
⑥為什么 TCP_NODELAY 能夠解決問題?
tcpNoDelay 關閉了 Nagle 算法，即使上個數據包的 ACK 沒有到達，也會發送下個數據包，進而打破 Delayed ACK 造成的影響。
一般在網絡編程中，強烈建議開啟 tcpNoDelay，來提升響應速度。
當然也可以通過 Delayed ACK 相關系統的配置來解決問題，但由于需要修改機器配置，很不方便，因此，這種方式不太推薦。
總結
本文是從一個簡單的 HTTP 調用，時延比較大而引發的一次問題排查過程。首先由外而內的分析了相關問題，然后定位問題并驗證解決方案。
最后刨根問底對 TCP 傳輸中的 Nagle 與 Delayed ACK 做了全面的講解，更加透徹的剖析了該問題案例。
