计算机网络 三次握手

采用三报文握手采用三报文握手，服务器要确认客户的连接请求，然后客户端要对服务器的确认进行确认。

A为客户端，B为服务端。
首先B处于LISTEN(监听)状态，等待客户的连接请求。

1.A 的 TCP 向 B 发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x，表明传送数据时的第一个数据字节的序号是 x。不能携带数据，但要消耗掉一个序号。

2. B 的 TCP 收到连接请求报文段后，如同意，则回确认。B 在确认报文段中应使 SYN = 1，使 ACK = 1，其确认号ack = x + 1，自己选择的序号 seq = y。不能携带数据，但要消耗掉一个序号。

ack是确认号  是期望收到对方下一个报文段的第一个数据字节的序号

确认号ack=x+1,代表B期望A的下一个报文段的第一个数据字节的序号是x+1

3.A 收到此报文段后向 B 给出确认，其 ACK = 1，  确认号 ack = y + 1。 A 的 TCP 通知上层应用进程，连接已经建立。  

4.B 的 TCP 收到主机 A 的确认后，也通知其上层 应用进程：TCP 连接已经建立。

 

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

第三次握手是为了防止失效的连接请求到服务器，让服务器错误打开连接

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

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