傳輸層

計算機網絡筆記,視頻地址:https://www.bilibili.com/video/av9876107

1. 傳輸層功能

傳輸層爲相互通信的應用進程提供了邏輯通信 找到對應端口

在這裏插入圖片描述

此外,傳輸層還需要對收到的報文進行差錯檢測

在這裏插入圖片描述

2. OSI參考模型和TCP/IP協議棧

在這裏插入圖片描述

2.1 傳輸層協議和應用層協議的關係

在這裏插入圖片描述

常見應用層協議使用的端口:

  • HTTP:TCP+80
  • HTTPS:TCP+443
  • RDP:TCP+3389
  • FTP:TCP+21
  • 共享文件夾:TCP+445
  • SMTP(發郵件):TCP+25
  • POP3(收郵件):TCP+110
  • telnet:TCP+23
  • SQL:TCP+1433
  • DNS:UDP+53

3. 服務和應用層協議之間的關係

傳輸層的數據包攜帶目標端口信息,不同服務根據端口匹配偵聽

計算機上可能安裝不同服務,但是接受的數據訪問服務端需要匹配端口,這裏涉及到了網絡安全問題,避免惡意數據入侵服務

服務使用TCP或UDP端口偵聽客戶端請求

客戶端使用IP地址定位服務器,使用目標端口定位服務

可以在服務器網卡上設置只開放必要的端口從而實現網絡安全

3.1 如何查看服務偵聽的端口

netstat -a:查看偵聽的端口

telnet 192.168.80.100 3389:測試到遠程計算機192.168.80.100的3389端口是否打開

netstat -ano:查看端口占用情況

在這裏插入圖片描述

tasklist | findstr "80":查看80端口被哪些應用佔用
在這裏插入圖片描述

3.2 計算機中端口

需要注意的是,端口號具有本地意義,同一個計算機上不同應用的端口號不同,但是不同計算機中的端口號沒有聯繫,即不同計算機對應相同端口號表示的意義不同

端口可以分爲三類:

  • 熟知端口:0-1023
  • 登記端口:1024-49151
  • 客戶端口:49152-65535

4 UDP(User Data Protocol,用戶數據報協議)

UDP面向無連接的傳輸,不需要建立會話,非可靠傳輸,不需要流量控制

一個數據包就可以完成通信

UDP使用盡最大努力交付,不保證可靠交付,也不使用擁塞控制

UDP是面向報文的,適合多媒體通信要求

UDP支持一對一,一對多和多對多的交互通信

UDP首部開銷小,只有八個字節

在這裏插入圖片描述

UDP首部格式:

在這裏插入圖片描述

僞首部中的UDP長度表示的是IP數據報的長度,首部中的長度表示UDP用戶數據報的長度

在這裏插入圖片描述

計算過程如下:

​ 1001 1001 0001 0011

+ 0000 1000 0110 1000


​ 1010 0001 0111 1011

+ 1010 1011 0000 0011


1 0100 1100 0111 1110

進位 1


​ 0100 1100 0111 1111

+ 0000 1110 0000 1011


​ 0101 1010 1000 1010

+ 0000 0000 0001 0001


​ 0101 1010 1001 1011

+ 0000 0000 0000 1111


​ 0101 1010 1010 1010

+ 0000 0100 0011 1111


​ 0101 1110 1110 1001

+ 0000 0000 0000 1101


​ 0101 1110 1111 0110

+ 0000 0000 0000 1111


​ 0101 1111 0000 0101

+ 0000 0000 0000 0000


​ 0101 1111 0000 0101

+ 0101 0100 0100 0101


​ 1011 0011 0100 1010

+ 0101 0011 0101 0100


1 0000 0110 1001 1110

進位 1


​ 0000 0110 1001 1111

+ 0100 1001 0100 1110


​ 0100 1111 1110 1101

+ 0100 0111 0000 0000


​ 1001 0110 1101 1101

取反


​ 0110 1001 0010 0010

應用:域名解析,QQ聊天、屏幕廣播/多播

5 TCP協議(Transmission Control Protocol,傳輸控制協議)

TCP是面向連接的傳輸,需要建立會話,是可靠的傳輸,有流量控制

每條TCP連接都有兩個端點,是點對點的連接,全雙工通信,面向字節流

傳輸的文件需要分段傳輸

應用:大文件傳輸,郵件發送

5.1 TCP的連接

TCP連接的端點被稱爲套接字(socket),端口號拼接IP地址構成套接字

套接字 socket = (IP地址:端口號)

每一條TCP連接唯一地被通信兩端的兩個套接字確定,例如

{socket1,socket2}={(IP1:port1),(IP2:port2)}

傳輸連接的三個階段:建立連接、數據傳送、連接釋放

TCP連接的建立都是採用客戶服務器的方式,即將主動發起連接建立的應用進程叫做客戶(Client),將被動等待連接建立的應用進程叫做服務器(Server)

TCP連接需要三次握手,斷開需要四次揮手

5.1.1 建立連接

三次握手

在這裏插入圖片描述

第一次握手:客戶端發送syn報文請求到服務器,等待服務器確認,MSS表示最大數據包,seq表示序號,len表示數據長度;

第二次握手:服務器收到syn請求,向服務端發送一個確認報文ACK和一個請求連接報文SYN,WIN表示最大緩存;

第三次握手:客戶端收到服務器的SYN+ACK包,向服務器發送確認包ACK,此包發送完畢,客戶端和服務器進入ESTABLISHED狀態,完成三次握手。

在這裏插入圖片描述

第三次握手是爲了保證服務器SYN請求有效

