ajaxv的往返时间。双向信息传输

我想问一下，当使用web套接字（消息）实现时，与标准HTTP GET相比，我是否需要一些不同的往返时间（向服务器发送一些信息并接收响应）。我假设web套接字已连接，DNS已解析

---

据我所知，如果GET在底层协议中包含多个往返，那就不同了，我不确定这一点。否则，我会期望得到相同的结果。

WebSocket的往返时间似乎较短。我在本地和远程服务器上运行了一些测试，平均每次100个请求的跳闸时间：

Local: WebSocket: 2.46ms Ajax: 9.97ms Remote: WebSocket: 93.41ms Ajax: 183.49ms 本地： WebSocket:2.46毫秒 Ajax:9.97ms 远程： WebSocket:93.41ms 阿贾克斯：183.49毫秒 测试在服务器上使用Node.js和express和socket.io完成，在客户端使用Chrome和socket.io库完成。远程测试通过3G连接运行

更新：在家里，延迟低得多的连接，数字有点不同：

Websocket: 63.02ms Ajax: 72.11ms Websocket:63.02ms Ajax:72.11ms

---

这表明延迟对HTTP请求的影响比对WebSocket连接的影响更大，这可能是因为HTTP必须进行更多的往返才能为每个请求重新建立连接，正如您所提到的。

这取决于您考虑的初始场景

例1： 在一种情况下，您已经建立了HTTP 1.1连接，而在另一种情况下，您已经建立了WebSocket。在这种情况下，两种情况下的往返过程将完全相同，因为在这两种情况下，您已经建立了TCP连接，不需要进一步的应用程序握手。（注意：两种情况下发送的数据量不同，但这会影响带宽，而不是延迟，即往返时间）

例2：

---

在一种情况下，您已经有了HTTP 1.1连接（因为您可能刚刚下载了页面中的最后一个图像），而在另一种情况下，没有打开WebSocket。在这种情况下，HTTP上的往返时间将低于WebSocket上的往返时间。原因是使用HTTP，您只需要发送一个TCP段和接收一个TCP段（单程往返）。使用WebSocket，您需要设置TCP连接并执行WS-handshake，这涉及到一些往返。

不完全是。尽管HTTP 1.1能够在同一TCP连接中通过管道传输多个请求，但这并不意味着它的延迟与WebSocket连接相同。每一个HTTP请求响应都会在客户端和服务器上进行大量处理，这会增加HTTP请求的延迟。请求和响应中的每个HTTP头通常都需要一些处理。例如，只有一个小例子是cookie编组和解编。在WebSocket中，“HTTP”头处理仅在初始连接设置时发生。@kanaka:这不完全正确。HTTP 1.1管道是不同的。它是一种规范，用于在套接字上发送多个GET或POST请求，而无需在发送下一个请求之前等待响应。HTTP 1.1管道从未实现过。我在解释中提到的是HTTP“keep alive”，它适用于HTTP 1.0和1.1（默认行为）。@kanaka:我也不同意您的处理考虑，因为这将讨论转移到了应用层的优化上。您可能有一个处理请求速度较慢的未优化WebSocket服务器，以及一个处理cookie速度非常快的超级优化HTTP服务器，甚至为了特定的应用程序而忽略cookie。Alessandro：没错，我指的是HTTP 1.1启用的TCP连接重用。但在实践中，您无法摆脱处理方面的考虑。仅仅因为理论上HTTP服务器的开销可能和WebSockets服务器一样低，实际上不会。而且不仅仅是服务器，客户端/浏览器在处理HTTP请求（XMLHttpRequest）和响应时比生成/处理WebSockets框架时做的处理要多得多，这对所有流行浏览器都是正确的（将来也是正确的）。你确定chrome的积极缓存不会影响此测试的结果吗？你能发布这个测试吗？不幸的是，这个测试在我写它之后的两年里丢失了。不过，这种方法需要将数据发送到服务器并等待响应，因此我认为缓存可能不会影响结果。