對於 dApp 通知，WebSockets 可以更高 Web3 因為它們允許針對單個請求持續發出關鍵事件的實時通知。
對於 HTTP，每個連接在客戶端發出請求時開始，並在請求得到滿足時終止連接。
WebSocket 是一種雙向通信協議，允許客戶端和服務器之間進行交互式通信會話 。 它基於 TCP，通常用於需要實時通知功能的應用程序和服務。
WebSocket 服務器是一個在 TCP 端口上偵聽的應用程序，遵循特定的協議。 WebSocket 是客戶端和服務器之間的雙向通信協議，允許客戶端和服務器相互請求和發送數據。
相比之下，HTTP 是一種單向通信協議，客戶端只能向服務器發送請求，服務器只能發送響應數據，HTTP 關係中的服務器永遠不能向客戶端請求。
WebSocket 連接是客戶端和服務器之間的持續連接，而 HTTP 連接只是一次性的。 連接以客戶端向服務器發出的每個請求開始，並以服務器的響應結束。 只要客戶端和服務器希望它們打開，WebSocket 連接就可以保持，這意味著只要雙方願意，數據就可以通過該 WebSocket 流動，所有這一切都來自初始請求。
WebSocket 使用 WS 協議，該協議基於傳輸控制協議 (TCP) 。 它是一個面向連接的網絡，這意味著必須首先在參與者之間建立連接，以便將數據路由到正確的位置。
相反，互聯網協議根據數據包中的信息確定數據發送到哪裡； 無需事先配置即可路由數據包。
服務器有兩種方式向客戶端發送數據。 客戶端可以定期向服務器請求數據，稱為 輪詢 ，或者服務器可以自動發送數據給客戶端，稱為 服務器推送 .
WebSocket API 通過在初始請求使用服務器推送技術後保持打開狀態來利用客戶端和服務器之間的連接，從而消除客戶端不斷輪詢服務器以獲取新更新所產生的基礎設施壓力。
WebSocket 是一種雙向通信方法，允許單個服務器請求進行多個響應。 WebSocket 也主要用於客戶端-服務器通信，而 webhooks 主要用於服務器-服務器通信。
與 WebSocket 不同， 網絡鉤子 使用 HTTP 的協議是嚴格單向的：服務器僅在發出請求時才響應應用程序，每次請求得到滿足時，連接就會斷開。
使用 WebSocket 或 Webhook 之間的權衡來自於這樣一個事實：與來自客戶端的許多 Webhook 連接請求相比，基礎設施設計可以更好地處理許多同時打開的 WebSocket 連接。
如果您的服務器應用程序作為雲函數（AWS Lambda、Google Cloud Functions 等）運行，請使用 Webhooks，因為應用程序不會保持 WebSocket 連接打開。
如果發送的通知量較低，則 Webhooks 也會較高，因為僅在事件發生的情況下才會啟動連接。
如果事件很少發生，最好使用 Webhook，而不是在客戶端和服務器之間保持許多 WebSocket 連接打開。
最後，無論您是嘗試將服務器與另一台服務器連接還是客戶端與服務器連接也很重要； webhooks 更適合前者，websocket 更適合後者。
對於許多 Web3 dApp 來說，必須實時更新用戶的交易狀態。 如果沒有，他們可能會獲得糟糕的用戶體驗並離開您的應用或服務。
只要延遲需要盡可能低，就應該在 HTTP 請求上使用 WebSocket。 通過這樣做，我們可以讓用戶在事件發生時立即收到有關事件的通知。 HTTP 相對要慢得多，因為客戶端發送請求的頻率限制了獲取更新的頻率。
BlogInnovazione.it
