程序员成长之旅 ——三次握手四次挥手

程序员成长之旅 ——三次握手四次挥手

三次握手

概述

首先Client端发送连接请求报文,Server段接受连接后回复ACK报文,并为这次连接 分配资源。Client端接收到ACK报文后也向Server段发生ACK报文,并分配资源,这样TCP连接就建立了。也就是在二次握手的时候服务端就已经分配了资源,而三次握手,客户端才会分配资源。

在这里插入图片描述

最初两端的TCP进程都处于close关闭状态,A主动发送连接,而B被动打开连接。
(A、B关闭状态CLOSED–B收听状态LISTEN–A同步已发送状态SYN-SENT–B同步收到状态SYN-RCVD–A、B连接已建立状态ESTABLISHED)

三次握手的总结
起初A和B都处于CLOSED状态——B创建TCB,处于LISTEN状态,等待A请求

  • (第一次握手)A创建TCB,发送连接请求(SYN=1,seq=x),进入SYN-SENT状态
  • (第二次握手)B收到连接请求,向A发送确认(SYN=ACK=1,确认号ack=x+1,初始序号seq=y),进入SYN-RCVD状态
  • (第三次握手)A收到B的确认后,给B发出确认(ACK=1,ack=y+1,seq=x+1),A进入ESTABLISHED状态
  • B收到A的确认后,进入ESTABLISHED状态。

三次握手的常见问题
1.为什么A还要发送一次确认呢?可以二次握手吗?
答:主要为了防止已失效的连接请求报文段突然又传送到了B,因而产生错误。如A发出连接请求,但因连接请求报文丢失而未收到确认,于是A再重传一次连接请求。后来收到了确认,建立了连接。数据传输完毕后,就释放了连接,也就是A发出了两个连接请求报文段,其中第一个丢失,第二个到达了B,但是第一个丢失的报文段有可能只是在某些网络结点长时间滞留了,延误到连接释放以后的某个时间才到达B,此时B误认为A又发出一次新的连接请求,于是就向A发出确认报文段,同意建立连接,不采用三次握手,只要B发出确认,就建立新的连接了,此时A不理睬B的确认且不发送数据,则B一致等待A发送数据,浪费资源。
2.Server端易受到SYN攻击?
答:服务器端的资源分配是在二次握手时分配的,而客户端的资源是在完成三次握手时分配的,所以服务器容易受到SYN洪泛攻击,SYN攻击就是Client在短时间内伪造大量不存在的IP地址,并向Server不断地发送SYN包,Server则回复确认包,并等待Client确认,由于源地址不存在,因此Server需要不断重发直至超时,这些伪造的SYN包将长时间占用未连接队列,导致正常的SYN请求因为队列满而被丢弃,从而引起网络拥塞甚至系统瘫痪。
防范SYN攻击措施:降低主机的等待时间使主机尽快的释放半连接的占用,短时间受到某IP的重复SYN则丢弃后续请求。

四次挥手

概述

假设client(客户端)发起中断连接请求,也就是FIN报文。server(服务端)收到FIN报文,也就是知道了客户端现在没有数据要发送给我服务端了,但是这个时候也许服务端还有数据要发送,这时候就不急着关闭套接字,所以给客户端先发送一个ACK告诉客户端你的请求我收到了,但是我还没有完全准备好,这个时候客户端就处在FIN_WAIT状态;一直等待服务端发过来FIN报文为止。当服务端确定已经发送数据完成,这时候就会给客户端发一个FIN报文,表示,好了,我这边已经完成,可以关闭连接了。但是他还是不相信网络,害怕服务端不知道要关闭,所以在发送一个ACK后进入TIME_WAIT状态,如果服务端没有收到ACK则可以重传。服务端收到ACK后,就知道要关闭连接了。这时候客户端等待了2MSL后如果没有收到服务端的消息,那说明服务端已经关闭,客户端这时候也就可以关闭了。TCP连接的关闭就是这样的。

在这里插入图片描述
四次挥手的总结
刚开始A和B都处在ESTABLISHED状态

  • A发出连接释放报文段并处在FIN-WAIT-1状态
  • B发出确认收到A发出的请求并处在CLOSE-WAIT状态
  • A收到后,进入FIN-WAIT-2状态,等待B的连接释放报文段
  • B没有要发的数据了,这时候B就发送连接释放报文段并进入LAST-ACK状态
  • A发出确认报文段并进入TIME-WAIT状态
  • B收到确认后进入CLOSED状态
  • A经过等待计时器时间2MSL后,进入CLOSED状态

四次挥手的常见问题
1 为什么A在TIME-WAIT状态必须等待2MSL的时间?

MSL最长报文段寿命Maximum Segment Lifetime
两个理由:
1.防止ACK没有发送成功
这个ACK报文段有可能丢失,使得处在LAST-ACK状态下的B收不到已发送的FIN+ACK报文段确认,B超时重传FIN+ACK报文段,而A能在2MSL时间内收到这个重传的FIN+ACK报文段,接着A重传一次确认,重新启动2MSL计时器,最后A和B都进入到CLOSED状态,如若不然B可能都没有关闭。
2.防止未连接成功的报文段出现在本连接中
A在发送完最后一个ACK报文段后,再经过2MSL,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失,使下一个新的连接中不会出现这种旧的连接请求报文段。

2 为什么连接的时候是三次握手,关闭的时候却是四次握手?

因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

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

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

从零出发——

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值