六、流量控制
TCP支持根据接收端的接收数据的能力来决定发送端发送数据的速度
接收端处理数据的速度是有限的，若发送端发的太快，导致接收端的缓冲区被打满，此时发送端继续发送数据，就会造成丢包，进而引起重传、资源浪费等一系列连锁反应
因此接收端可以将自己接收数据的能力告知发送端，让发送端控制发送数据的速度
接收端将接收缓冲区空余大小放入TCP报头的"16位窗口大小"字段，通过ACK通知发送端
窗口大小字段越大，说明网络的吞吐量越高
接收端一旦发现接收缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端
发送端接收到这个窗口之后，就会调整发送速度
当发送端得知接收端接收数据的能力为0时会停止发送数据，此时发送端会通过以下两种方式来得知何时可以继续发送数据
等待告知。接收端上层将接收缓冲区当中的数据读走后，接收端向发送端发送一个TCP报文，主动将窗口大小告知发送端，发送端得知接收端的接收缓冲区有空间后就可以继续发送数据了
主动询问。发送端每隔一段时间向接收端发送报文，该报文不携带有效数据，只是为了询问发送端的窗口大小，直到接收端的接收缓冲区有空间后发送端就可以继续发送数据了
16为数字最大表示65535，那TCP窗口最大就是65535吗？
理论上是这样的，但实际上TCP报头中40字节的选项字段中包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位得到的
第一次向对方发送数据时如何得知对方的窗口大小？
双方在进行TCP通信之前需先进行三次握手建立连接，而双方在握手时除了验证双方信道是否通畅以外，还进行其他信息的交互，其中就包括告知对方自己的接收能力，因此在双方还没有正式开始通信之前就已经知道了对方接收数据能力，所以双方在发送数据时是不会出现缓冲区溢出的
七、滑动窗口
连续发送多个数据
每次仅发送一个数据段（多次IO）效率太低，双方在进行TCP通信时可以一次向对方发送多条数据，等待多个响应的时间重叠，提高通信效率
注意：虽然双方在进行TCP通信时可以一次向对方发送大量的报文，但不能将发送缓冲区中的数据全部一次发送给对端，在发送数据时还需考虑对方的接收能力
滑动窗口
发送方可以一次发送多个报文给对方，此时也就意味着发送出去的这部分报文中有相当一部分数据是暂时没有收到应答的
发送缓冲区中的数据分为三部分：
已经发送并且已经收到ACK的数据
已经发送还但没有收到ACK的数据
还没有发送的数据
滑动窗口描述的是：发送方不用等待ACK一次所能发送的数据最大量
滑动窗口存在的最大意义就是可以提高发送数据的效率：
滑动窗口的大小等于对方窗口大小与自身拥塞窗口大小的较小值，因为发送数据时不仅要考虑对方的接收能力，还要考虑当前网络的状况
先不考虑拥塞窗口，并且假设对方的窗口大小一直固定为4000，此时发送方不用等待ACK一次所能发送的数据就是4000字节，即滑动窗口的大小为4000字节
现在连续发送1001-2000、2001-3000、3001-4000、4001-5000这四个段，不需等待任何ACK，可以直接进行发送
当收到对方响应的确认序号为2001时，说明1001-2000这个数据段已经被对方收到了，此时该数据段应被纳入发送缓冲区中的"第一部分"
滑动窗口越大，则网络的吞吐率越高，同时也说明对方的接收能力很强
当发送方发送出去的数据段陆续收到对应的ACK时，滑动窗口左边界向右移动，此时收到ACK的数据段就被归置到滑动窗口左侧。再根据当前滑动窗口的大小决定，滑动窗口右边界是否向右移动
TCP的重传机制要求暂时保存发出但未收到确认的数据，而这部分数据实际就位于滑动窗口中，只有滑动窗口左侧的数据才是可以被覆盖或删除的，因为这部分数据才是发送并被对方可靠的收到了，所以滑动窗口除了支持大量发送以外，也支持TCP的重传机制
滑动窗口一定会整体右移吗？
滑动窗口不一定会整体右移的，假设对方已经收到了1001-2000的数据段并进行了响应，但对方上层一直不从接收缓冲区中读取数据，此时对方的16位窗口大小就由4000变为了3000
当发送端收到对方的响应序号为2001时，1001-2000的数据段依然保存，但此时由于对方的接收能力变为了3000，滑动窗口的大小也变为3000，右侧不能继续向右进行扩展
如何实现滑动窗口
TCP接收和发送缓冲区都被看作一个字符数组，而滑动窗口可以看作是两个指针（下标）限定的一个范围，比如用start指向滑动窗口的左侧，end指向的是滑动窗口的右侧，此时在start和end区间范围内的就可以被称为滑动窗口
当发送端收到对方的响应时，若响应中的确认序号为x，16位窗口大小为win，此时就可以将start更新为x，而将end更新为start + win
滑动窗口中的数据一定都没有被对方收到吗？
滑动窗口中的数据是可以暂时不用收到对方确认的数据，而不是说滑动窗口中的数据一定都没有被对方收到，滑动窗口中可能有一部分数据已经被对方收到了，但可能因为滑动窗口中一部分数据，在传输过程中出现了丢包等情况，导致后面已经被对方收到的数据得不到响应
如图中的1001-2000的数据包若在传输过程中丢包了，此时虽然2001-5000的数据都被对方收到了，此时对方发来的确认序号是1001，当发送端补发了1001-2000的数据包后，对方发来的确认序号就会变为5001，此时发送缓冲区向右移动
丢包问题
情况一： 数据包已经抵达，ACK响应丢包
在发送端连续发送多个报文数据时，部分ACK丢包并不要紧，此时可以通过后续的ACK进行确认
如图中2001-3000和4001-5000的数据包对应的ACK丢失了，但发送端收到了最后5001-6000数据包的响应，此时发送端就知道2001-3000和4001-5000的数据包实际上被接收端收到了的，因为确认序号为6001的含义就是序号为6000以前的字节数据都收到了，下一次从序号为6001的字节数据开始发送
情况二： 数据包丢包
当1001-2000的数据包丢失后，发送端会一直收到确认序号为1001的响应报文，提醒发送端下一次应从序号为1001的字节数据开始发送
若发送端连续收到三次确认序号为1001的响应报文，此时就会将1001-2000的数据包重新进行发送（快重传）
此时当接收端收到1001-2000的数据包后，就会直接发送确认序号为6001的响应报文，因为2001-6000的数据接收端在之前就已经收到了
快重传需要在大量的数据重传和个别的数据重传之间做平衡，上述例子中发送端并不知道是否仅有1001-2000这个数据包丢了，当发送端重复收到确认序号为1001的响应报文时，理论上发送端应该将1001-7000的数据全部进行重传，但这样可能会导致大量数据被重复传送，所以发送端可以尝试先把1001-2000的数据包进行重发，然后根据重发后的得到的确认序号继续决定是否需要重发其它数据包
快重传 VS 超时重传
快重传能够快速进行数据的重发，当发送端连续收到三次相同的应答时就会触发快重传，不需像超时重传一样需要通过设置重传定时器，在固定的时间后才会进行重传
虽然快重传能够快速判定数据包丢失，但快重传并不能完全取待超时重传，因为有时数据包丢失后可能并没有收到对方三次重复的应答，此时快重传机制就触发不了，而只能进行超时重传
快重传虽然是一个效率上的提升，但超时重传却是所有重传机制的保底策略
八、拥塞控制
为什么会有拥塞控制？
两个主机在进行TCP通信的过程中，出现个别数据包丢包的情况是很正常的，此时可以通过快重传或超时重发对数据包进行补发。但若双方在通信时出现了大量丢包，此时就不能认为是正常现象了
TCP不仅考虑了通信双端主机的问题，同时也考虑了网络的问题。双方网络通信时出现少量的丢包TCP是允许的，但一旦出现大量的丢包，此时TCP就不再认为是双方接收和发送数据的问题，而是判断双方通信信道网络出现了拥塞问题，从而需要进行拥塞控制
如何应对网络拥塞问题？
网络出现大面积瘫痪时，通信双方作为网络中两台小小的主机，看似并没有什么作用，但大部分主机都会使用TCP协议，网络出现问题一定是网络中大部分主机共同作用的结果
若网络中的主机在同一时间节点向网络中塞入大量数据，此时位于网络中某些关键节点下就可能阻塞许多报文，最终导致报文无法在超时时间内到达对端主机，导致了丢包问题
当网络出现拥塞问题时，通信双方虽然不能提出特别有效的解决方案，但双方主机可以做到不加重网络的负担
双方通信时若出现大量丢包，不应立即将这些报文重传，而应该少发数据甚至不发数据，待网络状况恢复后双方再恢复数据的传输速率
网络拥塞影响的不只是一台主机，而几乎是该网络中的所有主机，发生网络拥塞时所有使用TCP传输控制协议的主机都会执行拥塞避免算法
拥塞控制
虽然滑动窗口能够高效可靠的发送大量的数据，但在不清楚当前网络状态的情况下，贸然发送大量的数据，可能会引起或加重网络拥塞问题。因此TCP引入了慢启动机制，在刚开始通信时先发少量的数据探路，摸清当前网络状况，再决定按照多大的速度传输数据
TCP除了有16位窗口大小和滑动窗口的概念以外，还有拥塞窗口。拥塞窗口是可能引起网络拥塞的阈值，若一次发送的数据超过了拥塞窗口的大小就可能会引起网络拥塞
刚开始发送数据时拥塞窗口大小定义以为1，每收到一个ACK应答拥塞窗口的值就加一
每次发送数据包的时候，将拥塞窗口和接收端主机反馈的16位窗口大小比较，取较小值作为实际发送数据的窗口大小，即滑动窗口的大小
每收到一个ACK应答拥塞窗口的值就加一，经过每个传输轮次，拥塞窗口以指数级别进行增长，拥塞窗口的大小变化情况如下：
"慢启动"只是初始时比较慢，越往后增长越快。若拥塞窗口一直以指数的方式进行增长，就可能在短时间内再次导致网络出现拥塞
为了避免短时间内再次导致网络拥塞，不能一直让拥塞窗口按指数级的方式进行增长
此时就引入了慢启动的阈值，当拥塞窗口的大小超过这个阈值时，就不再按指数的方式增长，而按线性的方式增长
当TCP刚开始启动的时候，慢启动阈值设置为对方窗口大小的最大值
在每次超时重发时，慢启动阈值会变成当前拥塞窗口的一半，同时拥塞窗口的值被重新置为1，如此循环下去
指数增长。拥塞窗口的初始值为1，并不断按指数的方式进行增长
加法增大。慢启动的阈值初始时为对方窗口大小的最大值，图中慢启动阈值的初始值为16，因此当拥塞窗口的值增大到16时就不再按指数形式增长了，而变成了的线性增长
乘法减小。拥塞窗口在线性增长的过程中，在增大到24时发生了网络拥塞，此时慢启动的阈值将变为当前拥塞窗口的一半，即12。并且拥塞窗口的值被重新设置为1，下一次拥塞窗口由指数增长变为线性增长时拥塞窗口的值是12
九、延迟应答
若接收数据的主机收到数据后立即进行ACK应答，此时返回的窗口可能较小
假设对方接收端缓冲区剩余空间大小为1MB，对方一次收到500KB的数据后，若立即进行ACK应答，此时返回的窗口大小为500KB
但接收端处理数据的速度很快，10ms内就将接收缓冲区中500K的数据消费掉了，接收端处理还远没有达到极限
若接收端稍等一会再进行ACK应答，如等待20ms再应答，那么这时返回的窗口大小就是1MB
注意：延迟应答的目的不是为了保证可靠性，而是留出时间让接收缓冲区中的数据尽可能被上层应用层消费掉，此时在进行ACK响应时窗口大小就更大，从而增大网络吞吐量，减少IO次数，进而提高数据的传输效率
延迟应答机制也有一定限制
数量限制：每个N个包应答一次
时间限制：超过最大延迟时间应答一次（这个时间不会导致误超时重传）
延迟应答具体的数量和超时时间，依操作系统不同也有差异，一般N取2，超时时间取200ms
十、捎带应答
捎带应答是TCP通信最常规的机制。当主机A给主机B发送了一条消息，当主机B收到这条消息后需进行ACK应答，但若主机B正好也要给主机A发送消息，此时就不用单独发送一个ACK应答。此时主机B发送的这个报文就可以既包含数据，又包含对收到数据的响应，即捎带应答
捎带应答机制可提高发送数据的效率，此时双方通信时就不用发送单纯的确认报文了，减少网络IO次数
十一、面向字节流
当创建一个TCP的socket时，同时在内核中会创建一个发送缓冲区和一个接收缓冲区。
调用write函数可以将数据写入发送缓冲区中，此时write函数就可以进行返回了，接下来发送缓冲区中的数据由TCP自行进行发送
若发送的字节数太长，TCP会将其拆分成多个数据包发出。若发送的字节数太短，TCP会先将其留在发送缓冲区中，合适时机再进行发送
接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区，可以通过调用read函数来读取接收缓冲区中的数据
由于缓冲区的存在，TCP程序的读和写不需要一一匹配，例如：
写100个字节数据时，可以调用一次write写100字节，也可以调用100次write写1个字节
读100个字节数据时，也不需要考虑是怎么写的，既可以一次read100个字节，也可以一次read一个字节，重复100次
对于TCP而言，并不关心发送缓冲区中的是什么数据，在TCP看来只是一个个的字节数据，其任务就是将这些数据准确无误的发送到对方的接收缓冲区中就行了，而至于如何解释这些数据完全由上层应用来决定，这就被称为面向字节流
十二、粘包问题
什么是粘包？
粘包问题中的"包"，指的是应用层的数据包
在TCP的协议头中，没有如同UDP一样的“报文长度”这样的字段（仅有4位首部长度）
站在传输层的角度，TCP是一个一个报文过来的，按照序号排好序放在缓冲区中
但站在应用层的角度，看到的只是一串连续的字节数据
那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包
如何解决粘包问题
要解决粘包问题，本质就是要明确报文和报文之间的边界。
对于定长的包，保证每次都按固定大小读取即可
对于变长的包，可以在报头的位置约定一个总长度的字段，从而就知道包的结束位置。如HTTP报头中就包含Content-Length属性，表示正文的长度
对于变长的包，还可以在包和包之间使用明确的分隔符。应用层协议是程序员自己来定的，只要保证分隔符不和正文冲突即可
UDP是否存在粘包问题？
对于UDP，若还没有上层交付数据，UDP的报文长度字段依然存在。同时，UDP是一个一个把数据交付给应用层的，有很明确的数据边界
站在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收，不会出现"半个"的情况
因此UDP是不存在粘包问题的，根本原因是UDP报头中的16位UDP长度记录了UDP报文的长度，因此UDP在底层的时候就把报文和报文之间的边界明确了，而TCP存在粘包问题就是因为TCP是面向字节流的，TCP报文之间没有明确的边界
十三、TCP异常情况
进程终止
当客户端正常访问服务器时，若客户端进程突然崩溃了，此时建立好的连接会怎么样？
当一个进程退出时，该进程曾经打开的文件描述符都会自动关闭，因此当客户端进程退出时，相当于自动调用了close函数关闭了对应的文件描述符，此时双方操作系统在底层会正常完成四次挥手，然后释放对应的连接资源。即进程终止时会释放文件描述符，TCP底层仍然可以发送FIN，和进程正常退出没有区别
机器重启
当客户端正常访问服务器时，若将客户端主机重启，此时建立好的连接会怎么样？
当选择重启主机时，操作系统会先杀掉所有进程然后再进行关机重启，因此机器重启和进程终止的情况是一样的，此时双方操作系统也会正常完成四次挥手，然后释放对应的连接资源
机器掉电/网线断开
当客户端正常访问服务器时，若客户端突然掉线了，此时建立好的连接会怎么样？
当客户端掉线后，服务器端在短时间内无法知道客户端掉线了，因此在服务器端会维持与客户端建立的连接，但这个连接也不会一直维持，因为TCP是有保活策略的
服务器会定期询问客户端的存在状况，检查对方是否在线，若连续多次没有收到ACK应答，此时服务器就会关闭这条连接
客户端也可能会定期向服务器"报平安"，若服务器长时间没有收到客户端的消息，此时服务器也会将对应的连接关闭
其中服务器定期询问客户端的存在状态的做法，叫做基于保活定时器的一种心跳机制，由TCP实现。应用层的某些协议，也有一些类似的检测机制，例如基于长连接的HTTP，也会定期检测对方的存在状态
十四、TCP小结
TCP协议复杂的原因是因为TCP既要保证可靠性，同时又尽可能的提高性能。
可靠性：
检验和
序列号
确认应答
超时重传
连接管理
流量控制
拥塞控制
提高性能：
滑动窗口
快速重传
延迟应答
捎带应答
注意：TCP的这些机制有些能够通过TCP报头体现，但有一些是通过底层代码逻辑体现出来的
TCP定时器
重传定时器：为了控制丢失的报文段或丢弃的报文段，即对报文段确认的等待时间
坚持定时器：专门为对方零窗口通知而设立的，即向对方发送窗口探测的时间间隔
保活定时器：为了检查空闲连接的存在状态，即向对方发送探查报文的时间间隔
TIME_WAIT定时器：双方在四次挥手后，主动断开连接的一方需要等待的时长
理解传输控制协议
TCP的各种机制实际都没有谈及数据真正的发送，这些都是传输数据的策略。TCP协议是在网络数据传输中做决策的，提供的仅是理论支持，而数据真正的发送实际是由底层的IP和MAC帧完成的
TCP做决策和IP+MAC做执行，将这些统称为通信细节，最终的目的就是为了将数据传输到对端主机。而传输数据的目的是什么则是由应用层决定的。因此应用层决定的是通信的意义，而传输层及其往下的各层决定的是通信的方式
基于TCP的应用层协议
常见的基于TCP的应用层协议如下：
HTTP（超文本传输协议）
HTTPS（安全数据传输协议）
SSH（安全外壳协议）
Telnet（远程终端协议）
FTP（文件传输协议）
SMTP（电子邮件传输协议）
使用TCP套接字自定义的应用层协议
