【计算机网络系列】TCP 可靠传输原理

秒速五厘米 2023-01-05 12:55 150阅读 0赞

# TCP 可靠传输原理 #

## 概念 ##

可靠传输

*  简单的说，可靠传输就是无差错传输。即，所有发送的数据都能被无差错接受。都具有差错检测的能力。
 *  无差错接受是指只接受没有传输错误的数据，丢弃或更正所有在传输过程中发生错误的数据。
 *  因此，发现传输过程中可能发生的各种错误是可靠传输的基础。这种发现错误的能力称为差错检测。
    
     *  差错检测：具有发现传输过程中可能出现的各种差错的能力，即从发送到接受的传输过程的各个阶段

差错检测和控制

*  差错检测和控制在差错检测中，有纠错码和检错码两种不同的编码校验技术。
 *  检错码
    
     *  发送前：发送端计算检错码，并与数据同时发送。接收端能够检测出传输过程中出现的数据差错，但不能确定发生错误的位置，也不进行错误纠正。编码效率高，译码速度快。
     *  到达后：接收端进行校验。若无错，则确认；否则要求重新发送。
 *  纠错码
    
     *  也称为前向纠错（Forward Error Correction ，FEC ）。接收端能够检测出传输过程中出现的数据差错，并能确定发生错误的位置，可以进行错误纠正。编码效率低，译码速度慢。一般用于不可重传的场合。
     *  发送前：发送端计算纠错码，并与数据同时发送；
     *  到达后：接收端进行校验。若有错则进行纠正。纠错码的编码效率低是因为需要比检错码长的多的编码才能拥有确定错误发生位置的能力。因此在相同长度的编码中，真正的数据部分占的比例远比检错码少。

可靠传输：

*  在不可靠的信道上实现可靠传输，需要达到以下条件
    
     *  各数据位无差错
     *  数据顺序与发送端保持一致
     *  无数据重复
     *  无数据丢失
 *  要达到上述条件，需要采用以下技术：
    
     *  差错检测
     *  数据编号、数据确认、数据重传

## 停止等待协议 ##

简单流控

*  假设：
    
     *  传输过程中不会出错
     *  接收端不保证总能及时接受发送端发出的数据
 *  流量控制
    
     *  基本思想：由接收端控制发送端发送数据的速度
     *  这种思想是现代网络中各种流量控制方法的基础。

基本流控：

*  发送端
    
     *  （1 ）等待从上层应用中获得数据
     *  （2 ）获得数据并封装成可发送的数据报文
     *  （3 ）发送报文，等待接收端的确认报文转（1 ）
 *  接收端
    
     *  （1 ）等发送端发送数据
     *  （2 ）获得数据并转交到上层应用
     *  （3 ）向发送端发送确认报文，转（1）
 *  对比
    
    ![image-20210104155156661][]
    
     *  显然，具有简单流量控制的停止等待协议不会由于来不及接受而丢失数据，但其通信效率极低。

有差错的流控

*  在不可靠的信道中，假设不会丢失报文，则对应的停止等待协议算法：
 *  发送端
    
     *  （1 ）从上层获得数据并计算校验码，封装报文并缓存。
     *  （2 ）发送报文并等待接收端应答报文。
     *  （3 ）收到接收端应答报文。若肯定，删除缓存并转（1 ）；若否定，提取缓存数据报文并转（2 ）。
 *  接收端
    
     *  （1 ）等待并获得发送端发送的报文，缓存并校验。
     *  （2 ）若校验错，删缓存并发否定报文，转（1 ）；若校验正确，上交缓存并删缓存，发肯定报文，转（1 ）。
 *  对比
    
    ![image-20210104155619702][]

有报文丢失的流控

*  无论是数据报文（发送端发送）还是应答报文（接收端发送），都有可能在传输过程中丢失。
    
     *  若数据报文丢失，接收端未收到数据报文，等待发送端发送。
     *  若应答报文丢失，发送端未收到应答报文，等待接收端发送。
     *  上述两种情况，都会使发送端等待接收端发送应答报文，而接收端等待发送端发送数据报文。
 *  死锁
    
     *  解决死锁的办法
        
         *  设置重发计时器发送端在发出报文后即启动重发计时器
         *  若在设置的时间  t o u t t\_\{out\} tout 内未收到接收端的应答报文，则认为报文已丢失，从而重发报文。
         *  通常， T o u t T\_\{out\} Tout 略大于 报文平均往返时间 。
     *  采用超时重发后可能的结果
        
         *  如果是数据报文丢失：接收端只接收到一次正确的报文
         *  如果是否定应答报文丢失：接收端只接收到一次正确的报文
         *  如果是肯定应答报文丢失：接收端接收到二次正确的报文（重复报文）

对停止等待协议的改进（针对采用重传计时器后出现的新问题）

*  对报文编号，接收方对收到的报文进行编号重复检查，丢弃编号重复的报文，从而解决重复报文的问题。
 *  接收方不再发送否定应答报文，只对无差错的数据报文发送肯定应答报文（并改名为确认报文）。对于有差错的报文，由于没有收到确认报文而超时，导致发送方重发该报文。
 *  在确认报文中添加确认信息，以明确被确认的报文。
 *  接收方收到重复报文后，在丢弃重复报文的同时，也要向发送方发出针对该重复报文的确认报文。
    
    ![image-20210104160818098][]

改进的停止等待协议中的报文序号

