55
66websocket is a minimal and idiomatic WebSocket library for Go.
77
8- This library is not final and the API is subject to change.
8+ This library is now production ready but some parts of the API are marked as experimental.
9+
10+ Please feel free to open an issue for feedback.
911
1012## Install
1113
1214``` bash
13- go get nhooyr.io/websocket@v0.2.0
15+ go get nhooyr.io/websocket
1416```
1517
1618## Features
1719
1820- Minimal and idiomatic API
19- - Tiny codebase at 1400 lines
21+ - Tiny codebase at 1700 lines
2022- First class context.Context support
2123- Thorough tests, fully passes the [ autobahn-testsuite] ( https://github.com/crossbario/autobahn-testsuite )
2224- Zero dependencies outside of the stdlib for the core library
2325- JSON and ProtoBuf helpers in the wsjson and wspb subpackages
24- - High performance
26+ - High performance, memory reuse wherever possible
2527- Concurrent reads and writes out of the box
2628
2729## Roadmap
@@ -88,8 +90,9 @@ c.Close(websocket.StatusNormalClosure, "")
8890- net.Conn is never exposed as WebSocket over HTTP/2 will not have a net.Conn.
8991- Using net/http's Client for dialing means we do not have to reinvent dialing hooks
9092 and configurations like other WebSocket libraries
91- - We do not support the compression extension because Go's compress/flate library is very memory intensive
92- and browsers do not handle WebSocket compression intelligently. See [ #5 ] ( https://github.com/nhooyr/websocket/issues/5 )
93+ - We do not support the deflate compression extension because Go's compress/flate library
94+ is very memory intensive and browsers do not handle WebSocket compression intelligently.
95+ See [ #5 ] ( https://github.com/nhooyr/websocket/issues/5 )
9396
9497## Comparison
9598
@@ -111,7 +114,7 @@ Just compare the godoc of
111114
112115The API for nhooyr/websocket has been designed such that there is only one way to do things
113116which makes it easy to use correctly. Not only is the API simpler, the implementation is
114- only 1400 lines whereas gorilla/websocket is at 3500 lines. That's more code to maintain,
117+ only 1700 lines whereas gorilla/websocket is at 3500 lines. That's more code to maintain,
115118 more code to test, more code to document and more surface area for bugs.
116119
117120The future of gorilla/websocket is also uncertain. See [ gorilla/websocket #370 ] ( https://github.com/gorilla/websocket/issues/370 ) .
@@ -124,8 +127,18 @@ it has to reinvent hooks for TLS and proxies and prevents support of HTTP/2.
124127Some more advantages of nhooyr/websocket are that it supports concurrent reads,
125128writes and makes it very easy to close the connection with a status code and reason.
126129
127- In terms of performance, the only difference is nhooyr/websocket is forced to use one extra
128- goroutine for context.Context support. Otherwise, they perform identically.
130+ nhooyr/websocket also responds to pings, pongs and close frames in a separate goroutine so that
131+ your application doesn't always need to read from the connection unless it expects a data message.
132+ gorilla/websocket requires you to constantly read from the connection to respond to control frames
133+ even if you don't expect the peer to send any messages.
134+
135+ In terms of performance, the differences depend on your application code. nhooyr/websocket
136+ reuses buffers efficiently out of the box whereas gorilla/websocket does not. As mentioned
137+ above, it also supports concurrent readers and writers out of the box.
138+
139+ The only performance downside to nhooyr/websocket is that uses two extra goroutines. One for
140+ reading pings, pongs and close frames async to application code and another to support
141+ context.Context cancellation. This costs 4 KB of memory which is fairly cheap.
129142
130143### x/net/websocket
131144
0 commit comments