一、什么是可靠传输
可靠传输的意思是数据发送端发送什么数据，数据接收放就接收到什么数据，没有出现分组丢失、差错、重复、乱序等情况。由于计算机网络的分层结构，数据的可靠传输由运输层的TCP协议来完成。这里注意区分一点是数据链路层的差错检测仅仅是检测比特差错，而可靠传输所讨论的范围大多数是分组是否丢失、出现差错、重复或乱序的问题。所以运输层的可靠传输要区别于数据链路层的差错检测所讨论的 比特差错对应的“可靠传输”
二、可靠传输的工作原理
我们知道，TCP发送的TCP报文段是交付给网络层传送的，但是网络层只提供最大努力交付。也就是说TCP下面的网络都不支持可靠传输，所以TCP要采取适当措施(协议) 才能使通信主机之间的运输层实现可靠传输。
在理想的情况下，1.信道不产生差错、2.不管发送放以多快的速率发送数据，接收方总能来得及处理接收到的数据。在这两种条件下即可自动实现可靠传输。第二点可以通过协议来进行控制。
在介绍TCP可靠传输的实现之前，先用两种实现可靠传输的协议来理解一般的可靠传输是如何实现的，之后再进一步延伸到TCP可靠传输的实现
1.停止等待协议
原理：每发送完一个分组就停止发送，等待接收方的确认，在收到接收确认之后再发送下一个分组。
注意：(运输层传送的协议数据单元是报文段，网络层传输的协议数据单元是IP数据报，但在讨论一般问题的时候可以都称为分组)
采用停止等待协议实现可靠传输会出现以下三种情况：无差错情况、出现差错(发送端)、确认丢失和确认迟到(接收端)
- 无差错情况与出现差错示例图：
对于无差错情况，A向B发送数据分组M1，B收到后向A发送M1确认报文；A收到M1确认报文之后，再发送M2，B收到后向A发送M2确认报文，以此类推。
对于出现差错的情况，A发送的M1被B在接收的时候检测出分组由差错，B就将M1丢弃，然后什么也不干；可靠传输协议是这样设计的，在A发送报文之后会设置一个超时计时器，当分组发送之后超过了计时器规定的时间而还没有接收到来自接收端的确认报文之后，发送端意识到要么发送的分组出现差错，要么发送的分组丢失了。这个时候发送端将重新发送分组(超时重传)。
- 确认丢失与确认迟到示例图：
对于确认丢失指的是当A发送分组M1到达B之后，B向A发送了确认报文(说明B已经收到分组)。但是就是这个时候，确认报文在发向A的过程中丢失了。由于超时重传机制，A因为没有收到M1的确认报文而再次向B发送M1分组。这个时候B的处理是将这个重复分组M1丢弃，并且向A发送分组M1的确认报文。直到A发送下一个分组M2，否则一直循环。
对于确认迟到指的是A向B发送分组M1，B接收到之后发送M1的确认报文，但是在回送的过程中回送时间超过了超时定时器所规定的时间，A就以为B没有收到M1分组，然后又向B发送一遍M1分组。这时候B的处理是将重复的M1分组丢弃，重新回传M1的确认报文(因为B知道A没有收到M1的确认报文，才又发了一遍M1)。A收到M1的确认报文之后，接着发送M2分组，就在发送M2之后，迟到的第一次M1确认报文才姗姗来迟。这个时候A对于来迟的M1报文(重复报文)的处理是手下确认报文，但是什么也不做。
- 提高信道利用率
停等协议解决可靠传输的优点是简单，但是信道利用率太低了。为了提高传输速率，发送方可以不使用低效率的停等协议，而采用流水线传输。流水线传输的方式是发送方可以连续发送多个分组，不必发送完一个分组之后就停下来等待接收端的确认
向上面的停止等待协议中对可靠传输的各种处理方式也被称为自动重传请求(ARQ),重传请求是自动进行的，不需要接收方通知发送方重传分组。
2.连续ARQ协议
连续ARQ（Automatic Repeat reQuest）协议指发送方维持着一个一定大小的发送窗口，位于发送窗口内的所有分组都可连续发送出去，而中途不需要等待对方的确认。这样信道的利用率就提高了。而发送方每收到一个确认就把发送窗口向前滑动一个分组的位置。
接收方一般都是采用积累确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止前面的所有分组都已正确收到了。
但是接收方的确认机制会有一个缺点：传输的数据是
1 2 3 4 5
当中间的3号分组丢失了，接收方收到的是
1 2 4 5
这时候接收方只能确认前面的分组1和分组2，发送确认1和2的确认报文回给发送方；丢失的分组3以及后面的4和5接收方不会向发送方发送信息说3 4 5的下落。但是接收方要接收的数据是要连续的，所以这种情况下的差错处理出现了两种解决方式：GBN(回退N帧协议)和SR(选择重传协议) 这两种协议都是在连续ARQ协议下处理差错的方法。区别如下：
GBN协议的做法是出现上述的差错时，发送方将发送窗口中的全部分组重新发送一遍；而SR协议的做法是只重传出现差错的数据分组；也就是说已经确认收到的分组就不用再发送了，只需要发送端重新发送出现差错的分组即可。GBN在网络延迟较大的情况下会导致大量的数据重传。
3.TCP可靠传输的实现
TCP基于以字节为单位的滑动窗口来实现可靠传输
TCP实现可靠传输的机制：校验、序号、确认、重传；
简略过程的视频解答：王道计算机网络 -- TCP可靠传输 (但是有些问题没有讲解清楚，发送报文迟到的问题)
- 序号机制
TCP是面向字节流的。对于一个要发送的文件或者其他数据，数据的第一个字节序号是多少可以随意规定，但是要保证相对有序(一个字节占用一个序号)。虽然TCP是面向字节流的，但是TCP在进行数据传输的时候会将字节流分为大小不一的报文段进行发送。基于序号就会有确认和重传机制，用于保证数据可靠传输
- 确认机制
当第一个报文段从发送端发送出去，接收端接收到了之后，接收端就会向发送端发送一个确认报文段。确认报文段中首部确认字段为期待下一次发送的数据的序号，同时确认字段也代表着序号之前的报文段已经被接收。
这里还需要注意一点就是，当报文段发送出去之后，发送方不会立即将发送缓存中的报文段删除(相当于留了一份副本，这个副本用于当传输网络出现问题时重传使用)，而是等到收到接收方的确认报文段之后才删除。
TCP默认使用的是累计确认，当发送报文段像下面这样由于路由选择的原因迟于其他报文段时(分组转发的话分组可以通过不同的路由到达接收端)，没有按序到达的报文接收端照常接收，但是接收端向发送端发送的确认报文首部确认序号是迟到的报文序号4，意思是接收端还没有收到序号4的报文，请求发送端再发送。发送端接收到确认报文后发现报文段首部确认号仍为4，这时候发送端知道自己发送的序号为4的报文接收端没有收到，之后重传序号为4的报文段。接收端收到后将因迟到重发的报文段按序插入TCP缓存中，随后向发送端发送确认号字段为9的确认报文。(这里有个问题：如果迟到的报文段在发送端重发并且接收端已经收到了重发的报文段后，迟到的报文段又到了这时候该怎么办？应该是直接丢弃吧)
-
重传机制
确认和重传不分家。TCP在规定时间内没有收到确认报文就要重传已发送的报文段，这种做法叫做超时重传
但是超时重传机制有个问题，超时所设置的时间如果动态变化变得过长的话，就会白白等上一段时间。这时候的解决方法就是利用接收端返回的确认报文中的确认字段(接收端期待下一个报文数据的序号)，当发送端连续收到接收端发回来的确认报文中确认字段都是同一个序号到达三次，发送端就立即明白接收端对于这个确认字段序号的报文没有收到，这时候就立即重传而不用等到超时重传再重传报文。这三次对于某个序号的确认报文称为冗余ACK(冗余报文) 。
举例来说，首先要明白分组转发不是沿着同一个路径来的，而是可以根据路由选择动态地选择路径到达接收端 。从第一次收到确认报文起，后面的三次确认字段都是2，后面这三次才是一次冗余ACK。(这里再解释一下，确认报文的确认字段是收到的报文段尾部序号n+1，比如收到的报文段是1 2 3，那么返回的确认报文确认序号就是4(这就是“期待发送的序号”的由来，既起到了确认作用，又发挥了指引期待作用))，，有四条路径的数据到达接收端时就可以连续发送冗余ACK，相比于超时重传快 -- 这种做法也叫快速重传。
这里做个我觉得的拓展，相对于停等协议确认报文丢失的情况，快速重传可因为分组分为多路径到达的情况,向发送端发送冗余ACK的做法更容易处理因确认丢失而导致发送端再重传一次报文的问题。停等协议是一个个报文发送，达不到冗余ACK形成的要求 ，TCP得益于滑动窗口机制一窗口一窗口发送分组使冗余ACK得以实现。
\
