40 | 案例篇：網路請求延遲變大了，我該怎麼辦？
阿新 • • 發佈：2020-11-23
上一節，學習了碰到分散式拒絕服務（DDoS）的緩解方法。簡單回顧一下，DDoS 利用大量的偽造請求，導致目標服務要耗費大量資源，來處理這些無效請求，進而無法正常響應正常使用者的請求。
由於 DDoS 的分散式、大流量、難追蹤等特點，目前確實還沒有方法，能夠完全防禦 DDoS 帶來的問題，我們只能設法緩解 DDoS 帶來的影響。
比如，你可以購買專業的流量清洗裝置和網路防火牆，在網路入口處阻斷惡意流量，只保留正常流量進入資料中心的伺服器。
在 Linux 伺服器中，你可以通過核心調優、DPDK、XDP 等多種方法，增大伺服器的抗攻擊能力，降低 DDoS 對正常服務的影響。而在應用程式中，你可以利用各級快取、 WAF、CDN 等方式，緩解 DDoS 對應用程式的影響。
不過要注意，如果 DDoS 的流量，已經到了 Linux 伺服器中，那麼，即使應用層做了各種優化，網路服務的延遲一般還是會比正常情況大很多。
所以，在實際應用中，我們通常要讓 Linux 伺服器，配合專業的流量清洗以及網路防火牆裝置，一起來緩解這一問題。
除了 DDoS 會帶來網路延遲增大外，我想，你肯定見到過不少其他原因導致的網路延遲，比如
- 網路傳輸慢，導致延遲；
- Linux 核心協議棧報文處理慢，導致延遲；
- 應用程式資料處理慢，導致延遲等等。
網路延遲
我相信，提到網路延遲時，你可能輕鬆想起它的含義——網路資料傳輸所用的時間。不過要注意，這個時間可能是單向的，指從源地址傳送到目的地址的單程時間；也可能是雙向的，即從源地址傳送到目的地址，然後又從目的地址發回響應，這個往返全程所用的時間。 通常，我們更常用的是雙向的往返通訊延遲，比如 ping 測試的結果，就是往返延時 RTT（Round-Trip Time）。應用程式延遲
從 hping3 的結果中，你可以看到，往返延遲 RTT 為 20.9ms。 當然，我們用 traceroute ，也可以得到類似結果：# -c 表示傳送 3 次請求，-S 表示設定 TCP SYN，-p 表示埠號為 80 $ hping3 -c 3 -S -p 80 baidu.com HPING baidu.com (eth0 123.125.115.110): S set, 40 headers + 0 data bytes len=46 ip=123.125.115.110 ttl=51 id=47908 sport=80 flags=SA seq=0 win=8192 rtt=20.9 ms len=46 ip=123.125.115.110 ttl=51 id=6788 sport=80 flags=SA seq=1 win=8192 rtt=20.9 ms len=46 ip=123.125.115.110 ttl=51 id=37699 sport=80 flags=SA seq=2 win=8192 rtt=20.9 ms --- baidu.com hping statistic --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 20.9/20.9/20.9 ms
# --tcp 表示使用 TCP 協議，-p 表示埠號，-n 表示不對結果中的 IP 地址執行反向域名解析
$ traceroute --tcp -p 80 -n baidu.com
traceroute to baidu.com (123.125.115.110), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 123.125.115.110 20.684 ms * 20.798 ms案例準備
下面的案例仍然基於 Ubuntu 18.04，同樣適用於其他的 Linux 系統。我使用的案例環境是這樣的： 機器配置：2 CPU，8GB 記憶體。 預先安裝 docker、hping3、tcpdump、curl、wrk、Wireshark 等工具，比如 apt-get install docker.io hping3 tcpdump curl 這裡的工具你應該都比較熟悉了，其中 wrk 的安裝和使用方法在 怎麼評估系統的網路效能 中曾經介紹過。如果你還沒有安裝，請執行下面的命令來安裝它：https://github.com/wg/wrk
cd wrk
apt-get install build-essential -y
make
sudo cp wrk /usr/local/bin/案例分析
為了對比得出延遲增大的影響，首先，我們來執行一個最簡單的 Nginx，也就是用官方的 Nginx 映象啟動一個容器。在終端一中，執行下面的命令，執行官方 Nginx，它會在 80 埠監聽：docker run --network=host --name=good -itd nginx
fb4ed7cb9177d10e270f8320a7fb64717eac3451114c9fab3c50e02be2e88ba2docker run --name nginx --network=host -itd feisky/nginx:latency
b99bd136dcfd907747d9c803fdc0255e578bad6d66f4e9c32b826d75b6812724# 80 埠正常
curl http://192.168.0.30
<!DOCTYPE html>
<html>
...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
# 8080 埠正常
curl http://192.168.0.30:8080
...
<p><em>Thank you for using nginx.</em></p>
</body>
</html># 測試 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 埠延遲
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# 測試 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.85MBtcpdump -nn tcp port 8080 -w nginx.pcap# 測試 8080 埠效能
wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30:8080/TCP 延遲確認
看到 40ms 這個值，你有沒有想起什麼東西呢？實際上，這是 TCP 延遲確認（Delayed ACK）的最小超時時間。 這裡我解釋一下延遲確認。這是針對 TCP ACK 的一種優化機制，也就是說，不用每次請求都發送一個 ACK，而是先等一會兒（比如 40ms），看看有沒有“順風車”。如果這段時間內，正好有其他包需要傳送，那就捎帶著 ACK 一起傳送過去。當然，如果一直等不到其他包，那就超時後單獨傳送 ACK。 因為案例中 40ms 發生在客戶端上，我們有理由懷疑，是客戶端開啟了延遲確認機制。而這兒的客戶端，實際上就是前面執行的 wrk。 查詢 TCP 文件（執行 man tcp），你就會發現，只有 TCP 套接字專門設定了 TCP_QUICKACK ，才會開啟快速確認模式；否則，預設情況下，採用的就是延遲確認機制：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.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
...Nagle
第二個分組沒跟前一個分組（697 號）一起傳送，而是等到客戶端對第一個分組的 ACK 後（1173 號）才傳送，這看起來跟延遲確認有點像，只不過，這兒不再是 ACK，而是傳送資料。 看到這裡，我估計你想起了一個東西—— Nagle 演算法（納格演算法）。進一步分析案例前，我先簡單介紹一下這個演算法。 Nagle 演算法，是 TCP 協議中用於減少小包傳送數量的一種優化演算法，目的是為了提高實際頻寬的利用率。 舉個例子，當有效負載只有 1 位元組時，再加上 TCP 頭部和 IP 頭部分別佔用的 20 位元組，整個網路包就是 41 位元組，這樣實際頻寬的利用率只有 2.4%（1/41）。往大了說，如果整個網路頻寬都被這種小包占滿，那整個網路的有效利用率就太低了。 Nagle 演算法正是為了解決這個問題。它通過合併 TCP 小包，提高網路頻寬的利用率。Nagle 演算法規定，一個 TCP 連線上，最多隻能有一個未被確認的未完成分組；在收到這個分組的 ACK 前，不傳送其他分組。這些小分組會被組合起來，並在收到 ACK 後，用同一個分組傳送出去。 顯然，Nagle 演算法本身的想法還是挺好的，但是知道 Linux 預設的延遲確認機制後，你應該就不這麼想了。因為它們一起使用時，網路延遲會明顯。如下圖所示：- 當 Sever 傳送了第一個分組後，由於 Client 開啟了延遲確認，就需要等待 40ms 後才會回覆 ACK。
- 同時，由於 Server 端開啟了 Nagle，而這時還沒收到第一個分組的 ACK，Server 也會在這裡一直等著。
- 直到 40ms 超時後，Client 才會回覆 ACK，然後，Server 才會繼續傳送第二個分組。
TCP_NODELAY
If set, disable the Nagle algorithm. This means that segments are always sent as soon as possible, even
if there is only a small amount of data. When not set, data is buffered until there is a sufficient
amount to send out, thereby avoiding the frequent sending of small packets, which results in poor uti‐
lization of the network. This option is overridden by TCP_CORK; however, setting this option forces an
explicit flush of pending output, even if TCP_CORK is currently set.docker exec nginx cat /etc/nginx/nginx.conf | grep tcp_nodelay
tcp_nodelay off;# 刪除案例應用
docker rm -f nginx
# 啟動優化後的應用
docker run --name nginx --network=host -itd feisky/nginx:nodelaywrk --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 9.58ms 14.98ms 350.08ms 97.91%
Req/Sec 6.22k 282.13 6.93k 68.50%
Latency Distribution
50% 7.78ms
75% 8.20ms
90% 9.02ms
99% 73.14ms
123990 requests in 10.01s, 100.50MB read
Requests/sec: 12384.04
Transfer/sec: 10.04MBdocker rm -f nginx good小結
今天，我們學習了網路延遲增大後的分析方法。網路延遲，是最核心的網路效能指標。由於網路傳輸、網路包處理等各種因素的影響，網路延遲不可避免。但過大的網路延遲，會直接影響使用者的體驗。 所以，在發現網路延遲增大後，你可以用 traceroute、hping3、tcpdump、Wireshark、strace 等多種工具，來定位網路中的潛在問題。比如，- 使用 hping3 以及 wrk 等工具，確認單次請求和併發請求情況的網路延遲是否正常。
- 使用 traceroute，確認路由是否正確，並檢視路由中每一跳閘道器的延遲。
- 使用 tcpdump 和 Wireshark，確認網路包的收發是否正常。
- 使用 strace 等，觀察應用程式對網路套接字的呼叫情況是否正常。