http://nopainnogain.iteye.com/blog/832017
http://blog.csdn.net/realxie/article/details/7270119
http://zoomq.qiniudn.com/ZQScrapBook/ZqSKM/data/20100325150259/index.html
個人理解：TCP是天生的長連接協(xié)議，主要看其上的協(xié)議
TCP連接一旦建立連接，通信雙方就可以相互發(fā)送信息，可以看做是長連接
雖然http也是基于TCP的，但是其在通訊結(jié)束之后，瀏覽器就主動斷開連接，所以看起來是 request-response的形式
poll方式
poll方式，也稱為輪循，是大家都比較熟悉的一種數(shù)據(jù)同步方式，客戶端定期去ping查詢服務(wù)器，確定是否有需要的數(shù)據(jù)。例如，軟件更新模塊，客戶端軟件需要定期去查詢官方網(wǎng)站，判斷當(dāng)前是否有更新的版本，如果有就提醒用戶進(jìn)行升級。郵件客戶端，需要定期查詢郵件服務(wù)器，查詢是否有新的郵件。RSS閱讀器，也是需要不斷的查詢rss地址的狀態(tài)，如果有更新，就將數(shù)據(jù)拿回來。
當(dāng)服務(wù)器沒有數(shù)據(jù)的時候，poll方式會浪費大量的帶寬。 為了降低帶寬，通常是采用減低poll的頻率來實現(xiàn)的，這就導(dǎo)致了消息的長延遲，實時性不高。像gmail的POP3郵件檢查間隔從10分鐘到1小時不等。
push方式
poll的問題在于很多情況下，通信信道是單向的。為了解決poll的問題，可以將通信信道設(shè)計為雙向的，這樣就可以服務(wù)器采用push的方式主動向客戶端進(jìn)行數(shù)據(jù)同步了。雙向通信信道設(shè)計，考慮到要穿透NAT和防火墻，很多實現(xiàn)采用長連接。例如各種IM的實現(xiàn)：MSN是TCP的長連接，QQ是UDP模仿的長連接，GTALK是HTTP模仿的長鏈接。
push方式，服務(wù)器主動向客戶端推送數(shù)據(jù)。當(dāng)前實現(xiàn)push方式有兩種方法：
1. 客戶端首先連接到服務(wù)器，并維持長連接
2. 服務(wù)器能夠直接訪問到客戶端，不需要長連接
在國內(nèi)NAT和firewall遍地都是的情況下，第2種方法不是很可行，但是對于一些企業(yè)應(yīng)用，這種方法還是不錯的，比如后面提到的pubsubhubbub。
但是push方式，通常需要長連接，對于服務(wù)器端其實也是一個不小的壓力，雖然現(xiàn)在C10K問題得到了比較好的解決，但是對于一些大規(guī)?；ヂ?lián)網(wǎng)應(yīng)用來講，用戶數(shù)是數(shù)以億計的，單單是維持TCP連接，就需要太多的服務(wù)器。因此，除了一些實時性要求比較高的應(yīng)用，現(xiàn)在push方式使用的范圍還不是很廣，例如push方式在IM、服務(wù)器監(jiān)控等領(lǐng)域都有應(yīng)用。
下面選取這兩天看的兩個東東，來理解一下poll和Push。
XMPP
xmpp類似于email系統(tǒng)，將一個消息從一個JID送達(dá)到另一個JID。xmpp通常被用作im，那么它是如何實現(xiàn)實時消息傳送的呢。我們接下來討論的BOSH技術(shù)就是解決這個問題的。BOSH也就是Bidirectional-streams Over Synchronous HTTP，在HTTP上模擬長連接，gtalk就是用的這種方法。
BOSH技術(shù)能夠同時減小網(wǎng)絡(luò)帶寬和減小客戶端響應(yīng)的時間。其方案是對客戶端的請求連接管理器不給于返回直到數(shù)據(jù)已經(jīng)就緒，當(dāng)客戶端收取連接管理器返回的數(shù)據(jù)會向連接管理器發(fā)送下一個請求，于是連接管理器總是保持著一個客戶端的請求，當(dāng)服務(wù)器端數(shù)據(jù)就緒的時候，可以將數(shù)據(jù)封裝在請求的響應(yīng)包中，“推送”給客戶端。
如果雙向連接長時間沒有數(shù)據(jù)，連接管理器負(fù)責(zé)給客戶端發(fā)送一個空包，空包觸發(fā)客戶端發(fā)送新的請求，連接管理器通過這種機(jī)制判斷連接是否已經(jīng)中斷，由于BOSH不是輪詢的機(jī)制，帶寬消耗比標(biāo)準(zhǔn)的TCP連接大不了多少。
由于大多數(shù)的客戶端不支持HTTP的Pipeling（單一的連接上承載并發(fā)的請求），于是，客戶端必須從第二條HTTP連接發(fā)送消息。當(dāng)?shù)诙lHTTP連接有新的請求發(fā)送的時候，連接管理器將第一條連接中的請求返回，即便此時第一條連接中的返回的是空數(shù)據(jù)包。這樣做的原因是讓客戶端有需要的話可以發(fā)送新的請求過來?？蛻舳瓮粫r間最多只能保持兩條HTTP連接，否則的話，客戶端必須等待舊的請求處理完之后才能發(fā)送新的請求
在網(wǎng)絡(luò)經(jīng)常中斷的環(huán)境下，BOSH退化成每個數(shù)據(jù)請求一個新HTTP連接。然而，在通常情況下，網(wǎng)絡(luò)環(huán)境良好，客戶端可以使用http/1.1,這個時候，一個Session包含兩個TCP長連接，所有的請求都在這兩個長連接上傳輸?；旧先魏螘r候，客戶端通過一條連接能夠推送數(shù)據(jù)到服務(wù)器，與此同時，服務(wù)器端可以“推送”數(shù)據(jù)到客戶端。值得注意的是，這兩條長連接的角色在客戶端每發(fā)送一次請求則角色轉(zhuǎn)換一次。
盡管大多數(shù)時間可以隨時推送數(shù)據(jù)到對端，但是，如果一方剛剛推送完數(shù)據(jù)，則需要等一個網(wǎng)絡(luò)來回的時間才能推送下一個數(shù)據(jù)。
pubsubhubbub
pubsubhubbub是Google的工程師開發(fā)的一種協(xié)議，可以在ATOM和RSS更新的時候，訂閱者能實時得到更新，實現(xiàn)一種基于RSS Feed的類似Twitter的實時效果。
PubSubHubbub 協(xié)議在供稿網(wǎng)址內(nèi)容更新后，能接近即時的得到通知(通過webhook回調(diào))。sub(訂閱者)向要訂閱的RSS中指定的hub進(jìn)行注冊，hub和pub(發(fā)布者)之間通過poll和push等方式同步數(shù)據(jù)，然后hub向已經(jīng)注冊的sub推送更新后的數(shù)據(jù)。
這樣，就能夠?qū)崟r的得到RSS的更新，而且避免了sub不斷輪循pub，節(jié)省了帶寬。但是，這有一個缺點，就是hub向sub推送消息，就回到最初我們討論的兩種方法，現(xiàn)在pubsubhubbub中sub大都要求為公網(wǎng)可訪問，但是對于一些企業(yè)應(yīng)用，像google reader，這樣做還是會節(jié)省很大帶寬的。
PubSubHubbub 協(xié)議概述如下：
1. 一個供稿網(wǎng)址（ “主題” ）通過
