如何正确设计 TCP/IP 流式应用层网络协议

在我多年打黑工的职业生涯之中，除了在盛大游戏出身的半个老师（做游戏服务器的）曾今深入的教过我，关于正确的 TCP/IP 流式应用层网络协议的设计理念，前往其它公司打黑工、包括一些的开源项目，见识到的 TCP/IP 应用层网络协议设计似乎都有一些潜在问题。

很多人虽然设计的 TCP/IP 应用层协议解决了沾包的问题，但是并没有对 CC 有一定预防措施，也没有对错误的协议有预防措施。

举个例子：

很多人涉及 TCP/IP 应用层协议，只是在每个包前面加上两个字节、或三个/四个字节代表长度字节，也不考虑大小端平台的差异性，也没有考虑别人会不会恶意的 CC 挂着大量的长连接，每个TCP 链接实例保护一般是在7200秒（2个小时），多数操作系统一般能够保证至少 30 分钟链接是存活的。

那么是否可以完全可以挂着大量的 CC 来耗死服务器系统的资源，并且经过抓包分析测试应用层协议的长度，假设为两个字节代表长度，人家完全有必要每个挂起的链接，只发送 65534 个字节数据包，让服务器一直处于缓冲区数据保持读入的状态，而资源无法得到释放。

你算算一个G内存能够支撑多少个64字节，而且这不是成比例的，应用层分配64K内存，往往需要至少多占用一个页的内存空间大小，因为内存分配是需要加上链表帧头、校队帧尾的，所以分配64K，意味着至少需要分配 64K+4096K 的内存资源（这里还没有算页头这些占用的内存空间）。

单纯指望三方防火墙，而开发人员不做一些处理是有些搞笑的，别人是正常的网络链接，也是在给服务器跑流量的。