亚洲一区二区观看,天天插天天操天天干,视频一区二区在线

在 linux 服務(wù)器中，可以通過(guò)內(nèi)核調(diào)優(yōu)、DPDK 以及 XDP 等多種方式提高服務(wù)器的抗攻擊能力，降低 DDoS 對(duì)正常服務(wù)的影響。在應(yīng)用程序中，可以使用各級(jí)緩存、WAF、CDN 等來(lái)緩解 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ù)器，配合專(zhuān)業(yè)的流量清洗和網(wǎng)絡(luò)防火墻設(shè)備，來(lái)緩解這個(gè)問(wèn)題。

除了 DDoS 導(dǎo)致的網(wǎng)絡(luò)延遲增加，我想你一定見(jiàn)過(guò)很多其他原因?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 命令來(lái)測(cè)試網(wǎng)絡(luò)延遲，ping 是基于 ICMP 協(xié)議的，它通過(guò)計(jì)算 ICMP 發(fā)出的響應(yīng)報(bào)文和 ICMP 發(fā)出的請(qǐng)求報(bào)文之間的時(shí)間差來(lái)獲得往返延遲時(shí)間。這個(gè)過(guò)程不需要特殊的認(rèn)證，從而經(jīng)常被很多網(wǎng)絡(luò)攻擊所利用，如，端口掃描工具 nmap、分組工具 hping3 等。

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

例如：

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

當(dāng)然，你也可以使用 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 會(huì)在路由的每一跳（hop）發(fā)送三個(gè)數(shù)據(jù)包，并在收到響應(yīng)后輸出往返延遲。如果沒(méi)有響應(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：

# 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

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

$ curl http://127.0.0.1
<!DOCTYPE html>
<html>
...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
$ curl http://127.0.0.1:8080
...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

host2 準(zhǔn)備

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

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

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

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

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

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

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

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

$ wrk --latency -c 100 -t 2 --timeout 2 http://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)有圖形界面，可以跳過(guò)復(fù)制步驟），用 Wireshark 打開(kāi)。

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

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

從這里，您可以看到從三次握手開(kāi)始，此 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 的值，你有沒(méi)有想到什么？事實(shí)上，這是 TCP 延遲 ACK 的最小超時(shí)。這是 TCP ACK 的一種優(yōu)化機(jī)制，即不是每次請(qǐng)求都發(fā)送一個(gè) ACK，而是等待一段時(shí)間（比如 40ms），看看有沒(méi)有“搭車(chē)”的數(shù)據(jù)包。如果在此期間還有其他數(shù)據(jù)包需要發(fā)送，它們將與 ACK 一起被發(fā)送。當(dāng)然，如果等不及其他數(shù)據(jù)包，超時(shí)后會(huì)單獨(dú)發(fā)送 ACK。

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

根據(jù) TCP 文檔，只有在 TCP 套接字專(zhuān)門(mén)設(shè)置了 TCP_QUICKACK 時(shí)才會(huì)啟用快速確認(rèn)模式（Fast Acknowledgment Mode）；否則，默認(rèn)使用延遲確認(rèn)機(jī)制：?

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.

讓我們測(cè)試一下我們的質(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 只設(shè)置了 TCP_NODELAY 選項(xiàng)，沒(méi)有設(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ò)延遲是不可避免的。但過(guò)多的網(wǎng)絡(luò)延遲會(huì)直接影響用戶體驗(yàn)。