TCP 和 UDP 的区别：解析网络传输协议

在开始之前，推荐大家阅读一篇文章《好技能 | Chromium 是如何解决队头阻塞问题的》https://cloud.tencent.com/developer/article/2470234，该文章介绍了 Chromium 为解决队头阻塞问题，从 2013 年起多次迭代重构底层消息机制的过程，有兴趣的朋友可以去了解下。

引言

在计算机网络的世界中，TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Datagram Protocol，用户数据报协议）是两种极为重要且应用广泛的传输层协议。它们在功能、特性以及适用场景等诸多方面存在着明显的区别，下面我们就来详细探讨一下这两者之间的差异。

一、基本概念

TCP

TCP 是一种面向连接的、可靠的、基于字节流的传输层协议。它就如同在网络通信的两端建立起了一条虚拟的 “管道”，在数据传输之前，需要先通过三次握手来建立连接，确保通信双方都已经准备就绪，能够进行稳定的数据交互。在传输过程中，TCP 会对发送的数据进行编号、确认、重传等一系列操作来保证数据能够准确无误地从发送端到达接收端。而且，数据是按照顺序依次接收的，接收端会将接收到的数据按照发送的顺序重新组装起来，就好像把打乱的拼图块按正确顺序拼接完整一样。当数据传输完毕后，还会通过四次挥手来优雅地断开连接。

UDP

UDP 则是一种无连接的、不可靠的、基于数据报的传输层协议。它不需要像 TCP 那样事先建立连接，发送端可以随时向网络中发送数据报，就好比在人群中随意喊话，并不提前确认对方是否在听或者准备好了接收信息。UDP 也不会对数据报进行编号、确认和重传等操作，数据报有可能会在传输过程中丢失、重复或者乱序到达接收端，接收方收到的数据报就是发送方发送时的原样，并不会去整理顺序等，所以使用 UDP 传输数据时并不能保证数据一定能完整无误地被接收。

二、可靠性对比

TCP 的可靠性保障

• 确认机制：TCP 每发送一段数据，都会等待接收方发送回确认信息（ACK），只有收到了对应的数据确认，发送方才会继续发送下一部分数据，这样能确保每一个字节的数据都被对方正确接收了。例如，你发送一份重要文件，接收方每收到一部分都会回复说 “这部分我收到了，可以发下一部分了”，这样就保证了文件完整传输。
• 重传机制：如果发送方在一定时间内没有收到接收方的确认消息，就会认为该部分数据可能丢失了，进而会重新发送这部分数据，以此来应对网络中可能出现的数据丢失情况，最大限度地保证数据的完整性。
• 顺序保障：接收端会按照数据的编号顺序来整理接收到的数据，保证数据是按照发送的顺序依次排列的，不会出现混乱的情况，就像我们按照页码顺序阅读一本书一样，保证内容的连贯性。

UDP 的不可靠性表现

由于 UDP 没有上述的确认、重传以及顺序保障机制，所以它无法确保数据一定能准确无误地到达接收端。例如，在实时视频流传输中使用 UDP 时，偶尔出现一两个画面的数据丢失，可能只是画面短暂的卡顿或者花屏，但后续的数据依然在继续传输，它更注重实时性而不是数据的绝对完整可靠。

三、连接特性对比

TCP 的面向连接特性

TCP 在通信之前，必须通过三次握手的过程来建立连接。发送方首先发送一个带有 SYN（同步序列号）标志的数据包，表示希望建立连接；接收方收到后回复一个 SYN + ACK 的数据包，表示同意建立连接并对发送方进行确认；最后发送方再回复一个 ACK 数据包，至此连接正式建立。在通信结束后，还需要经过四次挥手来断开连接，整个过程就像是打电话，先拨号建立通话线路（三次握手），通话结束后挂断电话（四次挥手），这种面向连接的方式使得通信过程更加有序和可靠，但同时也带来了一定的开销，比如建立和断开连接时占用的时间和网络资源。

UDP 的无连接特性

