计算机网络篇1:OSI + HTTP进化史 + 三次握手四次挥手

一、osi模型

主要的三大层：

应用层 (Application Layer) ：这里的"居民"是我们熟悉的 HTTP, HTTPS, DNS。它们负责直接为用户的应用服务。
传输层 (Transport Layer) ：这里的"搬运工"是 TCP 和 UDP。它们负责端到端的数据传输（管发不管送达是 UDP，使命必达是 TCP）。
网络层 (Network Layer) ：这里的核心是 IP。负责寻址和路由，告诉数据包该往哪走。

二、http和https

HTTP 协议的发展，本质上是减少延迟 (Latency) 和 提高带宽利用率 的历史。

1. HTTP/1.0 vs HTTP/1.1：短连接到长连接

HTTP/1.0 (短连接)：每次请求都要新建一个 TCP 连接，发完就断。就像送快递，送一个包裹就得重新打一次电话叫快递员，效率极低。
HTTP/1.1 (长连接 Keep-Alive) ：引入了长连接。快递员送完一个包裹后不走，继续等待下一个包裹。
- 痛点：虽然连接复用了，但请求必须排队（串行）。如果前面的请求（大文件）处理慢，后面的请求（小数据）就得干等。这就是 应用层的队头阻塞 (Head-of-Line Blocking)。

2. HTTP/1.1 vs HTTP/2.0：从"串行"到"并行"

为了解决阻塞，HTTP/2.0 带来了革命性的改变：

多路复用 (Multiplexing) ：不再按顺序排队，而是将数据切成二进制帧。所有请求和响应的帧在同一个 TCP 连接中乱序混发，接收端根据 ID 重新组装。
头部压缩 (HPACK)：使用字典压缩 Header，不再重复发送 User-Agent 等冗余信息。
痛点：虽然应用层不堵了，但底层还是 TCP。TCP 的队头阻塞依然存在------一旦发生丢包，TCP 协议会强行暂停所有数据流，等待重传。

3. HTTP/3.0：从TCP到UDP

既然 TCP 太死板，HTTP/3.0 直接抛弃 TCP，改用基于 UDP 的 QUIC 协议。

0-RTT 建连：极速建立连接。
连接迁移：基于 ID 识别连接，网络从 WiFi 切到 4G 不断线。
彻底解决阻塞：不同数据流互不干扰，丢包只重传丢失的部分。

4. 关于 HTTPS：更安全

HTTP 是明文传输（裸奔），HTTPS 则是 HTTP + SSL/TLS。

核心逻辑 ：非对称加密 （RSA/ECC）用于安全的交换密钥，对称加密 （AES）用于快速传输数据。对称密钥就是加密解密同一把钥匙，非对成就是公钥加密，私钥解密。
流程简述：客户端索要证书 -> 验证证书 -> 算出随机密钥 -> 用公钥加密发给服务端 -> 双方达成共识，后续用随机密钥进行加密通信。

三、TCP 的核心 ------ 握手与挥手（重点）

前置知识

在研究三次握手之前，我们必须先看懂 TCP 报文格式包括里面的四个核心字段。它们决定了连接的状态和数据的顺序。

a. 序号 (Sequence Number, 简称 seq)

是什么：它是一个 32 位的数字。
作用：给数据编号 。TCP 是面向字节流的，为了解决乱序问题，发送出去的每一个字节都有一个编号。
通俗理解：就像你写一本 1000 页的书寄给朋友。
- 第一页的 seq = 1
- 第二页的 seq = 2
- ...
- 这样朋友收到后，即使纸张乱了，看页码（seq）也能重新排好序。
注意：为了安全（防止黑客伪造），最开始的序号（ISN）通常不是从 0 或 1 开始，而是随机生成的。

b. 确认号 (Acknowledgment Number, 简称 ack)

是什么：它也是一个 32 位的数字。
作用：告诉对方"我想要什么"。
核心逻辑 ：ack = N 表示 "N 序号之前的所有数据我都收到了，下一次请你从 N 开始发"。
通俗理解 ：朋友收到了前 10 页，他回复你 ack = 11。意思是："前 10 页都齐了，快把第 11 页发过来"。

c. 标志位：SYN (Synchronize)

是什么：一个开关（Bit）。
作用：发起新连接。
场景：当 SYN=1 时，说明这是一个"请求建立连接"的包。

d. 标志位：ACK (Acknowledgment)

是什么：也是一个开关（Bit）。
作用：确认收到。
场景：只要连接建立后，所有传输的数据包 ACK 开关都必须推上去（置为 1），否则传输无效。

