网络原理一＞TCP协议详解,一文搞懂几大核心机制,连接管理，粘包问题，超时重传，延时应答等等

UDP和TCP都是应用层中的重要协议，如果做基础架构开发，会用得多一些。 这一篇我们聊一下TCP协议，TCP我们通过其几个核心机制来进行阐述

TCP协议的结构图： 我们知道TCP是一种有连接，面向字节流，全双工，可靠传输特性的网络协议。 TCP我们就是围绕，可靠传输来展开的，要实现可靠传输肯定有很多机制。

一.TCP部分简单的结构说明：

1.源端口和目的端口： 我们知道端口号标识了一个主机上进行通信的不同的应用程序，在应用层上的 要想进行一次通信，就必须涉及 “五元组”--->源端口，目的端口，源IP，目的IP，协议号 这里的源端口和目的端口号，就是应用层的核心内容

2. 4位部首长度 和 选项： 占4个比特位，表示TCP协议报头的长度 选项部分的存在导致TCP报头是，可变的

3.保留位： UDP长度不可变，但是TCP设计就很注意这一点，保留位先不用就是先占个位置

4.TCP6个标志位： TCP6个标志位是TCP协议最核心的部分，标志了建立连接断开连接，和一些状态包等等，下面讲解TCP核心机制时会具体展开。

5.校验和： 校验数据是否修改的手段 为了防止，传输过程中的比特翻转 比特翻转就是传输过程中，光电信号或者电磁波二进制信号，从0->1, 1->0

6.怎么用校验和来判断是否发生比特翻转呢? 首先发送之前，通过数据包中的数据，先计算好一个校验和，然后把校验和连带整个数据报的数据都发送到对端； 对端通过接受到的数据，再算一遍校验和，一比对，如果发现校验和不一样就发送了比特翻转，就丢弃这个TCP数据报。 补：校验和是通过CRC (循环冗余校验)的简算法来校验的，会有比特翻转其实也是小概率事件。

二. TCP十大核心机制：

TCP的可靠性，是尽可能让对端收到信息，但是不是100%

核心机制之一确认应答： TCP给传输的数据进行编号，需要接收方返回一个应答报文，来确认传输是否可靠 TCP6个标志位中 ACK标志位为 1 就表示这个是个应答报文。 1.1. 32位确认序号和32位序号： TCP是面向字节流，所以编号时候是按照字节为单位，每个字节分配一个序号一次递增

1.2. 32位确认序号填法： 把收到的载荷最后一个字节的序号加1返回填到确认序号中，下次从这个序号开始发送

核心机制之二超时重传： 超时重传是针对丢包的情况做出处理，网络上传输数据报是有时间限制的，为网络错综复杂 数据包，数据包太多会导致路由器转发不过来，接收缓冲区满了就丢包了。

2.1.丢包情况： 第一种：传输的ack丢了 第二种：发送的数据丢了 发送方区分不了是哪一种情况都是进行重传

第一种情况，B端收到了两个相同的数据，这里不用担心排序也会同时进行

注意这里纠正一下网上资料的错误： TCP可靠传输的关键机制是三次握手和四次挥手->这个说法是错误的。 正确的是：TCP可靠传输的关键机制是确认应答和超时重传

核心机制之三连接管理： 建立连接 -->三次握手；断开连接 --> 四次挥手

3.1.三次握手： 三次握手通俗说就是发送一个和业务不相关的数据，来和对方打招呼要求和对方建立关系。 在和对方建立连接，就需要和对方同步的保存数据，这个就是依靠TCP6个标志位中 syn 标志位为 1 就表示

三次握手过程理解图：

详细状态图： listen状态，启动服务器时候就有 established状态，表示连接建立完成

三次握手的作用： 1.投石问路，确认网络通信是否通畅。 2.验证双方发送能力和接收能力是否正常 3.协商一些关键信息 (序号从多少开始)

3.2.四次挥手： TCP6个标志位中 fin 标志位为 1 就表示挥手数据报。 断开连接过程：

四次挥手可以变成三次挥手吗？ 不能，以为中间的ACK和FIN，两次交互是不同的。 这里ACK在内核进行的； 而这里发FIN是在程序员写的应用程序触发的

四次挥手具体状态图：

谁主动发起FIN，谁就进入TIME_WAIT状态 谁被动发起FIN，谁就进入CLOSE_WAIT状态

CLOSE_WAIT状态：就是应用程序代码等待你调用CLOSE方法。 也就是你的hasNext,到调用close之间，就是CLOSE_WAIT状态

这里如果你的服务器，大量的处于CLOSE_WAIT状态那可能就是出bug了

TIME_WAITE状态 : 就是防止四次挥手丢包问题 这里最棘手就是最后一个，ACK丢了, A主动释放了连接，B收不到ACK就会一直发FIN

这里TIME_WAITE状态就是，让A端多等待一行，确认B没有重传FIN再释放连接。

