CN104662865A - 混合型http和udp内容分发 - Google Patents

Abstract

混合型HTTP/UDP分发协议提供对通过网络(诸如覆盖)分发视频及其他内容的显著改进。该方法对解决基于HTTP的流处理的问题(例如慢启动时间、重新缓冲以及低比特率)特别有用处。一般而言，该协议具有两个阶段：HTTP阶段和UDP阶段。在HTTP阶段，客户端向服务器发送HTTP GET请求。GET请求包含通知服务器客户端想要通过协议使用基于UDP的传送的传输标头。服务器可以拒绝此模式并在普通HTTP模式下继续，或者服务器可以通过发送空响应来作出响应，用标头信息通知客户端如何使连接进入UDP阶段。在UDP阶段，客户端发起连接并通过UDP接收原始请求的内容。

Description

混合型HTTP和UDP内容分发

技术领域

本申请一般涉及通过网络的数据通信。

背景技术

分布式计算机系统在现有技术中是已知的。一个这样的分布式计算机系统是通常由服务提供商运营和进行管理的“内容分发网络”或“CDN”。服务提供商通常代表使用该服务提供商的共享基础结构的第三方(客户)而提供内容分发服务。这一类型的分布式系统有时被称为“覆盖网络”，并且通常是指通过一个或多个网络链接起来的自治计算机的集合连同被设计为便利于各种服务(诸如内容分发、应用加速、或对外包的源站点基础结构的其他支持)的软件、系统、协议和技术。CDN服务提供商通常通过在客户门户中提供的、接着被部署到网络的数字属性(诸如网站)来提供服务分发。

所描述的类型的覆盖网络从网络中的服务器向客户端提供基于HTTP的流处理，客户端接收视频流并将它播放到屏幕。客户端可以在台式计算机、移动设备(智能电话、平板电脑)、机顶盒、智能电视机或电器、或者任何其他连接网络的设备上运行。对于典型的基于HTTP的流处理的使用情况，客户端通过DNS将名称(例如CDN主机名)解析为IP地址，并建立到与该地址相关联的服务器的TCP连接。一旦建立，客户端就发送对所期望的内容(例如媒体段)的HTTPGET请求。服务器在响应正文中以内容数据作出响应。连接对于进一步的请求和响应保持打开。

使用超文本传输协议(HTTP)的标准方法通过HTTP协议(在传输控制协议/网际协议(TCP/IP)连接之上)作出请求，并且在HTTP响应中接收包含所请求的数据的响应(通过同一TCP/IP连接)。另选的流处理方法对于请求和响应两者(包括控制消息)使用用户数据报协议(UDP)或TCP之上的协议。其他方法通过HTTP会话穿遂(tunnel)某种协议。

目前，许多最终用户遇到基于HTTP的流处理所存在的问题，诸如慢启动时间、重新缓冲以及低比特率。这些用户的连接对于高质量视频常常表现出足够大的带宽，但是，服务器和客户端之间的往返时间和数据包丢失特性负面地影响流处理性能，主要是因为标准基于TCP的实现在这样的网络上无效率地操作。

如此，需要提供改善视频流处理质量的新技术。此处的公开内容解决这些及与相关现有技术相关联的其他问题。

发明内容

混合型HTTP/UDP分发协议对于通过网络(诸如覆盖)分发视频及其他内容提供重要的改善。该方法对于解决基于HTTP的流处理的问题(例如慢启动时间、重新缓冲以及低比特率)特别有用处。

一般而言，该协议具有两个阶段：HTTP阶段以及UDP阶段。在HTTP阶段，客户端向服务器发送HTTP GET请求。GET请求包含通知服务器客户端想要通过协议使用基于UDP的传送的传输标头(header)。服务器可以拒绝此模式并在普通HTTP模式下持续，或者服务器可以通过发送空的响应来作出响应，用标头信息通知客户端如何建立连接以进入UDP阶段。在UDP阶段，客户端发起连接并通过UDP接收原始请求的内容。

