前言

雖然在大學(xué)的時(shí)候大家都學(xué)過網(wǎng)絡(luò)協(xié)議 ，但是肯定感覺網(wǎng)絡(luò)協(xié)議的知識(shí)點(diǎn)非常多 ，非常復(fù)雜。學(xué)的時(shí)候就渾渾噩噩，真正到了實(shí)踐中更是糊里糊涂，一旦工作中遇到了網(wǎng)絡(luò)問題，除了會(huì)簡(jiǎn)單地 ping 幾下 ，基本沒有什么解決問題的思路。然而當(dāng)拿起書來學(xué)習(xí)，或者看一些官方文檔的時(shí)候，各種生僻的專業(yè)詞匯馬上撲面而來，每了解其中的一個(gè)詞匯 ，都要看多 篇文章，讀多本書，導(dǎo)致一篇即使很短的有關(guān)網(wǎng)絡(luò)技術(shù)的文章也要幾個(gè)星期才能看完。

這嚴(yán)重打擊著大家的自信心，并且很容易讓人在技術(shù)的海洋中迷失自我，從而產(chǎn)生“從人門到放棄”的沖動(dòng)！

網(wǎng)絡(luò)協(xié)議和變化萬千的前沿技術(shù)不同，它的變化比較小，一旦掌握到一定程度，就會(huì)一直受益 技術(shù)變 很快，這 幾年OpenStack、docker、Mesos、kubernetes、微服務(wù)、serverless、AIops等技術(shù)層出不窮，讓大多數(shù)技術(shù)人員應(yīng)接不暇，但是掌握了基礎(chǔ)知識(shí) 后，反而發(fā)現(xiàn)很多技術(shù)看起來“轟轟烈烈”， 脫下外衣，其實(shí)本質(zhì)還是操作系計(jì)算機(jī)網(wǎng)絡(luò)、算法與數(shù)據(jù)結(jié)構(gòu)、編譯原理 、計(jì)算機(jī)組成與系統(tǒng)結(jié)構(gòu) 。

如果基礎(chǔ)打好了，最大的收益就是，在最新的技術(shù)出來以后，只要經(jīng)過短時(shí)間的學(xué)習(xí)，就很容易上手，就能在新技術(shù)的滾滾浪潮中保持快速學(xué)習(xí)的能力。

既然網(wǎng)絡(luò)協(xié)議既是基礎(chǔ)，又繞不過去，還這么難，但是趟過去之后又不怎么變，收益越來越大，那為什么不寫一文檔，給大家一點(diǎn)可借鑒的經(jīng)驗(yàn)，幫助大家盡快掌握網(wǎng)絡(luò)協(xié)議呢？

那么，今天咱們就從目錄、主要包括的內(nèi)容和總結(jié)三部分給大家進(jìn)行網(wǎng)絡(luò)協(xié)議的拓展學(xué)習(xí)，希望大家能夠喜歡??！

由于文章幅篇的限制小編就用截圖的方式給大家展示需要獲取完整版的小伙伴關(guān)注我之后點(diǎn)贊+轉(zhuǎn)發(fā)，私信回復(fù)【666】即可領(lǐng)取

目錄

主要內(nèi)容

主要把本文內(nèi)容分為九章來給大家介紹：

第1章通信協(xié)議概述.

1.1為什么要學(xué)習(xí)網(wǎng)絡(luò)協(xié)議

1.2網(wǎng)絡(luò)分層的真實(shí)含義，總結(jié)一下本節(jié)的內(nèi)容，理解網(wǎng)絡(luò)協(xié)議的工作模式，有以下兩個(gè)小竅門。

• 始終想象自己是一個(gè)處理網(wǎng)絡(luò)包的程序:如何拿到網(wǎng)絡(luò)包，如何根據(jù)規(guī)則進(jìn)行處理，如何發(fā)出去。

• 始終牢記一個(gè)原則:只要是在網(wǎng)絡(luò)上跑的包，都是完整的?？梢杂邢聦記]上層，絕對(duì)不可能有上層沒下層。

1.3 ifconfig:熟悉又陌生的命令行，通過本節(jié)的學(xué)習(xí)希望你能記住以下的知識(shí)點(diǎn)，后面都能用得上:

