我在Firefox中启动下面的脚本，连接并发送文本消息到安装在本地计算机上的Websocket服务器。你能解释一下为什么firefox有时会在服务器端打开两个不同的套接字来完成这项任务吗？（在第二个套接字上有发送0长消息）。
<html>
<head>
<script>
function ws_connect()
{
ws = new WebSocket('ws://localhost:8080');
ws.binaryType = "arraybuffer";
ws.onopen = function(event)
{
var buf = new Uint8Array(2);
buf[0] = "hi".charCodeAt(0);
buf[1] = "hi".charCodeAt(1); // send message
ws.send(buf.buffer);
}
...
}
</script>
<script> window.onload = function() {ws_connect();};</script>
</head>
当我启动上面的脚本时，我在服务器端得到了预期的数据（我打印缓冲区，存储来自firefox的第一个数据）：
GET / HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:31.0) Gecko/20100101 Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Sec-WebSocket-Version: 13
Origin: http://localhost:8383
Sec-WebSocket-Key: tEPJwmPYq9b2aMu7KfcpjQ==
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
当websocket握手可以，脚本发送"hi"按摩时，firefox似乎又打开了一个套接字，发送0长度按摩，然后关闭它。（第一个套接字仍然打开，我可以使用它。）
https://bugzilla.mozilla.org/show_bug.cgi?id=786647
我们发出第二个TCP套接字连接，以防第一个的SYN在运输途中丢失。这在HTTP浏览器中是相当标准的（这是自举websockets）。不确定Chrome为什么不起作用它--它们用于常规HTTP IIRC
显然，确保SYN数据包到达目标是一种常见的技术。
快速猜测-这可能是客户端意外的favicon请求如何阻止favicon.ico请求？