TCP 握手没成功怎么办?
大家好,我是小林。
之前收到个读者的问题,对于 TCP 三次握手和四次挥手的一些疑问:
第一次握手,如果客户端发送的SYN一直都传不到被服务器,那么客户端是一直重发SYN到永久吗?客户端停止重发SYN的时机是什么?
第三次握手,如果服务器永远不会收到ACK,服务器就永远都留在 Syn-Recv 状态了吗?退出此状态的时机是什么?
第三次挥手,如果客户端永远收不到 FIN,ACK,客户端永远停留在 Fin-Wait-2状态了吗?退出此状态时机是什么时候呢?
第四次挥手,如果服务器永远收不到 ACK,服务器永远停留在 Last-Ack 状态了吗?退出此状态的时机是什么呢?
如果客户端 在 2SML内依旧没收到 FIN,ACK,会关闭链接吗?服务器那边怎么办呢,是怎么关闭链接的呢?
可以看到,这些问题都是关于 TCP 是如何处理这些异常场景的,我们在学 TCP 连接建立和断开的时候,总是以为这些过程能如期完成。
可惜理想很丰满,现实很骨感,事实预料呀。
TCP 当然不傻,对以上这些异常场景都是有做处理的。
这次就针对读者问的这一系列问题,来详细说说 TCP 是怎么处理这些异常的?
这些异常场景共分为两大类,第一类是 TCP 三次握手期间的异常,第二类是 TCP 四次挥手期间的异常。
TCP 三次握手期间的异常
我们先来看看 TCP 三次握手的过程。
第一次握手丢失了,会发生什么?
当客户端想和服务端建立 TCP 连接的时候,首先第一个发的就是 SYN 报文,然后进入到 SYN_SENT
状态。
在这之后,如果客户端迟迟收不到服务端的 SYN-ACK 报文(第二次握手),就会触发超时重传机制。
不同版本的操作系统可能超时时间不同,有的 1 秒的,也有 3 秒的,这个超时时间是写死在内核里的,如果想要更改则需要重新编译内核,比较麻烦。
当客户端在 1 秒后没收到服务端的 SYN-ACK 报文后,客户端就会重发 SYN 报文,那到底重发几次呢?
在 Linux 里,客户端的 SYN 报文最大重传次数由 tcp_syn_retries
内核参数控制,这个参数是可以自定义的,默认值一般是 5。
通常,第一次超时重传是在 1 秒后,第二次超时重传是在 2 秒,第三次超时重传是在 4 秒后,第四次超时重传是在 8 秒后,第五次是在超时重传 16 秒后。没错,每次超时的时间是上一次的 2 倍。
当第五次超时重传后,会继续等待 32 秒,如果服务端仍然没有回应 ACK,客户端就不再发送 SYN 包,然后断开 TCP 连接。
所以,总耗时是 1+2+4+8+16+32=63 秒,大约 1 分钟左右。
第二次握手丢失了,会发生什么?
当服务端收到客户端的第一次握手后,就会回 SYN-ACK 报文给客户端,这个就是第二次握手,此时服务端会进入 SYN_RCVD
状态。
第二次握手的 SYN-ACK
报文其实有两个目的 :
- 第二次握手里的 ACK, 是对第一次握手的确认报文;
- 第二次握手里的 SYN,是服务端发起建立 TCP 连接的报文;
所以,如果第二次握手丢了,就会发送比较有意思的事情,具体会怎么样呢?
因为第二次握手报文里是包含对客户端的第一次握手的 ACK 确认报文,所以,如果客户端迟迟没有收到第二次握手,那么客户端就觉得可能自己的 SYN 报文(第一次握手)丢失了,于是客户端就会触发超时重传机制,重传 SYN 报文。
然后,因为第二次握手中包含服务端的 SYN 报文,所以当客户端收到后,需要给服务端发送 ACK 确认报文(第三次握手),服务端才会认为该 SYN 报文被客户端收到了。
那么,如果第二次握手丢失了,服务端就收不到第三次握手,于是服务端这边会触发超时重传机制,重传 SYN-ACK 报文。
在 Linux 下,SYN-ACK 报文的最大重传次数由 tcp_synack_retries
内核参数决定,默认值是 5。
因此,当第二次握手丢失了,客户端和服务端都会重传:
- 客户端会重传 SYN 报文,也就是第一次握手,最大重传次数由
tcp_syn_retries
内核参数决定。; - 服务端会重传 SYN-AKC 报文,也就是第二次握手,最大重传次数由
tcp_synack_retries
内核参数决定。
第三次握手丢失了,会发生什么?
客户端收到服务端的 SYN-ACK 报文后,就会给服务端回一个 ACK 报文,也就是第三次握手,此时客户端状态进入到 ESTABLISH
状态。
因为这个第三次握手的 ACK 是对第二次握手的 SYN 的确认报文,所以当第三次握手丢失了,如果服务端那一方迟迟收不到这个确认报文,就会触发超时重传机制,重传 SYN-ACK 报文,直到收到第三次握手,或者达到最大重传次数。
注意,ACK 报文是不会有重传的,当 ACK 丢失了,就由对方重传对应的报文。
TCP 四次挥手期间的异常
我们再来看看 TCP 四次挥手的过程。
第一次挥手丢失了,会发生什么?
当客户端(主动关闭方)调用 close 函数后,就会向服务端发送 FIN 报文,试图与服务端断开连接,此时客户端的连接进入到 FIN_WAIT_1
状态。
正常情况下,如果能及时收到服务端(被动关闭方)的 ACK,则会很快变为 FIN_WAIT2
状态。
如果第一次挥手丢失了,那么客户端迟迟收不到被动方的 ACK 的话,也就会触发超时重传机制,重传 FIN 报文,重发次数由 tcp_orphan_retries
参数控制。
当客户端重传 FIN 报文的次数超过 tcp_orphan_retries
后,就不再发送 FIN 报文,直接进入到 close
状态。
第二次挥手丢失了,会发生什么?
当服务端收到客户端的第一次挥手后,就会先回一个 ACK 确认报文,此时服务端的连接进入到 CLOSE_WAIT
状态。
在前面我们也提了,ACK 报文是不会重传的,所以如果服务端的第二次挥手丢失了,客户端就会触发超时重传机制,重传 FIN 报文,直到收到服务端的第二次挥手,或者达到最大的重传次数。
这里提一下,当客户端收到第二次挥手,也就是收到服务端发送的 ACK 报文后,客户端就会处于 FIN_WAIT2
状态,在这个状态需要等服务端发送第三次挥手,也就是服务端的 FIN 报文。
对于 close 函数关闭的连接,由于无法再发送和接收数据,所以FIN_WAIT2
状态不可以持续太久,而 tcp_fin_timeout
控制了这个状态下连接的持续时长,默认值是 60 秒。
这意味着对于调用 close 关闭的连接,如果在 60 秒后还没有收到 FIN 报文,客户端(主动关闭方)的连接就会直接关闭。
第三次挥手丢失了,会发生什么?
当服务端(被动关闭方)收到客户端(主动关闭方)的 FIN 报文后,内核会自动回复 ACK,同时连接处于 CLOSE_WAIT
状态,顾名思义,它表示等待应用进程调用 close 函数关闭连接。
此时,内核是没有权利替代进程关闭连接,必须由进程主动调用 close 函数来触发服务端发送 FIN 报文。
服务端处于 CLOSE_WAIT 状态时,调用了 close 函数,内核就会发出 FIN 报文,同时连接进入 LAST_ACK 状态,等待客户端返回 ACK 来确认连接关闭。
如果迟迟收不到这个 ACK,服务端就会重发 FIN 报文,重发次数仍然由 tcp_orphan_retrie
s 参数控制,这与客户端重发 FIN 报文的重传次数控制方式是一样的。
第四次挥手丢失了,会发生什么?
当客户端收到服务端的第三次挥手的 FIN 报文后,就会回 ACK 报文,也就是第四次挥手,此时客户端连接进入 TIME_WAIT
状态。
在 Linux 系统,TIME_WAIT 状态会持续 60 秒后才会进入关闭状态。
然后,服务端(被动关闭方)没有收到 ACK 报文前,还是处于 LAST_ACK 状态。
如果第四次挥手的 ACK 报文没有到达服务端,服务端就会重发 FIN 报文,重发次数仍然由前面介绍过的 tcp_orphan_retries
参数控制。
是吧,TCP 聪明着很!
TCP 握手没成功怎么办?相关推荐
- TCP握手没成功怎么办
TCP三次握手期间异常 第一次握手丢失,会发生什么? 当客户端想和服务端建立TCP连接的时候,首先第一个发的就是SYN报文,然后进入SYN_SENT状态. 在这之后,如果客户端迟迟收不到服务端的SYN ...
- 内网PC通过NAT server公网地址访问内部服务器时TCP三次握手不成功
公网地址访问内部服务器时TCP三次握手不成功 一. 背景 在上图所示的网络中,PC 及Server属不同LAN,都是zone trust.为了让Internet用户能够访问到Server,FW上 ...
- 当连接一个 IP 不存在的主机时,TCP握手过程是怎样的?
最近前同事去字节跳动面试,被问到了下面这个问题: 连接一个 IP 不存在的主机时,握手过程是怎样的? 连接一个 IP 地址存在但端口号不存在的主机时,握手过程又是怎样的呢? 这让我回想起曾经也被面试官 ...
- tcp_tw_recycle引起的TCP握手失败
背景 测试环境的一台Nginx服务器,最近一直被前端同事吐槽网络有问题,经常出现访问HTTP请求时超时,哪怕是静态文件也经常超时. 刚开始以为是公司网络抽风了,也就没放在心上,但持续了一个星期,而且复 ...
- 【计算机网络】 0、各网络命令 + tcpdump + Wireshark、抓包实战、TCP 握手挥手、防火墙、保活、MTU
文章目录 一.各层网络工具 应用层 找到服务器的 IP 查接口.对象的耗时 删除指定网站的Cookie 表示层.会话层 tcpdump.wireshard 传输层 telnet: 路径可达性测试 nc ...
- 万字长文带图,从密码学到TCP握手:HTTPS如何保证安全?
深究HTTP系列 八千字长文详细图解:从输入URL到浏览器显示页面到底发生了什么? HTTPS为什么安全? 文章目录 深究HTTP系列 HTTPS为什么安全? 前言 一.HTTPS是什么? 二.HTT ...
- 抓包分析 TCP 握手和挥手
前言 首先需要明确的是 TCP 是一个可靠传输协议,它的所有特点最终都是为了这个可靠传输服务.在网上看到过很多文章讲 TCP 连接的三次握手和断开连接的四次挥手,但是都太过于理论,看完感觉总是似懂非懂 ...
- 【SRE笔记 2022.9.21 网络及TCP握手】
SRE笔记 2022.9.21 TCP握手 AAA ARP协议 功能 网络发展历程 中继器 集线器(hub) 工作模式 冲突域 网桥 广播风暴 交换机的特点和作用 路由器 路由软件 经典三类网络拓扑 ...
- 【计算机网络】TCP握手详情
[TCP三次握手过程] 1.第一次握手:客户端将标志位SYN置为1,随机产生一个序列号seq=x,并将该数据包发送给服务端,客户端进入syn_sent状态,等待服务器确认 2.第二次握手:服务端收到数 ...
- TCP 握手和挥手图解(有限状态机)
1.引言 TCP 这段看过好几遍,老是记不住,没办法找工作涉及到网络编程这块,各种问 TCP .今天好好整理一下握手和挥手过程.献给跟我一样忙碌,找工作的童鞋,欢迎大神批评指正. 2.TCP 的连接建 ...
最新文章
- 数据密集型应用系统设计 [Designing Data-Intensive Applications]
- winpcapp配置c++网口通讯_MES、SCADA项目中的数据采集—基于C#与研华IO模块ModbusTCP通讯...
- 数据库中id类型和varchar类型的区别
- Spring整合web开发
- mybatis 注解传入 list 集合​​​​​​​
- php域运算符号,PHP中的域运算符号是()。
- 144Hz和60Hz显示器差别很大吗?
- 爆炸性环境设备通用要求标准_防爆电气设备的适用环境及温度要求
- scipy.sparse、pandas.sparse、sklearn稀疏矩阵的使用
- php 压缩及解压文件,php zip文件的解压与压缩
- MSSQL表别名使用注意事项
- Kafka学习笔记之Kafka三款监控工具
- Java完全自学手册pdf,由浅入深,循序渐进(1)
- Windows游戏加速外挂-变速齿轮 学习笔记-【第一篇】
- 千万千万不可运行的 Linux 命令
- 程序员可选择的个博客论坛网站
- 学习 RestTemplate 一篇文章就够了 !!!
- CSS中margin属性详解
- 飞鸽传书——CRM短信平台
- 配置ubuntu20.04 LTS深度学习工作站教程
热门文章
- 吴恩达预热新课!万字回顾机器学习!
- python自动玩游戏_python学习:(2)自动玩2048游戏
- Ubuntu18.04安装Pangolin0.6
- 项目系统设计和数据库设计(追光的人)
- 项目Beta冲刺(5/7)(追光的人)(2019.5.27)
- 笔记本计算机提升性能,笔记本电脑改装!轻松提升电脑性能!
- 推荐一个专利检索的网站
- “一流的科研成果一定是自己研制的仪器做出来的” – 中国科大LB膜实验室的日子...
- 计算机控制技术第二章,微型计算机控制技术 赖寿宏版 课件 第二章.ppt
- win10下装python