在1974年Cerf和Kahn发表那篇奠基性的《分组网络互联协议》时，TCP（Transmission Control Program）还是一个浑然一体的单体协议。在这个最初的设想中，TCP不仅要负责“把数据包送到哪里”（路由与寻址），还要负责“确保数据包安全到达”（传输控制、纠错、排序）。这种设计在同构网络中运行尚可，就好比一家只送挂号信的邮局，每一封信都必须被追踪、确认回执。然而，当ARPA的研究人员试图将这种设计推向更广阔的异构网络——特别是包含卫星网（SATnet）和无线电网（PRnet）的复杂环境时，这种“大包大揽”的设计立刻撞上了南墙。问题的核心在于可靠性与实时性的根本冲突。在1977年的三网互联实验中，研究人员（特别是Danny Cohen）发现，如果你想在网络上跑实时语音（Voice over Packet），TCP那种“丢包必须重传”的强迫症逻辑简直是灾难。

试想一下，你在打卫星电话，中间丢了0.5秒的音节。如果按照TCP的逻辑，系统会暂停后续的播放，直到那丢失的0.5秒被重新传回来。结果就是，你听到的不是流畅的对话，而是一段段被严重延迟、顺序错乱的“鬼畜”音频。对于语音通信而言，“当下的残缺”远比“迟到的完美”更重要。为了解决这个矛盾，Vint Cerf、Jon Postel和Danny Cohen在1977年决定对这个单体协议进行一场“外科手术”。他们将TCP劈开，剥离出了一个轻量级的、甚至是“不负责任”的底层协议——IP（Internet Protocol）。这个3人组将原本的TCP协议分为了两个协议，第一个是TCP协议只管控制，第二个是IP协议只管找路——因此TCP的控制能力也从最早的重连演变为拥塞控制算法，而基于IP协议发展一系列不再要求控制的协议，也包括了今天的UDP。

由于这个TCP协议的版本为v4，独立出来的IP协议也就是IPv4。既然有IPv4和IPv6，那么IPv5呢？1979年IPv4才刚拆分的时候，IPv4的主要贡献者Danny Cohen就和Estil Hoversten、James W. Forgie一起提出了因特网流协议（Internet Stream Protocol），顾名思义这个协议专门用于处理音视频的数据流，并且和IPv4一样处于平级——其核心思想是让路由器意识到这个是一个重要的数据，必须要尽量保持——和UDP的无状态、无控制的思路完全不同。之所以会有这种需求，就是因为军方对于TCP传输中重连过程导致语言通话卡顿表示不满，并且在语音通讯和雷达传输中可靠性并不如及时性重要。在1980年代，ST以及其演变的ST-II（1987年）曾经是音视频传输的主流协议之一，然而在今天其地位以及被UDP/IP所取代。虽然ST协议从来没有被冠名以IPv5，但是其和IPv4共用了数据链路层协议号和IP地址结构并以协议号5封装，实际上在传输中就是IPv5。

IPv4的缺陷和NAT

众所周知，IPv4有一个重大缺陷就是地址数量不足。设计者选用了32位地址空间（$2^{32}$），理论上提供约43亿个地址。 在1970年代，这是一个天文数字。Vint Cerf曾打趣说：“当时我想，这只是个实验，43亿地址做实验总够了吧？”然而，他们没预料到个人电脑、智能手机乃至物联网的爆发。按照最初的分类（A/B/C类地址），大量的地址被豪爽地分配给了早期的大学和公司（例如MIT和IBM都各自拥有极其庞大的A类地址段），导致地址资源在90年代就出现了分配不均和枯竭的危机。这也为IPv6的出现埋下了伏笔。

此外由于早期IPv4地址分配缺乏层级规划，路由器也不得不维持一张庞大的路由表来记录通往海量地址的路径，为此不得不提出了CIDR来压缩路由表的大小。另外，IPv4缺乏服务质量的控制，它像一个没有VIP通道的拥挤地铁站，不管是性命攸关的远程手术数据，还是无关紧要的垃圾邮件，在路由器面前一视同仁。虽然IPv4头部设计了ToS（服务类型）字段，但在实际工程中，这个字段长期被路由器忽略。直到后来，随着流媒体和VoIP的兴起，人们才不得不通过各种复杂的手段（如DiffServ）来模拟QoS。

