目录
[TCP 核心](#TCP 核心)
[TCP 是如何保证可靠传输的](#TCP 是如何保证可靠传输的)
[TCP 三次握手机制*](#TCP 三次握手机制*)
[TCP 为什么是三次握手*](#TCP 为什么是三次握手*)
[TCP 四次挥手的发起方](#TCP 四次挥手的发起方)
[TCP 四次挥手*](#TCP 四次挥手*)
[TCP 的流量控制（滑动窗口）](#TCP 的流量控制（滑动窗口）)
网络模型
ISO七层协议、以及协议当中的内容
OSI 七层模型是什么
OSI（开放式系统互联通信参考模型）是国际标准化组织制定的网络分层标准，目的是解决不同设备间的网络兼容性问题，实现跨设备通信。
它将网络通信从上到下分为 7 层（物数网传会表应）：
应用层 → 表示层 → 会话层 → 传输层 → 网络层 → 数据链路层 → 物理层
各层核心职能
- 应用层
- 核心作用：为具体应用程序提供数据传输接口，直接面向用户业务。
- 典型协议：HTTP、DNS、FTP、SMTP 等。
- 表示层
- 核心作用：负责数据格式转换（如二进制 / ASCII 码）、加密、压缩处理。
- 关键细节：解决乱码问题，这部分逻辑通常由开发者处理。
- 会话层
- 核心作用：建立、管理和终止客户端与服务端之间的通信会话，管理连接生命周期。（一般是客户端主动发起连接）
- 传输层
- 核心作用：负责端到端的数据传输，提供可靠 / 不可靠传输、流量控制能力。
- 典型协议：TCP（可靠传输）、UDP（不可靠传输）；负责端口寻址，将数据交给对应应用。
- 网络层
- 核心作用：选择最佳路由、规划 IP 地址，负责数据的转发与分片。
- 典型协议：IP、ICMP、ARP；解决跨网段的路径选择问题。
- 数据链路层
- 核心作用：将数据封装成帧，标记帧的起止，实现透明传输与差错校验，负责 MAC 寻址。
- 关键细节：主要用于局域网内设备寻址。
- 物理层
- 核心作用：定义网络设备接口、电气等硬件标准，负责在物理链路上传输比特流（0/1）。
TCP/IP模型
TCP/IP 是实际互联网使用的网络分层模型，是对 OSI 七层模型的简化实现，目的是让不同设备能高效互联通信。
它从上到下分为 4 层：
应用层 → 传输层 → 网络层（Internet 层）→ 网络接入层（链路层）
各层核心职能
1.应用层
- 核心作用：为最终用户 / 应用程序提供服务，处理数据编码、会话控制、业务逻辑。
- 典型协议：HTTP、HTTPS、SMTP、DNS、FTP 等。
- 对应 OSI：应用层 + 表示层 + 会话层。
- 传输层
- 核心作用：负责 端到端（主机到主机） 的数据传输，提供可靠 / 不可靠传输、流量控制。
- 典型协议：
- TCP：可靠传输，面向连接，保证数据有序不丢失；
- UDP：不可靠传输，无连接，速度快，适合实时场景。
- 对应 OSI：传输层。
- 网络层（Internet 层）
-
核心作用：负责数据包的寻址、路由、转发，确定数据在网络中的最佳传输路径。
-
典型协议：IP（IPv4/IPv6）、ICMP、ARP 等。
-
对应 OSI：网络层。
4.网络接入层（链路层 / 网络接口层
-
核心作用：控制硬件设备与物理介质，负责在物理链路中传输比特流（0/1），处理帧封装、MAC 寻址。
-
典型协议：以太网、Wi-Fi 等底层协议。
-
对应 OSI：数据链路层 + 物理层。
OSI 是理论上的概念分层，设计复杂且未提供具体实现方案；而 TCP/IP 模型将其简化为 4 层（应用层、传输层、网络层、网络接口层），更贴合实际互联网场景，是当前广泛使用的网络模型。
TCP 核心
TCP和UDP的区别
| 对比维度 | TCP | UDP |
|---|---|---|
| 连接性 | 面向连接，传输前必须建立连接 | 无连接，无需建立连接即可传输 |
| 通信方式 | 只能一对一通信 | 支持一对一、一对多、多对一、多对多 |
| 传输方式 | 面向字节流，无边界，保证顺序 | 面向报文（数据包），有边界，可能乱序 / 丢包 |
| 可靠性 | 可靠传输，数据无差错、不丢失、不重复、按序到达 | 不可靠传输，尽最大努力交付，不保证到达 |
| 流量 / 拥塞控制 | 有流量控制和拥塞控制机制 | 无，网络拥堵时也不降低发送速率 |
| 首部开销 | 首部最小 20 字节，最大 60 字节 | 首部固定 8 字节，开销极小 |
TCP 是如何保证可靠传输的
-
连接管理 ：通过三次握手 建立可靠连接，四次挥手释放连接，确保连接建立和断开的可靠性。
-
校验和：对 TCP 报文段进行校验，检测传输过程中的误码。
-
序列号 + 确认应答（ACK）：
- 对每个字节数据编号，保证数据有序、不重复、不丢失；
- 接收方收到数据后回传 ACK，告知发送方接收情况。
-
超时重传：若发送方在指定时间内未收到 ACK，判定数据包 / 确认包丢失，自动重发。
-
流量控制 ：通过滑动窗口机制，匹配接收方处理速度，避免接收缓冲区溢出导致丢包。
-
拥塞控制 ：通过慢开始、拥塞避免等算法，在网络拥堵时降低发送速率，防止网络崩溃。
-
最大消息长度（MSS）：连接时约定最大分段大小，以该单位重传，避免网络层分块。
TCP 三次握手机制*
核心目的：
建立可靠的全双工连接 ，三次交互，让客户端和服务器确认彼此「能发、能收」。即确认双方收发能力正常，并同步初始序列号（ISN）。
关键术语：
| 术语 | 含义 |
|---|---|
| SYN | 同步位，SYN=1 表示这是一个「连接请求」或「连接确认」报文 |
| ACK | 确认位，ACK=1 时确认号字段才生效 |
| seq | 本次发送的起始编号是 x（随机生成） |
| ack | 期望收到对方的下一个序列号（= 对方 seq + 1） |
核心流程：
初始状态
客户端和服务端默认都处于 CLOSED （关闭）状态，没有任何连接。
建立连接前：
服务端会先主动调用监听接口 （比如 listen()），将自己从 CLOSED （关闭）切换到 LISTEN（监听）状态，在指定端口等待客户端的连接请求。
客户端行为：
客户端保持 CLOSED 状态，直到需要发起连接时，才主动发送报文。也就是第一次握手。
1. 第一次握手（客户端 → 服务端） SYN 包
- 客户端发送
SYN=1（连接请求），seq=x（随机初始序列号） - 客户端状态变为
SYN_SENT（同步已发送） - 含义：我想连接你，同步我的序列号
x
2. 第二次握手（服务端 → 客户端） SYN+ACK 包
- 服务端回复
SYN=1（连接确认报文），ACK=1，seq=y（自己的随机序列号），ack=x+1（期望收到\的下一个序列号） - 服务端状态变为
SYN_RCVD（同步已收到） - 含义：我收到你的请求，同意连接；我也同步我的序列号
y
3. 第三次握手（客户端 → 服务端） ACK 包
- 客户端回复
ACK=1，ack=y+1（期望收到]的下一个序列号）、seq=x+1（自己的随机序列号） - 双方状态都变为
ESTABLISHED（连接已建立） - 含义：我确认收到你的序列号，连接正式建立，可以传输数据了
TCP 为什么是三次握手*
为什么不能是四次？
三次握手已经足够确认双向收发能力：
- 第一次：确认客户端能发
- 第二次：确认服务器能收、能发
- 第三次：确认客户端能收
四次握手只会增加连接建立时间，没有额外收益，完全冗余。
为什么不能是两次？
核心问题：「失效报文」导致服务器资源浪费
- 本质：两次握手无法确认客户端是否能收，服务器不知道自己的确认包有没有被客户端收到。
- 网络延迟时，客户端早已过期的连接请求可能在连接释放后才到达服务器。
- 两次握手下，服务器收到后会直接建立连接并等待数据，但客户端根本没发起新连接，不会发数据。
- 结果：服务器空等，浪费资源（半连接队列占满，易被 SYN Flood 攻击）。
TCP 四次挥手的发起方
TCP 四次挥手没有规定必须由谁发起，谁先不需要连接，谁就先发送 FIN 包。
在 HTTP 短连接场景下，通常是服务器先发起 （响应完就关）；在长连接场景下，客户端或服务器都可能先发起。
- HTTP/1.0 短连接：
设计就是 "一次请求 - 响应就断开"，所以服务器发完响应报文后，通常会主动发起关闭，这是最符合协议设计的行为。
- HTTP/1.1+ 长连接（keep-alive）：
连接会保持复用，谁先触发关闭条件，谁先发起：
- 浏览器关闭 / 页面跳转 → 客户端先发起；
- 服务器达到
keep-alive timeout空闲超时 → 服务器先发起； - 一方主动要求断开（比如
Connection: close头） → 谁带这个头谁先发起。
TCP 四次挥手*
核心目的：
安全断开 TCP 连接，确保双方数据都发送完毕，并确认彼此都同意关闭，避免数据丢失。
关键术语：
| 术语 | 含义 |
|---|---|
| FIN | 结束位，FIN=1 表示本方数据已发送完，请求断开 |
| ACK | 确认位，ACK=1 时确认号字段生效 |
| seq | 本机发送的序列号（非随机数，是当前发送数据的字节序号） |
| ack | 期望收到对方的下一个序列号（= 对方 seq + 1） |
核心流程：
初始状态
双方都处于 ESTABLISHED（已连接）状态。
**1. 第一次挥手（主动方 → 被动方）**FIN 包
- 主动方发送
FIN=1（请求关闭连接），seq=u（本次发送的序列号，非随机数） - 主动方进入
FIN_WAIT_1（终止等待 1）状态 - 含义：我没数据要发了，准备断开连接。
**2. 第二次挥手（被动方 → 主动方）**ACK 包
- 被动方回复
ACK=1，ack=u+1（期望下次收到的序列号），seq=v（本次发送的序列号） - 被动方进入
CLOSE_WAIT（关闭等待）状态；主动方进入FIN_WAIT_2（终止等待 2）状态 - 含义：我收到断开请求了，但我可能还有数据没发完，等我发完再告诉你。
**3. 第三次挥手（被动方 → 主动方）**FIN + ACK 包
- 被动方发完剩余数据后，发送
FIN=1, ACK=1（同意关闭），seq=w（本次发送的序列号），ack=u+1（期望下次收到的序列号） - 被动方进入
LAST_ACK（最后确认）状态 - 含义：我也没数据了，同意断开连接。
**4. 第四次挥手（主动方 → 被动方）**ACK 包
- 主动方回复
ACK=1，ack=w+1（期望下次收到的序列号），seq=u+1（本次发送的序列号） - 主动方进入
TIME_WAIT（时间等待）状态，等待 2MSL 后才进入CLOSED状态；被动方收到 ACK包 后直接进入CLOSED状态 - 含义：我确认收到，连接可以彻底关闭了。
为什么四次挥手*
TCP 连接是全双工的（即：客户端可以发，服务器也可以同时发）。
为了安全断开 TCP 连接，必须确保双方数据都发送完毕，并确认彼此都同意关闭，避免数据丢失。
流程对应
- 第一次：主动方发
FIN（已发完，我要断）。 - 第二次：被动方回
ACK（收到，等我发完）。 - 第三次：被动方发
FIN+ACK（已发完，我也断）。 - 第四次：主动方回
ACK（收到，确认关闭）。
为什么会有等待时间TIME_WAIT
核心原因
进入 TIME_WAIT 状态并等待 2MSL（最长报文寿命），主要有两个目的：
- 保证可靠关闭（重传机制）。
- 防止旧连接干扰新连接（防止乱码）。
详细阐述
-
保证 ACK 可靠到达（重传机制）：
主动方最后发送的 ACK 包可能丢失。根据 TCP 超时重传机制，如果被动方在 2MSL 内没收到 ACK，会超时重发 FIN 包。
主动方等待 2MSL，就是为了确认是否需要重传 。如果收到了被动方重发的 FIN，就立刻再次回复 ACK，确保对方最终能收到确认，安全关闭连接。
-
防止旧报文干扰新连接：
网络中可能存在迟到的旧数据包。等待 2MSL，能确保这些残留报文在网络中彻底消失。
这样当建立新连接时，就不会误把旧连接的数据包当成新数据，避免数据错乱。
TCP 的流量控制（滑动窗口）
核心概念
流量控制：让发送方根据接收方的实际接收能力，控制发送数据量，避免接收方缓冲区溢出导致丢包。
实现方式 ：通过 滑动窗口 机制实现。
核心流程
- 初始化窗口：三次握手时，双方协商初始窗口大小（如 400 字节），表示接收方最多能接收的数据量。
- 发送数据：发送方按窗口大小发送数据（如 200 字节），可用窗口随之减少。
- 接收方反馈窗口 ：
- 接收方处理数据后，每次返回 ACK 报文时，都会携带当前剩余的窗口大小（win），实时告知发送方自己还能接收多少数据。
- ✅ 关键：不是等缓冲区满了才反馈，而是每次 ACK 都要更新窗口大小，保证发送方实时感知接收方状态。
- 窗口为 0 时的处理 ：
- 若接收方窗口
win=0（缓冲区已满），发送方停止发送，并启动定时器。 - 定时器到期后发送试探报文，询问接收方是否有可用窗口。
- 若接收方回复
win>0（缓冲区已腾出空间），发送方恢复发送数据。
- 若接收方窗口