Skip to content

Tcp udp介绍并说明使用场景

TCP（Transmission Control Protocol，传输控制协议）

TCP是一个面向连接的、可靠的、基于字节流的传输层协议。它的设计目标是“质量优先”，确保数据能够准确无误地从一端传输到另一端。

它的核心特点可以概括为以下几点：

  1. 面向连接：在数据传输之前，必须通过“三次握手”建立一个虚拟的连接。数据传输完毕后，需要通过“四次挥手”来断开连接。这个过程确保了通信双方都准备好了数据的收发。
  2. 可靠传输：TCP通过多种机制来保证数据的可靠性：
    • 序列号和确认应答（ACK）：TCP将数据拆分成多个有序的数据段，并为每个数据段分配一个序列号。接收方收到数据后会发送一个ACK确认，告知发送方已经收到了哪些数据。
    • 超时重传：如果发送方在一定时间内没有收到某个数据段的ACK，就会认为该数据段丢失，并重新发送。
    • 数据校验：通过校验和来检查数据在传输过程中是否出错。
  3. 流量控制：通过“滑动窗口”机制，接收方可以告诉发送方自己还有多少缓冲区可以接收数据，防止发送方发送过快导致接收方处理不过来。
  4. 拥塞控制：当网络出现拥堵时，TCP会自动降低发送数据的速率，以缓解网络压力。这包括慢启动、拥塞避免、快重传、快恢复等算法。
  5. 字节流：TCP不保留报文的边界。发送方分两次发送10字节和20字节的数据，接收方可能一次性收到30字节。

UDP（User Datagram Protocol，用户数据报协议）

UDP是一个面向无连接的、不可靠的、面向报文的传输层协议。它的设计目标是“速度优先”，以最快的速度、最小的开销发送数据，但不对数据的到达做任何保证。

它的核心特点如下：

  1. 无连接：发送数据前不需要建立连接，直接将数据打包成数据报（Datagram）发送出去。
  2. 不可靠：UDP是“尽力而为”（Best-Effort）的传输。它不保证数据包会到达，不保证数据包的到达顺序，也不保证数据包不重复。
  3. 面向报文：UDP保留了应用程序发送时的数据边界。发送方发送了一个100字节的数据包，接收方如果收到，就一定会收到一个完整的100字节的数据包。
  4. 开销小，速度快：UDP的头部只有8个字节，相比TCP的20个字节起步要小得多。它没有建立连接、确认、重传等复杂的机制，因此传输延迟低，效率高。

使用场景分析

理解了它们的特点后，选择哪个协议就变成了一个在“可靠性”和“实时性/效率”之间的权衡。

TCP的适用场景（对数据完整性和顺序要求极高的场景）

  1. 文件传输：FTP、SCP等。文件的任何一个字节出错都会导致整个文件损坏，必须使用TCP。
  2. 网页浏览：HTTP/HTTPS。网页的HTML、CSS、JS文件必须完整无误地加载，才能正确渲染页面。
  3. 电子邮件：SMTP、POP3、IMAP。邮件内容不容有失。
  4. 数据库连接：几乎所有的数据库客户端和服务器之间的通信都使用TCP，保证SQL指令和数据的准确性。
  5. 远程登录：SSH、Telnet。你输入的每一个命令字符都必须按序、准确地传到服务器。

总结：在这些场景下，我们愿意为了数据的准确可靠，牺牲一点点的传输延迟。

UDP的适用场景（对实时性要求高，能容忍少量数据丢失的场景）

  1. 在线直播、视频会议：如WebRTC。在这种场景下，实时性是第一位的。如果因为网络抖动丢了某一帧画面，与其卡住等待重传，不如直接播放下一帧，用户体验会更好。丢一帧的影响远小于画面卡顿。
  2. 网络游戏：特别是FPS（第一人称射击）、MOBA（多人在线战术竞技）等游戏。玩家的位置、动作等信息需要以极低的延迟广播给其他玩家。如果一个位置信息包丢失了，服务器会很快发送下一个更新的位置信息，旧的那个就无所谓了。
  3. DNS（域名系统）：DNS查询就是一个简单的请求-响应过程。数据包很小，逻辑简单。如果请求失败，客户端简单地重新发起一次请求即可。使用TCP的握手挥手开销显得过于笨重。
  4. VoIP（网络电话）：和视频会议类似，保证通话的流畅性比保证每个音频数据包都完整到达更重要。
  5. 物联网（IoT）设备数据上报：大量传感器以高频率上报数据，这些数据通常是时序性的，丢掉一两个数据点对整体趋势分析影响不大。

总结：在这些场景下，我们优先保证低延迟和高效率，应用层自己会处理少量的数据丢失（比如插值、忽略等）。

最后，值得一提的是，现代网络协议的发展也在试图结合两者的优点，比如基于UDP的QUIC协议（HTTP/3的核心），它在UDP之上实现了一套可靠的、多路复用的传输机制，既有UDP的低延迟，又有类似TCP的可靠性，这是网络协议演进的一个重要方向。