你用微信发一张照片，对方几乎总能完整收到——没缺角、没花屏、没重复。这背后不是运气好，而是传输层在默默扛事。
靠确认+重传，像快递签收
TCP 发一个数据包，不是发完就不管了。它会等对方回个“已收到”（ACK）。比如你发了序号为 100 的包，对方收到后立刻回一个 ACK=101（意思是“100 及之前都收到了，下个请发 101”）。如果发出去 1 秒内没等到 ACK，TCP 就自动重发。这就像你寄快递，没收到签收单就再寄一次，直到对方确认为止。
用序号和校验，防乱序、防出错
每个 TCP 包都带一个序号（Sequence Number），像给信封编号：1、2、3……即使网络把第 3 封信先送到、第 2 封后到，接收方也能按序号重新排好队。同时，每个包还附带一个校验和（Checksum）——相当于给内容算了个“指纹”。接收方一核对，发现指纹对不上（比如某个字节传错了），就直接丢掉这个包，不给 ACK，逼发送方重发。
滑动窗口：不傻等，边发边收
如果每发一个包就死等 ACK，效率太低。TCP 用了“滑动窗口”机制：一次允许发多个包（比如 5 个），只要其中任意一个收到 ACK，窗口就往前滑，补发下一个。就像餐馆点菜，不用等第一道菜吃完才点第二道，而是端上两道、吃掉一道、立马再上一道，流水线跑起来。
超时重传不是瞎猜
重传等多久？TCP 不是固定等 1 秒或 2 秒。它实时测量每次发包到收 ACK 的时间（RTT），再算出动态的超时时间（RTO），网络快就等得短，网络卡就多等一会儿。这样既不浪费时间，也不至于过早重发造成拥堵。
连接建立和断开：三次握手和四次挥手
发数据前，双方先“约好”：客户端发 SYN，服务端回 SYN+ACK，客户端再回 ACK——三次握手成功，才开始传数据。断开时也一样讲规矩：一方发 FIN 表示“我发完了”，对方回 ACK 确认，等自己也发完再回 FIN，对方再 ACK。这套流程保证两端都清楚彼此状态，不会一边还在发、另一边已经关机了。
这些机制不是孤立的，它们拧成一股绳，让看似不可靠的网络，变得像邮局挂号信一样靠谱。