#2022争霸赛*干货满满#面试官竟然把TCP三次握手、四次挥手问的这么详细?
  

我不要凑合 29493人觉得有帮助

{{ttag.title}}
Part1TCP的定义
TCP全称为Transmission Control Protocol(传输控制协议),是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。
TCP的三次握手和四次挥手,可以说是老生常谈的经典问题了,通常也作为各大公司常见的面试考题,具有一定的水平区分度。看似简单的面试问题。如果你的回答不符合面试官期待的水准,有可能就直接凉凉了。
Part2优雅回答三次握手
三次握手: 服务端新建套接字,绑定地址信息后开始监听,进入LISTEN状态。客户端新建套接字绑定地址信息后调用connect,发送连接请求SYN,并进入SYN_SENT状态,等待服务器的确认。服务端一旦监听到连接请求,就会将连接放入内核等待队列中,并向客户端发送SYN和确认报文段ACK,进入SYN_RECD状态。客户端收到SYN+ACK报文后向服务端发送确认报文段ACK,并进入ESTABLISHED状态,开始读写数据。服务端一旦收到客户端的确认报文,就进入ESTABLISHED状态,就可以进行读写数据了
1为什么握手是三次,而不是两次或者四次?
答:两次不安全,四次没必要。tcp通信需要确保双方都具有数据收发的能力,得到ACK响应则认为对方具有数据收发的能力,因此双方都要发送SYN确保对方具有通信的能力。第一次握手是客户端发送SYN,服务端接收,服务端得出客户端的发送能力和服务端的接收能力都正常;第二次握手是服务端发送SYN+ACK,客户端接收,客户端得出客户端发送接收能力正常,服务端发送接收能力也都正常,但是此时服务器并不能确认客户端的接收能力是否正常;第三次握手客户端发送ACK,服务器接收,服务端才能得出客户端发送接收能力正常,服务端自己发送接收能力也都正常。
2三次握手可以携带数据吗?
答:第一次、第二次握手不可以携带数据,而第三次握手是可以携带数据的。假设第一次可以携带数据,如果有人恶意攻击服务器,每次都在第一次握手中的SYN报文放入大量数据,重复发送大量SYN报文,此时服务器会花费大量内存空间来缓冲这些报文,服务器就更容易被攻击了
3tcp三次握手失败,服务端会如何处理?
答:握手失败的原因有两种,第一种是服务端没有收到SYN,则什么都不做;第二种是服务端回复了SYN+ACK后,长时间没有收到ACK响应,则超时后就会发送RST重置连接报文,释放资源
4ISN代表什么?意义何在?ISN是固定不变的吗?ISN为何要动态随机
答:ISN全称是Initial Sequence Number,是TCP发送方的字节数据编号的原点,告诉对方我要开始发送数据的初始化序列号。ISN如果是固定的,攻击者很容易猜出后序的确认号,为了安全起见,避免被第三方猜到从而发送伪造的RST报文,因此ISN是动态生成的
5什么是半连接队列
答:服务器第一次收到客户端的SYN之后,就会处于SYN_RECD状态,此时双方还没有完全建立连接。服务器会把这种状态下的请求连接放在一个队列里,我们把这种队列称之为半连接队列。当然还有一个全连接队列,就是已经完成三次握手,建立起来连接的就会放在全连接队列中,如果队列满了就有可能出现丢包现象
Part3优雅回答四次挥手
四次挥手:客户端主动调用close时,向服务端发送结束报文段FIN报,同时进入FIN_WAIT1状态;服务器会收到结束报文段FIN报,服务器返回确认报文段ACK并进入CLOSE_WAIT状态,此时如果服务端有数据要发送的话,客户端依然需要接收。客户端收到服务器对结束报文段的确认,就会进入到FIN_WAIT2状态,开始等待服务器的结束报文段;服务器端数据发送完毕后,当服务器真正调用close关闭连接时,会向客户端发送结束报文段FIN包,此时服务器进入LAST_ACK状态,等待最后一个ACK的带来;客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出送确认报文段ACK;服务器收到了对结束报文段确认的ACK,进入CLOSED状态,断开连接。而客户端要等待2MSL的时间,才会进入到CLOSED状态
6为什么握手是三次,而挥手时需要四次呢?
答:其实在TCP握手的时候,接收端将SYN包和ACK确认包合并到一个包中发送的,所以减少了一次包的发送。对于四次挥手,由于TCP是全双工通信,主动关闭方发送FIN请求不代表完全断开连接,只能表示主动关闭方不再发送数据了。而接收方可能还要发送数据,就不能立即关闭服务器端到客户端的数据通道,所以就不能将服务端的FIN包和对客户端的ACK包合并发送,只能先确认ACK,等服务器无需发送数据时在发送FIN包,所以四次挥手时需要四次数据包的交互
7TIME_WAIT状态有什么作用,为什么主动关闭方没有直接进入CLOSED状态释放资源?
答:如果主动关闭方进入CLOSED状态后,被动关闭方发送FIN包后没有得到ACK确认,超时后就会重传一个FIN包。如果客户端没有TIME_WAIT状态而直接进入CLOSED状态释放资源,下次启动新的客户端就可能使用了与之前客户端相同的地址信息,有两个危害,第一种是这个刚启动的新的客户端绑定地址成功时,就会收到了一个重传的FIN包,对新连接就会造成影响。第二种是如果该新客户端向相同的服务端发送SYN连接请求,但是此时服务端处于LAST_ACK状态,要求收到的是ACK而不是SYN,因此就会发送RST重新建立请求。
8为什么TIME_WAIT状态需要经过2MSL才能进入CLOASE状态?
答:MSL指的是报文在网络中最大生存时间。在客户端发送对服务端的FIN确认包ACK后,这个ACK包有可能到达不了,服务器端如果接收不到ACK包就会重新发送FIN包。所以客户端发送ACK后需要留出2MSL时间(ACK到达服务器器+服务器发送FIN重传包,一来一回)等待确认服务器端缺失收到了ACK包。也就是说客户端如果等待2MSL时间也没收到服务器端重传的FIN包,则就可以确认服务器已经收到客户端发送的ACK包
9一台主机上出现大量的TIME_WAIT是什么原因?应该如何处理?
答:TIME_WAIT是主动关闭方出现的,一台主机出现大量的TIME_WAIT证明这台主机上发起大量的主动关闭连接。常见于一些爬虫服务器。这时候我们应该调整TIME_WAIT的等待时间,或者开启套接字地址重用选项
10一台主机上出现大量的CLOSE_WAIT是什么原因?应该如何处理?
答:CLOSE_WAIT是被动关闭方收到FIN请求进行回复之后的状态,等待上层程序进一步处理,若出现大量CLOSE_WAIT,有可能是被动关闭方主机程序中忘了最后一步断开连接后调用close释放资源。这是一个 BUG.,只需要加上对应的 close 即可解决问题
11tcp连接管理中的保活机制
答:tcp通信中,若两端长时间没有数据往来,则这时候每隔一段时间,服务端会向客户端发送一个保活探测数据报,要求客户端进行回复。若连续多次没有收到响应,就认为连接已经断开。长时间默认为7200s,每隔一段时间默认为75s,连续多次无响应默认为9次。这些数据都可以在套接字中修改。