握手過程中傳送的包裏不包含數據,三次握手完畢後,客戶端與服務器才正式開始傳送數據。理想狀態下,TCP連接一旦建立,在通信雙方中的任何一方主動關閉連接之前,TCP 連接都將被一直保持下去。

5.1.2 釋放連接

四次揮手

與建立連接的“三次握手”類似,斷開一個TCP連接則需要“四次握手”。

第一次揮手:客戶端作爲主動關閉方像服務器發送一個FIN報文申請斷開,但是,此時客戶端還可以接受數據

第二次揮手:服務器收到FIN包後,發送一個ACK給客戶端,之後不再向客戶端發送新的數據,但是如果已有數據在傳輸,會繼續傳輸

第三次揮手:當服務端想客戶端數據傳輸完成後,向客戶端發送一個FIN斷開報文

第四次揮手:客戶端收到服務器的FIN報文之後, 向服務器發送ACK確認報文, 告訴服務器說我也收到了你的關閉請求了. 此時如果服務器收到了ACK報文,服務器就關閉了, 而客戶端還要等待2MSL的時間之後才能關閉,如果2MSL內客戶端未收到服務端重發的FIN就可以執行斷開操作。

在這裏插入圖片描述

5.2 TCP報文段首部格式

在這裏插入圖片描述

TCP首部包括固定的20個字節和可變數據

  • 序號:分段數據的第一個字節是整個數據的第幾個字節

    在這裏插入圖片描述

  • 確認號:記錄發送端下一個數據段的起始字節數,例如發送1234這個數據段,確認號應該是5

  • 數據偏移:記錄TCP報文段從第幾個字節開始有數據

  • URG(urgent):urg標記爲1表示有較高的優先級,即在傳輸數據的時候不需要排隊,直接先傳

  • ACK(acknowledgment):ACK是0表示確認號無效,ACK爲1表示確認號有效

  • SYN:建立會話請求,在建立請求那個會話爲1,建立好會話後就爲0

  • PSH(push):PSH設爲1表示優先級較高,數據先傳

  • RST(resset):RST=1表示服務中斷,拒絕後面數據的通信,重新建立連接

  • FIN(finally):FIN=1表示釋放連接

  • 窗口:緩存大小,接收端要告訴發送端最大接收緩存,發送端要告訴接收端最大發送緩存

  • 緊急指針:只有在urg=1時起作用,指明瞭緊急傳遞數據包的字節結束爲止

5.3 TCP如何實現可靠傳輸

在這裏插入圖片描述

在這裏插入圖片描述

這種可靠的傳輸協議被稱爲自動重傳請求(Automatic Repeat reQuest, ARQ)

ARQ表明重傳的請求是自動進行的,接收方不需要請求發送方重傳某個出錯的部分

但是ARQ的信道利用率太低

爲了解決信道利用率低的問題,可以採用流水線傳輸,即發送方連續發送多個分組,如下圖所示
在這裏插入圖片描述

連續ARQ協議可以連續發送數據

在這裏插入圖片描述

如上圖所示,發送窗口爲5,表示發送端可以連續發送五個數據包,然後等待接收端返回確認,等到第一個數據包確認,發送窗口前移一位,類似滑動窗口,注意在沒有接收到接收端確認時,發送窗口中的數據不能丟棄

爲了進一步提高效率,不需要每一個數據包都發送確認,可以使用累積確認,例如發送三個數據包,最後一個數據包發送確認就默認前兩個都已經確認。

TCP實現可靠傳輸

  • 以字節爲單位的滑動窗口技術

    即規定發送窗口和接收窗口,窗口中的數據可以打包發送,在接收端返回確認後,發送窗口可以往後移,發送成功的數據可以丟棄

  • 選擇性確認(SACK)

    在發送的包不連續時,接收端會發送選擇性確認,讓發送端重新發送缺失的部分

    在這裏插入圖片描述

  • 超時重傳時間

    TCP每發送一個報文段就設置一個計時器,只要計時器設置的重傳時間到了還未收到確認,就重傳這一段報文

    超時重傳時間略大於加權平均往返時間RTTsRTT_s

    RTTs=(1α)(RTTs)+α(RTT)舊的新的樣本RTT_s=(1-\alpha)*(舊的RTT_s)+\alpha*(新的RTT樣本)

5.4 TCP協議如何實現流量控制

發送端的窗口大小不能大於接收端

通過調整發送窗口和接受窗口的大小可以控制發送和接收的數據

當接收端緩存不足就需要縮小窗口,讓可以處理緩存數據(將緩存數據發送給應用)

5.5 TCP協議如何避免網絡堵塞

當對資源需求的總和大於可用資源就會出現資源擁塞情況

擁塞控制是一個全局性的過程,涉及到所有主機、所有路由器以及與降低網絡傳輸性能有關的所有因素

在這裏插入圖片描述

可以看出,如果沒有擁塞控制,可能使得傳輸量越大通過的數據量越少,更嚴重可能出現死鎖情況,導致數據不能傳輸

5.5.1 慢開始和擁塞避免

發送方維持一個擁塞窗口(congestion window, cwnd)

發送方控制擁塞窗口的原則是:

  • 只要沒有出現擁塞,擁塞窗口就能再增大一些,以便發送更多數據出去
  • 如果出現網絡擁塞,擁塞窗口就適當減小,減少網絡中的分組數

可以看出也是通過調節窗口的大小來控制流量
在這裏插入圖片描述

慢開始門限剛開始設置爲16,之後線性增長而不是按照指數增長,當出現網絡擁塞後,新的慢開始門限變爲網絡擁塞前擁塞窗口的一半,之後擁塞窗口從1開始重新安裝指數增長

5.5.2 快重傳和快回復

在這裏插入圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章