计算机网络篇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是不是送到的，也就是它不能确定自己是不是发成功了，也不知道客户端是不是接收成功了。

案例：帮助理解

目标：凑齐 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）