以IP通訊協定為基礎的Internet/Intranet/Extranet各種服務應用，除卻新近興起的P2P(Peer-to-Peer)外，都難離Client-Server的架構。在Client-Server架構下進行的種種應用，其資訊流向，均難脫兩種模式：1.Client-Pull 2.Server-Push。以下詳細說明之：
何謂 Client-Pull ?
所謂的Client-Pull(以下簡稱Pull)，又可稱為On-Demand Service，是指當各種應用的Client端軟體，隨著使用者的操作指令，或是Client端自動化的程式設計，向Server提出服務的要求，Server始給予回應，並將結果傳回給Client端，完成整個資訊服務的作業流程。諸如在WWW服務中的Client (如Browser IE 或Navigator)中點按Hyperlink，或是在E-Mail服務中用POP3 Client軟體(如Outlook或Outlook Express)接收電子郵件，都是此類應用顯著的例子。
在Pull的應用中，因為我們很難去預測個別Client的服務需求在何時會被提出，所以在服務能量的準備上，容易造成困擾。比如說，在一個流量數以百萬計的Portal Site首頁上，可能擁有數十個Hyperlink，但我們實在很難去預測這些正在瀏覽該首頁的眾多網友們，下一刻會去點按哪一個Hyperlink，以繼續其網路瀏覽的行為。所以在網路流量尖峰時刻，整體的網站服務效能超出負荷，讓網友在瀏覽時有服務遲緩的感受。但在離峰時刻，卻只用去整體服務量能的15%∼30%，又讓網站經營者有投資浪費之感。
何謂 Server-Push ?
所謂的Server-Push(以下簡稱Push)，又可稱為Subscribe-Publish Service，是指各種應用的Client端軟體，可以經由使用者的自由意志，或是Client端軟體程式設計強迫式地向Server訂閱包含各種不同資訊的頻道(Channel)，之後Client就保持在待命接收的狀態。當各頻道有更新的資訊餵入Server時，由Server主動推播給有訂閱紀錄的諸Clients去接收、展現，完成整個資訊服務的作業流程。
過去，由於技術與整體網路環境的瓶頸，著實讓Push的服務應用數量，遠低於Pull者。且在Push單一的應用規模上，也甚少能達到以千或萬計的Clients同時連線數量(Concurrent Connection)。ICE iPush Communication Server，創新IP通訊技術，不只能做到Bi-directional Push，且在服務的量能上，可輕易達到以萬計的Clients同時連線數量，可謂是Internet應用史上，重要的技術突破。
Internet應用歷史上的「Push」
在Internet的應用歷史沿革中，曾經出現過幾次「Push」的例子，也激起程度不一的火花，藉此一隅，讓我們來回顧一下。
- 偽裝成「Push」的「Smart-Pull」
在Microsoft Internet Explorer 4.x中，出現了所謂的「Active Channel」；無獨有偶地，Netscape Communicator 4.x中，也有類似的「Netcaster」網路播報頻道。這兩家，在Browser爭戰達到最高峰時，都強調這兩者皆為「Push」的應用，也都仿造Subscribe-Publish的模式來進行服務。
但這終究是逃不過專家的法眼，深入一點研究，即不難探知，這兩者都只是較為聰明的「Smart-Pull」，也就是說，是在Client (Browser)這端，針對使用者訂閱的頻道，於預設，或使用者指定的時間間隔，定時由Client去向Server要求更新該頻道的內容(Scheduled Reload)，所以本質上，還是Client-Pull的行為。
- 單向的「Push」
要說到大規模、真正的Internet Push服務，歷史上除卻PointCast，難出其右。就技術而言，這是一個以真正Server-Push的方式，在網路上單向 (One-way) 地播送著各類的資訊：新聞、財經、娛樂、運動、廣告……；以商業模式而言，PointCast是一個對訂閱者免費，對廠商收取廣告費為收入的ICP服務。就像許多ICP一般，PointCast最終還是走向被購併的命運，但遙想恭逢盛況時，許多人Windows的系統桌布，或是螢幕保護裝置，隨著個人所喜愛的各式PointCast頻道內容更新，變換著生動迷人的背景，讓人充分感受到Push的威力。
Server-Push無法取代Client-Pull，但是...
事實上，Push與Pull的服務應用，各有擅場，資訊流向不同、作業方式也不同，無法相互取代。但是，在今天，我們卻看到許多Pull的「彆腳」應用，若能改採用Push，則在頻寬與伺服器量能上，肯定可以增加不少效益，與降低不少成本。以上述定時更新的「Smart-Pull」來說，我們假設以下的使用情境：某個可供使用者訂閱的頻道內容每30分鐘會被更新一次，但使用者A君卻將其Client設為每5分鐘自動Reload一次，於是在完整的30分鐘內，A君的Client軟體做了6次的Reload動作，其中有5次由Client對Server提出的服務需求，Server都傳回未更新的舊有資料，造成了下列的浪費：
- 5次Client對Server提出服務需求的網路頻寬
- 5次Server回應A君Client服務需求所需用到的Computing Power
- 5次Server透過網路卡要對外傳送結果給A君Client的I/O Resource
- 5次Server傳送結果給A君Client的對外頻寬
倘若以上是一項針對廣大網友的開放性B2C服務，可能有成千上萬類似A君的Clients在同時要求服務，那這樣的浪費加總起來，是多麼地可觀啊！
所以，我們可以下一個結論，就是在資訊來源可被規劃分類，形成一個一個類似頻道概念，且使用者經事先訂閱，而後被Server源源不絕主動更新內容者，就相當適合改採Push的應用架構。以WWW為例，現在有許多的網頁設計師，為了顯示一個網頁上的特定內容，往往都會利用 tag、JavaScript、或是VB Script來定時重新載入同一URL。其實若我們能將該特定內容改為以Java Applet來展現，搭配Server-Push，這樣既可免除以上的浪費，又可讓瀏覽者享有更佳的視覺效果(不必整頁更新)，何樂而不為？
|
|
