互联网技术漫谈(五): 如何看待IP协议的那些不足?

2020年05月06日 17:04 来源:亚太网络研究APNet 作者:李丹

1、对IP协议的常见“非议”主要有哪些?

2、IP协议的设计目标不全吗?

3、IP协议的技术存在缺陷吗?

4、IP协议需要不断迭代有问题吗?

5、总结

不知道从什么时候开始,IP协议似乎一下子成了“过街老鼠”。只要做“互联网”(“网络”)体系结构研究,一定要对IP协议(或者是对“已有”的IP协议)批一通,然后一个新的架构横空出世,针对“IP协议”和“互联网”的各种新名词层出不穷。而我们的科研环境,也总是喜欢听到有这些“新网络架构”出现,否则就感觉不算网络研究的创新。这篇文章,我们就来讨论应该如何看待IP协议的那些“不足”?基于IP协议进行互联网体系结构的研究到底算不算创新?

1、对IP协议的常见“非议”主要有哪些?

对于IP协议的“不足”,往往最常见的是以下几种说法。

1)设计目标不全:IP协议没有服务质量保障,不适合于许多要求高带宽、低时延、确定性时延的业务;IP协议是为了静止的主机而设计的,不适合于移动互联网时代;IP协议在设计时缺乏安全性考虑,没有支持网络“内生安全”。

2)技术存在缺陷:主要是针对“尽力而为”的转发方式以及“基于IP地址的寻址方法”存在的问题。

3)需要不断迭代:IP协议“修三年、补三年,修修补补又三年”,这样不断打补丁的方式不好,需要另外设计互联网协议。

4)时间过于古老:IP协议是上世纪70年代设计的,已经不适合于今天的互联网。

5)其他国家反推:人家美国或者欧洲都在搞“未来互联网”/“未来网络”研究,说明IP协议确实有问题。

6)反正就是不好:“众所周知,IP协议存在很多缺陷”。

批评总是比反思来得容易;但没有反思的批评,就显得很廉价了。对于后3种非技术的论调,因为太容易反驳,咱们就不讨论了。下边我们重点从“设计目标不全”、“技术存在缺陷”、“需要不断迭代”这三个方面来探讨,看看IP协议是不是真的那么不堪?

2、IP协议的设计目标不全吗?

要理解IP协议是否存在设计目标不全的问题,首先要看IP协议的核心设计目标到底是什么?然后再看看服务质量保障、移动性、安全性等目标是否可以放到与核心设计目标等同的位置?

2.1 IP协议的核心设计目标是什么?

IP协议的全称是“互联网协议”,它的核心设计目标自然就是要体现互联网的核心使命。我们在之前的几篇文章已经讨论过,互联网技术就是为了实现大规模“网际互联”(Internetworking)的想法而诞生的,IP协议是实现“网际互联”的最重要的技术。关于IP协议最初的设计动机,有兴趣的读者也可以去读一下David Clark先生发表于SIGCOMM 1988年的论文:“The Design Philosophy of the DARPA Internet Protocols”。其中明确地写到互联网最重要的设计目标。“The components of the Internet were networks, which were to be interconnected to provide some larger service. The original goal was to connect together the original ARPANET with the ARPA packet radio network, in order to give users on the packet radio network access to the large service machines on the ARPANET. At the time it was assumed that there would be other sorts of networks to interconnect, although the local area network had not yet emerged.”在 “互联网”这个想法诞生的时候,世界上甚至连“计算机局域网”都还没有。因此IP协议的核心设计目标非常单纯,就是“开放与互联”;并不只是对当前已经存在的“网络”互联(更不是对“计算机”互联),而是要把将来可能存在的“网络”都互联起来。如果IP协议不以“互联”作为最核心的设计目标,“互联网”就不能叫“互联网”了。

