H3C OAA之WAN優(yōu)化技術白皮書

1、H3C OAA之WAN優(yōu)化技術白皮書目 錄 TOC o 1-3 h z u HYPERLINK l _Toc168822958 目 錄 PAGEREF _Toc168822958 h 4 HYPERLINK l _Toc168822959 1. 概述 PAGEREF _Toc168822959 h 5 HYPERLINK l _Toc168822960 1.1 背景 PAGEREF _Toc168822960 h 5 HYPERLINK l _Toc168822961 1.2 廣域網(wǎng)優(yōu)化簡介 PAGEREF _Toc168822961 h 5 HYPERLINK l _Toc168822962

2、 2. 廣域網(wǎng)優(yōu)化原理介紹 PAGEREF _Toc168822962 h 6 HYPERLINK l _Toc168822963 2.1 數(shù)據(jù)壓縮原理介紹 PAGEREF _Toc168822963 h 6 HYPERLINK l _Toc168822964 2.2 緩存原理 PAGEREF _Toc168822964 h 7 HYPERLINK l _Toc168822965 2.2.1 基本原理 PAGEREF _Toc168822965 h 7 HYPERLINK l _Toc168822966 2.2.2 數(shù)據(jù)塊緩存原理 PAGEREF _Toc168822966 h 7 HYPER

3、LINK l _Toc168822967 2.3 TCP加速原理介紹 PAGEREF _Toc168822967 h 8 HYPERLINK l _Toc168822968 2.3.1 窗口大小通告與滑動窗口 PAGEREF _Toc168822968 h 9 HYPERLINK l _Toc168822969 2.3.2 慢啟動 PAGEREF _Toc168822969 h 9 HYPERLINK l _Toc168822970 2.3.3 擁塞避免 PAGEREF _Toc168822970 h 9 HYPERLINK l _Toc168822971 2.3.4 窗口調節(jié)技術 PAGER

4、EF _Toc168822971 h 11 HYPERLINK l _Toc168822972 2.3.5 選擇性確認 PAGEREF _Toc168822972 h 11 HYPERLINK l _Toc168822973 2.3.6 Split TCP PAGEREF _Toc168822973 h 11 HYPERLINK l _Toc168822974 2.4 QoS原理介紹 PAGEREF _Toc168822974 h 12 HYPERLINK l _Toc168822975 2.4.1 模型 PAGEREF _Toc168822975 h 12 HYPERLINK l _Toc1

5、68822976 2.4.2 QoS技術介紹 PAGEREF _Toc168822976 h 13 HYPERLINK l _Toc168822977 3. 解決方案主要模塊介紹 PAGEREF _Toc168822977 h 14 HYPERLINK l _Toc168822978 3.1 多業(yè)務路由器MSR PAGEREF _Toc168822978 h 14 HYPERLINK l _Toc168822979 3.2 WAAM模塊 PAGEREF _Toc168822979 h 14 HYPERLINK l _Toc168822980 3.2.1 數(shù)據(jù)壓縮 PAGEREF _Toc168

6、822980 h 15 HYPERLINK l _Toc168822981 3.2.2 應用加速 PAGEREF _Toc168822981 h 19 HYPERLINK l _Toc168822982 3.2.3 TCP加速 PAGEREF _Toc168822982 h 21 HYPERLINK l _Toc168822983 3.2.4 基于應用的QoS技術 PAGEREF _Toc168822983 h 21 HYPERLINK l _Toc168822984 3.2.5 ACFP協(xié)議 PAGEREF _Toc168822984 h 22 HYPERLINK l _Toc1688229

7、85 4. 參考案例 PAGEREF _Toc168822985 h 25目 錄 TOC h z t 圖注 c HYPERLINK l _Toc166655438 圖1 數(shù)據(jù)壓縮原理 PAGEREF _Toc166655438 h 7 HYPERLINK l _Toc166655439 圖2 同類數(shù)據(jù)壓縮原理 PAGEREF _Toc166655439 h 8 HYPERLINK l _Toc166655440 圖3 基于塊的數(shù)據(jù)緩存 PAGEREF _Toc166655440 h 9 HYPERLINK l _Toc166655441 圖4 字節(jié)級數(shù)據(jù)緩存 PAGEREF _Toc16665

8、5441 h 9 HYPERLINK l _Toc166655442 圖5 擁塞避免與慢啟動 PAGEREF _Toc166655442 h 11 HYPERLINK l _Toc166655443 圖6 Split TCP PAGEREF _Toc166655443 h 13 HYPERLINK l _Toc166655444 圖7 IPComp和RTM壓縮模式 PAGEREF _Toc166655444 h 16 HYPERLINK l _Toc166655445 圖8 VDA算法 PAGEREF _Toc166655445 h 17 HYPERLINK l _Toc166655446 圖

9、9 SC算法 PAGEREF _Toc166655446 h 18 HYPERLINK l _Toc166655447 圖10 APC算法 PAGEREF _Toc166655447 h 18 HYPERLINK l _Toc166655448 圖11 壓縮過程1 PAGEREF _Toc166655448 h 19 HYPERLINK l _Toc166655449 圖12 壓縮過程2 PAGEREF _Toc166655449 h 19 HYPERLINK l _Toc166655450 圖13 HTTP/FTP應用加速 PAGEREF _Toc166655450 h 20 HYPERLI

10、NK l _Toc166655451 圖14 DNS應用加速 PAGEREF _Toc166655451 h 21 HYPERLINK l _Toc166655452 圖15 Citrix應用加速 PAGEREF _Toc166655452 h 21 HYPERLINK l _Toc166655453 圖16 語音應用加速 PAGEREF _Toc166655453 h 22 HYPERLINK l _Toc166655454 圖17 OAA體系結構示意圖 PAGEREF _Toc166655454 h 24 HYPERLINK l _Toc166655455 圖18 主機模式示意圖 PAGE

11、REF _Toc166655455 h 25 HYPERLINK l _Toc166655456 圖19 透傳模式示意圖 PAGEREF _Toc166655456 h 25 HYPERLINK l _Toc166655457 圖20 鏡像模式示意圖 PAGEREF _Toc166655457 h 26 HYPERLINK l _Toc166655458 圖21 重定向模式示意圖 PAGEREF _Toc166655458 h 26OAA WAN優(yōu)化解決方案技術白皮書概述背景廣域網(wǎng)的帶寬比局域網(wǎng)帶寬差很多，并且廣域網(wǎng)帶寬的增加會帶來成本大幅度上升。與此同時還會帶來一定影響的網(wǎng)絡延遲。廣域網(wǎng)應用

