架構文摘：Linux負載均衡總結性說明

在正常運維工作中，經常會運用到負載均衡服務。負載均衡分為四層負載和七層負載，那麼這兩者之間有什麼不同？

一、什麼是負載均衡

負載均衡（Load Balance）建立在現有網絡結構之上，它提供了一種廉價有效透明的方法擴充網絡裝置和伺服器的帶寬、增加吞吐量、加強網絡資料處理能力、提高網絡的靈活性和可用性。

負載均衡有兩方面的含義：

• 首先，大量的并發通路或資料流量分擔到多台節點裝置上分别處理，減少使用者等待響應的時間；
• 其次，單個重負載的運算分擔到多台節點裝置上做并行處理，每個節點裝置處理結束後，将結果彙總，傳回給使用者，系統處理能力得到大幅度提高。

簡單來說就是：

• 其一，是将大量的并發處理轉發給後端多個節點處理，減少工作響應時間；
• 其二，是将單個繁重的工作轉發給後端多個節點處理，處理完再傳回給負載均衡中心，再傳回給使用者。

目前負載均衡技術大多數是用于提高諸如在Web伺服器、FTP伺服器和其它關鍵任務伺服器上的Internet伺服器程式的可用性和可伸縮性。

二、負載均衡分類

對于負載均衡，主要分為以下幾類：

• 二層負載均衡（mac）

  一般采用虛拟mac位址方式，外部對虛拟MAC位址請求，負載均衡接收後配置設定後端實際的MAC位址響應）

• 三層負載均衡（ip）

  一般采用虛拟IP位址方式，外部對虛拟的ip位址請求，負載均衡接收後配置設定後端實際的IP位址響應）

• 四層負載均衡（tcp）

  在三次負載均衡的基礎上，用IP+PORT接收請求，再轉發到對應的機器。

• 七層負載均衡（http）

  根據虛拟的URL或IP，主機名接收請求，再轉向相應的處理伺服器。

我們運維中最常見的是四層和七層負載均衡，這裡重點說下這兩種負載均衡。

• 四層負載均衡就是基于IP+端口的負載均衡：在三層負載均衡的基礎上，通過釋出三層的IP位址（VIP），然後加上四層的端口号，來決定哪些流量需要做負載均衡，對需要處理的流量進行NAT處理，轉發至背景伺服器，并記錄下這個TCP或者UDP的流量是由哪台伺服器處理的，後續這個連接配接的所有流量都同樣轉發到同一台伺服器處理。

四層負載均衡對應的負載均衡器稱為四層交換機（L4 switch），主要分析IP層及TCP/UDP層，實作四層負載均衡。此種負載均衡器不了解應用協定（如HTTP/FTP/MySQL等等）。

實作四層負載均衡的軟體有：

F5：硬體負載均衡器，功能很好，但是成本很高
LVS：重量級的四層負載軟體
Nginx：輕量級的四層負載軟體，帶緩存功能，正規表達式較靈活
Haproxy：模拟四層轉發，較靈活
           

• 七層負載均衡就是基于虛拟的URL或主機IP的負載均衡：在四層負載均衡的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特征，比如同一個Web伺服器的負載均衡，除了根據VIP加80端口辨識是否需要處理的流量，還可根據七層的URL、浏覽器類别、語言來決定是否要進行負載均衡。舉個例子，如果你的Web伺服器分成兩組，一組是中文語言的，一組是英文語言的，那麼七層負載均衡就可以當使用者來通路你的域名時，自動辨識使用者語言，然後選擇對應的語言伺服器組進行負載均衡處理。

七層負載均衡對應的負載均衡器稱為七層交換機（L7 switch），除了支援四層負載均衡以外，還有分析應用層的資訊，如HTTP協定URI或Cookie資訊，實作七層負載均衡。此種負載均衡器能了解應用協定。

實作七層負載均衡的軟體有：

Haproxy：天生負載均衡技能，全面支援七層代理，會話保持，标記，路徑轉移
Nginx：隻在http協定和mail協定上功能比較好，性能與haproxy差不多
Apache：功能較差
Mysql Proxy：功能尚可
           

總的來說，一般使用LVS做4層負載，Nginx做7層負載，Haproxy則比較靈活，能同時支援4層和7層負載均衡。

三、四層負載均衡與七層負載均衡對比

1. 從技術原理上分析

