瞭解Finesse的WebSocket連線

簡介

本文檔對WebSocket連線進行了完整說明，以便在進行故障排除時能夠全面瞭解底層過程。

必要條件

需求

本文件沒有特定需求。

元件 已使用

本文中的資訊係根據以下軟體和硬體版本：

• Cisco Finesse 
• UCCX 

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

Web套接字是客戶端與伺服器之間的持久連線。

Web套接字

「持久連線」一詞是什麼意思？

這意味著一旦客戶端和伺服器之間建立連線，客戶端和伺服器就可以隨時傳送和/或接收資料。

這是雙向全雙工連線。

伺服器不必等待客戶端請求回推任何資料。

同樣，客戶端也不必每次都建立一個新連線來向伺服器傳送任何新資料。

Web Socket連線主要用於需要即時資料更新的應用。

例如，股票交易應用、報文傳送應用，以及我們的Cisco Finesse。

WebSockets如何工作？

請考慮：

HTTP

1. 發生TCP連線（三次握手）。
2. 然後使用者端傳送HTTP要求。
3. 伺服器傳送HTTP響應。
4. 在一個請求響應週期後，TCP連線關閉。
5. 同樣，對於新的HTTP請求，首先會建立TCP連線。

HTTP 1.0 — 在每次請求響應後，TCP握手會針對另一個HTTP請求響應再次啟動。

HTTP 1.1 — 此連線工作正常，因為您可以傳送和接收資料，然後關閉連線。

同樣，這也不適用於即時應用，因為伺服器可以傳送一些資料，即使客戶端沒有請求資料。因此、這種模式是無效的。

HTTP問題

問題始於即時系統。

對於一個需要即時更新的網站，每次從伺服器獲取更新都很難傳送HTTP請求，並且會佔用大量頻寬，導致過載。

為了解決這個問題，使用了一種稱為Polling的HTTP機制。

Short Poll — 在為請求和響應設定短固定計時器時實施。例如，05秒或1秒（取決於實施情況）。

如果另一端沒有更新，則在該時間範圍內您可能會收到可能會浪費資源的空響應。

長輪詢 — 它以某種方式克服了短輪投票，但仍有固定時間等待回應。

如果在比短期輪詢相對較長時間段內沒有響應但仍被固定，則再次請求超時。

因此，輪詢並不是解決此問題的最佳方法。

為此，要使用的另一種方法稱為SSE。

SSE

伺服器傳送的事件

在這種方式中，伺服器和客戶端之間有一個單向連線，伺服器可以通過該連線在任何點向客戶端傳送資料。

這裡需要注意的是，它是一個單向連線，這意味著只有伺服器才能將資料傳送到客戶端，而不是反過來。

用例的示例是：從伺服器到客戶端的批次通知或更新。例如，新聞live更新、Instagram live等。

這對於涉及即時更新和消息傳送的應用程式不太有效。

Web套接字連線是一種持久的雙向全雙工連線。

這可能是伺服器與客戶端之間的電話呼叫，其中任何一方可以隨時與另一方通話。

WebSocket操作

1. 要建立Websocket連線，客戶端將傳送帶有升級或更新的報頭的HTTP握手請求。
   1. 這表示客戶端正在對伺服器說，現在這是通過HTTP的，但是從現在開始，它將轉到Websocket連線。
2. 然後伺服器會使用HTTP 101響應進行響應，這意味著伺服器正在切換協定響應。
3. 之後，會建立Websocket連線。

現在，伺服器和客戶端可以使用該連線隨時相互傳輸資料。

WebSocket調試

此時，如果您登入到Finesse客戶端並看到網路調試，將顯示為：

方法 — GET
域 — 服務器名稱

文件 — /WS/

INITIATOR - Openfire.js - websocket

檢查請求和響應：

請求

GET

方案:wss

主機：uccxpub.prabhat.com:8445

檔名： /ws/

地址：uccx伺服器的IP

狀態:101

交換 通訊協定

版本HTTP/1.1

響應報頭

連線：升級

升級:WebSocket

          

Request – open Response PLAIN http://jabber.org/protocol/caps" hash="sha-1" node=" https://www.igniterealtime.org/projects/openfire/" ver="k3mOuil8afx3OTZxYy6yxLmFsok="/> Request - auth YWRtaW5pc3RyYXRvckB1Y2N4cHViLnByYWJoYXQuY29tAGFkbWluaXN0cmF0b3IAMTIzNA== Response Request – XMPP Bind Bind request to Bind the resource which in this case is desktop with a jabber id desktop Response – XMPP Bind where User ID is given a jabber id administrator@uccxpub.prabhat.com/desktop administrator@uccxpub.prabhat.com/desktop Presence request Presence response http://jabber.org/protocol/caps" hash="sha-1" node=" http://www.igniterealtime.org/projects/smack" ver="NfJ3flI83zSdUDzCEICtbypursw="> http://jabber.org/protocol/caps" hash="sha-1" node=" http://www.igniterealtime.org/projects/smack" ver="NfJ3flI83zSdUDzCEICtbypursw="> PUBSUB request – Requesting to subscribe the user to the pubsub node so that all the events on the user are monitored. Response – user subscribed. http://jabber.org/protocol/pubsub"> PUBSUB request – Requesting to subscribe the Team to the pubsub node so that all the events on the team are monitored. Response – Team subscribed http://jabber.org/protocol/pubsub">

相關資訊

• 思科技術支援與下載