TCP

TCP 本身也是一个“协议”，而且是一个非常“厚”的传输层协议。

1.TCP 在网络模型中的位置

在 TCP/IP 模型里，TCP 是传输层协议，在 IP 之上、应用层之下：

• 应用层：HTTP、FTP、SSH、DNS 等（你要用的业务）
• 传输层：TCP、UDP（负责端到端传输）
• 网际层：IP（负责主机到主机的尽力而为转发）
• 网络接口层：以太网、Wi-Fi 等（负责真正物理传输）

所以从“封装关系”看：

• HTTP：应用层协议，定义“请求/响应长什么样”。
• TCP：传输层协议，定义“如何在一个不可靠的 IP 网络上，可靠地传输字节流”。
• IP：网络层协议，定义“如何把数据包从一端主机传到另一端主机”。

2.TCP 的核心特性：一句话版

TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。

可以拆成几个关键词：

1. 面向连接：通信前要先“三次握手”建立连接，结束后“四次挥手”断开连接。
2. 可靠传输：保证数据无差错、不丢失、不重复、按序送达。
3. 面向字节流：把数据看成一连串字节，不保留“消息边界”。
4. 全双工：连接建立后，双方可以同时收发数据。
5. 流量控制和拥塞控制：防止发太快淹没接收方或堵死网络。

3.用一个比喻理解 TCP

如果用“寄快递”比喻：

• IP：快递公司，只负责把包裹从城市 A 运到城市 B，不保证不丢、不保证不烂、不保证一次到。
• TCP：一个负责调度+客服的系统：
  • 发货前：先和对方确认“你要不要收快递？能收多少？”（连接建立）。
  • 发货时：给每个包裹编号，记录发了几号、对方确认了几号，没确认就重发。
  • 对方仓库满了：通知你“先别发那么快”（流量控制）。
  • 路上堵车：自动减慢发货速度（拥塞控制）。
• HTTP：你们公司内部填的“发货单格式”（怎么写订单号、品名、数量等）。

4.TCP 主要机制一图看懂

下面这张流程图，把 TCP 的核心机制串在一起：

5.重点机制拆开讲一下

5.1 面向连接：三次握手 / 四次挥手

三次握手（建立连接）：

1. 客户端 -> 服务器：SYN=1, seq=x（请求建立连接）
2. 服务器 -> 客户端：SYN=1, ACK=1, seq=y, ack=x+1（同意并同步自己的序列号）
3. 客户端 -> 服务器：ACK=1, seq=x+1, ack=y+1（确认）

目的：

• 同步双方的初始序列号（ISN）；
• 确认双方的发送、接收能力正常。

四次挥手（断开连接）：

1. A -> B：FIN=1, seq=u（我没有数据要发了）
2. B -> A：ACK=1, ack=u+1（我知道了）
3. B -> A：FIN=1, seq=v（我也没有数据要发了）
4. A -> B：ACK=1, ack=v+1（我知道了）

因为是全双工，每个方向需要单独关闭，所以是四次。

5.2 可靠传输：序号+确认+重传

• 序列号（Sequence Number）：

TCP 给数据流中的每个字节编号，接收方根据序号排序、去重。

• 确认号（Acknowledgment Number）：

告诉对方“我期望下一个收到的字节序号是多少”，表示之前的字节都受到了。

• 超时重传：

发送数据后启动定时器，若在重传时间（RTO）内没收到 ACK，就重传该段。

• 快速重传：

收到 3 个重复的 ACK 时，立即重传对应的段，而不必等超时。

5.3 流量控制：滑动窗口

• 接收方在 ACK 中携带“窗口大小”，告诉对方：我当前还能接收多少字节。
• 发送方根据这个窗口控制发送速率，避免接收方缓冲区溢出。

简单理解：

接收方说“我只能再收 10KB 了”，发送方就只发 10KB，等新的窗口通知。

5.4 拥塞控制：防止网络被“打爆”

TCP 有一套拥塞控制算法：慢启动、拥塞避免、快速重传、快速恢复等。

核心思路：

