TCP/IP入门(3) --传输层
/**
本篇博客由汗青ZJF整理并發布,?轉載請注明出處:
http://blog.csdn.net/zjf280441589/article/category/1854365
*/
傳輸層的主要功能
? ? 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)防止已失效的連接請求報文段出現在本連接中?？蛻舳嗽诎l送完最后一個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?字節?，F在發送端最多還可發送?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值。
?
小結:
? ??在慢開始和擁塞避免算法中使用了“乘法減小”和“加法增大”方法?！俺朔p小”是指不論在慢開始階段還是擁塞避免階段,只要出現一次超時(即很可能出現了網絡擁塞),就把慢開始門限值ssthresh設置為當前的擁塞窗口值的一半。當網絡頻繁出現擁塞時,ssthresh值就下降得很快,以大大減少注入到網絡中的分組數。而“加法增大”是指執行擁塞避免算法后,在收到對所有報文段的確認后(即經過一個RTT),就把擁塞窗口cwnd增加一個MSS大小,使擁塞窗口緩慢增大,以防止網絡過早出現擁塞。
快重傳與快恢復
? ??快重傳和快恢復算法是對慢開始和擁塞避免算法的改進。
1.快重傳
? ??當發送方連續收到三個重復的ACK報文時,直接重傳對方尚未收到的報文段,而不必等待那個報文段設置的重傳計時器超時。
?
2.快恢復
? ??快恢復算法原理:當發送端收到連續三個冗余ACK(即重復確認)時,就執行“乘法減小”算法,把慢開始門限ssthresh減半。與慢開始(慢開始算法將擁塞窗口cwnd設置為1)不同之處是它把cwnd的值設置為慢開始門限ssthresh減半后的數值,然后開始執行擁塞避免算法(“加法增大”),使擁塞窗口緩慢地線性增大。
? ??由于跳過了cwnd從1起始的慢開始過程(因為既然現在能夠收到三個重復ACK確認,?就說明擁塞程序并不是很大),所以被稱為快恢復?？旎謴退惴ǖ膶崿F過程如下圖所示,作為對比,虛線為慢開始的處理過程。
?
?
?
? ??注-發送方發送窗口的實際大小由流量控制和擁塞控制共同決定。因此,當同時出現了接收端窗口(rwnd)和擁塞窗口(cwnd)時,發送方實際的發送窗口大小是由rwnd和cwnd中較小的那一個確定的。
總結
以上是生活随笔為你收集整理的TCP/IP入门(3) --传输层的全部內容，希望文章能夠幫你解決所遇到的問題。
