可视化TCP

发布于2010年12月13日星期一。

这个视频通过显示以下内容描述HTTP GET数据包就像球一样在客户端和服务器之间飞舞，与实时相比慢了40倍。很好地了解了底层TCP会话：你可以在开始时看到单独的回合，然后随着会话的稳定，回合开始重叠到足以消失的程度。

当我看到这段视频时，它让我想起了一直存在的排序算法视频，就像维基百科上的那些堆式分拣和快速排序页：

这又让我想起了2007年的一篇博文Aldo Cortesi关于可视化排序算法使用图形而不是视频。他指出，动画使得基于时间的问题很难回答：

我慎重地认为，这部动画就像一团粥被扔到墙上一样具有解释力。要了解我为什么这么说，请尝试参照以下一组简单问题找到大致答案：

• 经过多少百分比的时间后，一半的数组被排序？
• 你能找到一个移动了大约一半数组长度的元素来到达它的最终目的地吗？
• 80%的排序过程后，数组的排序百分比是多少？20%怎么样？
• 排序元素的数量是随时间线性增长还是非线性增长（即对数增长还是指数增长）？

如果你认为这比实际情况更难，那就怪动画吧。首先，虽然人类擅长估算空间距离，但他们在估算时间距离方面却相当糟糕。这就是为什么你要看两三次动画才能回答第一个问题。当我们将时间转换为几何长度时，就像在任何具有时间维度的科学图表中所做的那样，这个估算过程变得很容易。其次，许多关于排序算法的问题要求我们主动比较两个或多个不同时间点的排序状态。由于我们没有完美的记忆，除了最简单的情况外，这很难做到。这给我们留下了一个奇怪的动画一维视图——我们可以在任何给定时刻看到屏幕上的内容，但我们必须努力回答一些简单的问题，比如变化率。这就是为什么最后一个问题很难准确回答的原因。

相反，他建议绘制静态图，显示随时间变化的单个数组元素。以下是他对heapsort和quicksort的原始可视化：

这篇博文值得一读。它有更多的细节和许多其他有趣的博客帖子的链接，以及一个专门用于这些可视化的新网站，sortvis.org网站.

想起这一点，我不禁想知道排序的教训动画也应用于TCP动画，所以我收集了我的自己的HTTPGET两边的tcpdumps，取出可信（但被忽视）的Unix工具参加(1)生成每个数据包上有两个时间戳的转储，然后使用Perl将其转换为图形(原始PostScript):

时间向右移，每一行都在哪前一个中断。蓝色线表示来自客户机和黑线表示来自服务器的数据包。

我认为这种图表具有与科尔特斯用他的排序图实现了这一点。这是静态的，所以你有时间研究它，关注异常或注意模式这一点目前还不明显。线条的几何形状，与较慢的数据包相对应的更平缓斜率使其易于比较速度。

以下是我注意到的一些事情。

连接从通常的3路TCP握手开始。客户端在握手过程中发送第三个数据包第一个背对背的数据包，这是为数不多的背对背数据包之一变速箱。握手和初始GET后，它可能完全适合第一个包，即客户端仅接收数据：黑线表示较大的有效载荷而蓝线是触发更多ACK消息有效载荷。扫描客户端的连接视图（每行的顶部边缘）我们可以看到客户使用标准延迟ACK，每两个数据包发送一次ACK。扫描服务器的连接视图（每行的下边缘）我们可以看到服务器通常响应再发送两个数据包TCP窗口大小（传输中的数据包数）不变。不过，偶尔服务器会增加窗口大小用三个数据包而不是两个数据包进行响应。其中三个事件在第1行和第2行中圈出。有时，服务器仅对ACK作出响应单个数据包，但大多数情况下客户只确认了一个数据包。

我们可以随时统计飞行中的包裹数量通过计算黑线的数量穿过特定的蓝线，再加上数据包的数量当蓝线到达服务器时发送。例如，三条黑线穿过最后一个完整的第1行的蓝线，服务器再发送两个数据包作为响应，因此窗口大小为5个数据包。在第2行末尾，窗口大小为7个数据包。

窗口大小在稳定后会略有波动：在第10行末尾，它已经增长到8个数据包但在第20排的末尾，又回到了第7排。尚不清楚是什么导致服务器缩小或增大窗口大小。我找不到痕迹中数据包丢失的证据。

我设置了时间轴，使那些初始数据包能够传输斜率为2:1的直线上。浏览页面显示当客户端发送的数据包继续以大约那个速度旅行，包裹服务器发送的数据逐渐变慢，直到第3行，它们似乎稳定在1:2的斜坡上，发送时间是初始数据包的四倍。看看原始数据，那些后来的数据包大约100毫秒与最初握手时的20ms相比，单向跳闸，所以我们的视觉估计离我们不远了。这是沿路排队的证据从服务器到客户端；可能的嫌疑人是服务器的上游DSL连接。

第11行的圆圈碎片更能证明排队。某些东西延迟了ACK从客户端到服务器（注意坡度更为平缓）但服务器作为响应发送的数据包没有明显延迟：他们还有时间赶上瓶颈包裹。

第24行的圆圈碎片显示了相反的情况。大多数情况下，数据包到达客户端的时间是均匀间隔，但如果从服务器到客户端被延迟，这会延迟相应的确认，这会使谈话陷入混乱需要几轮才能转换为的行为稳定状态。

更熟悉TCP的人可能会注意到情节中有趣的细节。如果你发现有事，请留言。

当然，绘制网络数据包的想法以这种方式对抗时间并不是什么新鲜事：网络中的任何课程协议使用这样的图表。然而，我已经从来没有见过这样一个由真实的图表两侧的计时，以便您可以看到单个数据包并比较不同的数据包，我从未见过图表这是放大的，这样你可以看到宏比如第11排和第24排偶尔出现的拥堵打嗝。如果有一个工具可以生成这些自动，但我很少需要检查这一级别的协议，所以我不太可能在这方面花费更多时间。如果你知道（或制作）这样一个工具，请留下评论。