使用可编程网络的多播传输的制作方法

本发明涉及用于经由网络传输数据的系统和方法，特别地涉及包括远程可控的一个或多个转发节点的可编程网络。本发明进一步涉及供系统中使用的服务器或控制器。本发明进一步涉及包括用于使得处理器系统执行方法的指令的计算机程序产品。

背景技术：

数据由发送者传输到多个接收机在网络中频繁地发生。这样的数据传输也被称为“一对多”或多播分发，但是也可以发生在“多对多”分发的背景内。

例如，在MPEG-DASH（通过HTTP的动态自适应流式传输）的背景内，许多接收机可能在请求实况流时的同时可以同时使用HTTP来请求相同数据（例如，DASH段）。由于HTTP是单播机制，该递送不是高效的，因为它要求网络具有相对大的运输容量以用于本质上是数据的许多副本的传输的事情（what）。为了增加数据递送的效率，可以使用HTTP高速缓存。然而，视频会话使用比正常的web浏览多得多的数据。照此（as such），可能需要相对大的HTTP高速缓存。此外，在通常具有有着多个级别的似树结构的接入网中，将HTTP高速缓存在网络树中放置得过“低”（过于靠近接收机）导致每HTTP高速缓存几个接收机，并且将因此是相当昂贵的。相反地，将HTTP高速缓存在网络树中放置得过“高”要求网络具有较大的运输容量，其也是相当昂贵的。

在MPEG-DASH旁边，类似的问题发生在需要以可靠的方式给许多接收机提供（大量的）基本上相同的数据的情况下。示例包括软件更新的递送、媒体内容的预加载等。问题可以发生在例如ADSL、DOCSIS、移动、光纤等的所有类型的网络（的组合）中。

为了解决上面的（一个或多个）问题，已经开发了所谓的“可靠多播”技术，其允许在网络内高效地分发这样的数据。这里，形容词“可靠”指示多播技术采用在正常情况下确保分组的递送并且该分组将被按次序递送的递送机制。示例是通过因特网协议（IP）的多播运输控制协议（TCP）。另一示例是通过单播运输的文件递送（FLUTE）。不利地，当前的可靠多播技术通常要求接收机中的至少某些改变，并且将因此不对“现成的”单播接收机起作用。当前的可靠多播技术还不对当前的超文本传输协议（HTTP）机制起作用，因为以交互式的单播方式使用HTTP。又一缺点是现有的可靠多播技术将在速度上被限制，因为它们必须接受TCP拥塞管理。

技术实现要素：

获得解决上面缺点中的一个或多个的用于数据的多播的系统或方法将是有利的。

根据本发明的第一方面，提供一种用于经由网络传输数据的方法，其可以包括：

- 接收针对数据的单播传输的请求；

- 通过i）根据运输协议来格式化数据以获得经格式化的数据以及ii）将经格式化的数据提供到网络而对请求进行响应，经格式化的数据包括目的地地址字段；

其中网络可以是包括远程可控的一个或多个转发节点的可编程网络，方法进一步包括：

- 控制一个或多个转发节点通过如下来实现经格式化的数据的多播：

j）复制经格式化的数据以获得所复制的经格式化的数据，以及

jj）将所复制的经格式化的数据的目的地地址字段设置成源于针对数据的单播传输的进一步请求的地址。

根据本发明的另一方面，可以提供一种用于使得处理器系统执行方法的计算机程序。

根据本发明的另一方面，提供了一种经由网络传输数据的系统，其可以包括：

- 服务器，配置用于：

- 接收针对数据的单播传输的请求；

- 通过i）根据运输协议来格式化数据以获得经格式化的数据以及ii）将经格式化的数据提供到网络而对请求进行响应，经格式化的数据包括目的地地址字段；

其中网络可以是包括远程可控的一个或多个转发节点的可编程网络，系统进一步包括：

- 控制器，其用于控制一个或多个转发节点通过如下来实现经格式化的数据的多播：

- 复制经格式化的数据以获得所复制的经格式化的数据，以及

- 将所复制的经格式化的数据的目的地地址字段被设置成源于针对数据的单播传输的进一步请求的地址。

根据本发明的其他方面，提供了供在该系统中使用的控制器和服务器。服务器可以包括控制器。

上面的措施涉及经由网络传输数据。可以响应于针对数据的单播传输的至少一个请求来传输数据。例如，可以通过“现成的”单播接收机来发出这样的请求。作为响应，可以例如通过服务器根据运输协议来格式化所请求的数据。然后可以例如通过从服务器朝网络的一个或多个转发节点发出经格式化的数据而将其馈送到网络中。

虽然请求针对例如通过在服务器与接收机之间的单播会话期间发送的数据的单播传输，但是可以实现经格式化的数据的多播。即，可以使用可编程网络，其可以包括例如由控制器远程可控的一个或多个转发节点。可编程网络的示例是软件定义网络（SDN），如在例如2012年4月13日开放网络基金会（ONF）的白皮书“Software-Defined Networking： The New Norm for Networks”中描述的那样。

发明人已经认识到，这样的可编程网络可以被用来实现经格式化的数据的多播。即，可以控制一个或多个转发节点在网络内复制经格式化的数据。已经获得了所复制的经格式化的数据，所复制的经格式化的数据的目的地地址字段可以被设置成适当的地址。例如，如果在针对数据的单播传输的初始请求之后接收到针对数据的单播传输的进一步请求，则所复制的经格式化的数据的目的地地址字段可以被设置成源于所述进一步请求的地址。

上面的措施的优点是即使请求和进一步请求可能针对数据的单播传输也可以实现数据的多播。照此，可以针对“现成的”单播接收机提供多播，所述“现成的”单播接收机可能没有被专门地配置用于可靠多播技术本身。特别地，接收机可以保持不察觉到数据正被多播到它。即，可编程网络可以执行多播使得（现成的）接收机可以像其是与服务器的单播会话的部分一样进行操作。此外，通过在可编程网络内复制经格式化的数据，在一个或多个转发节点上游的网络中可能比如果经格式化的数据已经被事先复制并且因此已经以复制的格式馈送到网络中要求更少的网络容量，这在由各种接收机（接近）同时地请求数据时特别地高效。

在实施例中，可以根据供通过因特网协议[IP]使用的运输控制协议[TCP]来格式化数据。TCP/IP是可靠的运输协议并且因此可以提供经格式化的数据的可靠传输。

在实施例中，方法可以进一步包括如下中的至少一个：

- 针对经格式化的数据的分组生成确认编号，并且控制一个或多个转发节点复制具有确认编号的经格式化的数据的分组，以便获得用于所复制的经格式化的数据的分组的相同的确认编号方式（numbering）；

