13 案例篇 | TCP拥塞控制是如何导致业务性能抖动的？

课后作业答案： - 通过 ssh 登录到服务器上，然后把网络关掉，过几秒后再打开，请问这个 ssh 连接还正常吗？为什么？ ssh使用的TCP协议，也就是它是有连接的，这个连接对内核而言就是tcp_sock这个结构体，这个结构体会记录该TCP连接的状态，包括四元组(src_ip:src_port - dst_ip:dst_port)，该连接的路由信息也被保存着。关闭网络后，该TCP连接的这些信息都还在，如果两边没有数据交互的话，这些信息就不会被更新，也就你一直存在着，当你再次打开网络，该连接还可以正常使用；假如关闭网络后，该TCP连接有数据交互，此时就会检查到异常，同样的也会去更新TCP连接状态信息，就有可能会断开这个连接。除此之外，TCP还有keepalive机制，如果该连接长时间没有数据，keepalive机制也会把该连接给关闭掉。

课后思考题： 这个应该是不确定的。 以前也测试过，只要在网络断开期间不主动发送数据，就会晚一点探测到连接已断开。 如果不主动发数据，可能网络恢复时，连接就自动恢复了。

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

cwnd和rwnd使用的单位是什么呢？

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

要分情况： 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有效期是否超过网络关闭时间，大小则可以连接，小于则关闭。

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

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

连接是否正常，要看是否开启了 tcp_keepalive, 并且探测持续失败，连接才失效

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