全部博文（322）
分类： BSD
2012-04-06 14:41:38
1、 HTTP应答码一律设计为200 OK，不许用别的。（部分脑残的代理服务器会帮你改HTTP应答码。如遵守此规则，客户端对于非200 OK应答码可直接认定是网络异常，进行重试逻辑或放弃请求。真正的业务应答码在消息体中找）
2、 Content-Type永远只写plain/text、application/xml和application/oct-stream之一，除非万不得已。（避免防火墙什么的自作多情，同时防止处理非常见类型时低版本Windows自身的Bug）
3、 HTTP请求字段要么放在URL中，要么在消息体拼XML或JSON，绝不放在HTTP Header中。应答字段则全扔进消息体。（有被部分脑残的代理服务器吃掉的风险，以移动WAP代理为最高境界。最好保证HTTP Header永远是最最基本的那几个）
4、 坚持不设计multipart格式的HTTP协议。（这是Server方便了自己，给客户端调试和排错带来了不小的困难。自己写的客户端并非标准的浏览器，完美处理multipart的代价可能不低）
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数据流来说，数据传输速度越快，越容易断。（各公司网络一定会有这样那样的限制，而且有的纯属没事找事。所以设计高速数据传输协议时必须使协议与链路状态解耦，顶过这一关）
