第7章SDN應用編程案例7.1基于SDN的ARP代理服務器7.2基于SDN的防DDOS網絡攻擊7.3基于OpenDaylightRESTAPI的應用與開發7.4小結復習思考題

本章給出了三個SDN應用編程案例，分別是

（1）基于SDN的ARP代理服務器；

（2）基于SDN的防DDOS網絡攻擊；

（3）基于OpenDaylight的RESTAPI的應用與開發。

在SDN中，用戶可以通過下發流表的方式改變特定類型數據包的接收目標主機，然后通過接收目標主機上的接收程序捕獲相應的數據幀并進行分析，從而產生一種新的網絡應用。

例如，ARP代理服務器就是通過集中捕獲ARP請求數據幀，記錄不同IP地址對應的MAC地址，并構造ARP響應包發送給請求主機的方式實現ARP代理服務器的功能。類似地，基于SDN的防DDOS網絡攻擊也是將可能存在攻擊的數據包轉到“清洗服務器”上進行特征檢測，對可疑的數據包不進行轉發，正常的數據包則被轉發到目標服務器上。基于OpenDaylight的RESTAPI的應用與開發則是采用Java語言編程的方式，通過調用OpenDaylight提供的RESTAPI實現流表的提取和下發操作，充分展示了SDN可編程的特點。

7.1基于SDN的ARP代理服務器

地址解析協議（AddressResolutionProtocol,ARP）是根據IP地址獲取MAC地址（物理地址）的一個數據鏈路層協議。PC主機發送信息時，將包含目標IP地址的ARP請求廣播到網絡上的所有主機，并接收返回消息，從而獲得目標主機的MAC地址。收到返回消息后，將該IP地址和MAC地址存入本機ARP緩存中并保留一定時間，下次請求時直接查詢ARP緩存以節約資源。

地址解析協議是建立在網絡中各個主機互相信任的基礎上的，網絡中的主機可以自主發送ARP應答消息，其他主機收到應答報文時不會檢測該報文的真實性就會將其記入本機ARP緩存。

ARP協議的處理機制存在兩個問題：其一是可能造成網絡的不安全。例如，攻擊者可以向某一主機發送偽ARP應答報文，使其發送的信息到達錯誤的主機，或無法到達預期的主機，或者直接刪除，從而構成了一個ARP欺騙。其二是ARP請求包以廣播的方式發送給網絡上所有的主機，這無疑會占用一定的網絡資源。

因此，在一些關鍵的網絡中，可能采取ARP代理服務器而非ARP廣播方式。例如，在電力系統的網絡中，通常禁止使用ARP廣播。所謂ARP代理服務器，就是由中間設備代替其他主機響應ARP請求，實際上就是一臺專門用于接收所有ARP請求、并根據本地存儲的MAC地址和IP地址的對應關〖HJ*5/9〗系數據庫生成ARP響應數據包的軟件。這樣既可以避免ARP造成的網絡不安全的問題，又能節省網絡帶寬資源。

此外，在一些大型的服務器上每天都會收到成千上萬臺終端的ARP請求，每當服務器接收到相應的ARP請求時，必然要對其進行應答，這無疑會占用服務器的一定資源。同時，ARP請求會產生一定的網絡廣播，占據一部分的網絡帶寬，在有環的網絡中還會產生網絡廣播風暴，有網絡癱瘓的風險。因此，將ARP的應答功能從服務器中剝離出來是十分必要的。

在傳統網絡中，ARP代理服務器通常設置在路由器上。例如，主機PC1（00）和主機PC2（00）雖然屬于不同的廣播域，但它們處于同一網段中，所以當PC1向PC2發出ARP請求廣播包，請求獲得PC2的MAC地址時，由于路由器不會轉發廣播包，因此ARP請求只能到達路由器，不能到達PC2。而當在路由器上啟用ARP代理后，路由器會查看ARP請求，發現IP地址00屬于它連接的另一個網絡，因此路由器就會用自己的接口MAC地址代替PC2的MAC地址，向PC1發送了一個ARP應答。

