【计算机网络】传输层协议 -- TCP协议
文章目录
- 1. TCP协议的引入
- 2. TCP协议的特点
- 3. TCP协议格式
-
- 3.1 序号与确认序号
- 3.2 发送缓冲区与接收缓冲区
- 3.3 窗口大小
- 3.4 六个标志位
- 4. 确认应答机制
- 5. 超时重传机制
- 6. 连接管理机制
-
- 6.1 三次握手
- 6.2 四次挥手
- 7. 流量控制
- 8. 滑动窗口
- 9. 拥塞控制
- 10. 延迟应答
- 11. 捎带应答
- 12. 面向字节流
- 13. 粘包问题
- 14. TCP异常情况
- 15. 总结
- 16. 基于TCP的应用层协议
1. TCP协议的引入
认识可靠性
现在的计算机大多都是基于冯诺依曼体系结构的
虽然这里的输入设备、输出设备、内存、CPU是在同一个机器上的，但是它们彼此间却是相互独立的。如果它们之间要进行通信，那就必须要用“线”连接起来，其中连接内存和外设之间的“线”叫做IO总线，连接CPU与内存之间的线叫做系统总线。由于这些硬件设备在同一台机器上，因此连接它们的“线”是很短的，它们之间传输数据时出现错误的概率也很低。
但如果要进行通信的设备相隔千里，那么连接它们之间的“线”就要很长，传输数据时出现错误的概率也就大大增加，此时要保证传输到对端的数据无误，就必须引入可靠性的概念。
而TCP就是在这样一种背景下诞生了，TCP就是一种保证可靠性的协议！
那UDP的存在有何意义？
既然我们用TCP协议来保证传输的可靠性，而UDP协议是不可靠的，它存在的意义是什么呢？
其实，可靠与不可靠，它们两个是中性词，并无褒贬之分。
- TCP是可靠的协议，那么就意味着它要做更多的工作来保证数据传输的可靠性，并且如果引起不可靠的因素越多，那么保证可靠消耗的成本（时间与空间）也就越多。
- 数据在传输过程中出现了丢包、乱序、检验和失败等，这些都是不可靠的情况。
- 由于TCP相比UDP要保证可靠性的问题，那么它使用起来一定比UDP更加复杂，并且维护成本也更高。
- UDP协议是不可靠的协议，那么UDP协议在数据传输的过程中也就不要考虑数据传输时出现错误的问题，它使用和维护起来也就一定更简单。
- 需要注意的是，虽然TCP简单，但是TCP效率不一定比UDP低，TCP当中不仅有保证传输可靠性的机制，还有保证传输效率的机制。
TCP与UDP这两个协议，没有谁好谁坏之分，只有谁更合适，我们在网络通信时使用TCP还是UDP取决于上层的应用场景。如果上层应用严格要求数据在传输过程中的可靠性，那么我们选择TCP协议，因为TCP协议可以保证数据传输的可靠性；如果上层应用允许在数据传输时出现丢包等情况，那么我们选择UDP协议，因为它足够简单。
2. TCP协议的特点
经过上面的介绍，我们也就可以明白，TCP（Transmission Control Protocol）是一种常用的传输层协议，用于在计算机网络中传输数据。它是TCP/IP协议簇的核心协议之一，确保可靠性从一个断点传输到另一个端点。
TCP协议有以下特点：
- 可靠性：TCP提供可靠的数据传输，确保数据按顺序传输到对端，并且不会出现丢失、重复或者损坏的情况。
- 连接导向：在数据传输之前，TCP需要在通信的两端建立一个连接。这个连接在数据传输结束后会被关闭。
- 流控制：TCP使用滑动窗口机制进行流量控制，确保发送方不会淹没接收方。
- 拥塞控制：TCP具有拥塞控制机制，可在网络拥塞时自动调整发送速率，以减少网络拥塞和数据丢失。
- 面向字节流：TCP将数据视为连续的字节流，而不是离散的数据包。这意味着着数据可以分割成更小的块进行传输，也可以合并多个小块的数据后交付给应用层。
3. TCP协议格式
TCP报头中各个字段的含义如下：
- 源/目的端口号：表示数据从哪个进程来，发送到哪个进程去。
- 32位序号/32位确认序号：分别表示TCP报文中每个字节数据的编号以及对方的确认，是TCP保证可靠性的重要字段。
- 4位TCP报头长度：表示该TCP报头的长度，以4字节为单位。
- 6位保留字段：TCP报头中暂时未使用的6个比特位。
- 16位窗口大小：保证TCP可靠性机制和效率提升机制的重要字段。
- 16位检验和：由发送端填充，采用CRC校验。接收端校验不通过，则认为接收到的数据有问题。（检验和包含TCP首部和TCP数据部分）
- 16位紧急指针：标识紧急数据在报文中的偏移量，需要配合标志字段当中的URG字段统一使用。
- 选项字段：TCP报头当中允许携带额外的选项字段，最多40字节。
TCP报头当中的六位标志位：
- URG：紧急指针是否有效
- ACK：确认序号是否有效
- PSH：提示接收端应用程序立刻将TCP接收缓冲区当中的数据读走
- RST：表示请求对方重新建立连接，我们把携带RST标识的报文称为复位报文段
- SYN：表示请求与对方建立连接，我们把携带SYN标识的报文称为同步报文段
- FIN：通知对方，本端要关闭了。我们把携带FIN标识的报文称为结束报文段
TCP报头在内核中本质就是一个位段类型，给数据封装TCP报头时，本质就是用该位段类型定义了一个变量，然后填充TCP报头当中的各个属性字段，最后将这个TCP报头拷贝到数据的首部，至此便完成了TCP报头的封装。
TCP如何将报头与有效载荷分离？
当TCP从底层获取到一个报文之后，虽然TCP不知道报文的具体长度，但是报文的前20个字节是报文的基本报头，且其中涵盖了4位的首部长度。
TCP是这样分离报头和有效载荷的：
- 当TCP读取到一个报文之后，首先提取出报文的前20个字节，并从20个字节中提取出4位首部长度，这样便得到了TCP报头的大小size。
- 如果size的值大于20，则需要再从报文中读取size - 20字节的数据，这部分数据就是TCP报头当中选项字段。
- 读取完TCP的基本报头和选项字段之后，剩下的就是有效载荷了。
需要注意的是，TCP报文当中的4位首部长度描述的基本单位是4字节，这恰好也是报文的宽度（即报文数据的单位）。4位首部长度的取值范围为0000~1111，因此TCP报头的最大长度为 15 * 4 = 60 字节，因为基本报头的长度是20字节，所以报头中选项的长度最多为40字节。
如果TCP报头当中不携带选项字段，那么TCP报头的长度就为20字节，此时报头当中的4位首部长度的值也就为 20 / 4 = 5 字节，也就是说，首部长度的值为0101。
TCP如何得知将有效载荷交付给上层的哪一个协议？
应用层的每一个网络进程都必须绑定一个端口号。服务端进程必须由程序员显式指定一个端口号，而客户端进程又系统分配一个端口号。
TCP的报头中涵盖了目的进程端口号，因此就可以根据端口号，找到指定的进程，从而交付数据。
3.1 序号与确认序号
如何保证可靠性？
在进行网络通信时，一方发出数据之后，它不能保证该数据能被对方成功收到。因为数据在传输过程中可能会发生各种各样的错误，只有当收到对端主机的响应之后，才可认为上一次发送的数据被对端成功收到了。
图中，实线表示数据可以保证被对方收到，虚线则不能。
但TCP要保证的是双方通信的可靠性，虽然此时主机A能够保证自己上一次发送的数据被主机B可靠地收到了，但主机B也需要保证自己发送的响应数据被主机A可靠地收到了。因此主机A在收到主机B的响应消息之后，还要向主机B发送响应消息的响应消息，如此这样循环下去。。。岂不是很不合理呢？
只有当一端收到对方的响应消息之后，才能保证自己发送的消息被对方成功收到了，但是总有一方有最新的一条消息，所以我们无法百分百保证可靠性！
所以严格意义上来说，互联网通信当中是没有百分百的可靠性的，因为通信双方总有一条消息得不到响应。 但是实际上也没有必要保证百分百的可靠性，我们只需要保证核心数据被对方收到就可以了。而对于一些无关紧要的数据（比如响应数据），我们不必保证它的可靠性。
这种策略在TCP当中就叫做确认应答机制。需要注意的是，确认应答机制不是保证双方通信的百分百可靠性，而是只要一方收到另一方的响应消息，就说明它上一次发送的数据被另一方可靠地收到了。
可是，我们必须要考虑一个问题，如果双方在进行网络通信时，只有收到了上一次发送数据的响应才能发下一个数据，那么此时双方的数据通信就是串行的，效率非常低！
因此双方在进行网络通信的时候，允许一方向另一方连续发送多个报文数据，只要保证发送的每个报文都有对应的响应消息就行了，此时也就能保证这些报文被对方收到了。
但在连续发送多个报文时，由于各个报文在进行网络传输时选择的路径可能是不一样的，因此这些报文到达对端主机的先后顺序也就可能和报文的发送顺序是不一致的。
但是报文有序也是可靠性的一种，为了保证报文有序，我们引入32位序号！
32位序号
报文有序也是可靠性的一种，TCP报头当中的32位序号的作用之一实际就是用来保证报文的有序性的。
TCP将发送出去的每个字节数据都进行了编号，这个编号叫做序列号。
- 比如现在发送端要发送3000字节的数据，如果每次只发送1000字节的数据，那么就需要用三个TCP报头来发送者3000字节的数据。
- 此时这三个TCP报文当中的32位序号填的就是发送数据中首个字节的序列号，因此分别填的是1、 1001、 2001
此时接收端在收到了这三个TCP报文之后，就可以根据TCP报头当中的序列号对这三个报文进行重排（该动作在传输层进行），重拍后将其放到TCP的接收缓冲区中，此时接收端这里报文的顺序就与发送端一致了。
接收端在进行报文重排时，可以根据当前报文的32位序号以及与其有效载荷的字节数，进而确定下一个报文对应的序列号。
在我们发送核心数据的时候需要32位序号，那么在我们发送响应数据的时候其实也需要32位确认序号。
32位确认序号
TCP报头当中的32位确认序号是告诉对端，我当前已经收到了哪些数据，你的数据下一次应该从哪里发送。
以上面的例子为例，当主机B收到主机A发送的32位序号为1的报文后，由于该报文中报文1000字节的数据，因此主机B收到序列号为1 ~ 1000的字节数据，于是主机B发给主机A的响应数据的报头当中的32位确认序号就会被填为1001。
这样做有两个目的：
- 一方面是告诉主机A，序列号为在1001之前的数据我已经收到了
- 另一方面是告诉主机A，下次你应该从序列号为1000的数据开始发送
注意：响应数据和其他数据一样，也是一个完整的报文，虽然它不携带有效载荷。
如果出现报文丢失的情况，怎么办？
主机A发送了三个报文给主机B，其中每个报文的有效载荷都是1000字节，这三个报文的32位序号是1、 1001、 2001。
如果这三个报文在网络传输的过程中出现了丢包，最终只有需要为1和2001的报文都主机B收到了，那么当主机B在对报文进行顺序重排的时候，就会发现只收到了 1 ~ 1000 和2001 ~ 3000的数据。此时主机B在对主机A进行响应时，其响应报头当中的32位确认序号填的就是10001，告诉主机A下次要从序号1001的数据开始发送。
注意：
- 此时主机B在对主机A响应时，其32位确认序号就不能填3001。因为如果填了3001，就表明3001之前的数据全被收到了，这样就忽略了 1001 ~ 2000 的字节数据了。
- 因此主机B只能给主机A响应1001，当主机A收到该确认序号之后就能确定从1001开始的报文丢失了，然后就重新发送。
因此发送端可以根据对端发来的确认序号，判断是否有哪个报文在传输中丢失了。
为什么要使用两套序号机制？
如果通信一方只是发送数据，另一方只是接收数据，那么只用一套序号就可以了。
但是TCP是全双工通信的，双方都有可能发送数据和接收数据。
- 双方发出的报文中，不仅要填充自己的32位序号来表明自己发送数据的序列号。
- 还要填充32位确认序号，对对方上一次发送的数据进行确认，告诉对方下一次应该从哪一字节序号进行发送。
因此在TCP通信时，双方都要有确认应答机制，在TCP报头当中就出现了两套序号。
3.2 发送缓冲区与接收缓冲区
TCP本身是具有发送缓冲区和接收缓冲区的，这两个缓冲区都是在TCP传输层内部实现的。
- TCP发送缓冲区当中的数据由上层应用层进行写入，当上层应用层调用write/send这样的系统调用接口时，实际并不是直接将数据发送到了网络当中，而是将数据从应用层拷贝到了TCP的发送缓冲区当中。
- TCP接收缓冲区当中的数据最终也是由应用层来读取的，当上层调用read/recv这样的系统调用接口时，实际也不是直接从网络中读取数据，而是将数据从TCP的缓冲区拷贝到了应用层而已。
- 就好比调用read和write接口进行文件读写时，并不是直接从磁盘读取数据，也不是直接将数据写入到磁盘上，而对文件缓冲区进行读写操作。
当数据写入到TCP的缓冲区之后，对应的read/write函数就可以返回了，至于发送缓冲区当中的数据具体什么时候发送，怎么发送等问题是由TCP决定的。
我们之所以称TCP为传输层控制协议，就是因为TCP决定了数据的发送和接收方式，以及决定了传输数据时遇到的问题该如何解决。用户只需要将数据拷贝到TCP的发送缓冲区当中，以及从TCP的接收缓冲区当中读取数据就行。
TCP的发送缓冲区和接收缓冲区存在的意义：
发送缓冲区和接收缓冲区的作用：
- 数据在网络中传输时可能会出现某些错误，此时就可能要求发送端进行数据重传，因此TCP必须提供一个发送缓冲区来暂时保存发送出去的数据，便于应对出现数据重传的情况。只有当发出去的数据被对端可靠地读取之后，发送缓冲区中对应的数据才可以被覆盖掉。
- 接收端处理数据的速度是有限的，为了保证没来得及处理的数据不被丢弃，我们必须提供一个接收缓冲区来暂时保存没有被处理的数据。另外，TCP的数据重排也是在接收缓冲区中进行的。
它们其实就是一个经典的生产者消费者模型：
- 对于发送缓冲区来说，上层应用不断向缓冲区内写入数据，下层网络层不断读取数据从而进行进一步地封装。在这个过程中，上层应用就是生产者的角色，下层网络层就是消费者的角色，而发送缓冲区就是它们的交易场所。
- 对于接收缓冲区来说，下层网络层不断向缓冲区中写入数据，上层应用不断从缓冲区中拿出数据进行处理。在这个过程中，下层网络层就是生产者的角色，上层应用就是消费者的角色，而接收缓冲区就是它们的交易场所。
- 因此引入发送缓冲区和接收缓冲区也就是引入了两个生产者消费者模型，从而将上层应用于底层通信进行解耦。
3.3 窗口大小
当发送端要发送数据给对端时，本质是将自己发送缓冲区的数据发送到对端的接收缓冲区当中。但是缓冲区是有大小的，如果接收端处理的速度小于发送端发送的速度，那么总有一个时刻接收缓冲区会被写满，这时发送端再发送数据过来就会造成数据丢包，进而引发丢包重传等一系列的连锁反应。
因此TCP报文当中就有了16的窗口大小，这个16位窗口大小当中填的是自身接收缓冲区中剩余空间的大小，也就是当前主机接收数据的能力。
接收端在对发送端发来的数据进行响应时，就可以通过16位窗口大小告知发送端自己当前接收缓冲区剩余空间的大小，此时发送端就可以更具这个窗口大小字段来调整自己发送数据的速度。
- 在编写TCP套接字时，我们调用read/recv函数从套接字中读取数据时，可能会因为套接字当中没有数据而被阻塞，本质是因为TCP的接收缓冲区当中没有数据了，我们实际是阻塞在接收缓冲区当中了。
- 而我们调用write/read函数往套接字当中写入数据时，可能会因为套接字已经写满而被阻塞住，本质是因为TCP的发送缓冲区已经被写满了，我们实际是阻塞在发送缓冲区当中了。
- 在生产者消费者模型中，如果生产者生产数据被阻塞，或者消费者消费数据被阻塞，那么一定是因为某些条件不就绪而被阻塞。
3.4 六个标志位
为什么会存在标志位？
- TCP报文的种类多种多样，除了正常连接时发送的普通报文，还有建立连接时发送的请求建立连接的报文，以及断开连接时发送的断开连接的报文等等。
- 收到不同种类的报文时我们需要执行对应的动作，比如正常通信的报文我们需要放到接收缓冲区当中等待上层进行读取，而建立和断开连接的报文本质不是交给用户处理的，而是需要让操作系统在TCP层执行对应的握手和挥手动作。
- 也就是说不同种类的报文对应的不同的处理逻辑，所以我们要能够区分报文的种类。而CPU就是使用报文当中的六个标志字段来进行区分的，这六个标志位都只占用一个比特位，为0表示假，为1表示真。
SYN
- 报文当中的SYN被设置为1，表示该报文是一个连接建立的请求报文。
- 只有在连接建立阶段，SYN才被设置，正常通信的时候SYN不被设置。
ACK
- 报文当中的ACK被设置为1，表明该报文可以对收到的报文进行确认。
- 一般除了第一个请求没有设置ACK，其余报文都会设置ACK。因为发送出去的数据本身就对对方发送过来的数据具有一定的确认能力，因此双方在进行数据通信时，可以顺便对对方上一次发送的数据进行响应。
FIN
- 报文当中的FIN被设置为，表明该报文是一个连接断开的请求报文。
- 只有在断开连接阶段，FIN才被设置，正常通信时FIN不会被设置。
URG
双方在进行网络通信的时候，由于TCP是保证数据按序到达的，即便发送端将要发送的数据分成了若干个TCP报文进行发送，最终到达接收端时这些数据也都是有序的，因为TCP可以通过序号来对这些TCP报文进行顺序重排，最终就能保证数据到达对端接收缓冲区中是有序的。
TCP按序到达本身也是我们的目的，此时对端上层从接收缓冲区读取数据时也必须是按顺序读取的。但是有时候发送端可能发送了一些“紧急数据”，这些数据需要让对方上层提取进行读取，此时就要用到URG。
此时就需要用到URG标志位，以及TCP报头当中的16位紧急指针。
- 当URG标志位被设置为1时，需要通过TCP报头当中的16位紧急指针来找到紧急数据，否则一般情况下不需要关注TCP报头当中的16位紧急指针。
- 16位紧急指针代表的就是紧急数据在报文中的偏移量。
- 因为紧急指针只有一个，它只能表示数据段中的某一个位置，因此紧急数据只能发送一个字节，而至于这一个字节的具体含义这里就不展开讨论了。
recv函数的第四个参数flags有一个叫做MSG_OOB的选项可以设置，其中OOB是带外数据（out of band）的简称，带外数据就是一些比较重要的数据，因此上层如果想读取紧急数据，就可以使用recv函数进行读取，并设置MSG_OOB选项。
与之对应的send函数的第四个参数flags也提供了一个叫做MSG_OOB的选项，上层如果想发送紧急数据，就可以使用send函数进行写入，并设置MSG_OOB选项。
PSH
报文当中的PSH被设置为1，是在告诉对方尽快将你的接收缓冲区的数据交付给上层。
我们一般任务：
- 当使用read/recv从缓冲区中读取数据时，如果缓冲区当中有数据read/recv函数就能够读取到数据并进行返回，而如果缓冲区当中没有数据，那么此时read/recv就会阻塞住，直到缓冲区当中有数据时才会读取到数据并进行返回。
实际这种说法是不准确的，其实接收缓冲区和发送缓冲区都有一个水位线的概念。
- 比如我们假设TCP接收缓冲区的水位线是100字节，那么只有当接收缓冲区当中有100字节时才会让read/recv函数读取这100字节的数据并进行返回。
- 如果接收缓冲区当中有一点数据就让read/recv函数读取返回了，此时read/recv函数就会频繁地进行读取和返回，进而影响读取数据的效率（在内核态和用户态之间切换也是有成本的）。
- 因此不是说接收缓冲区当中只要有数据，调用read/recv函数时就能读取到数据进行返回，而是当缓冲区当中的数据量到一定范围时才能进行读取。
当报文当中的PSH设置为1时，实际就是在告诉对方操作系统，尽快将接收缓冲区的数据交付给上层，尽管接收缓冲区的数据还没到达指定的水位线。这也就是为什么我们使用read/recv函数读取数据时，期望读取的字节数和实际读取的字节数是不一定吻合的。
RST
- 报文当中的RST被设置为1，表示需要让对方重新建立连接
- 在通信双方在连接未建立好的情况下，一方向另一方发送数据，此时另一方的响应报头中的RST位就会被置1，表示要求对方重新建立连接。
- 在双方建立好连接进行正常通信时，如果通信中途发现之前建立好的连接出现了异常也会要求重新建立连接。
4. 确认应答机制
TCP保证可靠性的机制之一就是确认应答机制
确认应答机制就是由TCP报头中的32位序号和32位确认序号来保证的。需要再次强调的是，确认应答机制不是保证双方通信的全部消息的可靠性，而是通过收到对方的应答消息，来保证自己曾经发送给对方的某一条消息被对方可靠地收到了。
如何理解TCP将每个字节的数据都进行了编号？
TCP是面向字节流的，我们可以将TCP的发送缓冲区和接收缓冲区都想象成一个字符数组。
- 此时上层应用拷贝到TCP发送缓冲区当中的每一个字节数据天然有了一个序号，这个序号就字符数组的下标，只不过这个下标不是从0开始的，而是从1开始递增的。
- 而双方在同时时，本质就是将自己发送缓冲区的数据拷贝到对方的接收缓冲区中。
- 发送方发送数据时报头中所填的序号，实际就是发送的若干字节数据当中，首个字节数组在发送缓冲区中对应的下标。
- 接收方接收到数据进行响应时，响应报头当中的确认序号实际就是，接收缓冲区接收到的最后一个有效数据的下一个位置对应的下标。
- 当发送方收到接收方的响应后，就可以从下标为确定序号的位置继续发送了。
5. 超时重传机制
双方在进行网络通信的时候，发送方发出去的数据在一个特定的时间间隔内如果得不到对方的应答，此时发送方就会进行数据重发，这就是TCP的超时重传机制。
需要注意的是，TCP保证双方通信的可靠性，一部分是通过TCP的协议报头体现出来的，还有一部分是通过实现TCP的代码逻辑体现出来的。
比如超时重传机制就是发送方在发送数据后开启了一个定时器，若是在这个时间内没有收到刚才发送的数据的确认应答报文，则会对报文进行重传，这就是通过TCP的代码逻辑实现的，而在TCP报头中是看不出来的。
丢包的两种情况
丢包分为两种情况，一直种是发送的数据报文丢失了，此时发送端在一定时间内收不到对应的响应报文，就会进行超时重传。
另一种情况是对方发来的响应报文丢包了，此时发送端也会因为收不到对应的响应报文，而进行超时重传。
- 当出现丢包时，发送方是无法辨别是发送的数据报文丢失了，还是对方发来的响应报文丢失了，因为这两种情况下发送方都收不到对方发来的响应报文，此时发送方就只能进行超时重传。
- 如果是对方的响应报文丢失而导致发送方进行超时重传，此时接收方就会再次收到一个重复的报文数据，但此时也不用担心，接收方可以根据报头当中的32位序号来判断曾经是否收到过这个报文，从而进行去重。
- 需要注意的是，当发送缓冲区当中的数据被发送出去后，操作系统不会立即将该数据从发送缓冲区当中删除或者覆盖，而是会让其保存在发送缓冲区当中，以便后续可能的超时重传。直到收到响应报文后，发送缓冲区中的这部分数据才可以删除或者覆盖。
超时重传的等待时间
超时重传的时间既不能太短也不能太长。
- 如果超时重传的时间设置太长，会导致丢包后长时间收不到对方的数据，影响效率。
- 超时重传的时间设置的太短，会导致双方收到大量的重复报文，可能对方发送的响应报文孩子网络中传输而并没有丢包，但此时发送方就开始进行数据重传了，并且发送大量重复报文也会浪费网络资源。
因此超时重传的时间一定要是合理的，最理想的情况就是找到一个最小的时间，保证确认应答一定能在这个时间返回。但这个时间的长短，是与网络环境有关的。网好的时候重传的时间可以设置短一点，网卡的时候重传的时间可以设置的长一点1，也就是说超时重传设置的等待时间一定是上下浮动的，因此这个时间不可能是固定的某个值。
TCP为了保证无论在任何环境下都有比较高性能的通信，会动态计算这个最大超时时间。
- Linux中（Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定超时重发的时间都是500ms的整数倍。
- 如果重发一次之后，仍然得不到应答，下次重发的时间就是 2 * 500ms，如果再得不到应答，继续乘2，以此类推下去。
- 当累计到一定的重传次数之后，TCP就会认为是网络或对端主机出现了异常，进而强制关闭连接。
6. 连接管理机制
TCP是面向连接的
TCP的各种可靠性机制实际都不是从主机到主机的，而是基于连接的，与连接是强相关的。比如一台服务器启动后有可能有多个服务器前来访问，如果TCP不是基于连接的，也就意味着服务器只有一个接收缓冲区，此时各个客户端发来的数据都会拷贝到这个接收缓冲区当中，此时这些数据就可能会收到干扰。
而我们在TCP通信之前需要先建立连接，就是因为TCP的各种可靠性都是基于连接的，要保证数据传输的可靠性就必须先建立好连接。
操作系统对连接的管理
面向连接是TCP可靠性的一种，只有在连接建立好之后可靠性才能得到保证，而一台机器上可能存在大量的连接，此时操作系统就要对这些连接做管理。
- 操作系统在管理这些连接的时候需要“先描述，再组织”，在操作系统中有一个管理连接的结构体，该结构体当中包含了连接的各种属性字段，所有定义出来的连接结构体最终都会以某种数据结构组织起来，此时操作系统对连接的管理就变成了对数据结构的增删查改。
- 建立连接，本质就是在操作系统中定义一个管理连接的结构体变量，然后填充各种属性字段，最后将其插入到管理连接的数据结构当中。
- 断开连接，本质也就是将某个连接从管理连接的数据结构删除，释放连接占用的资源。
- 因此连接的管理是有成本的，这个成本就是管理连接结构体的时间成本和存储连接结构体的空间成本。
6.1 三次握手
双方在使用TCP协议通信之前需要先建立连接，这个建立连接的过程我们称之为三次握手。
三次握手的过程
以服务端和客户端为例，当客户端要与服务器进行通信时，需要先与服务器建立连接，此时客户端会作为主动方先向服务器发送连接建立请求，然后双方TCP在底层进行三次握手。
- 第一次握手：客户端向服务器发送的报文当中的SYN位被设置为1，表示请求与服务器建立连接。
- 第二次握手：服务器收到客户端发来的连接请求之后，紧接着向客户端发起连接请求并对客户端发起的连接请求进行响应，此时服务器向客户端发送的报文中的SYN和ACK均被设置为1。
- 第三次握手：客户端收到服务器发来的报文后，得知服务器收到了自己发送的连接请求，并请求和自己建立连接，最后客户端再向服务器发来的报文进行响应。
需要注意的是，客户端向服务器发起的连接建立请求，是请求建立从客户端到服务端的通信连接，而TCP是全双工通信，因此服务器在收到客户端发来的连接建立请求后，服务器也需要向客户端发起连接建立请求，请求建立从服务器到客户端方法的通信连接。
为什么是三次握手？
首先我们需要知道，连接建议不是百分之百能成功的，通信双方在进行三次握手时，其中前两次握手能够保证被对方收到，因为前两次握手都有对应的下一次握手对其进行响应，但是第三次握手是没有对应的响应报文的，如果第三次握手客户端发送的ACK报文丢失了，那么连接就会建立失败。
建立连接不管采用几次握手，最后一次握手的可靠性都是不能保证的。
建立连接的建立都不说百分之百成功的，因此建立连接时具体采用几次握手的依据，实际是看几次握手时的优点更多。
- 因为TCP是全双工通信的，因此建立连接的核心要务就是，验证双方的通信信道是否是连通的。
- 而三次握手恰好是验证双方通信信道的最小次数，通过三次握手后双方就都能知道自己和对方是否都能够正常发送和接收数据。
- 在客户端看来，把它收到服务器发来第二次握手时，说明自己发出的第一次握手被对方可靠地收到了，证明自己能发送以及服务器能接收，同时当自己收到服务器发来的第二次握手时，也就证明服务器能发以及能收，此时就证明自己和服务器都是能发能收的。
- 在服务器看来，当它收到客户端发来第一次握手时，证明客户端能发以及自己能收，而当它收到客户端发来的第三次握手时，说明自己发出的第二次握手被对方可靠地收到了，也就证明自己能发以及客户端能收，此时就证明自己和客户端都是能发能收的。
- 既然三次握手已经能够验证双方通信信道是否正常了，那么三次以上的握手当然也是可以验证的，但既然三次已经能验证了就没有必要再进行更多次的握手了。
三次握手能够保证连接建立时的异常连接挂在客户端：
- 当客户端收到服务器发来的第二次握手时，客户端就已经证明双方通信是连通的了，因此当客户端发出第三次握手之后，这个连接就已经在客户端建立了。
- 而只有当服务器收到客户端发来的第三次握手后，服务器才知道双方通信信道是连通的，此时在服务器端才会建立对应的连接。
- 因此双方在进行第三次握手建立连接时，双方建立连接的时间点也是不一样的。如果客户端最后发出的第三次握手丢包了，此时在服务端就不会建立对应的连接，而在客户端就需要短暂地维护一个异常的连接。
- 而维护连接是需要时间成本和空间成本的，因此三次握手还有一个好处就是能够保证连接建立异常时，这个异常连接是挂在客户端的，而不会影响到服务器。
- 虽然此时客户端也需要短暂维护这个异常，但客户端的异常连接不会特别多，不像服务器，一旦多个客户端建立连接时都失败了，此时服务器端就需要耗费大量资源来维护这些异常连接。
- 此外，建立连接失败时的异常连接不会一直维护下去。如果服务端长时间收不到客户端发来的第三次握手，就会将第二次握手进行超时重传，此时客户端就有机会重新发出第三次握手。或者当客户端认为连接建立好后向服务器发送数据时，此时服务器会发现没有和该客户端建立连接时而要求客户端重新建立连接。
因此，这里给出两个连接时采用三次握手的理由：
- 三次握手是验证双方通信信道的最小次数，能够让建立的连接尽快建立起来。
- 三次握手能够保证连接建立时的异常连接挂在客户端。
三次握手时的状态变化
三次握手时的状态变化如下：
- 最开始客户端和服务端都处于CLOSED状态
- 服务器为了能够接收客户端发来的连接请求，需要由CLOSED状态变为LISTEN状态
- 此时客户端就可以向服务器发起三次握手了，当客户端发起第一次握手后，状态变为SYN_SENT状态
- 处于LISTEN状态的服务器收到客户端的连接之后，将该连接放入内核等待队列中，并向客户端发起第三次握手，此时服务器的状态变为SYN_RCVD
- 当客户端收到服务器发来的第二次握手后，紧接着向服务发送最后一次握手，此时客户端的连接已经建立，状态变为ESTABLISHED
- 而服务端收到客户端发来的最后一次握手后，连接也建立成功，此时服务器的状态也变为ESTABLISHED
至此三次握手结束，双方可以进行数据交互了。
套接字和三次握手之间的关系
- 在客户端发起连接请求之前，服务器需要先进入LISTEN状态，此时就需要服务器调用对应listen函数。
- 当服务器进入LISTEN状态后，客户端就可以向服务器发起三次握手了，此时客户端对应调用的就是connect函数。
- 需要注意的是，connect函数不参与底层的三次握手，connect函数的作用只是发起三次握手。当connect函数返回时，要么是底层已经成功完成了三次握手连接建立成功，要么是底层三次握手失败。
- 如果服务器端与客户端成功完成了三次握手，此时在服务器端就会建议一个连接，但这个连接在内核的等待队列当中，服务器端需要调用accept函数将这个建立好的连接提取上来。
- 当服务器端将建立好的连接获取上来之后，双方就可以通过read/recv以及write/send进行数据交互了。
6.2 四次挥手
四次挥手的过程
由于维护双方的连接是需要成本的，所以在通信结束的时候我们就要断开连接，这个断开连接的过程为四次挥手。
- 第一次挥手：客户端向服务端发送的报文中的FIN位被设置为1，表示请求与服务端断开连接。
- 第二次挥手：服务端收到客户端发来的断开连接请求之后对其进行响应。
- 第三次挥手：服务端收到客户端断开连接的请求，且已经没有数据需要发送给客户端的时候，服务端就会向客户端发起断开连接请求。
- 第四次挥手：客户端收到服务端发来的断开连接请求后对其进行响应。
四次挥手结束之后双方的连接才算是真正断开。
为什么是四次握手？
- 由于TCP是全双工的，建立连接的时候也需要建立双方的连接，断开连接的时候也如此。在断开连接时不仅要断开从客户端到服务器方向的通信信道，还要断开从服务器到客户端的通信信道，其中每两次挥手就对应就是关闭一个方向的通信信道，因此断开连接需要四次挥手。
- 需要注意的是，第二次挥手和第三次挥手不能合并在一起，因为第三次挥手是服务端想要与客户端断开时发给客户端的请求，而当服务器收到客户端断开连接的请求并响应之后，服务器不一定会马上发起第三次挥手，因为服务器可能还有某些数据要发送给客户端，只有当服务器将这些数据发送完之后才会向客户端发起第三次挥手。
四次挥手时的状态变化
- 在挥手前客户端和服务器都处于连接建立后的ESTABLISHED装填。
- 客户端为了与服务器断开连接主动向服务器发起连接断开请求，此时客户端的状态变为FIN_WAIT_1。
- 服务端收到客户端发来的连接断开请求后对其进行响应，此时服务器的状态变为CLOSE_WAIT，而客户端状态变为FIN_WAIT_2。
- 当服务器没有数据需要发送给客户端时，服务器会向客户端发起断开连接请求，等待最后一个ACK到来，此时服务器的状态变为LASE_ACK。
- 客户端收到服务器发来的第三次挥手后，会向服务器发送一个响应报文，此时客户端进入TIME_WAIT装填。
- 当服务器收到客户端发来的最后一个响应报文时，服务器会彻底关闭连接，变为CLOSE状态。
- 而客户端则会等待一个2MSL（Maximum Segment Lifetime，报文最大生存时间）才会进入CLOSED状态。
至此四次挥手结束，通信双方断开连接。
套接字与四次挥手之间的关系
- 客户端发起断开连接请求，对应就是客户端主动调用close函数
- 服务端发起断开连接请求，对应就是服务端主动调用close函数
- 一个close对应的就是两次挥手，双方都要调用close，因此就是四次挥手
CLOSE_WAIT
- 双方在进行四次挥手时，如果只有客户端调用了close函数，而服务器不调用close函数，此时服务器就会进入CLOSE_WAIT状态，而客户端则会进入FIN_WAIT_2状态。
- 但只有完成四次挥手后连接才算真正断开，此时双方才会释放对应的连接资源，如果服务器没有主动关闭需要的文件描述符，此时在服务器端就会存在大量处于CLOSE_WAIT状态的连接，而每个连接都会占用服务器的资源，最终就会导致服务器可用资源越来越少。
- 因此如果不及时关闭不用的文件描述符，除了会造成文件描述符泄漏以外，可能也会导致连接资源没有完全释放，这其实也是一种内存泄漏的问题。
- 因此编写网络编程套接字代码时，如果发现服务器端存在大量处于CLOSE_WAIT状态的连接，此时就可以检查一下是不是服务器没有及时调用close函数关闭对应的文件描述符。
TIME_WAIT
如果客户端在发出第四次挥手之后立即进入CLOSED状态，那么此时服务器就算进行超时重传，也得不到客户端的响应，因为客户端已经关闭了。
服务器在经过若干次超时重发之后得不到响应的话，最终也一定会将对应的连接关闭，但在服务器不断进行超时重传期间还需要维护这条废弃的连接，这样对服务器是非常不友好的。
为了避免这种情况，客户端在四次挥手之后并没有立即进入CLOSED状态，而是进入到了TIME_WAIT状态进行等待，此时要是第四次挥手的报文丢包了，客户端也能收到服务器重发的报文进行响应。
TIME_WAIT状态存在的必要性：
- 客户端在进行四次挥手后进入TIME_WAIT状态，如果第四次挥手的报文丢包了，客户端在一段时间内仍然能够接收到服务器重发的FIN报文并对其进行响应，能够较大概率保证最后一个ACK被服务器收到。
- 客户端发出最后一次挥手时，双方历史通信的数据可能还没有发送到对方。因此客户端四次挥手后进入TIME_WAIT状态，还可以保证双方通信信道上的数据在网络中尽可能地消散。
实际第四次挥手丢包后，可能双方网络状态出现了问题，尽管客户端还没有关闭连接，也收不到服务器重发的连接断开请求，此时客户端TIME_WAIT等若干时间最终也会关闭连接，而服务器经过多次超时重传之后也会关闭连接。这种情况虽然让服务器维持了闲置的连接，但毕竟是少数，引入TIME_WAIT状态就是尽量让主动发起四次挥手的客户端维护这个成本。
因此TCP并不能完全保证建立连接和断开连接的可靠性，TCP保证的是建立连接之后，以及断开连接之前双方通信数据的可靠性。
TIME_WAIT的等待时长是什么？
TIME_WAIT的等待时长既不能太长也不能太短。
- 太长会让等待方维持一个较长的等待时间的TIME_WAIT状态，在这个时间内等待方也需要花费时间成本来维护这个连接，这也是一种浪费资源的现象。
- 太短可能没有达到我们的最初目的，没有保证ACK被对方较大概率收到，也没有保证数据在网络中消散，此时TIME_WAIT的意义也就没有了。
TCP协议规定，主动关闭连接的一方在四次挥手后要处于TIME_WAIT装填，等待两个MSL的时间才能进入CLOSED状态。
MSL在RFC1122中规定为两分钟，但是各个操作系统的实现不同，比如在CentOS7上默认的值是60s，我们可以通过以下命令来查看MSL的值。
TIME_WAIT的等待时长设置为两个MSL的原因：
- MSL是TCP报文的最大生存时间，因此TIME_WAIT状态储蓄存在2MSL的话，就能保证两个传输方向上的尚未被接收或迟到的报文段都已经消失。
- 同时也是在理论上保证最后一个报文可靠到达的时间。
7. 流量控制
TCP支持根据接收端的接收数据的能力来决定发送端发送数据的速度，这个机制叫做流量控制。
接收端处理数据的速度是有限的，如果发送端是发送的太快，导致接收端的缓冲区被打满，此时发送端继续发送数据，就会造成丢包等问题。
因此接收方可以将自己接收数据的能力告知发送端，从而让发送端控制自己发送数据的速度。
- 接收端将自己可以接收数据的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK通知发送端。
- 窗口大小字段越大，说明网络的吞吐量越高。
- 接收端一旦发现自己的缓冲区快慢了，就会将窗口大小设置成一个更小的值通知给发送端。
- 发送端接收到这个窗口之后，就会减慢自己发送的速度。
- 如果接收缓冲区满了，就会将窗口值设置为0，这时发送方不再发送数据，但需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。
当发送端得知接收端接收数据的能力为0时会停止发送数据，此时发送端会通过以下两种方式来得知何时可以继续发送数据。
- 等待告知，接收端上层将接收缓冲区的数据读走后，接收端会向发送端发送一个TCP报文，主动将自己的窗口大小告知发送端，发送端得知接收端的接收缓冲区有空间后就可以继续发送数据了。
- 主动询问，发送端每隔一段时间向接收端发送报文，该报文不携带有效数据，只是为了询问发送端的窗口大小，直到接收端的接收缓冲区有空间后发送端就可以继续发送数据了。
16位数字最大表示为65535，那TCP窗口最大就是65535吗？
理论上确实是这样的，但实际上TCP报头当中40字节的选项字段中包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位得到的。
第一次向对方发送数据时如何得知对方的窗口大小？
双方在进行TCP通信之前需要先进行三次握手建立连接，而双方在握手时除了验证双方通信信道是否畅通以外，还进行了其他信息的交互，其中就包括告知对方自己的接收能力，因此双方在还没有正式开始通信之前就已经知道了对方接收数据的能力，所以双方在发送数据时是不会出现缓冲区溢出的问题的。
8. 滑动窗口
连续发送多个数据
双方在进行TCP通信时可以一次向对方发送多条数据，这样可以将等待多个响应的时间重叠起来，进而调高数据通信的效率。
需要注意的是，虽然双方在进行TCP通信时可以一次向对方发送大量的报文，但不能将自己发送缓冲区当中的数据全部打包发送给对端，在发送数据时还要考虑对方的接收能力。
滑动窗口
发送方可以一次发送多个报文给对方，此时也就意味着发送出去的这部分报文当中有相当一部分数据是暂时没有收到应答的。
其实可以将发送缓冲区的数据分为三部分：
- 已经发送并且已经收到ACK的数据
- 已经发送但还没有收到ACK的数据
- 还没有发送的数据
发送缓冲区的第二部分就叫做滑动窗口。
滑动窗口描述的是：发送方不用等待ACK一次所能描述的数据最大量。
滑动窗口存在的最大意义就是可以提高发送数据的效率：
- 滑动窗口的大小等于对方窗口大小与自身拥塞窗口大小的较小值，因为发送数据不仅要考虑对方的接收能力，还要考虑当前网络的状况。
- 我们这里先不考虑拥塞窗口，并且假设对方的窗口大小一直固定为4000，此时发送方不用等待ACK一次所能发送的数据就是4000字节，因此滑动窗口的大小就是4000字节。
- 现在连续发送1001~2000、 2001~3000、 3001~4000、 4001 ~ 5000这四个段的时候，不需要等待任何ACK，可以直接进行发送。
- 当收到对方响应数据的确认序号为2001时，说明1001~2000的数据已经被对方收到了，此时该数据段应该被纳入发送缓冲区当中的第一部分，而由于我们假设对方的窗口大小一直是4000，因此滑动窗口现在可以向右移动，继续发送5001 ~ 6000的数据，以此类推。
- 滑动窗口越大，则网络的吞吐率越高，同时也说明对方的接收能力很强。
当发送方发送出去的数据段陆陆续续收到对应的ACK时，就可以将收到ACK的数据段归置到滑动窗口的左侧，并根据当前的滑动窗口大小决定，是否需要将滑动窗口右侧的数据归置到滑动窗口当中。
TCP的重传机制要求暂时保存发出但未收到确认的数据，而这部分数据实际就位于滑动窗口当中，只有滑动窗口左侧的数据才是可以被覆盖或者删除的，因为这部分数据才是发送并被对方可靠地收到了，所以也可以支持TCP的重传机制。
滑动窗口一定会整体右移吗？
滑动窗口不一定会整体右移的，以刚才的例子为例，假设对方已经收到了1001~2000的数据段并进行了响应，但对方上层一直不从接收缓冲区读取数据，此时当对方收到1001 ~ 2000的数据段时，对方的窗口大小就由4000变为了3000。
当发送端收到对方的响应序号为2001时，就会将1001~2000的数据归置到滑动窗口的左侧，但此时由于对方的接收能力变为了3000，而当1001 ~ 2000的数据归置到滑动窗口的左侧之后，滑动窗口也不会整体右移，而是会将大小变为3000。
因此滑动窗口是不一定在一直右移的，随着对方接收数据能力大小的变化，滑动窗口的大小也在变化。
如何实现滑动窗口
TCP接收和发送缓冲区都可以看作一个字符数组，而滑动窗口实际就可以看作是两个指针限定的一个范围，比如我们用start指向滑动窗口的左侧，end指向的是滑动窗口的右侧，此时在start和end区间范围内的就可以叫做滑动窗口。
当发送端收到对方的响应时，如果相应当中的确认序号为x，窗口大小为win，此时就可以将start更新为x，而将end更新为start+win。
丢包问题
当发送端一次发送多个报文数据时，此时的丢包情况也可以分为两种。
情况一：数据包已经递达，ACK丢包
在发送端连续发送多个报文数据时，部分ACK丢包并不要紧，此时可以通过后续的ACK进行确认。
比如图中2001 ~ 3000和4001 ~ 5000的数据包对应的ACK丢失了，但只要发送端收到了最后5001 ~ 6000数据包的响应，此时发送端也就知道2001 ~ 3000 和 40001 ~ 5000的数据包是收到了的。因为如果接收方收到了确认序号6001之后，就可以认为1 ~ 6000的数据都已经收到了，下次发送应该从序号为6001的数据开始发送。
情况二：数据丢包了
- 当1001 ~ 2000的数据包丢失之后，接收端会一直收到确认序号为1001的响应报文，就是在提醒发送端“下一次应该从序号为1001的字节数据开始发送”。
- 如果发送端连续收到三次确认序号为1001的响应报文，此时就会将1001 ~ 2000的数据包重新进行发送。
- 此时当接收端收到1001 ~ 2000的数据包之后，就会直接发送确认序号为6001的响应报文，因为2001 ~ 6000的数据接收端其实在之前就已经收到了。
这种机制被称为“高速重发机制”，也叫做“快重传”。
需要注意的是，快重传需要在大量的数据重传和个别的数据重传之间做平衡，实际上这个例子中发送端并不知道是1001 ~ 2000的数据丢包了，当发送端重复收到确认序号为1001的响应报文时，理论是哪个发送端将1001 ~ 7000的报文全部重传，但是这样会造成大量数据被重新传送，从而导致网络资源的浪费。所以发送端可以先尝试将1001 ~ 2000的数据进行重传，然后再更具重发后得到的响应报文判断是否需要重传其他数据。
滑动窗口的数据一定都还没有被对方收到吗？
滑动窗口中的数据是暂时还没有收到对应响应报文的数据，但并不是说滑动窗口中的数据一定没有被对方收到，滑动窗口中可能有一部分数据对方已经收到了，但是可能因为滑动窗口内左侧的数据出现了丢包等情况，导致收不到对端的响应报文。
例如图中的1001 ~ 2000的数据包如果在传输过程中丢包了，此时虽然2001 ~ 5000的数据对方都收到了，但此时对方发过来的确认序号为1001，这时候不能确定对端是否收到了后面的数据，滑动窗口也是不能移动的。直到成功补发1001之后的数据后，对端发来5001的确认序号，此时1001 ~ 5000的数据才能被归置到滑动窗口的左侧。
快重传与超时重传
- 快重传是能够快速进程数据的补发，当发送端收到三次连续的应答之后就会触发快重传，而不像超时重传一样需要通过设置重传定时器，在一定的时间之后才能进行重传。
- 虽然快重传能够快速地判定数据包丢失，但是快重传并不难取代超时重传，因为有时数据包丢失之后可能不能收到对方连续三次相同的应答，此时就需要进行超时重传。
- 因此快速重传能提高效率，但是超时重传也是必不可少的！
9. 拥塞控制
两台主机在进行TCP传输的过程中，出现个别数据丢包是很正常的，此时可以通过快重传或者超时重发对数据包进行补发。但是如果出现了大量丢包时，就不能认为是正常现象了。
TCP通信不仅考虑了通信双端主机的问题，还考虑了网络的问题。
- 流量控制：考虑的是对端接收缓冲区的接收能力，进而控制发送方发送数据的速度，避免对端接收缓冲区溢出。
- 滑动窗口：考虑的是发送端不用等待ACK而一次所能发送数据的最大量，进而提高发送端发送数据的效率。
- 拥塞窗口：考虑的是双方网络的问题，如果发送数据大小超过了拥塞窗口的大小就可能会引起网络拥塞。
双方通信时出现少量的丢包时，TCP是允许的，但是如果出现了大量的丢包，TCP就会认为是网络出现了拥塞问题。
如何解决网络拥塞问题？
网络出现大面积瘫痪时，一定是网络中不部分主机共同作用的结果。
- 如果网络中的主机在同一时间内发送了大量数据到网络中，此时位于网络中某些关键节点的路由器就可能会排了很长的报文，最终导致报文无法在超时时间内到达对端主机，此时也就会导致丢包等问题。
- 当网络出现拥塞问题时，通信双方虽然没有很好的解决方案，但它们至少可以做到不加重网络的负担。
- 双方通信时出现大量丢包的情况，不应该立即将这些数据进行重传，而应该选择少发或者是不发，等待网络状况恢复之后再选择慢慢恢复发送数据的速率。
需要注意的是，网络拥塞时影响的不只是一台主机，而应该是该网络当中的所有主机，此时该网络中所有主机都会使用避免拥塞算法。
因此拥塞控制看似是一台主机上采取的策略，其实在网络崩溃之后该网络中所有主机都用采用拥塞控制的策略，这样才能有效缓解网络拥塞问题。
拥塞控制
虽然滑动窗口可以高效可靠地发送大量数据，但是有可能当前的网络状况是拥塞的，此时贸然发送大量数据，会加重网络的拥塞问题。
因此TCP引入慢启动机制，在刚开始通信的时候先发送少量数据，摸清当前网络状况，再决定要安装多大的速度进行发送。
刚开始放数据的时候拥塞窗口的值为1，每收到一个ACK应答时，拥塞窗口的值就乘以2。如果不考虑对方接收数据的能力，俺么滑动窗口的大小就是取决于拥塞窗口的大小的，此时拥塞窗口的大小和滑动窗口的大小就是按指数级增长的。
但是指数级增长是非常快的，如果拥塞窗口的值一直以指数的方式进行增长，就有可能导致网络出现拥塞。
为了避免短时间内再次导致网络拥塞，不能让拥塞窗口按指数级的方式进行增长。此时就引入了慢启动的阈值，当拥塞窗口的大小超过这个阈值之后，拥塞窗口就是线性增长的。
当TCP刚开始启动的时候，慢启动阈值设置为对方窗口大小的最大值。在每次超时重发的时候，慢启动阈值会变成当前拥塞窗口的一般，同时拥塞窗口的值被置为1，如此循环下去。
主机在进行网络通信的时候，实际就是在不断进行指数增长，加法增大和乘法减小。
需要注意的是，在同一网络中，不是所有主机此时的网络状态都是一样的，每台主机认为拥塞窗口的大小不一样是一样的。即便是同区域的两台主机在同一时刻认为拥塞窗口的大小也不一定是完全相同的。因此在同一时刻，可能一部分主机正在进行网络通信，而另一部分主机可能已经发送网络拥塞了。
10. 延迟应答
由于TCP的流量控制机制，接收端进行接收数据后，如果立刻返回ACK应答，此时由于数据还没有被消费，那么返回的窗口大小此时就是缓冲区中剩下的那一小部分区域，也就是说，此时返回的窗口可能是比较小的。
- 假设接收缓冲区大小为1M，如果对方一次发送600K的数据，此时立刻进行ACK应答，那么返回的窗口大小就是1M - 600K = 400K。
- 但实际上接收端数据数据的速度是很快的，这400K的数据很快就被处理掉了。
- 在这种情况下，如果接收端返回的窗口更大一些，它也能处理的过来。
- 于是，接收端最好在收到消息之后，延迟一小段时间再进行应答，这样返回的窗口更大一些。
延时应答不是为了提高网络传输的可靠性，而是流出一点时间让接收缓冲区的上层及时消费数据，这样返回的窗口就跟大一些，从高增大网络吞吐量，提高数据的传输效率。
数据包的延迟应答有数量限制和时间限制，延迟应答的数据包的数量不能超过一定的范围，且延迟应答的时间不能超过最大延迟时间（这个时间不会导致误超时重传）。
延迟应答具体的数量和超时时间，不同操作系统有差异，一般N取2，超时时间取200ms。
11. 捎带应答
捎带应答其实是TCP通信时最常规的一种方式，就好比主机A给主机B发送了一条消息，当主机B收到这条消息之后需要对其进行ACK应答，但是刚好主机B也要给主机A发送消息，此时这个ACK就可以搭顺风车，和消息一起发送过去。既发送数据，又完成了对收到数据的响应，这种方式就叫做捎带应答。
有了捎带应答，双方通信就可以减少单纯的确认报文了。
此外，由于捎带应答的报文携带了有效数据，那么此时对方也要回发一个ACK响应，这样的话，不仅可以保证报文被对方成功收到了，也能保证发给对方的响应被成功收到了。
12. 面向字节流
当创建一个TCP的socket时，会同时在内核中创建一个发送缓冲区和一个接收缓冲区。
- 调用write函数就是将数据写入到发送缓冲区当中，此时write函数就返回了，缓冲区中的数据又TCP在合适的时候进行发送。
- 如果发送的字节数太长，TCP会将其拆成多个数据包进行发送。而如果字节数太短，TCP不会立刻发送，而是会等到合适的时机再进行发送。
- 接收数据的时候，数据从网卡驱动程序到内核的接收缓冲区，再由read函数去读取数据。read函数读取的字节数，也是可以根据用于意愿而调整的。
由于缓冲区的存在，TCP程序的读写不需要一一对应。比如：
- 写100个字节数据时，可以调用一次write函数。
- 读100个字节数据的时候，可以读100次，每次读1个字节。
对于TCP来说，它并不关心缓冲区内的是什么数据，在TCP看来，都是一个个的字节数据而已。至于怎么解析数据，由应用层决定，TCP只负责发送，这就是面向字节流。
13. 粘包问题
什么是粘包问题？
- 粘包问题通常出现在使用TCP作为传输层协议的网络通信总。TCP是一个面向连接的协议，它保证传输的可靠性，但是并不难保证数据的边界。
- 站在应用层来看，TCP是一个一个地发送报文，按顺序放在缓冲区中，但是站在应用层的角度，看到的只是一串连续的数据。
- 在发送方连续发送多个小数据包时，TCP协议会将它们组合成较大的数据块进行传输，而接收方在接收数据时并不知道原始的数据边界，因此就无法正确地将其拆分开来。
这就是所谓的粘包问题。
如何解决粘包问题
要解决粘包粘包问题，本质就是要明确报文和报文之间的边界。
- 对于定长的包，保证每次都按固定大小读取即可。
- 对于变长的包，可以在报头的位置，约定一个包总长度的字段，从而就知道了包的结束位置。比如HTTP报头当中就包含Content-Length属性，表示正文的长度。
- 对于变长的包，还可以在包和包之间用明确的分隔符。因为应用层协议是程序员自己来定的，只要保证分隔符不喝正文冲突即可。
UDP是否存在粘包问题？
- 对于UDP，如果还没有上层交付数据，UDP的报文长度依然存在，同时，UDP是一个一个把数据交付给应用层的，有很明确的数据边界。
- 站在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收。不会出现收一部分的情况。
因此UDP是不存在粘包问题的，根本原因就是UDP报头当中的16位UDP长度记录了UDP报文的长度，因此UDP在底层的时候就把报文和报文之间的边界明确了。而TCP存在粘包问题就是因为TCP是面向字节流的，TCP报文直接没有明确的边界。
14. TCP异常情况
进程终止
当客户端正常访问服务器时，如果客户端突然崩溃了，此时建立好的连接会怎样？
当一个进程在正常连接的时候退出，该进程曾经所占用的文件描述符都会被操作系统自动关闭，也就是说，操作系统会去调用close函数，此时操作系统在底层仍然会进行四次握手，然后释放对应的资源。TCP底层也仍然可以发送FIN，和正常关闭连接没有什么区别。
机器重启
当客户端正常访问服务器时，如果将客户端重启，此时建立好的连接会怎样？
当客户端机器重启之后，操作系统会先杀掉所有进程之后再进行关机重启，此时双操作系统也会正常完成四次挥手，然后释放对应的连接资源。
机器掉电/网线断开
当客户端正常访问服务器时，如果客户端突然掉线了，此时建立好的连接会怎样？
当客户端掉线之后，服务器在短时间之内无法知道客户端掉线了，因此在服务器端会维持与客户端建立的连接，但这个连接也不会一直维持，因为TCP是有保活策略的。
- 服务器会定期查看客户端的存在状况，检查对方是否在线，如果连接多次都没有收到ACK响应，那么服务器就会关闭这条连接。
- 此外，客户端会可能会定期向服务器“报平安”，如果服务器长时间没有收到客户端的消息，此时服务器也会将对应的连接关闭。
其中服务器定期询问客户端的存在状态的做法，叫做基于保活定时器的一种心跳机制，是由TCP实现的。此外，应用层的某些协议，也有一定类似的检测机制，例如基于长连接的HTTP，也会定期检测对方的存在状态。
15. 总结
从文章的长度也可以看出，TCP协议是非常复杂的，它之所以这么复杂，就是因为它既要保持可靠性，同时又要尽可能地提高性能。
可靠性：
- 检验和
- 序列号
- 确认应答
- 超时重传
- 连接管理
- 流量控制
- 拥塞控制
提高性能：
- 滑动窗口
- 快速重传
- 延迟应答
- 捎带应答
TCP的这些机制有些是通过协议来体现的，有些是通过代码逻辑实现的。
TCP定时器
此外，TCP当中还设置了各种定时器
- 重传定时器：为了控制丢失的报文段或者丢弃的报文段，也就是对报文段确认的等待时间。
- 坚持定时器：专门为对方零窗口通知而设立的，也就是向对方发送窗口探测的时间间隔。
- 保活定时器：为了检查空闲连接的存在状态，也就是向对方发送探查报文的时间间隔。
- TIME_WAIT定时器：双方在四次挥手后，主动断开连接的一方需要等待的时长。
理解传输控制协议
TCP的各种机制实际都没有谈及数据真正的发送，这些都叫做传输数据的策略。TCP协议是在网络数据传输当中做决策的，它提供的是理论支持，比如TCP只是要求发出的报文在一段时间内收不到ACK应答就进行超时重传，而数据真正的发送实际是由底层的IP和MAC帧完成的。
TCP做决策，IP+MAC做执行，我们将它们统称为通信细节，它们最终的目的就是将数据传输到对端主机。而传输数据的目的是什么则是由应用层决定的，因此应用层决定的是通信的意义，而传输层及其往下的各层决定的是通信的方式。
16. 基于TCP的应用层协议
常见基于TCP的应用层协议如下：
- HTTP（超文本传输协议）
- HTTPS（安全数据传输协议）
- SSH（安全外壳协议）
- Telnet（远程终端协议）
- FTP（文件传输协议）
- SMTP（电子邮件传输协议）
谈谈云服务器
SSH也就是XShell的底层协议，我们使用XShell时实际就是使用XShell的ssh客户端连接我们的云服务器。
我们在使用XSheel时，可以通过 ssh 用户名@主机名（IP地址） 的方式连接云服务器。实际因为我们的云服务器中存在sshd这样的服务。
这实际就是ssh服务的服务器端，我们使用的 ssh 用户名@主机名 命令当中的ssh实际就是ssh的客户端，因此我们连接云服务器的本质就是在用ssh的客户端连接ssh服务器。
使用netstat可以查看对应的ssh服务
我们在云服务上敲出的各种命令，最终会通过网络编程套接字的方式发送给云服务器，由服务器来对我们的命令进行各种解释，进而执行对应的动作。