運輸層 ,跑腿的祕書

運輸層

本節重點

• 運輸層爲相互交互的通訊的應用進程提供邏輯通訊
• 端口和套接字的意義
• 無鏈接的UDP含義
• 面向鏈接的TCP特色
• 在不可靠的網絡上實現可靠傳輸的工做原理，中止等待協議和ARQ協議
  

注 運輸層最近又添加了第三種協議 ，STCP（Stream Cntrol Transmission Protocol) [建議標準] 它具備TCP和UDP的協議的共同優勢

運輸層協議概述

進程間的通訊

運輸層向他上面的應用層提供通訊。
當網絡邊緣的主機使用網絡的核心功能進行端對端通訊時，只有主機的協議棧纔有運輸層，核心部分通常都只有三層結構 。
通訊的真正端點時主機和主機之間的進程
邏輯通訊 ： 從應用層來看，只要把應用層報文交給下面的運輸層，運輸層就能夠把報文傳輸給對方的物理層。
運輸層還要對收到的報文進行檢錯。前面的網絡層， 只是對應的數據報的首部的檢測。
網絡層爲主機之間提供邏輯通訊，而運輸層爲應用進程之間提供端到端的邏輯通訊

運輸層的兩個協議

TCP/IP運輸層的兩個協議都是互聯網的正式標準即：

• 用戶數據協議UDP（User Datagram Protocol）
• 傳輸控制協議TCP（Transmission Control Protocol）
  按照OSI的術語： 兩個對等的運輸實體在通訊傳輸時的數據單元叫作運輸數據控制單元 TPDU（Transport Protocol Data Unit 。 在TCP和UDP分別稱之爲TCP報文段（segment和 UDP用戶數據報
  使用UDP和TCP 協議的各類應用和應用棧協議

應用	應用層協議	運輸層協議
域名轉換	DNS（域名）系統	UDP
文件傳輸	TFTP（簡單文件傳輸）	UDP
路由選擇協議	DHCP（動態主機配置）	UDP
網絡管理	SNMP（簡單網絡管理協議）	UDP
遠程文件服務器	NFS（網絡文件系統）	UDP
IP電話	專用協議	UDP
流式多媒體通訊	專用協議	UDP
多播	IGMP（網絡組管理協議)	UDP
電子郵件	SMTP（簡單郵件傳輸協議）	TCP
遠程終端接入	TELNET（遠程終端協議）	TCP
萬維網	HTTP（超文本傳輸協議）	TCP
文件傳送	FTP（文件傳送協議）	TCP

TCP和UDP使用一個16位的端口號來標示一個端口號。端口號只有本地意義，就是爲了表示計算機應用層中的個進程在 和運輸層在交互時的接口。 16位的端口號容許65535個不一樣的端口號。

• 服務器使用的端口號 ,或者比較熟知的端口號(Well-known port number)或者系統端口號 ：

經常使用的熟知的端口號

應用程序	FTP	TELNET	SMTP	DNS	TFTP	HTTP	SNMP	SNMP（trao）	HTTPS
熟知的端口號	21	23	25	53	69	80	161	162	443

另外一類叫作登記端口號，數值爲1024-49151 。 這類端口時爲沒有熟知端口號的應用程序的使用， 使用這類端口號必須在IANA按照規定的手續登記，以防止重複

• 客戶端使用的端口號 熟知爲49152-65535 短暫端口號

用戶數據包協議UDP

UDP只在IP的數據報之上添加了不多的功能。就是複用和分用以及 差錯檢錯的功能 ：

1. 特色：

• UDP是無鏈接的
• 盡最大努力交互
• UDP時面向報文的 對應用層傳過來的數據添加UDP首部後就直接的交付給下層IP協議
• UDP沒有阻塞控制
• UDP支持一對一，一對多和多對多的相互通訊
• UDP的首部開銷少

UDP的首部格式

共8個字節

• 源端口 須要對對方回信時選用 。不須要爲能夠全爲0
  當運輸層收到UDP數據報，就是根據首部中的目標地址，把UDP數據報經過相應的端口，上交給最後的終點---應用進程
  圖中僞首部，主要時爲了計算檢驗和，臨時添加到UDP用戶數據報以前。