• I地址有定位功能，MAC地址類似身份證號(hào)，無定位功能。

• CIDR可以用來判斷是不是本地地址。

• IP地址分公網(wǎng)IP地址和私網(wǎng)IP地址。后面的章節(jié)中會(huì)談到“出國(guó)門”，就與此有關(guān)。

1.4 DHCP與PXE:IP地址是怎么來的，又是怎么沒的，本節(jié)內(nèi)容總結(jié)如下:

• DHCP主要租給客戶端IP地址，這個(gè)過程和租房很像，要商談、簽約、續(xù)租，廣播還不能“搶單”。

• DHCP會(huì)給客戶端推薦“裝修隊(duì)”PXE來安裝操作系統(tǒng)，這在云計(jì)算領(lǐng)域大有用處。

第2章從二層到三層．

2.1從物理層到MAC層:如何在宿舍里自己組網(wǎng)玩聯(lián)機(jī)游戲，本節(jié)有3個(gè)重點(diǎn)需要記住:

• MAC層是用來解決多路訪問的“堵車”問題的。

• ARP是通過“吼”的方式來尋找目標(biāo)MAC地址的，“吼”完之后會(huì)記住一段時(shí)間，這個(gè)叫作緩存。

• 交換機(jī)是有MAC地址學(xué)習(xí)能力的，學(xué)會(huì)了它就能知道誰(shuí)在哪里，不用廣播了。

2.2交換機(jī)與VLAN:辦公室太復(fù)雜，我要回學(xué)校，本節(jié)總結(jié)如下:

• ·當(dāng)交換機(jī)的數(shù)目越來越多時(shí)，會(huì)遭遇環(huán)路問題，讓廣播包迷路。這時(shí)就需要使用STP通過“比武論劍”的方式，將有環(huán)路的圖變成沒有環(huán)路的樹，從而解決環(huán)路問題。

• ·交換機(jī)數(shù)目過多會(huì)導(dǎo)致隔離問題?？梢酝ㄟ^VLAN形成虛擬局域網(wǎng)，從而解決廣播問題和安全問題。

2.3ICMP與ping:投石問路的偵察兵，本節(jié)內(nèi)容總結(jié)如下:

• ·ICMP 相當(dāng)于網(wǎng)絡(luò)世界的偵察兵。本節(jié)講解了兩種類型的ICMP報(bào)文，一種是主動(dòng)探查的查詢報(bào)文，一種異常報(bào)告的差錯(cuò)報(bào)文。

• ping使用查詢報(bào)文，Traceroute使用差錯(cuò)報(bào)文。

2.4世界這么大，我想出網(wǎng)關(guān):歐洲十國(guó)游與玄奘西行，本節(jié)總結(jié)如下:

• ·如果離開局域網(wǎng)，就需要經(jīng)過網(wǎng)關(guān)。

• ·路由器是一個(gè)三層設(shè)備，里面有如何尋找下一跳的規(guī)則。

• ·經(jīng)過路由器之后MAC頭要變，如果I地址不變，相當(dāng)于不換護(hù)照的“歐洲十國(guó)游”，如果IP地址改變，相當(dāng)于換護(hù)照的“玄奘西行”。

2.5路由協(xié)議:“西出網(wǎng)關(guān)無故人""敢問路在何方”，本節(jié)總結(jié)如下:

• 路由分靜態(tài)路由和動(dòng)態(tài)路由，靜態(tài)路由可以配置復(fù)雜的策略路由，控制轉(zhuǎn)發(fā)策略。

• 動(dòng)態(tài)路由有兩種主流協(xié)議，距離矢量路由協(xié)議和鏈路狀態(tài)路由協(xié)議。分別對(duì)應(yīng)BGP和OSPF 這兩個(gè)實(shí)現(xiàn)。

第3章重要的傳輸層．

3.1 UDP:雖然簡(jiǎn)單但是可以定制化，本節(jié)總結(jié)如下:

• 如果將TCP比作成熟的社會(huì)人，UDP則是頭腦簡(jiǎn)單的小朋友。TCP復(fù)雜，UDP簡(jiǎn)單。TCP維護(hù)連接，UDP誰(shuí)都相信。TCP知進(jìn)退，UDP愣頭青一個(gè)，勇往直前。