核心机制之四 滑动窗口： 可靠传输保证了，那效率还没有得到改善，滑动窗口就是针对效率进行改善 滑动窗口就是把，发送的数据，分为一大份一大份来发，就可以用一份等待ACK的时间，发多份提升效率

传输过程中也会丢包 情况一：发送的ACK丢了是不用管的，因为后一个ACK涵盖前一个ACK的信息

情况二：发送的数据丢了，会触发快速重传，快速重传就是只管把丢掉的数据，重新传输即可。 注意：超时重传是发送数据少的情况，快速重是一次发送数据多的时候也就是滑动窗口时会触发

核心机制之五.流量控制： 滑动窗口，窗口越大效率越高，但是不能无限大，太大可靠性就无法保证

流量控制就相当于一个蓄水池，控制进水速度来控制整个流量；在TCP中可以根据接收方的处理速度，来控制发送方的速度。

流量控制依赖于，TCP中16位窗口大小 上面的蓄水池就相当于，接收缓冲区，根据接收缓冲区剩余空间的大小，把这个大小填入TCP16位窗口大小 属性当中。

16位窗口大小的空间大小： 大小最大并不是64kb，而是指数型的增长，理论来说，最大值为2的16次方减一这么大，但是实际上TCP“选项”属性那里有，窗口扩展因子，可以扩展16位窗口大小，远远大于2的16次方

注意：这里如果窗口大小为0，发送方会发一个，窗口探测包，为了触发ACK看看接收方怎么样了 （接收缓冲区的情况还是要依靠接收方的ACK告知，不然发送方不知道缓冲区情况，就不发做出正确的流量控制！）

核心机制之六. 拥塞控制： 拥塞控制就是根据，传输链路的某个设备的转发能力进行限制； 如果不好看某个设备，就以整个设备作为整体，以做实验的方式进行展开

做实验就是：先按照小的窗口来转发数据，如果出现丢包，就减小窗口，没有丢包就加大窗口

大概描述： 先慢启动窗口大小以指数型增长，窗口大小到一个初始值ssthresh，会改变为线性增长，出现丢包的时候就会减小窗口大小，重新慢启动，经过多次这样后，下次丢包不会重新慢启动，而是根据上一次初始值ssthresh，进行线性增长，再经过这个流程多次，最后窗口大小区域稳定。

核心机制之七.延时应答： 一般来说，接收方收到数据报第一瞬间会返回一个ACK，但是我们先不返回ACK，先让接收缓冲区消耗一些数据，再返回ACK，可以提高一定效率。

核心机制之八.捎带应答： 返回业务数据的时候，顺便把上次的ACK也返回去

核心机制之九. 面向字节流： 说到面向字节流，就有一个值得讨论的问题粘包问题

粘包问题：就是通过字节流方式的传输很容易混淆包与包之间的边界，不知道从哪个字节开始是一个完整的应用层数据包。（粘包问题粘的是应用层数据包）

解决： 方法一：约定包与包之间的分隔符：用 "\n"分隔开 方法二：约定包的长度：约定每个包开头4个字节来说明包的长度

上述的解决办法，在应用层协议，HTTP请求中就有体现：GET请求一般没有body，使用空行最为结束标记；POST请求有body的时候，使用Content-Length决定body的长度

核心机制之十.异常情况的处理： TCP在通信过程中存在特殊情况： 1.某个进程崩溃了： 进程崩溃和主动退出没有本质区别，都会释放进程->就是回收文件描述符表的每个资源-->调用socket的close方法，这个时候进程虽然没了，但是断开连接这个时候四次挥手可以正常进行

2.主机关机了： 正常流程的关机本质也是会杀死用户进程和情况一差不多； 但是如果关机时候四次挥手没有全部挥手完成如图，假设A是主机关机状态

B最终也会把连接释放掉

3.主机掉电： 站在四次挥手层面， 3.1.接收方突然掉电： 如果是接收方突然掉电，接收方就不会发送ACK，发送方会先触发超时超时重传，解决不了，会主动 " 重置TCP连接 ", 发送一个复位报文， TCP6个标志位中 RST 标志位为 1 就表示复位报文 ，此时也会有ACK，发送方会主动单方面释放连接。

3.2.发送方掉电： 接收方收不到ACK时，会等待一会儿，然后发送一个 "心跳包"，看对方是否存活，如果存活就继续等待，没有存活就，像上面接收方掉电一样，发RST复位报文，还是没有反应就单方面释放连接。

4.无线断开了： 中间网线断开，接收方和发送方相当于 “阴阳两隔” ，只需站在不同角度看即可：站在发送方就是相当于“接收方掉电”，反之亦然。

补充：16为紧急指针位 一般TCP一般是按照序号发送和接收的，但是也有例外，16为紧急指针位主要配合TCP6个标志位中 URG 标志位使用，当这个标志位为1 时紧急指针才有效，这个时候就代表某个报文段中存在紧急数据需要处理，直接read到引应用程序中即可。