为什么需要第三次握手?
如果没有第三次握手,可能会出现如下情况:
- 如果只有两次握手,那么server收到了client的SYN=1的请求连接数据包之后,便会分配资源并且向client发送一个确认位ACK回复数据包。那么,如果在client与server建立连接的过程中,由于网络不顺畅等原因造成的通信链路中存在着残留数据包,即client向server发送的请求建立连接的数据包由于数据链路的拥塞或者质量不佳导致该连接请求数据包仍然在网络的链路中,这些残留数据包会造成如下危害
- 危害:当client与server建立连接,数据发送完毕并且关闭TCP连接之后,如果链路中的残留数据包才到达server,那么server就会认为client重新发送了一次连接申请,便会回复ACK包并且分配资源。并且一直等待client发送数据,这就会造成server的资源浪费。
第三次握手失败了怎么办?
当client与server的第三次握手失败了之后,即client发送至server的确认建立连接报文段未能到达server,server在等待client回复ACK的过程中超时了,那么server会向client发送一个RTS报文段并进入关闭状态,即:并不等待client第三次握手的ACK包重传,直接关闭连接请求,这主要是为了防止泛洪攻击,即坏人伪造许多IP向server发送连接请求,从而将server的未连接队列塞满,浪费server的资源。
为什么要四次挥手?
- 前两次挥手是为了断开client至server的连接,后两次挥手是为了断开server至client的连接,如果没有第四次挥手,会出现如下状况:
- server发送FIN数据包并携带ACK至client之后直接断开连接,如果client没有收到这个FIN数据包,那么client会一直处于等待关闭状态,这是为了确保TCP协议是面向连接安全有保证锝。
- 上面解释了为什么不是三次挥手,同理,两次挥手也是不安全的。不能保证server与client都能正确关闭连接释放资源,而不会造成资源浪费。
四次挥手之后client为什么还要等待2MSL的时间才释放资源关闭连接?
- 第一,保证客户端发送的最后一个ACK报文能够到达服务器,因为这个ACK报文可能丢失,站在服务器的角度看来,我已经发送了FIN+ACK报文请求断开了,客户端还没有给我回应,应该是我发送的请求断开报文它没有收到,于是服务器又会重新发送一次,而客户端就能在这个2MSL时间段内收到这个重传的报文,接着给出回应报文,并且会重启2MSL计时器。
- 第二,防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后,在这个2MSL时间中,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。
如果已经建立了连接,但是客户端突然出现故障了怎么办?
TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。(说明:因为tcp/ip详解年代实在是太过久远了,不知道保活计时器是否还是75秒,大家在看的时候注意一下就行)。
什么是SYN泛洪攻击
TCP SYN泛洪发生在OSI第四层,这种方式利用TCP协议的特性,就是三次握手。攻击者发送TCP SYN,SYN是TCP三次握手中的第一个数据包,而当服务器返回ACK后,该攻击者就不对其进行再确认,那这个TCP连接就处于挂起状态,也就是所谓的半连接状态,服务器收不到再确认的话,还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接,由于每一个都没法完成三次握手,所以在服务器上,这些TCP连接会因为挂起状态而消耗CPU和内存,最后服务器可能死机,就无法为正常用户提供服务了。
服务器上出现大量的TIME_WAIT状态的原因
由于主动关闭TCP连接的一方才会进入TIME_WAIT状态,一般情况服务器端不会出现TIME_WAIT状态,因为大多数情况都是客户端主动发起连接并主动关闭连接。但是某些服务如pop/smtp、ftp却是服务端收到客户端的QUIT命令后主动关闭连接,这就造成这类服务器上容易出现大量的TIME_WAIT状态的连接,而且并发量越大处于此种状态的连接越多。另外,对于被动关闭连接的服务在主动关闭客户端非法请求或清理长时间不活动的连接时(这种情况很可能是客户端程序忘记关闭连接)也会出现TIME_WAIT的状态。