- 将经格式化的数据和/或所复制的经格式化的数据的分组中的确认控制位和确认编号设置成零；以及

- 控制一个或多个转发节点调整经格式化的数据和/或所复制的经格式化的数据的分组中的确认编号以获得与用于TCP确认的规则一致的确认编号方式。

上文是用于处理经格式化的数据和/或所复制的经格式化的数据的分组的确认编号的不同选项。应注意，“与用于TCP确认的规则一致”指在注有日期1981年9月的RFC 793 “传输控制协议DARPA因特网程序协议规范 （TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION）”中描述的确认机制，例如如在章节2.6 “可靠通信（Reliable Communication）”中引入的那样，并且特别地可以指提供确认所接收的TCP分组的确认编号。这可以包括关于其他RFC中的TCP确认的进一步规则，诸如关于选择性ACK的那些，还参见针对各种TCP扩展的概观的RFC 4614。

在实施例中，方法可以进一步包括针对特定请求一个接一个地测试上面列举的选项中的两个或更多直至接收到确认消息（因为这可以指示接收机已经成功地接收并且接受TCP分组）。特定接收机可以或者可以不与上面选项中的每个兼容。照此，可以例如以列举的次序顺序地尝试上面选项中的两个或更多直至接收到确认消息，因为前两个选项是计算上最高效的。

在实施例中，格式化数据以获得经格式化的数据可以进一步包括：

- 使用IP分片将每个分组至少分片成包括确认编号的第一分片和至少包括数据的部分的第二分片；

- 通过单播传输每个分组的第一分片，每个分组的第一分片具有与用于TCP确认的规则一致的确认编号方式；以及

- 将每个分组的第二分片提供到网络以由一个或多个转发节点多播。

多播因此可以仅被应用于包括数据的第二分片，而第一分片可以经由单播递送。由于第一分片包括确认编号，这些可以被生成以正确地指示由接收机预期的下一TCP序列编号值。然而，在大小上通常比第一分片大（得多）的第二分片可以由可编程网络的一个或多个转发节点多播，以便获得多播的较早提及的优点。

在实施例中，方法可以进一步包括在以同步-确认消息对请求和/或进一步请求进行响应之后为经格式化的数据和/或所复制的经格式化的数据的分组提供与相应的同步-确认消息的序列编号一致的序列编号。根据TCP在例如服务器与接收机之间的会话期间维持序列编号中的一致性通常是所期望的。照此，可以给经格式化的数据和/或所复制的经格式化的数据的分组提供与相应的同步-确认消息的序列编号一致的序列编号。

在实施例中，方法可以进一步包括在每个同步-确认消息中使用相同的序列编号。代替在相应同步-确认消息中使用不同的序列编号，如可能正常地是根据TCP的情况那样，使用相同的序列编号。优点是相同的序列编号方式可以被用于经格式化的数据和所复制的经格式化的数据。因此，所复制的经格式化的数据的序列编号方式可能不需要由一个或多个转发节点改变。

在实施例中，方法可以进一步包括：

- 在每个同步-确认消息中使用不同的序列编号，以及

- 控制一个或多个转发节点为经格式化的数据和/或所复制的经格式化的数据的分组提供与相应的同步-确认消息的不同的序列编号一致的序列编号。

在根据TCP在每个同步-确认消息中使用不同的序列编号的情况下，可以控制一个或多个转发节点例如通过调整或重写分组中的现有序列编号来提供与相应的同步-确认消息的不同的序列编号一致的经格式化的数据和/或所复制的经格式化的数据的分组的序列编号方式。

在实施例中，方法可以进一步包括在将经格式化的数据提供到网络之前将经格式化的数据的目的地地址字段设置成对应于：

- 源于针对数据的单播传输的请求的接收机地址，或者

- 针对由一个或多个转发节点进行的多播而提供的分离地址。

经格式化的数据因此可以被指向请求数据的单播传输的（第一）接收机处。替代地，可以使用分离地址。在两种情况下，经格式化的数据可以由一个或多个转发节点复制。

在实施例中，对一个或多个转发节点的控制可以包括：

- 在将经格式化的数据提供到网络之前将一个或多个转发节点预配置用于多播；或者

- 响应于经格式化的数据的第一分组由所述节点接收到而将一个或多个转发节点配置用于多播。

预配置的优点是减少的网络负载。触发配置的优点是服务器处的减少的等待时间以及因此减少的复杂性。

在实施例中，方法可以进一步包括如下中的至少一个：

- 响应于针对通过经格式化的数据的多播提供的分组的重传的请求，通过单播重传分组；以及

- 响应于针对通过经格式化的数据的多播提供的分组的重传的多个请求，将分组提供到网络以由一个或多个转发节点多播。

服务器可以被提供供在系统中使用并且可以被配置用于：

- 接收针对数据的单播传输的请求；

- 通过i）根据运输协议来格式化数据以获得经格式化的数据以及ii）将经格式化的数据提供到网络而对请求进行响应，经格式化的数据包括目的地地址字段；以及

- 当接收到针对数据的单播传输的进一步请求时，响应于所述进一步请求而与实现经格式化的数据的多播的控制器通信以便提供所复制的经格式化的数据。

控制器可以被提供供在系统中使用并且可以被配置用于控制一个或多个转发节点通过如下来实现经格式化的数据的多播：

- 复制经格式化的数据以获得所复制的经格式化的数据，以及

- 将所复制的经格式化的数据的目的地地址字段设置成源于针对数据的单播传输的进一步请求的地址。

将领会，可以在相同或者分离的转发节点上执行经格式化的数据的复制以及地址字段的设置。

服务器可以包括控制器。

由本领域那些技术人员将领会，可以以认为有用的任何方式组合本发明的上面提及的实施例、实现和/或方面中的两个或更多。

可以由本领域技术人员在当前描述的基础上执行系统和/或计算机程序产品的修改和变化，其与方法的所描述的修改和变化对应。

附图说明

根据下文中描述的实施例，本发明的这些和其他方面是显然的，并且将参考下文中描述的实施例阐明本发明的这些和其他方面。在图中，

图1示出了示例网络拓扑；

图2提供了用于使用可编程网络实现数据的多播传输的系统和方法的一般概观；

图3示出了其中由可编程网络实现向两个接收机多播数据的示例消息流；

图4图示了TCP分组中的确认编号；

图5图示了在服务器从接收机接收到针对文件的请求之后由控制器配置转发节点；

图6图示了转发节点在从服务器接收到数据时通过控制器触发配置；

图7示出了用于使用可编程网络实现数据的多播传输的经组合的服务器/控制器；

图8示出了向两个接收机多播的示例消息流，其中经格式化的数据被定址到接收机中的一个；

