運輸層和TCP/IP協議

0. 基本要點

• 運輸層是爲相互通訊的應用進程提供邏輯通訊。
• 端口和套接字的意義
• 什麼是無鏈接UDP
• 什麼是面向鏈接的TCP
• 在不可靠的網絡上實現可靠傳輸的工做原理，中止等待協議和ARQ協議
• TCP的滑動窗口、流量控制、擁塞控制和鏈接管理

1. 運輸層協議概述

• 爲何須要運輸層？
  通訊真正的端點並非主機而是主機中的進程，IP協議幫助咱們將分組數據發送到對應的主機，可是這個分組仍是停留在了網絡層，IP協議並不知道須要將分組數據交付給主機中的哪個應用或者哪個進程，而運輸層的做用在於，一方面爲上層應用層提供進程的端到端通訊服務，一方面屏蔽了下面網絡核心的細節，在邏輯上好像兩個進程實體之間存在一條端到端的邏輯通訊通道。
• 運輸層的兩個功能：複用和分用

• 運輸層和網絡層的區別：
  1. 網絡層爲主機之間提供邏輯通訊，運輸層爲進程之間提供端到端的邏輯通訊
  2. 運輸層還要對報文進行差錯檢測，網絡層只檢驗頭部部分

2. TCP和UDP

• UDP傳輸的是UDP報文段，在傳送數據以前不須要創建鏈接
• TCP提供面向鏈接的服務，傳送數據前要創建鏈接，傳送結束後要釋放鏈接，TCP 不提供廣播和多播服務，由於TCP要保證可靠的鏈接，所以增長不少相應的開銷，協議首部會相對較大，同時也佔用不少處理機的資源

• 端口：標誌本計算機應用層的各個進程與運輸層交互的層間接口，爲了找到對方計算機中的應用進程。由於進程在不一樣的操做系統中的進程標識符是不一樣的，所以用標識符來識別進程是行不通的。

  1. 服務器使用的端口號：系統端口號:0-1023 登記端口號：1024-49151
     常見端口號：FTP：21， TELNET：23， SMTP：25
     DNS：55，TFTP：69，HTTP：80
     SNMP：161 SMP（trap）：162 ，HTTPS：443html

  2. 客戶端使用端口號：短暫端口號 49152-65535算法

3. UDP協議

• UDP是無鏈接的，UDP不須要維持複雜的鏈接狀態表，它盡最大努力交付
• UDP是面向報文的，這裏注意：UDP對於應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界，應用層交給UDP多長的報文，UDP就封裝多長的報文，所以，用戶須要選擇合適的報文長度，不然交給IP層後，過長會致使分片，過短會形成首部相對長度太大，下降IP層的效率。
• UDP沒有擁塞控制，網絡擁塞不會下降源主機的發送效率。在一些實時應用中，如ＩＰ電話容許存在必定程度的丟包，但不容許太大延時。
• UDP支持一對一，一對多，多對多交互通訊
• UDP首部開銷小，只有8個字節，每一個字段的長度都是兩個字節，源端口+目的端口+長度+校驗和

4. TCP協議

4.1 TCP協議特色

• TCP協議是面向鏈接的，使用時創建鏈接，使用完畢釋放鏈接
• 每一個TCP鏈接只有連個端點，也就是說TCP鏈接是點對點，一對一的
• TCP提供可靠的交付，無差錯，不丟失，不重複，而且按序到達
• TCP提供全雙工的通訊，TCP容許進程任什麼時候候都發送數據，TCP兩端設有發送緩存和接收緩存，TCP會在合適的時候讀取緩存或者將緩存中的數據發送出去。
• TCP面向字節流，注意TCP並不關心進程一次將多少緩存發送到TCP的緩存，UPD發送的報文長度由進程指定，而TCP則是根據對方給的窗口值和當前網絡擁塞狀況而決定一個報文段包含多少字節。若是緩存數據塊過長，TCP劃分短一些，太短就積累足夠多的字節構成報文段發送出去。

4.2 套接字

• 套接字是一個抽象的概念：socket = （IP地址：端口號），TCP鏈接：{套接字}：{套接字}，同一個IP地址能夠有多個不一樣的TCP鏈接，同一個端口號也能夠出如今多個不一樣的TCP鏈接中。

4.3 可靠傳輸的工做原理