12、大幅度增加，除了語音、視頻外，傳輸文件、圖片以及海量數(shù)據(jù)的分析以及處理，這些都是困擾用戶正常使用的重要因素。 另外信息的集中化管理，對各分部和總部之間的高質量信息轉送也提出了越來越高的要求，這就需要增加各地的分支機構。與此同時企業(yè)分支網(wǎng)絡逐漸出現(xiàn)了數(shù)據(jù)集中趨勢，一般情況下企業(yè)會將大部分共享數(shù)據(jù)庫放到總部的數(shù)據(jù)中心，給每一個分支機構訪問，但隨著分支機構的迅速增加且多數(shù)員工外出辦公時的訪問量也在上升，這種一對多的數(shù)據(jù)服務給企業(yè)總部的服務器和帶寬帶來了巨大的壓力，影響了數(shù)據(jù)交換的速度。企業(yè)雖然也可以向運營商購買更高的帶寬，不過成本費用較高并且效果不明顯。廣域網(wǎng)性能低下對于用戶的影響主要包括以下幾個方

13、面：大多數(shù)企業(yè)管理、應用軟件均采用C/S結構進行編寫，雖逐步在進行B/S的更改，但是大部分企業(yè)的應用仍然基于C/S結構，對于C/S到B/S結構的更改仍然是一個重要的課題增加帶寬并不能解決訪問及應用慢速的問題，問題存在與TCP自身，TCP自身慢啟動問題仍然是阻礙企業(yè)業(yè)務正常開展的主要問題廣域網(wǎng)行業(yè)縱向網(wǎng)的分支機構眾多，全部采用高帶寬連接投資非常巨大，合作伙伴之間帶寬一般采取的是臨時建立的連接，帶寬極低，又要傳輸大量的數(shù)據(jù)，造成傳輸速度難以忍受基本語音視頻業(yè)務沒有最佳的QoS策略來進行保證，造成質量不佳，最終導致應用開展不起來；大量非法應用堵塞了現(xiàn)有正常應用開展，占據(jù)的帶寬造成了正常帶寬的縮減。廣

14、域網(wǎng)優(yōu)化簡介廣域網(wǎng)（WAN）帶寬昂貴，絕大多數(shù)用戶也因此只能擁有有限的廣域網(wǎng)帶寬。如何以最小的投入提高網(wǎng)絡性能？如何為遠程用戶提高訪問速度和服務效率？怎樣確保隨時召開異地視頻會議而不被打斷？一種方式是“擴出口買帶寬”，其實有更合理的方法解決。數(shù)據(jù)壓縮、動態(tài)緩存、IP流量管理以及QoS等都可以一定程度上解決廣域網(wǎng)傳輸加速的問題。但壓縮僅僅解決了帶寬資源的問題，對于延遲非常大的鏈路，僅靠壓縮是無法完全解決問題的。為解決系統(tǒng)性能和應用系統(tǒng)數(shù)據(jù)傳輸受WAN通信限制的問題，相關技術開始浮出水面，并逐漸形成一個細分的市場這就是WAN優(yōu)化技術市場。其中包括：應用加速、數(shù)據(jù)壓縮、動態(tài)緩存、IP流量管理、QoS

15、保障、帶寬管理、延時縮減、序列緩存、路徑優(yōu)化和應用管理可視化等。要解決的核心問題是應用和廣域網(wǎng)之間的矛盾，因為傳統(tǒng)的網(wǎng)絡資源限制了多種應用的性能。隨著網(wǎng)絡優(yōu)化技術的發(fā)展，諸如控制網(wǎng)絡應用（控制QQ、MSN、IM）、限制P2P（限制BT、eMule、PPLive、eDonkey）軟件占用帶寬、通過QoS合理分配帶寬、Web緩存、數(shù)據(jù)壓縮、動態(tài)緩存等網(wǎng)絡加速方法和解決方案已經(jīng)能夠滿足多數(shù)用戶的需要了。為什么廣域網(wǎng)優(yōu)化會受到如此青睞呢？原因是它的確能解決廣域網(wǎng)目前存在的幾大關鍵弊病。首先，帶寬問題。廣域網(wǎng)的帶寬比局域網(wǎng)帶寬差得太多，如一條T1線路的帶寬只相當于千兆網(wǎng)的千分之一，許多幀中繼線路的帶寬只

16、有256Kbps，并且廣域網(wǎng)帶寬的增加會帶來成本大幅度上升。其次，延遲問題。打過跨國IP電話的人或許都有這樣的體驗，當你說完話后，對方的回音總是過一小段時間才能聽到，這就是延遲的最好例子，在進行視頻通話時就更明顯了。目前廣域網(wǎng)應用劇增，除了語音、視頻外，傳輸圖形或圖像文件、海量數(shù)據(jù)的處理，都是困擾用戶的實際應用。再有，協(xié)議問題。一些目前采用的協(xié)議并不是為廣域網(wǎng)而設計的（如TCP協(xié)議），協(xié)議效率低下，性能不夠理想。廣域網(wǎng)優(yōu)化原理介紹廣域網(wǎng)優(yōu)化的技術有很多，但核心的技術主要包括：數(shù)據(jù)壓縮、動態(tài)緩存、TCP加速、應用加速、QoS等幾個方面。數(shù)據(jù)壓縮原理介紹迄今為止大多數(shù)網(wǎng)絡壓縮系統(tǒng)都是基于數(shù)據(jù)包?；?/p>

17、于數(shù)據(jù)包的壓縮系統(tǒng)緩沖數(shù)據(jù)包都通過解壓器引導至遠程網(wǎng)絡。此后，用戶可一次壓縮一個數(shù)據(jù)包，或一次壓縮多個數(shù)據(jù)包，然后再發(fā)送至在其中反向進行該流程的解壓器。數(shù)據(jù)壓縮原理基于數(shù)據(jù)包壓縮應用的主要問題是壓縮時它將多種數(shù)據(jù)類型混合在一起。所有壓縮例程在處理同類數(shù)據(jù)時將獲得更大的壓縮比。在處理異質數(shù)據(jù)時（例如，多種協(xié)議的大量數(shù)據(jù)包），壓縮比率會大大降低?；跀?shù)據(jù)包的壓縮系統(tǒng)會存在其它問題。壓縮數(shù)據(jù)包時，這些系統(tǒng)必須在網(wǎng)絡中編寫小數(shù)據(jù)包，并進行其它工作以集合并封裝多個數(shù)據(jù)包。僅有其中一項操作不可能達到最佳效果。在網(wǎng)絡中編寫小數(shù)據(jù)包會增加 TCP/IP 標頭的開銷。另外，集合并封裝數(shù)據(jù)包會為該數(shù)據(jù)流增加封裝標

