苦且繞不過去，經過多次放棄之后，我發現在我的職業生涯中，網路這一關無論如何也繞不過去，本來覺得寫Java程式時可以依賴別人的庫，所以就不用關心這么多底層的技術了，但是到后來才發現，服務數量一多，吞吐量一大，我們關心的不再僅僅是某個Java應用，而是要提升整個集群的性能，這時網路問題就會出現，而且大規模的微服務架構必定要上云、使用VPC網路，這時就必定要考慮雙活和災備，必定要做各個層次的負載均衡，這些都需要網路方面的技術，既然繞不過去，那就必須“啃”下它，于是我就進入了暗無天日的網路協議學習的程序，

見山開路、遇水搭橋，遇到一個知識點攻克一個，再將其寫到博客或者筆記里面，有時候要看很多文章和書才能攻克一個知識點，但我還是每天下班抱著網路技術相關的文章和書看，直到將各個零散的知識點串連了起來，后來在定位網路問題的時候，我開始有了自己的思路，這時才感覺算是暫時趟過了這條河，

網路協議知識點太多，學完記不住，大部分讀者應該都學過計算機網路課程，學的時候感覺并不難，尤其這門課沒有公式，更像是文科的東西，學了一大堆東西，也背了一大堆東西，但是最終應付完考試之后，都“還給了老師”

每次都感覺自己好像學會了，但實際應用的時候依舊無從下手，雖然很多細節都摸索得差不多了，但是當自己去應用和除錯時，才發現還是沒有任何思路，比如，當創建出來的虛擬機不能上網時，還是無從下手，學過的很多東西，似乎都用不上，我把這種現象總結為：一看覺得懂，一問就打鼓，一用就糊涂，

所以本書使用了“趣談”這種方式，它可以解決從“入門到放棄”的問題，把晦澀的知識點和一些有趣的故事通過比喻的方式結合起來，這樣更容易幫助讀者系統、深入地了解網路技術的知識點和大致的作業流程，

主要包括的內容和總結三部分給大家進行網路協議的拓展學習，希望大家能夠喜歡！！

第1 章 通信協議概述

1.1 為什么要學習網路協議

相信大家都信過通天塔的故事，上帝為了阻止人類聯合起來，讓人類說不同的語言，人類沒法溝通，達不成“協議", 通天塔的計劃就失敗了，

但是千年以后，有一種叫“程式猿”的物種，“敲”著一種這個群體通用的語言，打造著互聯網世界的“通天塔”，如今的世界，正是因為互聯網，才連接在一起，

