为什么 websocket 连接在几秒钟后关闭

Question

好吧，我已经尝试解决这个问题有一段时间了，但没有结果。因此，我们在 aws 负载均衡器后面有一个 aws ec2 实例，并为负载均衡器分配了一个 aws free ssl。在我们的 ec2 实例中，我们有一个 apache Web 服务器侦听端口 1338 和一个 websocket 服务器（使用 Ratchet）侦听端口 8080。在我们之间，我们使用具有此配置的 HAProxy

global
    log     127.0.0.1   local0
    maxconn 10000
    user    haproxy
    group   haproxy
    daemon

defaults
        mode                    http
        log                     global
        option                  httplog
        retries                 3
        backlog                 10000
        timeout client          30s
        timeout connect         30s
        timeout server          30s
        timeout tunnel          3600s
        timeout http-keep-alive 1s
        timeout http-request    15s

frontend public
        bind            *:80
        acl             is_websocket hdr(Upgrade) -i WebSocket
        use_backend     ws if is_websocket #is_websocket_server
        default_backend www

backend ws
    option forwardfor # This sets X-Forwarded-For
        timeout queue 5000
        timeout server 5000
        timeout connect 5000
        server  ws1     127.0.0.1:8080

backend www
    timeout server  30s
        server  www1    127.0.0.1:1338

所以除了 Web 套接字服务器之外，一切似乎都正常。当我尝试连接时，连接成功，但大约 50-60 秒后，连接关闭，就像用户离开页面一样。并且只有使用 https 时才会出现这种情况。问题是，在我们的 httpd.conf 中，我们有一个 mod_rewrite 它将所有 http 连接重定向到 https。

另一个问题是，我们有 websocket php 客户端脚本，我们用它来连接到 websocket 服务器，这样我们就可以从 php 脚本发送通知，但是当我使用主机 127.0.0.1 时，该客户端无法连接到服务器和端口 8080。在没有 ssl 和 haproxy 的情况下进行本地测试时，一切都运行良好。我就是不知道问题出在哪里。是我的 HAProxy 配置还是我需要更改 aws 负载均衡器中的某些内容？

编辑 所以这些是来自 haproxy 的日志。我刚刚注意到另一件事。我不断向套接字服务器发送消息，客户端不会断开连接，因此，如果每 30 秒后继续向服务器发送虚拟消息，一切似乎都正常工作，但我仍然不明白为什么这个问题仅在使用 HTTPS

    Oct 26 16:49:31 localhost haproxy[7831]: 172.31.51.17:18222 [26/Oct/2016:16:49:31.913] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>"
