什麼是 WebSocket，運作原理為何

WebSocket 是一種基於 TCP 的雙向通訊協定，將客戶端與伺服器之間的通訊標準化，讓雙方都能向對方請求資料。相較之下，像 HTTP 這種單向協定只允許客戶端向伺服器請求資料。

客戶端與伺服器之間的 WebSocket 連線，只要雙方希望維持連線，就能一直保持開啟，讓通訊得以持續進行。

而在 HTTP 中，每次連線都是從客戶端發出請求時開始，並在請求完成後結束連線。

WebSocket 可能更適合用於 Web3 dApp 通知，因為它能針對關鍵事件持續提供即時通知，不需要個別發出請求。像 Alchemy Notify 這類工具，能讓你輕鬆為錢包和應用程式加入即時通知功能。

什麼是 WebSocket？

WebSocket 是一種雙向通訊協定，能在客戶端與伺服器之間建立互動式的通訊連線階段。它以 TCP 為基礎，經常用於需要即時通知功能的應用程式和服務。

什麼是 WebSocket 伺服器？

WebSocket 伺服器是一種監聽 TCP 連接埠、並遵循特定協定的應用程式。 WebSocket 是客戶端與伺服器之間的雙向通訊協定，讓雙方都能互相請求並傳送資料。

相較之下，HTTP 是單向通訊協定，客戶端只能向伺服器發出請求，伺服器也只能回應資料——在 HTTP 的關係中，伺服器永遠不能向客戶端發出請求。

什麼是 WebSocket 連線？

WebSocket 連線是客戶端與伺服器之間持續存在的連線。相較之下，HTTP 連線只是一次性的。連線會在客戶端每次向伺服器發出請求時開始，並在伺服器回應後結束。WebSocket 連線可以在客戶端與伺服器雙方都希望維持開啟的情況下持續保持，意味著只要雙方願意，資料就能透過該 WebSocket 持續傳輸——而這一切都始於最初的一次請求。

WebSocket 使用什麼協定？

WebSocket 使用 WS 協定，該協定基於傳輸控制協定（Transmission Control Protocol，TCP）。這是一種以連線為導向的網路，意味著必須先在參與者之間建立連線，才能將資料傳送到正確的位置。

相較之下，網際網路協定（Internet Protocol）是根據資料封包內的資訊來決定資料要傳送到哪裡；不需要事先建立連線就能傳送封包。

什麼是 WebSocket API？

伺服器有兩種方式可以將資料傳送給客戶端。客戶端可以定期向伺服器請求資料，這稱為輪詢（polling）；或者伺服器可以主動將資料傳送給客戶端，這稱為伺服器推播（server push）。

WebSocket API 善用客戶端與伺服器之間的連線，在初始請求後保持連線開啟，採用伺服器推播的方式，消除客戶端不斷輪詢伺服器以取得最新資訊所造成的基礎架構負擔。

WebSocket 如何運作？

WebSocket 是一種雙向通訊方式，讓單一伺服器請求可以得到多次回應。WebSocket 大多用於客戶端與伺服器之間的通訊，而 webhook 則大多用於伺服器與伺服器之間的通訊。

WebSocket 與 webhook 的運作方式有何不同？

相較於 WebSocket，使用 HTTP 的 webhook 是嚴格的單向通訊：伺服器只有在收到請求時才會回應應用程式，而且每次請求完成後，連線就會終止。

Alchemy Notify 使用 webhook 來進行伺服器之間的通訊，並使用 WebSocket 將通知推播給 dApp 使用者。

Web3 WebSocket 有哪些用途？

Alchemy 的 Subscription API 提供兩個新的 API 方法，擴充了原本 Ethereum API 的功能——eth_subscribe 和 eth_unsubscribe——讓 Web3 開發者能利用 WebSocket 持續接收資訊或資料，例如取得待處理交易資訊、待處理交易雜湊值、新的區塊標頭，以及日誌。

以下是 Alchemy Subscription API 中使用 WebSocket 的支援方法：

• alchemy_newFullPendingTransactions——回傳所有新增至待處理狀態的交易的完整交易資訊（不只是交易雜湊值）
• alchemy_filteredNewFullPendingTransactions——回傳所有符合 to 或 from 位址篩選條件的待處理交易的交易資訊
• newPendingTransactions——回傳所有新增至待處理狀態的交易的雜湊值，無論是否為你所發送
• newHeads——每當有新的區塊標頭（區塊）被加入區塊鏈時，就會傳送一次事件
• logs——傳送符合指定篩選條件、屬於新加入區塊的日誌

當需要終止任何現有的 WebSocket 連線時，可以搭配訂閱 ID 參數使用 eth_unsubscribe 呼叫。

何時該使用 WebSocket，何時該使用 webhook

選擇使用 WebSocket 還是 webhook 的取捨，取決於你的基礎架構設計，是更適合同時處理大量開啟的 WebSocket 連線，還是更適合處理客戶端發出的大量 webhook 連線請求。

如果你的伺服器應用程式是以雲端函式（例如 AWS Lambda、Google Cloud Functions 等）的形式執行，請使用 webhook，因為該應用程式不會保持 WebSocket 連線開啟。

如果需要傳送的通知數量較少，webhook 也比較有優勢，因為連線只會在事件發生時才開始建立。

如果事件發生的頻率很低，比起讓客戶端與伺服器之間維持大量開啟的 WebSocket 連線，使用 webhook 會是更好的做法。

最後，你是要在伺服器與伺服器之間建立橋接，還是在客戶端與伺服器之間建立橋接，也很重要；webhook 更適合前者，WebSocket 更適合後者。我們已建立一個 用於架設 webhook 伺服器的 Github 儲存庫。

何時該使用 WebSocket 協定

對許多 Web3 應用程式來說，即時更新使用者交易狀態是必要的功能。否則，使用者可能會有不佳的體驗，進而放棄使用你的應用程式或服務。Alchemy Notify 讓使用者能確切掌握其交易的狀態，藉此解決這個問題。

何時該用 WebSocket 取代 HTTP

當延遲需要盡可能降到最低、以便使用者能在事件發生的當下立即收到通知時，就應該使用 WebSocket 而非 HTTP 請求。HTTP 相對慢得多，因為客戶端能多常收到更新，取決於它多常送出請求，這是一種限制。

WebSocket 範例

我們已建立一些指南，說明如何實作 Alchemy Notify，以應用程式內通知的方式，針對關鍵事件（例如錢包餘額變動）更新使用者狀態。以下是我們發佈的幾篇教學文章：

1. 追蹤待處理與已挖出的 Ethereum 交易
2. 打造具有即時交易通知功能的 dApp
3. 將 Alchemy webhook 與 Zapier 整合

Alchemy Notify 甚至可以用來向你的 dApp 使用者發送電子郵件通知，避免他們因不清楚交易狀態而感到困擾。