• ·UDP雖然簡(jiǎn)單，但它有簡(jiǎn)單的用法。它可以用在環(huán)境簡(jiǎn)單、需要多播、應(yīng)用層自己控制傳輸?shù)牡胤?，例如DHCP、VXLAN、QUIC等。

3.2 TCP(上):雖然復(fù)雜，使用起來卻輕松，本節(jié)總結(jié)如下:

• · TCP頭很復(fù)雜，但是主要關(guān)注五個(gè)方面:順序問題、丟包問題、連接維護(hù)、流量控制，以及擁塞控制。

• 連接的建立要經(jīng)過三次握手，斷開要經(jīng)過四次揮手。

3.3 TCP (下):西行必定多妖孽，恒心智慧消磨難，總結(jié)如下:

• 順序問題、丟包問題、流量控制都是通過滑動(dòng)窗口來解決的，滑動(dòng)窗口其實(shí)就相當(dāng)于領(lǐng)導(dǎo)和下屬的工作備忘錄，布置過的工作要有編號(hào)，干完了有反饋，活兒不能派太多，也不能太少。

• 擁塞控制是通過擁塞窗口來解決的，相當(dāng)于往管道里面倒水，快了容易溢出，慢了浪費(fèi)帶寬，要摸著石頭過河，找到最優(yōu)值。

3.4 socket: Talk is cheap, show me the code ，本節(jié)總結(jié)如下:

• 你需要記住在基于TCP和UDP的socket程序的函數(shù)調(diào)用過程中，客戶端和服務(wù)端都需要調(diào)用哪些函數(shù)。

• 寫一個(gè)能夠支撐大量連接的高并發(fā)的服務(wù)端不容易，需要多進(jìn)程、多線程，而 epoll能解決C10K問題。

第4章常用的應(yīng)用層．

4.1 HTTP:看個(gè)新聞原來這么麻煩，本節(jié)總結(jié)如下:

• HTTP很常用，也很復(fù)雜，重點(diǎn)記住GET、POST、PUT、DELETE這幾個(gè)方法，以及重要的首部字段。

• HTTP2.0通過頭壓縮、分幀、二進(jìn)制編碼、多路復(fù)用等技術(shù)提升性能。

• QUIC協(xié)議通過基于UDP自定義的連接、重傳、多路復(fù)用、流量控制等機(jī)制進(jìn)一步提升性能。

4.2 HTTPS:點(diǎn)外賣的過程原來這么復(fù)雜，本節(jié)總結(jié)如下:

• 加密分對(duì)稱加密和非對(duì)稱加密。對(duì)稱加密效率高，但是解決不了密鑰傳輸問題;非對(duì)稱加密可以解決這個(gè)問題，但是效率低。

• 非對(duì)稱加密需要通過證書和權(quán)威機(jī)構(gòu)來驗(yàn)證公鑰的合法性。

• HTTPS是綜合了對(duì)稱加密和非對(duì)稱加密的HTTP。既保證傳輸安全，也保證傳輸效率。

4.3流媒體協(xié)議:如何在直播里看到帥哥美女，本節(jié)總結(jié)如下:

• 編碼兩大流派達(dá)成了一致，都是通過關(guān)于時(shí)間、空間的各種算法來壓縮數(shù)據(jù)的。

• 壓縮好的數(shù)據(jù)，為了方便傳輸會(huì)組成一系列NALU，按照幀和片依次排列。

• 排列好的NALU在網(wǎng)絡(luò)傳輸時(shí)，要按照RTMP包的格式進(jìn)行包裝，RTMP包會(huì)拆分成塊進(jìn)行傳輸。

• 推送到流媒體服務(wù)器的視頻流經(jīng)過轉(zhuǎn)碼和分發(fā)，可以被客戶端通過RTMP拉取，然后組合為NALU，解碼成視頻格式進(jìn)行播放。

4.4 P2P協(xié)議:下載電影，分布式協(xié)議速度快，本節(jié)總結(jié)如下：

• 下載一個(gè)文件可以使用HTTP或FTP，這兩種協(xié)議都使用集中下載的方式，而P2P則換了一種思路，采取去中心化下載的方式。