• 一开始先慢慢发（慢启动），逐步增加发送窗口；
• 一旦检测到丢包（认为网络拥塞），就大幅减小窗口；
• 然后再线性增加（拥塞避免），避免再次拥塞。

目标是：在保证可靠性的前提下，尽量提高网络利用率，但又不能把网络压垮。

6.TCP 和 UDP 的对比（顺带提一下）

特性	TCP	UDP
连接	面向连接，三次握手/四次挥手	无连接
可靠性	可靠：确认、重传、序号、校验	不可靠，尽最大努力交付
顺序	保证按序到达	不保证顺序
流量/拥塞控制	有（滑动窗口、拥塞控制）	没有
传输方式	字节流，无消息边界	数据报，保留消息边界
典型应用	HTTP、SSH、FTP、邮件	DNS、直播、视频会议、游戏

7.和 HTTP 的关系

• HTTP：定义“请求行 + 头部 + body 的格式”，以及状态码、方法等语义。
• TCP：保证这一串 HTTP 报文能够可靠地从客户端传到服务器，不丢、不乱、不重复。
• IP：把 TCP 段打成 IP 包，在网络上一跳一跳传过去。

所以可以这样理解：

HTTP 是“上层业务协议”，TCP 是“下层可靠传输管道”，IP 是“负责真正投递的快递公司”。

HTTP

HTTP 是应用层协议，通常运行在 TCP（传输层）之上，利用 TCP 提供的可靠字节流传输来收发 HTTP 报文。

1.层次上看：HTTP在上，TCP在下

在 TCP/IP 模型里：

• 应用层：HTTP、FTP、SMTP 等
• 传输层：TCP、UDP
• 互联网层：IP
• 网络接入层：以太网、Wi-Fi 等

所以 HTTP 是“上层”，TCP 是“下层”，HTTP 把 TCP 当成“可靠的传输管道”来用。

可以简单理解为：

2.封装关系：HTTP报文→ TCP段→IP包

当浏览器发一个 HTTP 请求时，大致是这样“封装”的：

1. 浏览器构造 HTTP 请求（例如GET / HTTP/1.1+首部等）。
2. HTTP 报文交给传输层，使用 TCP：
   • TCP 加上自己的首部（源端口、目的端口、序号、确认号等），形成 TCP 段。
3. TCP 段交给网络层 IP：
   • IP 再加首部（源 IP、目的 IP 等），形成 IP 包。
4. IP 包再交给数据链路层和物理层，真正在网上传输。

所以从“数据封装”的角度看：

• HTTP 是“内容”：定义请求/响应的格式、方法、状态码、首部语义等，
• TCP是“快递公司”：负责把这段数据可靠地送到对方手里（不丢、不乱序、差错检测）等。

3.能不能说“HTTP 是 TCP 的封装”？

可以理解为：

• HTTP 使用 TCP 提供的服务；
• HTTP 报文作为 TCP 的“数据部分”，被 TCP 段封装。

但严谨一点说：

• HTTP 和 TCP 是两个不同层上的协议，不是“HTTP 是 TCP 的某个扩展”。
• HTTP 定义的是“应用层语义”（怎么表示请求、响应、资源等）；
• TCP 定义的是“传输层语义”（怎么建立连接、可靠传输、流量控制、拥塞控制等）。

4.一个细节：HTTP/3 不再直接跑在TCP上

有一个重要例外：

• HTTP/1.0、HTTP/1.1、HTTP/2：都是跑在 TCP 之上。
• HTTP/3：跑在 QUIC 之上，而 QUIC 是跑在 UDP 之上的传输层协议。

所以更精确的说法是：

HTTP 是应用层协议，传统上运行在 TCP 之上，但 HTTP/3 改为运行在 QUIC（基于 UDP）之上。

也就是说，HTTP 语义不变，只是底层“运输方式”从 TCP 换成了 QUIC。

5.总结一句

• HTTP 确实是“在 TCP 之上封装”出来的协议，用 TCP 做可靠传输。
• 不过从网络分层看，更严谨的说法是：HTTP 是应用层协议，TCP 是传输层协议，HTTP 利用 TCP 提供的可靠字节流服务来实现请求/响应模型，而 HTTP/3 则把这个“传输层”换成了 QUIC。