基本原理：當出現差錯時讓發送方從新傳輸出錯的數據，同時在收方來不及處理數據時，及時告知發送方下降發送速率。緩存

• 中止等待協議（最簡單的協議，實際運輸層並無採用）：發送完一個分組後中止發送，等待對方的確認，收到確認後再發送下一個分組，若是收不到對方確認，超時重傳，而產生超時重傳的緣由多是收方的確認丟失了，也多是發送方發送的分組出錯或者丟失，所以對於收方，對於重傳的分組，假如是已經收到過的分組，此時須要執行丟棄重複分組，向發送方發送確認的動做。對於可能遲到的確認，發送方執行收下丟棄的處理。這種自動重傳的協議咱們稱之爲ARQ（Automatic Repeat request）協議。
• ARQ協議最大的缺點是信道利用率過低，要一直等待來回往返的確認RTT時間，若是往返時間大於分組發送時間Td，那麼信道利用率是很是低的。所以將來提升傳輸效率，採用流水線發送，也就是連續ARQ協議和滑動窗口協議。
• 連續ARQ協議與go-back-N

4.4 TCP報文段首部

有幾個比較重要的概念：服務器

• 序號：佔4個字節，一個TCP鏈接中的傳輸的字節流都要按順序編號，好比一個報文字節序號爲301，攜帶100個字節數據，那麼該報文中第一個字節的序號爲301，最後一個字節爲400，下一個報文的序號字段值應爲401
• 確認號：佔4個字節，是指望收到對方下一個報文段的第一個數據字節的序號。好比B正確收到了A發來的501-700的數據，那麼B發送給A的確認報文中確認號位701，確認號=N，則代表到序號N-1爲止全部數據都正確收到。
• 窗口：窗口值告訴對方從本報文首部確認號算起，接收方目前容許對方發送的數據量，（接收方的緩存是有限的）。B返回給A確認號701，窗口字段爲1000，也就是告訴對方，從701開始，個人接收緩存空間還可接收1000個字節數據，你在發送數據時，必須考慮這一點。窗口字段明確指出如今容許對方發送的數據量，窗口值常常在動態變化。
• 選項：最大報文段長度MSS，窗口擴大項，時間戳（可處理**TCP序號超過2^32的狀況，防止序號繞回）

5. TCP的可靠傳輸的實現

TCP 滑動窗口協議網絡

以字節爲單位的滑動窗口：發送方A的發送窗口，接收方B的接收窗口socket

• 發送方緩存：發送緩存用於存放準備發送的數據和已經發送但還沒有收到確認的數據
• 發送窗口：發送窗口是發送緩存的一部分，已經確認的數據應當從發送緩存中刪除，所以發送緩存和發送窗口的後沿是重合的（注意發送程序須要控制寫入緩存的速率，太快會致使緩存沒有存放數據的空間，由於發送的數據可能還未被確認）
• 接收緩存存放：按序到達但尚未被應用接收的數據和未按序到達的數據
• 接收窗口：若是收到分組出錯，就要丟棄，若是接收應用程序來不及接收數據，接收緩存會被填滿，接收窗口會被減少爲零，若是可以及時處理，接收窗口就能夠增大，接收窗口動態調整，並反饋給發送方，以通知發送方調整發送速率。
• 發送窗口兩個決定因素：1.B的接收窗口做爲參考 2.根據網絡擁塞狀況適當減少發送窗口數值
• 整個發送過程能夠描述爲：
  1. A能夠將窗口內的數據都發送出去，在此期間不須要收到B的確認狀況，凡是沒有獲得確認的已發送數據暫時保留，以便超時重傳。
  2. B接收窗口對按序收到的數據的最高序號給出確認，若是B確認收到這些數據，就將接收窗口向前移動，並給A發送確認，A收到確認後，就將發送窗口向前移動。
  3. 若是A一直髮送數據，一直到整個發送窗口內的數據發送完畢，也沒有收到B的確認，那麼A的發送窗口已滿，則須要中止發送，通過一段時間（超時）重傳這部分數據，直到收到B的確認，就能夠向前移動窗口了。
