在 TCP 连接建立过程中要解决以下三个问题:
(1)要使每一方能够确知对方的存在。
(2)要允许双方协商一些参数(如最大窗口值、是否使用窗口扩大选项和时间戳选及服务质量等)。
(3)能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配。
TCP 连接的建立采用客户服务器方式。主动发起连接建立的应用进程叫做客户( client ),而被动等待连接建立的应用进程叫做 服务器( server )。
TCP 的连接建立
TCP 建立连接的过程叫做握手,握手需要在客户和服务器之间交换三个 TCP 报文段 画出了三报文握手建立 TCP 连接的过程。
假定主机 A 运行的是 TCP 客户程序,而 B 运行 TCP 服务器程序。最初两端的 TCP 进程都处于 CLOSED (关闭)状态。图中在主机下面的方框分别是 TCP 进程所处的状态。请注意,在本例中, A 主动打开连接,而 B 被动打开连接。
一开始, B 的 TCP 服务器进程先创建传输控制块 TCB ,准备接受客户进程的连接请求。然后服务器进程就处于 LISTEN (收听)状态,等待客户的连接请求。如有,即作出响应。
A 的 TCP 客户进程也是首先创建传输控制模块 TCB 。然后,在打算建立 TCP 连接时,向 B 发出连接请求报文段,这时首部中的同步位 SYN =1,同时选择一个初始序号 seq = x 。 TCP 规定, SYN 报文段(即SYN =1的报文段)不能携带数据,但要消耗掉一个序号。这时, TCP 客户进程进入 SYN - SENT (同步己发送)状态。
B 收到连接请求报文段后,如同意建立连接,则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置1,确认号是 ack = x +1,同时也为自己选择一个初始序号 seq = y 请注意,这个报文段也不能携带数据,但同样要消耗掉一个序号。这时 TCP 服务器进程进入 SYN - RCVD (同步收到)状态。
TCP 客户进程收到 B 的确认后,还要向 B 给出确认。确认报文段的 ACK 置1,确认号 ack = y +1。而自己的序号 seq = x +1。TCP的标准规定, ACK 报文段可以携带数据。但如果不携带数据则不消耗序号,在这种情况下,下一个数据报文段的序号仍是 seq = x +1。这时, TCP 连接已经建立, A 进入 ESTABLISHED (已建立连接)状态。
当 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 的许多资源就会浪费。