• 邵亚方
    置顶
    2020-10-11
    课后作业答案： - 通过 ssh 登录到服务器上，然后把网络关掉，过几秒后再打开，请问这个 ssh 连接还正常吗？为什么？ ssh使用的TCP协议，也就是它是有连接的，这个连接对内核而言就是tcp_sock这个结构体，这个结构体会记录该TCP连接的状态，包括四元组(src_ip:src_port - dst_ip:dst_port)，该连接的路由信息也被保存着。关闭网络后，该TCP连接的这些信息都还在，如果两边没有数据交互的话，这些信息就不会被更新，也就你一直存在着，当你再次打开网络，该连接还可以正常使用；假如关闭网络后，该TCP连接有数据交互，此时就会检查到异常，同样的也会去更新TCP连接状态信息，就有可能会断开这个连接。除此之外，TCP还有keepalive机制，如果该连接长时间没有数据，keepalive机制也会把该连接给关闭掉。
    
    21
  • 我来也
    2020-09-18
    课后思考题： 这个应该是不确定的。 以前也测试过，只要在网络断开期间不主动发送数据，就会晚一点探测到连接已断开。 如果不主动发数据，可能网络恢复时，连接就自动恢复了。

    作者回复: 对的！

    共 2 条评论
    7
  • 黑客不够黑
    2020-11-07
    我们金融交易平台的生产环境出现过一个案例，每天早上9点开盘会有用户集中登录的情况，其中登录链路中有两个服务，部署在两台服务器上，事故当天就出现了很多用户无法登陆的情况，开发人员排查日志发现这两个服务之间的通信有非常大的延时，A服务发的消息，B服务过了很久才收到，时间5分钟到20分钟不等，我们运维小伙伴监控服务器的负载非常低，CPU，内存，io都很正常，甚至我们还有专门的程序每秒探测内网机器的存活，ping包每秒一次，延时也都在毫秒级别。所以当时判断可能是两个服务之间的tcp链接出了问题，我比较怀疑是接收方窗口变为0了，但苦于没有抓包无法验证猜想，并且此类事件再也没有出现，但是心里一直存在疑惑，所以想问问老师，在您看来这种情况比较可能原因有哪些？

    作者回复: 看你的描述，这类问题大概率跟TCP缓冲区有关系。A服务所在机器的发送缓冲区太小，或者B服务所在服务器的接受缓冲区太小，都会导致缓冲区排队严重，甚至引起丢包，接受窗口变为0也可能会出现。 我建议你可以适当的增加TCP缓冲区大小。 你可以通过ss -natp来看是否存在数据积压的情况。

    
    6
  • solar
    2020-10-10
    cwnd和rwnd使用的单位是什么呢？

    作者回复: TCP segment个数

    共 3 条评论
    5
  • Ilovek8s
    2021-03-14
    keepalive心跳的时间里如果不发送ssh命令操作，断开网络之后再重新打开，由于TCP有重试机制，是可以恢复的，但如果keepalive开始检查了，服务端发现客户端是死的之后就会关闭连接

    作者回复: 对的。

    
    4
  • jssfy
    2020-09-19
    引用：对此，我们使用 tcpdump 在 server 上抓包后发现，Client 响应的 ack 里经常出现 win 为 0 的情况，也就是 Client 的接收窗口为 0。于是我们就去 Client 上排查，最终发现是 Client 代码存在 bug，从而导致无法及时读取收到的数据包。 请问这里的前一句的接收窗口为0和后一句的代码bug是有什么逻辑关系吗？这里没太看懂

    作者回复: 哦 是应用被阻塞住 没有及时从缓冲区里读取数据 导致缓冲区满

    
    3
  • webmin
    2020-09-18
    要分情况： 1. 如果关闭网络是发生在Client端或Server端的机器上，那么网络恢复后连接不会正常； 2. 如果关闭网络是发生在Client端与Server端之间链路中的某个路由节点上； 2.1 Client端到Server端之间有多条路可用，只要不是和CS直连这个设备有问题，那么设备可以选择其它路走，这时连接还是正常的； 2.2 Client端与Server端之间链路有NAT，且网络关闭发生与NAT端相关的设备上，那么连接就不正常； 2.3 Client端与Server端之间只有一条路，只要不是和CS直连这个设备有问题，那么如果网络在发生tcp_keepalive之前恢复，那么连接还是正常的； 3. 以上讨论的都是在TCP/IP协议情况下，网上查了一下SSH有居于UDP的方案（http://publications.lib.chalmers.se/records/fulltext/123799.pdf），如果走UDP的话这个要看SSH应用层的保活或SESSION有效期是否超过网络关闭时间，大小则可以连接，小于则关闭。

    作者回复: 很赞！总结的比较全面，很多因素都考虑到了。

    共 2 条评论
    3
  • 董泽润
    2020-09-17
    连接是否正常，要看是否开启了 tcp_keepalive, 并且探测持续失败，连接才失效

    作者回复: 是的

    
    2
  • 我能走多远
    2020-11-09
    感谢老师分享，学习了拥塞控制的原理，慢启动，拥塞避免，快速重传和快速恢复。cwnd和rwnd使用的单位是什么呢？ TCP segment个数。每个segment的长度就是mss的大小吗？

    作者回复: segment的大小最大是mss，最小的话就只是tcp header。

    共 2 条评论
    1
  • redseed
    2020-10-09
    老师你好，去年公司接入了跨境专线，使用默认对 CUBIC 算法时 TCP 的流量极不稳定，根据网上的优化建议增大了 TCP 的 sendbuf 适应这类高延迟网络，但是 TCP 的传输带宽反而下降了，想请教一下可能的原因出现在哪里？（PS. 后面我们使用了 BBR 算法并增大 sendbuf，这个对长肥管道有奇效...）
    共 1 条评论
    4