我正在使用CURL库下载文件。我们将TLS 1.2与https：//一起使用。 使用的Curl版本是7.48.0。我们正在观察一个奇怪的问题。文件大小为224 MB时，服务器和客户端之间的Curl下载工作非常慢。如果我们使用curl的命令行工具非常快，但是如果从应用程序一侧调用“ curl_easy_perform”，情况就不会如此。
此外，我们使用--libcurl选项检查命令行和代码之间的区别，没有区别。我们使用与命令行工具相同的选项，但是通过直接调用curl_easy_perform完成下载仍然很慢。
如果我们从其他服务器和同一客户端进行下载，则工作正常。但是，仅对于特定服务器，我们会遇到下载时间问题。 进一步调试后，我们发现netstat输出显示tcp套接字的接收队列非常高。但是，即使设置了相同的选项，也不清楚为什么仅通过我们的程序而不是通过命令行这会是一个问题。
答案 0 :(得分：0)
事实证明，问题出在写回叫上，而这需要花费一些时间在该服务器上。在应用程序层的写回调用中，我们完成了malloc，memcpy并可以自由复制收到的新数据。除一台服务器外，其他所有服务器都可以正常工作。与该服务器的连接的不同之处在于，Curl在Write回叫中提供了16378个字节，后跟6个字节的数据，而在其他服务器工作正常的情况下，它始终提供16384个字节的数据。这与设备上默认为套接字缓冲区设置的rmem_max大小相同。不知道为什么使用特定服务器（Wildfly）时，它将分解为16378个字节，后跟6个字节。这导致连续的malloc，memcpy和免费循环下载224 MB文件。结果，从套接字读取的速度非常慢，导致下载速度很慢。在Curl命令行工具中，写回叫的写法不同，即打开文件，并在接收到数据时定期调用fwrite来将数据写入该文件，然后在接收到所有数据后调用fclose。与malloc，memcpy和free操作相比，这是非常快速的操作。因此curl命令行工具可以很好地下载相同的文件。我们更改了写回调用，使其与curl命令行所做的操作保持一致，从而解决了该问题。 但是，对于此特定服务器，Curl将数据划分为16378 + 6字节的原因尚不清楚，我将对此进行进一步研究。