混合型方法因添加单独的通道用于通过UDP协议进行内容传输而不同于常规基于HTTP的流处理。一旦客户端连接到服务器，客户端就发送对所期望的内容(例如媒体段)的HTTP GET请求，并包括指示它希望将UDP连接用于响应正文传送的HTTP标头。客户端还可以包括关于UDP分发的任何偏好(例如前向纠错(FEC)或其他参数)。服务器——如果被提供使用该协议——则以空正文(内容-长度：0)应答作出响应。响应优选地也包括各种标头以阻止沿途中的代理缓存该响应。在响应标头中，客户端查找有关如何通过UDP协议连接到同一服务器的信息(或者还有其他额外的替换的服务器引用，例如用于多源内容获取)。此信息通常包括IP地址、UDP端口号、可选地包括某种其他特殊端口号(来标识通信属于哪个流，因为在同一服务器的UDP端口上可能有许多这样的连接)、版本以及令牌T。一旦从服务器接收到此信息，客户端就通过基于在HTTP响应标头中提供的信息(IP地址、UDP端口号、其他端口号等等)而向服务器发送SYNUDP数据包来发起UDP连接。此请求优选地也包括来自HTTP响应的令牌T。通过使用该令牌，服务器因此可以验证发送UDP数据包的客户端看到了先前的HTTP响应，并且应该处理这样的SYN数据包。优选地，SYN还包含客户端的初始序列号(ISN)。服务器以SYN_ACK数据包作出响应，该数据包包括来自客户端的SYN数据包的经确认的ISN值。SYN_ACK还包含服务器的ISN值。接着，客户端以包含来自SYN_ACK数据包的服务器的经确认的ISN的SYN_ACK_ACK数据包(也再次包括令牌T)来确认接收到SYN_ACK。对ISN和令牌T的确认充当确保双方正在参与通信并看到全部先前的数据包的措施。令牌(HTTP响应、SYN和SYN_ACK_ACK数据包中的)也便利连接重复用于此特定客户端和服务器之间的其他HTTP请求。一旦以此方式完成了握手，基于UDP的连接就被视为已建立；接着，服务器开始发送带有(可能FEC编码的)内容的数据包。内容与在不使用UDP的情况下将已经在原始HTTP响应正文中的相同。

前述内容概述了主题的一些更相关的特征。这些特征应该被理解为只是说明性的。通过以不同的方式应用所公开的主题或通过修改主题，可以实现许多其他有益的结果，如下文所描述的。

附图说明

为更加完整地理解主题以及其优点，现在参考下面的结合附图的描述，在附图中：

图1是示出被配置为内容分发网络(CDN)的已知分布式计算机系统的框图；

图2是代表性的CDN边缘机器配置；

图3是示出本公开内容的基本混合型HTTP/UDP数据分发方法的图示；以及

图4是以附加细节示出本公开内容的混合型HTTP/UDP分发技术的操作场景的图示。

具体实施方式

图1示出了由此处的技术扩展的已知分布式计算机系统(如下面所描述的)。

在已知系统中，诸如图1所示出的，分布式计算机系统100被配置为CDN，并假设具有分布在因特网中的一组机器102a-n。通常，大多数机器是位于因特网的边缘附近的服务器，即位于最终用户接入网络处或与最终用户接入网络相邻。网络操作命令中心(NOCC)104管理系统中的各种机器的操作。第三方站点(诸如网站106)将内容(例如，HTML、嵌入的页对象、流式媒体、软件下载等等)的分发的负载卸载到分布式计算机系统100，具体来说，卸载到“边缘”服务器。通常，内容提供商通过对给定内容提供商域或子域使用别名而命名为由服务提供商的权威性的域名服务进行管理的域(例如通过DNSCNAME)，来卸载他们的内容分发的负载。期望内容的最终用户可以被定向到分布式计算机系统，以更加可靠而有效地获取该内容。虽然未详细地显示，但是，分布式计算机系统还可以包括其他基础结构，诸如分布式数据收集系统108，该系统108用于从边缘服务器收集使用情况及其他数据，跨区域或区域集合地聚合该数据，并将该数据传递到其他后端系统110、112、114和116，以便利监视、记录、警告、计费、管理及其他操作和管理功能。分布式网络中介(agent)118监视网络以及服务器负载，并向DNS查询处理机制115提供网络、流量和负载数据，该机制115对于由CDN进行管理的内容域是权威性的。分布式数据传输机制120可以用来向边缘服务器分发控制信息(例如管理内容、便利负载平衡等等的元数据)。

如图2所示，给定机器200包括运行支持一个或多个应用206a-n的操作系统内核(诸如Linux或变种)204的商品硬件(例如IntelPentium处理器)202。为便利内容分发服务，例如，给定机器通常运行一组应用，诸如HTTP(web)代理207、名称服务器208、本地监视进程210、分布式数据收集进程212。更一般而言，代理207是包括程序指令的软件，该指令被保存在存储器中，并根据需要由一个处理器(或多个处理器)执行。

