三次握手四次挥手

TCP是一种面向连接的协议，在发送数据前，通信双方必须在彼此之间建立一条连接。所谓的“连接”，其实是客户端和服务器的内存里保存的一份关于对方的信息，如ip地址、端口号等。在连接的建立过程中，双方需要交换一些连接的参数，这些参数可以放在TCP的头部。

服务器必有内容：HTTP/1.1 200 ok

deflate:是同事使用了LZ77算法与哈夫曼编码的一个无损数据压缩算法。

general:常规 普通的 综合的  200 ok  ; 404 file is not defind 

response hearders: 响应头部

request headers:请求头部

ACK--确认，使得确认有效

RST--重置连接

SYN--用于初始化一个连接的序列号

FIN--该报文的发送方已经结束向对方发送数据

三次握手能保证客户端，服务端双方都准备好资源来进行相关操作，在通信前进行连接，让双方都能明确自己和对方的收、发能力时正常的。第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论；客户端的发送能力、服务端的接收能力时正常的。第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：客户端的接收、发送能力，客户端的接收、发送能力时正常的。第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力，服务端的发送、接收能力是正常的。经过了三次握手过程，客户端和服务端都确认了自己的接收、发送能力是正常的，之后就可以通信了。 之所以这么做是因为每次都是接收到数据包的一方可以得出一些结论，发送的一方没有任何头绪。虽然有发包动作，但不知道发没发出去，也不知道对方有没有收受到。每次的接受可以得出对方的发送和我的接受是正常的。

四次挥手能保证双方都释放掉资源：一次挥手，客户端发送完数据后向服务端发送一个FIN数据包，申请断开，并且自身进入等待结束连接状态FIN_WAIT-1；二次挥手服务端收到了来自客户端的FIN请求包后，向客户端回复一个确认报文ACK，同时进入关闭等待状态（CLOSE-WAIT），这时TCP连接的server便会向上层应用发送通知，表明客户端数据发送完毕，是否需要发送树蕨给客户端，这时TCP连接已经处于半关闭状态了，因为客户端已经没有数据要发送了。同时客户端收到了来自服务端的确认报文之后，便会进入FIN-WAIT-2状态。三次挥手 TCP连接的服务端收到上层应用的指令表明没有数据要发送之后，会向客户端发送一个FIN请求数据包，其中确认ACK=1，表明响应客户端的关闭连接请求，同时FIN=1表明服务端也准备好断开TCP连接了。四次挥手客户端收到了来自服务端的FIN数据包之后，知道服务端已经准备好断开连接了，于是向服务端发送了一个确认数据包ACK，告诉服务端，可以关闭资源断开连接了。同时自身进入TIME-WAIT阶段，这个阶段将持续2MSL（MSL：报文在网络链路中的最长生命时长），在等待2MSL之后，客户端将会关闭资源。服务端收到了来自与客户端的最后一盒确认断开连接数据包之后便会直接进入TCP关闭状态，进行资源的回收。

三次握手四次挥手的目的

三次握手能保证双方有资源

四次挥手是保证双方吧资源释放掉

为什么是四次挥手而不是三次挥手？

当客户端第一次挥手的时候，服务器有两件事情要做，就是进行回复和通知应用程序recev解阻塞，

接阻塞之后，应用程序有可能会调用close 但是也有可能发送数据包，也有这个close。只要不调用close就不会发生第三次挥手的包

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。

而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

在服务器收到第4次挥手的数据包之前，服务器会释放资源吗？

不会，即便服务器调用了close()，仍然会保留资源，保留到客户端发来第4次挥手的数据包到了为止，什么时候到了，什么时候才释放资源