本文将给出关于互联网架构演进的一个不同视角。回顾一下互联网的核心理论基础产生的背景：
左边是典型的集中控制通信网络，很容易被摧毁，而右边的网络则没有单点问题，换句话说它很难被全部摧毁，与此同时，分时计算机无法容忍 “占线”，它希望网络也是一个分时系统。如何同时处理多个来源的数据包的交织是一个实际问题，最后，莱昂纳德克莱因洛克通过排队论数学分析，使人们相信了分组交换网的可行性。
理论基础奠定后，时间来到 1970 年代，人们需要将概念工程化，TCP 诞生，但 IP 还没有。再次通过 RFC675 看 TCP 最初的样子，4.2 节展示了 TCP 格式：
8 bits: Internet information
2 bits: Reserved for local PSN use
2 bits: Header format (11 in binary)
4 bits: Protocol version number
8 bits: Header length in octets (32 is the current value)
16 bits: Length of text in octets
32 bits: Packet sequence number
32 bits: Acknowledgment number (i.e. sequence number of next octet expected).
16 bits: Window size (in octets)
16 bits: Control InformationListed from high to low order:SYN: Request to synchronize sending sequence numbersACK: There is a valid acknowledgment in the 32 bit ACK fieldFIN: Sender will stop SENDing and RECEIVEing on this connectionDSN: The sender has stopped using sequence numbers and wants to initiate a new sequence number for sending.EOS: This packet is the end of a segment and therefore has a checksum in the 16 bit checksum field. If this bit is not set, the 16 bit checksum field is to be ignored. The bit is usually set, but if fragmentation at a GATEWAY occurs, the packets preceding the last one will not have checksums, and the last packet will have the checksum for the entire original fragment (segment) as it was calculated by the sending TCP.EOL: This packet contains the last fragment of a letter. The EOS bit will always be set in this case.INT: The sender wants to INTERRUPT on this connection.XXX: six (6) unused control bitsOD: three (3) bits of control dispatch:000: Null (the control octet contents should be ignored}001: Event Code is present in the control octet. These were defined in section 2.4.3.010: Special Functions011: Reject (codes as yet undefined)1XX: Unused
8 bits: Control Data OctetIf CD is 000 then this octet is to be ignored.If CD is 001, this octet contains event codes defined in section2.4.3If CD is 010, this octet contains a special function code as defined below:0: RESET all connections between Source and Destination TCPsl: RESET the specific connection referenced in this packet2: ECHO return packet to sender with the special function code ECHOR (Echo Reply).3: QUERY Query status of connection referenced in this packet4: STATUS Reply to QUERY with requested status.5: ECHOR Echo Reply6: TRASH Discard packet without acknowledgment>6: UnusedNote: Special function packets not pertaining to a particular connection [RESET all, ECHO, ECHOR, and TRASH] are normally sent using socket zero as described in section 3.2.If CD is 01l, this octet contains an as yet undefined REJECT code.If CD is 1XX, this octet is undefined.
# 4 bits: Length of destination network address in 4 bit units (current value is 1)
# 4 bits: Destination network address1010-1111 are addresses of ARPANET, UCL, CYCLADES, NPL, CADC, and EPSS respectively.
# 16 bits: Destination TCP address
# 8 bits: Padding
# 4 bits: length of source network address in 4 bit units (current value is 1)
# 4 bits: source network address (as for destination address)
# 16 bits: Source TCP address
# 24 bits: Destination port address
# 24 bits: Source port address
16 bits: Checksum (if EOS bit is set)
看上去和现在的 TCP 一点都不一样，当时 TCP 和后来的 IP 是同一个协议，统称 TCP。第 41 行开始(我做了 # 标记)的字段与寻址有关，早期并没有采用固定 32 位地址，而采用了一种非常变通的方式：
- 4bits 指示网络地址长度，16bits 寻址该网络内的具体 TCP 实体。
我们知道，“16 bits: Destination TCP address” 标识的 TCP 实体其实就是主机地址，但在当时，一个 TCP 就表示一个主机，因为没别的协议。接下来的 24bit 端口有点意思，我们知道最终它变成了 16bit，用于多路复用和解复用。
在 1980 年 RFC760 和 RFC761 试图分离 IP 并标准化 TCP/IP 时，考虑到当时的实现开销(慢 CPU，小内存)，变长地址转向固定 32bit，即 IP 地址，这一切终于在 RFC791 和 RFC793 中最终被标准化，就是 TCP/IPv4。
回顾互联网早期历史时，虽然分时系统已经预见了后来的 PC 以及随之而来的内容分发时代迟早到来，但畅想归畅想，在实践中仍然倾向于换一种方式 “打电话”，这更实际，所以我们看到 1974 年的 TCP 是一条虚电路，建立 TCP 连接带着浓厚的 “呼叫”，“连接” 的味道(细看 SYN，ACK/SYN[是这个顺序，而不是 SYN/ACK]，ACK)。
至于 IP，它只是从 TCP 剥离出来的一个极其稳定的平台，极其稳定的原因是它极其简化，它甚至没有任何语义，但在本质上，IP 依旧源自于 “呼叫”，IP 互联的意思是，基于 IP 之上端到端传输层协议的点对点互联，一个 IP 地址与另一个 IP 地址之间的 “通信”。换句话说，IP 不负责 “打电话的方式” 这种复杂的带有逻辑的语义，但 IP 地址似乎就是 “电话号码” 本身。
离开 TCP/IP 转向底层分组交换传输网络，我们发现无论是 X.25，帧中继，还是 ATM，都可归为 “用分组交换的方式打电话”。当我们说 ATM 带有电信的影子时我们在说什么，这个问题很有趣。
分组交换传输网络转发方案分为两大阵营，分别为利用路由器内转发状态(流表)的电信阵营和利用数据包中转发指示(地址)的互联网阵营，前者成员直接或间接传承传统电话电信系统(ITU)，典型作品为 ATM，后者则来自相对较新的开放组织(IEEE/IETF)，典型作品为以太网，TCP/IP。下面简述它们彼此争论的核心过程和结果。
我们现在知道，ATM 以及其它虚电路传输技术都是分离后 IP(即 RFC760 之后) 的反面，看清 IP 后反着看就看清了它们所有。IP 是无状态，尽力而为(best-effort)的，这意味着路由器不保留任何包或流状态，所有寻址信息都在数据包本身(即 IP 头)，路由器仅执行 SPF 逐跳转发。那么反过来，ATM 等网络就是在交换机保存状态，数据包中携带一个短标识，该标识可以理解为交换机中保存状态的索引，即虚电路标识。虚电路网络基于虚电路标识的转发本质上就是 “标签交换”。
虚电路网络采用有状态交换的好处之一就是 QoS 非常容易实现，有句话说得好，IP 从诞生到现在一直在想办法支持 QoS，而 QoS 一直是虚电路网络的核心原则。
IP 除了无状态交换，其数据包的大小是可变长的，这加剧了时延和抖动的不确定性，对于电话系统的设计者或受其影响的网络工作者而言不可接受，那么自然而然的，固定大小的信元交换就成了这类虚电路网络的核心特征。衍生自电话系统的设计，虚电路信元足够短，这样才能支持足够细粒度的信元调度，以确保低时延和低抖动，既然信元足够短，支持相对大的头(比如 IP 头)就显得昂贵，这又反过来催使信元交换网络必须采用有状态交换，每个信元中的地址只是一个简单的表索引，而不是索引匹配的目的地址，所有的信息都在交换机中。
你看，信元交换和有状态网络是相辅相成，相互加强的。相对应的，IP 的无状态交换和变长包也是相辅相成的。
最后，在一种朴素的哲学意义上，任何相对立的事物最终都会出现某种融合，MPLS 就是典型例子，在变长的数据包而不是定长的信元上使用标签交换。另一个更加激进的融合实例是 IP NAT，它本质上也是标签交换，只不过它交换的是 IP 地址本身。
以上我们看到，无论从 TCP/IP 还是底层传输网络来看，“呼叫”，“连接” 是早期互联网的核心，但随着 1980 年代后期到 1990 年代全面进入 PC 时代后以及随着 Web 的发展，“呼叫” 网络逐渐开始变成 “内容” 网络，在这种网络中，一台计算机程序 “呼叫” 另一台计算机程序是非常奇怪的，取而代之更合理的是多台计算机作为客户端从少数服务器上 “获取内容”。这导致了前面的文章 TCP Listen 语义与端口失衡 里提到的源端口和目标端口数量偏斜以及与之相关的一系列问题，我也给出了相应的 work around，但在这里，我用更抽象的描述重述同一件事。
TCP 可分为两类，作为内容服务的 Anycast TCP 以及作为通信连接的 Unicast TCP：
- 内容 TCP：非对称连接，dport 高 8bit 作为 Anycast 服务进程索引(比如 hash 索引)，低 8bit 做 Anycast 地址索引服务类型；
- 通信 TCP：对称连接，一对一通信，类似呼叫类服务，打电话，远程登录等。
无论哪一种，都并非一定需要 Listen，注意，Listen 是 Socket 的，不是 TCP 的。内容 TCP 请求可以直接定向到服务进程，而通信 TCP 请求可以执行唤起服务进程的操作，类似 Unix 系统中 “振铃” 服务，而 sip + sport 和 dip + dport 可视作主叫和被叫的 “电话号码”，这就很类似 fork + exec 操作，只是为了实现这个操作，Listen + Accept 非常合适而已。
但 work around 总归治标不治本，这是因为 TCP 甚至整个 TCP/IP 协议族本就不适合内容分发，它最初是为全球 IP 互联互通的 “呼叫” 和 “连接” 创立的，但后面的发展表明，类似 Web 这种多对一的 C/S 内容分发应用才是互联网上最流行的，NAT 之所以可行并大规模铺开，反面印证了内容分发模式应用确实是普遍的，否则如果真的都是一对一通信应用，NAT 根本无法部署实施。
映射到现实世界，人们去商超购物，去影院看电影，去饭店吃饭这种出入公共场所的频率远大于去私人家登门拜访的频率，而出入公共场所和出入私人家最本质的区别有两个：
- 公共场所不需要登记人们是谁或来自哪里，但私人拜访需要；
- 公共场所不挑地址，比如连锁店去最近的那家即可，但私人拜访必须去固定地址。
映射回互联网络架构，这导致专门用于内容分发的网络被提出，即 NDN(Named Data Networking)，这是一种以内容为中心的网络，人们只关心获取的内容，并不关心该内容来自哪里，同时，内容提供者也过度不关心请求者来自哪里。
NDN 是一种非常激进的网络架构，它要求路由器记录每包状态，却不强制每包内含任何地址信息，同时，它建议路由器缓存它能尽力缓存的一切内容，比如被很多人请求频率很高的内容。
包中没有地址如何路由，还记得虚电路如何做的吗，包中有个虚电路标号，索引交换机的状态表即可，对应于 NDN，包里有个 “内容名字”，索引路由器中的状态表即可：
如果本地没有请求名字对应的内容，路由器如何知道内容在哪里呢？这涉及到 NDN 复杂的技术细节，比如沿途路由器可以自学习机制，学习过路名字/内容对所对应的端口，或者直接泛洪，还有一种可能就是内容提供者主动泛洪或自定义推送，类似商场搞活动时沿途发传单推销，传单上印有店铺地址。
至于路由器如何缓存内容，主要看内容的流行度，重要程度以及一些自定义策略。
NDN 延续了 TCP/IP 成功的沙漏模型，保持了沙漏形状的架构，但用数据名字代替 IP 地址进行数据传输。增加路由器的缓存功能也在情理之中，TCP/IP 的年代存储部件小且昂贵，如今不同了。
NDN 是天然的静态内容分发网络，它和现实世界是高度拟合的，在内容的自然选择下，最流行，最重要，流量最大的内容总会在离人们最近的边缘节点被缓存，这就是一个无需 GSLB 的 CDN 网络。至于动态内容，它天然就是一个扇入系统，自带拥塞属性，类似直播的流量几乎就是现实世界演唱会，大型集会的翻版。
由于 CDN 的高速发展和全面部署，回源被聚拢在 CDN 内容提供商极其粗壮的内网，掩盖了传统 TCP/IP 的大多数问题，使 NDN 网络始终停留在概念，但它的理念无疑是先进的，从 NDN 先进的内容分发理念的意义上说，CDN 只是一个 work around，比如它始终解决不了最后一公里拥塞问题，因为本质上 CDN 仍是一个多对一访问系统，而 NDN 会将内容推向离多个用户更近的多个位置，没了带宽竞争，问题自然消失，交易则是用存储成本自动机交换独享内容带宽。
NDN 是一种完全不同于 TCP/IP 并与之并列的网络架构，它甚至不使用 IP 这个稳定的平台。如果说 TCP/IP 适用于点到点通信，它本质上还是一个通信网络，那么 NDN 就是一个专门的静态内容分发网络，非常适用于 Web。如果 1960～1970 年代网络从理论，概念到工程化的时期，内容分发已经比打电话，远程登录，互传文件更流行了，那么可想而知，如今的互联网架构大概率就是 NDN 或与之类似的，它可能仍叫 TCP/IP，但含义将完全不同。
醉过风，喝过茶，没得英雄名讳，掂量个旧事抵酒价，在座皆算老友，碗底便是天涯，作罢。
浙江温州皮鞋湿，下雨进水不会胖。