5
5
6
6
websocket is a minimal and idiomatic WebSocket library for Go.
7
7
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.
9
11
10
12
## Install
11
13
12
14
``` bash
13
- go get nhooyr.io/websocket@v0.2.0
15
+ go get nhooyr.io/websocket
14
16
```
15
17
16
18
## Features
17
19
18
20
- Minimal and idiomatic API
19
- - Tiny codebase at 1400 lines
21
+ - Tiny codebase at 1700 lines
20
22
- First class context.Context support
21
23
- Thorough tests, fully passes the [ autobahn-testsuite] ( https://github.com/crossbario/autobahn-testsuite )
22
24
- Zero dependencies outside of the stdlib for the core library
23
25
- JSON and ProtoBuf helpers in the wsjson and wspb subpackages
24
- - High performance
26
+ - High performance, memory reuse wherever possible
25
27
- Concurrent reads and writes out of the box
26
28
27
29
## Roadmap
@@ -88,8 +90,9 @@ c.Close(websocket.StatusNormalClosure, "")
88
90
- net.Conn is never exposed as WebSocket over HTTP/2 will not have a net.Conn.
89
91
- Using net/http's Client for dialing means we do not have to reinvent dialing hooks
90
92
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 )
93
96
94
97
## Comparison
95
98
@@ -111,7 +114,7 @@ Just compare the godoc of
111
114
112
115
The API for nhooyr/websocket has been designed such that there is only one way to do things
113
116
which 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,
115
118
more code to test, more code to document and more surface area for bugs.
116
119
117
120
The 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.
124
127
Some more advantages of nhooyr/websocket are that it supports concurrent reads,
125
128
writes and makes it very easy to close the connection with a status code and reason.
126
129
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.
129
142
130
143
### x/net/websocket
131
144
0 commit comments