Golang Go语言中吐槽下 rfc7692 permessage-deflate

槽点 1：允许 server_context_takeover 和 client_context_takeover 不一致

槽点 2: 允许 server_max_window_bits 和 client_max_window_bits 不一致

在我看来这 4 个参数完全可以合并为 2 个，参数越多越让使用者迷惑。而且让握手协商变得啰嗦复杂许多，给 compressor/decompressor 内存复用带来麻烦。

更多关于Golang Go语言中吐槽下 rfc7692 permessage-deflate的实战教程也可以访问 https://www.itying.com/category-94-b0.html

虽然不太懂具体的，但是 rfc 和 go 的关联在于？

更多关于Golang Go语言中吐槽下 rfc7692 permessage-deflate的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html

移不了主题了 😌

在Golang（Go语言）社区中，关于rfc7692 permessage-deflate的讨论确实存在一些吐槽的声音，这主要是因为该压缩扩展在WebSocket协议中的实现和使用涉及一些复杂性和潜在的性能开销。以下是一些专业的看法和建议：

复杂性：rfc7692 permessage-deflate使用zlib进行压缩，这意味着开发者需要处理与zlib相关的各种边缘情况和错误处理，这增加了代码的复杂性。在Go语言中，虽然标准库提供了zlib的支持，但正确实现和使用它仍然需要一定的技巧和经验。
性能开销：压缩和解压缩操作都会引入一定的CPU和内存开销，这在高并发或低延迟的应用场景中可能尤为明显。因此，在决定是否使用rfc7692 permessage-deflate时，需要仔细权衡其带来的压缩收益与性能开销之间的平衡。
替代方案：对于对性能有严格要求的应用，可以考虑使用其他更轻量级的压缩算法，或者在某些情况下完全不使用压缩。此外，也可以考虑在传输层使用更高效的协议，如HTTP/2或QUIC，它们提供了更好的性能和更丰富的功能。

综上所述，rfc7692 permessage-deflate在Go语言中的实现和使用确实存在一些挑战，但这并不意味着它不是一个有用的工具。在决定是否使用它时，建议根据具体的应用场景和需求进行权衡和选择。同时，也可以关注Go社区和相关开源项目的发展，以获取更优化的实现和更好的支持。