TCP建立连接时,为什么要进行三次挥手?
在TCP层，有个FLAGS字段，这个字段有以下几个标识：SYN, FIN, ACK, PSH, RST, URG.
其中，对于我们日常的分析有用的就是前面的五个字段。
它们的含义是：
SYN表示建立连接，
FIN表示关闭连接，
ACK表示响应，
PSH表示有 DATA数据传输，
RST表示连接重置，
Sequence number(顺序号码)，
Acknowledge number(确认号码)。
其中，ACK是可能与SYN，FIN等同时使用的，比如SYN和ACK可能同时为1，它表示的就是建立连接之后的响应，
如果只是单个的一个SYN，它表示的只是建立连接。
TCP的几次握手就是通过这样的ACK表现出来的。
但SYN与FIN是不会同时为1的，因为前者表示的是建立连接，而后者表示的是断开连接。
RST一般是在FIN之后才会出现为1的情况，表示的是连接重置。
一般地，当出现FIN包或RST包时，我们便认为客户端与服务器端断开了连接；而当出现SYN和SYN＋ACK包时，我们认为客户端与服务器建立了一个连接。
PSH为1的情况，一般只出现在 DATA内容不为0的包中，也就是说PSH为1表示的是有真正的TCP数据包内容被传递。
TCP的连接建立和连接关闭，都是通过请求－响应的模式完成的。
概念补充-TCP三次握手：
TCP(Transmission Control Protocol)传输控制协议
TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接：
位码即tcp标志位，有6种标示：SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)Sequence number(顺序号码) Acknowledge number(确认号码)
第一次握手：主机A发送位码为syn＝1，随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；
第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1)，syn=1，ack=1，随机产生seq=7654321的包；
第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1，以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1)，ack=1，主机B收到后确认seq值与ack=1则连接建立成功。
完成三次握手，主机A与主机B开始传送数据。
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据.
每一次TCP连接都需要三个阶段：连接建立、数据传送和连接释放。三次握手就发生在连接建立阶段。 在谢希仁著《计算机网络》第四版中讲三次握手的目的是为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。在另一部经典的《计算机网络》一书中讲三次握手的目的是为了解决网络中存在延迟的重复分组的问题。 这两种不用的表述其实阐明的是同一个问题。
谢希仁版《计算机网络》中的例子是这样的，已失效的连接请求报文段的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用三次握手，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用三次握手的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。
这个例子很清晰的阐释了三次握手对于建立可靠连接的意义。在Google Groups的TopLanguage中看到一帖讨论TCP三次握手觉得很有意思。贴主提出的问题，在众多回复中，有一条回复写道：这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了. 。这可视为对三次握手目的的另一种解答思路。
举个打电话的例子：
A : 你好我是A，你听得到我在说话吗
B : 听到了，我是B，你听到我在说话吗
A : 嗯，听到了
建立连接，开始聊天！
三次握手
第一次: 客户端A发送位码为SYN＝1,随机产生序号seq=123的数据包到服务器B，服务器B由SYN=1知道，A要求建立联机；
第二次: 服务器B收到请求后要确认联机信息，向A发送ACK=1,SYN=1,ack=(客户端A的seq+1),随机产生seq=321的包；
第三次: 客户端A收到后，检查服务器中的ack是否为第一次握手中if(seq+1==124),以及位码ACK是否为1，若正确，主机A会再发送ACK=1,ack=322(主机B的seq+1=322),seq=123+1(第一次握手seq+1)；主机B收到后确认seq124是否等于第一次seq+1(123+1)，与ACK=1则连接建立成功。
为什么TCP协议终止链接要四次？
1、当主机A确认发送完数据且知道B已经接受完了，想要关闭发送数据口（当然确认信号还是可以发），就会发FIN给主机B。
2、主机B收到A发送的FIN，表示收到了，就会发送ACK回复。
3、但这是B可能还在发送数据，没有想要关闭数据口的意思，所以FIN与ACK不是同时发送的，而是等到B数据发送完了，才会发送FIN给主机A。
4、A收到B发来的FIN，知道B的数据也发送完了，回复ACK， A等待2MSL以后，没有收到B传来的任何消息，知道B已经收到自己的ACK了，A就关闭链接，B也关闭链接了。
为什么要等待2MSL时间呢
MSL(最长报文段寿命Maximum Segment Lifetime),建议2分钟，所以要等近4分钟
保证A发送的最后一个ACK报文段可以到达B，使得B正常关闭。如果不等的话，A发送的ack丢失，则会造成b无法关闭。等待则保证B能正常接收。如果在2MSL时间中，又收到B发送的FIN(超时重传)，则A重新发送ACK，并重启定时器防止出现“已失效的连接请求报文段”，经过2MSL时间可以保证本连接时间内的所有报文段都可以从网络消失。
A为什么等待2MSL，从TIME_WAIT到CLOSE？
在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
这个网上转载的例子不错：
三次握手：
A:“喂，你听得到吗？”A->SYN_SEND
B:“我听得到呀，你听得到我吗？”应答与请求同时发出 B->SYN_RCVD | A->ESTABLISHED
A:“我能听到你，今天balabala……”B->ESTABLISHED
四次挥手：
A:“喂，我不说了。”A->FIN_WAIT1
B:“我知道了。等下，上一句还没说完。Balabala…..”B->CLOSE_WAIT | A->FIN_WAIT2
B:”好了，说完了，我也不说了。”B->LAST_ACK
A:”我知道了。”A->TIME_WAIT | B->CLOSED
A等待2MSL,保证B收到了消息,否则重说一次”我知道了”,A->CLOSED
总结
TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接，与之相反的，采用四次挥手来断开连接：
TCP标志位有6种标示，即：SYN(建立联机) 、 ACK(确认) 、 PSH(传送) 、 FIN(f结束) 、 RST(重置) 、 URG(紧急) 、 Sequence number(顺序号码) 、 Acknowledge number(确认号码)。
三次握手
为了准确无误的将数据发送到指定IP处，TCP协议采用了三次握手的策略，如下步骤所示：
1、客户端采用TCP协议将带有SYN标志的数据包发送给服务器，等待服务器的确认。
2、服务器端在收到SYN的数据包后，必须确认SYN，即自己发送的ACK标志，同时，自己也将会向客户端发送一个SYN标志。
3、客户端在接收到服务器短的SYN+ACK包后，自己会向服务器发送ACK包，完成三次握手。那么客户端和服务器正式建立了连接，开始传输数据。
三次握手的图如下所示：
四次挥手
四次挥手是用来断开服务器和客户端之间的通信的，之所以要断开连接，是因为TCP/IP 协议是要占用端口号的，而计算机的端口却是有限的，不进行断开的话，势必会造成计算机资源的浪费。
1、在整个通信的过程中，谁先发起请求，谁就是客户端。
当客户端的数据传输到尾部时，客户端向服务器发送带有FIN标志的数据包，使其明白自己准备断开通信了。
2、因为TCP的通信是使用全双工通信的WebSocket，所以在断开连接的时候也应该是双向的；当服务器收到带有FIN标志的数据包时，其必不会直接发送FIN标志断开通信的请求，而是先发送一个带有ACK标志的应答信息，使客户端明白服务器还有数据要进行发送。
3、当 服务器的数据发送完成后，向客户端发送带有FIN标志的数据包，通知客户端断开连接。
4、这一次挥手是我觉得四次挥手中设计的最巧妙的一次。
当客户端收到FIN后，担心网络上某些不可控制的因素导致服务器不知道他要断开连接，会发送ACK进行确认，同时把自己设置成TIME_WAIT状态并启动定时器，**在TCP的定时器到达后客户端并没有接收到请求，会重新发送；当服务器收到请求后就断开连接；当客户端等待2MLS（两倍报文最大生存时间）后，没有收到请求重传的请求后，客户端这边就断开连接，**整个TCP通信就结束了。
四次挥手的图如下所示：
注：三次握手为什么不能改成两次握手？
解：三次握手中的每一次都是必须的。如果是两次握手，在第二次结束后，服务器并不能保证客户端已经收到了第二次的请求，如此一来的话，服务器会一直保存着这个通信过程，因为TCP通信都是要占用端口的，造成了一定的资源浪费。所以，就一定要让客户端来发送ACK的确认请求。
注：关闭的时候为什么会是四次挥手？
解：四次挥手不能像三次握手一样，三次握手可以将ACK+SYN 一起发送，ACK用于确认信息，SYN却是用来建立联机的；四次挥手中ACK是不能和FIN一起发送，ACK只是告诉客户端确认我收到了，等我将数据发送完毕之后会向其发送FIN的标志，所以四次挥手是不能够改变的。
原文地址：https://www.cnblogs.com/yhxb/p/11513193.html