TCP三次握手与四次挥手

三次握手

什么是三次握手?

其实就是TCP通过三次握手建立链接,在建立过程中一共要发送3个包,所以称为三次握手。主要就是确定双方的发送能力、接受能力是否正常,并且为后续的可靠性传输定义序列号。
刚开始的时候,客户端是Closed状态,服务端是Listen状态。

  • 第一次握手,客户端向服务端发送一个SYN报文,并且指定ISN初始化序列号。
  • 第二次握手,服务端接受SYN报文后,会把接受的ISN+1作为ACK返回给客户端。并且也会发送自己的SYN报文来指定服务端的ISN序列号。
  • 第三次握手,客户端接收服务端的SYN报文后,会将服务端ISN+1作为ACK返回给服务端。此时客户端就认为链接建立完成,而服务端接受到ACK之后,也建立完成。
为什么是三次而不是两次握手?

三次握手可以保证服务端和客户端的发送以及接受功能都是正常的。如果只有两次的话,无法保证每次建立的链接都是可用的。
比如:客户端发送第一次握手时,发生消息延迟的情况。客户端认为消息丢失,于是再次发送第一次握手。
服务端先接受到第二次的请求,于是直接返回成功,于是建立连接。数据传输完成后断开连接。
这时候延迟的消息到了服务端,那服务端就认为这是一次新的链接,于是再次建立连接等待客户端的数据。但是客户端并不认为这是一次有效链接就不会管。那么这时候就造成了服务端的资源浪费。

三次挥手过程可以携带数据吗?

第三次挥手是可以携带数据的,但是前两次挥手不可以。
因为,如果第一次挥手就可以携带数据的话,如果有人要恶意攻击服务器,那他在第一次挥手的时候携带大量的数据,因为攻击者根本不理会服务器是否会返回数据。那么重复发送大量的SYN报文,就会占用服务器大量的资源。

SYN攻击是什么?

服务器的资源是在第二次握手的时候分配的,而客户端的资源是在第三次握手的时候才分配的,所以服务端容易受到SYN洪泛攻击。
SYN攻击就是在短时间内,Client客户端在短时间内伪造大量的IP地址,向server服务端发送第一次握手的请求SYN。server接受SYN后会回复确认包,并且等待Client的确认,因为IP是伪造的,所以无法接受到回执,于是server就会不断地发送直到超时。这些伪造的SYN包将长时间占用未连接队列,导致正常的SYN包请求因为队列阻塞而被丢弃。从而因为网络拥堵甚至系统瘫痪。SYN攻击是一种非常典型的DoS/DDoS攻击
检测SYN攻击非常简单,当发现服务器有大量半链接状态时,并且都是不一样的IP地址,就很有可能是SYN攻击。
防御方法有以下几种:

  • 缩短超时(SYN Timeout)时间
  • 增大半链接数
  • 过滤网关防护
  • SYN cookies

四次挥手

建立链接需要三次握手,而断开连接需要四次挥手

  • 客户端发送一个FIN,用来关闭客户端到服务端的链接,并且进入fin_wait_1状态
  • 服务端接受FIN后,返回一个ACK,并且将连接挂起,进入Close_wait状态半关闭状态,服务端不会再接收客户端请求了。但是客户端还会接受服务端。
  • 服务端发送一个FIN,用来关闭服务端到客户端的连接,发送后等待客户端回执。
  • 客户端接收FIN后,客户端进入Time_wait状态,之后返回一个ACK。服务端接收确认后进入Closed状态,完成四次挥手。

另外要注意Time_wait状态会等待2秒的时间,是为了保证最后一次挥手的成功。
因为2秒是一个报文的最大生存时间,如果2秒后服务器端没有接受到ACK,那么就会再次发送FIN进行第3和4次挥手。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

木小同

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

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

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

打赏作者

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

抵扣说明:

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

余额充值