TCP 三次握手和四次挥手理解

三次握手建立连接

1. 客户主机发送请求报文，Flag设置为 SYN，带上 Seq， 假设为 clientNo;
2. 服务主机接收到报文后，为这次连接分配资源，并回复报文, Flag设置为 [SYN, ACK]， 带上 Seq, 假设为 serverNo，同时带上 Ack，为clientNo + 1;
3. 客户主机收到报文后，为链接分配资源，也会发送回复报文，Flag设置为 ACK， 带上 Seq，为 clientNo + 1， 并带上 Ack，为 serverNo + 1。

三次握手后，TCP连接正式建立。具体流程如下图所示：

三次握手

四次挥手断开连接

1. 客户主机发送断开连接请求（也可以是服务主机首先发送该请求，如 Http 服务器），发送报文，Flag设置为 FIN，并带上 Seq，假设为 clientNo。发送该报文，可以通俗的理解为：客户主机告诉服务主机，我们没啥好说的了，你那边没什么异议的话，要不我们分手吧。
2. 服务主机收到 Fin 报文后，发送回复报文，Flags设置为 ACK，带上Seq，假设为 serverNo1，同时带上 Ack，为clientNo + 1。可以通俗的理解为：我懂你的意思了，让我先准备准备先。此时，提出分手的主机进入 FIN_WAIT 状态，等待服务主机的分手报文。
3. 服务主机确定数据已经发送完成，则向客户主机发送断开报文，Flag设置为 FIN，并带上 Seq，假设为 serverNo2。可以理解为：碧池，我这边事情完结了，我们可以分手了。
4. 客户主机收到 FIN 报文后，知道可以关闭网络，发送回复报文，设置Flags为 ACK，带上Seq为clientNo2，Ack为ServerNo2 ＋ 1，之后进入 TIME_WAIT状态，如果 2MSL 后，服务主机没有回应，说明服务主机已经正常关闭，客户主机也关闭连接。

具体流程如下图所示：

三次挥手

抓包实例

下图是用 WireShark 对 HTTP 请求的抓包实例：

WireShark抓包

前三个包是三次握手，后四个包是四次挥手

三次握手

1. 客户端发送 SYN 包，Seq为0
2. 服务端发送 [SYN, ACK] 包，Seq为0， Ack为1
3. 客户端发送 ACK 包，Seq为0， Ack为1

四次挥手

1. 服务端发送 [FIN, ACK] 包，Seq为1226，Flags中的 ACK 不是用于关闭连接
2. 客户端发送 ACK 包，Seq为2031， Ack为1227
3. 客户端发送 [FIN, ACK] 包，Seq为2031
4. 服务端发送 ACK 包，Seq为1227， Ack＝2032

注意

什么要三次握手

在谢希仁的《计算机网络》中是这样说的：

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

在书中同时举了一个例子，如下：

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

这就很明白了，防止了服务器端的一直等待而浪费资源。

什么要四次握手

TCP是全双工模式，这就意味着：

1. 当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；
2. 当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；
3. 当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

内容来源

http://www.jellythink.com/archives/705

http://blog.csdn.net/whuslei/article/details/6667471/