打赏鼓励作者,期待更多好文!

打赏
19人已打赏

339015 发表于 2022-10-22 03:50
  
感谢楼主分享,文章介绍了TCP连接建立与释放的原理,比较详细,期待更多分享
一个无趣的人 发表于 2022-10-22 10:28
  
楼主的文章图文并茂,清晰易懂,看完这波操作可以轻松上手了,如遇到问题再向楼主请教~
平凡的小网工 发表于 2022-10-22 10:36
  
楼主分析的很详细,不错的实战经验,小白用户一看就懂,非常好的技术干货帖,顶一个!
Mr程 发表于 2022-10-23 11:01
  
爱了爱了,大佬讲的细节牛逼
Hellos 发表于 2022-10-28 08:08
  
每天学习一点,每天进步一点!!!!!!!
技术飞 发表于 2023-1-5 17:25
  
果然是高手在民间,楼主帖子写的不错,很有参考价值,还想看更多精彩分享,期待楼主下一篇好帖!
蟲爺 发表于 2023-3-21 14:42
  
感谢分享
小鱼儿 发表于 2023-4-3 09:18
  

每天学习一点,每天进步一点!!!!!!!
日出 发表于 2023-4-3 09:18
  

每天学习一点,每天进步一点!!!!!!!
发表新帖
热门标签
全部标签>
技术盲盒
西北区每日一问
安全效果
每日一问
干货满满
新版本体验
【 社区to talk】
技术笔记
功能体验
技术咨询
产品连连看
标准化排查
2023技术争霸赛专题
GIF动图学习
信服课堂视频
每周精选
通用技术
自助服务平台操作指引
秒懂零信任
技术晨报
技术圆桌
安装部署配置
答题自测
原创分享
升级&主动服务
社区新周刊
POC测试案例
畅聊IT
专家问答
在线直播
MVP
网络基础知识
升级
安全攻防
上网策略
测试报告
日志审计
问题分析处理
流量管理
每日一记
运维工具
云计算知识
用户认证
解决方案
sangfor周刊
VPN 对接
项目案例
SANGFOR资讯
专家分享
技术顾问
信服故事
SDP百科
功能咨询
终端接入
授权
设备维护
资源访问
地址转换
虚拟机
存储
迁移
加速技术
排障笔记本
产品预警公告
玩转零信任
信服圈儿
S豆商城资讯
技术争霸赛
「智能机器人」
追光者计划
深信服技术支持平台
社区帮助指南
答题榜单公布
纪元平台
卧龙计划
华北区拉练
天逸直播
以战代练
山东区技术晨报
文档捉虫活动
齐鲁TV
华北区交付直播
2024年技术争霸赛
北京区每日一练
场景专题
故障笔记
排障那些事
高手请过招
高频问题集锦
全能先锋系列
云化安全能力

本版版主

147
113
49

发帖

粉丝

关注

121
315
352

发帖

粉丝

关注

7
20
6

发帖

粉丝

关注

5
7
7

发帖

粉丝

关注

本版达人

新手89785...

本周建议达人

七嘴八舌bar

本周分享达人

新手76619...

本周提问达人