图9示出了向两个接收机多播的示例消息流，其中经格式化的数据被定址到分离的地址以用于多播；

图10示出了其中在可编程网络的入口节点处采用数据丢掉（drop）的示例消息流；

图11示出了其中服务器是与控制器分离的标准服务器的示例消息流；以及

图12示出了其中服务器在TCP连接的建立期间向服务器指示所请求的文件的示例消息流。

应该注意到，在不同的图中具有相同参考编号的项目具有相同的结构特征和相同的功能，或者是相同的信号。在已经解释了这样的项目的功能和/或结构的情况下，在详细描述中不存在针对其重复的解释的必要。

参考编号的列表

参考编号的以下列表被提供用于促进对图的解释并且将不被分析为限制权利要求。

010 摄取点

020 轨道（metro）核

030 轨道桥

040 数字订户线接入复用器

050 接收机

060 每网元较少接收机

062 每网元较多接收机

100 服务器

110 控制器

112 数据交换

120 服务器/控制器节点

300 可编程网络

310 转发节点

312 入口转发节点

314 出口转发节点

320 控制通信

330 数据通信

400 接收机A

410 接收机B

500 针对数据请求A

502 针对数据请求B

510 将经格式化的数据提供到网络

520 控制一个或多个转发节点

530 复制经格式化的数据。

具体实施方式

系统和方法的以下实施例涉及使用可编程网络实现数据的多播传输。照此，多播可以被提供用于“现成的”单播接收机。参考图1和2提供了一般解释，而图3-11示出了具体实施例。实施例都不应被理解为表示对本发明的限制。

在下文中，互换地使用术语“接收机”、“终端”、“客户端”和“用户设备”（还简言之UE），其指所请求的数据的接收者。此外，术语“流”要被理解为连续数量的数据分组，其一起包含由接收机请求的数据。

图1示出了具有典型的似树拓扑的网络的示例。举例来说，图1的网络被示出是数字订户线（DSL）提供商的承载网络，其包括摄取点010、轨道核020、轨道桥030、DSL接入复用器040和接收机050。可能存在从例如摄取点010上游的服务器（在图1中没有示出的服务器）向接收机050中的两个或更多提供相同数据的需要。为了增加（单播）数据递送的效率，可以使用数据高速缓存。然而，将数据高速缓存在网络树中放置得过“低”（过于靠近接收机，如由箭头060图示的那样）导致每数据高速缓存几个服务器，并且将因此相当昂贵。相反地，将数据高速缓存在网络中放置得过“高”（如由箭头062图示的那样）要求网络具有较大的运输容量，其也相当昂贵。

图2提供了用于使用可编程网络300实现数据的多播传输的系统和方法的一般概观。示出了服务器100、控制器110、可编程网络300和第一接收机400、第二接收机410。举例来说，服务器100和控制器110被示出被集成到单个服务器/控制器节点120中。

网络300是包括远程可控的一个或多个转发节点的可编程网络。在图2中，并且在以下示例中，可编程网络是软件定义网络（SDN）。然而，可以等同地采用其他类型的可编程网络，包括但不限于在N. Feamster标题为“The Road to SDN： An Intellectual History of Programmable Networks”的论文中描述的那些可编程网络。

在SDN或其他可编程网络中，所谓的控制平面（例如路由或智能）从路由器移动并且被集中在控制器中。路由器仍负责分组转发，但是在控制器的远程控制之下。照此，路由器现在有效地起转发节点的作用并且因此在下文中也被称为转发节点，或者在SDN的情况下被称为SDN节点。控制器可以每业务流设置转发节点的转发规则。该控制可以被预编程或者可以被实时地动态地调整。转发节点还可以将例如关于带宽使用的监视信息报告给控制器。控制器因此可以获得网络的完整视图，其在决定如何路由分组流中是有用的。应注意，为了减少图2的复杂性，没有明确地示出网络的转发节点。

系统的方法和操作可以涉及接收针对数据的单播传输的请求。例如，请求可以由服务器100从第一接收机400接收，如由箭头500指示的那样。服务器100然后可以通过i）根据运输协议来格式化数据以获得经格式化的数据以及ii）将经格式化的数据提供到网络而对请求进行响应，如由箭头510指示的那样。经格式化的数据包括目的地地址字段。响应于针对数据的单播传输的进一步请求，例如如由服务器100从第二接收机410接收502的那样，可以例如通过控制器110控制一个或多个转发节点实现经格式化的数据的多播，其中该控制由箭头520指示。一个或多个转发节点然后可以复制530经格式化的数据以获得所复制的经格式化的数据，并且将所复制的经格式化的数据的目的地地址字段设置成源于进一步请求的地址，例如对应于第二接收机410的地址。此外，如将更进一步阐明的那样，在多播的背景内可能存在服务器100和控制器110之间的数据通信112。

有效地，可编程网络300可以执行多播使得现成的单播接收机可以保持不察觉到多播，因为每个接收机可以像其是与服务器100的单播会话的部分一样进行操作。

应注意，可能近似同时接收针对数据的请求和进一步请求，使得服务器100能够仅向可编程网络300发送一次数据。然而，在针对数据的初始请求之后，仅可以在稍后的时间接收针对数据的（一个或多个）进一步请求。然而，上面的多播仍可以被应用。例如，服务器100可以在接收到初始请求之后为其他请求等待某时段。在“附加点和替代”之下进一步讨论了该选项以及其他选项。

图3示出了其中通过可编程网络实现向两个接收机多播数据的示例消息流。举例来说，这里和在下文中，请求和随后的数据传输是经由TCP的HTTP。然而，将领会，还可以使用虑及可靠的数据递送的除TCP之外的运输协议。例如，可以使用诸如SCTP（流控制传输协议）和VTP（Venturi运输协议）之类的运输协议，其展现与TCP类似的行为。而且，可以使用除HTTP之外的应用协议，诸如SPDY或WebDAV（分布式编写和版本控制）。

在图3的示例中，此后也被称为接收机A的第一接收机400可以请求文件。为此，接收机A可以首先使用默认的三次TCP握手来建立与在该示例中是服务器/控制器节点120的部分的HTTP服务器的TCP会话。在TCP会话活跃之后，接收机A可以发送HTTP GET以检索文件。HTTP服务器可以在TCP级别上利用TCP ACK来确认HTTP GET。应注意，该消息交换可以全部是HTTP服务器与接收机A之间的单播交换。随后，此后也被称为接收机B的第二接收机410可以以与接收机A类似的方式请求文件。HTTP服务器然后可以向SDN网络的转发节点310发出文件，即如HTTP 200 OK消息中的净荷。转发节点310然后可以在步骤12中向接收机A发送该数据。接收机A可以向HTTP服务器发送回TCP ACK。上述情况在步骤14和15中也适用于接收机B。这样，如果例如接收机A和B在相同DSLAM上，并且该DSLAM是使能SDN的，则文件仅被发送到DSLAM一次并且在其中被复制。应注意，可以在多个TCP分组中携带HTTP 200 OK，并且因此可以由接收机发送多个TCP ACK。然而，为了简单起见，这没有在图3中示出。

