目錄
應(yīng)用層
傳輸層
udp 協(xié)議?
端口號
報文長度（udp 長度）
校驗和
TCP 協(xié)議
確認應(yīng)答
超時重傳
鏈接管理
滑動窗口
流量控制
擁塞控制
延時應(yīng)答
捎帶應(yīng)答
總結(jié)
我們第一章讓我們對網(wǎng)絡(luò)有了一個初步認識，第二章和第三章我們通過代碼感受了網(wǎng)絡(luò)通信程序。
而本章的 通信原理? 進一步了解網(wǎng)絡(luò)是如何實現(xiàn)工作的，本章主要以理論為主，本章的理論非常多，面試?？?，工作中也會常用，同時也非常抽象。
我們之前提到過的：由于復(fù)雜的網(wǎng)絡(luò)環(huán)境催生出了復(fù)雜的網(wǎng)絡(luò)協(xié)議，我們將這些復(fù)雜的協(xié)議拆分成 多種小協(xié)議；再將這些小協(xié)議進行分類可以分成不同的層級。
我們這一章將重點介紹應(yīng)用層和傳輸層，其他層了解即可。
應(yīng)用層
我們這里簡單介紹，后面介紹 http 協(xié)議的時候我們會重點介紹。
應(yīng)用層直接和代碼相關(guān)；直接決定了數(shù)據(jù)需要傳輸什么，接收方需要拿到那些數(shù)據(jù)，拿到后如何使用。
應(yīng)用層這一層中現(xiàn)存著一些現(xiàn)有的協(xié)議，比如HTTP協(xié)議，也可以是自己寫的協(xié)議；
我們最開始就聊到過微信發(fā)送消息的那個栗子，
這就是簡單的看一看，實際上遠比這個復(fù)雜的多，具體的如何實現(xiàn)呢？
需要根據(jù)需求去寫：
比如我們的微信小程序：美團外賣
需要傳輸哪些信息（根據(jù)需求）
?具體需求按照啥格式來組織（隨意約定）
具體的我們留在http 協(xié)議來細說。
傳輸層
再傳輸層中我們已經(jīng)認識了兩個協(xié)議 udp 和 tcp 協(xié)議。
我們先挑個軟柿子捏，捏完軟的我們再捏硬的。
udp 協(xié)議?
我們先來看看udp 報文結(jié)構(gòu)：
去網(wǎng)上copy 幾張下來：
這個是大部分計算機網(wǎng)絡(luò)教材上的圖，事實上這個圖其實并不準確，我們來畫一張實際的圖：
- 偽頭部 ： 只是為了提取 IP 數(shù)據(jù)報中的源IP，目的IP信息并加上協(xié)議等字段構(gòu)造的數(shù)據(jù)。在實際傳輸中并不會發(fā)送，僅起到校驗和計算使用，因此稱之為偽首部。
- 源端口號 : 一般是客戶端程序請求時,由系統(tǒng)自動指定,端口號范圍是 0 ~ 65535,0~ 1023為知名端口號。
- 目的端口 ： 一般是服務(wù)器的端口，一般是由編寫程序的程序員自己指定，這樣客戶端才能根據(jù)ip地址和 port 成功訪問服務(wù)器
- UDP 長度 ： 是指整個UDP數(shù)據(jù)報的長度 ， 包括 報頭 + 載荷，
- UDP校驗和 ： 用于檢查數(shù)據(jù)在傳輸中是否出錯，是否出現(xiàn)bit反轉(zhuǎn)的問題，當(dāng)進行校驗時，需要在UDP數(shù)據(jù)報之前增加臨時的 偽首部。
?我們看到上述的報頭都是兩個字節(jié)：都是 0 ~ 65535；
端口號
源端口、源IP? ?表示數(shù)據(jù)來自哪里
目的端口、目的IP? ? 表示數(shù)據(jù)要去哪里；
就像唐僧說的那樣：貧僧自東土大唐而來，到西天拜佛取經(jīng)。
我們的端口號一般小于 1024 的都別那些有名的大公司軟件用了；像我們耳熟能詳?shù)腗ySQL 它也才是 3306 ；如果非要用其實也沒事。
報文長度（udp 長度）
2個字節(jié)長度，也是 0 ~ 65535 也就是 64k 的大小，說大不大，說小也不算小。
為什么但是設(shè)計的時候，不設(shè)計大一些呢，這就是時代的局限了，換成當(dāng)年，64k 已經(jīng)非常大了，當(dāng)時的電腦內(nèi)存那才多少 M 啊；但是對于現(xiàn)在我們來說，64k 太小了，隨便一個小插件都不知64k。
因為電子元件的發(fā)展，64k 對我們來說太小了，隨便發(fā)一些數(shù)據(jù)都可能超過這個數(shù)字。
所以我在使用 udp 編程的時候，需要注意了，需要控制大小，不然超出這個大小就會出現(xiàn)一些不必要的問題。
校驗和
?在我們的網(wǎng)絡(luò)傳輸過程中，并非那么的穩(wěn)定，隨時都會出現(xiàn)問題，例如：受強磁產(chǎn)的作用，輻射，或者其他物理環(huán)境影響，都會造成網(wǎng)絡(luò)傳輸?shù)牟环€(wěn)定。
我們都知道，路由器、交換機之間傳輸?shù)氖歉?、低電平，轉(zhuǎn)換為 01 的二進制，那么在這些特殊情況就可能造成： 0 - 1 變?yōu)?： 1 - 0 ；我們把這種現(xiàn)象稱之為 比特翻轉(zhuǎn)。
所以，我們在此基礎(chǔ)上提出了：校驗和，就是用來判斷一下目前傳輸?shù)臄?shù)據(jù)時候發(fā)送了錯誤；但是這個校驗和不是 100% 正確的。
例如：
我們要去買菜：番茄、土豆、黃瓜、青菜； 一共是四種菜，我們買回來四種不一定正確，但是買回來不是 四種一定不正確。
- 校驗和正確，數(shù)據(jù)不一定是正確的，
- 但是檢驗和如果不正確，數(shù)據(jù)一定是不正確的
校驗和更多的用處不是“證實”，而是為了證偽，判斷數(shù)據(jù)是不是錯的
ok；說到這我們算是吧 udp 這個軟柿子捏完了，接下來到了難啃的硬骨頭：TCP / IP。
TCP 協(xié)議
我們之前講到過：
TCP 協(xié)議的特點：
- 有鏈接
- 可靠傳輸
- 全雙工
- 面向字節(jié)流
我們本章的重點在于 "可靠傳輸"
可靠不是說百分之百可靠，我們的可靠是盡可能傳輸過去，哪怕沒有傳輸過去，起碼需要讓對方知道自己沒有傳輸過去。
這個核心機制就來了：確認應(yīng)答、超時重傳 這個是確?？煽康暮诵模。?！
確認應(yīng)答
這個機制是實現(xiàn)可靠傳輸?shù)暮诵模?/p>
舉個栗子??：
我現(xiàn)在是個舔?? ，我向我女神發(fā)出一個邀請：能不能讓我陪她一起去游樂園玩玩。
那么她會回答一個 好 或者是 不好 。這就是答復(fù)，讓我知道她到底去不去。
接收方也一樣，接收方會返回一個 ACK報文（acknowledge）【應(yīng)答報文】；
但是在過去 發(fā)短信常常會出現(xiàn)一種狀況： 后發(fā)先至。
什么叫后發(fā)先至，舉個栗子??：
我向女神發(fā)出了兩個邀請：
邀請1：周六能不能讓我陪她去游樂園玩玩？
邀請2： 能不能做我女朋友？
她回答：
可以；
滾。
我接收到的 不一定是對方按順序發(fā)的；我收到的可能就是：滾 ；?可以。
這種情況就叫做后發(fā)先至。
在過去，這種情況也算是很普遍的，現(xiàn)在這類情況減少了，我們給 頭tcp 數(shù)據(jù)報添加了一個序號和確認序號，女神對應(yīng)的回答就是： 回答1：可以，回答2：滾！
那么此時我也是按順序接收到女神發(fā)送的消息。
真實的TCP 協(xié)議中也是有?序號和確認序號。
TCP 針對每個字節(jié)都進行了編號?。
我們來可靠 TCP 的報文結(jié)構(gòu)：
我們先不用去了解其他的結(jié)構(gòu)是什么意思，我們一步步來理解?。
?注意：
我們接受方返回的序列號與發(fā)送方無關(guān)，不是說你發(fā)送過來啥就返回啥；
而是返回發(fā)送過來的所有數(shù)據(jù)的下一個序號。
可以將這個返回的序號理解為：前n 個字節(jié)我已經(jīng)收到了，現(xiàn)在需要你從 n + 1 個字節(jié)開始發(fā)送。
為啥網(wǎng)絡(luò)傳輸中會出現(xiàn)這種后發(fā)先至的情況呢？
在網(wǎng)絡(luò)傳輸中不是兩個機器直接發(fā)送數(shù)據(jù)的，而是中間通過了多臺交換機和路由器，具體在這傳輸過程中是如何傳輸?shù)?，這就不得而知了。
但是沒關(guān)系，對我們的 tcp 來說，它本身自帶了一個 "?整隊 " 的任務(wù)，tcp 有個內(nèi)存緩沖區(qū)（本質(zhì)是內(nèi)核上的一塊地址），tcp 就可以按照序號針對收到的數(shù)據(jù)進行 " 整隊 " ;
這樣做只有一個目的：讓應(yīng)用程式讀到的和發(fā)送方有一樣的順序。
如果上述過程可以完整進行，那么網(wǎng)絡(luò)傳輸?shù)目煽啃源_實可以保證，但是在網(wǎng)絡(luò)傳輸過程中還有一個問題非常常見，那就是 " 丟包 "?
為啥會丟包呢？
我們在發(fā)送數(shù)據(jù)的整個過程中，會經(jīng)歷多個交換機和路由器，這些交換機和路由器不只是接收、發(fā)送這兩個設(shè)備的數(shù)據(jù)，還會有其他機器傳輸需要經(jīng)過它。
那么當(dāng)某個設(shè)備的流量達到峰值，就可能出現(xiàn)丟包現(xiàn)象。
這種情況下，丟誰的包，不知道，什么時候丟包，不知道！
這時，接收方?jīng)]收到包，就不會返回一個 ack ，那么這時就觸發(fā)了 tcp 協(xié)議的的第二個機制：超時重傳
超時重傳
發(fā)送方遲遲拿不到ack ，那么它也就反應(yīng)過來，可沒可能是發(fā)生丟包了呢？
不管是不是，發(fā)送方過一段時間就再發(fā)送一個，丟包只是個概率性事件，如果多次重傳，我們發(fā)生方還是沒有拿到ack ，那么大概率就是嚴重的網(wǎng)絡(luò)事故；此時我們發(fā)送方也不傻，每次重傳的延遲發(fā)送時間增加，增加到一定界限時，那么我們就會不發(fā)送，斷開網(wǎng)絡(luò)鏈接。可靠性指的是盡可能的傳輸過去。
我們丟包的情況有兩種，第一種發(fā)送的時候丟包，第二種返回ack 的時候丟包：
第一種情況，我們超時重傳就沒事了；
如果是第二種，那么就會出現(xiàn)問題，加入我們?nèi)ビ梦⑿鸥犊?，把錢付過去以后，返回時出現(xiàn)丟包，我們還需要付第二次款，那么此時：一份商品的價格我們付款了兩次，就會出現(xiàn)大問題。
主機B 出現(xiàn)大量重復(fù)數(shù)據(jù)，那么TCP協(xié)議需要能夠識別出那些包是重復(fù)的包，并且把重復(fù)的丟棄掉。
這時候我們可以利用前面提到的序列號，就可以很容易做到去重的效果。
TCP 幫我們處理好了這個問題，在接收緩存區(qū)中，我們根據(jù)收到的數(shù)據(jù)的序號，自動去重。? ? ? ? ? 保證程序讀到的數(shù)據(jù)只有唯一一份。
我們保證可靠性的最主要的機制就是： 確認應(yīng)答 和 超時重傳?！?。?！
千萬不要說是：三次握手和四次揮手?。。?！
這是雙方建立建立連接的機制，而不是保證可靠性的機制。
鏈接管理
建立鏈接：三次握手
斷開鏈接：四次揮手
我們來講講什么是三次握手，什么是四次揮手
三次握手：
握手（handshake）指的是通信雙方，進行一次網(wǎng)絡(luò)交互；三次握手就是通信雙方進行三次交互，從而建立鏈接。這里的鏈接就是雙方各自記錄對方的信息。
syn 表示同步報文段，意思就是客戶端要向服務(wù)器申請建立鏈接。
那么服務(wù)需要給個回信（應(yīng)答報文）：ack ，??
這就完成了客戶端對服務(wù)器的鏈接，但是服務(wù)器還需要對客戶端進行鏈接；
服務(wù)器向客戶端發(fā)送一個 syn ；然后客戶端要給服務(wù)器一個回信?ack。
?
我們一看，不對啊，這不是四次交互嗎？為什么要叫三次握手?。?/strong>
我們其實可以把 服務(wù)器發(fā)送給客戶端的 ack 和 syn 合并到一起，如：
我們可以拆分成四次，為什么需要將其何必為三次呢？
我們在前面說過，數(shù)據(jù)傳從發(fā)送端發(fā)送，要經(jīng)過層層封裝，接收端接收到數(shù)據(jù)要經(jīng)過層層分用，我們兩次發(fā)送和接收較于一次而言 效率更加低，耗時較長。
故此，最終成了三次握手了。
啥樣的報文叫做syn 報文呢？
我們回到之前講到的 TCP 報文結(jié)構(gòu)：
?這六個特殊的比特位默認是 0 ，如果變?yōu)榱?1 有其特殊的含義；
比如我們的ack 為1，就表示當(dāng)前TCP 報文是一個應(yīng)答報文。
如果 syn 為1，就表示當(dāng)前 TCP 報文是一個 同步報文。
那么我們?nèi)挝帐值闹虚g一次： 即使一個ack 又是一個 syn，就可以把這兩位 同時設(shè)為 1；
那么我們?nèi)挝帐制鸬搅耸裁醋饔媚兀?/p>
三次握手的本質(zhì)就是投石問路，驗證了客戶端和服務(wù)器之間各自的發(fā)送能力和接收能力是否正常。
四次揮手
三次握手的作用是建立鏈接，四次揮手的作用是斷開鏈接。
通訊雙方各自給對方發(fā)送一個fin（結(jié)束報文），再各自返回ack；
如圖：
?建立鏈接一定是由客戶端主動的，斷開連接雙發(fā)都可以主動，服務(wù)器有時也是會崩潰的。
我們這里四次揮手很像三次握手啊，這里中間的 ack 和 fin 是否可以像三次握手一樣合并為一次呢？
三次握手中 fin 和 ack 都是由內(nèi)核態(tài)來完成的（同一時刻）；
而四次揮手是不同時機觸發(fā)的：
服務(wù)器第一次收到了 fin 立馬就返回了一個 ack ，而要向客戶端發(fā)送fin 則要看代碼執(zhí)行（執(zhí)行close 方法時才觸發(fā)發(fā)送fin）。
如果是客戶端斷開連接了，服務(wù)器立馬也斷開連接（執(zhí)行close 方法），那么乘著 服務(wù)器還沒有發(fā)送 ack ，此時可以合并。
具體的得看代碼怎么寫。
來看看三次握手和四次揮手的中間傳輸?shù)倪^程：
?這種圖網(wǎng)上一搜一大把，
我們?nèi)绻嬖囈獑柕臅r候就畫中間的部分：
其他的畫對了不加分，畫錯了就扣分，吃力不討好?
我們 tcp 到這里就結(jié)束了嗎？只能說這種想法太天真了，我們才剛剛開始。
我們目前認識了三個：確認應(yīng)答，超時重傳 ，這兩個特性保證了 tcp 傳輸?shù)目煽啃裕绘溄庸芾砭褪峭妒瘑柭?，也和可靠性有點關(guān)系，但關(guān)系不大。
我們接下來要在保證可靠性的前提下，盡可能地提高效率??！
滑動窗口
按照我們先前提到的方式去傳輸數(shù)據(jù)，每次都只傳輸幾個字節(jié)，這樣效率就非常低了。
所以我們的 tcp 還需要在保證可靠的情況下，還需要盡可能的保證效率。
那么如何提高效率呢？
如上圖，我們的主機A 一直在等待主機B 傳輸回來的 ack 。
想要提高效率可以從縮減等待時間下手：批量發(fā)送數(shù)據(jù)（一次性發(fā)送多條數(shù)據(jù)，一次等待多個ack）。
上圖這個過程就稱之為滑動窗口。我們這里用一次等待時間接收了四個 ack 。
收到這個 ack 就發(fā)送下一組數(shù)據(jù)，這樣等待時間減少了，整體的效率就提高了。
相比之下，其實 udp 的效率還要快，但是 udp 是犧牲性能的條件下提高的效率。
?下圖是我copy的一張動圖演示：
?ok，我們說過，滑動窗口是要保證可靠性的，那么之前發(fā)生的情況，滑動窗口也會發(fā)生：丟包問題；
這種情況下啥事沒有，即使丟了這么多ack 都沒有關(guān)系。
?我們 1001 序列號丟了，但是還有 2001 這個序列號收到了，我們這里的 2001 可以涵蓋前面的 1001 序列號，主機 A 就會明白主機 B 已經(jīng)收到了，但是 1001 這個ack 包丟了。
但如果是6001 這個包丟了，就觸發(fā)超時重傳。
上面的是返回的 ack 丟了，這里是發(fā)送的數(shù)據(jù)沒有被主機 B 收到，那么主機 B 就會反復(fù)索要 這個數(shù)據(jù)。
主機 A 連續(xù)幾次收到這個索要，就知道這個 數(shù)據(jù) 估計是丟了。于是就觸發(fā)了超時重傳。
最后就返回一個 7001 ack ，為什么不是 2001 呢，因為之前的 ack 都被 主機 A 收到了。
如果中間缺了兩塊，那么重傳完 1001 之后就會再重傳中間缺失的那個。
上述的重傳過程是沒有冗余的，缺失了就重傳，沒有缺失就不重傳，整個過程速度是非?？斓?，所以也被稱之為 ： 快速重傳。
我們目前說的是傳輸大量數(shù)據(jù)的情況，如果是少量數(shù)據(jù)，就那么幾條不會使用滑動窗口和快速重傳。
流量控制
?滑動窗口是加快了效率，但是速度是越快越好嗎？
有疑問那么就說明有些問題，我們的速度并非是越快越好的，我們別忘了這一切的前提是保證可靠！ 這里的流量控制也是保證可靠性的一種。
我們的接收方是有個緩沖區(qū)的，如果我們滑動窗口發(fā)太快了，一下子就把這個緩沖區(qū)打滿了，余下的發(fā)送過來這個緩沖區(qū)也接收不到，那么就出現(xiàn)丟包了；所以我們不如發(fā)送的慢一點。
流量控制的本質(zhì)就是控制速度；如何控制這是個重點！
我們可以看到這里是有一個 16 位的窗口大小的，我們可以讓 ack 報文返回的時候攜帶一個窗口大小，這個值得意義就是用來建議?主機 A 下次該發(fā)送多大得窗口，這里說的是建議，并不絕對。
那么我們主機 B 又是如何來確認這個 窗口大小的呢？
簡單粗暴，直接拿緩沖區(qū)中剩余的空間大小作為窗口大小。
?例如：
當(dāng)我們的緩沖區(qū)滿了以后，我們的數(shù)據(jù)還沒有發(fā)送完，過了一段時間以后，我們就發(fā)送幾個數(shù)據(jù)，進行試探，看看緩沖區(qū)是否有空閑的位置，?
?這就有點像個阻塞隊列。
圖中還出現(xiàn)一個叫做 擁塞控制的東西..
擁塞控制
?滑動窗口大小 = 流量控制 + 擁塞控制?
流量控制：制衡了接收方的處理能力
擁塞控制：制衡了傳輸路徑的處理能力
我們都知道兩個遠程的機器進行數(shù)據(jù)傳輸要經(jīng)過很多交換機和路由器，·很明顯這個路徑上任何一臺設(shè)備遇到瓶頸都會影響到這整個傳輸過程。
這就是個木桶效應(yīng)，一個木桶能裝多少水取決于最短的木板。
而這里的擁塞控制存在的意義就是衡量中間節(jié)點的傳輸能力。
具體任務(wù)就是：衡量傳輸過程有多少太結(jié)點，每個結(jié)點當(dāng)前的情況，甚至是每次傳輸走的路徑都不同，通過實驗找到一條合適的路線。
怎么試驗？
我們來看下圖：
我們來一個個解釋：
最開始的時候我們會給一個非常小的速度，也叫做慢開始，當(dāng)發(fā)現(xiàn)路徑空曠，就開始指數(shù)形式增長，當(dāng)發(fā)現(xiàn)達到一個閾值就開始成線性增長，一直增長到發(fā)現(xiàn)：出現(xiàn)丟包情況；
此時，又從慢開始出發(fā)，然后指數(shù)形式增長，直到達到閾值，此時的閾值為上一次丟包的一半，其他不做出改變，從此往復(fù)。
這個過程是動態(tài)變化的，目的就是：為了防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，這樣就可以使網(wǎng)絡(luò)中的路由器或鏈路不致過載。
延時應(yīng)答
我們 tcp 的可靠核心是： 確認應(yīng)答 和 超時重傳。
而確認應(yīng)答的 ack 不是要立刻返回，而是要等一會再返回，這是為什么呢？
我們知道 tcp 決定傳輸效率的關(guān)鍵在于滑動窗口，而窗口大小又是由 擁塞控制 和 流量控制的，? ? ? 流量控制又是來接收緩沖區(qū)的大小。
關(guān)鍵就在這里：緩沖區(qū)的大小，只要緩沖區(qū)里還有數(shù)據(jù)，那么我們主機 B 就會不斷地消費緩沖區(qū)中的數(shù)據(jù)。
假設(shè)我們我們立刻返回的 ack 是 n ，那么稍微等一會，等緩沖區(qū)消費一些數(shù)據(jù)，返回的ack 大概率會比 n 大。
延遲應(yīng)答的作用就再此：通過這個延遲，讓接收方乘機多消費一些數(shù)據(jù)，以達到返回的窗口會大一丟丟，以此來增加發(fā)送方發(fā)送的速率。
捎帶應(yīng)答
捎帶應(yīng)答是基于延時應(yīng)答，它是作用于服務(wù)器 與 客戶端 之間的；
我們服務(wù)器與客戶端之間存在 四種通信模型：
一問一答：絕大部分網(wǎng)絡(luò)通信
多問一答：上傳大文件
一文多答：下載大文件
多問多答：游戲串流
而捎帶應(yīng)答通常是作用于 一問一答 的模型。
例如：
我們客戶端發(fā)送一個請求給客戶端，我們 服務(wù)器會返回一個 ack，我們的服務(wù)器通過 write 這個方法寫的數(shù)據(jù)，通過一些代碼執(zhí)行到才返回一個響應(yīng)；這里的 ack 和 響應(yīng) 本來是不同時機返回的，但是我們通過捎帶應(yīng)答這個機制，讓 ack 等會再發(fā)送，那么 ack 和 響應(yīng) 就可能會同時發(fā)送。
我們的四次揮手也有可能這樣成為" 三次揮手 " 就結(jié)束。
TCP 遠不止這些機制，還有其他很多核心的機制，這里只是介紹了比較核心的機制，可以參考 TCP RFC 標準文檔。
總結(jié)
我們介紹了 udp 協(xié)議，和 tcp 協(xié)議
tcp 中我們介紹了：
- 確認應(yīng)答，超時重傳（確?？煽啃缘暮诵臋C制）
- 鏈接管理（網(wǎng)絡(luò)鏈接的核心機制，三次握手和四次揮手面試?？迹?/li>
- 滑動窗口（優(yōu)化手段，增加效率）
- 流量控制，擁塞控制（組成滑動窗口的機制，也是優(yōu)化手段，其中流量控制也是保證可靠性的一種）
- 延時應(yīng)答，捎帶應(yīng)答（?提升效率的機制 ）
tcp 和 udp 的區(qū)別：
tcp 是可靠傳輸，效率并沒有那么高
udp 是不可靠傳輸，效率很高
為什么我們tcp 協(xié)議既要保證可靠又要追求效率呢？
我們現(xiàn)實生活中的確存在很多需要用到 tcp 的場景，例如各類對抗性激烈的網(wǎng)游：王者農(nóng)藥，lol，csgo 等等， 我們既要保證可靠的情況，又要 盡可能追求效率。文章來源：http://www.zghlxwxcb.cn/news/detail-427099.html
我們的傳輸層之間不僅僅只有這兩個協(xié)議，還存在很多其他協(xié)議，也可以自己寫協(xié)議，但這兩個協(xié)議是用的最多，最權(quán)威的協(xié)議。文章來源地址http://www.zghlxwxcb.cn/news/detail-427099.html
到了這里，關(guān)于網(wǎng)絡(luò)原理（四）：傳輸層協(xié)議 TCP/UDP的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
