计算机网络
OSI 与 TCP/IP
OSI 七层协议模型

各层功能
- 物理层:通过传输介质传输比特流,定义机械、电气等规范,传输单位为 bit。
- 数据链路层:将比特组装成帧,负责相邻节点之间的数据传输,传输单位为帧,常见协议或技术包括 MAC、VLAN、PPP、ARP。
- 网络层:实现数据包的选路和转发,提供网络互连,传输单位为包,常见协议包括 IP、ICMP。
- 传输层:为两台主机上的应用进程提供端到端通信,传输单位为报文段或数据报,常见协议包括 TCP、UDP。
- 会话层:建立、管理和终止会话。
- 表示层:负责数据格式转换、加密和压缩。
- 应用层:面向应用程序提供网络服务,常见协议包括 FTP、HTTP、DNS。
TCP/IP 体系结构

应用层
HTTP:超文本传输协议,在浏览器与服务器间传送文档。
DNS(Domain Name Service,域名服务)协议提供域名到 IP 地址的转换。DNS 是一套分布式域名服务系统,每个 DNS 服务器保存一部分域名和 IP 地址的映射,并可以动态更新。客户端通常通过 DNS 协议查询目标主机的 IP 地址,DNS 常见情况下使用 UDP 传输。

SMTP 协议:简单邮件传送协议。
FTP 协议:文件传输协议。
RIP 协议:距离矢量路由选择协议。
传输层
TCP 协议(Transmission Control Protocol,传输控制协议)为应用层提供可靠、面向连接、基于字节流(stream)的服务。
UDP 协议(User Datagram Protocol,用户数据报协议)为应用层提供无连接、尽最大努力交付、基于数据报的服务。
网络层
IP 协议:IP 协议根据数据包的目的 IP 地址决定如何投递,使用逐跳(hop by hop)的方式确定通信路径,主要负责寻址、路由选择、分片与组装。
ICMP 协议:是 IP 协议的重要补充,主要用于差错报告和网络诊断,ping 命令底层就使用 ICMP。
数据链路层
ARP 协议:ARP 地址解析协议用于将网络地址(IP 地址 32 位)转换为物理地址(MAC 地址 48 位)。
原理:
- 主机A检查自己的ARP缓存表(ARP cache),其中存储了最近与其他主机通信的IP地址和对应的MAC地址。如果目标主机的IP地址已经存在于ARP缓存表中,主机A可以直接使用该MAC地址发送数据。
- 如果ARP缓存表中没有目标主机的IP地址条目,主机A将发送一个ARP请求广播到局域网上的所有主机。ARP请求包含主机A的IP地址和MAC地址,以及目标主机的IP地址。
- 其他主机收到ARP请求后,会检查自己的IP地址是否与ARP请求中的目标IP地址匹配。如果匹配,说明该主机是目标主机,它将发送一个ARP响应给主机A,包含自己的IP地址和MAC地址。
- 主机A收到ARP响应后,将目标主机的IP地址和MAC地址存储到ARP缓存表中,以便将来的通信使用。
- 主机A现在知道了目标主机的MAC地址,可以使用该地址发送数据包到目标主机。
RARP 协议:RARP 协议(Reverse ARP,反向 ARP 协议)的功能是将 MAC 地址解析为对应的 IP 地址。
TCP 与 UDP
UDP 头部结构
- 源端口:16 位,表示发送端端口。
- 目的端口:16 位,表示接收端端口。
- 长度:16 位,表示 UDP 数据报整体长度。UDP 头部最小为 8 字节。
- 校验和:16 位,用于校验 UDP 头部和数据。
TCP 头部结构

