TCP三次握手(建立连接)
第一次:建立连接时,客户端发送SYN请求报文包(同步位SYN=1,初始序号seq=x)到服务器,并进入SYN_SEND(同步已发送)状态,等待服务器确认;
第二次:服务器收到SYN包,向客户端返回确认报文段(SYN位、ACK位置为1,确认号ack=x+1,序号seq=y),此时服务器进入SYN_RCVD(同步收到)状态;
第三次:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(确认号ack=y+1,序号seq=x+1),此包发送完毕,客户端和服务器进入ESTABLISHED(已建立连接)状态,完成三次握手。
确认号ack:占4个字节,期待收到对方下一个报文段的第一个数据字节的序号;序列号表示报文段携带数据的第一个字节的编号;而确认号指的是期望接收到下一个字节的编号;因此当前报文段最后一个字节的编号+1即为确认号。
确认ACK:占1位,仅当ACK=1时,确认号字段才有效。ACK=0时,确认号无效
同步SYN:连接建立时用于同步序号。当SYN=1,ACK=0时表示:这是一个连接请求报文段。若同意连接,则在响应报文段中使得SYN=1,ACK=1。因此,SYN=1表示这是一个连接请求,或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1,握手完成后SYN标志位被置0。
终止FIN:用来释放一个连接。FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接
PS:ACK、SYN和FIN这些大写的单词表示标志位,其值要么是1,要么是0;ack、seq小写的单词表示序号。(https://blog.csdn.net/qq_38950316/article/details/81087809)
注意1:四报文握手:
在服务器发送给客户端确认报文段时,可以拆为两个报文段,可以先发一个确认报文段(ACK=1,ack=x+1),再发一个同步报文段(SYN=1,seq=y)
注意2:为什么要采用三次握手
防止已失效的连接请求报文段突然传到B而产生错误。
假设A发送的第一个连接请求滞留了,在过了一段时间才到达B,这时候它就是一个已失效的请求报文。但是B收到后,误以为A又发起了一次连接请求,于是发送确认报文段。
如果没有第三次握手,那么此时新连接就会建立,B会一直等待从A发来的数据,从而浪费B的资源。
TCP四次挥手(连接释放)
通信双方都可以释放连接。
-
A的应用进程向TCP发出连接释放报文段,并停止发送数据,主动关闭TCP。
A把连接释放报文段首部的终止控制位FIN置为1,序号seq=u(等于前面已传送过的数据的最后一个字节的序号加1),A进入FIN-WAIT-1(终止等待1) -
B收到连接释放报文段后发出确认,确认号ack=u+1,序号为v(B前面已传送过的数据的最后一个字节的序号加1),B进入CLOSE-WAIT(关闭等待)状态。A收到B的确认后,进入 FIN-WAIT-2(终止等待2),等待B发出连接释放报文段。
TCP服务器通知高层应用进程,从A到B方向的连接已释放,TCP处于半关闭状态。
进行B到A的数据传输
-
若B已经不需要向A传输数据,则应用进程通知TCP释放连接,B向A发送释放报文段,FIN置为1,ack = u+1,B进入LAST-ACK(最后确认状态),seq =w, 等待A的确认。
-
A收到后,进行确认,在确认报文段中ACK置1,ack = w+1,然后进入时间等待状态(此时还没有释放TCP)。必须经过2MSL(最长报文段寿命)后,A才进入到CLOSED 状态。
【问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?
答:因为当服务器端收到客户端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。
但是关闭连接时,当服务器端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,“你发的FIN报文我收到了”。只有等到我服务器端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。
【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
答:
1.保证A发送的最后一个ACK报文段能够到达B。
假设A发送的最后一个ACK丢失,则B会超时重传FIN+ACK报文段,A收到后则重传一次确认,并重启计时器。如果没有最大报文段生存时间,则A收不到B的FIN+ACK报文段,则B无法证明进入CLOSed状态。
2.防止已失效的连接请求报文段出现在本连接中。A发送最后一个ACK报文段后,等待2MSL后,则本连接所有的报文段都消失,下一次连接就不会有旧报文。
【问题3】为什么不能用两次握手进行连接?
答:3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发 送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S 是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分 组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。
【问题4】如果已经建立了连接,但是客户端突然出现故障了怎么办?
TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。