目录
一、前导知识
1.1 TCP协议段格式
1.2 TCP全双工本质
二、三次握手
2.1 标记位
2.2 三次握手
2.3 捎带应答
2.4 标记位 RST
三、四次挥手
3.1 标记位 FIN
四、确认应答(ACK)机制
五、超时重传机制
六 TCP 流量控制
6.1 16位窗口大小
6.2 标记位 PSH
6.3 标记位 URG
七、滑动窗口
7.1 滑动窗口的概念
7.2 滑动窗口的相关问题
7.2.1 滑动窗口的大小
7.2.2 滑动窗口策略简单思路
7.2.2 超时重传时的数据如何保存
7.2.3 超时重传 vs 快重传
八、拥塞窗口
一、前导知识
1.1 TCP协议段格式
源/目的端口号：表示数据是从哪个进程来, 到哪个进程去;
32 位序号/32 位确认号：后面详细讲;
4 位 TCP 报头长度：表示该 TCP 头部有多少个 32 位 (有多少个 4 字节)；所以TCP 头部最大长度是 15(2^4 - 1) * 4 = 60
6位标志位：后面具体说
16位窗口大小：后面再说
16位校验和：发送端填充，CRC 校验。接收端校验不通过，则认为数据有问题。此处的检验和不光包含 TCP 首部，也包含 TCP 数据部分
16 位紧急指针：后面和标志位中的URG一起说
1.2 TCP全双工本质
在任何一台主机上， TCP 连接既有发送缓冲区， 又有接受缓冲区， 所以， 在内核中， 可以在发消息的同时， 也可以收消息， 即全双工。在这里，收消息和发消息的本质都变成了拷贝，发消息首先把应用层的数据拷贝到发送缓冲区，然后再拷贝到接受方的接受缓冲区，接受方再通过特殊的 API 将接受缓冲区中的数据拷贝到应用层。
二、三次握手
2.1 标记位
为什么要有标记位呢？这里先做一下简单的理解：
作为网络服务器，服务端可以连接多个客户端，但是每个客户端发送的报文分为很多种，以三次握手为例，该报文可能是1)请求连接 2)正文 3)请求关闭 ，所以客户端收到各种各样的报文，这就说明TCP报文是需要类型的，为了区分不同的报文类型，就引入了标记位的概念。
2.2 三次握手
1. TCP建立连接时，发送方先传达一个连接意愿
2. 接收方收到后需要响应这个消息，若不响应，发送方可能会一直重发消息。除此之外，接收方还要表达连接意愿
3.发送方响应接收方的意愿。
首先需要明确的是，上图中的标记位其实是一个个报文，其中SYN指的是报文中SYN标记位被置为1，以此类推：
SYN：请求建立连接，称携带SYN标识的报文为同步报文段。
ACK：确认号是否有效。
其中，当请求方发送连接意愿时，就会发送将SYN标记位置1的报文，接收方相应表示为ACK标记位置1，同时表达连接意愿又会将SYN置1...这种方式即为捎带应答(下面会讲到)。
在这里，配合着上一篇博客中对于TCP网络编程中相关的API来看：
client 通过应用层的 connect 接口发送握手请求，然后阻塞等待三次握手完毕，再继续向后执行
server 通过 listen 接口才会受理接受的 SYN 请求，否则会直接丢弃。
2.3 捎带应答
捎带应答相当于搭顺风车，当不影响网络服务时，ACK 会和服务器的接受意愿一起发送给客户端。但是，在四次握手中并没有出现捎带应答机制，者在下面会讲到。
其实不止是服务器首次回应连接意愿时会有捎带应答，在后面我们要讲到的窗口大小，它们在首次发送时，就会将窗口大小填到报文中传输给发送端，同时，在两次握手后，即发送端确认接受端已经可以接受数据后，发送端相应的ACK就可以开始携带传输数据了！
2.4 标记位 RST
在传输控制协议（TCP）中，RST标记位（Reset flag）用于复位连接。RST标记位通常在以下情况下使用：
-
拒绝连接：当一方收到一个连接请求（例如SYN包），但不愿意或者无法建立连接时，它会发送一个带有RST标记位的包来拒绝连接请求。
-
中止连接：当一个已经建立的连接出现问题（例如，某一方的应用程序崩溃），一方可能会发送一个带有RST标记位的包来强制终止连接。
-
处理错误的数据包：如果一方收到一个无法识别或不符合预期的数据包，它可能会发送一个带有RST标记位的包来通知发送方存在错误并终止连接。
具体来说，当一个TCP数据包的RST标记位被设置时，接收方会立即关闭连接，并不会等待剩余的数据传输完成。这是一种快速且强制性的连接终止方式。
RST标记位的使用通常表示存在某种异常或错误情况，因此在正常的TCP连接管理过程中，RST标记位的出现相对较少。
三、四次挥手
1. 发送方发起断开意愿
2. 接收端响应消息
3. 接收方表达断开意愿
4. 发送方响应断开意愿
3.1 标记位 FIN
这和三次握手的规律大致相同，只是把中间一条拆分成了两条，其中2和3不可以合并为一条，当接收方等待数据数据接收完整后，才可以表达断开意愿。
FIN：通知对方，本端要关闭了，称携带FIN表示的报文为结束报文段
四、确认应答(ACK)机制
在TCP的特点中，有一点叫做：可靠。那么TCP的可靠指的是什么呢？
TCP的可靠指的是，发送方不仅要发送数据，而且还要知道自己发送的数据是否被接收方接收，这就依赖于TCP的确认应答机制。
TCP 将每个字节的数据都进行了编号，即为序列号：
TCP 将应用程序发送的字节流分割成适合传输的段，每个段包含一个序列号，用于在接收端重新组装数据。接收方可以根据这些序列号将数据段正确地拼接成原始的字节流。
下面将发送缓冲区简单想象成线性的数组：
假设主机A发送的数据段是 1-1000 ，那么主机B的应答则需要是 1001 ，此时1001就会写到协议段中的32位确认序号中，表示确认序号以前的报文全部被收到。
五、超时重传机制
若发送方未收到接受方的应答，则统一约定接受方未收到报文，此时有三种可能：
1) 传输数据丢失 2) 应答丢失 3) 被阻塞在路由器中
为了避免第三种情况，发送方会进行等待，如果等待超时，则会进行重传，这就是超时重传机制。超时重传中约定的等待时间在 Linux 系统中会以500ms为基本单位进行动态调整。
六 TCP 流量控制
接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。
因此 TCP 支持根据接收端的处理能力, 来决定发送端的发送速度。这个机制就叫做流量控制。
6.1 16位窗口大小
那么，假设主机A向主机B发送消息，如果要进行流量控制，就需要知道主机B的接受能力，即接受缓冲区中剩余空间的大小。这就要求主机B要将自身的接受能力通告给主机A，这里就用到了TCP协议段格式中的16位窗口大小，用于标明主机B接受缓冲区中剩余空间的大小，同时使用了确认应答机制与捎带应答机制。
6.2 标记位 PSH
当B的接受缓冲区中剩余空间大小为0时，A在此期间会发送一个窗口探测的包，如果B的接受缓冲区一直为0，A就会将报文中的 PSH 标记位置1作为催促标记位，要求主机B尽快将缓冲区中的数据交给上层。
当然不止是这种极端情况，在日常通信中，凡是有这种需求时，都会将标记位 PSH 置1。
6.3 标记位 URG
以上已经介绍了五种标记位，现在剩下最后一种 URG ，URG表示紧急指针是否有效。
在接受缓冲区中，TCP按序为我们排好了很多的数据并按序向应用层进行交付，
紧急指针：仅当URG标记位被设置时才有效。它指示了紧急数据的结束位置。紧急指针的值是一个相对序号，它表示从当前序号开始到紧急数据结束的偏移量。
接受方会优先处理该报文，但是URG的使用并不常见，它传输的紧急数据通常是1字节，表示的是一个状态码，比如在传输2G的数据时，接受方的缓冲区已经接受了1G，此时发送方想要紧急停止传输工作，就会传输一个 URG 被设置的报文，接受方优先处理该报文得知其状态码意味着中断传输，那么之前存放在缓冲区的1G数据也不会再向上进行交付
七、滑动窗口
在前面的讲解中，我们也会意识到，每次先传输数据等待应答后才能再次传输的效率太低了，尤其是数据往返的时间较长的时候：
7.1 滑动窗口的概念
既然这样一发一收的方式性能较低, 那么我们一次发送多条数据，这些数据暂时不需要被应答，可以直接发送，这样就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)，这种策略在发送方的体现就是以一个滑动窗口的形式：
在不考虑网络的前提下，将暂时不需要应答，可以直接发送的数据的最大值称为发送方的滑动窗口的大小，上图中滑动窗口的大小就是4000字节。
滑动窗口其实就是在发送窗口上的双指针之间的一个数据段：
从上图我们可以把发送缓冲区分为三段：
7.2 滑动窗口的相关问题
重中之重：
确认序号的意义：确认序号以前的报文全部被收到
7.2.1 滑动窗口的大小
在不考虑网络速度的前提下，窗口的大小一般是接受方接收缓冲区中剩余空间的大小。
7.2.2 滑动窗口策略简单思路
7.2.2 超时重传时的数据如何保存
前面提到了确认序号的意义以及滑动窗口的策略，当有数据丢包时，比如1001-2000丢了，那么确认应答的值就为1001，从滑动窗口的策略可以看出：左指针仍是1001，这意味着1001-2000的数据仍在滑动窗口中，那么发送方就可以进行数据的重传。
当某一段报文段丢失之后, 发送端会一直收到 1001 这样的 ACK, 就像是在提醒发送端 "我想要的是 1001" 一样;
如果发送端主机连续三次收到了同样一个 "1001" 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;
这个时候接收端收到了 1001 之后, 再次返回的 ACK 就是 7001 了(因为 2001 -7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中;
这种机制被称为 "高速重发控制"(也叫 "快重传")。
在滑动窗口中，可以分为窗口最左侧数据丢包，窗口中间数据丢包，窗口最右侧数据丢包，但是根据确认序号的意义，每次的确认序号都会保证确认序号前面的数据全部被成功接收，如果最左侧数据被丢包那么就参考以上方案。如果中间和右侧数据被丢包，那么它们最后都会称为滑动窗口中的最左侧，解决方案也同上一样。
7.2.3 超时重传 vs 快重传
从上面可以看出快重传的效率明显高于超时重传，超时重传需要等待一定的时间，而快重传接受到确认应答即可实现重传，那么超时重传的存在还有意义吗？
其实，从7.2.2中的图中可以看出接受方需要发送3次重复的确认应答，发送方也需要收到3个同样的确认应答才会重发，那么总有不足3个的情况，这时候发生生丢包，就需要超时重传进行兜底。
八、拥塞窗口
虽然 TCP 有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题。因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。
TCP 引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据
此处引入一个概念称为拥塞窗口：
1.发送开始的时候, 定义拥塞窗口大小为 1；
2.每次收到一个 ACK 应答, 拥塞窗口加 1；
3.每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口。
实际上，拥塞窗口并不是一直呈指数增长的，这里引入了新的概念，即慢启动的阈值，当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长
当 TCP 开始启动的时候，慢启动阈值等于窗口最大值；
•在每次超时重发的时候，慢启动阈值会变成原来的一半，同时拥塞窗口置回 1；
少量的丢包, 我们仅仅是触发超时重传；大量的丢包，就认为网络拥塞；
当 TCP 通信开始后, 网络吞吐量会逐渐上升；随着网络发生拥堵，吞吐量会立刻下降；
拥塞控制，归根结底是 TCP 协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案。
TCP 拥塞控制这样的过程, 就好像热恋的感觉