32位序号(sequence number):一次TCP通信(从TCP连接建立到断开)过程中某一个传输方向上的字节流的每个字节的编号。序号值被系统初始化为某个随机值ISN(Initial Sequence Number,初始序号值)。
32位确认号(acknowledgement number):用作对另一方发送来的TCP报文段的响应。其值是收到的TCP报文段的序号值加1。
4位头部长度(header length):标识该TCP头部有多少个32bit字(4字节)。
标识位:
- URG标志,表示紧急指针(urgent pointer)是否有效。
- ACK标志,表示确认号是否有效。称携带ACK标志的TCP报文段为确认报文段。
- PSH标志,提示接收端应用程序应该立即从TCP接收缓冲区中读走数据,为接收后续数据腾出空间。
- RST标志,表示要求对方重新建立连接。称携带RST标志的TCP报文段为复位报文段。
- SYN标志,表示请求建立一个连接。称携带SYN标志的TCP报文段为同步报文段。
- FIN标志,表示通知对方本端要关闭连接了。称携带FIN标志的TCP报文段为结束报文段。
16位窗口大小(window size):是TCP流量控制的一个手段。这里说的窗口,指的是接收通告窗口(Receiver Window,RWND)。
16位校验和(TCP checksum):由发送端填充,接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。
16位紧急指针(urgent pointer):是一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。
选项字段40字节:最大报文段长度(Max Segment Size,MSS),通常将MSS设置为(MTU-40)字节,(减掉的这40字节包括20字节的 TCP头部和20字节的IP头部),MTU为帧的最大传输单元。对以太网而言,MSS值是 1460(1500-40)字节。
RST 产生复位报文段的3种情况:
- 访问不存在的端口
- 异常终止连接
- 处理半打开连接
TCP 与 UDP 区别?
| 对比项 | TCP | UDP |
|---|---|---|
| 连接 | 面向连接,传输前需要建立连接 | 无连接,发送前不需要建立连接 |
| 通信方式 | 点对点,一条连接只有两个端点 | 支持一对一、一对多、多对一、多对多 |
| 可靠性 | 可靠交付,保证不丢失、不重复、按序到达 | 尽最大努力交付,不保证可靠性 |
| 流量控制/拥塞控制 | 支持流量控制和拥塞控制 | 不支持 |
| 数据边界 | 面向字节流,没有消息边界 | 面向报文,保留消息边界 |
| 首部开销 | 至少 20 字节 | 8 字节 |
| 典型场景 | 文件传输、HTTP、邮件等可靠传输场景 | 直播、语音、DNS 等对实时性要求高的场景 |
TCP 建立连接(三次握手)

Client将标志位SYN置为1,随机产生一个值seq=J,并将该数据包发送给Server,等待Server确认。此时客户端进入SYN-SENT(同步已发送) 状态。
- SYN报文段**(即SYN=1的报文段)不能携带数据**,但要消耗一个序号
Server收到数据包后由标志位SYN=1知道Client请求建立连接,Server将标志位SYN和ACK都置1,ack=J+1,随机产生一个值seq=K,并将该数据包发给Client以确认连接请求。这时TCP服务器进行进入SYN-RCVD(同步收到)状态。
- 同理,此报文段也不能携带数据。
Client收到确认后,检测ack是否为J+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=K+1,并将该数据包发送给Server。完成三次握手,客户端进入ESTABLISHED(已建立连接)状态。当服务器收到客户端的确认后,也进入ESTABLISHED(已建立连接)状态。
- TCP标准规定,ACK报文段可以携带数据,但如果不携带数据则不消耗序号
ISN(Initial Sequence Number)初始序号是动态生成的。
TCP 关闭连接(四次挥手)

