websocket出来好久了，一直没有动手去玩玩，今天抽了点时间写了一个golang的例子，下面简单记录一下。
协议websocket是个二进制协议，需要先通过Http协议进行握手，从而协商完成从Http协议向websocket协议的转换。一旦握手结束，当前的TCP连接后续将采用二进制websocket协议进行双向双工交互，自此与Http协议无关。
可以通过这篇知乎了解一下websocket协议的基本原理：《WebSocket 是什么原理？为什么可以实现持久连接？》。
粘包我们开发过TCP服务的都知道，需要通过协议decode从TCP字节流中解析出一个一个请求，那么websocket又怎么样呢？
websocket以message为单位进行通讯，本身就是一个在TCP层上的一个分包协议，其实并不需要我们再进行粘包处理。但是因为单个message可能很大很大（比如一个视频文件），那么websocket显然不适合把一个视频作为一个message传输（中途断了前功尽弃），所以websocket协议其实是支持1个message分多个frame帧传输的。
我们的浏览器提供的编程API都是message粒度的，把frame拆帧的细节对开发者隐蔽了，而服务端websocket框架一般也做了同样的隐藏，会自动帮我们收集所有的frame后拼成messasge再回调，所以结论就是：
golang实现websocket以message为单位通讯，不需要开发者自己处理粘包问题。
golang官方标准库里有一个websocket的包，但是它提供的就是frame粒度的API，压根不能用。
不过官方其实已经认可了一个准标准库实现，它实现了message粒度的API，让开发者不需要关心websocket协议细节，开发起来非常方便，其文档地址：https://godoc.org/github.com/gorilla/websocket。
开发websocket服务时，首先要基于http库对外暴露接口，然后由websocket库接管TCP连接进行协议升级，然后进行websocket协议的数据交换，所以开发时总是要用到http库和websocket库。
上述websocket文档中对开发websocket服务有明确的注意事项要求，主要是指：
- 读和写API不是并发安全的，需要启动单个goroutine串行处理。
- 关闭API是线程安全的，一旦调用则阻塞的读和写API会出错返回，从而终止处理。
在我的实现中，我对websocket进行了封装，简化应用层开发的复杂度，主要思路是：
- 请求和应答都放入管道中排队。
- 读协程阻塞读websocket，将message放入请求队列。
- 写协程阻塞读应答channel，将message写给websocket。
如何处理websocket错误和主动关闭websocket呢？
- 读/写协程调用websocket若返回错误，那么直接调用websocket的Close关闭连接，协程退出。（此时用户可能仍旧持有连接对象，继续向下阅读！）
- websocket连接关闭后，用户通常正阻塞在读/写channel上而不知情，所以每个连接配套一个closeChan专门用于唤醒用户代码，关闭websocket连接同时关闭closeChan，这会令<-closeChan总是立即返回。
- 因为上一条设计，所以用户读/写channel时总是select同时监听channel和closeChan，以便实时感知到websocket连接的关闭。
- 用户可以主动关闭连接，websocket连接重复Close没有影响，而closeChan重复关闭会报错，所以通过一个上锁的状态位判重处理。
描述比较繁琐，实际并不复杂，看看我的代码吧：https://github.com/owenliang/go-websocket。
体验项目首先运行server.go，然后打开client.html页面，即可体验所有流程：
网上有很多nginx如何反向代理websocket服务的配置，通过Proxy即可实现，不再演示。