码迷,mamicode.com
首页 > 其他好文 > 详细

【协议森林】TCP三次握手和SYN***

时间:2020-11-23 12:27:28      阅读:6      评论:0      收藏:0      [点我收藏+]

标签:学习   释放   分布式   实践   coding   生产   mic   web   知乎   

在日常分析和定位生产环境的问题时,经常会碰到各种各样的网络问题,查看应用监听端口上连接的数量、各种状态的连接数量分布成为常用的手段之一。但一些同学看不懂使用netstat过滤出来的各种状态是什么含义以及各种状态的连接数量分布可能存在什么问题。

其实只要弄懂了TCP/IP建立连接(即三次握手)和关闭连接(即四次挥手),上面的问题迎刃而解。这也是为什么TCP三次握手四次挥手是面试中出现频率最高的问题之一,见服务器后台开发面试题总结(请戳我)。这篇文章主要就来总结下三次握手及其三次握手可能带来的一个问题---SYN***。

TCP三次握手过程

下面是TCP三次握手的示意图,基本上讲TCP三次握手的文章都会拿下面这幅图来讲解,这里也不例外。
技术图片
第一次握手:client首先发送SYN(Synchronization)报文给server,此时,client进入SYN_SENT状态,等待server端确认;注:SYN报文的特点:SYN标识位置1,随机产生一个值seq=X,占用一个序列号。

第二次握手:server收到client发过来的SYN包后知道client请求建立连接,将产生一个SYN+ACK包发送给client以确认连接请求,此时server进入SYN_RCVD状态;注:SYN+ACK包的特点:SYN和ACK标识位都为1,ack=X+1,随机产生的seq=Y。

第三次握手:client收到server的SYN+ACK包,向server发送确认包ACK(ack=Y+1),此包发送完毕,client和server进入ESTABLISHED(TCP连接成功)状态,完成三次握手。

完成三次握手,客户端与服务器开始传送数据,其实在第三次握手的同时,client就可以向sever发送数据了。

为什么是三次握手

关于三次握手的目的,谢希仁的《计算机网络》中这么说“为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误”。

“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。

假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。”

如果上面的解释太学术化了,还是有点蒙,没关系,看点生动形象点的东西吧(来自知乎网友的一个回答)。
三次握手
A:“喂,你听得到吗?”
B:“我听得到呀,你听得到我吗?”
A:“我能听到你”,今天blabla.....

三次握手正常建立连接

两次握手
A:“喂,你听得到吗?”
B:“我听得到呀”
A:“喂,你听得到吗?” ----问题:A有可能没听到B的回答
B:“草,我听得到呀!!!!”
A:“你TM能不能听到我讲话啊!!喂!”

两次握手不能保证成功率

四次握手
A:“喂,你听得到吗?”
B:“我听得到呀,你听得到我吗?”
A:“我能听到你
B:你能听到我吗? ----问题:这次完全是没必要的
A:“……不想跟傻逼说话”

四次握手纯粹是浪费资源

SYN***

如果理解了TCP三次握手的原理,再来理解SYN***相信不是什么难事了。下面来看看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***了
技术图片

推荐阅读:

精心整理 | 2017下半年文章目录
神经网络浅讲:从神经元到深度学习(一)
互联网协议入门(一)
亿级Web 系统的容错性实践【下】
分布式缓存---Memcached

专注服务器后台技术栈知识总结分享

欢迎关注交流共同进步

技术图片

码农有道 coding

码农有道,为您提供通俗易懂的技术文章,让技术变的更简单!

【协议森林】TCP三次握手和SYN***

标签:学习   释放   分布式   实践   coding   生产   mic   web   知乎   

原文地址:https://blog.51cto.com/15006953/2552045

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!