在 Linux 服務器中，可以通過內核調優(yōu)、DPDK 以及 XDP 等多種方式提高服務器的抗攻擊能力，降低 DDoS 對正常服務的影響。在應用程序中，可以使用各級緩存、WAF、CDN 等來緩解 DDoS 對應用程序的影響。

但是需要注意的是，如果 DDoS 流量已經到達 Linux 服務器，那么即使應用層做了各種優(yōu)化，網絡服務延遲一般也會比平時大很多。

因此，在實際應用中，我們通常使用 Linux 服務器，配合專業(yè)的流量清洗和網絡防火墻設備，來緩解這個問題。

除了 DDoS 導致的網絡延遲增加，我想你一定見過很多其他原因導致的網絡延遲，例如：

網絡傳輸慢導致的延遲。

Linux 內核協(xié)議棧數據包處理速度慢導致的延遲。

應用程序數據處理速度慢造成的延遲等。

那么當我們遇到這些原因造成的延誤時，我們該怎么辦呢？如何定位網絡延遲的根本原因？讓我們在本文中討論網絡延遲。

Linux 網絡延遲

談到網絡延遲（Network Latency），人們通常認為它是指網絡數據傳輸所需的時間。但是，這里的“時間”是指雙向流量，即數據從源發(fā)送到目的地，然后從目的地地址返回響應的往返時間：RTT（Round-Trip Time）。

除了網絡延遲之外，另一個常用的指標是應用延遲（Application Latency），它是指應用接收請求并返回響應所需的時間。通常，應用延遲也稱為往返延遲，它是網絡數據傳輸時間加上數據處理時間的總和。

通常人們使用ping命令來測試網絡延遲，ping是基于 ICMP 協(xié)議的，它通過計算 ICMP 發(fā)出的響應報文和 ICMP 發(fā)出的請求報文之間的時間差來獲得往返延遲時間。這個過程不需要特殊的認證，從而經常被很多網絡攻擊所利用，如，端口掃描工具nmap、分組工具hping3等。

因此，為了避免這些問題，很多網絡服務都會禁用 ICMP，這使得我們無法使用 ping 來測試網絡服務的可用性和往返延遲。在這種情況下，您可以使用traceroute或hping3的 TCP 和 UDP 模式來獲取網絡延遲。

例如：

#-c:3requests
#-S:SetTCPSYN
#-p:Setportto80
$hping3-c3-S-p80google.com
HPINGgoogle.com(eth0142.250.64.110):Sset,40headers+0databytes
len=46ip=142.250.64.110ttl=51id=47908sport=80flags=SAseq=0win=8192rtt=9.3ms
len=46ip=142.250.64.110ttl=51id=6788sport=80flags=SAseq=1win=8192rtt=10.9ms
len=46ip=142.250.64.110ttl=51id=37699sport=80flags=SAseq=2win=8192rtt=11.9ms
---baidu.comhpingstatistic---
3packetstransmitted,3packetsreceived,0%packetloss
round-tripmin/avg/max=9.3/10.9/11.9ms

當然，你也可以使用traceroute：

$traceroute--tcp-p80-ngoogle.com
traceroutetogoogle.com(142.250.190.110),30hopsmax,60bytepackets
1***
2240.1.236.340.198ms**
3**243.254.11.50.189ms
4*240.1.236.170.216ms240.1.236.240.175ms
5241.0.12.760.181ms108.166.244.150.234ms241.0.12.760.219ms
...
24142.250.190.11017.465ms108.170.244.118.532ms142.251.60.20718.595ms

traceroute會在路由的每一跳（hop）發(fā)送三個數據包，并在收到響應后輸出往返延遲。如果沒有響應或響應超時（默認 5s），將輸出一個星號*。

案例展示

我們需要在此演示中托管 host1 和 host2 兩個主機：

host1 (192.168.0.30)：托管兩個 Nginx Web 應用程序（正常和延遲）

host2 (192.168.0.2)：分析主機

host1 準備

在 host1 上，讓我們運行啟動兩個容器，它們分別是官方 Nginx 和具有延遲版本的 Nginx：

