三亩地 三亩地SAN MU DI · CODE DIARY
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天,欢迎挑你感兴趣的翻一翻。

TCP 与 UDP:传输层的 “靠谱老大哥” 与 “闪电跑腿员”

TCP 与 UDP:传输层的 “靠谱老大哥” 与 “闪电跑腿员”

一、TCP:面向连接的 “可靠传输专家”

TCP 就像寄重要快递,会打电话确认对方收货,丢了还会重发,全程 “稳” 字当头。

1. 核心特性:

  • 面向连接:传输前必须 “三次握手” 建连接,结束后 “四次挥手” 断连接,像打电话 “喂 - 能听到 - 开始说” 和 “挂了啊 - 好的 - 真挂了 - 拜拜”。
  • 可靠传输:通过 “序列号 + 确认应答” 保证数据不丢、不乱。比如发送方发 1、2、3 号数据包,接收方收到 1 和 3,会回复 “确认收到 1,等 2”,发送方就重发 2。
  • 流量控制:接收方会告诉发送方 “我现在最多能收 1000 字节”,避免发送太快 “撑爆” 对方缓冲区,类似 “你慢点说,我记不过来了”。
  • 拥塞控制:如果网络堵车,TCP 会主动减速,等路况好再加速,防止 “添堵”,比如高速上堵车时大家会慢慢开。
  • 面向字节流:把数据当成连续的字节序列,没有 “数据包” 边界,接收方会按顺序拼接,适合大文件传输。

2. 三次握手:如何 “安全建连接”?

  • 第一次:客户端发 “SYN=1,seq=x”,说 “我想连你”。
  • 第二次:服务端回 “SYN=1,ACK=1,seq=y,ack=x+1”,说 “我同意连,你发的 x 我收到了”。
  • 第三次:客户端回 “ACK=1,seq=x+1,ack=y+1”,说 “好的,那我们开始传数据吧”。为什么三次?防止 “已失效的连接请求” 突然传到服务端,导致错误建连。比如客户端发的第一个请求堵车了,超时后又发了一个新的,结果旧请求后来到了服务端,如果两次握手,服务端会直接建连,但客户端已经不管旧请求了,浪费资源。三次握手时,客户端会验证服务端的应答,发现是旧请求就拒绝,避免这种情况。

3. 四次挥手:如何 “优雅断连接”?

  • 第一次:客户端发 “FIN=1,seq=u”,说 “我数据发完了,想断开”。
  • 第二次:服务端回 “ACK=1,ack=u+1”,说 “我知道了,你等我一下,我还有数据没发完”。
  • 第三次:服务端发 “FIN=1,ACK=1,seq=v,ack=u+1”,说 “我数据也发完了,现在可以断了”。
  • 第四次:客户端回 “ACK=1,seq=u+1,ack=v+1”,说 “收到,断开吧”,然后等 2MSL 确保服务端收到,自己再断。为什么四次?因为服务端收到断开请求时,可能还有数据没发给客户端,所以需要先回复 “知道了”,等数据发完再发 “我也断” 的请求,两次应答拆成了两次包。

4. 适用场景:对 “可靠性” 要求高,不那么急的场景

  • 网页浏览、文件下载、邮件收发、在线支付。

二、UDP:无连接的 “高速传输闪电侠”

UDP 就像发微信消息,不管对方在不在,直接发,快但可能丢,主打一个 “效率至上”。

1. 核心特性:

  • 无连接:直接发数据,不用建连接,省了握手时间,像喊人 “喂,东西给你放桌上了”,不等对方回应就走。
  • 不可靠传输:没有序列号和确认应答,丢包了不重发,顺序乱了也不管,比如发 1、2、3 号包,对方可能收到 3、1,或者只收到 2。
  • 面向数据报:每个 UDP 包都是独立的 “数据报”,有明确边界,接收方不会拼接,比如发两个 100 字节的包,对方会收到两个 100 字节,而不是一个 200 字节。
  • 开销小:头部只有 8 字节,比 TCP 的 20 字节 + 更轻量,传输速度更快。

2. 头部结构:极简主义

UDP 头部只有 4 个字段,共 8 字节:

  • 源端口、目标端口;
  • 长度;
  • 校验和。

3. 适用场景:对 “实时性” 要求高,偶尔丢包能接受的场景

  • 视频通话、语音聊天;
  • 在线游戏;
  • 直播;
  • DNS 查询。

三、TCP vs UDP:怎么选?

一句话总结:重要的数据找 TCP,快的数据找 UDP。

谢谢
← 返回列表