1. 傳輸層概述

? 傳輸層的功能是提供進程和進程之間的==通信==,實現(xiàn)==復用和分用==,對收到的報文進行==差錯檢測==.

? 傳輸層會給消息加上發(fā)送端端口和接收端端口,根據(jù)下一層網絡層提供的IP地址去尋找相應的目標機器(其中還會經歷IP地址轉換為MAC地址)

(1). 傳輸層協(xié)議

? 傳輸層兩個協(xié)議:TCP和UDP.

(2). 端口

? 實現(xiàn)分用需要通過端口號分發(fā)從網絡層獲得的數(shù)據(jù).

? 端口號用于區(qū)分本地不同的網絡進程,只有本地意義,不同計算機之間的端口號是沒有聯(lián)系的.

端口號:

• 服務端使用的端口號
  • 熟知端口號(1~1023):給TCP/IP最重要的一些應用程序,大多數(shù)被系統(tǒng)占用
    • FTP:21
    • TELNET:24
    • SMTP:25
    • DNS:53
    • TFTP:69
    • HTTP:80
    • SNMP:161
  • 等級端口號(1024~49151):服務端安裝的應用程序使用的,如Tomcat的8080端口
• 客戶端使用的端口號(49152~65535):在客戶進程運行是動態(tài)分配

網絡中使用套接字來標識網絡中的一個主機和它上面的進程,套接字Socket=(主機IP地址,進程端口號)

2. UDP協(xié)議

(1). UDP協(xié)議概述

? UDP只是在IP數(shù)據(jù)服務報之上增加了很少的功能,即復用分用和差錯檢測功能.

主要特點:

• UDP是無連接的
• UDP使用最大努力交付,即不保證可靠交付
• UDP是面向報文的,適合一次性傳輸少量數(shù)據(jù)的網絡應用
• UDP無擁塞控制,適合實時應用(視頻通話)
• UDP的首部開銷比較小,8B,而TCP有20B
  • 16位源端口號
  • 16位目的端口號
  • 16位UDP長度
  • 16為UDP檢驗和

(2). UDP校驗

在進行校驗時會出現(xiàn)偽首部:

• 源IP地址
• 目的IP地址
• 0
• 17
• UDP長度:UDP首部加數(shù)據(jù)字段長度

1574490572867

3. TCP協(xié)議

(1). TCP的特點

• TCP是面向連接的傳輸層協(xié)議
• 每條TCP連接只能有兩個端點
• TCP提供可靠交付的服務,無差錯,無丟失,不重復,按序到達
• TCP提供全雙工通信
  • 發(fā)送緩存:準備發(fā)送的數(shù)據(jù),和已經發(fā)送但是沒被確認收到的數(shù)據(jù)
  • 接收緩存:按序到達但是沒被讀取的數(shù)據(jù),不按序到達的數(shù)據(jù)
• TCP面向字節(jié)流:將應用程序交下來的數(shù)據(jù)看成是一連串的無結構的字節(jié)流

(2). TCP報文段首部格式

1574491692732

序號:TCP連接傳送的字節(jié)流中的每一個字節(jié)都按順序編號,這里指本次傳輸?shù)牡谝粋€字節(jié)的序號

確認號:期望收到對方下一個發(fā)送的下一個報文段中包含的序號,如果確認號為n,那么證明前n-1個字節(jié)全部都正確收到了

數(shù)據(jù)偏移:TCP報文中起始字節(jié)到第一個數(shù)據(jù)字節(jié)的長度,也就是首部的長度

URG:緊急位,當此位為1時,該報文具有較高的優(yōu)先級,可以不在緩存中排隊發(fā)送

ACK:確認位,當ACK為1時,報文段才有效.連接建立后所有的報文此位都為1

PSH:推送位,當PSH為1時,接收方不會等到緩存填滿再向上交付,而是立即交付

RST:復位,當RST為1時,表明連接中出現(xiàn)了嚴重的差錯,必須釋放連接重新建立傳輸連接

SYN:同步位,當SYN為1時,表名當前報文是一個請求或接受連接報文

FIN:終止位,FIN為1時,表名次報文段將發(fā)送方所有的數(shù)據(jù)都發(fā)送完畢,請求釋放連接

窗口:由接收方給出,是接收方允許發(fā)送方下一次發(fā)送數(shù)據(jù)的數(shù)量

檢驗和:加上12B的偽首部,進行校驗,TCP中協(xié)議字段為6,TCP中是17

緊急指針:在緊急位URG為1時才有效,代表本報文段中緊急數(shù)據(jù)的字節(jié)數(shù)

選項:最大報文段長度MSS,窗口擴大,時間戳,選擇確認等等

(3). TCP連接管理

? TCP連接傳輸?shù)娜齻€階段:連接建立,數(shù)據(jù)傳送,連接釋放

? TCP連接的建立采用客戶服務器方式,主動發(fā)起連接的應用進程叫客戶,被動等待連接建立的應用進程叫服務器

1). TCP連接的建立

? 過程中SYN是同步位,代表本次是請求報文,ACK是確認位,代表已經建立了連接.seq是序號,ack是確認號,回應的ack應該是請求中seq+1