#Officialnginx
$dockerrun--network=host--name=good-itdnginx
fb4ed7cb9177d10e270f8320a7fb64717eac3451114c9fab3c50e02be2e88ba2
#Latencyversionofnginx

$dockerrun--namenginx--network=host-itdfeisky/nginx:latency
b99bd136dcfd907747d9c803fdc0255e578bad6d66f4e9c32b826d75b6812724

運行以下命令以驗證兩個容器都在為流量提供服務：

$curlhttp://127.0.0.1


...
Thankyouforusingnginx.


$curlhttp://127.0.0.1:8080
...
Thankyouforusingnginx.

host2 準備

現在讓我們用上面提到的hping3來測試它們的延遲，看看有什么區(qū)別。在 host2 中，執(zhí)行以下命令分別測試案例機的 8080 端口和 80 端口的延遲：

80 端口：

$hping3-c3-S-p80192.168.0.30
HPING192.168.0.30(eth0192.168.0.30):Sset,40headers+0databytes
len=44ip=192.168.0.30ttl=64DFid=0sport=80flags=SAseq=0win=29200rtt=7.8ms
len=44ip=192.168.0.30ttl=64DFid=0sport=80flags=SAseq=1win=29200rtt=7.7ms
len=44ip=192.168.0.30ttl=64DFid=0sport=80flags=SAseq=2win=29200rtt=7.6ms
---192.168.0.30hpingstatistic---
3packetstransmitted,3packetsreceived,0%packetloss
round-tripmin/avg/max=7.6/7.7/7.8ms

8080 端口：

#測試8080端口延遲
$hping3-c3-S-p8080192.168.0.30
HPING192.168.0.30(eth0192.168.0.30):Sset,40headers+0databytes
len=44ip=192.168.0.30ttl=64DFid=0sport=8080flags=SAseq=0win=29200rtt=7.7ms
len=44ip=192.168.0.30ttl=64DFid=0sport=8080flags=SAseq=1win=29200rtt=7.6ms
len=44ip=192.168.0.30ttl=64DFid=0sport=8080flags=SAseq=2win=29200rtt=7.3ms
---192.168.0.30hpingstatistic---
3packetstransmitted,3packetsreceived,0%packetloss
round-tripmin/avg/max=7.3/7.6/7.7ms

