副标题：作为内容分发的互联网协议演进
注意，"作为内容分发的互联网" 修饰，这意味着本文缺失了 "作为对等通信的互联网" 的内容，这是有意为之，因为互联网一开始就源自对等通信，稍微照顾内容分发(FTP)，对等通信不需要任何描述，它一直工作的很好。
先看第一个问题，互联网拥塞。
前面不止一次从互联网基因的视角分析 TCP/IP 协议族的固有问题，它适合做什么以及不适合做什么，比方说拥塞为什么与生俱来。
在更深层面，拥塞总是来自于短时间(相对于 RTT 的期望)内从一个位置获取内容或向一个位置推送内容，聚合带宽过载。早期互联网就从没考虑到这类应用会如此普遍。而 TCP/IP 单播模式导致这些流量在传输中是冗余的，而在存储中却维持单独副本。
互联网拥塞常见于大型直播，明星汇演，体育赛事直播，产品发布，以及每日流量高峰(刷视频，玩游戏)等，这类应用的数据源多来自固定且少数的几处。显而易见，静态内容分发可参考 NDN，不赘述，而动态直播分发采用组播的方式则更合理，可以从较新的有线电视网络技术中看到这一合理性。
令人遗憾的是，从现实出发，设备兼容性问题，拓扑限制，组播管理的复杂性，安全和认证风险，计费和版权问题几乎导致了组播似乎只能停留在文档阶段，限制了其大规模部署。人们每人各自拉取相同的流量，宁愿忍受拥塞卡顿风险。因此，互联网拥塞问题，短时间内不会有什么质的改变。
如果解决不了互联网架构问题，只能在 TCP/IP 层面做建议和优化，来看第二个问题，地址对称性的问题。
仅从技术角度看，无论 NDN 还是组播，都极大弱化了地址的概念，NDN 甚至不需要携带任何地址标识请求和数据的源和目标，因为内容获取是个匿名操作，同样，组播也没有明确的目标，组播地址标识的是一个感兴趣目标集合。只有对称操作才需要明确的源和目标，比如对等通信。
从这个视角再看 TCP，仅从 TCP 头看，它俨然一个对等通信协议，16 bits sport，16 bits dport，潜在的源和目标数量级是对等的，但另一方面，The TCP as a POST OFFICE，在协议操作上，TCP 又是一个 C/S 模型协议。这是一个从 1974 年 TCP 出世就自带的一个矛盾点，虽然看起来微不足道，但后续 "client 端口号不够用"，"timewait 太多新连接无法创建"，"syncookie 被触发"，"connect 热点" 等问题都源自于它。
来看一个我在上周的一个建议，展示协议头前 32 bits：
txt
16 bits：源端口
16 bits：目标端口，其中：
高 8 bits：服务实例号
低 8 bits：服务号目标端口的高 8 bits 在 SYN 报文中置 0，由 Server 确定，在 ACK/SYN 中返回，如果所有不可用或冲突，返回 RST。
这将允许两边在大得多的端口号空间(一对 IP 可用 32 bits 端口号空间)中确保四元组唯一性，这也是打破 Client, Server 端口号偏斜(源端口号比目标端口号紧张得多，目标端口号大量结余)的有效协议。
就好比去政务大厅办事，这个政务大厅就是目标 IP 地址，而税务服务则是目标端口低 8bits，假设它是 10，而你将等待叫号，叫到你的号码时会说第 31 号窗口为你服务，这个 31 就是目标端口高 8bits. 这就比以前那种一家人只能一人办事松弛多了，由服务器叫号分配窗口，而不是客户端自决。
注意，这不是要改 TCP，而且基于 UDP 实现新协议又不想改应用层(比如 QUIC)的一种建议，因为 UDP 和 TCP 的端口号在同一个位置。至于 SYN，只是个说法，但凡需要同步的协议，都有类似 SYN 的震铃信令。
实现中有很多花活儿，负载均衡之类的优化，但可对中间防火墙等 midbox 不友好。
同理，IP 协议也存在类似问题，在一个典型的 C/S 通信模型中，我们总是倾向于用短标识描述 Server，用长标识描述 Client，对非常核心的服务，甚至允许硬编码写死，比如 8.8.8.8，但我们知道，它是个 Anycast 地址，同样不必在乎具体它在哪。
用短的地址标识描述服务可以让对扫描等攻击行为的防护更加收敛，如果只有 8 bits 描述服务端口号，就不必在 16 bits 的防线上部署线性防御，取而代之的只需要轻量很多的纵深防御。
至于剩下的，按照 RFC817 建议，牛逼的协议三要素：
- 最小的传输成本，一个极简的头
- 最大的收发效率，快的硬件和算法
- 最少的资源完成上面两件事，一套极简的协议原语
浙江温州皮鞋湿，下雨进水不会胖。