Tcp三握四挥

一、三次握手

你瞅啥？
瞅你咋地！
你再瞅一个试试！！！
言罢，双方进入扭打（连接）状态

最初，客户机A与服务器B的TCP进程都处于 CLOSED 状态。
然后由服务器B先创建TCB（传输控制块），进入到 LISTEN 状态，准备随时响应客户请求。
下面开始三握：

第一次握手
　　A的TCP进程创建TCB（传输控制块），然后向B发出连接请求报文段。段首部中的 同步位SYN=1，同时选择一个初始序列号seq=x；（SYN报文段不能携带数据，但需要消耗一个序列号）这时客户端A进入到 SYN-SENT（同步已发送）状态。

第二次握手
　　B收到连接请求报文段，如果同意建立连接，则向A发送确认。在确认报文段中 同步位SYN=1、确认位ACK=1、确认号ack=x+1（对接收的序列号seq=x的报文段进行确认，并期望接收的下一个报文段的序号seq=x+1），同时也为自己选择一个初始序列号seq=y，这时服务器B进入 SYN-RCVID 状态。
　　
注：该报文段是ACK报文段的同时也是SYN报文段，所以该报文段也不能携带数据。

第三次握手
　　A收到B的确认以后，再向B发出确认。确认报文 ACK=1、确认号ack=y+1（对接收的序列号seq=y的报文段进行确认，并期望接收的下一个报文段的序号seq=y+1）。这时A进入到 ESTAB-LISHED 状态。当B接收到A的确认后，也进入 ESTAB-LISHED 状态。连接建立完成。
　　
注：ACK报文段可以携带数据，但如果不携带数据则不消耗序列号，在这种情况下，下一个报文段的序号不变，seq仍是x+1。

同步位SYN、确认位ACK、确认号ack 以及 三次握手时出现的五个状态：

同步位SYN：在建立连接时用来同步序号；当SYN=1，ACK=0时，表明这是一个连接请求报文段。当SYN=1，ACK=1时，表明这是一个连接接收报文段；

确认位ACK：当ACK=1时，确认号ack才生效。在请求建立连接后（第一次握手后），所有的报文段都必须把ACK置1。

确认号ack：期望收到的下一个报文段的第一个数据字节的序号，比如：B正确接收到了A发送过来的一个报文段，序号是501，数据长度是200字节；这表明B正确接收到了序号501-700的数据。所以，B期望的下一个序号是701，于是B在发送给A的确认报文段中确认号ack=701。

CLOSED：初始关闭状态
LISTEN：监听状态，等待客户连接
SYN-SENT：同步已发送
SYN-RCVD：同步已接收
ESTAB-LISHED：已建立连接

Q： 为什么不是两次握手？

A：这主要是为了防止已失效的连接请求报文段突然又传送到了 B，从而造成资源浪费。

考虑一种异常情况，即 A 发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 B。本来这是一个早已失效的报文段，但 B 收到此失效的连接请求报文段后，就误认为是 A 又发出了一次新的连接请求，于是就向 A 发出确认报文段，同意建立连接。假定不采用报文握手，那么只要 B 发出确认，新的连接就建立了。

由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向 B 发送数据，但 B 却认为新的运输连接已经建立了，并一直等待 A 发来数据，B 的许多资源就这样浪费了。

采用三次握手的办法，可以防止上述现象的发生，例如在刚才的异常情况下，A 不会向 B 的确认发出确认，B 由于收不到确认，就知道 A 并没有要求建立连接。

Q：为什么不是四次握手？

A：完全可靠的通信协议是根本不存在的，我们任何的通信协议都是在接受这样的现实情况之上进行的。 三次握手后，A 和 B 至少可以确认之前的通信情况，但无法确认之后的情况。在这个道理上说，无论是四次还是五次或是更多次都是徒劳的。
三次握手不是为了确定通信的双方能够确定消息的传达，而是确定消息传播的通道是不是畅通的。只要通道是畅通的，可以用其他策略去判断消息是不是准确有序的传递了（消息的序列号，确认号，超时重传等）。

