TCP 跟 GBN 与 SR 的关系

对于 GBN

  GBN：回退 N 步(go back N)，允许发送方发送多个分组（当有多个分组可用的时候）而不需等待确认，但是它受限于在流水线中未确认的分组数不能超过某个最大允许数 N。
  图 1 显示了发送方看到的 GBN 协议的序号范围。若将基序号 (hase) 定义为最早未确认分组的序号，将下一个序号( nextseqnum )定义为最小的未使用序号(即下一个待发分组的序号) ，则可将序号范围分割成 4 段，在[0，base - 1 ]段内的序号对应于已经发送并被确认的分组。[base , nextseqnum - 1] 段内对应已经发送但未被确认的分组。[nextseqnum , base + N - 1 ]段内的序号能用于那些要被立即发送的分组，如果有数据来自上层的话。最后，大于或等于 base +N 的序号是不能使用的，直到当前流水线中未被确认的分组(特别是序号为 base 的分组)已得到确认为止

  其中已经发送但未确认的可以看成长度为 N 的窗口，窗口在序号空间内向前滑动。在运行过程中，如图所示，对于发送方必须响应三种类型的事件：

• 上层的调用。当上层调用 rdt_send()时，发送方首先检查发送窗口是否已满，即是否有 N 个已发送但未被确认的分组。如果窗口未满,则产生一个分组并将其发送,并相应地更新变量。如果窗口已满，发送方只需将数据返回给上层，隐式地指示上层该窗口已满。然后上层可能会过一会儿再试。在实际实现中，发送方更可能缓存（并不立刻发送）这些数据，或者使用同步机制（如一个信号量或标志）允许上层在仅当窗口不满时才调用 rdt_send()。
• 收到一个 ACK。在 GBN 协议中，对序号为 n 的分组的确认采取累积确认的方式，表明接收方已正确接收到序号为 n 的以前且包括 n 在内的所有分组。
• 超时事件。协议的名字“回退 N 步”来源于出现丢失和时延过长分组时发送方的行为。就像在停等协议中那样，定时器将再次用于恢复数据或确认分组的丢失。如果出现超时，发送方重传所有已发送但还未被确认过的分组。当发送方仅使用一个定时器，它可被当作是最早的已发送但未被确认的分组所使用的定时器。如果收到一个 ACK,但仍有已发送但未被确认的分组，则定时器被重新启动。如果没有已发送但未被确认的分组,停止该定时器。

  对于接收方，如果一个序号为 n 的分组被正确接收到，并且按序（即上次交付给上层的数据是序号为 n -1 的分组)，则接收方为分组 n 发送一个 ACK，并将该分组中的数据部分交付到上层。在所有其他情况下，接收方丢弃该分组，并为最近按序接收的分组重新发送 ACK。注意到因为一次交付给上层一个分组，如果分组 k 已接收并交付，则所有序号比 k 小的分组也已经交付。因此，使用累积确认。

  对于 GBN，接收方需要丢弃所有失序分组。因为数据必须按序交付，接收方可能缓存（保存）分组 n+1，然后，在它收到并交付分组 n 后，再将该分组交付到上层。然而，如果分组 n 丢失，则该分组及分组 n +1 最终将在发送方根据 GBN 重传规则而被重传。因此，接收方只需丢弃分组 n+1 即可。这种方法的优点是接收缓存简单，即接收方不需要缓存任何失序分组。其运行过程如图 2 所示，图 2 展示了窗口场度为 4 个分组的 GBN 协议的运行情况。因为该窗口长度的限制,发送方发送分组 0~3，然后在继续发送之前,必须等待直到一个或多个分组被确认。当接收到每一个连续的 ACK（例如 ACK O 和 ACK 1)时,该窗口便向前滑动,发送方便可以发送新的分组(分别是分组 4 和分组 5)。在接收方，分组 2 丢失，因此分组 3、4 和 5 被发现是失序分组并被丢弃。

