[置頂] TCP/IP入門(3) --傳輸層

/**

本篇博客由汗青ZJF整理并發布, 轉載請注明出處:

http://blog.csdn.net/zjf280441589/article/category/1854365

*/

傳輸層的主要功能

    1)傳輸層為利用進程之間提供端到端的邏輯通訊(網絡層是為主機到主機提供邏輯通訊)。

    2)復用和分用: 復用是指發送方不同的利用進程都可使用同1個傳輸層協議傳送數據; 分用是指接收方的傳輸層在剝去報文的首部以后能夠把這些數據正確交付到目的利用進程.

    3)傳輸層還會對收到的報文進行過失檢測(首部和數據部份), 而網絡層只檢查IP數據報的首部, 不檢驗數據部份是不是出錯。

    4)傳輸層需要有兩種不同的運輸協議:面向連接的傳輸控制協議 TCP (Transmission Control Protocol)和無連接的用戶數據報協議 UDP (User Datagram Protocol);

流量控制與堵塞控制的區分

    流量控制常常是指在發送端和接收端之間的點對點通訊量的控制. 流量控制所要做的是抑制發送端發送數據的速率, 以便使接收端來得及接收; 而堵塞控制必須確保通訊子網能夠傳送待傳送的數據, 是1個全局性的問題, 觸及網絡中所有的主機、路由器和致使網絡傳輸能力降落的所有因素.

端口

    端口就是傳輸層的服務訪問點, 用1個 16位的數字進行標標記。

    端口號只具有本地意義,即端口號只是為了標志本計算機利用層中的各進程。在因特網中不同計算機的相同端口號是沒有聯系的。

    端口的作用是讓利用層的各種利用進程都能將其數據通過端口向下交付給傳輸層,和讓傳輸層知道應當將其報文段中的數據向上通過端口交付給利用層的哪一個進程。

    從這個意義上講,端口是用來標志利用層的進程;

經常使用端口號

TCP VS UDP

1)TCP

    TCP是1種面向連接的(1對1),提供可靠交付的和全雙工通訊的,基于字節流的端到端傳輸層通訊協議。

    面向連接: TCP在傳輸數據之前必須先建立連接,數據傳輸結束后要釋放連接。

    1對1: 每條TCP連接只能有2個端點,故TCP不提供廣播或多播服務。

    可靠交付: TCP提供可靠交付,通過TCP連接傳輸的數據,無過失、不丟失、不重復、并且按序到達。

    基于字節流: TCP是面向字節流的。雖然利用進程和TCP的交互是1次1個數據塊(大小不等),但TCP把利用程序交下來的數據僅僅看成是1連串的無結構的字節流, 而其實不知道所傳輸的字節流的含義。

2)UDP

    UDP是1種無連接的,盡最大努力交付的和全雙工通訊的,基于報文段的端到端傳輸層通訊協議。

    無連接: UDP在發送數據之前不需要建立連接

    盡最大努力交付: UDP不保證可靠交付,主機不需要保持復雜的連接狀態

    面向報文: UDP是面向報文的。UDP對利用層交下來的報文,既不合并,也不拆分,而是保存這些報文的的邊界,即利用層交給UDP多長的報文,UDP就照樣發送,即1次發送1個報文。在接收端,UDP1次交付1個完全的報文, 因此利用程序需要選擇適合的報文大小。

其他:

    UDP沒有堵塞控制,網絡出現的堵塞不會使源主機的發送速率下降。

    UDP支持1對1、1對多、多對1和多對多的交互通訊。

    UDP的首部開消小,只有8個字節,比TCP的20個字節的首部要短。

3)區分

UDP數據報

UDP有兩個字段: 首部字段和數據字段。

首部字段很簡單,只有8個字節,由4個字段組成,每一個字段的長度都是兩個字節。

UDP校驗

    UDP首部中校驗和的計算方法有些特殊。在計算校驗和時,要在UDP用戶數據報之前增加12個字節的偽首部。偽首部既不向下傳送也不向上遞交,而僅僅是為了計算校驗和。與IP數據報的校驗和只校驗IP數據報的首部不同,UDP的校驗和是把首部和數據部份1起都校驗。

    在計算檢驗和時,臨時把“偽首部”和 UDP 用戶數據報連接在1起。偽首部僅僅是為了計算檢驗和, 示例以下:

    在發送方,首先是把全零放入校驗和字段并且添加偽首部。然后,把UDP數據報看成是由許多16位的字串聯接起來。若UDP數據報的數據部份不是偶數個字節,則要在數據部份末尾增加1個全零字節(但此字節不發送)。接下來就按2進制反碼計算出這些16位字的和。將此和的2進制反碼寫入校驗和字段。在接收方,把收到的UDP數據報加上偽首部(如果不為偶數個字節,還需要補上全零字節)后,按2進制反碼計算出這些16位字的和。當無過失時其結果應全為1。否則就表明有過失出現,接收方就應當拋棄這個UDP數據報。

