在Windows Server 2012 和 Windows 8 中引入的RemoteFX模块，显著提高了传输效率。下面是传输改善的主要目标：
使远程会话在广域网和无线网络中提供快速流畅的用户体验。
在传输中使用行业标准的安全协议，而不是自定义安全方案很关键。
尽量能达到广域网的性能最佳，使得大多数用户能通过配置获益。
不认为REMOTEFX是网络中唯一的流量，保证REMOTEFX的流量和其他网络流量公平（例如浏览网页）
默认不需要用户配置也能智能提供最好体验，但是管理员也可以进行控制。
RemoteFX针对广域网的主要特点如下：
自动网络检测，以适应网络初始，及不断变化的情况
针对网络丢包进行UDP优化，并为多媒体内容的最佳交付提供选项
前向纠错（FEC ），使得内容可以修复，不需要重传
UDP不可用时回退到TCP传输
UDP支持通过RD网关连接
行业标准的安全性和拥塞控制协议
在这篇博客中，我们将提供有关这些交通改善的更多细节。
目标广域网
WAN（广域网）的传统定义意味着高延迟网络（相对于LAN时），原因可能是带宽限制。然而，在实践中广域网的范围很宽。例如包括美国海岸到海岸链接（例如60ms的RTT，5 Mbps的容量，1％的损失），洲际的链接（如250毫秒RTT，3 Mbps的容量，1％的损失）和分支机构链接（如100毫秒RTT，256 kbps的容量，0.5％的损失）。除了这些传统的广域网，还有挑战性的移动和无线网络（如使用200毫秒RTT，1 Mbps的容量，5％的损失3G / 4G连接），信号丢包和时延抖动干扰远程桌面，产生了很多问题。
RemoteFX针对广域网传输进行设计时，不是专注于某一特定类型的网络优化，而是专注于解决每个基本因素造成的影响：延时，丢包和可用带宽。我们还研究了其他重要因素，例如延迟变化（也称为抖动）和分组丢失模式（单个或连续的，拥塞引起的或非拥塞引起的）。
在接下来的几节中，我们将讨论广域网这些基本面因素对性能的影响和相关RemoteFX的改进。
自动网络检测
高效率的传送的目标是：确保最充分利用网络容量，排队时延（Queuing delay）最小。这两个目标任意一个都容易实现，但同时实现两者就很难。发送数据的速度比网络处理能力的还高将实现高吞吐量，但导致在网络中的不同点形成大队列。这些队列会增加延迟，不利于实时交互程序的响应，例如远程桌面。
反过来，传输最小量的数据能减少排队时延（Queuing delay），但会影响体验的质量，因为多媒体和图形的带宽有限。对于网络的瓶颈容量（C）和往返延迟时间（RTT），最好的传输方式应该始终保持接近（但不超过）C *（RTT）字节。面临的挑战是怎样确定RemoteFX用于连接的网络等待时间和带宽。
你们中许多人可能熟悉（如下图所示）的远程桌面连接客户端选项中选择连接速度。通过选择这些选项，我们可以通过合适的选择来提高RemoteFX吞吐量（以及体验）。不幸的是，它要求客户猜测他们的连接速度，即使这样也未必已经完全准确。
WINDOWS 7 的选项
WINDOWS 8的选项
用于Windows Server 2012和Windows 8版本中的RemoteFX，我们已经添加了的RemoteFX网络自动检测功能，用来解决管道流量问题。这是远程桌面连接的默认选项，让用户很少需要猜测他们的连接速度。在连接建立后和数据实时流动时，这个功能被用来计算可用的网络流量和链路延迟。然后，这些因素被用来确定保持管道满，而且延迟最小时，所需的数据量。此外，其他RemoteFX特性还可以通过检测网络条件，来自适应变化的网络条件（例如RemoteFX的媒体流可基于网络条件决定视频的目标比特率）。
下图说明RemoteFX的网络自动检测机制改善了网络吞吐量。我们没有显示以太网情况（没有丢包），因为大多数的协议在以太网都表现良好。数据显示，以百分比计算，相对于Windows Server 2008 R2的TCP吞吐量，我们有显著改善。然而，在损耗和延迟更高时，TCP吞吐量有理论极限。我们将在下一节讨论这些限制和相关的RemoteFX功能。
UDP处理丢包
即使协议解决了填充管道问题，丢包也可能严重破坏性能。以下是两个原因的丢包是坏的：
排头阻塞（Head of Line Blocking）：因为TCP确保可靠和按顺序传递数据，丢包必须由发送方重传。当该分组被重发时，丢包后面发送的任何数据包都被卡在接收方的TCP队列中，无法传递。这种拖延被称为排头阻塞，这对广域网的响应速度危害特别大，因为失速时间（ stall time）至少是网络的1.5倍RTT。
吞吐量的损失（Loss of Throughput）：任何行为良好的网络协议都要实现拥塞控制，使得网络拥塞时，发送方会降低发送速率。不执行任何拥塞控制将导致拥塞崩溃，这时分组丢失和延迟非常高，而能用的吞吐量却很少。 TCP使用基于丢包的拥塞控制[NewReno或其他AIMD（加性增，乘性减）变种]，其假定丢包原因是网络拥塞。因此，每个数据包丢失都导致退避（backs off）（滑动窗口减少一半）。这种方法非常出色的保证了全球互联网工作正常。但是在某些固有、非拥塞丢包情况下（例如，WiFi，3G / 4G，非常高延迟的网络），会导致非常严重的吞吐量损失。丢包导致的TCP吞吐量减少宣告更高的延迟。下图说明一个50M的链路，在不同的丢包和延迟级别下，计算得到的理论最大TCP吞吐量（由Mathis的公式计算出）。如这里所示，尽管具有50 Mbps链路，损耗和延迟结合，可以减少吞吐量低至270 Kbps。
只要使用TCP，我们就得受它的规则限制：可靠，按顺序传送，每次丢包都积极退后来解决拥塞。 RemoteFX通过引入UDP解决这个限制，因为我们可以控制所有这些因素。根据数据产生者需要，这个UDP传输即可以提供可靠传输（无丢包），也可以提供尽力传输（best-effort delivery，有丢包）。例如，音频和视频流都不太在意丢包恢复，更关注降低抖动。对于这样的数据流，RemoteFX UDP使用进来传输，而不需要重传。对于其它更关注可靠的生产者，RemoteFX的UDP传输集成了可靠性语义，一些重要的改进将在下面提及。
前向纠错（Forward Error Correction，FEC）：RemoteFX的UDP传输使用前向纠错（FEC）来恢复丢失的数据包。当数据包可恢复时，传输就不需要等待数据重传，数据立即被交付，避免了线端阻塞问题。阻止线端阻塞引起的失速整体提高了响应速度。
处理吞吐量损失（Addressing Loss of Throughput）：没有严格的拥塞控制协议对网络性能非常不利，并可能影响所有的网络流量，甚至包括远程网络。因此，RemoteFX的UDP协议实施和执行行业标准的拥塞控制，它有以下好处：
补偿非拥堵相关的吞吐量损失（例如WiFi信号干扰导致的丢包）
从网络丢包事件中恢复的行为得到改进，变得更快
网络上的RemoteFX 和非RemoteFX 流量得到公平处理
因为前向纠错需要在发送的数据中增加一些冗余，在不必要时我们不会增加这种开销。因此， UDP传输是TCP传输的附加，而TCP仍用于初始连接和非交互的流量传输。 UDP用于传输交互数据，如图形，音频，视频和触摸命令。
如下图所示，UDP在整体吞吐量方面较TCP有改善。这是评估RemoteFX UDP传输性能测量矩阵的一个非常小的子集。
吞吐量仅是广域网传输优化的一部分。排队时延（Queuing delay）在整体响应中也起到同样重要的作用。下图显示了RemoteFX的UDP传输是如何能够保持时延在一个良好的范围内（小于或在100ms周围），即使在极端的广域网环境。
下图显示各类性能改进和预期影响
RemoteFX UDP传输的安全性
如上所述，RemoteFX的UDP传输显著改善了各种类型配置的广域网的性能。我们确保这些性能提升并不以安全为代价。
当用UDP进行可靠数据传输时，通过安全套接字层（SSL）实现类似TCP传输的安全性。但SSL不能用于尽力传输（best-effort delivery）模式，因为其中的一些数据可能丢失。于是我们不是发明了自定义的而不是发明了自定义的尽力传输（best-effort delivery）安全机制，而是与与Windows安全团队联手使用数据报传输层安全（DTLS），它定义在IETF RFC 6347。
RemoteFX UDP的连接性
UDP在连接性方面有许多挑战，因为它的尽力发送的特性，并且缺少一些网络配置的支持。我们采取了许多措施，以确保UDP可在大多数网络配置中可用。最显著的是让RD网关原生支持UDP（而不是像一些×××，通过TCP隧道支持）。出于安全性和易管理性，RD网关只打开一个端口（3391）用于UDP连接（类似TCP）。另外，RD会话主机服务器和RD虚拟化主机间只打开一个UDP端口（3389）（类似TCP）。
在Remote Desktop Connection的连接质量提示中也显著显示是UDP连接。
为广域网传输配置RemoteFX
我们已经提供了必要的组策略设置，以允许管理员控制RemoteFX在广域网的配置。这些策略设置位于计算机配置 - >管理模板 - > Windows组件 - >远程桌面服务 - >远程桌面会话主机 - >连接。
其中的一个策略设置允许管理员配置使用UDP和TCP传输。
另外一个规则可以配置RemoteFX 自动网络检测功能。
结论
综上所述，RemoteFX包含的传输功能适应不断变化的网络条件和丢包。虽然在无线和高延迟WAN网络中，UDP提供最佳传输性能，但我们认识到， 在现实世界的许多网络配置中，UDP连接不可能总建立成功。因此，RemoteFX针对广域网的许多改进，如RemoteFX的网络自动检测也加入TCP传输中。无法使用UDP的地方，我们动态地切换到TCP 。 UDP传输采用业界标准的加密和安全机制，也能通过本地RD网关得到最好的连接支持。结合RemoteFX自适应图形堆栈其他方面的改进，它为所有的网络提供最佳的用户体验。
The UDP transport incorporates industry standard encryption and security practices and is also natively supported through RD Gateway for best connectivity. Combined with other improvements in the RemoteFX Adaptive Graphics stack, it provides an optimal user experience for all networks.
转载于:https://blog.51cto.com/11182063/1811644
3511
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
