是否开启压缩会直接影响与客户端是否能够成功握手。
一、具体分析
通常客户端发起与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值的使用，客户端可以传输三种情况：
-
不压缩
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博客