18、頭。先進的壓縮算法支持在處理所有應用類型時能夠在完全同類的數(shù)據(jù)之間進行壓縮。隨之而來的結果是，與同類基于數(shù)據(jù)包的系統(tǒng)相比，壓縮比更高。同類數(shù)據(jù)壓縮原理緩存原理基本原理所有壓縮例程共同存在的局限性是存儲空間有限。許多例程，例如 gzip，只能存儲 64 Kb 的數(shù)據(jù)。其它技術，例如基于磁盤的壓縮系統(tǒng)，可以存儲 1 TB 的數(shù)據(jù)。為了理解字典大小的作用，需要對高速緩存管理內(nèi)容有一個基本的了解。請求 web 站點類似，并非所有網(wǎng)絡中傳輸?shù)淖止?jié)會在同一個頻率下重復。有時系統(tǒng)會通過高頻率傳輸一些字節(jié)，因為這些字節(jié)是常用文件或通用網(wǎng)絡協(xié)議中的一部分。其它字節(jié)只會出現(xiàn)一次并且不會重復出現(xiàn)。壓縮和堆積定律 (

19、Zipfs Law and Heaps Law) 中描述了頻繁重復字節(jié)序列和非頻繁重復字節(jié)序列之間的關系。所有基于當前字典的壓縮系統(tǒng)會通過存儲頻繁訪問的數(shù)據(jù)并刪除非頻繁訪問的數(shù)據(jù)以進行不均等的分配。通過這種優(yōu)化方式，存儲少于 10% 的所有字節(jié)方式會使命中率超過 50%。這種字節(jié)方式的不均等分布效果充分證明了公共壓縮程序的效率。Gzip 僅存儲 64kb 的歷史記錄，但平均能夠壓縮近 64% 的內(nèi)容。Bzip2 能夠存儲 100kb 至 900kb 的歷史記錄，平均壓縮了 66% 的內(nèi)容。盡管數(shù)據(jù)存儲空間不足，但 Gzip 和 Bzip2 仍能出色運行的原因在于頻繁出現(xiàn)的字節(jié)序列能夠表示網(wǎng)絡中

20、的大多數(shù)字節(jié)。數(shù)據(jù)塊緩存原理基于塊的系統(tǒng)可存儲以前在廣域網(wǎng)中傳輸數(shù)據(jù)流部分。再次遇到這些塊時，其參考數(shù)據(jù)會傳送到遠程設備中，該遠程設備繼而會重組原始數(shù)據(jù)。基于塊的系統(tǒng)主要缺點是反復出現(xiàn)的數(shù)據(jù)和塊的長度永遠不會完全相同。因此，匹配僅是部分匹配，還會留下一些重復數(shù)據(jù)不被壓縮。下圖詳細描述了使用 256 字節(jié)塊大小壓縮 512 字節(jié)數(shù)據(jù)時的情況?；趬K的數(shù)據(jù)緩存為了提高緩存效率，字節(jié)級粒度的緩存技術出現(xiàn)了。匹配并發(fā)送帶有字節(jié)級粒度 (byte level granularity) 的數(shù)據(jù)。下圖說明了處理數(shù)據(jù)的過程。字節(jié)級數(shù)據(jù)緩存與基于塊的系統(tǒng)相比，字節(jié)粒度級別無論對于文檔還是對于應用層協(xié)議標頭，均能

21、提高其壓縮級別。TCP加速原理介紹TCP協(xié)議原理較為復雜，影響TCP性能的因素很多，但有一個關鍵的因素是TCP會降低帶寬的利用率，這對于帶寬極其有限的廣域網(wǎng)來說是非常致命的。影響TCP帶寬利用率的主要因素包括以下幾個方面：窗口大小通告與滑動窗口擁塞避免慢啟動窗口調節(jié)技術除了提高帶寬利用率之外，減少確認重傳次數(shù)，縮短TCP連接的握手過程時間等也是TCP加速的重要技術點。選擇性確認3次握手過程的優(yōu)化下面簡單介紹這幾個方面的原理。窗口大小通告與滑動窗口通信雙方接收模塊需要依據(jù)各自的緩沖區(qū)大小，相互通告還能接受對方數(shù)據(jù)的尺寸。雙方發(fā)送模塊則必須根據(jù)對方通告的接收窗口大小，進行數(shù)據(jù)發(fā)送。這種機制稱之謂滑

22、動窗口，它是TDP接收方的流量控制方法。它允許發(fā)送方在停止并等待確認前可以連續(xù)發(fā)送多個分組（依據(jù)滑動窗口的大?。?，由于發(fā)送方不必每發(fā)一個分組就停下來等待確認，因此可以加速數(shù)據(jù)的傳輸。 滑動窗口在排序數(shù)據(jù)流上不時的向右移動，窗口兩個邊沿的相對運動增加或減少了窗口的大小，關于窗口邊沿的運動有三個術語：窗口合攏（當左邊沿向右邊沿靠近）、窗口張開（當右邊沿向右移動）、窗口收縮（當右邊沿向左移動）。 當遇到快的發(fā)送方與慢的接收方的情況時，接收方的窗口會很快被發(fā)送方的數(shù)據(jù)填滿，此時接收方將通告窗口大小為0,發(fā)送方則停止發(fā)送數(shù)據(jù)。直到接收方用戶程序取走數(shù)據(jù)后更新窗口大小，發(fā)送方可以繼續(xù)發(fā)送數(shù)據(jù)；另外，因為A

23、CK報文段有可能丟失，發(fā)送方可能沒有成功接收到更新的窗口大小，因此發(fā)送方將啟動一個堅持定時器，當堅持定時器超時，發(fā)送方將發(fā)送一個字節(jié)的數(shù)據(jù)到接收方，嘗試檢查窗口大小的更新。慢啟動如果發(fā)送方一開始便向網(wǎng)絡發(fā)送多個報文段，直至達到接收方通告窗口大小為止。當發(fā)送方與接收方在同一局域網(wǎng)時，這種方式是可以的。但如果在發(fā)送方與接收方之間存在多個路由器和速率較慢的鏈路時，就可能出現(xiàn)問題。一些中間路由器必須緩存分組，并有可能耗盡存儲器的空間，將來得降低TCP連接的吞吐量。于是需要一種叫“慢啟動”的擁塞控制算法。 慢啟動為發(fā)送方增加一個擁塞窗口，記為cwnd，當與另一個網(wǎng)絡的主機建立連接時，擁塞窗口被初始化為1

