阅读本文大概需要3分钟
大家好，我是一天都在写bug的湾湾，一个乐天派的前端开发，人称移动的表情包。
今天给大家讲一道笔试常见的面试题：说说你对三次握手的了解
一、三次握手过程
请求端（客户端）发送一个包含SYN标志的TCP报文，SYN即同步（Synchronize），同步报文会指明客户端使用的端口以及TCP连接的初始序号；
服务器在收到客户端的SYN报文后，将返回一个SYN+ACK的报文，表示客户端的请求被接受，同时TCP序号被加一，ACK即确认（Acknowledgment）。
客户端也返回一个确认报文ACK给服务器端，同样TCP序列号被加一，到此一个TCP连接完成。
二、为什么采用3次握手？
相信不少同学被问到这个问题，究竟是因为什么一定要3次握手，而不是1次握手，2次握手，甚至八九次握手呢？
这个数字3就很特别啊，这里湾湾给大家讲一个小故事，代入一下你就懂啦。
第一次通信：
男生给女生写情书??表白，为了给女生不一样的感觉，他决定使用使用寄明信片形式，可以说是独树一帜了。
第二次通信：
明信片长路漫漫终于到女生的手里了，女生感动得不行，觉得这种形式太有味道了。掏出压箱底最好看的信纸，写了一手好字寄了回去，天天等着邮局的回复，一没事就去宿舍楼下的邮件箱瞅两眼。第三次通信：
时隔多日，男生收到女生的回信了，心里开满了花，为了让女生更加心安，他又洗了一封正式确认关系的信，给他们的感情盖上了章。
从上面的小故事可以知道，采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，防止服务端端一直等待，浪费资源，从而产生错误。
二、有同学可能会问，那两次不就行了吗？为什么一定要3次这么多呀？存在这样子的情况，客户端发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了（因为网络并发量很大在某结点被阻塞了），以致延误到连接释放以后的某个时间才到达服务端。但本来这是一个早已失效的报文段，但服务端收到此失效的连接请求报文段后，就误认为是客户端再次发出的一个新的连接请求。于是就向客户端发出确认报文段，同意建立连接。这不就完蛋了吗，咱们这么聪明肯定要避免这种情况啊，所以就需要3次啦~这么说大家可能绕不过来，我继续用上面的例子给大家分析上面说的情况：女生的邮件在路上丢了，男生没有等到邮件回复，以为自己被拒绝了，悲伤欲绝把女生的联系方式都删了，躲在被窝里一句话都不想说。过了一两年终于走出来了，女生丢失的信居然到了，但这又有什么意义呢？
小提问：为什么不4次，5次呢？不是应该次数越多越好吗？是因为和3次达到效果相差不大，不浪费资源的情况下，3次刚刚好~
好啦，今天就说到这里啦，你有没有收获呢？欢迎你在后台私信我哦，咱们明天再见哦～
前期回顾：前端面试必看｜如何让div内容不可见？
超级无敌小湾娘一毛也是爱，让湾湾买糖吃吧～