记一次线上websocket返回400问题排查

现象

生产环境websocket无法正常连接，服务端返回400 bad request，开发及测试环境均正常。

抓包排查

src：nginx服务器 172.16.177.193
dst：imp应用服务器 172.16.177.218

问题定位

观察到header中的host值带有下划线，在一些中间件（如kafka、hadoop）中，对host中的特殊字符也有限制。由此猜测是header问题。
经排查，此header来自nginx的upstream

解决方案1

修改nginx的upstream配置，去除下划线

解决方案2

既然upstream中用了下划线，为何普通的http请求正常，而websocket则返回400呢？

再看正常的http请求的抓包

src: nginx服务器 172.31.47.151
dst: imp应用服务器 172.31.47.153

可见，header中的host，被转发到了目标服务器，而此host并没有下划线，正常请求。
所以，如果不修改nginx中的upstream下划线的配置，其实还可以在server中的websocket 对应的location中，添加参数，以便转发原始请求的host

proxy_set_header Host $host;
proxy_set_header X-real-ip $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

配置后的抓包如下

请求正常

原因探讨

带有下划线的host，为何会被服务端返回400？从上述排查过程可知，应是tomcat返回的。
这一切要从一个RFC协议规范说起
RFC-1034 是一个关于DNS及域名基础的标准。在「3.5 Preferred name syntax」中，有提及主机名的格式规范：由字母开头，字母或数字结尾，中间包含字母、数字或横杆

可见，RFC-1034标准中下划线并不被允许。

而Tomcat在一次8.x的升级中遵循该标准对host做了此校验，详见链接
org.apache.coyote.AbstractProcessor#parseHost
org.apache.tomcat.util.http.parser.Host#parse(java.io.Reader)

总结

在我们日常配置host参数时，都尽量避免使用下划线。包括在/etc/hosts下进行的配置，有时在集群环境中为了方便管理，会配置host，此时也应注意避免使用下划线。因为中间件可能也遵循了RTC规范。

CLAYJJ