对于流式媒体，根据所支持的媒体格式的需要，CDN机器通常包括一个或多个媒体服务器，诸如Windows Media Server(WMS)或Flash服务器。使用专用媒体服务器的另选方案使用HTTP作为传输协议。在美国公开No.20110173345中描述了用于基于HTTP的实况流和基于VOD的分发的体系结构。该方法在CDN内实现，并包括使用记录层来记录要被分发的内容流以及使用播放器层来播放流的高级别功能。记录流的步骤包括一组子步骤，这些子步骤当在CDN入口点处以源格式接收到该流时开始。接着，流被转换为中间格式(IF)，该中间格式是用于在CDN内分发流的内部格式，并包括流清单(manifest)、一个或多个段索引(FI)的集合以及IF段的集合。播放器进程在发出请求的客户端与诸如基于ghost的代理之类的CDNHTTP代理相关联时开始。响应于在HTTP代理处接收到对流或其一部分的请求，HTTP代理检索(或从档案或从数据存储)流清单和至少一个段索引。通过使用段索引，IF段被检索到HTTP代理，被转换为目标格式，并接着响应于客户端请求而被服务。源格式可以与目标格式相同或不同。优选地，由HTTP代理通过HTTP访问、缓存并服务所有段。在另一个实施例中，分发按需流(VOD)的方法使用转换层(代替记录层)来管理IF组件的创建和/或处理。

CDN边缘服务器被配置为提供一个或多个扩展的内容分发特征，优选地在特定于域、特定于客户的基础上，优选地使用通过使用配置系统分发给边缘服务器的配置文件。给定配置文件优选地是基于XML的，并包括一组内容处理规则和指示，用于便利一个或多个高级内容处理特征。配置文件可以通过数据传输机制被分发到CDN边缘服务器。美国专利No.7,111,057示出了用于分发和管理边缘服务器内容控制信息的有用的基础结构，此边缘服务器控制信息及其他边缘服务器控制信息可以由CDN服务提供商本身提供，或(通过外部网等等)由操作源服务器的内容提供商客户提供。

由于CDN基础结构由多个第三方共享，因此，此处它有时被称为多承租人共享的基础结构。CDN进程可以位于在因特网上可公开地路由的节点上，位于或邻近移动网络中的节点，位于或邻近基于企业的专用网络中，或者位于它们的任何组合中。

可通过元数据配置的覆盖网络web代理(诸如图2中的代理207)此处有时被称为全局主机或GHost进程。

CDN可以包括存储子系统，诸如在美国专利No.7,472,178中所描述的，其公开内容以引用的方式并入本文中。

CDN可以操作服务器缓存层次结构，以提供客户内容的中间缓存；在美国专利No.7,376,716中描述了一个这样的缓存层次结构子系统，该公开内容以引用的方式并入本文中。

CDN可以以在美国公开No.20040093419中所描述的方式在客户端浏览器、边缘服务器和客户源服务器之间提供安全内容分发。如此文所描述的安全内容分发，一方面在客户端和边缘服务器进程之间、另一方面在边缘服务器进程和源服务器进程之间，来实施基于SSL的链路。这允许受SSL保护的网页和/或其组件通过边缘服务器被分发。

作为覆盖，CDN资源可以被用来便利企业数据中心(可以被私有地管理)和第三方软件即服务(SaaS)提供商之间的广域网(WAN)加速服务。

CDN还可以提供客户端侧软件以便利各种内容分发功能，诸如HD流处理。在一种方法中，客户端包括两个组件。第一组件是非持久性的、浏览器内的媒体播放器，这种媒体播放器可基于第三方(例如，Adobe Flash或Microsoft Silverlight)组件，以便利HD内容的自适应或动态比特率分发。第二组件是持久性守护进程(daemon)的形式的界面，该守护进程可以执行“客户端侧”内容分发。客户端侧分发意味着从CDN边缘服务器以及从正在运行该界面并预先下载了相同内容的其他最终用户两者来下载内容。

对于典型的基于HTTP的流处理使用场景，客户端通过DNS将名称(例如域名、主机名等等)解析为IP地址，并建立到与该地址相关联的服务器的TCP连接。一旦建立，客户端就发送对所期望的内容(例如媒体段)的HTTP GET请求。服务器在标准HTTP响应正文中以内容数据作出响应。连接保持打开，用于进一步的请求和响应。

以上面的内容作为背景，现在将描述本公开内容的主题。

流处理和下载的混合型HTTP+UDP方法

本公开内容是通过因特网来分发媒体及其他内容的新的方法，并对标准的基于HTTP的分发进行替换或与其进行互补。与现有的标准流处理和下载方法相比，主要区别是基于HTTP的请求和基于UDP的响应的组合。

