在 linux 服務器中，可以通過內核調優、DPDK 以及 XDP 等多種方式提高服務器的抗攻擊能力，降低 DDoS 對正常服務的影響。在應用程序中，可以使用各級緩存、WAF、CDN 等來緩解 DDoS 對應用程序的影響。
但是需要注意的是，如果 DDoS 流量已經到達 Linux 服務器，那么即使應用層做了各種優化，網絡服務延遲一般也會比平時大很多。
因此，在實際應用中，我們通常使用 Linux 服務器，配合專業的流量清洗和網絡防火墻設備，來緩解這個問題。
除了 DDoS 導致的網絡延遲增加，我想你一定見過很多其他原因導致的網絡延遲，例如：
-
網絡傳輸慢導致的延遲。
-
Linux 內核協議棧數據包處理速度慢導致的延遲。
-
應用程序數據處理速度慢造成的延遲等。
那么當我們遇到這些原因造成的延誤時，我們該怎么辦呢？如何定位網絡延遲的根本原因？讓我們在本文中討論網絡延遲。
Linux 網絡延遲
談到 網絡延遲?.NETwork Latency），人們通常認為它是指網絡數據傳輸所需的時間。但是，這里的“時間”是指雙向流量，即數據從源發送到目的地，然后從目的地地址返回響應的往返時間： RTT（Round-Trip Time）。
除了 網絡延遲之外，另一個常用的指標是 應用延遲（Application Latency），它是指應用接收請求并返回響應所需的時間。通常， 應用延遲也稱為 往返延遲，它是網絡數據傳輸時間加上數據處理時間的總和。
通常人們使用 ping 命令來測試網絡延遲， ping 是基于 ICMP 協議的，它通過計算 ICMP 發出的 響應報文和 ICMP 發出的 請求報文之間的時間差來獲得往返延遲時間。這個過程不需要特殊的認證，從而經常被很多網絡攻擊所利用，如，端口掃描工具 nmap 、分組工具 hping3 等。
因此，為了避免這些問題，很多網絡服務都會禁用 ICMP，這使得我們無法使用 ping 來測試網絡服務的可用性和往返延遲。在這種情況下，您可以使用 traceroute 或 hping3 的 TCP 和 UDP 模式來獲取網絡延遲。
例如：
# -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
當然，你也可以使用 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 會在路由的每一跳（hop）發送三個數據包，并在收到響應后輸出往返延遲。如果沒有響應或響應超時（默認 5s），將輸出一個星號 * 。
案例展示
我們需要在此演示中托管 host1 和 host2 兩個主機：
-
host1 (192.168.0.30)：托管兩個 Nginx Web 應用程序（正常和延遲）
-
host2 (192.168.0.2)：分析主機
在 host1 上，讓我們運行啟動兩個容器，它們分別是官方 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
運行以下命令以驗證兩個容器都在為流量提供服務：
$ curl http://127.0.0.1
<!DOCTYPE html>
<html>
...
<p><em>Thank you forusing nginx.</em></p>
</body>
</html>
$ curl http://127.0.0.1:8080
...
<p><em>Thank you forusing nginx.</em></p>
</body>
</html>
host2 準備
現在讓我們用上面提到的 hping3 來測試它們的延遲，看看有什么區別。在 host2 中，執行以下命令分別測試案例機的 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
從這個輸出中您可以看到兩個端口的延遲大致相同，均為 7 毫秒。但這僅適用于單個請求。如果換成并發請求怎么辦？接下來，讓我們用 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 in10.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 in10.01s, 18.55MB read
Requests/sec: 2283.31
Transfer/sec: 1.85MB
從以上兩個輸出可以看出，官方 Nginx（監聽 80 端口）的平均延遲為 9.19ms，而案例 Nginx（監聽 8080 端口）的平均延遲為 43.6ms。從延遲分布上來看，官方 Nginx 可以在 9ms 內完成 90% 的請求；對于案例 Nginx，50% 的請求已經達到 44ms。
那么這里發生了什么呢？我們來做一些分析：
在 host1 中，讓我們使用 tcpdump 捕獲一些網絡數據包：
$ tcpdump -nn tcp port 8080 -w nginx.pcap
現在，在 host2 上重新運行 wrk 命令
$ wrk --latency -c 100 -t 2 --timeout 2 http://192.168.0.30:8080/
當 wrk 命令完成后，再次切換回 Terminal 1（host1 的終端）并按 Ctrl+C 結束 tcpdump 命令。然后，用 Wireshark 把抓到的 nginx.pcap 復制到本機（如果 VM1（host1 的虛擬機）已經有圖形界面，可以跳過復制步驟），用 Wireshark 打開。
由于網絡包的數量很多，我們可以先過濾一下。例如，選中一個包后，可以右鍵選擇 “Follow”->“TCP Stream”，如下圖：
然后，關閉彈出的對話框并返回 Wireshark 主窗口。這時你會發現 Wireshark 已經自動為你設置了一個過濾表達式 tcp.stream eq 24 。如下圖所示（圖中省略了源 IP 和目的 IP）：
從這里，您可以看到從三次握手開始，此 TCP 連接的每個請求和響應。當然，這可能不夠直觀，可以繼續點擊菜單欄中的 Statistics -> Flow Graph，選擇 “Limit to display filter”，將 Flow type 設置為 “TCP Flows”：
請注意，此圖的左側是客戶端，而右側是 Nginx 服務器。從這個圖中可以看出，前三次握手和第一次 HTTP 請求和響應都相當快，但是第二次 HTTP 請求就比較慢了，尤其是客戶端收到服務器的第一個數據包后，該 ACK 響應（圖中的藍線）在 40ms 后才被發送。
看到 40ms 的值，你有沒有想到什么？事實上，這是 TCP 延遲 ACK的最小超時。這是 TCP ACK 的一種優化機制，即不是每次請求都發送一個 ACK，而是等待一段時間（比如 40ms），看看有沒有“搭車”的數據包。如果在此期間還有其他數據包需要發送，它們將與 ACK 一起被發送。當然，如果等不及其他數據包，超時后會單獨發送 ACK。
由于案例中的客戶端發生了 40ms 延遲，我們有理由懷疑客戶端開啟了 延遲確認機制（Delayed Acknowledgment Mechanism）。這里的客戶端其實就是之前運行的 wrk 。
根據 TCP 文檔，只有在 TCP 套接字專門設置了 TCP_QUICKACK 時才會啟用 快速確認模式（Fast Acknowledgment Mode）；否則，默認使用 延遲確認機制：
TCP_QUICKACK (since Linux 2.4.4)
Enable quickack mode ifsetor disablequickack mode ifcleared. In quickack mode, acks are sent imme‐
diately, rather than delayed ifneeded inaccordance 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 incode 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
...
可以看到 wrk 只設置了 TCP_NODELAY 選項，沒有設置 TCP_QUICKACK 。現在您可以看到為什么延遲 Nginx（案例 Nginx）響應會出現一個延遲。
結論
在本文中，我們向您展示如何分析增加的網絡延遲。網絡延遲是核心網絡性能指標。由于網絡傳輸、網絡報文處理等多種因素的影響，網絡延遲是不可避免的。但過多的網絡延遲會直接影響用戶體驗。
-
使用 hping3 和 wrk 等工具確認單個請求和并發請求的網絡延遲是否正常。
-
使用 traceroute ，確認路由正確，并查看路由中每個網關跳躍點的延遲。
-
使用 tcpdump 和 Wireshark 確認網絡數據包是否正常收發。
-
使用 strace 等觀察應用程序對網絡 socket 的調用是否正常。
來源：https://blog.devgenius.io/linux-troubleshoot-network-latency-a6da740f5cb8
