图解TCP 三次握手四次挥手

TCP/IP：因特网整个 TCP/IP 协议族

TCP/IP(Transmission Control Protocol/Internet Protocol)传输控制协议/因特网互联协议，又名网络通讯协议。由网络层的 IP 协议和传输层的 TCP 协议组成。

TCP 负责发现传输的问题，一有问题就发出信号，要求重新传输，直到所有数据安全正确地传输到目的地。而 IP 是给因特网的每一台联网设备规定一个地址。

TCP/IP 参考模型：应用层、传输层、网络层、网络接口层。但是网络接口层并没有严格的划分。所以有时候也有人把网络接口层拆分成两层：数据链路层、物理层。

“三次握手”：建立 TCP 连接过程

目的：为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。————谢希仁《计算机网络》

“已失效的连接请求报文段”的产生在这样一种情况下：服务端 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 服务端。本来这是一个早已失效的报文段。但 服务端 收到此失效的连接请求报文段后，就误认为是 服务端 再次发出的一个新的连接请求。于是就向 服务端 发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要 服务端 发出确认，新的连接就建立了。由于现在 服务端 并没有发出建立连接的请求，因此不会理睬 服务端 的确认，也不会向 服务端 发送数据。但 服务端 却以为新的运输连接已经建立，并一直等待 服务端 发来数据。这样，服务端 的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，服务端 不会向 服务端 的确认发出确认。服务端 由于收不到确认，就知道 服务端 并没有要求建立连接。”。主要目的防止 服务端 端一直等待，浪费资源。

【动图转自：https://blog.csdn.net/qzcsu/article/details/72861891】

标志位含义：
ACK：确认序号有效，表示响应。
SYN：发起一个新连接。
FIN：释放一个连接，关闭连接。
PSH：有数据传输
RST：连接重置

第一次握手
Client 将标志位 SYN 置 1，随机产生一个值 seq=J,并将数据包发给 Server
Client 进入 SYN*SENT 状态，等待 Server 确认

第二次握手
Server 收到数据包后标志位 SYN=1 知道 Client 请求建立连接，Server 将标志位 SYN 和 ACK 都置 1，随机产生一个值,并将数据包发给 Client 确认连接请求，Server 进入 SYN_RCVD 状态

第三次握手
Client 收到确认后若 ACK 为 1，则将该数据包发送给 Server，Server 检查 ACK 为 1 则连接建立成功，Client 与 Server 进入 ESTABLISHED 状态完成三次握手，可以传输数据
简述：

服务端发送一个带 SYN 标志的数据包给对方。服务端收到后，回传一个带有 SYN/ACK 标志的数据包以示传达确认信息。 最后，服务端再回传一个带 ACK 标志的数据包，代表“握手”结束。

为什么是三次不是两次
防止已失效的请求报文段突然又传送到了服务端而产生连接的误判

“四次挥手”：终止 TCP 连接过程

原因：由于 TCP 连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个 FIN 来终止这一方向的连接，收到一个 FIN 只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个 TCP 连接上仍然能够发送数据，直到这一方向也发送了 FIN。

【动图转自：https://blog.csdn.net/qzcsu/article/details/72861891】

第一次挥手：
Client 发送一个 FIN，用来关闭 Client 到 Server 的数据传送，Client 进入 FIN_WAIT_1 状态。

第二次挥手：
Server 收到 FIN 后，发送一个 ACK 给 Client,Server 进入 CLOSE_WAIT 状态。

第三次挥手：
Server 发送一个 FIN，用来关闭 Server 到 Client 的数据传送，Server 进入 LAST_ACK 状态。

第四次挥手：
Client 收到 FIN 后，Client 进入 TIME_WAIT 状态，发送 ACK 给 Server，Server 进入 CLOSED 状态，完成四次握手。

简述：

服务端发送 FIN；服务端接收 FIN 并发送 ACK 给服务端；服务端发送 FIN；服务端接收 FIN 并发送 ACK 给服务端，

参考连接:
https://blog.csdn.net/yu876876/article/details/81560122
http://www.imooc.com/article/79180
https://blog.51cto.com/13871180/2162062
https://blog.csdn.net/qzcsu/article/details/72861891