【第七天】TCP三次握手四次挥手 HTTP的keep-Alive和TCP的keepalive

TCP三次握手四次挥手

既然要了解这些，首先我们要清楚一个概念，半连接队列和全连接队列：
在TCP三次握手中，Linux内核会维护两个队列来管理连接请求。
这两个队列的存在是为了处理并发连接请求，确保服务端能够有效管理新的请求。
半连接队列（SYN Queue）：
当服务端收到客户端的SYN请求时，此时双方都还没有完全建立连接，它会把半连接状态的连接放在半连接队列。
全连接队列（Accept Queue）：
当服务端收到客户端的ACK响应时，意味着三次握手成功完成，服务端会将该连接从半连接队列移动到全连接队列。如果没有收到客户端的ACK响应，会进行重传，重传的时间是指数级增长的。如果重传次数超过系统规定的最大次数，则会将这个连接从半连接队列里删除。

然后是SYN:
SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。

建立连接三次握手：

TCP三次握手的过程：

1. 客户端向服务端发送带有SYN（SEQ=x)标志的数据包，然后客户端进入SYN_SEND状态，等待服务器确认。
   在此过程中，客户端确认不了什么，服务端能够确认：自己接收正常，对方发送正常。

2. 服务端发送带有SYN+ACK（SEQ=y,ACK=x+1)标志的数据包到客户端，然后服务端进入SYN_RECV状态。
   在此过程中，客户端确认：自己发送接收正常，对方发送接收正常。服务端确认：自己接收正常，对方发送正常。

3. 客户端发送带有ACK（y+1）标志的数据包到服务端，然后客户端和服务端都进入ESTABLISHED状态，完成三次握手。
   在此过程中，客户端确认：自己发送接收正常，对方发送接收正常。服务端确认：自己发送接收正常，对方发送接收正常。

为什么要三次？

三次握手的目的就是建立可靠的连接，归根结底就是双方确认自己与对方发送接收数据是否正常。
第一次握手：客户端确认不了什么；服务端确认了自己接收正常，对方发送正常。因为服务端收到了客户端的信息。
第二次握手：客户端确认了自己发送接收正常，对方发送接收正常；服务端还是只确认了自己接收正常，对方发送正常。客户端是接收到了服务端的反馈信息，也就能确认双方的接收发送状态，而服务端还没有收到来自客户端的信息，所以也就只能确认自己能接收，对方能发送。
第三次握手：客户端确认自己发送接收正常，对方发送接收正常；服务端确认自己发送接收正常，对方发送接收正常。因为服务端接到了来自客户端的反馈信息，说明了自己发送的信息到了客户端，客户端也接收处理了。

不能是两次或者四次吗？

三次握手才能确保双方具备接收和发送的能力。两次握手可能会导致资源浪费。没有第三次握手，那么服务端就无法确认客户端是否接收到了自己的回复，所以服务端每收到一个SYN，就要去主动向客户端建立一个连接。假设一次握手用1个单位资源，那么一次三次握手的连接要用3单位资源。如果使用两次握手的连接的话，服务端和客户端要建立可靠连接，就得都向对方进行两次握手连接，要消耗4单位资源。这样就导致了资源的浪费。而四次握手的话可以被优化成3次握手，因为3次握手就已经确保了双方具备接收和发送能力了。

断开连接四次挥手

挥手过程：

1. 第一次挥手：客户端发送一个FIN（SEQ=x)标志的数据包到服务端，用来关闭客户端到服务端的数据传送。然后客户端进入FIN-WAIT-1状态。
2. 第二次挥手：服务端收到FIN（SEQ=x）后，发送一个ACK（ACK=x+1）标志的数据包到客户端。然后服务端进入CLOSE-WAIT状态，客户端进入FIN-WAIT-2状态。
3. 第三次挥手：服务端发送一个FIN（SEQ=y+1)标识的数据包到客户端，请求关闭连接，然后服务端进入LAST-ACK状态。
4. 第四次挥手：客户端发送ACK（ACK=y+1）标志的数据包到服务端，然后客户端进入TIME_WAIT状态，服务端在收到ACK（ACK=y+1）后，进入CLOSE状态。如果此时客户端等待2MSL后仍没有收到回复，则证明服务端已经正常关闭，随后客户端也关闭连接。
   只要四次挥手没有结束，客户端和服务端就可以继续传输数据

为什么要四次挥手？

TCP是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连续释放通知，对方确认后就完全关闭了TCP连接。
就如A和B打电话
第一次挥手：A：我说完了。（A放下电话，等B回复）
第二次挥手：B：我知道了。我还有话要说。你先别挂。（A放下电话，等B说）
第三次挥手：B：叽里呱啦。我也说完了。（B放下电话，等A回复）
第四次挥手：A：我知道了。（A回复了，B听到后就关电话，A等一小会儿，没听到B的声音，A也关掉电话）。

为什么不把服务端发送的ACK和FIN结合起来，变成三次挥手？

因为服务端也要发送数据，可能服务端收到客户端断开请求的时候，服务端的数据还没发送完。要是合并起来了，那就会导致服务端传数据传一半就断开了。

HTTP的Keep-Alive和TCP的Keepalive

HTTP多个TCP连接怎么实现？
多个TCP连接是靠服务器对Connect: keep-alive的Header进行了支持。简而言之，就是完成了这个HTTP请求之后，不断开HTTP请求使用的TCP连接。
这样做的好处是连接可以被重新使用，之后发送HTTP请求的时候不需要重新建立TCP了解，以及如果维持连接，那么SSL的开销也可以避免。

HTTP的Keep-Alive是由应用层(用户态）实现的，称为HTTP长连接。
HTTP请求的建立过程是：建立TCP连接->请求资源->响应资源->释放连接。
每次这样建立连接都只能请求一次资源。而HTTP的Keep-Alive实现了使用同一个TCP连接来发送和接收多个HTTP请求/应答，避免了建立连接和释放连接的开销。

TCP的Keepalive是由TCP层（内核态）实现的，称为TCP保活机制。
就是给一个TCP设置一个定时任务用于倒计时，超时后触发任务，即发送一个探测报文给对端，用来判断对端是否存活