TCP 是面向连接的、可靠的传输协议。它的可靠性体现在：我知道你知道了。

1. 三次握手 (Three-Way Handshake)

建立连接的过程，就是确认双方发送和接收能力的过程。

第一次 (SYN) ：客户端发包。含义："我是客户端，我想连你，我的初始序号是 X。"（客户端处于 SYN_SENT）
第二次 (SYN + ACK) ：服务端回复。含义："收到 X 了（ACK=X+1）。我是服务端，我也想连你，我的初始序号是 Y。"（服务端处于 SYN_RCVD）
第三次 (ACK) ：客户端回复。含义："收到 Y 了（ACK=Y+1）。连接建立，可以发数据了。"（客户端处于 ESTABLISHED）

为什么是三次？不是两次？
我们三次握手的目的是要让客户端和服务端都知道：自己和对方都可以发送和接收，而如果没有第三次握手的话，服务端它是不知道syn和ack是不是送到的，也就是它不能确定自己是不是发成功了，也不知道客户端是不是接收成功了。

案例：帮助理解

cpp 复制代码

目标：凑齐 4 张拼图
客户端能发？

服务端能收？

服务端能发？

客户端能收？

我们来看看，如果是两次握手，这 4 张拼图能凑齐吗？

第一步：客户端 -> 服务端 (SYN)
动作：客户端发包，服务端收到了。

服务端心想：

"好的，我收到了你的信。" -> 证明了：客户端能发 (√)，服务端能收 (√)。

缺憾：此时，客户端什么都不知道。

第二步：服务端 -> 客户端 (SYN + ACK)
动作：服务端回信，客户端收到了。

客户端心想：

"太好了！既然我收到了回信，说明我的信你收到了，你的信我也收到了。"

证明了：服务端能收 (√)，服务端能发 (√)，客户端能发 (√)，客户端能收 (√)。

结论：对于客户端来说，两次握手后，它手里的 4 张拼图已经全齐了！ 它知道连接是通的。

关键问题来了：此时服务端的视角
在发完第二步（SYN+ACK）之后，如果只有两次握手（没有第三步）：

服务端心想：

"我把回信发出去了，但是......他收到了吗？"

"如果他没收到，那我发的数据岂不是都石沉大海了？"

"我现在只知道'他能发'，但我完全不知道'他能不能收'！"

你看，对于服务端来说，拼图缺了两块：

服务端能发？（服务端自己不知道发出去能不能到）

客户端能收？（服务端不知道客户端耳朵好不好使）

第三步：客户端 -> 服务端 (ACK)
动作：客户端回一句："我收到你的确认了"。

服务端心想：

"Nice！他收到我的回信了！"

补齐最后两块拼图：证明了 服务端能发 (√)，客户端能收 (√)。

造成的问题：僵尸请求问题

2. 四次挥手 (Four-Way Wave)

断开连接时，由于 TCP 是全双工（双向）的，需要双方分别关闭自己的通道。

第一次 (FIN) ：客户端说："我没数据发了，我要挂了。"（客户端进入 FIN_WAIT_1）
第二次 (ACK) ：服务端说："知道你要挂了，但我还有数据没发完，你先等着。"（服务端进入 CLOSE_WAIT，客户端进入 FIN_WAIT_2）
- 此时，客户端 -> 服务端的通道关闭，但服务端 -> 客户端依然畅通。
第三次 (FIN) ：服务端数据发完了，说："好了，我也没数据了，我也挂了。"（服务端进入 LAST_ACK）
第四次 (ACK) ：客户端说："好的，拜拜。"（客户端进入 TIME_WAIT）

为什么是四次？

其实最本质的原因是tcp是全双工的。

因为服务端的 ACK（确认收到客户端的关闭请求）和 FIN（服务端自己的关闭请求）通常不能合并发送。中间那段时间服务端可能还在处理未发送完的数据。

3. 关键状态：TIME_WAIT

主动关闭连接的一方（通常是客户端），在发送完最后一个 ACK 后，必须等待 2MSL（报文最大生存时间的2倍）才能彻底释放资源。

为什么？
1. 防丢包：万一最后一个 ACK 丢了，服务端会重发 FIN。如果客户端早已关闭，服务端就会报错。2MSL 是为了兜底。
2. 防混淆：等待足够长的时间，让网络中所有残留的旧报文都自然消亡，避免影响新的连接。

总结

OSI/TCP 是架构基础。
HTTP 演进是为了更快（多路复用）和更强（QUIC）。
HTTPS 是为了更安全（混合加密）。
TCP 握手挥手 是为了保证在不可靠的网络中实现可靠的通信（序列号同步与确认机制）。