图3是示出了本公开内容的基本方法的图示。如在此图中所使用的，服务器300是指通信的服务器侧，客户端302是指客户端侧。服务器和客户端组件已被配置成执行本公开内容的HTTP请求-UDP响应的功能。在此示例情况下，客户端302发出对于感兴趣的内容的给定字节范围(例如视频的段、软件下载或其他内容)的HTTP GET请求(在304示出了其中一个)。每一HTTP请求都包括指示客户端被使能接收UDP响应的服务器代码的HTTP标头(或等效的带外数据结构)。如图所示，在步骤306中，服务器300以包括HTTP标头和正文的HTTP响应，对HTTP GET请求作出响应。然而，此响应在几个方面不同于常规HTTP响应。具体而言，HTTP响应标头包括UDP IP:端口的标识，其中服务器在该UDP IP:端口监听UDP连接、以及可选地监听诸如秘密令牌T1之类的数据串。然而，HTTP响应正文是空的(即，它没有(不包括)由HTTP GET请求所请求的内容)。头两个通信通过TCP发生。根据此公开内容，本将被包括在HTTP正文中的内容接着由所示出的随后的基于UDP的连接通过UDP被分发。具体而言，在步骤308中，接收到HTTP响应的客户端向服务器的如在HTTP响应中所标识的UDP IP:端口发出SYN。SYN可包括秘密令牌T1(用于安全目的)。在步骤310中，服务器向客户端返回包括秘密令牌T2的SYNACK。在步骤312中，客户端以包括秘密令牌T2的ACK作出响应。令牌确保只有接收到原始HTTP响应的客户端才可以接收到被请求的原始内容。在步骤314中，服务器以通过UDP分发的所请求的数据包作出响应。

优选地，HTTP连接保持存在(持久性地维持)以接收一个或多个额外的HTTP请求(通常是对于同一或不同内容的额外字节范围的请求)，所请求的内容是通过UDP以此方式被分发的。

可选的改进是使用对数据包(用于UDP分发)的前向纠错(FEC)或其他编码。

下面提供了混合型HTTP/UDP协议的优选实施例的附加细节。图4示出了此混合型HTTP/UDP连接初始化和使用场景。如上文所指出的，混合型方法通过添加用于通过UDP协议进行内容传输的单独的通道而不同。在此处的方法中，客户端400通过DNS(例如覆盖网络权威性的DNS)将名称解析为IP地址，并建立到该网络中的边缘服务器402的TCP连接。一旦建立，在步骤404中，客户端就发送对所期望的内容(例如媒体段)的HTTP GET请求，并包括指出它希望使用UDP连接来传输响应的正文的HTTP标头(等等)。客户端还可以包括关于UDP分发的任何偏好(例如前向纠错(FEC)或其他参数)，但是，通常由服务器决定是否遵从它们。为被使能使用UDP协议的对象承担元数据处理的服务器在步骤406中以空正文(内容-长度：0)的应答作出响应。响应优选地还包括阻止沿途中的代理缓存响应的各个标头。在响应标头中，客户端查找有关如何通过UDP协议连接到同一服务器的信息(或者还有其他额外的替换的服务器引用，例如用于多源内容获取)。此信息通常包括IP地址(因为，例如到目前为止连接可能是通过显式的代理连接，客户端可能不能看见它与其进行通信的服务器IP地址)。返回的信息还包括UDP端口号，以及可选的某种其他特殊端口号(标识通信属于哪一个流，因为在同一服务器的UDP端口上可能有许多这样的连接)、版本以及如上文所描述的令牌T。

一旦从服务器402接收到此信息，客户端400就通过基于在HTTP响应标头中提供的信息(IP地址、UDP端口号、其他端口号等等)向服务器发送SYN UDP数据包，来在步骤408中发起UDP连接。此请求优选地还包括来自HTTP响应的令牌T。通过使用该令牌，服务器因而可以验证发送UDP数据包的客户端看到先前的HTTP响应，并且应该处理这样的SYN数据包(或其相反，悄悄地丢弃由服务器接收到的所有意外的数据包，而不会有对发送器的任何响应)。如图所示，优选地，SYN还包含客户端的初始序列号(ISN1)。在步骤410中，服务器402以SYN_ACK数据包作出响应，该数据包包括经确认的来自客户端的SYN数据包的ISN1值。SYN_ACK还包含服务器的ISN值，ISN2。在步骤412中，客户端接着以包含经确认的来自SYN_ACK数据包的服务器的ISN(即，ISN2)的SYN_ACK_ACK数据包(也再次包括令牌T)，来确认接收到SYN_ACK。对ISN和令牌T的确认充当确保双方正在参与通信并看到全部先前的数据包的措施。令牌(在HTTP响应、SYN和SYN_ACK_ACK数据包中)便利连接重复用于此特定客户端与服务器实例之间的其他HTTP请求。一旦以此方式完成了握手，基于UDP的连接就被视为建立；如此，在步骤414中，服务器接着开始发送带有(可能FEC编码的)内容的数据包。内容与在不使用UDP的情况下本来将在原始HTTP响应正文中的相同。优选地，服务器保持发送数据包，客户端以确认(ACK)回复。ACK可以被用来便利拥塞控制。在握手和数据分发过程中，客户端还可以发送(例如，在步骤416中)类似于TCP的某些控制消息，诸如RST数据包。在使用FEC的情况下，客户端还发送特殊数据包以控制由服务器发送的经编码数据的流，例如指出当前FEC块被成功地解码，下一块应该由服务器发送。