• P2P也有兩種下載方式，一種是依賴于tracker服務(wù)器，即元數(shù)據(jù)集中，文件數(shù)據(jù)分散;另一種基于分布式哈希算法，元數(shù)據(jù)和文件數(shù)據(jù)全部分散。

第5章陌生的數(shù)據(jù)中心.

5.1 DNS:網(wǎng)絡(luò)世界的地址簿，本節(jié)總結(jié)如下:

• DNS是網(wǎng)絡(luò)世界的地址簿，可以通過域名查詢地址，由于DNS服務(wù)器是按照樹狀結(jié)構(gòu)組織的，因而域名查找使用的是遞歸的方法，并通過緩存的方式增強(qiáng)性能。

• 域名和IP地址相互映射的過程給了應(yīng)用基于域名做負(fù)載均衡的機(jī)會(huì),可以實(shí)現(xiàn)簡(jiǎn)單的負(fù)載均衡，也可以根據(jù)地址和運(yùn)營(yíng)商實(shí)現(xiàn)全局負(fù)載均衡。

5.2 HTTPDNS:網(wǎng)絡(luò)世界的地址簿也會(huì)指錯(cuò)路，本節(jié)需要記住以下兩個(gè)重點(diǎn):

• ·傳統(tǒng)的DNS服務(wù)器有很多問題，例如解析慢、更新不及時(shí)。因?yàn)榫彺?、轉(zhuǎn)發(fā)NAT問題導(dǎo)致客戶端誤會(huì)自己所在的位置和所屬的運(yùn)營(yíng)商，從而影響流量的調(diào)度。

• ·HTTPDNS服務(wù)器通過客戶端SDK，服務(wù)端通過HTTP直接調(diào)用解析DNS服務(wù)器的方式，繞過了傳統(tǒng)DNS服務(wù)器的缺點(diǎn)，實(shí)現(xiàn)了智能調(diào)度。

5.3 CDN:你去小賣部取過快遞嗎，本節(jié)需記住以下兩個(gè)重點(diǎn):

• CDN和電商系統(tǒng)的分布式倉(cāng)儲(chǔ)系統(tǒng)-樣，分為中心節(jié)點(diǎn)、區(qū)域節(jié)點(diǎn)、邊緣節(jié)點(diǎn)，將數(shù)據(jù)緩存在離用戶最近的位置。

• CDN最擅長(zhǎng)的是緩存靜態(tài)數(shù)據(jù),除此之外還可以緩存流媒體數(shù)據(jù),這時(shí)要注意使用防盜鏈。CDN也支持動(dòng)態(tài)數(shù)據(jù)緩存，可用模式有兩種:一種是邊緣計(jì)算的生鮮超市模式，另一種 是鏈路優(yōu)化的冷鏈運(yùn)輸模式。

5.4數(shù)據(jù)中心:我是開發(fā)商，自己拿地蓋別墅，本節(jié)需要記住以下3個(gè)重點(diǎn):

• 數(shù)據(jù)中心分為三層。服務(wù)器連接到接入層，然后是匯聚層，接著是核心層，最外面是邊界路由器和安全設(shè)備。

• 數(shù)據(jù)中心的所有鏈路都要高可用。服務(wù)器可以綁定網(wǎng)卡，交換機(jī)可以堆疊，三層設(shè)備可以通過等價(jià)路由，二層設(shè)備可以通過TRILL協(xié)議實(shí)現(xiàn)高可用。

• 隨著云和大數(shù)據(jù)的發(fā)展,東西流量相較于南北流量更加重要,因而演進(jìn)出葉脊網(wǎng)絡(luò)結(jié)構(gòu)。

5.5 VPN:朝中有人好做官，本節(jié)總結(jié)如下:

• VPN可以將一個(gè)機(jī)構(gòu)的多個(gè)數(shù)據(jù)中心通過隧道連接起來,讓機(jī)構(gòu)感覺在一個(gè)數(shù)據(jù)中心里面一樣，如同自駕游通過瓊州海峽。

• 完全基于軟件的IPsec VPN可以保證私密性、完整性、真實(shí)性，簡(jiǎn)單便宜，但是性能稍微差一些。

