運輸層

爲了對的起大家百兆寬帶，所有的筆記都已經上傳至
【碼雲】，歡迎大家star或者fork
點個【star】在走

本節重點

運輸層爲相互交互的通信的應用進程提供邏輯通信
端口和套接字的意義
無連接的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的數據報之上添加了很少的功能。就是複用和分用以及差錯檢錯的功能：

特點：

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

UDP的首部格式

共8個字節

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

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

接受方：
將僞首部和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報文格式也發生這變化，使得傳輸更加的高效，可靠。
例如：窗口擴大選擇確認

可靠傳輸的原理

理想的傳輸條件具備的兩個特點：

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

停止等待協議

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

每次發送完都需要保留一個暫時的副本。只有收到確認分組才能清除
需要對分組和分組確認編號
設定超時計算器
三種情況：
正常，無差錯
出現差錯，繼續重發
確認丟失和確認遲到（會發送重複的包忽略）
上述協議也可以稱爲自動重傳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_D

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

新的RTT_D = (1-β)×（舊的RTT_D）+ β×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運輸連接的建立和選擇時面向連接的通信中必不可少的。因此運輸連接必有三個階段，即：連接建立，數據傳送，連接釋放。運輸連接的管理就是使得運輸連接的建立和釋放都能正常的進行。

TCP連接建立解決的三大問題：

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

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，就可以使得本連接持續的時間產生的所有報文從網絡中消失。可以使得下一次連接中不會出現舊的請求連接報文。

【碼雲】中國人自己的gitHub，不看一看？

運輸層知識點總結

運輸層