Oct 26 16:49:35 localhost haproxy[7831]: 172.31.16.211:6536 [26/Oct/2016:16:49:35.312] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>"
Oct 26 16:49:41 localhost haproxy[7831]: 172.31.51.17:18227 [26/Oct/2016:16:49:41.913] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>"
Oct 26 16:49:42 localhost haproxy[7831]: 172.31.18.111:22978 [26/Oct/2016:16:49:42.769] public www/www1 0/0/0/126/126 302 1040 - - ---- 1/1/0/0/0 0/0 "GET / HTTP/1.1"
Oct 26 16:49:45 localhost haproxy[7831]: 172.31.16.211:6537 [26/Oct/2016:16:49:45.312] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>"
Oct 26 16:49:46 localhost haproxy[7831]: 172.31.62.174:22616 [26/Oct/2016:16:49:46.025] public www/www1 0/0/0/120/120 302 1038 - - ---- 1/1/0/0/0 0/0 "GET / HTTP/1.1"
Oct 26 16:49:51 localhost haproxy[7831]: 172.31.51.17:18230 [26/Oct/2016:16:49:51.913] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>"
Oct 26 16:49:55 localhost haproxy[7831]: 172.31.16.211:6540 [26/Oct/2016:16:49:55.311] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>"
Oct 26 16:50:01 localhost haproxy[7831]: 172.31.51.17:18236 [26/Oct/2016:16:50:01.913] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>"
Oct 26 16:50:05 localhost haproxy[7831]: 172.31.16.211:6545 [26/Oct/2016:16:50:05.312] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>"
Oct 26 16:50:11 localhost haproxy[7831]: 172.31.51.17:18240 [26/Oct/2016:16:50:11.913] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>"
Oct 26 16:50:12 localhost haproxy[7831]: 172.31.18.111:22992 [26/Oct/2016:16:50:12.791] public www/www1 0/0/0/124/124 302 1038 - - ---- 1/1/0/0/0 0/0 "GET / HTTP/1.1"
Oct 26 16:50:15 localhost haproxy[7831]: 172.31.16.211:6548 [26/Oct/2016:16:50:15.312] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>"
Oct 26 16:50:16 localhost haproxy[7831]: 172.31.62.174:22626 [26/Oct/2016:16:50:16.056] public www/www1 0/0/0/120/120 302 1034 - - ---- 1/1/0/0/0 0/0 "GET / HTTP/1.1"
Oct 26 16:50:21 localhost haproxy[7831]: 172.31.51.17:18241 [26/Oct/2016:16:50:21.913] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>"
Oct 26 16:50:25 localhost haproxy[7831]: 172.31.16.211:6551 [26/Oct/2016:16:50:25.311] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>"
Oct 26 16:50:25 localhost haproxy[7831]: 172.31.18.111:22952 [26/Oct/2016:16:49:23.912] public ws/ws1 750/0/0/65/61448 101 314 - - ---- 0/0/0/0/0 0/0 "GET /socket/ HTTP/1.1"
Oct 26 16:50:31 localhost haproxy[7831]: 172.31.51.17:18244 [26/Oct/2016:16:50:31.913] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 0/0/0/0/0 0/0 "<BADREQ>"
Oct 26 16:50:35 localhost haproxy[7831]: 172.31.16.211:6556 [26/Oct/2016:16:50:35.312] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 0/0/0/0/0 0/0 "<BADREQ>"
Oct 26 16:50:41 localhost haproxy[7831]: 172.31.51.17:18246 [26/Oct/2016:16:50:41.913] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 0/0/0/0/0 0/0 "<BADREQ>"
Oct 26 16:50:42 localhost haproxy[7831]: 172.31.18.111:22998 [26/Oct/2016:16:50:42.814] public www/www1 0/0/0/154/154 302 1034 - - ---- 0/0/0/0/0 0/0 "GET / HTTP/1.1"
Oct 26 16:50:45 localhost haproxy[7831]: 172.31.16.211:6557 [26/Oct/2016:16:50:45.312] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 0/0/0/0/0 0/0 "<BADREQ>"
Oct 26 16:50:46 localhost haproxy[7831]: 172.31.62.174:22632 [26/Oct/2016:16:50:46.087] public www/www1 0/0/0/132/133 302 1034 - - ---- 0/0/0/0/0 0/0 "GET / HTTP/1.1"
Oct 26 16:50:51 localhost haproxy[7831]: 172.31.51.17:18252 [26/Oct/2016:16:50:51.914] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 0/0/0/0/0 0/0 "<BADREQ>"
Oct 26 16:50:55 localhost haproxy[7831]: 172.31.16.211:6560 [26/Oct/2016:16:50:55.312] public public/<NOSRV> -1/-1/-1/-1/0 400 187 - - CR-- 0/0/0/0/0 0/0 "<BADREQ>"

Answer 1

您基本上需要配置隧道的超时，因为 websockets 创建一个隧道，所以您只需要在配置中添加：

timeout tunnel 2m
timeout client-fin 1s

haproxy 文档： https: //cbonte.github.io/haproxy-dconv/1.7/configuration.html#4-timeout%20tunnel

超时 client-fin 虽然不是强制性的，但似乎很重要，如其文档中所述：

由于此超时通常与长期连接结合使用，因此通常最好还设置“timeout client-fin”来处理客户端突然从网络中消失并且不确认关闭或发送消息的情况关闭并且不再确认待处理的数据。这种情况可能发生在存在防火墙的有损网络中，并且可以通过存在大量处于 FIN_WAIT 状态的会话来检测。

PS：我知道这是一个旧答案，但我刚刚遇到了这个问题，这是第一个结果。