前言

小亭子正在努力的學(xué)習(xí)編程，接下來(lái)將開(kāi)啟javaEE的學(xué)習(xí)~~

分享的文章都是學(xué)習(xí)的筆記和感悟，如有不妥之處希望大佬們批評(píng)指正~~

同時(shí)如果本文對(duì)你有幫助的話，煩請(qǐng)點(diǎn)贊關(guān)注支持一波, 感激不盡~~

?

目錄

前言

TCP協(xié)議

TCP協(xié)議特點(diǎn)

TCP協(xié)議通信場(chǎng)景

TCP協(xié)議的幾個(gè)重要機(jī)制

一、確認(rèn)應(yīng)答

二、 超時(shí)重傳

三、連接管理（重點(diǎn)）

四、滑動(dòng)窗口

五、流量控制

六、擁塞控制

七、延時(shí)應(yīng)答

八、捎帶應(yīng)答

九、面向字節(jié)流 -粘包問(wèn)題

十、異常處理-心跳包

緩沖區(qū)：

UDP協(xié)議

?UDP協(xié)議的特點(diǎn)?

UDP協(xié)議通信場(chǎng)景

?UDP協(xié)議端格式

傳輸層的2個(gè)常見(jiàn)協(xié)議

TCP(Transmission Control Protocol) ：傳輸控制協(xié)議

UDP(User Datagram Protocol)：用戶數(shù)據(jù)報(bào)協(xié)議

TCP協(xié)議

TCP協(xié)議特點(diǎn)

使用TCP協(xié)議，必須雙方先建立連接，它是一種面向連接的可靠通信協(xié)議。

傳輸前，采用“三次握手”方式建立連接，所以是可靠的 。

在連接中可進(jìn)行大數(shù)據(jù)量的傳輸 。

連接、發(fā)送數(shù)據(jù)都需要確認(rèn)，且傳輸完畢后，還需釋放已建立的連接，通信效率較低。

TCP協(xié)議通信場(chǎng)景

對(duì)信息安全要求較高的場(chǎng)景，例如：文件下載、金融等數(shù)據(jù)通信。

TCP協(xié)議的幾個(gè)重要機(jī)制

?TCP對(duì)數(shù)據(jù)傳輸提供的管控機(jī)制，主要體現(xiàn)在兩個(gè)方面：安全和效率。

這些機(jī)制和多線程的設(shè)計(jì)原則類似：保證數(shù)據(jù)傳輸安全的前提下，盡可能的提高傳輸效率

一、確認(rèn)應(yīng)答

是實(shí)現(xiàn)可靠性的最核心機(jī)制

舉個(gè)栗子：你約女同學(xué)出去吃飯，給她發(fā)消息

為了解決上述問(wèn)題，就需要對(duì)信息進(jìn)行編號(hào)，給發(fā)出去的消息分配一個(gè)“序號(hào)”，同時(shí)應(yīng)答報(bào)文給出“確認(rèn)序號(hào)”

確認(rèn)序號(hào)，是取發(fā)送方發(fā)過(guò)來(lái)的所有數(shù)據(jù)，最后一個(gè)字節(jié)的下一個(gè)字節(jié)的序號(hào)

TCP從前往后將每個(gè)字節(jié)分別分配一個(gè)編號(hào)，即為序列號(hào)

?每一個(gè)ACK都帶有對(duì)應(yīng)的確認(rèn)序列號(hào)，意思是告訴發(fā)送者，我已經(jīng)收到了哪些數(shù)據(jù)，下一次你從哪里開(kāi)始發(fā)。

舉個(gè)栗子：

確認(rèn)序號(hào) 1001的含義：

1.<1001的數(shù)據(jù)，我已經(jīng)收到

2.我接下來(lái)想向發(fā)送方索要從1001開(kāi)始的數(shù)據(jù)

接收方通過(guò)ack的確認(rèn)序號(hào)，告訴發(fā)送方哪些數(shù)據(jù)已經(jīng)收到了。

如果一切順利的話，就可以直接確認(rèn)應(yīng)答了，可靠性就得到了支持。

二、 超時(shí)重傳

什么是超時(shí)重傳？

?主機(jī)A發(fā)送數(shù)據(jù)給B之后，可能因?yàn)榫W(wǎng)絡(luò)擁堵等原因，數(shù)據(jù)無(wú)法到達(dá)主機(jī)B

