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

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 复制代码
原理图的具体'过程'描述