• 超時重傳的時間選擇
  1. 太短，引發沒必要要的重傳，過長，空閒時間增大，下降效率
  2. 自適應算法，記錄報文段往返時間RTT（報文發出到收到確認之間的時間），經過測量RTT，得到一個加權平均往返時間RTTs
     新RTTs = （1-α）舊RTTs + α 新RTT樣本（α一般爲0.125）
     則超時重傳時間RTO爲：RTO= RTTs + 4 * RTTd（RTT的誤差加權平均值）
  3. Kam算法：在計算加權平均RTTs的時候，只要報文段重傳了，就不採用其往返時間樣本。

6. TCP的流量控制

注意理解流量控制和擁塞控制的區別tcp

• 流量控制：flow control，讓發送方發送速率不要太快，要讓接收方來得及接收，也就是說是一對一，發送方和接收方的協商
• 流量控制的實現：滑動窗口機制，發送方的接收窗口不能超過接收方的接收窗口，接收方在發送ACK時可向發送方發送rwnd字段，告知接收窗口的大小進行流量控制

• 注意死鎖的產生：B向A發送了零窗口報文後，過一段時間後B有了空間並向A發送rwnd = n的報文段，可是該報文段丟失了，這個時候A在等待B，B也在等待A從新發送數據，致使了互相等待的死鎖局面。解決方法是當TCP鏈接的一方接到對方的零窗口通知，就啓動持續計時器，若是時間到，就發送一個零窗口探測報文段。
• TCP傳輸效率：控制TCP發送報文段的時機

  1. Nagle算法：Nagle算法就是爲了儘量發送大塊數據，避免網絡中充斥着許多小數據塊。Nagle算法的基本定義是任意時刻，最多隻能有一個未被確認的小段。 所謂「小段」，指的是小於MSS尺寸的數據塊，所謂「未被確認」，是指一個數據塊發送出去後，沒有收到對方發送的ACK確認該數據已收到。性能

     （1）若是包長度達到MSS或者發送窗口大小的一半，則容許發送；
     （2）若是該包含有FIN，則容許發送；
     （3）設置了TCP_NODELAY選項，則容許發送；
     （4）未設置TCP_CORK選項時，若全部發出去的小數據包（包長度小於MSS）均被確認，則容許發送；
     （5）上述條件都未知足，但發生了超時（通常爲200ms），則當即發送。操作系統

  2. 糊塗窗口綜合徵（silly window syndrome）設計

7. TCP的擁塞控制

7.1 擁塞控制與流量控制的區別

• 擁塞產生的緣由：對網絡資源的需求大於可用的資源，多是帶寬不夠，也多是交換結點的緩存過小，也多是發送方發送數據過快，而接受方接受數據過慢
• 擁塞控制：擁塞控制是防止過多的數據注入到網絡中，這樣使得網絡中路由器或者鏈路不至於過載，擁塞控制是一個全局性控制，涉及到全部主機、全部路由器以及下降網絡傳輸性能有關的因素，相對於流量控制，流量控制是點對點通訊量的控制，是一個端到端的問題，抑制發送端發送速率，以便接收端來得及接收。
• 擁塞控制容易與流量控制搞混，實際上某些擁塞控制就是經過向發送端報告網絡狀況，減緩發送速率來實現擁塞的控制
• 擁塞控制由開環控制和閉環控制兩種方法：
  1. 開環：設計網絡時充分考慮有關擁塞狀況，力求網絡工做時不發送擁塞
  2. 閉環：檢測系統網絡以便檢測擁塞在何處發生什麼時候發生，而後根據擁塞產生的信息來調整網絡運行狀態，調整狀態的操做如增大網絡某些可用資源，或減小用戶對某些資源的額需求等，調整過程也是一個動態變化的過程

7.2 TCP擁塞控制方法

TCP擁塞控制算法包括：快開始（Slow-start），擁塞避免（congestion avoidance）,快重傳（fast retransmit）和快恢復（fast recovery）,這四個算法是配合起來使用的，以實現擁塞控制，固然這裏的擁塞控制本質上是流量控制