*  序号会消耗通信资源，序号越长消耗的资源越多。由于只需要区分前后报文，在停止等待协议中报文序号只需要一位即可。
 *  （1 ）发送方变量V(S)：
    
     *  序号V(S)-1 的报文已经得到确认。
     *  发送一个尚未得到确认的报文后， V(S)= 期望得到确认的报文序号
     *  发送的报文得到确认后， V(S)= V(S)+1 （模2 加），为下一个报文的序号。
 *  （2 ）接收方变量V®
    
     *  希望收到的下一个报文的序号
     *  若 V® 等于收到报文的序号，发出对该报文的确认， V®=V®+1
     *  若收到的报文序号不等于 V®

信道利用率

*  停止等待协议的最大优点是 简单 ，最大缺点是 信道利用率极低 。
    
    ![image-20210104162308052][]

改进后的停止等待协议总结

*  只要传输层采用有效的检错重传机制，可以在不可靠的网络上为应用层建立可靠的传输服务。
 *  每个报文发送后均需暂时缓存，以备重传。
 *  超时计时器的阈值应该适当大于数据传输的平均往返时间。
 *  由于具备了超时自动重传的能力，改进后的停止等待协议也被称为**停止等待自动重传请求协议**（Automatic Repeatre Quest ，ARQ ），简称停等ARQ 协议。

## 连续ARQ 协议 ##

概念

*  发送方可连续发送多个报文，不必每发完一个报文就停止并等待接收方的确认。也被称为流水线传输。
 *  流水线传输
    
    ![image-20210104162911751][]
    
     *  发送方在TD +RTT+TA 的时间周期内不必每发送一个报文就等待接收方的确认，而是连续的发送多个报文。
 *  有很高的信道利用率
    
    ![image-20210104163323273][]
 *  代价
    
     *  发送方要准备好n 个缓冲区，用于暂存n 个报文，以备重发。只有收到针对某报文的确认后，相应的缓存报文才能删除。
 *  问题：在信道利用率优先的前提下，n 取多大比较合适？
    
     *  一方面：随着n 的增大，信道利用率会随之提升。但是，当n 达到一定值后即不能再增大，因为TD 有相对固定的值。
     *  另一方面：由于信道利用率不会超过100% ，因此在n 达到某个值之后，信道利用率不可能继续提高
     *  同时：n 的增加也意味着缓冲区的增加，成本也随之上升。

报文序号

*  为了能够区分尚未确认的报文，需要有更多报文序号。
    
     *  通常，如果n=N ，则序号范围为0~N ，共n+1 个序号。
     *  例：如，n=5则，序号的范围为0~5 ，n=N因此，需要三位序号编码序号可以从0~7
 *  序号的生成采用循环方法。
    
     *  在不可靠的网络中，由于超时造成的重复确认包可能会对已经发生循环的序号产生误认。
     *  在不可靠的网络中，为了避免由于超时造成序号产生误认，序号的范围需要有更大的取值范围。

GO-Back-N 的连续ARQ

*  在返回N 协议(GO-Back-N GBN) 中，接收方只接收按序到达的正确报文。在发送方等待确认时，有多个报文正在传送中。也就是说，让多个报文处于等待确认的状态，以便在发送方等待确认的同时，信道也能保持忙碌状态。
    
     *  如果接收方正在校验的报文出错或丢失，则发送方重传这个出错的报文以及其后所有已经发送的报文。
     *  在返回N 协议中，发送方为所有已经发送但尚未确认的报文进行缓存，直到被确认。接收方只缓存当前正在校验的报文即可。
 *  特点：控制简单；缓冲区较少（发送方N 个缓存，接收方1 个缓存）。
 *  例：如果发送方已经发送了前5 个报文，若中间的第 3 个报文丢失或校验出错，则接收方只会对前两个报文发出确认。发送方需要重发后面三个报文。极端情况是重发全部5 个报文。

滑动窗口

*  滑动窗口（Sliding window ，SW ）是一种流控方法，用于约束发送方可发送报文的数量。窗口是指发送方最多可发送未被确认报文的数量，而滑动则是指每收到一个确认报文，窗口可向前滑动一个报文，从而纳入新的待发送的报文。
 *  停等ARQ 协议是连续ARQ 协议窗口为1 的特例

应答机制改进

*  捎带应答
    
     *  收到正确报文时若有数据报文发送给对方，则在数据报文中应答。若一定时间内没有数据报文给对方，则发送应答报文。
     *  捎带方式在数据报文首部增加应答字段N® ，表示对报文序号为N®
 *  累积应答
    
     *  不必对每个收到的数据报文都应答在收到一定数量的正确报文后再对最后一个收到的正确报文进行确认应答，表示到这个报文为止所有的报文都正确。
     *  通常与捎带应答结合使用无数据报文时暂不应答。
     *  收到正确报文后的一定时间内至少应答一次避免对方因为超时而重发正确报文。
     *  累积应答的优点是简单，容易实现，即使确认丢失也不必重传；缺点是不能及时反映接收已经接收到的正确报文。

[image-20210104155156661]: /images/20221119/cd10b495766943a5a678282e73759840.png
[image-20210104155619702]: /images/20221119/03efae6f11c94bef8efd5fb07f529ef3.png
[image-20210104160818098]: /images/20221119/e66917cc519e48929e6da356cb8932e9.png
[image-20210104162308052]: /images/20221119/f51d5901bca5477c9096796e1626e27c.png
[image-20210104162911751]: /images/20221119/32642b515d5c4c5ab86059fd405f51de.png
[image-20210104163323273]: /images/20221119/f70ecf745a1f44be830233d7b2243c2a.png