TCP的10个机制

确认应答机制

确认应答机制是保证TCP可靠性的核心机制；

确认序号在TCP中表示接下来想要的下一条数据编号，而不是当前收到的数据编号；

发送方收到应答数据的时候，应答报文中的确认序号为1001，此时发送方就知道1-1000的数据已经顺利抵达，接下来要发送的数据是从1001开始；

应答报文中ACK这一位为1，说明当前确认序号是有效的。

超时重传

可靠性就是为了应对丢包，针对丢包情况进行重传数据。应答报文发送失败，发送方会继续发送报文，直到接收方发送应答报文被发送方收到。（这个过程中在一定时间内没有收到应答报文时才会重传）。

重传时的发送报文会和之前的重复，
but
TCP自身已经处理好了这种数据重复的情况，TCP有一个“接收缓冲区”（一块内存），TCP就会根据序号检查缓冲区中有没有重复的数据，并去重。

丢包有一定的概率，超时重传等待的时间间隔不是固定的，而是逐渐变大的。假设丢包率的概率是固定值，此时连续丢包的概率比较小。若出现连续丢包，大概率是网络出现了彻底的问题，所以TCP重传的时间间隔就会越来越高，频率会越来越低。（！重传到一定的次数，就会尝试断开连接）

TCP的可靠性依赖于“超时重传+应答机制”。

连接管理

TCP建立连接（三次握手）

三次握手的本质：确认通信双方的发送能力和接受能力都正常。（可靠性的基础）

• 第一次握手：接收方知道发送方的发送能力正常；
  主机A——>主机B：SYN
• 第二次握手：发送方知道自己和接收方的发送能力正常；
  主机B——>主机A：SYN+ACK
• 第三次握手：接收方知道自己的发送能力和发送方的街火速能力
  主机A——>主机B：ACK

（SYN为1，就是同步报文段）

TCP断开连接（四次挥手）

• 建立了连接，就需要在操作系统内核中来维护这些连接，用一些数据结构或者对象来保存连接相关的信息，并为后面的通信进行服务；

• 双方各自向对方发送FIN，并向对方回应ACK

• 断开连接时，主机B给主机A回复的ACK和FIN
  1.可能合并在一起：如果close（）能够被很快的调用到（FIN和ACK的时间间隔不是很长的时候就会触发TCP的“延时应发+捎带应答”机制）
  2.也可能不合并：发送ACK和FIN的时机不一样。发送ACK是操作系统内核行为，在收到FIN的第一时间就回复ACK；发送FIN是应用程序的行为，在代码中执行到对应的“close（）”才会触发FIN。

• 在三次握手和四次挥手之间也会涉及到确认应答和超时重传

• TCP协议的一些核心状态
  1.ESTABLISHED连接成功，可以进行后续通信了；
  2.LISTEN服务器端进入的状态，表示服务器准备就绪，允许客户端随时来建立连接；
  3.CLOSED_WAIT断开连接时的中间状态，这个状态正常情况下存在时间较短。出现在收到FIN，返回ACK到发送FIN这个时间间隙中。一般看到这个状态是，可能是代码出bug了，导致没有及时调用到close方法
  4.TIME_WAIT也是断开连接时的状态。谁主动断开连接，谁进入该状态。（建立连接只能客户端发起连接请求；断开连接时，客户端和服务器端都可以做）。该状态存在的意义是为了防止最后一个ACK丢包做准备的，当进行最后一个ACK发送完成之后，并不会立刻销毁连接，而是以这种状态等待一段时间。一定时间之后，发现对方没有重传FIN，就视为ACK没丢包，然后真正的释放连接。（等待时间为2MSL，MSL表示网络中两个主机之间传输数据的最大间隔）

滑动窗口

• 保证可靠性也要提高传输效率。确认应答如果等到ACK到达之后再发送数据，效率比较低，可以让发送方批量的发送一组数据，同一等待ACK，这组数据的数据量称为窗口大小。

• 窗口范围内的数据就是已经发出去的数据，同时也是要等待ACK的数据，随着对方ACK的到达，要等待的数据也就随之变化，同时也会发送新的数据出去。

• 这里的重传机制得益于确认序号的设计，保证了较高的传输效率

• 窗口越大，传输效率越高，内存消耗就更大；窗口越小，传输效率越低，内训消耗更小。

• 影响串口大小的其他因素：接收方的处理速率（即应用程序从队列中取的速度快慢）。此时就需要根据接收方的处理能力限制发送方的窗口大小。

流量控制

• 发送方先有一个初始的窗口大小。发送数据过去之后，对方返回一个ACK，其中包括确认序号和数据（接收方缓冲区的剩余空间大小）。
• 流量控制的目的一是为了让发送方和接收方的速率尽可能步调一致，才能做到可靠地同时尽量高效。
• 接收方根据自己的处理能力，方向控制发送方和发送速率。
• 复杂的网络环境中，不仅要考虑接收方的处理能力还要考虑中间结点的处理能力。

拥塞控制

• 滑动窗口大小是由拥塞控制和流量控制一起决定的
• 由于网络环境比较复杂，发送方采取一个动态变化的过程，来试探出当前的窗口大小多少合适，会在初始情况下设置一个比较小的窗口大小，发数据，如果没丢包，网络是畅通的，就会扩大窗口大小，循环，直到丢包再缩小窗口。
• 滑动窗口的实际大小，就是拥塞窗口和流量控制窗口的较小值。

延迟应答

接收方收到发送方的数据之后，并不是立刻返回ACK，而是等待一会（500ms）再返回ACK,ACK携带的窗口大小可能会更大，这500ms中农应用程序可能从缓冲区中取走了一些数据。

捎带应答

最常见的服务器通信模式——一问一答。
因为延时应答的原理。应用程序返回响应的时候，顺带把上个ACK数据也一起携带过去，减少了传输的数据包个数，减低了通信成本，提高了效率。

面向字节流

• 粘包问题不是TCP独有的问题，只要是面向字节流都会涉及到年报，面向数据报的UDP就没有这个问题
• UDP的接收方以每个数据包为单位组织的数据，每个数据报都相当于链表的节点
• 解决粘包问题：显式的指定包的长度；显式的指定包和包之间的分隔符（结束标记）
• GET请求，通过“结束标记”来区分不同的包的（空行），指定body长度。

TCP对于异常情况的处理

• 进程终止：进程终止会释放文件描述符，仍然可以发送FIN，和正常关闭没有什么区别。

• 机器重启：和进程终止的情况相同。
  系统会先杀死进程，触发四次挥手，注：主机B还没挥手完成，主机A已经关闭，主机B会以LAST_ACK状态尝试重传几次FIN，一直没有ACK之后，也就释放了连接。

• 机器掉电/网线断开：
  接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset，即使没有写入操作，TCP也内置了一个保活定时器，会定期询问对方是否还在，如果对方不在，也会把连接释放。

• 负载均衡，哪些节点是正常工作的，哪些节点是出现问题的，心跳包是判断的依据。负载均衡可以在服务不中断的情况下对服务器进行重启和升级。