是否开启压缩会直接影响与客户端是否能够成功握手。
一、具体分析
通常客户端发起与Websocket连接一般是以下形式。
1)包含6个必要的Header
Request Headers
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: Nlpc0kiHFjRom5/62lj8bA==
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Host: 198.18.198.43:8081
2)一个请求行
Request URL: http://127.0.0.1:8081/v1/realtime?model=gpt-4o-realtime-preview-2024-10-01
Request Method: GET
Status Code: 101 Switching Protocols
其中,关键的一个在于请求头中的Sec-WebSocket-Extensions值的使用,客户端可以传输三种情况:
1. 不压缩
Sec-WebSocket-Extensions:
在此种情况下,如果Server开启了压缩,客户端不做兼容,则会直接导致握手失败,因为客户端解码不出具体的Server响应信息。如果Server没开启压缩,则客户端可以正常解码。
2.开启压缩
Sec-WebSocket-Extensions: permessage-deflate
在此种情况下,如果Server没开启压缩,客户端不做兼容,则会直接导致握手失败,因为客户端解码不出具体的Server响应信息。如果Server开启压缩,则客户端可以正常解码。
3.与服务器开启协商时压缩
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
此种情况下,是最理想的情况,不但能协商双方是否可期压缩,还能确定压缩窗口的大小。这种情况下,通常代表客户端功能也比完善。是最为推荐的。
二、Server端设置
如果要开启压缩,只需要在Netty启动Server时,添加如下Handler即可。
//webSocket数据压缩拓展,当添加这个处理器时WebSocketServerProtocolHandler的第三个参数需要设置true
ch.pipeline().addLast(new WebSocketServerCompressionHandler());
如果不开启,只需取消改行即可。更推荐的做法时,Server端根据客户端请求头Sec-WebSocket-Extensions中的值进行兼容处理。
三、客户端设置
客户端应该尽量设置为Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
,并对解析做兼容。对于类似Okhttp较新的版本默认开启压缩,且默认设置为:
Sec-WebSocket-Extensions: permessage-deflate
就不是非常合理。此时可以采用一种取消的方法,如下:
该方法,具体含义是根据传入的参数值确定具体是否要锁,默认1024.
如果这只参数值为0,代表对outbound的任何大小内容都会压缩,因为有内容必然大于0.
如果这只参数值为Long.MAX_VALUE,代表对outbound的任何大小内容都不会压缩,因为任何时候传输的值都不可能大于最大长整型。
默认1024,含义就是如果要穿书的内容大于1024则执行压缩,小于等于则不压缩。
参考:Okhttp实现的ws客户端,对接netty时,协议报错分析_rsv != 0 and no extension negotiated, rsv:4-CSDN博客