传输层协议：TCP的三次握手与四次挥手、UDP的特点、端口号的作用、流量控制与拥塞控制
传输层，说白了就是网络通信的「调度中心」。我做了这么多年系统，发现很多人把TCP和UDP搞混，其实它们俩的定位完全不同。一个像快递员，一个像飞鸽传书。今天咱们就把这块彻底捋清楚。
一、TCP的三次握手：建立连接的那点事
TCP是面向连接的协议。什么叫「面向连接」？就是通信前，双方得先打个招呼，确认彼此都在线。这个打招呼的过程，就是三次握手。
我习惯用一个比喻来理解：
- 第一次握手：客户端说「嘿，你在吗？」（发送SYN包）
- 第二次握手：服务端回「在呢，你找我啥事？」（发送SYN+ACK包）
- 第三次握手：客户端说「没事，确认你在就行，咱们开始聊吧」（发送ACK包）
你想想看，为什么非得三次？两次不行吗？嗯，这里有个关键点：防止已失效的连接请求突然传到服务端。我在项目中遇到过这种情况——客户端发了个连接请求，网络卡了，它以为没发出去，又发了一个。结果第一个请求延迟到达，服务端以为是新连接，就回复了ACK。如果只有两次握手，服务端就直接建立连接了，白白浪费资源。三次握手能确保双方都确认了对方的接收能力。
核心要点：三次握手本质上是双方互相确认「我能发，你能收」的过程。
二、四次挥手：好聚好散的艺术
断开连接比建立连接多一次，一共四次。为什么？因为TCP是全双工的，两边都能独立地关闭自己的数据流。
流程是这样的：
- 客户端说「我发完了，准备关了」（发送FIN包）
- 服务端回「收到，但我还有数据没发完」（发送ACK包）
- 服务端发完数据后说「我也发完了，可以关了」（发送FIN包）
- 客户端回「好的，确认关闭」（发送ACK包）
我曾经踩过一个坑：服务端在收到客户端的FIN后，没有及时发送自己的FIN，导致客户端一直处于TIME_WAIT状态。嗯，这个TIME_WAIT状态会持续2MSL（最大报文段生存时间），如果并发高，端口就被占满了。避坑指南：服务端收到FIN后，尽快处理完剩余数据并发送FIN。
注意：TIME_WAIT状态不是bug，是TCP为了保证可靠性的设计。但高并发场景下，要关注端口耗尽问题。
三、UDP的特点：简单粗暴，但快
UDP和TCP完全是两个路子。TCP追求可靠，UDP追求速度。UDP的特点就四个字：无连接、不可靠。
- 无连接：发数据前不用握手，直接扔出去
- 不可靠：不保证数据到达，不保证顺序，不保证不重复
- 头部开销小：UDP头部只有8字节，TCP是20字节
- 支持广播和多播：TCP只能一对一，UDP可以一对多
我个人的经验是：实时性要求高的场景，用UDP。比如视频通话、在线游戏、DNS查询。丢一帧画面没关系，但卡顿就受不了。你想想看，视频通话如果用TCP，丢包了还要重传，画面反而更卡。
技巧：如果要在UDP上实现可靠性，可以在应用层自己做确认和重传。很多游戏引擎就是这么干的。
四、端口号的作用：门牌号
端口号，说白了就是区分不同应用程序的标识。一台服务器上跑着Web服务、邮件服务、数据库服务，它们都用同一个IP地址。怎么区分？靠端口号。
| 端口范围 | 类别 | 示例 |
|---|---|---|
| 0-1023 | 知名端口 | HTTP(80)、HTTPS(443)、SSH(22) |
| 1024-49151 | 注册端口 | MySQL(3306)、Redis(6379) |
| 49152-65535 | 动态/私有端口 | 客户端临时使用 |
我记得有一次排查问题，发现服务连不上数据库。查了半天，原来是数据库端口被防火墙封了。嗯，端口号虽小，但配置错了就是大问题。
五、流量控制与拥塞控制：别把网络撑爆了
这两个概念经常被混为一谈，其实它们解决的是不同的问题。
流量控制：管好接收方
流量控制是防止发送方太快，接收方来不及处理。TCP用滑动窗口机制来实现。接收方告诉发送方「我的缓冲区还剩多少空间」，发送方根据这个窗口大小调整发送速度。
我见过一个案例：接收方处理能力弱，发送方一股脑发数据，结果接收方缓冲区溢出，数据全丢了。后来加了流量控制，问题就解决了。
拥塞控制：管好网络
拥塞控制是防止网络中间节点（路由器、交换机）过载。TCP有四种算法：
- 慢启动：刚开始发送时，慢慢增加发送量，探测网络容量
- 拥塞避免：达到阈值后，线性增长，避免突然拥塞
- 快速重传：收到三个重复ACK，立即重传，不等超时
- 快速恢复：重传后，降低发送速度，但不用回到慢启动
你想想看，如果所有人都用最大速度发数据，网络早就瘫痪了。拥塞控制就是让大家都「悠着点」。
一句话总结：流量控制管「接收方能不能接住」，拥塞控制管「网络能不能扛住」。
六、知识体系图
下面这张图展示了传输层协议的核心逻辑关系：
这张图把传输层的核心要素都串起来了。TCP和UDP是两条路，端口号是它们的门牌，流量控制和拥塞控制是TCP的「刹车系统」。