我们都知道,DDoS 是利用了大量的伪造请求,导致目标服务器消耗大量资源来处理这些无效请求,从而无法正常响应正常用户请求。在 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