三次握手

客户端和服务端都是先建立传输控制模块。

SYN=1，表明这是一个TCP连接请求报文段。序号字段seq被设置了一个初始值x，作为TCP客户进程所选择的初始序号。

TCP规定SYN被设置为1的报文段不能携带数据，但要消耗掉一个序号。

由于是TCP客户端主动发起的，因此称为主动打开链接。TCP服务进程是被动打开（监听）

TCP服务端发送的报文中的SYN=1,ACK=1表明这是一个 连接请求确认报文段。seq序号字段作为服务器选择的初始序号，确认号ack为x+1，这是对tcp 客户进程选择的初始序号 的确认。同时这个报文段也不能设置数据，因为这个是SYN被设置为1的报文段。同样也消耗掉一个序号。

这个时候客户端返回的 ACK=1, seq=x+1， ack=y+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x，并且不携带数据。请注意：TCP规定普通的TCP报文段可以携带数据，如果不携带数据，则不消耗序号。

在这种情况下，所发送的下一个数据报文段的序号仍是seq=x+1。确认号ack=y+1就是对服务器的确认。

TCP客户进程为什么最后还要发送给一个普通的TCP确认报文段呢？换句话说，就是两次握手能否建立连接？

如果改为 两次握手：

这将白白浪费服务器的资源。

四次挥手

客户端发送的报文段首部中的终止位 FIN =1，确认为ACK=1，表明这是一个TCP连接释放报文段。

同时也对之前收到的报文段进行确认：序号seq=u，它等于客户进程发送的最后一个数据的最后字节序号+1,。

ack=v，等于TCP客户进程最后一个进程收到的服务器的seq+1；

TCP规定：终止位FIN=1的报文段即使不携带数据，也要消耗掉一个序号。

服务器发的：ACK=1，表明是一个普通的 TCP确认报文段。

序号seq字段的值为v，等于服务器进程之前已传送过的数据的最后一个字节的序号+1；

ack就是对上次的seq=u进行确认+1；同时服务进程通知高层应用进程：客户进程要断开与自己的连接。

此时TCP客户进程到TCP服务进程这个方向的连接就释放了。

这是TCP连接属于半关闭状态。也就是服务器进程到客户进程这个方向的连接没有关闭。

这个状态可能会持续一段时间。等待TCP服务进程发送的释放报文段。

然后TCP高层应用进程就通知 服务进程进行被动释放（没有数据要传输了）。

在TCP客户进程发送的 第二次TCP普通确认中 seq=u+1 是因为 之前发送的TCP连接释放报文段虽然不携带数据，但要消耗掉一个序号。ack就是对之前seq=w的确认了。

MSL：最长报文段寿命。