如在图4中进一步指出的，在初始连接建立和交换之后，客户端400可以请求下一段内容。为此，在步骤418中，客户端400发出对于下一段的GET请求(例如，在相同域名中)。可以使用现有的用于HTTP请求的TCP连接来发送该请求，现有的UDP连接用于响应。在步骤420中，从服务器402分发响应。这完成了示例场景的描述。

通常，通过UDP的协议连接一次只支持一个会话(类似于通过TCP的HTTP)。尽管该方法不提供每个连接的显式的多路复用，但是许多连接可以通过同一UDP端口工作；如此，从操作系统的角度来看，多连接场景具有多路复用的表象。如此，在一个实施例中，多个UDP端口(每个堆栈一个)可以用在单个服务器上，以更好地利用可用的CPU处理资源。

优选地，TCP连接(用于HTTP)和UDP连接两者在满足请求之后都保持存在。接着，当必须下载另一个URL对象(例如流中的下一媒体段)时，如果这两个连接仍被视为存在着(通过超时)，则它们被(或可以被)重复使用。优选地，TCP和UDP连接不以对于每一单个HTTP GET请求之外的任何方式耦合或绑定，每一个连接都可以被关闭而不会影响另一个，每一个连接都可以独立地对于进一步的请求被重复使用。新的HTTP GET请求通过TCP连接发送，通过HTTP标头指出应该重复使用现有的UDP连接，而服务器通过借助于TCP发送HTTP(空)响应以及通过借助于现有的UDP连接发送所请求对象的正文，来立即作出响应。

在处理新段的新UDP数据包之前，客户端通常必须首先获得完整的HTTP响应，因为(当使用FEC编码的数据时)它包含解码通过该协议发来的经FEC编码的数据所需的所有细节。还可以在当前数据传送完成之前发送新的HTTP GET请求(并且请求重复使用现有的连接用于数据传送)。这导致停止现有的传送，并且新的请求被立即满足。为此无需来自每一侧的额外确认，因为符合此协议的每个数据包都包含它所“属于”的HTTP响应的ID；如此，属于新的HTTP请求的数据包由客户端容易地识别。

优选地，通过符合HTTP/1.1的要求的传输HTTP标头值，在服务器和客户端之间交换特定于协议的信息。特殊的用户中介(UA)字符串也可以被包括在客户端HTTP请求(来自被使能实现该协议的客户端)中。如上文所指出的，如果协议将被使用，则来自服务器的HTTP响应包含空的正文，并具有额外的传输标头，该标头带有有关如何建立(或重复使用)连接的细节。更具体而言，服务器解析传输标头并通过发送下列各项中的一项来对请求作出响应：在将使用混合型协议的情况下，带有HTTP状态代码202的HTTP响应(并且，标头包含连接端点和令牌细节)；在将使用该协议的情况下，带有状态代码202的HTTP响应(并且上文的标头不包含端点和令牌密钥，这意味着现有的协议连接将被重复使用，如客户端在请求标头中的所请求的)；或者如果将不使用该协议，带有它将使用的任何状态代码的HTTP响应，即服务器将根据HTTP规范来表现，响应在正文中包含资源数据，好像没有标识该协议的传输标头存在。在两种202响应代码的情况下，响应不可由代理服务器缓存，而第三种是可缓存的(如由通常的服务器元数据设置所控制的)。由服务器施加的防缓存标头(在HTTP 202响应中)包括例如Pragma:no-cache,Cache-Control:private,must-revalidate,Date,Expires,Cache-Control:no-store,no-cache,max-age＝0,and Vary:"*"。

令牌是可选的。它可以是表示为32个大写十六进制数字的128比特无符号整数。端点是密钥，它的存在向客户端指出，它应该建立新的连接(通过协议)以接收内容。端点的格式可以是：[IP_address]-[UDP_port_number]-[destination_port_number]。