?如果主機(jī)A在一個(gè)特定時(shí)間間隔內(nèi)沒(méi)有收到B發(fā)來(lái)的確認(rèn)應(yīng)答，就會(huì)進(jìn)行重發(fā)

丟包，是一個(gè)網(wǎng)絡(luò)通信中常見(jiàn)的問(wèn)題，那么為什么會(huì)丟包呢？

在網(wǎng)絡(luò)通信中，數(shù)據(jù)的發(fā)送很復(fù)雜，需要經(jīng)過(guò)很多的設(shè)備，每個(gè)設(shè)備的轉(zhuǎn)發(fā)能力都是有上限的，某一時(shí)刻，某個(gè)設(shè)備上面的流量達(dá)到峰值，就有可能引起部分?jǐn)?shù)據(jù)被丟包。

【補(bǔ)充：看直播，看視頻，對(duì)于丟包是不敏感的（看視頻提前有預(yù)緩沖）

打游戲，特別是LOL，王者等對(duì)抗性游戲，對(duì)于丟包非常敏感，丟包率高直接卡成ppt】

發(fā)送方對(duì)于丟包的判定：

1.數(shù)據(jù)直接丟了，接收方?jīng)]收到，自然不會(huì)發(fā)送ack

2.接收方收到了數(shù)據(jù)，但返回的ack丟了

發(fā)送方無(wú)法區(qū)分這兩種情況，都會(huì)觸發(fā)超時(shí)重傳，

但是第二種情況下，接收方會(huì)收到重復(fù)的數(shù)據(jù)，但是沒(méi)關(guān)系，TCP會(huì)在接收緩沖區(qū)中，根據(jù)收到的數(shù)據(jù)的序號(hào)自動(dòng)去重，保證了應(yīng)用程序督導(dǎo)的數(shù)據(jù)任然只有一份。

【也有可能出現(xiàn)連續(xù)丟包的情況，TCP的處理方式是繼續(xù)超時(shí)重傳，但是每一次丟包后等待的時(shí)間就會(huì)變長(zhǎng)，此時(shí)說(shuō)明網(wǎng)絡(luò)出現(xiàn)了比較嚴(yán)重的問(wèn)題，TCP就會(huì)嘗試重置連接，如果還不行，TCP就會(huì)關(guān)閉連接，放棄通信，總之就是，能重傳就重傳，實(shí)在傳不了就關(guān)閉連接，盡最大可能完成傳輸】

【一切順利的情況下，使用確認(rèn)應(yīng)答保證可靠性，出現(xiàn)丟包，使用超時(shí)重傳作為補(bǔ)充，這兩個(gè)機(jī)制是TCP可靠性的基石】

三、連接管理（重點(diǎn)）

?在正常情況下，TCP要經(jīng)過(guò)三次握手建立連接，四次揮手?jǐn)嚅_(kāi)連接

建立連接三次握手

握手（handshake）是指通信雙方，進(jìn)行一次網(wǎng)絡(luò)交互

三次握手相當(dāng)于客戶機(jī)與服務(wù)器之間通過(guò)三次交互建立了連接（雙方各自記錄對(duì)方的信息）

syn：同步報(bào)文段，意思是一方向另一方申請(qǐng)建立連接

ack：確認(rèn)字符，表示發(fā)來(lái)的數(shù)據(jù)已確認(rèn)接收無(wú)誤

三次握手這個(gè)過(guò)程，本質(zhì)上是投石問(wèn)路，驗(yàn)證一下客戶端和服務(wù)器各自的接收和發(fā)送能力是否正常。

【舉個(gè)栗子：就像每天的第一趟高鐵和地鐵一樣，第一趟車都是空的，為了檢驗(yàn)線路是否通暢】

【補(bǔ)充：中間的syn和ack也可以分開(kāi)發(fā)送，但是沒(méi)必要，一起發(fā)效率高】

斷開(kāi)連接——四次揮手

四次揮手和三次握手非常像，最主要的區(qū)別就是：

三次握手中，ack和syn是同一個(gè)時(shí)機(jī)觸發(fā)的，都是內(nèi)核完成的