TCP報文段

TCP3次握手

為何需要采取3次握手?

    主要是為了避免兩次握手情況下已失效的連接要求報文段突然又傳送到服務端,而產生的毛病。舉例以下:

    客戶A向服務器B發出TCP連接要求,第1個連接要求報文在網絡的某個節點長時間滯留,A超時后認為報文丟失,因而再重傳1次連接要求,B收到后建立連接。數據傳輸終了后雙方斷開連接。而此時,前1個滯留在網絡中的連接要求到達了服務端B,而B認為A又發來連接要求,若采取的是“兩次握手”,則這類情況下B認為傳輸連接已建立,并1直等待A傳輸數據,而A此時并沒有連接要求,因此不予理會,這樣就造成了B的資源白白浪費了;但此時若是使用“3次握手”,則B向A返回確認報文段,由因而1個失效的要求,因此A不予理會,建立連接失敗。第3次握手的作用:避免已失效的連接要求報文段突然又傳送到了服務器。

3次握手進程

    1)第1次握手:客戶機的TCP首先向服務器的TCP發送1個連接要求報文段。這個特殊的報文段中不含利用層數據,其首部中的SYN標志位被置為1。另外,客戶機會隨機選擇1個起始序號seq=x(連接要求報文不攜帶數據,但要消耗掉1個序號)。

    2)第2次握手:服務器的TCP收到連接要求報文段后,猶如意建立連接,就向客戶機發回確認,并在OS內核中為該TCP連接分配TCP緩存和變量。在確認報文段中,SYN和ACK位都被置為1,確認號字段的值為x+1(表示希望收到的下1個字節的序號為x+1),并且服務器隨機產生起始序號seq=y(確認報文不攜帶數據,但也要消耗掉1個序號)。

    3)第3次握手:當客戶機收到確認報文段后,還要向服務器給出確認,并且也要在client真個OS內核中給該連接分配緩存和變量。這個報文段的ACK標志位被置1,序號字段為x+1,確認號字段為y+1。

    需要注意的是:服務器真個資源是在完成第2次握手時分配的,而客戶真個資源是在完成第3次握手時分配的。這就使得服務器易于遭到SYN洪泛攻擊。

TCP4次斷開

    1)第1次斷開:客戶機打算關閉連接,就向其TCP發送1個連接釋放報文段,并停止發送數據,主動關閉TCP連接,該報文段的FIN標志位被置1,seq=u,它等于前面已傳送過的數據的最后1個字節的序號加1(FIN報文段即便不攜帶數據,也要消耗掉1個序號)。

    2)第2次斷開:服務器收到連接釋放報文段后即發出確認,確認號是ack=u+1,而這個報文段自己的序號是v,等于它前面已傳送過的數據的最后1個字節的序號加1。此時,從客戶機到服務器這個方向的連接就釋放了,TCP連接處于半關閉狀態。但服務器若發送數據,客戶機仍要接收,即從服務器到客戶機這個方向的連接并未關閉。

    3)第3次斷開:若服務器已沒有要向客戶機發送的數據,就通知TCP釋放連接,此時其發出FIN=1的連接釋放報文段(注意: 此時確認號字段值仍為u+1, 由于這段時間里, 客戶端并未發送任何數據到服務器)。

    4)第4次斷開:客戶機收到連接釋放報文段后,必須發出確認。在確認報文段中,ACK字段被置為1,確認號ack=w+1,序號seq=u+1。此時TCP連接還沒有釋放掉,必須經過時間等待計時器設置的時間2MSL后,A才進入到連接關閉狀態。

