1.運輸層協(xié)議概述
1.進程之間的通信
- 從IP層來說越败，通信的兩端是兩臺主機。但是嚴格來講诗芜，兩臺主機之間的通信就是兩臺主機中的應(yīng)用進程相互通信。
- 從運輸層的角度埃疫，通信的真正端點并不是主機而是主機中的進程伏恐。也就是說，端到端的通信是應(yīng)用進程之間的通信栓霜。
1.網(wǎng)絡(luò)層和運輸層的區(qū)別
概括的來說翠桦，就是網(wǎng)絡(luò)層根據(jù)IP地址只能找到對應(yīng)的是哪臺主機，而運輸層能夠找到該主機上的具體哪個應(yīng)用進程進行通信胳蛮。
2.運輸層的作用
- 在一臺主機中經(jīng)常有多個應(yīng)用進程同時分別和另一臺主機中的多個應(yīng)用進程通信销凑，這就表明運輸層有一個很重要的功能——復(fù)用和分用。
- 根據(jù)應(yīng)用程序的不同需求仅炊，運輸層需要有兩種不同的運輸協(xié)議斗幼，即面向連接的TCP和無連接的UDP做祝。
3.基于端口的分用和復(fù)用功能
復(fù)用是在發(fā)送端實現(xiàn)的胞枕，把多個應(yīng)用進程的任務(wù)放在同一條信道上傳輸；分用是在接收端實現(xiàn)的殷绍。為了區(qū)分不同進程呆馁，還引入了端口號桐经，在復(fù)用和分用時都會用到，保證不會出現(xiàn)發(fā)送端的A進程的數(shù)據(jù)發(fā)送給接收端的B進程浙滤。
3.兩種不同的運輸協(xié)議
2.運輸層的兩個主要協(xié)議
- 兩個對等運輸實體在通信時傳送的數(shù)據(jù)單位叫做運輸協(xié)議數(shù)據(jù)單元TPDU阴挣。
- TCP傳送的數(shù)據(jù)單位協(xié)議是TCP報文段，UDP傳送的數(shù)據(jù)單位協(xié)議是UDP報文或UDP用戶數(shù)據(jù)報**瓷叫。
TCP和UDP：
3.運輸層的端口
- 運行在計算機中的進程使用進程標(biāo)識符來標(biāo)志的屯吊。
- 但運行在應(yīng)用層的各種應(yīng)用進程卻不應(yīng)當(dāng)讓計算機操作系統(tǒng)指派它的進程標(biāo)識符。因為計算機操作系統(tǒng)的多樣性摹菠，為了使運行不同操作系統(tǒng)的計算機的應(yīng)用進程能夠相互通信盒卸，必須用統(tǒng)一的方法對TCP/IP體系的應(yīng)用進程進行標(biāo)志。
解決這個問題的方法就是在運輸層使用協(xié)議端口號次氨。
1.軟件端口和硬件端口：
硬件端口是不同的硬件設(shè)備進行交互的接口蔽介，而軟件端口是應(yīng)用層的各種協(xié)議進程與運輸實體進行層間交互的一種地址。
- 在協(xié)議棧層間的抽象的協(xié)議端口是軟件端口煮寡。
- 路由器或交換機上的端口是硬件端口虹蓄。
2.TCP/IP運輸層端口
- 端口用一個16位端口號進行標(biāo)志。
- 端口號具有本地意義幸撕，即端口號只是為了標(biāo)志本計算機應(yīng)用層中的各個進程薇组。在互聯(lián)網(wǎng)中，不同計算機的相同端口號是沒有聯(lián)系的坐儿。由此可見律胀，兩個計算機中的進程要相互通信，不僅必須知道對方的IP地址(為了找到對方的計算機)貌矿，而且還要知道對方的端口號(為了找到對方計算機中的應(yīng)用進程)炭菌。
3.兩大類端口
- (1)服務(wù)器使用的端口號
熟知端口：1-1023
登記端口號：1024-49151，為沒有熟知端口號的應(yīng)用程序使用逛漫，使用這個范圍內(nèi)的端口號必須在IAN登記防止重復(fù)黑低。 - (2).客戶端使用的端口號
又稱為短暫端口，數(shù)值為49152-65535酌毡，留給客戶進程選擇暫時使用克握。
常用的熟知端口：
2.用戶數(shù)據(jù)報協(xié)議UDP
1.UDP概述
UDP只在IP數(shù)據(jù)報服務(wù)至上增加了很少一點功能：復(fù)用和分用，差錯檢測(對數(shù)據(jù)部分)阔馋。
1.UDP的主要特點
2.面向報文的UDP
- 發(fā)送方UDP對應(yīng)用程序交下來的報文玛荞，在添加首部后就向下交付IP層，UDP對應(yīng)用層交下來的報文呕寝，既不合并勋眯，也不拆分，而是僅僅添加一個UDP首部下梢，保留這些報文的邊界客蹋。應(yīng)用層交給UDP多長的報文，UDP就照常發(fā)送孽江，即一次發(fā)送一個報文讶坯。
- 接收方UDP對IP層交上來的UDP用戶數(shù)據(jù)，在去除首部后就原封不動地交付上層的應(yīng)用進程岗屏，一次交付一個完整的報文辆琅。另外漱办，應(yīng)用程序必須選擇合適大小的報文。報文太長的話婉烟，IP層在傳輸時可能要進行分片娩井，這會降低IP層的效率；報文太短似袁，IP層首部的相對長度太大洞辣，也會降低IP層的效率。
2.UDP的首部格式
源端口和目的端口字段就是用來復(fù)用和分用的昙衅；長度字段指的是整個UDP用戶數(shù)據(jù)報的長度扬霜；檢驗和字段是用來對數(shù)據(jù)部分進行差錯檢測的。偽首部僅僅是用來計算檢驗和的而涉，實際上并不會發(fā)送給接收方著瓶。
計算UDP檢驗和：
如上圖，在沒有計算得到檢驗和之前婴谱，首部的檢驗和字段全為0蟹但；UDP首部共8個字節(jié)，數(shù)據(jù)部分共7個字節(jié)谭羔，這與總長度15個字節(jié)相同說明正確华糖。在計算檢驗和的時候，我們把偽首部瘟裸，首部客叉，數(shù)據(jù)部分都劃分為16位(2個字節(jié))，因此當(dāng)數(shù)據(jù)部分不足2字節(jié)的整數(shù)倍時可以用0位進行填充话告。
3.傳輸控制協(xié)議TCP概述
1.TCP最主要的特點
- TCP是面向連接的運輸層協(xié)議兼搏。
- 每一條TCP連接只能有兩個端點，每一條TCP的連接只能是點對點的(一對一)沙郭。
- TCP提供可靠交付的服務(wù)佛呻。
- TCP提供全雙工通信。
-
面向字節(jié)流病线。
它的含義是雖然應(yīng)用程序和TCP的交互是一個數(shù)據(jù)塊吓著，但是TCP把應(yīng)用程序交下來的數(shù)據(jù)看成僅僅是一連串的無結(jié)構(gòu)的數(shù)字流。
TCP面向流的概念：
- TCP不保證接收方應(yīng)用程序所收到的數(shù)據(jù)塊和發(fā)送方應(yīng)用程序所發(fā)出的數(shù)據(jù)塊具有對應(yīng)大小的關(guān)系(可能被拆分或合并)送挑。
- 但接收方應(yīng)用程序收到的字節(jié)流必須和發(fā)送方應(yīng)用程序發(fā)出的字節(jié)流完全一樣绑莺。
注意，當(dāng)發(fā)送端發(fā)送數(shù)據(jù)到發(fā)送緩存中后惕耕，并不能一口氣將它們?nèi)堪l(fā)送出去纺裁，同樣的接收方在接收數(shù)據(jù)時也是將數(shù)據(jù)先放入接收緩存，如果接收緩存是滿的司澎，那么此時再發(fā)送進來的數(shù)據(jù)就會丟失欺缘。假設(shè)接收緩存中還能再接收2個字節(jié)的數(shù)據(jù)栋豫，那么如果發(fā)送緩存中的數(shù)據(jù)大于2個字節(jié)，不能全部發(fā)送谚殊，只能拆分發(fā)送笼才。當(dāng)發(fā)送緩存中的數(shù)據(jù)小于接收緩存中的最大數(shù)據(jù)量時，發(fā)送緩存中的數(shù)據(jù)就會合并一起發(fā)送出去络凿。其余的數(shù)據(jù)在發(fā)送緩存中等待下一次發(fā)送。等到接收緩存中的數(shù)據(jù)被讀取完了之后昂羡，發(fā)送緩存中的數(shù)據(jù)才發(fā)送絮记。
2.TCP的連接
- TCP把連接作為最基本的抽象。
- 每一條TCP連接有兩個端點虐先。
- TCP連接的端點不是主機怨愤，不是主機的IP地址，不是應(yīng)用進程蛹批，也不是運輸層的協(xié)議端口撰洗。而是套接字或插口。所謂套接字就是端口號拼接到IP地址后面就構(gòu)成了套接字腐芍。
注意差导，同一個IP地址可以有多個不同的TCP連接(多個不同的端口)，同一個端口也可以出現(xiàn)在多個不同的TCO連接中猪勇。
4.可靠傳輸?shù)墓ぷ髟?/h2>
1.停止等待協(xié)議
-
理想的傳輸條件有以下兩個特點：
(1).傳輸信道不產(chǎn)生差錯设褐。
(2).不管發(fā)送發(fā)以多快的速度發(fā)送數(shù)據(jù)，接收方總是來得及處理收到的數(shù)據(jù)泣刹。
- 再這樣的理想傳輸條件下助析，不需要采用任何措施就能夠實現(xiàn)可靠傳輸。
- 然而實際的網(wǎng)絡(luò)都不具備以上兩個理想條件椅您。必須使用一些可靠傳輸協(xié)議外冀，在不可靠的傳輸信道實現(xiàn)可靠傳輸。
(1).傳輸信道不產(chǎn)生差錯设褐。
(2).不管發(fā)送發(fā)以多快的速度發(fā)送數(shù)據(jù)，接收方總是來得及處理收到的數(shù)據(jù)泣刹。
"停止等待"就是每發(fā)送完一個分組就立即停止發(fā)送掀泳，等待對方確認之后再發(fā)送下一個分組(全雙工通信的雙方既是發(fā)送方又是接收方)雪隧。
1.無差錯情況
注意只需要發(fā)送方收到一次來自接收方的確認即可，不需要來回反復(fù)確認开伏。
2.出現(xiàn)差錯
當(dāng)A發(fā)送給B的分組出現(xiàn)比特差錯時膀跌，B就無法接收到正確的分組，也就不會發(fā)送確認給A固灵，A在沒有收到B的確認的情況下捅伤，也就不會繼續(xù)發(fā)送下一個分組。就這樣巫玻，B在等待A重新發(fā)送新的正確的分組丛忆，而A在等待B的確認祠汇，如果沒有外力干擾，它們會一直等待下去直到天荒地老合ü睿枯石爛??????(這種情況可以叫做死鎖)可很。因此就需要一個外力——超時器。如果超過了超時器規(guī)定的時間還沒收到確認凰浮，A就會重新發(fā)送一次分組——超時重發(fā)我抠。
當(dāng)出現(xiàn)分組丟失的情況(比如放在緩存中的分組被丟棄)，此時B根本就不知道A給自己發(fā)送過數(shù)據(jù)袜茧，那么也就不會發(fā)送確認菜拓，因此還是和前面一樣會出現(xiàn)發(fā)送方和接受方都在等對方的消息的情況，解決辦法還是超時器笛厦。
3.確認丟失和確認遲到
在上面說到的接收方B如果收到發(fā)送方A發(fā)送的分組之后會發(fā)送回一個確認纳鼎。那么這個確認在發(fā)送的過程中也會出現(xiàn)錯誤情況，例如確認丟失和確認遲到裳凸。
確認丟失：當(dāng)發(fā)送方A發(fā)送分組給B并且B收到之后贱鄙，B會發(fā)送一個確認給A，但是這個確認在途中碰到了問題姨谷，A沒有收到B的確認就不會發(fā)送下一個分組逗宁，因此A就會超時重發(fā)，重發(fā)的分組和這個之前的分組是一樣的梦湘。這里就有兩個問題：第一個分組我在第一次發(fā)送的時候已經(jīng)發(fā)送出去了疙剑，那我重發(fā)的分組(和之前的一樣)從哪來呢？践叠？言缤？解決辦法就是：當(dāng)A發(fā)送完第一個分組之后，不要丟棄它禁灼，而是保留它留著下一次超時重發(fā)的時候用管挟。另外一個問題時，在A超時重發(fā)后弄捕，B實際上是接收了兩次同一個分組僻孝，那么B該怎么去判斷兩次接收到的分組是否是重復(fù)的，又怎么判斷重發(fā)后的分組接受到了呢守谓？穿铆？？解決辦法：給每個分組編號斋荞，編號相同說明重復(fù)荞雏，我已經(jīng)正確接收過了，接收方就會不要重復(fù)的分組，但是同時必須給出一個確認凤优。那么問題又來了悦陋，這個多個確認我啷個曉得是不是來自同一個分組的確認呢？很簡單筑辨，還是編號就完事了俺驶。編號機制無敵。
確認遲到：B在發(fā)送確認的時候是"2G網(wǎng)"棍辕，太慢了導(dǎo)致A以為B沒接收到暮现，于是超時重發(fā)了，這下分組和確認會"碰頭"楚昭，結(jié)果第一次的確認還是很慢送矩，B都接收到A超時重發(fā)的分組，并發(fā)現(xiàn)重復(fù)丟棄之后再發(fā)送一個和第一次那個龜速的確認一樣的確認哪替，結(jié)果確認2先到，A收到確認2之后發(fā)送下一個分組菇怀，此時確認1來了凭舶，通過編號機制，A知道這個姍姍來遲的確認1和我剛才接收到的確認2是同一個分組的確認爱沟，于是舍棄了確認1帅霜。其實，確認1就相當(dāng)于沒發(fā)一樣呼伸，一點用都沒有身冀，因為它太慢了！＠ㄏ怼搂根！還有應(yīng)該注意一點，超時計時器的重傳時間應(yīng)當(dāng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r間更長一點铃辖。
自動重傳請求ARQ：
自動重傳請求ARQ：在上面的例子中剩愧，A重傳的原因從來都不是B向A發(fā)送了重傳請求，而是A在超時重傳時間后自動重傳娇斩。
4.信道利用率
停止等待協(xié)議的優(yōu)點是簡單仁卷，缺點是信道利用率太低。
A正確發(fā)送一個分組到B確認收到A可以發(fā)送下一個分組所經(jīng)過的時間包括四部分犬第，(1).A將分組發(fā)送到信道上的發(fā)送時延TD锦积；(2).分組從A發(fā)送到B的傳播時延；(3).確認從B發(fā)送到信道上的發(fā)送時延TA歉嗓；(4).確認從B發(fā)送到A的傳播時延丰介；，其中(2)(4)合起來就是往返時間RTT。在上述過程中真正有數(shù)據(jù)發(fā)送到信道上的時間為TD基矮，因此信道利用率很低淆储。若出現(xiàn)重傳，則對于傳送有用的數(shù)據(jù)信息來說家浇，信道利用率更低(TD/TD+RTT+TD+RTT+TA)本砰。
5.流水線傳輸
2.連續(xù)ARQ協(xié)議
在通信雙方A，B中都有兩個窗口钢悲，發(fā)送窗口和接收窗口点额。發(fā)送方可以不必等待確認而連續(xù)發(fā)送分組，只要是在發(fā)送窗口中的分組都能連續(xù)發(fā)送出去莺琳，而連續(xù)發(fā)送的分組的個數(shù)是由接收方?jīng)Q定的(因為要考慮接收方的接收能力)还棱。如下圖：
連續(xù)ARQ協(xié)議的工作原理
在(a)圖中，發(fā)送窗口中的1-5號分組都位于發(fā)送窗口內(nèi)惭等，因此是都可以連續(xù)發(fā)送的珍手。當(dāng)1號分組發(fā)送出去并且A接收到B發(fā)回來的確認之后，發(fā)送窗口就會往前移(滑)動一個分組的位置(因為你既然已經(jīng)接收到1號分組了辞做，這個分組再保留就沒有任何意義了)琳要。另外，還有一個機制叫做累計確認：
累計確認
所謂的累計確認就是位于發(fā)送窗口的一組分組全部接收到了之后才發(fā)送一個確認秤茅。表示在此之前的分組我都收到了稚补。下一次的分組發(fā)送從這一組的后一個開始發(fā)送。累計確認的優(yōu)點就是當(dāng)我收到3號分組的確認之后框喳，發(fā)送方就認為在3號分組之前的分組全部已經(jīng)正確接收到了课幕，因此即使2號分組的確認丟失了也沒關(guān)系。當(dāng)然按序到達的最后一個分組的確認千萬不能丟失五垮。否則發(fā)送方就會重新發(fā)送這個分組乍惊，累計確認的缺點就在這里體現(xiàn)。另外放仗，它還存在一個機制污桦，回退缤谎。就是如果發(fā)送方發(fā)送的前5個分組中的第3個分組丟失了蚕愤，這時接收方只能對前兩個分組發(fā)出確認，發(fā)送方無法知道后面三個分組的下落台汇，因此只好把后三個都重傳一遍亭姥，這就叫做回退稼钩，表示需要向后退回重傳已經(jīng)發(fā)送過的N個分組。
5.TCP報文段的首部格式
源端口和目的端口字段：各16位达罗，源端口用來實現(xiàn)復(fù)用坝撑，目的端口用來實現(xiàn)分用静秆；序號字段：4個字節(jié)，就是之前說的編號機制巡李，TCP連接中傳送的數(shù)據(jù)流中的每一個字節(jié)都編上一個序號抚笔，首部中的序號字段指的就是第一個字節(jié)的序號；確認號字段：4個字節(jié)侨拦，是期望收到的對方的下一個報文段的數(shù)據(jù)的第一個字節(jié)的序號殊橙；數(shù)據(jù)偏移字段：即首部長度，4位狱从，指的是數(shù)據(jù)部分起始處距離整個報文的起始處間的距離膨蛮，計算單位是4個字節(jié)；保留字段：6位季研，保留為今后使用目前置為0敞葛；
緊急URG：當(dāng)URG=1時，表明報文段中有緊急數(shù)據(jù)与涡，這些數(shù)據(jù)需要優(yōu)先傳送惹谐，當(dāng)然還需要知道緊急數(shù)據(jù)的位置的話光靠這個字段是不夠的，還需要緊急指針驼卖。
確認ACK：當(dāng)ACK=1時氨肌，確認號字段(ack)才有效；ACK=0時款慨，確認號無效。
推送PSH：當(dāng)接收到TCP=1的報文段就應(yīng)該盡快交付不必要等緩存填滿再交付谬莹。
復(fù)位RST：當(dāng)RST=1時檩奠，表明TCP連接中出現(xiàn)嚴重差錯，必須釋放連接再重新連接附帽。
同步SYN：當(dāng)SYN=1時埠戳，表明這是一個連接請求或者連接接收報文。
種植FIN：用來釋放一個連接蕉扮。FIN=1表示此報文段發(fā)送端的數(shù)據(jù)已經(jīng)發(fā)送完畢整胃，要求釋放連接。
窗口字段：2字節(jié)喳钟，用來讓對方設(shè)置發(fā)送窗口的依據(jù)屁使，也就是接收窗口的大小奔则；檢驗和字段：2字節(jié)蛮寂，檢驗的部分包括首部和數(shù)據(jù)部分；緊急指針字段：16位易茬，指出緊急數(shù)據(jù)共多少字節(jié)酬蹋，放在本報文段數(shù)據(jù)的最前面及老；選項字段：長度可變，MSS是TCP報文段中的數(shù)據(jù)字段的最大長度范抓；
對于MSS骄恶，一般情況應(yīng)該控制在范圍(64B-14B-4B-20B)-(1500B-18B)內(nèi)，14B和4B是幀首幀尾匕垫，20B的IP層首部僧鲁，1500B是I層最大長度MTU，MTU還會因為網(wǎng)絡(luò)的不同而不同年缎。
6.TCP可靠傳輸?shù)膶崿F(xiàn)
1.以字節(jié)為單位的滑動窗口
- TCP的滑動窗口是以字節(jié)為單位的悔捶。
- 現(xiàn)假定A收到了B發(fā)來的確認報文，其中窗口值是20字節(jié)单芜，而確認號是31(這表明B期望收到的下一個序號是31)蜕该，而到序號30為止的數(shù)據(jù)已經(jīng)接收到了)。
- 根據(jù)這兩個數(shù)據(jù)洲鸠，A就構(gòu)造出自己的發(fā)送窗口(從31號開始堂淡，到50結(jié)束共20字節(jié))。
發(fā)送窗口的起始位置叫做后沿扒腕，結(jié)束位置叫做前沿绢淀。后沿只能前移或者不動，而前沿可以有三種行為：收縮瘾腰，不動和前移皆的。在收到確認之后，一般情況下后沿和前沿都會向前移動蹋盆，例如窗口值20费薄，確認號34。當(dāng)確認號34而窗口值為17時栖雾，此時前沿不會移動楞抡。同理，當(dāng)窗口值更小之后析藕，前沿就會向后收縮召廷。
在上圖中，A發(fā)送了11字節(jié)的數(shù)據(jù)账胧。這位于發(fā)送窗口中的11字節(jié)數(shù)據(jù)不能馬上移出發(fā)送窗口竞慢，因為可能發(fā)送出去的分組會超時以便于重傳。還有另外9個字節(jié)的數(shù)據(jù)允許發(fā)送但沒被發(fā)送治泥。這樣發(fā)送窗口中的數(shù)據(jù)就被分為了兩類數(shù)據(jù)梗顺，分別給三個臨界點標(biāo)注P1，P2车摄，P3這三個指針寺谤。P3-P2也可以稱為可用窗口仑鸥。當(dāng)可用窗口的數(shù)據(jù)長度為0時，說明整個發(fā)送窗口的數(shù)據(jù)已經(jīng)被全部發(fā)送出去变屁，如果此時還沒有收到確認眼俊，必須停止繼續(xù)發(fā)送直到收到確認為止。
發(fā)送緩存：
發(fā)送方的應(yīng)用進程把字節(jié)流寫入TCP緩存粟关。發(fā)送窗口僅僅是發(fā)送緩存中的一部分疮胖。如上圖中，粉色部分就是已經(jīng)發(fā)送但未收到確認的數(shù)據(jù)闷板，藍色部分就是允許發(fā)送但是尚未發(fā)送的數(shù)據(jù)澎灸，灰色部分就是不允許發(fā)送的數(shù)據(jù)，它沒有在發(fā)送窗口中遮晚。
發(fā)送緩存用來暫時存放：發(fā)送應(yīng)用程序傳送給發(fā)送方TCP準(zhǔn)備發(fā)送的數(shù)據(jù)性昭；TCP已經(jīng)發(fā)送出但尚未收到確認的數(shù)據(jù)。
接收緩存：
接收方的應(yīng)用程序從TCP的接收緩存中讀取字節(jié)流县遣。接收窗口僅僅是接收緩存中的一部分糜颠。如上圖中，粉色部分就是已收到的并讀取的數(shù)據(jù)萧求，藍色部分就是已收到未讀取的部分其兴。藍色部分中的一點粉色部分就是未按序到達的數(shù)據(jù)。接收緩存用來暫時存放：按序到達夸政，但尚未被接收應(yīng)用程序讀取的數(shù)據(jù)元旬；不按序到達的數(shù)據(jù)。
- A的發(fā)送窗口并不總是和B的接收窗口一樣大守问，因為有一定的時間滯后(單程的傳播延遲)匀归。因為A只有在發(fā)送連接請求之后并收到確認，再根據(jù)B的接收窗口來確定自己的發(fā)送窗口酪碘。
- TCP標(biāo)準(zhǔn)沒有規(guī)定對不按序到達的數(shù)據(jù)應(yīng)如何處理朋譬。通常是先臨時存放在接收窗口中盐茎，等到字節(jié)流中所缺少的字節(jié)收到后兴垦，再按序交付上層。
- TCP要求接收方必須有累計確認的功能字柠，這樣可以減小傳輸開銷探越。
注意，接收方發(fā)送確認可以有兩種方式窑业，第一種最常見的就是正常的發(fā)送確認钦幔，第二種就是捎帶確認，也就是在下一次自己要發(fā)送數(shù)據(jù)的時候捎帶上確認常柄。
2.超時重傳時間的選擇
重傳時間的選擇時TCP最復(fù)雜的問題之一鲤氢，這個時間一般比往返傳播時延稍長一點搀擂，并且往返傳播時延很難確認，也就是往返時延的方差很大卷玉。另外哨颂，由于發(fā)送方對接收方發(fā)來的確認無法分別出到底是第一次發(fā)送的的確認還是重傳后的確認，因此往返時延變得很難確定與計算相种。
3.選擇確認SACK
當(dāng)發(fā)送方發(fā)送數(shù)據(jù)1,2,4,5威恼，而3在途中丟失的情況下，接收方無法給出數(shù)據(jù)3的確認寝并，但是數(shù)據(jù)4,5的確認已經(jīng)被發(fā)送方給接收了箫措。因此在發(fā)送方會找不到數(shù)據(jù)3以數(shù)據(jù)3后面的數(shù)據(jù)，會選擇從3開始往后全部重傳衬潦，怎么避免這樣的問題斤蔓，使得只重傳第3個數(shù)據(jù)。方法就是：選擇確認别渔。
例如上圖附迷，前1-1000位的是連續(xù)的字節(jié)流，按照累計確認的原則哎媚，只要接收到第1000位的確認喇伯，就認為前1000位全部接收到了。但是后面并不是連續(xù)的字節(jié)流了拨与，而是不連續(xù)的字節(jié)塊稻据。每一個字節(jié)塊都有左右兩個邊界。
選擇確認SACK
7.TCP的流量控制
之前說過發(fā)送方發(fā)送數(shù)據(jù)的速度取決于接收方能夠接收的速度买喧。一旦當(dāng)發(fā)送方的發(fā)送速度過快時捻悯，接收方就會來不及接收，那么就可能造成數(shù)據(jù)的丟失淤毛，這個傳輸就不可靠了今缚。流量控制就是接收方告訴發(fā)送方，你發(fā)送的數(shù)據(jù)太快了我來不及接收低淡。這個時候就要用到滑動窗口姓言。
1.利用滑動窗口實現(xiàn)流量控制
例如上圖，首先B會發(fā)送給A自己的接收窗口大小為400蔗蹋，確認號為1(就是起始位置)何荚，A收到之后就開始構(gòu)建自己的發(fā)送窗口，其起始位置就是確認號1猪杭，長度就是400餐塘。將位于發(fā)送窗口中的400個字節(jié)的數(shù)據(jù)分為4個TCP報文段，每個100長度皂吮。這些數(shù)據(jù)都位于發(fā)送窗口內(nèi)戒傻，因此都是可以連續(xù)發(fā)送的税手。假設(shè)第三個報文段(序號為201)在傳輸過程中丟失了，那么B就會給A發(fā)送一個確認需纳，內(nèi)容就是在201之前的數(shù)據(jù)我全部已經(jīng)接收到了冈止，接下去你給我發(fā)送從201開始的數(shù)據(jù)，而且接收窗口的大小調(diào)整為300(這里就是流量控制)候齿，因此發(fā)送窗口中的數(shù)據(jù)可以被劃分為3個TCP報文段熙暴，分別是序號201,301,401。等到A將這3個報文段的數(shù)據(jù)全部發(fā)送完了之后慌盯，就會停下來等B的確認然后再次發(fā)送數(shù)據(jù)周霉。所以，整個過程就是建立鏈接亚皂，確定發(fā)送窗口俱箱，發(fā)送數(shù)據(jù)，確定發(fā)送窗口灭必，發(fā)送數(shù)據(jù)...狞谱，發(fā)送窗口是在不斷的調(diào)整的，也就是流量控制禁漓。直到A的發(fā)送窗口變?yōu)?跟衅，假如過一段時間后B又發(fā)送給A報文，窗口不為0播歼，但是這個報文在傳輸過程中丟失了伶跷，那么就會導(dǎo)致A在等B的不為0的發(fā)送窗口報文，B在等A重新發(fā)送數(shù)據(jù)(B以為自己發(fā)送的報文A接受到了實際上是丟失了)這樣的死鎖局面秘狞。
持續(xù)計時器
2.TCP的傳輸效率
8.TCP的擁塞控制
就好比你去食堂打飯叭莫，窗口只有10個，但人數(shù)卻有1000烁试，因此好多人就得排隊等待雇初，這個時候假如增加幾個凳子，那么等待的人可以坐下來等不會很累减响，但是增加凳子這個做法對于提高打飯速度沒有任何幫助靖诗，另外如果你多開幾個窗口，也不會提高打飯速度辩蛋，你還必須要多配幾個打飯人員才行呻畸。這就說明了網(wǎng)絡(luò)擁塞是一個非常復(fù)雜的問題移盆，它是由許多因素引起的悼院，并不能通過簡單的增加某個資源量來解決這個問題，甚至?xí)鸬椒醋饔?/strong>咒循。
擁塞控制和流量控制的區(qū)別：
擁塞控制所起的作用：
如上圖据途，理想的擁塞控制的前半段曲線就是y=x绞愚，即有多少數(shù)據(jù)流入網(wǎng)絡(luò)就有多少數(shù)據(jù)流出網(wǎng)絡(luò)，這樣不會對網(wǎng)絡(luò)上的設(shè)備造成過大的負載颖医。
1.擁塞控制的一般原理
- 實踐證明位衩，擁塞控制是很難設(shè)計的，因為它是一個動態(tài)的（而不是靜態(tài)的）問題熔萧。
- 當(dāng)前網(wǎng)絡(luò)正朝著高速化的方向發(fā)展糖驴，這很容易出現(xiàn)緩存不夠大而造成分組的丟失。但分組的丟失是網(wǎng)絡(luò)發(fā)生擁塞的征兆而不是原因佛致。擁塞的原因是對資源的需求量超過了現(xiàn)有的資源量贮缕。
- 在許多情況下，甚至正是擁塞控制本身成為引起網(wǎng)絡(luò)性能惡化甚至發(fā)生死鎖的原因俺榆。這點應(yīng)特別引起重視感昼。
檢測網(wǎng)絡(luò)的擁塞的指標(biāo)：
- 由于缺少緩存空間而被丟棄的分組的百分數(shù)；
- 平均隊列長度罐脊；
- 超時重傳的分組數(shù)定嗓；
- 平均分組時延；
- 分組時延的標(biāo)準(zhǔn)差萍桌，等等宵溅。
2.TCP的擁塞控制方法
1.概述
TCP 采用基于窗口的方法進行擁塞控制。TCP發(fā)送方維持一個擁塞窗口CWND(Congestion Window)上炎。
- 擁塞窗口的大小取決于網(wǎng)絡(luò)的擁塞程度层玲，并且動態(tài)地在變化。
- 發(fā)送端利用擁塞窗口根據(jù)網(wǎng)絡(luò)的擁塞情況調(diào)整發(fā)送的數(shù)據(jù)量反症。
- 所以辛块，發(fā)送窗口大小不僅取決于接收方公告的接收窗口，還取決于網(wǎng)絡(luò)的擁塞狀況铅碍，所以真正的發(fā)送窗口值為：Min(公告窗口值润绵，擁塞窗口值)
2.控制擁塞窗口的原則
控制擁塞窗口的原則就是：只要網(wǎng)絡(luò)沒有出現(xiàn)擁塞，擁塞窗口就可以增大一點胞谈，以便把更多的分組發(fā)送出去尘盼，這樣就可以提高網(wǎng)絡(luò)的利用率。但只要網(wǎng)絡(luò)出現(xiàn)擁塞或有可能出現(xiàn)擁塞烦绳，就必須把擁塞窗口減小一些卿捎，以減少注入到網(wǎng)絡(luò)中的分組數(shù)，以便緩解網(wǎng)絡(luò)出現(xiàn)的擁塞径密。
3.擁塞的判斷
-
重傳定時器超時
現(xiàn)在通信線路的傳輸質(zhì)量一般都很好午阵，因傳輸出差錯而丟棄分組的概率是很小的(遠小于1%)，只要出現(xiàn)了超時，就可以猜想網(wǎng)絡(luò)可能出現(xiàn)了擁塞底桂。 -
收到三個重復(fù)確認
個別報文段會在網(wǎng)絡(luò)中丟失植袍，預(yù)示可能會出現(xiàn)擁塞(實際未發(fā)生擁塞)，因此可以盡快采取控制措施籽懦，避免擁塞于个。
4.TCP擁塞控制算法
- 慢開始 (slow-start)
- 擁塞避免 (congestion avoidance)
- 快重傳 (fast retransmit)
- 快恢復(fù) (fast recovery)
慢開始 (slow-start)
慢開始 (slow-start)
慢開始 (slow-start)
慢開始中擁塞窗口的值增加的非常快暮顺，指數(shù)增長厅篓，因此當(dāng)增大到一定程度之后就需要降低它的增速，但它還是在增長捶码。這個值就是慢開始門限ssthresh贷笛，用來防止擁塞窗口cwnd增長過大引起網(wǎng)絡(luò)擁塞。具體用法如下：當(dāng)cwnd<ssthresh時宙项，使用慢開始算法乏苦；當(dāng)cwnd>ssthresh時，停止使用慢開始算法而改用擁塞避免算法尤筐；當(dāng)cwnd=ssthresh時汇荐，既可使用慢開始算法，也可使用擁塞避免算法盆繁。
擁塞避免 (congestion avoidance)
擁塞避免算法：讓擁塞窗口 cwnd 緩慢地增大掀淘，即每經(jīng)過一個往返時間 RTT 就把發(fā)送方的擁塞窗口 cwnd 加 1，而不是加倍油昂，使擁塞窗口 cwnd 按線性規(guī)律緩慢增長革娄。
當(dāng)網(wǎng)絡(luò)出現(xiàn)擁塞時，就執(zhí)行：ssthresh = max(cwnd/2冕碟，2)拦惋；cwnd = 1；執(zhí)行慢開始算法安寺。這樣做的目的就是要迅速減少主機發(fā)送到網(wǎng)絡(luò)中的分組數(shù)厕妖，使得發(fā)生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢菠剩。
擁塞避免算法舉例
如上圖宏蛉，剛開始擁塞窗口值為1惩激，慢開始門限為16舔示，然后每經(jīng)過一個輪次，擁塞窗口的值就翻一倍1-2-4-8-16绽淘，等到擁塞窗口的值變?yōu)?6時箕别，即等于慢開始門限時躯舔，執(zhí)行擁塞避免算法凳枝，之后擁塞窗口+1按線性規(guī)律增長抄沮，到了24之后發(fā)現(xiàn)此時網(wǎng)絡(luò)出現(xiàn)擁塞情況，于是，將擁塞窗口的值/2=12合是，12就是更新之后的慢開始門限，而擁塞窗口的值重新被置為1锭环，再執(zhí)行慢開始算法聪全。
快重傳 (fast retransmit)
采用快重傳FR (Fast Retransmission) 算法可以讓發(fā)送方盡早知道發(fā)生了個別報文段的丟失，也就是在超時重傳的時間之前就進行告知辅辩∧牙瘢快重傳算法首先要求接收方不要等待自己發(fā)送數(shù)據(jù)時才進行捎帶確認，而是要立即發(fā)送確認玫锋，即使收到了失序的報文段也要立即發(fā)出對已收到的報文段的重復(fù)確認蛾茉。發(fā)送方只要一連收到三個重復(fù)確認(因為累積確認只需要對按序到達的最后一個分組進行確認，而下圖例子中的按序的最后一個分組是M2)撩鹿，就知道接收方確實沒有收到報文段谦炬，因而應(yīng)當(dāng)立即進行重傳(即“快重傳”)，這樣就不會出現(xiàn)超時节沦，發(fā)送方也不就會誤認為出現(xiàn)了網(wǎng)絡(luò)擁塞键思。如下圖：
快重傳舉例
快恢復(fù) (fast recovery)
當(dāng)發(fā)送端收到連續(xù)三個重復(fù)的確認時，由于發(fā)送方現(xiàn)在認為網(wǎng)絡(luò)很可能沒有發(fā)生擁塞甫贯，因此現(xiàn)在不執(zhí)行慢開始算法吼鳞，而是執(zhí)行快恢復(fù)算法 FR (Fast Recovery) 算法：(1) 慢開始門限 ssthresh = 當(dāng)前擁塞窗口 cwnd / 2 ；(2) 新?lián)砣翱?cwnd = 慢開始門限 ssthresh (這里和慢開始算法不同的就是新的擁塞窗口并不是變?yōu)?叫搁，這樣省去了前面慢開始算法的幾個輪次)赔桌；(3) 開始執(zhí)行擁塞避免算法，使擁塞窗口緩慢地線性增大渴逻。
5.加法增大疾党，乘法減小
6.TCP擁塞控制流程圖
7.發(fā)送窗口的上限值
3.主動隊列管理AQM
1.先進先出FIFO處理規(guī)則
2.全局同步
所謂的主動隊列管理AQM就是不要等到路由器的隊列長度已經(jīng)達到最大值時才不得不丟棄后面到達的分組惨奕。這樣就太被動了仿贬。應(yīng)當(dāng)在隊列長度達到某個值得警惕的數(shù)值時(即當(dāng)網(wǎng)絡(luò)擁塞有了某些擁塞征兆時)，就主動丟棄到達的分組墓贿。AQM 可以有不同實現(xiàn)方法茧泪，其中曾流行多年的就是隨機早期檢測RED(Random Early Detection)。
3.隨機早期檢測RED
9.TCP的運輸連接管理
1.TCP的連接建立
1.TCP建立連接的過程中要解決的三個問題：
- (1) 要使每一方能夠確知對方的存在聋袋。
- (2) 要允許雙方協(xié)商一些參數(shù)(如最大窗口值队伟、是否使用窗口擴大選項和時間戳選項以及服務(wù)質(zhì)量等)。
- (3) 能夠?qū)?strong>運輸實體資源
2.客戶-服務(wù)器方式
- TCP連接的建立采用客戶-服務(wù)器方式。
- 主動發(fā)起連接建立的應(yīng)用進程叫做客戶(client)。
- 被動等待連接建立的應(yīng)用進程叫做服務(wù)器(server)锈颗。
3.握手
- TCP建立連接的過程叫做握手顷霹。
- 握手需要在客戶和服務(wù)器之間交換三個TCP報文段，稱之為三報文握手击吱。
- 采用三報文握手主要是為了防止已失效的連接請求報文段突然又傳送到了淋淀，因而產(chǎn)生錯誤(就是假設(shè)第一次發(fā)送的請求沒有按時到，等到兩臺主機都發(fā)送完數(shù)據(jù)了才到而造成再次連接)覆醇。
x+1的原因是因為請求建立連接的報文和確認報文不能攜帶數(shù)據(jù)朵纷，反而會消耗一個序號的數(shù)據(jù)。另外永脓，建立連接時袍辞，客戶端和服務(wù)器端并不是同步的。有一定的時延常摧。
2.TCP的連接釋放
- TCP連接釋放過程比較復(fù)雜
- 數(shù)據(jù)傳輸結(jié)束后搅吁，通信的雙方都可以釋放連接。
- TCP連接釋放過程是四報文握手(因為通信是雙向的落午，通信的雙方都可以釋放連接似芝，而每一條連接斷開需要一個請求和一個確認)
假設(shè)現(xiàn)在A要給B發(fā)送的數(shù)據(jù)都已經(jīng)發(fā)送完了，那么A就可以斷開與B的連接板甘，此時A就會向B發(fā)送一個連接釋放請求報文党瓮，其中的
FIN字段=1 ，seq=u就是A發(fā)送給B的最后一個數(shù)據(jù)的序號盐类。這個連接釋放請求報文不能攜帶數(shù)據(jù)但是會消耗掉一個序號寞奸，因此B發(fā)回的確認號為u+1，等到A收到確認在跳，此時A到B的這條通信已經(jīng)斷開了枪萄，即A不能向B的發(fā)送數(shù)據(jù)了。但是B到A的通信連接還沒斷猫妙，B還能給A發(fā)送數(shù)據(jù)瓷翻。此時TCP的連接處于半關(guān)閉的狀態(tài)。同時等到B發(fā)送完數(shù)據(jù)之后也需要斷開連接時割坠，過程同A斷開連接一樣齐帚。當(dāng)B收到A的確認之后B就會馬上進入CLOSED狀態(tài)，但是A發(fā)回確認之后還需要等待2MSL的時間彼哼，這個時間通常是單程傳播時延对妄。為什么要等待2MSL時間？
A必須等待2MSL時間