为了解决IPv4的地址稀缺，NAT横空出世并很快在IPv4的世界中占据了重要的地位。NAT的核心逻辑是一种精密的“欺骗”。它打破了互联网设计之初神圣的“端到端”（End-to-End）原则——即世界上的每一台设备都应拥有一个独一无二的公网IP，能够直接被访问。NAT允许一个家庭或公司内部的成百上千台设备共用私有IP地址（如熟悉的192.168.x.x），而在连接互联网的出口处，路由器会将这些私有地址统一“伪装”成一个或少数几个公网IP。

  • 出站时：路由器擦除数据包中的源私有IP，换上自己的公网IP，并记录在案。

  • 入站时：路由器查表，将回传数据包的目标IP改回对应的私有IP，精准投递给内部设备。

为了区分内网中通过同一个公网IP上网的不同设备（比如张三和李四同时访问百度），NAT进化出了NAPT（网络地址端口转换）。路由器利用端口号（Port）作为区分标识，为内网的每一个连接分配一个唯一的公网端口。这张庞大的映射表（NAT Table）成为了路由器的核心机密，确保了数据流的井然有序。

P2P技术如何解决NAT问题

在NAT环境下，内网设备是“隐形”的。外部无法主动发起连接，这使得点对点通信（如早期BT下载、联机游戏）变得异常困难，工程师们被迫发明了STUN、TURN等一系列复杂的“打洞”技术来穿透NAT。路由器本应工作在网络层（第3层），只看IP地址。但NAPT为了区分设备，不得不“越级”拆开传输层（第4层）的包头查看端口号，这增加了处理负担，也违背了分层解耦的设计初衷。为了解决这种问题，UDP Tunneling和P2P技术应运而生。

P2P打洞的核心在于解决“可见性”与“连通性”的矛盾。在NAT环境下，内网设备对于外部世界是不可见的，Peer A无法直接向Peer B发起连接，因为Peer B躲在路由器的防火墙之后。为了解决身份认知的问题，工程师们首先引入了STUN（Session Traversal Utilities for NAT）协议。这是一个位于公网的第三方服务，它的作用类似于一面镜子——内网设备连接STUN服务器，询问“我是谁？”STUN服务器则回复路由器分配给该设备的公网IP和端口号。一旦Peer A和Peer B通过这种方式获知了各自在公网上的“伪装身份”，它们就具备了建立连接的先决条件。

然而，仅知道地址并不意味着大门就会打开。大多数NAT路由器遵循“限制性锥形”或更严格的规则：只有内网设备主动向外发送过数据，路由器才会允许该外部地址的回传数据通过，否则一律视为攻击并丢弃。P2P技术利用这一规则，发明了被称为“打洞”（Hole Punching）的技术。其过程充满了博弈的智慧：Peer A和Peer B在服务器的协调下，几乎同时向对方发送一个UDP包。对于Peer A的路由器来说，虽然Peer B发来的第一个包会被拦截，但Peer A发出的包会在自己的防火墙上打出一个“洞”（即建立一条允许Peer B进入的映射记录）；同理，Peer B也为Peer A打了一个洞。当双方的第二个数据包到达时，路由器会误以为这是对自己发出请求的“合法回应”而予以放行。至此，一条穿越两层NAT的直接通道就被建立起来了，数据不再需要经过中心服务器中转。

当然，工程现实远比理论复杂。对于那些采用“对称型NAT”（Symmetric NAT）的路由器——即针对不同目标IP分配不同端口的严苛设备——打洞战术会彻底失效。在这种绝境下，P2P通信只能退回到最后的防线：TURN（Traversal Using Relays around NAT）。这是一种妥协，既然无法直连，就通过一个拥有公网IP的中继服务器来转发所有数据。虽然这保证了100%的连通性，但却牺牲了P2P技术最引以为傲的低延迟和分布式带宽优势，重新退回到了依赖中心化资源的老路上。

为了在复杂的现实网络中自动选择最优路径，IETF最终制定了ICE（Interactive Connectivity Establishment）标准，将STUN的探测、打洞的尝试和TURN的中继整合为一套标准流程。这套复杂的机制证明了互联网协议的韧性，但也是一种无奈的注脚：为了对抗NAT对端到端原则的破坏，我们不得不在应用层构建一套极其复杂的补丁系统，以此在一个支离破碎的网络层之上，强行拼凑出一个逻辑上互联互通的对等网络。