一、項目簡介

目的：設有一臺PC機(Host1)，一臺Web服務器(Host2)提供簡單的靜態(tài)網(wǎng)頁訪問服務。通過RYU控制網(wǎng)絡流，限制PC訪問服務器的頻率，如兩次訪問的間隔不能低于5秒。應用場景：

①為 付費用戶 和 免費用戶 提供差異化服務

②小型站點、個人站點、未做優(yōu)化站點的負載緩解

③……在詳細了解TCP三次握手、四次揮手、RST強制重置，以及HTTP包交互全程的基礎上，本項目達成了以下特色：限制訪問時，返回給PC友好的WEB頁面提示，而不是僅僅通過流表把包丟棄，以及由此導致的PC用戶瀏覽器持續(xù)等待、多次TCP重傳、多次HTTP嘗試。

二、關鍵技術分析

本項目中，由于TCP重傳機制的特殊性，控制器不對握手和揮手等TCP控制交互階段進行控制，只對HTTP報文進行控制。控制器偽裝了服務器的角色，好似第三方劫持會話。對于80目的端口的TCP控制交互報文，控制器通過packet-out讓其順利轉發(fā)。當正常訪問時，控制器通過packet-out讓HTTP請求順利轉發(fā)，同時下一條從服務器到PC的反向流表;當限制訪問時，控制器通過：

①提取計算Seq、提取計算Ack、設置bits協(xié)議標志位、設置window_size來構造一個TCP報文;

②同時依照HTTP協(xié)議構造一個web頁面數(shù)據(jù)包(訪問限制提示頁面)

③構造Ip包

④構造Ethernet幀然后按照HTTP -> TCP -> IP -> Ethernet 的順序?qū)訉臃庋b，將其發(fā)回給PC，PC即可顯示限制訪問的提示頁面。一般情況下還不算完，此時雖然PC瀏覽器退出了等待狀態(tài)，但是PC、服務器雙方的TCP連接仍然保持，仍在占用資源。由此，我通過巧妙構造TCP協(xié)議字段和HTTP協(xié)議字段，利用TCP揮手階段的RST機制，讓PC端向服務器主動發(fā)起RST報文，隨后PC端和服務器會各自強制斷開連接。到此，一次優(yōu)雅的訪問限制圓滿結束，PC、服務器的資源都不被持續(xù)占用，用戶也不用茫然地等待，同時能得到友好的提示!

具體細節(jié)，詳見下方的各項解析，以及下文的實驗演示中的截圖。(可放大觀看)(1)TCP的有趣細節(jié)

TCP這個孩子非常執(zhí)著，無論是握手階段、數(shù)據(jù)通信階段，還是揮手階段，只要沒有收到ACK，就會以“翻番”的時間間隔去重發(fā)數(shù)據(jù)包，1、2、4、8、16、32秒……。開發(fā)過程中，我觀察到如果單純以丟包作為限制手段，TCP會持續(xù)握手握上五分鐘之久!并且會持續(xù)下去。平日里我們看到的TCP報告連接失敗，可能是對方積極地使用RST給了我們失敗的指示。因此，如果單純地丟包，會導致PC瀏覽器持續(xù)處于等待網(wǎng)頁的狀態(tài)，即使我們設置限制間隔為一分鐘，但其實一分鐘過后自動打開的網(wǎng)頁，是屬于“同一次”訪問。RST協(xié)議字段在我這個項目中，可謂是一個神器，它是一個TCP協(xié)議字段，會讓通信雙方各自強制關閉連接。RST常出現(xiàn)在連接本身出現(xiàn)嚴重差錯、通信對端端口不可達、在已關閉的socket上收到數(shù)據(jù)等情況。在這里，我們利用了“連接本身出現(xiàn)嚴重差錯”這一條：在HTTP響應數(shù)據(jù)包中，我們給TCP設置一個錯誤的Ack和一個正確的Seq，使得PC發(fā)起HTTP Request的超時重傳，此時RYU會再次響應帶有錯誤Ack卻有正確Seq的響應，這就導致了PC端發(fā)現(xiàn)連接出現(xiàn)嚴重差錯，中斷連接!經(jīng)我分析，由于RYU第一次的響應是正常的通信過程，所以PC重傳的HTTP Request中，TCP Ack已經(jīng)累積遞增，然后RYU的第二次響應中，有正確的Seq，說明已經(jīng)是收到了重傳的HTTP Request，按理說它的TCP Ack應該累積遞增，但是卻沒有，而仍然是我們設定的錯誤Ack。

