有了這款 Linux 網(wǎng)絡(luò)延遲排查方法，再也不用加班了 ~
在 Linux 服務(wù)器中，可以通過內(nèi)核調(diào)優(yōu)、DPDK 以及 XDP 等多種方式提高服務(wù)器的抗攻擊能力，降低 DDoS 對正常服務(wù)的影響。在應(yīng)用程序中，可以使用各級(jí)緩存、WAF、CDN 等來緩解 DDoS 對應(yīng)用程序的影響。
但是需要注意的是，如果 DDoS 流量已經(jīng)到達(dá) Linux 服務(wù)器，那么即使應(yīng)用層做了各種優(yōu)化，網(wǎng)絡(luò)服務(wù)延遲一般也會(huì)比平時(shí)大很多。
因此，在實(shí)際應(yīng)用中，我們通常使用 Linux 服務(wù)器，配合專業(yè)的流量清洗和網(wǎng)絡(luò)防火墻設(shè)備，來緩解這個(gè)問題。
除了 DDoS 導(dǎo)致的網(wǎng)絡(luò)延遲增加，我想你一定見過很多其他原因?qū)е碌木W(wǎng)絡(luò)延遲，例如：
- 網(wǎng)絡(luò)傳輸慢導(dǎo)致的延遲。
- Linux 內(nèi)核協(xié)議棧數(shù)據(jù)包處理速度慢導(dǎo)致的延遲。
- 應(yīng)用程序數(shù)據(jù)處理速度慢造成的延遲等。
那么當(dāng)我們遇到這些原因造成的延誤時(shí)，我們該怎么辦呢？如何定位網(wǎng)絡(luò)延遲的根本原因？讓我們在本文中討論網(wǎng)絡(luò)延遲。
Linux 網(wǎng)絡(luò)延遲
談到網(wǎng)絡(luò)延遲（Network Latency），人們通常認(rèn)為它是指網(wǎng)絡(luò)數(shù)據(jù)傳輸所需的時(shí)間。但是，這里的“時(shí)間”是指雙向流量，即數(shù)據(jù)從源發(fā)送到目的地，然后從目的地地址返回響應(yīng)的往返時(shí)間：RTT（Round-Trip Time）。
除了網(wǎng)絡(luò)延遲之外，另一個(gè)常用的指標(biāo)是應(yīng)用延遲（Application Latency），它是指應(yīng)用接收請求并返回響應(yīng)所需的時(shí)間。通常，應(yīng)用延遲也稱為往返延遲，它是網(wǎng)絡(luò)數(shù)據(jù)傳輸時(shí)間加上數(shù)據(jù)處理時(shí)間的總和。
通常人們使用 ping 命令來測試網(wǎng)絡(luò)延遲，ping 是基于 ICMP 協(xié)議的，它通過計(jì)算 ICMP 發(fā)出的響應(yīng)報(bào)文和 ICMP 發(fā)出的請求報(bào)文之間的時(shí)間差來獲得往返延遲時(shí)間。這個(gè)過程不需要特殊的認(rèn)證，從而經(jīng)常被很多網(wǎng)絡(luò)攻擊所利用，如，端口掃描工具 nmap、分組工具 hping3 等。
因此，為了避免這些問題，很多網(wǎng)絡(luò)服務(wù)都會(huì)禁用 ICMP，這使得我們無法使用 ping 來測試網(wǎng)絡(luò)服務(wù)的可用性和往返延遲。在這種情況下，您可以使用 traceroute 或 hping3 的 TCP 和 UDP 模式來獲取網(wǎng)絡(luò)延遲。
例如：
# -c: 3 requests
# -S: Set TCP SYN
# -p: Set port to 80
$ hping3 -c 3 -S -p 80 google.com
HPING google.com (eth0 142.250.64.110): S set, 40 headers + 0 data bytes
len=46 ip=142.250.64.110 ttl=51 id=47908 sport=80 flags=SA seq=0 win=8192 rtt=9.3 ms
len=46 ip=142.250.64.110 ttl=51 id=6788 sport=80 flags=SA seq=1 win=8192 rtt=10.9 ms
len=46 ip=142.250.64.110 ttl=51 id=37699 sport=80 flags=SA seq=2 win=8192 rtt=11.9 ms
--- baidu.com hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 9.3/10.9/11.9 ms
當(dāng)然，你也可以使用 traceroute：
$ traceroute --tcp -p 80 -n google.com
traceroute to google.com (142.250.190.110), 30 hops max, 60 byte packets
1 * * *
2 240.1.236.34 0.198 ms * *
3 * * 243.254.11.5 0.189 ms
4 * 240.1.236.17 0.216 ms 240.1.236.24 0.175 ms
5 241.0.12.76 0.181 ms 108.166.244.15 0.234 ms 241.0.12.76 0.219 ms
...
24 142.250.190.110 17.465 ms 108.170.244.1 18.532 ms 142.251.60.207 18.595 ms
traceroute 會(huì)在路由的每一跳（hop）發(fā)送三個(gè)數(shù)據(jù)包，并在收到響應(yīng)后輸出往返延遲。如果沒有響應(yīng)或響應(yīng)超時(shí)（默認(rèn) 5s），將輸出一個(gè)星號(hào) *。
案例展示
我們需要在此演示中托管 host1 和 host2 兩個(gè)主機(jī)：
host1 (192.168.0.30)：托管兩個(gè) Nginx Web 應(yīng)用程序（正常和延遲）
host2 (192.168.0.2)：分析主機(jī)
host1 準(zhǔn)備
在 host1 上，讓我們運(yùn)行啟動(dòng)兩個(gè)容器，它們分別是官方 Nginx 和具有延遲版本的 Nginx：
# Official nginx
$ docker run --network=host --name=good -itd nginx
fb4ed7cb9177d10e270f8320a7fb64717eac3451114c9fab3c50e02be2e88ba2
# Latency version of nginx
$ docker run --name nginx --network=host -itd feisky/nginx:latency
b99bd136dcfd907747d9c803fdc0255e578bad6d66f4e9c32b826d75b6812724
運(yùn)行以下命令以驗(yàn)證兩個(gè)容器都在為流量提供服務(wù)：
$ curl http://127.0.0.1
<!DOCTYPE html>
<html>
...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
$ curl http://127.0.0.1:8080
...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
host2 準(zhǔn)備
現(xiàn)在讓我們用上面提到的 hping3 來測試它們的延遲，看看有什么區(qū)別。在 host2 中，執(zhí)行以下命令分別測試案例機(jī)的 8080 端口和 80 端口的延遲：
80 端口：
$ hping3 -c 3 -S -p 80 192.168.0.30
HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data bytes
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=80 flags=SA seq=0 win=29200 rtt=7.8 ms
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=80 flags=SA seq=1 win=29200 rtt=7.7 ms
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=80 flags=SA seq=2 win=29200 rtt=7.6 ms
--- 192.168.0.30 hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 7.6/7.7/7.8 ms
8080 端口：
# 測試8080端口延遲
$ hping3 -c 3 -S -p 8080 192.168.0.30
HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data bytes
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=8080 flags=SA seq=0 win=29200 rtt=7.7 ms
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=8080 flags=SA seq=1 win=29200 rtt=7.6 ms
len=44 ip=192.168.0.30 ttl=64 DF id=0 sport=8080 flags=SA seq=2 win=29200 rtt=7.3 ms
--- 192.168.0.30 hping statistic ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 7.3/7.6/7.7 ms
從這個(gè)輸出中您可以看到兩個(gè)端口的延遲大致相同，均為 7 毫秒。但這僅適用于單個(gè)請求。如果換成并發(fā)請求怎么辦？接下來，讓我們用 wrk (https://github.com/wg/wrk) 試試。
80 端口：
$ wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30/
Running 10s test @ http://192.168.0.30/
2 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 9.19ms 12.32ms 319.61ms 97.80%
Req/Sec 6.20k 426.80 8.25k 85.50%
Latency Distribution
50% 7.78ms
75% 8.22ms
90% 9.14ms
99% 50.53ms
123558 requests in 10.01s, 100.15MB read
Requests/sec: 12340.91
Transfer/sec: 10.00MB
8080 端口：
$ wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30:8080/
Running 10s test @ http://192.168.0.30:8080/
2 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 43.60ms 6.41ms 56.58ms 97.06%
Req/Sec 1.15k 120.29 1.92k 88.50%
Latency Distribution
50% 44.02ms
75% 44.33ms
90% 47.62ms
99% 48.88ms
22853 requests in 10.01s, 18.55MB read
Requests/sec: 2283.31
Transfer/sec: 1.85MB
從以上兩個(gè)輸出可以看出，官方 Nginx（監(jiān)聽 80 端口）的平均延遲為 9.19ms，而案例 Nginx（監(jiān)聽 8080 端口）的平均延遲為 43.6ms。從延遲分布上來看，官方 Nginx 可以在 9ms 內(nèi)完成 90% 的請求；對于案例 Nginx，50% 的請求已經(jīng)達(dá)到 44ms。
那么這里發(fā)生了什么呢？我們來做一些分析：
在 host1 中，讓我們使用 tcpdump 捕獲一些網(wǎng)絡(luò)數(shù)據(jù)包：
$ tcpdump -nn tcp port 8080 -w nginx.pcap
現(xiàn)在，在 host2 上重新運(yùn)行 wrk 命令
$ wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30:8080/
當(dāng) wrk 命令完成后，再次切換回 Terminal 1（host1 的終端）并按 Ctrl+C 結(jié)束 tcpdump 命令。然后，用 Wireshark 把抓到的 nginx.pcap 復(fù)制到本機(jī)（如果 VM1（host1 的虛擬機(jī)）已經(jīng)有圖形界面，可以跳過復(fù)制步驟），用 Wireshark 打開。
由于網(wǎng)絡(luò)包的數(shù)量很多，我們可以先過濾一下。例如，選中一個(gè)包后，可以右鍵選擇 “Follow”->“TCP Stream”，如下圖：
然后，關(guān)閉彈出的對話框并返回 Wireshark 主窗口。這時(shí)你會(huì)發(fā)現(xiàn) Wireshark 已經(jīng)自動(dòng)為你設(shè)置了一個(gè)過濾表達(dá)式 tcp.stream eq 24。如下圖所示（圖中省略了源 IP 和目的 IP）：
從這里，您可以看到從三次握手開始，此 TCP 連接的每個(gè)請求和響應(yīng)。當(dāng)然，這可能不夠直觀，可以繼續(xù)點(diǎn)擊菜單欄中的 Statistics -> Flow Graph，選擇 “Limit to display filter”，將 Flow type 設(shè)置為 “TCP Flows”：
請注意，此圖的左側(cè)是客戶端，而右側(cè)是 Nginx 服務(wù)器。從這個(gè)圖中可以看出，前三次握手和第一次 HTTP 請求和響應(yīng)都相當(dāng)快，但是第二次 HTTP 請求就比較慢了，尤其是客戶端收到服務(wù)器的第一個(gè)數(shù)據(jù)包后，該 ACK 響應(yīng)（圖中的藍(lán)線）在 40ms 后才被發(fā)送。
看到 40ms 的值，你有沒有想到什么？事實(shí)上，這是 TCP 延遲 ACK 的最小超時(shí)。這是 TCP ACK 的一種優(yōu)化機(jī)制，即不是每次請求都發(fā)送一個(gè) ACK，而是等待一段時(shí)間（比如 40ms），看看有沒有“搭車”的數(shù)據(jù)包。如果在此期間還有其他數(shù)據(jù)包需要發(fā)送，它們將與 ACK 一起被發(fā)送。當(dāng)然，如果等不及其他數(shù)據(jù)包，超時(shí)后會(huì)單獨(dú)發(fā)送 ACK。
由于案例中的客戶端發(fā)生了 40ms 延遲，我們有理由懷疑客戶端開啟了延遲確認(rèn)機(jī)制（Delayed Acknowledgment Mechanism）。這里的客戶端其實(shí)就是之前運(yùn)行的 wrk。
根據(jù) TCP 文檔，只有在 TCP 套接字專門設(shè)置了 TCP_QUICKACK 時(shí)才會(huì)啟用快速確認(rèn)模式（Fast Acknowledgment Mode）；否則，默認(rèn)使用延遲確認(rèn)機(jī)制：
TCP_QUICKACK (since Linux 2.4.4)
Enable quickack mode if set or disable quickack mode if cleared. In quickack mode, acks are sent imme‐
diately, rather than delayed if needed in accordance to normal TCP operation. This flag is not perma‐
nent, it only enables a switch to or from quickack mode. Subsequent operation of the TCP protocol will
once again enter/leave quickack mode depending on internal protocol processing and factors such as
delayed ack timeouts occurring and data transfer. This option should not be used in code intended to be
portable.
讓我們測試一下我們的質(zhì)疑：
$ strace -f wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30:8080/
...
setsockopt(52, SOL_TCP, TCP_NODELAY, [1], 4) = 0
...
可以看到 wrk 只設(shè)置了 TCP_NODELAY 選項(xiàng)，沒有設(shè)置 TCP_QUICKACK?，F(xiàn)在您可以看到為什么延遲 Nginx（案例 Nginx）響應(yīng)會(huì)出現(xiàn)一個(gè)延遲。
結(jié)論
在本文中，我們向您展示如何分析增加的網(wǎng)絡(luò)延遲。網(wǎng)絡(luò)延遲是核心網(wǎng)絡(luò)性能指標(biāo)。由于網(wǎng)絡(luò)傳輸、網(wǎng)絡(luò)報(bào)文處理等多種因素的影響，網(wǎng)絡(luò)延遲是不可避免的。但過多的網(wǎng)絡(luò)延遲會(huì)直接影響用戶體驗(yàn)。
- 使用 hping3 和 wrk 等工具確認(rèn)單個(gè)請求和并發(fā)請求的網(wǎng)絡(luò)延遲是否正常。
- 使用 traceroute，確認(rèn)路由正確，并查看路由中每個(gè)網(wǎng)關(guān)跳躍點(diǎn)的延遲。
- 使用 tcpdump 和 Wireshark 確認(rèn)網(wǎng)絡(luò)數(shù)據(jù)包是否正常收發(fā)。
- 使用 strace 等觀察應(yīng)用程序?qū)W(wǎng)絡(luò) socket 的調(diào)用是否正常。
