一篇博客带你认识TCP的十个机制

TCP是一个面向连接的传输层协议。

为了保证数据传输的可靠传输，它使用了三个机制

1. 确认应答，当主机A给主机B传输数据的时候，主机A给主机B一个数据序号，而主机B接受到数据之后会给主机A一个确认序号。来让主机A知道主机B已经接受到了数据。

2. **超时重传，**当主机A在一定时间内没有接受到主机B的确认序号，主机A就会给主机B从新发送这个数据。有两种可能，一种是主机A给主机B发送的数据丢了，一种是主机B返回的确认序号丢了。这两种情况都会导致超时重传，第二种情况的下主机B发现自己已经接受了这个数据，那木就会丢弃这个数据并且从新发送一个确认序号

3. 连接管理 连接管理的话 就是三次握手建立连接和四次挥手断开连接，这个是非常重要的。

   主机A给主机B发送一个SYN请求数据包，主机B给主机A返回一个响应ACK和SYN数据包，主机A再给主机B一个一个响应ACK。（相当于一个楼上的人给楼下的人说话，楼下给楼上喊你听的到吗，楼上回应 我听得到，你听得到嘛，然后楼下说我听得到，然后双发开始说话）
   
   当主机A发现自己的所要发送的数据已经发送玩了，最后发送一个FIN断开连接的请求，主机B接受到之后，先返回一个ACK请求，说我收到这个请求了，然后开始处理自己剩下没有处理完的数据，处理完之后然后给主机A返回一个FIN请求，主机A收到主机B的请求之后返回给主机B一个ACK请求。
   

但是可靠性又会牺牲一定的效率，为了增加效率，我们又引入了滑动窗口机制。

4.滑动窗口机制 滑动窗口的本质就是批量传输数据，我们在不等待ACK的情况下然后批量发出最大数据，ACK的回应就是最后一个数据的序号+1。
但是引入滑动窗口的机制之后ACK丢了的情况，有些ACK丢了之后并不会引起重传，比如2001丢了但是收到了4001的ACK，那木发送方就知道了接受方收到了4000之前的数据，自然就不会重传。

数据包丢了的情况，比如1001到2000的数据包丢了，但是并不会立即重传，而是发送方为了保证效率会继续发后面的数据，但是接受方发现一直没有1001到2000的数据，就会一直给发送方发送1001的确认序号，但是其他的数据接收方已经按顺序放好，当发送方发现接收方一直给自己发送要1001的数据之后就会重传。

引入滑动窗口的机制后，我们需要将滑动窗口控制到一定的大小，不能使其过大。我们引入了拥塞控制和流量控制。流量控制和拥塞控制同时决定窗口的大小

5.流量控制，就是接受方为了限制发送方的发送效率，就是限制发送方的传输效率的大小，不能让窗口过大，窗口过大的话，接收方接受来不及处理。（可以把接受方当作一个中转站，我们得根据中转站的处理货物的快慢然后来决定往中转站发送货物的多少以及快慢）

6.拥塞控制，拥塞控制就是根据传输路径的拥堵情况来决定窗口的大小。（相当于我们货车往中转站运送货物的时候的公路，货车一旦过去太多的话会发生堵车）

我们又为了进一步提高效率，就使用了延时应答和捎带应答
7.延时应答，在流量控制的基础上尽力返回一个合理但是又比较大的窗口。(我们往中转站发货了，到了中转站问还有多少地方可以放货，准备下一次发货，然后中转站告诉你我有多少地方，这就不是延时应答，若是中转站告诉你，你先回去，我晚上告诉你，然后这点时间中转站就多处理了一些货物，多了一些地方。这就是延时应答)
8.捎带应答,在延时应答的基础上。内核一般收到数据是立即返回一个ACK的，但是我们可以把ACK和回应的数据一起反应给接受方。这个ACK的延时一般为200ms，当回应的数据发现ACK还没发出去的话，就会带上ACK一起回应。四次挥手可以合成三次挥手。
9.粘包问题,因为TCP是面向字节流的，就是发送数据或者接受数据的时候，只会发送或者接受一部分（比如发送一个数据”不好，不好“，但是一部部分数据丢了，导致读到了”不“和”好不好“）。解决的办法就是在数据上使用分隔符或者明确包的长度。
10.保活机制就是TCP连接突然出现异常之后，然后为了TCP就会进行一些处理。
进程崩溃: TCP进行正常的四次挥手。
主机关机:关机的时候会强制先杀进程，杀进程过程中的进行四次挥手。
主机断电：接受方断电的话，发送方发送一定的消息之后，发现没有ACK,就会重传，重传一定次数之后就会放弃连接。发送方断电：两方在没有数据传输的情况下一般有每隔一段时间就会有一个心跳包发个接收方，一旦长时间没有心跳包给接受方，接受方就认为发送方挂了，结束连接。