• 數據檢驗的方式：首部和數據部分一塊兒檢驗
  

1. 用0填充首部檢驗和字段
2. 取偶數個字節進行加法運算 （奇數，補零 ，運算，實際的數據中沒有）
3. 結果求反碼放入到首部檢驗和字段

• 接受方：
  將僞首部和UDP數據報進行求和，結果全爲 1 ，無錯，不然丟棄。

傳輸層控制協議TCP

TCP協議的主要特色 ：

• TCP時面向連接的運輸層協議
• 每一條TCP連接只能有兩個端點。TCP連接只能時點對點
• TCP提供可靠交付服務
• TCP提供雙全共服務
• 面向字節流
  TCP把連接做爲最基本的抽象，TCP的許多特性都與TCP是面向連接的這個基本屬性有關。 TCP的兩個端點叫套接字或接口 。
  [RPC 793]定義： 端口號拼接到（Connection with）IP地址即構成了套機字。

套接字socket = （IP地址：端口號）

每條TCP連接惟一地被通信兩個端點（即套接字） 所肯定。即：

TCP連接：：={socket1，socket2}= {（IP，端口號），（IP2,端口號）｝

TCP報文段的首部格式

其中個別字段解釋：

• 序號： 在TCP連接中傳輸的字節流中的每一個字節都是按順序編號的。字節的起始信號在創建連接時候確認。

• 確認號 ： 指望收到下一個報文段的第一個字節的序列

• 數據偏移 ： 數據離起始TCP報文段起始處有多遠

• 緊急URG（URgent） ： 優先處理 ，配合緊急指針使用

• 推送PSH（PuSH）：不緩衝當即發送

• 復位RST（ReSeT） ： 代表TCP連接出現嚴重的差錯，必須釋放鏈接，而後從新創建 。

• SYN標誌，表示請求創建一個鏈接。咱們稱攜帶SYN標誌的TCP報文段爲同步報文段。

• FIN標誌，表示通知對方本端要關閉鏈接了。咱們稱攜帶FIN標誌的TCP報文段爲結束報文段。

• 16位窗口大小（window size）：是TCP流量控制的一個手段。這裏說的窗口，指的是接收通告窗口（Receiver Window，RWND）。它告訴對方本端的TCP接收緩衝區還能容納多少字節的數據，這樣對方就能夠控制發送數據的速度。

• 16位校驗和（TCP check sum）：由發送端填充，接收端對TCP報文段執行CRC算法以檢驗TCP報文段在傳輸過程當中是否損壞。注意，這個校驗不只包括TCP頭部，也包括數據部分。這也是TCP可靠傳輸的一個重要保障。

• 16位緊急指針（urgent pointer）：是一個正的偏移量。它和序號字段的值相加表示最後一個緊急數據的下一字節的序號。所以，確切地說，這個字段是緊急指針相對當前序號的偏移，不妨稱之爲緊急偏移。TCP的緊急指針是發送端向接收端發送緊急數據的方法

• TCP頭部選項：TCP頭部的最後一個選項字段（options）是可變長的可選信息。這部分最多包含40字節，由於TCP頭部最長是60字節（其中還包含前面討論的20字節的固定部分
  隨着發展TCP報文格式也發生這變化，使得傳輸更加的高效，可靠。
  例如： 窗口擴大 選擇確認

可靠傳輸的原理

• 理想的傳輸條件具有的兩個特色：　　　

1. 傳輸信道不產生差錯
2. 無論發送方以 多塊的速度發送數據，接受方老是來得及處理接受到的消息　　

中止等待協議

就是每發送一個分組就中止發送，等待對方確認。收到確認後在發送下一個分組。　

• 每次發送完都須要保留一個暫時的副本。只有收到確認分組才能清除
• 須要對分組和分組確認編號
• 設定超時計算器
  三種狀況：
• 正常，無差錯
• 出現差錯 ，繼續重發
• 確認丟失和確認遲到 （會發送重複的包忽略）
  上述協議也能夠稱爲自動重傳ARQ（Automatic Repeat reQuest)。意思時： 重傳的請求時自動進行的，接受方不須要請求發送方重傳某個出錯請求