在变体实施例中，UDP分发可以是多播UDP。在此变体中，客户端向服务器发出HTTP请求，HTTP服务器以包含空正文的响应作出响应，如前面所描述的。HTTP响应还包含用于混合型协议的传输标头，在此情况下，标头包括多播组地址。接着，客户端加入多播组并接收所请求的内容。对于不支持本机(native)IP多播的网络中的客户端，加入多播组和接收多播UDP数据包可以通过自动多播穿隧(AMT)来便利(作为一个选项)。一旦接收到内容，客户端就可以离开多播组。由许多客户端对相同文件(可以是流的一段)的任何数量的请求可以通过同一多播组来满足。为使这一情况成为可能，服务器向多播组发送文件的数据。优选地，数据是经FEC编码地发送的。如此，例如如果文件是1MB大小，则服务器以预先配置的速率、在某个预先配置的时间量内保持发送包含有关文件的数据的信息(对由客户端解码文件有用)的FEC数据包。例如，服务器可以在某个定义的时段内，以8Mbps(即每秒钟1MB)发送1MB文件。在该时间段内，请求同一文件的所有客户端都使用同一多播组。此方法节省资源，并可以在通过多播发送流行的内容(实况流或软件更新)的单个副本的同时，支持将流行的内容分发到许多接收器。可以基于由客户端对文件的需求，动态地扩展文件正在向多播组发送的持续时间；即，只要有对文件的请求，服务器就保持向多播通道发送文件。客户端可以在任何时间加入多播组，由于FEC编码，它们只需加入一如接收足以解码原始文件所需的数据的那样长的时间。作为优化，服务器可以并行地在多个多播组上发送同一文件的内容，客户端可以加入它们中的多个(所有都将在原始HTTP响应的标头中返回)，以更好地利用它们的下载能力，更快地接收文件(因为FEC允许轻松地组合来自多个源的数据)。

可以看出，该方法通过客户端(被配置成使用混合型HTTP-UDP协议)向服务器(被配置成使用该协议)发出HTTP请求、该服务器接着通过UDP返回媒体或文件内容作为对HTTP请求的响应来工作。此方法使得提供商能够使用或利用可用于HTTP的标准CDN基础结构——包括访问控制、认证、QoS报告、地理位置及内置到基于HTTP的web服务器中的其他特征，同时在UDP之上提供对媒体或文件数据传输的完全控制。这种完全控制包括(不受限制的)自定义拥塞控制方法和/或对数据包的编码(诸如前向纠错(如上文所描述的))，以甚至在网络特性(诸如数据包丢失和延迟)不是最佳的情况下提供更好的体验和控制。在这样的情况下，该方法因此组合了使用来自传统下载和流处理解决方案的HTTP的现有特征的优点与基于UDP的数据传输的优点。混合型方法是非常有利的，因为它使用现有的基于HTTP的用于控制将传输什么的解决方案，同时得益于为媒体或其他内容使用基于UDP的数据传输。在UDP通信不可能的情况下，标准HTTP用于请求和响应，以确保每个客户端都可以接收到数据。通过HTTP，传递对于UDP的支持。

应用和服务器可以直接使用该方法，或者可以使用代理来添加对此功能的支持。例如，流处理应用或浏览器(用于下载)可以仅通过HTTP向代理或通过代理来发出请求，代理接着在与服务器进行通信时使用此方法。优选地，客户端到代理的通信是仅HTTP，而代理通过基于混合型HTTP和UDP的协议与服务器进行通信。类似地，web服务器可以使用代理(透明地或者显式地)添加对此方法的支持。

对于流处理，所添加的优点在于，该方法与任何现有的基于HTTP的流处理技术很好地一起工作。

更一般而言，每当要求从服务器到客户端的HTTP流处理时，都可以实现此处所描述的方法。客户端是指接收视频流并将其播放到屏幕的那一侧。客户端可以在台式计算机、移动设备(智能电话、平板电脑等等)、机顶盒、智能电视机、或任何其他连接的设备上运行。服务器是向客户端发送出流数据的那一侧。如此处引用的，基于HTTP的流处理是指只使用HTTP协议来请求并下载对象以构建用于播放的流的任何视频流处理。非限制性示例包括Apple HLS、Adobe HDS、Microsoft SmoothStreaming以及MPEG-DASH。此处的方法可以被用来支持实况和按需的流处理，例如包含由H.264视频基本流以及AAC音频基本流构成的节目流的MPEG-2传输流。当然，此示例不旨在是限制性的。

此处所描述的HTTP/UDP混合型分发方法改善视频流式播放质量。该方法可以透明地适配到现有的基于HTTP的流处理解决方案中。该混合型方法大大地降低了媒体数据传送的数据包丢失和延迟的负面影响，由此大大地改善流处理质量。