TIME_WAIT狀態

    1)為了保證客戶端發送的最后1個ACK報文段能夠到達服務器。 這個ACK報文段可能丟失,因此使處在LAST_ACK狀態的服務器收不到確認。這樣的話, 服務器會超時重傳FIN+ACK報文段,客戶端就可以在2MSL時間內收到這個重傳的FIN+ACK報文段,接著客戶端重傳1次確認,重啟計時器。最后,客戶端和服務器都正常進入到CLOSED狀態。

    如果客戶端在TIME_WAIT狀態不等待1段時間,而是在發送完ACK報文后立即釋放連接,那末就沒法收到服務器重傳的FIN+ACK報文段,因此也不會再發送1次確認報文。這樣,服務器就沒法依照正常步驟進入CLOSED狀態。

    2)避免已失效的連接要求報文段出現在本連接中。客戶端在發送完最后1個ACK確認報文段后,再經過時間2MSL,就能夠使本連接延續的時間內所產生的所有報文段都從網絡中消失。這樣就能夠使下1個新的連接中不會出現這類舊的連接要求報文段。

    注意:服務器結束TCP連接的時間要比客戶端早1些,由于客戶機(最早提出close要求的1端)最后要等待2MSL后才可以進入CLOSED狀態。

TCP如何保證可靠性

    序號: TCP連接中傳送的數據流中的每個字節都編上1個序號。序號字段的值則指的是本報文段所發送的數據的第1個字節的序號;

    確認: TCP首部的確認號是期望收到對方的下1個報文段數據的第1個字節的序號。當數據發送出去以后, 發送方緩存區會繼續存儲那些已發送但未收到確認的報文段,以便在需要的時候重傳。TCP默許使用累計確認,即TCP只確認數據流中至第1個丟失字節為止的字節。

    重傳: 有兩種事件會致使TCP對報文段進行重傳:超時和冗余ACK。

        1)超時: TCP每發送1個報文段,就對這個報文段設置1次計時器。只要計時器設置的重傳時間到期但還沒有收到確認,就要重傳這1報文段。

        2)冗余ACK(冗余確認): 冗余ACK就是再次確認某個報文段的ACK,而發送方先前已收到過該報文段的確認; TCP規定當發送方收到對同1個報文段的3個冗余ACK時,就能夠認為跟在這個被確認報文段以后的報文段已丟失;

    校驗: TCP將保持它首部和數據的校驗和。這是1個端到真個校驗和,目的是檢測數據在傳輸進程中的任何變化。如果收到段的校驗和有過失,TCP將拋棄這個報文段并且不確認(致使對方超時重傳);

    重排: TCP承載于IP數據報來傳輸,而IP數據報的到達可能會失序,因此TCP報文段的到達也可能會失序。TCP將對收到的數據進行重新排序。IP數據報會產生重復,TCP的接收端會拋棄重復的數據。

    流量控制: TCP還能提供流量控制。TCP連接的每方都有1定大小的緩沖空間。

    分割: 利用數據被分割成TCP認為最合適發送的數據塊,稱為TCP報文段傳遞給IP層。

滑動窗口協議與停止等待協議的區分

    滑動窗口協議中,允許發送方發送多個分組(當有多個分組可用時), 而不需等待確認,但它受限于在流水線中未確認的分組數不能超過某個最大允許數N。

    滑動窗口協議是TCP使用的1種控制流量的方法,此協議能夠加速數據的傳輸。 只有在接收窗口向前滑動時(與此同時也發送了確認), 發送窗口才有可能向前滑動。收發兩真個窗口依照以上規律不斷地向前滑動,因此這類協議稱為滑動窗口協議。

    當發送窗口和接收窗口的大小都等于1時,就是停止等待協議。

TCP流量控制

    TCP提供了流量控制服務以消除發送方使接收方緩存區溢出的可能性,因此可以說流量控制是1個速度匹配服務(匹配發送方的發送速率與接收方的讀取速率)。

    在通訊進程中,接收方根據自己接收緩存的大小,動態地調劑發送方的發送窗口大小,這就是接收窗口rwnd,即調劑TCP報文段首部中的“窗口”字段值,來限制發送方向網絡注入報文的速率。同時,發送方根據其對當前網絡堵塞程序的估計而肯定的窗口值,稱為堵塞窗口cwnd,其大小與網絡的帶寬和時延密切相干。

滑動窗口

    TCP 采取大小可變的滑動窗口進行流量控制(窗口大小的單位是字節), 在 TCP 報文段首部的窗口字段寫入的數值就是當前給對方設置的發送窗口數值的上限。

    發送窗口在連接建立時由雙方約定。但在通訊的進程中,接收端可根據自己的資源情況,隨時動態地調劑對方的發送窗口上限值(可增大或減小)。

發送進程及詳細分析

    1)發送端要發送 900 字節長的數據,劃分為 9 個 100 字節長的報文段,而發送窗口肯定為 500 字節。 發送端只要收到了對方的確認,發送窗口便可前移。發送 TCP 要保護1個指針。每發送1個報文段,指針就向前移動1個報文段的距離。

    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 這兩個變量中較小的1個,即應按以下公式肯定:

        發送窗口的上限值 = Min(rwnd, cwnd)

