在日常生活中，我們要傳遞資訊，以前最常用的手段是郵寄信件，想象一下你寫信寄信的過程，寫信産生資料，寄信傳遞資料，标準的信件格式是要在信封上寫“收信人位址”和“寄信人位址”（由此引入IP位址），“收信人位址”對應資料包裡IP頭部中的“目的ip位址”，“寄信人位址”對應資料包裡IP頭部中的“源ip位址”，寫上寄信、收信兩個位址就可以保證信件可以郵寄到目的地了。
但信件郵寄到目的位址後由誰來收？從上面這封信的收件人位址檢索到這個位址是“沈陽大學”的，沈陽大學裡可能住着幾萬人，那你這封信是郵寄給居住沈陽大學裡的那個人的？收件人不明确，郵局就算幫你把信件送到這個位址，也沒辦法幫你投遞到具體的收信人。
是以，我們郵件信件需要填寫“收件人姓名”、“收件人位址”和“寄件人姓名”、“寄件人位址”的組合，這樣才能保證信件能準确投遞到具體的收件人手中。
是以我們要在信件上添加收信人姓名和寄信人姓名（由此引入端口号），這個時候收件人姓名就對應資料包裡TCP協定頭部中的目的端口号，寄信人姓名對應資料包裡TCP協定頭部中的源端口号。
我們再來對比傳遞信件與傳遞資料包的過程：
1.首先是位于南甯的李小明給沈陽的王小花通過QQ發送了一條消息，李小明的電腦将此消息打包成TCP資料包發送到計算機網絡中，計算機網絡通過資料包中的目的IP位址把該資料包準确傳遞到王小花的電腦。
2.王小花的電腦收到了李小明的電腦發送過來的資料包，但是王小花的電腦上同時運作有多個程式（例如圖中的QQ和微信），雖然王小花的電腦知道這個資料包是傳輸給它的，但是它不知道該把這個資料包中的資料交給那個程式（就像上面講的，信件雖然郵寄到了沈陽大學，但沈陽大學裡住着那麼多人，這封信上沒有标示說是郵寄給誰的）。
3.針對以上的問題。如果我們使用資料包結構中的源端口号和目的端口号，根據不同的程式使用不同的端口号來發送和接受資料，這樣資料包就能像郵寄信件一樣準确投遞到具體的電腦上指定的程式了。例如我們指定QQ和微信使用的端口号分别是8000和8080，那麼隻要你的電腦接收的資料包裡目的端口号是8000，那這個資料包就是傳輸給QQ的。
由上面的例子我們還可以引申出資料包結構中的其他字段的作用，例如我們收到信後可以簡單地通過信封是否完整來檢查該信件是否被别人在傳輸途中拆開并篡改過信件内容，那麼我們怎麼保證我們收到的資料包裡的資料有沒有在中途被别人拆開修改過呢？資料包結構中有一個字段叫TCP校驗和就是專門做這個工作的。由資料包的字段可以看出，很多字段都有其用處，隻是我們一開始學的時候沒必要學的那麼仔細而已。
一定要形象地了解資料包，簡單的想一下，計算機網絡不就是幫助我們傳遞資訊的嗎？對于郵寄信件來說，資訊的載體是信紙和信封，那計算機網絡中資訊的載體是什麼？就是各種類型的資料包啊！ 資料包裡有我們關心的資訊，也有我們不關心的花銷，我們要學的就是如何使網絡按照我們的要求傳遞資訊。例如，我們郵寄信件，有平信，有挂号信，根據不同的應用場景選擇不同的郵寄方式。計算機網絡裡資訊傳輸也是一樣，針對不同的場景使用不同的協定， 有些場景需要多種協定同時配合使用。
上面那個QQ的例子不太嚴謹，因為QQ和微信的資訊都是通過騰訊伺服器中轉的，但你是初學者沒必要一開始就深究這些細節，總之要學會把一切抽象的東西都對照生活中的一些場景使之形象化。這樣你的學習過程就不會那麼枯燥乏味了。
再來看一下為什麼需要網絡協定，我們看下圖的簡單類比：
從上圖可以看出，我們郵寄信件隻是想要把我們寫在信紙資訊傳遞出去，對于我們來說，郵寄信件需要購買信封和郵票，這對于我們來說是沒有意義的，甚至我們會覺得連信紙都是多餘的，因為還要購買信紙，我們隻是想傳遞資訊而已，信封、郵票和信紙對于我們來說是傳遞資訊的額外花銷，但是沒有這些花銷，你的資訊就無法通過郵局傳遞。同理，在計算機網絡裡也是一樣的，我們的通過計算機網絡傳遞資訊也需要額外的花銷，這些花銷展現在計算機網絡裡就是TCP/IP的各種協定資料包的頭部（除去應用層資料之外的其他資訊）。
你要知道計算機網絡裡的資料交換都是像我們日常郵寄信件一樣通過各種的資料包來傳遞的，了解了資料包的作用之後你就應該開始學習計算機網絡是如何把資料包傳輸到目的地的？例如我們的電腦在生成資料包時是怎麼知道對方電腦的ip位址的，（由此引入DNS）？我們的信件是最開始是通過郵局幫我們郵寄的，那麼我們的電腦的資料包應該由誰來幫我們傳輸呢？（由此引入網關），網關又是如何幫我們把資料包傳輸到目的地的？（由此引入各種路由協定）。
是以，你想要學習網絡協定，就要先把一些基本的協定的作用和工作過程搞清楚，網絡裝置還沒智能到人腦的程度，它是由人類創造出來的，它的工作過程肯定是符合人類的交流習慣，按照人類的交流習慣來設計的。是以要以人類的思維方式去了解這些協定。例如，你給别人打電話，不可能電話一接通你就啪啦啪啦地說一大通，萬一對方接通電話後因為有事還沒來得及傾聽呢？這不太符合正常人類的交流習慣。一般是電話接通後，雙方一般會有個互動的過程，一般是你說一聲“你好”，然後對方也回複一聲“你好”，雙方通過各自一句“你好”明确對方的注意力都放在了電話溝通上，然後你們雙方就可以開始交流了，這才是正常的人類交流方式，這個過程展現在計算機網絡裡就是網絡協定！我們通過TCP協定在兩台電腦建立網絡連接配接之前要先發資料包進行溝通，溝通後再建立連接配接，然後才是資訊的傳輸。而UDP協定就類似于我們的校園廣播，廣播内容已經通過廣播站播放出去了，你能不能聽到，那就與廣播站無關了，正常情況下，不可能你說沒注意聽然後再讓廣播站再播放一次廣播内容。
同理，我們來看一下網絡廣播，對于某一個網絡的網絡廣播，隻要發送一個網絡廣播包，這個子網裡的所有電腦都能收到這些廣播包，這是一個很友善的通知機制，但是會增加對廣播資料不感興趣主機的處理負荷。類似我們的校園廣播，校園廣播一開啟播放，校園裡的所有人都能聽到，但是不是所有人都對廣播内容感興趣，有些人選擇傾聽，有些人選擇忽略。但不管你是傾聽還是忽略，廣播的聲音都會傳到你的耳邊。例如，校園廣播一條失物招領通知，你根本沒丢東西，是以這個廣播内容與你無關，但是廣播的聲音還是會傳到你的耳邊。對比廣場舞音樂，對于跳廣場舞的大媽大嬸來說，這就是音樂，對于想睡覺的您來說，這就是噪音。
怎樣才能更好地了解常見的網絡協定？學習網絡協定就是要先學習它的工作過程，例如DHCP協定，協定大概是這樣講的：啟用了DHCP協定的電腦啟動後便會發送廣播資料包網絡中尋找DHCP伺服器，如果網絡中有DHCP伺服器，這台DHCP伺服器便會發送廣播資料包與你的電腦進行響應。
這個過程很簡單，就是我想要擷取ip位址，然後你給我提供一個。想象一下如果你是DHCP協定的設計者，你會考慮到在ip擷取和配置設定過程中會有哪些特殊情況呢？
第一種，如果在你啟動電腦的過程中網絡中的dhcp伺服器剛好當機了，這時怎麼辦？讓你的電腦一直徒勞地發送尋找DHCP伺服器的廣播包嗎？還是在發現沒有DHCP伺服器與你響應後就再也不發了？還是每隔一段時間就再發送一次尋找DHCP伺服器的廣播包？
第二種，如果DHCP伺服器的可用ip位址剛好已經配置設定完了，那又怎麼處理？
第三種，如果網絡中同時有兩台以上的DHCP伺服器，那又該怎麼處理？
第四種，對于已經配置設定出去的ip位址就這麼一直保持配置設定出去的狀态嗎？還是要回收？如果要回收？是我去問你還要不要使用這個ip位址？還是我設定一個回收的時間？隻要你在這個時間段内你沒有再次聯系我重新擷取這個ip位址我就把它回收？等等。。。
通過這樣的思考你可以發現，網絡協定其實也是按照人的思維方式在工作，但是網絡裝置不會像人一樣思考，是以我們當初給它設計各種協定的時候就要盡可能地為它想到這些協定所要應對的場景。例如，你可以先學習ARP協定的工作過程，然後再百度搜尋ARP攻擊是怎麼回事？就是利用ARP協定設計的不嚴謹，僞造ARP資料包篡改網絡裡其他電腦的ARP緩存清單。ARP協定采用廣播發送協定資料包，這就導緻裡網絡裡的每一台電腦都會收到ARP的協定資料包，而ARP協定規定即使你的電腦沒有發出arp請求，隻要有ARP回應包到達你的主機，你就要對這些協定包進行處理，并将回應包中的mac和ip對應關系放入自己的arp緩存。如果ARP回應包裡面的網關IP與ARP對應關系是正确的，這個問題不大，但如果有人在網絡中僞造了錯誤的網關IP與ARP對應關系并廣播到網絡裡，那就出問題了，你可能也意識到你上不了網是因為網關IP對應的ARP對應關系出錯，但是沒有辦法，因為你的電腦上運作的ARP協定規定，你的電腦必須要接受這個錯誤的對應關系，這就是網絡協定設計的不嚴謹，設計和實作ARP協定的時候沒有想到居然會有人在網絡中僞造ARP回應包并廣播到網絡中。
如果你看《TCP/IP詳解》這套書覺得很吃力，那就建議暫時不要看了，強烈建議你先看《計算機網絡自頂向下方法與Internet特色》這本書，這本書對常見的網絡協定的工作過程進行了分析，可讀性很強，看起來比《TCP/IP詳解》輕松多了，了解了常見協定的工作過程你就可以動手做實驗來驗證這個協定的工作過程了，建議先使用模拟器來做實驗，像cisco packet tracer 就很好用，它有個模拟功能可以像看動畫一樣看到網絡資料包是如何在網絡拓撲結構中傳輸和互動的，對了解協定的工作過程非常有用，還有抓取資料包的功能，可以抓去指定協定的資料包進行檢視。
使用真實裝置通過在電腦上安裝抓包工具進行抓包也可以，隻不過沒有模拟器上看得那麼直覺，對于初學者還是建議先以模拟器做實驗為主，因為你可以很直覺地觀察你所設計的網絡的運作情況，更容易把心放在學習網絡協定的工作過程上。
作者：知乎使用者
連結：https://www.zhihu.com/question/51074319/answer/124733136
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
如果這篇文章對你有幫助的話,評論或推薦下吧！(轉載請注明原作者！)