一首小诗~
TCP 长肥管道性能分析
先来说TCP 下载速度为什么这么慢?一文的答案:是因为接收端窗口太小。
这是一个典型「长肥管道」的问题。长,是说这个 TCP 连接的延迟很大,距离很长;肥,是说这个 TCP 连接的传输内容很多,尝试使用最大吞吐来传输内容,管道很粗,是肥。长肥管道的性能分析方法就是提示里面的《用 Wireshark 分析 TCP 吞吐瓶颈》介绍的,用此方法可以初步定位出来大部分的问题。
使用文中的方法打开 tcptrace 图,我们会看到这是一个典型的受接收端窗口限制的问题。
如果切换到 window scaling 图,会看到发送中的数据已经是和 window size 一样了。
在这个问题中,我还加入了几个丢包。但是传输受到接收端的影响太大,丢包造成的影响倒是可以忽略不计了。如果把接收端的窗口扩大到很大,吞吐就会受到丢包的影响。(一般来说,如果丢包率到了千分之一,TCP 吞吐就会下降的很严重)。
类似问题另一个可以关注的地方是 TCP 的专家信息,Wireshark 会帮你分析接收端的窗口大小,如果接收端说自己的接收窗口已经是 0 了,请不要再继续发送了,我们可以在 Wireshark 中看到类似的提示。
其实我这次的抓包也有这些信息,只是为了不让这个问题太简单,我把所有的包接收端窗口改成最小为 1 了,所以读者没有看到这个提示,嘻嘻。
今年 Netflix 技术博客发布了一篇 debug 文章:Investigation of a Cross-regional Network Performance Issue。文中因为一个超时问题,最终定位到内核代码变更,导致接收端窗口大小不正确,影响了性能。我想说的是,原文在排查问题的时候,去看最近有哪些变更,定位到了内核问题。如果使用本文介绍的方法,排查思路是:请求超时 > 抓包确认 TCP 传输时间 > tcptrace 分析长肥管道传输性能问题 > 定位到接收端的窗口大小问题。这个思路按图索骥,更加 solid.
==计算机网络实用技术 目录==
这篇文章是计算机网络实用技术系列文章中的一篇,这个系列正在连载中,我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题,经过精心构造和编写,每个文件附带抓包文件,通过实战来学习网路分析。
如果本文对您有帮助,欢迎扫博客右侧二维码打赏支持,正是订阅者的支持,让我公开写这个系列成为可能,感谢!
没有链接的目录还没有写完,敬请期待……
- 序章
- 抓包技术以及技巧
- 理解网络的分层模型
- 数据是如何路由的
- 网络问题排查的思路和技巧
- 不可以用路由器?
- 网工闯了什么祸?
- 网络中的环路和防环技术
- 延迟增加了多少?
- TCP 延迟分析
- 重新认识 TCP 的握手和挥手
- 重新认识 TCP 的握手和挥手:答案和解析
- TCP 下载速度为什么这么慢?
- TCP 长肥管道性能分析
- 后记:学习网络的一点经验分享
与本博客的其他页面不同,本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
数据中心网络高可用技术之从交换机到交换机:MLAG, 堆叠技术
在上一篇文章结束对链路聚合的讨论之后,我们发现一个问题——我们只能用多条线连接到同一个 switch 上面,这样万一这个交换机挂了,连接这个这个交换机的机器(通常是一个 Rack)就一起消失了。
MLAG 技术
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!
数据中心网络高可用技术系列
TCP 下载速度为什么这么慢?
最近,某团队在上线一个 AI 训练服务,运行在美国。AI 训练需要从另一个服务加载一些数据,数据因为欧洲国家的规定必须存储在欧洲,在美国的训练集群只能按需去加载欧洲的数据。
在训练的时候, 这个团队发现美国的客户端去读取欧洲的数据效率很低,美国欧洲购买的带宽是 10MiB/s,但是实际运行,数据的加载速度只有 KB 级别。导致训练时间都花在了数据加载上。AI 团队刚刚采购了昂贵的英伟达 A100 显卡,这数据加载这么慢,显卡都闲着,眼看着钱都打水漂了呀。
这个团队听说隔壁组有个新来的同事小张(就是你!)经常在一个叫卡瓦邦噶!的博客上学习网络知识,现在已经学成一个网络大神了,说不定他能解决这个问题呢!
这个团队找到小张,小张听说之后眉头一皱,觉得事情并不简单,要求这个团队在美国机房的客户端侧测试一下 TCP 的传输速率。
测试方法是,使用 iperf 软件测试带宽速度(可以理解为就是模拟 TCP 传输,使用一个连接,传输一个大文件,测试传输速度),并且在客户端机器上进行抓包。传输方向是欧洲向美国传输,抓包是在欧洲(TCP 的发送端)。
不一会,AI 团队发来了抓包数据。
小张兴奋地打开了 Wireshark……
请下载如下的文件并分析网络下载达不到带宽瓶颈的原因。
如果没有头绪的话,可以打开这个提示。
==计算机网络实用技术 目录==
这篇文章是计算机网络实用技术系列文章中的一篇,这个系列正在连载中,我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题,经过精心构造和编写,每个文件附带抓包文件,通过实战来学习网路分析。
如果本文对您有帮助,欢迎扫博客右侧二维码打赏支持,正是订阅者的支持,让我公开写这个系列成为可能,感谢!
没有链接的目录还没有写完,敬请期待……
- 序章
- 抓包技术以及技巧
- 理解网络的分层模型
- 数据是如何路由的
- 网络问题排查的思路和技巧
- 不可以用路由器?
- 网工闯了什么祸?
- 网络中的环路和防环技术
- 延迟增加了多少?
- TCP 延迟分析
- 重新认识 TCP 的握手和挥手
- 重新认识 TCP 的握手和挥手:答案和解析
- TCP 下载速度为什么这么慢?
- TCP 长肥管道性能分析
- 后记:学习网络的一点经验分享
与本博客的其他页面不同,本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。