24、個報文段。每收到一個ACK，擁塞窗口就增加一個報文段（cwnd以字節(jié)為單位，但慢啟動以報文段大小為單位進行增加）。發(fā)送方取擁塞窗口與通告窗口中的最小值作為發(fā)送上限。擁塞窗口是發(fā)送方使用的流量控制，而通告窗口是接收方使用的流量控制。 發(fā)送方開始時發(fā)送一個報文段，然后等待ACK。當收到該ACK時，擁塞窗口從1增加到2,即可以發(fā)送兩個報文段。當收到這兩個報文段的ACK時，擁塞窗口就增加為4。這是一種指數(shù)增加的關系。擁塞避免慢啟動算法增加擁塞窗口大小到某些點上可能達到了互聯(lián)網(wǎng)的容量，于是中間路由器開始丟棄分組。這就通知發(fā)送方它的擁塞窗口開得太大。擁塞避免算法是一種處理丟失分組的方法。該算法假定由于分組

25、受到損壞引起的丟失是非常少的（遠小于1），因此分組丟失就意味著在源主機和目標主機之間的某處網(wǎng)絡上發(fā)生了擁塞。有兩種分組丟失的指示：發(fā)生超時和接收到重復的確認。擁塞避免算法與慢啟動算法是兩個獨立的算法，但實際中這兩個算法通常在一起實現(xiàn)。擁塞避免與慢啟動 擁塞避免算法和慢啟動算法需要對每個連接維持兩個變量：一個擁塞窗口cwnd和一個慢啟動門限ssthresh。算法的工作過程如下： 1) 對一個給定的連接，初始化cwnd為1個報文段，ssthresh為65535個字節(jié)。 2) TCP輸出例程的輸出不能超過cwnd和接收方通告窗口的大小。擁塞避免是發(fā)送方使用的流量控制，而通告窗口則是接收方進行的流量控

26、制。前者是發(fā)送方感受到的網(wǎng)絡擁塞的估計，而后者則與接收方在該連接上的可用緩存大小有關。 3) 當擁塞發(fā)生時（超時或收到重復確認），ssthresh被設置為當前窗口大小的一半（cwnd和接收方通告窗口大小的最小值，但最少為2個報文段）。此外，如果是超時引起了擁塞，則cwnd被設置為1個報文段（這就是慢啟動）。 4) 當新的數(shù)據(jù)被對方確認時，就增加cwnd，但增加的方法依賴于我們是否正在進行慢啟動或擁塞避免。如果cwnd小于或等于ssthresh，則正在進行慢啟動，否則正在進行擁塞避免。慢啟動一直持續(xù)到我們回到當擁塞發(fā)生時所處位置的半時候才停止（因為我們記錄了在步驟2中給我們制造麻煩的窗口大小的一

27、半），然后轉為執(zhí)行擁塞避免。 慢啟動算法初始設置cwnd為1個報文段，此后每收到一個確認就加1。這會使窗口按指數(shù)方式增長：發(fā)送1個報文段，然后是2個，接著是4個。擁塞避免算法要求每次收到一個確認時將cwnd增加1/cwnd。與慢啟動的指數(shù)增加比起來，這是一種加性增長。我們希望在一個往返時間內(nèi)最多為cwnd增加1個報文段（不管在這個RT T中收到了多少個ACK），然而慢啟動將根據(jù)這個往返時間中所收到的確認的個數(shù)增加cwnd。 處于擁塞避免狀態(tài)時，擁塞窗口的計算公式如下（引公式參照BSD的實現(xiàn)，segsize/8的值是一個匹配補充量，不在算法描述當中）： cwnd - cwnd + segsize

28、 * segsize / cwnd + segsize / 8。窗口調節(jié)技術傳輸窗口大小，即在收到回應之前一次發(fā)送的數(shù)據(jù)量，會直接影響到TCP的性能。相反，性能又與回程時間成正比，因為協(xié)議需要（通過ACK包表明數(shù)據(jù)已被成功接收的信號）確保數(shù)據(jù)投送到位。在最糟糕的情況下，一個端點會等待另一端點回應數(shù)據(jù)的傳輸情況，從而使網(wǎng)絡閑置的時間變長。當傳輸窗口變得很小時，這種現(xiàn)象便會發(fā)生，但此現(xiàn)象并不能準確反映線路速度和延遲情況。 使情況變得更加復雜的是，TCP會根據(jù)響應速度調整自己的窗口大小。連接的距離越長，窗口就越小。如果響應的速度非常緩慢，TCP 協(xié)議就可能永遠也不選擇最大的窗口尺寸，這意味著許多廣域

29、網(wǎng)連接的完整容量永遠也不會被完全利用。因此，TCP協(xié)議可能導致廣域網(wǎng)性能的惡化，甚至在帶寬 仍然非常充足時，性能的惡化也在所難免。同樣，重傳也會嚴重影響TCP的性能，要知道1%的包丟失可能導致最多80%的性能損失。TCP應當基于系統(tǒng)可用帶寬時延積（BDP，Bandwidth Delay Product）設定合適的接收方窗口大小。接收方通知窗口應當至少同BDP一樣大，否則接收方的TCP層將對最大可用帶寬造成限制。該技術可以自行選擇TCP窗口的大小，從而實現(xiàn)最高的傳輸速率并在廣域網(wǎng)連接發(fā)生包丟失時 將重傳數(shù)據(jù)包的數(shù)量減至最小。通知窗口應當盡可能地設大一些，使得所有的可用帶寬都有可能使用；但如果通知

30、窗口比BDP大太多，也可能因為緩存溢出和隨后的TCP重傳導致性能惡化。因而，通知窗口應當比BDP稍大，一方面充分使用容量，另一方面也不會損害到網(wǎng)絡處理擁塞和丟報恢復的能力。TCP Fast Start也是一種算法，它可以加速TCP發(fā)送窗口的增長速度，從而實現(xiàn)了可用帶寬的快速利用。選擇性確認TCP連接期間，接收方將最后一個成功接收報文段的序號包含進ACK中，此即累積性確認。一般而言，選擇性ACK（SACK，Selective Acknowledgement）則是可選項，它允許接收方向發(fā)送方通知所有數(shù)據(jù)段的傳輸狀態(tài)。這樣，發(fā)送方就可以有選擇地重傳，而不是僅僅重傳第一個丟失分組并等待下一個ACK（一

31、個RTT）來接收新的丟失信息。 在具有較大BDP通道時，SACK更能發(fā)揮作用，有研究結果表明它適合于具有中等丟失率（低于窗口大小的50%）的長延遲網(wǎng)絡環(huán)境。這使得SACK比較適合于無線鏈路。但其不足在于它會稍微加大報頭的尺寸（最多增添8byte），且其使用需要客戶機、服務器兩端的支持。Split TCPTCP連接跨越廣域網(wǎng)時，廣域網(wǎng)上跳數(shù)多，路由變化頻繁，會對TCP連接的性能造成不良影響。為了提高TCP連接的吞吐率，提出Split TCP（即TCP代理）的解決思路。具體地說就是在TCP端到端連接中設置代理，將一條完整的長路經(jīng)切割成多條段路徑，針對每一條短路徑分別建立TCP連接。這樣可以提高TC