從這個輸出中您可以看到兩個端口的延遲大致相同，均為 7 毫秒。但這僅適用于單個請求。如果換成并發(fā)請求怎么辦？接下來，讓我們用wrk (https://github.com/wg/wrk) 試試。

80 端口：

$wrk--latency-c100-t2--timeout2http://192.168.0.30/
Running10stest@http://192.168.0.30/
2threadsand100connections
ThreadStatsAvgStdevMax+/-Stdev
Latency9.19ms12.32ms319.61ms97.80%
Req/Sec6.20k426.808.25k85.50%
LatencyDistribution
50%7.78ms
75%8.22ms
90%9.14ms
99%50.53ms
123558requestsin10.01s,100.15MBread
Requests/sec:12340.91
Transfer/sec:10.00MB

8080 端口：

$wrk--latency-c100-t2--timeout2http://192.168.0.30:8080/
Running10stest@http://192.168.0.30:8080/
2threadsand100connections
ThreadStatsAvgStdevMax+/-Stdev
Latency43.60ms6.41ms56.58ms97.06%
Req/Sec1.15k120.291.92k88.50%
LatencyDistribution
50%44.02ms
75%44.33ms
90%47.62ms
99%48.88ms
22853requestsin10.01s,18.55MBread
Requests/sec:2283.31
Transfer/sec:1.85MB

從以上兩個輸出可以看出，官方 Nginx（監(jiān)聽 80 端口）的平均延遲為 9.19ms，而案例 Nginx（監(jiān)聽 8080 端口）的平均延遲為 43.6ms。從延遲分布上來看，官方 Nginx 可以在 9ms 內完成 90% 的請求；對于案例 Nginx，50% 的請求已經達到 44ms。

那么這里發(fā)生了什么呢？我們來做一些分析：

在 host1 中，讓我們使用tcpdump捕獲一些網絡數據包：

$tcpdump-nntcpport8080-wnginx.pcap

現在，在 host2 上重新運行wrk命令

$wrk--latency-c100-t2--timeout2http://192.168.0.30:8080/

當wrk命令完成后，再次切換回 Terminal 1（host1 的終端）并按 Ctrl+C 結束tcpdump命令。然后，用Wireshark把抓到的nginx.pcap復制到本機（如果 VM1（host1 的虛擬機）已經有圖形界面，可以跳過復制步驟），用Wireshark打開。

由于網絡包的數量很多，我們可以先過濾一下。例如，選中一個包后，可以右鍵選擇 “Follow”->“TCP Stream”，如下圖：

然后，關閉彈出的對話框并返回Wireshark主窗口。這時你會發(fā)現Wireshark已經自動為你設置了一個過濾表達式tcp.stream eq 24。如下圖所示（圖中省略了源 IP 和目的 IP）：

從這里，您可以看到從三次握手開始，此 TCP 連接的每個請求和響應。當然，這可能不夠直觀，可以繼續(xù)點擊菜單欄中的 Statistics -> Flow Graph，選擇 “Limit to display filter”，將 Flow type 設置為 “TCP Flows”：

請注意，此圖的左側是客戶端，而右側是 Nginx 服務器。從這個圖中可以看出，前三次握手和第一次 HTTP 請求和響應都相當快，但是第二次 HTTP 請求就比較慢了，尤其是客戶端收到服務器的第一個數據包后，該 ACK 響應（圖中的藍線）在 40ms 后才被發(fā)送。

看到 40ms 的值，你有沒有想到什么？事實上，這是 TCP 延遲 ACK 的最小超時。這是 TCP ACK 的一種優(yōu)化機制，即不是每次請求都發(fā)送一個 ACK，而是等待一段時間（比如 40ms），看看有沒有“搭車”的數據包。如果在此期間還有其他數據包需要發(fā)送，它們將與 ACK 一起被發(fā)送。當然，如果等不及其他數據包，超時后會單獨發(fā)送 ACK。

由于案例中的客戶端發(fā)生了 40ms 延遲，我們有理由懷疑客戶端開啟了延遲確認機制（Delayed Acknowledgment Mechanism）。這里的客戶端其實就是之前運行的 wrk。

根據 TCP 文檔，只有在 TCP 套接字專門設置了 TCP_QUICKACK 時才會啟用快速確認模式（Fast Acknowledgment Mode）；否則，默認使用延遲確認機制：

TCP_QUICKACK(sinceLinux2.4.4)
Enablequickackmodeifsetordisablequickackmodeifcleared.Inquickackmode,acksaresentimme‐
diately,ratherthandelayedifneededinaccordancetonormalTCPoperation.Thisflagisnotperma‐
nent,itonlyenablesaswitchtoorfromquickackmode.SubsequentoperationoftheTCPprotocolwill
onceagainenter/leavequickackmodedependingoninternalprotocolprocessingandfactorssuchas
delayedacktimeoutsoccurringanddatatransfer.Thisoptionshouldnotbeusedincodeintendedtobe
portable.

讓我們測試一下我們的質疑：

$strace-fwrk--latency-c100-t2--timeout2http://192.168.0.30:8080/
...
setsockopt(52,SOL_TCP,TCP_NODELAY,[1],4)=0
...

可以看到wrk只設置了TCP_NODELAY選項，沒有設置TCP_QUICKACK。現在您可以看到為什么延遲 Nginx（案例 Nginx）響應會出現一個延遲。

結論

在本文中，我將向您展示如何分析增加的網絡延遲。網絡延遲是核心網絡性能指標。由于網絡傳輸、網絡報文處理等多種因素的影響，網絡延遲是不可避免的。但過多的網絡延遲會直接影響用戶體驗。

使用hping3和wrk等工具確認單個請求和并發(fā)請求的網絡延遲是否正常。

使用traceroute，確認路由正確，并查看路由中每個網關跳躍點的延遲。

使用tcpdump和Wireshark確認網絡數據包是否正常收發(fā)。

使用strace等觀察應用程序對網絡 socket 的調用是否正常。

審核編輯：湯梓紅