syn演算法
⑴ SYN COOKIE 防火牆具體的工作原理（轉發內容細節、具體演算法）
SYN Cookie是對TCP伺服器端的三次握手協議作一些修改，專門用來防範SYN Flood攻擊的一種手段。它的原理是，在TCP伺服器收到TCP SYN包並返回TCP SYN+ACK包時，不分配一個專門的數據區，而是根據這個SYN包計算出一個cookie值。在收到TCP ACK包時，TCP伺服器在根據那個cookie值檢查這個TCP ACK包的合法性。如果合法，再分配專門的數據區進行處理未來的TCP連接。
⑵ 屬於網路協議的攻擊有哪幾種
1. TCP/IP 協議的脆弱性
1.1 不能提供可靠的身份驗證
TCP/IP 協議以 32 bit 的 IP 地址來作為網路節點的唯一標識，而 IP 地址只是用戶軟體設置中的一個參數，因而是可以隨意修改的。
對 UDP 來說，是根據這個 IP 地址來唯一標識通信對方。 TCP 則通過三次握手，使情況稍有改善。 TCP 中的每個報文都含有一個標識本報文在整個通信流中位置的 32 bit 序列號，通信雙方通過序列號來確認數據的有效性。
由於 TCP 設計三次握手過程本身並不是為了身份驗證，只是提供同步確認和可靠通信，雖然這也能夠提供一定的身份驗證的支持，但這種支持很薄弱。
由於 TCP/IP 不能對節點上的用戶進行有效的身份認證，伺服器無法鑒別登錄用戶的身份有效性，攻擊者可以冒充某個可信節點的 IP 地址，進行 IP 欺騙攻擊.
其次，由於某些系統的 TCP 序列號是可以預測的，攻擊者可以構造一個TCP'數據包，對網路中的某個可信節點進行攻擊。
IPv4 中沒有考慮防止信息泄漏，在 IP 、 TCP 、 UDP 中都沒有對數據進行加密。 IP 協議是無連接的協議，一個 IP 包在傳輸過程中很可能會經過很多路由器和網段，在其中的任何一個環節都很容易進行竊昕 。攻擊者只需簡單地安裝一個網路嗅探器，就可以看到通過本節點的所有網路數據包。
在 IP 協議中，僅對 IP 頭實現校驗和保護
在UDP 協議中，對整個報文的校驗和檢查是一個可選項，並且對 UDP 報文的丟失不做檢查。
在 TCP 協議中，雖然每個報文都經過校驗和檢查，並且通過連續的序列號來對包的順序和完整進行檢查，保證數據的可靠傳輸。但是，校驗演算法中沒有涉及加密和密碼驗證，很容易對報文內容進行修改，再重新計算校驗和
各個網路 ISP 應該限制源地址為外部地址的 IP 數據包進入互聯網
合理的配置防火牆，限制數據包的源地址為內部網路的數據包進入網路。
攻擊者看到被假冒主機和目標主機建立一個連接並進行身份認證後，通過對數據包捕獲和進行分析，就可以得到連接的序列號。
一旦得到正確的序列號就可以發送一個假冒的 TCP 分段，接管已經建立的連接。這樣，被假冒主機發送的數據包都會被目標主機忽略，因為它們的序列號會被目標主機認為不正確。
無效連接監視釋放
這種方法不停監視系統的半開連接和不活動連接，當達到一定閾值時拆除這些連接，從而釋放系統資源。這種方法對於所有的連接一視同仁，而且由於SYN Flood造成的半開連接數量很大，正常連接請求也被淹沒在其中被這種方式誤釋放掉，因此這種方法屬於入門級的SYN Flood方法。延緩TCB分配方法
從前面SYN Flood原理可以看到，消耗伺服器資源主要是因為當SYN數據報文一到達，系統立即分配TCB，從而佔用了資源。而SYN Flood由於很難建立起正常連接，因此，當正常連接建立起來後再分配TCB則可以有效地減輕伺服器資源的消耗。常見的方法是使用Syn Cache和Syn Cookie技術。Syn Cache技術：
這種技術是在收到SYN數據報文時不急於去分配TCB，而是先回應一個SYN ACK報文，並在一個專用HASH表（Cache）中保存這種半開連接信息，直到收到正確的回應ACK報文再分配TCB。在FreeBSD系統中這種Cache每個半開連接只需使用160位元組，遠小於TCB所需的736個位元組。在發送的SYN ACK中需要使用一個己方的Sequence Number，這個數字不能被對方猜到，否則對於某些稍微智能一點的Syn Flood攻擊軟體來說，它們在發送Syn報文後會發送一個ACK報文，如果己方的Sequence Number被對方猜測到，則會被其建立起真正的連接。因此一般採用一些加密演算法生成難於預測的Sequence Number。
Syn Cookie技術：
對於SYN攻擊，Syn Cache雖然不分配TCB，但是為了判斷後續對方發來的ACK報文中的Sequence Number的正確性，還是需要使用一些空間去保存己方生成的Sequence Number等信息，也造成了一些資源的浪費。
Syn Cookie技術則完全不使用任何存儲資源，這種方法比較巧妙，它使用一種特殊的演算法生成Sequence Number，這種演算法考慮到了對方的IP、埠、己方IP、埠的固定信息，以及對方無法知道而己方比較固定的一些信息，如MSS、時間等，在收到對方的ACK報文後，重新計算一遍，看其是否與對方回應報文中的（Sequence Number-1）相同，從而決定是否分配TCB資源。使用SYN Proxy防火牆
Syn Cache技術和Syn Cookie技術總的來說是一種主機保護技術，需要系統的TCP/IP協議棧的支持，而目前並非所有的操作系統支持這些技術。因此很多防火牆中都提供一種SYN代理的功能，其主要原理是對試圖穿越的SYN請求進行驗證後才放行，下圖描述了這種過程：image.png
可以利用防火牆來阻止 Ping ，然而這樣也會阻擋一些合法應用。所以只要阻止被分段的 Ping ，這樣在大多數系統上允許一般合法的 64 Byt 的 Ping 通過，擋住了那些長度大於 MTU 的 ICMP 數據包.
這種攻擊能使系統崩潰的原因因系統不同而異.有的可能因為內核中固定大小的緩沖區因 IP 數據包過大而越界，損壞了其它數據或編碼;有的則可能因為用一個無符號的 16 bit 變數來保存數據包的長度和相關變數，當這些變數的值超過 65 535 Byte 時，變數不再與其數值一致，從而引發異常。因此可以為相應的系統打上補丁。
黑客鎖定一個被攻擊的主機（通常是一些Web伺服器）；
黑客尋找可做為中間代理的站點，用來對攻擊實施放大（通常會選擇多個，以便更好地隱藏自己，偽裝攻擊）；
黑客給中間代理站點的廣播地址發送大量的ICMP包（主要是指Ping命令的回應包）。這些數據包全都以被攻擊的主機的IP地址做為IP包的源地址；
中間代理向其所在的子網上的所有主機發送源IP地址欺騙的數據包；
中間代理主機對被攻擊的網路進行響應。
1.2 不能有效防止信息泄漏
1.3 沒有提供可靠的信息完整性驗證手段
1.4 協議沒有手段控制資源占杳和分配
TCP/IP 中，對資源占杳和分配設計的一個基本原則是自覺原則。如參加 TCP通信的一方發現上次發送的數據報丟失，則主動將通信速率降至原來的一半。這樣，也給惡意的網路破壞者提供了機會 c 如網路破壞者可以大量的發 IP 報，造成網路阻塞，也可以向一台主機發送大量的 SYN 包從而大量佔有該主機的資源 (SYN Flood) 。這種基於資源佔用造成的攻擊被稱為拒絕服務攻擊( DOS)
2.常見 TCP/IP 協議攻擊方法分析
2.1 IP 欺騙( IP Spoofing)
IP 欺騙是指一個攻擊者假冒一個主機或合法用戶的 IP 地址，利用兩個主機之間的信任關系來達到攻擊的目的，而這種信任關系只是根據源 IP 地址來確定。所謂信任關系是指當主機 B 信任主機 A 上的 X用戶時，只要 X 在 A 上登錄， X 用戶就可以直接登錄到主機 B 上，而不需要任何口令。
IP 欺騙通常需要攻擊者能構造各種形式 IP 數據包，用虛假的源 IP 地址替代自己的真實 IP 地址。如果主機之間存在基於 IP 地址的信任關系，目標主機無法檢測出已經被欺騙。
防範措施
2.2 TCP 會話劫持 (TCP sessJOn hijacking)
image.png
TCP 會話劫持跳過連接過程.對一個已經建立的連接進行攻擊。攻擊者與被假冒主機和目標主機之一在同一個子網中，攻擊者通過一個嗅探程序可以看到被假冒主機和目標主機之間通信的數據包。
防範措施
最主要的方法是在傳輸層對數據進行加密。
2.3 拒絕服務( Denial Of Service )
拒絕服務坷的目的就是使受害的伺服器不能提供正常的網路服務。
2.3.1 SYN 淹沒 (SYN Flooding)
當開放了一個TCP埠後，該埠就處於Listening狀態，不停地監視發到該埠的Syn報文，一旦接收到Client發來的Syn報文，就需要為該請求分配一個TCB（Transmission Control Block），通常一個TCB至少需要280個位元組，在某些操作系統中TCB甚至需要1300個位元組，並返回一個SYN ACK命令，立即轉為SYN-RECEIVED即半開連接狀態，而操作系統在SOCK的實現上最多可開啟半開連接個數是一定的。
image.png
從以上過程可以看到，如果惡意的向某個伺服器埠發送大量的SYN包，則可以使伺服器打開大量的半開連接，分配TCB，從而消耗大量的伺服器資源，同時也使得正常的連接請求無法被相應。而攻擊發起方的資源消耗相比較可忽略不計。
防範措施
從上圖（左圖）中可以看出，防火牆在確認了連接的有效性後，才向內部的伺服器（Listener）發起SYN請求，在右圖中，所有的無效連接均無法到達內部的伺服器。
採用這種方式進行防範需要注意的一點就是防火牆需要對整個有效連接的過程發生的數據包進行代理，如下圖所示：
image.png
因為防火牆代替發出的SYN ACK包中使用的序列號為c，而伺服器真正的回應包中序列號為c』，這其中有一個差值|c-c』|，在每個相關數據報文經過防火牆的時候進行序列號的修改。
TCP Safe Reset技術：
這也是防火牆Syn代理的一種方式，其工作過程如下圖所示：
image.png
這種方法在驗證了連接之後立即發出一個Safe Reset命令包，從而使得Client重新進行連接，這時出現的Syn報文防火牆就直接放行。在這種方式中，防火牆就不需要對通過防火牆的數據報文進行序列號的修改了。這需要客戶端的TCP協議棧支持RFC 793中的相關約定，同時由於Client需要兩次握手過程，連接建立的時間將有所延長。
2.3.2 死亡之 Ping(Ping O' Death )
死亡之 Ping 是利用 ICMP 協議的一種碎片攻擊 。攻擊者發送一個長度超過 65 535Byte 的 Echo Request 數據包，目標主機在重組分片的時候會造成事先分配的 65 535 Byt 位元組緩沖區溢出，系統通常會崩憤或掛起
IP 數據包的最大長度是 65 535 (2 16 - 1) Byte，其中包括包頭長度(如果 IP 選項末指定，一般為 20 B)超過 MTU( Maximum Transmission Unit) 的數據包被分割成小的數據包，在接受端重新組裝。一般乙太網的MTU 為 11500 Byte ，互聯網上的 MTU 通常是 576 Byte ICMP 回應請求放在 IP 數據包中，其中有 8 Byt 的 ICMP頭信息，接下來是 "Ping" 請求的數據宇節的數目。因此數據區所允許的最大尺寸為 65 535 - 20 - 8 = 65 507Byte
image.png
分段後的 IP 包要在接收端的 IP 層進行重組，這樣"死亡之 Ping"就可以再發送一個回應請求數據包，使它的數據包中的數據超過 65 507 Byte ，使得某些系統的 IP 分段組裝模塊出現異常。因為在 IP 分段組裝的過程中，它通過每一個 IP 分段中的偏移量來決定每一個分段在整個 IP 包中的位置，最後一個分段中，如果 IP 包的長度大於 65 507 Byte各個分段組裝後就會超過 IP 包的最大長度。某些操作系統要等到將所有的分段組裝完後才對 IP 包進行處理，所以就存在這樣一種內部緩沖區或內部變數溢出的可能性，這樣會導致系統崩憤或重啟。
防範措施
2.3.3 RST 和 FIN 攻擊( RST and FIN attack)
在 TCP 包中有 6 個標志位來指示分段的狀態。其中 RST 用來復位一個連接， FIN 表示沒有數據要發送了攻擊者經常利用這兩個標志位進行拒絕服務攻擊。他們先分析通過目標主機和受騙主機之間的 IP 數據包，計算出從受騙主機發往目標主機的下一個 TCP 段的序列號，然後產生一個帶有 RST 位設置的 TCP 段，將其放在假冒源 IP 地址的數據包中發往目標主機，目標主機收到後就關閉與受騙主機的連接。
利用 FIN 位的攻擊與 RST 位的攻擊很相似。攻擊者預測到正確的序列號後，使用它創建一個帶 FIN 位的 TCP 分段，然後發送給目標主機，好像受騙主機沒有數據要發送了，這樣，由受騙主機隨後發出的 TCP 段都會目標主機認為是網路錯誤而忽略。
2.3.6 Smurf攻擊
通過地址欺騙，並使用回復地址設置成受害網路的廣播地址的ICMP應答請求(ping)數據包來淹沒受害主機的方式進行。最終導致該網路的所有主機都對此ICMP應答請求做出答復，導致網路阻塞
2.3.7 Land 攻擊
用一個特別打造的SYN包，其原地址和目標地址都被設置成某一個伺服器地址。此舉將導致伺服器向它自己的地址發送SYN-ACK消息，結果這個地址又發回ACK消息並創建一個空連接。被攻擊的伺服器每接收一個這樣的連接都將保留，直到超時
防禦方法：
這類攻擊的檢測方法相對來說比較容易，因為可以直接通過判斷網路數據包的源地址和目標地址是否相同確認是否屬於攻擊行為。反攻擊的方法當然是適當地配置防火牆設備或制定包過濾路由器的包過濾規則，並對這種攻擊進行審計，記錄事件發生的時間、源主機和目標主機的MAC地址和IP地址，從而可以有效地分析並跟蹤攻擊者的來源。
2.3.8 UDP FLOOD攻擊
UDP不需要像TCP那樣進行三次握手，運行開銷低，不需要確認數據包是否成功到達目的地。這就造成UDP泛洪攻擊不但效率高，而且還可以在資源相對較少的情況下執行。UDP FLOOD可以使用小數據包(64位元組)進行攻擊,也可以使用大數據包(大於1500位元組,乙太網MTU為1500位元組)進行攻擊。大量小數據包會增大網路設備處理數據包的壓力；而對於大數據包，網路設備需要進行分片、重組，最終達到的效果就是佔用網路傳輸介面的帶寬、網路堵塞、伺服器響應慢等等。
防禦方案： 限制每秒鍾接受到的流量(可能產生誤判)；通過動態指紋學習(需要攻擊發生一定時間)，將非法用戶加入黑名單。
2.3.9 淚滴攻擊
「teardrop」,又稱「淚滴」：IP數據包在網路傳遞時，數據包可以分成更小的片段。攻擊者可以通過發送兩段(或者更多)數據包來實現TearDrop攻擊。第一個包的偏移量為0，長度為N，第二個包的偏移量小於N。為了合並這些數據段，TCP/IP堆棧會分配超乎尋常的巨大資源，從而造成系統資源的缺乏甚至機器的重新啟動，達到攻擊者需要的拒絕服務的目的。
3. DOS與DDOS區別
3.1 DOS
「DoS」是Denial of Service，拒絕服務的縮寫。所謂的拒絕服務是當前網路攻擊手段中最常見的一種。它故意攻擊網路協議的缺陷或直接通過某種手段耗盡被攻擊對象的資源，目的是讓目標計算機或網路無法提供正常的服務或資源訪問，使目標系統服務停止響應甚至崩潰，而最值得注意的是，攻擊者在此攻擊中並不入侵目標伺服器或目標網路設備，單純利用網路缺陷或者暴力消耗即可達到目的。
從原理上來說，無論攻擊者的攻擊目標(伺服器、計算機或網路服務)的處理速度多快、內存容量多大、網路帶寬的速度多快都無法避免這種攻擊帶來的後果。任何資源都有一個極限，所以攻擊者總能找到一個方法使請求的值大於該極限值，導致所提供的服務資源耗盡。
從技術分類的角度上來說，最常見的DoS攻擊有對計算機網路的帶寬攻擊和連通性攻擊。帶寬攻擊指以極大的通信量沖擊網路，使得所有可用網路資源都被消耗殆盡，最後導致合法用戶的請求無法通過。連通性攻擊指用大量的連接請求沖擊伺服器或計算機，使得所有可用的操作系統資源都被消耗殆盡，最終計算機無法再處理合法用戶的請求。
在網路還不發達的時候，單一的DoS攻擊一般是採用一對一的方式，也就是攻擊者直接利用自己的計算機或者設備，對攻擊目標發起DoS攻擊。當攻擊目標處在硬體性能低下、網路連接情況不好等情況的時候，一對一的DoS攻擊效果是非常明顯的，很有可能直接一個攻擊者就搞定一個網站或者一個伺服器，讓它拒絕服務。
3.2 DDOS
隨著計算機和網路技術的發展，硬體設備的處理性能加速度增長，成本也變得非常低廉，網路的快速發展更是讓帶寬、出入口節點寬度等大大的提升，這讓傳統的DoS攻擊很難湊效。
隨著這樣情況的出現，攻擊者研究出了新的攻擊手段，也就是DDoS。
DDoS是在傳統的DoS攻擊基礎之上產生的一種新的攻擊方式，即Distributed Denial Of Service，分布式拒絕服務攻擊。
如果說計算機與網路的處理能力比以往加大了10倍的話(示例數據，沒有實質意義)，那攻擊者使用10台計算機同時進行攻擊呢？也就達到了可以讓目標拒絕服務的目的。簡單來說，DDoS就是利用更多的計算機來發起攻擊。
就技術實現方式來分析，分布式拒絕服務攻擊就是攻擊者利用入侵手段，控制幾百台，或者成千上萬台計算機(一般被控制的計算機叫做傀儡主機，或者口頭被網路安全相關人員稱為「肉雞」)，然後在這些計算機上安裝大量的DDoS程序。這些程序接受來自攻擊者的控制命令，攻擊者同時啟動全部傀儡主機向目標伺服器發起拒絕服務攻擊，形成一個DoS攻擊群，猛烈的攻擊目標，這樣能極為暴力的將原本處理能力很強的目標伺服器攻陷。
3.3 區別
通過上面的分析，可以看出DDoS與DoS的最大區別是數量級的關系，DoS相對於DDoS來說就像是一個個體，而DDoS是無數DoS的集合。另一方面，DDoS攻擊方式較為自動化，攻擊者可以把他的程序安裝到網路中的多台機器上，所採用的這種攻擊方式很難被攻擊對象察覺，直到攻擊者發下統一的攻擊命令，這些機器才同時發起進攻。可以說DDoS攻擊是由黑客集中控制發動的一組DoS攻擊的集合，現在這種方式被認為是最有效的攻擊形式，並且非常難以抵擋。
⑶ 伺服器給攻擊後會有哪幾種影響
DoS攻擊是網路攻擊最常見的一種。它故意攻擊網路協議的缺陷或直接通過某種手段耗盡被攻擊對象的資源，目的是讓目標計算機或網路無法捉供正常的服務或資源訪問，使目標系統服務停止響應甚至崩潰，而在此攻擊中並不入侵目標伺服器或目標網路設備。這些服務資源包括網路寬頻、系統堆棧、開放的進程。或者允許的連接。這種攻擊會導致資源耗盡，無論計算機的處理速度多快、內存容量多大、網路帶寬的速度多快都無法避免這種攻擊帶來的後果。任何資源都有一個極限，所以總能找到一個方法使請求的值大於該極限值，導致所提供的服務資源耗盡。
DoS攻擊有許多種類，主要有Land攻擊、死亡之ping、淚滴、Smurf攻擊及SYN洪水等。
據統計，在所有黑客攻擊事件中，syn洪水攻擊是最常見又最容易被利用的一種DoS攻擊手法。
1.攻擊原理
要理解SYN洪水攻擊，首先要理解TCP連接的三次握手過程(Three-wayhandshake)。在TCP/IP協議中，TCP協議提供可靠的連接服務，採用三次握手建立一個連接。第一次握手:建立連接時，客戶端發送SYN包((SYN=i)到伺服器，並進入SYN SEND狀態，等待伺服器確認;
第二次握手:伺服器收到SYN包，必須確認客戶的SYN (ACK=i+1 )，同}Jj』自己也發送一個SYN包((SYN j)}即SYN+ACK包，此時伺服器進入SYN_RECV狀態;
第三次握手:客戶端收到伺服器的SYN十ACK包，向伺服器發送確認包ACK(ACK=j+1)，此包發送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手，客戶端與伺服器開始傳送數據。
在上述過程中，還有一些重要的概念:
半連接:收到SYN包而還未收到ACK包時的連接狀態稱為半連接，即尚未完全完成三次握手的TCP連接。
半連接隊列:在三次握手協議中，伺服器維護一個半連接隊列，該隊列為每個客戶端的SYN包(SYN=i )開設一個條目，該條目表明伺服器已收到SYN包，並向客戶發出確認，正在等待客戶的確認包。這些條目所標識的連接在伺服器處於SYN_ RECV狀態，當伺服器收到客戶的確認包時，刪除該條目，伺服器進入ESTABLISHED狀態。
Backlog參數:表示半連接隊列的最大容納數目。
SYN-ACK重傳次數:伺服器發送完SYN-ACK包，如果未收到客戶確認包，伺服器進行首次重傳，等待一段時間仍未收到客戶確認包，進行第二次重傳，如果重傳次數超過系統規定的最大重傳次數，系統將該連接信息、從半連接隊列中刪除。注意，每次重傳等待的時間不一定相同。
半連接存活時間:是指半連接隊列的條目存活的最長時間，也即服務從收到SYN包到確認這個報文無效的最長時間，該時間值是所有重傳請求包的最長等待時間總和。有時也稱半連接存活時間為Timeout時間、SYN_RECV存活時間。
上面三個參數對系統的TCP連接狀況有很大影響。
SYN洪水攻擊屬於DoS攻擊的一種，它利用TCP協議缺陷，通過發送大量的半連接請求，耗費CPU和內存資源。SYN攻擊除了能影響主機外，還可以危害路由器、防火牆等網路系統，事實上SYN攻擊並不管目標是什麼系統，只要這些系統打開TCP服務就可以實施。從圖4-3可看到，伺服器接收到連接請求(SYN=i )將此信息加入未連接隊列，並發送請求包給客戶( SYN=j,ACK=i+1 )，此時進入SYN_RECV狀態。當伺服器未收到客戶端的確認包時，重發請求包，一直到超時，才將此條目從未連接隊列刪除。配合IP欺騙，SYN攻擊能達到很好的效果，通常，客戶端在短時間內偽造大量不存在的IP地址，向伺服器不斷地發送SYN包，伺服器回復確認包，並等待客戶的確認，由於源地址是不存在的，伺服器需要不斷的重發直至超時，這些偽造的SYN包將長時間佔用未連接隊列，正常的SYN 請求
被丟棄，目標系統運行緩慢，嚴重者引起網路堵塞甚至系統癱瘓。過程如下:
攻擊主機C(地址偽裝後為C')-----大量SYN包---->彼攻擊主機
C'<-------SYN/ACK包----被攻擊主機
由於C』地址不可達，被攻擊主機等待SYN包超時。攻擊主機通過發人量SYN包填滿未連接隊列，導致正常SYN包被拒絕服務。另外，SYN洪水攻擊還可以通過發大量ACK包進行DoS攻擊。
2．傳統演算法
抵禦SYN洪水攻擊較常用的方法為網關防火牆法、中繼防火牆法和SYNcookies。為便於敘述，將系統拓撲圖簡化為圖4-4。圖中，按網路在防火牆內側還是外側將其分為內網、外網(內網是受防火牆保護的)。其次，設置防火牆的SYN重傳計時器。超時值必須足夠小，避免backlog隊列被填滿;同時又要足夠大保證用戶的正常通訊。
(1) 網關防火牆法
網關防火牆抵禦攻擊的基本思想是:對於內網伺服器所發的SYN/ACK包，防火牆立即發送ACK包響應。當內網伺服器接到ACK包後，從backlog隊列中移出此半連接，連接轉為開連接，TCP連接建成。由於伺服器處理開連接的能力比處理半連接大得多，這種方法能有效減輕對內網伺服器的SYN攻擊，能有效地讓backlog隊列處於未滿狀態，同時在重傳一個未完成的連接之前可以等待更長時間。
以下為演算法完整描述:
第一步，防火牆截獲外網客戶端發向內網伺服器SYN數據包，允許其通過，抵達內網伺服器。同時在連接跟蹤表中記錄此事件.
第二步，防火牆截獲伺服器發向客戶端的SYN/ACK響應包，用連接跟蹤表中記錄的相應SYN包匹配它.
第三步，防火牆讓截獲的SYN/ACK繼續進行(發向客戶端)。同時，向內網伺服器發送ACK包。這樣，對伺服器來說，TCP連接三次握手已經完成。系統在backlog隊列中刪掉此半連接.
第四步，看此TCP連接是否有效，相應產生兩種解決方法。如果客戶端的連接嘗試是有效的，那麼防火牆將接到來自客戶端的ACK包，然後防火牆將它轉發到伺服器。伺服器會忽略這個冗餘的ACK包，這在TCP協議中是允許的.
如果客戶端的IP地址並不存在，那麼防火牆將收不到來自客戶端的ACK包，重轉計時器將超時。這時，防火牆重傳此連接.
(2) 中繼防火牆法
中繼防火牆抵禦攻擊的思想是:防火牆在向內網伺服器發SYN包之前，首先完成與外網的三次握手連接，從而消除SYN洪水攻擊的成立條件。
以下為演算法完整描述:
第一步，防火牆截獲外網客戶端發向內網伺服器SYN數據包.
第二步，防火牆並不直接向內網發SYN數據包，而是代替內網伺服器向外網發SYNIACK數據包.
第三步，只有接到外網的ACK包，防火牆向內網發SYN包.
第四步，伺服器應答SYN/ACK包.
第五步，防火牆應答ACK包.
(3) 分析
首先分析演算法的性能，可以看出:為了提高效率，上述演算法使用了狀態檢測等機制(可通過本系統的基本模塊層得以實現)
對於非SYN包(CSYN/ACK及ACK包)，如果在連線跟蹤信息表未查找到相應項，則還要匹配規則庫，而匹配規則庫需比較諸多項(如IP地址、埠號等)，花費較大，這會降低防火牆的流量。另外，在中繼防火牆演算法中，由於使用了SYN包代理，增加了防火牆的負荷，也會降低防火牆的流量。
其次，當攻擊主機發ACK包，而不是SYN包，演算法將出現安全漏洞。一般地，TCP連接從SYN包開始，一旦 SYN包匹配規則庫，此連接將被加到連接跟蹤表中，並且系統給其60s延時。之後，當接到ACK包時，此連接延時突然加大到3600s。如果，TCP連接從ACK包開始，同時此連接未在連接跟蹤表中注冊，ACK包會匹配規則庫。如匹配成功，此連接將被加到連接跟蹤表中，同時其延時被設置為3600s。即使系統無響應，此連接也不會終止。如果攻擊者發大量的ACK包，就會使半連接隊列填滿，導致無法建立其它TCP連接。此類攻擊來自於內網。因為，來自於外網的ACK包攻擊，伺服器會很快發RST包終止此連接(SOs>。而對於內網的外發包，其限制規則的嚴格性要小的多。一旦攻擊者在某時間段內從內網發大量ACK包，並且速度高於防火牆處理速度，很容易造成系統癱瘓。
(4) SYN cookies
Linux支持SYN cookies，它通過修改TCP協議的序列號生成方法來加強抵禦SYN洪水攻擊能力。在TCP協議中，當收到客戶端的SYN請求時，伺服器需要回復SYN-SACK包給客戶端，客戶端也要發送確認包給伺服器。通常，伺服器的初始序列號由伺服器按照一定的規律計算得到或採用隨機數，但在SYN cookies中，伺服器的初始序列號是通過對客戶端IP地址、客戶端埠、伺服器IP地址和伺服器埠以及其他一些安全數值等要素進行hash運算，加密得到的，稱之為cookie。當伺服器遭受SYN攻擊使得backlog隊列滿時，伺服器並不拒絕新的SYN請求，而是回復cookie(回復包的SYN序列號)給客戶端，如果收到客戶端的ACK包，伺服器將客戶端的ACK序列號減去1得到。cookie比較值，並將上述要素進行一次hash運算，看看是否等於此cookie。如果相等，直接完成三次握手(注意:此時並不用查看此連接是否屬於backlog隊列)。
⑷ 四層負載均衡和七層負載均衡的區別
（一）
簡單理解四層和七層負載均衡:
① 所謂四層就是基於IP+埠的負載均衡；七層就是基於URL等應用層信息的負載均衡；同理，還有基於MAC地址的二層負載均衡和基於IP地址的三層負載均衡。 換句換說，二層負載均衡會通過一個虛擬MAC地址接收請求，然後再分配到真實的MAC地址；三層負載均衡會通過一個虛擬IP地址接收請求，然後再分配到真實的IP地址；四層通過虛擬IP+埠接收請求，然後再分配到真實的伺服器；七層通過虛擬的URL或主機名接收請求，然後再分配到真實的伺服器。
② 所謂的四到七層負載均衡，就是在對後台的伺服器進行負載均衡時，依據四層的信息或七層的信息來決定怎麼樣轉發流量。 比如四層的負載均衡，就是通過發布三層的IP地址（VIP），然後加四層的埠號，來決定哪些流量需要做負載均衡，對需要處理的流量進行NAT處理，轉發至後台伺服器，並記錄下這個TCP或者UDP的流量是由哪台伺服器處理的，後續這個連接的所有流量都同樣轉發到同一台伺服器處理。七層的負載均衡，就是在四層的基礎上（沒有四層是絕對不可能有七層的），再考慮應用層的特徵，比如同一個Web伺服器的負載均衡，除了根據VIP加80埠辨別是否需要處理的流量，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。舉個例子，如果你的Web伺服器分成兩組，一組是中文語言的，一組是英文語言的，那麼七層負載均衡就可以當用戶來訪問你的域名時，自動辨別用戶語言，然後選擇對應的語言伺服器組進行負載均衡處理。
③ 負載均衡器通常稱為四層交換機或七層交換機。四層交換機主要分析IP層及TCP/UDP層，實現四層流量負載均衡。七層交換機除了支持四層負載均衡以外，還有分析應用層的信息，如HTTP協議URI或Cookie信息。
1、負載均衡分為L4 switch（四層交換），即在OSI第4層工作，就是TCP層啦。此種Load Balance不理解應用協議（如HTTP/FTP/MySQL等等）。例子：LVS，F5。
2、另一種叫做L7 switch（七層交換），OSI的最高層，應用層。此時，該Load Balancer能理解應用協議。例子： haproxy，MySQL Proxy。
注意：上面的很多Load Balancer既可以做四層交換，也可以做七層交換。
（二）
負載均衡設備也常被稱為"四到七層交換機"，那麼四層和七層兩者到底區別在哪裡？
第一，技術原理上的區別。
所謂四層負載均衡，也就是主要通過報文中的目標地址和埠，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。
以常見的TCP為例，負載均衡設備在接收到第一個來自客戶端的SYN 請求時，即通過上述方式選擇一個最佳的伺服器，並對報文中目標IP地址進行修改(改為後端伺服器IP），直接轉發給該伺服器。TCP的連接建立，即三次握手是客戶端和伺服器直接建立的，負載均衡設備只是起到一個類似路由器的轉發動作。在某些部署情況下，為保證伺服器回包可以正確返回給負載均衡設備，在轉發報文的同時可能還會對報文原來的源地址進行修改。
所謂七層負載均衡，也稱為「內容交換」，也就是主要通過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。
以常見的TCP為例，負載均衡設備如果要根據真正的應用層內容再選擇伺服器，只能先代理最終的伺服器和客戶端建立連接(三次握手)後，才可能接受到客戶端發送的真正應用層內容的報文，然後再根據該報文中的特定欄位，再加上負載均衡設備設置的伺服器選擇方式，決定最終選擇的內部伺服器。負載均衡設備在這種情況下，更類似於一個代理伺服器。負載均衡和前端的客戶端以及後端的伺服器會分別建立TCP連接。所以從這個技術原理上來看，七層負載均衡明顯的對負載均衡設備的要求更高，處理七層的能力也必然會低於四層模式的部署方式。
第二，應用場景的需求。
七層應用負載的好處，是使得整個網路更"智能化"。例如訪問一個網站的用戶流量，可以通過七層的方式，將對圖片類的請求轉發到特定的圖片伺服器並可以使用緩存技術；將對文字類的請求可以轉發到特定的文字伺服器並可以使用壓縮技術。當然這只是七層應用的一個小案例，從技術原理上，這種方式可以對客戶端的請求和伺服器的響應進行任意意義上的修改，極大的提升了應用系統在網路層的靈活性。很多在後台，例如Nginx或者Apache上部署的功能可以前移到負載均衡設備上，例如客戶請求中的Header重寫，伺服器響應中的關鍵字過濾或者內容插入等功能。
另外一個常常被提到功能就是安全性。網路中最常見的SYN Flood攻擊，即黑客控制眾多源客戶端，使用虛假IP地址對同一目標發送SYN攻擊，通常這種攻擊會大量發送SYN報文，耗盡伺服器上的相關資源，以達到Denial of Service(DoS)的目的。從技術原理上也可以看出，四層模式下這些SYN攻擊都會被轉發到後端的伺服器上；而七層模式下這些SYN攻擊自然在負載均衡設備上就截止，不會影響後台伺服器的正常運營。另外負載均衡設備可以在七層層面設定多種策略，過濾特定報文，例如SQL Injection等應用層面的特定攻擊手段，從應用層面進一步提高系統整體安全。
現在的7層負載均衡，主要還是著重於應用HTTP協議，所以其應用范圍主要是眾多的網站或者內部信息平台等基於B/S開發的系統。 4層負載均衡則對應其他TCP應用，例如基於C/S開發的ERP等系統。
第三，七層應用需要考慮的問題。
1：是否真的必要，七層應用的確可以提高流量智能化，同時必不可免的帶來設備配置復雜，負載均衡壓力增高以及故障排查上的復雜性等問題。在設計系統時需要考慮四層七層同時應用的混雜情況。
2：是否真的可以提高安全性。例如SYN Flood攻擊，七層模式的確將這些流量從伺服器屏蔽，但負載均衡設備本身要有強大的抗DDoS能力，否則即使伺服器正常而作為中樞調度的負載均衡設備故障也會導致整個應用的崩潰。
3：是否有足夠的靈活度。七層應用的優勢是可以讓整個應用的流量智能化，但是負載均衡設備需要提供完善的七層功能，滿足客戶根據不同情況的基於應用的調度。最簡單的一個考核就是能否取代後台Nginx或者Apache等伺服器上的調度功能。能夠提供一個七層應用開發介面的負載均衡設備，可以讓客戶根據需求任意設定功能，才真正有可能提供強大的靈活性和智能性。
（三）
負載均衡四七層介紹:
負載均衡（Load Balance）建立在現有網路結構之上，它提供了一種廉價有效透明的方法擴展網路設備和伺服器的帶寬、增加吞吐量、加強網路數據處理能力、提高網路的靈活性和可用性。
負載均衡有兩方面的含義：首先，大量的並發訪問或數據流量分擔到多台節點設備上分別處理，減少用戶等待響應的時間；其次，單個重負載的運算分擔到多台節點設備上做並行處理，每個節點設備處理結束後，將結果匯總，返回給用戶，系統處理能力得到大幅度提高。
本文所要介紹的負載均衡技術主要是指在均衡伺服器群中所有伺服器和應用程序之間流量負載的應用，目前負載均衡技術大多數是用於提高諸如在Web伺服器、FTP伺服器和其它關鍵任務伺服器上的Internet伺服器程序的可用性和可伸縮性。
負載均衡技術分類
目前有許多不同的負載均衡技術用以滿足不同的應用需求，下面從負載均衡所採用的設備對象、應用的網路層次（指OSI參考模型）及應用的地理結構等來分類。
軟/硬體負載均衡
軟體負載均衡解決方案是指在一台或多台伺服器相應的操作系統上安裝一個或多個附加軟體來實現負載均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的優點是基於特定環境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求。
軟體解決方案缺點也較多，因為每台伺服器上安裝額外的軟體運行會消耗系統不定量的資源，越是功能強大的模塊，消耗得越多，所以當連接請求特別大的時候，軟體本身會成為伺服器工作成敗的一個關鍵；軟體可擴展性並不是很好，受到操作系統的限制；由於操作系統本身的Bug，往往會引起安全問題。
硬體負載均衡解決方案是直接在伺服器和外部網路間安裝負載均衡設備，這種設備我們通常稱之為負載均衡器，由於專門的設備完成專門的任務，獨立於操作系統，整體性能得到大量提高，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。
負載均衡器有多種多樣的形式，除了作為獨立意義上的負載均衡器外，有些負載均衡器集成在交換設備中，置於伺服器與Internet鏈接之間，有些則以兩塊網路適配器將這一功能集成到PC中，一塊連接到Internet上，一塊連接到後端伺服器群的內部網路上。
一般而言，硬體負載均衡在功能、性能上優於軟體方式，不過成本昂貴。
本地/全局負載均衡
負載均衡從其應用的地理結構上分為本地負載均衡(Local Load Balance)和全局負載均衡(Global Load Balance，也叫地域負載均衡)，本地負載均衡是指對本地的伺服器群做負載均衡，全局負載均衡是指對分別放置在不同的地理位置、有不同網路結構的伺服器群間作負載均衡。
本地負載均衡能有效地解決數據流量過大、網路負荷過重的問題，並且不需花費昂貴開支購置性能卓越的伺服器，充分利用現有設備，避免伺服器單點故障造成數據流量的損失。其有靈活多樣的均衡策略把數據流量合理地分配給伺服器群內的伺服器共同負擔。即使是再給現有伺服器擴充升級，也只是簡單地增加一個新的伺服器到服務群中，而不需改變現有網路結構、停止現有的服務。
全局負載均衡主要用於在一個多區域擁有自己伺服器的站點，為了使全球用戶只以一個IP地址或域名就能訪問到離自己最近的伺服器，從而獲得最快的訪問速度，也可用於子公司分散站點分布廣的大公司通過Intranet（企業內部互聯網）來達到資源統一合理分配的目的。
網路層次上的負載均衡
針對網路上負載過重的不同瓶頸所在，從網路的不同層次入手，我們可以採用相應的負載均衡技術來解決現有問題。
隨著帶寬增加，數據流量不斷增大，網路核心部分的數據介面將面臨瓶頸問題，原有的單一線路將很難滿足需求，而且線路的升級又過於昂貴甚至難以實現，這時就可以考慮採用鏈路聚合（Trunking）技術。
鏈路聚合技術（第二層負載均衡）將多條物理鏈路當作一條單一的聚合邏輯鏈路使用，網路數據流量由聚合邏輯鏈路中所有物理鏈路共同承擔，由此在邏輯上增大了鏈路的容量，使其能滿足帶寬增加的需求。
現代負載均衡技術通常操作於網路的第四層或第七層。第四層負載均衡將一個Internet上合法注冊的IP地址映射為多個內部伺服器的IP地址，對每次 TCP連接請求動態使用其中一個內部IP地址，達到負載均衡的目的。在第四層交換機中，此種均衡技術得到廣泛的應用，一個目標地址是伺服器群VIP（虛擬 IP，Virtual IP address）連接請求的數據包流經交換機，交換機根據源端和目的IP地址、TCP或UDP埠號和一定的負載均衡策略，在伺服器IP和VIP間進行映射，選取伺服器群中最好的伺服器來處理連接請求。
第七層負載均衡控制應用層服務的內容，提供了一種對訪問流量的高層控制方式，適合對HTTP伺服器群的應用。第七層負載均衡技術通過檢查流經的HTTP報頭，根據報頭內的信息來執行負載均衡任務。
第七層負載均衡優點表現在如下幾個方面：
通過對HTTP報頭的檢查，可以檢測出HTTP400、500和600系列的錯誤信息，因而能透明地將連接請求重新定向到另一台伺服器，避免應用層故障。
可根據流經的數據類型（如判斷數據包是圖像文件、壓縮文件或多媒體文件格式等），把數據流量引向相應內容的伺服器來處理，增加系統性能。
能根據連接請求的類型，如是普通文本、圖象等靜態文檔請求，還是asp、cgi等的動態文檔請求，把相應的請求引向相應的伺服器來處理，提高系統的性能及安全性。
第七層負載均衡受到其所支持的協議限制（一般只有HTTP），這樣就限制了它應用的廣泛性，並且檢查HTTP報頭會佔用大量的系統資源，勢必會影響到系統的性能，在大量連接請求的情況下，負載均衡設備自身容易成為網路整體性能的瓶頸。
負載均衡策略
在實際應用中，我們可能不想僅僅是把客戶端的服務請求平均地分配給內部伺服器，而不管伺服器是否宕機。而是想使Pentium III伺服器比Pentium II能接受更多的服務請求，一台處理服務請求較少的伺服器能分配到更多的服務請求，出現故障的伺服器將不再接受服務請求直至故障恢復等等。
選擇合適的負載均衡策略，使多個設備能很好的共同完成任務，消除或避免現有網路負載分布不均、數據流量擁擠反應時間長的瓶頸。在各負載均衡方式中，針對不同的應用需求，在OSI參考模型的第二、三、四、七層的負載均衡都有相應的負載均衡策略。
負載均衡策略的優劣及其實現的難易程度有兩個關鍵因素：一、負載均衡演算法，二、對網路系統狀況的檢測方式和能力。
考慮到服務請求的不同類型、伺服器的不同處理能力以及隨機選擇造成的負載分配不均勻等問題，為了更加合理的把負載分配給內部的多個伺服器，就需要應用相應的能夠正確反映各個伺服器處理能力及網路狀態的負載均衡演算法：
輪循均衡（Round Robin）：每一次來自網路的請求輪流分配給內部中的伺服器，從1至N然後重新開始。此種均衡演算法適合於伺服器組中的所有伺服器都有相同的軟硬體配置並且平均服務請求相對均衡的情況。
權重輪循均衡（Weighted Round Robin）：根據伺服器的不同處理能力，給每個伺服器分配不同的權值，使其能夠接受相應權值數的服務請求。例如：伺服器A的權值被設計成1，B的權值是 3，C的權值是6，則伺服器A、B、C將分別接受到10%、30％、60％的服務請求。此種均衡演算法能確保高性能的伺服器得到更多的使用率，避免低性能的伺服器負載過重。
隨機均衡（Random）：把來自網路的請求隨機分配給內部中的多個伺服器。
權重隨機均衡（Weighted Random）：此種均衡演算法類似於權重輪循演算法，不過在處理請求分擔時是個隨機選擇的過程。
響應速度均衡（Response Time）：負載均衡設備對內部各伺服器發出一個探測請求（例如Ping），然後根據內部中各伺服器對探測請求的最快響應時間來決定哪一台伺服器來響應客戶端的服務請求。此種均衡演算法能較好的反映伺服器的當前運行狀態，但這最快響應時間僅僅指的是負載均衡設備與伺服器間的最快響應時間，而不是客戶端與伺服器間的最快響應時間。
最少連接數均衡（Least Connection）：客戶端的每一次請求服務在伺服器停留的時間可能會有較大的差異，隨著工作時間加長，如果採用簡單的輪循或隨機均衡演算法，每一台伺服器上的連接進程可能會產生極大的不同，並沒有達到真正的負載均衡。最少連接數均衡演算法對內部中需負載的每一台伺服器都有一個數據記錄，記錄當前該伺服器正在處理的連接數量，當有新的服務連接請求時，將把當前請求分配給連接數最少的伺服器，使均衡更加符合實際情況，負載更加均衡。此種均衡演算法適合長時處理的請求服務，如FTP。
處理能力均衡：此種均衡演算法將把服務請求分配給內部中處理負荷（根據伺服器CPU型號、CPU數量、內存大小及當前連接數等換算而成）最輕的伺服器，由於考慮到了內部伺服器的處理能力及當前網路運行狀況，所以此種均衡演算法相對來說更加精確，尤其適合運用到第七層（應用層）負載均衡的情況下。
DNS響應均衡（Flash DNS）：在Internet上，無論是HTTP、FTP或是其它的服務請求，客戶端一般都是通過域名解析來找到伺服器確切的IP地址的。在此均衡演算法下，分處在不同地理位置的負載均衡設備收到同一個客戶端的域名解析請求，並在同一時間內把此域名解析成各自相對應伺服器的IP地址（即與此負載均衡設備在同一位地理位置的伺服器的IP地址）並返回給客戶端，則客戶端將以最先收到的域名解析IP地址來繼續請求服務，而忽略其它的IP地址響應。在種均衡策略適合應用在全局負載均衡的情況下，對本地負載均衡是沒有意義的。
盡管有多種的負載均衡演算法可以較好的把數據流量分配給伺服器去負載，但如果負載均衡策略沒有對網路系統狀況的檢測方式和能力，一旦在某台伺服器或某段負載均衡設備與伺服器網路間出現故障的情況下，負載均衡設備依然把一部分數據流量引向那台伺服器，這勢必造成大量的服務請求被丟失，達不到不間斷可用性的要求。所以良好的負載均衡策略應有對網路故障、伺服器系統故障、應用服務故障的檢測方式和能力：
Ping偵測：通過ping的方式檢測伺服器及網路系統狀況，此種方式簡單快速，但只能大致檢測出網路及伺服器上的操作系統是否正常，對伺服器上的應用服務檢測就無能為力了。
TCP Open偵測：每個服務都會開放某個通過TCP連接，檢測伺服器上某個TCP埠（如Telnet的23口，HTTP的80口等）是否開放來判斷服務是否正常。
HTTP URL偵測：比如向HTTP伺服器發出一個對main.html文件的訪問請求，如果收到錯誤信息，則認為伺服器出現故障。
負載均衡策略的優劣除受上面所講的兩個因素影響外，在有些應用情況下，我們需要將來自同一客戶端的所有請求都分配給同一台伺服器去負擔，例如伺服器將客戶端注冊、購物等服務請求信息保存的本地資料庫的情況下，把客戶端的子請求分配給同一台伺服器來處理就顯的至關重要了。有兩種方式可以解決此問題，一是根據IP地址把來自同一客戶端的多次請求分配給同一台伺服器處理，客戶端IP地址與伺服器的對應信息是保存在負載均衡設備上的；二是在客戶端瀏覽器 cookie內做獨一無二的標識來把多次請求分配給同一台伺服器處理，適合通過代理伺服器上網的客戶端。
還有一種路徑外返回模式（Out of Path Return），當客戶端連接請求發送給負載均衡設備的時候，中心負載均衡設備將請求引向某個伺服器，伺服器的回應請求不再返回給中心負載均衡設備，即繞過流量分配器，直接返回給客戶端，因此中心負載均衡設備只負責接受並轉發請求，其網路負擔就減少了很多，並且給客戶端提供了更快的響應時間。此種模式一般用於HTTP伺服器群，在各伺服器上要安裝一塊虛擬網路適配器，並將其IP地址設為伺服器群的VIP，這樣才能在伺服器直接回應客戶端請求時順利的達成三次握手。
負載均衡實施要素
負載均衡方案應是在網站建設初期就應考慮的問題，不過有時隨著訪問流量的爆炸性增長，超出決策者的意料，這也就成為不得不面對的問題。當我們在引入某種負載均衡方案乃至具體實施時，像其他的許多方案一樣，首先是確定當前及將來的應用需求，然後在代價與收效之間做出權衡。
針對當前及將來的應用需求，分析網路瓶頸的不同所在，我們就需要確立是採用哪一類的負載均衡技術，採用什麼樣的均衡策略，在可用性、兼容性、安全性等等方面要滿足多大的需求，如此等等。
不管負載均衡方案是採用花費較少的軟體方式，還是購買代價高昂在性能功能上更強的第四層交換機、負載均衡器等硬體方式來實現，亦或其他種類不同的均衡技術，下面這幾項都是我們在引入均衡方案時可能要考慮的問題：
性能：性能是我們在引入均衡方案時需要重點考慮的問題，但也是一個最難把握的問題。衡量性能時可將每秒鍾通過網路的數據包數目做為一個參數，另一個參數是均衡方案中伺服器群所能處理的最大並發連接數目，但是，假設一個均衡系統能處理百萬計的並發連接數，可是卻只能以每秒2個包的速率轉發，這顯然是沒有任何作用的。性能的優劣與負載均衡設備的處理能力、採用的均衡策略息息相關，並且有兩點需要注意：一、均衡方案對伺服器群整體的性能，這是響應客戶端連接請求速度的關鍵；二、負載均衡設備自身的性能，避免有大量連接請求時自身性能不足而成為服務瓶頸。有時我們也可以考慮採用混合型負載均衡策略來提升伺服器群的總體性能，如DNS負載均衡與NAT負載均衡相結合。另外，針對有大量靜態文檔請求的站點，也可以考慮採用高速緩存技術，相對來說更節省費用，更能提高響應性能；對有大量ssl/xml內容傳輸的站點，更應考慮採用ssl/xml加速技術。
可擴展性：IT技術日新月異，一年以前最新的產品，現在或許已是網路中性能最低的產品；業務量的急速上升，一年前的網路，現在需要新一輪的擴展。合適的均衡解決方案應能滿足這些需求，能均衡不同操作系統和硬體平台之間的負載，能均衡HTTP、郵件、新聞、代理、資料庫、防火牆和 Cache等不同伺服器的負載，並且能以對客戶端完全透明的方式動態增加或刪除某些資源。
靈活性：均衡解決方案應能靈活地提供不同的應用需求，滿足應用需求的不斷變化。在不同的伺服器群有不同的應用需求時，應有多樣的均衡策略提供更廣泛的選擇。
可靠性：在對服務質量要求較高的站點，負載均衡解決方案應能為伺服器群提供完全的容錯性和高可用性。但在負載均衡設備自身出現故障時，應該有良好的冗餘解決方案，提高可靠性。使用冗餘時，處於同一個冗餘單元的多個負載均衡設備必須具有有效的方式以便互相進行監控，保護系統盡可能地避免遭受到重大故障的損失。
易管理性：不管是通過軟體還是硬體方式的均衡解決方案，我們都希望它有靈活、直觀和安全的管理方式，這樣便於安裝、配置、維護和監控，提高工作效率，避免差錯。在硬體負載均衡設備上，目前主要有三種管理方式可供選擇：一、命令行介面（CLI：Command Line Interface），可通過超級終端連接負載均衡設備串列介面來管理，也能telnet遠程登錄管理，在初始化配置時，往往要用到前者；二、圖形用戶介面（GUI：Graphical User Interfaces），有基於普通web頁的管理，也有通過Java Applet 進行安全管理，一般都需要管理端安裝有某個版本的瀏覽器；三、SNMP（Simple Network Management Protocol，簡單網路管理協議）支持，通過第三方網路管理軟體對符合SNMP標準的設備進行管理。
⑸ 針對SYN Flood攻擊，請提出一個檢測攻擊和防禦攻擊的方法，並闡述理由。
SYN Flood是當前最流行的DoS（拒絕服務攻擊）與DdoS（分布式拒絕服務攻擊）的方式之一，這是一種利用TCP協議缺陷，發送大量偽造的TCP連接請求，從而使得被攻擊方資源耗盡（CPU滿負荷或內存不足）的攻擊方式。
要明白這種攻擊的基本原理，還是要從TCP連接建立的過程開始說起：
大家都知道，TCP與UDP不同，它是基於連接的，也就是說：為了在服務端和客戶端之間傳送TCP數據，必須先建立一個虛擬電路，也就是TCP連接，建立TCP連接的標准過程是這樣的：
首先，請求端（客戶端）發送一個包含SYN標志的TCP報文，SYN即同步（Synchronize），同步報文會指明客戶端使用的埠以及TCP連接的初始序號；
第二步，伺服器在收到客戶端的SYN報文後，將返回一個SYN+ACK的報文，表示客戶端的請求被接受，同時TCP序號被加一，ACK即確認（Acknowledgment）。
第三步，客戶端也返回一個確認報文ACK給伺服器端，同樣TCP序列號被加一，到此一個TCP連接完成。
以上的連接過程在TCP協議中被稱為三次握手（Three-way Handshake）。
問題就出在TCP連接的三次握手中，假設一個用戶向伺服器發送了SYN報文後突然死機或掉線，那麼伺服器在發出SYN+ACK應答報文後是無法收到客戶端的ACK報文的（第三次握手無法完成），這種情況下伺服器端一般會重試（再次發送SYN+ACK給客戶端）並等待一段時間後丟棄這個未完成的連接，這段時間的長度我們稱為SYN Timeout，一般來說這個時間是分鍾的數量級（大約為30秒-2分鍾）；一個用戶出現異常導致伺服器的一個線程等待1分鍾並不是什麼很大的問題，但如果有一個惡意的攻擊者大量模擬這種情況，伺服器端將為了維護一個非常大的半連接列表而消耗非常多的資源----數以萬計的半連接，即使是簡單的保存並遍歷也會消耗非常多的CPU時間和內存，何況還要不斷對這個列表中的IP進行SYN+ACK的重試。實際上如果伺服器的TCP/IP棧不夠強大，最後的結果往往是堆棧溢出崩潰---即使伺服器端的系統足夠強大，伺服器端也將忙於處理攻擊者偽造的TCP連接請求而無暇理睬客戶的正常請求（畢竟客戶端的正常請求比率非常之小），此時從正常客戶的角度看來，伺服器失去響應，這種情況我們稱作：伺服器端受到了SYN Flood攻擊（SYN洪水攻擊）。
從防禦角度來說，有幾種簡單的解決方法：
第一種是縮短SYN Timeout時間，由於SYN Flood攻擊的效果取決於伺服器上保持的SYN半連接數，這個值=SYN攻擊的頻度 x SYN Timeout，所以通過縮短從接收到SYN報文到確定這個報文無效並丟棄改連接的時間，例如設置為20秒以下（過低的SYN Timeout設置可能會影響客戶的正常訪問），可以成倍的降低伺服器的負荷。
第二種方法是設置SYN Cookie，就是給每一個請求連接的IP地址分配一個Cookie，如果短時間內連續受到某個IP的重復SYN報文，就認定是受到了攻擊，以後從這個IP地址來的包會被丟棄。
可是上述的兩種方法只能對付比較原始的SYN Flood攻擊，縮短SYN Timeout時間僅在對方攻擊頻度不高的情況下生效，SYN Cookie更依賴於對方使用真實的IP地址，如果攻擊者以數萬/秒的速度發送SYN報文，同時利用SOCK_RAW隨機改寫IP報文中的源地址，以上的方法將毫無用武之地。
⑹ 簡述三次握手演算法。。。。計算機十道題
1.OSI七層：物理層，數據鏈路層，網路層，傳輸層，會話層，表示層，應用層。TCP/IP四層：網路介面層、網路層、傳輸層、應用層。
2.看不懂。
3.HTTP協議。
4.發送使用SMTP，讀取使用POP3和IMAP。
5.IP（Internet Protocol）:Internet協議，負責TCP/IP主機間提供數據報服務，進行數據封裝並產生協議頭，TCP與UDP協議的基礎。
ICMP（Internet Control Message Protocol）：Internet控制報文協議。ICMP協議其實是IP協議的的附屬協議，IP協議用它來與其它主機或路由器交換錯誤報文和其它的一 些網路情況，在ICMP包中攜帶了控制信息和故障恢復信息。
ARP（Address Resolution Protocol）協議：地址解析協議。
RARP（Reverse Address Resolution Protocol）：逆向地址解析協議。
6.分別是UDP，TCP，TCP，TCP。
7.所謂的統一資源定位器又叫URL.就是你輸入網址的地方.瀏覽器用它對你要訪問的資源進行描述.由三部分組成:協議型,主機名,路徑及文件名.如http://www.bau.com/
8.很簡單，就是提供傳輸服務----為基於應用層的TELNET、HTTP、FTP、POP、SMTP、DNS等應用提供端到端的連接，途徑有兩種，TCP：傳輸控制協議，面向連接可靠的，傳輸效率低，速度慢；UDP：用戶數據報協議，面向非連接，不可靠的，傳輸效率高，速度快
9.HTTP的埠號為80， Telnet（遠程登錄）為23，FTP（文件傳輸）為21
10.在TCP/IP協議中，TCP協議提供可靠的連接服務，採用三次握手建立一個連接。
第一次握手：建立連接時，客戶端發送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；
第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端 和伺服器進入ESTABLISHED狀態，完成三次握手。
⑺ 數字簽名的經典演算法和流行演算法是什麼
數字簽名是
用私鑰加的密
私鑰加密的內容是信息的MD5值
既然是私鑰了那麼肯定是非對稱加密了