客户端向服务器发送一个FIN报文,首部的FIN=1,同时报文给自己指定一个序号(m),此时客户端进入FIN_WAIT_1 (终止等待1)状态,但客户端依然可以接收服务器发送来的数据。
- TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
服务端收到了客户端的FIN报文,会发送ACK报文进行确认,把收到报文的序列号的值+1(m+1)作为ACK报文的序列号的值,表明已经收到了客户端的报文,服务器进入CLOSE-WAIT(关闭等待)状态
- TCP服务器进程这时应通知高层应用程序,客户端到服务端这个方向的连接就释放了,此时TCP连接处于半关闭(HALF-CLOSE)状态,即客户端已经没有数据要发送了,但服务器若发送数据,客户端仍要接收。客户端收到服务端的确认后,进入FIN-WAIT-2(终止等待2)状态。等待服务端发出的连接释放报文段。
当服务器没有数据要发送了,也想要断开连接,会给客户端发送FIN报文,且指定一个序列号(n),服务器进入了LAST-ACK(最后确认)状态。
客户端收到FIN之后,一样会发送一个ACK报文作为应答,且把服务端的序号+1(n+1)作为自己ACK报文的序号。然后进入TIME-WAIT(时间等待)状态,等待2MSL(MSL:报文段最大生存时间),然后关闭连接。
为什么不能两次握手?
- TCP 是全双工通信,两次握手只能确定单向数据链路是可以通信的,并不能保证反向的通信正常
详细解释:
这个问题的本质是:在信道不可靠的情况下, 通信双发需要就某个问题达成一致. 需要几次通信?
对于此问题,无论在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足**"在不可靠信道上可靠地传输信息"**这一需求所导致的
具体来说:
- TCP连接的双方要确保各自的收发消息的能力都是正常的。
- 客户端第一次发送握手消息到服务端,服务端接收到握手消息后把ack和自己的syn一同发送给客户端,这是第二次握手,当客户端接收到服务端发送来的第二次握手消息后,客户端可以确认“服务端的收发能力OK,客户端的收发能力OK”,但是服务端只能确认“客户端的发送OK,服务端的接收OK”,
- 所以还需要第三次握手,客户端收到服务端的第二次握手消息后,发起第三次握手消息,服务端收到客户端发送的第三次握手消息后,就能够确定“服务端的发送OK,客户端的接收OK”,
- 至此,客户端和服务端都能够确认自己和对方的收发能力OK,TCP连接建立完成。
为什么需要四次挥手?
因为当处于LISTEN状态的服务器端收到来自客户端的SYN报文(客户端希望新建一个TCP连接)时,它可以把ACK(确认应答)和SYN(同步序号)放在同一个报文里来发送给客户端。但在关闭TCP连接时,当收到对方的FIN报文时,对方仅仅表示对方已经没有数据发送给你了,但是自身可能还有数据需要发送给对方,则等你发送完剩余的数据给对方之后,再发送FIN报文给对方来表示你数据已经发送完毕,并请求关闭连接,所以通常情况下,这里的ACK报文和FIN报文都是分开发送的。
TIME_WAIT 的作用
2MSL(MaximumSegment Life,报文段最大生存时间)
- 保证最后一次握手报文能到服务器,能进行超时重传。
- 2MSL 后,这次连接的所有报文都会消失,不会影响下一次连接。
缺点:
- 第一是内存资源占用,但不是很严重,基本可以忽略。
- 第二是对端口资源的占用,一个 TCP 连接至少消耗一个本地端口。端口资源也是有限的,一般可以开启的端口为 32768~61000 ,也可以通过net.ipv4.ip_local_port_range指定,如果 TIME_WAIT 状态过多,会导致无法创建新连接。
TCP 状态转移图

