通过TCP选择JSON的传输

fad*_*bee 16 streaming json multipart websocket ldjson

我正在编写一个简单的流式JSON服务.它由间歇性发送的JSON消息组成,持续很长一段时间(数周或数月).

通过普通TCP套接字发送多个JSON消息的最佳实践是什么?

我看过的一些替代方案(及其缺点)是:

  1. 换行符分隔JSON - 缺点:JSON中的换行符需要转义或禁止
  2. websocket灵感来自0x00 0xff框架 - 缺点:它现在是二进制,而不是utf-8
  3. 真正的websockets - 缺点:缺乏(opensource)websocket 客户端
  4. http multipart http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html - 缺点:不完整的客户支持?
  5. 没有分隔符 - 缺点:分块需要JSON解析(不能只计算curlies因为字符串中的curlies)

这样做是否有良好的,或至少是完善的方式?

Jav*_*ier 14

我的前两个选项是:

  1. 执行早期TCP协议的工作:发送一条消息(在您的情况下为JSON对象)并关闭连接.客户端检测到它并重新打开以获取下一个对象.

    • 优点:非常容易解析,没有发送额外(内容)字节.任何数据丢失意味着只丢失一个对象.如果你能坚持下去,就不需要为你的应用添加重新传输.
    • 缺点:如果发送(大量)(非常)小对象,则三包TCP握手会增加延迟.
  2. 执行chunked-mode HTTP的工作:首先发送JSON对象中的字节数,换行符(HTTP中的CRLF)和JSON对象.客户端只需要计算字节数就可以知道下一个字节何时成为下一个对象.

    • 专业人士:你保留一条长寿的流.
    • 缺点:一些额外的字节,你必须保持一个长期的流,所以意外中断和重新连接必须作为例外事件处理,需要建立一些握手继续失败的地方.


obe*_*tet 5

当您想要提供浏览器客户端时,最接近原始TCP的是WebSockets.

WebSockets有足够的动力,浏览器​​供应商将提高支持(Chrome 14和Firefox 7/8支持最新的协议草案),并且广泛的客户端和服务器框架将支持它.

已经几个开源客户端库,包括高速公路的WebSocket.

当你想为自己的东西(在原始TCP之上)烘焙时,我建议你的JSON消息使用长度前缀格式,即Netstrings

免责声明:我是高速公路的作者并为Tavendo工作.


fad*_*bee 2

我已经整理了我和其他一些开发人员正在做的事情:

http://en.wikipedia.org/wiki/Line_Delimited_JSON

它的优点是兼容 netcat/telnet。

另请参阅: http: //ndjson.org/

  • 正如我在维基百科中所说,这不是创作原创作品的最佳场所,您应该将其放在其他地方 (3认同)