Linux网络协议之TCP协议(传输层)
文章目录
1.理解TCP协议
TCP全称为“传输控制协议（Transmission Control Protocol）”，TCP协议是当今互联网当中使用最为广泛的传输层协议，没有之一
TCP协议被广泛应用，其根本原因就是提供了详尽的可靠性保证，基于TCP的上层应用非常多，比如HTTP、HTTPS、FTP、SSH等，甚至MySQL底层使用的也是TCP
2.谈谈可靠性问题
我们需要思考一个问题：为什么网络中会存在不可靠？
- 现代的计算机大部分都是基于冯诺依曼体系结构的
- 虽然这里的输入设备、输出设备、内存、CPU都在一台机器上，但这几个硬件设备是彼此独立的。如果它们之间要进行数据交互，就必须要想办法进行通信，因此这几个设备实际是用“线”连接起来的，其中连接内存和外设之间的“线”叫做IO总线，而连接内存和CPU之间的“线”叫做系统总线。由于这几个硬件设备都是在一台机器上的，因此这里传输数据的“线”是很短的，传输数据时出现错误的概率也非常低
- 但如果要进行通信的各个设备相隔千里，那么连接各个设备的“线”就会变得非常长，传输数据时出现错误的概率也会大大增高，此时要保证传输到对端的数据无误，就必须引入可靠性
- 总之，网络中存在不可靠的根本原因就是，长距离数据传输所用的“线”太长了，数据在长距离传输过程中就可能会出现各种各样的问题，而TCP就是在此背景下诞生的，TCP就是一种保证可靠性的协议
我们之前提到过UDP是一种不可靠的传输协议，那么让我们来思考下为什么还会存在UDP这种传输协议呢？
- TCP协议是可靠的协议，也就意味着TCP协议需要做更多的工作来保证传输数据的可靠，并且引起不可靠的因素越多，保证可靠的成本（时间+空间）就越高
- 比如数据在传输过程中出现了丢包、乱序、检验和失败等，这些都是不可靠的情况
- 由于TCP要想办法解决数据传输不可靠的问题，因此TCP使用起来一定比UDP复杂，并且维护成本特别高
- UDP协议是不可靠的协议，也就意味着UDP协议不需要考虑数据传输时可能出现的问题，因此UDP无论是使用还是维护都足够简单
- 需要注意的是，虽然TCP复杂，但TCP的效率不一定比UDP低，TCP当中不仅有保证可靠性的机制，还有保证传输效率的各种机制
UDP和TCP没有谁最好，只有谁最合适，网络通信时具体采用TCP还是UDP完全取决于上层的应用场景。如果应用场景严格要求数据在传输过程中的可靠性，那么就必须采用TCP协议，如果应用场景允许数据传输出现少量丢包，那么肯定优先选择UDP协议，因为UDP协议足够简单
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报头当中的6位标志位：
- URG：紧急指针是否有效
- ACK：确认序号是否有效
- PSH：提示接收端应用程序立刻将TCP接收缓冲区当中的数据读走
- RST：表示要求对方重新建立连接。我们把携带RST标识的报文称为复位报文段
- SYN：表示请求与对方建立连接。我们把携带SYN标识的报文称为同步报文段
- FIN：通知对方，本端要关闭了。我们把携带FIN标识的报文称为结束报文段
TCP报头在内核当中本质就是一个位段类型，给数据封装TCP报头时，实际上就是用该位段类型定义一个变量，然后填充TCP报头当中的各个属性字段，最后将这个TCP报头拷贝到数据的首部，至此便完成了TCP报头的封装
4.关于TCP的两个问题
第一个问题：TCP如何将报头与有效载荷进行分离？
- 当TCP从底层获取到一个报文后，虽然TCP不知道报头的具体长度，但报文的前20个字节是TCP的基本报头，并且这20字节当中涵盖了4位的首部长度
因此TCP是这样分离报头与有效载荷的：
- 当TCP获取到一个报文后，首先读取报文的前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的报头中涵盖了目的端口号，因此TCP可以提取出报头中的目的端口号，找到对应的应用层进程，进而将有效载荷交给对应的应用层进程进行处理
说明一下： 内核中用哈希的方式维护了端口号与进程ID之间的映射关系，因此传输层可以通过端口号快速找到其对应的进程ID，进而找到对应的应用层进程
5.TCP序号与确认序号
我们来思考一个问题：什么是真正的可靠？
在进行网络通信时，一方发出的数据后，它不能保证该数据能够成功被对端收到，因为数据在传输过程中可能会出现各种各样的错误，只有当收到对端主机发来的响应消息后，该主机才能保证上一次发送的数据被对端可靠的收到了，这就叫做真正的可靠
注：实线表示该数据能够被对方可靠的收到，虚线则不能保证
但TCP要保证的是双方通信的可靠性，虽然此时主机A能够保证自己上一次发送的数据被主机B可靠的收到了，但主机B也需要保证自己发送给主机A的响应数据被主机A可靠的收到了。因此主机A在收到了主机B的响应消息后，还需要对该响应数据进行响应，但此时又需要保证主机A发送的响应数据的可靠性…，这样就陷入了一个死循环
因为只有当一端收到对方的响应消息后，才能保证自己上一次发送的数据被对端可靠的收到了，但双方通信时总会有最新的一条消息，因此无法百分之百保证可靠性
所以严格意义上来说，互联网通信当中是不存在百分之百的可靠性的，因为双方通信时总有最新的一条消息得不到响应。但实际没有必要保证所有消息的可靠性，我们只要保证双方通信时发送的每一个核心数据都有对应的响应就可以了。而对于一些无关紧要的数据（比如响应数据），我们没有必要保证它的可靠性。因为对端如果没有收到这个响应数据，会判定上一次发送的报文丢失了，此时对端可以将上一次发送的数据进行重传
这种策略在TCP当中就叫做确认应答机制。需要注意的是，确认应答机制不是保证双方通信的全部消息的可靠性，而是只要一方收到了另一方的应答消息，就说明它上一次发送的数据被另一方可靠的收到了
下面我们来理解下序号与确认序号：
首先我们来理解下，32位序号：
- 如果双方在进行数据通信时，只有收到了上一次发送数据的响应才能发下一个数据，那么此时双方的通信过程就是串行的，效率可想而知
- 因此双方在进行网络通信时，允许一方 向另一方连续发送多个报文数据，只要保证发送的每个报文都有对应的响应消息就行了，此时也就能保证这些报文被对方收到了
- 但在连续发送多个报文时，由于各个报文在进行网络传输时选择的路径可能是不一样的，因此这些报文到达对端主机的先后顺序也就可能和发送报文的顺序是不同的。但报文有序也是可靠性的一种，因此TCP报头中的32位序号的作用之一实际就是用来保证报文的有序性的
TCP将发送出去的每个字节数据都进行了编号，这个编号叫做序列号
- 比如现在发送端要发送3000字节的数据，如果发送端每次发送1000字节，那么就需要用三个TCP报文来发送这3000字节的数据
- 此时这三个TCP报文当中的32位序号填的就是发送数据中首个字节的序列号，因此分别填的是1、1001和2001
此时接收端收到了这三个TCP报文后，就可以根据TCP报头当中的32位序列号对这三个报文进行顺序重排（该动作在传输层进行），重排后将其放到TCP的接收缓冲区当中，此时接收端这里报文的顺序就和发送端发送报文的顺序是一样的了
- 接收端在进行报文重排时，可以根据当前报文的32位序号与其有效载荷的字节数，进而确定下一个报文对应的序号
让我们再来看一下，32位确认序号：
TCP报头当中的32位确认序号是告诉对端，我当前已经收到了哪些数据，你的数据下一次应该从哪里开始发
以刚才的例子为例，当主机B收到主机A发送过来的32位序号为1的报文时，由于该报文当中包含1000字节的数据，因此主机B已经收到序列号为1-1000的字节数据，于是主机B发给主机A的响应数据的报头当中的32位确认序号的值就会填成1001
- 一方面是告诉主机A，序列号在1001之前的字节数据我已经收到了
- 另一方面是告诉主机A，下次向我发送数据时应该从序列号为1001的字节数据开始进行发送
之后主机B对主机A发来的其他报文进行响应时，发给主机A的响应当中的32为确认序号的填法也是类似的道理
注意：响应数据与其他数据一样，也是一个完整的TCP报文，尽管该报文可能不携带有效载荷，但至少是一个TCP报头
一点小思考：报文丢失怎么办？
还是以刚才的例子为例，主机A发送了三个报文给主机B，其中每个报文的有效载荷都是1000字节，这三个报文的32位序号分别是1、1001、2001
如果这三个报文在网络传输过程中出现了丢包，最终只有序号为1和2001的报文被主机B收到了，那么当主机B在对报文进行顺序重排的时候，就会发现只收到了1-1000和2001-3000的字节数据。此时主机B在对主机A进行响应时，其响应报头当中的32位确认序号填的就是1001，告诉主机A下次向我发送数据时应该从序列号为1001的字节数据开始进行发送
注意：
- 此时主机B在给主机A响应时，其32位确认序号不能填3001，因为1001-2000是在3001之前的，如果直接给主机A响应3001，就说明序列号在3001之前的字节数据全都收到了
- 因此主机B只能给主机A响应1001，当主机A收到该确认序号后就会判定序号为1001的报文丢包了，此时主机A就可以选择进行数据重传
因此发送端可以根据对端发来的确认序号，来判断是否某个报文可能在传输过程中丢失了
一点小思考：为什么要用两套序号机制？
如果通信双方只是一端发送数据，另一端接收数据，那么只用一套序号就可以了
- 发送端在发送数据时，将该序号看作是32位序号
- 接收端在对发送端发来的数据进行响应时，将该序号看作是32位确认序号
但实际TCP却没有这么做，根本原因就是因为TCP是全双工的，双方可能同时想给对方发送消息
- 双方发出的报文当中，不仅需要填充32位序号来表明自己当前发送数据的序号
- 还需要填充32位确认序号，对对方上一次发送的数据进行确认，告诉对方下一次应该从哪一字节序号开始进行发送
因此在进行TCP通信时，双方都需要有确认应答机制，此时一套序号就无法满足需求了，因此需要TCP报头当中出现了两套序号
最后我们总结一下：
- 32位序号的作用是，保证数据的按序到达，同时这个序号也是作为对端发送报文时填充32位确认序号的根据
- 32位确认序号的作用是，告诉对端当前已经收到的字节数据有哪些，对端下一次发送数据时应该从哪一字节序号开始进行发送
- 序号和确认序号是确认应答机制的数据化表示，确认应答机制就是由序号和确认序号来保证的
- 此外，通过序号和确认序号还可以判断某个报文是否丢失
6.TCP缓冲区
TCP的缓冲区分为：接收缓冲区和发送缓冲区
TCP本身是具有接收缓冲区和发送缓冲区的：
接收缓冲区用来暂时保存接收到的数据发送缓冲区用来暂时保存还未发送的数据这两个缓冲区都是在TCP传输层内部实现的
- TCP发送缓冲区当中的数据由上层应用应用层进行写入。当上层调用write/send这样的系统调用接口时，实际不是将数据直接发送到了网络当中，而是将数据从应用层拷贝到了TCP的发送缓冲区当中
- TCP接收缓冲区当中的数据最终也是由应用层来读取的。当上层调用read/recv这样的系统调用接口时，实际也不是直接从网络当中读取数据，而是将数据从TCP的接收缓冲区拷贝到了应用层而已
- 就好比调用read和write进行文件读写时，并不是直接从磁盘读取数据，也不是直接将数据写入到磁盘上，而对文件缓冲区进行的读写操作
- 当数据写入到TCP的发送缓冲区后，对应的write/send函数就可以返回了，至于发送缓冲区当中的数据具体什么时候发，怎么发等问题实际都是由TCP决定的
- 我们之所以称TCP为传输层控制协议，就是因为最终数据的发送和接收方式，以及传输数据时遇到的各种问题应该如何解决，都是由TCP自己决定的，用户只需要将数据拷贝到TCP的发送缓冲区，以及从TCP的接收缓冲区当中读取数据即可
- 需要注意的是，通信双方的TCP层都是一样的，因此通信双方的TCP层都是既有发送缓冲区又有接收缓冲区
最后让我们来思考一个问题：TCP的发送缓冲区和接收缓冲区存在的意义
发送缓冲区和接收缓冲区的作用：
- 数据在网络中传输时可能会出现某些错误，此时就可能要求发送端进行数据重传，因此TCP必须提供一个发送缓冲区来暂时保存发送出去的数据，以免需要进行数据重传。只有当发出去的数据被对端可靠的收到后，发送缓冲区中的这部分数据才可以被覆盖掉
- 接收端处理数据的速度是有限的，为了保证没来得及处理的数据不会被迫丢弃，因此TCP必须提供一个接收缓冲区来暂时保存未被处理的数据，因为数据传输是需要耗费资源的，我们不能随意丢弃正确的报文。此外，TCP的数据重排也是在接收缓冲区当中进行的
经典的生产者消费者模型：
- 对于发送缓冲区来说，上层应用不断往发送缓冲区当中放入数据，下层网络层不断从发送缓冲区当中拿出数据准备进一步封装。此时上层应用扮演的就是生产者的角色，下层网络层扮演的就是消费者的角色，而发送缓冲区对应的就是“交易场所”
- 对于接收缓冲区来说，上层应用不断从接收缓冲区当中拿出数据进行处理，下层网络层不断往接收缓冲区当中放入数据。此时上层应用扮演的就是消费者的角色，下层网络层扮演的就是生产者的角色，而接收缓冲区对应的就是“交易场所”
- 因此引入发送缓冲区和接收缓冲区相当于引入了两个生产者消费者模型，该生产者消费者模型将上层应用与底层通信细节进行了解耦，此外，生产者消费者模型的引入同时也支持了并发和忙闲不均
7.TCP窗口大小
当发送端要将数据发送给对端时，本质是把自己发送缓冲区当中的数据发送到对端的接收缓冲区当中。但缓冲区是有大小的，如果接收端处理数据的速度小于发送端发送数据的速度，那么总有一个时刻接收端的接收缓冲区会被打满，这时发送端再发送数据过来就会造成数据丢包，进而引起丢包重传等一系列的连锁反应
因此TCP报头当中就有了16位的窗口大小，这个16位窗口大小当中填的是自身接收缓冲区中剩余空间的大小，也就是当前主机接收数据的能力接收端在对发送端发来的数据进行响应时，就可以通过16位窗口大小告知发送端自己当前接收缓冲区剩余空间的大小，此时发送端就可以根据这个窗口大小字段来调整自己发送数据的速度
- 窗口大小字段越大，说明接收端接收数据的能力越强，此时发送端可以提高发送数据的速度
- 窗口大小字段越小，说明接收端接收数据的能力越弱，此时发送端可以减小发送数据的速度
- 如果窗口大小的值为0，说明接收端接收缓冲区已经被打满了，此时发送端就不应该再发送数据了
让我们来理解一些现象：
- 在编写TCP套接字时，我们调用read/recv函数从套接字当中读取数据时，可能会因为套接字当中没有数据而被阻塞住，本质是因为TCP的接收缓冲区当中没有数据了，我们实际是阻塞在接收缓冲区当中了
- 而我们调用write/send函数往套接字中写入数据时，可能会因为套接字已经写满而被阻塞住，本质是因为TCP的发送缓冲区已经被写满了，我们实际是阻塞在发送缓冲区当中了
- 在生产者消费者模型当中，如果生产者生产数据时被阻塞，或消费者消费数据时被阻塞，那么一定是因为某些条件不就绪而被阻塞
8.TCP的六个标志位
为什么会存在标志位？
TCP报文的种类多种多样，除了正常通信时发送的普通报文，还有建立连接时发送的请求建立连接的报文，以及断开连接时发送的断开连接的报文等等收到不同种类的报文时完美需要对应执行动作，比如正常通信的报文需要放到接收缓冲区当中等待上层应用进行读取，而建立和断开连接的报文本质不是交给用户处理的，而是需要让操作系统在TCP层执行对应的握手和挥手动作也就是说不同种类的报文对应的是不同的处理逻辑，所以我们要能够区分报文的种类。而TCP就是使用报头当中的六个标志字段来进行区分的，这六个标志位都只占用一个比特位，为0表示假，为1表示真
TCP中的六个标志位分别是：SYN、ACK、FIN、URG、PSH、RST
对于SYN：
- 报文当中的SYN被设置为1，表明该报文是一个连接建立的请求报文
- 只有在连接建立阶段，SYN才被设置，正常通信时SYN不会被设置
对于ACK：
- 报文当中的ACK被设置为1，表明该报文可以对收到的报文进行确认
- 一般除了第一个请求报文没有设置ACK以外，其余报文基本都会设置ACK，因为发送出去的数据本身就对对方发送过来的数据具有一定的确认能力，因此双方在进行数据通信时，可以顺便对对方上一次发送的数据进行响应
对于FIN：
- 报文当中的FIN被设置为1，表明该报文是一个连接断开的请求报文
- 只有在断开连接阶段，FIN才被设置，正常通信时FIN不会被设置
对于URG：
- 双方在进行网络通信的时候，由于TCP是保证数据按序到达的，即便发送端将要发送的数据分成了若干个TCP报文进行发送，最终到达接收端时这些数据也都是有序的，因为TCP可以通过序号来对这些TCP报文进行顺序重排，最终就能保证数据到达对端接收缓冲区中时是有序的
- TCP按序到达本身也是我们的目的，此时对端上层在从接收缓冲区读取数据时也必须是按顺序读取的。但是有时候发送端可能发送了一些“紧急数据”，这些数据需要让对方上层提取进行读取，此时应该怎么办呢？
此时就需要用到URG标志位，以及TCP报头当中的16位紧急指针
- 当URG标志位被设置为１时，需要通过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，表示要求对方重新建立连接。
- 在双方建立好连接进行正常通信时，如果通信中途发现之前建立好的连接出现了异常也会要求重新建立连接
9.确认应答机制(ACK)
TCP保证可靠性的机制之一就是确认应答机制
确认应答机制就是由TCP报头当中的，32位序号和32位确认序号来保证的。需要再次强调的是，确认应答机制不是保证双方通信的全部消息的可靠性，而是通过收到对方的应答消息，来保证自己曾经发送给对方的某一条消息被对方可靠的收到了
如何理解TCP将每个字节的数据都进行了编号？
TCP是面向字节流的，我们可以将TCP的发送缓冲区和接收缓冲区都想象成一个字符数组
- 此时上层应用拷贝到TCP发送缓冲区当中的每一个字节数据天然有了一个序号，这个序号就是字符数组的下标，只不过这个下标不是从0开始的，而是从1开始往后递增的
- 而双方在通信时，本质就是将自己发送缓冲区当中的数据拷贝到对方的接收缓冲区当中
- 发送方发送数据时报头当中所填的序号，实际就是发送的若干字节数据当中，首个字节数据在发送缓冲区当中对应的下标
- 接收方接收到数据进行响应时，响应报头当中的确认序号实际就是，接收缓冲区中接收到的最后一个有效数据的下一个位置所对应的下标
- 当发送方收到接收方的响应后，就可以从下标为确认序号的位置继续进行发送了
10.超时重传机制
超时重传机制概念：当发送端发送数据，如果在一段时间内没有收到应答(ACK)，会直接重发数据
但是在我们在传输的时候可能会发生丢包问题
丢包分为两种情况：
- 第一种情况：发送的数据报文丢失了，此时发送端在一定时间内收不到对应的响应报文，就会进行超时重传
- 第二种情况：其实不是发送端发送的数据丢包了，而是对方发来的响应报文丢包了，此时发送端也会因为收不到对应的响应报文，而进行超时重传
- 当出现丢包时，发送方是无法辨别是发送的数据报文丢失了，还是对方发来的响应报文丢失了，因为这两种情况下发送方都收不到对方发来的响应报文，此时发送方就只能进行超时重传
- 如果是对方的响应报文丢失而导致发送方进行超时重传，此时接收方就会再次收到一个重复的报文数据，但此时也不用担心，接收方可以根据报头当中的32位序号来判断曾经是否收到过这个报文，从而达到报文去重的目的
- 需要注意的是，当发送缓冲区当中的数据被发送出去后，操作系统不会立即将该数据从发送缓冲区当中删除或覆盖，而会让其保留在发送缓冲区当中，以免需要进行超时重传，直到收到该数据的响应报文后，发送缓冲区中的这部分数据才可以被删除或覆盖
11.连接管理机制
首先我们来理解一下连接：一台主机可能收到很多的连接，操作系统需要对连接进行管理，先描述后组织。所以连接在内核层会有对应数据结构。所以建立连接是有时间和空间的成本
11.1 三次握手和四次挥手图解
11.2 详解三次握手过程
详解三次握手过程：
双方在进行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函数进行数据交互了
11.3 详解四次挥手过程
详解四次挥手过程：
由于双方维护连接都是需要成本的，因此当双方TCP通信结束之后就需要断开连接，断开连接的这个过程我们称之为四次挥手
还是以服务器和客户端为例，当客户端与服务器通信结束后，需要与服务器断开连接，此时就需要进行四次挥手
- 第一次挥手：客户端向服务器发送的报文当中的FIN位被设置为1，表示请求与服务器断开连接
- 第二次挥手：服务器收到客户端发来的断开连接请求后对其进行响应
- 第三次挥手：服务器收到客户端断开连接的请求，且已经没有数据需要发送给客户端的时候，服务器就会向客户端发起断开连接请求
- 第四次挥手：客户端收到服务器发来的断开连接请求后对其进行响应
- 四次挥手结束后双方的连接才算真正断开
为什么是四次挥手？
- 由于TCP是全双工的，建立连接的时候需要建立双方的连接，断开连接时也同样如此。在断开连接时不仅要断开从客户端到服务器方向的通信信道，也要断开从服务器到客户端的通信信道，其中每两次挥手对应就是关闭一个方向的通信信道，因此断开连接时需要进行四次挥手
- 需要注意的是，四次挥手当中的第二次和第三次挥手不能合并在一起，因为第三次握手是服务器端想要与客户端断开连接时发给客户端的请求，而当服务器收到客户端断开连接的请求并响应后，服务器不一定会马上发起第三次挥手，因为服务器可能还有某些数据要发送给客户端，只有当服务器端将这些数据发送完后才会向客户端发起第三次挥手
四次挥手时的状态变化：
四次挥手时的状态变化如下：
- 在挥手前客户端和服务器都处于连接建立后的ESTABLISHED状态
- 客户端为了与服务器断开连接主动向服务器发起连接断开请求，此时客户端的状态变为FIN_WAIT_1
- 服务器收到客户端发来的连接断开请求后对其进行响应，此时服务器的状态变为CLOSE_WAIT
- 当服务器没有数据需要发送给客户端的时，服务器会向客户端发起断开连接请求，等待最后一个ACK到来，此时服务器的状态变为LASE_ACK
- 客户端收到服务器发来的第三次挥手后，会向服务器发送最后一个响应报文，此时客户端进入TIME_WAIT状态
- 当服务器收到客户端发来的最后一个响应报文时，服务器会彻底关闭连接，变为CLOSED状态
- 而客户端则会等待一个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（Maximum Segment Lifetime，报文最大生存时间）的时间才能进入CLOSED状态
MSL在RFC1122中规定为两分钟，但是各个操作系统的实现不同，比如在Centos7上默认配置的值是60s。我们可以通过下面命令查看MSL：
cat /proc/sys/net/ipv4/tcp_fin_timeout #查看MSL的值
TIME_WAIT的等待时长设置为两个MSL的原因：
- MSL是TCP报文的最大生存时间，因此TIME_WAIT状态持续存在2MSL的话，就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失
- 同时也是在理论上保证最后一个报文可靠到达的时间
12.TCP的滑动窗口
滑动窗口存在的最大意义就是可以提高发送数据的效率：
- 滑动窗口的大小等于对方窗口大小与自身拥塞窗口大小的较小值，因为发送数据时不仅要考虑对方的接收能力，还要考虑当前网络的状况
- 我们这里先不考虑拥塞窗口，并且假设对方的窗口大小一直固定为4000，此时发送方不用等待ACK一次所能发送的数据就是4000字节，因此滑动窗口的大小就是4000字节（四个段）
- 现在连续发送1001-2000、2001-3000、3001-4000、4001-5000这四个段的时候，不需要等待任何ACK，可以直接进行发送
- 当收到对方响应的确认序号为2001时，说明1001-2000这个数据段已经被对方收到了，此时该数据段应该被纳入发送缓冲区当中的第一部分，而由于我们假设对方的窗口大小一直是4000，因此滑动窗口现在可以向右移动，继续发送5001-6000的数据段，以此类推
- 滑动窗口越大，则网络的吞吐率越高，同时也说明对方的接收能力很强
12.1 滑动窗口的由来
TCP以1个段为单位，每发一个段进行一次确认应答的处理。这样的传输方式有一个缺点：包的往返时间越长通信性能就越低
刚才我们讨论了确认应答策略, 对每一个发送的数据段, 都要给一个ACK确认应答，收到ACK后再发送下一个数据段。这样做有一个比较大的缺点, 就是性能较差。尤其是数据往返的时间较长的时候
既然这样一发一收的方式性能较低, 那么我们一次发送多条数据, 就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了）为解决这个问题，TCP引入了窗口这个概念。即使在往返时间较长的情况下，它也能控制网络性能的下降。如图所示，确认应答不再是以每个分段，而是以更大的单位进行确认时，转发时间将会被大幅度的缩短。也就是说，发送端主机，在发送了一个段以后不必要一直等待确认应答，而是继续发送
- 窗口大小就是指无需等待确认应答而可以继续发送数据的最大值。图中，窗口大小为4个段，也就是4000个字节
- 发送前四个段的时候, 不需要等待任何ACK, 直接发送
- 收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推
- 操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉
- 窗口越大, 则网络的吞吐率就越高
这种机制就被称为滑动窗口机制
再具体一点就是：
12.2 滑动窗口存在的问题
滑动窗口的大小：
数据包已经传输给对方，但是对方返回的ACK数据包丢失：
数据包已经抵达, ACK被丢了
这种情况下, 部分ACK丢了并不要紧, 因为可以通过后续的ACK进行确认
传输的数据包直接丢失，或者说是某个报文段丢失的情况
- 当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 "我想要的是 1001开始的数据"一样
- 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送
- 这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中
13.TCP的流量控制
接收端处理数据的速度是有限的。 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送,就会造成丢包, 继而引起丢包重传等等一系列连锁反应。因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度。这个机制就叫做流量控制(Flow Control)
- 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端
- 窗口大小字段越大, 说明网络的吞吐量越高
- 接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端
让我们来思考下，什么时候回复 发送方给接收方发送的数据？两种回复方式！
- 发送方主动给接收方发送窗口探测包，询问接收方的接收能力。注意：窗口探测包的数据的大小为固定的1字节
- 接收方主动给发送方发送窗口更新通知
- 发送端接受到这个窗口之后, 就会减慢自己的发送速度
- 如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端
接收端如何把窗口大小告诉发送端呢? 回忆我们的TCP首部中, 有一个16位窗口字段, 就是存放了窗口大小信息;那么问题来了, 16位数字最大表示65535, 那么TCP窗口最大就是65535字节么?
实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是 窗口字段的值左移 M 位
14.TCP的拥塞控制
- 虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题
- 因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据,是很有可能引起雪上加霜的
- TCP引入 慢启动机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据
此处引入一个概念称为
拥塞窗口，详解如下：
- 发送开始的时候, 定义拥塞窗口大小为1个数据段（1MSS）
- 每次收到一个ACK应答, 拥塞窗口加1
- 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的滑动窗口大小做比较, 取较小的值作为实际发送的窗口
像上面这样的拥塞窗口增长速度, 是指数级别的。“慢启动” 只是指初使时慢, 但是增长速度非常快
- 为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍
- 此处引入一个叫做
慢启动的阈值- 当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长
- 当TCP开始启动的时候, 慢启动阈值等于窗口最大值
- 在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1
少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞，当TCP通信开始后, 网络吞吐量会逐渐上升，随着网络发生拥堵, 吞吐量会立刻下降
但是这种拥塞窗口的大小一旦到达网络拥塞的情况时，拥塞窗口的大小会直接一下子变为慢启动时的阈值，即1个MSS，但是这种情况其实是不科学的，因为我一次丢包有可能是正常的，这种正常的情况的发生有可能是网络闪断了，当网络闪断的时候，拥塞串口的大小就会被置为1，然后再慢启动，再进行拥塞控制，针对这种情况，我们就需要一种快恢复的机制
总结一下：TCP为了实现拥塞控制，总共采用了慢启动机制、拥塞避免机制、快重传机制和快恢复机制
图示说明：
- 指数增长。刚开始进行TCP通信时拥塞窗口的值为1，并不断按指数的方式进行增长
- 加法增大。慢启动的阈值初始时为对方窗口大小的最大值，图中慢启动阈值的初始值为16，因此当拥塞窗口的值增大到16时就不再按指数形式增长了，而变成了的线性增长
- 乘法减小。拥塞窗口在线性增长的过程中，在增大到24时如果发生了网络拥塞，此时慢启动的阈值将变为当前拥塞窗口的一半，也就是12，并且拥塞窗口的值被重新设置为1，所以下一次拥塞窗口由指数增长变为线性增长时拥塞窗口的值应该是12
主机在进行网络通信时，实际就是在不断进行指数增长、加法增大和乘法减小
需要注意的是，不是所有的主机都是同时在进行指数增长、加法增大和乘法减小的。每台主机认为拥塞窗口的大小不一定是一样的，即便是同区域的两台主机在同一时刻认为拥塞窗口的大小也不一定是完全相同的。因此在同一时刻，可能一部分主机正在进行正常通信，而另一部分主机可能已经发生网络拥塞了
15.TCP的延迟应答
接收数据的主机如果每次都立刻回复确认应答的话，可能会返回一个较小的窗口。那是因为刚接收完数据，缓冲区已满
当某个接收端收到这个小窗口的通知以后，会以它为上限发送数据，从而又降低了网络的利用率（这其实是窗口控制特有的问题，专门术语叫做糊涂窗口综合征）。为此，引入了一个方法，那就是收到数据以后并不立即返回确认应答，而是延迟一段时间的机制
- 假设对方接收端缓冲区剩余空间大小为1M，对方一次收到500K的数据后，如果立即进行ACK应答，此时返回的窗口就是500K
- 但实际接收端处理数据的速度很快，10ms之内就将接收缓冲区中500K的数据消费掉了
- 在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来
- 如果接收端稍微等一会再进行ACK应答，比如等待200ms再应答，那么这时返回的窗口大小就是1M
需要注意的是，延迟应答的目的不是为了保证可靠性，而是留出一点时间让接收缓冲区中的数据尽可能被上层应用层消费掉，此时在进行ACK响应的时候报告的窗口大小就可以更大，从而增大网络吞吐量，进而提高数据的传输效率
此外，不是所有的数据包都可以延迟应答
- 数量限制：每个N个包就应答一次
- 时间限制：超过最大延迟时间就应答一次（这个时间不会导致误超时重传）
延迟应答具体的数量和超时时间，依操作系统不同也有差异，一般N取2，超时时间取200ms
16.TCP的捎带应答
捎带应答，其实是TCP通信时最常规的一种方式，就好比主机A给主机B发送了一条消息，当主机B收到这条消息后需要对其进行ACK应答，但如果主机B此时正好也要给主机A发送消息，此时这个ACK就可以搭顺风车，而不用单独发送一个ACK应答，此时主机B发送的这个报文既发送了数据，又完成了对收到数据的响应，这就叫做捎带应答
- 捎带应答最直观的角度实际也是发送数据的效率，此时双方通信时就可以不用再发送单纯的确认报文了
- 此外，由于捎带应答的报文携带了有效数据，因此对方收到该报文后会对其进行响应，当收到这个响应报文时不仅能够确保发送的数据被对方可靠的收到了，同时也能确保捎带的ACK应答也被对方可靠的收到了
17.TCP中的粘包问题
什么是粘包：
- 首先要明确，粘包问题中的“包”，是指的应用层的数据包
- 在TCP的协议头中，没有如同UDP一样的“报文长度”这样的字段
- 站在传输层的角度，TCP是一个一个报文过来的，按照序号排好序放在缓冲区中
- 但站在应用层的角度，看到的只是一串连续的字节数据
- 那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包
如何解决粘包问题：
要解决粘包问题，本质就是要明确报文和报文之间的边界
- 对于定长的包，保证每次都按固定大小读取即可
- 对于变长的包，可以在报头的位置，约定一个包总长度的字段，从而就知道了包的结束位置。比如HTTP报头当中就包含Content-Length属性，表示正文的长度
- 对于变长的包，还可以在包和包之间使用明确的分隔符。因为应用层协议是程序员自己来定的，只要保证分隔符不和正文冲突即可
UDP是否存在粘包问题？
- 对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在，同时，UDP是一个一个把数据交付给应用层的，有很明确的数据边界
- 站在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收，不会出现“半个”的情况
- 因此UDP是不存在粘包问题的，根本原因就是UDP报头当中的16位UDP长度记录的UDP报文的长度，因此UDP在底层的时候就把报文和报文之间的边界明确了，而TCP存在粘包问题就是因为TCP是面向字节流的，TCP报文之间没有明确的边界
18.TCP的异常情况
TCP的异常情况分为三种：进程终止、机器重启、机器掉线(网线断开)
进程终止：
- 当客户端正常访问服务器时，如果客户端进程突然崩溃了，此时建立好的连接会怎么样？
- 当一个进程退出时，该进程曾经打开的文件描述符都会自动关闭，因此当客户端进程退出时，相当于自动调用了close函数关闭了对应的文件描述符，此时双方操作系统在底层会正常完成四次挥手，然后释放对应的连接资源。也就是说，进程终止时会释放文件描述符，TCP底层仍然可以发送FIN，和进程正常退出没有区别
机器重启：
- 当客户端正常访问服务器时，如果将客户端主机重启，此时建立好的连接会怎么样？
- 当我们选择重启主机时，操作系统会先杀掉所有进程然后再进行关机重启，因此机器重启和进程终止的情况是一样的，此时双方操作系统也会正常完成四次挥手，然后释放对应的连接资源
机器掉线：
当客户端正常访问服务器时，如果将客户端突然掉线了，此时建立好的连接会怎么样？
当客户端掉线后，服务器端在短时间内无法知道客户端掉线了，因此在服务器端会维持与客户端建立的连接，但这个连接也不会一直维持，因为TCP是有保活策略的，如下：
- 服务器会定期客户端客户端的存在状况，检查对方是否在线，如果连续多次都没有收到ACK应答，此时服务器就会关闭这条连接
- 此外，客户端也可能会定期向服务器“报平安”，如果服务器长时间没有收到客户端的消息，此时服务器也会将对应的连接关闭
其中服务器定期询问客户端的存在状态的做法，叫做基于保活定时器的一种心跳机制，是由TCP实现的。此外，应用层的某些协议，也有一些类似的检测机制，例如基于长连接的HTTP，也会定期检测对方的存在状态
19.TCP的保活机制
20.对于TCP协议机制的总结
TCP协议这么复杂就是因为TCP既要保证可靠性，同时又尽可能的提高性能
在可靠性上的机制：
检验和序列号确认应答超时重传连接管理流量控制拥塞控制
在提高性能上的机制：
滑动窗口快速重传延迟应答捎带应答
在定时器上的机制：
重传定时器：为了控制丢失的报文段或丢弃的报文段，也就是对报文段确认的等待时间坚持定时器：专门为对方零窗口通知而设立的，也就是向对方发送窗口探测的时间间隔保活定时器：为了检查空闲连接的存在状态，也就是向对方发送探查报文的时间间隔TIME_WAIT定时器：双方在四次挥手后，主动断开连接的一方需要等待的时长
需要注意的是，TCP的这些机制有些能够通过TCP报头体现出来的，但还有一些是通过代码逻辑体现出来的
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
