在全球化發展之際，愈來愈多企業以分散式據點型態存在，而各地據點因應協同作業的需求，網路架構也逐漸轉換為集中式架構，除了資料中心所在的總部以外，其他據點都屬於遠端存取。順應企業遷移的趨勢，網路架構跟著改變，廣域網路應用加速的需求成長顯而易見。
以現有網路環境而言，ISP接上網際網路骨幹的頻寬相當大，企業內部區域網路的主流規格也正逐漸從1Gbps 過渡到10Gbps ，但是介於其間的廣域網路卻通常只有10∼100Mbps 的頻寬，連Gbps 等級都還不多見。懸殊的頻寬落差，造成應用程式使用時存在著許多問題，因為程式設計者無法針對這樣的頻寬落差特別去撰寫在不同通訊協定之間的運作流程。
以長遠的網路發展角度來看，即便未來有所謂次世代網路出現，頻寬可望大幅增加，但是廣域網路與區域網路之間頻寬的等級仍然會保持相當大的差距，簡單來說，廣域網路的速度永遠趕不上區域網路。
系統營運商為了讓廣域網路骨幹線路盡可能容納更多用戶，所以會採用最大容量的傳輸線路，然而企業若要在區域網路佈設高頻寬的線路，成本卻相對低廉，以致區域網路往往都可以具有與廣域網路相近等級的頻寬。當總公司及外點辦公室兩端都具有高速的區域網路頻寬，然而中間的廣域網路卻因為要提供多家用戶共同分享，因此成為傳輸的瓶頸。
傳輸資料激增頻寬日趨壅塞
頻寬落差使得用戶在透過廣域網路存取各種應用如檔案分享、電子郵件、資訊管理系統時，會比透過LAN 有相當明顯的速度差異，而廣域網路的效能不彰，往往會對企業營運造成影響。
常見的情況是，製造業通常因為研發單位、資料中心與工廠分散在世界各地，據點之間又須建立協同作業的機制，檔案傳輸效率扮演著企業營運的關鍵角色。又如金融業者因為具有許多分支據點，分公司每天與資料中心會進行無數次的溝通，商業軟體的回應速度影響著營運服務的效率。
要解決頻寬不足的問題，理所當然就從增加頻寬著手，然而廣域網路的線路租用價格昂貴，企業不可能無限制地增加頻寬。而且事實上，即使增加了頻寬，也未必就能讓企業的重要應用系統獲得充分的效能提升，因為應用程式彼此爭奪頻寬產生的排擠效應，往往也是企業應用程式回應速度緩慢的元兇。
網管人員都心知肚明，如果不對網路的使用加以管理，公司即使提供再大的頻寬，也可能會被同仁消耗殆盡。畢竟ERP 系統和視訊會議的流量，與P2P 下載或轉寄爆笑短片的流量，用的是同一條廣域網路連線，彼此競爭頻寬的結果，往往就算砸下預算擴充線路，重要的應用程式還是緩慢依舊。
協定效率低落導致延遲
廣域網路更令人困擾的問題，還有延遲（latency ）。即使不計成本添購頻寬，其實還是無法解決這個問題，因為單純加大廣域網路的傳輸容量，並不能減少隨著傳輸距離而遞增的線路延遲。例如台灣到美國西岸的純粹線路延遲大約是130ms ，這是距離造成的影響，就算把頻寬加大十倍，也無法讓這個延遲時間降低分毫。萬一中間還透過衛星傳輸，延遲會比經由海底光纖電纜再高5到10 倍。
更麻煩的是，大多數廣泛應用的傳輸協定，最初都不是針對低頻寬、高延遲的廣域網路環境而設計，往往會加劇廣域網路回應緩慢的程度。最常見的例子就是CIFS（Common Internet File System ）及MAPI （Messaging API ）等早期設計在區域網路下運作的傳輸協定。
微軟作業系統的網路芳鄰，是透過CIFS 協定來傳輸檔案，預設會將檔案切割成4KB 大小的區塊進行傳輸，伺服器每傳送一個區塊，要等收到確認訊息才會再傳送下一個。所以即使簡單的操作例如將一個遠端分享的檔案拖曳到本地桌面上，可能都得在主機與伺服器間來回通訊多達三、四千次。由於線路本身的延遲會造成大量來回加乘的效應，因此CIFS 或MAPI 即使只是稍微增加傳輸的距離，就會造成回應所需的時間激增。新一代的微軟作業系統對此稍微做了改善，但一般相信，至少幾年內這個問題仍然還不會消失。
然而可不是只有微軟的應用程式才會受到這麼大的影響。瀏覽器介面的HTTP 應用程式，在高延遲廣域網路上的回應速度同樣不忍卒睹。這主要是受到往返交談的通訊協定，以及重複傳輸所造成的影響。瀏覽器每次都會從伺服器下載頁面上的每個物件與小圖示，如果有比較大的物件，往往得分兩三回才能傳輸完。萬一使用者覺得不耐而按下〔重新整理〕，即使只有一個小圖標有改變，瀏覽器還是會把頁面上所有的物件再下載一次，結果又讓回應速度變得更慢。
壓縮、資料減量初步紓解頻寬
由於廣域網路應用傳輸的效能問題原因如此複雜，因此絕非依賴單一技術就能處理，勢必得混合運用多樣化的頻寬管理與加速技術。目前市場上各家廠商的廣域網路應用加速產品，就紛紛運用了多樣化技術來解決廣域網路的問題並縮短應用程式的回應時間。必備的類型包括流量管理（例如頻寬分級管理或流量塑形）、資料複製或減量（包括壓縮或快取等）、針對TCP 或HTTP 等通用協定進行加速，以及針對特定應用（例如微軟的CIFS 檔案共享協定）的最佳化。
在這些層面中主要涉及的技術包括壓縮（Compression ）、重複片段快取（Sequence Caching 或Delta Caching ）、協定代理（Protocol Spoofing ）、TCP 最佳化、頻寬管理（QoS ）、流量塑形（Traffic Shap-ing ）及加密通道（Encrypted Tunnel ）等。位於資料中心端的設備，則可能還會具有一些協助伺服器卸載（Off-Load ）的設計，例如負載平衡、TCP 連線管理、SSL 加密或網路應用防火牆等，當然也負責處理壓縮及快取。
對廣域網路最佳化設備而言，「壓縮」當然是必備的技術，最直接解決頻寬不足的問題，用以減少實際的資料傳輸量，以便適應有限的廣域網路頻寬，讓資料能在更短的時間內傳輸完成，用戶也就感覺到網路效能變快了。
不過，並非一味進行壓縮就可以發揮加速的效果。由於壓縮作業本身的運算也會產生一定程度的延遲，如果資料的壓縮比不高，像MPEG 檔案等內容原本就已經壓縮過的格式，額外再予以壓縮的效益不大，只會徒增延遲，還不如直接傳送，廣域網路應用加速設備應能依據傳輸的內容判斷是否需要進行壓縮。
快取技術減少重複資料傳輸
快取技術則是另一個加速廣域網路的法寶。廠商對於各自的快取技術都有不同的名目描述，不過大致上都是將經由廣域網路傳輸的封包打散成更小的片段，並賦予每個片段唯一的指標（稱為index 或to-ken），只要在後續的傳輸過程中偵測到是傳輸完全相同的資料片段，伺服器端的裝置就只傳送其指標，讓接收端裝置依指標直接將先前快取暫存的資料傳送給用戶。
在同一個分公司據點中的使用者，往往傳輸的都是內容相同或相似的資料，因此採用快取技術的效益特別明顯。例如傳輸一份簡報文件時，其實每一頁的頭尾外框Logo 都相同，運用快取技術就毋須重複傳送這些片段，接著如果只是稍作修改之後回傳，廣域網路最佳化設備更只需傳送少部分變更過的片段，速度就更快了。
這種重複片段快取技術通常稱為Sequence Cache 或Delta Cache ，理論上只要解析的片段夠小，重複傳送相同指標的機率就會提高，只須由接收端的設備直接提供資料，因而可以節省許多等待傳輸的時間與頻寬。當然切成太小的片段又會造成需要往來傳輸比對的指標過多，所以必須取其平衡。由於解析片段的最小單位可以直達Byte ，因此也被稱為位元組快取（Byte-cache ），基本上與應用程式沒有直接的關係，在經常重複傳送近似資料的場合十分有效。相較之下，傳統的檔案快取（File Cache ）方式由於解析單位太大，在廣域網路加速中意義不大。
頻寬管理確保關鍵應用順暢
 |