此后讨论了使用可编程网络使能多播的以下方面：

1. IP地址重写

2. ACK编号

3. TCP拥塞管理

4. 重传

5. 预配置和触发配置

6. 实现场景

1. IP地址重写

接收机正常地仅接受被定址到它们的IP分组。照此，如果可编程网络仅拷贝分组，则它们可以全部具有相同的目的地IP地址。如果例如HTTP服务器使用接收机A的IP地址作为目的地地址向接收机A发送文件，则仅拷贝这些分组并且将它们发送到接收机B可能不起作用，因为接收机B将看到被定址到未知目的地IP地址的IP分组并且可能丢弃它们。

例如使用OpenFlow的 SDN正常地通过使用群组表格来执行多播：传入的分组经受指令的群组。用于多播的指令可以是：向接收机A发送，接着向接收机B发送。可以通过将目的地IP地址和目的地TCP端口编号设置（即改变）成对应于请求接收机的地址来扩展指令的该群组。这些指令通常由SDN例如通过OpenFlow支持。

假定HTTP服务器向接收机A发送分组，则经扩展的群组表格可以如下：

1. 向接收机A转发

2. 设置用于接收机B的目的地IP地址和TCP端口编号

3. 向接收机B转发

通过重复步骤2和3，该机制可以被扩展到多于两个接收机。

应注意，SDN在做出对分组的改变时可能必须重新计算TCP校验和。正常地使用整个TCP分组的数据来计算TCP校验和，所述数据包括TCP报头和伪报头，其可能包含IP地址、协议和TCP长度。在改变TCP分组的部分之后，原始校验和也应该被改变。SDN节点将正常地在改变IP地址或端口编号时重新计算这样的校验和。

2. ACK编号

TCP使用序列编号实现可靠性，其虑及将TCP分组放置在正确的次序中的接收机并且虑及使能丢失分组的重传的确认方案。通常，除初始SYN分组之外的所交换的每个TCP分组包含确认（ACK）。该ACK包含由接收机预期的下一TCP序列编号值。

应注意，每个接收机将通常选择随机的开始序列编号。这意味着在一个或多个TCP分组中携带的初始HTTP GET的确认可能必须针对每个接收机而不同。照此，当在网络中拷贝TCP分组时，那些分组中的ACK可能不是正确的，除了可能是一个接收机。图4图示了如何针对接收机A和接收机B生成这样的确认编号。这里，针对接收机A，在具有序列编号“15” （应注意，出于可读性选择编号，而不是TCP的32位序列编号）的TCP分组中携带HTTP GET。照此，发送到接收机A的初始ACK包含作为下一预期的序列编号“16”。针对B，在该示例中，序列编号是“83”并且因此ACK包含“84”。

在HTTP服务器发送较多数据的情况下，将下一预期的序列编号插入在携带HTTP响应的TCP分组中通常将继续。如在图4中示出的那样，HTTP服务器针对接收机A如此做，保持编号“16”在确认字段中。但是由于该分组在SDN网络中也被拷贝并且被发送到接收机B，接收机B接收具有“陌生”确认编号的TCP分组，所述“陌生”确认编号即接收机A的确认编号，其是“16”而不是“84”。

取决于在TCP堆栈中实现的规则，这可能是或者可能不是问题。照此，存在关于如何处理在SDN中的数据的多播中的确认编号的多个选项：

1. 接收机处的TCP/IP堆栈可以仅接受分组，即使确认编号是错误的。即，TCP实现通常遵循一般的鲁棒性原则：在你所做的方面保守、在从其他所接受的方面宽容。因此，当接收到例如“无效的ACK”的无效的确认编号时，接收机可能无论如何接受分组。特别地，已知些网络装备，诸如来自Cisco的网络设备，可以被配置成接受或丢掉具有“无效的ACK”的这样的分组。因此，在接收机被配置用于接受初始TCP会话建立之后的“无效的ACK”的情况下，可能不需要进一步校正确认编号。

然而，可能丢弃分组，并且可能通过TCP重传系统请求重传，导致另一丢弃并且最终导致TCP会话超时。对此，可以采用选项2-4。

2. TCP ACK控制位可以由HTTP服务器设置成“0”，这意味着不使用确认字段。附加地，确认编号也可以被设置成0。这正常地仅被允许用于初始SYN分组，因为对于该初始分组而言还不存在要确认的TCP分组。然而，控制位和确认编号仍然可以被设置成0。类似于选项1，接收机是否将接受分组将取决于接收机的TCP堆栈。

3. SDN控制器可以使得通过转发节点来改变确认编号。例如，已经从例如HTTP服务器学习到将被用于每个接收机的适当的确认编号的SDN控制器可以将该确认编号与在转发分组之前利用用于该接收机的适当的确认编号来替换分组中的确认编号的指令一起发送到最接近接收机的转发节点。这可能涉及重新计算TCP校验和，其附带地可以在已经重写目的地IP地址和确认编号二者之后被执行。由于接收机通常在初始HTTP GET请求之后不向HTTP服务器发送任何数据，将被插入的确认编号可以对于包含将被递送的文件的所发送的所有随后TCP分组而言相同。SDN控制器可以利用适当的确认编号指示SDN网络一次，根据其SDN网络可以替换用于给定接收机的所有TCP分组中的编号。

4. 可以采用IP分组分片，其中将被发送的分组分片成包含IP和TCP报头的小分组，其至少包括确认编号，以及包含数据的大分片。可以以单播方式将小分片发送到每个接收机，而可以使用SDN多播大分片。由于大分片不包含任何接收机特定的部分，关于确认编号在SDN中复制大分片不存在问题。在接收到IP分组分片时，接收机将组合这些并且将提取将包含用于该接收机的正确的确认编号的TCP分组。应注意，分片的该形式对IPv4和IPv6二者起作用。IPv6不支持途中的分片，但是其支持在源处的分片。

由于存在如何处理SDN中的数据的多播中的确认编号的多个选项，一个接一个地尝试这些选项中的两个或更多可以是可能的。前两个选项可能是最高效的，因此这些可以被首先尝试。如果没有接收到针对像这样发出的分组的确认，则服务器可以确定这些选项对给定接收机不起作用。服务器因此可以依靠SDN支持什么或者也许依靠服务器上的负荷（因为选项3将负荷放在网络中并且选项4将它主要放在服务器上）而对选项3或4做出决定。又一选项可以是使接收机在会话建立期间或者例如作为HTTP GET的部分如附加参数来指示接收机是否支持选项1或2。应注意，选项3和4完全独立于接收机的配置。此外，接收机上的TCP/IP堆栈可以被修改或配置以接受选项1或2。

