傳輸層的主要功能
1)傳輸層爲應用進程之間提供端到端的邏輯通信(網絡層是爲主機到主機提供邏輯通信)。
2)複用和分用: 複用是指發送方不同的應用進程都可以使用同一個傳輸層協議傳送數據; 分用是指接收方的傳輸層在剝去報文的首部之後能夠把這些數據正確交付到目的應用進程.
3)傳輸層還會對收到的報文進行差錯檢測(首部和數據部分), 而網絡層只檢查IP數據報的首部, 不檢驗數據部分是否出錯。
4)傳輸層需要有兩種不同的運輸協議:面向連接的傳輸控制協議 TCP (Transmission Control Protocol)和無連接的用戶數據報協議 UDP (User Datagram Protocol);
流量控制與擁塞控制的區別
流量控制往往是指在發送端和接收端之間的點對點通信量的控制. 流量控制所要做的是抑制發送端發送數據的速率, 以便使接收端來得及接收; 而擁塞控制必須確保通信子網能夠傳送待傳送的數據, 是一個全局性的問題, 涉及網絡中所有的主機、路由器以及導致網絡傳輸能力下降的所有因素.
端口
端口就是傳輸層的服務訪問點, 用一個 16位的數字進行標標記。
端口號只具有本地意義,即端口號只是爲了標誌本計算機應用層中的各進程。在因特網中不同計算機的相同端口號是沒有聯繫的。
端口的作用是讓應用層的各種應用進程都能將其數據通過端口向下交付給傳輸層,以及讓傳輸層知道應當將其報文段中的數據向上通過端口交付給應用層的哪個進程。
從這個意義上講,端口是用來標誌應用層的進程;
常用端口號
|
應用程序 |
echo |
ftp |
ssh |
telnet |
smtp |
|
端口號 |
7 |
20,21 |
22 |
23 |
25 |
|
應用程序 |
dns |
dhcp |
tftp |
http |
pop3 |
|
端口號 |
53 |
67, 68 |
69 |
80 |
110 |
TCP VS UDP
1)TCP
TCP是一種面向連接的(一對一),提供可靠交付的和全雙工通信的,基於字節流的端到端傳輸層通信協議。
面向連接: TCP在傳輸數據之前必須先建立連接,數據傳輸結束後要釋放連接。
一對一: 每一條TCP連接只能有2個端點,故TCP不提供廣播或多播服務。
可靠交付: TCP提供可靠交付,通過TCP連接傳輸的數據,無差錯、不丟失、不重複、並且按序到達。
基於字節流: TCP是面向字節流的。雖然應用進程和TCP的交互是一次一個數據塊(大小不等),但TCP把應用程序交下來的數據僅僅看成是一連串的無結構的字節流, 而並不知道所傳輸的字節流的含義。
2)UDP
UDP是一種無連接的,盡最大努力交付的和全雙工通信的,基於報文段的端到端傳輸層通信協議。
無連接: UDP在發送數據之前不需要建立連接
盡最大努力交付: UDP不保證可靠交付,主機不需要維持複雜的連接狀態
面向報文: UDP是面向報文的。UDP對應用層交下來的報文,既不合並,也不拆分,而是保留這些報文的的邊界,即應用層交給UDP多長的報文,UDP就照樣發送,即一次發送一個報文。在接收端,UDP一次交付一個完整的報文, 因此應用程序需要選擇合適的報文大小。
其他:
UDP沒有擁塞控制,網絡出現的擁塞不會使源主機的發送速率降低。
UDP支持一對一、一對多、多對一和多對多的交互通信。
UDP的首部開銷小,只有8個字節,比TCP的20個字節的首部要短。
3)區別
|
TCP |
UDP |
|
面向連接 |
無連接 |
|
傳輸速度慢 |
傳輸速度快 |
|
保證數據有序到達 |
不保證數據有序到達 |
|
保證數據正確性 |
可能丟包 |
|
TCP報文段 |
UDP用戶數據報 |
|
系統資源要求多(需要內核維護髮送/接受緩衝區) |
要求少(不需要內核維護緩衝區, 直接將數據報發送到網絡上, 或直接交付給進程) |
|
適用於對效率要求相對低,但對準確性要求相對高的場景下,或者是有一種連接概念的場景(如HTTP服務) |
適用於對效率要求相對高,對準確性要求相對低的場景(如視頻點播) |
UDP數據報
UDP有兩個字段: 首部字段和數據字段。
首部字段很簡單,只有8個字節,由4個字段組成,每個字段的長度都是兩個字節。
|
源端口號 |
在需要對方回信時選用。不需要時可用全0 |
|
目的端口號 |
這在終點交付報文時必須要使用到 |
|
UDP長度 |
UDP用戶數據報的長度,其最小值是8(僅有首部) |
|
UDP校驗和 |
檢測UDP用戶數據報在傳輸中是否有錯。有錯就丟棄 |
UDP校驗
UDP首部中校驗和的計算方法有些特殊。在計算校驗和時,要在UDP用戶數據報之前增加12個字節的僞首部。僞首部既不向下傳送也不向上遞交,而僅僅是爲了計算校驗和。與IP數據報的校驗和只校驗IP數據報的首部不同,UDP的校驗和是把首部和數據部分一起都校驗。
在計算檢驗和時,臨時把“僞首部”和 UDP 用戶數據報連接在一起。僞首部僅僅是爲了計算檢驗和, 示例如下:
在發送方,首先是把全零放入校驗和字段並且添加僞首部。然後,把UDP數據報看成是由許多16位的字串連接起來。若UDP數據報的數據部分不是偶數個字節,則要在數據部分末尾增加一個全零字節(但此字節不發送)。接下來就按二進制反碼計算出這些16位字的和。將此和的二進制反碼寫入校驗和字段。在接收方,把收到的UDP數據報加上僞首部(如果不爲偶數個字節,還需要補上全零字節)後,按二進制反碼計算出這些16位字的和。當無差錯時其結果應全爲1。否則就表明有差錯出現,接收方就應該丟棄這個UDP數據報。
TCP報文段
|
協議描述 |
|
|
源端口/目的端口 |
源/目的主機的IP地址加上端口號構成一個TCP連接(Socket) |
|
序號和確認號 |
序號爲該TCP數據包的第一個字節在所發送的數據流中的偏移量;確認號爲希望接收的下一個數據字節的序號; |
|
數據偏移(首部長度) |
以4個字節爲單位,通常爲20個字節 |
|
6個標誌位: |
|
|
URG |
如果使用了緊急指針,URG置1,緊急指針爲當前序號到緊急數據位置的偏移量(常用於發送/接受帶外數據) |
|
ACK |
爲1表示確認號有效,爲0表示該TCP數據包不包含確認信息 |
|
PSH |
表示是帶有PUSH標誌的數據,接收到數據後不必等緩衝區滿再發送(較少使用) |
|
RST |
置爲1時表示TCP連接中出現了嚴重的差錯, 必須釋放連接, 然後重建連接, 也可用於拒絕非法的數據或拒絕連接請求 |
|
SYN |
用於建立連接,連接請求時SYN＝1,ACK=0;響應連接請求時SYN=1,ACK=1 |
|
FIN |
用於釋放連接,表示發送方已經沒有供發送的數據 |
|
窗口大小 |
用來讓對方設置發送窗口的大小(用於流量控制) |
|
校驗和 |
校驗和覆蓋了整個數據包,包括對數據包的首部和數據 |
|
緊急指針 |
指出本報文段中緊急指針共佔用多少個字節(緊急數據放在本報文段數據的最前面) |
|
選項 |
常見的選項是MSS(Maximum Segment Size, 最大報文長度) |
|
填充字段 |
爲了使整個首部爲4字節整數倍 |
TCP三次握手
爲什麼需要採用三次握手?
主要是爲了防止兩次握手情況下已失效的連接請求報文段突然又傳送到服務端,而產生的錯誤。舉例如下:
客戶A向服務器B發出TCP連接請求,第一個連接請求報文在網絡的某個節點長時間滯留,A超時後認爲報文丟失,於是再重傳一次連接請求,B收到後建立連接。數據傳輸完畢後雙方斷開連接。而此時,前一個滯留在網絡中的連接請求到達了服務端B,而B認爲A又發來連接請求,若採用的是“兩次握手”,則這種情況下B認爲傳輸連接已經建立,並一直等待A傳輸數據,而A此時並無連接請求,因此不予理睬,這樣就造成了B的資源白白浪費了;但此時若是使用“三次握手”,則B向A返回確認報文段,由於是一個失效的請求,因此A不予理睬,建立連接失敗。第三次握手的作用:防止已失效的連接請求報文段突然又傳送到了服務器。
三次握手過程
1)第一次握手:客戶機的TCP首先向服務器的TCP發送一個連接請求報文段。這個特殊的報文段中不含應用層數據,其首部中的SYN標誌位被置爲1。另外,客戶機會隨機選擇一個起始序號seq=x(連接請求報文不攜帶數據,但要消耗掉一個序號)。
2)第二次握手:服務器的TCP收到連接請求報文段後,如同意建立連接,就向客戶機發回確認,並在OS內核中爲該TCP連接分配TCP緩存和變量。在確認報文段中,SYN和ACK位都被置爲1,確認號字段的值爲x+1(表示希望收到的下一個字節的序號爲x+1),並且服務器隨機產生起始序號seq=y(確認報文不攜帶數據,但也要消耗掉一個序號)。
3)第三次握手:當客戶機收到確認報文段後,還要向服務器給出確認,並且也要在client端的OS內核中給該連接分配緩存和變量。這個報文段的ACK標誌位被置1,序號字段爲x+1,確認號字段爲y+1。
需要注意的是:服務器端的資源是在完成第二次握手時分配的,而客戶端的資源是在完成第三次握手時分配的。這就使得服務器易於受到SYN洪泛攻擊。
TCP四次斷開
1)第一次斷開:客戶機打算關閉連接,就向其TCP發送一個連接釋放報文段,並停止發送數據,主動關閉TCP連接,該報文段的FIN標誌位被置1,seq=u,它等於前面已傳送過的數據的最後一個字節的序號加1(FIN報文段即使不攜帶數據,也要消耗掉一個序號)。
2)第二次斷開:服務器收到連接釋放報文段後即發出確認,確認號是ack=u+1,而這個報文段自己的序號是v,等於它前面已傳送過的數據的最後一個字節的序號加1。此時,從客戶機到服務器這個方向的連接就釋放了,TCP連接處於半關閉狀態。但服務器若發送數據,客戶機仍要接收,即從服務器到客戶機這個方向的連接並未關閉。
3)第三次斷開:若服務器已經沒有要向客戶機發送的數據,就通知TCP釋放連接,此時其發出FIN=1的連接釋放報文段(注意: 此時確認號字段值仍爲u+1, 因爲這段時間裏, 客戶端並未發送任何數據到服務器)。
4)第四次斷開:客戶機收到連接釋放報文段後,必須發出確認。在確認報文段中,ACK字段被置爲1,確認號ack=w+1,序號seq=u+1。此時TCP連接還沒有釋放掉,必須經過時間等待計時器設置的時間2MSL後,A才進入到連接關閉狀態。
TIME_WAIT狀態
1)爲了保證客戶端發送的最後一個ACK報文段能夠達到服務器。 這個ACK報文段可能丟失,因而使處在LAST_ACK狀態的服務器收不到確認。這樣的話, 服務器會超時重傳FIN+ACK報文段,客戶端就能在2MSL時間內收到這個重傳的FIN+ACK報文段,接着客戶端重傳一次確認,重啓計時器。最後,客戶端和服務器都正常進入到CLOSED狀態。
如果客戶端在TIME_WAIT狀態不等待一段時間,而是在發送完ACK報文後立即釋放連接,那麼就無法收到服務器重傳的FIN+ACK報文段,因而也不會再發送一次確認報文。這樣,服務器就無法按照正常步驟進入CLOSED狀態。
2)防止已失效的連接請求報文段出現在本連接中。客戶端在發送完最後一個ACK確認報文段後,再經過時間2MSL,就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。這樣就可以使下一個新的連接中不會出現這種舊的連接請求報文段。
注意:服務器結束TCP連接的時間要比客戶端早一些,因爲客戶機(最先提出close請求的一端)最後要等待2MSL後纔可以進入CLOSED狀態。
TCP如何保證可靠性
序號: TCP連接中傳送的數據流中的每一個字節都編上一個序號。序號字段的值則指的是本報文段所發送的數據的第一個字節的序號;
確認: TCP首部的確認號是期望收到對方的下一個報文段數據的第一個字節的序號。當數據發送出去之後, 發送方緩存區會繼續存儲那些已經發送但未收到確認的報文段,以便在需要的時候重傳。TCP默認使用累計確認,即TCP只確認數據流中至第一個丟失字節爲止的字節。
重傳: 有兩種事件會導致TCP對報文段進行重傳:超時和冗餘ACK。
1)超時: TCP每發送一個報文段,就對這個報文段設置一次計時器。只要計時器設置的重傳時間到期但還沒有收到確認,就要重傳這一報文段。
2)冗餘ACK(冗餘確認): 冗餘ACK就是再次確認某個報文段的ACK,而發送方先前已經收到過該報文段的確認; TCP規定當發送方收到對同一個報文段的3個冗餘ACK時,就可以認爲跟在這個被確認報文段之後的報文段已經丟失;
校驗: TCP將保持它首部和數據的校驗和。這是一個端到端的校驗和,目的是檢測數據在傳輸過程中的任何變化。如果收到段的校驗和有差錯,TCP將丟棄這個報文段並且不確認(導致對方超時重傳);
重排: TCP承載於IP數據報來傳輸,而IP數據報的到達可能會失序,因此TCP報文段的到達也可能會失序。TCP將對收到的數據進行重新排序。IP數據報會發生重複,TCP的接收端會丟棄重複的數據。
流量控制: TCP還能提供流量控制。TCP連接的每一方都有一定大小的緩衝空間。
分割: 應用數據被分割成TCP認爲最適合發送的數據塊,稱爲TCP報文段傳遞給IP層。
滑動窗口協議與停止等待協議的區別
滑動窗口協議中,允許發送方發送多個分組(當有多個分組可用時), 而不需等待確認,但它受限於在流水線中未確認的分組數不能超過某個最大允許數N。
滑動窗口協議是TCP使用的一種控制流量的方法,此協議能夠加速數據的傳輸。 只有在接收窗口向前滑動時(與此同時也發送了確認), 發送窗口才有可能向前滑動。收發兩端的窗口按照以上規律不斷地向前滑動,因此這種協議稱爲滑動窗口協議。
當發送窗口和接收窗口的大小都等於1時,就是停止等待協議。
TCP流量控制
TCP提供了流量控制服務以消除發送方使接收方緩存區溢出的可能性,因此可以說流量控制是一個速度匹配服務(匹配發送方的發送速率與接收方的讀取速率)。
在通信過程中,接收方根據自己接收緩存的大小,動態地調整發送方的發送窗口大小,這就是接收窗口rwnd,即調整TCP報文段首部中的“窗口”字段值,來限制發送方向網絡注入報文的速率。同時,發送方根據其對當前網絡擁塞程序的估計而確定的窗口值,稱爲擁塞窗口cwnd,其大小與網絡的帶寬和時延密切相關。
滑動窗口
TCP 採用大小可變的滑動窗口進行流量控制(窗口大小的單位是字節), 在 TCP 報文段首部的窗口字段寫入的數值就是當前給對方設置的發送窗口數值的上限。
發送窗口在連接建立時由雙方商定。但在通信的過程中,接收端可根據自己的資源情況,隨時動態地調整對方的發送窗口上限值(可增大或減小)。
發送過程及詳細分析
1)發送端要發送 900 字節長的數據,劃分爲 9 個 100 字節長的報文段,而發送窗口確定爲 500 字節。 發送端只要收到了對方的確認,發送窗口就可前移。發送 TCP 要維護一個指針。每發送一個報文段,指針就向前移動一個報文段的距離。
2)發送端已發送了 400 字節的數據,但只收到對前 200 字節數據的確認,同時窗口大小不變。現在發送端還可發送 300 字節(401~700)。
3)發送端收到了對方對前 400 字節數據的確認,但對方通知發送端必須把窗口減小到 400 字節。現在發送端最多還可發送 400 字節(401~800)的數據。
利用可變窗口大小進行流量控制(雙方確定的窗口值是 400)
(101~200的數據發生丟失)
慢開始和擁塞避免
1. 發送端的主機在確定發送報文段的速率時,既要根據接收端的接收能力,又要從全局考慮不要使網絡發生擁塞。因此,每一個 TCP 連接需要有以下兩個狀態變量:
接收窗口 rwnd (receiver window): 這是接收端根據其目前的接收緩存大小所許諾的最新的窗口值,是來自接收端的流量控制。接收端將此窗口值放在 TCP 報文的首部中的窗口字段,傳送給發送端。
擁塞窗口 cwnd (congestion window): 是發送端根據自己估計的網絡擁塞程度而設置的窗口值,是來自發送端的流量控制。
發送端的發送窗口的上限值應當取爲接收端窗口 rwnd 和擁塞窗口 cwnd 這兩個變量中較小的一個,即應按以下公式確定:
發送窗口的上限值 = Min(rwnd, cwnd)
2. 慢開始算法
在TCP剛剛連接好,開始發送TCP報文段時,先令擁塞窗口cwnd=1,即一個最大報文段長度MSS。而在每收到一個對新的報文段的確認後,將cwnd加1,即增大一個MSS。用這樣的方法逐步增大發送方的擁塞窗口cwnd,可以使分組注入到網絡的速率更加合理。
使用慢開始算法後,每經過一個傳輸輪次(即往返時延RTT),擁塞窗口cwnd就會加倍,即cwnd的大小呈指數形式增長(可以看出”慢開始”並不”慢”)。這樣慢開始一直把擁塞窗口cwnd增大到一個規定的慢開始門限ssthresh(閾值),然後改用擁塞避免算法。
3. 擁塞避免算法
發送端的擁塞窗口cwnd每經過一個往返時延RTT就增加一個MSS的大小,而不是加倍(不同於慢開始算法),使cwnd按線性規律緩慢增長(即加法增大),而當出現一次超時(網絡擁塞)時,則令慢開始門限ssthresh等於當前cwnd的一半(即乘法減小)。
根據cwnd的大小執行不同的算法,可歸納如下:
當cwnd<ssthresh時,使用慢開始算法。
當cwnd>ssthresh時,停止使用慢開始算法而改用擁塞避免算法。
當cwnd=ssthresh時,既可使用慢開始算法,也可使用擁塞避免算法(通常做法)。
4.網絡擁塞的處理
當網絡出現擁塞時,無論在慢開始階段還是在擁塞避免階段,只要發送方檢測到超時事件的發生(沒有按時收到確認,重傳計時器超時),就要把慢開始門限ssthresh設置爲出現擁塞時的發送方cwnd值的一半(但不能小於2)。然後把擁塞窗口cwnd重新設置爲1,執行慢開始算法。這樣做的目的就是要迅速減少主機發送到網絡中的分組數,使得發生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。
擁塞避免並非完全能避免擁塞。利用以上措施要完全避免網絡擁塞是不可能的。擁塞避免是指在擁塞避免階段把擁塞窗口控制爲按線性規律增長,使網絡比較不容易出現擁塞。
慢開始和擁塞避免算法的實現過程如下圖所示:
注意,在慢開始(指數級增長)階段,若2*cwnd＞ssthresh,則下一個RTT的cwnd應等於ssthresh,而不是2*cwnd,即cwnd不能躍過ssthresh值。
小結:
在慢開始和擁塞避免算法中使用了“乘法減小”和“加法增大”方法。“乘法減小”是指不論在慢開始階段還是擁塞避免階段,只要出現一次超時(即很可能出現了網絡擁塞),就把慢開始門限值ssthresh設置爲當前的擁塞窗口值的一半。當網絡頻繁出現擁塞時,ssthresh值就下降得很快,以大大減少注入到網絡中的分組數。而“加法增大”是指執行擁塞避免算法後,在收到對所有報文段的確認後(即經過一個RTT),就把擁塞窗口cwnd增加一個MSS大小,使擁塞窗口緩慢增大,以防止網絡過早出現擁塞。
快重傳與快恢復
快重傳和快恢復算法是對慢開始和擁塞避免算法的改進。
1.快重傳
當發送方連續收到三個重複的ACK報文時,直接重傳對方尚未收到的報文段,而不必等待那個報文段設置的重傳計時器超時。
2.快恢復
快恢復算法原理:當發送端收到連續三個冗餘ACK(即重複確認)時,就執行“乘法減小”算法,把慢開始門限ssthresh減半。與慢開始(慢開始算法將擁塞窗口cwnd設置爲1)不同之處是它把cwnd的值設置爲慢開始門限ssthresh減半後的數值,然後開始執行擁塞避免算法(“加法增大”),使擁塞窗口緩慢地線性增大。
由於跳過了cwnd從1起始的慢開始過程(因爲既然現在能夠收到三個重複ACK確認, 就說明擁塞程序並不是很大),所以被稱爲快恢復。快恢復算法的實現過程如下圖所示,作爲對比,虛線爲慢開始的處理過程。
注-發送方發送窗口的實際大小由流量控制和擁塞控制共同決定。因此,當同時出現了接收端窗口(rwnd)和擁塞窗口(cwnd)時,發送方實際的發送窗口大小是由rwnd和cwnd中較小的那一個確定的。