四次揮手中，ack和fin則是不同時(shí)機(jī)觸發(fā)的，ack是內(nèi)核完成的，會(huì)在收到fin的時(shí)候第一時(shí)間返回，fin則是應(yīng)用程序代碼控制的，在調(diào)用到socket的close方法是才會(huì)觸發(fā)。

上述兩個(gè)過(guò)程和可靠性多少有點(diǎn)關(guān)系，但是可靠性主要還是靠確認(rèn)應(yīng)答和超時(shí)重傳。

四、滑動(dòng)窗口

?剛才我們討論了確認(rèn)應(yīng)答策略，對(duì)每一個(gè)發(fā)送的數(shù)據(jù)段，都要給一個(gè)ACK確認(rèn)應(yīng)答。收到ACK后再發(fā)送

下一個(gè)數(shù)據(jù)段。這樣做有一個(gè)比較大的缺點(diǎn)，就是性能較差。尤其是數(shù)據(jù)往返的時(shí)間較長(zhǎng)的時(shí)候。

TCP要保證的不僅僅是可靠性，還要保證效率。

想要提升效率就需要縮短等待時(shí)間，解決的方法就是一次發(fā)送多條數(shù)據(jù)，一次等待多個(gè)ack，（批量發(fā)送）

上圖所示就是批量發(fā)送4條數(shù)據(jù)，發(fā)完以后統(tǒng)一等待ack，每次收到一個(gè)ack后就立刻發(fā)送下一條（注意不是收到4個(gè)ack再發(fā)下一組）如下圖：

?窗口大小指的是無(wú)需等待確認(rèn)應(yīng)答而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值。上圖的窗口大小就是4000

個(gè)字節(jié)（四個(gè)段）。

發(fā)送前四個(gè)段的時(shí)候，不需要等待任何ACK，直接發(fā)送；

收到第一個(gè)ACK后，滑動(dòng)窗口向后移動(dòng)，繼續(xù)發(fā)送第五個(gè)段的數(shù)據(jù)；依次類推；

操作系統(tǒng)內(nèi)核為了維護(hù)這個(gè)滑動(dòng)窗口，需要開(kāi)辟 發(fā)送緩沖區(qū) 來(lái)記錄當(dāng)前還有哪些數(shù)據(jù)沒(méi)有應(yīng)

答；只有確認(rèn)應(yīng)答過(guò)的數(shù)據(jù)，才能從緩沖區(qū)刪掉；

窗口越大，則網(wǎng)絡(luò)的吞吐率就越高；

?那么如果出現(xiàn)了丟包，如何進(jìn)行重傳？這里分兩種情況討論。

情況一：數(shù)據(jù)包已經(jīng)抵達(dá)，ACK被丟了

?這種情況下，部分ACK丟了并不要緊，因?yàn)榭梢酝ㄟ^(guò)后續(xù)的ACK進(jìn)行確認(rèn)

?情況二：數(shù)據(jù)包就直接丟了。

?當(dāng)某一段報(bào)文段丟失之后，發(fā)送端會(huì)一直收到 1001 這樣的ACK，就像是在提醒發(fā)送端 "我想要的是 1001" 一樣；

如果發(fā)送端主機(jī)連續(xù)三次收到了同樣一個(gè) "1001" 這樣的應(yīng)答，就會(huì)將對(duì)應(yīng)的數(shù)據(jù) 1001 -2000 重新發(fā)送；

這個(gè)時(shí)候接收端收到了 1001 之后，再次返回的ACK就是7001了（因?yàn)?/span>2001 - 7000）接收端

其實(shí)之前就已經(jīng)收到了，被放到了接收端操作系統(tǒng)內(nèi)核的接收緩沖區(qū)中；

上述重傳過(guò)程，沒(méi)有任何冗余操作，數(shù)據(jù)丟了才會(huì)重傳，不丟數(shù)據(jù)不會(huì)重傳，整體速度還是比較快的。

這種機(jī)制被稱為 "高速重發(fā)控制"（也叫 "快重傳"）。

五、流量控制

?接收端處理數(shù)據(jù)的速度是有限的。如果發(fā)送端發(fā)的太快，導(dǎo)致接收端的緩沖區(qū)被打滿，這個(gè)時(shí)候如果發(fā)送端繼續(xù)發(fā)送，就會(huì)造成丟包，繼而引起丟包重傳等等一系列連鎖反應(yīng)。

