4层运输层 UDP TCP

翘首等待

已于 2022-05-30 17:39:37 修改

阅读量2.2k

点赞数

分类专栏：计算机网络文章标签：网络

于 2022-03-22 18:42:01 首次发布

本文链接：https://blog.csdn.net/weixin_41154070/article/details/123666971

版权

计算机网络专栏收录该内容

16 篇文章 1 订阅

订阅专栏

运输层的两个主要协议：

用户数据报协议 UDP
传输控制协议 TCP

用户数据报协议 UDP

用户数据报协议 UDP 只在 IP 的数据报服务之上增加了很少一点的功能:

复用：应用层所有的应用进程都可以通过运输层再传递到 IP 层
分用：运输层从 IP 层收到发送给各应用进程的数据后，必须分别交付指明的各应用进程
差错检测

用户数据报协议 UDP 有两个字段：数据字段和首部字段。首部字段有 8 个字节，由四个字段组成，每个字段的长度都是两个字节。

源端口：源端口号。不需要时可用全 0。
目的端口：目的端口号。
长度：UDP 用户数据报的长度，其最小值是 8 （仅有首部）。
校验和：检测 UDP 用户数据报在传输中是否有错。有错就丢弃。

UDP的主要特点：

UDP 是无连接的，即发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。
UDP 使用尽最大努力交互，即不保证可靠交互，因此主机不需要维护复杂的连接状态表。
UDP 是面向报文的。发送方的 UDP 对应用程序交下来的报文，在添加首部后就向下交互 IP 层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。
UDP 没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。
UDP 支持一对一、一对多和多对多的交互通信。
UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。

传输控制协议 TCP

TCP 的主要特点：

TCP 是面向连接的运输层协议。应用程序在使用 TCP/IP 协议之前，必须先建立 TCP 连接。在传送数据完毕后，必须释放已经建立的 TCP 连接。
每一条 TCP 连接只能有两个端点，每一条 TCP 连接只能是点对点的（一对一）。
TCP 提供可靠交付的服务。通过 TCP 连接传送的数据，无差错、不丢失、不重复，并且按序到达。
TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信是数据。
面向字节流。虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。

理想的传输条件有以下两个特点：

传输信道不产生差错
不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。

然而实际的网络都不具备以上两个理想条件。但我们可以使用一些可靠传输协议：

当出现差错时让发送方重传出现差错的数据
在接收方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速率。

传输控制协议 TCP使用流水线传输，就要使用 连续 ARQ 协议 和 滑动窗口协议。

连续 ARQ 协议

连续 ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。接收方一般采用累积确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分组都已正确收到了。累积确认有优点也有缺点。优点是容易实现，即使确认丢失也不必重传；但缺点是不能向发送方及时反映接收方已经正确收到所有分组的信息。

发送方只要超过了一段时间没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这就叫做超时重传。要实现超时重传，就要在每发送完一个分组时设置一个超时计时器。如果在超时计时器到期之前收到了对方的确认，就撤销已设置的超时计时器。

发送方没有收到确认的三种情况：

分组在传输过程中出现差错的情况。接收方接收分组时检测出了差错，就丢弃分组，其他什么也不做。
发送方所发送的对分组的确认丢失了。
传输过程中没有出现差错。但接收方对分组的确认迟到了。

发送方在设定的超时重传时间内没有收到确认，并无法知道是自己发送的分组出错、丢失、或者是接收方发送的确认丢失或迟到了。因此发送方在超时计时器到期后就要重传分组。接收方又收到了重传的分组，这时应采取的行动：

出现差错的情况：接收方接收分组，并向发送方发送确认。
确认丢失的情况：接收方丢弃这个重复的分组，不向上层重复交付。向发送方发送确认。不能认为发送过确认就不再发送，因为发送方之所以重传分组就表示发送方没有收到对分组的确认。
确认迟到的情况：发送方会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃，但什么也不做。接收方仍然会收到重复的分组，丢弃这个重复的分组，不向上层重复交付。向发送方发送确认。

使用确认和重传机制，就可以在不可靠的传输网络上实现可靠的通信。这种可靠传输的协议常称为自动重传请求 ARQ。流水线传输就是发送方可连续发送多个分组，不必每发送完一个分组就停顿下来等待对方的确认。

TCP 的发送方在规定的时间内没有收到确认就要重传已发送的报文段。这种重传的概念是很简单的，但**重传时间的选择**却是 TCP 最复杂的问题之一。

若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？答案是可以的。选择确认（Selective ACK） 就是一种可行的处理方法。

滑动窗口协议

TCP 的滑动窗口是以字节为单位的。发送窗口里面的序号表示允许发送的序号，显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。

