目录
一、基本概述
二、连接建立
1.基本任务
2.具体实现
三、经典问题之为什么不用“两次握手”?
一、基本概述
在前面的部分提到过,TCP是基于运输连接来传输TCP报文段。
所以TCP的连接和释放是每次面向连接的通信过程中必不可少的过程。
TCP运输连接分为三个阶段:连接建立、数据传输、释放连接。
二、连接建立
1.基本任务
TCP建立连接主要解决以下问题:
(1)TCP双方能够确知对方的存在。
(2)TCP双方可以协商一些参数(如最大窗口值等)。
(3)TCP双方能对运输实体资源进行分配(如缓存大小,连接表中的项目等)。
2.具体实现
如图:主动进行TCP连接建立的应用进程称为TCP客户端(后面简称为客户端),而被动等待TCP连接建立的应用进程称为TCP服务器端(后面简称为服务器端)。连接建立采用“三次握手”的形式,即客户和服务器之间需要交换三个TCP报文段。
(1)初始关闭状态:起初两端TCP进程都属于关闭(CLOSED)状态。首先客户和服务器都会创建一个传输控制块。里面就包含了TCP连接表,指向发送和接收缓存的指针等信息。该块在图中不做演示。
(2)服务器进入监听状态:之后,服务器就会进入监听(LISTEN)状态,等待客户的TCP连接建立的请求。很明显这是被动打开。
(3)客户端发送TCP连接请求报文:客户在想要建立TCP连接时,向服务器发送TCP连接请求报文段,并进入同步已发送(SYN-SENT)状态。
TCP连接请求报文段首部的同步位SYN被设置为1,表示这是一个TCP连接请求报文段。序号字段seq被设为x,表示的是客户端所选择的初始序号。很明显这是主动打开。
注意:同步位SYN=1的报文段不允许携带数据,但要消耗掉一个序号。
同步位SYN=1的报文段不一定就是TCP连接请求报文段,TCP连接请求确认报文段的SYN也为1。
(4)服务器端发送TCP连接请求确认报文:如果服务器端收到TCP请求报文段后同意进行TCP连接建立,就会向客户端发送TCP连接确认报文段。并进入同步已接收(SYN-RCVD)状态。
TCP连接确认报文段首部的同步位SYN和确认位ACK都被设置为1,表示这是一个TCP连接请求确认报文段;序号字段seq被设为y,表示的是服务器端所选择的初始序号;确认号字段ack为x+1,这是对客户端所选择的初始号的确认。
该报文段仍然不能携带数据,但是会消耗掉一个序号,因为它的同步位SYN也为1。
(5)客户端发送TCP确认报文段:客户端收到TCP连接请求确认报文段之后,向服务器端发送一个普通的TCP确认报文段,并进入连接已建立(ESTABLISHED)状态。
该报文段首部中的确认位ACK被设置为1,表示这是一个TCP确认报文段;序号字段取x+1,这是因为客户端在发送第一个报文段(即TCP连接请求报文段)时,该报文段只是消耗了一个序号x,所以发送第二个报文段的序号就从x+1开始(博主还有一种理解就是,之前一直说ack的值表示该序号之前的数据都已被正确接收,该值就表示下一次想要收到的初始的序号,所以第二个报文段的seq的值就是x+1);确认号字段ack为y+1,这是对服务器端所选择的初始号的确认。
注意:这是一个普通的TCP确认报文段,所以它可以携带数据,但是如果不携带数据,它也就不会消耗序号。那么客户端发送下一个报文段的seq的值仍为x+1。
服务器端收到该报文段后就会进入连接已建立状态。然后,双方就可以进行数据传输了。
总结:这里做一个简单的总结 ,对一些博主认为比较细节的东西再次进行说明。
首先就是三报文段中,前两个报文段的序号字段seq的值可以随便取,但是第三个报文段的序号字段seq的值应该是第一个报文段seq的值加1。
第二个就是分清普通确认报文段和TCP连接请求确认报文段。
普通确认报文段是可以携带数据的,但是TCP连接确认报文段不能携带数据。
普通确认报文段的首部只需把确认位ACK设为1即可,但是TCP连接请求确认报文段还要把首部中的同步位SYN设为1。
第三个就是注意报文段首部同步位SYN为1的话不能携带数据。但是会消耗掉一个序号。
三、经典问题之为什么不用“两次握手”?
首先我们需要清楚,如果是两次握手,那么服务器端就不会有进入同步已接收的状态这一过程,当它收到TCP连接请求报文段后,会在向客户端发送TCP连接请求确认报文段之后,进入连接已建立状态。如图:
如图:现在假设客户发送的TCP连接请求报文段在网络中的某处长时间停留了,这必然会引起客户端的超时重传。重传的TCP连接请求被客户端接收,客户端针对该请求发出确认,随后进入连接已建立状态,客户端收到该确认后,也进入连接已建立状态。
现在,双方可以进行数据传输了。
随后双方激情地传输数据,并潇洒地进行四次挥手释放连接,双方都进入了关闭状态。
而此时,最开始的TCP连接请求姗姗来迟。因为服务器端的被动打开的特性,服务器以为是客户端又一次发送了TCP连接请求,于是再次对其确认,并进入连接已建立状态。但实际客户端并没有发送新的TCP连接请求,并且TCP是主动打开,所以对该确认不予理会。
而客户端就一直在傻傻的等待。这样就会浪费掉很多网络资源。
综上所述,三次握手就是为了防止已失效的连接请求报文段突然又传送到了服务器端,从而导致错误。