关于IP协议在“网络互联”方面的目标,有兴趣的朋友还可以参考RFC 1287“Towards the Future Internet Architecture”(1991年)。其中明确提到:“The Internet architecture needs to be able to scale to 10**9 networks.”“The exponent “9” is rather fuzzy; estimates have varied from 7 to 10.”也就是说,在1991年讨论未来互联网体系结构的时候,明确提到希望将来的互联网能把大概10亿个“网络”互联(注意:不是10亿个“节点”)。从这一点,也可以看出IP协议在“网络互联”方面的压力有多大。尽管在IP协议设计之初需要互联的“网络”数量非常少,而且今天IP协议所互联的“网络”数量也远小于10亿,但“互联网”的设计目标就是为了扩展到非常大的网络数量,这是互联网存在的终极意义。今天不断涌现的各种“网络”的新名词,如物联网、工业互联网、卫星互联网、能源互联网、金融互联网、家庭网络、个域网等,也充分说明了未来需要互联的“网络”数量是非常多的。IP协议的首要目标就是要把这些为数众多的“网络”都“互联”起来。

IP协议对互联网“开放与互联”这一核心目标到底实现得如何呢?我想绝大部分人的答案都是一样的:完美得超出预期。今天世界各国那么繁荣的互联网产业,那么多互联网应用领域的巨头公司,就是最好的明证。通过IP协议,互联网不但连接了世界上许多的计算机网络,而且还连接了电信网。“网际互联”这一伟大构想,对人类社会的生产力带来了空前的解放,无数行业被互联网改造,我们随时都可以听到“互联网思维”、“互联网哲学”这样的词汇,我国在2015年还推出了“互联网+行动计划”。但要注意的是,当前互联网所取得成就,仅仅是把计算机网络互联、以及和电信网连接的结果,并非是互联网发展的终点。

当然我们可以问,对“开放与互联”这一核心目标(先不说其他目标),IP协议就一定是最好的选择吗?如果历史回退到互联网诞生的起点,我们还能找到比IP协议更好的技术嘛?这个答案很简单:也许能,也许不能。IP协议以及当前的TCP/IP协议栈的成功确实有多方面的原因。但历史不容假设,IP协议和TCP/IP协议栈已经成功地运行了几十年。在足球领域有句名言:“一直赢球的队伍,是不会更换首发阵容的”。作为互联网规模高速扩展背后的技术引擎,要更换它、替掉它,势必要进行更严谨的论证。而且新的技术一定是围绕“开放与互联”这一核心使命来提的,一定是针对IP协议在“无连接”、“分组交换”、“尽力而为的转发”、“基于IP地址的寻址”这几个方面的根本特征来进行改善或替换的。

2.2、能把IP协议的其他设计目标跟“开放与互联”这一核心目标放在“并列第一”的位置吗?

我们接下来可能会问,就算“开放与互联”是IP协议最重要的设计目标,那“服务质量保障”、“移动性”、“安全性”等目标是否可以处于与“开放与互联”同等重要的位置呢?如果能放到同等重要的位置的话,那就不能只优化“开放与互联”这一目标了。我们下面就来讨论“开放与互联”这一设计目标与其他几个目标之间的关系。

1)“开放与互联”和“服务质量保障”之间的关系

“服务质量保障”指的是网络为业务/用户提供确定的带宽、时延、抖动和丢包率。不能提供“服务质量保障”,是IP协议被诟病最多的一点。在第四篇文章我们也讨论过,由于互联网把“开放与互联”作为最重要的使命,采用完全分布式的架构,对用户和流量没有准入控制,因此不可能实现像电路交换中一样的严格“服务质量保障”,只能采用“尽力而为”的转发方式。

互联网带宽总是有限的,而用户和业务的数量是巨大的。假设互联网当初真的采取了严格保障服务质量的做法,也许我们今天体验到的互联网服务会是这样的。我们正准备打开QQ和一位好友聊天,互联网提醒你:“抱歉,互联网带宽正在保障其他用户的服务质量,请您稍后再来聊天”;我们兴致勃勃地看了李佳琦的带货直播,然后打开一个链接去购物,互联网提醒你:“抱歉,互联网带宽正在保障直播业务的服务质量,暂时无法为您提供购物服务”。试想一下:如果是这样的互联网,能发展成今天这样的用户规模和业务规模吗?“尽力而为”的转发,意味着大家都起码能至少用一点互联网资源,不至于被互联网直接“禁入”、“拒绝”。这对于互联网实现“开放与互联”的使命非常重要。

