如何仿造一个websocket请求？

之前两次singnalr、 websocket实时推送相关：

• • .NET WebSockets 核心原理初体验^[1]

• • SignalR 从开发到生产部署避坑指南^[2]

tag：浏览器--->nginx--> server

其中提到nginx默认不会为客户端转发Upgrade、Connection标头， 因为为了让被代理的后端服务器知道客户端要升级协议，故要在nginx上显式转发标头：

location /realtime/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

事情本该就就这么简单， 但devops总会有各种奇怪的姿势。

小动作引起的头脑风暴

但是运维在给nginx配置的时候，给/根路径配置了webcoket协议升级标头。

按照字面理解，导致所有的客户端转发请求都在要求切换到websocket协议，但是除了/chat路径， 服务器其他http路径并没有做websocket协议的逻辑，其他http请求是不是都该报错了。

是实际看，所有的请求(websocket、http)都没有报错，都按照指定预期返回。

刨一下

利用asp.netcore默认脚手架项目:

已知http://localhost:5000/WeatherForecast是http请求，返回一大坨json数据;
在WeatherForecast添加断言日志：

模拟ops的错配效果，我们给这个请求添加websocket协议升级标头。

第一次：curl 'http://localhost:5000/WeatherForecast' -H 'Upgrade: websocket' -H 'Connection: Upgrade' --verbose，正常返回大坨json数据。

日志记录：

该请求是不是webcocket请求：False,headers:[Accept, */*], [Connection, Upgrade], [Host, localhost:5000], [User-Agent, curl/7.79.1], [Upgrade, websocket]

以上说明，服务端并不认为是websocket请求， 这也印证了ops虽然错配，但对于常规的http请求没造成影响。

那服务端到底是怎么认定websocket请求？

从服务端认定websocket请求的源码^[3]看

依次判断；

• • HttpMethod: GET

• • Sec-WebSocket-Version标头==13

• • Connection标头==Upgrade

• • Upgrade标头==websocket

• • 有效的Sec-WebSocket-Key标头

这样我们就明白了，虽然websocket协议基于http，添加了httpConnection、Upgrade标头，但是浏览器实际会给我们带上Sec-WebSocket-Key^[4]、Sec-WebSocket-Version标头，以向服务器证明这是一个有效的websocket握手。

于是我们可以使用 curl 'http://localhost:5000/WeatherForecast' -H 'Upgrade: websocket' -H 'Connection: Upgrade' -H 'Sec-WebSocket-Version: 13' -H 'Sec-webSocket-Key: eeZn6lg/rOu8QbKwltqHDA==' --verbose 仿造客户端websocket请求。

日志记录：

该请求是不是webcocket请求：True,headers:[Accept, */*], [Connection, Upgrade], [Host, localhost:5000], [User-Agent, curl/7.79.1], [Upgrade, websocket], [Sec-WebSocket-Version, 13], [Sec-WebSocket-Key, eeZn6lg/rOu8QbKwltqHDA==]

对于这个websocket请求，服务端还是按照http代码逻辑返回200ok和JSON数据，从这个层面上看，http协议是兼容websocket的。

要让服务端真正按照websocket姿势， 要使用HttpContext.WebSockets.AcceptWebSocketAsync()告知客户端开始切换协议^[5]，并在原tcp上发起全双工通信。

前后对比， 困惑得解：虽然nginx为http请求转发了Connection、Upgrade标头， 但是服务器并不认可这是websocket升级协议，依旧当成带了Connection和Upgrade特殊标头的http协议，走原来的http业务处理逻辑是没有问题的。

总结

1. 1. 本文记录了nginx在转发websocket请求时要添加的配置

2. 2. websocket以http协议为蓝本，添加了特定的htp标头来要求切换协议；为了与常规http区分，浏览器自动增加了Sec-websocket-key等标头， 让服务端认为这是一个有效的websocket请求。

引用链接

[1] .NET WebSockets 核心原理初体验: https://www.cnblogs.com/JulianHuang/p/14681331.html
[2] SignalR 从开发到生产部署避坑指南: https://www.cnblogs.com/JulianHuang/p/15434137.html
[3] 服务端认定websocket请求的源码: https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/WebSockets/src/WebSocketMiddleware.cs#L219
[4] Sec-WebSocket-Key: https://www.rfc-editor.org/rfc/rfc6455#section-11.3.1
[5] 开始切换协议: https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/WebSockets/src/WebSocketMiddleware.cs#L134