TCP 是用来解决什么问题？
- 标签：网络
🏛 业务架构师
TCP 解决的核心问题：在不可靠的 IP 网络上构建可靠、有序、按节奏的传输通道。
IP 层的现实：包会丢、会乱序、会重复、会坏，网络拥塞谁也不管。TCP 用一套机制把它变成"看起来像专线"：
- 可靠性：序号 + 确认 + 超时重传——丢包自动补发；
- 有序性：序号重组——乱序到达按序交付；
- 完整性：校验和——损坏被丢弃重传；
- 流量控制：滑动窗口——不淹没慢接收方；
- 拥塞控制：慢启动、拥塞避免、快重传——不压垮网络本身，全网公平共享带宽；
- 连接管理：握手建立双方共识，挥手有序释放。
业务视角的意义：交易敢跑在互联网上的前提。没有 TCP，应用要自己处理"支付请求可能丢了、订单数据可能乱序"——每个业务都要重新发明可靠性。TCP 把这些一次性解决，HTTP、数据库连接、RPC 全部踩在它的肩膀上——它是"不可靠世界上批发确定性"的基础设施。
代价与使用智慧：可靠不等于快——重传、排队、握手都有延迟成本。业务的协议选择就是在"可靠"与"实时"之间排序：
- 要"对"：交易、支付、文件 → TCP；
- 要"快"（偶尔丢一帧无所谓）：语音、视频、游戏心跳、设备状态上报 → UDP（应用层按需补可靠，或 QUIC 折中）。
工程实践提醒：跨机房专线抖动时 TCP 重传风暴会放大流量（超时重传叠加业务重试）——业务层重试预算与 TCP 层重传要统筹，别让两层重试相乘把下游打爆。一句话：TCP 用复杂性换来"数据的确定性"，业务的一切承诺都建立在这份确定性之上。
🏗 系统架构师
TCP 解决的是IP 层"尽力而为、不可靠"传输之上，构建端到端可靠、有序、按需交付的字节流服务。IP 只承诺把包尽量送到：会丢、会乱、会重复、会损坏，且不管带宽公平。TCP 在两端补齐这些能力：
- 可靠性：序列号 + 确认应答（ACK）+ 超时重传（RTO 自适应）+ 快速重传（3 个重复 ACK），丢包自动补；
- 有序性：序列号排序，接收端重组乱序报文，应用读到的永远是字节流顺序；
- 流量控制：滑动窗口（接收方通告 rwnd），发送不超出对端缓冲区能力——保护接收方；
- 拥塞控制：慢启动、拥塞避免、快速恢复（cwnd 动态调整），感知网络拥塞主动降速——保护网络，也保公平性；
- 连接管理：三次握手建立状态同步、四次挥手优雅关闭、keepalive 探活；
- 字节流语义：无消息边界（应用层自己拆包）、全双工、点对点。
架构视角：TCP 是"端到端原则"的经典实践——复杂性放在网络边缘（两端主机），网络核心保持简单。这个原则指导了整个互联网设计，也影响我做系统设计：中间件（网关/MQ/代理）保持轻转发，可靠性与语义放服务两端，体系扩展性最好。UDP 则把选择权还给应用（QUIC、WebRTC、游戏都基于它自定义可靠性），这是另一条路线。
💻 全栈开发专家
TCP 解决"IP 之上如何不可靠网络里做可靠传输"的问题。
IP 层只承诺"尽力而为"：可能丢包、乱序、重复、出错，也不保证带宽公平。TCP 在其上补齐一整套机制：
- 可靠传输：序列号 + 确认应答（哪些字节收到了）+ 超时重传 & 快速重传（丢了补发）+ 校验和（错了丢弃）。
- 有序：按序列号重组，应用层读到的永远是字节流顺序。
- 流量控制：滑动窗口，发送速率匹配接收方缓冲能力，不打爆慢端。
- 拥塞控制：慢启动/拥塞避免/快速重传/快速恢复，感知网络拥塞主动降速——对网络整体公平，避免拥塞崩溃。
- 连接管理：三次握手/四次挥手，为双向可靠流建立和释放状态。
一句话：TCP 给应用提供了一条"像水管一样的可靠字节流"，应用不用操心丢包乱序。
工程联想（拉开差距）：
- 为什么音视频/游戏反而用 UDP：实时性 > 完整性，等重传不如丢掉下一帧；WebRTC/QUIC 在 UDP 上自建"可调的可靠性"；
- "TCP 保活"不等于应用层可用：连接 ESTABLISHED 但对端进程假死，必须心跳探测；
- 我排查过的"长连接断开重连风暴"，本质就是没处理好 TCP 层保活与应用层心跳的关系。