GB/T 38801-2020
基本信息
标准号： GB/T 38801-2020
中文名称：内容分发网络技术要求互联应用场景
标准类别：国家标准(GB)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：567499
标准分类号
关联标准
出版信息
相关单位信息
标准简介
GB/T 38801-2020.Technical requirements for content distribution network-Interconnection use cases.
1范围
GB/T 38801规定了内容分发网络之间互联的应用场景。
GB/T 38801适用于内容分发网络之间的互联。
2术语和定义、缩略语
2.1 术语和定义
下列术语和定义适用于本文件。
2.1.1
内容分发网络 content distribution network
为更有效地向端用户交付内容,在4层~7层网络单元进行互操作的网络基础设施。
注:典型的CDN由请求路由系统、分发系统(包括缓存设备/功能集)、日志系统以及CDN控制系统组成。
2.1.2
授权的CDN authoritative CDN
为分发和交付CSP的内容,通过由CSP授权的CDN或由CSP授权的CDN的下游CDN与CSP直接相关联的CDN。
2.1.3
CDN提供者 CDN provider
运营CDN并提供内容分发服务的业务提供者。
注:给定的实体可能同时作为多个运营角色提供多种服务。
2.1.4
内容 content
任何形式的数字化的数据。
注:具有分发和交付的内容,包括流媒体、图片、文本等。
2.1.5
内容服务 content service
为端用户提供特定格式的内容。
注:内容服务包括完全的服务,可以仅提供访问内容的完全服务、节目指南等。
2.1.6
控制系统 control system
负责启动和控制CDN的其他构件以及处理与外部系统交互的CDN功能。
2.1.7
交付 delivery
负责向端用户交付部分内容的CDN功能。
2.1.8
分发系统 distribution system
负责分发内容、分发元数据以及CDN中内容本身的CDN功能。
1范围
GB/T 38801规定了内容分发网络之间互联的应用场景。
GB/T 38801适用于内容分发网络之间的互联。
2术语和定义、缩略语
2.1 术语和定义
下列术语和定义适用于本文件。
2.1.1
内容分发网络 content distribution network
为更有效地向端用户交付内容,在4层~7层网络单元进行互操作的网络基础设施。
注:典型的CDN由请求路由系统、分发系统(包括缓存设备/功能集)、日志系统以及CDN控制系统组成。
2.1.2
授权的CDN authoritative CDN
为分发和交付CSP的内容,通过由CSP授权的CDN或由CSP授权的CDN的下游CDN与CSP直接相关联的CDN。
2.1.3
CDN提供者 CDN provider
运营CDN并提供内容分发服务的业务提供者。
注:给定的实体可能同时作为多个运营角色提供多种服务。
2.1.4
内容 content
任何形式的数字化的数据。
注:具有分发和交付的内容,包括流媒体、图片、文本等。
2.1.5
内容服务 content service
为端用户提供特定格式的内容。
注:内容服务包括完全的服务,可以仅提供访问内容的完全服务、节目指南等。
2.1.6
控制系统 control system
负责启动和控制CDN的其他构件以及处理与外部系统交互的CDN功能。
2.1.7
交付 delivery
负责向端用户交付部分内容的CDN功能。
2.1.8
分发系统 distribution system
负责分发内容、分发元数据以及CDN中内容本身的CDN功能。
标准图片预览
标准内容
ICS33.160.60
中华人民共和国国家标准
GB/T38801—2020
内容分发网络技术要求
互联应用场景
Technical requirements for content distribution network-Interconnection use cases
2020-06-02发布
国家市场监督管理总局
国家标准化管理委员会
2020-12-01实施
GB/T38801—2020
2术语和定义、缩略语
术语和定义
缩略语
3概述
互联应用场景
扩展服务范围应用场景
4.1.1扩展服务的地理范围
分支机构之间互联
4.1.3ISP处理第三方内容·
4.1.4用户漫游应用场景
4.2负载均衡应用场景
4.2.1分流突发忙时业务量互联应用场景4.2.2增加CDN弹性的互联应用场景4.3能力扩展应用场景
4.3.1设备和网络技术扩展
技术和供应商互操作
改进QoE和QoS·
本标准按照GB/T1.1—2009给出的规则起草本标准由中华人民共和国工业和信息化部提出。本标准由全国通信标准化技术委员会（SAC/TC485）归口。GB/T38801—2020
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任，本标准起草单位：中国信息通信研究院、中国电信集团公司、中国联合网络通信集团有限公司、中国移动通信集团公司。
本标准主要起草人聂秀英、陈戈、梁洁、乔治、陈炜。1
1范围
内容分发网络技术要求
互联应用场景
本标准规定了内容分发网络之间互联的应用场景。本标准适用于内容分发网络之间的互联2
术语和定义、缩略语
2.1术语和定义
下列术语和定义适用于本文件。2.1.1
内容分发网络
:content distribution networkGB/T38801—2020
为更有效地向端用户交付内容，在4层～7层网络单元进行互操作的网络基础设施。注：典型的CDN由请求路由系统、分发系统（包括缓存设备/功能集）、日志系统以及CDN控制系统组成，2.1.2
授权的 CDN
authoritativeCDN
为分发和交付CSP的内容，通过由CSP授权的CDN或由CSP授权的CDN的下游CDN与CSP直接相关联的CDN。
CDN提供者
CDNprovider
运营CDN并提供内容分发服务的业务提供者。注：给定的实体可能同时作为多个运营角色提供多种服务。2.1.4
内容content
任何形式的数字化的数据。
注：具有分发和交付的内容，包括流媒体、图片、文本等。2.1.5
contentservice
内容服务
为端用户提供特定格式的内容。注：内容服务包括完全的服务，可以仅提供访问内容的完全服务、节目指南等，2.1.6
control system
控制系统
负责启动和控制CDN的其他构件以及处理与外部系统交互的CDN功能。2.1.7
交付delivery
负责向端用户交付部分内容的CDN功能。2.1.8
分发系统免费标准下载网bzxz
distribution system
负责分发内容、分发元数据以及CDN中内容本身的CDN功能GB/T38801—2020
下游CDNdownstreamCDN
对于给定的端用户请求，其他CDN(上游CDN)被重定向到请求直接互联的CDN（在上下级直接互联的CDN场景中）。
enduser
端用户
系统的“真实”用户。
注：典型的是指个人的硬件和/或软件的某些组合。2.1.11
网络服务提供者
network serviceprovider
向端用户提供基于网络连接/服务的提供者。2.1.12
体验质量
quality of experience
表达用户体验到的质量等级描述注：可采用主观分数表示用户体验和/或体验到的QoS等级。QoE具有两个主要的成分：定量和定性。定量成分可能受完整的端到端系统效果的影响（包括用户设备和网络基础设施）。定性成分可能受用户的期望、周围环境、心理因素以及应用场景等影响。QoE也可被看作是用户接受到、接收到和理解到的服务质量（QoS)以及影响用户体验服务的相关定量因素。2.1.13
catchdevice/function
缓存设备/功能
为在CDN内部控制和分发内容，与CDN的其他模块交互，即交付内容与端用户进行交互的设备/功能。
注：典型的缓存设备/功能可缓存端用户请求的内容，这样缓存设备/功能在响应多个用户代理（它们的端用户）请求时，能够直接交付相同的内容，以避免通过核心网络将同一内容传送多次。2.1.14
upstreamCDN
上游CDN
对于给定的端用户请求，将请求重定向到下级CDN(在直接互联的CDN场景中）。2.1.15
用户代理
useragent;UA
通过端用户与内容服务进行交互的软件（或硬件和软件的组合）。注：用户代理与内容服务或CDN进行通信为用户交付内容。这类通信不限于使用HTTP协议，也可通过其他协议。用户代理的例子(非全部)是浏览器、机项盒(STB)或专用的内容应用。SA
接入CDN
accessCDN
在相同的管理网络中，作为接入端用户的CDN。注：为向内容服务提供者提供附加的内容交付服务·这类CDN能够使用端用户网络上下文的精确信息。2.2
缩略语
下列缩略语适用于本文件。
CDN：内容分发网络（ContentDistributionNetwork）CDNI：内容分发网络互联（ContentDistributionNetworkInterconnection）CSP：内容服务提供者（ContentServiceProvider）dCDN：下游内容分发网络（downstreamContentDistributionNetwork）DNS：域名系统（DomainNameSystem）2
EU：端用户（EndUser）
ISP：互联网服务提供者（InternetServiceProvider）NSP：网络服务提供者（NetworkServiceProvider）QoE：体验质量（QualityofExperience）QoS：服务质量（QualityofService）uCDN：上游内容分发网络（upstreamContentDistributionNetwork）3概述
GB/T38801—2020
全球互联网由分布在各地的不同ISP组建的网络互联而成并为全球范围内的用户提供服务。内容分发网络为承载在互联网之上的重叠网络，根据其所服务的内容业务提供者的不同需求，提供内容加速服务，以提升用户的QoE和QoS。4互联应用场景
4.1扩展服务范围应用场景
4.1.1扩展服务的地理范围
该互联应用场景是指在不降低交付质量，不需要增加附加的传输以及地理上的或拓扑上的远程缓存等其他花销的前提下，CDN提供者扩展其提供服务的地理分布。由于不调整相应的地理范围，不带来拓展和运营相关CDN基础设施所需的花销（例如，由于相对低投递量或满足大的量所需的高投资）。若地理覆盖范围受限的多个CDN提供者（例如，限制到一个国家）或者在地理范围内不能为所有端用户提供服务，那么互联其CDN可以使这些CDN提供者向其CDN覆盖范围外的用户提供其服务。除了视频内容，该应用场景还可包括自动软件更新等各类内容（例如，浏览器更新、操作系统补丁和病毒数据库更新等）。
4.1.2分支机构之间互联
4.1.1描述了由不同实体运营的CDN或自建的地理范围扩展的应用场景。大的CDN提供者可有几个分支机构，每个机构各自运营自己的CDN（可能使用不同的CDN技术）。在特定的环境下，CDN提供者需要使这些CDN互操作，并整体上向用户提供一致服务。4.1.3ISP处理第三方内容
考虑到ISP向其用户提供大量来自第三方CSP的内容，同时这些内容是由授权CDN提供者插人到ISP的网络中。对于ISP（作为访CDN）、授权CDN和CSP而言，建立CDNI协议是有利的。例如：
充许CSP向用户提供改进的QoE和QoS服务。例如，减少内容起始时简或提高视频质量以及自适应流内容的分辨率。
通过ISP缓存和投递能力，允许授权CDN减少硬件能力以及覆盖范围。b）
通过在ISP网络内部缓存，允许ISP减少网络的某些端的业务负载。c
允许ISP影响和/或控制业务进入点。d）
充许ISP为传输业务而获得某些增加的收人并通过QoE服务而获利。e）
GB/T38801—2020
4.1.4用户漫游应用场景
在该应用场景中，CSP希望允许在接人网络之间移动的用户连续访问他们所提供的内容。该场景的目的是允许漫游端用户在穿过设备和/或地理范围时保持采用相同的QoE访问内容。用户漫游应用场景覆盖以下情况a）端用户在可能相同的地理区域或不同的地理区域中的不同接人网络之间运动；b）端用户在访问内容期间更换终端设备或采用不同的交付技术。支持用户漫游的CDN互联场景如图1所示，端用户A已经从其“家乡ISPISPA订购了宽带服务。
ISPA运营CDN-A。通常情况下，当端用户A通过ISPA（其“家乡ISP\)访问内容时，内容通过ISPA的网络中的CDN-A交付给用户。当端用户A没有连接到ISPA的网络时，如该用户连接到了WiFi提供者或移动网，端用户A也能够访问相同的内容。
CDN拆供者“A
端H户A（家多）
说明：
CDN互联。
N提供考“”
端户A（漫游）
图1支持用户漫游的CDN互联场景尽管CDN-B的一般用户不能访问CSPA的内容.但端用户A可以通过替代的CDN(CDN-B)访问到其“家乡”的内容（例如，CSPA的内容）。这种场景下，根据CSP的内容交付政策的不同，漫游到不同地理区域的用户可能需要服从地理屏蔽内容交付限制。在这种情况下，用户可能不被允许访问相同的内容。
4.2负载均衡应用场景
4.2.1分流突发忙时业务量互联应用场景般情况下，一个CDN通常根据所预期的最大业务量来建设。然而，未预期到的临时热点内容的出现可能会使得业务量超出更多期望的峰值。一般情况下，对于两个不同CDN，内容分发的最高峰周期可能是不同的。利用不同的业务忙时，一个CDN可以与另一个CDN互联以增加其业务忙时的有效能力。
该种应用场景也可用于在某一段的时间内，CDN提供者需要特定区域的CDN能力。例如，CDN可以在特定维护期间或在特定事件的分发期间，将业务量转由另一个CDN来承担，如图2所示例如，考虑作为某一重大事件，如重大体育赛事的分发者的某一TV频道为该次重大事件的交付已4
GB/T38801—2020
经与特定的CDN签订了合作协议。该TV频道用于交付与该事件相关内容的CDNs(CDN-A和CDN-B)可能具有该事件出现临时大流量的经验，并需要将这些突发流量转给具有支持更多业务流量并能够接收转移过来业务量的其他CDN（CDN-C）。在这种应用场景下，请求分流的交付CDN应能够处理分流过来的请求。：因而，uCDN需要每一个dCDN可分流的业务量的相关信息。TY频烂
说明：
CDN互联。
图2分流业务量互联应用场景
4.2.2增加CDN弹性的互联应用场景4.2.2.1内容交付资源出现差错的应用场景2
(N-C(分流）
在部分设施差错（例如，某些缓存设备/功能出现差错）期间，保证服务的连续性是非常重要的。在部分设施出现差错情况下，CDN提供者至少具有如下三种选择：a）使用内部机制将业务量重定向到存活的设备；b）根据业务量管理政策，将某些请求前转到CSP的起始服务器；c）重定向某些请求到另二个CDN，所重定向的CDN应能够为重定向的请求提供服务。最后一种选择是CDNI的应用场景。4.2.2.2内容获取的弹性
通过如下两种方法之一处理源内容获取：a）CSP源：CDN直接从CSP的起始服务器获取内容；b）CDN源：下游CDN从上游CDN中的缓存设备功能获取内容。支持内容获取弹性的能力是互联CDN的重要应用场景。当内容获取失败时，CDN可转到另一个内容获取源。同样，当儿个内容获取源有效时，CDN可在这些多个源之间平衡业务量。尽管可在网络中使用其他服务器和/或DNS负载均衡技术，为在出现获取失败时在源服务器之间分发负载并尝试从替代的内容源获取内容，互联CDN可以对源服务器的有效性进行更有效的探测当正常的内容获取失败时，CDN需要尝试其他可选内容源，例如：a）上游CDN可从替代的CSP起始服务器获得内容；b）：下游CDN可从上游CDN的替代缓存设备/功能获取内容；c)
下游CDN可从替代的上游CDN获取内容；d）下游CDN可直接从CSP的起始服务器获取内容。内容获取协议不在CDNI的范围内，应考虑和推进内容获取源的选择。GB/T38801—2020
4.3能力扩展应用场景
4.3.1设备和网络技术扩展
在该应用场景中，CDN提供者可以具有正常的地理覆盖范围，但是可能希望扩展设备的支持范围以及用户代理或投递技术支持的范围。在该种情况下，CDN提供者不希望提供的服务，自身拥有的CDN不能支持的服务可能与提供如下服务的CDN进行互联。下列一些例子表明了该类应用场景：a）CDN-A不支持特定的交付协议。例如，为提供支持HTTP的服务，CDN-A可与CDN-B互联。在不需要拓展其自身的基础设施的情况下，为交付HTTP，CDN-A可使用CDN-B的覆盖范围（可能与它自身的覆盖范围相重叠）。对其他格式，交付协议例如，实时消息协议（RTMP）、实时流媒体协议（RTSP)等以及特征（像令牌、每次会话加密等授权的特定形式等），该应用场景也可能是正确的
b）CDN-A具有覆盖传统固定宽带的范围并希望扩展到移动设备的范围。在该情况下，CDN-A可以与CDN-B签订合约并进行互联。其中CDN-B具有：1）在移动网络中的物理覆盖范围；2）在特定移动设备的协议上投递内容的能力。c）CDN-A在其基础设施中仅支持IPv4协议，但想要在IPv6上交付内容，CDN-B支持IPv4和IPv6。如CDN-A需为纯IPv6连接提供内容服务，CDN-A与CDN-B需互联这些应用场景可以应用在CDN提供者的许多CDN特征上。因而，这些CDN提供者应通过另个CDN提供相应特征。
4.3.2技术和供应商互操作
CDN提供者可通过简单地将其CDN服务迁移到新技术而在其已有的CDN基础上拓展新CDN。另外，针对其自身的CDN，CDN提供者具有多供应商策略的方式拓展新CDN。最终，CDN提供者可能希望为特定CSP或特定网络拓展单独的CDN4.3.3改进QoE和QoS
在某些情况下，尽管CDN提供者能够向端用户交付内容，但它不能满足CSP的服务等级需求。CDN提供者可根据与其他可向端用户提供所期望的QoE的CDN提供者建立CDN互联协议，例如通过能够从靠近端用户的缓存设备/功能交付具有所需服务等级的内容6
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国国家标准
GB/T38801—2020
内容分发网络技术要求
互联应用场景
Technical requirements for content distribution network-Interconnection use cases
2020-06-02发布
国家市场监督管理总局
国家标准化管理委员会
2020-12-01实施
GB/T38801—2020
2术语和定义、缩略语
术语和定义
缩略语
3概述
互联应用场景
扩展服务范围应用场景
4.1.1扩展服务的地理范围
分支机构之间互联
4.1.3ISP处理第三方内容·
4.1.4用户漫游应用场景
4.2负载均衡应用场景
4.2.1分流突发忙时业务量互联应用场景4.2.2增加CDN弹性的互联应用场景4.3能力扩展应用场景
4.3.1设备和网络技术扩展
技术和供应商互操作
改进QoE和QoS·
本标准按照GB/T1.1—2009给出的规则起草本标准由中华人民共和国工业和信息化部提出。本标准由全国通信标准化技术委员会（SAC/TC485）归口。GB/T38801—2020
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任，本标准起草单位：中国信息通信研究院、中国电信集团公司、中国联合网络通信集团有限公司、中国移动通信集团公司。
本标准主要起草人聂秀英、陈戈、梁洁、乔治、陈炜。1
1范围
内容分发网络技术要求
互联应用场景
本标准规定了内容分发网络之间互联的应用场景。本标准适用于内容分发网络之间的互联2
术语和定义、缩略语
2.1术语和定义
下列术语和定义适用于本文件。2.1.1
内容分发网络
:content distribution networkGB/T38801—2020
为更有效地向端用户交付内容，在4层～7层网络单元进行互操作的网络基础设施。注：典型的CDN由请求路由系统、分发系统（包括缓存设备/功能集）、日志系统以及CDN控制系统组成，2.1.2
授权的 CDN
authoritativeCDN
为分发和交付CSP的内容，通过由CSP授权的CDN或由CSP授权的CDN的下游CDN与CSP直接相关联的CDN。
CDN提供者
CDNprovider
运营CDN并提供内容分发服务的业务提供者。注：给定的实体可能同时作为多个运营角色提供多种服务。2.1.4
内容content
任何形式的数字化的数据。
注：具有分发和交付的内容，包括流媒体、图片、文本等。2.1.5
contentservice
内容服务
为端用户提供特定格式的内容。注：内容服务包括完全的服务，可以仅提供访问内容的完全服务、节目指南等，2.1.6
control system
控制系统
负责启动和控制CDN的其他构件以及处理与外部系统交互的CDN功能。2.1.7
交付delivery
负责向端用户交付部分内容的CDN功能。2.1.8
分发系统免费标准下载网bzxz
distribution system
负责分发内容、分发元数据以及CDN中内容本身的CDN功能GB/T38801—2020
下游CDNdownstreamCDN
对于给定的端用户请求，其他CDN(上游CDN)被重定向到请求直接互联的CDN（在上下级直接互联的CDN场景中）。
enduser
端用户
系统的“真实”用户。
注：典型的是指个人的硬件和/或软件的某些组合。2.1.11
网络服务提供者
network serviceprovider
向端用户提供基于网络连接/服务的提供者。2.1.12
体验质量
quality of experience
表达用户体验到的质量等级描述注：可采用主观分数表示用户体验和/或体验到的QoS等级。QoE具有两个主要的成分：定量和定性。定量成分可能受完整的端到端系统效果的影响（包括用户设备和网络基础设施）。定性成分可能受用户的期望、周围环境、心理因素以及应用场景等影响。QoE也可被看作是用户接受到、接收到和理解到的服务质量（QoS)以及影响用户体验服务的相关定量因素。2.1.13
catchdevice/function
缓存设备/功能
为在CDN内部控制和分发内容，与CDN的其他模块交互，即交付内容与端用户进行交互的设备/功能。
注：典型的缓存设备/功能可缓存端用户请求的内容，这样缓存设备/功能在响应多个用户代理（它们的端用户）请求时，能够直接交付相同的内容，以避免通过核心网络将同一内容传送多次。2.1.14
upstreamCDN
上游CDN
对于给定的端用户请求，将请求重定向到下级CDN(在直接互联的CDN场景中）。2.1.15
用户代理
useragent;UA
通过端用户与内容服务进行交互的软件（或硬件和软件的组合）。注：用户代理与内容服务或CDN进行通信为用户交付内容。这类通信不限于使用HTTP协议，也可通过其他协议。用户代理的例子(非全部)是浏览器、机项盒(STB)或专用的内容应用。SA
接入CDN
accessCDN
在相同的管理网络中，作为接入端用户的CDN。注：为向内容服务提供者提供附加的内容交付服务·这类CDN能够使用端用户网络上下文的精确信息。2.2
缩略语
下列缩略语适用于本文件。
CDN：内容分发网络（ContentDistributionNetwork）CDNI：内容分发网络互联（ContentDistributionNetworkInterconnection）CSP：内容服务提供者（ContentServiceProvider）dCDN：下游内容分发网络（downstreamContentDistributionNetwork）DNS：域名系统（DomainNameSystem）2
EU：端用户（EndUser）
ISP：互联网服务提供者（InternetServiceProvider）NSP：网络服务提供者（NetworkServiceProvider）QoE：体验质量（QualityofExperience）QoS：服务质量（QualityofService）uCDN：上游内容分发网络（upstreamContentDistributionNetwork）3概述
GB/T38801—2020
全球互联网由分布在各地的不同ISP组建的网络互联而成并为全球范围内的用户提供服务。内容分发网络为承载在互联网之上的重叠网络，根据其所服务的内容业务提供者的不同需求，提供内容加速服务，以提升用户的QoE和QoS。4互联应用场景
4.1扩展服务范围应用场景
4.1.1扩展服务的地理范围
该互联应用场景是指在不降低交付质量，不需要增加附加的传输以及地理上的或拓扑上的远程缓存等其他花销的前提下，CDN提供者扩展其提供服务的地理分布。由于不调整相应的地理范围，不带来拓展和运营相关CDN基础设施所需的花销（例如，由于相对低投递量或满足大的量所需的高投资）。若地理覆盖范围受限的多个CDN提供者（例如，限制到一个国家）或者在地理范围内不能为所有端用户提供服务，那么互联其CDN可以使这些CDN提供者向其CDN覆盖范围外的用户提供其服务。除了视频内容，该应用场景还可包括自动软件更新等各类内容（例如，浏览器更新、操作系统补丁和病毒数据库更新等）。
4.1.2分支机构之间互联
4.1.1描述了由不同实体运营的CDN或自建的地理范围扩展的应用场景。大的CDN提供者可有几个分支机构，每个机构各自运营自己的CDN（可能使用不同的CDN技术）。在特定的环境下，CDN提供者需要使这些CDN互操作，并整体上向用户提供一致服务。4.1.3ISP处理第三方内容
考虑到ISP向其用户提供大量来自第三方CSP的内容，同时这些内容是由授权CDN提供者插人到ISP的网络中。对于ISP（作为访CDN）、授权CDN和CSP而言，建立CDNI协议是有利的。例如：
充许CSP向用户提供改进的QoE和QoS服务。例如，减少内容起始时简或提高视频质量以及自适应流内容的分辨率。
通过ISP缓存和投递能力，允许授权CDN减少硬件能力以及覆盖范围。b）
通过在ISP网络内部缓存，允许ISP减少网络的某些端的业务负载。c
允许ISP影响和/或控制业务进入点。d）
充许ISP为传输业务而获得某些增加的收人并通过QoE服务而获利。e）
GB/T38801—2020
4.1.4用户漫游应用场景
在该应用场景中，CSP希望允许在接人网络之间移动的用户连续访问他们所提供的内容。该场景的目的是允许漫游端用户在穿过设备和/或地理范围时保持采用相同的QoE访问内容。用户漫游应用场景覆盖以下情况a）端用户在可能相同的地理区域或不同的地理区域中的不同接人网络之间运动；b）端用户在访问内容期间更换终端设备或采用不同的交付技术。支持用户漫游的CDN互联场景如图1所示，端用户A已经从其“家乡ISPISPA订购了宽带服务。
ISPA运营CDN-A。通常情况下，当端用户A通过ISPA（其“家乡ISP\)访问内容时，内容通过ISPA的网络中的CDN-A交付给用户。当端用户A没有连接到ISPA的网络时，如该用户连接到了WiFi提供者或移动网，端用户A也能够访问相同的内容。
CDN拆供者“A
端H户A（家多）
说明：
CDN互联。
N提供考“”
端户A（漫游）
图1支持用户漫游的CDN互联场景尽管CDN-B的一般用户不能访问CSPA的内容.但端用户A可以通过替代的CDN(CDN-B)访问到其“家乡”的内容（例如，CSPA的内容）。这种场景下，根据CSP的内容交付政策的不同，漫游到不同地理区域的用户可能需要服从地理屏蔽内容交付限制。在这种情况下，用户可能不被允许访问相同的内容。
4.2负载均衡应用场景
4.2.1分流突发忙时业务量互联应用场景般情况下，一个CDN通常根据所预期的最大业务量来建设。然而，未预期到的临时热点内容的出现可能会使得业务量超出更多期望的峰值。一般情况下，对于两个不同CDN，内容分发的最高峰周期可能是不同的。利用不同的业务忙时，一个CDN可以与另一个CDN互联以增加其业务忙时的有效能力。
该种应用场景也可用于在某一段的时间内，CDN提供者需要特定区域的CDN能力。例如，CDN可以在特定维护期间或在特定事件的分发期间，将业务量转由另一个CDN来承担，如图2所示例如，考虑作为某一重大事件，如重大体育赛事的分发者的某一TV频道为该次重大事件的交付已4
GB/T38801—2020
经与特定的CDN签订了合作协议。该TV频道用于交付与该事件相关内容的CDNs(CDN-A和CDN-B)可能具有该事件出现临时大流量的经验，并需要将这些突发流量转给具有支持更多业务流量并能够接收转移过来业务量的其他CDN（CDN-C）。在这种应用场景下，请求分流的交付CDN应能够处理分流过来的请求。：因而，uCDN需要每一个dCDN可分流的业务量的相关信息。TY频烂
说明：
CDN互联。
图2分流业务量互联应用场景
4.2.2增加CDN弹性的互联应用场景4.2.2.1内容交付资源出现差错的应用场景2
(N-C(分流）
在部分设施差错（例如，某些缓存设备/功能出现差错）期间，保证服务的连续性是非常重要的。在部分设施出现差错情况下，CDN提供者至少具有如下三种选择：a）使用内部机制将业务量重定向到存活的设备；b）根据业务量管理政策，将某些请求前转到CSP的起始服务器；c）重定向某些请求到另二个CDN，所重定向的CDN应能够为重定向的请求提供服务。最后一种选择是CDNI的应用场景。4.2.2.2内容获取的弹性
通过如下两种方法之一处理源内容获取：a）CSP源：CDN直接从CSP的起始服务器获取内容；b）CDN源：下游CDN从上游CDN中的缓存设备功能获取内容。支持内容获取弹性的能力是互联CDN的重要应用场景。当内容获取失败时，CDN可转到另一个内容获取源。同样，当儿个内容获取源有效时，CDN可在这些多个源之间平衡业务量。尽管可在网络中使用其他服务器和/或DNS负载均衡技术，为在出现获取失败时在源服务器之间分发负载并尝试从替代的内容源获取内容，互联CDN可以对源服务器的有效性进行更有效的探测当正常的内容获取失败时，CDN需要尝试其他可选内容源，例如：a）上游CDN可从替代的CSP起始服务器获得内容；b）：下游CDN可从上游CDN的替代缓存设备/功能获取内容；c)
下游CDN可从替代的上游CDN获取内容；d）下游CDN可直接从CSP的起始服务器获取内容。内容获取协议不在CDNI的范围内，应考虑和推进内容获取源的选择。GB/T38801—2020
4.3能力扩展应用场景
4.3.1设备和网络技术扩展
在该应用场景中，CDN提供者可以具有正常的地理覆盖范围，但是可能希望扩展设备的支持范围以及用户代理或投递技术支持的范围。在该种情况下，CDN提供者不希望提供的服务，自身拥有的CDN不能支持的服务可能与提供如下服务的CDN进行互联。下列一些例子表明了该类应用场景：a）CDN-A不支持特定的交付协议。例如，为提供支持HTTP的服务，CDN-A可与CDN-B互联。在不需要拓展其自身的基础设施的情况下，为交付HTTP，CDN-A可使用CDN-B的覆盖范围（可能与它自身的覆盖范围相重叠）。对其他格式，交付协议例如，实时消息协议（RTMP）、实时流媒体协议（RTSP)等以及特征（像令牌、每次会话加密等授权的特定形式等），该应用场景也可能是正确的
b）CDN-A具有覆盖传统固定宽带的范围并希望扩展到移动设备的范围。在该情况下，CDN-A可以与CDN-B签订合约并进行互联。其中CDN-B具有：1）在移动网络中的物理覆盖范围；2）在特定移动设备的协议上投递内容的能力。c）CDN-A在其基础设施中仅支持IPv4协议，但想要在IPv6上交付内容，CDN-B支持IPv4和IPv6。如CDN-A需为纯IPv6连接提供内容服务，CDN-A与CDN-B需互联这些应用场景可以应用在CDN提供者的许多CDN特征上。因而，这些CDN提供者应通过另个CDN提供相应特征。
4.3.2技术和供应商互操作
CDN提供者可通过简单地将其CDN服务迁移到新技术而在其已有的CDN基础上拓展新CDN。另外，针对其自身的CDN，CDN提供者具有多供应商策略的方式拓展新CDN。最终，CDN提供者可能希望为特定CSP或特定网络拓展单独的CDN4.3.3改进QoE和QoS
在某些情况下，尽管CDN提供者能够向端用户交付内容，但它不能满足CSP的服务等级需求。CDN提供者可根据与其他可向端用户提供所期望的QoE的CDN提供者建立CDN互联协议，例如通过能够从靠近端用户的缓存设备/功能交付具有所需服务等级的内容6
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。