32、P連接的吞吐量，同時也可以改善TCP建立的3次握手過程的性能。連接建立分要經(jīng)過三次握手過程：客戶端發(fā)送一個SYN段到指明客戶打算連接的服務器的端口，報文段中要設置客戶端初始序號。服務器發(fā)回包含服務器的初始序號的SYN報文段作為應答。同時，將確認序號設置為客戶的初始序號加1,并設置ACK位標志報文段為確認報文段?？蛻舳吮仨殞⒋_認序號設置為服務器初始序號加1,對服務器的SYN報文段進行確認。 全局維護一個初始序號種子，這個初始序號為隨時產(chǎn)生的32位整數(shù)。連接建立的超時和重傳初始值為3秒，超時采用指數(shù)退避算法，3秒超時后超時值為6秒，然后是12秒，24秒。連接建立最長時間限制為75秒。Split T

33、CPQoS原理介紹模型Best-Effort模型Best-Effort是一個單一的服務模型，也是最簡單的服務模型。應用程序可以在任何時候發(fā)出任意數(shù)量的報文，而且不需要事先獲得批準，也不需要通知網(wǎng)絡。對Best-Effort服務網(wǎng)絡，盡最大的可能性來發(fā)送報文，但對時延可靠性等性能不提供任何保證。InterServ模型該模型使用資源預留（RSVP）協(xié)議，RSVP運行在從源端到目的端的每個路由器上，負責請求/預留資源。InterServ模型能夠在IP網(wǎng)上提供端到端的QOS保證。但是，InterServ模型對路由器的要求很高，當網(wǎng)絡中的數(shù)據(jù)流數(shù)量很大時，路由器的存儲和處理能力會遇到很大的壓力。Diff

34、Serv模型區(qū)分服務（DiffServ）是IETF工作組為了克服InterServ的可擴展性差在1998年提出的另一個服務模型，目的是制定一個可擴展性相對較強的方法來保證IP的服務質量。在DiffServ模型中，業(yè)務流被劃分成不同的差分服務類。一個業(yè)務流的差分服務類由其IP包頭中的差分服務標記字段（Different Service Code Point，簡稱DSCP）來表示。在實施DiffServ的網(wǎng)絡中，每一個路由器都會根據(jù)數(shù)據(jù)包的DSCP字段執(zhí)行相應的PHB(Per Hop Behavior)行為，主要包括以下三類PHB：Expedited Forwarding (EF)：主要用于低延遲

35、、抖動和丟包率的業(yè)務，這類業(yè)務一般運行一個相對穩(wěn)定的速率，需要在路由器中進行快速轉發(fā)；Assured Forwarding (AF)：這類業(yè)務在沒有超過最大允許帶寬時能夠確保轉發(fā)，一旦超出最大允許帶寬，則允許根據(jù)不同的丟棄級別丟棄報文。AF確保轉發(fā)類將轉發(fā)行為分為4類，每一個確保轉發(fā)類都被分配了不同的帶寬資源，并對應3個不同的丟棄優(yōu)先級。IETF建議使用4個不同的隊列分別傳輸AF1x、AF2x、AF3x、AF4x業(yè)務，并且每個隊列提供3種不同的丟棄優(yōu)先級，因此可以構成12個有保證轉發(fā)的PHB。Best Effort (BE)：盡力轉發(fā)，主要用于對時延、抖動和丟包不敏感的業(yè)務。目前，基于Diff

36、Serv模型的QoS服務是業(yè)界主流。下面將簡單介紹一些基于DiffServ模型的QoS技術。QoS技術介紹流量分類和標記報文分類是將報文劃分為多個優(yōu)先級或多個服務類，如使用IP報文頭的ToS（Type of service，服務類型）字段的前三位（即IP優(yōu)先級）來標記報文，可以將報文最多分成8類；若使用DSCP（Differentiated Services Codepoint，區(qū)分服務編碼點，ToS域的前6位），則最多可分成64類。在報文分類后，就可以將其它的QoS特性應用到不同的分類，實現(xiàn)基于類的擁塞管理、流量整形等。擁塞管理擁塞管理是指網(wǎng)絡在發(fā)生擁塞時，如何進行管理和控制。處理的方法是使

37、用隊列技術。將所有要從一個接口發(fā)出的報文 進入多個隊列，按照各個隊列的優(yōu)先級進行處理。不同的隊列算法用來解決不同的問題，并產(chǎn)生不同的效果。常用的隊列有FIFO、PQ，CQ，RTP優(yōu)先隊列，WFQ，CBWFQ等。擁塞管理的處理包括隊列的創(chuàng)建、報文的分類、將報文送入不同的隊列、隊列調度等。在一個接口沒有發(fā)生擁塞的時候，報文在到達接口后立即就被發(fā)送出去，在報文到達的速度超過接口發(fā)送報文的速度時，接口就發(fā)生了擁塞。擁塞管理就會將這些報文進行分類，送入不同的隊列；而隊列調度對不同優(yōu)先級的報文進行分別處理，優(yōu)先級高的報文會得到優(yōu)先處理。擁塞避免由于內(nèi)存資源的有限，按照傳統(tǒng)的處理方法，當隊列的長度達到規(guī)定的

38、最大長度時，所有到來的報文都被丟棄。對于TCP報文，如果大量的報文被丟棄，將造成TCP超時，從而引發(fā)TCP的慢啟動和擁塞避免機制，使TCP減少報文的發(fā)送。當隊列同時丟棄多個TCP連接的報文時，將造成多個TCP連接同時進入慢啟動和擁塞避免，稱之為：TCP全局同步。這樣多個TCP連接發(fā)向隊列的報文將同時減少，使得發(fā)向隊列的報文的量不及線路發(fā)送的速度，減少了線路帶寬的利用。并且，發(fā)向隊列的報文的流量總是忽大忽小，使線路的上的流量總在極少和飽滿之間波動。為了避免這種情況的發(fā)生，隊列可以采用加權隨機早期檢測WRED（Weighted Random Early Detection ）的報文丟棄策略（WRE

