使用express-session时Socket.IO服务器的Cookie值来源及会话识别疑问

握手请求头信息 #

GET wss://<REDACTED>/socket.io/?EIO=4&transport=websocket HTTP/1.1
Host: <REDACTED>
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36
Upgrade: websocket
Origin: https://<REDACTED>
Sec-WebSocket-Version: 13
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,lb;q=0.7
Sec-WebSocket-Key: /FnojBTpR8wswCAXCR62rQ==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

疑问 #

请求中并未提及Cookie，那服务器是如何识别该请求所属的会话的？

WebSocket似乎确实从服务器收到了一些Cookie相关的数据，但我们并未向服务器发送Cookie，服务器怎么知道要发送哪个sid呢？

解答 #

1. 漏掉了Socket.IO的初始HTTP握手请求
   Socket.IO不会直接建立WebSocket连接，它首先会发起一个普通HTTP请求完成初始握手。这个阶段服务器会生成会话sid，并通过Set-Cookie响应头把sid发给客户端。后续浏览器发起WebSocket连接时，会自动携带这个Cookie，只是你当前抓包没覆盖到之前的HTTP握手步骤，所以看不到Cookie的传递。

2. 通过URL参数传递sid
   如果客户端配置了不携带Cookie（比如withCredentials: false），Socket.IO会把sid放在请求URL的参数里（格式类似sid=xxx），服务器可以直接从URL中提取sid来识别会话。你当前的请求URL里没显示sid，可能是初始握手时已经通过其他方式完成了关联。

3. 弱标识方案（极少用）
   极端情况下，服务器可能会用IP地址+User-Agent的组合来临时标识会话，但这种方案可靠性极低，同一IP下的多个客户端会出现会话冲突，所以很少被实际采用。

内容的提问来源于stack exchange，提问作者rjpj1998