NX 的到来，第 3 部分
这是由 FreeNX 开发团队成员 Kurt Pfeifle 撰写的七部分系列文章的第三篇，内容关于他参与 NX 技术。在此过程中，他基本介绍了 NX 和 FreeNX 的内部工作原理，同时概述了其未来的发展蓝图。Kurt 在这里描述的大部分内容都可以使用一两张最新的 Knoppix CD（3.6 或更高版本）进行重现和验证。Knoppix 已经包含可用的 FreeNX 服务器设置和 NoMachine NX 客户端一年多了。作为参考，您可能需要回顾第 1 部分“我是如何认识 NX 的”和第 2 部分“X 的工作原理”。
以下是一些您可以使用 NX 运行的测试。尝试使用您的手机内置的 GSM 调制解调器连接到网络。我在这里不深入探讨如何在 Linux 上执行此操作的技术细节。ssh进入您可以访问的任何联网的 Linux 或 UNIX 计算机。启动 Mozilla——您可以执行ssh -X -C username@remotehost mozilla来执行此操作。等待。再等等。再等等。去煮一杯咖啡。慢慢享用。回到您的显示器前。六分钟过去了。再等一会儿。七分零六秒后，Mozilla 启动页和用户界面完成并在其全部荣耀中显示出来。您希望任何人使用这样的链接来处理本地显示的远程应用程序吗？如果您神志清醒，就不会。毕竟，GSM 调制解调器仅为您提供 9,600 位/秒的链接速度。
现在，尝试通过 NX 驱动的 GSM 调制解调器链接进行相同的连接。我使用了商业 NoMachine 软件提供的免费 NX 客户端 来测试这一点。再次启动 Mozilla。但是，这一次，不要走开——Mozilla 在更短的时间跨度后启动并运行。啊，您忘了测量它？好吧，再做一次。第二次，Mozilla 准备就绪仅需 20 秒的延迟。您仍然使用相同的物理 9,600 位/秒 GSM 调制解调器链接，但这次您使用的是 NX-over-GSM 而不是 X-over-GSM。您甚至现在可以使用它做一些工作。是的，它仍然很慢，但它是可用的。它肯定比我在现实生活中看到的许多 TightVNC 连接感觉更快。而且相当多的人每天都在使用 TightVNC 工作。我不建议每天使用 VNC，但在看到人们使用它工作后，我敢说，“NX 甚至可以通过 9.6 kBits/秒的 GSM 调制解调器链接使用”。但是，对于实际工作，我建议至少保证 40 kBits/秒的链接。这足以让 NX 工作得很好。稍后会详细介绍。
您已经知道 NX 结合了哪些技术来涡轮增压其令人难以置信的性能
压缩通常会是 X 流量的内容
缓存服务器和客户端之间传输的数据
减少 X 客户端和 X 服务器之间的所有 X 请求 <--> X 响应往返
让我们更详细地了解这些机制中的每一个。
那么，NX 压缩对整体性能有多重要？它比 ZLIB 更好吗？
这是一个挑战。尝试验证我所说的话
使用“慢速”远程链接，例如拨号调制解调器。或者，使用这些流量整形工具之一模拟慢速链接：trickle、tc 或 tcng。
首先，禁用 NX 自身的压缩运行远程 NX 会话。相反，启用 SSH 内置的基于 ZLIB 的压缩。您可以从 NX 文档和源代码包提供的 xscripts 中学习如何执行此操作。这样，您可以享受 NX 往返抑制技术的全部优点，同时分离出 NX 自身的内置压缩以改用通用 ZLIB 压缩。连接仍然感觉缓慢而迟缓，因为 SSH 压缩还不够好。您也可以在 NoMachine NX 客户端中简单地禁用所有压缩，方法是将滑块从“调制解调器”位置拉到“局域网”位置并重新运行测试。“局域网”设置禁用所有 NX 压缩。因此，此设置仍然使用缓存和往返抑制，但放弃了所有压缩。
最后，运行完整的 NX 会话。使用“调制解调器”压缩滑块设置，从而为您的桌面背景壁纸接受一些有损 JPEG 压缩。然后，NX 使用其自身的 uniq 压缩算法。差异立即显现。它比您在“远程 X 世界”中见过的任何东西都快。
因为 NX 通过 nxproxy 是一种专门的压缩器——经过优化以压缩 X 协议流量——它可以比通用压缩算法做得更好。作为一个粗略的数字，对于 X 协议网络流量，NX 使用的 CPU 消耗是 ZLIB 压缩的 10%，同时实现了比 ZLIB 压缩高 10 倍的压缩率。
图 1. 远程 xterm，实际上在 Knoppix 盒子的其他地方运行，在 Windows XP Professional 工作站上可见。连接是使用 NX 建立的。
您可以以不同的压缩级别运行 NX；较高的压缩设置会消耗更多的 CPU。因此，最高的压缩设置可能不适用于旧硬件。对于 i486 或 Pentium I 或 II 处理器，压缩计算可能会占用过多的 CPU 周期，使处理器成为比慢速 TCP/IP 链接更大的瓶颈。但在 Pentium III 上，与普通的远程 X 相比，NX 可以为典型的桌面远程会话提供高达 70 倍的整体效率提升。我的典型会话包括在 KDE 上执行办公效率任务：邮件、文字处理、互联网浏览。有关验证此方法的方式，请参见下文。
与 NX 压缩密切相关的是 NX 缓存。在我看来，NX 的缓存设计是一件创新的工程艺术品。考虑到它运行良好，我想知道为什么如此少的开源杰出人士注意到它。那么，NX 整体效率的关键是什么？
“显然，缓存本身并不是什么新鲜事。但 NX 识别‘增量’的方式非常原始。它还需要大量关于 X 协议的状态信息。” 这是 Gian Filippo Pinzari 在我们的电子邮件采访中试图向我解释 NX 缓存的方式。
我不得不回复，“抱歉，我没有完全理解。您能否在这里详细说明一下？”
Pinzari 回复说：“如果 NX 只逐位查看 X 消息，就像大多数其他缓存算法所做的那样，它几乎无法缓存其中的许多消息。在 99.99% 的情况下，X 消息在位级别上是不同的。”
“那么您在 NX 中做什么？”，我问道。
他说
NX 将消息分成两部分，一个标识部分和一个数据部分。标识部分很可能不同。这作为增量传输。数据部分可以很容易地与同一类型的先前消息的数据部分匹配。这部分只是作为引用传输。引用要小得多。它让链接另一端的远程对等方从其本地缓存中获取匹配的数据部分。
“啊，我明白了”，我回复道。“但我不是在 DXPC 的文档中读到过类似的东西吗？差分 X 协议压缩器 (DXPC) 不是已经使用了这个想法吗？”
“是的”，Pinzari 回答说，“使用每消息差分算法发送 X 更新的想法已经存在于旧的 DXPC 中。但是将 X 消息拆分为‘指纹’和‘数据’部分，并将数据部分作为一个整体缓存的想法是全新的。据我所知，它不存在于我所知道的任何压缩算法中。这就是实现 NX 巨大压缩提升的原因。”
数据缓存，尤其是像素图，会产生一个受欢迎的效果：您的 NX 会话会随着时间的推移而变得更快。最初，会话可能会感觉有点慢。但持续时间越长，先前传输的元素被重用的机会就越高。它在图标、字体和小部件元素（例如按钮、滑块和菜单栏）上尤其有效，这些元素在许多程序界面中都很常见。
我的下一个问题是，“与对完整 X 消息进行逐位比较时 99.99% 的‘未命中’相比，您使用您的方法实现了什么样的命中率？”
Pinzari 回答说
多年来，我们通过对近 160 个 X 消息操作码中的每一个应用修改后的编码来微调我们的方法。我们现在处于跨线传输的 X 消息总样本的 60% 到 80% 的缓存命中率范围内。对于某些消息，例如图形请求、图像、字体、图标和常用办公自动化桌面应用程序中使用的其他请求，缓存命中率可以达到 100%，从而使 NX 能够实现 1000:1 数量级的有效压缩比。
“所有这些计算和运算不是很耗时且 CPU 密集型吗？”，我问道。
“实际上，不是”，Pinzari 回复说。“我们比通用 ZLIB 具有更好得多的整体压缩率，同时比 ZLIB 消耗的 CPU 周期少得多。”
“所以这个总体思路仅适用于 X 消息交换？”，我问道。
“不！值得注意的是，它可以应用于许多其他协议。事实上，我计划将来将其应用于 HTTP。”
NX/X 协议压缩技术已在 NoMachine 网站上公开文档化以供公众和同行评审。它没有专利限制。它是自由软件。它是 GPL。因此，开源开发人员，去使用它吧！
图 2. 此处使用远程 xterm 启动了 The GIMP 的远程实例。这是 Windows 用户轻松且廉价地访问在其他平台（例如 GNU/Linux）上运行的应用程序的一种方式。在这种情况下，Windows Server CAL 以及 Photoshop 许可证变得多余。
之前，我们问过，“往返消除有多重要？” 现在您了解了 X 如何在网络上工作的基本知识，对于不必要的往返不容忍的重要性对您来说显而易见。您现在应该意识到任何链接（尤其是慢速链接）的延迟在使远程连接感觉更慢方面有多大的影响，每次发生的额外往返都会使远程连接感觉更慢。每次节省的往返都会稍微提高 GUI 响应速度。
还记得上面描述的实验吗，即在 9,600 波特链接上运行 Mozilla 的实验？使用普通的旧 X，系统需要等待七分钟才能完成绘制带有启动页面的窗口。这是因为 Mozilla 1.1 需要近 6,000 次往返才能完成其启动。
使用 NX，启动时间缩短至 20 秒，比率为 21:1。在这种情况下，真正的速度提升来自于 NX 将 Mozilla 启动的往返次数减少到十几次以下。
NX 知道它在每个连接和每个数据包中传输的流量类型。NX 根据传输的协议使用不同的算法压缩流。它还“仲裁”带宽，以便交互式流量获得更高的优先级。这对于 X11 尤其有利，X11 本身会受到高网络延迟条件的影响。如果需要传输 128KB 的大图像，那么在慢速链接上，这可能需要 30 多秒。通常，在这整个 30 秒的时间段内，用户界面将被阻止且无响应，直到下载完成。
但这在 NX 中并非如此。NX 不会一次性流式传输 128KB 图像，而是以不同的较小块流式传输。部件之间的空间用于传输任何排队的 X 消息，这些消息是保持 GUI 处于交互状态所必需的。因此，用户感知的延迟大大减少。
本系列文章的第 4 部分将更详细地描述 NX 的各种组件以及它们如何为支持的不同会话类型（UNIX/X11、Windows/RDP 和 all/VNC）工作。
要了解有关 FreeNX 的更多信息，并亲眼目睹远程文档创建、打印和发布的真实工作流程演示，请访问 Linuxprinting.org 在 2005 年 8 月 8 日至 11 日在旧金山举行的 LinuxWorld Conference & Expo 上的展位（#2043）。我将与合作项目的其他成员一起在那里。
Kurt Pfeifle 是一位系统专家，也是德国斯图加特的 Danka Deutschland GmbH 咨询和培训网络打印组的技术主管。Kurt 在全球开源和自由软件社区中被誉为热情的 CUPS 推广者；他对 CUPS 的兴趣可以追溯到 1999 年 6 月的第一个 Beta 版本。他是 KDEPrint 手册的作者，并为 KDEPrint 网站 做出贡献。Kurt 还处理 Linuxprinting.org 的一系列事务，并为 Samba 项目编写了大部分打印文档。
