正文
1. TCP與UDP:
在網(wǎng)絡(luò)體系結(jié)構(gòu)中我們提過TCP/IP的四層網(wǎng)絡(luò)層級:
而TCP(Transmisson Control Protocol,即傳輸控制協(xié)議)和UDP(User Datagram Protocol 即用戶數(shù)據(jù)報協(xié)議)是在傳輸層的,所以我們知道UDP和TCP是用來傳輸數(shù)據(jù)的一種協(xié)議副硅,為主機中不同進程提供通信屋摇,那既然是傳輸數(shù)據(jù)羞迷,我們舉例以快遞盒寄信的邏輯來說明猴凹。
TCP像快遞揽思,寄快遞現(xiàn)在都有物流信息悉抵,最后是否簽收了我的快遞肩狂。如果丟件也會通知給你反饋。而UDP更像寄信姥饰,收不收得到我也不管傻谁。
對比與UDP,TCP的傳輸是可靠的媳否、無差錯的栅螟。
1.1 TCP通道的連接及斷開
既然數(shù)據(jù)是從一個地方到另一個地方,我們要先建立一個通道篱竭,這樣數(shù)據(jù)才能傳輸流動力图。
TCP三次握手,四次揮手掺逼,這個就是用來建立這個通道及斷開通道吃媒。
三次握手:
- A發(fā)信息給B:你在不在啊吕喘?急事W改恰!
- B發(fā)信息給A:我在啊氯质,急事募舟?那你快告訴我,我這邊時刻聽著你說闻察。
不幸的是A這時候拉肚子拱礁,只能馬上跑去廁所了琢锋,然后一拉就是半個小時,然后B就一直等了半個小時呢灶。
這時候你是不是發(fā)現(xiàn)了二次握手的問題了吴超,如果第二次B發(fā)送給A的話后,A沒有馬上回相應(yīng)的信息給B鸯乃,B就可以認為A已經(jīng)不在了鲸阻,從而不再等它,也不建立通道缨睡。
所以應(yīng)該是這樣:
- A發(fā)信息給B:你在不在澳胥病?急事=蹦辍遣臼!
- B發(fā)信息給A:我在啊,急事拾并?那你快告訴我,我這邊時刻聽著你說鹏浅。
- A發(fā)信息給B:事情是這樣的嗅义。你聽我慢慢道來。
balabala.......
balabala.......
balabala.......
然后A和B之間的通道就通了隐砸,然后A這時候可以給B不停的發(fā)信息了之碗。
然后有人會問,TCP 又不會拉肚子季希,那TCP為啥要三次褪那,因為如果規(guī)定二次的話: A 發(fā)給B信息,申請建立通道式塌,因為網(wǎng)絡(luò)延遲博敬,B一直沒收到,這時候A等的不耐煩了峰尝,直接就退出了偏窝,但是過了一會兒B收到了這個信息,B以為A是剛發(fā)的請求武学,所以建立了通道祭往,但是A其實早就已經(jīng)不在了。這樣防止B形成死鎖火窒、浪費資源等硼补。
當(dāng)然上面是我們舉得例子,具體肯定是通過一些值來傳遞:具體的圖是這樣的:
四次揮手
我們知道TCP連接之后我們可以互相之間發(fā)消息了熏矿,這里假設(shè)通道里包含了兩個小通道已骇,一個是A發(fā)給B的离钝,一個是B發(fā)給A的,這樣當(dāng)我們斷開連接的時候有兩大步疾捍。
- 斷開A發(fā)給B信息的通道
- 斷開B發(fā)給A信息的通道
我們先看斷開A發(fā)給B信息的通道:
A發(fā)信息給B:我累了奈辰,我先睡了,88.
B發(fā)信息給A:好的乱豆,那你先睡吧奖恰。
這時候A就睡覺了,A也不會發(fā)信息給B了宛裕。但是這時候B還是可以繼續(xù)給A發(fā)信息瑟啃,B可能深夜突然來個深情告白
B發(fā)信息給A: 其實我XXXXXXXX。
所以單純二次揮手是不夠的揩尸,還要斷開B發(fā)給A信息的通道:
B發(fā)信息給A:不過你說你要睡了蛹屿,我覺得是比較晚了,我也要睡了岩榆,晚安错负。
A發(fā)信息給B: 那你也早點睡。晚安
所以連在一起是:
A發(fā)信息給B:我累了勇边,我先睡了犹撒,88.
B發(fā)信息給A:好的,那你先睡吧
B發(fā)信息給A:不過你說你要睡了粒褒,我覺得是比較晚了识颊,我也要睡了,晚安奕坟。
A發(fā)信息給B: 那你也早點睡祥款。晚安
剛開始是雙向通信,然后二次揮手后月杉,A到B的斷了刃跛,所以這時候變成單向的數(shù)據(jù)傳輸,然后再二次揮手沙合,把這個單向數(shù)據(jù)傳輸也關(guān)閉奠伪。
所以我們看到了TCP的連接和斷開都這么多步,多次確認等操作首懈,但是UDP是不需要先建立一個穩(wěn)定的通道绊率,直接就把數(shù)據(jù)發(fā)過去了。所以UDP更快究履,因為不用先去建立連接滤否。
1.2 TCP的無差錯傳輸
TCP為什么傳輸安全,UDP傳輸不安全最仑,TCP傳輸保證了數(shù)據(jù)最終能穩(wěn)定安全的到達目的地藐俺,而UDP只管發(fā)送出去炊甲,不管最終是否收到,具體原因是為啥欲芹?
發(fā)送端
對于發(fā)送端:每收到一個確認幀卿啡,發(fā)送窗口就向前滑動一個幀的距離。當(dāng)發(fā)送窗口內(nèi)無可發(fā)送幀時(即窗口內(nèi)的幀全是已發(fā)送但未收到確認的幀)菱父,發(fā)送方就會停止發(fā)送颈娜,直到接收方發(fā)送確認幀使窗口移動,窗口內(nèi)有可以發(fā)送的幀浙宜,之后才繼續(xù)發(fā)送 具體如下圖:
接收端:
對于接收端:當(dāng)收到數(shù)據(jù)幀后官辽,將窗口向前移動一個位置,并發(fā)回確認幀粟瞬,若收到的數(shù)據(jù)幀落在接收窗口之外同仆,則一律丟棄。
滑動窗口協(xié)議的重要特性
- 只有接收窗口向前滑動裙品、接收方發(fā)送了確認幀時俗批,發(fā)送窗口才有可能(只有發(fā)送方收到確認幀)向前滑動
- 停止-等待協(xié)議、后退N幀協(xié)議 & 選擇重傳協(xié)議只是在發(fā)送窗口大小和接收窗口大小上有差異市怎。
1.停止等待協(xié)議:發(fā)送窗口大小=1扶镀,接收窗口大小=1;即 單幀滑動窗口 等于 停止-等待協(xié)議
2.后退N幀協(xié)議:發(fā)送窗口大小>1焰轻,接收窗口大小=1。
3.選擇重傳協(xié)議:發(fā)送窗口大小>1昆雀,接收窗口大小>1辱志。
- 當(dāng)接收窗口的大小為1時,可保證幀有序接收狞膘。
- 數(shù)據(jù)鏈路層的滑動窗口協(xié)議中揩懒,窗口的大小在傳輸過程中是固定的(注意要與TCP的滑動窗口協(xié)議區(qū)別)