Linux網(wǎng)絡(luò)訪問慢？這個(gè)方法快速定位

在 Linux 服務(wù)器中，可以通過內(nèi)核調(diào)優(yōu)、DPDK 以及 XDP 等多種方式提高服務(wù)器的抗攻擊能力，降低 DDoS 對(duì)正常服務(wù)的影響。在應(yīng)用程序中，可以使用各級(jí)緩存、WAF、CDN 等來緩解 DDoS 對(duì)應(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í)，我們?cè)撛趺崔k呢？如何定位網(wǎng)絡(luò)延遲的根本原因？讓我們?cè)诒疚闹杏懻摼W(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)用接收請(qǐng)求并返回響應(yīng)所需的時(shí)間。通常，應(yīng)用延遲也稱為往返延遲，它是網(wǎng)絡(luò)數(shù)據(jù)傳輸時(shí)間加上數(shù)據(jù)處理時(shí)間的總和。

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

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

例如：

#-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

當(dāng)然，你也可以使用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會(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：

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

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

運(yùn)行以下命令以驗(yàn)證兩個(gè)容器都在為流量提供服務(wù)：

$curlhttp://127.0.0.1


...
Thankyouforusingnginx.


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

host2 準(zhǔn)備

現(xiàn)在讓我們用上面提到的hping3來測(cè)試它們的延遲，看看有什么區(qū)別。在 host2 中，執(zhí)行以下命令分別測(cè)試案例機(jī)的 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 端口：

#測(cè)試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

從這個(gè)輸出中您可以看到兩個(gè)端口的延遲大致相同，均為 7 毫秒。但這僅適用于單個(gè)請(qǐng)求。如果換成并發(fā)請(qǐng)求怎么辦？接下來，讓我們用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

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

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

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

$tcpdump-nntcpport8080-wnginx.pcap

現(xiàn)在，在 host2 上重新運(yùn)行wrk命令

$wrk--latency-c100-t2--timeout2http://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)閉彈出的對(duì)話框并返回Wireshark主窗口。這時(shí)你會(huì)發(fā)現(xiàn)Wireshark已經(jīng)自動(dòng)為你設(shè)置了一個(gè)過濾表達(dá)式tcp.stream eq 24。如下圖所示（圖中省略了源 IP 和目的 IP）：

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

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

看到 40ms 的值，你有沒有想到什么？事實(shí)上，這是 TCP 延遲 ACK 的最小超時(shí)。這是 TCP ACK 的一種優(yōu)化機(jī)制，即不是每次請(qǐng)求都發(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(sinceLinux2.4.4)
Enablequickackmodeifsetordisablequickackmodeifcleared.Inquickackmode,acksaresentimme‐
diately,ratherthandelayedifneededinaccordancetonormalTCPoperation.Thisflagisnotperma‐
nent,itonlyenablesaswitchtoorfromquickackmode.SubsequentoperationoftheTCPprotocolwill
onceagainenter/leavequickackmodedependingoninternalprotocolprocessingandfactorssuchas
delayedacktimeoutsoccurringanddatatransfer.Thisoptionshouldnotbeusedincodeintendedtobe
portable.

讓我們測(cè)試一下我們的質(zhì)疑：

$strace-fwrk--latency-c100-t2--timeout2http://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è)請(qǐng)求和并發(fā)請(qǐng)求的網(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)用是否正常。

審核編輯：湯梓紅