3. TCP拥塞管理

TCP具有内置拥塞管理，其包括发送器选择适当的发送速度来开始和缓慢地（TCP的“慢启动”）增大（build up）速度。这可以通过经由发送窗口（也被称作拥塞窗口cwnd）对适当的发送速度的跟踪来完成，所述发送窗口指示在任何给定时间在TCP连接上可以发送多少数据。接收机可以指示（例如由其缓冲器容量限制的）它在某时间可以接收的数据的最大量，其被称作接收机窗口（rwnd），用于流控制以防止发送器对于该接收机发送得过快。正常地，TCP发送器将选择两个窗口（发送窗口和接收窗口）中的较低者，并且通过增加发送窗口来逐渐地增大速度，直至例如使用完整接收机窗口达到最大速度，或者直至通过例如（经由TCP确认方案确定的）分组丢失而注意到业务遭遇拥塞。

在SDN中的数据的多播的情况下，所有接收机可以接收相同流，但是TCP流控制可能是每接收机有效的（active）。这可以使得最慢的接收机减慢所有流，或者当发送器忽略最慢接收机的接收机窗口时，数据的流对于最慢的接收机而言过多。然而，这不需要实现在本说明书中公开的多播技术。例如，SDN通常具有整个SDN网络的视图，包括带宽可用性和带宽使用。因此，SDN控制器通常知道某些数据流是否将适合网络，并且可能TCP拥塞控制不被需要。实际上，在内容递送网络（CDN）中，先验地知道网络带宽的量，并且发送器可以使用大发送窗口开始，例如不进行慢启动。此外，大部分接收机现今具有大接收机窗口，因为它们无论如何被适配到高速网络。因此，最可能地，通过网络（即，使用cwnd）而不是通过接收机（即，使用rwnd）限制可以以其发送数据的速度。

4. 重传

正常地，用于TCP的发送侧具有针对每个分组的重传超时。如果接收机没有确认某TCP分组，则发送器可以在超时之后重传分组。存在使用例如选择性确认和快速重传的关于这一点的各种扩展，但是它们全部可能实际上是相同的，即通过重传未被确认的分组来实现可靠性。

针对在本说明书中公开的多播技术，接收机可以按照正常情况那样确认分组。如果服务器检测到一个接收机已经错失分组，例如用于该接收机的重传定时器已经终止，则其可以使用单播重传TCP分组，例如如正常地在TCP会话期间那样。

如果服务器检测到多个接收机未能正常地接收到TCP分组，例如用于多个接收机的重传定时器已经终止，则其也可以选择通过可编程网络使用多播来重传分组。这样，分组也可能到达已经正确地接收分组的接收机。这不是问题，因为接收机可以丢掉重复分组，其对于TCP而言是正常行为，因为确认可能已经被丢失或延迟过多并且然后发送侧也将重传TCP分组。

5. 预配置和触发配置

转发节点可能需要被配置成实现数据的多播。可以如下执行这样的配置：

- 预配置：控制器可以例如在数据已经由多个接收机请求之后、但是在将被多播的数据由服务器提供到网络之前预配置网络中的SDN节点

- 触发：SDN节点将流的第一分组转发到SDN控制器，并且SDN控制器然后作为响应而设置用于该流的配置。

图5图示了在如由标题为“REQ_FILE”（“请求文件”的简称）的消息指示的那样服务器100从第一接收机400接收到针对文件的请求之后由控制器预配置转发节点。在该示例中，服务器100还从（没有在图5中示出的）第二接收机接收进一步请求，使得服务器100可以确定多播是适当的。服务器100然后可以向控制器110指示将执行多播，例如如由标题为“IND_FILE_REQUEST”（“指示文件请求”的简称）的消息指示的那样。控制器120然后可以如由标题为“CONF_DUPL”（“针对副本进行配置”的简称）的消息指示的那样配置转发节点310，所述消息可以如由标题为“ACK”的消息指示的那样向控制器110并且随后向服务器100确认。在接收到已经完成的预配置的确认时，服务器100然后可以开始将数据发送到转发节点310，如由标题为“SND_DATA”（“发送数据”的简称）的消息指示的那样，并且转发节点310然后可以执行多播并且随后转发所复制的数据，如由标题为“FWD_DATA”（“转发数据”的简称）的消息指示的那样。

图6图示了转发节点310在从服务器100接收到数据时通过控制器触发配置。在该情况下，服务器100可以向控制器指示文件请求并且立即开始发送数据。转发节点310现在可以接收包含数据的分组，并且可以将此检测为它不具有针对其的任何配置的新数据流。转发节点310现在可以例如通过将流的第一分组转发到控制器110来触发控制器110。这样的触发在图6中由标题为“TRIG/REQ_CONF”（“触发/请求配置”的简称）的消息指示。这可以允许控制器110就如何处置流来配置转发节点310，所述如何处置流在该情况下即如何将副本发送到接收机。这通过标题为“CONF_DUPL”（“针对副本进行配置”的简称）的消息来指示。应注意，在该场景中，转发节点310可能必须对在它从控制器110接收配置之前到达的属于流的分组排队。

6. 实现场景

可能存在服务器和控制器的不同实现场景，其在下文中被指示用于HTTP服务器和SDN控制器并且在TCP的背景内。场景包括（这里，“默认”指示缺少针对如在本说明书中描述的多播的修改）：

- 场景A：经组合的HTTP服务器和SDN控制器

- 场景B：默认HTTP服务器，SDN处置多播

- 场景C：经修改的HTTP服务器，其与SDN控制器交互。

在每个场景中，可能注意以下：

1. 可以使TCP序列编号一致。TCP连接建立是接收机和HTTP服务器之间的单播，而数据分组被多播。照此，在TCP连接建立期间，初始TCP序列编号可以由服务器选择，但是这可能不与被多播的分组中的TCP序列编号自动地一致，如果例如被多播的数据流来自另一初始连接建立的话。为了解决这一点，服务器可以选择非随机的TCP序列编号，使得到所有接收机的数据分组具有相同的序列编号方式。替代地，可以在可编程网络中针对每个接收机调整TCP序列编号。这可以遵循在可编程网络中针对每个接收机对确认编号的较早描述的调整。替代地，可以设计总是在特定序列编号（例如1）处开始的运输协议。