| ▲Blue Coat深資技術總監曾良駿認為，廣域網路流量的加速必須建立在安全的基礎上，如果對好的、壞的流量都一視同仁給予加速，反而對企業不利。 |
除了物元組快取，Blue Coat 另有獨特的物件快取（Object Cache ）技術，可以「物件」為單位進行快取加速，則對於Web-based 應用（每次頁面上都有重複的Icon 等物件）、網路檔案分享以及串流媒體分享等，具有顯著的加速效果。Blue Coat 資深技術總監曾良駿表示，對於這些類型的傳輸，若以Byte Cache 技術進行加速，由於無法察覺個別應用程式相關的單一物件，因此還是必須往來核對許多token 以便確認各資料片段是否重複，效率當然不如Object Cache 整個物件只須傳送一個Token 來得快。
Citrix 的WANScaler 系列，運用的則是封包快取（Packet Cache ）技術。封包快取技術不像Byte Cache 需要傳輸那麼多Token 影響效能，但是也不像File Cache 因為快取的基本單位較大所以加速效果較差，算是比較中庸平衡的做法。由於是以封包為單位來進行快取，所以與傳輸資料的應用程式無關，即使是專屬開發的特殊應用程式也可以應付自如。
不過，壓縮及快取技術只對於減少頻寬消耗有幫助，而且也並非絕對有效。理由已經在前面說明過了，因為「延遲」是廣域網路效能低落的最大元兇，而壓縮或快取並無法減輕線路延遲所造成的影響。如果營運所需的應用程式或傳輸流量，能不受廣域網路上其他次要的流量所排擠，甚至享有優先傳輸或保障頻寬，那麼也能有效的提升使用者感受到的遠端回應速度。畢竟企業即使不限制員工如何使用網路，至少沒有義務保證非公務必須的流量也要給予最好的頻寬條件。
 |