UDP 不需要建立连接就可以直接发送数据，就像发传单一样，不管对方有没有准备好，直接把传单（数据报）发出去就行。这种方式使得 UDP 在发送数据时非常迅速，能够快速地将数据投送到网络中，尤其适用于那些对实时性要求极高、偶尔丢失一点数据也不影响整体功能的应用场景，比如实时的在线游戏操作指令发送等，操作指令更注重快速送达让游戏及时响应，而不是绝对保证每个指令都一定被接收。

四、数据传输形式对比

TCP 的字节流传输

TCP 把要传输的数据看作是一连串的字节，这些字节按照顺序依次传输，接收端也是按照字节流的顺序来进行组装和解读数据。例如，发送端发送一段文字信息，接收端会根据字节的先后顺序完整地还原出这段文字内容，就像用线穿珠子一样，珠子按照顺序串起来形成完整的一串项链（完整的数据）。

UDP 的数据报传输

UDP 是以数据报为单位来进行传输的，每个数据报都是独立的个体，有自己固定的格式和大小限制等，发送端发送的数据报在网络中是各自独立传输的，接收端收到的数据报也是独立存在的，不会像 TCP 那样将它们组装成连续的字节流，更像是一个个单独的包裹被分别投递和接收。

五、首部开销对比

TCP 首部

TCP 的首部相对比较长，一般为 20 字节（如果有选项字段会更长），它包含了很多用于实现可靠传输、流量控制、连接管理等功能的字段，比如源端口、目的端口、序列号、确认号、首部长度、标志位（如 SYN、ACK、FIN 等）、窗口大小、校验和、紧急指针等。这些字段虽然有助于保证数据传输的质量和连接的有效管理，但也使得 TCP 首部在传输时占用了一定的网络带宽和资源。

UDP 首部

UDP 的首部则比较简洁，仅仅只有 8 个字节，包含源端口、目的端口、长度和校验和这几个基本字段。因为 UDP 不需要像 TCP 那样复杂的功能支持，所以其首部开销很小，能更高效地利用网络带宽来传输数据本身，尤其适合那些对数据量传输效率要求较高且对可靠性要求不是特别严格的场景。

六、适用场景对比

TCP 的适用场景

• 文件传输：例如通过 FTP（文件传输协议）来传输大文件时，需要确保文件的每一个字节都准确无误地到达目的地，TCP 的可靠性保障能很好地满足这一需求，避免文件出现损坏、丢失数据等情况。
• 网页浏览：当我们在浏览器中访问网页时，浏览器使用 HTTP（超文本传输协议），而 HTTP 通常是基于 TCP 协议的，这样能保证网页的 HTML、CSS、图片等各种资源完整且有序地传输过来，让我们看到完整、正确的网页页面。
• 电子邮件传输：像 SMTP（简单邮件传输协议）、POP3（邮局协议版本 3）等用于电子邮件收发的协议大多也是基于 TCP 的，保证邮件内容准确地从发件人发送到收件人的邮箱中，不会出现邮件内容丢失或者错乱的情况。

UDP 的适用场景

• 实时视频和音频流传输：如在线直播、视频会议等场景，虽然偶尔丢失一些视频帧或者音频片段可能会稍微影响观看体验，但更重要的是要保证实时性，让画面和声音能够及时传递给观众，UDP 的快速传输和低延迟特性就很适合这类应用，即使有少量数据丢失也不会对整体的实时播放造成严重破坏。
• 实时在线游戏：在游戏中玩家发送操作指令时，需要指令能快速送达服务器以便游戏能立即做出响应，稍微的指令丢失可以通过游戏自身的一些机制来弥补（比如角色位置的快速调整等），所以 UDP 能更好地满足游戏对实时操作响应的要求。
• 域名系统（DNS）查询：当我们在浏览器中输入网址后，计算机需要通过 DNS 来查询对应的 IP 地址，这个查询过程一般使用 UDP，因为 DNS 查询通常数据量较小，而且更注重快速得到结果，偶尔的查询失败可以通过再次发起查询来解决，UDP 的高效传输能加快查询速度。

综上所述，TCP 和 UDP 作为网络传输层的两大重要协议，各有其独特的优缺点和适用场景。在实际的网络应用开发和部署中，需要根据具体的业务需求来选择合适的协议，以便在可靠性、实时性、资源利用等多个方面达到最佳的平衡，确保网络通信的高效与顺畅