话虽如此,IETF其实也一直在做各种服务质量保障的技术标准,包括IPv4的ToS字段和IPv6的Traffic Class字段,MPLS、DiffServ、AQM,以及最近比较热门的确定性网络(DetNet)等技术。但这些标准并未提供“严格”的服务质量保障。有些是给流量分成了很多优先级,在路由器上进行优先级调度,但每个优先级内部还是“尽力而为”的;假设所有用户/业务都给自己打成最高优先级,其实也就回退到完全的“尽力而为”了。有些是更好地为业务选路,但选定路径之后还是“尽力而为”地转发的。“确定性网络”技术的一个重要前提假设,是互联网中大部分流量还是只需要“尽力而为”的,因此可以为少量特殊业务提供“确定性时延”。我对“确定性网络”的应用前景持保留态度,因为一旦开了先例,每个用户/业务都可以把自己标记成特殊的,而互联网是不可能保障所有的业务都获得“确定性时延”的。

我们也可以看到,尽管IP协议一直没有提供严格的“服务质量保障”,IP协议支持的业务却越来越多;语音、视频等业务,以前都被认为是很难通过IP协议来支持的。IP协议为什么能做到呢?我认为主要原因有两点:第一,互联网带宽的增长。这不用说了,总盘子大了,每个人能分到的自然多一些。第二,端系统应用程序的各种解决方案,比如DASH (自适应流媒体传输)技术,通过自适应网络带宽来调整流媒体的码率,从而更好地支持流媒体传输应用。而这一点又恰恰得益于IP协议的极简化设计,把丰富的功能留给了端系统。有理由相信,未来会有更多的我们原以为“尽力而为”的IP协议难以支持的业务,同样可以在互联网上运行地很好;也许其“服务质量”并不那么完美,但因为最大程度地实现了“开放与互联”,其实际效果可能会好得多(梅特卡夫定律)。

当然我们还可以继续“挑战”,我的业务就是要超高的服务质量,互联网满足不了我怎么办?这种情况下,也有一个互联网技术,就是RSVP,为某些特定用户或应用预留带宽。我一直把RSVP协议理解成互联网技术在服务质量保障方面做出的一个巨大妥协,因此今天RSVP并没有在互联网的大网上广泛使用。如果对某个应用或业务,RSVP还是无法保障其服务质量,那就只能自己铺光纤或建一个“专网”了。互联网是公众网络,从来不是为某些特定业务或特定用户而设计的,考虑的永远是大部分人/大部分业务的需求,否则无法实现其“开放与互联”的使命。

2)“开放与互联”和“移动性”之间的关系

对于IP协议在“移动性”支持方面的批评,其实大部分时候指的都是 “节点”的移动性。但我们讨论过,互联网技术本身关注的网络之间互联的问题,并不特别关注“节点”的移动,因此WiFi标准是在IEEE制定的,而不是在IETF制定的。并且WiFi技术与蜂窝网技术相比,其根本的不同来自于频谱分配的不同,导致WiFi的覆盖范围较小(与4G以前的电信网相比)。

如果节点的移动跨越了不同的网络,会造成节点IP地址的变化,可能会影响正常通信;如果要保持原来的IP地址的话,就得更新互联网的路由信息,这就与互联网有关了。因此IETF定义了Mobile IP标准解决这一问题。尽管这一解决方案并不完美,可是我们知道,这同样是由于互联网“分布式控制”的原因带来的。不同的WiFi网络,本就属于不同的计算机局域网,都是被互联网所“互联”的“网络”之一,在网络之间进行移动性切换的时候肯定会有一些困难。为什么电信网不存在这个问题呢?因为电信网是集中控制的,就算打电话时手机跨基站移动,但毕竟属于同一个管理主体,在移动切换上也存在更有效的处理办法。

因此我们可以看到,当前批评者们所指出的IP协议“移动性”的问题,要么与互联网无关,要么是由于互联网“开放与互联”的核心使命所导致的“分布式”管理机制所带来的,都与IP协议没有直接的关系。尽管如此,互联网技术也一直在通过各种方法提升移动性体验,比如为了克服IP地址同时作为节点身份标识和节点位置标识的问题,IETF制定了HIP(Host Identity Protocol)协议标准。虽然WiFi技术标准本身不属于IETF关注的范围,但2019年推出的WiFi 6 技术,由于获得了新的频谱,与之前的WiFi相比,将会极大提升用户的性能和体验。

