计算机网络之运输层（TCP的可靠传输的工作原理和具体实现方法）

• 可靠传输的工作原理和具体实现方法
  　　TCP 之所以具备极强的容错率（不担心出错），在于它有让两个运输层之间的通信可靠的方法。
  　　 理想的传输条件需要有的特点：
  　　 （1）传输信道不产生差错。
  　　 （2）不管对方以多快的速度发送数据，接收方总是来得及处理收到的数据。
  　　实际情况满足不了这两个特点。但是可以使用一些协议，当出现差错时让对方重发数据（满足第一点）。同时当接收方来不及处理收到的数据时，及时通知对方降低速度（满足第二点）。所以原本不可靠的传输信道，就能够实现可靠传输了。
  　　具体实现方法是：停止等待协议（这是早期使用的协议，真正使用的协议，比这个要复杂得多）、连续 ARQ 协议、滑动窗口协议。
  　　如果是自动重发协议（不过好像都是自动重发协议）的话，意思是重传的请求是自动进行的，接收方不需要请求发送方重发某个出错的分组（甚至，哪个数据出错，都是发送方自己确定的，真是报喜不报忧）。

• 停止等待协议（自动重传请求 ARQ（automatic repeat request））：
  ——正常收发：
  　　停止等待，就是发送完一个数据，就停止发送，等待对方的确认。收到确认后，才能够发送下一个数据（对于运输层来说，数据的形式就是分组）。
  ——出现差错：
  　　在无差错情况下，如发送方为 A ，接收方为 B。A 发送 M1，接收方接收到后，返回确定信号，发送方才能发送 M2。那么，在出现差错之后，如 M1 发送失败，接收方不会返回任何信息（可能是 M1 在发送中丢失了，这时候更加不弧返回信息，或者接收方测试发现错误）。协议是这么应对的：A 超过一段时间后，还没有收到信号，就认为 M1丢失了重新发送。这叫做超时重传。在每次发送一个数据时， 发送方都会自动设置一个超时计时器。如果收到了，就撤销掉那个计时器。
  　　那么，这个应对方案需要有：
  　　（1）A 发送完一个分组后，必须暂时保留副本，只有在收到确认后，才能清理数据。
  　　（2）分组和确认分组的信号，必须进行编号，才能够一一对应（这是在首部里，认定的）。
  　　（3）超时计时器的截止时间要大于数据在分组传输的平均时间更长一些。
  ——（具体的差错执行后续）确认丢失：
  　　如果是 B 收到了 M1，但是返回的确认信号丢失了，导致 A 重发 M1，那么 B 接收到了 M1 的话，需要执行：（1）丢弃这个重复到的数据 M1，不向上层交付；（2）向 A 发送确认信号，避免 A 再发送 M1。
  ——（具体的差错执行后续）确认迟到：
  　　如果是 B 收到了 M1，但是返回的确认信号延迟发送了，导致 A 已经重发 M1，那么 B 接收到了 M1 的话， B 需要执行：丢弃分组，并向 A 发送确认信号。而 A 会接收到2个确认 M1 的信号，需要执行·：丢弃重复的信号。
  　　但是，停止等待协议的优点在于逻辑清晰，操作简单，但是信道利用率太低了。为了提高利用效率，发送方可以不使用低效率的停止等待协议，而是流水线传输。即是连续发送多个分组，不要等到发完一个分组接收到确定信号之后，才发送。
  当使用流水线传输时，就需要使用连续 ARQ 协议和滑动窗口协议。

• 连续 ARQ 协议：
  　　滑动窗口协议，比较复杂，是 TCP 协议的精髓所在，后面再讲。对于连续 ARQ 协议，是先建立一个发送窗口的概念，即是选中 n 个分组，认为是在同一个发送窗口内。位于发送窗口里的这些分组，可以连续发送出去，而不需要等待对方的确认。而如果在这个发送过程里，每收到一个确认，就可以将发送窗口向发送分组的队列下沿一个单位。
  　　更加方便的是，接收方一般采用的是，累积确认的方式，即是接收方不用对收到的分组逐个发送确认，而是对按序到底的最后一个分组，发送确认。表示包括这个之前的那些分组，都收到了。
  　　当然也会有缺点，即是不能向发送方正确反映接收方收到的所有分组信息。比如 A 发送了5个分组，第三个出现问题，其余没问题。但是 B 只能对前面两个分组发出确认。所以后面三个都要重发。

