性能：网络数据传输慢，问题到底出在哪里了？

问题

说到底，网络传输问题就两种：

• 数据根本没有传递
• 数据传输速度比较慢

这里，我们来解决“数据传输速度慢”的问题

为什么数据传输慢

原因

这种问题的可能原因大致可以分为三种：

• 客户端应用程序的原因
• 网络的原因
• 服务器应用程序的原因

也就是说：

• 可能是由于数据发送方过载，而没有向接收方发送数据
• 可能是为了通道很慢
• 或者是数据接收方的服务器太忙，从而无法从网络缓冲区读取数据

为了描述方便，我们根据平时客户浏览网页的场景，假设客户端是数据接收方，而服务器端是数据发送方。

进行此类分析诊断时，负责的工程师通常需要快速隔离出上述不同场景，以便他们可以专注于特定场景里面的可疑组件，并对本质原因进行更深入的分析。但这一快速诊断过程会遇到很多难点。

• 首先，数据传输会涉及多个网络实体，包括两台机器（也就是发送者和接收者）和网络路由
• 其次，这种诊断涉及多层信息，包括应用程序层和网络传输层。为了找出原因，工程师必须检查各种数据，包括客户端日志、服务器日志、网络统计信息、CPU 使用情况等。这些检查需要花费很多时间和精力，并且通常需要性能工程师的经验和专业知识。

如何判断问题所在位置

要想快速诊断，我们需要先看看三种问题场景的不同特性。

这个解决方案本质上依靠的是客户端和服务端的TCP层面的特性。

• TCP是传输层协议之一，可以提供有序而且可靠的流字节传输，是当今使用最广泛的传输协议。
• TCP具有流控制功能，可以避免接收方挂载。接收方设置专用的接收缓冲区，发送方设置相应的发送缓冲区。服务端的发送缓存和客户端的接收缓冲区，都可以通过操作系统来检测当前队列的大小

为了能够识别瓶颈，你需要在发送方和接收方的传输层上，收集有关队列大小的信息。有很多收集此类信息的方法。常用工具有netstat和ss

• netstat是一个命令行工具，可以显示网络连接和网络协议统计信息。我们主要是用它来观察TCP/IP套接字的发送队列和接收队列的大小
• ss命令，可以显示套接字统计信息，包括显示TCP以及其他类型套接字的统计信息，以及发送和接收队列的大小

问题：传输数据时候，应用层和TCP 层的交互

• A时，服务端应用程序发出write()系统调用，并将应用程序复制到套接字发送缓冲区中‘
• B时，服务器的TCP层发出send()调用，并将一些数据发送到网络；数据量受TCP的拥塞控制和流控制
• C中，网络将数据逐跳路由(IP路由协议)到接收方
• D中，客户端的TCP层将通过recv()系统调用接收数据，数据放入接收缓冲区
• E时，客户端应用程序发出read()调用，以接收数据并将其复制到用户空间。

’
接下来，我们就来看看三种不同场景下的问题特性是怎么样的。
（1） 客户端接收缓慢的情况：

• 为了重现这一场景，我们做一个实验，让发送端发送一段固定大小的数据给接收方。我们强制接收方，也就是客户端，减慢数据的接收速度。具体的做法，就是在应用程序调用read()之前，注入一定的延迟。这种场景代表了客户端数据接收称为瓶颈的情况
• 如下图为数据发送方的发送缓冲区，SendQ（Send Queue）的大小变化。开始时，数据发送调用send()，立即注满SendQ。随着数据的传输，慢慢变为0
  
• 下图为客户端接收缓冲区，RecvQ（Receive Queue）的大小变化。客户端因为应用程序运行缓慢，所以RecvQ具有一定的积累，这可以由非0值看出。这些非0值持续了一段时间，随着应用程序不断被读取，最终RecvQ减为0

（2）数据发送方缓慢

• 我们强制发送方（即服务器端），放慢数据的发送速度。具体来说，我们在应用程序代码中，对 write() 的调用之前注入了一定延迟，模拟了发送者是瓶颈的情况
• 下图为服务器端的 SendQ 的值，你可以看到，SendQ 几乎全是0。这是因为发送端是瓶颈，其他地方不是瓶颈，所以任何SendQ的数据会被很快发送出去
• 而且图中还有一个持续时间很短的峰值，这是因为SendQ取样的时候恰好取到数据还没有被传输到网络中的时候。但是因为这个峰值持续时间很短，简单的过滤就可以去掉
  
• 接收端的 RecvQ 显示在下图，你可以看到，因为接收端不是瓶颈，RecvQ 是零。

（3）网络本身是瓶颈造成的数据缓慢

• 我们通过向网络路径注入延迟来创建这一场景，以使TCP仅能以非常低的吞吐量进行传输
• 下图中显示了发送端的 SendQ 值，你可以看到它的值不为零，因为那些数据不能很快地被传送出去。
  
• 再来看接收端的 RecvQ，如下图。RecvQ 全为零，这些零值就代表了快速的数据传递。
  
  总结：通过上面三种场景的分析，尤其是对发送端 SendQ 和接收端 RecvQ 的观察，我们不难总结出规律来。正常的数据传输情况下，客户端的接收队列和服务器的发送队列都应该是零。

反之，如果数据传输缓慢，则有如下几种情况：

1. 如果客户端上的接收队列 RecvQ 不为零，则客户端应用程序是性能瓶颈；
2. 如果服务器上的发送队列 SendQ 为零，则服务器应用程序是性能瓶颈；
3. 如果客户端的接收队列 RecvQ 为零，而服务器的发送队列 SendQ 为非零，则网络本身是性能瓶颈。

你可以通过这个表格，快速判断问题出现的位置。

解决方案

这是一个基于状态转移的方案，需要从客户端和服务端收集几个关键点的信息。

我们需要先来看看数据请求和传输流程图。就用常见的HTTP协议Request 和 Response 方式来描述，如下图所示。

• 当客户端需要下载服务器的数据时，首先在 T0 发出数据请求；
• 网络将请求发送到服务器后，服务器在T1收到数据
• 然后，服务器开始准备数据，数据准备好后，服务器将开始在 T2 时发回数据。 通过一系列write() 调用。发送在 T4 完成。
• 网络传输后，客户端在 T3 开始接收数据，并在 T5 完成接收。

请注意，尽管其他时间戳是按照严格的顺序，T3 和 T4 的顺序可能会因实际情况而异。

• 具体来说，对于小数据传输时，T4 可以先于 T3，因为单个 write() 调用就足够了。
• 对于大数据传输，通常使用 T3 在 T4 之前。

接下来，我们来看看基于状态机的解决方案，它是一个针对 HTTP 数据传输问题的，完整而具体的解决方案。

从上面的过程中，我们可以看到，如果服务器无法接收到数据请求，则数据传递将不会发生了，因此不会完成。

状态机如下图。这个状态机显示了整个HTTP数据传输的过程，包括Request和Response。如果数据攒底成功，状态机最后会到达状态F

• 数据传递的初始状态为State-S。
• 客户端发出请求后，它将移至状态A
• 当网络通道完成其工作，并将请求传递到服务器OS时，状态变为B
• 当服务器准备好数据，并开始发出数据的第一个字节时，状态变为C
• 当客户端收到第一个字节后，状态变为F；当服务器发出最后一个字节时，状态变为E；或者这两个次序交换
• 成功进行数据传递的最终状态是 State-F。

在整个过程中，如果发生其他的转移，那么就是为了传输有问题了，我们就可以根据发送端的发送队列和接收端的接收队列长度的变化，判断是谁的问题。