此处所描述的技术的客户端部分可以实现为一种或多种平台(例如iOS、Android等等)的软件开发工具包(SDK)，SDK可以用于平台上的应用中，以使得兼容的移动app能够使用混合型HTTP/UDP方法来下载/流处理内容。如此，例如应用可以使用SDK通过其API来下载URL对象，或者可以使用由SDK所创建的本地HTTP服务器来流处理/下载。

混合型协议提供显著的优点，特别是在与诸如基于FEC的UDP分发和高级拥塞控制技术之类的其他技术耦合时。FEC是通过利用冗余来克服数据包丢失的已知的技术。在FEC中，作为对发送原始数据包流(其中每一数据包都表示一段数据)的替代，发送器将数据编码为新的数据包集合(其中每一数据包都持有有关原始数据的各部分的信息，带有额外的奇偶校验数据)。与原始数据相比，新集合的大小一般较大。经编码数据的接收器执行解码，一旦它接收到足够的经编码数据包，就重构原始数据。为了重构数据，通常只需要接收与原始数据大小相同量的经编码数据，或者稍微多一些。这可允许传输是有损的，同时仍能够解码原始数据，而没有对重新传输数据的任何需要。有适用于不同的丢包率和应用的各种FEC码。IETF可靠多播工作组指定了用于可靠地分发内容的三个FEC方案，即RaptorQ(如RFC6330所描述)、低密度奇偶校验检查(LDPC)(如RFC 5170所描述)以及里德-索罗蒙(如RFC 5510所描述)。其他已知的FEC技术包括Raptor R10(如RFC 5053所描述)，这是RaptorQ的旧版本。诸如FastTCP^TM之类的拥塞控制方案可以适用于便利对从服务器向客户端发送的数据包的自定义拥塞控制。一般而言，此已知方案使用排队延迟来度量网络拥塞。在发送器处，使用拥塞窗口(CWND)来控制要发送的字节数。初始地以及根据该方案，CWND快速地提高以匹配传输延迟，接着不太积极地调整以匹配排队延迟的变化(因为数据包沿着路径排队)。发送器调整其CWND以适应网络变化。

与标准TCP或多个并行TCP连接相比，此处所描述的技术在随机环境(非拥塞的)丢失和高延迟下，提供总吞吐量的增加。该技术还通过更准确的带宽估计和高级的拥塞检测，提高吞吐量的稳定性的增加。进一步，该技术还提供起动时间的减少、量和持续时间的重新缓冲事件的减少、以及比特率切换的频率的减小。以上全部导致较长的查看时间和更好的用户体验。所描述的技术还提供使用用于流处理的标准HTTP方法的平稳回落(fail-back)模式。

作为变体，可以通过多路径来执行分发的基于UDP的部分。一般而言，多路径是指并行地从多个源(例如多个边缘服务器、最终用户对等体等等)下载。多路径还指其中同一个服务器(或对等体)用于通过网络中的不同的路径并行地多次下载的情况。当实现FEC编码时，这样的方案可以有用，因为FEC允许组合来自许多源的数据，而无需任何协调。在某些情况下，并行地从多个源下载(甚至根据这些源的性能来动态地改变它们)可以在UDP阶段实现。

在代表性的实现中，本功能以软件、作为由处理器执行的计算机程序指令来实现。

更一般而言，此处所描述的技术提供使用一起便利或提供上文所描述的功能的一个或多个计算相关的实体(系统、机器、进程、程序、库、函数等等)的集合来被提供。在典型的实现中，软件在其上面执行的代表性的机器包括商用硬件、操作系统、应用运行时环境、以及提供给定系统或子系统的功能的应用或进程的集合以及相关联的数据。如上文所描述的，功能可以在独立机器中或跨分布式的机器集合来实现。功能可以作为服务(例如作为SaaS解决方案)来提供。

尽管上文描述了由本发明的某些实施例执行的操作的特定顺序，但是应该理解，这样的顺序是示例性的，因为另选实施例可以以不同的顺序执行操作，组合某些操作，重叠某些操作等等。说明书中对给定实施例的引用表示所描述的实施例可包括特定特征、结构或特性，但是每一个实施例可以不一定都包括该特定特征、结构或特性。

尽管在方法或处理的上下文中描述了所公开的主题，但是本公开内容还涉及用于执行此处操作的设备。此设备可以为所需的用途专门地构造，或者其可以包括由存储在计算机中的计算机程序选择性地激活和/或重新配置的通用计算机。这样的计算机程序可以存储在计算机可读存储介质上，诸如但不仅限于任何类型的盘(包括光盘、CD-ROM以及磁光盘)、只读存储器(ROM)、随机存取存储器(RAM)、磁卡或光卡、或者适于存储电子指令、并且每个都耦合到计算机系统总线的任何类型的介质。