对于 SR

  选择重传，接收方设置缓冲区，为每个报文段设置计时器，如果某个报文段没有被正确接收但是后面的报文段被正确接收了，那么就只需要重发这一个报文段，在接收方整理排序之后就 ok 了，返回的 ACK 就是当前接收成功的报文段序号，通过让发送方仅重传那些它怀疑在接收方出错(即丢失或受损)的分组而避免了不必要的重传。这种个别的、按需的重传要求接收方逐个地确认正确接收的分组再次用窗口长度来眼制流水线中未完成、未被确认的分组数。然而，与 GBN 不同的是，发送方已经收到了对窗口中某些分组的 ACK。 [图 3] (#jump3) 显示了 SR 发送方看到的序号空间。 [图 4] (#jump4) 详细描述了 SR 发送方所采取的动作。

  SR 接收方将确认一个正确接收的分组而不管其是否按序。失序的分组将被缓存直到所有丢失分组（即序号更小的分组）皆被收到为止，这时才可以将一批分组按序交付给上层。图 5中使用例子说明的丢包时 SR 的操作。其中，接收方初始时缓存了分组 3、4、5，并在最终收到分组 2 时才一并交付。
  因此，在 SR 中，发送方需要响应对应的事件：

• 从上层收到数据。当从上层接收到数据后，SR 发送方检查下一个可用于该分组的序号。如果序号位于发送方的窗口内，则将数据打包并发送;否则就像在 GBN 中一样，要么将数据缓存，要么将其返回给上层以便以后传输。
• 超时。定时器再次被用来防止丢失分组。然而，现在每个分组必须拥有其自己的逻辑定时器，因为超时发生后只能发送一个分组。可以使用单个硬件定时器模拟多个逻辑定时器的操作
• 收到 ACK。如果收到 ACK，倘若该分组序号在窗口内，则 SR 发送方将那个被确认的分组标记为已接收。如果该分组的序号等于 send_base，则窗口基序号向前移动到具有最小序号的未确认分组处。如果窗口移动了并且有序号落在窗口内的未发送分组，则发送这些分组。

  接收方也需要对对应的事件进行响应：

• 序号在[rev_base，rcv_base+N-1]内的分组被正确接收。在此情况下，收到的分组落在接收方的窗口内，一个选择 ACK 被回送给发送方。如果该分组以前没收到过，则缓存该分组。如果该分组的序号等于接收窗口的基序号，则该分组以及以前缓存的序号连续的分组交付给上层。然后，接收窗口按向前移动分组的编号向上交付这些分组。举例子来说，考虑一下图 5。当收到一个序号为 rev_base =2 的分组时，该分组及分组 3、4、5 可被交付给上层。

• 序号在[rev_base - N，rev_hase -1]内的分组被正确收到。在此情况下，必须产生一个 ACK，即使该分组是接收方以前已确认过的分组。

• 其他情况。忽略该分组。

  

对于 TCP

   TCP 是面向连接的协议，这是因为在一个应用进程可以开始向另一个应用进程发送数据之前，这两个进程必须先相互“握手”，它基于运输连接来传送 TCP 报文段，TCP 运输连接的建立和释放，是每一次面向连接的通信中必不可少的过程，即它们必须相互发送某些预备报文段，以建立确保数据传输的参数。报文段的结构如图 6 所示。

   TCP 运输连接有以下三个阶段:

• 建立 TCP 连接，也就是通过三次握手来建立 TCP 连接。即客户首先发送一个特殊的 TCP 报文段，服务器用另一个特殊的 TCP 报文段来响应，最后，客户再用第三个特殊报文段作为响应。前两个报文段不承载“有效载荷”，也就是不包含应用层数据;而第三个报文段可以承载有效载荷。如图 7所示

• 数据传送，也就是基于已建立的 TCP 连接进行可靠的数据传输。一旦建立起一条 TCP 连接，两个应用进程之间就可以相互发送数据了。我们考虑一下从客户进程向服务器进程发送数据的情况。客户进程通过套接字（该进程之门）传递数据流。数据一旦通过该门，它就由客户中运行的 TCP 控制了。如图 8所示，TCP 将这些数据引导到该连接的发送缓存里，发送缓存是发起三次握手期间设置的缓存之一。接下来 TCP 就会不时从发送缓存里取出一块数据，并将数据传递到网络层。TCP 可从缓存中取出并放入报文段中的数据数量受限于最大报文段长度.

• 释放连接，也就是在数据传输结束后，还要通过四报文挥手来释放 TCP 连接。过程如图 9 所示客户应用进程发出关闭链接命令，会引起客户 TCP 向服务器进程发送一个 TCP 报文段，当服务器接收到后，就像发送方返回一个确认报文段，然后服务器发送它自己的终止报文段，最后客户对这个服务器终止报文段进行确认，进而驶方所有连接上的资源。

  TCP 的运输连接管理就是使运输连接的建立和释放都能正常的进行。对于 TCP 发送方，有 3 个主要事件，即从上层应用程序接收数据；定时器超时和收到 ACK。

• 当第一个主要事件发生，TCP 从应用程序接收数据，将数据封装在一个报文段中，并把该报文段交给 P。注意到每一个报文段都包含一个序号，这个序号就是该报文段第一个数据字节的字节流编号。还要注意到如果定时器还没有为某些其他报文段而运行，则当报文段被传给 IP 时，TCP 就启动该定时器。该定时器的过期间隔是 TimeoutInterval。
• 当第二个主要事件发生，TCP 通过重传引起超时的报文段来响应超时事件，然后重启定时器。
• 第三个主要事件是，到达一个来自接收方的确认报文段（ACK)。当该事件发生时，TCP 将 ACK 的值 y 与它的变量 SendBase 进行比较。TCP 状态变量 SendBase 是最早未被确认的字节的序号。(因此 SendBase -1 是指接收方已正确按序接收到的数据的最后一个字节的序号。）因为 TCP 采用累积确认，所以 y 确认了字节编号在 y 之前的所有字节都已经收到。如果 y >SendBase，则该 ACK 是在确认一个或多个先前未被确认的报文段。因此发送方更新它的 SendBase 变量;如果当前有未被确认的报文段，TCP 还要重新启动定时器。

TCP 跟 GBN 和 SR 的异同

TCP 与 GBN：

• TCP 确认是累积式的，正确接收但失序的报文段是不会被接收方逐个确认的。因此，如图 1所示，TCP 发送方仅需维持已发送过但未被确认的字节的最小序号和下一个要发送的字节的序号。在这种意义下，TCP 看起来更像一个 GBN 风格的协议.
• 但是 TCP 和 GBN 协议之间有着一些显著的区别。许多 TCP 实现会将正确接收但失序的报文段缓存起来。另外考虑一下，当发送方发送的一组报文段 1，2，…，N，并且所有的报文段都按序无差错地到达接收方时会发生的情况。进一步假设对分组 n < N 的确认报文丢失，但是其余 N-1 个确认报文在分别超时以前到达发送端，这时又会发生的情况。在该假设的情况下，GBN 不仅会重传分组 n，还会重传所有后继的分组 n+1，n +2，…，N。对于 TCP,T 将重传至多一个报文段，即报文段 n。此外，如果对报文段 n+1 的确认报文在报文段 n 超时之前到达,TCP 甚至不会重传报文段 n。同时 GBN 接收方不对失序到达的分组进行缓存，而 TCP 允许接收方有选择地确认失序报文段。

TCP 与 SR：

• 二者均在接收方设置缓存区，用于接收失序到达的分组。
• 接收端返回 ACK 是当前接收成功报文段的序号，SR 不采用累计应答的方式，而 TCP 使用累计应答的方式。为每个报文段设置单独的计时器，单个分组计时器超时只重发这一个报文段而 TCP 使用快速重传机制：如果收到对于一个特定报文段的 3 个冗余 ACK，则在超时事件发生前就会对该报文段进行重传，这大大节约了时间。

  对 TCP 提出的一种修改意见是所谓的选择确认，它允许 TCP 接收方有选择地确认失序报文段,而不是累积地确认最后一个正确接收的有序报文段。当将该机制与选择重传机制结合起来使用时，TCP 看起来就很像 SR 协议。因此,TCP 的差错恢复机制也许最好被分类为 GBN 协议与 SR 协议的混合体。

最后

以上就是热心白开水为你收集整理的GBN与SR简介以及TCP 跟 GBN 与 SR 的关系TCP 跟 GBN 与 SR 的关系的全部内容，希望文章能够帮你解决GBN与SR简介以及TCP 跟 GBN 与 SR 的关系TCP 跟 GBN 与 SR 的关系所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。