阿华代码，不是逆风，就是我疯
你们的点赞收藏是我前进最大的动力！！
希望本文内容能够帮助到你！！
目录
一：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个字节那么每一个字节都会有一个相应的序号。由于这个序号是连续的，我们只要确定头序号，后面的字节通过计算就可以很容易拿到了
三：应答报文机制
数据发送出去了，那么以怎样的形式，告知发送方“哦，我收到了”~
注：应答报文——也叫ask报文（asknowledge缩写），通过应答报文来反馈给发送方，当前的数据收到了。
（1）过程梳理
A发送1-1000这个数据，主机B如果收到了，就会反馈一个“应答报文”——应答报文的序号是收到的数据的最后一个字节的序号+1。即从1001开始
注：这里的1001有两层含义
①告诉主机A：序号<1001的数据我都收到了
②主句A你下次应该给我发1001开始的数据了
（2）误区
确认应答机制是TCP“可靠性传输”的核心机制，并非是只要有确认应答机制就可以保证TCP可靠传输。
TCP的可靠传输是因为“进行了三次握手”这一说法是错误的（后续我们会详细解释）
四：超时重传机制
超时重传机制是确认应答的补充
1：发送方丢包
上文有说到，设备间进行通讯的时候需要经过，像路由器和交换机这种中间站，进行转发，我们知道路由器和交换机能处理转发的数据是由上限的，如果超过了负载上限，这个数据报包就会被丢弃 ，这就是我们说的“丢包”现象
2：超时重传
发送方发送完数据后，会等待接收方返回应答报文（不是无限制的等待~），迟迟等不到（超时）ask应答报文，发送方就会认为，这次发送的数据报包丢失了没有到达接收方，那么就会重新在发送一遍。
注：这里的重传次数也是有策略的
（1）重传次数有上限
假设数据传输到接收方的概率是90%，那么发送方发送两次数据发生丢包的概率就是10%*10%=1%。这种情况，此时就很可能不是丢包的问题了，可能是设备的问题，此时设备间就会重新连接，连接失败，就放弃连接了
（2）超时时间动态变化
超时时间会随着重传次数的增加而增大，（因为经历重传之后还丢包的话，大概率是网络的原因，在咋传也是白费力气，不如少传几次，节省力气资源）
3：接收方丢包
上述，我们得到一个结论（有问题）：如果发送方（主机A）没有收到ask,那么就认为发送的数据丢包了。
这里其实还有一些问题——到底是“发送的数据丢了，还是返回的ask丢了”。从发送方的角度是没有办法区分的。
（1）扣款情景引入
如果是主机A发送扣款数据，主机B完成扣款，并发送ask报文，但是ask丢失了，此时主机A迟迟收不到ask报文（超时重传），A再次发送扣款数据，完蛋了~，扣了两次款。
4：数据缓存
通过之前的socket的学习，我们知道socket在内存当中有一块缓存区（用flush冲刷解决问题那一篇文章）
对于接收到的数据都是先暂时放到缓存区中，攒一波，然后调用read或者scanner.next进行读取操作，这里读的就是接受缓存区中的内容。
这里的应答过程中，也有读取数据这一操作，这里的缓冲区主要有两个作用
（1）数据去重
当数据到达接受方的时候，接收方会先判断一下，缓冲区中是否已经有或者有过这个数据，如果yes，那么就把这个重复发来的数据就丢弃，确保应用程序不会出现重复的数据。
（2）数据排序
对接受的数据按照序号进行排序，保证应用程序中读到的数据顺序跟发送过来的数据顺序是一致的。
注：应用程序读的时候也是按照序号的先后顺序连续读取，可以想象成一个阻塞队列。
实现以上两个作用的核心是：数据有序号