39、D與RED的區(qū)別在于前者引入IP優(yōu)先權，DSCP值，和MPLS EXP來區(qū)別丟棄策略）。采用WRED時，用戶可以設定隊列的閾值（threshold）。當隊列的長度小于低閾值時，不丟棄報文；當隊列的長度在低閾值和高閾值之間時，WRED開始隨機丟棄報文（隊列的長度越長，丟棄的概率越高）；當隊列的長度大于高閾值時，丟棄所有的報文。由于WRED隨機地丟棄報文，將避免使多個TCP連接同時降低發(fā)送速度，從而避免了TCP的全局同步現(xiàn)象。當某個TCP連接的報文被丟棄，開始減速發(fā)送的時候，其他的TCP連接仍然有較高的發(fā)送速度。這樣，無論什么時候，總有TCP連接在進行較快的發(fā)送，提高了線路帶寬的利用率。流量監(jiān)管與

40、流量整形流量監(jiān)管（traffic policing）的典型作用是限制進入某一網(wǎng)絡的某一連接的流量與突發(fā)。在報文滿足一定的條件時，如某個連接的報文流量過大，流量監(jiān)管就可以對該報文采取不同的處理動作，例如丟棄報文，或重新設置報文的優(yōu)先級等。通常的用法是使用CAR來限制某類報文的流量，例如限制HTTP報文不能占用超過50%的網(wǎng)絡帶寬。流量整形（traffic shaping）的典型作用是限制流出某一網(wǎng)絡的某一連接的流量與突發(fā)，使這類報文以比較均勻的速度向外發(fā)送。流量整形通常使用緩沖區(qū)和令牌桶來完成，當報文的發(fā)送速度過快時，首先在緩沖區(qū)進行緩存，在令牌桶的控制下，再均勻地發(fā)送這些被緩沖的報文。鏈路分片

41、與交叉（Link Fragment & Interleave，LFI）對于低速鏈路，即使為語音等實時業(yè)務報文配置了高優(yōu)先級隊列（如RTP優(yōu)先隊列或LLQ），也不能夠保證其時延與抖動，原因在于接口在發(fā)送其他數(shù)據(jù)報文的瞬間，語音業(yè)務報文只能等待，而對于低速接口發(fā)送較大的數(shù)據(jù)報文要花費相當?shù)臅r間。采用LFI以后，數(shù)據(jù)報文（非RTP實時隊列和LLQ中的報文）在發(fā)送前被分片、逐一發(fā)送，而此時如果有語音報文到達則被優(yōu)先發(fā)送，從而保證了語音等實時業(yè)務的時延與抖動。LFI主要用于低速鏈路。RTP報文頭壓縮（RTP Header Compression，cRTP）cRTP主要在低速鏈路上使用，可將40字節(jié)的IP

42、/UDP/RTP頭壓縮到24個字節(jié)（不使用校驗和可到2字節(jié)），提高鏈路的利用率。cRTP主要得益于同一會話的語音分組頭和語音分組頭之間的差別往往是不變的，因此只需傳遞增量。RTP協(xié)議用于在IP網(wǎng)絡上承載語音、視頻等實時多媒體業(yè)務。解決方案主要模塊介紹H3C的OAA WAN優(yōu)化解決方案，主要由MSR(Multiple Service Router)多業(yè)務路由器與WAAM(Wan Application )模塊組成，兩者之間通過ACFP(Application control forward protocol應用控制轉發(fā)協(xié)議)進行互動連接。多業(yè)務路由器MSRMSR（Multiple Service

43、s Router）多業(yè)務開放路由器是H3C公司專門面向行業(yè)分支機構和大中型企業(yè)而推出的新一代網(wǎng)絡產(chǎn)品。MSR先進的軟件結構與硬件平臺，能夠在最小的投資范圍內(nèi)為企業(yè)邊緣網(wǎng)絡提供一體化解決方案，更能充分滿足未來業(yè)務擴展的多元化應用需求，符合企業(yè)IT建設的現(xiàn)狀與趨勢。企業(yè)信息架構正在由C/S模式向B/S模式轉變，MSR具備高數(shù)據(jù)轉發(fā)能力與高加密能力，很好的解決了轉變過程中凸現(xiàn)的網(wǎng)絡帶寬壓力與安全隱患，保障企業(yè)關鍵業(yè)務流可以高速、機密的通過廣域網(wǎng)傳輸。WAAM模塊WAAM模塊的主要功能包括以下4個部分：數(shù)據(jù)壓縮應用加速TCP加速L7QoS數(shù)據(jù)壓縮壓縮模式WAAM有兩個壓縮模式：IPComp, RTM。

44、報文的具體壓縮封裝模式參加下圖。IPComp和RTM壓縮模式IPComp類似一種隧道封裝方式，在兩個WAAM模塊之間建立一條靜態(tài)隧道，對于隧道內(nèi)的數(shù)據(jù)提供完全的封裝，對原始報文頭和數(shù)據(jù)都進行壓縮處理，對外不可見，安全性較高。但由于對外屏蔽了原始報文頭，使得網(wǎng)絡中一些基于報文頭特殊字段的處理無法實施，例如：QoS，流量分析等等。需要注意的是：如果有明確的需要，可以通過配置保留原始報文頭中的部分字段，如：源地址、TTL或ToS域。RTM保留原始報文頭，僅壓縮原始數(shù)據(jù)區(qū)，安全性較差，但由于保留了原始報文頭，可以保證QoS、流量分析等功能的實施。壓縮算法WAAM的壓縮算法主要有3個，分別針對不同區(qū)域的

45、數(shù)據(jù)進行壓縮。VDA(Vertical Data Analysis), 將數(shù)據(jù)流分割成不同的報頭和數(shù)據(jù)段，并標記可以緩存的部分。SC(Selective Caching), 緩存重復傳輸?shù)淖止?jié)段。APC(Adaptive Packet Compression), 對于不能緩存、不能分割報頭的數(shù)據(jù)進行壓縮。VDA算法VDA算法VDA可以自動識別報文中的各個協(xié)議字段，例如：:HDLCIP HeaderTCP HeaderHTTP/1.1 HeaderXMLData通過預定義的規(guī)則，VDA能夠分析更加細致的報頭信息，例如：sequence numbersChecksumsprotocol ident

46、ifiersSC算法SC算法SC算法的本質就是數(shù)據(jù)塊緩存，為了提高緩存效率，SC算法支持字節(jié)級粒度的緩存方式。從緩存的角度來看，VDA算法實際上是為SC算法服務的。APC算法APC算法APC算法屬于典型的壓縮算法，具體原理與2.1小節(jié)中描述的原理很相似。不同的數(shù)據(jù)類型應用不同的壓縮算法，例如：下列的數(shù)據(jù)就用不同的方式壓縮處理。這樣壓縮效果更好。HTMLSQLJavaScript壓縮處理過程在整個壓縮過程中，VDA、SC、APC并不是獨立存在的，而是相互配合、相互作用的一個整體，下面是一個完成的壓縮過程中，各算法之間的關系。壓縮過程1VDA、SC、APC算法的應用有嚴格的順序關系，VDA算法實際

