TCP三次握手四次挥手

Posted 紫魔戒

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了TCP三次握手四次挥手相关的知识,希望对你有一定的参考价值。

TCP三次握手四次挥手

标志位缩写 全称 中文
SYN synchronous 建立联机
ACK acknowledgement 确认
PSH push 传送
FIN finish 结束
RST reset 重置
URG urgent 紧急
Seq Sequence number 顺序号码
ACK Acknowledge number 确认号码
状态名称 意义
LISTEN 侦听来自远方TCP端口的连接请求
SYN-SENT 在发送连接请求后等待匹配的连接请求
SYN-RECEIVED 在收到和发送一个连接请求后等待对连接请求的确认
ESTABLISHED 代表一个打开的连接,数据可以传送给用户
FIN-WAIT-1 等待远程TCP的连接中断请求,或先前的连接中断请求的确认
FIN-WAIT-2 从远程TCP等待连接中断请求
CLOSE-WAIT 等待从本地用户发来的连接中断请求
CLOSING 等待远程TCP对连接中断的确认
LAST-ACK 等待原来发向远程TCP的连接中断请求的确认
TIME-WAIT 等待足够的时间以确保远程TCP接收到连接中断请求的确认
CLOSED 没有任何连接状态

技术分享

【注意】 在TIME_WAIT状态中,如果TCP client端最后一次发送的ACK丢失了,它将重新发送。TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。等待之后连接正式关闭,并且所有的资源(包括端口号)都被释放

根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方 socket将进入TIME_WAIT状态。TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟,即240秒。TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量的处于TIME_WAIT状态的socket, 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的socket,停止服务。

【问题】为什么连接的时候是三次握手,不是两次呢?

??现假定出现一种异常情况,即A发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间滞留了,以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后,就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段,同意建立连接。假定不采用三次握手,那么只要B发出确认,新连接就建立了。
??由于现在A并没有发出建立连接的请求,因此不会理睬B的确认,也不会向B发送数据。但B却以为新的运输连接已经建立了,并一直等待A发来数据,B的许多资源就这样白白浪费了。

【问题】关闭的时候却是四次握手?

答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。
??关闭连接时,当收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,乙方也未必全部数据都发送给对方了,所以乙方可以立即close,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,乙方ACK和FIN一般都会分开发送。

【问题】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

【问题】主动发起关闭连接的操作的一方将达到TIME_WAIT状态,而且这个状态要保持Maximum Segment Lifetime的两倍时间。为什么要这样做而不是直接进入CLOSED状态?

1.保证TCP协议的全双工连接能够可靠关闭

如果Client直接CLOSED了,那么由于IP协议的不可靠性或者是其它网络原因,导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN,此时由于Client已经CLOSED了,就找不到与重发的FIN对应的连接,最后Server就会收到RST而不是ACK,Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失,但是却导致TCP协议不符合可靠连接的要求。所以,Client不是直接进入CLOSED,而是要保持TIME_WAIT,当再次收到FIN的时候,能够保证对方收到ACK,最后正确的关闭连接。

2.保证这次连接的重复数据段从网络中消失

如果Client直接CLOSED,然后又再向Server发起一个新连接,我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题,但是还是有特殊情况出现:假设新连接和已经关闭的老连接端口号是一样的,如果前一次连接的某些数据仍然滞留在网络中,这些延迟数据在建立新连接之后才到达Server,由于新连接和老连接的端口号是一样的,又因为TCP协议判断不同连接的依据是socket pair,于是,TCP协议就认为那个延迟的数据是属于新连接的,这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL,这样可以保证本次连接的所有数据都从网络中消失。

SYN攻击:

??在三次握手过程中,Server发送SYN-ACK之后,收到Client的ACK之前的TCP连接称为半连接(half-open connect),此时Server处于SYN_RCVD状态,当收到ACK后,Server转入ESTABLISHED状态。
??SYN攻击就是Client在短时间内伪造大量不存在的IP地址,并向Server不断地发送SYN包,Server回复确认包,并等待Client的确认,由于源地址是不存在的,因此,Server需要不断重发直至超时,这些伪造的SYN包将长时间占用未连接队列,导致正常的SYN请求因为队列满而被丢弃,从而引起网络堵塞甚至系统瘫痪。
??SYN攻击时一种典型的DDOS攻击,检测SYN攻击的方式非常简单,即当Server上有大量半连接状态且源IP地址是随机的,则可以断定遭到SYN攻击了,使用如下命令可以让之现行:
#netstat -nap | grep SYN_RECV

技术分享

http://www.frankyang.cn/2017/08/23/tcp-san-ci-wo-shou-si-ci-hui-shou/






以上是关于TCP三次握手四次挥手的主要内容,如果未能解决你的问题,请参考以下文章

一文搞懂TCP的三次握手和四次挥手

TCP三次握手与四次挥手

TCP的三次握手和四次挥手

tcp 三次握手,四次挥手

TCP报文与三次握手四次挥手TCP报文与三次握手四次挥手

网络 之 三次握手&四次挥手 介绍