• TCP 的滑动窗口机制
  　　作为全双口的通信机制， TCP 的双方既可以做发送方，也可以做接收方。所以每一个具体的一方，都需要有发送窗口和接收窗口。发送方、接收方为 A、B 。
  
  　　A 在发送时，只要没有接收到 的确认信号，就可以将发送窗口 的数据，连续地发送出去，但所有发送的数据，在没有收到确定信号前，都必须先保留的。如果接收到确认信号，就根据确定信号的首部的确认号，来移动窗口。
  但是，其实还要考虑当时网络拥塞的程度，暂不考虑。
  　　TCP 的发送方在规定的时间里，如果没有收到确认，就要重新发送已发送的报文段。这种重传的概念和必要性是很简单的。但是重传的具体时间却是很复杂的，它取决于下层网络和拥塞程度和硬件的传送速度。现在已经有行之有效的算法来估算具体的时间，不再介绍。
  　　 一般发送方希望每次数据发送得尽可能多。但是接收方的接收窗口有限，所谓流量控制，就是让发送方的发送速率不要太快，让对方来得及处理数据，腾出空间。利用滑动窗口机制可以很方便地完成接收方对发送方的流量控制（发送窗口大小一定要小于接收方接收窗口大小）。
  值得一提的是，如果接收方的接收窗口为 0 ，发送零窗口报文段后，不久接收窗口又有了空余地方，但发送空余窗口报文段时，丢失了。发送方会不会一直在等待呢？其实和确认信号类似的机制， TCP 的一方接收到零窗口通知，会启动计时器，如果时间到了的话，会发送一个零窗口探测报文段（仅携带 1 字节的数据），进行测试。

• TCP 的拥塞控制
  　　计算机网络中的带宽、交换节点的缓存空间和处理机（cpu）等，都是网络的资源。如果对网络的某一个资源的需求超过了实际能提供的数量，网络则拥塞。
  　　网络的拥塞，不能简单地哪里拥塞扩大哪里的资源，只是不断地转移瓶颈的做法，治标不治本。如果扩大某个结点的容量，到达该结点的数据都可以在结点的缓存序列里排队，但是输出链路的容量和处理机速度没有跟上，导致数据的等候时间基本不变，同样需要超时重传。问题的本质是不同地方资源的利用率不同，只有利用率相同了，才能够不出现拥塞。
  　　拥塞是整个系统（发送方—中间的线路，路由器等—接收方）整体的问题描述，流量控制是两个端点的动作描述。但往往，流量控制是拥塞的解决办法之一。
  　　从控制理论来看拥塞控制这个问题，分为开环控制和闭环控制。开环控制是设计系统时，将可能发生拥塞的“瓶颈”都考虑到，力求不发生拥塞（真的发生了，唯一可做的就是流量控制）。
  ——闭环控制有以下几个措施：
  　　（1）实时监测网络系统以便确定是否有拥塞发生，具体位置。
  　　（2）将拥塞的具体信息发送大可以采取行动的地方（可进行调整的地方）。
  　　（3）调整那些地方，以解决问题。
  　　网络拥塞的指标有：由于缺少缓存空间而被丢弃的数据的百分数（有些地方空间太小了）、平均队列长度（计算或者传输速度跟不上）、超时重传的分组数（直接说明拥塞了）、平均分组时延（直接说明拥塞了）、分组时延的标准差（直接说明拥塞了）等。
  ——确定拥塞发生和具体位置：
  可以在路由器转发地分组中保留一个比特或者字段，来显示该路由器是否发生拥塞。或者由一些路由器或者主机周期性发送试探分组，确定所负责部分是否拥塞（这都是确定发送拥塞与否，和发生拥塞的具体位置而已）。
  ——处理的办法：
  还是从流量控制为主。发送方要建立一个拥塞窗口的状态变量。它会根据实际网络拥塞程度实时变化。而发送窗口，就是要少于拥塞窗口和接收方的接收窗口两者中小的那个。