TCP三次握手建立连接，四次握手断开连接

TCP报文段首部格式：
序号：本报文段所发送的数据的第一个字节的序号。
确认号ack：期待收到对方下一个报文段的第一个数据字节的序号。
确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效。
同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。

终止FIN：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接

1.三次握手

三次握手（ 第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
完成三次握手，客户端与服务器开始传送数据，在上述过程中，还有一些重要的概念：
未连接队列

在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于SYN_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。三次联络）

还要再发送一次确认是为了，防止已失效的连接请求报文段突然又传到了B，因而产生错误。

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

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

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

2.四次握手断开连接

B收到连接释放报文段后就立即发送确认，然后就进入close-wait状态，此时TCP服务器进程就通知高层应用进程，因而从A到B的连接就释放了。此时是“半关闭”状态。即A不可以发送给B，但是B可以发送给A。
此时，若B没有数据报要发送给A了，其应用进程就通知TCP释放连接，然后发送给A连接释放报文段，并等待确认。
A发送确认后，进入time-wait，注意，此时TCP连接还没有释放掉，然后经过时间等待计时器设置的2MSL后，A才进入到close状态。
为什么要等待呢?
①、为了保证A发送的最后一个ACK报文段能够到达B。即最后这个确认报文段很有可能丢失，那么B会超时重传，然后A再一次确认，同时启动2MSL计时器，如此下去。如果没有等待时间，发送完确认报文段就立即释放连接的话，B就无法重传了（连接已被释放，任何数据都不能出传了），因而也就收不到确认，就无法按照步骤进入CLOSE状态，即必须收到确认才能close。
②、防止“已失效的连接请求报文段”出现在连接中。经过2MSL，那些在这个连接持续的时间内，产生的所有报文段就可以都从网络中消失。即在这个连接释放的过程中会有一些无效的报文段滞留在楼阁结点，但是呢，经过2MSL这些无效报文段就肯定可以发送到目的地，不会滞留在网络中。这样的话，在下一个连接中就不会出现上一个连接遗留下来的请求报文段了。
可以看出：B结束TCP连接的时间比A早一点，因为B收到确认就断开连接了，而A还得等待2MSL.