3)“开放与互联”和“安全性”之间的关系

ISOC主页上清楚地写着,互联网的使命是“开放、互联、安全、可信”。这里我们就不再区分“安全”与“可信”的技术内涵了,都用广义的“安全性”来概括。不止互联网,对于任何系统来说,“安全性”都是一个重要的设计目标,但它始终是一个“伴生”技术,一般不会成为首要的设计目标。道理很简单,如果要追求系统的极致安全,那就不要设计这个系统,因为这样最“安全”。

关于互联网的“安全性”,不得不提到最近很热门的“内生安全”技术。我对“内生安全”的理解是,系统在设计上需要把系统内的安全因素考虑进来,而不是在产生安全问题之后全部推给系统之外去处理。但如果“内生安全”指的是把安全作为系统的首要设计目标,或者说要设计一个永远不会产生安全问题的系统,这个恐怕不现实。

总结以上三个方面的讨论。对IP协议的设计来说,“服务质量保障”和“开放与互联”的核心设计目标在本质上存在冲突,“(节点)移动性”不属于IP协议要解决的问题,“安全性”是排在“开放与互联”之后的伴生目标。因此我们不可能把“服务质量保障”、“移动性”、“安全性”放在和“开放与互联”同等重要的目标上考虑。互联网的设计目标,只能是首先围绕“开放与互联”来优化,并在此基础上,尽量优化其他几个设计目标。如果只拿着“服务质量保障”、“移动性”和“安全性”这几个方面的问题来批判IP协议,却拿不出更好的实现“开放与互联”目标的技术,就显得“本末倒置”、“因噎废食”了。

3、IP协议的技术存在缺陷吗?

IP协议的核心技术,主要有几点:“无连接”、“分组交换”、“尽力而为”的转发、基于“IP地址”的寻址。当前对IP协议的具体技术的各种批评中,很少有批判“无连接”和“分组交换”的,主要是针对“尽力而为”的转发和基于“IP地址”的寻址这两个方面。下面分别讨论。

3.1 “尽力而为”的问题

“尽力而为”和“服务质量保障”其实就是一对对立的概念。关于互联网无法提供严格“服务质量保障”的原因,在第2节已经阐述,不再重复。这里再补充一点,“尽力而为”绝对不是互联网“不作为”的选择,而是“有作为”的追求。举一个例子。在互联网协议设计早期,TCP和IP是合为同一个协议的,就是“TCP/IP”。因为当时的考虑很简单,“可靠性”应该是任何一个应用都会需要的基本服务啊!可是很快,互联网设计者们就反应过来,我们不应该对互联网上的应用做任何假设,就连“可靠传输”这种需求都不能假设;甚至“可靠传输”会干扰到某些应用的正常运行,比如远程Debug。于是,TCP和IP才分裂为两个不同的协议,并且增加了UDP协议(只对IP做了简单的封装,仅仅满足不同应用程序端口复用这一需求)。从这个例子可以看出,“尽力而为”这一看似简单、带有“负面”感情色彩的选择,其实是仔细考虑之后主动选择的结果。“尽力而为”不但最大程度地实现了互联网的“网际互联”目标,而且催生了各种以前意想不到的互联网应用。对这段历史感兴趣的朋友,可以去阅读David Clark先生发表于SIGCOMM 1988年的论文“The Design Philosophy of the DARPA Internet Protocols”,里面有详细的描述。

除此之外,“尽力而为”与“服务质量保障”之间的关系,还可以从另一个角度来理解:对于一个网络系统的设计,到底应该“业务”适应“网络”,还是应该“网络”适应“业务”?互联网选择了让“业务”适应“网络”,因为互联网的首要目标是让尽可能多的“网络”互联起来;但为了最小程度地限制业务种类,互联网采用了“尽力而为”的极简设计方式。而作为对比,电信网选择了让“网络”适应“业务”,因为电信网的首要目标是提供更好的业务;为了满足业务的需求,网络必须要有“服务质量保障”。

