前言
雖然在大學的時候大家都學過網絡協議 ，但是肯定感覺網絡協議的知識點非常多 ，非常複雜。學的時候就渾渾噩噩，真正到了實踐中更是糊里糊塗，一旦工作中遇到了網絡問題，除了會簡單地 ping 幾下 ，基本沒有什麼解決問題的思路。 然而當拿起書來學習，或者看一些官方文檔的時候，各種生僻的專業詞彙馬上撲面而來，每瞭解其中的一個詞彙 ，都要看多 篇文章，讀多本書，導致一篇即使很短的有關網絡技術的文章也要幾個星期才能看完。
這嚴重打擊着大家的自信心，並且很容易讓人在技術的海洋中迷失自我，從而產生“從人門到放棄”的衝動！
網絡協議和變化萬千的前沿技術不同，它的變化比較小，一旦掌握到一定程度，就會一直受益 技術變 很快，這 幾年OpenStack、docker、Mesos、kubernetes、微服務、serverless、AIops等技術層出不窮，讓大多數技術人員應接不暇，但是掌握了基礎知識 後，反而發現很多技術看起來“轟轟烈烈”， 脫下外衣，其實本質還是操作系計算機網絡、算法與數據結構、編譯原理 、計算機組成與系統結構 。
如果基礎打好了，最大的收益就是，在最新的技術出來以後，只要經過短時間的學習，就很容易上手，就能在新技術的滾滾浪潮中保持快速學習的能力。
既然網絡協議既是基礎，又繞不過去，還這麼難，但是趟過去之後又不怎麼變，收益越來越大，那爲什麼不寫一文檔，給大家一點可借鑑的經驗，幫助大家儘快掌握網絡協議呢？
那麼，今天咱們就從目錄、主要包括的內容和總結三部分給大家進行網絡協議的拓展學習，希望大家能夠喜歡！！
目錄
主要內容
主要把本文內容分爲九章來給大家介紹：
第1章通信協議概述.
1.1爲什麼要學習網絡協議
1.2網絡分層的真實含義，總結一下本節的內容，理解網絡協議的工作模式，有以下兩個小竅門。
- 始終想象自己是一個處理網絡包的程序:如何拿到網絡包，如何根據規則進行處理，如何發出去。
- 始終牢記一個原則:只要是在網絡上跑的包，都是完整的。可以有下層沒上層，絕對不可能有上層沒下層。
1.3 ifconfig:熟悉又陌生的命令行，通過本節的學習希望你能記住以下的知識點，後面都能用得上:
- I地址有定位功能，MAC地址類似身份證號，無定位功能。
- CIDR可以用來判斷是不是本地地址。
- IP地址分公網IP地址和私網IP地址。後面的章節中會談到“出國門”，就與此有關。
1.4 DHCP與PXE:IP地址是怎麼來的，又是怎麼沒的，本節內容總結如下:
- DHCP主要租給客戶端IP地址，這個過程和租房很像，要商談、簽約、續租，廣播還不能“搶單”。
- DHCP會給客戶端推薦“裝修隊”PXE來安裝操作系統，這在雲計算領域大有用處。
第2章從二層到三層．
2.1從物理層到MAC層:如何在宿舍裏自己組網玩聯機遊戲，本節有3個重點需要記住:
- MAC層是用來解決多路訪問的“堵車”問題的。
- ARP是通過“吼”的方式來尋找目標MAC地址的，“吼”完之後會記住一段時間，這個叫作緩存。
- 交換機是有MAC地址學習能力的，學會了它就能知道誰在哪裏，不用廣播了。
2.2交換機與VLAN:辦公室太複雜，我要回學校，本節總結如下:
- ·當交換機的數目越來越多時，會遭遇環路問題，讓廣播包迷路。這時就需要使用STP通過“比武論劍”的方式，將有環路的圖變成沒有環路的樹，從而解決環路問題。
- ·交換機數目過多會導致隔離問題。可以通過VLAN形成虛擬局域網，從而解決廣播問題和安全問題。
2.3ICMP與ping:投石問路的偵察兵，本節內容總結如下:
- ·ICMP 相當於網絡世界的偵察兵。本節講解了兩種類型的ICMP報文，一種是主動探查的查詢報文，一種異常報告的差錯報文。
- ping使用查詢報文，Traceroute使用差錯報文。
2.4世界這麼大，我想出網關:歐洲十國遊與玄奘西行，本節總結如下:
- ·如果離開局域網，就需要經過網關。
- ·路由器是一個三層設備，裏面有如何尋找下一跳的規則。
- ·經過路由器之後MAC頭要變，如果I地址不變，相當於不換護照的“歐洲十國遊”，如果IP地址改變，相當於換護照的“玄奘西行”。
2.5路由協議:“西出網關無故人""敢問路在何方”，本節總結如下:
- 路由分靜態路由和動態路由，靜態路由可以配置複雜的策略路由，控制轉發策略。
- 動態路由有兩種主流協議，距離矢量路由協議和鏈路狀態路由協議。分別對應BGP和OSPF 這兩個實現。
第3章重要的傳輸層．
3.1 UDP:雖然簡單但是可以定製化，本節總結如下:
- 如果將TCP比作成熟的社會人，UDP則是頭腦簡單的小朋友。TCP複雜，UDP簡單。TCP維護連接，UDP誰都相信。TCP知進退，UDP愣頭青一個，勇往直前。
- ·UDP雖然簡單，但它有簡單的用法。它可以用在環境簡單、需要多播、應用層自己控制傳輸的地方，例如DHCP、VXLAN、QUIC等。
3.2 TCP(上):雖然複雜，使用起來卻輕鬆，本節總結如下:
- · TCP頭很複雜，但是主要關注五個方面:順序問題、丟包問題、連接維護、流量控制，以及擁塞控制。
- 連接的建立要經過三次握手，斷開要經過四次揮手。
3.3 TCP (下):西行必定多妖孽，恆心智慧消磨難，總結如下:
- 順序問題、丟包問題、流量控制都是通過滑動窗口來解決的，滑動窗口其實就相當於領導和下屬的工作備忘錄，佈置過的工作要有編號，幹完了有反饋，活兒不能派太多，也不能太少。
- 擁塞控制是通過擁塞窗口來解決的，相當於往管道里面倒水，快了容易溢出，慢了浪費帶寬，要摸着石頭過河，找到最優值。
3.4 socket: Talk is cheap, show me the code ，本節總結如下:
- 你需要記住在基於TCP和UDP的socket程序的函數調用過程中，客戶端和服務端都需要調用哪些函數。
- 寫一個能夠支撐大量連接的高併發的服務端不容易，需要多進程、多線程，而 epoll能解決C10K問題。
第4章常用的應用層．
4.1 HTTP:看個新聞原來這麼麻煩，本節總結如下:
- HTTP很常用，也很複雜，重點記住GET、POST、PUT、DELETE這幾個方法，以及重要的首部字段。
- HTTP2.0通過頭壓縮、分幀、二進制編碼、多路複用等技術提升性能。
- QUIC協議通過基於UDP自定義的連接、重傳、多路複用、流量控制等機制進一步提升性能。
4.2 HTTPS:點外賣的過程原來這麼複雜，本節總結如下:
- 加密分對稱加密和非對稱加密。對稱加密效率高，但是解決不了密鑰傳輸問題;非對稱加密可以解決這個問題，但是效率低。
- 非對稱加密需要通過證書和權威機構來驗證公鑰的合法性。
- HTTPS是綜合了對稱加密和非對稱加密的HTTP。既保證傳輸安全，也保證傳輸效率。
4.3流媒體協議:如何在直播裏看到帥哥美女，本節總結如下:
- 編碼兩大流派達成了一致，都是通過關於時間、空間的各種算法來壓縮數據的。
- 壓縮好的數據，爲了方便傳輸會組成一系列NALU，按照幀和片依次排列。
- 排列好的NALU在網絡傳輸時，要按照RTMP包的格式進行包裝，RTMP包會拆分成塊進行傳輸。
- 推送到流媒體服務器的視頻流經過轉碼和分發，可以被客戶端通過RTMP拉取，然後組合爲NALU，解碼成視頻格式進行播放。
4.4 P2P協議:下載電影，分佈式協議速度快，本節總結如下：
- 下載一個文件可以使用HTTP或FTP，這兩種協議都使用集中下載的方式，而P2P則換了一種思路，採取去中心化下載的方式。
- P2P也有兩種下載方式，一種是依賴於tracker服務器，即元數據集中，文件數據分散;另一種基於分佈式哈希算法，元數據和文件數據全部分散。
第5章陌生的數據中心.
5.1 DNS:網絡世界的地址簿，本節總結如下:
- DNS是網絡世界的地址簿，可以通過域名查詢地址，由於DNS服務器是按照樹狀結構組織的，因而域名查找使用的是遞歸的方法，並通過緩存的方式增強性能。
- 域名和IP地址相互映射的過程給了應用基於域名做負載均衡的機會,可以實現簡單的負載均衡，也可以根據地址和運營商實現全局負載均衡。
5.2 HTTPDNS:網絡世界的地址簿也會指錯路，本節需要記住以下兩個重點:
- ·傳統的DNS服務器有很多問題，例如解析慢、更新不及時。因爲緩存、轉發NAT問題導致客戶端誤會自己所在的位置和所屬的運營商，從而影響流量的調度。
- ·HTTPDNS服務器通過客戶端SDK，服務端通過HTTP直接調用解析DNS服務器的方式，繞過了傳統DNS服務器的缺點，實現了智能調度。
5.3 CDN:你去小賣部取過快遞嗎，本節需記住以下兩個重點:
- CDN和電商系統的分佈式倉儲系統-樣，分爲中心節點、區域節點、邊緣節點，將數據緩存在離用戶最近的位置。
- CDN最擅長的是緩存靜態數據,除此之外還可以緩存流媒體數據,這時要注意使用防盜鏈。CDN也支持動態數據緩存，可用模式有兩種:一種是邊緣計算的生鮮超市模式，另一種 是鏈路優化的冷鏈運輸模式。
5.4數據中心:我是開發商，自己拿地蓋別墅，本節需要記住以下3個重點:
- 數據中心分爲三層。服務器連接到接入層，然後是匯聚層，接着是核心層，最外面是邊界路由器和安全設備。
- 數據中心的所有鏈路都要高可用。服務器可以綁定網卡，交換機可以堆疊，三層設備可以通過等價路由，二層設備可以通過TRILL協議實現高可用。
- 隨着雲和大數據的發展,東西流量相較於南北流量更加重要,因而演進出葉脊網絡結構。
5.5 VPN:朝中有人好做官，本節總結如下:
- VPN可以將一個機構的多個數據中心通過隧道連接起來,讓機構感覺在一個數據中心裏面一樣，如同自駕遊通過瓊州海峽。
- 完全基於軟件的IPsec VPN可以保證私密性、完整性、真實性，簡單便宜，但是性能稍微差一些。
- MPLS-VPN綜合了I轉發模式和ATM標籤轉發模式的優勢，性能較好，但是需要從運營商處購買。
5.6移動網絡:去巴塞羅那，手機也上不了“臉書”，本節總結如下:
- 移動網絡的發展歷程從2G到3G，再到4G，功能逐漸從以打電話爲主轉變爲以上網爲主。
- 請記住4G網絡的結構，有eNodeB、MME、SGW、PGW等，分控制面協議和數據面協議，你可以對照這個結構，試着說出手機上網的流程。
- 即便你在國外運營商的範圍內上網，也要由國內運營商控制，因而也上不了“臉書”。
第6章雲計算中的網絡．
6.1雲中網絡:自己拿地成本高，購買公寓更靈活，本節總結如下:
- 雲計算的關鍵技術是虛擬化，這裏我們重點關注的是虛擬網卡通過打開TUN/TAP字符設備的方式，將虛擬機內外連接起來。
- 雲中的網絡重點關注四個方面:共享、隔離、互通、靈活。其中共享和互通有兩種常用的方式，分別是橋接和NAT，隔離可以通過VLAN的方式來進行。
6.2軟件定義網絡:共享基礎設施的小區物業管理辦法，本節總結如下:
- 用SDN 控制整個雲裏面的網絡，就像小區保安從總控室管理整個物業是一樣的，將控制面和數據面進行了分離。
- Open vSwitch是一種開源的虛擬交換機的實現，它能對經過自己的網絡包做任意修改，從而使得雲對網絡的控制十分靈活。
- 將Open vSwitch引入雲之後，可以使配置簡單而靈活，並且可以解耦物理網絡和虛擬網絡。
6.3雲中網絡之安全:雖然不是土豪，也需要基本保障，本節總結如下:
- 雲中的安全策略的常用方式是使用iptables的規則,請記住它的5個鏈:PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING。
- iptables 的表分爲4種: raw、mangle、nat、filter。其中安全策略主要在filter表中實現，而虛擬網絡和物理網絡地址的轉換主要在nat表中實現。
6.4雲中網絡之QoS:室友瘋狂下電影，我該怎麼辦，本節總結如下:
- 雲中的流量控制主要是通過隊列進行的，排隊規則分爲兩大類:無類別排隊規則和基於類別的排隊規則。
- 在雲中網絡Open vSwitch中，主要使用HTB將總的帶寬在一棵樹上按照配置的比例進行分配，並且在一個分支不使用流量時，借給另外的分支，從而增強帶寬利用率。
6.5雲中網絡之隔離GRE、VXLAN:雖然住一個小區，也要保護隱私，本節總結如下:
- 要對不同用戶的網絡進行隔離,解決VLAN數目有限的問題,需要通過Overlay的方式，常使用的是GRE和VXLAN。
- GRE是一種點對點的隧道模式，VXLAN是支撐組播的隧道模式，它們都要在某個隧道端口進行封裝和解封裝，實現跨物理機的互通。
- Open vSwitch可以作爲隧道端口，通過設置流表規則在虛擬機網絡和物理機網絡之間進行轉換。
第7章容器技術中的網絡．
7.1容器網絡:來去自由的日子，不買公寓去合租，本節總結如下:
- 容器是一種比虛擬機更加輕量級的隔離方式，主要通過namespace和 cgroup技術進行資源的隔離，namespace負責“看起來”隔離，cgroup負責“用起來”隔離。
- 容器網絡連接到物理網絡的方式和虛擬機很像，通過橋接的方式可以實現一臺物理機上容器的相互訪問，如果要訪問外網，最簡單的方式還是通過NAT。
7.2容器網絡之Flannel:每人一畝三分地.，本節總結如下:
- 基於NAT的容器網絡模型在微服務架構下有兩個問題，一個是IP地址重疊，另一個是端口衝突，需要通過Overlay 網絡保持跨節點的連通性。
- Flannel是跨節點容器網絡方案之一，它提供的Overlay方案主要有兩種方式，一種是UDP在用戶態封裝，另一種是VXLAN在內核態封裝，而VXLAN的性能更好一些。
7.3容器網絡之Calico:爲了高效說出善意的謊言，本節總結如下:
- Calico推薦使用物理機作爲路由器，這種模式沒有虛擬化開銷，性能比較高。
- Calico的主要組件包括路由、iptables 的配置組件Felix、路由廣播組件BGP Speaker，以及大規模場景下的BGP路由反射器。
- 爲解決跨網段的問題，Calico還有一種IPIP模式，即在兩臺機器之間打一個隧道，兩臺機器分別位於隧道兩端，這樣本來不是鄰居的兩臺機器，因爲隧道變成了相鄰的機器。
7.4 RPC概述:遠在天邊，近在眼前，本節總結如下:
- 遠程調用看起來用socket編程就可以了，其實是很複雜的，要解決協議約定問題、傳輸協議問題和服務發現問題。
- Bruce Jay Nelson的論文、早期ONC RPC框架，以及NFS的實現，給出瞭解決這三大問題的示範性實現，即協議約定要公用協議描述文件並通過這個文件生成Stub程序，RPC的傳輸一般需要一個狀態機，同時需要另外一個進程專門做服務發現。
第8章微服務相關協議．
8.1基於XML的SOAP:不要說NBA，請說美國職業籃球聯賽，本節總結如下:
- 原來的二進制RPC有很多缺點:格式要求嚴格、修改過於複雜、不面向對象。於是產生了基於文本的調用方式——基於XML的SOAP。
- SOAP的三大要素:協議約定用WSDL、傳輸協議用HTTP、服務發現用UDDL。
8.2基於JSON的RESTful接口協議:我不關心過程，請給我結果，本節總結如下。
- SOAP過於複雜，而且設計是面向動作的，因而往往因爲架構問題導致併發量上不去。
- RESTful不僅僅是一個API，還是一種架構模式，主要面向資源提供無狀態服務，有利於橫向擴展應對高併發。
8.3二進制類RPC協議:還是叫NBA吧，總說全稱多費勁，本節總結如下:
- RESTful API對於接入層和Controller層之外的調用，已基本形成事實標準，但隨着內部
- 服務之間的調用越來越多,性能也越來越重要，於是Dubbo的RPC框架有了用武之地。
- Dubbo通過註冊中心解決服務發現問題，通過Hessian2序列化解決協議約定的問題，通過Netty解決網絡傳輸的問題。
在更加複雜的微服務場景下，Spring Cloud的RESTful方式在內部調用時也會被考慮，重要的是JAR包的依賴和管理問題。
8.4跨語言類RPC協議:交流之前，雙方先交換一下專業術語表，本節總結如下:
- gRPC是一種二進制、性能好、跨語言、更靈活，同時可以進行服務治理的多快好省的
- gRPC框架，唯一的不足就是要寫協議文件。
- gRPC 在序列化時使用Protocol Buffers，網絡傳輸時使用HTTP 2.0，服務治理時可以使用基於Envoy的Service Mesh。
第9章網絡協議知識串講．
9.1 知識串講:用"雙*"的故事串起網絡協議的碎片知識(上)，
9.2 知識串講:用"雙*"的故事串起網絡協議的碎片知識(中)，
9.3 知識串講:用"雙*“的故事串起網絡協議的碎片知識（下)，
9.4 搭建—個網絡實驗環境:授人以魚不如授人以漁，
這份【趣談網絡協議】文檔共有435頁，需要完整版的朋友，可以轉發此文關注小編，私信小編【技術】來獲取！！
當然，單單有文檔看是遠遠不夠的，還有視頻和相匹配的課件進行學習提升，努力把計算機網絡這一塊兒給搞明白，相信一定會有不凡的人生！！
TCP/IP/網絡IO學習視頻
TCP/IP網絡協議
網絡IO
還有課件分享
IO課件
TCP/IP課件
TCP/IP/IO網絡通信視頻和課件獲取，點贊+關注小編，私信【技術】獲取！
好了，今天就分享到這裏了，希望大家能夠好好學習，把計算機網絡這一塊兒給提升上來，也希望本文能夠得到大家的喜歡！！