TCP是面向连接的协议，因此TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。所以，一次完整的TCP通信就包括三个过程：连接建立、数据传送和连接释放。

1. TCP的连接建立

TCP建立连接的过程叫做握手，握手需要在连接发起者（客户）和连接接收者（服务器）之间交换三个 TCP 报文段。因此人们常将这一过程称为三次握手。

图中两个主机下面的方块表示它们分别处在什么状态。

最开始，客户和服务器都处于 CLOSED 状态，之后服务器为了接收外部的请求，于是处于 LISTEN 状态，等待客户的连接。如有，立刻做出反应。

之后客户发出请求连接报文，该报文首部中 SYN 为1，同时选择一个初始序号 seq=x。TCP 规定，SYN 报文段（即SYN = 1的报文段）不能携带数据，但要消耗掉一个序号。这时，客户进入 SYN-SENT（同步已发送） 状态。

服务器收到请求连接报文后，如果同意连接，则向 A 发送确认。在确认报文段中，SYN 和 ACK都置为1，确认号 ack=x+1，同时也为自己选择一个初始序号 seq=y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时TCP服务器进入 SYN_RCVD（同步收到）状态。

TCP客户收到服务器的确认后，还要再给服务器一次确认。确认报文段的 ACK 置1，确认号 ack=y+1，而自己的序号 seq=x+1。TCP标准规定，这个 ACK 报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，客户发送的下一个数据报文的序号仍是 seq=x+1。这之后，TCP客户进入 ESTABLISHED（连接已建立）状态。

当服务器接收到上一个确认的时候，也进入 ESTABLISHED 状态。

这是一个 SSH 的例子，SSH 是应用层协议，要先建立 TCP 链接，可以看到前三个数据包就是三次握手。前面提到的头部的各种控制字也能对应上。

为什么客户也要发送一次确认呢

这主要是为了处理过期的 TCP 连接请求。试想这样一种情况，客户端对服务器发送了一个 SYN 请求建立连接，但这个数据段在网络的某个节点滞留了，导致定时器超时，客户端重传 SYN 。这个 SYN 被服务端成功接收并建立起一条 TCP 链路，在完成数据传输后 TCP 链路断开。但这时，第一个 SYN 终于姗姗来迟，而服务器并不知道这个 SYN 其实已经被客户端认定为过期了，假设没有第三次握手，服务端会给客户端发送 SYN-ACK，然后建立对应的结构体分配资源，自以为建立了一条 TCP 链路。而客户端会忽略这个莫名其妙的 SYN-ACK ，所以这就会导致服务端一直单方面保持着这条 TCP 链路所需的各种资源，白白浪费。

而有了第三次握手就可以避免这种情况，例如服务端发送了 SYN-ACK 后如果半天没有收到第三次握手，就会释放对应的资源。

2. 三次握手的异常情况

客户端发送 ACK 后一直没有收到 SYN-ACK 的回应

这有可能是客户端的 ACK 在网络中丢失了，自然不会收到 SYN-ACK 的回应。于是客户端会在计时器过期后重传 ACK ，这样即可以解决异常。

但同样还有一种可能。我们说服务端的 TCP 为每一个处在监听状态的套接字维护两个队列，未完成连接队列和已完成连接队列。未完成连接队列中存储每个到达的 SYN 分节，表示已接收到 SYN 请求，正在等待三次握手完成，即等待客户端返回的 ACK 。而已完成连接队列中的每一项代表已经收到客户端返回的 ACK ，三次握手完成，TCP 连接已建立。客户端程序通过系统调用 accept() 取出已完成连接队列的一项。但这两个队列的长度是有限制的，即通过系统调用 listen() 的第二个参数控制。假如两个队列满了，则此时再次收到一个 SYN 后，服务端会直接将之忽略，这样客户端同样会半天收不到 SYN-ACK ，导致超时重传 SYN 。之所以服务端设计成这样忽略 SYN ，是因为队列满这个情况很可能是暂时的，等下一次客户端重传 SYN 来很可能队列就有位置了，所以直接忽略比较合理。

客户端发送 ACK 后收到 RST

这表示服务端的对应端口没有正在监听的套接字。操作系统收到 SYN 且对应端口并无进程在监听的话，就会返回一个 RST 。

客户端的第三次握手 ACK 丢失

客户端收到服务端的 SYN-ACK 后会进入 ESTABLISHED 状态，假如第三次握手的 ACK 丢失，会导致服务端的计时器超时，从而重传 SYN-ACK。而已经进入 ESTABLISHED 状态的客户端会忽略这个 SYN-ACK ，导致服务端不断重传，在一定次数的重传后，服务端会主动将这个连接关闭。但客户端认为这个连接已经建立，假如其向服务端发送数据，会得到 RST 的回应，从而感知到 TCP 连接出现了错误。

TCP 连接的释放

TCP 连接的释放也被称为四次挥手，下面就来详细看看：

如图，假设客户现在想要主动关闭 TCP 连接，则其主动发送一个 FIN 报文，其中 seq=u ，即等于之前使用的最后一个序号加一。此时 A 进入 FIN-WAIT-1 状态。TCP 规定，即使 FIN 报文不携带数据，也要消耗一个序号。

然后服务器收到 FIN 后，要确认这个报文，即发送一个 ACK 给客户，这个 ACK 的 ack=u+1，seq=v，即之前传输的最后一个序号加一。客户收到这个 ACK 后，进入 FIN-WAIT-2 状态，此时相当于客户到服务器的连接已经关闭。而服务器发送完 ACK 后进入 CLOSE-WAIT 状态，这个状态被称为半关闭状态，因为此时只是客户到服务器的连接关闭，而服务器到客户的连接并未关闭。也就是说此时服务器仍然可以给客户发送数据，且客户也必须得接收数据。注意这些报文段的 ack 一直等于 u+1 。

而等到服务器把自己的数据也发完了，就再给客户发送一个 FIN，表示我的数据也传送完了。此时服务器进入 LAST-ACK 状态，等待客户的确认。

客户收到服务器最后的 ACK 后，要再次发送确认。然后进入 TIME-WAIT 状态，注意此时 TCP 仍未释放，客户必须等待 2MSL 时间后才能释放 TCP 连接。MSL 被称为最长报文段寿命，RFC-793 建议 MSL 为 2 分钟，现实中可能更短一些。过了 2MSL 时间后客户才进入 CLOSED 状态。而服务器收到最终确认后也进入 CLOSED 状态。

那么问题就来了，这个 2MSL 是干嘛的呢？两个目的，第一，这其实是为了处理客户的最后一个 ACK 在网络中丢失这种情况的，假如客户的最终 ACK 在网络中丢失，而客户不等待直接进入 CLOSED 状态。那服务器只会发现没有收到客户的最终 ACK ，从而重传 FIN ，但客户已经 CLOSED 了，就会导致服务器永远处于 LAST-ACK 状态，浪费系统资源。而加上了 2MSL 时间后，客户可以等待是否还会受到重传的 FIN ，从而阻止了这种情况的出现。第二，记得前面说的第三次握手的作用吗，为了防止已失效的 SYN 再次传输到服务器。而这里挥手时等待 2MSL 也可以延长 TCP 连接时间，使得网络中的失效 SYN 尽快消失。