2. 慢開始算法

    在TCP剛剛連接好,開始發送TCP報文段時,先令堵塞窗口cwnd=1,即1個最大報文段長度MSS。而在每收到1個對新的報文段的確認后,將cwnd加1,即增大1個MSS。用這樣的方法逐漸增大發送方的堵塞窗口cwnd,可使分組注入到網絡的速率更加公道。

    使用慢開始算法后,每經過1個傳輸輪次(即來回時延RTT),堵塞窗口cwnd就會加倍,即cwnd的大小呈指數情勢增長(可以看出”慢開始”其實不”慢”)。這樣慢開始1直把堵塞窗口cwnd增大到1個規定的慢開始門限ssthresh(閾值),然后改用堵塞避免算法。

3. 堵塞避免算法

    發送真個堵塞窗口cwnd每經過1個來回時延RTT就增加1個MSS的大小,而不是加倍(不同于慢開始算法),使cwnd按線性規律緩慢增長(即加法增大),而當出現1次超時(網絡堵塞)時,則令慢開始門限ssthresh等于當前cwnd的1半(即乘法減小)。

根據cwnd的大小履行不同的算法,可歸納以下:

        當cwnd<ssthresh時,使用慢開始算法。

        當cwnd>ssthresh時,停止使用慢開始算法而改用堵塞避免算法。

        當cwnd=ssthresh時,既可以使用慢開始算法,也可以使用堵塞避免算法(通常做法)。

4.網絡堵塞的處理

    當網絡出現堵塞時,不管在慢開始階段還是在堵塞避免階段,只要發送方檢測到超時事件的產生(沒有按時收到確認,重傳計時器超時),就要把慢開始門限ssthresh設置為出現堵塞時的發送方cwnd值的1半(但不能小于2)。然后把堵塞窗口cwnd重新設置為1,履行慢開始算法。這樣做的目的就是要迅速減少主機發送到網絡中的分組數,使得產生堵塞的路由器有足夠時間把隊列中積存的分組處理終了。

    堵塞避免并不是完全能避免堵塞。利用以上措施要完全避免網絡堵塞是不可能的。堵塞避免是指在堵塞避免階段把堵塞窗口控制為按線性規律增長,使網絡比較不容易出現堵塞。

    慢開始和堵塞避免算法的實現進程以下圖所示:

    注意,在慢開始(指數級增長)階段,若2*cwnd＞ssthresh,則下1個RTT的cwnd應等于ssthresh,而不是2*cwnd,即cwnd不能躍過ssthresh值。

小結:

    在慢開始和堵塞避免算法中使用了“乘法減小”和“加法增大”方法。“乘法減小”是指不論在慢開始階段還是堵塞避免階段,只要出現1次超時(即極可能出現了網絡堵塞),就把慢開始門限值ssthresh設置為當前的堵塞窗口值的1半。當網絡頻繁出現堵塞時,ssthresh值就降落得很快,以大大減少注入到網絡中的分組數。而“加法增大”是指履行堵塞避免算法后,在收到對所有報文段的確認后(即經過1個RTT),就把堵塞窗口cwnd增加1個MSS大小,使堵塞窗口緩慢增大,以避免網絡過早出現堵塞。

快重傳與快恢復

    快重傳和快恢復算法是對慢開始和堵塞避免算法的改進。

1.快重傳

    當發送方連續收到3個重復的ACK報文時,直接重傳對方還沒有收到的報文段,而沒必要等待那個報文段設置的重傳計時器超時。

2.快恢復

    快恢復算法原理:當發送端收到連續3個冗余ACK(即重復確認)時,就履行“乘法減小”算法,把慢開始門限ssthresh減半。與慢開始(慢開始算法將堵塞窗口cwnd設置為1)不同的地方是它把cwnd的值設置為慢開始門限ssthresh減半后的數值,然后開始履行堵塞避免算法(“加法增大”),使堵塞窗口緩慢地線性增大。

    由于跳過了cwnd從1起始的慢開始進程(由于既然現在能夠收到3個重復ACK確認, 就說明堵塞程序其實不是很大),所以被稱為快恢復。快恢復算法的實現進程以下圖所示,作為對照,虛線為慢開始的處理進程。

    注-發送方發送窗口的實際大小由流量控制和堵塞控制共同決定。因此,當同時出現了接收端窗口(rwnd)和堵塞窗口(cwnd)時,發送方實際的發送窗口大小是由rwnd和cwnd中較小的那1個肯定的。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