第8章 传输层(7)_TCP连接管理

时间:2024-01-17 10:07:02

7. TCP连接管理

7.1 TCP的连接建立

(1)三次握手

第8章 传输层(7)_TCP连接管理

  ①三次握手过程

    A.第1、2次握手,数据包的SYN均为1,表示用于同步。即第1次客户端发起请求,并将自己的连接参数(如接收窗口大小、MSS和是否支持SACK等)告知服务器。第2次连接是服务器收到连接请求后作出确认,同时其自己的连接参数告知客户端,这主要是出于双向通信的需要)。因此SYN=1表示,这两个数据包主要用于协商和同步通信双方的连接参数)。ACK=1表示是一个确认包。ack表示确认的数据包序号。

    B.第3次握手用于告知客户端服务器端收到确认,可以正式开始通信。

  ②TCP连接状态(查看的命令:netstat -an

    A.服务器启用后,会进入LISTEN状态,监听客户端连接。

    B.当客户端发出连接请求后进入SYN-SEND状态。服务器收到请求后进入SYN-RCVD状态,然后发一个确认包给客户端。

    C.客户端收到确认包以后,创建TCP连接并进入ESTABLISHED状态,同时通知服务器己收到确认包。

    D.服务器收到客户端和通知后,也创建TCP连接并进入ESTABLISHED,于是双方TCP连接建立完成,可以正式通信。

(2)为什么需要三次握手?防止失效的连接请求突然又到达服务器!

第8章 传输层(7)_TCP连接管理

  ①场景假设:客户端发出的第1次连接请求,由于网络延时的原因直至客户端连接超时,该请求还未到达服务器端。因此,这个连接请求在客户端这里就会被作废。于是发送第2个连接请求。

  ②如果只采用两次握手

    A.当服务器收到第2次的连接请求后,会发送确认告诉客户端己收到请求。由于采用的是两次连接,此时就会创建一个新的Socket来服务客户端

    B.客户端收到服务端的确认后,也创建与服务器通信的TCP连接。于是双方可以正式通信了。

    C.当双方TCP连接建立起来以后。突起那个在网络上延时的第1个连接请求到达了服务器。服务器收到这个连接请求后,由于两次握手机制依然会创建一个用来服务客户端的TCP连接,并发一个确认给客户端。但由于第1次连接请求在客户端看来己失效,相当于客户端会认为我并没有发出连接请求,而服务器莫名其妙地发一个确认给自己,因此就会直接丢弃这个确认包。但对于服务端来讲,连接己经建立了,可以正常通信。就会一直在那等着客户端给自己发数据,这对服务器来说是一种严重的资源浪费。

  ③如果采用三次握手主要分析这个延时的请求会被如何处理?因为第2次连接请求是正常的TCP通信的过程!)

    A.第1次连接请求(在网络上被延时)突然到达服务器(第一次握手)。

    B.服务器并不马上建立TCP连接,而是通知客户端收到了该请求。(第二次握手)

    C.当客户端收到这个“确认”以后,由于第1次连接请求在客户端看来己经失效,所以会认为自己并没有发出连接请求,就会直接丢弃这个“确认包”。服务器由于没有收到对“确认的确认”就不会为客户端创建TCP连接,这可以防止服务端资源的浪费。

7.2 TCP连接释放

(1)四次挥手过程

