**

*第五層:運輸層*

**

1. 概述:

 (1)真正資料通訊的意思其實是: 在主機的程序中, 由A主機的程序與B主機的程序進行資料交換的 過程而不是主機之間的資料交換. 很顯然, 將一個通訊過程分為這麼多層, 是為了讓底層給高層服務, 並將每一層的任務分配好. 更重要的是, 我們知道 一個主機當中有很多個程序同時在通訊, 但是我們又只有一個運輸層, 所以很明顯, 運輸層具有"複用"和"分用"功能, "複用"指的是這麼多程序都只使用一個運輸層來傳輸資料, 而"分用"指的是運輸層收到資料後,能夠準確地派遞相應的資料給相應的程序.



 (2)在物理層, 鏈路層, 網路層都沒有對資料的可靠傳輸進行把關, 所以這個任務也就留到了運輸層上了. 運輸層要對報文進行差錯檢測.



 (3)運輸層的UDP協議: 又叫 使用者資料報協議, UDP不提供可靠交付, 對給出的傳送報文, 不需要任何確認.



(4)運輸層的TCP協議: 又叫 傳輸控制協議, TCP是一種面向連線的服務, 要很多確認報文. 並且TCP不提供廣播和多播服務.
 

2. 埠

(1)歷史: 在概述(1)中提到, 運輸層有"分用"和"複用"功能, 所以對於每一個程序有一個標識號是非常重要的. 所以在運輸層使用"協議埠號"可以解決這問題, 簡稱"埠".



(2)分類: 埠分兩種: 第一種叫熟知埠號(系統埠號), 這些是一些常用並且固定下來的應用程式埠, 例如(FTP:21, HTTP:80), 另外一種叫登記埠, 這類埠是要申請的. 

3. UDP協議(使用者資料報協議)

 (1)概述: UDP是一種無連線, 盡最大努力交付的協議, 所以他不需要建立連結, 最重要的是, UDP協議是面向報文的, 也就是說, 對於應用層丟下來的資料, 和網路層傳上來的資料, UDP協議對它都不做任何改動, 既不拆分, 也不合並. 直接去除或者加上 UDP協議的首部就繼續下一步工作. 



(2)格式:

1.源埠: 在對方回信時選用, 不用就全0. 

2.目的埠: 在重點交付報文時需要.

3.長度: UDP資料部分的長度.

4.檢驗和: 檢驗UDP報 是否出現差錯, 有就丟棄. 

5.summary: 檢驗和部分百度把,不過這裡提一點, 在進行檢驗和時, 是將首部和資料報一起檢驗.
 

4. TCP協議(傳輸控制協議)

(1)格式: 

1.源埠和目的埠: 和UDP協議一樣.

2.序號: 對每一個位元組都進行按順序編號. 例如(一個數據包開始位元組序號:20111, 長度為10 , 則結束序號為20110)

3.確認號: 期望收到對方下一個報文的第一個資料位元組的序號.例如(A收到B的報文, 結束序號為100, 所以B希望下一次收到的是A的101序號開始的報文)

4.資料偏移: 指出 資料起始處距離TCP報文起始處有多遠, 其實就指出了TCP報文首部的長度.

5.保留: 無用就置為0, 根據一下功能置為1.

    5.1. 緊急URG: 當URG置為1, 表明緊急指標有效. 當URG=1(有緊急資料時), 此TCP報文就把緊急資料插入到本TCP報文的資料部分的最前面.

    5.2. 確認ACK: 當ACK=1時, 確認序號欄位生效.

    5.3. 推送PSH: 當PSH=1時, 就表明要儘快將此報文交付給應用程序.不要等到傳送快取滿了再發送.

    5.4. 復位RST: 當RST=1時, 表明TCP連接出現嚴重差錯, 需要釋放連線並重新連線. 

    5.5. 同步SYN: 這是一個"在連線建立時用來同步的序號", SYN置為1表示這是一個連線請求互毆連線接受的報文

    5.6. 終止FIN: 當FIN=1時, 表示此報文段的傳送方的資料已經發送完畢, 要求釋放連線.

6.視窗: 指的是傳送這個報文段的一方的接收視窗. 傳送視窗的大小就是視窗值決定的.

7.校驗和: 和UDP一樣 

8.緊急指標: 當IRG=1才有意義, 即使視窗值為0, 也可以傳送資料. 

