你目前正处于脱机状态,正在等待 Internet 重新连接

修复: 如果 Forefront 统一访问网关 2010 年前发布某些已发布的 web 应用程序查看已发布的 web 服务器与客户端之间降低的网络吞吐量

注意:这篇文章是由无人工介入的微软自动的机器翻译软件翻译完成。微软很高兴能同时提供给您由人工翻译的和由机器翻译的文章, 以使您能使用您的语言访问所有的知识库文章。然而由机器翻译的文章并不总是完美的。它可能存在词汇,语法或文法的问题,就像是一个外国人在说中文时总是可能犯这样的错误。虽然我们经常升级机器翻译软件以提高翻译质量,但是我们不保证机器翻译的正确度,也不对由于内容的误译或者客户对它的错误使用所引起的任何直接的, 或间接的可能的问题负责。

点击这里察看该文章的英文版: 2811128
症状
一些已发布的 web 应用程序将应用程序发布到 Microsoft 最前沿统一访问网关 (UAG) 2010年降低的网络吞吐量已发布的 web 服务器与客户端之间。该吞吐量较小较经历由直接访问 web 服务器的客户端的吞吐量。

此问题通常发生在大型 Outlook 无处邮件发送出版物或 SharePoint 文件将上载到 Forefront UAG 2010 服务器。但是,此问题会影响所有客户端和发布的服务器之间的数据传输。
原因
因为 Nagle 算法不到已发布的 web 服务器的网络连接禁用 Microsoft 最前沿统一访问网关 2010 Service Pack 2 和早期版本中发生此问题。

根据网络拓扑结构和模式的客户端发送的数据包,Nagle 算法可能会导致减少了的数据吞吐量。这是因为 Nagle 算法 Forefront uag,使服务器和发布服务器上的延迟的确认计时器 (也称为延迟 ACK 计时器) 可能会导致很多 200 毫秒的延迟。这些延迟发生,原因如下:
  • Nagle 算法让未完成网络连接上的只有一个小型 (非全部) TCP 数据包。
  • 延迟的 ACK 计时器允许 Windows 确认仅每一其他 TCP 数据包,或者仅在 200 毫秒后确认单个数据包。

如果一个 TCP 连接上的待处理小的 TCP 数据包,Nagle 算法可防止发送更多数据包 Forefront UAG。这会导致延迟,因为已发布的 web 服务器将等待 200 毫秒,承认未完成数据包。许多 200 毫秒延迟的累积后果可能会导致降低的吞吐量。
解决方案
要解决此问题,请安装以下 Microsoft 知识库文章中介绍的服务包:

2744025 说明最前沿的统一访问网关 2010年服务包 3
应用此服务包后,则 Forefront UAG 2010 禁用 Nagle 算法上创建已发布的 web 服务器套接字。此更改是为了避免"原因"一节中描述的延迟。
替代方法
若要变通解决此问题,请将设置 TcpAckFrequency 对价值 1在已发布的 web 服务器上。此设置导致 TCP 堆栈上已发布的 web 服务器发送每个数据包的 ACK。此设置还允许忽略的延迟的 ACK 计时器的系统。

有关TcpAckFrequency值的详细信息,请转到以下 Microsoft 开发人员网络 (MSDN) 网站:


状态
Microsoft 已经确认这是在"适用于"一节中列出的 Microsoft 产品中的问题。
参考
Nagle 算法有关的详细信息,请转到下面的网站:

TcpAckFrequency 注册表值的更多信息,请单击下面的文章编号,以转到 Microsoft 知识库中相应的文章:

328890 用于控制 Windows Server 2003 和 Windows XP 中的 TCP 确认 (ACK) 行为的新注册表项
有关软件更新术语的详细信息,请单击下面的文章编号,以转到 Microsoft 知识库中相应的文章:
824684 用于描述 Microsoft 软件更新的标准术语的说明

警告:本文已自动翻译

属性

文章 ID:2811128 - 上次审阅时间:02/20/2013 17:40:00 - 修订版本: 1.0

Microsoft Forefront Unified Access Gateway 2010, Microsoft Forefront Unified Access Gateway 2010 Service Pack 1, Microsoft Forefront Unified Access Gateway 2010 Service Pack 2

  • kbqfe kbfix kbexpertiseinter kbsurveynew kbbug kbmt KB2811128 KbMtzh
反馈