UDP 和 TCP 对应用层报文的处理对比

文章内容来自 B站up主 湖科大教书匠
视频教程链接： https://www.bilibili.com/video/BV1JJ411V7Zy?spm_id_from=333.880.my_history.page.click.

对于 UDP 来说，发送方的应用进程将应用层报文交付给运输层的UDP，UDP直接给应用层报文添加一个UDP首部，使其成为UDP用户数据报，然后进行发送，这里需要注意的是，为了简单起见，这里忽略运输层下面的各层处理。接收方的UDP收到该UDP用户数据报后，去掉UDP首部，将应用层数据报文交付给应用进程。也就是说，UDP对应用进程交下来的报文既不合并也不拆分，而是保留这些报文的边界，换句话说，UDP是面向应用报文的。

再来看使用TCP协议的情况，发送方的TCP将发送方的应用进程交付下来的数据块仅仅看做是一连串的、无结构的字节流。

TCP并不知道这些待传送的字节流的含义，仅仅将它们编号并存储在自己的发送缓存中，TCP根据发送策略，从发送缓存中提取一定数量的字节，构建 TCP报文段并发送，接收方的TCP，一方面从所接收到的TCP报文段中，取出数据载荷部分并存储在接收缓存中，另一方面将接收缓存中的一些字节交付给应用进程，TCP并不保证接收方的应用进程所收到的数据块与发送方应用进程所发送的数据块具有对应大小的关系（例如，发送方应用进程交给发送方的TCP共10个数据块，但接收方的TCP可能只用了4个数据块，就把收到的字节流交付给了上层的应用进程，但是接收方收到的字节流必须和发送方应用进程发出的字节流完全一样）。当然，接收方的应用进程必须有能力识别收到的字节流，把它还原成有意义的应用层数据。也就是说 TCP 是面向字节流的，这正是TCP实现可靠传输、流量控制、以及拥塞控制的基础。

为了突出要点，在图中，我们只画出了一个方向的数据流。在实际网络中，基于TCP连接的两端，可以同时进行TCP报文段的发送和接收，也就是全双工通信。另外，图中TCP报文段的数据部分只包含了几个字节。实际当中，一个TCP报文段包含上千个字节是很常见的。

TCP/IP体系结构的网际层（IP层）向其上层提供的是无连接的不可靠的传输服务。当运输层使用UDP传输协议时，向其上层提供的也是无连接不可靠的传输服务。发送方给接收方发送UDP用户数据报，若传输过程中用户数据报受到干扰而产生误码。接收方UDP可以通过该数据报首部中的校验和字段的值，检查出产生误码的情况。但仅仅丢弃该数据报，其他什么也不做。发送方给接收方发送UDP用户数据报，如果该数据报被因特网中的某个路由器丢弃了，发送方UDP同样不做任何处理。因为UDP向上层提供的是无连接不可靠的传输服务。因此，对于UDP用户数据报出现的误码和丢失等问题，UDP并不关心，基于UDP的这个特点，UDP适用于实时应用，例如IP电话、视频会议等。

当运输层使用TCP传输协议时，尽管它的下层网际层（IP层）向其提供的也是无连接的不可靠的传输服务，也就是说IP数据报可能在传输过程中出现丢失或误码，但因为TCP协议是面向连接的可靠的传输服务，就可以向其上层提供面向连接的可靠的传输服务。我们可以将其想象成使用TCP协议的收发双方，基于TCP连接的可靠信道进行数据传输，不会出现误码、丢失、乱序以及重复等传输差错。TCP适应于要求可靠传输的应用，比如小文件传输。

对比UDP用户数据报的首部和TCP报文段的首部

一个UDP用户数据报由首部和数据载荷两部分构成。其首部格式如图所示，仅有四个字段。每个字段长度为2个字节。由于UDP不提供可靠传输服务，它仅仅在网际层的基础上，添加了用于区分应用进程的端口，因而它的首部非常简单，仅有8个字节。

而一个TCP报文段由首部和数据载荷两部分构成，其首部格式如图所示，这比UDP用户数据报的首部复杂的多，其最小长度为20字节，最大长度为60字节。这是因为TCP要实现可靠传输、流量控制、拥塞控制等服务。其首部自然会比较复杂，首部中的字段也就比较多，首部长度也就比较长。

总结：