因此TCP支持根據(jù)接收端的處理能力，來(lái)決定發(fā)送端的發(fā)送速度。這個(gè)機(jī)制就叫做流量控制（FlowControl）；

接收端將自己可以接收的緩沖區(qū)大小放入 TCP 首部中的 "窗口大小" 字段，通過(guò)ACK端通知發(fā)送端；

窗口大小字段越大，說(shuō)明網(wǎng)絡(luò)的吞吐量越高；

接收端一旦發(fā)現(xiàn)自己的緩沖區(qū)快滿了，就會(huì)將窗口大小設(shè)置成一個(gè)更小的值通知給發(fā)送端；

發(fā)送端接受到這個(gè)窗口之后，就會(huì)減慢自己的發(fā)送速度；

如果接收端緩沖區(qū)滿了，就會(huì)將窗口置為0；這時(shí)發(fā)送方不再發(fā)送數(shù)據(jù)，但是需要定期發(fā)送一

個(gè)窗口探測(cè)數(shù)據(jù)段，使接收端把窗口大小告訴發(fā)送端。

補(bǔ)充：

?各個(gè)字段的含義：

源/目的端口號(hào)：表示數(shù)據(jù)是從哪個(gè)進(jìn)程來(lái)，到哪個(gè)進(jìn)程去；
32位序號(hào)：指的是報(bào)文段序號(hào)，有時(shí)候我們會(huì)發(fā)多條數(shù)據(jù)，為了方便回答，進(jìn)行編號(hào)；
32位確認(rèn)號(hào)：這個(gè)確認(rèn)號(hào)是針對(duì)序號(hào)設(shè)定的，為了防止回復(fù)串行；
4位TCP報(bào)頭長(zhǎng)度：表示該TCP頭部有多少個(gè)32位bit（有多少個(gè)4字節(jié)）；所以TCP頭部最大長(zhǎng)度是15 * 4 = 60
6位標(biāo)志位:
URG：緊急指針是否有效
ACK：確認(rèn)號(hào)是否有效
PSH：提示接收端應(yīng)用程序立刻從TCP緩沖區(qū)把數(shù)據(jù)讀走
RST：對(duì)方要求重新建立連接；我們把攜帶RST標(biāo)識(shí)的稱為復(fù)位報(bào)文段
SYN：請(qǐng)求建立連接；我們把攜帶SYN標(biāo)識(shí)的稱為同步報(bào)文段
FIN：通知對(duì)方，本端要關(guān)閉了，我們稱攜帶FIN標(biāo)識(shí)的為結(jié)束報(bào)文段
16位窗口大?。嚎刂泼看位瑝K的流量
16位校驗(yàn)和：發(fā)送端填充，CRC校驗(yàn)。接收端校驗(yàn)不通過(guò)，則認(rèn)為數(shù)據(jù)有問(wèn)題。此處的檢驗(yàn)和不光包含TCP首部，也包含TCP數(shù)據(jù)部分。
16位緊急指針：標(biāo)識(shí)哪部分?jǐn)?shù)據(jù)是緊急數(shù)據(jù)；

六、擁塞控制

?雖然TCP有了滑動(dòng)窗口這個(gè)大殺器，能夠高效可靠的發(fā)送大量的數(shù)據(jù)。但是如果在剛開(kāi)始階段就發(fā)送大量的數(shù)據(jù)，仍然可能引發(fā)問(wèn)題。

因?yàn)榫W(wǎng)絡(luò)上有很多的計(jì)算機(jī)，可能當(dāng)前的網(wǎng)絡(luò)狀態(tài)就已經(jīng)比較擁堵。在不清楚當(dāng)前網(wǎng)絡(luò)狀態(tài)下，貿(mào)然發(fā)送大量的數(shù)據(jù)，是很有可能引起雪上加霜的。

TCP引入 慢啟動(dòng) 機(jī)制，先發(fā)少量的數(shù)據(jù)，探探路，摸清當(dāng)前的網(wǎng)絡(luò)擁堵?tīng)顟B(tài)，再?zèng)Q定按照多大的速度傳輸數(shù)據(jù)；

擁塞控制就是通過(guò)實(shí)驗(yàn)的方式找到一個(gè)合適的發(fā)送速率??！

開(kāi)始的時(shí)候，按照一個(gè)小的速率發(fā)送，如果不丟包，就可以提高一下速率（擴(kuò)大窗口大?。?/span>

