基於瀏覽器的聊天需要特殊技術？

Question

在this post上，我瞭解了XMPP的用法。這樣的事情是必需的，更重要的是，我的主要問題擴展了：只能使用標準的HTTP和瀏覽器技術（例如PHP和JS，或RoR和JS等）有效地構建聊天服務器和客戶端嗎？或者，最好是堅持使用像XMPP這樣的舊協議，找到一種方法將它們與我的應用程序集成？

我通過LiveHTTPHeaders和Firebug查看了CampFire大約5分鐘，它似乎使用Ajax發送一個請求，這個請求在另一個聊天發生之前是不會回答的。這只是CampFire在服務器上打開一個新線程來偵聽更新，然後在線程聽到更新時返回對請求的響應？我注意到他們正在請求一個特定的端口（8043，如果內存服務於我），這讓我覺得他們正在做的事情比我剛纔提到的要複雜得多。此外，請求的網址以/tcp/開頭，我發現它很有趣。

說明：我不希望在同一時間內所有房間中有超過150名用戶在現場聊天。據我所知，如果我正在爲成千上萬的併發用戶構建像CampFire這樣的聊天服務的託管支付服務，那麼我應該投入時間研究特殊技術，並嘗試以簡單的方式在我的應用中重新發明輪子。另外，如果你打算用服務器輪詢來做，你會不會經常砰地一聲調查，以最大限度地提高響應，而不會耽誤服務器？

Answer 1

這項技術被廣泛地稱爲Comet，據推測，這是一種在Ajax上有些搞笑的雙關語。

XmlHTTPResponse變體似乎是最流行的。

XHR版本本身並不嚴格輪詢;正如你所說的那樣，客戶端連接一個很長的超時時間，並且服務器實際上並沒有發送響應，直到有什麼要發送。一旦發送響應，它就會斷開連接並重新連接客戶端。他們稱之爲長輪詢，因爲客戶端正在啓動連接，但它與經典輪詢的不同之處在於，即使沒有任何變化，客戶端也不會始終連接請求新內容（即沒有「現在是否有消息？不？大約現在呢？現在呢？「）

這更像是試圖保持不斷下降的連接。

是的，它絕對可以使用標準的網絡技術。

---

我更願意認爲阿賈克斯作爲一個強大的希臘勇士，而不是清潔產品，所以我皺眉大大感動這個雙關語。

Answer 2

這將首先取決於您的Web服務器負載平衡策略。通過無狀態介質（HTTP）發佈數據的150個併發用戶在腳本（客戶端和服務器端）方面肯定是有效的。請記住，聊天應用程序只是許多客戶端 - >一個服務器策略，完全適合網絡。