• 改進的思路： 使用流水線一次發送多個分組，在請求確認。

連續的ARQ協議

位於滑動窗口內的5個分組均可以連續的發送出去，而不需等待確認。 發送每收到一個確認就把窗口向前滑動一個分組的單位。接受方沒必要對收到的數據逐個發送確認，而是在收到幾個分組紅顏，對按序到達的最後一個分組發送確認。 出現差錯時，使用Go-back-N（回退N。

TCP實現可靠傳輸的特色

一樣TCP使用的滑動窗口實現的，可是若是存在確認丟失，那麼也是採用超時重傳的方法來肯定。 可是超時時間設置也是比較的複雜 ，採用自適應算法

超時重傳時間的選擇

TCP採用的是一種自適應算法，它是記錄一個報文發出的時間，以及收到相應的確認時間 。這兩時間之差就是報文的往返時間RTT TCP保留了一個加權平均往返時間RTTs，這又稱爲平滑的往返時間。 當第一次測量到RTT樣本時，RTTs值就爲RTT樣本的值，之後沒采測到一次，就按照下面的公式計算一次：

新的RTTs=（1-α）× （舊的RTTs) + α× （新的RTT樣本）

標準建議設置爲：0.125

• 上面時RTT的計算方法，下面給出超時重傳時間RTO（Retransminssion Time-OUT） 應略大於上面得出的加權平均時間RTTs。
  標準建議 :

RTO  =  RTTs + 4* RTT<sub>D</sub>

RTTD 建議的計算值： 當一次計算時，RTT_D 的取值爲RTT樣本值的一半 ，之後的計算方法

新的RTT<sub>D</sub>  =  (1-β)×（舊的RTT<sub>D</sub>）+ β×ABS（RTTs-新的RTT樣本）

β的推薦值0.25
但時這種算法有缺陷。重傳後，收到前面的一個確認報文，沒法肯定時那個分組的RTT。
如果前一個，則RTTS和_D增大， 如果後一個減小。

• 解決上述問題：Karn提出思路： 發送重傳時不計算. 映入了一個新的問題： 假設重傳時延變得很是大，不計算重傳，就沒法從新計算RTO的時間
• 在爲了解決上述的問題，將RTO的時間肯定的大一點，重傳的時間直接計算爲原來的2倍。

選擇確認 SACK

若收到的報文無差錯 ， 只是序號序號未按照序號，中間的缺乏一些數據，沒必要重傳，只須要傳輸缺乏的數據

TCP流量控制

所謂的流量控制（flow contro）就是讓發送方發送速率不要太快，要讓接受方來的及接受
假設問題：Ｂ發送rwnd= 0，Ａ接受到後不在發送數據，可是一段時間後，Ｂ的rwnd = 400，可是在發送rwnd=400的報文段丟失了。那麼Ａ就一直等待Ｂ發送︿（￣︶￣）︿非零窗口的報文段，Ｂ也在等待Ａ的數據報陷入相互死鎖的問題　。　
解決辦法：使用一個持續的計時器，時間一到就發送一個零窗口的探測報文段。　　

• TCP的傳輸效率　　
  當應用進程吧數據傳送到TCP後，TCP就緩衝起來了，剩下的發送任務就由TCP來來控制了 。TCP提供了不一樣的機制來控制TCP報文段的發送時機
• TCP 維持一個變量MSS 。只有緩衝到達MSS，就啓動發送
• 發送方應用指明瞭TCP支持的push操做，直接發送
• 維持一個計時器，時間到就發送
  在TCP實現中使用的是Nagle算法 ： 先發送一個字節，而後等待確認，而後後面到達的數據緩衝，再把緩衝中的全部數據組裝成一個數據段在發送出去。
  只有接受到前一個數據段的確認在發送下一個。