• MPLS-VPN綜合了I轉(zhuǎn)發(fā)模式和ATM標(biāo)簽轉(zhuǎn)發(fā)模式的優(yōu)勢(shì)，性能較好，但是需要從運(yùn)營(yíng)商處購(gòu)買。

5.6移動(dòng)網(wǎng)絡(luò):去巴塞羅那，手機(jī)也上不了“臉書”，本節(jié)總結(jié)如下:

• 移動(dòng)網(wǎng)絡(luò)的發(fā)展歷程從2G到3G，再到4G，功能逐漸從以打電話為主轉(zhuǎn)變?yōu)橐陨暇W(wǎng)為主。

• 請(qǐng)記住4G網(wǎng)絡(luò)的結(jié)構(gòu)，有eNodeB、MME、SGW、PGW等，分控制面協(xié)議和數(shù)據(jù)面協(xié)議，你可以對(duì)照這個(gè)結(jié)構(gòu)，試著說出手機(jī)上網(wǎng)的流程。

• 即便你在國(guó)外運(yùn)營(yíng)商的范圍內(nèi)上網(wǎng)，也要由國(guó)內(nèi)運(yùn)營(yíng)商控制，因而也上不了“臉書”。

第6章云計(jì)算中的網(wǎng)絡(luò)．

6.1云中網(wǎng)絡(luò):自己拿地成本高，購(gòu)買公寓更靈活，本節(jié)總結(jié)如下:

• 云計(jì)算的關(guān)鍵技術(shù)是虛擬化，這里我們重點(diǎn)關(guān)注的是虛擬網(wǎng)卡通過打開TUN/TAP字符設(shè)備的方式，將虛擬機(jī)內(nèi)外連接起來。

• 云中的網(wǎng)絡(luò)重點(diǎn)關(guān)注四個(gè)方面:共享、隔離、互通、靈活。其中共享和互通有兩種常用的方式，分別是橋接和NAT，隔離可以通過VLAN的方式來進(jìn)行。

6.2軟件定義網(wǎng)絡(luò):共享基礎(chǔ)設(shè)施的小區(qū)物業(yè)管理辦法，本節(jié)總結(jié)如下:

• 用SDN 控制整個(gè)云里面的網(wǎng)絡(luò)，就像小區(qū)保安從總控室管理整個(gè)物業(yè)是一樣的，將控制面和數(shù)據(jù)面進(jìn)行了分離。

• Open vSwitch是一種開源的虛擬交換機(jī)的實(shí)現(xiàn)，它能對(duì)經(jīng)過自己的網(wǎng)絡(luò)包做任意修改，從而使得云對(duì)網(wǎng)絡(luò)的控制十分靈活。

• 將Open vSwitch引入云之后，可以使配置簡(jiǎn)單而靈活，并且可以解耦物理網(wǎng)絡(luò)和虛擬網(wǎng)絡(luò)。

6.3云中網(wǎng)絡(luò)之安全:雖然不是土豪，也需要基本保障，本節(jié)總結(jié)如下:

• 云中的安全策略的常用方式是使用iptables的規(guī)則,請(qǐng)記住它的5個(gè)鏈:PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING。

• iptables 的表分為4種: raw、mangle、nat、filter。其中安全策略主要在filter表中實(shí)現(xiàn)，而虛擬網(wǎng)絡(luò)和物理網(wǎng)絡(luò)地址的轉(zhuǎn)換主要在nat表中實(shí)現(xiàn)。

6.4云中網(wǎng)絡(luò)之QoS:室友瘋狂下電影，我該怎么辦，本節(jié)總結(jié)如下:

• 云中的流量控制主要是通過隊(duì)列進(jìn)行的，排隊(duì)規(guī)則分為兩大類:無類別排隊(duì)規(guī)則和基于類別的排隊(duì)規(guī)則。

• 在云中網(wǎng)絡(luò)Open vSwitch中，主要使用HTB將總的帶寬在一棵樹上按照配置的比例進(jìn)行分配，并且在一個(gè)分支不使用流量時(shí)，借給另外的分支，從而增強(qiáng)帶寬利用率。

