Web 演进：从 CGI 到 Websockets（以及它将如何帮助您更好地监控云基础设施）

在过去的几年里，websockets 已或多或少地成为所有现代 Web 应用程序中的标准组件，但这是为什么，我们又是如何走到这一步的？更重要的是，websockets 如何帮助您更有效地监控您的云基础设施？

由于本主题的技术性质，我们可能会深入探讨细节。但我会尽量保持在相对宏观的层面，并专注于为我们的云基础设施用户带来的好处。

传统的方式

在 Web 的早期，一切都是静态的。如果您需要与服务器进行交互（除了渲染静态页面之外），您必须执行某种 CGI 脚本。一个典型的例子就像是邮件列表注册。您输入您的电子邮件地址并点击“提交”，然后会看到一个处理数据的独立页面。这反过来又是一个获取输入并在服务器上进行处理的脚本。

到了 90 年代，服务器端脚本已经有了显著的发展。技术已经从执行简单任务演变为构建完全动态的页面。像 PHP 这样的编程语言，以及更先进的服务器端技术，比如 mod_perl，使得更加复杂的 Web 编程成为可能。虽然这些技术意义重大，但它们仍然是围绕着加载时生成页面的概念演变的。一旦加载完成，人们必须重新加载整个页面才能刷新内容。

随着 Web 的发展，我们进入了 AJAX/Web 2.0——2000’年代的时代，网页变得更加动态和响应迅速。您不再需要重新加载页面来更新屏幕上的内容。您需要做的只是触发一些 JavaScript 操作。许多 AJAX 页面仍然由 PHP 提供支持，但随着客户端 JavaScript 的引入，它们可以变得更加动态。

引入 AJAX

随着 AJAX 的引入，服务器和客户端之间的持续通信变得越来越重要。您可能会突然发现，在给定的页面上，单个用户生成了大量的 API 调用。我们以“拉取”的方式进行此操作，这意味着客户端以给定的时间间隔（或基于某些操作）向服务器请求更新。

当我们进入 2010’年代时，网页完全分为前端（HTML/JavaScript/CSS）和后端（Ruby on Rails, Django 等）是很常见的，它们通常托管在不同的服务器上。前端与后端的通信方式是通过 API。前端或多或少是静态的。随着这一趋势，向服务器发起 API 调用成为了一个重大的瓶颈。如果您必须从服务器获取十个不同的内容，这通常意味着您需要进行十次不同的 API 调用，每次调用都会带来显著的开销和延迟。

现代方式

为了解决延迟和开销的问题，websockets 作为 HTML5 的一部分被引入，并在所有现代浏览器中得以实现。与传统的“拉取”方法（即客户端向服务器请求更改）相反，顾名思义，websocket 是一个套接字（socket），服务器可以通过它向客户端“推送”更改。因此，如果没有更改，就无需进行任何通信。此外，由于客户端可以直接与服务器通信，而无需增加打开和关闭连接的额外开销，应用程序变得更加响应迅速。

这正是我们自己的 web application 的构建方式。实际的应用程序是一个静态页面，它向 API 打开一个 websocket 连接。一旦这个套接字打开，Web 应用程序就可以从服务器接收包含更改的通知。我们仍然向 RESTful API 发送命令，但我们使用 websocket 将通知从服务器推送给客户端。

不仅适用于网页

虽然使用 websocket 接收更新最显而易见的场景是通过浏览器，但也有其他情况。也许您正在编写一个工具来监控架构的变化，并以此触发操作。在这种情况下，通过利用我们的 websocket，您可以显著加快应用程序的速度。

在我们的 Python Library pycloudsigma 中，我们内置了对 websockets 的支持。我们甚至有一个简单的 example ，说明如何只需几行代码即可利用它来监控 websocket 活动。以下是 monitor_websocket_activity.py 监控 Web 应用中用户输入所触发操作的快速演示。
有关我们服务的更多信息，请查看我们的 Features.