看源码，的确是b64=1。
如果为b64=true，服务端会出现什么错误么？
EIO的意思是：engineio的protocol版本号，因为js的socketio依赖了一个内部模块叫engineio的玩意。
客户端发送的这个版本号应该会影响服务端的一些版本差异的处理行为。
还是请官方重新绑定一下SOCKETIO吧，两边不一样用起来很不方便，而且问题也比较多
后续会跟进重点解决一下这个问题。目前有两套方案：
- 重写socketio的cpp绑定层，实现跟socketio js版本一样的逻辑。
- 废弃socketio绑定，直接使用socketio js版本。
这个问题解决了吗？我这里也是报一样的错。我的cocoscreator是1.6.1版本的，后端是nettysocketio这个框架，浏览器上socket连接正常，模拟器中，报错。我记录下了两个请求的差异。
浏览器下：
HttpObjectAggregator$AggregatedFullHttpRequest(decodeResult: success, version: HTTP/1.1, content: CompositeByteBuf(ridx: 0, widx: 0, cap: 0, components=0))
GET /socket.io/?EIO=3&transport=polling&t=Lz_bf-w HTTP/1.1
Host: 127.0.0.1:9081
Connection: keep-alive
Origin: http://localhost:7456
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
Accept: /
Referer: http://localhost:7456/
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.8
Cookie: io=4e6b2361-801f-499b-9721-9576b086dc6e
content-length: 0
模拟器中：
HttpObjectAggregator$AggregatedFullHttpRequest(decodeResult: success, version: HTTP/1.1, content: CompositeByteBuf(ridx: 0, widx: 0, cap: 0, components=0))
GET /socket.io/1/?EIO=2&transport=polling&b64=true HTTP/1.1
Host: 127.0.0.1:9081
Accept: /
Cookie: JSESSIONID=F671186BE09C475E6AF2300629B77AE4
User-Agent: beimi-mobile/1.0 CFNetwork/811.4.18 Darwin/16.6.0
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: keep-alive
content-length: 0
目前还抽不开身去做这个任务。。。
一定要用socketio吗？有更好的socket方案吗？
写websocket吧，我觉得还蛮好上手的
socket.io版本很老，没人维护， 为什么你们还要使用，或者为什么你们不维护下，cocos creator打包成native，socket.io根本连不上，浏览器预览一点问题都没有，这么基础的功能都，让开发者折腾来折腾去。而且解决方案之一是服务器socket.io版本太高，那到底最适合的socket版本是多少，现在github上的socket.io版本都是2.0.3上，难道开发者一个版本一个版本去测试，况且最新的版本是2.0.3,却用1.4的版本，想想就膈应，为什么creator出了1.7，就鼓励大家用最新的。肯定是最新的更好。先把cocos creator做稳定点，是开发者最希望的。
来看看
有结果了吗?
如果是java的话，可以换成tio！！！
有使用例子吗 求个demo
有例子吗
之前js下正常的代码，现在想换做TS写，同样的代码，无法运行了