阿华代码，不是逆风，就是我疯

你们的点赞收藏是我前进最大的动力！！

希望本文内容能够帮助到你！！

目录

一：TCP协议（面试重点重点）

1：报头长度

2：保留位

3：六位标志位

二：TCP传输的可靠性

1：场景引入

2：数据后发先至问题

3：序号解决问题

三：应答报文机制

（1）过程梳理

（2）误区

四：超时重传机制

1：发送方丢包

2：超时重传

（1）重传次数有上限

（2）超时时间动态变化

3：接收方丢包

（1）扣款情景引入

4：数据缓存

（1）数据去重

（2）数据排序

---

一：TCP协议（面试重点重点）

引入：

8位（bit） = 1 字节（byte），8位就是01010111这样的二进制数字组成

1：报头长度

解释：①看报头部分，不算选项那一行（后面再讲）共计5行，每一行32位，换算为4个字节。那总共就是4 * 5 = 20个字节，这20个字节是固定长度（最小长度）

②另一种看法：因为4位首部长度是01这样的二进制数据 即范围为   0101（5）——>1111（15）;注意这里4位首部长度的单位是4个字节，不是1个字节。所以报头长度的动态波动长度就为5*4=20,15*4=60。即[20,60]。所以这里多出来的40部分可以理解为，就是为了给选项部分预留的空间。

即：报头长度最低为20字节，此时无选项部分，

2：保留位

像UDP这个协议，受到2个字节的限制，无法扩展，如果扩展就会与其他厂商的机器不兼容，

所以在TCP这里，预防TCP以后进行功能扩展，而保留一部分空间，（留个坑位）

3：六位标志位

可以理解为像UDP中检验和一样，把报头和载荷放到一起进行计算，后续会对里面的内容进行具体解释，后面这个图我们会多次用到

二：TCP传输的可靠性

在过去的学习中我们了解到，TCP传输的特点有：有连接，可靠传输，面向字节流，全双工。

其中最重要的机制就是“可靠传输”，在数据传输过程中，我们无法保证数据100%传达到对端，退而求其次，我们可以确认对端是否受到数据了，这样保住了传输的可靠性

1：场景引入

应答机制这是TCP传输中最核心的机制

试想这样一个情景，我给我的发消息女神表白，并邀请她去爬山

本来女神已经答应做我的女朋友了，但是由于“滚，不行”   这条回复信息  ，后发先至，比“好呀好呀”更快一步到达我这一端，导致我以为女神拒绝我了~~~这是一个悲伤的故事

2：数据后发先至问题

为什么会出现信息后发先至这种情况呢？

我们知道，广域网之间是由很多路由器和交换机连接的，那么数据在进行传输的时候就有很多路径可以选择，倘若先发出去的数据包①遭遇线路阻塞，那么很可能后发的数据包②会比①还要先到达另一端。

3：序号解决问题

我们通过加入序号这一形式，来确认应答的哪一条数据，这里的模型只是简化了一下，实际TCP序号和确认序号都是以字节来进行编号的，要复杂的多

假如载荷中有1000个字节那么每一个字节都会有一个相应的序号。由于这个序号是连续的，我们只要确定头序号，后面的字节通过计算就可以很容易拿到了

三：应答报文机制

数据发送出去了，那么以怎样的形式，告知发送方“哦，我收到了”~

注：应答报文——也叫ack报文（acknowledge缩写），通过应答报文来反馈给发送方，当前的数据收到了。

（1）过程梳理

A发送1-1000这个数据，主机B如果收到了，就会反馈一个“应答报文”——应答报文的序号是收到的数据的最后一个字节的序号+1。即从1001开始

注：这里的1001有两层含义

①告诉主机A：序号<1001的数据我都收到了

②主句A你下次应该给我发1001开始的数据了

（2）误区

确认应答机制是TCP“可靠性传输”的核心机制，并非是只要有确认应答机制就可以保证TCP可靠传输。

TCP的可靠传输是因为“进行了三次握手”这一说法是错误的（后续我们会详细解释）

四：超时重传机制

超时重传机制是确认应答的补充

1：发送方丢包

上文有说到，设备间进行通讯的时候需要经过，像路由器和交换机这种中间站，进行转发，我们知道路由器和交换机能处理转发的数据是由上限的，如果超过了负载上限，这个数据报包就会被丢弃 ，这就是我们说的“丢包”现象

2：超时重传

发送方发送完数据后，会等待接收方返回应答报文（不是无限制的等待~），迟迟等不到（超时）ack应答报文，发送方就会认为，这次发送的数据报包丢失了没有到达接收方，那么就会重新在发送一遍。

注：这里的重传次数也是有策略的

（1）重传次数有上限

假设数据传输到接收方的概率是90%，那么发送方发送两次数据发生丢包的概率就是10%*10%=1%。这种情况，此时就很可能不是丢包的问题了，可能是设备的问题，此时设备间就会重新连接，连接失败，就放弃连接了

（2）超时时间动态变化

超时时间会随着重传次数的增加而增大，（因为经历重传之后还丢包的话，大概率是网络的原因，在咋传也是白费力气，不如少传几次，节省力气资源）

3：接收方丢包

上述，我们得到一个结论（有问题）：如果发送方（主机A）没有收到ack,那么就认为发送的数据丢包了。

这里其实还有一些问题——到底是“发送的数据丢了，还是返回的ack丢了”。从发送方的角度是没有办法区分的。

（1）扣款情景引入

如果是主机A发送扣款数据，主机B完成扣款，并发送ack报文，但是ack丢失了，此时主机A迟迟收不到ack报文（超时重传），A再次发送扣款数据，完蛋了~，扣了两次款。

4：数据缓存

通过之前的socket的学习，我们知道socket在内存当中有一块缓存区（用flush冲刷解决问题那一篇文章）

对于接收到的数据都是先暂时放到缓存区中，攒一波，然后调用read或者scanner.next进行读取操作，这里读的就是接受缓存区中的内容。

这里的应答过程中，也有读取数据这一操作，这里的缓冲区主要有两个作用

（1）数据去重

当数据到达接受方的时候，接收方会先判断一下，缓冲区中是否已经有或者有过这个数据，如果yes，那么就把这个重复发来的数据就丢弃，确保应用程序不会出现重复的数据。

（2）数据排序

对接受的数据按照序号进行排序，保证应用程序中读到的数据顺序跟发送过来的数据顺序是一致的。

注：应用程序读的时候也是按照序号的先后顺序连续读取，可以想象成一个阻塞队列。

实现以上两个作用的核心是：数据有序号