09 | 长肥管道：为何文件传输速度这么慢？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文通过深入分析文件传输速度缓慢的案例，提出了优化TCP传输速度的解决方案。首先介绍了TCP传输速度受到的影响因素，如往返时间（RTT）、在途字节数等，并解释了这些概念对传输速度的影响。随后，详细介绍了如何使用Wireshark工具来分析传输速度趋势和TCP序列号，并指导读者如何根据分析结果进行优化。通过对时延信息的收集和分析，读者可以了解到如何利用Ping和Wireshark获取RTT信息，并了解了iRTT的计算方法。文章还探讨了带宽时延积和发送窗口对传输速度的影响，以及窗口和往返时间在传输速度问题中的重要性。通过对窗口和往返时间的把握，读者能够解决大部分传输速度的问题。此外，还提到了使用Wireshark的一些技巧，包括查看I/O Graph、TCP Stream Graphs和TCP Window Scale等方法。总之，本文为读者提供了解决文件传输速度缓慢问题的实用方法和技巧，以及Wireshark分析技巧，使读者能够在网络排查中更加坚定有力地前行。
《网络排查案例课》，新⼈⾸单¥59
全部留言(19)
- 最新
- 精选
江山如画我们公司之前有一个场景是多个客户端连接同一个服务端，如果某个客户端下载文件或上传文件，占用大量的带宽，会导致新的客户端连不上服务端。后来在服务端使用 tc 工具做了流控，根据客户端个数均分带宽，还有限制单个IP的最大使用带宽。 学了今天的课程后，突然想到 tc tools 这类流控工具，底层原理是不是就是调整服务端的接收窗口，进而调节带宽大小的。进一步想类似百度网盘，迅雷，它们的限速原理是不是也是通过调整接收窗口的大小。如果是这样，可以通过修改报文中窗口大小字段，进而绕过带宽限制。作者回复: tc的原理是调整qdisc发送缓存队列，超出队列的数据就丢弃，进而达到速度限制的效果。
2022-02-09911
分清云淡这篇文章《TCP性能和发送接收Buffer的关系》讲得非常清楚：https://plantegg.github.io/2019/09/28/%E5%B0%B1%E6%98%AF%E8%A6%81%E4%BD%A0%E6%87%82TCP--%E6%80%A7%E8%83%BD%E5%92%8C%E5%8F%91%E9%80%81%E6%8E%A5%E6%94%B6Buffer%E7%9A%84%E5%85%B3%E7%B3%BB/作者回复: 这是高手：）
2022-02-2527
一把螺丝刀请问是做了什么修改来增大窗口呢？作者回复: 您好，案例里的设备是特殊硬件有其自己的配置方式，不具备普适性就没展开了。linux有相关参数，比如mem_rmax、rmin这些，都会影响接受窗口，你可以调整看看效果
2022-02-106
唐伟老师，你好！我有两个问题想请教一下： 1、文中“我们对它的配置做了修改，使得接收窗口大幅增加后，速度马上提上去很多倍，这才彻底解决了问题。”，这里是修改啥配置？能否贴出来学习一下？ 2、文中说“那为什么启用了 Window Scale，还是被限制在 64KB 附近呢？我们发现，这还是受限于这台设备本身的特点。在某些情况下，这里的 Window Scale 虽然启用了，但无法充分工作，导致实际上这台设备的接收窗口一直被压制在 64KB 附近。”，那这里是怎样定位设备本身的问题呢？作者回复: 您好，这两个问题跟特定硬件设备有关，不是很有普适性，所以也没有在课程里详细介绍。这节课的关键，还是整个排查的过程和TCP协议的理解。通过这个案例，我希望能帮助大家举一反三、融会贯通，而不是局限在这个特定案例里面。 当然，既然你在这里问了详细情况，我就稍展开一下： 1. 这个配置是硬件负载均衡的tcp profile。硬件设备（当然本质上还是软件和硬件和结合）的data plane是厂商自己研发的，并不是用linux提供的TCP/IP协议栈。这里的tcp profile也是厂商研发的特性，我们可以方便的定义不同的VIP使用不同的tcp profile。假设同一台LB上有两个VIP，一个VIP是对公网服务的，那面对的就是时延较长、带宽相对有限的网络，另外一个VIP是对内服务的，那面对的就是时延较短、带宽比较充足的网络。这两个VIP可以应用不同的tcp profile，来适配相应的网络场景。这就比linux要更加灵活一些了。虽然理论上linux也可以用容器来划分不同的网络命名空间并设置不同的tcp参数，但毕竟没有vip配合tcp profile这么方便。我们也是修改了tcp profile，使其接收窗口变得更大，能容纳这些错乱的数据，大部分情况下可以缓解这个bug带来的问题。 2. “启用了window scale还是被限制在64KB”，这就是这款设备的这个firmware的bug了，具体的情况只有厂商清楚啦。 希望对你有用~
2022-06-301
我来也最近的两篇文章比较有意思，可以借来排查一下一个比较困扰我的问题。 我电脑推送docker镜像时某些层经常卡住，然后重试。 中间的链路非常扰： mac 的docker 是自己的一套网段，我需要通过一个http 代理来推送镜像。我电脑上用了一个代理软件surge。 推送docker镜像是docker 进程发流量到代理软件surge，代理软件再自己建个tcp连接去发数据。 这个代理软件吧它自己有有虚拟网卡之类的，把docker 的流量自己又倒腾了一次。作者回复: 恩我们在学习群里已经在沟通了～
2022-02-1131
Realm设备上配置了限速64k引起的？老师，一般网络限速是基于窗口吗？作者回复: 确切说并不是直接调整带宽限制，而是修改设备对每个tcp连接的最大接收窗口的限制。按照“窗口/往返时间”这个公式，同一个窗口配合不同的往返时间，起到的速度限制各不相同～
2022-02-0921
AlohaJack“那为什么启用了 Window Scale，还是被限制在 64KB 附近呢？我们发现，这还是受限于这台设备本身的特点。在某些情况下，这里的 Window Scale 虽然启用了，但无法充分工作，导致实际上这台设备的接收窗口一直被压制在 64KB 附近。” 请问老师，这里可能具体由于什么原因和配置导致接收窗口被压制呢？ 发送窗口=min(接收窗口，拥塞窗口) 既然发送窗口只有64kb，接收窗口又比64kb大，那是不是可以理解为由于中间网络拥塞，导致拥塞窗口变小，最终导致发送窗口只有64kb？作者回复: 您好，这是一台硬件设备，其firmware（非Linux）是厂家自己维护的，自然也不开源，所以具体代码级别的原因就不得而知了。当时确定的是firmware本身的一个feature gap。 启用了WS只是告诉系统：“你可以用更大的接收窗口了”，但不等于直接修改接收窗口（毕竟接收窗口是系统动态生成而且一直变化的，不适合用静态值来配置）。我们观察到的是，设备（非Linux）的tcp profile里WS是启用的，但是抓包时候发现的接收窗口仍然在64KB左右。离我们预期很远，所以说也是这个firmware的一个bug吧。这一点跟具体设备有关，其实并不很重要。最重要的是深入掌握这里面的TCP原理，这是可以普适的，你可以到处能用到的知识：）
2022-08-17归属地：上海2
上杉夏香文章随机二刷中： 碰见传输速度慢的问题，排查思路如下： 1、确定这条线路的带宽。如果达到带宽的限制，那么慢有应得。 2、查看wireshark抓包的专家信息，是否有丢包的情况？严重吗？（这里以TCP为控制层协议） 3、根据公式：v=发送窗口/RTT。RTT一般都是客观存在且不容易改变的，除非直接加专线。发送窗口又分为两个方面，到底是对方的接受窗口限制了发送窗口还是拥塞窗口在起作用。如果是接受窗口在起作用，可以查看window scale是否开启？开启是否有额外的特殊问题？如果是拥塞窗口在起作用，一般认为该时段网络达到上限（丢包触发拥塞窗口的大小，丢包说明网络状态差），还有就是设置歧视拥塞窗口为10个MSS而不是2个MSS；发生拥塞后不要从头开始进入慢启动阶段等等作者回复: 差不多了，你总结的不错！在第3点钟，拥塞情况确实对传输速度有很大的影响，而初始拥塞窗口对于小文件传输的影响更大，因为小文件传输本身需要的时间就短，那么起始阶段占整个传输的比例就更大了，这个阶段效率高一些很有帮助。
2022-08-12归属地：上海- Geek_0d1ecd是否可以理解，目前网络加速都是把RTT减少，把长距离切成多个片段 （TCP Window Scale不变的情况下，另外TCP Window Scale的值会带来什么未知的隐患吗）
作者回复: 网络加速这个话题很大，几句话肯定讲不完，不过RTT不是那么容易缩小的，除了逻辑路径优化，就是真正的物理路径的优化了，比如更短距离的光纤线路等。不过我想你可能指的是CDN或者POP点这种离终端用户更近的节点，它们确实可以省去tcp握手的时间，另外CDN或者POP跟源站的tcp连接是“热”的，保持在一个较高的tcp窗口水平，这也十分有帮助。 window scale没什么副作用～
2022-06-14 
salt这个示例包似乎有问题，window size scaling factor 显示为unkown， options字段也只显示了字节不能展开，导致wireshark看到的Calculated widow size显示的值都是271。 上一节课的包，window size scaling factor /options都正常显示。作者回复: 你好，确实有这个问题，我刚重新编辑了文件并上传了，这次有window scale和准确的windows size了：）
2022-04-16
