建立连接（三报文握手）

TCP 连接的建立采用客户-服务器方式。

• 主动发起连接建立的应用进程叫做客户（client）

• 被动等待连接建立的应用进程叫做服务器（server）

假定主机 A 运行的是 TCP 客户程序，而 B 运行 TCP 服务器程序。

最初两端的 TCP 进程都处于 CLOSED（关闭）状态。B 的 TCP 服务器进程先创建传输控制块 TCB，准备接受客户进程的连接请求。然后服务器进程就处于 LISTEN（收听）状态，等待客户的连接请求。

1. A 的 TCP 客户进程也是首先创建传输控制模块 TCB。然后，在打算建立 TCP 连接时，向 B 发出连接请求报文段，这时首部中的同步位 SYN＝1，同时选择一个初始序号 seq＝x。 这时，TCP 客户进程进入 SYN-SENT（同步已发送）状态。

2. B 收到连接请求报文段后，如同意建立连接，则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1，确认号是 ack＝x＋1，同时也为自己选择一个初始序号 seq＝y。这时 TCP 服务器进程进入 SYN-RCVD（同步收到）状态。

3. TCP 客户进程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号 ack＝y＋1，而自己的序号 seq＝x＋1。 这时，TCP 连接已经建立，A 进入 ESTABLISHED（已建立连接）状态。

4. 当 B 收到 A 的确认后，也进入 ESTABLISHED 状态。

在图中 B 发送给 A 的报文段，也可拆成两个报文段，变成四报文握手：

• 可以先发送一个确认报文段（ACK＝1，ack＝x＋1）

• 然后再发送一个同步报文段（SYN＝1，seq＝y）

为什么 A 最后还要发送一次确认呢？

这主要是为了防止已失效的连接请求报文段突然又传送到了 B，因而产生错误。

考虑一种正常情况，A 发出连接请求，但因连接请求报文丢失而未收到确认。于是 A 再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A 共发送了两个连接请求报文段，其中第一个丢失，第二个到达了 B，没有“已失效的连接请求报文段”。

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

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

采用三报文握手的办法，可以防止上述异常情况的发生。