計算機網絡 運輸層

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
    • 客戶端使用的端口號: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ā)送確認
  • 通過以上這些,就可以在不可靠的傳輸網絡實現可靠的通信邦尊,稱之為自動重傳請求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
    • 以上為四報文握手
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市栓撞,隨后出現的幾起案子遍膜,更是在濱河造成了極大的恐慌,老刑警劉巖瓤湘,帶你破解...
    沈念sama閱讀 222,729評論 6 517
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件瓢颅,死亡現場離奇詭異,居然都是意外死亡弛说,警方通過查閱死者的電腦和手機挽懦,發(fā)現死者居然都...
    沈念sama閱讀 95,226評論 3 399
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來木人,“玉大人信柿,你說我怎么就攤上這事⌒训冢” “怎么了渔嚷?”我有些...
    開封第一講書人閱讀 169,461評論 0 362
  • 文/不壞的土叔 我叫張陵,是天一觀的道長稠曼。 經常有香客問我形病,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 60,135評論 1 300
  • 正文 為了忘掉前任漠吻,我火速辦了婚禮量瓜,結果婚禮上,老公的妹妹穿的比我還像新娘途乃。我一直安慰自己绍傲,他們只是感情好,可當我...
    茶點故事閱讀 69,130評論 6 398
  • 文/花漫 我一把揭開白布耍共。 她就那樣靜靜地躺著烫饼,像睡著了一般。 火紅的嫁衣襯著肌膚如雪划提。 梳的紋絲不亂的頭發(fā)上枫弟,一...
    開封第一講書人閱讀 52,736評論 1 312
  • 那天,我揣著相機與錄音鹏往,去河邊找鬼。 笑死骇塘,一個胖子當著我的面吹牛伊履,可吹牛的內容都是我干的。 我是一名探鬼主播款违,決...
    沈念sama閱讀 41,179評論 3 422
  • 文/蒼蘭香墨 我猛地睜開眼唐瀑,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了插爹?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 40,124評論 0 277
  • 序言:老撾萬榮一對情侶失蹤赠尾,失蹤者是張志新(化名)和其女友劉穎力穗,沒想到半個月后,有當地人在樹林里發(fā)現了一具尸體气嫁,經...
    沈念sama閱讀 46,657評論 1 320
  • 正文 獨居荒郊野嶺守林人離奇死亡当窗,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 38,723評論 3 342
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現自己被綠了寸宵。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片崖面。...
    茶點故事閱讀 40,872評論 1 353
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖梯影,靈堂內的尸體忽然破棺而出巫员,到底是詐尸還是另有隱情,我是刑警寧澤甲棍,帶...
    沈念sama閱讀 36,533評論 5 351
  • 正文 年R本政府宣布简识,位于F島的核電站,受9級特大地震影響,放射性物質發(fā)生泄漏财异。R本人自食惡果不足惜倘零,卻給世界環(huán)境...
    茶點故事閱讀 42,213評論 3 336
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望戳寸。 院中可真熱鬧呈驶,春花似錦、人聲如沸疫鹊。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,700評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽拆吆。三九已至聋迎,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間枣耀,已是汗流浹背霉晕。 一陣腳步聲響...
    開封第一講書人閱讀 33,819評論 1 274
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留捞奕,地道東北人牺堰。 一個月前我還...
    沈念sama閱讀 49,304評論 3 379
  • 正文 我出身青樓,卻偏偏與公主長得像颅围,于是被迫代替她去往敵國和親伟葫。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 45,876評論 2 361

推薦閱讀更多精彩內容

  • 一、運輸層協議 網絡層只把分組發(fā)送到目的主機常拓,但是真正通信的并不是主機而是主機中的進程渐溶。傳輸層提供了進程間的邏輯通...
    MachinePlay閱讀 812評論 0 0
  • 運輸層協議概述 從通信和信息處理的角度看,運輸層向它上面的應用層提供通信服務墩邀,它屬于面向通信部分的最高層掌猛,同時也是...
    srtianxia閱讀 2,411評論 0 2
  • 一、基礎概念 服務對象:進程 功能:邏輯通訊 載體:報文段 工作環(huán)境:端系統(tǒng) 運輸層協議??TCP:為進程提供可靠...
    IT白閱讀 397評論 0 0
  • 計算機網絡-運輸層 運輸層協議概述 進程間的通信 運輸層向它上面的應用層提供通信服務眉睹,它屬于面向通信部分的最高層荔茬,...
    CandyTong_閱讀 495評論 0 1
  • 1.UDP和TCP的對比 UDP 和 TCP 是TCP/IP體系結構運輸層中的兩個重要協議 當運輸層采用面向連接的...
    冰菓_閱讀 408評論 0 11