| ▲零壹科技網路加值部協理林顯山強調，想要提高關鍵應用的回應速度，最重要卻也是最容易被忽視的第一個步驟，其實是對廣域網路所有傳輸的應用進行透視、分析。 |
企業通常不會為特定應用租用1條專屬的線路，一般的狀況是，無論大小或重要性，所有的應用全都擠在同一WAN 線路中，每逢尖峰時段，一條線路當中可能同時存在多種應用一起搶占頻寬，如此一來，很可能會發生無關緊要的應用頻頻占用大部分的頻寬，但是關鍵應用卻無法享有穩定而充足頻寬的情形。因此頻寬管理也是廣域網路最佳化方案常見的功能，讓企業得以為重要的應用優先保留頻寬。
分析透視應用流量政策第一步
零壹科技網路加值部協理林顯山認為，許多業界的廣域網路最佳化方案業者，往往過度誇大了快取的功用，快取功能只有對於重複傳輸的內容才能發揮加速作用，其實對於大多數的企業應用來說，重複內容並不是主要的問題所在，尤其像交易性的資料庫存取等狀況，由於不會重複傳輸，快取技術的加速效果有限。
因此要提高企業關鍵應用的回應速度，真正的重點在於流量的管理，然後配合壓縮、協定最佳化等技術，才能發揮效果。他認為最重要卻最也最容易被忽略的第一步，就是對企業廣域網路傳輸的流量進行透視、分析，先了解到底有哪些應用在傳輸及其性質，接下來則由企業依據實際狀況制定政策，決定何種應用程式的流量應該優先，以保障企業重要應用的頻寬及傳輸優先等級。制定政策當然有許多必須斟酌之處，這方面廠商可以提供諮詢建議，但實際的拿捏仍應該由企業自行確定，才能符合實際的需求。
 |
| ▲零壹科技產品經理余仲平建議，企業可依「重要性」與「即時性」兩個向度來評估頻應用程式的頻寬管理政策。 |
零壹科技網路加值部產品經理余仲平也指出，就企業廣域網路上的應用程式而言，可以依據「重要性」與「即時性」兩個向度來評估，對最需要確保快速回應的應用流量採取保障措施，不過對於不需要的流量則需要適當考量。例如對於員工休閒性質的應用，直接予以封鎖頻寬是否適當？或者對於系統無法辨識的不明應用程式流量，應該採取何種處置？先管理好流量政策之後，接下來對傳輸的資料加以壓縮、減量，並透過協定的最佳化、重複資料快取、雙邊檔案傳輸的同步一致性以及存取權限等進行優化及管理，發揮真正的頻寬資源效率化。
頻寬流量管理或壓縮快取都是早期就被運用於廣域網路加速的技術，主要也都是針對頻寬不足，因此線路延遲的問題就成為目前遠端應用程式效能的主要限制。
為了解決傳輸協定無效率的問題，針對常見協定的最佳化技術也很重要。企業需要同時針對一般及特定應用的通訊協定進行加速，以便降低線路延遲對於遠端應用程式造成的效能影響。
這方面也是目前許多廠商研發競爭的部份，能提供愈多樣化的應用協定最佳化功能，就愈能夠滿足不同企業用戶的需求，因此很多廠商同時提供針對TCP 、HTTP 以及微軟的CIFS（Common Internet File System ）等協定的加速，並與各種應用軟體系統業者合作，針對企業常用的特定應用系統進行最佳化。