TCP/IP(八)TCP的连接管理(五)四次握手

bash 复制代码

每一个TCP报文的'超时重传'都由一个'特定的内核参数'来控制

① 四次握手的过程

bash 复制代码

遗留： 谁先发送'FIN'包,一定是'client'吗?  --> 'upload'和'download'

补充： '主动'和'被动'断开连接的场景

bash 复制代码

+++++++++++ "四次握手过程描述" +++++++++++

F  --> 'FIN'  --> 'Finish'

关注： 发送'报文'后,发送方所处的'TCP'状态

四次挥手对应'4'个报文

+++++++++++++++ "正常四次挥手TCP状态变迁" +++++++++++++++

client: ESTABLISHED --> FIN-WAIT-1 --> FIN-WAIT-2 --> TIME-WAIT  --> CLOSE

server: ESTABLISHED --> CLOSE-WAIT --> LAST-ACK   --> CLOSE

补充： 处于不同'TCP'状态的时间取决于丢包下'重试'的次数

② 为什么挥手需要四次

TCP三次握手

bash 复制代码

特殊'三次'挥手： 把 '第二次' 的 ack报文方在 '第三次'fin报文一起发送

二四次挥手报文丢失探究

bash 复制代码

明确： 通信哪一方'关闭'连接

① 第一次挥手丢失

bash 复制代码

关键： 客户端迟迟'收不到'被动方的 ACK 的话,也就会'触发'超时重传机制,重传 'FIN' 报文

内核参数： tcp_orphan_retries

参数含义： 如果一直都'收不到针对FIN的ACK',那么在彻底销毁这个FIN_WAIT1的连接前,等待几轮RTO

/proc/sys/net/ipv4/tcp_orphan_retries   --> 'Centos7.7' 默认是 0

bash 复制代码

案例： 假设 'tcp_orphan_retries = 3',当第'一'次挥手'一直丢失'时,发生的'过程图'

思考： 这种'算'异常断开连接吗? --> 这种和'正常的四次挥手'断开连接的区别?

强调： TCP'每一次超时',都会对下一次超时时间进行'指数退避'

bash 复制代码

原理图的具体'过程'描述

② 第二次挥手丢失了,会发生什么?

bash 复制代码

备注： 第二次'握手'是server端发起的'ACK'确认包

强调： 第'一、二'次握手'客户端感知'的都是'没有'收到服务端的'ACK'包

 1、第'一'次是客户端发起的'FIN'包丢失,导致服务端'没有'收到FIN包,服务端更不可能发送'ACK'包

 2、第'二'次是客户端发起的'FIN'包到服务端,服务端回的'ACK'包丢失,导致客户端'没有'收到ACK包

bash 复制代码

案例： 假设 'tcp_orphan_retries 参数值为 2',当第'二'次'一直丢失'时,发生的'过程图'

ACK 报文 '不会重传',所以重传 'FIN' 报文

client: ESTABLISHED --> FIN-WAIT-1  --> CLOSE

bash 复制代码

原理图的具体'过程'描述

③ 第二次握手和第三次握手间隔

bash 复制代码

/proc/sys/net/ipv4/tcp_fin_timeout --> 缺省值是'60秒' --> 控制'FIN_WAIT2'状态时间

重点： 'tcp_fin_timeout' 可以控制'close'关闭连接,但是'无法'控制'shutdown'关闭的连接

bash 复制代码

1、client 调用 'close函数' 图谱

调用 close 关闭的连接,如果在 60 秒后还没有收到'服务端的FIN' 报文,客户端连接就会直接关闭

bash 复制代码

2、client 调用 'shutdowne函数' 图谱

④ 第三次挥手丢失了,会发生什么?

bash 复制代码

案例： 假设 'tcp_orphan_retries 参数值为 3',当第'三'次'一直丢失'时,发生的'过程图'

bash 复制代码

重传： 客户端'重传'第'三'次握手的'FIN 报文'

⑤ 第四次挥手丢失了,会发生什么?

bash 复制代码

案例： 假设 'tcp_orphan_retries 参数值为 2',当第'四'次'一直丢失'时,发生的'过程图'

细节： 'ACK'报文丢失,不会重传'ACK'报文,而是重传上次的'FIN'报文

bash 复制代码

原理图的具体'过程'描述