基于tcp的不同协议之间互相通讯（tcp,http,websocket）

网页通常不能直接与tcp连接的设备直接通讯，虽然都是基于tcp,但是协议解析有点差别，通常是在服务器弄一个websocket代理，把tcp协议的数据转成websocket协议规范的数据，然后转发到真正的websocket服务器。

如果这个所谓的websocket代理服务器能够解析tcp,ws,http,这就不解决问题了吗，按照高内聚，低耦合的思想，应该是解析协议放在一起，然后使用同一个端口号，这样看起来是简洁，但是后期维护有点难度。还是一个协议使用一个端口，然后各个协议的服务器注册各自的信息到同一个端口，这样就通过这个端口统一了，这也可以简单理解成分布式服务器吧。基于workerman的gatewaywork能够完美解决这个问题。

包类型	包格式（JSON）
终端心跳	{type:pong}
终端登录	{type:login, uid:xx, room_id:x}
终端校时	{type:time, uid:xx}
终端主发	{type:ctl, uid:xx，content:xx}
终端状态	{type:state, uid:xx，content:xx}
转发数据	{type:trans, uid:xx，content:xx}

 

 

这个是json格式的，物联网好多设备都是走自定义协议的，字节字符串那种形式，每个字节的8个bit可能代表了很多内容。这里用json协议解析就不太可能了。还有裸tcp粘包也要服务器这边处理，怎么办呢，方法总比问题多，ws,http,wss,https不都是基于tcp的吗，那我这里也就自定义一个协议了。

input方法:截取协议规定长的的数据，提交给decode，达到最大长度仍未收到合法数据，关闭连接；

decode方法:将字节字符串解析成json格式的数据，提交给onmessage方法统一处理；

encode方法:将JSON格式的数据，转换成字节字符串，发送给客户端。

题外话：为啥使用字节字符串，不使用容易看懂的字符字符串，或者JSON,并且还弄一个crc校验。这样做当然有好处，节约流量，不易破解。终端使用字节字符串模式到服务器decode方法，可以处理成json模式，方便on_message方法统一处理。