PC1收到ARP應答后，會認為路由器的MAC地址就是PC2的MAC地址，不會感知到ARP代理的存在。這種路由器上的ARP實際上并不是專為解決ARP所帶來兩個問題，而是專注于網絡的透明傳輸。ARP代理服務器的設計思路是設置一臺專門的主機用于接收所有的ARP請求，這就要求交換機可以識別ARP請求數據包，并將該數據包以單播的方式發送給ARP代理服務器，代理服務器解析接收到的數據包，根據所請求的IP地址查找本地數據庫，找到對應MAC地址，再封裝成ARP響應包發送給請求者。

傳統的交換機由于無法直接進行編程，所以除非廠商自己，其他用戶很難在普通的交換機上實現上述識別ARP請求并進行轉發到特定主機的功能。但在SDN交換機上由于流表可以由用戶自己設定，因而利用SDN技術可以輕松實現識別ARP請求并進行轉發到特定主機的功能。

7.1.1基于SDN的ARP代理服務器實現原理

本節中ARP代理服務器是利用SDN技術實現的，遠端PC的ARP請求包通過SDN交換機時，SDN交換機應用流表將該數據包轉發到ARP代理服務器，ARP代理服務器捕獲該數據包并進行ARP代答，具體實現流程如圖7-1所示。終端主機數據包通過入端口進入SDN交換機，在SDN交換機上配置相應的流表，該流表設置為：判斷進入的數據包是否為ARP請求包，動作設置為出端口到代理服務器所連接的物理端口上。

代理服務器收到該數據包，分析幀結構的目的IP地址，并從本地數據庫中得到該IP地址對應的MAC地址，將該IP地址和MAC地址作為源IP地址和源MAC地址，將ARP請求中的源IP地址和源MAC作為目的IP地址和目的MAC地址封裝成ARP響應數據幀，以單播方式發送到網絡上，從而完成ARP代理功能。另外，為了保證本地保存的IP地址和MAC地址對應關系的正確性，每收到一個ARP請求，均要將源IP地址和源MAC地址與本地保存的數據進行比對，如果不一致將更新本地數據庫，如果不存在則在本地數據庫中記錄該IP地址和MAC地址的對應關系。本節中的ARP代理服務器程序采用C語言編寫，應用原始套接字編程技術實現，在7.1.3節中將對ARP代理服務器的源碼進行詳細分析。

SDN交換機上的流表可以通過SDN控制器OpenDaylight（ODL）設置，或者直接通過OpenvSwitch交換機上的流表設置命令完成，也可以通過調用ODL提供的RESTAPI接口直接在ARP代理服務器程序中設置。

圖7-1ARP代理服務器實現流程圖

7.1.2基于SDN的ARP代理服務器網絡設置

實驗中用到的主要設備有：安裝有OpenDaylightBeryllium版本的控制器一臺、OpenvSwitch2.5.0版本的交換機一臺、終端PC機三臺。終端PC機的配置信息如表7－1所示，網絡拓撲圖如圖7-2所示。

圖7-2ARP代理服務器網絡拓撲圖

本節中通過主機PC1pingPC2來驗證和測試ARP代理服務器軟件的正確性。如果ARP代理服務器未啟動，則PC1不能ping通PC2，反之則能ping通。這個結果說明ARP代理服務器確實起到了代理ARP響應的作用。實驗的主要步驟如下：

（1）在ODL控制器端啟動OpenDaylight控制器。

（2）在PC2上查詢ARP緩沖表，并刪除PC2的MAC地址以確保使用ping命令時能夠首先發出的是ARP請求包。查看本機ARP緩沖表的命令為arp，刪除命令為arp－d主機名，如圖7-3所示。

圖7-3查看ARP緩沖表以及刪除MAC地址

（3）在SDN交換機端上使用ovs-ofctladd-flow命令添加如下流表：

Ovs-ofctladd-flowbr0priority=152,arp,arp_op=1,actions=output:4

其中各參數含義如下：

①br0：表示本例SDN交換機中設置的網橋。

②priority=152：表示流表的優先級，一般設置的值大于100。根據OpenFlow1.3協議規定，在同一標號的流表中，優先級越高的流表項被越先選中進行條件匹配。