9.選項: 長度可變, 最長40位元組. 



(2)概述: TCP協議是一種"端對端"的可靠交付的服務, 也可以理解成點對點, 所以, 他提全雙工通訊, 並且, 在接收方設定一個接收快取, 在傳送方設定一個傳送快取, 用來儲存臨時的資料報, 最最重要的是, TCP協議是一種面向位元組流的服務, 也就是說, 它關注的物件不是UDP的報文, 而是報文裡面的位元組流, 對位元組流進行資訊處理.



(3)TCP的連線方式: TCP把連線作為最基本的抽象, 很多行為都是基於連線上實行的. 運輸層是根應用層打交道的, 所以我們把TCP的連線的斷點叫做套接字或者插口. 格式如下: {IP地址:埠}
 

5. 停止等待協議

 (1)產生背景: 要想TCP傳輸實現無差錯.就必須滿足以下兩點, 傳輸通道不產生差錯和不管傳送方以多塊的速率傳送資料, 接收方都可以來得及處理資料. 但是, 現實的網路情況是很複雜的, 以上兩個情況也不可能存在, 所以我們需要一些技術去輔助, 變相實現以上兩個條件. 



(2)停止等待協議: 概念: 就是每傳送完一個分組就停止傳送, 直到收到對方的確認, 才傳送下一個分組.



(3)出現差錯的情況: 無差錯就是你傳一個, 我就確認, 你再傳下一個, 如此類推. 但是這裡說明一下特殊情況. 當分組出現差錯, 接收方就丟棄此分組, 然後什麼都不做.  那麼傳送方應該有所表示, 既然接收方收不到, 傳送方就要重傳, 但這個重傳是建立在一定要過一段時間後. 所以要在傳送方設定一個超時計時器. 以便實現超時重傳. 當然, 因為傳送方的分組雖然是傳送了, 但未必接收方一定收得到, 所以傳送方要暫時保留自己發的分組. 而且 待確認分組和已確認分組 都要進行編號, 這樣才能更好了解那些已經確認了.  



(4)確認丟失和確認遲到的情況: 

丟失: 因為接收方的確認分組丟失, 所以傳送方重傳, 所以接收方又收到同一份報文, 這是 接收方要麼丟棄這個重複的分組, 要麼向傳送方傳送確認！！

遲到:因為接收方的確認分組遲到了, 所以A經過重傳後, 收到了重複的確認. 那麼傳送方就收下後, 丟棄。沒有別的操作.

6. 連續ARQ協議

(1)概念: 按照我自己的理解: 就是一個分組, 裡面有很多已經打上順序編號的位元組, 因為要實現無論傳送方多塊的發速率, 接收方都可以接受, 所以我們就 規定一個發哦是那個視窗, 這個視窗如圖所示, 可設定大小. 



(2)工作原理: 首先先把傳送窗口裡的位元組都發送出去, 那接收方, 採用累積確認的方式(不必每個分組都確認， 對按序到達的最後一個分組傳送確認就好了) 傳送確認報文, 然後 傳送方接收到確認報文後, 看一下確認分組裡面最後一個分組的序號是多少,(就是看一下有N個已經確認接收了),就把傳送視窗的起始位置向前推進N個.

7. 休息一下,累死我了

 接下來的部分就是 談談關於 滑動視窗, 流量控制, 擁塞控制了. 而且接下來的內容就是基於上面的內容來展開的.

8. 滑動視窗

(1)注意: 傳送視窗是由接收方的接收視窗具體數值和當前網路擁塞程度決定的.視窗值為20.



(2)工作原理:由上圖可以知道, 傳送視窗是由三個指標來決定的（在(1)之後）, 現在, A傳送了31-41的位元組, 但還沒收到確認,  再看看B接收方. 顯然, 31是已經收到併發送確認報文了, 所以B傳送的確認報文是31序號. 很顯然B也只收到了31, 31以後的32.33都沒收到.所以就要求A重傳32.33-》( A就把傳送視窗P1移到32, 並從32開始發位元組。)

(3)假定32和33位元組B都已經收到了, 那麼再把A的放鬆視窗往前推(即P1(34位置)), 然後再把P3往後推,P2保持不動,視窗值仍為20