1. 客戶端發(fā)送連接請求報文段
   1. SYN = 1, seq = x,其中seq是一個隨機數(shù),無效的
   2. 客戶端:無狀態(tài)(CLOSE) ===> 等待匹配請求(SYN-SENT)
2. 服務端為該TCP連接==分配緩存和變量==,并發(fā)送確認報文段
   1. SYN = 1, ACK = 1, seq = y, ack = x+1
   2. 服務端: 監(jiān)聽TCP建立請求(LISTEN) ===> 收到建立請求并且 返回確認后 等待確認的確認(SYN-RCVD)
3. 客戶端為該TCP連接==分配緩存和變量==,并向服務端返回確認的確認,這時可以攜帶數(shù)據(jù).
   1. SYN = 0, ACK = 1, seq = x+1, ack = y+1
   2. 客戶端: 等待匹配請求(SYN-SENT) ===> 已經建立連接(ESTABLISHED)
   3. 服務端:收到建立請求并且返回確認后等待確認的確認(SYN-RCVD) ===> 已經建立連接(ESTABLISHED)

1574495842797

? 以上的過程被稱作為TCP建立連接的三次握手機制.之所以要進行最后一次握手,是因為在第二次握手進行完之后,客戶端已經知道服務端同意建立連接了,但是服務端并不知道客戶端得到了同意,這是可能發(fā)生很多狀況,如消息的丟失,客戶端已經掛機.只有客戶端再發(fā)一次確認報文,才可以讓雙方都知道這個連接已經建立.

? 還有一個狀況就是,如果采用兩次握手.服務端發(fā)出第一個請求報文后,沒有到達服務端,有發(fā)送了一個請求.第二個請求順利到達,建立連接完成通信后斷開連接.這時第一個請求到達了服務端,那么服務端還是會給出一個確認報文,因為服務端并不能識別這兩個請求報文是重復的,這時不需要客戶端給出確認服務端就認為又建立了一個連接.明顯是不符合邏輯的.

2). SYN洪泛攻擊

? 客戶端不斷向服務端發(fā)送建立請求報文段,服務端就直接分配了內存,但是客戶端不進行下一步了,但是服務端會不斷的發(fā)送確認報文段.客戶端建立非常多的這種TCP連接,占用客戶端的內存,直至死機

3). TCP連接的釋放確認后

1. 客戶端發(fā)送連接釋放報文段.
   1. FIN = 1, seq = u.
   2. 這時還是可以雙向傳輸數(shù)據(jù)的
   3. 客戶端:已經建立連接(ESTABLISHED) ===> 等待中斷請求的確認(FIN-WAIT-1)
2. 服務端回送一個確認報文段.
   1. ACK = 1, seq = v, ack = u+1.
   2. 這時客戶端不能向服務端發(fā)送數(shù)據(jù)了
   3. 服務端:已經建立連接(ESTABLISHED) ===> 等待服務器應用程序關閉連接(CLOSE-WAIT)
   4. 客戶端:等待中斷請求的確認(FIN-WAIT-1) ===> 等待服務端關閉連接(FIN-WAIT-2)
3. 服務端發(fā)送完當前正在發(fā)送的數(shù)據(jù),會發(fā)出連接釋放報文段,主動的釋放連接.
   1. FIN = 1, ACK = 1, seq = w, ack = u+1
   2. 雙方都不能發(fā)送數(shù)據(jù)了
   3. 服務端:等待服務器應用程序關閉連接(CLOSE-WAIT) ===> 等待請求的確認(LAST-ACK)
4. 客戶端回復確認報文段,再等到時間等待計時器設置的最長報文段壽命后,連接徹底關閉
   1. ACK = 1, seq = u+1, ack = w+1
   2. 客戶端:等待服務端關閉連接(FIN-WAIT-2) ===> 等待足夠長的時間確保服務器收到回復(TIME-WAIT) ===> 連接斷開(CLOSED)
   3. 服務端:等待請求的確認(LAST-ACK) ===> 連接斷開(CLOSED)
   4. 服務端如果沒有收到這次的確認回復,那么會重新進行第三次揮手.直到得到回應

1574499370153

? 通常來說,讓客戶端和服務端兩方都知情一件事情需要三次通信,但是在連接的釋放過程中,還需要考慮當前正在發(fā)送的資源需要進行一個結尾.所以在服務端收到第一次斷開連接的請求報文后,會先給客戶端一個確認報文,表示服務端已經打算關閉連接,這時客戶端已經明白自己不需要再發(fā)送數(shù)據(jù)了,但是可能還會有服務端正在處理的數(shù)據(jù)發(fā)來.等服務端處理完所有的數(shù)據(jù),會給客戶端發(fā)送斷開連接的請求報文,表示服務端不再發(fā)送數(shù)據(jù).同樣的,客戶端需要會送一個確認報文來讓服務器知道客戶端已經收到了服務端的通知完全斷開連接,服務端也會完全斷開連接.

