5.1 上邊三層協議
- 應用層：http https DNS ftp SMTP PoP3 RDP
- 傳輸層：TCP UDP
- 網絡層：IP（RIP OSPF BGP）、ICMP、IGMP、ARP
5.2 TCP、UDP應用場景
- TCP ：分段 編號 流量控制 建立會話（netstat -n：查看會話）全雙工 可靠傳輸 面向字節流
- UDP： 一個數據包就能完成數據通信 不建立會話 多播 不可靠傳輸 面向報文
5.3 傳輸層和應用層之間的關係
應用層協議 = 傳輸層協議 + 端口號
- http =TCP + 80
- https = TCP + 443
- ftp = TCP + 21
- SMTP(發郵件) = TCP + 25
- PoP3(收郵件) = TCP +110
- RDP(遠程桌面協議) = TCP + 3389
- 共享文件夾 = TCP + 445
- SQL = TCP + 1433
- DNS = UDP + 53 or TCP + 53
- 登記端口：1024-49151 客戶端端口：49152-65535
5.4 應用層協議和服務之間的關係
服務運行後在TCP或UDP的某個端口偵聽客戶端請求
安全策略：更改服務器的默認端口
TCP、UDP
- 兩個運輸實體在通信時傳送的數據單位叫作運輸協議單元
- TCP運送的協議數據單元是TCP報文段
- UDP運送的協議數據單元是UDP報文或用戶數據報
UDP報文首部格式
TCP
每一條TCP連接有兩個端點。端點叫作：套接字（socket） = IP地址 ： 端口號
TCP報文段首部格式
可靠傳輸
停止等待
-
優點：簡單
-
缺點：信道利用率太低
-
信道利用率
-
自動重傳請求ARQ——重傳請求自動進行
-
提高信道利用率：流水線傳輸
-
發送方可連續發送多個分組，不必每發完一個分組就停頓下來等待對方的確認；
-
連續ARQ協議：使用滑動窗口實現可靠傳輸
-
累積確認
- 接收方一般採用累積確認的方式。即不必對收到的分組逐個發送確認，而是對按序到達的最後一個分組發送確認，這樣就表示：到這個分組爲止的所有分組都已正確收到了
-
以字節爲單位的滑動窗口
注意
- A 的發送窗口並不總是和 B 的接收窗口一樣大（因爲有一定的時間滯後）。
- TCP 標準沒有規定對不按序到達的數據應如何處理。通常是先臨時存放在接收窗口中，等到字節流中所缺少的字節收到後，再按序交付上層的應用進程。
- TCP 要求接收方必須有累積確認的功能，這樣可以減小傳輸開銷
流量控制
調整滑動窗口爲0暫停發送，實現流量控制
避免網絡擁塞
出現資源擁塞的條件：對資源需求的總和 > 可用資源
擁塞控制所起的作用:
擁塞控制算法
- 慢開始和擁塞避免
- 快重傳和快恢復
快重傳
- 快重傳算法首先要求接收方每收到一個失序的報文段後就立即發出重複確認。這樣做可以讓發送方及早知道有報文段沒有到達接收方。
- 發送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段。
- 不難看出，快重傳並非取消重傳計時器，而是在某些情況下可更早地重傳丟失的報文段
快恢復
- (1) 當發送端收到連續三個重複的確認時，就執行“乘法減小”算法，把慢開始門限 ssthresh減半。但接下去不執行慢開始算法。
- (2)由於發送方現在認爲網絡很可能沒有發生擁塞，因此現在不執行慢開始算法，即擁塞窗口cwnd 現在不設置爲 1，而是設置爲慢開始門限 ssthresh 減半後的數值，然後開始執行擁塞避免算法（“加法增大”），使擁塞窗口緩慢地線性增大。
發送窗口的上限值
發送窗口的上限值 = Min [rwnd, cwnd]
5.5 TCP的傳輸連接管理
三個階段
連接建立、數據傳送、連接釋放
TCP連接的建立都是採用客戶服務器方式
- 主動發起連接建立的應用進程叫做客戶
- 被動等待連接建立的應用進程叫做服務器
TCP連接建立（三次握手）
建立過程
建立連接時的各狀態
釋放連接
