1.運輸層協議概述
1.1.進程之間的通信
- 運輸層向它上面的應用層提供通信服務胚嘲,屬于面向通信部份的最高層
- IP數據報能指明 通信的兩端是主機噪漾,但真正通信的實體是在主機中的進程褐健。
- 端對端的通信實質上是進程間的通信
- 運輸層一個很重要的功能
- 復用:不同的應用進程都可以使用同一個運輸層協議傳輸數據
- 分用:接收方的運輸層在剝去報文的首部后能夠把這些數據正確交付目的進程
- 網絡層與運輸層的區(qū)別
- 網絡層為主機之間提供邏輯通信态坦,而運輸層為應用進程之間提供端對端的邏輯通信
- 網絡層只對首部差錯檢驗梅尤,運輸層要對報文進行差錯檢測
- 運輸層需要面向連接的TCP協議,無連接的UDP協議
- 運輸層為高層用戶屏蔽了下面的網絡核心細節(jié)
- 采用TCP時寄雀,盡管下面的網絡不可靠,但邏輯通信相當于一條全雙工的可靠信道陨献。
- 采用UDP時盒犹,邏輯通信仍是不可靠的
1.2.運輸層的兩個主要協議
- 用戶數據報協議UDP
- 不需要先建立連接
- 雖然不提供可靠交付,但很有效
- 傳輸控制協議TCP
- 面向連接的服務
- 可靠交付
- 開銷大
1.3.運輸層端口
- 在協議棧層間的抽象的協議端口是軟件端口
- 軟件端口是應用層的各種協議進程與運輸實體進行層間交互的一種地址
- TCP/IP使用16位的端口號
- 端口號只具有本地意義眨业,標志的是本機中的進程急膀。
- 不同主機相同進程號是沒有關聯的
- 端口號分類
- 服務端使用的端口號
- 熟知端口號(系統(tǒng)端口號):0-1023
- 21:FTP
- 23:TELNET
- 25:SMTP
- 53:DNS
- 69:TFTP
- 80:HTTP
- 161:SNMP
- 162:SNMP(TRAP)
- 443:HTTPS
- 登記端口號:1024-49151
- 熟知端口號(系統(tǒng)端口號):0-1023
- 客戶端使用的端口號:49152-65535
- 短暫端口號,通信結束后就注銷龄捡,供給其他進程使用
- 服務端使用的端口號
2.用戶數據報協議UDP
2.1.概述
- 無連接的:所以不需要使用套接字建立連接,TCP需要兩個套接字
- 不保證可靠交付
- 面向報文:保留邊界(不分片卓嫂,IP處理)
- 沒有擁塞控制
- 支持一對一,一對多聘殖,多對一晨雳,多對多
- 首部開銷小,8字節(jié)
2.2.首部格式
- 總共8個字節(jié)奸腺,4個字段餐禁,一個2字節(jié)
- 源端口:需要對方回信時選用,不用則0
- 目的端口
- 長度:用戶數據報長度突照,最小8字節(jié)(只有首部)
- 檢驗和:全檢驗帮非,首部——數據
3.傳輸控制協議TCP
3.1.主要特點
- 面向連接
- 每條TCP連接只能有兩個端點:點對點
- 可靠交付
- 全雙工
- 面向字節(jié)流
- TCP可以劃分片,再傳給IP
3.2.TCP連接
TCP把連接作為最基本的抽象
TCP所謂的點對點叫做:套接字socket:(IP地址:端口號)
每一條TCP連接唯一的被通信兩端點確定
3.3.可靠傳輸工作原理
- 理想的傳輸條件的特點:
- 傳輸信道不產生差錯
- 不管發(fā)送方的速度多少讹蘑,接收方總能處理
3.3.1.停止等待協議
- 即發(fā)送完一個分組就停止末盔,等待對方確認
- 出現差錯時:
- 超時重傳:發(fā)送方過了一段時間未收到確認信息,就認為信息丟失衔肢,重傳庄岖。超時計時器
- 發(fā)送方在發(fā)送完一個分組后,必須暫時保留已發(fā)送的副本
- 分組和確認分組都要編號
- 超時計時器的時間應該比數據在分組傳輸的品軍防范時間更長一些
- 確認丟失和確認遲到
- 假設接收方在發(fā)送 確認信號后 角骤,再次收到了相同編號的數據報隅忿,要采取兩個動作
- 丟棄這個重復分組
- 向A發(fā)送確認
- 假設接收方在發(fā)送 確認信號后 角骤,再次收到了相同編號的數據報隅忿,要采取兩個動作
- 通過以上這些,就可以在不可靠的傳輸網絡實現可靠的通信邦尊,稱之為自動重傳請求ARQ
- 信道利用率:發(fā)送時長/(發(fā)送市場+往返市場+接收方發(fā)送確認信號的時長)
3.4.連續(xù)ARQ協議
- 即 流水線傳輸
- 發(fā)送窗口(多個)
- 接收方采用累計確認
- 實現容易背桐,但不能向發(fā)送方反映出接收方已經正確收到的所有分組的信息(中間出錯,中間后面的需要全部重傳)
3.5.TCP報文段的首部格式
- 固定20字節(jié)
- 源端口和目的端口 : 各占2字節(jié)
- 序號:4字節(jié)蝉揍,在一個TCP連接中傳送的字節(jié)流中的每一個字節(jié)都按順序編號
- 確認號:期望收到對方下一個報文段的第一個數據字節(jié)的序號
- 若確認號為N链峭,則表示N-1為止的所有數據都以正確接收
- 數據偏移:4位,指出TCP報文段的首部長度又沾。
- 數據偏移的單位是32位字弊仪,即4字節(jié)熙卡,4位能表示的最大數為15,則首部最大長度為60字節(jié)
- 保留:6位励饵。今后使用
- -----------下面為6個控制位----------
- 1
- 推送PSH:當發(fā)送方需要立即回復時驳癌,可以PSH置1
- 復位RST:1表示TCP連接中出現嚴重差錯,必須釋放連接役听,重置
- 同步SYN:SYN為1颓鲜,ACK為0時表示這是一個連接請求報文,若對方同意典予,則在響應的報文段中使得兩個都為1甜滨,表示這是一個連續(xù)請求報文
- 終止FIN:1表示發(fā)送完畢,并釋放連接
- ---------控制位結束----------------------
- 窗口:占2字節(jié)瘤袖,接收窗口(而不是發(fā)送窗口)衣摩。窗口值作為接收方讓發(fā)送方設置其發(fā)送窗口的依據(動態(tài)變化)
- 校驗和:2字節(jié),全校驗
- 緊急指針:2字節(jié)孽椰,僅在URG置1時有意義昭娩,指出了緊急數據的位置
- 即使窗口為0,也可以發(fā)送緊急數據
- 選項:長度可變黍匾,40字節(jié)(擴展首部)
- 最大報文段長度MSS:每一個TCP報文段中的數據字段(不包括首部)的最大長度栏渺、
- ······
3.6.TCP可靠傳輸的實現
3.6.1.以字節(jié)為單位的滑動窗口
3.6.2.超時重傳時間RTO的選擇
- RTT:報文段的往返時間
- RTTS:加權平均往返
- RTO略大于RTTs
- 如果報文重傳的,就不采用其往返時間作為樣本(防止影響RTTs)
3.6.3.選擇確認SACK
3.7.TCP流量控制
3.7.1.利用滑動窗口實現流量控制
- 流量控制:讓發(fā)送方的發(fā)送速率不要太快锐涯,接收方要來得及接收
- 發(fā)送方決定接收方窗口
- TCP窗口單位是字節(jié)磕诊,不是報文段
- 會產生死鎖,解決:
- TCP會為每一個連接設有一個持續(xù)計時器
- 會發(fā)送零窗口探測報文段
3.8.TCP的擁塞控制
- 需求>可用
- 擁塞控制:防止過多的數據注入到網絡中纹腌,防止過載霎终。
- 這是一個全局性的過程
- 流量控制往往是點對點通信量的控制,端對端的問題
3.8.1.TCP擁塞控制方法
- 方法:
- 慢開始
- 擁塞避免
- 快重傳
- 快恢復
- 慢開始和擁塞避免
- 基于窗口的控制升薯,擁塞窗口
- 原則:只要網絡沒有出現擁塞莱褒,擁塞窗口就可以在增大一些。但只要出現擁塞或者可能出現擁塞涎劈,就要減小
- 判斷擁塞的依據:是否超時
- 慢開始:每經過一個傳輸輪次广凸,擁塞窗口cwnd就翻倍。2的指數增長
- 為防止 慢開始 的過度增長蛛枚,設置一個 慢開始門限ssthresh谅海,達到ssthresh后就執(zhí)行擁塞避免
- 擁塞避免:每經過一個傳輸輪次,擁塞窗口cwnd就+1
- 當隨著窗口增多蹦浦,出現超時(嚴重)扭吁,將ssthresh設置為cwnd的一半,窗口數從1開始,慢開始增長
- 快重傳和快恢復
- 當隨著窗口增多侥袜,出現三次ACK確認未回復( 信息丟失蝌诡,可能不是擁塞,不嚴重)系馆,執(zhí)行快重傳和快恢復
- 快重傳:收到三個相同的重復確認送漠,立刻重傳該報文顽照。并進行快恢復
- 快恢復:將ssthresh設置為cwnd的一半由蘑,擁塞避免增長,(+1增長)
3.9.TCP的運輸連接管理
運輸連接有三個階段:連接建立代兵,數據傳輸尼酿,連接釋放
-
TCP連接建立過程中要解決三個問題:
- 每一方能明確知道對方的存在
- 允許雙方協商參數
- 資源分配
TCP建立的訪問方式:C/S
3.9.1.TCP的連接建立
- 握手:TCP建立連接的過程。要交換三個TCP報文段植影。
- 裳擎!三報文握手表示:一次握手。不是三次握手思币!
- 一次握手(三報文握手)的過程:
- A—>B
- A創(chuàng)建傳輸控制模塊TCB鹿响,向B發(fā)送請求,SYN=1谷饿,初始序號seq=x惶我。
- TCP規(guī)定,該報文段不可攜帶數據博投,但要消耗一個序號
- B收到后绸贡,同意連接,向A發(fā)送確認毅哗,SYN=1听怕,ACK=1,ack=x+1虑绵,也為自己選擇一個初始序號seq=y
- TCP規(guī)定尿瞭,該報文段不可攜帶數據,但要消耗一個序號
- 這時TCP進程進入SYN-RCVD(同步收到)狀態(tài)
- A收到確認后翅睛,還要再給B發(fā)出確認声搁。ACK=1,ack=y+1,seq=x+1
- TCP規(guī)定,該報文段可以攜帶數據宏所,如果不攜帶酥艳,則不消耗序號,下一個數據報文段的序號仍是seq=x+1
- 最后這次確認是為了爬骤,防止已失效的連接請求報文突然又傳送到了B充石,產生錯誤
3.9.2.TCP的連接釋放
- 過程:
- 雙方都可主動釋放連接
- A向TCP發(fā)出連接釋放報文段,FIN=1霞玄,seq=u.
- A進入FIN-WAIT-1狀態(tài)骤铃,等待B的確認拉岁,FIN會消耗序號
- B收到后發(fā)送確認,ack=u+1惰爬,seq=v
- B進入了CLOSE-WAIT關閉等待狀態(tài)
- TCP服務器通知高層喊暖,連接釋放了,此時TCP的連接屬于半關閉撕瞧,A不可發(fā)送數據陵叽,但B向A發(fā),A還是要收
- 若B沒有需要發(fā)送的數據丛版,就通知TCP釋放連接
- B發(fā)送報文:FIN=1巩掺,seq=w,ack=u+1
- B進入了Last-ack最后確認页畦,等待A確認
- A收到后胖替,發(fā)出確認,ACK=1豫缨,ack=W+1独令,seq=u+1
- 到現在,TCP也釋放好芭,進入TIME-WAit狀態(tài)燃箭。必須經過 時間等待計時器的時間2MSL A才進入Closed狀態(tài)
- MSL:最長報文壽命
- 這是為了保證A發(fā)送的最后一個ACK報文段能到達B
- 以上為四報文握手