手机壳在线设计网站谷歌关键词
一 tcp连接断开
每一个TCP报文的'超时重传'都由一个'特定的内核参数'来控制① 四次握手的过程
遗留： 谁先发送'FIN'包,一定是'client'吗? --> 'upload'和'download'补充： '主动'和'被动'断开连接的场景
+++++++++++ "四次握手过程描述" +++++++++++F --> 'FIN' --> 'Finish'关注： 发送'报文'后,发送方所处的'TCP'状态四次挥手对应'4'个报文+++++++++++++++ "正常四次挥手TCP状态变迁" +++++++++++++++client: ESTABLISHED --> FIN-WAIT-1 --> FIN-WAIT-2 --> TIME-WAIT --> CLOSEserver: ESTABLISHED --> CLOSE-WAIT --> LAST-ACK --> CLOSE补充： 处于不同'TCP'状态的时间取决于丢包下'重试'的次数
② 为什么挥手需要四次
TCP三次握手
特殊'三次'挥手： 把 '第二次' 的 ack报文方在 '第三次'fin报文一起发送二 四次挥手报文丢失探究
明确： 通信哪一方'关闭'连接① 第一次挥手丢失
关键： 客户端迟迟'收不到'被动方的 ACK 的话,也就会'触发'超时重传机制,重传 'FIN' 报文内核参数： tcp_orphan_retries参数含义： 如果一直都'收不到针对FIN的ACK',那么在彻底销毁这个FIN_WAIT1的连接前,等待几轮RTO/proc/sys/net/ipv4/tcp_orphan_retries --> 'Centos7.7' 默认是 0
案例： 假设 'tcp_orphan_retries = 3',当第'一'次挥手'一直丢失'时,发生的'过程图'思考： 这种'算'异常断开连接吗? --> 这种和'正常的四次挥手'断开连接的区别?
强调： TCP'每一次超时',都会对下一次超时时间进行'指数退避'
原理图的具体'过程'描述
② 第二次挥手丢失了,会发生什么?
备注： 第二次'握手'是server端发起的'ACK'确认包强调： 第'一、二'次握手'客户端感知'的都是'没有'收到服务端的'ACK'包1、第'一'次是客户端发起的'FIN'包丢失,导致服务端'没有'收到FIN包,服务端更不可能发送'ACK'包2、第'二'次是客户端发起的'FIN'包到服务端,服务端回的'ACK'包丢失,导致客户端'没有'收到ACK包
案例： 假设 'tcp_orphan_retries 参数值为 2',当第'二'次'一直丢失'时,发生的'过程图'ACK 报文 '不会重传',所以重传 'FIN' 报文client: ESTABLISHED --> FIN-WAIT-1 --> CLOSE
原理图的具体'过程'描述
③ 第二次握手和第三次握手间隔
/proc/sys/net/ipv4/tcp_fin_timeout --> 缺省值是'60秒' --> 控制'FIN_WAIT2'状态时间重点： 'tcp_fin_timeout' 可以控制'close'关闭连接,但是'无法'控制'shutdown'关闭的连接
1、client 调用 'close函数' 图谱调用 close 关闭的连接,如果在 60 秒后还没有收到'服务端的FIN' 报文,客户端连接就会直接关闭
2、client 调用 'shutdowne函数' 图谱
④ 第三次挥手丢失了,会发生什么?
案例： 假设 'tcp_orphan_retries 参数值为 3',当第'三'次'一直丢失'时,发生的'过程图'
重传： 客户端'重传'第'三'次握手的'FIN 报文'
⑤ 第四次挥手丢失了,会发生什么?
案例： 假设 'tcp_orphan_retries 参数值为 2',当第'四'次'一直丢失'时,发生的'过程图'细节： 'ACK'报文丢失,不会重传'ACK'报文,而是重传上次的'FIN'报文
原理图的具体'过程'描述