粒度：
交換機（二層）：目的MAC地址
路由器（三層）：目的IP地址
防火牆和負載均衡器（四層）：會話
會話的標記為：從同一個域到域的數據流，以第一個SYN數據包的源和目的IP地址及其源和目的端口為標識
防火牆特性：
- 將所有會話做監控管理，默認限制所有會話，再逐一放行會話。
注意：如上會話標記的定義，如果限定了從192.13.2.1:23發送數據到182.12.12.1:12，是無法同時限定從182.12.12.1:12發送數據到192.13.2.1:23，記住會話是雙向的。
2.NAT
用途
a.解決地址緊張的問題
b.更安全，由於用戶端IP地址未暴露在互聯網，用戶側更安全，運營商也可以防止用戶上掛惡意內容在互聯網
問題：
多通道協議受阻，alg解決問題。比如ftp控制和數據分離。
注意：如上條注意，會話是雙向的，NAT基於會話的，也同樣是雙向的。基於源IP或者IP:PORT,是源NAT；基於目的IP或者IP:PORT，是目的NAT。
3.VPN
主要用途：a.認證,雙方身份確認；b.鑒權，授權可以使用的服務和數據流；c.加密，對數據流進行加密處理；d.網絡擴展，實現遠端網絡本地化
分類：基於不同的套接層，分為——二層L2TP,三層MPLS/GRE/IPSEC,七層SSL（SSL_VPN/SSH）
以下為華為防火牆數據流處理過程：
負載均衡（F5/Citrix）
不管是交換機，路由器，還是防火牆，對數據包的處理，總得來說都是兩個過程。
- 首先是按照粒度識別數據流，然后進行匹配歸類
這個歸類交換機查詢的是MAC地址表，路由器查詢的是IP路由表，防火牆查詢的是會話列表等
- 然后是再處理的過程，一般是轉發處理。
一般有兩種可能，一是多出口；二是基於不同的Qos考慮是否緩存延遲發送，還是丟棄。
負載均衡器處理方式是什么呢？
識別過程：
基於MAC/IP/端口號（協議）/http頭（host、url、文件格式、瀏覽器、操作系統等）,進而歸類；
轉發過程（負載均衡的前提是多出口）：
a.根據是否超過出口設定的閾值，分為以下兩種情況：
閾值內：基於不同的負載均衡算法，將流量分攤到多出口
超過閾值：將不轉發到超過閾值出口；所有出口都超過閾值，不能像路由交換設備采用丟棄策略，而是會配置默認出口（一般為默認網關），轉發超過部分的流量。
b.過載保護，閾值設定
一般采用最大連接數、最大帶寬、最大客戶端數量等因子。
c.負載均衡算法
數據包在轉發的時候，可以基於以下因子算法來負載均衡轉發到不同的出口：
Least Connections
Round Robin
Least response time
Least bandwidth
Least packets URL hashing
Domain name hashing
Source IP address hashing
Destination IP address hashing
Source IP - Destination IP hashing
Token LRTM
d.會話保持
交換機/路由器上，基於TRUNK、多路由（包括策略路由、多靜態路由、OSPF等的等價路由等）等二三層的負載均衡技術，可能會出現亂序包。負載均衡器后面如果帶的是幾個服務器的話，一般是不允許讓同一個連接的數據包，發送到不同的服務器上的。所以才有了該特性會話保持，會話保持基於的因子有如下：
Source IP
Cookie insert
SSL session ID
URL passive
Custom Server ID
Rule
DESTIP
注：其實在trunk上發送的發射可以設定hash，來轉發數據到特定的口，比如ethrunk。
e.上下行接口綁定技術
當做負載均衡的時候，只是考慮了請求流量出口的負載情況，但是卻未考慮返回流量的出口情況。理想狀況是，從線路1進來的請求，最后返回的結果也從線路1回去。
從F5和netscaler都只有類似的功能分別叫outbound和lld。
f.互聯網出流量優化
在互聯網對接口上，為了保證到對應運營商的流量能夠指定轉發。不僅僅是F5（outbound）和citrix(lld)支持，就是防火牆也提供該特性。
代理方式：
| 名稱 |
目的IP地址 |
源IP地址 |
是否中斷TCP鏈 |
位置 |
| 正向代理 |
代理IP——>源站IP |
客戶端IP——>代理IP |
是 |
客戶側行為 |
| 反向代理 |
不一定 |
不一定 |
不一定 |
服務側行為 |
| 透明代理 |
源站ip |
客戶端IP |
是 |
中間商行為 |
同源同宿
同源同宿指屬於同一個網絡連接的雙向數據報文必須從同一個輸出接口輸出。比如，網絡流量分析(DPI)中，僅分析通信雙方的單向流量是不夠的，往往需要結合通信雙方的雙向流量才能全面分析流量包含的信息，因此需要將通信雙方的報文分流到同一台流分析服務器，這就要求分流設備在特定的轉發流程中支持同源同宿。
同源同宿的特性：
1.將某一個TCP鏈接流，轉發到特定的出口；
2.上下行流量，都能得到相同的hash值，從而可以發送到指定接口。
同樣在華為93上也支持同源同宿，分別有支持eth-trunk和多等價路由等。
例如當93作為負載均衡器的時候，服務於代理服務器，特別是透明模式的時候，可以采用多條缺省路由加同源同宿作為負載均衡的方案。
用戶請求的流量和代理服務器回源的流量，經過同源同宿后准確的發送到特定的服務器上。而代理服務器發送的請求和返回客戶的響應，一般在93上走的是策略路由。
為了滿足同源同宿的特性，我處揣測如下兩種算法：
設一端為A=IP1:PORT1,另一端為B=IP2:PORT2。
算法一：a.滿足第一特性，MOD(hash(AB)),即先將A和B連接成為一個新的數據，並做hash，再對該hash值，對后端出口數求余，依次一一對應轉發；
b.滿足第二特性，先比較A和B的值，將較小者排在前面，不管A是源地址，還是B是源地址。
算法二：mod(hash(A xor B)),不管A是源地址還是目的地址，異或之后將得到一樣的值，然后再hash，求余即可。這種靠譜，簡單，實現有效。
HA或者容災什么的，主要思想和VRRP差不多。一個心跳平面，一個業務平面。心跳告知雙方健康否，業務平面傳送業務。最后都是在一個局域網里面通過響應免費ARP來控制，轉發到哪一台。一般建議心跳和業務在同一個局域網內，心跳失敗，則業務失敗，ARP也算失敗。
關於負載均衡算法，不同算法各有優劣，簡單說下：
a.最小連接負載均衡算法
當前我們使用的負載均衡算法為最小連接數負載均衡
最小連接數負載均衡算法是一種基於iso/osi參考模型傳輸層的算法。由於負載均衡器后端服務器的配置不盡相同，對於請求的處理有快有慢。該算法可以根據后端服務器當前的連接情況，動態地選取其中當前積壓連接數最少的一台服務器來處理當前的請求，盡可能地提高后端服務的利用效率，將負責合理地分流到每一台服務器。
對於基於TCP連接的HTTP、HTTPS和SSL_TCP等服務，在負載均衡器上一般有如下兩種連接情況：
- 已建鏈連接，這些連接是從客戶端發送到達負載均衡器，並且負載均衡器已經轉發給了后台的服務器。
- 等待連接。任何來自於外端的連接，都會先保存在隊列里面，等待負載均衡器轉發給后端服務器。
連接等待的情況，任何時候都可能發生，一般有以下幾方面原因：
A． 負載均衡器上針對每台服務器都配置了最小連接數限制，並且當前所有的服務器服務器的連接數都超過了閾值；
B． 負載均衡器配置了針對后端服務器的過載保護，比如帶寬等，當超過了配置閾值，將不再轉發請求給后端服務器；
C． 后端服務器達到了連接數上限，因此將不再新增服務連接。
最小連接算法能夠很好的均衡連接數到后端服務器。如果后端服務器的性能相當是特別適用的，否則會不盡合理。例如，考慮如下情況：后端服務器有兩台A和B。服務器A處理連接數上線是100，已經有95條活躍連接。服務器B處理連接數上線是500，當前活躍連接數為96。當前情況下，如果使用最小連接數算法選擇服務器，由於A服務器的活躍連接數較小，即使鏈接數情況已經接近其能力上線，接下來的請求連接，負載均衡器還是會轉發給A服務器而不是B服務器。
由於負載均衡器只能感知當前活躍連接數情況，而未知后端服務器實際處理能力情況。采用最小鏈接算法，將無法完美的服務於差異性的負載均衡，那么基於權重的最小連接數負載均衡算法應運而生。
基於權重的最小連接負載均衡算法，選擇通過以下表達式的值（Nw）決定將服務轉發給后端的服務器。負載均衡器始終將新的請求轉發給各台服務器計算情況得到的Nw最小值
Nw = (當前活躍連接數) * (10000 / 權重)
備注：權重是我們加以設定的值。
b.最小連接數算法缺陷
如果web緩存系統采用最小連接數負載均衡的話，將有很大可能遇到如下這種情況：
前提：假定有三台web緩存服務器在負載均衡器后面，分別為服務器A、服務器B和服務器C，並且web緩存服務器假定被訪問一次就會被緩存。
當有一個用戶U1訪問大小為100MB的資源S，LBS將該資源的請求轉發給了服務器A，服務器A隨及從源站回源，並經過查詢能夠提供緩存服務，就將該資源S存儲在了本機磁盤上，並將源站響應的資源S吐出給用戶U1。由此當前資源S占用磁盤資源100M。
當有另一個用戶U2再次訪問同一個資源S，如果將他的請求轉發給服務器A，服務器A就可以直接將資源S吐出給用戶U2。但是很不幸，經過負載均衡器，將請求轉發給了服務器B。由此服務器B從源站回源，並經過查詢能夠提供緩存服務，也將該資源S存儲在了本機磁盤上，並將源站響應的資源S吐出給用戶U2。首先占用了額外回源一次S的帶寬，破壞了WEB緩存系統的初衷，節省帶寬；再就是再次在磁盤上存儲了一次，由此加上服務器A上的，總共占用磁盤200M。
同理如果用戶U3訪問同一個資源，並且轉發給了服務器C。又會再次造成帶寬和磁盤的資源浪費。
很明顯基於四層的負載均衡算法是無法滿足web緩存系統要求的。必須提供一種能夠對資源進行唯一識別的算法，將資源有效的負載均衡到后端服務器。這就是下面要提到的優化方案url_hash負載均衡算法。
c.url_hash負載均衡算法
URL（Uniform/Universal Resource Locator的縮寫，統一資源定位符）是對可以從互聯網上得到的資源的位置和訪問方法的一種簡潔的表示，是互聯網上標准資源的地址。互聯網上的每個文件都有一個唯一的URL，它包含的信息指出文件的位置以及瀏覽器應該怎么處理它。它最初是由蒂姆·伯納斯·李發明用來作為萬維網的地址的。現在它已經被萬維網聯盟編制為因特網標准RFC1738了。一個完整的URL包括訪問協議類型、主機地址、路徑和文件名。例如：http://www.uestc.edu.cn/。
Hash，一般翻譯做“散列”，也有直接音譯為“哈希”的，就是把任意長度的輸入（又叫做預映射， pre-image），通過散列算法，變換成固定長度的輸出，該輸出就是散列值。這種轉換是一種壓縮映射，也就是，散列值的空間通常遠小於輸入的空間，不同的輸入可能會散列成相同的輸出，所以不可能從散列值來唯一的確定輸入值。簡單的說就是一種將任意長度的消息壓縮到某一固定長度的消息摘要的函數。
url_hash負載均衡算法基於url進行hash計算，然后通過hash結果找到對應的服務器。因為針對單一個url的hash結果是一樣的，所以理論上這個url會被永久分配到固定的一台服務器上。另外因為經過了hash算法，所以分配url就很均勻，同時訪問量也可以達到均衡。這類算法有多種，比如：
hash+求余的算法
首先將從用戶端到負載均衡器的url中的前一部分（一般為80字節）做hash得到hash值P。再將該值使用后端服務器的數量N相除求余（記為MOD(P，N)），再進行一對一的業務分配。比如有3台設備，分別為A、B、C。hash值除以3，求余得0，就分配與A；求余得1，分配給B；求余得2，分配給C。
該算法簡單，對負載均衡器性能消耗少，反應速度快。但是如果當后台服務器中有一台設備掛掉之后，所有資源都將經過重新計算，重新存儲服務。
完全使用hash算法
對服務器的IP地址進行一次hash得到hash值P1，對從用戶端到負載均衡器的url中的前一部分（一般為80字節）做hash得到hash值P2。再將這兩個hash值P1和P2進行hash，得到hash值P3。最后將用戶端請求轉發到hash值P3最大的服務器上。比如有三台設備，分別為
A、B、C，分別計算后得到的P3值：P3(B)>P3(A)>P3(C)。那么負載均衡器將該用戶端請求轉發到服務器B上去。
該算法經過了三次hash，對設備性能相對前面一種算法有更大的消耗。但是即使其中一台掛掉了，也只是影響掛掉那台設備的資源重新計算而已，受影響的范圍較小。
附，下圖顯示了 NetScaler 中的 L7 數據包流。
L7 數據包流圖
下圖顯示了 NetScaler 中的 DataStream 數據包流
更多細節請查看F5/Netscaler/華為防火牆等相關產品文檔，及其相關RFC。