1.Channel和Endpoint的定義
Channels are client-side objects that encapsulate the connection
behavior between Flex components and the BlazeDS server. Channels
communicate with corresponding endpoints on the BlazeDS server. You
configure the properties of a channel and its corresponding endpoint in
the services-config.xml file.
2.從數(shù)據(jù)格式上分，Channels分為AMF Channel和HTTP Channel，區(qū)別在于：
The difference between AMF and HTTP channels is that AMF channels transport data in the binary AMF format and HTTP channels transport data in AMFX, the text-based XML representation of AMF.
3.從客戶端與服務(wù)端的交互方式上分，Channels主要分為：
Simple channels and endpoints 包括：
(1) Non-polling channels
(2) Polling channels
(3) Long polling channels
Streaming channels
(1) Streaming channels
3.關(guān)于 Non-polling,Polling,Long polling和steaming的一些解釋
http://www.qgy18.com/2008/08/webim-design-transport/
http://newteevee.com/2009/10/04/adobe-to-finally-support-http-streaming/
1.短輪詢(polling)：核心思想是客戶端定時(shí)去服務(wù)器取消息。為了實(shí)現(xiàn)即時(shí)效果，輪詢的間隔必須設(shè)計(jì)得足夠短，另外為了操作的流暢，需要使用Ajax來(lái)發(fā)送請(qǐng)求。本人的QGYWebIM就是采用的此方案。這種方案的優(yōu)點(diǎn)是：后端程序編寫比較容易，發(fā)送完響應(yīng)信息馬上斷開(kāi)連接，不會(huì)占用太多服務(wù)器資源。缺點(diǎn)是一般情況下，頻繁的請(qǐng)求中有大半是無(wú)用，這些冗余請(qǐng)求無(wú)形中浪費(fèi)了帶寬和服務(wù)器資源。我們可以通過(guò)判斷用戶的活躍程度來(lái)決策請(qǐng)求服務(wù)器的間隔，我在51的一個(gè)帖子提到過(guò)這種方法，但是間隔一旦長(zhǎng)了，消息的傳送就有延時(shí)，違背了即時(shí)聊天的初衷了。
2.長(zhǎng)輪詢(long-polling)：基本原理是客戶端向服務(wù)器發(fā)送請(qǐng)求，服務(wù)器接到請(qǐng)求后hold住連接，直到有新消息才返回響應(yīng)信息并關(guān)閉連接，連接被斷開(kāi)期間用戶的新信息會(huì)被服務(wù)器緩存起來(lái)。客戶端處理完響應(yīng)信息后再向服務(wù)器發(fā)送新的請(qǐng)求。這種做法的優(yōu)勢(shì)是如果用戶一直沒(méi)新消息，客戶端不會(huì)頻繁的輪詢?nèi)シ?wù)器取消息，節(jié)省了流量，但是服務(wù)器維持長(zhǎng)連接是很消耗資源的。具體實(shí)現(xiàn)起來(lái)，前端這邊基本不需要什么改動(dòng)，依然是用Ajax輪詢?nèi)⌒畔?，后端需要在沒(méi)有新消息時(shí)處理一下。
3.長(zhǎng)連接(streaming)：其實(shí)很早以前就有人使用這種技術(shù)來(lái)實(shí)現(xiàn)聊天室的通訊，HTTP1.1開(kāi)始支持。以前在頁(yè)面中嵌入一個(gè)iframe，iframe里放一個(gè)使用長(zhǎng)連接頁(yè)面，服務(wù)器有新消息就會(huì)及時(shí)的在iframe里反映出來(lái)，再依靠客戶端的腳本解析出來(lái)就OK了。這樣做一個(gè)比較嚴(yán)重的問(wèn)題是：使用 iframe請(qǐng)求長(zhǎng)連接時(shí)，無(wú)論是IE還是firefox都會(huì)認(rèn)為頁(yè)面沒(méi)有加載完而顯示進(jìn)度條，很難看。不過(guò)這個(gè)問(wèn)題是可以解決的。firefox支持了Streaming Ajax，在readyState為3的時(shí)候就能接受數(shù)據(jù)，所以問(wèn)題不大；IE則只能在readyState為4，即連接斷開(kāi)時(shí)才能得到返回值。但是偉大的Google工程師使用了一個(gè)hack成功的解決了這個(gè)問(wèn)題：使用一個(gè)被稱為“htmlfile”的ActiveX，把iframe放在這個(gè)ActiveX里就OK了。
無(wú)疑，使用長(zhǎng)連接對(duì)于用戶來(lái)說(shuō)是最好的方案，用戶體驗(yàn)最好（消息能及時(shí)的到達(dá)）、占用用戶帶寬最少（不會(huì)發(fā)送無(wú)用的請(qǐng)求），但是會(huì)增加服務(wù)器的開(kāi)銷；長(zhǎng)輪詢是折中方案，F(xiàn)acebook IM 就是采用這種方案，不過(guò)做了一點(diǎn)改動(dòng)：客戶端發(fā)起的每個(gè)連接服務(wù)器都hold10S，這10S中新消息會(huì)源源不斷的返回給客戶端，10s后連接關(guān)閉，客戶端發(fā)起下一個(gè)連接。這樣做是因?yàn)镕acebook的用戶會(huì)不斷的打開(kāi)、關(guān)閉新頁(yè)面，如果每個(gè)頁(yè)面都建立一個(gè)永久的長(zhǎng)連接，會(huì)阻塞瀏覽器其他請(qǐng)求，服務(wù)器也會(huì)吃不消的；短輪詢因?yàn)閷?shí)現(xiàn)起來(lái)簡(jiǎn)單，適用于小型應(yīng)用。