• 协议-TCP协议-基础概念03-Keep live保活机制-TCP RST-TCP连接


    Keep live保活机制-TCP RST-TCP连接

    参考来源:
    极客专栏-网络排查案例课》

    Keep live保活机制

    定时发送心跳探测包;
    对于心跳回复包有超时限制;
    要打开这个 TCP Keep-alive 特性,你需要使用 setsockopt() 系统调用,对已经创建的Socket 进行配置,启用 Keep-alive。具体的调用方法,你可以参考 man setsockopt。

    在 Linux 操作系统层级,也有三个跟 Keep-alive 有关的全局配置项。

    间隔时间:net.ipv4.tcp_keepalive_time,其值默认为 7200(秒),也就是 2 个小时。

    最大探测次数:net.ipv4.tcp_keepalive_probes,在探测无响应的情况下,可以发送的最多连续探测次数,其默认值为 9(次)。

    最长间隔:net.ipv4.tcp_keepalive_intvl,在探测无响应的情况下,连续探测之间的最长间隔,其值默认为 75(秒)。

    补充:你可以在 Linux 系统里面,执行 man tcp,查看内核对 TCP 协议栈的详细文档。这里我摘录一下关于 Keep-alive 的部分:

    如果我们连接后启用了Keep-alive,但没有设定自定义的数值,那么就会便用上面这些默认值,即:当连接闲置(没有数据交互)送到7200秒(2小时)时发送心跳包,每次心跳包超时时间为75秒,最多重试9次。

    这样的话,对于一个已经失效的 TCP 连接,最大需要 7200+75*9=7875 秒(约等于 2 小时 11 分钟)才能探测到。

    毫无疑问,这个时间是相当长的。不过结合时代背景,这个其实也可以理解:TCP Keep-alive 被设计的时候是八十年代,当时因特网还很初级,所以设计者们并不想让心跳包占据太多的网络资源。从而,就有了这么一个感知时间很长的心跳机制。关于 TCP Keep-alive的一些更多信息在RFC1122里,你有兴趣的话可以去研究一下。

    长连接失效、被重置、异常关闭等问题的排查思路:
    我们需要先从应用层查找原因,然后是操作系统层面,最后是网络层分析。排查的顺序就是这样的:
    应用层代码 -> 操作系统的时间配置 -> 网络的抓包分析

    TCP RST的三类原因

    大体上,TCP RST 的原因可以分为这么几个大类:
    找不到相关连接,那么接收端可以放心地直接发送 RST。
    找到了相关连接,但收到的报文不符合 TCP 规范,那么接收端也可以发送 RST。
    找到了相关连接,但传输状况恶劣,内核选择及时“止损”,发送 RST。
    在这里插入图片描述

    TCP连接

    误区-一台机器最多 65535 个 TCP 连接

    连接是四元组,并不是单纯的源端口或者目的端口。那么多个数相乘,这个乘积当然可以远远超过 65535 了。先不谈论海量级网站的场景,就算我们维护一台 Web 服务器,假如当前有 10 万台客户端连着你,平均每个客户端跟你有 6 个连接(这很常见),那么就是 60 万个连接了,是不是也早就超过 6 万了?

    当然,在限定场景下,一个客户端(假设只有一个出口 IP)和一个服务端(假设也只有一个 IP 和一个服务端口),那么确实只能最多发起 6 万多个连接。但你自己也已经明白,这跟前面的误解,已经是两回事了。

    通信双方还真的可以同时向对方发送 SYN,也能建立起连接

    在这里插入图片描述

  • 相关阅读:
    第 4 章 串(串的堆分配存储实现)
    Java入门基础第5天Java程序的执行流程/运行过程
    Algorithm Review 2
    使用 Angular 14 的 inject 函数优化对 Ngrx 的使用方式
    基于深度学习图像特征匹配的双目测距方法
    基于SpringBoot+Vue的动漫漫画投稿网站 element
    开源深度学习模型部署工具箱MMDeploy简介及安装
    科创人·味多美CIO胡博:数字化是不流血的革命,正确答案藏在业务的田间地头
    Mybatis与Spring集成、Aop整合pagehelper插件
    HarmonyOS 4.0 实况窗上线!支付宝实现医疗场景智能提醒
  • 原文地址:https://blog.csdn.net/qinaide56/article/details/133278215