運輸層 ,跑腿的祕書

~小黑發表於2020-05-21

運輸層

本節重點

  • 運輸層為相互互動的通訊的應用程式提供邏輯通訊
  • 埠和套接字的意義
  • 無連線的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 建議的計算值： 當一次計算時，RTTD 的取值為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 連線建立採用的時客服伺服器模式，主動發起建立請求的應用程式叫做客戶，被動等待建立連線的時應用程式叫做伺服器 　　
  1. 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，就可以使得本連線持續的時間產生的所有報文從網路中消失。可以使得下一次連線中不會出現舊的請求連線報文。

相關文章