OSI是一個開放性的通信系統互連參考模型，他是一個定義得非常好的協議規範。OSI模型有7層結構，每層都可以有幾個子層。 OSI的7層從上到下分別是 7 應用層6 表示層 5 會話層 4 傳輸層3 網絡層 2 數據鏈路層 1 物理層；其中高層（即7、6、5、4層）定義了應用程序的功能，下面3層（即3、2、1層）主要面向通過網絡的端到端的數據流。應用層與其它計算機進行通訊的一個應用，它是對應應用程序的通信服務的。例如，一個沒有通信功能的字處理程序就不能執行通信的代碼，從事字處理工作的程序員也不關心OSI的第7層。但是，如果添加了一個傳輸文件的選項，那麼字處理器的程序員就需要實現OSI的第7層。示例：TELNET，HTTP，FTP，NFS，SMTP等。
應用層
與其它計算機進行通訊的一個應用，它是對應應用程序的通信服務的。例如，一個沒有通信功能的字處理程序就不能執行通信的代碼，從事字處理工作的程序員也不關心OSI的第7層。但是，如果添加了一個傳輸文件的選項，那麼字處理器的程序就需要實現OSI的第7層。示例：TELNET，HTTP，FTP，NFS，SMTP等。
表示層
這一層的主要功能是定義數據格式及加密。例如，FTP允許你選擇以二進制或ASCII格式傳輸。如果選擇二進制，那麼發送方和接收方不改變文件的內容。如果選擇ASCII格式，發送方將把文本從發送方的字符集轉換成標準的ASCII後發送數據。在接收方將標準的ASCII轉換成接收方計算機的字符集。示例：加密，ASCII等。
會話層
它定義瞭如何開始、控制和結束一個會話，包括對多個雙向消息的控制和管理，以便在只完成連續消息的一部分時可以通知應用，從而使表示層看到的數據是連續的，在某些情況下，如果表示層收到了所有的數據，則用數據代表表示層。示例：RPC，SQL等。
傳輸層這層的功能包括是否選擇差錯恢復協議還是無差錯恢復協議，及在同一主機上對不同應用的數據流的輸入進行復用，還包括對收到的順序不對的數據包的重新排序功能。示例：TCP，UDP，SPX。
網絡層
這層對端到端的包傳輸進行定義，它定義了能夠標識所有結點的邏輯地址，還定義了路由實現的方式和學習的方式。為了適應最大傳輸單元長度小於包長度的傳輸介質，網絡層還定義瞭如何將一個包分解成更小的包的分段方法。示例：IP，IPX等。
數據鏈路層
它定義了在單個鏈路上如何傳輸數據。這些協議與被討論的各種介質有關。示例：ATM，FDDI等。
物理層OSI的物理層規範是有關傳輸介質的特性標準，這些規範通常也參考了其他組織制定的標準。連接頭、幀、幀的使用、電流、編碼及光調製等都屬於各種物理層規範中的內容。物理層常用多個規範完成對所有細節的定義。
網絡層攻擊
Syn-flood
利用TCP建立連接時3次握手的“漏洞”，通過原始套接字發送源地址虛假的SYN報文，使目標主機永遠無法完成3次握手，佔滿了系統的協議棧隊列，資源得不到釋放，進而拒絕服務，是互聯網中最主要的DDOS攻擊形式之一。
網上有一些加固的方法，例如調整內核參數的方法，可以減少等待及重試，加速資源釋放，在小流量syn-flood的情況下可以緩解，但流量稍大時完全不抵用。防禦syn-flood的常見方法有：syn proxy、syn cookies、首包(第一次請求的syn包)丟棄等。
ACK-flood
對於虛假的ACK包，目標設備會直接回復RST包丟棄連接，所以傷害值遠不如syn-flood。DDOS的一種原始方式。
UDP-flood
使用原始套接字偽造大量虛假源地址的UDP包，目前以DNS協議為主。
ICMP-flood
Ping洪水，比較古老的方式。
應用層攻擊
CC
ChallengeCollapsar的名字源於挑戰國內知名安全廠商綠盟的抗DDOS設備-“黑洞”，通過botnet的傀儡主機或尋找匿名代{過}{濾}理服務器，向目標發起大量真實的http請求，最終消耗掉大量的併發資源，拖慢整個網站甚至徹底拒絕服務。
互聯網的架構追求擴展性本質上是為了提高併發能力，各種SQL性能優化措施：消除慢查詢、分表分庫、索引、優化數據結構、限制搜索頻率等本質都是為了解決資源消耗，而CC大有反其道而行之的意味，佔滿服務器併發連接數，儘可能使請求避開緩存而直接讀數據庫，讀數據庫要找最消耗資源的查詢，最好無法利用索引，每個查詢都全表掃描，這樣就能用最小的攻擊資源起到最大的拒絕服務效果。
互聯網產品和服務依靠數據分析來驅動改進和持續運營，所以除了前端的APP、中間件和數據庫這類OLTP系統，後面還有OLAP，從日誌收集，存儲到數據處理和分析的大數據平臺，當CC攻擊發生時，不僅OLTP的部分受到了影響，實際上CC會產生大量日誌，直接會對後面的OLAP產生影響，影響包括兩個層面，一個當日的數據統計完全是錯誤的。第二個層面因CC期間訪問日誌劇增也會加大後端數據處理的負擔。
DDOS攻擊本質上是一種只能緩解而不能完全防禦的攻擊，它不像漏洞那樣打個補丁解決了就是解決了，DDOS就算購買和部署了當前市場上比較有競爭力的防禦解決方案也完全談不上徹底根治。防火牆、IPS、WAF這些安全產品都號稱自己有一定的抗DDOS能力，而實際上他們只針對小流量下，應用層的攻擊比較有效，對於稍大流量的DDOS攻擊則無濟於事。
以2015年年中的情況為例，國內的DDOS攻擊在一個月內攻擊流量達到300G的就將近10-20次，這個數值將隨著國內家庭寬帶網速提升而進一步放大。對於200~500G的攻擊流量該如何防禦，下來將展示完整的防禦結構，通常可以分為4層。
這4層不是嚴格意義上的縱深防禦關係，也不是在所有的防禦中4層都會參與，可能有時候只是其中的2層參與防禦。但對於超大流量攻擊而言，4層就是防禦機制的全部，再沒有其他手段了。跟廠商們的市場宣傳可能有所不同，大流量攻擊的防護並不是像某些廠商宣稱的那樣靠廠商單方面就能解決的，而是多層共同參與防禦的結果。
ISP/WAN層
這一層通常對最終用戶不可見，如果只是中小企業，那這一層可能真的不會接觸到。但如果是大型互聯網公司，公有云廠商，甚至是雲清洗廠商，這層是必不可少的。因為當流量超過自己能處理的極限時必須要藉助電信運營商的能力。大型互聯網公司雖然自身儲備的帶寬比較大，但還沒到達輕鬆抵抗大流量DDOS的程度，畢竟帶寬是所有IDC成本中最貴的資源沒有之一。目前無論是雲計算廠商，大型互聯網公司向外宣稱的成功抵禦200G以上攻擊的新聞背後都用到了運營商的抗D能力，另外像第三方的雲清洗平臺他們實際上或多或少的依賴電信運營商，如果只依靠本身的清洗能力，都是非常有限的。
相比之下，對攻擊流量的牽引，清洗，回注的防禦方式對用戶體驗的挑戰沒那麼大，但是跟黑洞路由比防禦方的成本比較高，且觸發到響應的延時較大。
在運營商防禦這一層的主要的參與者是大型互聯網公司，公有云廠商，雲清洗廠商，其最大的意義在於應對超過自身帶寬儲備和自身DDOS防禦能力之外的超大攻擊流量時作為補充性的緩解措施。
CDN/Internet層
CDN並不是一種抗DDOS的產品，但對於web類服務而言，他卻正好有一定的抗DDOS能力，以大型電商的搶購為例，這個訪問量非常大，從很多指標上看不亞於DDOS的CC，而在平臺側實際上在CDN層面用驗證碼過濾了絕大多數請求，最後到達數據庫的請求只佔整體請求量的很小一部分。
對http CC類型的DDOS，不會直接到源站，CDN會先通過自身的帶寬硬抗，抗不了的或者穿透CDN的動態請求會到源站，如果源站前端的抗DDOS能力或者源站前的帶寬比較有限，就會被徹底DDOS。
雲清洗廠商提出的策略是，預先設置好網站的CNAME，將域名指向雲清洗廠商的DNS服務器，在一般情況下，雲清洗廠商的DNS仍將穿透CDN的回源的請求指向源站，在檢測到攻擊發生時，域名指向自己的清洗集群，然後再將清洗後的流量回源。
檢測方式主要是在客戶網站前部署反向代{過}{濾}理(nginx)，託管所有的併發連接。在對攻擊流量進行分流的時候，準備好一個域名到IP的地址池，當IP被攻擊時封禁並啟用地址池中的下一個IP，如此往復。
網上很多使用此類抗D服務的過程可以概括為一句話：更改CNAME指向，等待DNS遞歸生效。
DC層
Datacenter這一層的DDOS防禦屬於近目的清洗，就是在DC出口的地方部署ADS設備。
OS/APP層
這是DDOS的最後一道防線。這一層的意義主要在於漏過ADS設備的流量做最後一次過濾和緩解，對ADS防護不了的應用層協議做補充防護。比如NTP反射，可以通過服務器配置禁用monlist，如果不提供基於UDP的服務，可以在邊界上直接阻斷UDP協議。
互聯網在線服務中最大的比重就是web服務，因此有些互聯網公司喜歡自己在系統層面去做應用層的DDOS防護，例如對抗CC，有時這些功能也能順帶關聯到業務安全上
閱讀更多 小蟻雲防 的文章
