正如大家所熟悉的，采用的是C/S模式即"客户机-服务器模式"的tcp连接是计算机网络的基础，本文将直奔主题讲述TCP连接建立与释放（“三握四挥”）：
初始状态：
协议准备建立：
第一次握手
客户机需要与服务器建立连接。A的TCP进程创建TCB（传输控制块），然后向B发出连接请求报文段。段首部中的 同步位SYN=1，同时选择一个初始序列号seq=x；表明传送数据时的第一个数据字节的序号是 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 状态。连接建立完成。同时tcp将向上层应用报告连接已经建立，可以开始传输数据了。
注：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：监听状态，等待客户连接
SYB-SENT：同步已发送
SYN-RCVD：同步已接收
ESTAB-LISHED：已建立连接
数据传输结束后，通信的双方都可以释放连接：
第一次挥手：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）最长报文段寿命，RFC 793 建议设为两分钟，对于现在的网络，MSL=2分钟可能太长了一些，我们可根据具体情况使用更小的MSL值。
四挥的七个状态：
ESTAB-LISHED：已建立连接
FIN-WAIT-1：终止等待1
CLOSE-WAIT：关闭等待
FIN-WAIT-2：终止等待2
LAST-ACK：最后确认
TIME-WAIT：时间等待
CLOSED：关闭
为什么A要等待2MSL的时间？
- 为了保证A发送的最后一个报文段能够到达B。因为这个 ACK 有可能丢失，从而导致处在 LAST-ACK 状态的服务器收不到对 FIN-ACK 的确认报文。服务器会超时重传这个 FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待 2MSL，而是在发送完 ACK 之后直接释放关闭，一旦这个 ACK 丢失的话，服务器就无法正常的进入关闭连接状态。
- 可以防止已失效的报文段。客户端在发送最后一个 ACK 之后，再经过 2MSL，就可以使本连接持续时间内所产生的所有报文段都从网络中消失，从保证在关闭连接后，不会有仍在网络中滞留的报文段去骚扰服务器。
为什么要四次挥手？
- A 向 B 发送一个连接释放请求报文，代表 A 的数据传送完了，请求释放连接；
- B 收到后，B 立即向 A 发送一个确认报文，代表 B 已经知道 A 没有数据要传送了，但是 B 可能还有数据要向 A 传送；
- B 的数据传送完后，向 A 发送一个连接释放请求报文，代表 B 的数据也传送完了，请求释放连接；
- A 收到后，也立即向 B 发送一个确认报文，同时等待 2MSL 后，连接断开。
注：TCP 是全双工通信，因此必须两个方向分别断开连接。
为什么建立连接三次，断开连接四次？
- 因为建立连接时，服务器的确认 ACK 和请求同步 SYN 可以放在一个报文里，而断开连接时，服务器可能还有数据要传送，因此，必须先发一个客户端断开连接请求的确认 ACK，以免客户端超时重传，待服务器的数据传送完毕后，再发送一个请求断开连接的报文段。
- 断开时次数比连接多一次，是因为连接过程，通信只需要处理「连接」，而断开过程，通信需要处理「数据+连接」。