2. 数据分组将被多播，并且照此，数据分组应该进入网络仅一次以然后在网络中被拷贝（或分叉（fork）、复写、复制）。照此，可能需要针对网络中的副本进行布置（其可以在所有场景中相同），并且确保仅一个流进入网络。针对后者，存在若干选项，包括但不限于：

- HTTP服务器仅将分组发送到接收机中的一个的地址一次

- HTTP服务器仅将分组发送到针对SDN多播具体选择的地址一次

- HTTP服务器向每个接收机发送分组，其中网络本身丢掉不必要的流

3. 还如较早指示的那样，当到一个或多个接收机的分组丢失时，这些接收机将请求它们的重传。选项包括：

- 使用单播向请求重传的每个接收机进行重传，

- 检测请求相同重传的多个接收机，并且使用SDN多播进行重传。

在下文中，描述每个场景同时具体地解决上面三点。

场景A：经组合的HTTP服务器和SDN控制器

图7示出了用于使用可编程网络实现数据的多播传输的经组合的服务器/控制器120。组合HTTP服务器和SDN控制器的优点是两个元件之间的交互是内部的，所以其协作变得较容易：数据可以被共享，一个的知识对另一个可用。而且，在预配置模式中，可以在两个之间容易地对定时达成协议：首先控制器部件可以适当地配置网络，并且直到那时服务器部件才可以开始发送数据分组。

在图7中，服务器/控制器120被示出包括服务器部件100和控制器部件110。可编程网络300、入口转发节点312、出口转发节点314、第一接收机400、第二接收机410、控制器部件110和转发节点之间的控制通信320，以及服务器部件100和接收机400、410之间经由网络300、312、314的数据通信330被进一步示出。

针对序列编号方式，服务器部件可以选择非随机的TCP序列编号。由于每个接收机可以请求相同文件，发送到每个接收机的数据的量可以相同，包括TCP连接建立。因此，如果服务器部件选择相同TCP序列编号来开始TCP连接，则这将确保数据分组也都具有相同的序列编号。因此，当针对一个接收机将数据流复写到另一个接收机时，在发起TCP连接和发送数据中使用的数据编号将是正确的，即连续的。不存在针对控制器部件的角色。

替代是服务器部件针对其发起的每个TCP连接选择随机的TCP序列编号。如果没有被进一步修改，则这可以引起问题：对于接收数据流的副本的接收机而言，朝接收机的由服务器使用的TCP序列编号可能不是正确的，即不连续的。即，在携带实际数据的（多播）TCP分组和TCP的（单播）建立中使用的TCP序列编号之间可能存在不连续。为了校正这，控制器部件可以指示出口转发节点（最接近接收机的转发节点，在其之后将不再发生分组的复写）改变序列编号。在该场景中，控制器部件可以察觉到由服务器部件使用的序列编号，例如如果服务器部件将这些存储在数据库中的话。针对序列编号的指令可以包含两个序列编号：原始流中的一个以及其应该变成的值。替代地，仅可以发送差异，转发节点可以所述差异其添加到原始的序列编号以达到用于重复流的适当是序列编号。

关于非随机序列编号的选择，进一步注意以下。在TCP连接建立期间选择TCP序列编号，在该时间可能不知道哪个文件被请求。毕竟，正常地仅在TCP连接已经被建立之后发送包含文件URL的HTTP GET。然而，存在处理这一点的各种方式：

- 不管文件，针对每个连接选择相同的非随机序列号。应注意，这可以具有安全暗示（implication）。

- 使指向文件的URL包含唯一的TCP端口编号。照此，在其上请求TPC连接的端口编号将指示所请求的文件，并且非随机序列编号可以基于它。将在“附加点和替代”之下进一步解释该机制。

- 针对MPEG-DASH，所请求的文件不是随机的：以在索引文件（媒体呈现描述，MPD）中指示的连续次序来选择它们。照此，HTTP服务器一般知道接收机请求的下一文件，除非接收机切换到另一位率并且因此切换到另一文件，或者当多个文件被同时请求但是请求在网络中互相超过（overtake）时。

为了在该场景中多播数据分组，服务器部件可以向例如接收机A的地址的接收机中的一个的地址发送数据分组仅一次。服务器/控制器然后可以保持对哪些接收机已经请求相同文件的根据并且相应地指示转发节点。

图8示出了向两个接收机多播的示例消息流，其中经格式化的数据被定址到接收机中的一个。使用接收机中的一个的地址可能有问题，如果该接收机（例如接收机A）出于某原因离开多播（例如停止下载文件）的话。然而，在该情况下，可以指示可编程网络对数据分组进行过滤并且不再将它们发送到接收机A，而同时将副本发送到其他接收机。

在图8中，以下消息被指示：

“UNIC_REQ_FILE”：单播：请求文件

“INSTR”：指令：

“DUP_STR_A_TO_UEB”：将流A复写到UE B

“CHG_SEQ_NR”：改变序列编号

“UNIC_STR_A_TO_UEA”：单播：流A到UE B

图9示出了向两个接收机多播的示例消息流，其中经格式化的数据被定址到被提供用于多播的分离地址。消息以与图8中相同的方式被缩写，加上必要的变更。该示例涉及服务器使用具体地用于多播的（IP）地址。这可以防止在主接收机（即，加入多播的第一接收机）离开会话时出现问题，如参考图8指示的那样，但是可能要求到转发节点的附加指令以还将分组复写到主接收机。

图10示出了其中在可编程网络的入口节点处采用数据丢掉的示例消息流。即，处理多播的一个方式是让服务器向请求数据的所有接收机发送数据，并且然后控制可编程网络在适当的情况下在网络的入口节点处丢掉数据分组。优点可以是服务器不需要被修改。替代地，服务器也可以与转发节点组合。丢掉分组的指令然后可以去往与服务器共同定位（co-locate）的转发节点。这可以全然防止分组进入网络，而不是仍去往网络中的第一转发节点，例如入口节点。

在图10中，以下消息被指示：

“UNIC_REQ_FILE”：单播：请求文件

“INSTR”：指令：

“DRP_PCKTS_TO_UEB”：丢掉到UE B的分组

“DUP_STR_A_TO_UEB”：将流A复写到UE B

“CHG_SEQ_NR”：改变序列编号

“UNIC_STR_B_TO_UEB”：单播：流B到UE B

“UNIC_STR_A_TO_UEA”：单播：流A到UE A

