第3章 運輸層
3.1 概述和運輸層服務
運輸層協議爲運行在不同主機上的應用進程之間提供了邏輯通信。運輸層協議是在端系統中而不是在路由器中實現的。網絡路由器僅作用於該數據報的網絡層字段，它們不檢查封裝在該數據報的運輸層報文段的字段。
3.1.1 運輸層和網絡層的關係
網絡層提供了主機之間的邏輯通信，而運輸層爲運行在不同主機上的進程之間提供了邏輯通信。運輸協議能提供的服務往往受制於底層網絡層協議的服務模型。
3.1.2 因特網運輸層概述
UDP（用戶數據報協議），它爲調用它的應用程序提供了一種不可靠的、無連接的服務。另一種是TCP（傳輸控制協議），它爲調用它的應用程序提供了一種可靠的、面向連接的服務。
3.2 多路複用和多路分解
我們討論運輸層的多路複用與多路分解，也就是將由網絡層提供的主機到主機交付服務延伸到爲運行在主機上的應用程序提供進程到進程的交付服務。
套接字是從網絡向進程傳遞數據和從進程向網絡傳遞數據的門戶。在接收主機中的運輸層實際上並沒有直接將數據交付給進程，而是將數據交給了一箇中間套接字。通過套接字將數據交付給對應進程。
將運輸層報文段中的數據交付到正確的套接字的工作稱爲多路分解。在源主機從不同套接字中收集數據塊，併爲每個數據塊封裝上首部信息從而生成報文段，然後將報文段傳遞到網絡層，所有這些工作成爲多路複用。
1.無連接的多路複用和多路分解
一個UDP套接字是由一個二元組來全面標識的，該二元組包含一個目的IP地址和一個目的端口號。如果兩個UDP報文段有不同的源IP地址和/或源端口號，但具有相同的目的IP地址和目的端口號，那麼這兩個報文段將通過相同的目的套接字被定向到相同的目的進程。
2.面向連接的多路複用和多路分解
TCP套接字是由一個四元組（源IP地址，源端口號，目的IP地址，目的端口號）來標識的。當一個TCP報文段從網絡到達一臺主機時，該主機使用全部四個值來將報文段定向到相應的套接字。與UDP不同的是，即使兩個報文具有相同的目的IP和目的端口號，兩個具有不同源IP地址或源端口號的到達TCP報文段將被定向到兩個不同的套接字，除非TCP報文段懈怠了初始創建連接的請求。
3.Web服務器和TCP
當今高性能Web服務器通常只使用一個進程，但是爲每個新的客戶連接創建一個具有新連接套接字的新線程。
3.3 無連接運輸：UDP
使用UDP差不多就是直接和IP打交道。
UDP的特點：
1. 沒有阻塞控制、不保證可靠數據傳輸
2. 無需建立連接
3. 無連接狀態
4. 分組首部開銷小
3.3.1 UDP報文段結構
UDP首部有4個字段，每個字段由兩個字節組成。長度字段指示了在UDP報文段中的字節數（首部加數據）。接收方使用檢驗和來檢查在該報文段中是否出現了差錯。
3.3.2 UDP校驗和
發送方的UDP對報文段中的所有16比特字的和進行反碼運算，求和時遇到任何溢出都要被回捲。
在接收方，全部的4個16比特字加在一起，如果該分組中沒有引入差錯，則將所有數據段的16比特字加上校驗和，結果應爲1111111111111111。
3.4 可靠數據傳輸原理
3.4.1 構造可靠數據傳輸協議
rdt 3.0發送方狀態圖：
校驗碼：驗證報文段在發送過程中是否受損。
肯定確認、否定確認：當發送方將報文段發送給接收方時，接收方發送一個肯定確認或者否定確認到發送方以通知發送方發送報文數據是否正確。
序號：肯定確認或者否定確認在發送過程中可能會受損，爲了處理這種錯誤，在數據分組中添加一段字段，讓發送方對其數據分組編號，將發送數據分組的序號放在該字段。接收方只要檢查序號即可確定到的分組是否一次重傳。
倒計數定時器：肯定確認、否定確認丟失，或者過度延時，用於重傳的計時器。
當發送方從上層接收到報文，將報文打包添加序號、校驗碼等信息，然後發送報文段並啓動計時器，當接收到與打包序號相同的否定確認就重傳報文段，當計時器超時了，同樣執行重傳操作，如果接收到與打包序號相同的肯定確認就繼續發送報文，並重啓計時器。如果接收到的確認與發送報文中的序號不同，則繼續等待。
接收方FSM：
接收方相對發送方就很容易理解了，這裏不多贅述。
流水線：然而現在的rdt算法在發送報文後要一直等待確認報文，否則將無法繼續發送其他報文。這使性能大大降低。爲了不使用停等的方式運行，允許發送方發送多個分組而無需確認等待。
3.4.3 回退N步（GBN）
GBN協議中發送方看到的序號：
- [0 , base - 1]段內的序號對應於已經發送並被確認的分組。
- [base , nextseqnum - 1]段內對應已被髮送而沒被確認的分組。
- [nextsequm , base + N - 1]段內的序號能對於那些要被立即發送的分組。
- [base + N , 無窮大)表示當前不可用的部分。
N稱爲窗口長度，GBN協議也常被稱爲滑動窗口協議。
如果分組序號字段的比特數是k，那麼該序號的範圍是[0,2^k - 1]。
GBN具有一個計數器，用於計數最近要接收的確認報文的是否超時。
GBN發送方描述：當上層調用rdt_send()時，檢查是否發送窗口已滿，如果未滿則產生一個分組將其發送，將nextseqnum+1，當base和nextseqnum時相同時打開計時器。如果發送窗口已滿，則將數據返回給上層，指示該窗口已滿。當超時時，則重傳所有現在已經發送但沒有收到確認的分組，即綠色表示的分組。當收到一個ACK，如果ACK爲base指向的分組的確認ACK則，base前移。
GBN接收方描述：當接收到順序的分組，則base右移，然後發送肯定報文。如果接收到的分組是亂序的，那麼丟棄該分組，返回最後一個已經接收到的報文的肯定確認。
發送方、接收方窗口大小比：2^k-1:1。
3.4.4 選擇重傳（SR）
選擇重傳協議中發送方看到的序號：
選擇重傳協議中接收方看到的序號：
發送方描述：
1. 從上層收到數據。從上層收到數據後，SR發送方檢查下一個可用於該分組的序號。如果序號位於發送方的窗口內，則將數據打包併發送；否則通知上層。
2. 超時。每個分組都具有一個定時器，當定時器超時時，只用發送自己代表的那個分組就行。
3. 收到ACK。若收到的ACK在窗口內，則標記窗口內的分組，如果接收到的ACK是base分組的ACK，則移動窗口到最近的未接收到ACK的地方。
接收方描述：
1. 序號在[rcv_base , rcv_base + N - 1]內的分組被正確接收，返回一個ACK給發送方，如果沒接收到過則緩存該分組，如果該分組爲rcv_base，移動窗口。
2. 序號在[rcv_base - N , rcv_base - 1]內的分組被正確收到，產生一個ACK，即使該分組是接收方以前接收過並確認的分組。
3. 其他情況。忽略該分組。
發送方、接收方窗口大小比：2:1或者大於2/1。
3.5 面向連接的運輸：TCP
3.5.1 TCP連接
面向連接的：在進程傳輸數據之前必須先互相“握手”，建立連接。
全雙工服務：一臺主機上的進程A與另一臺主機上的進程B，在進程A發送數據流向進程B的同時，進程B可以發送數據流向進程A。
點對點的：單個發送方和單個接收方之間的連接。
TCP發送緩存和接收緩存：
TCP從上層獲取數據放到發送緩存中，然後在3次握手後，TCP從緩存中取出數據包裝發送到接收方緩存中，上層根據自己的情況從緩存中獲取數據。TCP從緩存中取出並放入報文段的輸入數量受限於最大報文段長度(Maximum Segment Size , MSS)。MSS通常根據最初確定的由本地發送主機發送的最大鏈路層幀長度來設置。
3.5.2 TCP報文段結構
TCP報文結構：
TCP報文包含如下字段：
- 源端口號、目的端口號
- 檢驗和字段
- 32比特的序號字段和32位確認號字段。兩者用於提供可靠數據傳輸服務。
- 16比特的接收窗口字段。用於流量控制。
- 4比特的首部長度字段。該字段指示了以32比特的字爲單位的TCP首部長度。由於TCP選項的原因，TCP首部長度是可變的。
- 可選和變長的選項字段。該字段用於發送方和接收方協商最大報文字段長度，或在告訴網絡環境下用作窗口調節因子時使用。
- 6比特的標誌字段。ACK用於指示確認字段總的值是有效的。RST、SYN、FIN用於連接建立和拆除。PSH比特被設置時，就指示接收方應立即將數據交給上層。URG比特用來指示報文段裏存在着被髮送端的上層設置爲緊急的數據。PSH、URG以及緊急數據指針沒有啓用。
1.序號和確認號
序號：TCP將數據看成一個無結構、有序的字節流，序號用於標記分組順序。吖
確認號：由於TCP是全雙工的，發送方傳輸分組到接收方後，接收方需通知發送方數據得到，確認號用於標記接收方等待的下一個分組的序號。
TCP採用累計確認，並未規定接收到失序報文段如何處理，而是交給編程者處理。處理方法一般有如下兩種：
1. 接收方立即丟棄失序報文；
2. 接收方保留失序字節，並等待缺少的字節以填補該間隔。
下面給出一個例子，用於演示序號和確認號的用法：
考慮Telnet協議的一個場景，即用戶輸入字符發送到遠程服務器回顯的情況。
TCP握手期間確定，發送方第一個報文序號爲42，接收方第一個報文序號97。當用戶鍵入第一個字符“C”，發送方發送第一個報文，然後序號和確認號不變，當主機接收到報文後，更新需要的下一個報文序號，然後返回回顯數據，發送方收到回顯數據後，更新需要發送的序號。
3.5.3 往返時間的估計與超時
1.估計往返時間
TCP估計發送方和接收方之間往返時間是通過如下方法完成的。
報文段的樣本RTT（SimpleRTT）就是從某報文段被髮出到對該報文的確認被收到之間的時間量。大多數TCP僅在某個時刻做一次SimpleRTT的測量，而不是Wie某個發送的報文段都測量SimpleRTT。
由於路由器的阻塞和端系統負載的變化，SimpleRTT總隨之波動，TCP維持一個SampleRTT的均值，公式如下：
EstimatedRTT = (1-a)*EstimatedRTT + a*SampleRTTRFC 6298給出的a的參考值爲0.125。
定義RTT偏差爲DevRTT，用於估算SampleRTT一般會偏離EstimatedRTT的程度：
DevRTT = (1 - b) * DevRTT + b * |SampleRTT - EstimatedRTT|b的推薦值爲 0.25。
2.設置和管理重傳超時間隔
TCP確定重傳和超時間隔公式如下：
TimeoutInterval = EstimatedRTT + 4 * DevRTT3.5.4 可靠數據傳輸
TCP發送方有3個與發送和重傳有關的主要事件：從上層應用程序接收數據；定時器超時；收到ACK。
- 從上層應用程序接收數據；TCP將數據封裝在一個報文段，然後把報文段交給IP。如果定時器還未爲某些報文段開啓，則開啓定時器。定時器設置時間是TimeoutInterval。
- 超時；TCP通過重傳引起超時的報文段來響應超時事件。每次超時都會講TimeoutInterval設置爲原來的2倍，直至本報文段傳輸成功。
- 收到ACK；當該事件發生時，TCP將ACK的值y與它的變量SendBase進行比較。TCP狀態變量SendBase是最早未被確認的序號。如果y>SendBase，則該ACK是在確認一個或多個現錢未被確認的報文段。因此更新它的SendBase變量。當接收到3個相同數據的冗餘ACK，證明發生了數據丟失，立即重傳冗餘ACK指出的報文段，即快速重傳。
TCP接收方事件：
1. 接收到順序報文，發送ACK，請求下一序號報文
2. 丟失報文導致接收到亂序報文，發送ACK，請求原本要求序號報文。正因如此才能使用快速重傳。
TCP的差錯恢復機制是一種GBN和SR的混合體。
5.流量控制
流量控制是消除發送方使接收方緩存溢出的可能性。
擁塞控制是因爲IP網絡的擁塞而被遏制。
TCP通過讓發送方維護一個稱爲接受窗口的變量來提供流量控制服務。主機A通過一條TCP連接連接向主機B。主機B爲連接分配緩存RcvBuffer。同時考慮如下兩個變量：
1. LastByteRead:主機B上的應用進程從緩存中讀出的數據流的最後一個字節的編號。
2. LastByteRcvd:從網絡中到達的並且已放入主機B接收緩存中的數據的最後字節的編號。
由於TCP不允許已經分配的緩存溢出，因此
LastByteRcvd - LastByteRead <= RcvBuffer接收窗口採用rwnd表示，則是
rwnd = RcvBuffer - [LastByteRcvd - LastByteRead ]主機B通過把當前的rwnd值放入它發給主機A的報文段的接收窗口字段中，通知主機A該連接的緩存中還有多少可用空間。
於此同時，主機A也必須跟蹤兩個變量，LastByteSent和LastByteAcked，即最後發送的變量序號和最後確認的變量序號，兩者之差便是發送但未確認的數據量。而我們要做的就是將這個值控制在小於等於接收方rwnd的範圍內。即
LastBySent - LastByteAcked <= rwnd但不得不提的是，一旦rwnd變爲0後，將不會產生交互，即使rwnd更改後發送方也得不到信息，因此，當rwnd爲0時，主機A會繼續發送只有一個字節的報文段。這些報文會被接收方確認，因此rwnd不爲0時，發送方能得到通知。
至於UDP嘛，當產生緩存溢出時，UDP直接將報文丟掉，所以不存在流量控制。