一首小诗~
钟表店里摆满了各种各样的钟表
每一个的时间都不一样
顾客问
怎么商品的时间不对也不调?
店主说
我这里每一个钟表呀
在世界上都有一个属于它的角落
它的时间是对的
一首小诗~
钟表店里摆满了各种各样的钟表
每一个的时间都不一样
顾客问
怎么商品的时间不对也不调?
店主说
我这里每一个钟表呀
在世界上都有一个属于它的角落
它的时间是对的
先来说TCP 下载速度为什么这么慢?一文的答案:是因为接收端窗口太小。
这是一个典型「长肥管道」的问题。长,是说这个 TCP 连接的延迟很大,距离很长;肥,是说这个 TCP 连接的传输内容很多,尝试使用最大吞吐来传输内容,管道很粗,是肥。长肥管道的性能分析方法就是提示里面的《用 Wireshark 分析 TCP 吞吐瓶颈》介绍的,用此方法可以初步定位出来大部分的问题。
使用文中的方法打开 tcptrace 图,我们会看到这是一个典型的受接收端窗口限制的问题。(注意,在给出的抓包文件中,实际上有两个 TCP flow,flow 是「一个 TCP 连接」的意思,也就是一个 TCP 四元组。Stream 0 是 iperf 用来做控制信息的,Stream 1 才是真正传输数据的。在实际的抓包分析中,能够正确地找到需要分析的 flow 也很重要。在这个例子中,可以通过传输数据的多少来判断。)

如果切换到 window scaling 图,会看到发送中的数据已经是和 window size 一样了。

在这个问题中,我还加入了几个丢包。但是传输受到接收端的影响太大,丢包造成的影响倒是可以忽略不计了。如果把接收端的窗口扩大到很大,吞吐就会受到丢包的影响。(一般来说,如果丢包率到了千分之一,TCP 吞吐就会下降的很严重)。
类似问题另一个可以关注的地方是 TCP 的专家信息,Wireshark 会帮你分析接收端的窗口大小,如果接收端说自己的接收窗口已经是 0 了,请不要再继续发送了,我们可以在 Wireshark 中看到类似的提示。

其实我这次的抓包也有这些信息,只是为了不让这个问题太简单,我把所有的包接收端窗口改成最小为 1 了,所以读者没有看到这个提示,嘻嘻。
今年 Netflix 技术博客发布了一篇 debug 文章:Investigation of a Cross-regional Network Performance Issue。文中因为一个超时问题,最终定位到内核代码变更,导致接收端窗口大小不正确,影响了性能。我想说的是,原文在排查问题的时候,去看最近有哪些变更,定位到了内核问题。如果使用本文介绍的方法,排查思路是:请求超时 > 抓包确认 TCP 传输时间 > tcptrace 分析长肥管道传输性能问题 > 定位到接收端的窗口大小问题。这个思路按图索骥,更加 solid.
这篇文章是抓包破案录系列文章(之前叫做《计算机网络实用技术》,后来改名了)中的一篇,这个系列正在连载中,我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题,经过精心构造和编写,每个文件附带抓包文件,通过实战来学习网络抓包与分析。
如果本文对您有帮助,欢迎扫博客右侧二维码打赏支持,正是订阅者的支持,让我公开写这个系列成为可能,感谢!
如果您正在阅读的是题目类的文章,这个目录内容正好用来隔离其他读者的评论。读完题目可以稍作暂停,进行思考,继续向下滑动,可能会被其他的读者剧透答案。
没有链接的目录还没有写完,敬请期待……
与本博客的其他页面不同,本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
在上一篇文章结束对链路聚合的讨论之后,我们发现一个问题——我们只能用多条线连接到同一个 switch 上面,这样万一这个交换机挂了,连接这个这个交换机的机器(通常是一个 Rack)就一起消失了。
MLAG(Multi-Chassis Link Aggregation) 可以提供跨设备的链路聚合功能。
Multi-Chassis 这个词很有意思,为什么叫做 Chassis (机箱)而不叫座 Multi-Switch LAG 呢?因为这个功能不仅仅是运行在 Switch 上,还记得在理解网络的分层模型中说的吗?二层和三层设备的界限已经越来越模糊了,三层设备也可以有这个功能。
现在的网络设备都是模块化的,一个机箱上面可以根据自己的需求插不同的线卡,卡上面甚至还能装不同的模块,满足不同的需求。机箱可以认为是网络设备单元,以「机箱」来说,意思就是运行于不同网络设备之间的功能。
MLAG 是一个设备的 feature,而不是协议,所以在不同厂商的产品中,MLAG,Peer Link 等术语会有所不同。
对于客户端 Linux 来说,不知道对端是两个设备,在 Linux 的视角下,自己的多条线路连接的就是同一个设备。
在交换机侧,就需要跨设备完成 LACP 信息的同步,两个交换机设备之间需要协调好,A 的 3号端口 和 B 的 3号端口是同一个链路聚合组(LAG)。所以两个交换机之间需要一条线,来沟通控制面的信息。这条线就叫做 Peer Link。在 Peer Link 上如何传输控制信息,取决于不同厂商对于 MLAG 的实现。某些厂商的设备使用 ICCP (Inter-Control Center Communications Protocol) 来进行不同的机箱之间的连接。
这样,就可以完成从服务器到交换机的高可用了,服务器网卡、网线、交换机接口、交换机系统、交换机整机,任意一个地方出现问题,都有冗余路线,不会对服务造成太大影响。
数据中心广泛使用的就是 MLAG。
在交换机之间的高可用,还有一种技术,就是交换机堆叠。这个功能在不同的厂商里也是不同的名字,比如华为的 istack,思科的 StackWise.
简单来说,这个功能可以让多个交换机虚拟成一个。只有一个主操作系统在运行,其他的交换机就像主交换机扩展出来的板卡一样。堆叠之后只有一个管理 IP 和 MAC 地址,只需要登录一个系统进行配置操作。

