網路演進：從 CGI 到 Websockets（以及它將如何幫助您更好地監控雲端基礎架構）

在過去的幾年中，websockets 已或多或少成為所有現代網頁應用程式中的標準組件，但這是為什麼？我們又是如何走到這一步的？更重要的是，websockets 如何幫助您更有效地監控您的雲端基礎架構？

由於此主題的技術性質，我們有可能會深入探討細節。但我會盡量保持在相對高階的層面，並專注於對我們雲端基礎架構用戶的好處。

傳統的做法

在網頁發展的早期，一切都是靜態的。如果您需要與伺服器互動（除了渲染靜態頁面之外），您必須執行某種 CGI 腳本。一個典型的例子就像是電子報訂閱。您輸入您的電子郵件地址並按下「提交」，然後會看到一個處理該資料的獨立頁面。這反過來又是一個接收輸入並在伺服器上進行處理的腳本。

到了 90 年代，伺服器端腳本技術已有了顯著的發展。技術已從執行簡單任務演變為構建完全動態的頁面。像 PHP，以及更先進的伺服器端技術，例如 mod_perl，實現了更複雜的網頁程式設計。雖然這些技術非常重要，但它們仍然圍繞著「載入時生成頁面」的概念發展。一旦載入，使用者就必須重新整理整個頁面才能更新內容。

隨著網頁的發展，我們進入了 AJAX/Web 2.0—’00 年代的時代，網頁變得更加動態且響應迅速。您不再需要重新載入頁面來更新螢幕上的內容。您只需要觸發一些 JavaScript 操作即可。許多 AJAX 頁面仍然由 PHP 驅動，但隨著用戶端 JavaScript 的引入，可以變得更加動態。

引入 AJAX

隨著 AJAX 的引入，伺服器與用戶端之間持續進行通訊變得越來越重要。您可能會突然發現，特定頁面上的單個用戶產生了大量的 API 呼叫。我們以「拉取」的方式進行此操作，這意味著用戶端會以特定的時間間隔（或基於某些操作）向伺服器請求更新。

當我們進入 ’10 年代時，網頁完全劃分為前端（HTML/JavaScript/CSS）和後端（Ruby on Rails, Django 等）已是司空見慣，而這些後端通常託管在不同的伺服器上。前端與後端通訊的方式是透過 API。前端或多或少是靜態的。隨著這種趨勢，向伺服器發送 API 呼叫成為了一個顯著的瓶頸。如果您必須從伺服器獲取十個不同的內容，這通常意味著您需要進行十次不同的 API 呼叫，每次呼叫都會帶來顯著的額外開銷和延遲。

現代的方法

為了解決延遲和額外開銷的問題，websockets 作為 HTML5 的一部分被引入，並在所有現代瀏覽器中得到實現。與傳統的「拉取」方法（即用戶端向伺服器請求變更）相反，顧名思義，websocket 是一個通訊端，伺服器可以透過它向用戶端「推送」變更。因此，如果沒有變更，就完全不需要任何通訊。此外，由於用戶端可以直接與伺服器通訊，而無需增加開啟和關閉連線的額外開銷，應用程式變得更加即時響應。

這正是我們自己的 web application 的構建方式。實際的應用程式是一個靜態頁面，它會向 API 開啟一個 websocket 連線。一旦此通訊端開啟，網頁應用程式就可以接收來自伺服器的變更通知。我們仍然向 RESTful API 發送指令，但我們使用 websocket 將通知從伺服器推送給用戶端。

不僅僅適用於網頁

雖然使用 websocket 接收更新最顯而易見的案例是透過瀏覽器，但也有其他情況。也許您正在編寫一個工具來監控架構的變更，並以此觸發對應的操作。在這種情況下，您可以透過利用我們的 websocket 來顯著提高應用程式的速度。

在我們的 Python 函式庫 pycloudsigma 中，我們內建了對 websocket 的支援。我們甚至有一個簡單的 範例，說明如何僅用幾行程式碼利用此功能來監控 websocket 活動。以下是 monitor_websocket_activity.py 監控 Web 應用程式中由使用者輸入所觸發之操作的快速示範。
如需更多關於我們服務的資訊，請查看我們的 功能.