[发明专利]用于HTTP流传输内容请求的主动TCP连接停止恢复

说明书

相关申请

本申请要求于2014年9月30日提交的题为“Proactive TCP Connection Stall Recovery for HTTP Streaming Content Requests”的美国临时申请No.62/057,701的优先权的权益，其全部内容通过引用并入本文。

背景技术

视频流传输应用经常使用一个或多个传输控制协议(TCP)连接来使用比如HTTP请求的数据请求从互联网下载媒体内容。例如，配置有传输加速器(TA)功能的一些计算设备可以将针对数据对象的HTTP“GET”请求拆分成针对相同对象的不同字节范围(或“数据块”)的多个HTTP GET子请求。针对数据块的每个请求(或子请求)(例如，数据块请求)可以通常通过不同的TCP连接来进行发送，使得通过该不同的TCP连接来下载与该数据块的所请求范围对应的字节。TA功能可以对经由请求接收的字节重新排序，并将重新排序的字节递交给上层，比如应用层。在一些情况下，只要按顺序的连续字节序列是可用的，甚至在请求已经完成之前(例如，在所有数据块已经到达之前)，字节也可以被传送到上层。

TCP连接(并且因此数据请求)可能停止，导致在停止的TCP连接上完成数据请求时的长延迟。例如，流传输内容的流动中的停止可能导致由于视频播放中断而造成的用户体验差。TCP连接的这种停止可以是由于各种原因造成的。例如，TCP连接可以在下载的中间由于网络拥塞而停止。作为另一示例，在蜂窝网络上的TCP连接可以由于用户设备在小区区域之间移动而发生停止。TCP连接的停止也可以是链路层错误、路由问题或甚至网络内的代理服务器或网络访问转换(NAT)功能或防火墙中的配置问题的结果。

为了解决这些问题，存在常规的停止恢复机制。例如，TCP自身可以尝试通过超时和重传来从错误状况中恢复。例如，常规的TCP机制尝试通过从最早的开始重传未确认的段来从这种停止中恢复。此外，常规机制可以仅仅在与停止的TCP连接所经历的网络接口相同的网络接口上和/或针对与停止的TCP连接所经历的数据源相同的数据源重新发出请求。例如，虽然用户设备可以使用多个“联网选项”来取回媒体内容(例如，多个网络接口或多个数据服务器)，但是响应于停止的TCP连接的TCP恢复机制可以仅仅使用与停止的TCP连接相同的网络接口和相同的服务器来尝试重传。

这种恢复机制在一些情形下可能是不够的，比如参照视频流传输应用。例如，在蜂窝网络中，一个或多个TCP连接的上行链路分组(例如，TCP ACK)可能被丢弃几十秒，造成服务器超时并且不必要地重传已经由请求设备接收的TCP段。有时，这可能由于链路作为整体的降级而造成影响所有TCP连接，并且在其他时候，如果问题不是由于链路问题而是由于其他原因(比如服务器或防火墙问题)造成的，则可能影响正在进行的TCP连接中的仅仅一个或子集。当蜂窝连接丢失时，现有的TCP机制不能恢复，因为确认(ACK)或所重传的分组可能未被成功地传送。TCP自身可能不能从这个状况中恢复。特别地，常规恢复机制可能不适合于一些视频流传输应用。作为另一示例，特定TCP连接的单向或双向分组流可以被中断几秒(例如，十秒等)，而其他TCP连接在没有中断的情况下继续进行，造成数据被无序接收。

此外，现有的TCP机制没有适当地处理涉及多个TCP连接下载特定媒体文件的情形。特别地，尽管单个TCP连接的丢失数据请求可以按顺序(例如，首先较早的)重传，但是当正在下载相同视频流的多个部分的多个TCP连接停止(或者以其他方式经历分组丢失)时，所丢失的数据分组的重传可能不会在TCP连接上按顺序次序出现。当多个分组被丢失时，重要的是按顺序次序恢复所丢失的分组，以防止视频播放中的中断。在TCP内没有确保重传在TCP连接上按顺序次序出现的机制。

发明内容

各种实施例提供用于通过响应于识别出其他TCP连接已经停止而主动使用新的TCP连接来改进计算设备处的数据(例如，流媒体视频)接收的方法、设备、系统和非暂时性处理器可读存储介质。