Skip to content

Commit 992ed07

Browse files
committed
wip
1 parent 387dc3b commit 992ed07

35 files changed

+2203
-2005
lines changed

README.md

Lines changed: 18 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -22,10 +22,11 @@ go get nhooyr.io/websocket
2222
- [Zero dependencies](https://godoc.org/nhooyr.io/websocket?imports)
2323
- JSON and ProtoBuf helpers in the [wsjson](https://godoc.org/nhooyr.io/websocket/wsjson) and [wspb](https://godoc.org/nhooyr.io/websocket/wspb) subpackages
2424
- Highly optimized by default
25+
- Zero alloc reads and writes
2526
- Concurrent writes out of the box
2627
- [Complete Wasm](https://godoc.org/nhooyr.io/websocket#hdr-Wasm) support
2728
- [Close handshake](https://godoc.org/nhooyr.io/websocket#Conn.Close)
28-
- Full support of the [RFC 7692](https://tools.ietf.org/html/rfc7692) permessage-deflate compression extension
29+
- Full support of [RFC 7692](https://tools.ietf.org/html/rfc7692) permessage-deflate compression extension
2930

3031
## Roadmap
3132

@@ -84,22 +85,12 @@ if err != nil {
8485
c.Close(websocket.StatusNormalClosure, "")
8586
```
8687

87-
## Design justifications
88-
89-
- A minimal API is easier to maintain due to less docs, tests and bugs
90-
- A minimal API is also easier to use and learn
91-
- Context based cancellation is more ergonomic and robust than setting deadlines
92-
- net.Conn is never exposed as WebSocket over HTTP/2 will not have a net.Conn.
93-
- Using net/http's Client for dialing means we do not have to reinvent dialing hooks
94-
and configurations like other WebSocket libraries
95-
9688
## Comparison
9789

98-
Before the comparison, I want to point out that both gorilla/websocket and gobwas/ws were
99-
extremely useful in implementing the WebSocket protocol correctly so _big thanks_ to the
100-
authors of both. In particular, I made sure to go through the issue tracker of gorilla/websocket
101-
to ensure I implemented details correctly and understood how people were using WebSockets in
102-
production.
90+
Before the comparison, I want to point out that gorilla/websocket was extremely useful in implementing the
91+
WebSocket protocol correctly so _big thanks_ to its authors. In particular, I made sure to go through the
92+
issue tracker of gorilla/websocket to ensure I implemented details correctly and understood how people were
93+
using WebSockets in production.
10394

10495
### gorilla/websocket
10596

@@ -121,7 +112,7 @@ more code to test, more code to document and more surface area for bugs.
121112
Moreover, nhooyr.io/websocket supports newer Go idioms such as context.Context.
122113
It also uses net/http's Client and ResponseWriter directly for WebSocket handshakes.
123114
gorilla/websocket writes its handshakes to the underlying net.Conn.
124-
Thus it has to reinvent hooks for TLS and proxies and prevents support of HTTP/2.
115+
Thus it has to reinvent hooks for TLS and proxies and prevents easy support of HTTP/2.
125116

126117
Some more advantages of nhooyr.io/websocket are that it supports concurrent writes and
127118
makes it very easy to close the connection with a status code and reason. In fact,
@@ -139,12 +130,13 @@ reuses message buffers out of the box if you use the wsjson and wspb subpackages
139130
As mentioned above, nhooyr.io/websocket also supports concurrent writers.
140131

141132
The WebSocket masking algorithm used by this package is [1.75x](https://github.com/nhooyr/websocket/releases/tag/v1.7.4)
142-
faster than gorilla/websocket or gobwas/ws while using only pure safe Go.
133+
faster than gorilla/websocket while using only pure safe Go.
143134

144135
The [permessage-deflate compression extension](https://tools.ietf.org/html/rfc7692) is fully supported by this library
145-
whereas gorilla only supports no context takeover mode. See our godoc for the differences.
136+
whereas gorilla only supports no context takeover mode. See our godoc for the differences. This will make a big
137+
difference on bandwidth used in most use cases.
146138

147-
The only performance con to nhooyr.io/websocket is that it uses one extra goroutine to support
139+
The only performance con to nhooyr.io/websocket is that it uses a goroutine to support
148140
cancellation with context.Context. This costs 2 KB of memory which is cheap compared to
149141
the benefits.
150142

@@ -163,14 +155,15 @@ https://github.com/gobwas/ws
163155
This library has an extremely flexible API but that comes at the cost of usability
164156
and clarity.
165157

166-
This library is fantastic in terms of performance. The author put in significant
167-
effort to ensure its speed and I have applied as many of its optimizations as
168-
I could into nhooyr.io/websocket. Definitely check out his fantastic [blog post](https://medium.freecodecamp.org/million-websockets-and-go-cc58418460bb)
169-
about performant WebSocket servers.
158+
Due to its flexibility, it can be used in a event driven style for performance.
159+
Definitely check out his fantastic [blog post](https://medium.freecodecamp.org/million-websockets-and-go-cc58418460bb) about performant WebSocket servers.
170160

171161
If you want a library that gives you absolute control over everything, this is the library.
172-
But for 99.9% of use cases, nhooyr.io/websocket will fit better. It's nearly as performant
173-
but much easier to use.
162+
But for 99.9% of use cases, nhooyr.io/websocket will fit better as it is both easier and
163+
faster for normal idiomatic Go. The masking implementation is [1.75x](https://github.com/nhooyr/websocket/releases/tag/v1.7.4)
164+
faster, the compression extensions are fully supported and as much as possible is reused by default.
165+
166+
See the gorilla/websocket comparison for more performance details.
174167

175168
## Contributing
176169

0 commit comments

Comments
 (0)