③arp,arp_op=1：表示匹配的數據包為ARP請求包，arp_op=1表示的是ARP類型，即請求包。

④actions=output:4：表示流表動作是將匹配到的數據包發到SDN交換機的物理端口4，也就是轉發給ARP代理服務器所在的終端PC3。

（4）查看流表，驗證流表是否設置成功（見圖7-4）。

圖7-4查看SDN交換機的所有流表

（5）在PC1上執行pingPC2的命令。由于PC1現在不知道PC2的MAC地址，所以此次ping命令將首先發送的是ARP請求包，但是由于流表項的作用，使得發送的ARP包轉給了PC3，所以發現ping不通，但是匹配的流表項有數據包增加，證明流表生效，如圖7-5和7-6所示。

圖7-5在未啟動ARP代理服務器的情況下PC1pingPC2圖7-6SDN交換機上流表項統計數據包數量增加

（6）在PC3上啟動ARP代理服務器程序，該服務器代理程序為arp_proxy。在啟動代理服務器程序之前需要將本地網卡設置為混雜模式，該命令如下：

$#sudo

ifconfigeth0promisc

運行代理程序的命令為

$#./arp_proxy

（7）在PC1上再次pingPC2，這時發現PC1可以ping通PC2，說明ARP代理服務器已經發出了ARP響應。查看PC1的本地ARP緩沖表，可以看到PC2的MAC地址，同時，在PC3上也能看到。這說明PC3上的ARP代理服務器已經收到PC1發送的ARP請求包，并成功發送ARP響應（如圖7-7、圖7-8、圖7-9所示）。

圖7-7在啟動ARP代理服務器的情況下PC1pingPC2圖7-8在啟動ARP代理服務器的情況下查看PC1的ARP緩沖表圖7-9在PC3上ARP代理服務器的運行情況

7.1.3ARP代理服務器的源碼分析

ARP代理服務器程序需要接收數據鏈路層的幀，這里采用原始套接字技術來實現收、發底層數據幀的功能。獲取數據鏈路層幀的另一種方法是采用PCAP開發包，該開發庫給抓包程序提供了一個高層次的接口，網絡上的所有數據包，甚至是那些發送給其他主機的數據包，通過這種機制都可以捕獲。本例中的ARP代理服務器采用C語言編程，邏輯結構簡單。為了簡化對ARP代理服務器的編程，這里忽略了對本地數據存儲的訪問與更新，僅專注于ARP請求包的接收和分析，以及ARP應答包的封裝和發送。

除main函數外，程序由三個函數組成。其中，arp_request_recv函數完成ARP請求包的接收和分析；arp_response_send函數完成ARP應答包的封裝和發送；print_arp_request函數主要負責打印接收到的ARP請求包。

ARP協議的幀格式如圖7-10所示，分為以太網首部和ARP協議字段兩部分，其中，以太網首部共12字節長（目的MAC和源MAC各占6字節）。ARP協議字段部分又分為ARP首部和ARP數據部分。ARP首部包括幀類型（2字節）、硬件類型（2字節）、協議類型（2字節）、硬件地址長度（1字節）、協議地址長度（1字節）和操作類型（2字節）。ARP數據部分包括發送者MAC地址（6字節）、發送者IP地址（4字節）、目的MAC地址（6字節）和目的IP地址（4字節）。

圖7-10ARP協議幀格式

以太網首部定義如下（C語言）：

typedefstructehhdr

{

unsignedchareh_dst[6];/*destinationethernetaddrress*/

unsignedchareh_src[6];/*sourceethernetaddresss*/

unsignedshorteh_type;/*ethernetpachettype*/

}EHHDR,*PEHHDR;

以太網arp字段定義如下：

typedefstructarphdr

{

unsignedshortarp_hrd;/*formatofhardwareaddress*/

unsignedshortarp_pro;/*formatofprotocoladdress*/

unsignedchararp_hln;/*lengthofhardwareaddress*/

unsignedchararp_pln;/*lengthofprotocoladdress*/

unsignedshortarp_op;/*ARP/RARPoperation*/

unsignedchararp_sha［6］;/*senderhardwareaddress*/

unsignedlongarp_spa;/*senderprotocoladdress*/

unsignedchararp_tha［6］;/*targethardwareaddress*/

unsignedlongarp_tpa;/*targetprotocoladdress*/

}ARPHDR,*PARPHDR;

