苏州公司建设网站制作,企业信用信息网查询系统官网,网站建设的颜色值,自己制作手机软件app之前两次singnalr、 websocket实时推送相关#xff1a;• .NET WebSockets 核心原理初体验[1]• SignalR 从开发到生产部署避坑指南[2]tag#xff1a;浏览器---nginx-- server其中提到nginx默认不会为客户端转发Upgrade、Connection标头#xff0c; 因为为了让被代理… 之前两次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. 本文记录了nginx在转发websocket请求时要添加的配置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