6.5云中網(wǎng)絡(luò)之隔離GRE、VXLAN:雖然住一個(gè)小區(qū)，也要保護(hù)隱私，本節(jié)總結(jié)如下:

• 要對(duì)不同用戶的網(wǎng)絡(luò)進(jìn)行隔離,解決VLAN數(shù)目有限的問題,需要通過Overlay的方式，常使用的是GRE和VXLAN。

• GRE是一種點(diǎn)對(duì)點(diǎn)的隧道模式，VXLAN是支撐組播的隧道模式，它們都要在某個(gè)隧道端口進(jìn)行封裝和解封裝，實(shí)現(xiàn)跨物理機(jī)的互通。

• Open vSwitch可以作為隧道端口，通過設(shè)置流表規(guī)則在虛擬機(jī)網(wǎng)絡(luò)和物理機(jī)網(wǎng)絡(luò)之間進(jìn)行轉(zhuǎn)換。

第7章容器技術(shù)中的網(wǎng)絡(luò)．

7.1容器網(wǎng)絡(luò):來去自由的日子，不買公寓去合租，本節(jié)總結(jié)如下:

• 容器是一種比虛擬機(jī)更加輕量級(jí)的隔離方式，主要通過namespace和 cgroup技術(shù)進(jìn)行資源的隔離，namespace負(fù)責(zé)“看起來”隔離，cgroup負(fù)責(zé)“用起來”隔離。

• 容器網(wǎng)絡(luò)連接到物理網(wǎng)絡(luò)的方式和虛擬機(jī)很像，通過橋接的方式可以實(shí)現(xiàn)一臺(tái)物理機(jī)上容器的相互訪問，如果要訪問外網(wǎng)，最簡(jiǎn)單的方式還是通過NAT。

7.2容器網(wǎng)絡(luò)之Flannel:每人一畝三分地.，本節(jié)總結(jié)如下:

• 基于NAT的容器網(wǎng)絡(luò)模型在微服務(wù)架構(gòu)下有兩個(gè)問題，一個(gè)是IP地址重疊，另一個(gè)是端口沖突，需要通過Overlay 網(wǎng)絡(luò)保持跨節(jié)點(diǎn)的連通性。

• Flannel是跨節(jié)點(diǎn)容器網(wǎng)絡(luò)方案之一，它提供的Overlay方案主要有兩種方式，一種是UDP在用戶態(tài)封裝，另一種是VXLAN在內(nèi)核態(tài)封裝，而VXLAN的性能更好一些。

7.3容器網(wǎng)絡(luò)之Calico:為了高效說出善意的謊言，本節(jié)總結(jié)如下:

• Calico推薦使用物理機(jī)作為路由器，這種模式?jīng)]有虛擬化開銷，性能比較高。

• Calico的主要組件包括路由、iptables 的配置組件Felix、路由廣播組件BGP Speaker，以及大規(guī)模場(chǎng)景下的BGP路由反射器。

• 為解決跨網(wǎng)段的問題，Calico還有一種IPIP模式，即在兩臺(tái)機(jī)器之間打一個(gè)隧道，兩臺(tái)機(jī)器分別位于隧道兩端，這樣本來不是鄰居的兩臺(tái)機(jī)器，因?yàn)樗淼雷兂闪讼噜彽臋C(jī)器。

7.4 RPC概述:遠(yuǎn)在天邊，近在眼前，本節(jié)總結(jié)如下:

• 遠(yuǎn)程調(diào)用看起來用socket編程就可以了，其實(shí)是很復(fù)雜的，要解決協(xié)議約定問題、傳輸協(xié)議問題和服務(wù)發(fā)現(xiàn)問題。

• Bruce Jay Nelson的論文、早期ONC RPC框架，以及NFS的實(shí)現(xiàn)，給出了解決這三大問題的示范性實(shí)現(xiàn)，即協(xié)議約定要公用協(xié)議描述文件并通過這個(gè)文件生成Stub程序，RPC的傳輸一般需要一個(gè)狀態(tài)機(jī)，同時(shí)需要另外一個(gè)進(jìn)程專門做服務(wù)發(fā)現(xiàn)。

第8章微服務(wù)相關(guān)協(xié)議．