当前反对IP协议“尽力而为”的提案,大多来自于各种行业网络。由于行业网络往往具有独特的业务需求,因此总希望能有一定程度的“服务质量保障”。如果仅仅着眼于行业网络的内部互联通信的话,这种需求无可厚非,可以基于IP协议进行改善,但这种改善不可能形成“互联网”的技术标准(当然可以另外搞一套针对该行业网络的协议标准,但就不能叫“IP”了)。但进一步想,任何一个行业网络,如果能着眼于长远价值而非眼前需求、着眼于全局优化而非局部利益,采用标准的“互联网技术”加入“互联网”,可能会带来大得多的收益。因为互联网的发展历史表明,业务总是能以各种方式适应网络,而网络规模扩张的价值,是不可替代的。

3.2 “IP地址寻址”的问题

再来看看针对“基于IP地址的寻址”的批评。目前看到的所有关于未来互联网的方案中,只有ICN(内容中心网络)/NDN(命名数据网络)是针对这一问题来提出新方案的。

要理解这个问题,必须先了解互联网的寻址体系。所谓“寻址”,就是以什么方式找到互联网的“通信对端”。我们今天的互联网是怎么操作的呢?必须先知道“通信对端”的“域名”(容易记忆和表达的一串字符);然后通过DNS系统把“域名”解析为“IP地址”(通信对端在互联网空间的位置标识);然后就可以发送报文了。这里其实有个问题:如果我们想要获取的内容在互联网的多个“位置”都能提供,为什么一定要求访问者首先提供“域名”呢?访问者能否只提供“内容”的标识,然后互联网自动选择一个合适的“位置”来提供这项服务? ICN/NDN就是针对这个问题来提出的。访问者只需要以“内容标识”来请求服务,路由器以“内容标识”把该项请求自动路由到“最近”的或“最优”的内容提供者处。这样,访问者就不用关心到底由哪个内容提供者来提供这项服务了,甚至路由器本身都可以直接从“缓存”中回复请求。

根据以上表述可以看出,ICN/NDN改变的,是互联网与用户之间的“人网接口”,到底是以内容提供者的“域名”为接口,还是以“内容本身的标识”为接口。这种接口方式的改变,也改变了路由器中的路由转发方式,即以“IP地址”为核心变成了以“内容标识”为核心。

从更本质的角度说,ICN/NDN对互联网体系结构的改变到底在哪里呢?虽然互联网是把不同的“网络”互联,但最终互联网服务还是为每个“网络”里的“节点”提供的。在传统的互联网体系结构中,我们站在节点本身的角度,以“节点”之间的“位置标识”作为建立“互通”关系的核心;而ICN/NDN站在节点的需求的角度,以“节点”所需求的“内容标识”作为建立“互通”关系的核心。这种技术革新,没有改变IP协议“无连接”、“分组交换”、“尽力而为”的技术特点,没有改变“分布式”管理的互联网架构,更没有改变“网际互联”的本意。

正因为如此,ICN/NDN目前已经形成了好几个RFC,包括RFC 7927、RFC 7945、RFC 8763。但ICN/NDN目前在技术上还存在诸多不完善的地方,因此这几个RFC都不是IETF的RFC,而只是IRTF的RFC,也意味着还没有广泛达成工程上的共识。现在说ICN/NDN替代IP协议,还为时尚早。

话又说回来,IPv6地址也只不过是128位的标识而已,没有人规定IP地址“只能”表示节点的“位置”。IP multicast技术中,不就用“组播IP地址”来作为一组会话的逻辑标识吗?因此,就算有一天ICN/NDN可以被成功部署,也完全可以采用128位的IPv6地址来作为“内容标识”,只是IPv6地址的语义就和今天不一样了。如果这种情况真的发生了,是否也仍然叫“IP协议”呢?就像从来没有人认为IP multicast不属于“IP协议”啊。因此按照我个人的看法,就算有一天ICN/NDN取得了成功,我们完全可以从IPv6地址空间中划出一半,专门作为“内容标识”,就和今天已经为组播和广播通信划分了专门的地址一样。这并不影响它仍然叫“IP协议”。