第8章 传输层(7)_TCP连接管理

  ①第1次挥手:客户端(也可以是服务端)主动向服务端发送一个FIN报文段,然后进入FIN_WAIT_1状态。此FIN报文段的意思表示客户端需要发送的用户数据己发送完毕,不再有用户数据需要发送给服务器了。这时的TCP处于半关闭状态,即只有一方向另一方发送用户数据。

  ②第2次挥手:服务器收到客户端发送的FIN报文段,通知其高层的应用程序。然后发送确认给客户端,客户端收到后进入FIN_WAIT_2状态继续等待。因为服务端可能还有数据没发完,让客户端继续等服务端的通知。而服务端发送对FIN报文的确认完,会进入CLOSE-WAIT状态等待从B向A的数据传完。

  ③第3次挥手:当服务端向客户端的数据传输完以后,高层应用程序会通知TCP。然后TCP发送FIN报文给客户端通知其也没有用户数据需要传输,可以关闭连接了。同时服务器进入LAST_ACK状态。

  ④第4次挥手:客户端收到服务器发送的FIN报文,向服务器发送ACK报文,然后客户端进入TIME_WAIT状态。服务器收到客户端的ACK报文段后,就关闭连接。此时,客户端等待2MSL(2倍的最长报文段时间)后就关闭连接了。

(3)为什么客户端在TIME-WAIT状态必须等待2MSL的时间?

  保证A发送的最后一个ACK报文段能够到达B。这个ACK报文可能丢失,因而B可能在超时以后重传这个FIN+ACK报文给A,而A就能在2MSL时间内收到这个重传的FIN+ACK报文。接着A重传一次确认,并重启2MSL计时器。如果A在TIME-WAIT不等待一段时间,而是在发送完ACK后立即释放连接,那么就无法收到B重传的FIN+ACK报文从而导致B不能按正常步骤进入CLOSED状态。

(4)保活器计时(Keepalive Timer)

  ①如果客户端突然出现故障,这时并没有机会通知服务器。为防止服务器无谓地等下去。就需要用保活计时器。

  ②服务器在每收到一次客户端发来的数据,就重置保活计时器(通常是2小时)。若在规定的时间内没有收到客户的数据服务器就会发送一个探测报文段,以后每隔(75秒)发一次,如果一连发送10个探测报文仍无客户的响应。就认为客户端出了故障,接着就关闭连接。

7.3 实战:查看TCP连接/释放的数据包

(1)抓包分析TCP连接过程的数据包(以客户端给服务器的第1个数据包为例)

第8章 传输层(7)_TCP连接管理

  ①第1次握手的数据包:seq=x(0),SYN=1,ACK= 0,ack= y(0)(在此次中该值无效),以及一些协商参数(如客户端的接收窗口大小,TCP选项部分包含了最大报文段长度(MSS)、是否支持选择确认)

  ②第2次握手的数据包:seq=y(0),SYN=1,ACK=1(表示是一个确认包),ack=x+1(1)以及为了支持双向通信的一些协商参数(如服务端的接收窗口、MSS、是否支持SACK等)

  ③第3次握手的数据包:seq=x+1(1),SYN=0,ACK=1,ack=y+1(1)

(2)抓包分析TCP释放过程的数据包

第8章 传输层(7)_TCP连接管理

  ①释放数据包的TCP首部有FIN标志。②可在命令行中通过netstat –n查看TCP活动的连接及状态

7.4 实战:SYN和LAND攻击

(1)SYN攻击

第8章 传输层(7)_TCP连接管理

  ①在A计算机上安装SYN攻击器软件。该软件会向B发送TCP连接请求。

  ②但由于SYN伪造了一个TCP请求报文,将源地址改为其他的主机地址(假设是x)。这将导致B计算机把对连接请求的确认报文给x计算机。

  ③由于x计算机根据没有向B机请求连接,因此会直接丢弃数据包。但B并不知道会一些等待x机的确认,以便完成TCP连接。如果A大量发送这样的TCP请求,无疑将造成B计算机资源的极大浪费(见抓包图)

第8章 传输层(7)_TCP连接管理

(2)LAND攻击

第8章 传输层(7)_TCP连接管理

  ①与SYN攻击类似,LAND将一个TCP请求报文中的源地址改成目标主机地址

  ②这样会导致B计算机在收到请求报文后又给自己发了一个确认包。这个攻击比SYN攻击更利害,可能会直接导致B的崩溃。