這就產(chǎn)生了矛盾!因此PC端就主動發(fā)起了RST連接中斷，特插圖如下：

 

 

(2)最精簡的HTTP響應數(shù)據(jù)

之前我在C++下開發(fā)過一些Socket通信程序，根據(jù)我的積累，僅包含必要信息的最精簡HTTP需要有如下協(xié)議信息，各信息之間用“\r\n”分隔，協(xié)議頭與數(shù)據(jù)之間用 \r\n\r\n分隔：①協(xié)議版本、響應狀態(tài)碼：HTTP/1.1 200 OK

②數(shù)據(jù)段長度：Content-Length: 257

③數(shù)據(jù)內(nèi)容類型、編碼：Content-Type: text/html; charset=utf-8

三、項目演示

(1)組網(wǎng)

Mininet：

  

 RYU：

(2)軟件準備

【 Mininet 】角色：h1 客戶端(wget、Firefox)、h2服務器(Python SimpleHTTPServer)

 

 

 

【W(wǎng)ireshark】啟動兩個，分別監(jiān)控：s1-eth1(h1)、s1-eth2(h2)，并且僅顯示TCP包

 

 

#p#

(3)訪問過程

由于Firefox在發(fā)起HTTP請求時會同時建立兩個TCP連接，所以我們先以wget來演示一次HTTP請求的最典型的收發(fā)包情況，再以Firefox來直觀演示W(wǎng)eb頁面效果。1. wget 正常訪問

 

2. wget 限制訪問

 

3. Firefox 正常訪問

 

4. Firefox 限制訪問

 

5. Firefox 正常訪問、限制訪問 Web 頁面

 

#p#

四、核心代碼展示

(1)代碼結構

 

 

(2)構造HTTP限制訪問Web包

HTTP -> TCP -> IP -> Ethernet

(3)控制器偽裝發(fā)包

 

(4)限制間隔計時

19行：Self.oldT 在__init__中初始化86行：檢查是否需要限制訪問，此處設定訪問間隔為5秒

【同時對網(wǎng)絡延遲造成的正常TCP重傳，設定0.3秒的容許】205行：刷新最后一次訪問成功的時間time.time() 用于獲取系統(tǒng)當前時間

五、項目心得

這個項目的開發(fā)真是歷經(jīng)坎坷，我也在其中悟到了很多課堂上沒有涉及到的知識。通過多網(wǎng)口同時抓包，然后加以細致的分析，從TCP的三次握手、四次揮手，到TCP的Seq、Ack在傳信令、數(shù)據(jù)時的累加機制，再到TCP的bits協(xié)議標志位，以及RST 這個連接守護者。一星一點地細看發(fā)包流程，然后在腦海中翻閱之前積累的TCP反饋重傳、累積確認、滑動窗口等機制，對流程進行細致的研究。雖然過程中遇到了一些難以理解的收發(fā)流程，但是我始終相信TCP這個東西在互聯(lián)網(wǎng)上跑了這么多年，不會說在通信交互的機制上有什么BUG，一定是流程中出了什么樣的意外情況導致了異常的收發(fā)，甚至連接的RST中斷。 細粒度地分析實際通信場景、bits協(xié)議標志位、Seq、Ack，一定能找到問題癥結所在!通過這個小項目，我算是對TCP的理解更加細致、深入、實際了!對于上方PC端主動發(fā)起RST的原因，只是我利用已有的知識積累，進行分析和一點點猜想的結果，還希望老師、學長學姐、同學們能給予我一些指導，非常感謝!這學期的SDN課程行至尾聲，還真的是意猶未盡，在北郵能聽到這么有前瞻性的課程，真是一大幸事，我想，我們也只有始終站在潮流前端，才能保持優(yōu)秀，引領未來!