TCP 是用来解决什么问题从 IP 的不可靠到可靠的端到端通信01. 前言为什么有了 IP 还不够02. IP 协议的四大先天缺陷03. TCP 要解决的六大核心问题04. 问题一丢包 → 确认 超时重传4.1 问题描述4.2 TCP 的解决方案05. 问题二乱序 → 序列号 排序5.1 问题描述5.2 TCP 的解决方案06. 问题三重复 → 序列号去重6.1 问题描述6.2 TCP 的解决方案07. 问题四无连接 → 三次握手建立连接7.1 问题描述7.2 TCP 的解决方案三次握手08. 问题五收发速度不匹配 → 流量控制8.1 问题描述8.2 TCP 的解决方案滑动窗口09. 问题六网络拥堵 → 拥塞控制9.1 问题描述9.2 TCP 的解决方案拥塞控制算法10. 汇总TCP 解决的 6 个问题及对应机制11. 完整流程图从发送到接收TCP 解决了什么12. 哪些场景不需要 TCP为什么13. 总结The Begin点点关注收藏不迷路01. 前言为什么有了 IP 还不够互联网的底层是IP 协议Internet Protocol它负责将数据包从源主机发送到目标主机。但 IP 协议只提供“尽力而为”的服务——不保证数据包能到达、不保证顺序、不保证不重复。如果 IP 已经能把数据送到对方电脑为什么还需要 TCP因为现实网络中存在丢包、乱序、重复、拥塞、流量不匹配等问题。TCP 就是在 IP 的“不可靠”之上构建一个“可靠”的传输层协议。本文从 IP 的先天缺陷出发逐一分析 TCP 要解决的 6 大核心问题以及它如何解决。02. IP 协议的四大先天缺陷IP 层提供的是无连接、不可靠的数据报服务发送端 IP 层 网络 接收端 IP 层 │ │ │ │──── 包1 ────────│─────────────────→│ ✅ 可能到达 │──── 包2 ────────│───── ✗ 丢包 ─────│ ❌ 可能丢失 │──── 包3 ────────│─────────────────→│ ✅ 可能到达 │──── 包4 ────────│─────────→ 包4 │ ❌ 可能乱序包4比包3先到 │──── 包5 ────────│─────────────────→│ ❌ 可能重复网络重传导致IP 的问题具体表现丢包路由器拥塞、线路故障数据包被丢弃乱序不同路由路径导致后发的包先到达重复超时重传导致接收方收到同一数据包的多个副本无流量控制发送方太快会淹没接收方导致丢包无拥塞控制发送方太快会堵塞网络加剧丢包无连接概念每个包独立路由没有“会话”状态TCP 的目标在 IP 的这个“烂摊子”上为用户提供一个可靠的、有序的、不重复的、带流量控制和拥塞控制的字节流连接。03. TCP 要解决的六大核心问题┌─────────────────────────────────────────────────────────────────┐ │ TCP 要解决的问题 │ ├─────────────────────────────────────────────────────────────────┤ │ 1. 丢包问题 → 如何发现丢了丢了怎么办 │ │ 2. 乱序问题 → 如何把乱序的包排好队 │ │ 3. 重复问题 → 如何识别并丢弃重复包 │ │ 4. 连接性问题 → 如何让双方知道“我们在通信” │ │ 5. 流量控制问题 → 发送太快接收方处理不过来怎么办 │ │ 6. 拥塞控制问题 → 发送太快网络本身撑不住了怎么办 │ └─────────────────────────────────────────────────────────────────┘下面逐一分析每个问题的解决方案。04. 问题一丢包 → 确认 超时重传4.1 问题描述IP 网络不保证数据包一定能到达。路由器丢包、WiFi 干扰、线路故障随时可能丢包。4.2 TCP 的解决方案发送端 接收端 │ │ │──── 发送 数据包(seq100) ─────────────→│ │ │ │ 包丢失了 │ │ │ │ [超时定时器到期没收到 ACK] │ │ │ │──── 重传 数据包(seq100) ─────────────→│ │ │ │←────────────────────────── ACK(101) ───│核心机制确认应答ACK接收方收到数据后回复 ACK确认号 下一个期望的字节序号超时重传RTO发送方启动定时器超时未收到 ACK 则重传快速重传收到 3 个重复 ACK 时立即重传不等超时05. 问题二乱序 → 序列号 排序5.1 问题描述IP 路由是动态的包1 走拥堵路径晚到包2 走快速路径早到导致接收方先看到包2。发送顺序 包1(seq100) → 包2(seq200) → 包3(seq300) │ │ │ ▼ ▼ ▼ [慢路径] [快路径] [快路径] │ │ │ └──────┬───────┴───────┬──────┘ ▼ ▼ 接收顺序 包2(seq200) → 包3(seq300) → 包1(seq100)乱序5.2 TCP 的解决方案每个字节都有唯一的序列号Sequence Number。接收方维护一个重排序缓冲区接收方收到的包乱序 收到包2 (seq200, 100字节) → 存入缓冲区等待前面的数据 收到包3 (seq300, 100字节) → 存入缓冲区继续等待 收到包1 (seq100, 100字节) → 缺失的补齐了按顺序提交给应用 重排序后提交给应用 字节 100-199 → 字节 200-299 → 字节 300-399核心接收方只提交连续的、有序的数据给应用层乱序的数据暂存。06. 问题三重复 → 序列号去重6.1 问题描述发送方因超时重传了一个包但实际上原包并没有丢只是延迟到达导致接收方收到两个相同的包。发送端 接收端 │ │ │──── 发送 包(seq100) ─────────────────→│ ✅ 收到 │ ACK 在路上延迟了 │ │ │ │ [超时没收到 ACK] │ │ │ │──── 重传 同一个包(seq100) ───────────→│ ✅ 又收到一次 │ │ │←────────────────────────── ACK(200) ───│6.2 TCP 的解决方案接收方根据序列号识别重复包接收方逻辑 第一次收到 seq100100字节 存入缓冲区标记 100-199 已接收 第二次收到 seq100 检查序列号范围发现已经收过了 → 丢弃重复包 但还是要回复 ACK告诉发送方已收到避免继续重传07. 问题四无连接 → 三次握手建立连接7.1 问题描述IP 是无连接的每个数据包独立路由。但应用层需要一个“会话”概念——双方需要知道“我们正在通信”并初始化状态序列号、窗口等。7.2 TCP 的解决方案三次握手客户端 服务器 │ │ │────── 1. SYN (seqx) ─────────────────→│ 客户端我想建立连接我的初始序号是x │ │ │←──── 2. SYNACK (seqy, ackx1) ──────│ 服务器好的我的初始序号是y确认收到x │ │ │────── 3. ACK (acky1) ───────────────→│ 客户端确认收到你的序号y │ │ ▼ ▼ ESTABLISHED ESTABLISHED解决的问题双方确认对方存活且愿意通信同步初始序列号防止旧连接的历史包干扰新连接协商窗口大小等参数08. 问题五收发速度不匹配 → 流量控制8.1 问题描述发送方以 100MB/s 的速度发送接收方只能以 10MB/s 的速度处理。没有控制的话接收方缓冲区会溢出数据被丢弃。8.2 TCP 的解决方案滑动窗口接收方在 ACK 包中携带窗口Window字段告诉发送方“我的缓冲区还能接收 N 字节”。发送端 接收端 │ │ │←────────────────── ACK(1001, win1024)─│ 接收方我能再收1024字节 │ │ │──── 发送最多 1024 字节 ───────────────→│ 发送方好我只发你允许的量 │ │ │←────────────────── ACK(2049, win512)──│ 接收方处理了一些窗口变小了 │ │ │──── 发送最多 512 字节 ─────────────────→│ 发送方跟着降速效果发送速度自动匹配接收方的处理能力防止接收方被淹没。09. 问题六网络拥堵 → 拥塞控制9.1 问题描述即使接收方处理能力很强如果网络本身拥堵路由器队列满了发送太快会导致路由器丢包。9.2 TCP 的解决方案拥塞控制算法拥塞控制的核心维护一个 拥塞窗口cwnd实际发送量 min(接收窗口, 拥塞窗口) ▲ │ 拥塞窗口 │ /──────── 大小 │ / │ / │ / 拥塞避免阶段线性增长 │ / │ / 慢启动阶段指数增长 │/ └──────────────────────► 时间 丢包发生时窗口减半拥塞发生四大组件机制作用慢启动连接建立后从一个小窗口开始指数增长直到达到阈值拥塞避免达到阈值后线性增长每个 RTT 增加 1 个 MSS快速重传收到 3 个重复 ACK立即重传丢包不等超时快速恢复快速重传后窗口减半而不是回到 1避免过度降速10. 汇总TCP 解决的 6 个问题及对应机制问题IP 的行为TCP 的解决方案丢包不保证送达确认应答ACK 超时重传 快速重传乱序可能乱序到达序列号 重排序缓冲区重复可能重复到达序列号去重无连接每个包独立三次握手建立状态机 四元组标识连接速度不匹配无控制流量控制滑动窗口网络拥堵无控制拥塞控制慢启动 拥塞避免 快重传11. 完整流程图从发送到接收TCP 解决了什么应用层数据 │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ TCP 发送方 │ ├─────────────────────────────────────────────────────────────┤ │ 1. 将数据切成 MSS 大小的段 │ │ 2. 给每个字节编号序列号 │ │ 3. 根据 拥塞窗口 接收窗口 决定发送多少 │ │ 4. 发送数据同时启动重传定时器 │ │ 5. 收到 ACK → 确认送达窗口滑动继续发送 │ │ 6. 超时未 ACK 或 3 个重复 ACK → 重传 │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ IP 网络不可靠 │ ├─────────────────────────────────────────────────────────────┤ │ 可能丢包、乱序、重复、延迟 │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ TCP 接收方 │ ├─────────────────────────────────────────────────────────────┤ │ 1. 收到数据包根据序列号判断 │ │ - 重复 → 丢弃 │ │ - 乱序 → 放入重排序缓冲区 │ │ - 正好是期望的序号 → 交给应用并尝试从缓冲区取出连续数据 │ │ 2. 发送 ACK确认号 下一个期望的字节序号 │ │ 3. 通告自己的接收窗口还能收多少 │ └─────────────────────────────────────────────────────────────┘ │ ▼ 应用层收到有序、可靠、不重复的数据12. 哪些场景不需要 TCP为什么TCP 解决了可靠性问题但代价是延迟增加、吞吐量波动、头部开销大。场景用什么协议为什么不用 TCP实时视频/语音UDP丢几个包没关系延迟更致命DNS 查询UDP一个包搞定不需要连接开销游戏FPS/竞速UDP宁可丢包也不等重传体验优先内部高速传输RDMAInfiniBandTCP 内核开销太大HTTP/3QUICUDPQUIC解决 TCP 队头阻塞但又想有可靠性一句话需要可靠传输用 TCP需要低延迟、可容忍丢包用 UDP。13. 总结┌─────────────────────────────────────────────────────────────────┐ │ TCP 到底解决了什么问题一句话总结 │ ├─────────────────────────────────────────────────────────────────┤ │ TCP 在不可靠的 IP 网络上通过 │ │ 序列号 确认 重传 排序 去重 窗口 拥塞控制 │ │ 为用户提供了一个 │ │ 可靠的、有序的、不重复的、带流量控制和拥塞控制的 │ │ 双向字节流连接。 │ └─────────────────────────────────────────────────────────────────┘面试回答模板TCP 主要解决 IP 层的四大缺陷丢包、乱序、重复、无连接。通过确认重传解决丢包通过序列号解决乱序和重复通过三次握手建立连接。此外还通过滑动窗口解决流量控制问题通过拥塞控制解决网络拥堵问题。The End点点关注收藏不迷路