AJAX是否推送HTTP協議畸變？

Question

在面向Web的應用程序中開發優雅的Pub-Sub架構是一個真正的挑戰。 儘管使用長輪詢連接（例如COMET）和重複超時（例如js setTimeout）有一些非常有趣的解決方案。恕我直言，AJAX推動仍然看起來像一層調整和黑客迫使無辜的HTTP協議。

那麼你覺得怎麼樣AJAX推送HTTP協議畸變？

您可以在Web架構中考慮哪些其他選擇？

Answer 1

我以前見過的另一個選擇是使用一個隱藏的小型Java或Flash通過普通套接字連接到遠程服務器。然後，服務器可以隨時在這些套接字上推送數據/事件，而無需從客戶端進行任何輪詢。

Flash是一個稍微好一點的IMO，因爲它不需要簽名的applet（彈出用戶的安全警告）。它有一種或另一種形式的套接字，現在已經有9年了，雖然直到Flash 9/AS3纔有了可以用來連接到任何類型服務的「純」套接字（以前它要求消息是以'零'數據包終止，這意味着您必須專門爲Flash設計協議，而不是使用XMPP或SMTP或任何現有協議）

Answer 2

哪些其他的替代品，你可以 在網絡架構考慮？

HTML 5 Web Sockets API和Server-sent Events看起來很有希望。目前還沒有IE支持Web Sockets，而服務器發送的事件仍然是試驗性的。道格拉斯克羅克福德的JSONRequest提案也將成爲AJAX推送的一個有趣替代方案，但它尚未在現代瀏覽器中實現。我想堅持Comet。

Answer 3

輪詢是做pub-sub的網絡架構方式。如果客戶不頻繁地進行輪詢並且可以緩存和共享響應（例如，博客的rss訂閱源），那麼它就可以很好地工作。保持每個客戶端打開一個tcp套接字，就像彗星一樣，不是使用http的理想方式。但是，如果您的應用程序在Web瀏覽器中運行，並且需要頻繁，唯一的每個客戶端更新，那麼這不是一個糟糕的方法。

針對每個客戶端資源的彗星和輪詢並不完全濫用http或web - 只是http和web被設計爲特別在許多客戶端之間共享相同的資源（即網頁），所以這就是它的效果最好。

Answer 4

想想最常見的Comet實現，只是你必須愚弄瀏覽器認爲它在iframe中接收多部分響應或無限長的html足以引發這是否是適合的技術或不適合這項工作。