所謂四層負載均衡，也就是主要通過封包中的目标位址和端口，再加上負載均衡裝置設定的伺服器選擇方式，決定最終選擇的内部伺服器。

以常見的TCP為例，負載均衡裝置在接收到第一個來自用戶端的SYN 請求時，即通過上述方式選擇一個最佳的伺服器，并對封包中目标IP位址進行修改(改為後端伺服器IP），直接轉發給該伺服器。TCP的連接配接建立，即三次握手是用戶端和伺服器直接建立的，負載均衡裝置隻是起到一個類似路由器的轉發動作。在某些部署情況下，為保證伺服器回包可以正确傳回給負載均衡裝置，在轉發封包的同時可能還會對封包原來的源位址進行修改。

所謂七層負載均衡，也稱為“内容交換”，也就是主要通過封包中的真正有意義的應用層内容，再加上負載均衡裝置設定的伺服器選擇方式，決定最終選擇的内部伺服器。

以常見的TCP為例，負載均衡裝置如果要根據真正的應用層内容再選擇伺服器，隻能先代理最終的伺服器和用戶端建立連接配接(三次握手)後，才可能接受到用戶端發送的真正應用層内容的封包，然後再根據該封包中的特定字段，再加上負載均衡裝置設定的伺服器選擇方式，決定最終選擇的内部伺服器。負載均衡裝置在這種情況下，更類似于一個代理伺服器。負載均衡和前端的用戶端以及後端的伺服器會分别建立TCP連接配接。是以從這個技術原理上來看，七層負載均衡明顯的對負載均衡裝置的要求更高，處理七層的能力也必然會低于四層模式的部署方式。

2. 從應用場景的需求上分析

七層應用負載的好處，是使得整個網絡更”智能化“。可以參考這篇：http應用優化和加速說明-負載均衡，就可以基本上了解這種方式的優勢所在。例如通路一個網站的使用者流量，可以通過七層的方式，将對圖檔類的請求轉發到特定的圖檔伺服器并可以使用緩存技術；将對文字類的請求可以轉發到特定的文字伺服器并可以使用壓縮技術。當然這隻是七層應用的一個小案例，從技術原理上，這種方式可以對用戶端的請求和伺服器的響應進行任意意義上的修改，極大地提升了應用系統在網絡層的靈活性。很多在背景，例如Nginx或者Apache上部署的功能可以前移到負載均衡裝置上，例如客戶請求中的Header重寫，伺服器響應中的關鍵字過濾或者内容插入等功能。

另外一個常常被提到的功能就是安全性。網絡中最常見的SYN Flood攻擊，即黑客控制衆多源用戶端，使用虛假IP位址對同一目标發送SYN攻擊，通常這種攻擊會大量發送SYN封包，耗盡伺服器上的相關資源，以達到拒絕服務（Denial of Service, DoS）的目的。從技術原理上也可以看出，四層模式下這些SYN攻擊都會被轉發到後端的伺服器上；而七層模式下這些SYN攻擊自然在負載均衡裝置上就截止，不會影響背景伺服器的正常營運。另外負載均衡裝置可以在七層層面設定多種政策，過濾特定封包，例如SQL Injection等應用層面的特定攻擊手段，從應用層面進一步提高系統整體安全。

現在的七層負載均衡，主要還是着重于應用HTTP協定，是以其應用範圍主要是衆多的網站或者内部資訊平台等基于B/S開發的系統。 四層負載均衡則對應其他TCP應用，例如基于C/S開發的ERP等系統。

3. 七層應用需要考慮的問題

1. 是否真的必要。七層應用的确可以提高流量智能化，同時必然不可避免地帶來裝置配置複雜，負載均衡壓力增高以及故障排查上的複雜性等問題。在設計系統時需要考慮四層七層同時應用的混雜情況。
2. 是否真的可以提高安全性。例如SYN Flood攻擊，七層模式的确将這些流量從伺服器屏蔽，但負載均衡裝置本身要有強大的抗DDoS能力，否則即使伺服器正常而作為中樞排程的負載均衡裝置故障也會導緻整個應用的崩潰。
3. 是否有足夠的靈活度。七層應用的優勢是可以讓整個應用的流量智能化，但是負載均衡裝置需要提供完善的七層功能，滿足客戶根據不同情況的基于應用的排程。最簡單的一個考核就是能否取代背景Nginx或者Apache等伺服器上的排程功能。能夠提供一個七層應用開發接口的負載均衡裝置，可以讓客戶根據需求任意設定功能，才真正有可能提供強大的靈活性和智能性。

4. 總體對比

• 智能性

七層負載均衡由于具備OSI七層的所有功能，是以在處理使用者需求上能更加靈活，從理論上講，七層模型能對使用者的所有向服務端的請求進行修改。例如對檔案header添加資訊，根據不同的檔案類型進行分類轉發。四層模型僅支援基于網絡層的需求轉發，不能修改使用者請求的内容。

• 安全性

七層負載均衡由于具有OSI模型的全部功能，能更容易抵禦來自網絡的攻擊；四層模型從原理上講，會直接将使用者的請求轉發給後端節點，無法直接抵禦網絡攻擊。

• 複雜度

四層模型的架構一般比較簡單，容易管理，容易定位問題；七層模型架構比較複雜，通常也需要考慮結合四層模型的混用情況，出現問題定位比較複雜。

• 效率比

四層模型基于更底層的設定，通常效率更高，但應用範圍有限；七層模型需要更多的資源損耗，在理論上講比四層模型有更強的功能，現在的實作更多是基于http應用。

四、負載均衡技術方案說明

目前有許多不同的負載均衡技術用以滿足不同的應用需求，下面從負載均衡所采用的裝置對象（軟/硬體負載均衡），應用的OSI網絡層次（網絡層次上的負載均衡），及應用的地理結構（本地/全局負載均衡）等來分類。

1. 軟/硬體負載均衡

軟體負載均衡解決方案是指在一台或多台伺服器相應的作業系統上安裝一個或多個附加軟體來實作負載均衡，如DNS Load Balance，KeepAlive+ipvs等，它的優點是基于特定環境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求。軟體解決方案缺點也較多，因為每台伺服器上安裝額外的軟體運作會消耗系統不定量的資源，越是功能強大的子產品，消耗得越多，是以當連接配接請求特别大的時候，軟體本身會成為伺服器工作成敗的一個關鍵；軟體可擴充性并不是很好，受到作業系統的限制；由于作業系統本身的Bug，往往會引起安全問題。

硬體負載均衡解決方案是直接在伺服器和外部網絡間安裝負載均衡裝置，這種裝置通常是一個獨立于系統的硬體，我們稱之為負載均衡器。由于專門的裝置完成專門的任務，獨立于作業系統，整體性能得到大量提高，加上多樣化的負載均衡政策，智能化的流量管理，可達到最佳的負載均衡需求。負載均衡器有多種多樣的形式，除了作為獨立意義上的負載均衡器外，有些負載均衡器內建在交換裝置中，置于伺服器與Internet連結之間，有些則以兩塊網絡擴充卡将這一功能內建到PC中，一塊連接配接到Internet上，一塊連接配接到後端伺服器群的内部網絡上。

軟體負載均衡與硬體負載均衡的對比：

• 軟體負載均衡的優點是需求環境明确，配置簡單，操作靈活，成本低廉，效率不高，能滿足普通的企業需求。缺點是依賴于系統，增加資源開銷；軟體的優劣決定環境的性能；系統的安全，軟體的穩定性均會影響到整個環境的安全。
• 硬體負載均衡優點是獨立于系統，整體性能大量提升，在功能、性能上優于軟體方式；智能的流量管理，多種政策可選，能達到最佳的負載均衡效果。缺點是價格昂貴。

2. 本地/全局負載均衡

負載均衡從其應用的地理結構上分為本地負載均衡（Local Load Balance）和全局負載均衡（Global Load Balance，也叫地域負載均衡）。本地負載均衡是指對本地的伺服器群做負載均衡，全局負載均衡是指對分别放置在不同的地理位置、有不同網絡結構的伺服器群間作負載均衡。

本地負載均衡能有效地解決資料流量過大、網絡負荷過重的問題，并且不需花費昂貴開支購置性能卓越的伺服器，充分利用現有裝置，避免伺服器單點故障造成資料流量的損失。其有靈活多樣的均衡政策把資料流量合理地配置設定給伺服器群内的伺服器共同負擔。即使是再給現有伺服器擴充更新，也隻是簡單地增加一個新的伺服器到服務群中，而不需改變現有網絡結構、停止現有的服務。

全局負載均衡主要用于在一個多區域擁有自己伺服器的站點，為了使全球使用者隻以一個IP位址或域名就能通路到離自己最近的伺服器，進而獲得最快的通路速度，也可用于子公司分散站點分布廣的大公司通過Intranet（企業内部網際網路）來達到資源統一合理配置設定的目的。

3. 網絡層次上的負載均衡

針對網絡上負載過重的不同瓶頸所在，從網絡的不同層次入手，我們可以采用相應的負載均衡技術來解決現有問題。

随着帶寬增加，資料流量不斷增大，網絡核心部分的資料接口将面臨瓶頸問題，原有的單一線路将很難滿足需求，而且線路的更新又過于昂貴甚至難以實作，這時就可以考慮采用鍊路聚合（Trunking）技術。

鍊路聚合技術（第二層負載均衡）将多條實體鍊路當作一條單一的聚合邏輯鍊路使用，網絡資料流量由聚合邏輯鍊路中所有實體鍊路共同承擔，由此在邏輯上增大了鍊路的容量，使其能滿足帶寬增加的需求。

現代負載均衡技術通常操作于網絡的第四層或第七層。第四層負載均衡将一個Internet上合法注冊的IP位址映射為多個内部伺服器的IP位址，對每次 TCP連接配接請求動态使用其中一個内部IP位址，達到負載均衡的目的。在第四層交換機中，此種均衡技術得到廣泛的應用，一個目标位址是伺服器群VIP（虛拟 IP，Virtual IP address）連接配接請求的資料包流經交換機，交換機根據源端和目的IP位址、TCP或UDP端口号和一定的負載均衡政策，在伺服器IP和VIP間進行映射，選取伺服器群中最好的伺服器來處理連接配接請求。

七層負載均衡控制應用層服務的内容，提供了一種對通路流量的高層控制方式，适合對HTTP伺服器群的應用。第七層負載均衡技術通過檢查流經的HTTP報頭，根據報頭内的資訊來執行負載均衡任務。

七層負載均衡優點表現在如下幾個方面：

• 通過對HTTP報頭的檢查，可以檢測出HTTP 400、500和600系列的錯誤資訊，因而能透明地将連接配接請求重新定向到另一台伺服器，避免應用層故障。
• 可根據流經的資料類型（如判斷資料包是圖像檔案、壓縮檔案或多媒體檔案格式等），把資料流量引向相應内容的伺服器來處理，增加系統性能。
• 能根據連接配接請求的類型，如是普通文本、圖象等靜态文檔請求，還是asp、cgi等的動态文檔請求，把相應的請求引向相應的伺服器來處理，提高系統的性能及安全性。

七層負載均衡缺點表現在如下幾個方面：

• 七層負載均衡受到其所支援的協定限制（一般隻有HTTP），這樣就限制了它應用的廣泛性。
• 七層負載均衡檢查HTTP報頭會占用大量的系統資源，勢必會影響到系統的性能，在大量連接配接請求的情況下，負載均衡裝置自身容易成為網絡整體性能的瓶頸。

五、負載均衡政策

在實際應用中，我們可能不想僅僅是把用戶端的服務請求平均地配置設定給内部伺服器，而不管伺服器是否當機。而是想使Pentium III伺服器比Pentium II能接受更多的服務請求，一台處理服務請求較少的伺服器能配置設定到更多的服務請求，出現故障的伺服器将不再接受服務請求直至故障恢複等等。選擇合适的負載均衡政策，使多個裝置能很好的共同完成任務，消除或避免現有網絡負載分布不均、資料流量擁擠反應時間長的瓶頸。在各負載均衡方式中，針對不同的應用需求，在OSI參考模型的第二、三、四、七層的負載均衡都有相應的負載均衡政策。

負載均衡政策的優劣及其實作的難易程度有兩個關鍵因素：負載均衡算法以及對網絡系統狀況的檢測方式和能力。

1. 負載均衡算法

（1）輪詢均衡（Round Robin）：每一次來自網絡的請求輪流配置設定給内部中的伺服器，從1至N然後重新開始。此種均衡算法适合于伺服器組中的所有伺服器都有相同的軟硬體配置并且平均服務請求相對均衡的情況。

（2）權重輪詢均衡（Weighted Round Robin）：根據伺服器的不同處理能力，給每個伺服器配置設定不同的權值，使其能夠接受相應權值數的服務請求。例如：伺服器A的權值被設計成1，B的權值是 3，C的權值是6，則伺服器A、B、C将分别接受到10%、30％、60％的服務請求。此種均衡算法能確定高性能的伺服器得到更多的使用率，避免低性能的伺服器負載過重。

（3）随機均衡（Random）：把來自網絡的請求随機配置設定給内部中的多個伺服器。

（4）權重随機均衡（Weighted Random）：此種均衡算法類似于權重輪循算法，不過在處理請求分擔時是個随機選擇的過程。

（5）響應速度均衡（Response Time）：負載均衡裝置對内部各伺服器發出一個探測請求（例如Ping），然後根據内部中各伺服器對探測請求的最快響應時間來決定哪一台伺服器來響應用戶端的服務請求。此種均衡算法能較好的反映伺服器的目前運作狀态，但這最快響應時間僅僅指的是負載均衡裝置與伺服器間的最快響應時間，而不是用戶端與伺服器間的最快響應時間。

（6）最少連接配接數均衡（Least Connection）：用戶端的每一次請求服務在伺服器停留的時間可能會有較大的差異，随着工作時間加長，如果采用簡單的輪詢或随機均衡算法，每一台伺服器上的連接配接程序可能會産生極大的不同，并沒有達到真正的負載均衡。最少連接配接數均衡算法對内部中需負載的每一台伺服器都有一個資料記錄，記錄目前該伺服器正在處理的連接配接數量，當有新的服務連接配接請求時，将把目前請求配置設定給連接配接數最少的伺服器，使均衡更加符合實際情況，負載更加均衡。此種均衡算法适合長時處理的請求服務，如FTP。

（7）處理能力均衡：此種均衡算法将把服務請求配置設定給内部中處理負荷（根據伺服器CPU型号、CPU數量、記憶體大小及目前連接配接數等換算而成）最輕的伺服器，由于考慮到了内部伺服器的處理能力及目前網絡運作狀況，是以此種均衡算法相對來說更加精确，尤其适合運用到第七層（應用層）負載均衡的情況下。

（8）DNS響應均衡（Flash DNS）：在Internet上，無論是HTTP、FTP或是其它的服務請求，用戶端一般都是通過域名解析來找到伺服器确切的IP位址的。在此均衡算法下，分處在不同地理位置的負載均衡裝置收到同一個用戶端的域名解析請求，并在同一時間内把此域名解析成各自相對應伺服器的IP位址（即與此負載均衡裝置在同一位地理位置的伺服器的IP位址）并傳回給用戶端，則用戶端将以最先收到的域名解析IP位址來繼續請求服務，而忽略其它的IP位址響應。在種均衡政策适合應用在全局負載均衡的情況下，對本地負載均衡是沒有意義的。

2. 網絡系統狀況的檢測方式

盡管有多種的負載均衡算法可以較好的把資料流量配置設定給伺服器去負載，但如果負載均衡政策沒有對網絡系統狀況的檢測方式和能力，一旦在某台伺服器或某段負載均衡裝置與伺服器網絡間出現故障的情況下，負載均衡裝置依然把一部分資料流量引向那台伺服器，這勢必造成大量的服務請求被丢失，達不到不間斷可用性的要求。是以，良好的負載均衡政策應有對網絡故障、伺服器系統故障、應用服務故障的檢測方式和能力。通常的檢測方式包括：

（1）Ping偵測：通過ping的方式檢測伺服器及網絡系統狀況，此種方式簡單快速，但隻能大緻檢測出網絡及伺服器上的作業系統是否正常，對伺服器上的應用服務檢測就無能為力了。

（2）TCP Open偵測：每個服務都會開放某個通過TCP連接配接，檢測伺服器上某個TCP端口（如Telnet的23口，HTTP的80口等）是否開放來判斷服務是否正常。

（3）HTTP URL偵測：比如向HTTP伺服器發出一個對main.html檔案的通路請求，如果收到錯誤資訊，則認為伺服器出現故障。

3、其他因素

負載均衡政策的優劣除受上面所講的兩個因素影響外，在有些應用情況下，我們需要将來自同一用戶端的所有請求都配置設定給同一台伺服器去負擔，例如伺服器将用戶端注冊、購物等服務請求資訊儲存的本地資料庫的情況下，把用戶端的子請求配置設定給同一台伺服器來處理就顯的至關重要了。有幾種方式可以解決此問題：

（1）一是根據IP位址把來自同一用戶端的多次請求配置設定給同一台伺服器處理，用戶端IP位址與伺服器的對應資訊是儲存在負載均衡裝置上的。

（2）二是在用戶端浏覽器 cookie内做獨一無二的辨別來把多次請求配置設定給同一台伺服器處理，适合通過代理伺服器上網的用戶端。

（3）還有一種路徑外傳回模式（Out of Path Return），當用戶端連接配接請求發送給負載均衡裝置的時候，中心負載均衡裝置将請求引向某個伺服器，伺服器的回應請求不再傳回給中心負載均衡裝置，即繞過流量配置設定器，直接傳回給用戶端，是以中心負載均衡裝置隻負責接受并轉發請求，其網絡負擔就減少了很多，并且給用戶端提供了更快的響應時間。此種模式一般用于HTTP伺服器群，在各伺服器上要安裝一塊虛拟網絡擴充卡，并将其IP位址設為伺服器群的VIP，這樣才能在伺服器直接回應用戶端請求時順利的達成三次握手。

六、負載均衡實施要素

1. 性能

性能是我們在引入均衡方案時需要重點考慮的問題，但也是一個最難把握的問題。衡量性能時可将每秒鐘通過網絡的資料包數目做為一個參數，另一個參數是均衡方案中伺服器群所能處理的最大并發連接配接數目，但是，假設一個均衡系統能處理百萬計的并發連接配接數，可是卻隻能以每秒2個包的速率轉發，這顯然是沒有任何作用的。

性能的優劣與負載均衡裝置的處理能力、采用的均衡政策息息相關，并且有兩點需要注意：

• 均衡方案對伺服器群整體的性能，這是響應用戶端連接配接請求速度的關鍵；
• 負載均衡裝置自身的性能，避免有大量連接配接請求時自身性能不足而成為服務瓶頸。

有時我們也可以考慮采用混合型負載均衡政策來提升伺服器群的總體性能，如DNS負載均衡與NAT負載均衡相結合。另外，針對有大量靜态文檔請求的站點，也可以考慮采用高速緩存技術，相對來說更節省費用，更能提高響應性能；對有大量

ssl/xml内容傳輸的站點，更應考慮采用ssl/xml加速技術。

2. 可擴充性

IT技術日新月異，一年以前最新的産品，現在或許已是網絡中性能最低的産品；業務量的急速上升，一年前的網絡，現在需要新一輪的擴充。合适的均衡解決方案應能滿足這些需求，能均衡不同作業系統和硬體平台之間的負載，能均衡HTTP、郵件、新聞、代理、資料庫、防火牆和 Cache等不同伺服器的負載，并且能以對用戶端完全透明的方式動态增加或删除某些資源。

3. 靈活性

均衡解決方案應能靈活地提供不同的應用需求，滿足應用需求的不斷變化。在不同的伺服器群有不同的應用需求時，應有多樣的均衡政策提供更廣泛的選擇。

4. 可靠性

在對服務品質要求較高的站點，負載均衡解決方案應能為伺服器群提供完全的容錯性和高可用性。但在負載均衡裝置自身出現故障時，應該有良好的備援解決方案，提高可靠性。使用備援時，處于同一個備援單元的多個負載均衡裝置必須具有有效的方式以便互相進行監控，保護系統盡可能地避免遭受到重大故障的損失。

5. 易管理性

不管是通過軟體還是硬體方式的均衡解決方案，我們都希望它有靈活、直覺和安全的管理方式，這樣便于安裝、配置、維護和監控，提高工作效率，避免差錯。在硬體負載均衡裝置上，目前主要有三種管理方式可供選擇：

• 指令行接口（CLI：Command Line Interface），可通過超級終端連接配接負載均衡裝置串行接口來管理，也能telnet遠端登入管理，在初始化配置時，往往要用到前者；
• 圖形使用者接口（GUI：Graphical User Interfaces），有基于普通web頁的管理，也有通過Java Applet 進行安全管理，一般都需要管理端安裝有某個版本的浏覽器；
• SNMP（Simple Network Management Protocol，簡單網絡管理協定）支援，通過第三方網絡管理軟體對符合SNMP标準的裝置進行管理。