互联网应用通讯协议设计攻略十条

 

1、 HTTP应答码一律设计为200 OK，不许用别的。（部分脑残的代理服务器会帮你改HTTP应答码。如遵守此规则，客户端对于非200 OK应答码可直接认定是网络异常，进行重试逻辑或放弃请求。真正的业务应答码在消息体中找）

2、 Content-Type永远只写plain/text、application/xml、application/json和application/oct-stream之一，除非万不得已。（避免防火墙什么的自作多情，同时防止处理非常见类型时低版本Windows自身的Bug）

3、 HTTP请求字段要么放在URL中，要么在消息体拼XML或JSON，绝不放在HTTP Header中（包括Cookie）。应答字段则全扔进消息体。（有被部分脑残的代理服务器吃掉的风险，如移动WAP代理等。最好保证HTTP Header永远是最最基本的那几个）

4、 坚持不设计multipart格式的HTTP协议。（这是Server方便了自己，给客户端调试和排错带来了不小的困难。自己写的客户端并非标准的浏览器，完美处理multipart的代价可能不低。同时可能触发脑残的防火墙的某些Bug）

5、 要想业务稳定到一定程度，就绝不设计上行消息体大于8K的HTTP POST，或者说大于8K时必须拆分成多个POST。（高丢包率环境中极易失败。8K上限是大量测试中发现的比较靠谱的经验值。单GET请求下载长数据流的协议靠谱程度稍好一些，但也能不用就不用）

6、 基于TCP的协议务必记得设计应用层双向心跳包。（在某公司网络中测试的惨痛教训。有些设备会以你根本想不到的方式吞掉FIN和RST）

7、 维持了Session状态的HTTP服务端，永远要记得处理客户端对于上一个成功事务的重试，为此经常需要对一个Session实现双状态机。（你虽然成功了，代理服务器帮你失败掉返回给客户端，客户端可真不知道是成功还是失败）

8、 8080端口传非文本二进制流的风险大于80和443。80又大于443。且443也并非完全无风险，需要有后备策略。（会发生莫名其妙被防火墙挡住的情况）

9、 如果还存在其他选择，就不要用Comet技术来调戏客户端。（还是那句话，自己写的客户端并非标准的浏览器，处理Comet的代价可能很大。不可控因素太多）

10、 对TCP数据流来说，数据传输速度越快，越容易断。（各公司网络一定会有这样那样的限制，而且有的纯属没事找事。所以设计高速数据传输机制时必须使数据包状态与链路状态脱离关系，保证链路上不可预测的中断不影响传输过程）