尽管分开地描述了系统的给定组件，但是本领域普通技术人员将理解，一些功能还可以在给定指令、程序序列、代码部分等等中组合或共享。

优选地，功能在应用层解决方案中实现，虽然这不是限制，因为所标识的功能的某些部分可以内置到操作系统等中。

功能还可以用HTTP之外的其他应用层协议来实现，这些协议诸如HTTPS、或具有类似操作特性的任何其他协议。

一般而言，对可实现连接的客户端侧或服务器侧的计算实体的类型没有限制。任何计算实体(系统、机器、设备、程序、进程、实用程序等等)都可以充当客户端或服务器。

Claims (14)

1.一种数据分发的方法，包括：

在于硬件平台上执行的服务器处：

从客户端接收标识内容对象的HTTP请求；

返回对所述HTTP请求的响应，该响应包括标识与所述服务器相关联的IP地址/端口号的标头，并且包括没有所请求的内容对象的响应正文；

接收指向所述IP地址/端口号的UDP请求；以及

返回对所述UDP请求的响应，该响应包括在所述HTTP请求中所标识的内容对象。

2.如权利要求2所述的方法，还包括：

维持所述客户端和所述服务器之间的持久性HTTP连接。

3.如权利要求2所述的方法，还包括：

从所述客户端接收至少一个额外的HTTP请求；以及

返回对所述至少一个额外的HTTP请求的基于UDP的响应。

4.如权利要求1所述的方法，其中，所述标头还包括安全令牌。

5.如权利要求4所述的方法，其中，在返回对所述UDP请求的响应之前，所述服务器验证所述UDP请求还包括所述安全令牌。

6.如权利要求1所述的方法，其中，所述标头还包括阻止所述服务器和所述客户端之间的一个或多个代理缓存对所述HTTP请求的响应的信息。

7.一种设备，包括：

处理器；

保存计算机程序指令的计算机存储器，所述计算机程序指令包括：

接收标识内容对象的请求的程序代码，所述请求是通过第一传输协议分发的；

返回对所述请求的响应的程序代码，所述响应是通过第一传输协议分发的；

所述响应包括空的响应正文，传输标头包括至少第一信息和第二信息，第一信息标识可在该处通过不同于第一传输协议的第二传输协议获取所述内容对象的地址，第二信息随后用于验证所述请求由发出所述请求的客户端接收到。

8.如权利要求7所述的设备，其中，第一传输协议是HTTP，第二传输协议是通过单播的UDP和通过多播的UDP之一。

9.如权利要求8所述的设备，其中，所述设备还包括对在所述地址处接收到包括第二信息的UDP请求进行响应的程序代码，该程序代码响应于所述UDP请求进行操作以返回下列各项中的一项：所述内容对象以及所述内容对象的一部分。

10.如权利要求9所述的设备，其中，根据前向纠错(FEC)编码方案来返回所述内容对象。

11.如权利要求7所述的设备，其中，所述地址是下列各项中的一项：多播组地址以及多播组地址的集合。

12.一种能在多承租人覆盖网络环境中操作的系统，在该环境中服务提供商使用基于HTTP的流处理来从边缘服务器提供视频分发，包括：

能在硬件处理器中执行的服务器侧程序代码；

在硬件处理器中执行的客户端侧程序代码；

所述服务器侧程序代码进行操作以：

从所述客户端侧程序代码接收标识内容对象的HTTP请求；

返回对所述HTTP请求的响应，该响应包括标识与所述服务器侧程序代码相关联的IP地址/端口号的标头，并且包括没有所请求的内容对象的响应正文；

接收指向所述IP地址/端口号的UDP请求；以及

返回对所述UDP请求的响应，该响应包括在所述HTTP请求中所标识的内容对象；

客户端侧程序代码进行操作以：

向所述服务器侧程序代码传输标识内容对象的所述HTTP请求；

接收对所述HTTP请求的响应，该响应包括标识与所述服务器侧程序代码相关联的IP地址/端口号的所述标头，并且包括没有所请求的内容对象的所述响应正文；

传输指向所述IP地址/端口号的所述UDP请求；以及

接收对所述UDP请求的包括在所述HTTP请求中所标识的内容对象的响应。

13.如权利要求12所述的系统，其中，所述标头还包括安全令牌。

14.如权利要求13所述的系统，其中，所述UDP请求包括所述安全令牌，服务器侧程序代码还进行操作以使得如果所述服务器侧程序代码验证所述UDP请求也包括所述安全令牌的话，就返回对所述UDP请求的响应。