TCP/UDP 詳解 （可靠傳輸、流量控制、連接管理等核心章節的詳解）
如果有需要PDF文檔的，可到下載專欄進行下載；
一、 傳輸層概述
1、傳輸層存在的必要性
由於網絡層的分組傳輸是不可靠的，無法瞭解數據到達終點的時間，無法瞭解數據未達終點的狀態。因此有必要增強網絡層提供服務的服務質量。
2、引入傳輸層的原因
面向連接的傳輸服務與面向連接的網絡服務類似，都分爲建立連接、數據傳輸、釋放連接三個階段；編址、尋址、流控制也是類似的。無連接的傳輸服務與無連接的網絡服務也非常類似。一個很顯然的問題：既然傳輸層的服務與網絡層的服務如此相似，那麼爲什麼我們還要兩個獨立的層呢？
原因在於：傳輸層的代碼完全運行在用戶的機器上，但是網絡層主要運行在由承運商控制的路由器上。試想以下幾種情況？
① 網絡層提供的服務不夠用；
② 頻繁的丟失分組；
③ 路由器時常崩潰。
用戶在網絡層上並沒有真正的控制權，所以他們不可能用最好的路由器或者在數據鏈路層上用更好的錯誤處理機制來解決服務太差的問題。唯一的可能是在網絡層之上的另一層中提高服務質量。這就是傳輸層存在的必要性。
傳輸層的任務：在源機器和目標機器之間提供可靠的、性價比合理的數據傳輸服務，並且與當前使用的物理網絡完全獨立。
3、傳輸層的功能
數據傳送，不關心數據含義，進程間通信。
彌補高層（上3層）要求與網絡層（基於下3層）數據傳送服務質量間的差異（差錯率、差錯恢復能力、吞吐率、延時、費用等），對高層屏蔽網絡層的服務的差異，提供穩定和一致的界面。
4、傳輸層協議與網絡層協議的主要區別
網絡層（IP層）提供點到點的連接即提供主機之間的邏輯通信，傳輸層提供端到端的連接——提供進程之間的邏輯通信。
5、傳輸層的用途
傳輸層將數據分段，並進行必要的控制，以便將這些片段重組成各種通信流。在此過程中，傳輸層主要負責：
① 跟蹤源主機和目的主機上應用程序間的每次通信；
② 將數據分段，並管理每個片段；
③ 將分段數據重組爲應用程序數據流；
④ 標識不同的應用程序。
6、端口的概念
運行在計算機中的進程是用進程標識符來標誌的。運行在應用層的各種應用進程卻不應當讓計算機操作系統指派它的進程標識符。這是因爲在因特網上使用的計算機的操作系統種類很多，而不同的操作系統又使用不同格式的進程標識符。爲了使運行不同操作系統的計算機的應用進程能夠互相通信，就必須用統一的方法對TCP/IP體系的應用進程進行標誌。
解決這個問題的方法就是在運輸層使用協議端口號(protocol port number)，或通常簡稱爲端口(port)；當傳輸層從網絡層收到數據後，根據傳輸層協議中的端口號將數據交付給相應的應用進程。
雖然通信的終點是應用進程，但我們可以把端口想象是通信的終點，因爲我們只要把要傳送的報文交到目的主機的某一個合適的目的端口，剩下的工作（即最後交付目的進程）就由 TCP來完成。
在通常情況下，端口好被劃分爲三段：
|
端口範圍 |
端口類別 |
|
0到1023 |
公認的端口號，一般爲服務端使用 |
|
1024到49151 |
已註冊的端口號 |
|
41952到65535 |
動態或者私用端口號，一般爲客戶端使用 |
二、 DUP的基本原理
1、UDP概述
UDP 是一個簡單的面向數據報的傳輸層協議（用戶數據報協議），UDP在傳輸數居前不需要先建立連接，遠程主機在收到數據後也無需返回任何確認信息。 基於UDP進程的每個輸出操作都產生一個UDP數據報，並封裝成一份待發送的IP數據報。如下圖(UDP的封裝)
在網絡層協議的數據服務上加上數據包的分用、複用以及差錯檢測即爲用戶數據報協議（UDP協議），主要有以下特徵：
（1） 無連接，；
（2） 盡最大阻力交付，不需要維持複雜的鏈路信息；
（3） 面向報文，不對應用層的數據進行合併和拆分；
（4） 沒有擁塞控制，即發送端不會考慮網絡傳輸的情況；
（5） 支持n：n的交付通信（n >= 1）;
（6） 首部開銷小，有利用提高數據傳輸效率。
2、UDP的首部格式
（1） 源端口號，表示本地的應用層進程；
（2） 目的端口，報文交付目的進程；
（3） 用戶數據報長度，最小值爲8個字節（僅有首部）；
（4） 檢驗和，用於檢驗UDP數據報在傳輸的過程中是否有錯。
3、UDP客戶端/服務器程序的交互過程
三、 TCP的基本原理
1、TCP概述
TCP是提供的面向連接的服務，即在傳送數據之前要先建立連接，數據傳輸結束後要釋放連接。TCP與UDP不同，不提供廣播和多播服務，由於TCP要提供可靠的、面向連接的運輸服務，故不可避免地增加了許多的開銷，如確認機制，流量控制，計時功能，連接管理擁塞控制等等，由於傳輸的複雜性，不僅增加了首部開銷，而且佔用了相當部分的處理機資源。
TCP的主要特點：
（1） 面向連接的傳輸層協議，即在傳送數據之前要先建立連接，數據傳輸結束後要釋放連接，也稱建立鏈路和釋放鏈路；
（2） 每條鏈路是一對一，即只能點對點的通信；
（3） 提供可靠交付，通信雙方需要對通信的數據進行無差錯驗證，確認，以保證交互數據不丟失、不重複並有序到達應用層；
（4） 提供全雙工通信，通信雙方既可以是信息的接收者也可以是信息的發送者，並且兩段都有接受緩存和發送緩存，在發送時，應用程序將數據交付tcp後無需關心數據的發送，在接收時，tcp把接收到的數據進行確認後放入緩存，應用程序可在合適的時候進行讀取，從而可以實現異步通信，提高應用程序的工作效率；
（5） 面向字節流，TCP把應用程序下傳的數據僅僅視爲一連串的無結構字節流，在傳輸的過程中只有字節流數量的概念，不會關心字節流的含義。也不保證接收方應用程序所收到的數據塊和發送端應用程序所發出的數據塊具有對於大小關係。但接收方的應用程序收到的字節流必須和發送端的應用程序發出的字節流一樣，故接收方的應用程序必須有能力識別接收到的字節流，把tcp的字節流還原成有意義的應用層數據。
TCP 的所有數據傳輸都是基於鏈路，每一條tcp鏈路都有兩個端點，也稱套接字或者插口。在RFC793中定義，應用程序的端口 + ip地址便構成了套接字。
套接字 Socket = （IP地址 ：端口號）
故TCP連接也被兩個端點唯一確定：
TCP連接：：= { Socket1, Socket2 } = { (IP_1 : Port_1), (IP_1 : Port_2)}
2、TCP報文段首部格式分析
雖然TCP是面向字節流的，但是TCP的傳輸單元式數據報。一個報文段分爲IP協議首部和IP數據兩部分，數據部分即應用層的數據，而TCP的全部功能都體現在它首部的各個字段的作用。故tcp的首部是tcp工作原理的核心所在。TCP的報文段首部的前20個字節是固定的（如下圖），後面有4N個字節是根據需要而增加的選項（N的整數倍），因此首部的最小長度爲20個字節。
（1）源端口和目的端口各佔 2 個字節，分別寫入源端口號和目的端口號。和前面所示的 UDP 的分用相似，TCP 的分用功能也是通過端口實現的。
（2）序號佔 4 字節。序號範圍是[0,232 - 1]，共 232（即 4 294 967 296）個序號。序號增加到232- 1 後，下一個序號就又回到0。也就是說，序號使用 mod 232 運算。TCP 是面向字節流的。在一個 TCP 連接中傳送的字節流中的每一個字節都按順序編號。整個要傳送的字節流的起始序號必須在連接建立時設置。首部中的序號字段值則指的是本報文段所發送的數據的第一個字節的序號。例如，一報文段的序號字段值是 301，而攜帶的數據共有 100 字節。這就表明：本報文段的數據的第一個字節的序號是 301，最後一個字節的序號是 400。顯然，下一個報文段（如果還有的話）的數據序號應當從 401 開始，即下一個報文段的序號字段值應爲 401。這個字段的名稱也叫做“報文段序號”。
（3）確認號 佔 4 字節，是期望收到對方下一個報文段的第一個數據字節的序號。例如，B 正確收到了 A 發送過來的一個報文段，其序號字段值爲 501，而數據長度是 200 字節（序號 501~700），這表明 B 正確收到了 A 發送的序號 700 爲止的數據。因此，B 期望收到 A 的下一個數據序號是 701，於是 B 在發送給 A 的確認報文段中把確認號置爲 701。請注意，現在的確認號不是 501，也不是 700，而是 701。
總之，應當記住：
若確認號 = N ，則表明：到序號 N - 1 爲止的所有數據都已正確收到。
由於序號字段有 32 位長，可對 4 GB（即 4 千兆字節）的數據進行編號。在一般情況下可保證序號重複使用時，舊序號的數據早已通過網絡到達終點了。
（5）首部長度佔 4 位，這個字段實際上是指出 TCP 報文段的首部長度。由於首部中還有長度不確定的選項字段，因此數據偏移字段是必要的。但請注意，“數據偏移”的單位是 32 位字（即以 4 字節長的字爲計算單位）。由於 4 位二進制數能夠表示的最大十進制數字是 15，因此數據偏移的最大值是 60 字節，這也是 TCP 首部的最大長度（即選項長度不能超過 40 字節）。
（6）保留佔 6 位，保留爲今後使用，但目前應置爲 0。
下面有 6 個控制位說明本報文段的性質，它們的意義見下面的（7）~（12）。
（7）緊急 URG(URGent) 當 URG = 1 時，表明緊急指針字段有效。它告訴系統此報文段中有緊急數據，應儘快傳送（相當於高優先級的數據），而不要按原來的排隊順序來傳送。例如，已經發送了很長的一個程序要在遠地的主機上運行。但後來發現了一些問題，需要取消該程序的運行。因此用戶從鍵盤發出中斷命令（Control + C ）。如果不使用緊急數據，那麼這兩個字符將存儲在接收 TCP 的緩存末尾。只有在所有的數據被處理完畢後這兩個字符才被交付到接收方的應用進程。這樣就浪費了許多時間。
當 URG 置 1 時，發送應用進程就告訴發送方的 TCP 有緊急數據要傳送。於是發送方 TCP 就把緊急數據插入到本報文段數據的最前面，而在緊急數據後面的數據仍是普通數據。這時要與首部中緊急指針(Urgent Pointer)字段配合使用。
（8）確認 ACK（ACKKnowlegment) 僅當 ACK = 1 時確認號字段纔有效。當 ACK = 0 時，確認號無效。TCP 規定，在連接建立後所有傳送的報文段都必須把 ACK 置 1。
（9）推送 PSH 當兩個應用進程進行交互式的通信時，有時在一端的應用進程希望在鍵入一個命令後立即就能夠收到對方的響應。在這種情況下，TCP 就可以使用推送(push)操作。這時，發送方 TCP 把 PSH 置 1，並立即創建一個報文段發送出去。接收方 TCP 收到 PSH = 1 的報文段，就儘快地（即“推送”向前）交付給接收應用進程，而不再等到整個緩存都填滿了後再向上交付。
（10）復位 RST(ReSeT) 當 RST = 1 時，表明 TCP 連接中出現嚴重的差錯（如由於主機崩潰或其他原因），必須釋放連接，然後再重新建立運輸連接。RST 置 1 還用來拒絕一個非法的報文段或拒絕打開一個連接。RST 也可稱爲重建或重置位。
（11）同步 SYN(SYNchronization) 在連接建立時用來同步序號。當 SYN = 1 而 ACK = 0 時，表明這是一個連接請求報文段。對方若同意建立連接，則應在響應的報文段中使 SYN = 1 和 ACK = 1。因此，SYN 置爲 1 就表示這是一個連接請求或連接接受報文。
（12）終止 FIN(final，意思是“完”、“終”） 用來釋放一個連接。當 FIN = 1 時，表明此報文段的發送方的數據已發送完畢，並要求釋放運輸連接。
（13）窗口佔 2 字節。窗口值是[0,216- 1]之間的整數。窗口指的是發送本報文段的一方的接收窗口（而不是自己的發送窗口）。窗口值告訴對方：從本報文首部中的確認號算起，接收方目前允許對方發送的數據量。這所以要有這個限制，是因爲接收方的數據緩存空間是有限的。總之，窗口值作爲接收方讓發送方設置其發送窗口的依據。
例如，設確認號是 701，窗口字段是 1000。這就表明，從 701 號算起，發送此報文段的一方還有接收 1000 個字節數據（字節序號是 701~1700）的接收緩存空間。
總之，應當記住：
窗口字段明確指出了現在允許對方發送的數據量。窗口值是經常在動態變化着。
（14）檢驗和佔 2 字節。檢驗和字段檢驗的範圍包括首部和數據這兩部分。和 UDP 用戶數據報一樣，在計算檢驗和時，要在 TCP 報文段的前面加上 12 字節的僞首部。僞首部的格式與 UDP 用戶數據報的僞首部一樣。但應把僞首部第 4 個字節中的 17 改爲 6 後，仍要加上這個僞首部來計算檢驗和。若使用IPv6，則相應的僞首部也要改變。
（15）緊急指針佔 2 字節。緊急指針僅在 URG = 1 時纔有意義，它指出本報文段中的緊急數據的字節數（緊急數據結束後就是普通數據）。因此緊急指針指出了緊急數據的末尾在報文段中的位置。當所有的緊急數據都處理完時，TCP 就告訴應用程序恢復到正常的操作。值得注意的是，即使窗口爲零時也可發送緊急數據。
（16）選項長度可變，最長可達 40 字節。當沒有使用選項時，TCP 首部長度是 20 字節。
TCP 最初只規定了一種選項，即最大報文段長度 MSS（Maximum Segment Size）[RFC 879]。請注意 MSS 這個名詞的含義。MSS 是每一個 TCP 報文段中的數據字段的最大長度。數據字段加上 TCP 首部纔等於整個TCP 報文段。所以 MSS 並不是整個TCP 報文段的最大長度，而是“TCP 報文段長度減去 TCP首部長度。”
爲什麼要規定一個最大報文長度 MSS 呢？這並不是考慮接收方的接收緩存可能放不下 TCP 報文段中的數據。實際上，MSS 與接收窗口值沒有關係。我們知道，TCP 報文段的數據部分，至少要加上 40 字節的首部（TCP 首部 20 字節和 IP 首部 20 字節），這裏都還沒有考慮首部中的選項部分），才能組裝成一個 IP 數據報。若選擇較小的 MSS 長度，網絡的利用率就降低。設想在極端的情況下，當 TCP 報文段只含有 1 字節的數據時，在 IP 層傳輸時數據報的開銷至少有 40 字節（包括 TCP 報文段的首部和 IP 數據報的首部）。這樣，對網絡的利用率就不會超過 1/41。到了數據鏈路層還要加上一些開銷。但反過來，若 TCP 報文段非常長，那麼在 IP 層傳輸時就有可能要分解成多個短數據片。在終點要把收到的各個數據報片裝配成原來的 TCP 報文段。當傳輸出錯時還要進行重傳。這些也都會使開銷增大。
因此，MSS 應儘可能大些，只要在 IP 層傳輸時不需要再分片就行。由於 IP 數據報所經歷的路徑是動態變化的，因此在這條路徑上確定的不需要再分片的 MSS，如果改走另一條路徑就可能需要進行分片。因此最佳的 MSS 是很難確定的。在連接建立的過程中，雙方都把自己能夠支持的 MSS 寫入這一字段，以後就按照這個數值傳送數據，兩個傳送方向可以有不同的 MSS 值。若主機未填寫這一項，則 MSS 默認值是 536 字節長。因此，所有在因特網上的主機都應能接受的報文長度是 536 +20（固定首部長度） = 556字節。
隨着因特網的發展，又陸續增加了幾個選項。如窗口擴大選項、時間戳選項等。以後又增加了有關選擇確認(SACK)選項。
窗口擴大選項是爲了擴大窗口。我們知道，TCP 首部中窗口字段長度是 16 位，因此最大的窗口大小爲 64 字節。雖然這對早期的網絡是足夠的，但對於包含衛星信道的網絡，傳播時延和帶寬都很大，要獲得高吞吐率需要更大的窗口大小。
窗口擴大選項佔 3 字節，其中有一個字節表示移位值 S。新的窗口值等於 TCP 首部中的窗口位數從 16 增大到（16 + S），這相當於把窗口值向左移動 S 位後獲得實際的窗口大小。移位值允許使用的最大值是 14，相當於窗口最大值增大到 2(16 + 14） - 1 = 230- 1。
窗口擴大選項可以在雙方初始建立 TCP 連接時進行協商。如果連接的某一端實現了窗口擴大，當它不再需要擴大其窗口時，可發送 S = 0 的選項，使窗口大小回到 16。
時間戳選項佔 10 字節，其中最主要的字段時間戳字段（4 字節）和時間戳回送回答字段（4 字節）。時間戳選項有以下兩個功能：
第一，用來計算往返時間 RTT。發送方在發送報文段時把當前時鐘的時間放入時間戳字段，接收方在確認該報文段時把時間戳字段值複製到時間戳回送回答字段。因此，發送方在收到確認報文後，可以準確地計算出 RTT 來。
第二，用於處理 TCP 序號超過 232 的情況，這又稱爲防止序號繞回 PAWS (Protect Against Wrapped Sequence numbers)。我們知道，序號只有 32 位，而每增加 2個字號就會重複使用原來用過的序號。當使用高速網絡時，在一次 TCP 連接的數據傳送中序號很可能會被重複使用。例如，若用 1 Gb/s 的速率發送報文段，則不到 35 秒鐘數據字節的序號就會重複。爲了使接收方能夠把新的報文段和遲到很久的報文段區分開，可以在報文段中加上這種時間戳。
3、TCP連接管理
TCP 是面向連接的協議，所有的報文傳輸都是基於連接，故傳輸連接的建立和釋放也爲每一次基於TCP通信中不可缺少的過程。傳輸連接可分爲三個過程：建立鏈接、數據傳輸、釋放鏈接。鏈接管理的主要功能就是使運輸的建立和釋放都能正常進行，以保證數據的傳輸。
建立鏈接：
建立鏈接的主要任務:
(1) 使通信雙方確知對方的存在；
(2) 協商傳輸過程中所需要的參數（例如：窗口、時間戳等等）；
(3) 分配傳輸實體資源（如緩存大小、連接表中的項目）。
在TCP中，建立連接就是採用經典的3次握手。爲了建立連接，其中一方，如服務器，通過執行LISTEN和ACCEPT原語（可以指定源端機也可以不指定）被動地等待一個到達的連接請求。
另一方，如客戶方，執行CONNECT原語，同時要指明它想連接到的IP地址和端口號，設置它能夠接受的 TCP數據段的最大值，以及一些可選的用戶數據（如口令）。CONNECT原語發送一個SYN=1，ACK=0的數據段到目的端，並等待對方響應。
數據段到達目的端後，那裏的TCP實體將查看是否有進程在偵聽目的端口字段指定的端口。如果沒有，它將發送一個RST=l的應答，拒絕建立該連接。
如果某個進程正在對該端口進行偵聽，於是便將到達的TCP數據段交給該進程。它可以接受或拒絕建立連接。如果接受，便發回一個確認數據段。交互過程如下圖：
建立TCP鏈接的過程相當於一個電話系統。Socket函數等同於有電話可用，bind函數是將自己的電話號碼告訴別人，listen函數是打開電話振鈴，這樣當有一個外來呼叫便可聽到。connect函數要求知道對方的電話號碼並撥打它，accept函數發生在被呼叫的人應答電話之時，由accept返回客戶標識（即爲客戶的ip和端口號）類似於讓電話機的呼叫者ID功能部件顯示呼叫者的電話號碼。然而兩者的不同之處在於accept只是在鏈接建立之後返回客戶標識，而呼叫者ID功能部件卻在我們選擇應答或者不應答之前顯示呼叫者電話號碼。
如果兩個主機同時想在相同的兩個套接字之間建立一個連接，事件的發生順序如下圖所示。這些事件的最終結果是隻有一個連接建立起來，而不是兩個，因爲連接是由其端點所標識的。如果首先建立的連接由（x，y）標識，第二個連接也是如此，那麼就生成一個表記錄，即（x，y）。
三路握手的主要原因，即客戶端對服務端的accept的確認是爲了消除已失效的客戶端請求到達服務端，讓服務端產生僞鏈接一直等待客戶端的數據，從而浪費資源。
釋放鏈接：
由於tcp是全雙工通信，所以鏈路釋放需要四個分節（四次握手）完成：
（1） 首先某個應用程序首先調用close，執行主動關閉，發送一個FIN分節，標識數據發送完畢；
（2） 接收到這個FIN分節的對端執行被動關閉，這個FIN由TCP確認。它的接收也作爲一個文件結束符（end of file）傳遞給接收端的應用程序（放在一排隊等候該應用進程接收的任何其他數據之後），因爲FIN的接收標識沒有其他數據需要接收了；
（3） 一段時間後，接收到這個文件結束符的應用程序將調用close關閉它的套接字（ip地址+端口號），發送一個FIN的tcp報文，表示被動關閉端的數據也發送完畢；
（4） 接收到最終這個FIN的源端tcp（執行主動關閉的那一端）確認這個FIN報文。
TCP所涉及的建立鏈接和釋放鏈接可以用狀態轉換圖來說明，如下圖：
下圖爲TCP連接的分組交換：
一旦一個連接建立，客戶端就構造一個請求發送給服務端，一般在以太網上的tcp分節的數據部分爲1460個字節，服務器處理該請求後併發送一個應答，上圖中用粗箭頭表示兩個數據分節。需要注意的是，服務端對客戶端的確認伴隨其應答一起發送，以提高網絡利用率，此種做法稱爲捎帶機制（piggybacking）,通常在服務端處理請求併產生應答的時間少於200ms時發送，否則分開發送，即數據應答和請求分開發送。
TIME_WAIT狀態一般維持在兩倍的MSL，其存在的兩個理由：
（1） 可靠地實現TCP全雙工鏈接的終止；
（2） 允許老的重複分節在網絡中消逝。
4、可靠傳輸與流量控制
TCP的可靠傳輸主要由滑動窗口機制、超時重傳機制來保證，同時也可利用選擇確認機制（SACK）提高網絡通信利用率。
滑動窗口機制：
本部分by （pan) http://blog.csdn.net/thisispan/article/details/7545785
（1） 窗口機制
滑動窗口協議的基本原理就是在任意時刻，發送方都維持了一個連續的允許發送的幀的序號，稱爲發送窗口；同時，接收方也維持了一個連續的允許接收的幀的序號，稱爲接收窗口。發送窗口和接收窗口的序號的上下界不一定要一樣，甚至大小也可以不同。不同的滑動窗口協議窗口大小一般不同。發送方窗口內的序列號代表了那些已經被髮送，但是還沒有被確認的幀，或者是那些可以被髮送的幀。下面舉一個例子（假設發送窗口尺寸爲2，接收窗口尺寸爲1）：
分析：①初始態，發送方沒有幀發出，發送窗口前後沿相重合。接收方0號窗口打開，等待接收0號幀；②發送方打開0號窗口，表示已發出0幀但尚確認返回信息。此時接收窗口狀態不變；③發送方打開0、1號窗口，表示0、1號幀均在等待確認之列。至此，發送方打開的窗口數已達規定限度，在未收到新的確認返回幀之前，發送方將暫停發送新的數據幀。接收窗口此時狀態仍未變；④接收方已收到0號幀，0號窗口關閉，1號窗口打開，表示準備接收1號幀。此時發送窗口狀態不變；⑤發送方收到接收方發來的0號幀確認返回信息，關閉0號窗口，表示從重發表中刪除0號幀。此時接收窗口狀態仍不變；⑥發送方繼續發送2號幀，2號窗口打開，表示2號幀也納入待確認之列。至此，發送方打開的窗口又已達規定限度，在未收到新的確認返回幀之前，發送方將暫停發送新的數據幀，此時接收窗口狀態仍不變；⑦接收方已收到1號幀，1號窗口關閉，2號窗口打開，表示準備接收2號幀。此時發送窗口狀態不變；⑧發送方收到接收方發來的1號幀收畢的確認信息，關閉1號窗口，表示從重發表中刪除1號幀。此時接收窗口狀態仍不變。
若從滑動窗口的觀點來統一看待1比特滑動窗口、後退n及選擇重傳三種協議，它們的差別僅在於各自窗口尺寸的大小不同而已。1比特滑動窗口協議：發送窗口=1，接收窗口=1；後退n協議：發窗口>1，接收窗口>1；選擇重傳協議：發送窗口>1,接收窗口>1。
（2） 1比特滑動窗口協議
當發送窗口和接收窗口的大小固定爲1時，滑動窗口協議退化爲停等協議（stop－and－wait）。該協議規定發送方每發送一幀後就要停下來，等待接收方已正確接收的確認（acknowledgement）返回後才能繼續發送下一幀。由於接收方需要判斷接收到的幀是新發的幀還是重新發送的幀，因此發送方要爲每一個幀加一個序號。由於停等協議規定只有一幀完全發送成功後才能發送新的幀，因而只用一比特來編號就夠了。其發送方和接收方運行的流程圖如圖所示。
（3） 後退n協議
由於停等協議要爲每一個幀進行確認後才繼續發送下一幀，大大降低了信道利用率，因此又提出了後退n協議。後退n協議中，發送方在發完一個數據幀後，不停下來等待應答幀，而是連續發送若干個數據幀，即使在連續發送過程中收到了接收方發來的應答幀，也可以繼續發送。且發送方在每發送完一個數據幀時都要設置超時定時器。只要在所設置的超時時間內仍收到確認幀，就要重發相應的數據幀。如：當發送方發送了N個幀後，若發現該N幀的前一個幀在計時器超時後仍未返回其確認信息，則該幀被判爲出錯或丟失，此時發送方就不得不重新發送出錯幀及其後的N幀。
從這裏不難看出，後退n協議一方面因連續發送數據幀而提高了效率，但另一方面，在重傳時又必須把原來已正確傳送過的數據幀進行重傳（僅因這些數據幀之前有一個數據幀出了錯），這種做法又使傳送效率降低。由此可見，若傳輸信道的傳輸質量很差因而誤碼率較大時，連續測協議不一定優於停止等待協議。此協議中的發送窗口的大小爲k，接收窗口仍是1。
（4） 選擇重傳協議
在後退n協議中，接收方若發現錯誤幀就不再接收後續的幀，即使是正確到達的幀，這顯然是一種浪費。另一種效率更高的策略是當接收方發現某幀出錯後，其後繼續送來的正確的幀雖然不能立即遞交給接收方的高層，但接收方仍可收下來，存放在一個緩衝區中，同時要求發送方重新傳送出錯的那一幀。一旦收到重新傳來的幀後，就可以原已存於緩衝區中的其餘幀一併按正確的順序遞交高層。這種方法稱爲選擇重發(SELECTICE REPEAT)，其工作過程如圖所示。顯然，選擇重發減少了浪費，但要求接收方有足夠大的緩衝區空間。
（5） 滑動窗口機制
滑動窗口協議可用下圖來表示：
圖中我們已經將字節進行了1到11的編號。由接收者通告的窗口稱爲提議窗口（offered window），它覆蓋了第4到第9個字節，意味着接收方已經確認了第3字節之前（包括第3字節）的數據，並且通告窗口的大小是6。窗口大小與確認的順序號（acknowledged sequence number）有關。發送者計算它的可用窗口（usable window），用以度量它可以立即發送多少數據。
隨着接收者對收到數據的確認，滑動窗口隨時向右移動。窗口兩端的相關運動增加或減少着窗口大小。我們使用3個術語來描述窗口邊緣（edge）的左右運動。
① 當窗口左邊緣靠近右邊緣時稱窗口閉合（window closes）。窗口閉合發生在數據已經發送並被確認的情況下；
② 當窗口右邊緣向右移動時稱窗口打開（window opens）。窗口打開發生在另一端的接收進程讀取已確認數據的時候，它釋放了TCP接收緩衝區的空間；
③ 當窗口右邊緣向左移動時稱窗口收縮（window shrinks）。HostRequirement RFC強烈不鼓勵這種做法，但TCP必須能夠在一端發生這種情況時進行處理。
上圖表示了這三個術語。由於窗口的左邊緣是受從連接另一端收到的確認號來控制的，因此它不會向左移動。如果收到一個ACK要求將左邊緣向左移動，那麼它是一個重複的（duplicate）的確認，並被丟棄。
如果窗口左邊緣重合了右邊緣，就稱它爲零窗口（zero window）。它將停止發送者傳輸任何數據。
示例，下圖顯示了圖一數據傳輸中TCP滑動窗口的動態變化。
以此圖爲例，我們可以總結幾個要點：
① 發送者不必傳送滿窗口大小的數據；
② 收到接收者對數據的確認後，窗口向右滑動。這是由於窗口大小與確認順序號相關；
③ 從段7到段8的變化，可以看出窗口可以減小，但窗口右邊緣不能向左移動；
④ 接收者不必等待窗口被填滿才發送確認。在許多實現中，接收者每收到兩個段發送一個確認。
（6） 滑動窗口與流量控制
流量控制用於防止在端口阻塞的情況下丟幀，這種方法是當發送或接收緩衝區開始溢出時通過將阻塞信號發送回源地址實現的。流量控制可以有效的防止由於網絡中瞬間的大量數據對網絡帶來的衝擊，保證用戶網絡高效而穩定的運行。滑動窗口協議是常用的流量控制方法之一。
5、擁塞控制
擁塞控制是防止過多的數據注入到網絡中，從而不導致網絡中的路由器或者鏈路過載，是一個全局性的過程；流程控制是點對點的通信控制，保證發送方和接收方的速度匹配。常用的擁塞控制方法有：慢開始、用賽避免、快重傳和快恢復四種。下圖爲慢開始策略的流程圖。
此圖by http://www.cppblog.com/lgq0537/archive/2011/09/15/155866.html
