一、TCP协议

每一行是四个字节，前面的20个字节是固定的（TCP最短长度，20字节，选项部分：有/无都行，当然了你有多个也行）

4bit表示的范围0——15 此处的单位是4字节🌸 ，所以要把这里的数值*4，才是真正的报头长度TCP，最大的长度60字节。

保留六位的六个标识位：resvered设计TCP大佬比设计UDP的大佬，留个心眼，虽然现在不用，但是先占有个位置，后面可能需要用（目前TCP这么多年大概不用了 🌸 ）

二、TCP核心特性的保障

TCP核心特性：有连接，可靠传输，面向字节流，全双工
可靠传输：内核实现的可靠传输，写代码的时候，感知不到（人本身就是这么设计，让感知成本，使用成本降低）🌻

网络传输中：常常会遇到那种后发先至（当连续发送多条信息的时候）🌻

网络上从A到B中间路径有很多（初心，冗余，让他不怕核弹这种，一个弹过来影响通讯）

比如：舔狗狗哥舔女神

问女神吃不吃麻辣烫呀？愿不愿意做我女朋友啊？

女神先回我：好的好的。😃 滚一边去，下头男啊🌚🌚🌚

结果后发先至，😍虽说没有吃麻辣烫，但是做我女朋友也挺好。（🤠小丑）。

另外每个节点/路由器/交换机/繁忙程度不一样，此时，这样的转发过程，也会存在差异。

那么我们该怎么办呢？

针对数据进行编号

TCP是面向字节流，不是按照条为单位进行传输的。

确认应答的意思，假如说应答下一个数据1001，就说明（1-1000）之前的数据全收到了，下面该从1001开始发。

1.针对字节进行编号的，而不是针对条

2.应答报文也是要和收到的数据序号相关联而不是相等。

只要知道这一串字节的开始编号，以及数据的长度，每个字节的编号也就知道了，TCP报头中，把这一串字节的编号表示出来，再结合报文长度，此时每个字节编号就都确定了。

编号也就是那个32位序号

32位确认序号——这个字段是给应答报文使用的，假如超越了32位，就开始从头计算，4个字节->42亿9千万，4个G,一般也不会一口气传4G

三、保留的六位标志位对于应答报文的作用

保留的六位具体是

那么对于应答报文是怎么样呢🐳🐳

ACK为0，表示这是一个普通报文，此时只有32位序号，是有效的

ACK为1，表示这是一个应答报文，这个报文的序号和确认序号都是有效的->确认报文的序号和正常报文，之间没有关联关系，各自论各自的，序号是你自己的主机发送的数据进行编号。

数据1-1000，序号1，长度1000，确认序号无意义，ACK为0

下一个返回确认报文1001，序号未知，假设是100（这个序号根发送序号没啥关系），长度不知道，确认序号是1001，ACK是1->应答报文可能携带载荷，也可能没有。

下一个传输应答的时候，应答是应答的序号，与发送的序号无关，上个应答序号是100，这个应答报文就应该是101，序号未知。

确认应答，是TCP保证->IP协议的报头中，可以知道载荷多长的，IP载荷长度——TCP报头长度->TCP载荷长度

如果设备过于繁忙，后来新来的等待的太久，就可能会被丢弃，越忙越容易丢包。

面对丢包，我们的应对机制是什么呢？，难道丢包就不可靠了吗？

四、如何处理丢包——超时重传的原理

这个问题最大的就是：无法区分是哪种情况，既然无法区分，那就都重新传输呗。但是也不能随意去重啊。你想想一个问题，你转50块钱，就算你没收到，我发出去了啊，我再发一个50，那不就亏了50嘛（任何问题一用钱💰🤬🤬考虑都好过分）接收方收到数据之后，需要对数据进行呢去重，把重复的数据丢弃掉，保证应用程序，调用inputStream的时候，读到的不会出现重复，如何进行去重？如何高效判定当前数据是否重复，直接使用TCP的序号，来作为判定依据

->TCP在内核中，给每个socket对象都安排一个内存空间，相当于一个队列，也称为“接收缓冲区”，收到的数据，都会被放到缓冲区里，并且按照序号排列，已经排好序了。

（这里又是一个生产者消费者模型，收到数据，接收的网卡，把数据放到对应socket的接收缓冲区内核中）

应用程序，调用read，就是从这个接收缓冲区中，消费数据，当数据被read走后，就可以从队列中删除掉了（read有两种模式，读到就删除，也可以读到不删除）-》接收缓冲区，数据按照序号有序排列～队列队首序号已经超过了新收到的这个数据的序号，新收到的序号在之前被读过了

以下是去重的思想：假如给B发一条序号为100，B成功收到消息后，并返回101作为确认，然后确认的消息发生了丢包，你不知道消息是否到达，所以你进行了重新发送，序号仍为100，确保B能正常接收，但是由于B之前已经读完了那个主机A的内容，所以他会帮你进行一个去重（注意不是根据内容去重的哈🌝🌝）

后发先至的这个问题，是根据序号重新排列的过程，因此应用程序不必考虑数据传输先后的顺序问题。

五、超时重传的时间

为啥我们重新传输的时候就能够传过去呢？（这就如同电脑重启，丢包的本质是概率问题）重传的次数增加，总体传输的成功概率也就越大，高中算数，一个丢包0.1概率，连着丢10的概率很低的。

超时时间当然也不是一个固定的值，（这段时间一直传不过去，就不传了这种），是会随着超时轮次的增加，进一步增加

随着转轮次数的增加，等待时间也会越来越长，当前认为，正常情况下，第二次重新传输有极大情况，重传成功，如果很多次都不成功，那就有可能当前的网络有故障。

超时重传的轮次也不是无限的，重新传输到一定次数，会重置TCP连接。使用复位报文

TCP复位报文

RST，那个六位里面的

RST为1，表示一个复位报文-》除非严重的故障，复位操作也无法成功，最后只好放弃连接。

确认应答是TCP可靠最核心的机制

超时连接是TCP可靠性的有效补充