• 判斷網絡擁塞的依據：出現超時
• 慢開始：當主機開始發送數據時，並不清楚網絡的負載狀況，若是將大量字節注入網絡，有可能引發網絡擁塞，那麼能夠先探測一下，由小到大逐漸增大擁塞窗口數值，也就是逐漸增大發送窗口。初始擁塞窗口cwnd設置不超過2-4個SMSS（sender maximum segement size）
  1. 慢開始規定，每收到一個對新的報文段的確認後，就能夠將擁塞窗口增長最多一個SMSS數值，也就是每次增長量 = min（N,SMSS），N是原先未確認，可是如今剛收到確認的字節數
  2. 如圖所示，每通過一個傳輸輪次，擁塞窗口cwnd就加倍，（傳輸輪次是指往返時間RTT，就是將發送窗口中全部數據都發送出去了，而且發送方收到了對該窗口中最後一個字節的確認的這樣一個輪次）
  3. 慢開始的慢在於TCP剛開始發送時是一個試探性發送的狀態，其窗口cwnd的增加速率並不慢，是呈指數增加的。
• 擁塞避免：由於慢開始的增加速率很快，cwnd很快就變得很大，若是增加過快就會產生網絡擁塞，因此須要一個慢開始門限。在cwnd達到門限以後，採用擁塞避免算法，使得cwnd緩慢線性增加。
  1. cwnd<ssthresh,使用慢開始算法，cwnd>ssthresh,使用擁塞避免，cwnd = ssthresh，二者皆可
  2. 擁塞避免每通過一個RTT時間，將cwnd加1，也就是加法增大，線性規律增加；
  3. 若是當達到某一窗口大小，產生超時，發送方判斷爲擁塞產生，則**調整門限值ssthresh = cwnd（當前值）/2, cwnd = 1(調整爲1，進入慢開始）
• 快重傳：目的是當網絡沒有產生擁塞，可是出現個別報文段丟失，爲了不發送方認爲超時進入慢開始狀態，應儘快在超時的限制時間內讓發送方儘早知道有個別報文段產生了丟失，以儘快進行重傳，這樣就不會產生超時，不會被默認爲存在網絡擁塞。
  1. 快重傳算法要求當即確認，要求接受方不使用捎帶確認，而是即便收到了失序報文段也要當即發出對已收到報文段的額重複確認。
  2. 算法規定，只要連續收到3個重複確認，就知道是哪一段對方沒有收到，應道當即進行重傳

• 快恢復：承接快重傳，發送方知道已經丟失了個別報文段，執行快回復算法，調整門限ssthresh = cwnd /2,設置cwnd = ssthresh，並開始執行擁塞避免算法，也有將ssthresh = cwnd/2 +3

  

• 注意：發送方窗口是由網絡擁塞狀況和對方的接收窗口共同決定的
  發送窗口上限值 = Min{rwnd，cwnd}

• 主動隊列管理：AQM（active queue management），路由器內部隊列採用先入先出規則，若是隊列已滿，會丟棄再到達的分組，若是被動的隊滿丟棄，容易影響不少TCP鏈接，致使全局同步，全局通訊量降低，因此採用主動隊列管理，當網絡擁塞出現某些徵兆的時候，主動丟棄某些分組，隨機早期檢測就是當隊列平均隊列長度達到必定值時，按照某種機率丟棄個別分組，這樣讓擁塞控制只在某些TCP鏈接上出現。

8. TCP鏈接創建，數據傳輸和鏈接釋放

• TCP採用C/S模型，主動發起鏈接的是客戶，等待鏈接的是服務器

• A和B都各自選擇初始序列號 x，y
• SYN = 1 即SYN報文段不能攜帶數據，但要消耗一個序號
• ACK報文段能夠攜帶數據，若是不攜帶數據就不消耗序號
• 爲何A最後還要再發送一個ACK？是爲了防止已經失效的鏈接報文請求忽然傳送到B，於是產生錯誤

• B結束TCP鏈接的時間要早於A
• 當A處於FIN-WAIT-2狀態時，TCP處於半關閉狀態，也就是說這個時候A已經不須要發送數據給B了，可是若是B有數據想要發送，A仍然須要接收
• A接收到B釋放鏈接報文並返回ACK後處於TIME-WAIT狀態，還要等待2MSL才能夠釋放鏈接
  1. 實現終止TCP全雙工鏈接的可靠性：假設最後的ACK丟失，服務器會重發FIN，所以客戶端須要維護狀態信息以容許重發最終的ACK（對於主動斷開鏈接的服務器是一樣的道理）保證A發送的最後一個ACK報文段可以到達B
  2. 保證老的重複分節在網絡消失：保證來自先前鏈接的老的重複分組已經消失，2MSL（maximum segment lifetime 最長分節生命）時間足夠讓某個方向上的分組丟棄