二、四次挥手

A与B想要断开连接，需要经过四次挥手

第一次挥手
     A先发送连接释放报文段，段首部的终止控制位FIN=1，序号seq=u（等于A前面发送数据的最后一个序号加1）；然后A进入 FIN-WAIT-1（终止等待1）状态，等待B的确认。

注：FIN报文段即使不携带数据也要消耗一个序列。

第二次挥手
     B收到A的连接释放报文段后，立刻发出确认报文段，确认号ack=u+1，序号seq=v（等于B前面发送数据的最后一个序号加1）；然后B进入CLOSE-WAIT（关闭等待）状态。
　
注：TCP服务器这时会通知高层应用进程，从A到B这个方向的连接就断开了，这时TCP连接处于半关闭（half-close）状态；但B到A这个方向的连接并没有断，B任然可以向A发送数据。

第三次挥手：
     A收到B的确认报文段后进入到FIN-WAIT-2（终止等待2）状态，继续等待B发出连接释放报文段；若B已经没有数据要发送，B就会向A发送连接释放报文段，段首部的终止控制位FIN=1，序号seq=w（半关闭状态可能又发送了一些数据），确认号ack=u+1，这时B进入LAST-ACK（最后确认）状态，等待A的确认。

特别注意：确认号ack没有变，仍然为上次发送过的确认号u+1。

第四次挥手：A收到B的连接释放报文段并发出确认，确认段中
     确认位ACK=1，确认号ack=w+1，序号seq=u+1；然后A进入到TIME-WAIT（时间等待）状态。当B再接收到该确认段后，B就进入CLOSED状态。

注：处于TIME-WAIT状态的A必须等待2MSL时间后，才会进入CLOSED状态。MSL（Maximum Segment Lifetime）最长报文段寿命。

四挥的七个状态：

ESTAB-LISHED：已建立连接
FIN-WAIT-1：终止等待1
CLOSE-WAIT：关闭等待
FIN-WAIT-2：终止等待2
LAST-ACK：最后确认
TIME-WAIT：时间等待
CLOSED：关闭

Q：为什么A要等待2MSL的时间？

为了保证A发送的最后一个报文段能够到达B。因为这个 ACK 有可能丢失，从而导致处在 LAST-ACK 状态的服务器收不到对 FIN-ACK 的确认报文。服务器会超时重传这个 FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待 2MSL，而是在发送完 ACK 之后直接释放关闭，一旦这个 ACK 丢失的话，服务器就无法正常的进入关闭连接状态。

可以防止已失效的报文段。客户端在发送最后一个 ACK 之后，再经过经过 2MSL，就可以使本连接持续时间内所产生的所有报文段都从网络中消失，从保证在关闭连接后，不会有仍在网络中滞留的报文段去骚扰服务器。

Q:为什么要四次挥手？

A 向 B 发送一个连接释放请求报文，代表 A 的数据传送完了，请求释放连接；
B 收到后，B 立即向 A 发送一个确认报文，代表 B 已经知道 A 没有数据要传送了，但是 B 可能还有数据要向 A 传送；
B 的数据传送完后，向 A 发送一个连接释放请求报文，代表 B 的数据也传送完了，请求释放连接；
A 收到后，也立即向 B 发送一个确认报文，同时等待 2MSL 后，连接断开。

注：TCP 是全双工通信，因此必须两个方向分别断开连接。

Q:为什么建立连接三次，断开连接四次？

因为建立连接时，服务器的确认 ACK 和请求同步 SYN 可以放在一个报文里，而断开连接时，服务器可能还有数据要传送，因此，必须先发一个客户端断开连接请求的确认 ACK，以免客户端超时重传，待服务器的数据传送完毕后，再发送一个请求断开连接的报文段。

断开时次数比连接多一次，是因为连接过程，通信只需要处理「连接」，而断开过程，通信需要处理「数据+连接」。