不管如何,ICN/NDN都可以成为挑战IP协议和互联网体系结构的一个好的样本:新技术既要围绕互联网“开放与互联”的核心使命来设计,又要针对IP协议的某个具体的技术问题进行革新。从这个例子也可以看出,只要符合互联网的核心使命和设计理念,互联网社区并不是“故步自封”的,并不是不接受任何改进意见的。

4、IP协议需要不断迭代有问题吗?

IP协议自从诞生以来,就在不断地改进、迭代。很多IETF的技术标准就在做这件事情。这些改进和迭代的例子非常多:为了支持安全性,诞生了IPsec协议;为了支持支持组通信,诞生了IP multicast协议;为了卸载IP地址同时表示位置和身份的问题,诞生了HIP协议;不胜枚举。但我们看到,任何一个“补丁”,都没有改变IP协议“无连接”、“分组交换”、“尽力而为”的本质。这些所谓的“补丁”,不过是对IP协议的丰富和完善而已;有些“补丁”确实在路由器上带来了过高的实现代价(代码行数),但这并非互联网体系结构的问题。对于互联网这一复杂巨系统,难道我们换一种互联互通的基本协议,就可以减少实现代价吗?

有人说,IP协议过多的“补丁”使得数据转发路径显得太“臃肿”,不够“高效”,比如NAT转化、防火墙、入侵检测设备等。这里其实指的问题是IP报文转发在数据平面上做的事情太多了。造成这一现状的原因大概有几点:1)因为IPv4地址不够用,带来了私有地址和公有地址之间的转化开销;2)安全方面的考虑:比如防火墙、入侵检测设备、ACL过滤等。3)服务质量方面的考虑:比如各种队列调度策略等。关于第1)点,事实上这也是为什么要推出IPv6的根本原因,可以保证每个节点都有IP地址,免去网络中的协议转换。关于第2)点,安全方面的“过滤”类操作是为了“过滤”掉非法流量,这是从体系结构层面保障互联网安全的重要技术,因为互联网的使命除了“开放、互联”,还有“安全、可信”,这一类操作并不会影响互联网的开放性。关于第3)点,IP协议一直主张在数据平面进行尽量“简单”的转发,所以才采用“尽力而为”的策略,为了“服务质量保障”而进行的操作,本来就是IP协议所希望避免的。因此,对IP协议在这方面的批评,事实上是在支持IP协议原本的设计目标。打个比方:设计“红绿灯”,是为了让道路交通更有秩序;我们不能因为在实际生活中红绿灯可能出故障、或者还是有人闯红灯,反过来说明红绿灯这个规则有问题;除非能拿出比“红绿灯”更好的方案。

还有人说,IP协议的补丁打得太多,如果要面临一些“新场景”或“新需求”,继续打“补丁”就显得很“笨拙”,不如推翻重来。这里要先问问,所谓的“新场景”或“新需求”,指的是除了“网际互联”之外的需求吗?如果是“网际互联”之外的需求,那就不用讨论了,因为IP协议从来不是为了其他需求而设计的;如果仍然是“网际互联”这个需求本身,那就先证明有什么新技术在这一点上可以比IP协议做得更好(就像本文前面部分所讨论的那样)。

5、总结

通过以上分析,我们的结论是,对于互联网技术中最核心的IP协议:1)IP协议从来不是完美的,但起码迄今为止,围绕互联网的“开放与互联”的核心使命,它完成得非常好;2)就算我们要改变IP协议,必须要保证新协议的首要设计目标仍然是围绕互联网“开放与互联”的使命来的,而不能以其他次要的目标来影响主要目标的实现。

就算IP协议保持稳定,也并不意味着互联网体系结构就没什么好做的了。因为“互联网体系结构技术”是包含很多方面的,不止有IP协议。为应用服务的传输协议、互联网控制平面的路由协议、互联网管理、互联网安全等等,都是很值得继续深入研究、进行技术创新的(这也是当前IETF正在做的许多标准化工作)。只是有两点希望:1)不要让任何对互联网体系结构的研究,都披着“推翻IP”的外衣;2)不要觉得任何不改变IP协议的互联网体系结构技术研究,就不是“重要创新”。再次打个不恰当的比方:如果不改变人类的基因,所有对人类健康的研究就都不算“重要创新”了吗?