TCP 的可靠机制
TCP 超时重传
TCP可靠性中最重要的一个机制是处理数据超时和重传。TCP协议要求在发送端每发送一个报文段,就启动一个定时器并等待确认信息;接收端成功接收新数据后返回确认信息。若在定时器超时前数据未能被确认,TCP就认为报文段中的数据已丢失或损坏,需要对报文段中的数据重新组织和重传。
拥塞控制
包含四个部分慢启动(slow start)、拥塞避免(congestion avoidance)、快速重传(fast retransmit)和快速恢复(fast recovery)
SWND(Send Window,发送窗口 )、SMSS(Sender Maximum SegmentSize,发送者最大段大小)、接收通告窗口(RWND)、拥塞窗口(CongestionWindow,CWND)
**慢启动:**CWND将按照指数形式扩大。慢启动算法的理由是,TCP模块刚开始发送数据时并不知道网络的实际情况,需要用一种试探的方式平滑地增加CWND的大小。(cwnd *2)
**拥塞避免:**慢启动门限(slow start threshold size,ssthresh)。当CWND的大小超过该值时(一般设为65536),TCP拥塞控制将进入拥塞避免阶段,拥塞窗口的值不再指数上升,而是加法增加。(cwnd +1)
**快速恢复:**当发送方知道只是丢失了个别的报文段,不会启动慢开始算法,而是执行快恢复算法。将阈值设为当前窗口大小的一半,同时设置拥塞窗口为阈值的大小,然后执行拥塞避免算法。
**快速重传:**发送方只要一连收到3个重复确认,就知道接收方没有收到应当立即进行快重传,这样就不会出现超时。
如何判断拥塞?
- 传输超时,或者 TCP 重传定时器溢出,通常采用慢启动和拥塞避免。
- 接收到重复的确认报文段,通常采用快速重传和快速恢复。
TCP 粘包/拆包怎么解决?
一个完整的应用层消息可能会被 TCP 拆分成多个报文段发送,也可能多个小消息被合并到一次发送中。接收方从 TCP 流里读取数据时,如果没有明确的消息边界,就会出现粘包或拆包问题。
原因
- 应用程序一次写入的数据大于套接字发送缓冲区。
- TCP 按照 MSS 大小进行分段。
- 以太网 payload 大于 MTU 时,IP 层可能发生分片。
- TCP 是面向字节流的协议,本身不保留应用层消息边界。
解决方法
- 使用固定长度消息。
- 使用特殊分隔符,例如换行符。
- 在消息头中保存消息体长度,接收方先读消息头,再按长度读取完整消息。
- 使用已有应用层协议,让协议自身定义消息边界。
为什么 UDP 不粘包?
UDP 是面向报文的协议,应用层交给 UDP 的一段数据会作为一个独立数据报发送,接收端一次读取的也是一个完整数据报。因此 UDP 保留消息边界,一般不会出现 TCP 那种粘包问题。
从协议头也能看出来:UDP 头部有长度字段,而 TCP 面向字节流,头部并不记录应用层消息长度。
HTTP
HTTP 协议是 Hyper Text Transfer Protocol(超文本传输协议)的缩写,用于在客户端和服务器之间传输超文本数据。
HTTP 采用请求/响应模型。客户端向服务器发送请求报文,请求报文一般包含请求行、请求头和请求体;服务器返回响应报文,响应报文一般包含状态行、响应头和响应体。
在浏览器输入 URL 到页面展示的过程?
大概过程:
- 浏览器向 DNS 服务器解析 URL 中的域名,得到对应 IP 地址。
- 根据 IP 地址和端口号与服务器建立 TCP 连接,HTTPS 还需要完成 TLS 握手。
- 浏览器发送 HTTP 请求。
- 服务器处理请求并返回 HTTP 响应。
- 浏览器解析 HTML、CSS、JavaScript 等资源。
- 浏览器构建 DOM、CSSOM,进行布局、绘制,最终展示页面。
细致过程(笔试原题,排序):
浏览器输入 URL,先解析 URL 地址是否合法。
浏览器检查是否命中缓存。如果命中且缓存有效,可以直接使用缓存资源。
在发送 HTTP 请求前进行 DNS 解析,获取服务器 IP 地址。
浏览器向服务器发起 TCP 连接,进行三次握手。
如果使用 HTTPS,还需要完成 TLS 握手。
握手成功后,浏览器向服务器发送 HTTP 请求。
服务器收到请求,处理后返回 HTTP 响应。
浏览器解析响应,如果响应可以缓存,则写入缓存。
浏览器继续请求 HTML 中引用的 CSS、JavaScript、图片等资源。
浏览器执行脚本、计算样式、布局和绘制,页面最终展示出来。
HTTP 请求方法

GET 和 POST 的区别?
GET 和 POST 都是 HTTP 请求方法,底层都可以通过 TCP 连接传输。区别主要来自语义约定、浏览器行为和服务器处理方式。
| 对比项 | GET | POST |
|---|---|---|
| 语义 | 获取资源 | 提交数据或产生副作用 |
| 参数位置 | 常见于 URL 查询参数 | 常见于请求体 |
| 缓存 | 更容易被浏览器或代理缓存 | 默认不适合缓存 |
| 幂等性 | 通常应当幂等 | 通常不要求幂等 |
| 浏览记录 | 参数可能保留在历史记录中 | 请求体一般不会出现在地址栏 |
| 数据长度 | 受浏览器、服务器、代理对 URL 长度的限制 | 主要受服务器配置限制 |
注意:网上常说“GET 产生一个 TCP 包,POST 产生两个 TCP 包”并不是 HTTP 规范要求,只是部分实现或场景下可能出现的行为,不能作为两者本质区别。
HTTP 状态码