定義整個arp報文包，總長度為42字節：

typedefstructarpPacket

{

EHHDRehhdr;

ARPHDRarphdr;

}ARPPACKET,*PARPPACKET;

程序中需要包含下列頭文件以及宏定義如下：

#include<stdio.h>

#include<string.h>

#include<unistd.h>

#include<stdlib.h>

#include<sys/ioctl.h>

#include<sys/socket.h>

#include<arpa/inet.h>

#include<netinet/in.h>

#include<netinet/if_ether.h>

#include<net/ethernet.h>

#include<net/if_arp.h>

#include<net/if.h>

#include<netpacket/packet.h>

#defineETHER_HEADER_LENsizeof(structether_header)/*以太網幀首部長度*/

#defineETHER_ARP_LENsizeof(structether_arp)/*整個arp結構長度*/

#defineETHER_ARP_PACKET_LENETHER_HEADER_LEN+ETHER_ARP_LEN

#defineIP_ADDR_LEN4/*IP地址長度*/

chararp_mac1［6］={0x00,0x1c,0x25,0xc1,0xe1,0x0f};∥01mac

chararp_mac2［6］={0x74,0x27,0xea,0x23,0xbd,0x52};∥02mac

函數arp_request_recv代碼如下：

voidarp_request_recv(ints)