public class HelloWorld {
  publ工cstatic void ma工口（String[]args) {
     System.out.println(”Hello World 1”);
  ）
）

如果你是程式員，一定看得懂上面這一段文字，這是每一個程式員向計算機世界說“你好，世界”的方式，但是，你不一定知道，這段文字也是一種協議，是人類和計算機溝通的協議，只有通過這種協議，計算機才知道我們想讓它做什么，

第 2 章 從二層到三層

2.1 從物理層到MAC 層：如何在宿舍里自己組網玩聯機游戲

第一層：物理層

• 路由器的使用發生在第三層上，我們先從第一層物理層開始說，
• 物理層能折騰什么？現在的同學可能想不到，我們當時去學校配電腦的地方買網線，賣網線的師傅都會問，你的網線是要電腦連電腦啊，還是電腦連網口啊？
• 我們要的是電腦連電腦的網線，就是將一根網線的一頭插在一臺電腦的網卡上，另一頭插在另一臺電腦的網卡上，但是在當時，用普通的網線這樣連接是通不了的，所以水晶頭要做交叉線，用的就是所謂的1-3,2-6交叉接法，
• 水晶頭的第l、2腳和第3'6腳，分別起著WL發信號的作用，將一端的1號線和3號線、2號線和6號線互換一下位置，就能夠在物理層實作兩端通信，
• 當然電腦連電腦，除了網線要交叉，還需要配置這兩臺電腦的IP地址、子網掩碼和默認網關，這3個概念前文已經詳細描述過了，要想兩臺電腦能夠通信，兩臺電腦的這3項必須屬于一個網路，否則是行不通的，

第二層：MAC層

你可能已經發現問題了，Hub采取的是廣播的模式，如果每一臺電腦發出的網路包，宿舍里的每臺電腦都能收到，那就麻煩了，這時就需要解決以下幾個問題：

• 這個網路包是發給誰的？誰應該接受？
• 大家都在發，會不會產生混亂？有沒有誰先發、誰后發的規則？
• 如果發送的時候出現了錯誤，怎么辦

這幾個問題，都發生在第二層鏈路層，即MAC層要解決的問題，MAC的全稱是MediumAccess Control，即媒體訪問控制，控制什么呢？其實就是給媒體發送資料時，控制誰先發、誰后發，防止發生混亂，MAC層解決的是第二個問題，這個問題學名叫多路訪問，有很多演算法可以解決，就像車管所管理車輛一樣，會想出很多辦法，比如以下3種方式，

• 方式一：分多個車道，每個車一個車道，你走你的，我走我的，這在計算機網路里叫作信道劃分協議，
• 方式二：今天單號出行，明天雙號出行，輪著來，這在計算機網路里叫作輪流協議，
• 方式三：不管三七二十一，有事兒先出門，發現特堵，就回去，錯過高峰再出門，這在計算機網路里叫作隨機接入協議，著名的以太網，用的就是這個協議，

第 3 章 重要的傳輸層

3.1 UDP：雖然簡單但是可以走制化

TCP和UDP有哪些區別

一般在面試時，如果面試官問這兩個協議的區別是什么，大部分面試者會回答，TCP是面向連接的，UDP是面向無連接的，

什么叫面向無連接，什么叫面向無連接呢？在互通之前，面向連接的協議會先建立連接，例如，TCP會進行三次握手來建立連接，而UDP不會，為什么要建立連接呢？TCP可以進行三次握手，UDP可以發三個包，難道不都是建立連接嗎？

所謂的建立連接，是為了維護客戶端和服務端的連接而去建立一定的資料結構，從而維護雙方互動的狀態，并用這樣的資料結構來保證面向連接的特性，

例如，TCP提供可靠交付，通過TCP連接傳輸的資料能夠無差錯、不丟失、不重復，并且可以按序到達，我們都知道IP包是沒有提供任何可靠性保證的，一旦發出去，就像西天取經，走丟了、被妖怪吃了，都只能隨它去，TCP號稱能做到連接維護程序做的事情，這部分內容在下面兩節中會詳細描述，而UDP繼承了IP包的特性，不保證傳輸的資料不丟失，也不保證按序到達，

再如，TCP是面向位元組流的，發送時發的是一個流，沒頭沒尾，但TCP基于的E層發送的可不是一個流，而是一個個的IP包，到TCP層后之所以變成流，是因為TCP自身的狀態維護做了相應的處理，而UDP則不一樣，它繼承了IP包的特性，也是一個一個地發，一個一個地收，在UDP層發送的一個個資料包，還有－個名字叫資料包，

另外，TCP是可以進行擁塞控制的，它意識到包已經被丟棄或者網路環境變差時，就會根據情況調整自己的行為，看看是不是資料包發得太快了，要不要發慢點，UDP就不會，應用讓我發，我就發，管它洪水滔天，

因而TCP是有狀態服務，通俗地講就是它“有腦子”，它精確地知道資料包是否已經被發送出去、是否被接收、發送到哪兒了、應該接收哪個資料包了，錯一點兒都不行，而UDP則是無狀態服務，通俗地說就是它“沒腦子”，天真無邪，發出去就發出去了，后續就不管了，

如果說MAC層定義了本地局域網的傳輸行為，IP層定義了整個網路端到端的傳輸行為，那么這兩層就基本定義了這樣的“基因”：網路傳輸是以包為單位的（網路包在不同的層有不同的叫法，鏈路層叫幀，網路層叫包，傳輸層叫段，我們可以籠統地稱之為包），包單獨傳輸，自行選路，在不同的設備上進行封裝、解封裝，不保證到達，基于這個“基因”，生下來的“孩子”UDP就完全繼承了這些特性，幾乎沒有自己的思想，

第 4 章 常用的應用層

4.1 HTTP：看個新聞原來這么麻煩

接下來開始講應用層的協議，就從最常用的HTTP開始講起，

HTTP幾乎是每個人上網用的第一個協議，同時也是很容易被忽略的協議，

既然本節要講看新聞，咱們就先登錄某新聞網站http://www.***·com，

http//www.***.com是一個URL( Uniform Resource Locator，統一資源、定位符），之所以叫統一，是因為它是有格式的，HTTP稱為協議，WWW.＊忡.com是一個域名，表示互聯網上的一個位置，有的URL會有更詳細的位置標識，例如http://www.***·corn/index.html，正是因為URL是統一的，所以當你把這樣一個字串輸入到瀏覽器的地址框里進行搜索的時候，瀏覽器才能知道如何進行統一處理，

第 5 章 陌生的資料中心

5.1 DNS：網路世界的地址簿

什么是DNS服務器

在網路世界，也是一樣的，你肯定記得住網站的名稱，但是很難記住網站的IP地址，因此也需要一個地址簿，即DNS(Domain Name System，域名系統）服務器，

由此可見，DNS服務器在日常生活中多么重要，每個人上網都需要訪問它，但是同時，這對它來講也是非常大的挑戰，一旦它出了故障，整個互聯網都將癱瘓，另外，上網的人分布在世界各地，如果大家都去同一個地方訪問某個服務器，時延將會非常大，因而，DNS服務器一定要設定成高可用、高并發和分布式的，

于是，就有了樹狀的層次結構，如圖所示，

• 根DNS服務器：回傳頂級域DNS服務器的IP地址，
• 頂級DNS服務器：回傳權威DNS服務器的IP地址，
• 權威DNS服務器：回傳相應主機的E地址，

第 6 章 云計算中的網路

6.1 云中網路：自己拿地成本高，購買公寓更靈活

我們知道了資料中心里面堆著一大片一大片的機器，相互之間用網路連接，如果機器數量非常多，那么維護起來還是挺麻煩的，有好多不靈活的地方，比如以下幾點

• 采購不靈活：如果客戶需要一臺電腦，那就需要自己采購、上架、插網線、安裝作業系統，周期非常長，一旦采購了，一用就得好多年，不能退貨，｜哪怕業務不做了，機器還在資料中心里留著，
• 運維不靈活：一旦需要擴容CPU、記憶體、硬碟，都需要去機房手動弄，非常麻煩，
• 規格不靈活：采購的機器往往動不動幾百GB的記憶體，而每個應用往往可能只需要4核8GB，所以很多應用混合部署在上面，埠可能會相互沖突，容易相互影響，
• 復用不靈活：一臺機器，一旦一個用戶不用了，另外一個用戶，就需要重裝作業系統，
• 因為原來的作業系統可能遺留著很多資料，非常麻煩，

第 7 章 容器技術中的網路

7.1 容器網路：來去自由的日子，不買公寓去合租

如果說虛擬機是買公寓，容器則相當于合租，有一定的隔離，但是隔離性沒有那么好，云計算解決了基礎資源層的彈性伸縮問題，卻沒有解決由于基礎資源層彈性伸縮而帶來的PaaS層應用批量、快速部署問題，于是，容器應運而生，

容器即Container，而Container的另一個意思是集裝箱，其實容器的思想就是要變成軟體交付的集裝箱，集裝箱有兩個特點：一是打包，二是標準，

在沒有集裝箱的時代，假設要將貨物從A運到B，中間要經過三個碼頭、換三次船，那么每次都要將貨物卸下船來，弄得亂七八糟，然后再搬上船重新擺好，如圖7-1所示，在沒有集裝箱的時候，每次換船，船員們都要在岸上待幾天才能干完活，

有了尺寸全部都一樣的集裝箱以后，可以把所有的貨物都打包在一起，每次換船的時候，把整個集裝箱搬過去就行了，幾個小時就能完成，船員換船時間大大縮短，如圖7-2所示，這是集裝箱的“打包”和“標準”兩大特點在生活中的應用，

第 8 章 微服務相關協議

8.1 基于XML 的SOAP：不要說NBA，請說美國職業籃球聯賽

ONC RPC存在哪些問題

ONCRPC將客戶端要發送的引數及服務端要發送的回復都壓縮為一個二進制串，這樣固然能夠解決雙方協議約定的問題，但是仍然不方便，

首先，需要雙方的壓縮格式完全一致，一點都不能差，一旦有少許的差錯，多一位、少一位或者錯一位，都可能造成無法解壓縮，當然，我們可以通過提高傳輸層的可靠性，以及加入校驗值等方式來減少傳輸程序中的差錯，

其次，協議修改不靈活，除了傳輸程序中造成的差錯，客戶端因為業務邏輯的改變添加或者洗掉了欄位，或者服務端添加或者洗掉了語段而沒有及時通知對方，或者線上系統沒有及時升級，都會造成解壓縮不成功，

因而，當業務發生改變，需要多傳輸或者少傳輸一些引數時，都需要及時通知對方，并且根據約定好的協議檔案重新生成雙方的Stub程式，自然，這樣操作的靈活性比較差，

如果僅僅是溝通的問題還好解決，更難處理的是版本的問題，比如在服務端提供一個服務，引數的格式是版本l的，已經有50個客戶端在線上呼叫了，現在有一個客戶端有一個需求，要加一個欄位，怎么辦呢？這可是一個大工程，所有的客戶端都要適配這個，重新寫程式，哪怕不需要這個欄位的客戶端也要加上這個欄位，并傳輸0，這些程式員就很委屈，本來沒我什么事兒，為什么讓我也忙活？

最后，ONCRPC的設計明顯是面向函式的，而非面向物件，而當前面向物件的業務邏輯設計與實作方式已經成為主流，

這一切的根源就在于壓縮，就像平時我們愛用縮略語，如果是籃球愛好者，你直接說NBA(National Basketball Association，美國職業籃球聯賽），他馬上就知道什么意思，但是如果你和一個大媽說NBA，她可能就聽不懂，

所以，這種RPC框架只能用于客戶端和服務端全由一批人開發的場景，或者至少客戶端和服務端的開發人員要密切溝通，相互合作，有大量的共同語言，才能按照既定的協議順暢地進行作業，

XML與SOAP

但是，一般情況下，我們做一個服務，都是要提供給陌生人用的，你和客戶不會經常溝通，也沒有什么共同語言，這時就不適合用縮略語，就像你給別人介紹陽A，你要說美國職業籃球聯賽，這樣不管他是做什么的，都能聽得懂，

放到我們的場景中，就是用文本類的方式進行傳輸，無論哪個客戶端獲得這個文本，都能夠知道它的意義，

第 9 章 網路協議知識串講

9.1 知識串講:用"雙*"的故事串起網路協議的碎片知識(上)

9.2 知識串講:用"雙*"的故事串起網路協議的碎片知識(中)

9.3 知識串講:用"雙*“的故事串起網路協議的碎片知識（下)

9.4 搭建—個網路實驗環境:授人以魚不如授人以漁

總目錄：

好了，本篇文章就分享到這里了，希望這份【趣談網路協議】對大家有所幫助，小編在這里也感謝大家對小編的支持😉