《计算机网络》读书笔记(一) 可靠传输的工作原理

旧城等待， 2023-08-17 16:28 161阅读 0赞

# 目录： #

1.     [《计算机网络》 读书笔记(二) 协议概述及链路层描述][Link 1]

2.    [《计算机网络》 读书笔记(二) 协议概述及链路层描述][Link 1]

3.   [ 《计算机网络》 读书笔记(三) 网络层][_ _]

4.     [《计算机网络》 读书笔记(四) 运输层][Link 2]

5.     [《计算机网络》 读书笔记(五) 其他杂项][Link 3]

6.     [《计算机网络》 读书笔记(六) 协议比较][Link 4]

7.      [网络编程之 Socket函数 (一)][Socket_]

8.   [   网络编程之 Socket函数 (二)][_ Socket_]

9.     [网络编程之 Socket的模式(一) --- “阻塞/非阻塞” 与 “同步/异步”][Socket_ --- _ _]

10. [  网络编程之 Socket的模式(二) --- “Linux网络I/O模型”][_ Socket_ --- _Linux_I_O]

11.   [网络编程之 Socket的模式(三) --- “Window网络I/O模型”][Socket_ --- _Window_I_O]

12.   [网络编程之 Socket的模式(四) --- “Window网络I/O模型”续][Socket_ --- _Window_I_O 1]

记得以前学习网络知识的时候，看过几本书，受益匪浅。其中论述TCP/IP协议的，除了<计算机网络-谢希仁>的，就是W.Richard Stevens的<TCP/IP详解 卷1：协议>了。之后工作中也陆陆续续的间或有网络项目，便一直以为自己对协议栈很了解。直到某天碰到网络故障时，遇到问题不解，重新拿起书后，才发现很多细节之处已经遗忘。好记性不如烂笔头，于是就有了这篇<计算机网络-谢希仁编著>的读书笔记。

而把可靠传输的原理当作读书笔记的第一篇，是因为绝大多数工程是都是工作在网络的应用层，有着自己的业务逻辑。对于分布式网络的应用而言，同传输一样，也会面对可靠和非可靠问题的解决。对于应用层来说，需要解决的问题是应用的执行的可靠。对于此，可靠传输的原理是完全适用或可作为参考的，解决的方法并无二至。

# 1. 可靠传输的工作原理 #

我们知道 TCP协议是能保证可靠传输的，而IP层协议是不可靠的。TCP把发送的报文段是交给IP层传送时，IP层只能提供尽最大努力服务。也就是说，TCP协议面对的是一个下层网络不可靠的服务。为此,TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠。这就引出了下面可靠传输的两个特点。  
            理想的传输条件有以下两个特点：  
             **1. 传输信道不产生差错**。  
             **2. 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据**。  
            在这样的理想传输条件下，不需要采取任何措施就能够实现可靠传输。  
            然而实际的网络都不具备以上两个理想条件。但可以使用一些可靠传输协议，当出现差错时让发送方重传出现差错的数据，同时在接受方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速度。

## 1.1 停止等待协议 ##

全双工通信的双方既是发送方也是接受方。为了讨论问题的方便，仅考虑A发送数据而B接受数据并发送确认。因此A叫做 **发送方**，而B叫做 **接收方**。因为这里讨论可靠传输的原理，因此把传送的数据单元都称为分组，而并不考虑数据是在哪一个层次上传送的。"停止等待"就是每发送完一个分组就停止发送，等待对方的确认，在收到确认后再发下一个分组。  
            对于停止等待协议，共会出现4种传输情况，分别是：  
**            1. 无差错情况  
            2. 出现差错的情况  
            3. 确认丢失的情况  
            4. 确认迟到的情况**

![20130821220720406][]

### 1.1.1 停止等待协议4种情况 ###

