TCP 与Http基准测试答案

【问题标题】：TCP Vs. Http BenchmarkTCP 与Http基准测试
【发布时间】：2010-11-14 20:39:45
【问题描述】：

我有一个位于 IIS 上的 Web 应用程序，并与 [remote]Service-Machine 通信。我不确定是选择 TCP 还是 Http 作为主要协议。

更多细节：

我将拥有多个服务\端点
其中一些是单向的
另一种是双向的
网页将在服务前运行
我们谈论的是大型网站

我很清楚其中的区别，但我正在寻找一个好的基准，它显示 TCP 的速度有多快？

【问题讨论】：

这取决于你想做什么。您是否有更多关于网络应用程序与之对话的服务的信息？请求是一次性的（即问题、响应）还是一次对话包含多个问题和响应？

标签： http tcp

【解决方案1】：

HTTP 是建立在 TCP 层之上的一层，用于标准化数据传输。因此，使用 TCP 套接字自然会比使用 HTTP 更轻。如果性能是您唯一关心的事情，那么纯 TCP 是最适合您的解决方案。

您可能需要考虑 HTTP，因为它易于使用和简单，最终可以缩短开发时间。如果您正在做的事情可能会被浏览器直接使用（通过 AJAX 调用），那么您应该使用 HTTP。对于非现代浏览器直接使用没有 HTTP 的 TCP 连接，您必须使用 Flash 或 Silverlight，这通常发生在视频和/或音频等丰富的内容上。但是，现在（截至 2013 年）许多现代浏览器都支持 API 以直接通过 JavaScript 访问网络、音频和视频资源。唯一需要考虑的是您的用户中现代网络浏览器的使用率；有关浏览器兼容性的最新信息，请参阅 caniuse.com。

至于基准，this 是我发现的唯一东西。见第 5 页，它有性能图表。请注意，它并没有真正将苹果与苹果进行比较，因为它将 TCP/二进制数据选项与 HTTP/XML 数据选项进行比较。这就引出了一个问题：您的服务输出什么样的数据？二进制（视频、音频、文件）还是文本（JSON、XML、HTML）？

一般来说，像军事或金融部门这样的面向性能的系统可能会使用普通的 TCP 连接。作为一般的以网络为中心的公司将选择使用 HTTP 并使用 IIS 或 Apache 来托管他们的服务。

【讨论】：

你有 WebSocket 做原始 TCP 连接和 Canvas/WebGL 使用浏览器中的 JavaScript 丰富的内容。
真；在我发表原始文章 4 年后，现在可以使用 JS 和 HTML5 工具（WebSocket、WebGL、Canvas、Audio、Drag and Drop、WebWorkers、WebRTC、Geolocation、Web Storage、TypedArrays 等）访问音频、视频和网络 api。 )
感谢 Darwyn 的精彩解释。消除了我的很多误解。您能否详细介绍一下“通过 JavaScript 直接访问网络、音频和视频资源的 API。”
@BenBarkay - websockets 不是原始 TCP 连接。
还要提一下，当使用 HTTP 添加安全性时，如 SSL 和身份验证更舒适，并降低了执行自制传输安全或授权协议时的风险

【解决方案2】：

您真正需要回答的问题是“my 应用程序的 TCP 或 HTTP 是否会更快”。答案是它取决于您的应用程序的性质，以及您在应用程序中使用 TCP 和/或 HTTP 的方式。通用的 HTTP 与 TCP 基准无法回答您的问题，因为该基准很可能与您的应用程序行为不匹配。

理论上，使用 TCP 进行优化设计/实施的解决方案将比使用 HTTP 的解决方案更快。但是实现起来也可能需要更多的工作......取决于您的应用程序的详细信息。

还有其他问题可能会影响您的选择。例如，与在某个随机端口上使用 TCP 相比，使用 HTTP 不太可能遇到防火墙问题。另一个原因是 HTTP 可以更轻松地在 IIS 服务器和后端系统之间实现负载平衡器。

最后，归根结底，您的系统的安全性、可靠性、可维护性和（也许）可扩展性可能比它的快速性更重要。一个明智的策略是首先实施简单版本，但如果简单的解决方案太慢，请计划好如何让它更快。

【讨论】：

使用 HTTP 时，您可以从 SSL 和授权实施中获益，与自制解决方案相比，这大大降低了风险和工作量
但是如果你愿意，你可以在普通套接字上使用 SSL；见SSLSocket

【解决方案3】：

您总是可以对其进行基准测试。

一般来说，如果您想要完成的任务可以通过 HTTP 轻松完成（即，您考虑使用原始 TCP 的唯一原因是为了提高性能），您可能应该只使用 HTTP。当然，您可以进行套接字编程，但何必呢？许多人花费了大量的时间和精力来构建 HTTP 客户端库和服务器，他们花费的时间优化和测试代码比您可能花费在 TCP 套接字上的时间要多得多。有很多可能的错误需要您处理、边缘情况和可以完成的优化，因此使用 HTTP 库函数通常更容易、更安全。

另外，HTTP 规范定义了各种功能（以及客户端/服务器实现，您可以“免费”使用，即无需额外的实现工作），这使得任何第三方互操作性变得更加容易。 “这是我的网址，这是你发送的规则，这是我返回的规则......”

【讨论】：

警告——如果是对话，HTTP 可能效率不高——通过每次打开 TCP 连接在 HTTP 中的多个请求是昂贵的，而且我已经看到服务器资源匮乏作为底层 TCP 连接没有完全关闭。是的，HTTP/1.1 支持为更多请求保持连接打开，但不清楚其他服务是否支持。
确实如此，但如果其他服务器确实支持它，那就是那些“免费”优化之一。至于连接没有完全关闭，这是库中的一个错误，并且将是一个严重的问题，但是再次“滚动你自己”的情况需要警惕可能导致相同资源的所有可能情况饥饿。
我不知道你在实施是什么意思？！如果 WCF 和 net.tcp 会更快（如果需要，可以创建 Java 代理），或者我们有 java 的实现......所以它已经实现和测试，只需要决定，是不是不是吗？
@adam 问题：在 add_to_cart / add_to_wishlist / add_to_favorite 等情况下使用 Socket 编程来代替从 Asynctask 生成的正确 http_request 是否很好。
@rabashani 及其风险更大

【解决方案4】：

我有一个使用 Casablanca C++ REST SDK 代码的自托管 Windows 本机 C++ 服务器应用程序。我可以使用任何客户端 C#、JavaScript、C++、cURL，基本上任何可以发送 POST、GET、PUT、DEL 的东西消息可用于向此自托管 Windows 应用程序发送请求消息。此外，我可以使用普通浏览器地址栏使用各种参数执行 GET 相关请求。目前我只在私有 Intranet 上运行这个系统，所以它非常快 - 我没有将它与只做原始 TCP 进行基准测试，但是在私有 Intranet 上我怀疑会有几微秒的差异？为了方便和易于开发以及扩展到成熟的互联网应用程序的能力，这是梦想成真。它是一个专用系统，具有使用小型 JSON 数据包的私有协议，因此不确定这是否适合您的应用程序需求？另一个好处是这个 Windows 应用程序原生 C++ 代码可以很容易地移植到 Linux/MacOS 上运行，因为 Casablanca REST SDK 可以移植到这些操作系统。

【讨论】：