? 如果服務端沒有收到客戶端最后發(fā)送的確認報文,那么會重新發(fā)送服務端斷開連接的請求報文.所以需要客戶端等待一定時間確?？梢允盏竭@個再次發(fā)送的請求報文.如果客戶端不進行等待,那么服務端會不停的重發(fā).

(4). TCP可靠傳輸

? 可靠傳輸是指數(shù)據(jù)的傳輸保證發(fā)出方發(fā)出的字節(jié)流和發(fā)送方發(fā)出的字節(jié)流是完全一樣的.

? 網絡層是不保證可靠傳輸?shù)?

TCP實現(xiàn)可靠傳輸?shù)臋C制:

1. ==校驗==:增加==偽部首==,二進制反碼求和的反碼.和UDP的校驗一樣
2. ==序號==:通過每次傳輸時發(fā)送序號,接收的==回應中傳輸下一次的首序號==,保證發(fā)送的數(shù)據(jù)是連續(xù)的
3. ==確認==:接收方收到數(shù)據(jù)后,會往回發(fā)送一個確認報文,內容包含當前接受方應該得到的下一個報文段(中間空缺的話會對發(fā)送方進行提示),發(fā)送方緩存中的字節(jié)流不經確認是不會刪除的.確認報文可以加在接收方發(fā)送的數(shù)據(jù)中發(fā)送,稱為捎帶確認.
4. ==重傳==:放接收方發(fā)回來的確認號不符合當前字節(jié)流中的第一個字節(jié)的序號或在規(guī)定時間內沒有收到確認(總而言之就是丟包了)時,發(fā)送方會重新傳輸這段數(shù)據(jù).

(5). TCP流量控制

? ==滑動窗口機制==

? 窗口規(guī)定了一次性可以發(fā)送的包的數(shù)量,每次接收方送回一個確認號,窗口的開始會滑動到確認號對應的位置.沒有收到確認的話,窗口不會進行滑動,就會重復的發(fā)送一樣的幾個包.

? 接收方在返回的確認報文中設置了自己期望的下一次發(fā)送的數(shù)據(jù)量(一般都是期望充分使用緩沖池),也就是窗口.這樣可以動態(tài)的調整數(shù)據(jù)發(fā)送的速度.

? 當接收方發(fā)送的窗口大小為0時,發(fā)送方不再發(fā)送數(shù)據(jù),接收方此時進行數(shù)據(jù)的上層提交等操作.當進行了一部分后如果想要讓發(fā)送方重新開始發(fā)送數(shù)據(jù),重新發(fā)送一個窗口大小不為0的確認報文即可.

? ==接收方的確認報文并不是每一次收到數(shù)據(jù)都會發(fā)送的,而是有一個累積的過程.==

? 為了防止窗口為0的確認報文丟失導致的兩端相互等待,出現(xiàn)了這樣的機制:TCP為每一個連接都設有一個計時器,發(fā)送方只要要收到接收方的零窗口通知,就啟動計時器.如果計時器設置的時間到期,會向接收方發(fā)送一個零窗口探測報文段,接收方這時會重新發(fā)送此時的窗口大小.

(6). TCP擁塞控制

? 擁塞是指對資源的需求超過了資源能提供的大小(交換機來不及轉發(fā)數(shù)據(jù)等等),會有許多資源同時呈現(xiàn)資源供應不足,導致網絡性能變壞.

? 擁塞控制總體上就是==防止過多的數(shù)據(jù)注入到網絡中==.這樣聽起來與流量控制很像,但流量控制面向的是單個連接中的兩個端點,而擁塞控制面向的是有全局性正在連接某臺設備的全部端點.

四種算法:

1. 慢開始
2. 擁塞避免
3. 快重傳
4. 快恢復

? ==接受窗口==是==接收方==根據(jù)接受緩存設置的值,并告知給發(fā)送方,反映==接收方容量==.

? ==擁塞窗口==是==發(fā)送方==根據(jù)自己==估算的網絡擁塞程度==而設置的窗口,反映==當前網絡的容量==.

? 發(fā)送窗口(實際發(fā)送的數(shù)據(jù)量) = Min(接收窗口, 擁塞窗口)

1). 慢開始和擁塞避免

? 慢開始指數(shù)據(jù)傳輸時擁塞窗口很小,但是后面以質數(shù)進行增長(收到確認報文時二倍增長).

? 當擁塞窗口達到ssthresh值時,通過加法進行增長,這是擁塞避免.

? 當擁塞窗口達到一定值時,減小到1,重新開始這個過程,并根據(jù)網絡擁塞的情況重新設置ssthresh值(網絡擁塞是擁塞窗口的一半).

1574510981964

2). 快重傳和快恢復

? 當收到3個重復的確認(中間的報文沒有收到)后,執(zhí)行快重傳,迅速的將缺少的報文進行重傳.此時被認為發(fā)生了網絡擁塞.會重新計算ssthresh值為此時擁塞窗口的一半大小,并重HTTP請求的發(fā)送新設置擁塞窗口大小為新的ssthresh值,也就是原來的一半.

? 快恢復是指擁塞窗口變小后,直接以加法進行增大,較快的進行恢復.(快恢復的快主要指不需要重新從1開始)

image-20191126223926961