47、上可以看作是SC算法的一個準備步驟，而APC則是VDA/SC算法的有效補充。壓縮過程2應用加速當前廣域網(wǎng)存在的主要問題是時延過大，導致各種應用性能嚴重降低。針對廣域網(wǎng)時延過大的問題，WAAM采用應用加速和TCP加速。應用加速主要包括：HTTP/FTP/DNS等Citrix的各種應用語音流的加速處理HTTP/FTP/DNS加速HTTP/FTP/DNS應用加速的原理是本地代理機制。即在本地應用加速設備上建立代理，通過代理與服務器連接連接，對常用的請求進行緩存。在收到請求時與緩存數(shù)據(jù)對比，如果匹配則可以直接從本地代理獲取應答，有效的減少了穿越廣域網(wǎng)的請求、應答過程。因此，可以取得很好的加速效果。HT

48、TP/FTP應用加速啟用HTTP/FTP加速時，部分重復的請求與應答不需要穿越廣域網(wǎng)，減小時延廣域網(wǎng)優(yōu)化設備終結會話緩存數(shù)據(jù)，并對重復的請求本地作出應答減少重復數(shù)據(jù)反復穿越廣域網(wǎng)啟用DNS加速時，廣域網(wǎng)優(yōu)化設備本地應答DNS請求，可以將原本需要200ms的應答縮短到5ms。DNS應用加速Citrix應用加速Citrix應用加速的核心是“小包組大包”，減少報文頭對帶寬的消耗Citrix數(shù)據(jù)流小包居多，平均報文大小是80-100字節(jié)，壓縮后40-50字節(jié)，這些小包的報文頭對帶寬的消耗很可觀將報文頭相同的多個小包組成一個大包，可以有效的減少報文頭部對于帶寬的消耗Citrix應用加速語音應用加速語音加

49、速的核心是鏈路分片與交叉（Link Fragment & Interleave，LFI）語音等實時業(yè)務報文配置了高優(yōu)先級隊列（如RTP優(yōu)先隊列或LLQ）低速接口發(fā)送較大的數(shù)據(jù)報文要花費相當?shù)臅r間，影響語音時延采用LFI以后，數(shù)據(jù)報文（非RTP實時隊列和LLQ中的報文）在發(fā)送前被分片、逐一發(fā)送，而此時如果有語音報文到達則被優(yōu)先發(fā)送，從而保證了語音等實時業(yè)務的時延與抖動語音應用加速TCP加速WAAM在實現(xiàn)TCP加速技術方面，主要依據(jù)SCPS(Space Communications Protocol Standards)的標準。重點突出以下幾個方面的技術內(nèi)容：Split TCP突破TCP端到端連接

50、的理念：取消了廣域網(wǎng)上TCP連接建立的3次握手過程。加快TCP連接建立過程。在兩端的局域網(wǎng)內(nèi)建立兩個高速的TCP連接在兩端的TCP加速設備之間建立一條優(yōu)化的TCP連接內(nèi)網(wǎng)隔離,快速啟動。本地加速設備回應SYN報文，同時保證廣域網(wǎng)連接啟動優(yōu)化TCP，增加帶寬的使用率取消廣域網(wǎng)上TCP連接得慢啟動過程，廣域網(wǎng)兩側的加速設備統(tǒng)一配置帶寬參數(shù)，通過帶寬參數(shù)計算擁塞窗口的尺寸取消窗口大小調整過程。窗口尺寸根據(jù)帶寬計算，相對固定，不再頻繁變化。窗口大小調整， 擴大 TCP 窗口尺寸：基準值 16K ，最大值 64K。便于ACK快速到達，減少不必要的重傳。選擇性ACK SNACK，僅對丟棄的包進行重傳。不對

51、稱鏈路，例如：減少廣域網(wǎng)上ACK傳輸?shù)臄?shù)量取消擁塞避免機制優(yōu)化容錯算法基于應用的QoS技術基于應用的QoS的本質還是QoS，不同的是前者增加了一項功能：識別應用。在識別應用的基礎上，對不同的應用進行標識，然后基于不同的標志對不同的應用作不同的QoS處理，就是基于應用的QoS技術的意義。應用識別WAAM識別應用的范圍包括以下幾個方面：預定義的應用識別支持60種預定義的應用識別，保存全部統(tǒng)計信息支持266種預定義的應用識別，保存簡要信息支持50種自定義的應用識別，定義內(nèi)容包括：IP地址和端口號TOS/COS入方向或是出方向7層應用識別，包括：HTTP地址，URL， MIME等等Citrix發(fā)布的應

52、用，客戶端名稱等等另外，WAAM還能監(jiān)控所有應用的歷史統(tǒng)計數(shù)據(jù)。QoS處理WAAM對不同的應用做不同的QoS處理，主要包括以下幾個方面：識別應用后，指定應用的優(yōu)先級根據(jù)應用的優(yōu)先級，改變報文的TOS/COS域指定應用的最小占用帶寬指定應用的最大占用帶寬ACFP協(xié)議ACFP Application control forward protocol，應用控制轉發(fā)協(xié)議，一種設備間的C/S（客戶端/服務端）模式的聯(lián)動框架。數(shù)據(jù)通信的基礎網(wǎng)絡主要由路由器、交換機這些設備組成，路由器、交換機完成了數(shù)據(jù)報文的轉發(fā)；隨著數(shù)據(jù)網(wǎng)絡的逐步發(fā)展，數(shù)據(jù)網(wǎng)絡上運行的業(yè)務也越來越多，路由器、交換機上支持的業(yè)務也越來越多，

53、這期間，一些專門的業(yè)務處理設備也應運而生，譬如，防火墻、IDS、IPS等安全產(chǎn)品，還有一些語音、無線產(chǎn)品。為更好地支撐這些業(yè)務，路由器、交換機這些傳統(tǒng)網(wǎng)絡設備也紛紛推出業(yè)務板（卡）專門來處理這些業(yè)務，有些傳統(tǒng)網(wǎng)絡設備（這里指路由器、交換機）的廠家提供一套軟硬件接口（譬如H3C提出的OAA 架構），允許其他廠家提供板（卡）的硬件或軟件，插入到傳統(tǒng)網(wǎng)絡設備上，協(xié)作處理這些業(yè)務，從而能發(fā)揮各廠家在各自領域的優(yōu)勢，更有效地支撐這些，并同時減低了用戶投資。OAA體系結構如下圖所示：OAA體系結構示意圖從圖中我們看到，OAA體系中，從硬件結構上看，可以分成三部分：路由交換部件、獨立業(yè)務部件、接口連接部件。

