TCP三次握手和四次挥手

TCP报文格式

• 源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去
• 序号：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
• 确认序号：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
• 6位标志位:
  URG: 紧急指针是否有效
  ACK: 确认号是否有效
  PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
  RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
  SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
  FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段

注意：

• 不要将确认序号Ack与标志位中的ACK搞混了。
• 确认方Ack=发起方Seq+1，两端配对

三次握手

所谓三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，流程如图：

建立TCP连接时，需要客户端和服务器共发送3个包。

• 第一次：客户端发送syn包(seq=J)到服务器，并进入SYN_SENT状态，等待服务器确认;
• 第二次：服务器收到syn包，必须确认客户SYN(ack=J+1)，同时自己也发送一个SYN包(seq=K)，即SYN+ACK包，此时服务器进入SYN_RCVD状态;
• 第三次：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=K+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

举个例子来说：如同两个人许久未见朋友打招呼，客户端不100%确定先招招手(SYN)，服务端接收到后发现是朋友，也招招手(SYN)，同时也微笑(ACK)，看到回应后也微笑(ACK)确认。

为什么是三次握手？

一次肯定是建立不了连接的。
为什么不是两次
因为有可能客户端先发了一个连接请求报文，但是由于网络的问题，迟迟没有到达服务端，这时候，客户端就超时重传了该报文，然后服务端响应了该请求报文，然后通信结束，然而第一次发送的报文到达了。然后服务端无端端的又激活了，但是客户端已经不需要在和服务端通信了。浪费服务端资源。
为什么不是四次
其实可以，但是四次就冗余了，所以4次、5次、6次都是可以的，但是为了兼顾性能和可靠性三次就够了。

四次挥手

四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发，流程如图：

首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。

• 第一次挥手：客户端发送一个FIN，用来关闭客户端到服务端的数据传送，客户端进入FIN_WAIT_1状态。
• 第二次挥手：服务端收到FIN后，发送一个ACK给客户端，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），服务端进入CLOSE_WAIT状态。
• 第三次挥手：服务端发送一个FIN，用来关闭服务端到客户端的数据传送，服务端进入LAST_ACK状态。
• 第四次挥手：客户端收到FIN后，客户端进入TIME_WAIT状态，接着发送一个ACK给服务端，确认序号为收到序号+1，服务端进入CLOSED状态，完成四次挥手。

为什么是四次挥手？

由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到另一方向也发送了FIN。
类似于：客服端告诉服务端，我的数据发完了。你看看你还有没有数据要发给我，没有的话，我们的通信就可以断了。然后服务端也告诉客户端，我的数据也发完了，我们一起关闭吧。

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

• 三次握手时，服务器同时把ACK和SYN放在一起发送到了客户端那里
• 四次挥手时，当收到对方的 FIN 报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方是否现在关闭发送数据通道，需要上层应用来决定，因此，己方 ACK 和 FIN 一般都会分开发送

为什么客户端最后还要等待2MSL？

• 客户端需要保证最后一次发送的ACK报文到服务器，如果服务器未收到，可以请求客户端重发，这样客户端还有时间再发，重启2MSL计时。