应注意，关于重传，在图10的多播场景中，当向例如接收机B重传分组时，单播中的重传可能由于网络被指示丢掉到接收机B的分组而失败。照此，可能所期望的是不使用单播重传而使用多播，或者使用变通方案。例如，控制器可以临时指示网络停止丢掉到接收机B的分组，进行重传，并且然后再次指示网络丢掉到接收机B的分组。另一替代是针对网络中的具体的单播重传机制进行布置。例如，当服务器使用不同的地址或端口编号发送单播重传时，（一个或多个）转发节点可以被配置成将这些分组转发到适当的接收机，并且（一个或多个）转发节点还可以配置为执行地址和端口编号的重写以再次将TCP分组重新格式化成原始的TCP分组。

场景B：默认HTTP服务器，SDN处置多播

图11示出了其中服务器是与控制器110分离的标准HTTP服务器100的示例消息流。HTTP服务器100完全默认并且SDN控制器110是分离实体的场景与场景A不同。即，SDN可能必须检测多个接收机正在请求相同的文件，并且可能不依赖由HTTP服务器100提供的信息来执行其在多播中的功能中的任何。

在图11中，入口节点312被示出将用于HTTP服务器100的所有分组首先转发到SDN控制器110。这样，SDN控制器110可以检测哪些接收机请求相同的文件，并且因此需要接收数据的拷贝，并且在TCP连接中使用什么序列编号。SDN控制器110可以在由接收机410作为请求发送到HTTP服务器100的HTTP GET中检测到前者。即，在该HTTP GET中，文件的URL显现，这指示请求针对什么。应注意，图11的消息流发生在TCP连接被建立之后，并且因此在TCP序列编号被指派之后。从接收机410到HTTP服务器110的HTTP GET因此包含ACK字段中的由HTTP使用的序列编号，由于ACK字段包含下一预期的序列编号。SDN控制器110因此可以使用该信息来导出将被用在流中的序列编号。

针对序列编号方式，最期望的选项是校正网络中的序列编号。该选项类似于场景A的选项。非随机序列编号的使用是较不所期望的选项。原则上，SDN可以改变来自初始TCP连接建立的序列编号。然而，在TCP连接建立期间，还未知道哪个文件被请求。为了解决这一点，所有TCP连接可以从SDN接收相同的TCP开始序列编号，这意味着与服务器的任何和全部TCP连接不仅针对需要被多播的文件。另一选项是涉猎例如端口编号：如果每个文件URL还包含唯一选择的TCP端口编号，则TCP端口编号然后可以被用来检测哪个文件由特定接收机请求。在该情况下，序列编号可能已经在TCP连接建立期间被调整。

为了实现多播，场景B可以使用第三选项，即HTTP服务器向每个接收机发送分组，其中网络本身丢掉不必要的流，这类似于如针对场景A描述的那样。HTTP服务器因此可以将单播数据分组发送到请求文件的所有接收机。SDN网络然后可以主动地丢掉用于除优选地一个的较小数量的流之外的所有流的分组，并且将这一个流复写到请求文件的所有接收机。

应注意，在该场景中，SDN控制器不能与HTTP服务器协作以随着发送数据等待直至SDN节点被适当地指示。照此，在该场景中，可能必须使用操作的“触发”模式。即，如果“预配置”模式将被使用，则所有会话将以到所有接收机的单播递送而开始，并且仅在SDN控制器配置SDN节点之后系统将切换到多播。尽管这可以起作用，但是其将比触发模式更不高效，并且SDN节点的配置更复杂。这可能是由于丢掉和复写动作必须被同步以防止分组被丢掉但还未被复制，导致错失针对某些接收机的分组，或者被复制但还未被丢掉，导致双重分组。

关于重传，因为HTTP服务器与SDN控制器分离，所以SDN控制器可能没有察觉到重传。然而，因为HTTP服务器将仅使用到每个接收机的单播连接用于到该接收机的重传，所以这意味着SDN网络可能必须标识重传，即变得察觉到重传。这可以通过使重传请求发送到SDN控制器来执行，所述SDN控制器可以例如通过使SDN转发节点检查序列编号而指示SDN转发节点不过滤掉重传。

场景C：经修改的HTTP服务器，其与SDN控制器交互

该场景类似于场景A，但是涉及HTTP服务器与SDN控制器之间的明确信令。

针对序列编号方式，可以使用以下选项：

- 使用非随机序列编号，如场景A中那样。

- 固定网络中的序列编号。为了实现这一点，HTTP服务器可以告知SDN控制器关于将被多播的流中的序列编号与到其他接收机的流中的序列编号之间的关系。因为HTTP服务器可以告知SDN控制器关于将使哪些流发送到哪些接收机（参见下文），所以关于序列编号的信息也可以是该信令的部分。

针对多播，可以使用以下选项：

- 使用接收机中的一个的（IP）地址。这类似于场景A。然而，HTTP服务器可能必须向SDN控制器发信号通知必须将哪些流转发到接收机中的哪些。而且，关于所使用的序列编号的信息可以被包括在信令中。

- 使用具体地用于多播的专用（IP）地址。这类似于场景A，但是HTTP服务器可能必须向SDN控制器发信号通知哪些流必须去往接收机中的哪些。而且，关于所使用的序列编号的信息可以被包括在信令中。

基本上，在上述的两个选项中，HTTP服务器可以向每个接收机发信号通知每个数据流的开始和结束，并且包括关于序列编号的信息。下文是可以发信号通知的信息的示例：

TCP流A

- 发送到网络中的流：

UE A（IP源、端口源、IP目的地、端口目的地、开始TCP序列编号）

- 将在网络中形成的流

UE B（IP源、端口源、IP目的地、端口目的地、开始TCP序列编号）

UE C（IP源、端口源、IP目的地、端口目的地、开始TCP序列编号）

等等。

作为用于多播的第三选项，HTTP服务器可以在单播中向所有接收机发送所有TCP流。这也类似于场景A中的第三选项。将被发送到SDN控制器的信息可以类似于用于前两个选项的信息，但是这里仅关于所发送的所有单播流的信息将被包括。SDN控制器然后可以选择保持和复写哪个流，以及在可编程网络的入口点处丢掉哪些流。

场景C中的重传也类似于场景A的重传。基本上，重传可以由HTTP服务器执行，而没有对向SDN控制器发信号通知的需要。应注意，针对重传，可能最简单的是使用多播重传，由HTTP服务器使用单个目的地IP地址。

附加点和替代

应注意，HTTP服务器不需要将内容直接地发送到请求它的第一接收机。相反，HTTP服务器可以察觉到或者预期到多个接收机将请求相同的文件。这可以是例如实况MPEG-DASH中的情况，其中许多接收机正在请求相同段。照此，HTTP服务器可以在发出段之前等待某时段，而不引起立即超时（其将导致客户端重新请求段）。例如，在段为1秒长度的情况下，HTTP服务器可以在发送段之前等待0.5或者甚至1秒。通过等待，HTTP服务器可能已经从接收机接收到较多请求。这允许服务器一次发送它并且使可编程网络针对许多接收机而复制它，虽然以将文件递送到接收机中的至少某些之前的某延迟为稍许代价。