HTTP 的无连接是什么意思?
早期 HTTP 的“无连接”通常指每次请求/响应结束后就断开 TCP 连接。HTTP 1.1 之后默认使用持久连接,可以在一个 TCP 连接上复用多个请求,因此更准确地说:HTTP 协议本身不要求长期保持连接,连接复用由具体版本和头部字段决定。
HTTP 的无状态是什么意思?
无状态是指 HTTP 协议本身不会记录上一次请求的上下文。服务器收到一次 HTTP 请求后,只根据当前请求生成响应;如果业务需要登录态、购物车等连续状态,需要借助 Cookie、Session、Token 等机制。
HTTP 1.0、HTTP 1.1、HTTP 2.0 的区别?
HTTP 1.0
- HTTP 1.0 默认使用短连接。浏览器每次请求通常都需要与服务器建立一次 TCP 连接,服务器完成响应后断开连接。
如果不想断开连接,需要在 HTTP 头部指定 Connection: keep-alive。
Connection: keep-aliveHTTP 1.1
- HTTP 1.1 默认使用持久连接,多个请求可以复用同一个 TCP 连接。
- 引入管道机制,客户端可以在同一个连接中连续发送多个请求。
- 管道机制下响应顺序必须和请求顺序一致,因此仍然可能出现队头阻塞问题。
HTTP 2.0
- HTTP 2.0 使用二进制分帧,把请求和响应拆成更小的帧进行传输。
- 支持多路复用,同一个连接上可以并发传输多个请求和响应,不需要严格按照请求顺序返回。
- 支持 Header 压缩,减少重复请求头带来的开销。
- 支持服务端推送,不过实际使用中需要结合业务场景判断是否适合。
HTTP 和 HTTPS 的区别?
HTTPS(Hyper Text Transfer Protocol Secure)可以理解为运行在 TLS/SSL 之上的 HTTP。它在 HTTP 的基础上增加了加密传输、身份认证和完整性校验。
HTTPS 采用混合加密机制:握手阶段使用非对称加密、密钥交换等机制协商对称密钥;通信阶段使用对称加密传输数据,以兼顾安全性和效率。
- **开销:**HTTPS 需要配置证书,并增加 TLS 握手和加解密开销。
- **端口不同:**HTTP 默认端口是 80,HTTPS 默认端口是 443。
- **安全性:**HTTP 明文传输,HTTPS 支持加密传输、身份认证和完整性校验。
- **资源消耗:**HTTPS 需要进行加解密计算,会消耗更多 CPU 和内存资源。
- **协议层次:**HTTP 和 HTTPS 都属于应用层协议。HTTPS 可以理解为 HTTP 运行在 TLS/SSL 之上,TLS/SSL 位于应用层协议和 TCP 之间。
HTTPS 优点
- HTTPS 传输数据过程中使用密钥进行加密,所以安全性更高
- HTTPS 协议可以认证用户和服务器,确保数据发送到正确的用户和服务器
HTTPS 缺点
**HTTPS 握手阶段延时较高:**在 HTTP 会话之前还需要进行 TLS 握手,因此连接建立阶段延时更高。
**HTTPS 部署成本高:**需要配置证书,同时加解密会占用更多计算资源。
证书的核心作用是证明“这个公钥确实属于这个服务器”。浏览器会根据系统或浏览器内置的根证书,验证服务端证书是否由可信 CA 签发、域名是否匹配、证书是否过期或被吊销。
对称加密
加密与解密使用同样的密钥。对称加密效率较高,被广泛应用于各种加密协议,然而在通讯前需要将密钥发送给对方,容易导致密钥泄漏。
非对称加密
非对称加密使用了一对密钥:公钥和私钥。私钥只能由一方保管,不能外泄,而公钥则可以发给任何请求者。通过公钥加密的数据只能由私钥解开。相比对称加密而言,非对称加密是十分安全的,但是加密和解密效率却没有对称加密高。
HTTPS 的通信建立过程?

