TCP-IP学习笔记回顾-4.9.1 TCP连接的建立 （三次握手）- 图文

（1）上图中，B的服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求。然后服务器进程就处于LISTEN（监听）状态，等待客户的连接请求。
（2）A的TCP客户进程也是首先创建传输控制块TCB，然后向B发出连接请求报文段，这时首部中的同步位SYN=1，同时选择一个初始序号seq=x。TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。
（3）B收到连接请求报文段后，如同意建立连接，则向A发送确认。在确认报文段中应把SYN位和ACK为都置1，确认好ack=x+1，同时也为自己选择一个初始序号seq=y。这个报文段也不能携带数据，但同样要消耗一个序号。这时TCP服务器进程进入SYN-RCVD（同步收到）状态。
（4）TCP客户进程收到B的确认后，（补充：A进入ESTABLISHEN（已建立连接）状态）还要向B给出确认。确认报文段的ACK置1.确认号ack=y+1，而自己的序号seq=x+1。TCP的标准规定，ACK报文段可以携带数据，但如果不携带数据则不消耗序号。这时，TCP连接已建立，A进入ESTABLISHEN（已建立连接）状态。

问题：为什么TCP客户端最后还要发送一次确认呢？
一句话，主要防止已失效的连接请求报文段突然又传送到了服务器，从而产生错误。
如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。（牛逼）