在这里插入图片描述

发送窗口后沿的后面部分表示已发送且已收到了确认。这些数据显然不需要再保留了
发送窗口的位置由窗口前沿和后沿的位置共同确定。
发送窗口前沿的前面部分表示不允许发送，因为接收方没有为这部分数据保留临时存放的缓存空间。

发送窗口后沿的变换情况有两种可能，即不动（没有收到新的确认）和前移（收到了新的确认）。发送窗口后沿不可能向后移动，因为不能撤销掉已收到的确认。

发送窗口前沿通常是不断向前移动的，但也有可能不动。这对应两种情况：一是没有收到新的确认，对方通知窗口大小也不变；二是收到了新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动。发送窗口前沿也有可能向后收缩。这发生在对方通知窗口缩小了。但 TCP 的标准强烈不建议这样做。因为很可能发送方在收到这个通知以前已经发送了窗口中的很多数据，现在又要收缩窗口，不让发送数据，这样就会产生一些错误。

发送方的应用进程把字节流写入 TCP 的发送缓存，接收方的应用进程从 TCP 的接收缓存中读取字节流。下面我们就进一步讨论窗口和缓存的关系。

在这里插入图片描述

发送方的缓存用来暂时存放：

发送应用程序传送给发送方 TCP 准备发送的数据；
TCP 已发送出但尚未收到确认的数据。

发送窗口通常只是发送缓存的一部分。已被确认的数据应当从发送缓存中删除，因此发送缓存和发送窗口的后沿是重合的。发送应用程序最后写入发送缓存的字节减去最后被确认的字节，就是保留在发送缓存中的被写入的字节数。发送应用程序必须控制写入缓存的速率，不能太快，否则发送缓存就会没有存放数据的空间。

接收缓存用来暂时存放：

按序到达的、但尚未被接收应用程序读取的数据；
未按序到达的数据。

如果收到的分组被检测出有差错，则要丢弃。如果接收应用程序来不及读取收到的数据，接收缓存最终就会被填满，使接收窗口减小到零。反之，如果接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口就可以增大，但最大不能超过接收缓存的大小。

TCP 报文段的发送时机

应用进程把数据传送到 TCP 的发送缓存后，剩下的发送任务就由 TCP 来控制了。但是，如何控制 TCP 发送报文段的时机仍然是一个较为复杂的问题。

在 TCP 的实现中广泛使用 Nagle 算法。 算法如下：若发送应用进程把要发送的数据逐个字节地送到 TCP 的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时，用这样的方法可明显地减少所用的网络带宽。Magle 算法还规定，当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。这样做，就可以有效地提高网络的吞吐量。
另一个问题叫作糊涂窗口综合征，有时也会使 TCP 的性能变坏。 设想一种情况：TCP 接收方的缓存已满，而交互式的应用进程一次只从接收缓存中读取 1 个字节（这样就使接收缓存空间仅腾出 1 个字节），然后向发送方发送确认，并把窗口设置为 1 个字节（但发送的数据报是 40 字节长）。接着，发送方又发来 1 个字节的数据（请注意，发送方发送的 IP 数据报是 41 字节长）。接收方发回确认，仍然将窗口设置为 1 个字节。这样下去，使网络的效率很低。要解决这个问题，可以让接收方等待一段时间，使得接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。 主要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。此外，发送方也不要发送太小的报文段，而是把数据积累成足够大的报文段，或达到接收方缓存的空间的一半大小。

上述两种方法可配合使用。使得在发送方不发送很小的报文段的同时，接收方也不要在缓存刚刚有了一点小的空间就急忙把这个很小的窗口大小信息通知给发送方。

利用滑动窗口实现的流量控制

所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意，TCP 的窗口单位是字节，不是报文段。

现在我们考虑一种情况。数据接收方向数据发送方发送了零窗口的报文段后不久，数据接收方的接收缓存又有了一些存储空间。于是数据接收方向数据发送方发送了 rwnd = 400 的报文段。然而这个报文段在传送过程中丢失了。数据发送方一直等待收到数据接收方的非零窗口的通知，而数据接收方也一直等待数据发送方发送的数据。如果没有其他的措施，这种互相等待的死锁局面一直延续下去。

为了解决这个问题，TCP 为每一个连接设有一个持续计时器。只要 TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带 1 字节的数据），而对方就在确认这个探测报文段时给出了现在的零窗口值。如果窗口仍然为零，那么收到这个报文段的一方就重新设置持续计时器。如果窗口不是零，那么死锁的僵局就可以打破了。TCP 规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段。

TCP 的拥塞控制方法

TCP 进行拥塞控制的算法有四种：