如果出現(xiàn)丟包，則立刻把速率調(diào)小。

重復(fù)上述過(guò)程，讓傳輸速率達(dá)到一個(gè)動(dòng)態(tài)平衡。

另外，網(wǎng)絡(luò)的擁堵情況也不是一成不變的，擁塞控制這一策略也能很好地解決這一問(wèn)題。

慢啟動(dòng)：

?慢啟動(dòng)" 只是指初使時(shí)慢，但是增長(zhǎng)速度非?？?。

?為了不增長(zhǎng)的那么快，因此不能使擁塞窗口單純的加倍。

此處引入一個(gè)叫做慢啟動(dòng)的閾值

當(dāng)擁塞窗口超過(guò)這個(gè)閾值的時(shí)候，不再按照指數(shù)方式增長(zhǎng)，而是按照線性方式增長(zhǎng)

滑動(dòng)窗口的大小取決于 流量控制 和 擁塞控制

流量控制衡量了接收方的處理能力，擁塞控制衡量了傳輸路徑的處理能力

七、延時(shí)應(yīng)答

如果接收數(shù)據(jù)的主機(jī)立刻返回ACK應(yīng)答，這時(shí)候返回的窗口可能比較小。

假設(shè)接收端緩沖區(qū)為1M。一次收到了500K的數(shù)據(jù)；如果立刻應(yīng)答，返回的窗口就是500K；

但實(shí)際上可能處理端處理的速度很快，10ms之內(nèi)就把500K數(shù)據(jù)從緩沖區(qū)消費(fèi)掉了；

在這種情況下，接收端處理還遠(yuǎn)沒(méi)有達(dá)到自己的極限，即使窗口再放大一些，也能處理過(guò)

來(lái)；如果接收端稍微等一會(huì)再應(yīng)答，比如等待200ms再應(yīng)答，那么這個(gè)時(shí)候返回的窗口大小就是

1M；

一定要記得，窗口越大，網(wǎng)絡(luò)吞吐量就越大，傳輸效率就越高。我們的目標(biāo)是在保證網(wǎng)絡(luò)不擁塞的情況下盡量提高傳輸效率

舉個(gè)栗子：你媽媽早上出門(mén)前讓你干家務(wù)，你給忘了，然后他下午給你發(fā)消息說(shuō)你怎么沒(méi)干，你當(dāng)做沒(méi)看到?jīng)]回消息，立刻去把家務(wù)做的差不多了，就只還剩一點(diǎn)的時(shí)候給他回消息，你就可以很有底氣的說(shuō)說(shuō)馬上完事兒了。

八、捎帶應(yīng)答

?在延遲應(yīng)答的基礎(chǔ)上，我們發(fā)現(xiàn)，很多情況下，客戶端服務(wù)器在應(yīng)用層也是 "一發(fā)一收" 的。意味著客戶端給服務(wù)器說(shuō)了 "How are you"，服務(wù)器也會(huì)給客戶端回一個(gè) "Fine, thank you"；

那么這個(gè)時(shí)候ACK就可以搭順風(fēng)車，和服務(wù)器回應(yīng)的 "Fine，thank you" 一起回給客戶端

九、面向字節(jié)流 -粘包問(wèn)題

當(dāng)A給B連續(xù)發(fā)了多個(gè)應(yīng)用層數(shù)據(jù)報(bào)后，這些數(shù)據(jù)就會(huì)都積累到B的接收緩沖區(qū)中，緊緊挨在一起，此時(shí)B的應(yīng)用程序在讀數(shù)據(jù)的時(shí)候就很難區(qū)分從哪到哪是一個(gè)完整的應(yīng)用層數(shù)據(jù)報(bào)，這就是粘包問(wèn)題。

舉個(gè)栗子：

你吃了嗎爸爸餓了一起吃飯吧

這句話既可以理解為：

你吃了嗎爸爸 餓了一起吃吧

或者：你吃了嗎 爸爸餓了 一起吃吧

那么怎么解決呢？

1.定義分隔符

2.約定有效長(zhǎng)度

十、異常處理-心跳包

補(bǔ)充：

緩沖區(qū)：

?創(chuàng)建一個(gè)TCP的socket，同時(shí)在內(nèi)核中創(chuàng)建一個(gè) 發(fā)送緩沖區(qū) 和一個(gè) 接收緩沖區(qū)；