下面分别介绍：  
             **1. 无差错情况**  
            通知等待协议可用下图来说明。下图是最简单的无差错情况。A发送分组M1，发完就暂停发送，等待B的确认。B收到了M1就向A发送确认。A在收到了对M1的确认后，就再发送下一个分组M2。同样，在收到B对M2的确认后，再发送M3。  
  
            ** 2. 出现差错**  
            分组在传输过程中出现差错时，接受端接受M1时检测出了差错，就丢弃了M1，其他什么也不做(不通知A收到有差错的分组)。也有可能是M1在传输过程中丢失了，这是B当然什么都不知道。在这两种情况下，B都不会发送任何信息。可靠传输协议是这么设计的：A只要超过一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这就叫做 **超时重传**。要实现超时重传，就要在每发送完一个分组设置一个 **超时计时器**。如果在超时计时器到期之前收到了对方的确认，就撤销已设置的超时计时器。  
            这里应注意以下三点。  
            第一，A在发送完一个分组后， **必须暂时保留已发送的分组的副本(为发生超时重传使用)**。只有在收到相应的确认后才能清除暂时保留的分组的副本。  
            第二，分组和确认分组都必须进行 **编号**。这样才能够明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认。  
            第三，超时计时器设置的重传时间 **应当比数据在分组传输的平均往返时间更长一点**。如果重传时间设定的很长，那么通信的效率就会很低。但如果重传时间设定的太短，以致产生了不必要的重传，浪费了网络资源。然而在运输层重传时间的准确设定是非常复杂的，这是因为已发送的分组到底会 **经过哪些网络**，以及这些网络将会 **产生多大的时延**(这取决于这些网络 **当时的拥塞情况**)，这些都是 **不确定因素**。  
  
            ** 3. 确认丢失**  
            B所发送的对M1的确认丢失了。A在设定的超时重传时间内没有收到确认，但并无法知道是自己发送的分组出错、丢失，或者是B发送的确认丢失了。因此A在超市计时器到期后就要重传M1。现在应注意B的动作。假定B又收到了重传的分组M1。这是应该采取两个行动。  
            第一， **丢失这个重复的分组M1**，不向上层交付。  
            第二， **向A发送确认**。不能认为已经发送过确认就不再发送，因为A之所以重传M1就表示A没有收到M1的确认。  
  
            ** 4. 确认超时**  
            传输过程中没有差错，但B对分组M1的确认迟到了。A会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃。B仍然会受到重复的M1，并且同样要丢弃重复的M1，并重传确认分组。  
            使用上述的确认和重传机制，我们就 **可以在不可靠的传输网络上实现可靠的通信**。像上述的这种可靠传输协议常被称为 **自动重传请求ARQ(Automatic Repeat reQuest)**。意思是重传的请求是自动进行的。接受方不需要请求发送方重传某个出错的分组。

### 1.1.2信道利用率分析 ###

停止等待协议的优点是简单，但缺点是信道利用率太低。其信道利用率下图。

![20130830205147578][]

在上图中，并没有考虑出现差错后的分组重传。若出现重传，则对传送有用的数据信息来说，信道的利用率还会更低。

为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用 **流水线传输**。流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地在传输。显然，这种传输方式可以获得很高的信道利用率。  
            当使用流水线传输时，就要使用下面介绍的连续ARQ协议和滑动窗口协议。

## 1.2 连续ARQ协议 ##

连续ARQ协议规定，发送方和接收方都要维持一个**发送或接收窗口**，窗口的大小通过协商确定为N（这里N=5）个分组的空间。发送方每收到一个确认就将发送窗口向前滑动一个分组的位置，如下图所示，现在可以发送第6个分组了。

![20130821220957734][]

接收方一般都是采用**累积确认**的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，**对按序到达的最后一个分组发送确认**，这样就表示：到这个分组为止的所有分组都已经正确收到了。

累积确认的方法容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息。

# 2. 可靠传输的扩展 #

上面讲述的是可靠传输的原理，对于应用层来说，关心的是分布式下的可靠控制。举个例子：A机器需要控制终端B执行动作，B的最终执行机构为机械部件。在这一个过程中，为了保证B能够正确的执行，如果去设计一个可靠控制过程，作为控制端的A同样需要B给出信号，以确认控制效果，同时作为控制端的A也同样需要考虑由于不可预料的情况导致的控制命令丢失，而采用的超时补救措施。

[Link 1]: http://blog.csdn.net/arau_sh/article/details/9904291
[_ _]: http://blog.csdn.net/arau_sh/article/details/9904649
[Link 2]: http://blog.csdn.net/arau_sh/article/details/10439891
[Link 3]: http://blog.csdn.net/arau_sh/article/details/10711785
[Link 4]: http://blog.csdn.net/arau_sh/article/details/11847887
[Socket_]: http://blog.csdn.net/arau_sh/article/details/12030951
[_ Socket_]: http://blog.csdn.net/arau_sh/article/details/12070053
[Socket_ --- _ _]: http://blog.csdn.net/arau_sh/article/details/12757095
[_ Socket_ --- _Linux_I_O]: http://blog.csdn.net/arau_sh/article/details/12888033
[Socket_ --- _Window_I_O]: http://blog.csdn.net/arau_sh/article/details/13769753
[Socket_ --- _Window_I_O 1]: http://blog.csdn.net/arau_sh/article/details/14056289
[20130821220720406]: /images/20230810/8b3b5ad305a84b2387f7b16efdf00a14.png
[20130830205147578]: /images/20230810/73f4d298589e4f0f94578d18d8dd2153.png
[20130821220957734]: /images/20230810/74ca56dd8e3f417c8e9704320e8fba69.png
[Link 5]: http://blog.csdn.net/arau_sh/article/details/8851666
[http_blog.csdn.net_arau_sh_article_details_10163193]: http://blog.csdn.net/arau_sh/article/details/10163193