文章内容概览
倡议联合我的上一篇文章来看本篇内容：牢靠传输的基本原理
TCP 协定的牢靠传输
- TCP 的牢靠传输是基于间断 ARQ 协定的（对于 ARQ 协定，能够看我的上一篇文章）
- ARQ 协定中有两个重要的概念：滑动窗口 和累计确认。这两个概念在 TCP 的牢靠传输中同样实用
- TCP 的滑动窗口以 字节 为单位
假如有一段的字节流须要传输，滑动窗口的大小为 7，这里是为了不便了解，所以窗口设的很小，理论状况下的窗口是很大的。窗口中的 7 个字节示意都是能够传输的，窗口右边的是 曾经确认的字节序号 ，窗口左边的是 不容许发送的字节序号 。图中的 23 示意的就是对方期待接管到的下一个字节，其实也就是 TCP 首部中的 确认号 的概念
如果在某一个时刻 23~26 这四个字节曾经发送进来了，然而没有收到确认信息，这个就属于 已发送但未确认的字节 。而窗口中剩下的三个字节就属于 可用窗口，也就是后边三个字节是能够发送的。然而，因为发送进来的四个字节还没有收到确认，所以窗口还不能向后挪动。假如通过一段时间之后，收到了 23、24 这两个字节的确认信息，此时就能够将窗口向后挪动两个字节
假如窗口中的 7 个字节都曾经发送进来了，然而一个确认信息都没有收到，此时可用的窗口是 0，因为窗口中所有发送的字节都没有收到确认，这个时候，滑动窗口不能向后推动。这是理论可能存在的状况
假如窗口中的 7 个字节都曾经发送进来了，在某一个时刻，收到了 25 和 27 这两个字节的确认信息。能够发现，这种状况，确认信息并不是按窗口中字节的程序收到的，此时该怎么办？
首先能够晓得的是，23、24 这两个字节的确认信息是没有收到的，因而，窗口是不能往前推动的。假如当初超时工夫曾经到了，而 23、24 还没有收到确认音讯，此时会怎么办 ？这种状况下，即便 25、27 这两个字节的确认信息曾经收到了，然而， 此时还是会从 23 开始重传音讯，因为 23、24 的确认信息还没有收到。因而，超时之后，会从 23 开始重发消息，即便收到了后边字节的确认音讯也没有用，这个就属于 TCP 协定的牢靠传输
从上边能够晓得，如果窗口中的字节没有按序收到确认信息，那么超时之后就会对窗口中的字节进行从新发送。由此也能够看到，TCP 的这种牢靠传输，效率并不是很高，因为曾经收到了 25、27 这两个字节的确认信息，意思就是这两个字节是精确的达到了接管方的，然而因为 23、24 这两个前边的字节没有收到确认信息，超时之后，还是须要对 25、27 进行传输，这样就导致可重传的效率并不高。有没有方法能够进步这个效率？
抉择重传
抉择重传，顾名思义，就是 能够抉择一部分音讯进行重传，而不是将窗口中所有的音讯进行从新传输
抉择重传是如何进行工作的？
- 抉择重传须要指定须要重传的字节
- 每一个字节都有惟一的 32 位序号（这个在 TCP 首部中，抉择重传会指定这个 32 位序号是什么）
（倡议在看后边的内容之前，回看一遍 TCP 头部的内容，这样了解下边内容会更加的容易）
对于 TCP 首部，其实咱们晓得它并没有 存储抉择重传指定字节的地位 。每一个字节都有一个惟一的序号，所以在存储须要抉择重传的字节的序号时，也是须要消耗很多的空间的。因而， 在理论的抉择重传中，这个数据实际上是存储在 TCP 选项中的
在 TCP 协定详解的文章中有进行过简略的计算，晓得了 TCP 选项最多有 40 个字节。因为一个序号是占用 4 个字节，那也就是说，TCP 选项中最多能够放 10 个序号。那是不是示意， 抉择重传只能重传 10 个字节？
其实并不是的，在理解 TCP 的时候晓得，TCP 的报文，一次是能够传输很多个字节的，前边的例子次要是为了不便对 TCP 牢靠传输进行了解，才把每次能够传输的字节数设置的很少。对于理论的 TCP 传输，它一次能够传输上百或上千个字节
因而，这里边的序号并不是说抉择指定某一个字节的。因为，如果产生出错了，很可能整个 TCP 报文都失落了，这种状况其实就间断的丢掉一段的字节，因而，这里的抉择重传，更多的状况是对 一段字节 来进行重传的。所以这个时候序号所表白的意思，个别都是 须要重传的边界
看个例子，假如要传送 1000~3500 这么多字节的数据，把 500 个字节看做是一个 TCP 报文。假如 1000~1500 范畴字节的 TCP 报文失落了，这个时候就能够指定两个边界，别离是 1000 和 1500，将他们存储到 TCP 首部中的 TCP 选项 中，示意 1000~1500 这么多个字节，都是须要从新传输的。因而，此时 TCP 选项中的 1000 和 1500 并不是指重传 1000 和 1500 这两个序号的字节，而是重传 1000 到 1500 这个范畴中的所有字节
如果看完对你有帮忙，辛苦给个三连激励一下哦！