【北航計算機網絡課程筆記】5. 傳輸層

基本定義

傳輸層:
實現可靠傳輸: 差錯控制, 順序控制, 擁塞控制
網絡層實現主機之間的通信, 傳輸層實現應用程序之間的通信, 自下而上第一個提供端(應用程序)到端服務的層次

TCP協議(可靠傳輸協議, 面向連接的服務, 安全), UDP協議(不可靠傳輸協議, 無需建立連接, 面向報文, 效率高, 但不安全)
數據傳輸單位: TPDU / TCP報文段 / UDP用戶數據報
爲多個應用進程提高服務–>複用與分用
區分應用進程: 端口, 不用進程ID(依賴於特定操作系統, 需要與多個主機通信)
TCP/IP協議使用16位整數作爲端口號
熟知端口號/系統端口號: 0-1023, HTTP服務, FTP服務等
登記端口號: 1024-49151, 須在IANA登記以防重複
客戶端口號/短暫端口號: 49152-65535
cmd中命令netstat查詢端口號

UDP與TCP

UDP協議:
12字節僞首部(計算校驗和使用, 不傳輸) + 8字節頭部(源端口+目的端口+長度+校驗和) + 數據
IP報頭protocol字段=17
Inter和網絡中通常採用大端, arm中採用小端, 所以使用轉換字節序的宏: htonl()即host to network long, htons(), ntohl(), htons()
校驗和計算: 添加僞頭部, 奇數字節需補充0字節.
若接收方的目的端口上沒有應用接收數據, 則返回ICMP的"目的不可達"報文

TCP協議:
面向連接, 點對點, 可靠服務, 全雙工通信, 面向字節流(數據塊不一定一一對應)
IP報頭protocol字段=6
根據對方給出的窗口值和當前網絡擁塞程度決定一個報文段包含多少個字節.(UDP報文長度是應用進程給出的)
可能將長數據塊分成幾個報文發送, 或者短的合在一起發送.
連接端點是套接字(socket=<IP:>)(socket=<IP地址: 端口號>)或插口,
20字節固定頭部+選填部分(這部分要是4字節的倍數)+數據
源端口, 目的端口
序號: 數據流中每一個字節有序號,本報文數據中第一個字節的序號
確認號: 期望收到對方的下一個報文數據中第一個字節的序號(接收方發出的報文中, 全雙工通信一起發)
數據偏移, 保留字段, URG(緊急數據, 加快發送), ACK, PSH(不同等緩存填滿就發送), RST(1=嚴重錯誤, 釋放連接後重新建立連接), STN(1=連接請求), FIN(1=釋放連接), 窗口大小
檢驗和(僞首部(和UDP一樣)+首部+數據), 緊急指針(緊急數據的字節數, 都放在最前面)
以字節爲單位的滑動窗口: 根據"窗口大小"確定大小, 根據"確認號"向前滑動窗口, 窗口大小變化時不向後收縮(可以向前收縮), 可用窗口(允許發送但尚未發送的字節數), 發送緩存和接受緩存
發送窗口大小小於等於接受窗口大小
可靠性: 校驗和+超時重傳(自適應算法計算超時重傳時間RTO=RTTS(RTT)+4RTTD(RTT)RTO=RTT_S(RTT的加權平均值) + 4 * RTT_D(RTT偏差的加權平均值)

TCP流量控制、擁塞控制

TCP協議
流量控制: 利用滑動窗口和持續計時器實現三種方式: 定量發送(最大報文長度MMS), 應用進程控制(需要push), 定時發送(長度達到MMS也要發送)
網絡擁塞: 需求>可用資源, 由多種原因引起, 簡單增加某種資源不能消除, TCP重傳機制會加劇惡化
擁塞控制是全局性過程, 流量控制是點對點控制
只要沒收到確認(超時), 認爲擁塞.
擁塞控制: 開環控制(網絡設計), 閉環控制(基於反饋環路): 四種方式
慢啓動: 試探性地從小到大逐漸增大發送窗口, 發送方維持擁塞窗口cwnd, 是一個狀態變量(當前窗口大小=cwnd*MMS), 傳輸輪次=RRT+確認收到, 收到一個確認cwnd+1(即一個傳輸輪次cwnd加倍). 有一個限制慢啓動門限ssthresh.
擁塞避免: cwnd>=ssthresh時, 一個傳輸輪次cwnd+1, 發生擁塞時, ssthresh改爲發送窗口值的一半, cwnd重新設爲1
快重傳: 接收方收到一個失序的報文段, 發出重複確認(最新的ACK), 發送方收到三個重複確認就立即重傳
快恢復: 發送方收到三個重複確認時, ssthresh改爲發送窗口值的一半, cwnd重新設爲ssthresh, 開始擁塞避免(一個傳輸輪次cwnd+1)
綜合流量控制和擁塞控制, 發送窗口=min(cwnd, 接收窗口)

TCP連接管理

TCP連接管理:
客戶(主動發起連接建立的應用進程)/服務器(被動)方式

連接建立
客戶端發起
三次握手(A->B:SYN=1; B->A:SYN=1,ACK=1; A->B:ACK=1), 三次可以防止失效的連接請求佔用服務器端資源
三次握手導致TCP SYN Flooding攻擊: 發送大量第一個報文卻不響應, 使服務器內部數據結構滿,不能正常應答TCP連接請求.
linux內核應對, SYN_Cookies機制: 收到第一個報文不分配資源

連接釋放
任一方發起
兩個來回, 發起方申請釋放+收到回覆–>中斷單方向連接, 接受方發送完所有數據, 確認釋放+收到回覆–>中斷雙方向連接, 接收方立即關閉進程, 發起方收到確認釋放後等待2MSL關閉進程(防止有數據滯留)
MSL報文段最大存活時間, 建議2分鐘

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