堆叠之后逻辑上就是一个交换机,所以服务器可以直接连接到多个物理交换机,从逻辑上看,交换机侧也是同一个了。

堆叠也能实现故障快速切换,在正常情况下也能充分利用线路的带宽,配置简单。但是和 MLAG 相比,稳定性上来说 MLAG 更高,因为堆叠交换机只有一个控制面,如果主交换机出现故障,比如堆叠失效,整个堆叠集群都会出错。MLAG 的故障域更小,交换机坏也就坏一台。这也带来很多维护便利,从升级维护上说,MLAG 可以让我们一台一台地操作交换机升级而不影响服务,堆叠就会更加麻烦一些。从部署上,MLAG 不受距离显示,堆叠的话,两个交换机距离越远,出错的概率越大。
说起来,思科还有一个 VDC 技术(Virtual Device Context), 支持把一个设备虚拟成多个。这些技术又是把一个物理设备拆成多个又是把多个合成一个的,可真有意思。
这个系列的二层技术介绍的差不多了,我们下一篇就开始聊三层技术。
Until next time!
最近,某团队在上线一个 AI 训练服务,运行在美国。AI 训练需要从另一个服务加载一些数据,数据因为欧洲国家的规定必须存储在欧洲,在美国的训练集群只能按需去加载欧洲的数据。
在训练的时候, 这个团队发现美国的客户端去读取欧洲的数据效率很低,美国欧洲购买的带宽是 10MiB/s,但是实际运行,数据的加载速度只有 KB 级别。导致训练时间都花在了数据加载上。AI 团队刚刚采购了昂贵的英伟达 A100 显卡,这数据加载这么慢,显卡都闲着,眼看着钱都打水漂了呀。
这个团队听说隔壁组有个新来的同事小张(就是你!)经常在一个叫卡瓦邦噶!的博客上学习网络知识,现在已经学成一个网络大神了,说不定他能解决这个问题呢!
这个团队找到小张,小张听说之后眉头一皱,觉得事情并不简单,要求这个团队在美国机房的客户端侧测试一下 TCP 的传输速率。
测试方法是,使用 iperf 软件测试带宽速度(可以理解为就是模拟 TCP 传输,使用一个连接,传输一个大文件,测试传输速度),并且在客户端机器上进行抓包。传输方向是欧洲向美国传输,抓包是在欧洲(TCP 的发送端)。
不一会,AI 团队发来了抓包数据。
小张兴奋地打开了 Wireshark……
请下载如下的文件并分析网络下载达不到带宽瓶颈的原因。
如果没有头绪的话,可以打开这个提示。
这篇文章是抓包破案录系列文章(之前叫做《计算机网络实用技术》,后来改名了)中的一篇,这个系列正在连载中,我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题,经过精心构造和编写,每个文件附带抓包文件,通过实战来学习网络抓包与分析。
如果本文对您有帮助,欢迎扫博客右侧二维码打赏支持,正是订阅者的支持,让我公开写这个系列成为可能,感谢!
如果您正在阅读的是题目类的文章,这个目录内容正好用来隔离其他读者的评论。读完题目可以稍作暂停,进行思考,继续向下滑动,可能会被其他的读者剧透答案。
没有链接的目录还没有写完,敬请期待……
与本博客的其他页面不同,本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。