• 糊塗窗口綜合徵（silly window syndrome）: 接受方的緩衝處理太慢，而發送方接受到確認後，繼續發送，部分數據丟失，一樣是的效率減低 。解決方法：① 接收方等待一段時間後 ② 等待接收緩衝區有一半空閒的空間。 在發送確認數據段，並通知當前窗口的大小。

TCP的擁塞控制

網絡中某一資源超過了網絡性能就會變壞。
TCP進行擁塞控制的算法一共有四種。
慢開始 擁塞避免 快重傳 快恢復

• 慢開始：開始cwnd爲1 ， 經過輪次（上一輪的數據報都發送完）的方法，利用乘法來擴大擁塞窗口 ，且不能超過1到2個發送方的SMSS的最大報文段 （新的標準3-4個大小）
  SMSS 在SYN中協商，默認時536字節。
  實際中，發送方只要接受到對新報文的確認就當即對cwnd窗口值加1，不須要等待上一輪次所有傳送完畢。
  爲了防止cwnd太大，須要設置慢開始門限。 當cwnd>門限值，使用擁塞避免算法
• 擁塞避免 就是加法運算，每次對cwnd增1，當出現超時，設置門限值爲cwnd/2 ，同時設置 cwnd爲1，開始慢算法。
• 快算法解決報文丟失，再次引發慢算法的問題。若發生丟失報文段，則接受方連續的發送前一個數據段的 重複確認3次，累計4次 ，發送方就知道了的確沒有收到丟失的報文，於是噹噹即重傳，而不是網絡擁堵。 啓動快速恢復算法。 調整發送方的門限值爲8，同時設置cwnd = 8。
  

TCP的傳輸連接管理

TCP時面向連接的協議，運輸鏈接是用來傳輸TCP報文的。TCP運輸鏈接的創建和選擇時面向鏈接的通訊中必不可少的。 所以運輸鏈接必有三個階段，即： 鏈接創建，數據傳送，鏈接釋放。 運輸鏈接的管理就是使得運輸鏈接的創建和釋放都能正常的進行。

1. TCP鏈接創建解決的三大問題：

• TCP 的每一方都要可以感知對方的存在　
• 要容許雙方協議一些參數
• 可以對運輸實體資源（緩存的大小，鏈接表中的項目）進行分配。　
  TCP 鏈接創建採用的時客服服務器模式，主動發起創建請求的應用進程叫作客戶，被動等待創建鏈接的時應用進程叫作服務器 　　

2. TCP的鏈接創建　　
   TCP創建鏈接的過程叫作握手(三報文握手), 握手須要在客戶和服務器之間交換三個TCP報文段
   

詳細過程：　

• 假定Ａ運行的時ＴＣＰ客戶端程序，B運行的時服務器段的程序。最初兩端的ＴＣＰ進程都處於CLOSED(關閉狀態).此時Ａ主動的打開鏈接，Ｂ被動打開鏈接　
  Ｂ進程ＴＣＰ服務器先創立傳輸控制塊ＴＣＢ,準備接受客戶端進程的請求鏈接。而後服務器處於　LISTEN(收聽)狀態，等待客戶端的鏈接請求。　
• A的TCP進程首先建立傳輸控制模塊ＴＣＢ， 而後打算創建TCP鏈接，向Ｂ發送鏈接請求報文，這是首部的同步位爲１，同時選擇一個初始化序列SYN=1 ，同時選擇一個初始化序號seq=x （ＴＣＰ規定ＳＹＮ爲１的報文段不能攜帶數據）可是要消耗一個序號。　
  ＴＣＰ客戶端進程進入發ＳＹＮ－ＳＥＮＴ(同步已發送)階段。　
