十大企业网站排行榜,泉州网站建设咨询,湛江有没有做网站的,深圳设计总院一 tcp连接断开
每一个TCP报文的超时重传都由一个特定的内核参数来控制
① 四次握手的过程 遗留#xff1a; 谁先发送FIN包,一定是client吗? -- upload和download补充#xff1a; 主动和被动断开连接的场景 四次握手过程描述 F -- FIN -- F…一 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报文 原理图的具体过程描述
