windump -d

可以列出當前的裝置列表。

我在windows7 下有時候會出現只能列出一個的問題，這時候需要把不可見的裝置Disable後再次Enable

然後再次 windump -d 就可以看到了。

windump -i   x      x是第幾個裝置，注意是 1Base ， 不是0Base

windump host 10.9.16.88 and(10.9.16.254)  可以監聽 10.9.16.88 和 10.9.16.254 之間的對話

其他連結：

重讀TCP

TCP 的資料流

       TCP的資料流大致可以分為兩類，互動資料流與成塊的資料流。互動資料流就是傳送控制命令的資料流，比如relogin

，telnet，ftp命令等等；成塊資料流是用來發送資料的包，網路上大部分的TCP包都是這種包。

很明顯，TCP在傳輸這兩種型別的包時的效率是不一樣的，因此為了提高TCP的傳輸效率，應該對這兩種型別的包採用不同的演算法。

總之，TCP的傳輸原則是儘量減少小分組傳輸的數量。

TCP的互動式資料流

Ø經受時延的確認技術

TCP的互動式資料流通常使用“經過時延的確認”技術。通常Server在接收到從Client傳送過來的資料時，並不馬上傳送ACK，而是等一小段時間，看看本機是否有資料要反饋給Client，如果有，就將資料包含在此ACK包中，以前傳送給Client。一般情況下這個時延為200ms。需要注意的時這個200ms

的定時器時相對於核心的時鐘滴答的，也就是jeffs的。加入一個數據分組到達後，此定時器已經pass了100ms，那麼再過100ms ACK才會被髮送，如果在這100ms內有資料要反饋，則在100ms後ACK會和資料一起傳送。

ØNagle演算法分析。

Nagle演算法主要用來預防小分組的產生。在廣域網上，大量TCP小分組極有可能造成網路的擁塞。

       Nagle時針對每一個TCP連線的。它要求一個TCP連線上最多隻能有一個未被確認的小分組。在改分組的確認到達之前不能傳送其他小分組。TCP會蒐集這些小的分組，然後在之前小分組的確認到達後將剛才蒐集的小分組合併發送出去。

有時候我們必須要關閉Nagle演算法，特別是在一些對時延要求較高的互動式操作環境中，所有的小分組必須儘快傳送出去。

我們可以通過程式設計取消Nagle演算法，利用TCP_NODELAY選項來關閉Nagle演算法。

TCP成塊資料流

和TCP成塊資料流相關的東西有很多，比如流量控制，緊急資料傳輸，資料視窗大小調整等等。

Ø正常資料流

TCP通常不會對每個到達的資料分段進行確認操作，通常一個ACK報文可以確認多個成塊資料段報文，通常情況下是兩個成塊資料報文段需要一個ACK報文確認。通常是由下面的原有造成的：當收到一個報文後，此TCP連線被標識未一個未完成的時延確認，當再次收到一個數據報文後，此連線有兩個未確認的報文段，TCP馬上傳送一個ACK，當第三個資料報文到達後，第四個報文到達前，通常此TCP連線已經經過了200ms延時，因此一個ACK被髮送，這樣的迴圈周而復始，從而出現了一個ACK確認兩個資料報文的情況。當然，ACK的產生很大程度上和其接收資料報文段的時間緊密相關，也就是和Client段傳送資料的頻率相關，和網路擁塞程度相關，和Client與Server兩端的處理能力相關，總是是一個多因素決定的結果。

ØTCP的滑動視窗協議

TCP使用滑動視窗協議來進行流量控制。特別需要注意的是，滑動視窗是一個抽象的概念，它是針對每一個TCP連線的，而且是有方向的，一個TCP連線應該有兩個滑動視窗，每個資料傳輸方向上有一個，而不是針對連線的每一端的。

視窗左邊沿向右邊滑動叫做視窗合攏，表示傳送方傳送了資料或者接收到了確認；視窗右邊沿向右邊滑動叫做視窗的張開，表示資料已經被使用者空間程序接收並且釋放了快取；視窗左邊沿向左移動則表明此ACK是重複ACK，應該丟棄；視窗右邊沿向左移動叫做視窗收縮，一般不會有人這樣做。

當左邊沿和右邊沿重合的時候表明視窗大小是0，此時傳送方不應該在傳送資料了，因為接收方的接收緩衝區已滿，使用者程序還沒以接收。當用戶程序接收完成後，接收方應該傳送一個ACK，表明此時的接收視窗已經恢復，此ACK的序號同前一個win為0的ACK相同。

同樣，在實現中，傳送方不必傳送一個全視窗的資料，但是它當然可以這樣做。ACK總是將視窗向右邊滑動，視窗的大小可以減小，接收方在傳送ACK之前不必等待視窗被填滿（即變為0），很多實現是收到兩個資料報文段後立刻傳送ACK。

ØTCP視窗大小的調整

TCP視窗的大小通常由接收端來確認，也就是在TCP建立連線的第二個SYN+ACK報文的Win欄位來確認。

當然，程式可以隨時改變這個視窗（快取）的大小。預設的視窗大小是4096位元組，但是對於檔案傳輸來說這並不是一個理想的數字，如果程式的主要目的是傳輸檔案，那麼最好將這個快取設定到最大，但是這樣可能會造成傳送端連續傳送多個數據報文段後，接收方才反饋一個ACK的情況，當然，這也沒有什麼不可以的，只要不超時，就不算錯。

ØTCP的PUSH包

PUSH是TCP報頭中的一個標誌位，傳送方在傳送資料的時候可以設定這個標誌位。該標誌通知接收方將接收到的資料全部提交給接收程序。這裡所說的資料包括與此PUSH包一起傳輸的資料以及之前就為該程序傳輸過來的資料。

當Server端收到這些資料後，它需要立刻將這些資料提交給應用層程序，而不再等待是否還有額外的資料到達。

那麼應該合適設定PUSH標誌呢？實際上現在的TCP協議棧基本上都可以自行處理這個問題，而不是交給應用層處理。如果待發送的資料會清空傳送快取，那麼棧就會自動為此包設定PUSH標誌，源於BSD的棧一般都會這麼做，而且，BSD TCP STACK也從來不會將收到的資料推遲提交給應用程式，因此，在BSD TCP STACK中，PUSH位是被忽略的，因為根本就沒有用。

ØTCP的慢啟動（擁塞視窗）

TCP在區域網環境中的效率是很高的，但是到了廣域網的環境中情況就不同了，在傳送方和接收方之間可能存在多個Router以及一些速率比較慢的鏈路，而且一些中繼路由器必須快取分組，還可能分片，所以在廣域網的環境中，TCP的效率可能出現問題。

為了解決這個問題，現在的TCP棧都支援“慢啟動”演算法，即擁塞視窗控制演算法。該演算法通過觀察到新分組進入網路的速率與另一端返回ACK的速率相同而工作。其實，擁塞視窗是傳送方使用的一種流量控制演算法。

慢啟動為TCP

相關推薦