{

structether_arp*arp_request;

intretlen;

charbuf[ETHER_ARP_PACKET_LEN]={0};

該函數一直不斷地接收數據幀，一旦接收到相關的數據幀，則判斷是否為ARP請求ARPOP_REQUEST。如果是，則打印接收到的ARP請求數據幀的源IP地址、源MAC地址以及目的IP地址，接下來調用arp_response_send函數發送ARP應答包。

7.2基于SDN的防DDOS網絡攻擊

在當前的網絡環境中DDOS攻擊已經非常普遍，而且攻擊的流量在幾秒鐘之內可以達到幾個Gb/s或者更大。在傳統網絡中要防御這些攻擊比較困難，而SDN可以為最復雜的環境提供更高級的網絡監控功能，控制器和交換機能夠分辨各種數據包的屬性，從而能夠對進入應用服務器的流量進行必要的“清洗”，實現對惡意訪問數據的攔截。

7.2.1DDOS防御實現原理

近年來，分布式拒絕服務（DistributedDenialOfService，DDOS）攻擊不斷在因特網上出現，并在應用過程中漸漸得到完善，在Unix或WindowsNT操作系統上已有一系列比較成熟的軟件產品，如Trinoo、TFN、TFN2K、STACHELDRATH等，其核心內容及攻擊思路都是類似的。要了解DDOS的原理，首先要知道拒絕服務攻擊（DOS）的含義，DOS是指攻擊者利用大量的數據“淹沒”目標主機，耗盡目標主機的可用資源直至主機系統崩潰，最終導致目標主機無法為正常用戶提供服務（例如Web頁面服務）。

早期的拒絕服務攻擊主要是針對處理能力比較弱的單機，如個人PC，或是窄帶寬連接的網站，對擁有高帶寬連接、高性能設備的服務器則影響不大，這主要是因為早期的DOS攻擊者往往是單兵作戰，很難在短時間內單獨制造出大量的攻擊數據。但在1999年底，伴隨著DDOS的出現，這種高性能服務器高枕無憂的局面就再也不存在了。DDOS攻擊是指攻擊者借助于客戶/服務器技術，將多個計算機聯合起來作為攻擊平臺，對一個或多個目標發動攻擊，從而成倍地提高拒絕服務攻擊的數量。在這種借助于數百、甚至數千臺被植入攻擊守護進程的攻擊主機同時發起的集團作戰行為中，網絡服務提供商所面對的破壞力是空前巨大的。

圖7-11是典型的DDOS網絡攻擊示意圖，攻擊者利用一些軟件植入手段將攻擊程序植入到連接在互聯網上的主機上，被植入攻擊程序的電腦通常被稱為“肉雞”，即被木馬軟件控制的傀儡計算機，然后攻擊者利用這些“肉雞”發送大量的攻擊報文給服務器，從而造成服務器服務質量下降或系統嚴重癱瘓。

圖7-11DDOS網絡攻擊示意圖

DDOS攻擊的形式很多，主要的或使用頻繁的攻擊方式有：TCPSYNFlood攻擊、TCPACKFlood攻擊、UDPFlood攻擊、ICMPFlood攻擊、ConnectionFlood攻擊、HTTPGet攻擊、UDPDNSQueryFlood攻擊等。其中，TCPSYNFlood攻擊是當前網絡上最為常見的DDOS攻擊，也是最為經典的拒絕服務攻擊。由于TCPSYNFlood攻擊的普遍性，因此，本節主要研究基于SDN對SYNTCPFlood攻擊的防護。

正常的TCP連接需要用到如圖7-12所示的三次握手，當客戶端發送一個帶SYN標志的TCP報文到服務器（第一次握手）時，服務器進程應回應客戶端ACK報文（第二次握手），這個報文同時帶有ACK標志和SYN標志，表示對剛才客戶端SYN報文的回應，同時也表示服務器發送SYN報文給客戶端，詢問客戶端是否準備好進行TCP通信。最后客戶端再次發送一個ACK報文給服務器（第三次握手），這時表明TCP連接成功。

圖7-12TCP建立連接的三次握手

如圖7-13所示，TCPSYNFlood攻擊利用了上述TCP連接協議實現上的一個缺陷。攻擊者通過向網絡服務器發送大量的偽造源IP地址的SYN報文，服務器進程在發出SYN+ACK應答報文后，由于第一次握手中服務器收到的SYN報文源地址是偽造的，因此服務器不可能再接收到客戶端的ACK報文，即第三次握手無法完成。在此情況下，服務器進程一般會重發SYN+ACK給客戶端，并等待一段時間后再丟棄這個未完成的連接，這就可能造成目標服務器中的半開連接隊列被占滿。

通常一臺服務器可用的TCP連接數是有限的，如果惡意攻擊者快速連續地發送此類連接請求，則服務器可用的TCP連接隊列可能很快就會阻塞，因而導致系統可用資源以及網絡可用帶寬急劇下降，結果無法向普通用戶提供正常的網絡服務。TCPSYNFlood攻擊最早出現在1996年，至今仍然出現在現實網絡環境中，很多操作系統和防火墻、路由器都無法有效地防御這種攻擊，并且由于SYN報文的源IP地址是偽造的，事后追查起來也相當困難。

圖7-13TCPSYNFlood攻擊示意圖

傳統的TCPSYNFlood防御技術通常有兩種，第一種是盡量縮短SYN超時等待時間。由于TCPSYNFlood攻擊的效果取決于服務器上保持的SYN半連接數，即這些無效連接占用服務器資源的多少和時長，這些半連接數應等于SYN攻擊的頻度乘以SYN的超時等待時間，所以通過縮短從接收到SYN報文到確定這個報文無效并丟棄該連接的時間，可以成倍地降低服務器的負荷。但過低的SYN超時等待時間的設置可能會影響客戶的正常訪問，即普通用戶由于無法連接TCP服務器而不能與服務器進行通信。第二種方法是設置SYNCookie，就是給每一個請求連接的IP地址分配一個Cookie，如果短時間內連續接收到某個IP的重復SYN報文，就認為是受到了攻擊，那么以后從這個IP地址來的報文一概丟棄。

本節中TCPSYNFlood的防御思路基本上與上述第二種方式相似，主要利用SDN流表配置實現對所有來訪數據報文進行“清洗”，其原理是將發往目標服務器的TCPSYN數據包通過SDN交換機轉發到另一臺代理服務器（簡稱“清洗服務器”）上，然后由該服務器對SDN交換機轉發來的數據包進行清洗，如果發現可能是TCPSYNFlood數據攻擊報文，則丟棄該報文，否則將清洗后的正常數據包發往目標服務器，從而實現對SYNFlood攻擊的防御功能。

本節中的DDOS防御服務器模塊沒有直接在控制器上開發（內嵌在控制器中），而是使用獨立的服務器來完成入侵檢測功能，這樣做的好處是可以避免對開源控制器源代碼結構的理解，缺點是不能很方便地利用控制器所提供的網絡基本服務功能。例如，不能直接利用控制器接收的pack_in報文進行報文檢測，需要自己編寫接收數據幀的程序。與直接在控制器上開發的DDOS防御模塊相比，本方案的優點是可以減輕控制器的負擔，和控制器之間的交集比較少，理解起來相對容易。此外，也可以通過RESTAPI調用SDN控制器提供的底層網絡服務功能，充分利用SDN可編程的特點。

基于SDN的TCPSYNFlood防御實現流程如圖7-14所示，數據包進入SDN交換機匹配對應的流表，如果是TCPSYN報文，則將該報文的目的MAC地址和IP地址修改為“清洗”服務器的MAC地址和IP地址，“清洗”服務器收到該報文后將記錄該報文的源IP地址和接收時間。由于網絡中存在很多主機，為此需要建立一張關于網絡中所有主機的記錄表，該表中的記錄是有時間限制的，在記錄被加入該表一定時間后將被刪除。這張記錄表定義了單位時間內對應主機的違規次數（閾值），也就是主機的“誠信度”。

比如，主機A在100毫秒內發送了6次（閾值）TCPSYN數據包，則可以認為是一次“違規”記錄。閾值、時間片長度等參數是可以動態調整和設置的。“誠信度”表的建立、管理以及相關參數的確立是一個復雜的過程，為了降低DDOS防御代碼實現的難度和便于理解，我們只是簡單地記錄主機發送連續TCPSYN報文的數量。一旦某個主機連續發送的TCPSYN數據報文達到某個閾值，則認為該主機可能發起TCPSYNFlood攻擊，該主機的TCPSYN數據包將被丟棄而不會被發往目標服務器；否則就認為是正常的TCPSYN報文，該報文被轉發給目標服務器。

圖7-14SYNFlood防御功能實現流程

7.2.2基于SDN的DDOS防御網絡配置

本節中網絡拓撲結構如圖7-15所示，主要設備有SDN控制器、安裝有OpenvSwitch2.5.0版本的SDN交換機一臺，PC2為攻擊計算機，用于發送TCPSYN數據包（使用hping3工具進行模擬發送SYN數據包），PC2的IP地址為02。PC1為被攻擊的目標服務器，IP地址為01。PC3為“清洗”服務器，用于檢測和過濾TCPSYNFlood攻擊的數據包，IP地址為03。

圖7-5基于SDN的DDOS防御網路拓撲圖

下面將展示通過OpenDaylight控制器的Web界面部署流表的過程，網絡配置或實戰過程如下：

（1）直接在交換機上添加流表，實現對PC2的TCPSYN數據包的轉發，如圖7－16所示。第一條流表的作用是將過濾好的數據包轉發給服務器PC1,第二條流表的作用是將PC2的數據包轉發給DDOS的清洗服務器PC3。TCP的flag標志位數值設置如下所示：

0:fin1:syn2:rst3:psh4:ack

5:urg6:ece7:cwr8:ns

圖7-16在交換機上增加流表

設置流表匹配類型為tcp_flags=0x2，即為TCPSYN數據包。圖7-17所示為交換機成功設置后顯示的流表信息。

圖7-17交換機上顯示已配置成功的流表

（2）在PC3上編譯并運行DDOS清洗服務器軟件。運行該軟件之前應確保網卡已被設置為混雜模式，具體代碼見7.2.3節。

（3）在PC2中使用hping3工具進行SYNFlood攻擊PC1（01），如圖7-18所示。

圖7-18模擬SYNFlood攻擊

命令中的具體參數解釋如下：

①-c10000：發送數據包的數量為10000個；

②-d120：發送到目標機器每個數據包的大小為120B；

③-S：只發送SYN數據包；

④-w64：TCP窗口大小為64；

⑤-p8080：攻擊的目的端口為8080；

⑥--faster：每秒發送100個數據包；

⑦01：為PC1的IP地址，即被攻擊目標服務器的IP地址。

7.2.3基于SDN的DDOS防御源碼分析

本節中的源碼是在7.1.3中源碼的基礎上改進的，函數ip_frame_recv代替了函數arp_request_recv，該函數一直不斷地接收源主機數據幀并打印接收到的數據幀的源IP地址、源MAC地址以及目的IP地址。注意，該程序只能接收到源主機發送的TCPSYN。接下來調用ip_ddos_proc函數處理接收到的TCPSYN數據報文，如果在短時間內（200毫秒）接收到的TCPSYN的數量大于6則函數返回，即該數據包不會被轉發給目標服務器，否則將該IP包轉發到目的服務器的端口eth0上。

函數ip_frame_recv代碼如下：

函數ip_ddos_proc代碼如下。其中，syncnt用于記錄源主機連續接收的TCPSYN報文的數量。當syncnt等于0時，獲得計時器開始時間，每接收到一個TCPSYN報文則syncnt加1，當計時時間超過200毫秒時，將syncnt置0。

7.2.4基于SDN的DDOS防御實驗數據分析

在PC3上用Wireshark工具捕獲的SYN數據包如圖7-19所示。可以看出，SYN=1,ACK=0，說明該數據包為SYN請求包。

圖7-19

TCPSYN數據包內容

從PC3的程序運行結果（如圖7-20所示）可以看出，運行結果沒有“sendto()OK!!!”，表明數據包沒有被轉發。

圖7-20防DDOS攻擊程序運行結果

流表攻擊前后的變化如圖7-21所示。由下發的兩條流表的數據包前后變化可以看出，PC1發出的SYNflood攻擊數據包進入到PC3上，PC3通過程序對數據包進行過濾，將非SYNFlood攻擊的數據包發送給交換機。

圖7-21流表變化

本實驗主要實現對SYNFlood攻擊的防護。首先由PC2模擬發送SYNFlood攻擊，攻擊對象為PC1服務器。當PC2發送數據包到OpenvSwitch交換機上時，交換機下發流表將數據包轉給PC3代理服務器，在PC3上運行C語言編寫的數據包過濾程序，將非SYNFlood攻擊的數據包發送給交換機，按照數據包的首部進行正常的數據轉發，從而有效地實現對SYNFlood攻擊的防護。

7.3基于OpenDaylightRESTAPI的應用與開發

本節主要是通過OpenDaylightRESTAPI在Java應用程序中進行流表操作，通過本節的實際應用將進一步體會SDN可編程的特點。

7.3.1OpenDaylightRESTAPI簡介

從根本上說，REST是一種軟件架構風格，REST可以有效地降低網絡應用開發的復雜性，同時提高系統的可伸縮性。OpenDaylightRESTAPI是使用OpenDaylight進行上層應用開發的一種極為簡單的開發方式，開發者可以直接對OpenDaylightRESTAPI進行遠程調用，而忽略OpenDaylight實現的底層細節，通過調用APl進行功能的創新與開發，使得OpenDaylight的開發更為簡單和快速。

OpenDaylightRESTCONF是最具代表性的一種OpenDaylightRESTAPI。RESTCONF是基于HTTP（HyperTextTransferProtocol）協議的，OpenDaylightRESTCONF提供RESTAPI可以操作基于Yang模型的數據和調用基于Yang模型的RPC（RemoteProcedureCallProtocol），一般將XML或者JSON作為HTTP的傳送載體。

JSON（JavaScriptObjectNotation）類似于XML，用于數據交換和傳輸，是一種輕量級的數據交換格式。JSON代碼簡潔明了，可讀性高，易于閱讀和編寫，同時也易于機器解析和生成。JSON的結構非常簡單，它只有對象和數組兩種結構，通過這兩種結構可以表示各種復雜的結構。

JSON中的對象表示為“{}”括起來的內容，通用的數據結構為{KEY1：VALUE1，KEY2：VALUE2，...}，采用鍵值對的形式。在面向對象的語言中，KEY為對象的屬性，VALUE為對應的屬性值。JSON中的數組表示為“［］”括起來的內容，例如，數據結構可以是［"flow"，"table"，"group"，...］，取值方式和所有語言一樣，使用索引獲取，字段值的類型可以是數字、字符串、數組、對象等。

常用的幾種HTTP請求是GET、POST、PUT和DELETE，其中，GET是向特定的資源發出請求，它是默認的HTTP請求方法。在日常使用中，通常使用GET來對指定資源請求數據，獲取相關的信息，在SDN中可以用于獲取統計信息或者具體的流表信息。POST也是HTTP請求中常用的一種，它是用來提交數據的，一般來說，使用POST提交的數據的位置在HTTP請求的正文里，其目的在于提交數據并用于服務器端的存儲，而不允許用戶過多地更改相應數據。PUT和POST的作用類似，PUT是對已有的數據進行修改，向指定的URI傳送更新資源，而POST是提交不存在的數據。顧名思義，DELETE就是通過HTTP請求刪除指定的URL上的資源，在SDN中可以進行刪除指定的流表等操作。

7.3.2使用Postman調用RESTCONF接口進行流表操作

Postman是Chrome瀏覽器中一個非常有名的插件，Postman一般用于調試網頁程序，它可以發送幾乎所有類型的HTTP請求，如POST、GET、DELECT、PUT等。開發人員調試一個網頁是否正常運行，并不是簡簡單單地調試網頁的HTML、CSS、腳本等信息是否正常運行，而是調試用戶的大部分數據能否通過HTTP請求來與服務器進行交互。Postman插件就充當著這種交互方式的“橋梁”，它可以利用Chrome插件的形式把各種模擬用戶HTTP請求的數據發送到服務器，以便開發人員能夠及時地作出正確的響應。

采用編程語言（例如Java）調用RESTAPI最難判斷的是發送給控制器的數據及格式（JSON格式）書寫是否正確，通常可以先用某些工具將這些數據調試正確，然后再拷貝到程序中使用，這樣可以更高效地開發網絡應用程序。為此我們先觀察一下如何在Postman中下發JSON格式的流表數據，這種流表操作的方式實際上是對OpenDaylightRESTAPI的應用，與其他方式的流表管理相比較，Postman管理流表具有簡單、方便等特點。

接下來在控制器端使用Chrome瀏覽器的Postman插件進行相關配置（URL填寫、流表的JSON格式書寫、RESTCONF接口認證等），進行獲取并查看流表、刪除流表、下發流表等操作，具體操作過程如下。由于Postman插件支持多種格式，如JSON、XML、HTML等，下面以JSON為例進行流表操作。

1.準備工作

（1）在Chrome瀏覽器安裝Postman插件。

（2）啟動控制器上的OpenDaylight，并安裝好需要的插件（如odl－restconfig－all插件）。

（3）啟動OpenvSwitch交換機，并將交換機連接到控制器上，使得OpenDaylight的Web管理界面能夠看到這臺OpenvSwitch交換機，并記住交換機的DPID。每臺交換機的DPID可能不同，本節中交換機的DPID為OpenFlow:619144302644。

2.對Postman進行配置

（1）由于調用服務器端的REST接口需要授權，因此要在Postman設置授權，如圖7-22所示，在Authorization中的Type選擇BasicAuth，在Username和Password中填入admin。

（2）指定Postman的數據交換的內容類型，這里使用的是JSON。在Headers中的Content－Type填入application/json，如圖7-23所示。

圖7-22

Postman設置授權圖7-23

Postman設置內容類型

3.GET請求顯示流表

（1）確定要查看的流表（使用YangUI工具下發完成一條流表），確保通過查看命令可以看到如圖7-24中所下發的流表。

圖7-24交換機中的流表

（2）在Postman中HTTP請求選擇GET，其中URL地址為

http://:8181/restconf/config/opendaylightinventory:nodes/node/openflow:619144302644/table/0

點擊Send獲取流表內容，流表內容為JSON格式（如圖7-25所示）。

圖7-25

Postman獲取流表

4.DELETE刪除流表