8.1基于XML的SOAP:不要說NBA，請(qǐng)說美國(guó)職業(yè)籃球聯(lián)賽，本節(jié)總結(jié)如下:

• 原來的二進(jìn)制RPC有很多缺點(diǎn):格式要求嚴(yán)格、修改過于復(fù)雜、不面向?qū)ο?。于是產(chǎn)生了基于文本的調(diào)用方式——基于XML的SOAP。

• SOAP的三大要素:協(xié)議約定用WSDL、傳輸協(xié)議用HTTP、服務(wù)發(fā)現(xiàn)用UDDL。

8.2基于JSON的RESTful接口協(xié)議:我不關(guān)心過程，請(qǐng)給我結(jié)果，本節(jié)總結(jié)如下。

• SOAP過于復(fù)雜，而且設(shè)計(jì)是面向動(dòng)作的，因而往往因?yàn)榧軜?gòu)問題導(dǎo)致并發(fā)量上不去。

• RESTful不僅僅是一個(gè)API，還是一種架構(gòu)模式，主要面向資源提供無狀態(tài)服務(wù)，有利于橫向擴(kuò)展應(yīng)對(duì)高并發(fā)。

8.3二進(jìn)制類RPC協(xié)議:還是叫NBA吧，總說全稱多費(fèi)勁，本節(jié)總結(jié)如下:

• RESTful API對(duì)于接入層和Controller層之外的調(diào)用，已基本形成事實(shí)標(biāo)準(zhǔn)，但隨著內(nèi)部

• 服務(wù)之間的調(diào)用越來越多,性能也越來越重要，于是Dubbo的RPC框架有了用武之地。

• Dubbo通過注冊(cè)中心解決服務(wù)發(fā)現(xiàn)問題，通過Hessian2序列化解決協(xié)議約定的問題，通過Netty解決網(wǎng)絡(luò)傳輸?shù)膯栴}。

在更加復(fù)雜的微服務(wù)場(chǎng)景下，Spring Cloud的RESTful方式在內(nèi)部調(diào)用時(shí)也會(huì)被考慮，重要的是JAR包的依賴和管理問題。

8.4跨語(yǔ)言類RPC協(xié)議:交流之前，雙方先交換一下專業(yè)術(shù)語(yǔ)表，本節(jié)總結(jié)如下:

• gRPC是一種二進(jìn)制、性能好、跨語(yǔ)言、更靈活，同時(shí)可以進(jìn)行服務(wù)治理的多快好省的

• gRPC框架，唯一的不足就是要寫協(xié)議文件。

• gRPC 在序列化時(shí)使用Protocol Buffers，網(wǎng)絡(luò)傳輸時(shí)使用HTTP 2.0，服務(wù)治理時(shí)可以使用基于Envoy的Service Mesh。

第9章網(wǎng)絡(luò)協(xié)議知識(shí)串講．

9.1 知識(shí)串講:用"雙*"的故事串起網(wǎng)絡(luò)協(xié)議的碎片知識(shí)(上)，

9.2 知識(shí)串講:用"雙*"的故事串起網(wǎng)絡(luò)協(xié)議的碎片知識(shí)(中)，

9.3 知識(shí)串講:用"雙*“的故事串起網(wǎng)絡(luò)協(xié)議的碎片知識(shí)（下)，

9.4 搭建—個(gè)網(wǎng)絡(luò)實(shí)驗(yàn)環(huán)境:授人以魚不如授人以漁，

由于文章幅篇的限制小編就用截圖的方式給大家展示需要獲取完整版的小伙伴關(guān)注我之后點(diǎn)贊+轉(zhuǎn)發(fā)，私信回復(fù)【學(xué)習(xí)】即可領(lǐng)取

當(dāng)然，單單有文檔看是遠(yuǎn)遠(yuǎn)不夠的，還有視頻和相匹配的課件進(jìn)行學(xué)習(xí)提升，努力把計(jì)算機(jī)網(wǎng)絡(luò)這一塊兒給搞明白，相信一定會(huì)有不凡的人生??！

本文就是愿天堂沒有BUG給大家分享的內(nèi)容，大家有收獲的話可以分享下，想學(xué)習(xí)更多的話可以到微信公眾號(hào)里找我，我等你哦。