- 服务端需要配置合法的数字证书。
- 客户端向服务端发起 HTTPS 连接请求。
- 服务端返回数字证书,并在握手过程中提供用于协商密钥的信息。
- 客户端验证证书是否合法,包括 CA 签名、域名、有效期等。
- 验证通过后,客户端和服务端通过 TLS 握手协商出对称密钥。
- 后续 HTTP 数据使用协商出的对称密钥进行加密传输。
什么是数字签名?
数字签名用于证明数据没有被篡改,并证明数据确实来自持有私钥的一方。
一般过程是:发送方先对原始数据计算摘要,再用私钥对摘要进行签名;接收方用发送方的公钥验证签名,并重新计算摘要进行对比。如果验证通过,说明数据完整性和发送方身份都可信。
什么是数字证书?
数字证书用于把服务器身份和公钥绑定起来。证书中包含域名、证书持有者、公钥、签发机构、有效期等信息,并由 CA 使用私钥签名。
浏览器拿到证书后,会用可信 CA 的公钥验证证书签名。如果验证通过,就可以相信证书中的公钥确实属于目标服务器,从而避免中间人替换公钥。
其他
Session 和 Cookie 的区别?
Cookie 的工作原理
- 浏览器第一次向服务器发送请求。
- 服务器通过响应头设置 Cookie。
- 浏览器保存 Cookie。
- 浏览器之后访问同一站点时,会自动携带符合条件的 Cookie。
- 服务器根据 Cookie 中的信息识别用户或维护状态。
Cookie 用途
- 会话状态管理(如用户登录状态、购物车、游戏分数或其它需要记录的信息)
- 个性化设置(如用户自定义设置、主题等)
- 浏览器行为跟踪(如跟踪分析用户行为等)
Session 的工作原理
- 浏览器第一次向服务器发送请求。
- 服务器创建 Session,并生成一个 Session ID。
- 服务器把 Session ID 通过 Cookie 返回给浏览器。
- 浏览器后续请求会携带这个 Session ID。
- 服务器根据 Session ID 查询服务端保存的 Session 数据。
区别:
| 对比项 | Cookie | Session |
|---|---|---|
| 存储位置 | 浏览器端 | 服务器端 |
| 安全性 | 数据在客户端,容易被查看或篡改,需要签名、加密、HttpOnly、Secure 等保护 | 数据在服务端,相对更安全 |
| 性能开销 | 每次请求都会携带,过大会增加网络开销 | 占用服务器存储资源 |
| 存储大小 | 单个 Cookie 通常约 4KB | 理论上受服务器资源限制 |
| 常见用途 | 保存少量状态、偏好设置、Session ID | 保存登录状态、用户会话数据 |
什么是 SQL 注入?举个例子
SQL 注入就是把恶意 SQL 片段插入到表单输入、URL 参数或请求体中,使服务器拼接出非预期的 SQL 语句,最终执行攻击者想要的数据库操作。
SQL 注入攻击的总体思路
- 寻找可能拼接 SQL 的输入位置。
- 判断服务器类型和数据库类型。
- 根据数据库特性构造注入语句。
例子:
user: ' or 1 = 1 --
pwd:
String sql = "select * from user_table where username='" + userName + "' and password='" + password + "'";
SELECT * FROM user_table WHERE username='' or 1 = 1 --' and password=''应对方法
- 参数绑定
- 过滤或校验传入参数。
- 避免把用户输入直接拼接进 SQL 字符串。
MTU 和 MSS 分别是什么?

MTU:Maximum Transmission Unit,最大传输单元,表示数据链路层一次能够传输的最大数据帧载荷大小。以太网常见 MTU 为 1500 字节。
IP 分片用于解决不同物理网络 MTU 不一致造成的传输问题。
MSS:Maximum Segment Size,最大报文段长度,表示 TCP 单个报文段中应用层数据的最大长度。常见情况下:
IPv4 头部通常 20 字节,TCP 头部通常 20 字节,因此以太网 MTU 为 1500 字节时,常见 MSS 为 1460 字节。
DDoS 攻击?
DDoS(Distributed Denial of Service,分布式拒绝服务)攻击是指攻击者控制大量主机同时向目标服务发送请求,耗尽目标的带宽、连接数、CPU 或内存资源,使正常用户无法访问服务。
以 SYN Flood 为例:客户端不断向服务器发送 SYN 报文,服务器回复 SYN-ACK 后等待客户端 ACK。如果攻击者不完成第三次握手,服务器会维持大量半连接状态,最终可能导致正常连接无法建立。
常见防护方式:
- 限制同时打开的 SYN 半连接数量。
- 缩短 SYN 半连接超时时间。
- 开启 SYN Cookie。
- 关闭不必要的服务,减少暴露面。
- 使用高防服务、流量清洗或限流策略。