• Ｂ接受帶請求報文後，若是贊成創建，則向Ａ發送確認。在確認報文段中應把ＳＹＮ位和ＡＣＫ爲置一。確認號是ack=x+1。同時也爲本身選擇一個初始化序號seq=ｙ. 一樣這個報文段也不能攜帶數據，可是消耗一個序號。　這是TCP 服務器進程進入到SYN-RCVD（同步收到）狀態。　　
• TCP客戶端收到Ｂ的請求後，還有給Ｂ發出確認請求。確認報文段的ACK置1，確認號ack=y+1,而本身的seq=x+1, 由於SNY=0，因此序號不用增長就是ack=y+1，而seq仍然爲x+1.
• B收到A的請求後，也進入到ESTABLISTEND(已創建)狀態
  爲何最後一次還要發送一次確認？ 主要時爲了防止已經失效的鏈接請求報文段忽然又穿送到了B，產生錯誤。
  失效的鏈接 A發出鏈接請求，但由於請求鏈接報文滯留在網絡。以致於A的鏈接釋放後纔到達了B，B認爲是一個新的請求鏈接，發送確認報文段（若是兩次握手，那麼已經創建鏈接，A不予迴應）浪費資源。

TCP的鏈接釋放。

TCP的鏈接關閉也是比較的複雜的，須要四次握手。

• 在數據傳輸結束後，通訊的雙發均可釋放鏈接。如今A和B都處於ESTABLESHED狀態。A的應用進程先向其TCP發出鏈接釋放報文段，並中止發送數據，主動關閉TCP鏈接。A鏈接釋放報文段的首部終止控制位置1，其序號爲 seq = u ,u爲前面已經傳送的過的數據的最後一個序號加1。這是A進入到 FIN-WAIT-1(中止等待1)狀態。 等待B的確認。 TCP規定FIN報文段即便不攜帶數據，它也消耗一個序號
• B收到鏈接釋放報文段後當即發送確認。確認號時是ack=u+1； 而這個報文段本身的序列號時V。等於B前面已經傳送的數據的最後一個字節加1。而後B進入到CLOSE-WAIT
  （關閉等待）ＴＣＰ的服務端進程這時通知高層應用程序進程，於是從Ａ到Ｂ的這個鏈接就是釋放了，這是ＴＣＰ鏈接處於半關閉狀態，　即Ａ已經沒有要發送的數據了。可是Ｂ若發送數據Ａ仍然接受　。Ｂ到Ａ的鏈接尚未關閉，將會保持一段的時間。　
• A收到的Ｂ的確認，就進入到FIN-WAIT2(中止等待２) 狀態。　等待Ｂ發出的鏈接釋放報文段　
• 若Ｂ已經沒有要向Ａ發送的數據，其應用進程就通知ＴＣＰ釋放鏈接。這時Ｂ發出的釋放鏈接報文必須時ＦＩＮ＝１。　如今假設Ｂ的序號爲ｗ（在Ｂ的半關閉狀態有向Ａ發送了一些數據），Ｂ仍是必須重複上次已經發送過的確認號ack = u+1; 這是Ｂ就進入到了ＬＡＳＴ－ＡＣＫ(最後確認)狀態　，等待Ａ的確認。　
  Ａ在收到B的鏈接釋放報文段後，必須對此發出確認。 在確認報文段中吧ACK置1。確認號ack=w+1。而後進入到TIME-WAIT（時間等待）狀態。如今TCP尚未正在的釋放掉，必須等待時間等地計時器（TIME-AWIT timer）設置的時間2MSL後，A進入到CLOSED狀態。 時間MSL叫作最長報文壽命（Maximum Segment Lifetime)。標準推薦爲2分鐘。 等待4分鐘以後，撤銷相應的傳輸控制塊TCB,就結束了本次鏈接。
• 爲什麼A在TIME-WAIT狀態等待2MSL？兩個理由
  • 保證A發送的最後一個ACK報文可以到達B。若是B沒有收到，A就會超時重傳，從新啓動2MSL計時器，B就能夠在2MSL時間內收到這個FIN+ ACK的確認段。若是沒有2MSL計時器，B若是沒有收到A的確認， B就沒法正常的進入到CLOSED階段。 形成資源的浪費
  • 再次防止，已失效的請求鏈接報文段 A在發送完ACK報文段後，在通過2MSL，就可使得本鏈接持續的時間產生的全部報文從網絡中消失。可使得下一次鏈接中不會出現舊的請求鏈接報文。