NDN基础
转载自：https://blog.csdn.net/gongxifacai_believe/article/details/50823420
【NDN基础】Networking Named Content 全文翻译
Networking Named Content
Van Jacobson et. al
Palo Alto ResearchCenter
摘要
网络使用逐步演化为对内容的分发和获取，然而现今网络技术仅仅涉及主机之间的连接。访问内容和服务需要把用户关心的东西映射到网络的位置。我们提出内容中心网络，它把内容看作原语，在身份识别、安全和可访问性上与位置去耦合，并且通过名字获取内容。内容中心网络使用新的方法路由命名的内容，这些方法是从IP衍生出来的，通过这些方法，我们能够同时获得可扩展性、安全性和性能。我们用安全文件下载系统和VoIP电话系统具体实现了体系结构的基本特征、表现力和性能。
关键词
设计，实验，性能，安全
1. 引言
今天因特网的工程原则和体系结构是在20世纪六七十年代创建的。（P31）网络设计的目的是解决资源共享问题——远程使用稀有的和昂贵的设备，比如读卡器或者高速磁带驱动器甚至超级计算机。这产生的通讯模型是确切的两台机器之间的会话，一方希望使用资源，另一方提供可以访问的资源。因此IP包包含两个标识符（地址），一个是源地址，一个是目的地址，几乎所有的因特网上的流量包含主机对之间的TCP会话。
自从包交换网络产生以来的50年里，计算机和附件已经变成便宜的无处不在的商品。因特网提供的连通性和低的存储成本使访问大量的新内容成为可能——仅在2008年就创造了500EB新内容。(P3 2)人们因为互联网包含的内容而重视互联网，但通讯依然是依据位置的。
我们看到影响用户的许多问题起因于模型之间的不兼容性。
（1）实用性：快的可靠的内容访问需要笨拙的预先计划的针对特定应用程序的机制，像CDN和P2P网络，并且强制增加了过多的带宽花费。（覆盖网还不了解）
（2）安全性：内容的信任很容易错位，依赖于不值得信任的位置和连接信息。
（3）位置独立：映射内容到主机位置使配置和网络服务的实现变得复杂。
解决这些问题的直接的统一的方式是将位置代替为内容。主机到主机的会话是一个被选择来解决60年代问题的网络抽象。我们认为命名数据对今天的通信问题来说是一个比命名主机更好的抽象。我们引进CCN，构建在命名数据上的通讯体系结构。CCN在最低层上没有主机概念，包地址是命名内容，而不是位置。然而，我们保持使得TCP/IP简单、健壮和可扩展的设计决策。
图1比较了IP和CCN协议栈，协议栈中的大部分层反映了双边协定：例如，二层帧协议是在物理链路的两端之间的一个协议，四层传输协议是在某个生产者和消费者之间的之间的协议。仅有的需要通用协议的层是三层网络层。IP的成功在很大程度上是由于网络层的简易性（IP包，协议栈的瘦腰部分）和对二层提出的弱要求，也就是说：无状态的，不可靠的，无序的，尽最大努力的交付。CCN的网络层与IP的网络层相似，并对二层提出更少的要求，产生许多同样有吸引力的特性。另外，CCN能够在任何东西上分层，包括IP自身。
CCN以许多严格的方式与IP区分开来。其中的两个是策略和安全，在CCN协议栈中表现为新的层。因为CCN在第二层更简单的关系，CCN最大化利用多个同时连接（例如，以太网、3G、蓝牙和802.11）。策略层（3.3节）做出了细粒度的动态优化选择，在变化的条件下最好的利用多个连接。CCN确保内容自身（第5节），而不是它上面运行的连接，从而避免了许多折磨IP网络的基于主机的缺陷。
我们在第2节到第5节描述CCN的体系结构和操作。在第6节用我们实现的原型评估性能。最后，在第7和第8节，我们讨论相关工作并做总结。
图1：CCN将网络栈的通用组件从IP移动到命名内容块
async：异步串行端口
sonet：同步光纤网络
§ Routing and forwarding plane separation has provennecessary for Internet development. It allows the forwarding plane to function whilethe routing system continues to evolve over time. NDN sticks to the sameprinciple to allow the deployment of NDN with the best available forwardingtechnology while we carry out new routing system research in parallel.
§ Security must be built into the architecture. Securityin the current Internet architecture is an afterthought, not meeting thedemands of today’s increasingly hostile environment. NDN provides a basicsecurity building blockright at the thin waist bysigning all named data.
§ Network traffic must be self-regulating. Flow-balanceddata delivery is essential to stable network operation. Since IP performs openloop data delivery, transport protocols have been amended to provide unicasttraffic balance. NDN designs flow-balance into the thin waist.
——http://named-data.net/project/archoverview/
（译：路由转发平面的分离证明了因特网发展的必要性，它允许当路由系统随着时间继续进化的同时，转发平面仍然可以工作。NDN坚持同样的原则，在我们实行新的路由系统研究的同时，允许NDN用最可用的转发技术来部署。
安全层必须在体系结构内部构建。当前因特网体系结构的安全是后来考虑的，不能满足今天的增长的不是以主机为中心的环境的需求。NDN通过在细腰部分签名所有的命名数据，提供了一个基本的安全构造块。
网络流量必须是自动调节的。流平衡的数据交付对使网络操作平稳是至关重要的。由于IP执行开环的数据交付，因而我们通过改进传输协议来提供单播的流量平衡。NDN在细腰部分设计流平衡。）（开环控制：没有反馈的控制；闭环控制：具有反馈的控制。）
（百度：何为数据链路层的（DATA LINKLAYER）的MAC子层和LLC子层？
MAC子层的主要功能包括数据帧的封装/卸装，帧的寻址和识别，帧的接收与发送，链路的管理，帧的差错控制等。MAC子层的存在屏蔽了不同物理链路种类的差异性;
在MAC子层的诸多功能中，非常重要的一项功能是仲裁介质的使用权，即规定站点何时可以使用通信介质。实际上，局域网技术中是采用具有冲突检测的载波侦听多路访问（Carrier Sense Multiple Access /Collision Detection，CSMA/CD）这种介质访问方法的。
LLC子层负责向其上层提供服务；
LLC 是在高级数据链路控制（HDLC：High-Level Data-Link Control）的基础上发展起来的，并使用了 HDLC 规范子集。LLC 定义了三种数据通信操作类型：
类型1：无连接。该方式对信息的发送通常无法保证接收。
类型2：面向连接。该方式提供了四种服务：连接的建立、确认和承认响应、差错恢复（通过请求重发接收到的错误数据实现）以及滑动窗口（系数：128）。通过改变滑动窗口可以提高数据传输速率。
类型3：无连接承认响应服务。
类型1的 LLC 无连接服务中规定了一种静态帧格式，并支持运行网络协议。有关传输层网络协议通常是使用服务类型1方式。
注意：在Windows 2000网络体系结构中，LLC子层是由传输驱动程序实现的，而MAC子层是由网络接口卡（NIC:网卡）来实现。
类型2的 LLC 面向连接服务支持可靠数据传输，运用于不需要调用网络层和传输层协议的局域网环境。）
（LLC的功能：
数据要通过网络进行传输，要从高层一层一层的向下传送，如果一个主机要传送数据到别的主机，先把数据包装到一个特殊协议报头中(一般分为mac头、llc头、ip头、tcp头)，这个过程叫封装，右边是一个数据链路解封的工作示意图：
IEEE于1980年2月成立了局域网标准委员会（简称IEEE802委员会），专门从事局域网标准化工作，并制定了IEEE802标准。802标准所描述的局域网参考模型只对应OSI参考模型的数据链路层与物理层，它将数据链路层划分为逻辑链路层LLC子层和介质访问控制MAC子层。
IEEE802委员会为局域网制订了一系列标准，统称为802标准。其中 IEEE 802.2 LAN 标准定义了逻辑链路控制LLC子层的功能与服务，并且是 IEEE 802.3，IEEE802.4和 IEEE 802.5等标准的基标准。
LLC负责识别网络层协议，然后对它们进行封装。LLC报头告诉数据链路层一旦帧被接收到时，应当对数据包做何处理。它的工作原理是这样的：主机接收到帧并查看其LLC报头，以找到数据包的目的地，比如说，在网络层的IP协议。LLC子层也可以提供流量控制并控制比特流的排序。
IEEE 802.2 LLC 应用于 IEEE802.3 （以太网）和 IEEE802.5（令牌环） LAN，以实现如下功能：
1.管理数据链路通信
2.链接寻址
3.定义服务接入点 Service Access Points （SAP）
4.排序
LLC 为上层提供了处理任何类型 MAC 层的方法，例如，以太网 IEEE 802.3 CSMA/CD 或者令牌环 IEEE 802.5 令牌传递（Token Passing）方式。
LLC 是在高级数据链路控制（HDLC ： High-Level Data-Link Control）的基础上发展起来的，并使用了HDLC 规范的子集。LLC 定义了三种数据通信操作类型：
类型1：无连接。该方式不保证发送的信息一定可以收到。
类型2：面向连接。该方式提供了四种服务：连接的建立、确认和数据到达响应、差错恢复（通过请求重发接收到的错误数据实现）以及滑动窗口（系数：128）。滑动窗口用来提高数据传输速率。
类型3：无连接应答响应服务。
类型4：高速传送服务。
不确认的无连接服务不需要事先建立连接，就可以传输数据帧。端-端流量控制和差错控制由高层协议提供。这种服务不需确认，也比较简单。通信方式可为点-点通信、广播通信和组通信，这是一种数据报服务。
类型1的 LLC 无连接服务中规定了一种静态帧格式，并允许在其上运行网络协议。使用传输层协议的网络协议通常会使用服务类型1方式。
类型2的 LLC 面向连接服务支持可靠数据传输，运用于不需要调用网络层和传输层协议的局域网环境。
）
2. CCN结点模型
CCN通信由数据的消费者驱动。有两个CCN包类型：兴趣包和数据包（图2）。消费者在所有可用的连接上通过广播兴趣包请求内容。任何听到兴趣包的结点，如果有可以满足兴趣包的数据，都能够用数据包来响应。数据包仅在对兴趣包的响应中传输，数据包消费请求包。（兴趣包和数据包是一对一的，并保持一个严格的流平衡。一个相似的在数据包和确认包之间的流平衡提供了TCP的可扩展性和适应性。然而，不像TCP，CCN的模型工作在多对多的多点交付。见3.1节。）兴趣包和数据包都通过名字识别正在交换的内容，多个对同样内容感兴趣的结点使用标准多播抑制技术通过广播介质共享传输。
如果兴趣包中的内容名是数据包中内容名的前缀，则数据包满足兴趣包。CCN名字是难懂的二进制对象，由许多明确指定的部分组成（见图4）。名字是典型分层的，所以前缀匹配等于说数据包是在兴趣包指定的命名子树中（见3.2节）。IP使用这个约定来解决IP地址的<网络号，子网号，主机号>层次结构，当需要快速查找的时候，经验显示它考虑到有效的分布式的分层的路由聚合和转发状态。
图2：CCN包类型
（兴趣包：
1内容名
2选择器：顺序偏好，发布者过滤器，范围
3随机数（同一发布者的一个兴趣包的不同副本有不同的随机数？怎么防环？））
（数据包：
1内容名
2签名：摘要算法，证人
3签名信息：发布者ID，密钥定位器，老化时间P280
4数据）
这个匹配的一个含义是内容还不存在的兴趣包仍然可能被收到——允许发布者生成对一个特殊查询响应的内容。(P6 1)这样的活跃名字允许CCN透明地支持静态缓存和动态生成的内容的混合，这在今天的网络中很普遍。名字前缀也可能是依赖环境的，比如/ThisRoom/projector显示出与在当前房间里的projector交换信息或者/Local/Friends显示出与在本地（广播）环境中的任何朋友交换信息。（最后一个例子使用CCN创建的明确的标识信息来签名，允许朋友通过一个固定的名字而不是通过复杂的枚举或者探测策略会合。例如，名字说他们想要通讯的内容，签名说在名字环境中他们是谁，例如，在本地环境中的一个朋友。）
CCN结点的基本操作与IP结点非常相似：包到达接口后，进行了对包名字的最长前缀匹配，然后实行了基于查询结果的行为。（我们使用术语face而不是interface，因为包不仅仅通过硬件网络接口转发，而且直接与机器内部的应用程序进程交换信息，像在第6节中描述的那样。）图3是核心CCN包转发引擎的原理图。有三个主要的数据结构：FIB（转发信息库）、CS（内容缓存，缓冲存储器）和PIT（待定兴趣包表）。
FIB用来向匹配数据的可能源转发兴趣包。除了他列出输出接口的一个列表，而不是一个单独的输出接口之外，几乎和IP中的FIB表相同。这反映了CCN没有限制在一个生成树上转发的事实。它允许多个数据源，能够并行地查询他们。
内容缓存与IP路由器的缓冲存储器相同，但有一个不同的替换策略。由于每个IP包属于一个单独的点到点会话，在被向下游转发后没有更多价值。因此IP“忘记”了一个包，并当转发完成后立即回收缓存（MRU替换）。CCN包是幂等的，自我识别的和自我认证的，因此每个包对许多消费者都可能是有用的（例如，许多主机阅读相同的新闻或者观看同样的YouTube的视频）。为了最大化共享的可能性，最小化上游带宽需求和下游延迟，CCN尽可能长时间地记住到达的数据包（LRU或者LFU替换策略）。
PIT记录转发到朝向内容源的上游的兴趣包，以至于返回数据包能够向下游请求者发送。在CCN中，仅仅兴趣包被路由，因为他们向上游可能的数据源传播，他们留下一个“面包屑”的痕迹为一个可以匹配的数据包遵循到源请求者的返回路径。每个PIT条目是一个面包屑。一旦PIT表项被用来转发一个匹配的数据包后，PIT表项就被擦除（数据包消费兴趣包）。从来没有找到匹配数据包的兴趣包的PIT条目最终会超时（一个软状态模型——消费者如果仍然想要数据包，会重复发送兴趣包）。
当兴趣包到达某一接口，就执行内容名字的最长匹配查询。用来查询的索引结构是排好序的，以至于内容缓存匹配将比PIT匹配优先，PIT匹配优先于FIB匹配。
因此如果内容缓存中已经有可以匹配兴趣包的数据包，他将从兴趣包到达的接口发送出去，兴趣包将会被丢弃（由于它已经被满足了）。
另外，如果有确切匹配的PIT条目，兴趣包的到达接口将会被添加到PIT表项的请求接口列表中，兴趣包将会被丢弃。（兴趣包中的数据已经被向上游发送，因此所需要做的事是确保当请求的数据包到达时，包的一个副本将会被从新的兴趣包到来的接口发送出去。）
图3 CCN转发引擎模型
另外，如果有一个匹配的FIB条目，那么兴趣包需要被朝着数据源向上游发送。如果查询FIB的结果列表不空，到达接口从FIB条目的接口列表中移除，然后，兴趣包被从所有保留的接口发出，一个新的PIT条目被从兴趣包和它的到达接口创建。
如果兴趣包没有匹配，则它将被丢弃（这个结点没有任何匹配数据，而且不知道怎样找到匹配数据）。
由于数据包没有被路由，而仅仅遵循PIT表项链返回到请求源，所以数据包的处理相对简单。数据包一旦到达，就执行数据包的内容名字的最长匹配查询。内容存储如果匹配，意味着数据包是一个副本，因此被丢弃。FIB匹配意味着没有匹配的PIT条目，因此数据包是未经请求的，所以被丢弃。(数据包到达还查找FIB表？那么如果可以匹配PIT条目，FIB表中没有记录吗？那么请求兴趣包查找FIB表并从相应接口转发了兴趣包之后，FIB表项是什么情况？)（未经请求的数据能够由恶意行为引发，数据包从多个源到达，或者来自单个源的多个路径。在后者情况下，到达数据包的第一份拷贝消费请求包，所以复制品不会找到PIT表项。在所有情况下，由于数据包保持了流平衡，并帮助保证了在任意负载下的静态操作，所以数据包应该被丢弃。）PIT匹配（也许有超过一个）意味着数据包是被这个结点发送的兴趣包所请求的。经过验证的数据包被加到内容缓存中（例如，创建一个C类型索引条目指向数据包）。然后创建一个请求接口列表的集合，这个列表是每个PIT匹配减去数据包的到达接口。数据包然后从列表中的每个接口送出。
不像IP体系结构的FIFO缓存模型，CCN内容缓存模型允许静态多路复用所需的结点内存，同时被用作整个网络的透明缓存。所有结点都能够提供缓存，仅仅受制于他们独立资源的可用性和策略。
兴趣包获取数据的多点性质对在高度动态的环境中维持通信提供了灵活性。可以访问多个网络的任何结点可以作为网络之间的内容路由器。通过使用缓存，移动结点可以作为不连通的区域之间的网络介质，或者在断断续续的链路上提供有延迟的连接。因此CCN传输提供延迟可容忍网络（DTN）。不论什么时候有本地连接，兴趣包/数据包的交换都会发生。例如，在没有连接到因特网或者他们的组织的孤立位置上，两个拥有笔记本电脑和ad-hoc无线网络的同事可以继续正常地共享合作文档。
3. 传输
CCN传输被设计为在不可信包交付服务的上层操作，包括移动的高度动态连接和普适计算。因此兴趣包，数据包，或者两者都可能在传输的过程中丢失或损坏，或者被请求的数据可能临时不可用。为了提供可靠的有弹性的交付，在某些合理的时间段不被满足的CCN兴趣包必须被重传。不像TCP，CCN发送者是无状态的，最后的消费者（发出初始兴趣包的应用程序）如果仍然想要数据，那么他对重新发出未满足的兴趣包负有责任。接收者的策略层（见图1）对在特别接口上的重传负有责任（由于他知道这个接口上的上游结点的超时时间），接收者的策略层也选择哪个可用的通信接口和多少可用的通信接口用来发送兴趣包，多少未满足的兴趣包应该被允许发送，不同兴趣包的优先级等。
下面的包网络可能复制包，CCN多点分布也可能引起复制。所有的重复数据包被在前面部分描述的基本结点机制中丢弃。尽管数据包不能在CCN中打环，兴趣包可以打环，并出现好像没有兴趣实际存在的接口上有兴趣包。为了检测和防止这个，兴趣包包含一个临时的随机值，以至于在不同路径上接收到的副本可能被丢弃（见图2）。
CCN兴趣包执行和TCP确认包同样的流控和排序功能。流控在下一部分描述，排序在流控之后的部分描述。由于结点能够保证看到任何由他发出的兴趣包的数据包，响应时间和响应速率能够被直接测量并用来适应性地决定满足某个前缀的兴趣包的最佳路径。这在第3节描述。
3.1 可靠性和流控
一个兴趣包最多获取一个数据包。这个基本原则确保流平衡在网络中保持，并允许不同速率的网络上的多样的机器之间的有效的通信。然而，就像在TCP中，数据包和请求包可能重叠。在数据包到达消费第一个兴趣包之前，多个兴趣包可能被立即发出。兴趣包以TCP中的窗口通告的角色服务。通过变化接收者发出的兴趣包，接收者能够动态地变化窗口大小。我们在后面的6.2节显示了这样的流水线技术的作用。由于CCN包能够独立命名，流水线没有因丢失而拖延，相当于固有的TCP SACK。
在大的网络中，TCP会话的端到端性质意味着发送者和接收者之间存在许多点，即使每个会话操作在流平衡状态下，拥塞仍能够从会话聚合中发生。拥塞的结果是延迟和包丢失，TCP的解决方案是对端结点动态地调整窗口大小来保持聚合流量在拥塞发生的水平之下。拥塞控制的需要是因为TCP流平衡是端到端的结果。在CCN中，相反，所有的通信都是本地的，因此没有意义讨论没有涉及到流平衡的发送者和接收者之间的会话。由于CCN流平衡在每一跳保持，不需要额外的技术在路径中间控制拥塞。与逐跳流控不同，相邻结点之间的反压力被用作调整连续流之间的资源共享。CCN在链路之间没有FIFO队列，而是一个LRU缓存，它解耦了逐跳反馈控制环路和减幅振动。（我们将在未来的论文中详细地讨论这个话题。）
图4：数据包名字例子
3.2 序列
在主机之间的TCP会话中，数据包用简单的序列号加以标识。CCN需要更加复杂的东西，因为消费者从大的数据集中请求独立的分片，许多接收者可能共享同样的数据包。使用分层的可聚合的名字促进了定位和数据共享，这些名字至少一部分对人类有意义，反映了他们起源的组织架构，而不仅仅是短暂会话中的序列。尽管CCN名字额外的丰富性，兴趣包的传输功能与TCP确认包的序列号相同：指定接收者需要的下一个数据包。
在解释下一个数据包被怎样加以标识之前，我们首先更加详细地描述名字。像上面提到的，名字是被层次化地组织的，以至于一个单独的名字由许多成分组成。每个成分由许多任意的八位组组成——对CCN传输没有意义的可变长度的二进制值。对协议栈中的高层，名字必须是有意义的和有用的，但是除了组件架构，传输没有限制条件。二进制整数编码或者其他的复杂值可能被直接使用，而没有因为传输被转换到文字。名字组件可能甚至因为隐私被加密。为了计数的方便，我们呈现了类似URI的名字，用/字符分割组件，就像图4所示那样，但是这些分隔符不是名字的一部分，没有包含在包的编码当中。这个例子阐明，应用程序层的约定当前被用于捕获临时的内容演化（一个版本标记，_v编码为FD，后面接一个整数版本号）和他的分割（一个分割标记，_s编码为00，后面跟一个整数值，这个整数值可能是一个块号或者字节号或者包中第一个视频帧的帧号）。每个数据包名的最后一个组件隐含包括一个包的SHA256摘要。
兴趣包能够精确地指定需要什么内容，但在绝大多数情况下，下一个数据包的全名是未知的，因此消费者指定它相对于名字是已知的内容。因为CCN名字树能够被完全排序（兄弟结点按字典顺序安排），因此像下一个和前一个这样的关系能够被CCN传输无歧义地翻译，即使没有任何名字语义的信息。
图5：名字树的遍历
例如，图5显示了与图4相关的名字树的一部分。想要显示绝大多数最近版本的视频的应用程序将会以名字’/parc.com/videos/WidgetA.mpgRightmostChild发送兴趣包，这导致突出的遍历和生成视频第二版本的第一段。当这被获取后，下一段将会通过发送包括名字的兴趣包获得，名字有一个最左右兄弟注释，或者通过简单地计算名字的_s1部分，由于应用程序已经知道划分规则。
像这个例子所示，集合中数据片的命名约定能够被设计来利用兴趣包的相关获取特征，应用程序能够通过树的遍历发现可用数据。尽管这样的名字约定不是基本CCN传输的一部分，然而他们是应用程序设计的重要元素。我们期望各种各样的可重用约定能够被标准化，在共享库中实现来提供应用程序的高层抽象，比如CCN上的文件和媒体流。
CCN中的兴趣包在可访问内容集上提供了一种形式的受限查询机制，兴趣包是为接收者接下来需要的有效表达设计的。我们没有空间来描述正在开发的查询选项的细节。发布者限制结果是可能的，不仅仅通过聚集，当简单的排序不够时，排除的内容已经获得了。我们也发展了高层名字发现机制，当内容自身不再需要时，这个机制对探测大的名字子树更有效。
3.3 丰富的连通性、移动性和策略
现在的典型的机器有多个网络接口，越来越具有移动性。由于IP被限制在生成树上转发，对IP来说，利用多于一个接口或者适应由快速移动性产生的改变是很困难的。CCN包不能有环路，因此CCN能够全面利用多个接口。CCN谈论数据，而不是结点，因此它不需要获取或者绑定三层身份（IP地址）到二层身份，比如MAC地址。甚至即使连通性正在快速改变，一旦物理上可能，CCN总能交换数据。此外，由于CCN兴趣包和数据包是配对的，每个结点得到细粒度分布，每个前缀，每个接口性能信息，为匹配某个前缀适应性地选择最好的接口转发兴趣包（见6.3节）。
像在第2节中描述的，CCN通过每个FIB条目接口列表明确地模拟多个连接。由于没有一个大小适合所有的策略来使用多个接口，设计意图是为每个CCN FIB条目包含一个程序，程序是为一个抽象的专门做转发选择的机器所写的，它决定了怎样转发兴趣包。这台机器的说明应该包括正常load/store的小的子集，算法和比较操作，加上在接口集上操作的行为，比如发送到所有，发送到最好，标记为最好，兴趣包满足的触发器，兴趣包超时，接口关闭，当一些有意义的事件发生时，能够被用来调用的行动列表。接口将有一个属性的（开放端）集合，比如能够广播的，是内容路由器的，基于费用的使用，高峰使用限制能够被用来动态构造行为使用集合。
这些动作，触发器和属性共同被称为CCN策略层，FIB条目的程序是获得与FIB前缀相关的数据的策略。我们当前的默认策略是在所有的能够广播的接口上发送兴趣包，如果没有响应，则按顺序尝试所有的其他接口。因此，在本地环境中可用的数据，比如在讲座中做讲座人的电脑上，或者一个商务会议中同事的笔记本电脑或者电话中的数据，将会被直接获得，仅仅没有在本地找到的数据将会使用路由器械。
FIB前缀条目中的其他接口将会通过许多方式被学习到。通过对本地CCN核心做注册操作，数据源，比如图6中的仓库，安排来为他们服务的前缀接收兴趣包。这为已注册的前缀创建了本地FIB条目，注册的前缀在接口列表中有贮藏应用程序接口仓库。如果已注册前缀应该被从本地机器中广播出去，他们有可选的标志表明。公告代理在本地结点中读已注册前缀表（通过正常的CCN兴趣包—数据包到为本地结点通信保留的命名空间），并广播打标签的前缀来满足策略限制（见5.4节）。这个广播可能是通过CCN（例如，以/local/CCN/registrations命名的代理服务兴趣包），通过标准的IP服务位置协议，或者通过CCN或者IP路由（见第4节）。
（Ad-hoc体系结构：
体系结构编辑
结点结构
Ad hoc网络中的结点不仅要具备普通移动终端的功能，还要具有报文转发能力，即要具备路由器的功能。因此，就完成的功能而言可以将结点分为主机、路由器和电台三部分。其中主机部分完成普通移动终端的功能，包括人机接口、数据处理等应用软件。而路由器部分主要负责维护网络的拓扑结构和路由信息，完成报文的转发功能。电台部分为信息传输提供无线信道支持。从物理结构上分，结构可以被分为以下几类：单主机单电台、单主机多电台、多主机单电台和多主机多电台。手持机一般采用的单主机单电台的简单结构。作为复杂的车载台，一个结点可能包括通信车内的多个主机。多电台不仅可以用来构建叠加的网络，还可用作网关结点来互联多个Ad hoc网络。
网络结构
Ad hoc网络一般有两种结构：平面结构和分级结构。 在平面结构中，所有结点的地位平等，所以又可以称为对等式结构。 分级结构中，网络被刈分为簇。每个簇由一个簇头和多个簇成员组成。这些簇头形成了高一级的网络。在高一级网络中，又可以分簇，再次形成更高一级的网络，直至最高级。在分级结构中，簇头结点负责簇间数据的转发。簇头可以预先指定，也可以由结点使用算法自动选举产生。 分级结构的网络又可以被分为单频分级和多频分级两种。单频率分级网络中，所有结点使用同一个频率通信。为了实现簇头之间的通信，要有网关结点（同时属于两个簇的结点）的支持。而在多频率分组网络中，不同级采用不同的通信频率。低级结点的通信范围较小，而高级结点要覆盖较大的范围。高级的结点同时处于多个级中，有多个频率，用不同的频率实现不同级的通信。在两级网络中，簇头结点有两个频率。频率1用于簇头与簇成员的通信。而频率2用于簇头之间的通信。分级网络的每个结点都可以成为簇头，所以需要适当的簇头选举算法，算法要能根据网络拓扑的变化重新分簇。 平面结构的网络比较简单，网络中所有结点是完全对等的，原则上不存在瓶颈，所以比较健壮。它的缺点是可扩充性差：每一个结点都需要知道到达其他所有结点的路由。维护这些动态变化的路由信息需要大量的控制消息。在分级结构的网络中，簇成员的功能比较简单，不需要维护复杂的路由信息。这大大减少了网络中路由控制信息的数量，因此具有很好的可扩充性。由于簇头结点可以随时选举产生，分级结构也具有很强的抗毁性。分级结构的缺点是，维护分级结构需要结点执行簇头选举算法，簇头结点可能会成为网络的瓶颈。 因此，当网络的规模较小时，可以采用简单的平面式结构；而当网络的规模增大时，应用分级结构。
）
4. 路由选择
路由选择最近经历了研究活动的再次兴起。今天对绝大多数路由选择问题，有许多有趣的和有效的候选解决方案。任何在IP体系结构中工作得好的路由方案在CCN中也工作得好，因为CCN的转发模型是拥有更少限制的IP模型的严格的超集（为了避免环路，没有在多源、多目的方面的限制），拥有同样的与路由选择相关的语义（最长匹配查询的层次化名字聚合）。CCN提供一个极好的媒介来实现路由选择协议的传输：绝大多数路由传输协议的核心与CCN的面向信息的引导扩散洪泛模型相似，由于他们必须在网络的预拓扑阶段起作用，这个阶段对等身份和位置是不知道的。由于CCN提供了健壮信息安全模型（第5节），用CCN作为路由传输能够使路由选择基础设施保护几乎是自动进行的。
为了说明怎样将CCN映射到一个路由方案，下一部分描述CCN怎样使用修改过的因特网链路状态IGP协议（IS-IS或者OSPF协议）来进行路由选择。我们意图展示CCN怎样使用现在存在的常见的路由选择（比如反对更加面向内容的路由，比如也应用到CCN中，但是有十分不同的实现策略的小世界理论）和通过使用现在存在的基础设施，CCN充分兼容可以被增量部署的IP体系结构。
（百度：集中式路由转发和分布式路由转发：
集中式第三层包转发
集中式第三层包转发是指在交换机中有一个专门的硬件模块（路由模块）来对全交换机的 第三层包进行转发。交换机的每个接口模块如千兆以太同交换模块，都不具备第三层的处理功能，需要把第三层的数据包从背饭送往路由模块来查询路由并转发。严格的讲，这种结构的交换机更准确的名称是第三层交换机，而不是路由交换机。 集中式第三层包转发是早期的技术，它的缺点在于整个交换机的路由性能受限于其路由模块的能力。另外，当一个IP包要进行路由时，它经常要从一个以太网接口 模块通过背板总线送 往路由模块，在路由模块处理后，又经背板总统送往同一以太网接口模块，这样一种数据包传送方式浪费了背板总规处理能力。并且路由模块的故障会导致整个交换机内的路由功能的失效。
实际中很多厂商交换机中的路由模块就是一个以插卡形式集成在交换机内的软件路由器。 因此在各厂商的产品中，采用集中式包转发的交换机的路由能力一般可达到15Mpps。
分布式第三层包转发
图6：路由兴趣包到一个域的多媒体内容
4.1 链路状态域内路由选择
域内路由选择协议为结点提供了一种方法来发现和描述他们的本地连通性（“邻接”），和描述直接连接的资源（“前缀通告”）。这两个功能是正交的—一个描述图中的链路，另一个描述图中特定结点中可用的东西。通常，这两个功能在完全不同的信息领域实现。例如，IS-IS以术语IEEE 802.1 二层MAC地址描述邻接关系，但是宣告三层的IPv4或者IPv6前缀。像在第2节中描述的那样，IP转发和CCN转发是几乎完全相同的。他们都使用基于前缀的最长匹配查询（因为同样的原因使用——层次化聚合细节）来找到更靠近匹配的标识符的本地邻居。已经给出了两个FIB表的相似之处，一个可能猜测是用来创建IP FIB表的分布式路由选择机制可以用来容易地创建CCN FIB表，确实是这种情况。
CCN前缀与IP前缀十分不同，因此主要的问题是在某个特殊的路由协议中是否可以表达他们。幸运的是，IS-IS和OSPF都可以通过一个适合于分配CCN内容前缀的TLV（类型标签值）方案直接描述连接的资源。这个设计约定说明未识别的类型应该被忽略，这意味着实现全部CCN转发模型的内容路由器能够连接到一个现在存在的IS-IS或者OSPF网络，而不修改这个网络或网络中的路由器。内容路由器学习物理网络拓扑，并通过在前缀通告中使用CCN TLV在拓扑中通过邻接协议和洪泛前缀宣告他们的位置。
例如，图6显示了一个仅有IP体系结构路由器（单个圆圈表示）的IGP域和一些IP+CCN路由器。与A相邻的媒体仓库正在（通过本地网络管理名字空间中的CCN广播）公告他能够服务匹配前缀’/parc.com/media/art’的兴趣包。A上的路由选择应用程序听到了这个公告（由于他已经在这样的已经发送了公告的名字空间发送了兴趣包），为指向听到宣告的接口的前缀建立一个本地的CCN FIB条目，并且把这个前缀打包进IGP LSA并洪泛到所有结点。例如，当E上的路由选择应用程序最初得到这个LSA，他创建了到A的CCN接口，然后为’/parc.com/media/art’添加一个前缀条目，并通过那个接口到达本地CCN FIB。当一个不同的与B邻接的仓库公告了’/parc.com/media’和’parc.com/media/art’，B为这两个前缀洪泛一个IGP LSA，结果是像图中所示的E的CCN FIB表。一个以/parc.com/media/art/impressionist-history.mp4’命名的兴趣包被一个连接到E的客户发送，这个兴趣包将会被转发到A和B，A和B都分别把它转发到他们的相邻仓库。
CCN动态地建立在带宽和延迟方面都接近最佳的拓扑上（例如，数据包仅仅在存在兴趣包的地方传输，在最短路径上，任何链路上任何数据包片至多只有一份拷贝）。但是由于连接到F的客户对同样的视频感兴趣，这个交付拓扑是明显未优化的，这将导致穿过A-C或者B-C链路的内容的第二份拷贝。这将发生在当一个增量CCN部署离开了对CCN不可访问的物理拓扑的一些部分（C不是内容路由器，因此不能缓存）。C一旦得到CCN软件升级，E和F将会通过它转发他们的兴趣包，分布将会变得最优化。
在上面描述的模型中，IGP LSA被用作传输正常的CCN消息，这个消息有全部的CCN内容身份验证、保护和策略注释。因此，即使IGP并不安全，可以运行CCN的结点之间的通信是安全的。如果所有的结点进化成为可以运行CCN的结点，IGP拓扑基础设施是自动保障安全的（见5.1节）。这个起源于外部的前缀公告的安全性是公告协议的一个功能。CCN内容前缀，比如在图6中的那些被媒体服务器公告的内容前缀，被CCN确保安全，并拥有健壮的可信的模型。从其他IGP或者BGP通告的IP前缀将是不可信的。
当有相同前缀的多个公告发生时，在IP和CCN之间有一个行为的不同。在IP体系结构中，任何特殊的结点将会发送所有的匹配流量到一个确切的发布者。在CCN中，所有的结点发送所有的匹配兴趣包到所有的发布者。这个起因于一个语义上的不同：一个IP前缀从某个IGP路由器通告说“拥有这个前缀的所有主机可以通过我到达”。这相当于一个CCN路由器通告说“拥有这个前缀的某个内容可以通过我到达”。由于IP体系结构在内容层面上没有检测环路的方法，所以被迫建造环路树转发拓扑，例如，一个以目的地为根的汇集树。由于树在任何两个结点之间有单独的路径，一个IP FIB表仅有一个出接口槽。因此所有与这个前缀相关的主机必须通过通告这个前缀的这个结点可达，因为所有匹配这个前缀的流量将会被送达这个结点。由于CCN包不能有环路，前缀宣告并不意味着这个结点与所有拥有这个内容的结点邻接，CCNFIB表被建立来转发兴趣包到所有通告这个前缀的结点。这个语义上的不同能够在不改变IGP的情况下被容纳，因为它是一个实现上的改变，而不是一个协议上的改变。IP体系结构必须从前缀通告中计算出一个生成树，而CCN不会，但这个计算在使用信息的地方执行，而不是生产信息的地方执行，两个协议都能接收到完整的信息。（严格地说，这个陈述对链路状态内部网关协议，像IS-IS或者OSPF来说是正确的，但对距离矢量内部网关路由协议，像RIP或者EIGRP来说是不正确的。他们路由宣告的产生包括以生成树为先决条件的Bellman-Ford计算和替代方案中的抑制信息。这样一个IGP协议需要小的修改来满足这里描述的方案。）
4.2 域间路由选择
仅仅一个ISP的很少的客户开始使用CCN，部署内容路由器来减少对等体花费（任何内容分片的一个副本需要穿越域间提供者的对等链路，多少消费者请求它是独立的）事关ISP的最大利益，尽管降低了消费者的平均延迟（所有，而不是第一个来自ISP的本地内容缓存的副本）。因此，当CCN到达某个最低部署阈值时，存在一个边缘驱动的，自底向上的激励结构来发展CCN。由于客户直接连接到他们的ISP，对他们来说，了解ISP的内容路由器是通过一个运行在客户-ISP的对等链路上的服务发现协议是不重要的。这个协议能够对通配符前缀使用基于CCN的注册通告（3.3节）。或者它能够使用任播（例如，所有的内容路由器拥有IP地址10.0.96.95），DNS约定（例如所有的内容路由器以ccn.isp.net命名），DNS SRV，SLP等，这些选项中没有选项需要任何内容前缀的域间分布。
这种类型的自底向上部署的中心问题是桥接域间沟壑，这些域中存在内容路由器但是被没有内容路由器的ISP分开了。例如，在parc.com的内容路由器想要通过前缀mit.edu获取内容，然而在PARC和MIT之间没有内容路由器。在启发式的DNS查询中使用这个前缀来定位MIT的内容服务器的IP地址（或者通过a_ccn._udp.mit.edu SRV查询或者ccn.mit.edu地址查询）工作得很好，它可以自动地和按需构建一个UDP隧道接口连接内容路由器。但是如果沟壑不是在边缘，这个方案不会工作的那么好。如果PARC和MIT的ISP都支持内容路由选择，但是他们通过不支持内容路由选择的ISP连接，那么PARC的ISP没有方法学习在MIT的ISP中相关内容路由器，因此，它将直接向MIT转发兴趣包。因此，如果没有额外机制，ISP路由器得益于入站内容（被消费者请求的内容），而不是出站内容（被消费者创建的内容）。这部分地否定了一个主要的长期CCN优势——使流量靠近内容分布树的根独立于内容的受欢迎程度（不受受欢迎程度的约束）；今天流量随着受欢迎程度线性增长（6.2节）。
问：DNS使用TCP还是UDP协议？
答：dns同时占用tcp和udp的53端口！
区域传送时使用TCP，主要有一下两点考虑：
1.辅域名服务器会定时（一般时3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传送，进行数据同步。区域传送将使用TCP而不是UDP，因为数据同步传送的数据量比一个请求和应答的数据量要多得多。
2.TCP是一种可靠的连接，保证了数据的准确性。
域名解析时使用UDP协议：
客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过TCP三次握手，这样DNS服务器负载更低，响应更快。虽然从理论上说，客户端也可以指定向DNS服务器查询的时候使用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。
这个问题能够通过整合域级内容前缀到BGP来解决。当前的BGP域间路由选择相当于IGP TLV机制，允许域广播他们的消费者的内容前缀。BGP的AS-path信息也允许每个域构建一个拓扑映射，相当于构建在IGP中的拓扑映射，但是在自治系统内部而不是网络前缀层。这个映射在功能上相当于IGP实例（学习哪个域服务具有某个前缀的兴趣包和在到达那些域的路径上的最近的具有CCN能力的域的映射），因此同样的算法可以应用。
5. 基于内容的安全
CCN构建在基于内容的安全的概念上，通过在传输过程中内容自身的保护和信任，而不是在它传输过程的连接上的一个连接属性。在CCN中，所有的内容通过数字签名被认证，私有内容通过加密被保护。这是一个CCN的动态内容缓存能力的临界使能器——如果你即将从最近可用的副本获取内容，你必须能够验证你得到的内容。当前的IP网络信任基于从哪里和怎样得到内容；因而客户必须直接从信任的内容源直接获取内容。对内容安全的具体化，而不是主机安全的具体化，减少了我们必须放在网络中介中的信任，向广泛的参与开放网络。在这一部分，我们给出了对CCN核心安全设计的概述，并且强调CCN安全处理的新奇方面。对CCN安全模型的细节分析，包括像撤回的话题，将会是一个单独论文的主题，额外的背景和动机在文献中描述。
5.1 内容验证
CCN认证名字和内容之间的绑定；每个CCN数据包（图2）的签名是构建在名字、内容和小数量的对签名验证有用的支持数据上的（签名信息见图2）。这允许内容发布者安全地将任意名字绑定到内容。相反，许多以前的方法需要名字被自认证来确保名字内容（例如，通过使用内容的加密摘要作为名字）。这个直接地安全地使用对用户有意义的或者对应用程序有意义的名字增强了可用性，并更加易于传输。没有它的系统需要一个间接基础设施来从人类关心的名字到安全的、难懂的、自认证的名字的映射。这个结果系统的安全性被限制到（通常不安全的）间接基础设施的安全性。
CCN的数据是公开认证的，每个包的签名是标准的公钥签名，任何人，不仅仅是通信系统的端结点，可以核实一个通过特殊密钥签名的名字—内容绑定。这个签名算法被内容发布者从一个大的固定集合中被挑选，被选择来满足特殊数据包的性能需求，例如，最小化验证数据包的大小，或者延迟，或者签名生成的计算代价，或者验证。尽管数据包被设计为个人可验证的，通过使用聚合技术，比如Merkle哈希树签名生成的计算代价可能被分摊在多个包上。
每个签名的CCN数据包包含能够获取的需要核实的公钥的信息。它的支持信息包括公钥的加密摘要，或者公钥指纹，作为发布者的速记标识符，并能够从本地缓存中快速获取密钥。它也包括密钥定位器，表明密钥可以从哪里获得，这包含密钥自身，或者获取密钥的CCN名字。
在最底层，CCN内容验证是纯粹的语法范畴——它简单地验证被它声称的密钥的签名的内容（这个密钥的指纹被指定作内容发布者）。不向密钥附加任何真实世界的意义——它属于谁，或者那个密钥的签名意味着用户是否应该信任这个特殊的内容片。甚至这个最小的验证可能惊人地有用，特别在防御许多类型的网络攻击方面。例如，它允许内容消费者通过发布者和通过名字请求内容，来得到他们想得到的在伪造的或者恶意的接口上的数据。CCN内容路由器可以按照他们资源的允许选择验证所有的或者某个他们处理的数据包或者不验证他们处理的数据包。他们也可以动态地适应、核实更多的数据来对检测到的攻击做出响应。
5.2 管理信任
尽管CCN在点到点类型中移动数据包，它在内容发布者和内容消费者之间提供端到端的安全。CCN内容消费者必须决定是否接收的内容是可以接受的，或者是值得信任的。CCN的信任观念是与上下文有关的，例如，在特殊内容的环境中被仔细的决定，并和它将使用的目的有关。例如，请求者可能需要一个被法院授权的某人签名的合法的文档或者在一个博客中签名了其他条目的同样的人签名的博客——或者甚至不是那样。这样的使用更加灵活和容易，而不是尝试要求信任一个大小适应所有的方法，例如一致地标志发布者好或者坏。
这个基本的简单的基于内容的安全——从名字到内容的认证绑定——能够被用来实现建立高层信任的机制。CCN在名字和内容之间的签名绑定本质上扮演着保证内容的角色。当名字指的是个人或组织时，内容是一个公钥，绑定结果本质上是一个数字证书。这允许CCN容易地支持传统的机制来用密钥建立信任。更有趣地是，通过允许的内容安全地链接，我们可以允许一些内容来证明其他内容。这提供了一个有力的机制，通过这个机制我们可以利用很少数量的密钥的信任到一个大的内部连通的内容森林的信任。
5.2.1 信任密钥
应用程序级的CCN消费者必须解决传统的密钥管理问题——把公钥和个人、组织相关联，这些真实世界的身份极大地决定了对一个给定的内容片谁是一个可接受的签名者。CCN以几种方式简化了这个任务：第一，它直接处理仅仅获得对验证内容片必要的密钥这个实际问题。密钥仅仅是另一种类型的CCN数据包，简单的命名约定使他们能够容易地被找到。
第二，像上面提到的，仅仅发布一个密钥，CCN为它有效地生成一个证书——为密钥绑定一个CCN名字作为签名者（发布者）的认证。这个构造块在CCN中能够直接被用来代表密钥之间的任意的可信关系——从简单的树，像在传统的基于认证的公钥基础设施（PKI）里，到任意的被PGP信任网络使用的图。
第三，CCN没有要求一个大小适应所有的可信模型。信任存在于发布者和内容消费者之间，对一个应用程序合适的东西可能对另一个应用程序不合适。用户可以自由重用现在存在的模型（例如PKI）来用密钥建立信任，或者来定义新的对CCN更加合适的模型。
一个特别适合于CCN的模型是SDSI/SPKI模型。在这个模型中，密钥通过本地控制的命名空间被映射到身份，例如一个组织的成员可能被识别，因为他们的密钥被组织自身认证，而不是因为他们被一些外部来源，第三方信任机构认证（例如Verisign）。知道parc.com的密钥，我们能够认证它的员工的密钥。更强大的是，如果我们知道并信任parc.com的一个员工，我们可能在他的SDSI命名空间中查询parc.com的身份和密钥。从少量的公钥认证开始，使用各种各样的用户友好的机制（例如，个人联系，组织成员关系，公众体验），一个人可以使用SDSI模型来在大数量的发布者中推断信任。
我们可以将SDSI身份直接映射到CCN名字，并直接向CCN内容发送SDSI信任关系。这样的命名空间由一个树森林组成——因为任何原因，从直接的经验（例如他们是PARC的员工），到朋友提供的信息，到它的在可信密钥目录清单中的呈现，内容消费者可能相信他们有parc.com的正确密钥（或者/parc.com/george的正确密钥）。我们不需要，或者不期望所有这样的树都被加到一个单独的（或小数量的）根，像在传统的全球的或者商业的PKI中那样。最显而易见的是，是消费者通过使用许多类型的信息决定他们为什么信任一个特别的密钥，而不是发布者从一个特别的供应商那里获得一个证书。
进一步地，通过依据层次命名空间组织内容，CCN允许签名策略，甚至密钥，来附加到特殊的内容名字；对内容名字空间中一层的授权由一个高层的密钥签名给出。图7显示了parc.com的密钥授权了用户george，然后george给他的桌面电脑授权了这个密钥。这些可信的陈述，表示为CCN数据，帮助消费者评估是否他是一个parc.com/george名字空间的WidgetA.mpg的可接受的发布者。
图7：CCN信任的建立与使用公钥的内容命名空间相关联
5.2.2 基于证据的安全
我们可以给我们结构化名字的观念添加一个与安全相关的表示，很像一个可信的超链接或者书签。一个CCN内容项能够参考另一个（链路目标），不仅仅通过目标的名字，也通过他的内容的加密摘要（有效地形成一个自证明名字）或者通过发布者的身份密钥。这样的参考文献能够被用来表达授权，也就是说一个名字为N的链路的发布者P的目标是（N’,P’），想要以名字N来指代发布者P’通过目标名字N’指代的东西。
这样的参考文献可以表达传统的授权形式，但是他们也能够被用来构建一个拥有可信内容的网络——单独的签名内容片有效地证明他们安全地适用的其他内容片。例如，已经决定信任内容A，比如说一个网页，用户可能自动地信任内容A安全地连接到——比如，它的图片、广告、原始资料等等，而没有额外的管理或者配置费用。这个信任是非常细粒度的，那些资料仅在环境A中被认为是有效的。
用户遇到的内容的每个分片也扮演着他所指的内容的有效性的证据的一个可能分片。如果我们信任的许多的发布者都说他们因为N’相信P’的价值,我们也很可能相信他。如果一个攻击者破坏了一个单独的发布者，例如，获得了P’’密钥，并使用它来伪造一个N’的恶意值，攻击将会失败，因为绝大多数的证据仍然指向正确的值。由于每个分片拥有额外签名支持的可信内容，攻击越来越难以成功，因为攻击者不能简单地破坏所有的可用证据。
5.3 内容保护和访问控制
最初对CCN内容的访问方法的控制是加密。CCN不需要可信的服务器或者目录来强制访问控制策略；不论谁偶然发现了私有内容，仅仅授权的用户能够解密。
内容的加密，或者甚至名字或名字组件的加密，对网络是完全透明的——对CCN来说，是所有的仅仅命名的二进制数据（尽管有效的路由选择和数据序列可能需要将一些名字组件用普通文字保留）。解密密钥可能连同他们的内容一起是分布式的，像CCN数据包块。名字约定，被封装在程序员友好的函数库中，能够使找到解密密钥更加容易，这个密钥对一个授权用户解密特定的内容片是必需的。CCN不托管任何特殊的加密或者密钥分布方案——任意的，适合应用程序的访问控制模型能够被仅仅通过选择怎样编码和分配特定内容的解密密钥实现。
5.4 网络安全和策略实施
CCN的设计保护它免受许多种类的网络攻击。认证所有的内容，包括路由选择和策略信息，防止数据被欺骗或者篡改。事实是CCN消息能够仅仅谈论内容，而不能简单地与主机交谈，这使得向一个特定目标发送恶意包很困难。为了高效，对CCN的攻击必须聚焦在拒绝服务攻击：隐藏合法的内容（例如，仅仅不返回一个可靠的最近的版本），或者淹没合法内容——通过用大量伪造包淹没合法内容来防止合法内容的传送。
为了确保在可能拥有伪造包的接口中得到他们想要的内容，消费者能够把约束条件加在内容能够满足消费者兴趣包的发布者身上。有效的约束条件尝试在网络效率和内容消费者的易使用性上取得平衡。消费者（或者作为消费者代表的软件库）能够最小化地指定特定的发布者（公钥），消费者想要让他们期望的内容被这个发布者签名，或者指定已经被内容发布者签名的密钥。这个间接层次避免了系统的脆弱性，需要内容消费者知道什么特定的密钥签名了他们想要先验的内容。
CCN组合了许多机制来防止过度转发不需要的流量。兴趣包和数据包之间的流平衡防止超越本地链路的数据包洪泛的强力拒绝服务攻击。流平衡以逐跳方式操作。仅仅被下游兴趣包请求的数据包将会被在一个特定链路上转发，不论提供了多少数据包。即使在许多网络上的兴趣包转发寻找匹配的数据包（不太可能的，但是依赖于路由选择），在每个汇聚点上，仅仅一个单独的数据包将被向内容消费者转发。基于数据的分布式拒绝服务攻击（DDoS）很简单，但是不可能。
因为兴趣包能够被消费者以一个他们选择的频率生成，理论上实施兴趣包的洪泛攻击是可能的——期望淹没结点的可用带宽或者网络CCN路由器，大量兴趣包的分布式生成是匹配内容的最可能来源。多个兴趣包请求同样的数据包将会被CCN路由器结合起来。仅仅单独的拷贝将会被转发到上游。因此为了试图兴趣包洪泛，攻击者必须生成以被目标提供的前缀开始的名字的兴趣包，但是它包含唯一的名字组件（为了防止兴趣包结合）。因为CCN路由选择允许不存在的内容的兴趣包的传递，这样的兴趣包将会被正常地转发到他们意图目标。
两个CCN路由选择的特征使得减轻这样的攻击很容易：首先，因为数据包跟随着他们满足的兴趣包的路径返回消费者，每一个CCN中间结点能够看见，对每个他转发的兴趣包，是否兴趣包成功地获取了数据包。（在IP网络中不是这样，网络的转发和返回路径通常不同。）这样随机的生成兴趣洪泛包将通常不会导致数据包回复。一个简单的自适应算法允许中间路由器限制他们以一个特定前缀转发的兴趣包的数量，根据那个前缀的之前的兴趣包被成功返回数据包的数量。第二，受到攻击的区域能够让下游路由器来节流他们通过名字前缀转发的兴趣包的数量，很像一个IP网络可以让上游IP来节流或者阻塞访问未使用地址的尝试。然而，CCN的将策略附加在内容名字空间的能力允许在语义上选择性地控制。
CCN也提供允许一个组织在他们的内容传播过程中的控制工具。属于一个组织或者服务提供者的路由器能够强制执行基于策略的路由，内容转发策略与内容名字或者签名者相关。一个简单的例子是如果请求内容在/parc.com/public名字空间下，那么内容防火墙仅允许来自因特网的兴趣包被满足。一个组织能够发布他的关于什么密钥能够签名一个特定名字前缀（例如，所有的密钥以ccnx.org签名）下的内容的策略，内容路由器自动地丢掉没有满足那些请求的内容，而不让那些路由器理解涉及的名字或者组织的语义。最后，兴趣包能够在特定的情况下被数字签名，允许策略路由选择限制到某个命名空间，或者特定的签名者查询的频率。
6. 评估
在这部分，我们描述和评估我们的CCN实现原型的性能。我们当前的实现以ccnb紧凑二进制XML表示法来编码包，使用基于字典的标签压缩。我们的CCN转发者，ccnd，用C语言实现，作为一个用户空间守护进程。以UDP封装的兴趣包和数据包通过广播、多播或单播在现在存在的网络上转发。
绝大多数使用CCN的机制（ccnd通信、密钥管理、签名、基本的加密和信任管理）在CCN函数库中被具体化。这个函数库，用Java和C实现，为名字和数据封装共同的会话，比如编码碎片和名字的版本控制，或者加密密钥的代表信息和信任管理。这些约定以配置文件组织，表示在基本的CCN兴趣包——数据包上的特定应用程序协议层。
这个体系结构有两个含义。首先，敏感数据的安全边界被推送到应用程序；内容只在有权力解密的应用程序中被解密，而不在操作系统网络栈或者磁盘上被解密。第二，许多工作在应用程序中使用CCN，这些工作包含指定的命名和数据约定，并在发布者和消费者之间达成一致。
所有的组件运行在Linux，Mac OS XTM，SolarisTM，FreeBSD，NetBSD和Microsoft WindowsTM。加密操作被OpenSSL和Java提供。
6.1 数据传输效率
TCP擅长移动数据。对在地球上的路径的成块传输，他通常传送应用程序到应用程序的数据吞吐量靠近理论上的最大值（瓶颈链路带宽）。TCP能够填充管道，因为它的可变的窗口大小允许传输足够的数据来填充带宽×延时的路径乘积加上所有的中间的存储转发缓存阶段。CCN的拥有多个兴趣包突出的能力给了它同样的能力（见3.1节），我们期望它的数据传输性能和TCP相似。
为了测试这个，我们测量了需要传输一个6MB文件的时间，根据TCP的窗口大小和突出数据包的数量（CCN）。这个测试运行在两个Linux主机之间，主机以100Mb/s的链路连接到我们的校园以太网。对TCP测试，文件使用测试工具ttcp来转移。对CCN测试，通过本地请求，文件被预安排进源的ccnd主存中。（测试将仅仅反映通信代价和CCN内容产生的签名代价。）这导致6278个独立命名的签名的CCN内容对象，每个拥有1KB数据（结果对象大小大约1350字节）。
图8：大量数据传输性能
结果如图8所示。（由于CCN在包大小的内容块上做处理，TCP的窗口大小被每个包的用户数据量分开，并将它转换成包。）CCN需要5倍的TCP流水线，20个包，而TCP需要4个包，来达到他的吞吐量渐近线。这是一个额外的存储转发阶段的人工制品，由我们的原型的完全非最优化的任务级的实现引进，而TCP是一个高度优化的内核实现。TCP的吞吐量渐近线达到链路带宽的90%，反映了包头开销（负载对包大小的比率）。CCN吞吐量渐近线是链路带宽的68%。由于在这个测试中，CCN被封装在IP/UDP中，他有TCP测试的全部开销加上自己头部的额外的22%。因此，在这个例子中，CCN的块数据传输效率可与TCP比较，但是由于他的大的头部开销，因此传输效率更低。（相比于TCP，绝大多数CCN的头部大小增加是由于他的安全性注释（签名，证人和密钥定位器）。
块级数据传输性能对像下载大的多媒体文件很重要，但是用户对网速的感觉被网络可以多么快地传送（很小的）网页内容条目驱动。我们用HTTP和HTTPS比较CCN获取单独HTML文件的相对性能。对不安全的HTTP例子来说，我们使用Wells Fargo Bank的主页。可以测量到两个不同的CCN封装：直接达到1500字节的以太网包（没有IP或者UDP头部），使用1230字节的负载，并使用一个最大负载为7656字节的UDP数据报。（由于这些数据报大于1500字节的路径MTU，它们被IP层分片了。数据包和字节计数包括帧和帧头。）
表1：网络内容效率
这个结果在表1中总结。前两列给出了字节的总体数量和被客户端发送和接收的包(包括所有的协议头和控制流量，比如SYNs和ACKs)。最后两列由前两列计算得出，并且给出了每个协议的开销百分数：封装措施是数据的封装开销，是开销字节（接收到的全部字节——接收到的数据字节）对数据字节的比率。处理措施是处理开销（请求内容的代价），是发送的全部字节对接收到的数据字节的比率。
通过CCN的内容传送总是安全的，结果显示它匹配了不安全的HTTP的性能，并实质上胜过安全的HTTPS。在以太网上的CCN本质上与HTTP相同（更多的字节，但是更少的包和更少的往返时间），并且是HTTPS效率的两倍（一半是包的数量）。在巨大的UDP上的CCN是HTTP效率的两倍，并在开销和包上是HTTPS效率的三倍。
6.2 内容分发效率
前面的部分比较了当CCN被用作TCP的嵌入式替代时，例如没有数据共享的点对点会话时，CCN和TCP的性能。然而，CCN的一个主要的力量是它提供自动的透明的所有数据的共享，本质上给出了一个最佳情景化的所有内容的网络代理，但是没有提供预安排或者配置。
为了测量共享性能，我们比较了在一个网络瓶颈链路上使用TCP和CCN同时获取一个大文件的多个副本的总时间。测试配置如插图9所示，并包含一个源结点通过10Mbps共享链路连接到一组6槽的通过1Gbps链路互连的结点。（我们使用10Mbps的瓶颈链路来清晰地展示饱和行为，甚至在仅仅拥有很少量结点的情况下。）机器使用各种各样的体系结构（Intel，AMD，PowerPC G5）和操作系统（Mac OS X 10.5.8，FreeBSD 7.2，NetBSD 5.0.1，Linux 2.6.27）。
这些槽同时从源拉取一个6MB数据文件。对TCP测试，通过源的一个http服务器这个文件可以访问和被使用curl的槽获取。对CCN测试，这个文件被预安排，像6.1节中描述的那样。对每个测试，整个文件的内容都被获取，我们记录了完成这个任务的最后结点的运行时间。对每个测试配置运行了多次尝试，这些测试因作为槽参与的特殊机器的不同而不同。
图9：总共传输时间对比槽的数量
测试结果如图9所示。拥有单个槽的TCP的更好的头部效率允许TCP比CCN完成得更快。但是尽管槽的数量线性地增加了TCP的完成时间，CCN的性能仍然恒定不变的。注意到由于使用CCN的性能代价对比TCP大约为20%，然而由共享获得的性能是整数倍的，甚至当共享比率/命中率低的时候，使用CCN仍然会赢得网络性能。这个赢得实际上比他在测试中出现的更大，因为CCN独立地在网络中的每条链路上应用，可以彻底地减轻我们现在在常见内容集线器和主要的对等点中看到的流量集中度。例如，今天一个受欢迎的YouTube视频将会穿过youtube.com和他的ISP之间的链路几百万次。如果视频通过CCN分布，它将只穿过那条链路一次。在当前的体系结构中，在聚合点的流量负载峰值规模类似于受欢迎内容的总共消耗率。在CCN中，他们测量了受欢迎内容的创造率，今天的数值是以指数方式降低的。
6.3 Voice-over-CCN和策略层
为了展示CCN怎样支持任意的点到点协议，我们实现了Voice-over-IP(VoIP)在CCN上面(VoCCN)。实现细节和性能测量在文献中给出。在这一部分，我们描述了一个使用VoCCN调用的测试来演示CCN策略层的行为和优势。
像在3.3节中描述的那样，当FIB包含一个内容前缀的多个接口时，策略层动态地选择最好的。这个可以实现是因为CCN能够在多个出接口发送同样的兴趣包（由于没有环路危险），因为一个CCN结点能够保证看见对它的兴趣包响应的数据包的发送（不像IP，请求和响应路径可能几乎完全不同）。这两个特性允许策略层在兴趣包被偶然从所有与这个前缀相关的接口发出的实验中运行。如果一个接口比现在最好的接口响应速度还快，它将变成新的最好接口，并被唯一地用于前缀的兴趣包，直到下一次实验的时间到达（例如，在200个包后，当载体或者SSID有改变时，或者当兴趣包没有得到响应并超时时）。
为了测试这个机制，我们运行我们在两个Linux2.6.27的机器（一个3.4GHz Intel P4，另一个2.66GHzIntel Core2 Duo）之间运行基于linphone的VoCCN客户端，每个连接到两个独立的1Gbps以太网线缆上。这个linphone默认是把音频包格式化为20ms的帧，因此音频活动导致了一个恒定的50pps的RTP包源。通过话音质量的测量，我们的安全VoCCN原型性能与库存linphone的性能相同。两边的客户端都没有包丢失，然而小数量的VoCCN包（<0.1%）由于到达太晚而被丢弃。
通过手动地断开和重新连接网络电缆，我们执行容错测试。图10显示了在一个测试中两条链路上的流量。策略层最初挑选了链路B，但是在15秒之内调用它转换到链路A，对在测量响应时间时一些小的变化做出响应，然后在40秒转换回链路B。在45秒我们拔去链路A，但这对这一时刻正在使用的链路B没有影响。在60秒链路A被重新连接。在82秒链路B断开了。策略层转换到链路A，链路A的流量速率有一个小的超过50pps的偏移，因为在失败检测期间生产的包是从上游ccnd获取的。在95秒，链路B重新连接了，流量仍然在链路A。在120秒链路A断开，CCN策略层转换回链路B，但是失败检测这次花费太长的时间，像大量的流量突然出现在紧跟着转换的B上显示的那样。在160秒，存在更多自发的转换，调用在165秒终止。
图10：CCN自动容错
容错行为没有编码进我们的客户端，但是完全从CCN的核心传输出现。最终的容错的小的延迟反映了我们当前实现的初步状态（不监听来自以太网驱动器的载体丢失通知，因此失败检测超时了，而不是事件驱动）。有趣地注意到失败之后，客户端能够从CCN获取丢失的会话数据：一些包延迟了，但并没有丢失。
7. 相关工作
人们广泛地认识到将身份和位置信息结合进一个单独的网络地址不能满足今天应用程序和移动环境的需要。在当今的因特网体系结构上实现提议的补救措施的功能，或者以一个从零开始的方法代替当前的体系结构，或者两者的结合。像CCN，这些建议的目标是从面向主机网络到面向内容网络的转换，来满足数据密集型应用程序的需要。
前面的面向内容的网络（CON）研究被无结构的难懂的通常是自证明的内容标签的使用所统治。这些系统面临的挑战是有效的路由查询和基于扁平化名字的数据，提供一个间接的机制来将用户有意义的名字映射到难懂的标签。
面向数据的网络体系结构（DONA）用扁平的自证明的名字和在IP层之上的基于名字的任播原语来代替DNS名字。DONA中的名字是一个发布者密钥的加密摘要，和一个用户友好的标签——然而，标签没有安全地绑定内容，允许替代攻击。不像CCN，数据不能动态地生成来响应查询——DONA中的内容必须首先被发布，或者注册，通过一个可信的树状解析处理器来使获取成为可能。每个解析处理器必须保持一个大的转发表来为网络中的每个内容片提供下一跳信息。一旦内容被定位，包通过最初的请求者使用标准的IP路由被交换。如果内容片的位置改变了，新的请求将会失败直到新的注册通过网络传播。CCN相反，能够向所有内容片可能的位置转发请求。
许多系统利用分布式哈希表（DHT）来对难懂的内容名字进行路由查询。ROFL（扁平标签上的路由选择）直接对自由语义的扁平标签评估了路由选择的可能性。一个圆形命名空间被创建来确保正确的路由选择，但是额外的指标被添加来缩短路径。用相似的方法，i3通过使用包标识和DHT的结合区分了发送和接收的行为。接收者将拥有数据标识符的触发器和他们的地址插入DHT。触发器被路由到合适的接收者，接收者通过用包含相同ID和请求数据的响应包满足请求。SEATTLE利用一跳DHT的扁平编址来提供拥有反应地址解析的目录服务和服务发现。不像CCN，所有这些系统需要内容被明确的发布，以便在内容被获取之前告知DHT内容的位置。也不像CCN，这个获取存在很大的位置自由度——查询可能获取路由路径上数据的一份缓存拷贝，但并不保证获取最近的可用拷贝。
代替依据标识名字的端到端的路由选择，PSIRP工程建议使用集合作为网络原语。每个数据片都有一个公有的和私有的标签，用来验证发布者并做出路由选择决定。消费者通过一个不安全的目录服务映射想要使用的用户友好的名字到一个难懂的公有标签来接收内容。这个标签被用来订阅数据片，触发系统来定位和传送响应内容。尽管被和CCN同样的问题激发，PSIRP遭遇了无结构化的标识符使用和缺少强健的在用户有意义的名字（或者当前，甚至他们的难懂的标签）和内容之间的加密绑定。
4WARD NetInf工程有和CCN相似的目标，但是聚焦于信息模型和抽象的高层问题。他当前使用DONA样式的数据包和信息对象命名，提供一个发布/订阅式的API。这个NetInf字典基础设施使用DHT作为名字解析和位置查询。
TRIAD，类似于CCN，尝试用用户友好的结构化的高效的位置独立的名字来命名内容。TRIAD使用URL作为名字，使用一个完整的目录从URL的DNS组件映射到最近的数据的可用副本。然后向下一跳转发请求，一直持续直到找到数据包的拷贝。他的位置返回到客户，客户将使用标准的HTTP/TCP来获取他。TRIAD依赖可信的目录来验证内容查询（但不是内容自身），建议为额外的安全性，将网络限制到相互信任的内容路由器。
对内容感知的路由选择协议的研究也尝试提高交付性能和减少流量开销。例如，Anand等人研究了大规模包缓存的优势来减少冗余的内容传输。在这个工作中，路由器识别之前的转发内容，从在传输中的包中脱去内容，用代表性的指纹代替内容部分。下游路由器在发送给请求者之前从自己的内容缓存中重建内容。
8. 结束语
今天的网络使用以移动内容为中心，但是今天的网络仍然按照主机到主机的会话方式工作。CCN是一个建筑在IP工程原则上的网络体系结构，但是使用命名的内容而不是主机标识作为主要抽象。这个结果保持了IP的简单性和可扩展性，但是提供了更好的安全性，传送效率和破坏容忍度。CCN是为替代IP设计的，但是能够作为覆盖网被增量部署——使它的功能优势对应用程序可用，而不需要普遍采纳。
我们实现了一个CCN网络栈的原型，演示了它在内容分发和点对点网络协议上的有用性。我们以开源的形式发布了这个实现，并可供大家使用。
感谢
我们感谢Paul Stewart, PaulRasmussen和Simon Barber在实现上的大量帮助。我们也感谢Ignacio Solis, Marc Mosko, Eric Osterweil和DirkBalfanz的富有成效的讨论和建议。
9. 参考文献
[1]Project CCNxTM. http://www.ccnx.org, Sep. 2009.
[2]M. Abadi. On SDSI’s Linked Local Name Spaces.Journal of Computer Security, 6(1-2):3–21,October 1998.
[3]B. Adamson, C. Bormann, M. Handley, and J. Macker. Multicast Negative-Acknowledgement (NACK) Building Blocks. IETF, November 2008. RFC 5401.
[4]W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, and J.Lilley. The Design and Implementation of an Intentional NamingSystem.SIGOPS Oper. Syst. Rev., 33(5):186–201,
1999.
[5]A. Anand, A. Gupta, A. Akella, S. Seshan, and S. Shenker. PacketCaches on Routers: The Implications of Universal RedundantTraffic Elimination. InSIGCOMM, 2008.
[6]H. Balakrishnan, K. Lakshminarayanan, S. Ratnasamy, S.Shenker, I. Stoica, and M. Walfish. A Layered Naming Architecturefor the Internet. InSIGCOMM, 2004.
[7]M. Caesar, T. Condie, J. Kannan, K. Lakshminarayanan, I.Stoica, and S. Shenker. ROFL: Routing on Flat Labels. In SIGCOMM, 2006.
[8]D. Cheriton and M. Gritter. TRIAD: A New Next-Generation InternetArchitecture, Jan 2000.
[9]I. Clarke, O. Sandberg, B. Wiley, and T. W. Hong. Freenet: A DistributedAnonymous Information Storage and Retrieval System.Lecture Notes in Computer Science, 2009:46, 2001.
[10]C. M. Ellison, B. Frantz, B. Lampson, R. Rivest, B. M. Thomas,and T. Ylonen.SPKI Certificate Theory, September 1999.RFC2693.
[11]S. Farrell and V. Cahill.Delay- and Disruption-Tolerant Networking. Artech House Publishers, 2006.
[12]K. Fu, M. F. Kaashoek, and D. Mazières. Fast and secure distributedread-only file system.ACM Trans. Comput. Syst., 20(1):1–24,2002.
[13]J. F. Gantz et al. IDC - The Expanding Digital Universe: A Forecastof Worldwide Inform ation Growth Through 2010. Technicalreport, March 2007.
[14]A. Gulbrandsen, P. Vixie, and L. Esibov.A DNS RR for specifying the location of services (DNS SRV). IETF - NetworkWorking Group, The Internet Society, February
2000.RFC 2782.
[15]E. Guttman, C.Perkins, J. Veizades, and M. Day.Service Location Protocol. IETF - NetworkWorking Group, The InternetSociety, June 1999. RFC 2608.
[16]IETF. RFC 2328 – OSPF Version 2.
[17]IETF. RFC 3787 – Recommendations for Interoperable IP Networksusing Intermediate System to Intermediate System (IS-IS).
[18]IETF. RFC 4971 – Intermediate System to Intermediate System(IS-IS) Extensions for Advertising Router Information.
[19]IETF. RFC 5250 – The OSPF Opaque LSA Option.
[20]V. Jacobson. Congestion Avoidance and Control. In SIGCOMM, 1988.
[21]V. Jacobson, R. Braden, and D. Borman.TCP Extensions for High Performance. IETF - NetworkWorking Group, The InternetSociety, May 1992. RFC 1323.
[22]V. Jacobson, D. K. Smetters, N. Briggs, M. Plass, P. Stewart, J.D. Thornton, and R. Braynard. VoCCN: Voice-over Content-CentricNetworks. InReArch, 2009.
[23]C. Kim, M. Caeser, and J. Rexford. Floodless in SEATTLE: AScalable Ethernet Architecture for Large Enterprises. In SIGCOMM, 2008.
[24]T. Koponen, M. Chawla, B.-G. Chun, A. Ermolinskiy, K. H. Kim,S. Shenker, and I. Stoica. A Data-Oriented (and Beyond)Network Architecture. InSIGCOMM, 2007.
[25]J. Kubiatowicz et al. OceanStore: An architecture for global-scalepersistent storage.SIGPLAN Not., 35(11):190–201,2000.
[26]D. Mazières, M. Kaminsky, M. F. Kaashoek, and E. Witchel. SeparatingKey Management from File System Security. In SOSP, 1999.
[27]R. C. Merkle. Secrecy, authentication, and public key systems. PhD thesis, 1979.
[28]R. Moskowitz and P. Nikander.Host Identity Protocol Architecture. IETF - Network Working Group, May2006. RFC4423.
[29]B. Ohlman et al. First NetInf architecture description, April 2009.http://www.4ward-project.eu/index. php?s=file_download&id=39.
[30]E. Osterweil, D. Massey, B. Tsendjav, B. Zhang, and L.Zhang. Security Through Publicity. InHOTSEC, 2006.
[31]B. C. Popescu, M. van Steen, B. Crispo, A. S. Tanenbaum, J.Sacha, and I. Kuz. Securely replicated web documents. In IPDPS, 2005.
[32]R. L. Rivest and B. Lampson. SDSI - A Simple Distributed SecurityInfrastructure. Technical report, MIT, 1996.
[33]M. S鋜el?, T. Rinta-aho, and S. Tarkoma. RTFM: Publish/SubscribeInternetworking Architecture. In ICT-MobileSummit, 2008.
[34]D. K. Smetters and V. Jacobson. Securing network content, October2009. PARC Technical Report.
[35]I. Stoica, D. Adkins, S. Zhuang, S. Shenker, and S. Surana. InternetIndirection Infrastructure. InSIGCOMM, 2002.
[36]I. Stoica, R. Morris, D. Karger, F. Kaashoek, and H.Balakrishnan. Chord: A Scalable Peer-To-Peer Lookup Servicefor Internet Applications. InSIGCOMM, 2001.
[37]D. Wendlandt, D. Andersen, and A. Perrig. Perspectives: ImprovingSSH-style host authentication with multi-path probing.InUSENIX, 2008.