进一步应注意，可以但是不必须正常地发送初始ACK。在后者的情况下，接收机将不必要重传HTTP GET请求。

针对实况MPEG-DASH，在媒体呈现描述（MPD）中，向每个段正常地给出可用性开始时间和可用性结束时间。这允许各种接收机在近似相同的时间全部请求相同的段，并且因此确保实况MPEG-DASH实际上是实况的。来自MPD的信息可以被用来确定何时段将不再被请求，例如在可用性结束时间之后，在该点处可以执行多播。

现今，大部分接收机被适配用于高速网络并且因此具有较大接收机窗口。照此，接收机不可能是所接收的任何网络传输中的瓶颈。然而，在接收机是瓶颈的不可能事件中，服务器可以将此考虑在内并且使某接收机离开多播并且代之以使用单播，或者在多个接收机全部在表示瓶颈的相同情形中的情况下开始并行的较低速多播。

如果接收机请求段，对于加入多播而言有点过晚，例如在加入进行中的实况MPEG-DASH会话时，则接收机仍可以从其加入的点加入多播。接收机然后可能缺少多个TCP分组，即从多播的开始直到接收机加入多播的时间。然而，可以使用TCP中的有规律的重传机制来检索错失的TCP分组，和/或服务器可以以单播方式朝该接收机主动地发送TCP分组。例如，在包括多个随后段的MPEG-DASH的情况下，如果错失第一段，则可以通过单播来发送第一段，在这之后，接收机加入多播。

代替选择接收机中的一个的地址或者多播地址用于通过可编程网络发送文件，也可以使用伪地址。伪地址的优点可以是在原始目的地接收机将离开多播的情况下不存在通过会话半途改变地址的需要。即，在网络中为了效率可以使用多播地址，如果并非网络中的所有节点都是SDN转发节点而是例如仅网络的边缘上的节点是SDN转发节点的话。使用（IP）多播地址使得非SDN网络能够高效地将数据分组路由到网络的边缘上的所有SDN转发节点。在将数据转发到接收机之前，这些SDN转发节点然后可以利用接收机的目的地IP地址代替（IP）多播地址。

关于非随机序列编号的选择，进一步注意以下。在TCP连接建立期间选择初始TCP序列编号，在该时间可能不知道哪个文件正被请求。即，正常地仅在TCP连接已经被建立之后发送包含文件URL的HTTP GET。这可以在考虑图3时被看到。在建立TCP连接中，服务器120在发送TCP SYN、ACK时选择初始TCP序列编号。服务器120优选地选择相同的初始TCP序列编号用于与不同的接收机400、410的TCP连接。即，在做这一点时，并且在随后复写携带HTTP 200 OK的TCP分组时，TCP序列编号将自动地对于不同的接收机400、410而言相同，因为分组是副本。照此，服务器120可以选择相同的初始TCP序列编号用于到多个接收机400、410的TCP连接。然而，所请求的数据还未已知，因为这仅在随后的HTTP GET中被指示。存在处理这一点的各种方式，包括但不限于：

- 不管所请求的文件，针对每个TCP连接选择相同的非随机序列编号。这可以具有安全暗示，因为TCP序列编号被正常地随机地选择作为对抗（counter）某些可能的安全问题的手段。然而，这对于某些情形而言可能是可接受的。

- 为了防止完全的非随机性，针对对于相同文件（例如数据项目）的请求可以选择相同的序列编号，但是针对不同文件之间的请求，可以不同地（例如随机地）选择序列编号。正常地，所请求的文件仅在HTTP GET中被指示。为了针对对于相同文件的请求选择相同的序列编号，可能需要较早在分组交换中指示文件，以便能够基于所请求的文件来确定TCP序列编号。图12示出可以如何实现这一点的示例。接收机400可以经由已知机制使URL指将由接收机请求的文件。正常地，用于HTTP的默认TCP端口是端口80。因此，对于不包含具体端口编号的URL，将使用TCP端口80。但是，URL还可以包含将被使用的不同的端口编号，在该示例中是目的地TCP端口12345。当URL包含这样的端口编号时，接收机将向该端口编号发送以第一TCP SYN消息开始的其TCP分组。服务器120可以检测该端口编号，如在图12中由“DCT_PRT_NR”（“检测端口编号”的简称）指示的那样。服务器然后可以基于端口编号确定初始序列编号，如在图12中由“DET_INI_TCP_SEQ_NR”（“确定初始TCP序列编号”的简称）指示的那样。为此，服务器120可以例如在端口上的第一请求到达时存储端口编号和初始序列编号的组合。如果（对于将被多播的该服务器上的每个文件而言）唯一的端口编号被插入在分发给接收机的URL中，则这允许服务器120查找该初始序列编号并且因此将相同的初始序列编号用于相同端口上的随后请求，即用于针对相同文件的请求。

- 针对MPEG-DASH，所请求的文件不是随机的：以在索引文件（媒体呈现描述，MPD）中指示的连续次序来选择它们。照此，HTTP服务器一般知道接收机请求的下一文件，除非接收机切换到另一位率并且因此切换到另一文件，或者当多个文件被同时请求但是请求在网络中互相超过时。

其他一般方面

应注意，服务器、控制器或者经组合的服务器/控制器可以被体现为单个设备或装置或者被体现在单个设备或装置中。设备或装置可以包括执行适当的软件的一个或多个微处理器。软件可能已经被下载和/或存储在相应的存储器中，所述存储器例如诸如RAM的易失性存储器或者诸如闪存的非易失性存储器。替代地，实现可以以可编程逻辑的形式，例如作为现场可编程门阵列（FPGA）。一般地，实现可以以电路的形式。应注意，也可以以例如涉及不同的设备或装置的分布式方式实现服务器、控制器或者经组合的服务器/控制器。例如，可能地使用其中实体是云的可配置计算资源的云基础设施，服务器或控制器可以被实现为由网络内的实体执行的基于软件的功能。在对等实现的情况下，这样的实体可以是用户设备。

在权利要求中，被放置在圆括号之间的任何参考记号将不被解释为限制权利要求。动词“包括”及其词形变化的使用不排除除了在权利要求中陈述的那些之外的元件或步骤的存在。在元件之前的冠词“一”或“一个”不排除多个这样的元件的存在。可以借助于包括若干不同元件的硬件和借助于经适当地编程的计算机来实现本发明。在列举若干构件的设备权利要求中，这些构件中的若干可以由硬件同一项体现。在相互不同的从属权利要求中记载某些措施的仅有事实不指示这些措施的组合不能被用来获益。