調(diào)用write時(shí)，數(shù)據(jù)會(huì)先寫(xiě)入發(fā)送緩沖區(qū)中；

如果發(fā)送的字節(jié)數(shù)太長(zhǎng)，會(huì)被拆分成多個(gè)TCP的數(shù)據(jù)包發(fā)出；

如果發(fā)送的字節(jié)數(shù)太短，就會(huì)先在緩沖區(qū)里等待，等到緩沖區(qū)長(zhǎng)度差不多了，或者其他合適

的時(shí)機(jī)發(fā)送出去；

接收數(shù)據(jù)的時(shí)候，數(shù)據(jù)也是從網(wǎng)卡驅(qū)動(dòng)程序到達(dá)內(nèi)核的接收緩沖區(qū)；

然后應(yīng)用程序可以調(diào)用read從接收緩沖區(qū)拿數(shù)據(jù)；

另一方面，TCP的一個(gè)連接，既有發(fā)送緩沖區(qū)，也有接收緩沖區(qū)，那么對(duì)于這一個(gè)連接，既

可以讀數(shù)據(jù)，也可以寫(xiě)數(shù)據(jù)。這個(gè)概念叫做 全雙工

由于緩沖區(qū)的存在，TCP程序的讀和寫(xiě)不需要一一匹配，例如：

寫(xiě)100個(gè)字節(jié)數(shù)據(jù)時(shí)，可以調(diào)用一次write寫(xiě)100個(gè)字節(jié)，也可以調(diào)用100次write，每次寫(xiě)一

個(gè)字節(jié)；

讀100個(gè)字節(jié)數(shù)據(jù)時(shí)，也完全不需要考慮寫(xiě)的時(shí)候是怎么寫(xiě)的，既可以一次read 100個(gè)字

節(jié)，也可以一次read一個(gè)字節(jié)，重復(fù)100次；

UDP協(xié)議

?UDP協(xié)議的特點(diǎn)?

UDP是一種無(wú)連接、不可靠傳輸?shù)膮f(xié)議。

將數(shù)據(jù)源IP、目的地IP和端口封裝成數(shù)據(jù)包，不需要建立連接

每個(gè)數(shù)據(jù)包的大小限制在64KB內(nèi)

發(fā)送不管對(duì)方是否準(zhǔn)備好，接收方收到也不確認(rèn)，故是不可靠的

可以廣播發(fā)送 ，發(fā)送數(shù)據(jù)結(jié)束時(shí)無(wú)需釋放資源，開(kāi)銷小，速度快。

UDP協(xié)議通信場(chǎng)景

語(yǔ)音通話，視頻會(huì)話等。

舉個(gè)栗子：

街邊的燒烤店，廚房和前廳，廚房做好了韭菜，把他裝進(jìn)盤(pán)子里，直接把盤(pán)子里的韭菜拋到客戶的盤(pán)子里，只管拋，不管客戶接沒(méi)接到。

?UDP協(xié)議端格式

上面那個(gè)是教科書(shū)上的，不好理解，我們看下面這個(gè)

校驗(yàn)和：網(wǎng)絡(luò)傳輸中，可能會(huì)因?yàn)閺?qiáng)磁場(chǎng)等外部的干擾，導(dǎo)致低電平變高，高電平變低，這樣就會(huì)導(dǎo)致數(shù)據(jù)傳輸出錯(cuò)

校驗(yàn)和就是用來(lái)判斷當(dāng)前傳輸?shù)臄?shù)據(jù)是否出錯(cuò)的。

舉個(gè)栗子：

媽媽讓我去買四樣菜，我買回了五樣，這一定是買錯(cuò)了直接一頓臭罵，但是如果我買回了四樣，就有可能買對(duì)了，暫時(shí)不會(huì)被罵，但是當(dāng)媽媽做飯的時(shí)候打開(kāi)袋子，發(fā)現(xiàn)買錯(cuò)了品種，我還是會(huì)被罵。

再舉個(gè)栗子：

至于校驗(yàn)的方法教科書(shū)中常見(jiàn)的有奇偶校驗(yàn)等，在這里我們就不詳細(xì)說(shuō)了。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-418042.html

到了這里，關(guān)于【網(wǎng)絡(luò)編程】TCP,UDP協(xié)議詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！