(4)現在繼續傳34-41,在B接收方看來. 31-41的位元組, 剩下37,38,40沒有收到, 所以B就傳送36的確認分組給A。A重傳37-41(就是重複(2)的操作). 即如果A收到B的確認號落在A的傳送視窗內, 那麼A就使傳送視窗向前移動, 併發送新資料.



(5)直到發完全部位元組(即P2和P3指標重合), 這樣就全部發送完成了.



(6)TCP通常對不按序到達的資料先臨時存放在接收視窗中, 等到缺失的位元組補回來, 再上交給應用層. 

8.1. 超時重傳時間選擇

 TCP採用自適應的演算法,  對報文的往返時間(RTT) 進行加權平均, 得出平滑的往返時間, 並且, 對於報文重傳的情況: 這一次就不採用加權平均, 而是直接將重傳時間增大兩倍. 直到分組不重傳. 

8.2. 選擇確認SACK

(1)在8.滑動視窗中的(6)中, 我們提到: 可以將不按序的資料先存放在接收臨時視窗先, 等連續了再交付

(2)那麼我們怎樣才能讓傳送方知道那些序號是缺失了呢. 

(3)我們使用選擇確認來實現. 利用兩個指標來描述出缺失序號的起始位置和終點位置, 並將在即將返回的確認分組中新增這兩個指標的資訊.

(4)這樣下一次傳送方傳送的就是這個缺失序號段的內容了.

9.流量控制

http://blog.csdn.net/sicofield/article/details/9708311

10.擁塞控制

http://blog.csdn.net/sicofield/article/details/9708383

11.TCP的運輸連線管理(三次握手)

(1)建立連線:三次握手
1. 首先, B的TCP伺服器建立 傳輸控制塊(TCB),準備接受請求, 然後B處於監聽狀態.

2. A的TCP客戶端也建立傳輸控制塊TCB, 並向B發出請求報文段, 這裡SYN必須為一喇, 肯定的. 然後初始序號SEQ就給一個X把. 

3. B收到請求後, 確認同意連線, 所以呢ACK也必須為1拉, SYN也為1, 確認號ack=x+1, 並且自己初始事序號SEQ=Y.

4. A客戶端收到B的確認後, 還要給B 一個確認收到確認的報文. ACK也肯定為1, 確認號為ack=Y+1, 然後這屬於A的第二個報文, 所5. 以SEQ=X+1;

5. 就這樣, TCP連線就建立了. 

(2)為什麼要最後確認B的確認報文,? 當B沒有收到A的請求而致使A重傳請求報文, 當重傳的請求生效並且完成到釋放連線的部分時, B收到了A第一個請求的報文, B就誤以為A又要請求連線,並確認連線, 產生新的連線. (這個情況叫 "防止已經失效的連線請求突然接收方又收到了").

12.TCP的運輸連線管理(四次握手)

(1)釋放連線: 四次揮手
1. A想要關閉連線, 就傳送報文. 首先FIN=1 必須的, 給個初始序號給他把 SEQ=U(這個U等於前一個報文的最後一個位元組+1).

2. 這時A進入等待結束狀態, B 收到釋放連線的報文後, 肯定給予確認嘛, 所以ACK=1,ack=U+1, 也給一個B的初始序號給它, SEQ=V.

3. 這時, TCP 處於半關閉狀態, 因為是A提出關閉的, 所以A就沒有資料傳給B , 但是如果B有資料傳給A , A一定要接收. 

4. A收到B的確認報文, 整個TCP處於半關閉狀態後, 就剩下最後一步, 等待B也傳送 釋放連線的請求.(相當於把半關閉狀態提升為全關閉狀態)

5. B傳送釋放連結報文. FIN=1, ACK=1, ack=u+1(相當於還是回覆A的u報文嘛), 重新給個初始序號給它SEQ=W. 

6. 當A收到B的請求釋放連線報文後, A也要做出迴應的嘛, 所以ACK=1, ack=w+1(回覆B的請求),SEQ=U+1. 發了之後, 進入"時間等待" 狀態.  經過時間等待計時器設定的2MSL後, 才算是完全釋放了TCP連線.

7. 除了時間等待計時器, 還有一個保活計時器, 如果客戶端突然出現故障, 為了不讓伺服器端白白等下去呢, 就設計這個計時器,: 一段時間之後，傳送一個探測報文段, 若連續發10個都沒有迴應, 就自動斷開連線把.