54、其中，路由交換部件就是路由器和交換機的主體部分，這部分有著完整的路由器或交換機的功能，也是用戶管理控制的核心；獨立業(yè)務部件則是可以開放給第三方合作開發(fā)的主體，主要用來提供各種獨特的業(yè)務服務功能；接口連接部件則是路由交換接部件和獨立業(yè)務部件的接口連接體，通過這個部件將兩個不同廠商的設備連接在一起，以形成一個統(tǒng)一的產(chǎn)品。這里需要指出的是，此處，獨立業(yè)務部件與路由交換部件是通過以太網(wǎng)相連。路由交換部件與獨立業(yè)務部件實際是兩個完全獨立的主體，這兩個主體如何協(xié)作完成某種特定業(yè)務，譬如，IPS業(yè)務，需要兩者的聯(lián)動，ACFP聯(lián)動規(guī)范主要定義的就是這兩者之間為協(xié)作完成業(yè)務而做的一系列工作。這種聯(lián)動是一種C/S

55、模式的聯(lián)動，獨立業(yè)務部件是ACFP Client，路由交換部件是ACFP Server；IDS等專門設備是ACFP Client，傳統(tǒng)網(wǎng)絡設備（主要指路由器、交換機）是ACFP Server。ACFP Client與ACFP Server之間允許以多對一的形式存在。根據(jù)ACFP Server與ACFP Client在報文流中的所處位置，將ACFP聯(lián)動的工作模式分為以下四類：主機模式、透傳模式、鏡像模式、重定向模式。主機模式主機模式下的報文流如下圖所示，報文流的正常轉發(fā)出接口同時也是連接ACFP Client的接口，ACFP Client是報文流的終結點。主機模式示意圖穿透模式穿透模式下的報文流

56、如下圖所示，報文流的正常轉發(fā)出接口同時也是連接ACFP Client的接口，報文流從ACFP Client中穿透而過。透傳模式示意圖鏡像模式鏡像模式下的報文流如下圖所示，報文流的正常轉發(fā)出接口與連接ACFP Client的接口不是同一個接口，報文流在正常轉發(fā)過程中，被復制一份遞給ACFP Client（紅色線條所示）。鏡像模式示意圖重定向模式重定向模式下的報文流如下圖所示，報文流的正常轉發(fā)出接口與連接ACFP Client的接口不是同一個接口，報文沒有被正常轉發(fā)，而是先遞給ACFP Client，ACFP Client分析處理后，再將報文原路遞回，接著報文再被ACFP Server正常轉發(fā)從出

57、接口發(fā)出去（如紅色線條所示）。重定向模式示意圖參考案例附錄資料：不需要的可以自行刪除OA是什么說起OA（Office Automation，辦公自動化），幾乎是人們都熟識和耳聞的一個IT名詞。然而什么是OA？卻是眾說紛紜、莫衷一是。這主要是因為隨著計算機技術、通信技術和網(wǎng)絡技術的突飛猛進，關于OA的描述也在不斷充實，但至今還沒有人對OA下過最權威、最科學、最全面、最準確的定義。其實OA的概念是動態(tài)的，進化論不管是其外延還是內(nèi)涵，已與十幾年前的OA發(fā)生了很大的變化?？傮w上講，它是指一切可滿足于企事業(yè)單位的、綜合型的、能夠提高單位內(nèi)部信息交流、共享、流轉處理的和實現(xiàn)辦公自動化和提高工作效率的各種信

58、息化設備和應用軟件；它不是孤立存在的，而是與企事業(yè)單位其它各類管理系統(tǒng)（如電子政務系統(tǒng)、電子商務系統(tǒng)、CRM系統(tǒng)、ERP系統(tǒng)、財務系統(tǒng)）密切相關、有機整合。一個獨立存在的OA辦公自動化系統(tǒng)生命力及作用是薄弱的。這也是目前最全面、最被認可的OA的概念。辦公自動化的發(fā)展經(jīng)歷了四個階段：從PC機加上個人辦公軟件實現(xiàn)的文字處理是第一個階段，這個階段大概在80年代到90年代初，大家主要是實現(xiàn)文字處理，就是單機的辦公自動化；第二個階段是局域網(wǎng)的出現(xiàn)，局域網(wǎng)和關系數(shù)據(jù)庫實現(xiàn)了文件共享、信息共享，這個應該在90年代的初期；第三個階段，這個階段的特點是以群件技術為基礎、以協(xié)同工作和知識管理為目標的辦公自動化。第

59、四個階段，即協(xié)同辦公門戶，這個階段的特點是OA系統(tǒng)作為整個組織內(nèi)部信息化的入口，相對于外部門戶（互聯(lián)網(wǎng)網(wǎng)站）。與組織內(nèi)各個業(yè)務系統(tǒng)進行集成，數(shù)據(jù)集中展現(xiàn)。OA軟件的效用從OA軟件近些年的發(fā)展來看，特別是進入OA第四個階段協(xié)同辦公門戶。具備以下七個方面的功效。(一)內(nèi)部通訊平臺建立組織內(nèi)部的郵件系統(tǒng)，短信系統(tǒng)，即時通訊系統(tǒng)、論壇、個人博客等，使組織內(nèi)部的通訊和信息交流快捷通暢。(二)信息發(fā)布平臺在內(nèi)部建立一個有效的信息發(fā)布和交流的場所，例如電子通告、新聞發(fā)布、電子論壇、電子刊物，使內(nèi)部的規(guī)章制度、新聞簡報、技術交流、公告事項等能夠在組織內(nèi)部員工之間得到廣泛的傳播，使員工能夠即時的了解組織內(nèi)部的發(fā)

60、展動態(tài)。(三)工作流程自動化這牽涉到流轉過程的實時監(jiān)控、跟蹤，解決多崗位、多部門之間的協(xié)同工作問題，實現(xiàn)高效率的協(xié)作。目前的企業(yè)和單位都存在著大量的工作流程，例如公文的處理、收發(fā)文、各種審批、請示、匯報，等等，都是一些流程化的工作，每個單位都會有大量的流程。通過實現(xiàn)工作流程的自動化，就可以規(guī)范各項工作，提高單位協(xié)同工作的效率，極大的減少中間環(huán)節(jié)的摩擦。（四）文檔管理的自動化使各類的文檔（包括各種文件、知識、信息）能夠按權限進行保存、共享和使用，并有一個方便的查找手段。（五）輔助辦公它牽涉的內(nèi)容比較多，像會議管理、車輛管理、辦公物品管理、圖書管理等與我們?nèi)粘＾k公事務性的工作相結合的各種輔助辦公，