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

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

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

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

網(wǎng)絡傳輸慢導致的延遲。

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

應用程序數(shù)據(jù)處理速度慢造成的延遲等。

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

Linux 網(wǎng)絡延遲

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

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

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

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

例如：

#?-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）發(fā)送三個數(shù)據(jù)包，并在收到響應后輸出往返延遲。如果沒有響應或響應超時（默認 5s），將輸出一個星號*。

案例展示

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

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

host2 (192.168.0.2)：分析主機

host1 準備

在 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


...
Thank?you?for?using?nginx.


$?curl?http://127.0.0.1:8080
...
Thank?you?for?using?nginx.

host2 準備

現(xiàn)在讓我們用上面提到的hping3來測試它們的延遲，看看有什么區(qū)別。在 host2 中，執(zhí)行以下命令分別測試案例機的 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 毫秒。但這僅適用于單個請求。如果換成并發(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

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

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

在 host1 中，讓我們使用tcpdump捕獲一些網(wǎng)絡數(shù)據(jù)包：

$?tcpdump?-nn?tcp?port?8080?-w?nginx.pcap

現(xiàn)在，在 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 的虛擬機）已經(jīng)有圖形界面，可以跳過復制步驟），用Wireshark打開。

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

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

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

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

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

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

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

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只設置了TCP_NODELAY選項，沒有設置TCP_QUICKACK?，F(xiàn)在您可以看到為什么延遲 Nginx（案例 Nginx）響應會出現(xiàn)一個延遲。

結論

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

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

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

使用tcpdump和Wireshark確認網(wǎng)絡數(shù)據(jù)包是否正常收發(fā)。

使用strace等觀察應用程序對網(wǎng)絡 socket 的調(diào)用是否正常。

編輯：黃飛

?