目錄：
網絡常見術語介紹
從一張圖看網絡參數，我們經常使用網絡的人都會見過下面這張圖，不過一般情況下大家都不會手動去配置，而是選擇自動獲取。那么有的時候當我們網絡出現故障了，無法自動獲取了，可能就需要去手動設置ip，所以還是需要對下面這些參數進行一定的了解的。
- ip地址：這是一個很大很繁瑣的東西，大家只需要知道電腦之間如果想要進行通信，就必須有一個網絡地址來識別每一台電腦。就好像我們打電話一樣，你要給你女朋友打電話，你就必須知道你女朋友的電話號，你如果想和目的主機通信，你就必須知道目的主機的ip地址。想要深入了解ip地址的朋友，可以參看我這一篇博客：
為什么百度查到的ip和ipconfig查到的不一樣；詳解公網Ip和私網ip；詳解網絡分類ＡＢＣ； - 子網掩碼（subnet mask）：將某個IP地址划分成網絡地址和主機地址兩部分。通常，我們使用子網掩碼和目的Ip進行&運算，來判斷目的Ip和自己的ip是否是在同一個局域網內
- 默認網關（default gateway）：我們可以把網關理解為路由器的ip地址。我們把ip地址擬人化，那么網關就是一棟大廈的門衛，所有人進出都要通過他。舉個例子，小米路由器的默認網關是192.168.31.1。而TPlink等等的大部分是192.168.0.1或者192.168.1.1。這些路由器所管理的所有主機要訪問外網的主機時，就必須要通過他們的默認網關。
- DNS服務器：域名服務器(Domain Name Server)。在Internet上域名與IP地址之間是一一對應的，域名雖然便於人們記憶，但機器之間只能互相認識IP地址，它們之間的轉換工作稱為域名解析，域名解析需要由專門的域名解析服務器來完成，DNS就是進行域名解析的服務器 。我們可以通俗的把它理解為一個黑盒子，你輸入域名，他就會輸出這個域名對應的ip地址。網絡之間通信還是靠的是ip，但是大多數人記不住這么多Ip,所以我們就想到了一個辦法建立一個黑盒子來實現ip和通俗域名之間的轉換。
- DHCP服務器： 就是能夠自動識別當前網絡環境，並依照當前網絡環境給你分配合適的ip地址的服務器。它的存在就是使手動設置Ip變得更加傻瓜式，實現一鍵上網。不需要你自己進行手動的配置
- ping:it術語中的ping類似於下圖的聲吶設置，如果目的電腦聯網，目的電腦會把這個Ping包發送回來。如果目的電腦不聯網，則ping包不會返還任何信息。所以在It界會經常使用這個命令來檢測電腦是否已經連上網絡
- 網段號： 我們知道ip由兩部分構成 網段號+主機號。當我們使用自身的子網掩碼和目的主機進行&運算時，我們就能得出目的主機的網段號，進而判斷目的主機與自己是否處在同一個網絡中。
- arp: 將已知的ip地址解析為對應的mac地址。（具體請百度）
- 集線器、交換機、路由器等設備介紹，請參看我下面的這篇博文。
集線器(hub),交換機以及路由器異同；沖突域和廣播域詳解 - 子網划分：對於該知識點的理解，可以參看下面博文：
子網划分詳解與子網划分實例精析
計算機之間是如何互相通信的
從上圖我們大概可以看到，小明和小美是處在同一個局域網內的，而小麗和他們都不在一個局域網內,那么肯定就會有兩種情況發生，一種是統一局域網之間的通信，還有一種情況就是不同局域網之間的通信。下面就分別對這兩種情況進行細致的說明。
相同網段的通信
小明和小美之間通信，其實就相當於小明主機ping10.1.1.3。下面我們來分析一下ping的這個流程。
1）小明利用自身的子網掩碼和小美的ip地址進行&運算，得到小美的網段號。然后小明發現自己和小美處在同一個網絡中。
2）檢查自身的arp緩存
- 當IP層的ARP高速緩存表中存在目的IP對應的MAC地址時：
直接封裝這個ping包並發送給小美 - 當IP層的ARP高速緩存表中不存在目的IP對應的MAC地址時:
小明按照路由表中的默認接口ETH0發送廣播給整個局域網，局域網內的每台主機都收到了這個信息，其他主機都無反應，但是小美這台主機10.1.1.3意識到這是在叫自己。然后采取點對點單播回復小明：我在這里，我的mac地址是xxxx.以后你可以用這個聯系方式聯系我。小明收到此回復后，保存到自己的通訊錄中（arp緩存中），方便下次聯系。然后通過剛才記錄的小紅的mac地址發送ping包，依照類似的步驟，很快小紅發出了回信。小明主機收到ping包的返回內容。
不同網段的通信
也就是上圖中小明和小麗的通信:
小明ip:10.1.1.2/24
小麗ip:10.1.2.2/24
第一步：判斷是否在同一個網段
小明將自己的子網掩碼和小麗的ip進行&運算，發現二人不在同一個網絡內。小明無法利用上文中的通信手段和小麗進行通信
第二步：查找路由表
既然無法直接通信，小明就想有沒有別的道路能夠到達小麗。於是他查看了自己的路由表，信息如下：
路由表內並沒有小麗的Ip信息。走投無路的小明決定走0.0.0.0這條路，0.0.0.0是默認路由，它的終點站是默認網關。
第三步：發現網關的mac地址
小明將網關的ip進行了第一步的操作，發現他們是在同一個網絡中，於是利用arp協議小明得到了默認網關的mac地址
第四步：發送ping包給網關
第五步：網關接收以太網幀
第六步：網關路由轉發
網關ip層查看這個ping包，去路由表里嘗試能否匹配到小麗的ip，下面是默認網關的路由表信息
剛好路由表里的第二條匹配到了小麗的網段號，到達下一條的方式是廣播，所以網關開始發送ARP廣播，並得到了小麗的mac地址，於是網關將這個ping包發送給了小麗
第七步：ping包彈回
小麗收到這個ping包后，不修改任何內容，重復第一步到第六步的內容，將這個ping包發送給了小明。
第八步：ping程序打印輸出
上圖是我用自己主機ping百度得到的結果，而小明電腦上將會收到跟我這個類似的結果。
計算機如何訪問Internet
上圖是我和室友在教室的網絡拓撲圖。下面我們來探討下，阿呆，ip：172.18.0.200是如何訪問百度服務器的，其過程是怎樣的。
當阿呆想要上百度的時候,阿呆就在瀏覽器中輸入www.baidu.com，那么接下來，電腦，路由器，以及百度服務器都做了什么呢？
第一步：域名解析
首先瀏覽器（程序）告訴DNS進程（程序）請幫我解析www.baidu.com的ip地址,然后才有一下dns的一系列操作
①用戶主機上運行着DNS的客戶端，就是我們的PC機或者手機客戶端運行着DNS客戶端了
②瀏覽器將接收到的url中抽取出域名字段，就是訪問的主機名，比如我現在要訪問百度：http://www.baidu.com/, 並將這個主機名傳送給DNS應用的客戶端
③DNS客戶機端向DNS服務器端發送一份查詢報文，報文中包含着要訪問的主機名字段（中間包括一些列緩存查詢以及分布式DNS集群的工作）
④該DNS客戶機最終會收到一份回答報文，其中包含有該主機名對應的IP地址
⑤一旦該瀏覽器收到來自DNS的IP地址，就可以向該IP地址定位的HTTP服務器發起TCP連接
其實也就是通過dns服務器，使我們能獲取到域名背后的ip地址。
第二步：打包http報文
如上圖所示瀏覽器將阿呆訪問百度的請求打包成http報文，然后瀏覽器將這份報文和百度服務器的ip交給tcp進程。tcp進程雖然知道了目的Ip地址，但是覺得不安全，不敢發出去，他覺得先發個ip包看看能不能收到比較好一點兒，於是有了第三步，TCP三次握手。
第三步：http觸發TCP進程三次握手連接
首先，我們來看一個簡單的示意圖，阿呆和百度服務器進行了三次對話.
- 通話A_阿呆to服務器：老鐵，有空嘛，聽到請回答。
- 通話B_服務器to阿呆：阿呆，我聽得到，你能聽到我嘛？
由通話A和通話B，我們能夠確定阿呆to服務器這條信道是通的
- 通話C_阿呆to服務器：我也聽得到你
同理，由通話B和通話C，我們能夠確定服務器to阿呆這條信道是通的
問題：為什么是三次握手，而不是二次或四次
這個問題很多人都有不同的見解，知乎上關於這個話題的討論，我貼在下面：
知乎：為什么要三次握手，而不是二次，四次
談一下自己的理解：
- 兩次握手：只能確定阿呆能發給百度信息，百度能收到，有可能百度to阿呆的信道是不通的，就有可能出現下面的情形：
因為信道不通，不知道對方喜歡自己，導致默默流淚，孤獨終老。 - 四次握手：我們通過三次就能夠知道阿呆和百度之間是能夠互相通信的，多增加一次握手，沒有任何實際意義。
三次是保證雙方互相明確對方能收能發的最低值。再往上加握手次數不過是提高“它是可用的”這個結論的可信程度。在ip進程的眼里，三次握手就是三個ip包，也就是說，我們在傳送數據之前，就花費了三個ip包的代價
第四步：TCP傳輸HTTP
到了這一步TCP真正開始傳輸數據了。
- 首先TCP把阿呆要訪問百度服務器的請求打包成一個ip包，然后發送給服務器，這個ip包里面不但有阿呆的請求，還有一個唯一的序列號.比如序列號為9527
- 服務器收到請求的ip包后，回傳一個ip包，告訴阿呆，我收到序列號為9527的Ip包了
我們由此知道這個序列好的作用就是讓阿呆知道服務器確實收到了請求ip包而不是其他ip包。
上述過程涉及到了兩個ip包，一個是阿呆發送的內容為”請求訪問服務器”的ip包，另一個是服務器發送的內容為”收到你的請求”的ip包
這兩個ip包總共傳送了一個數據，就是請求訪問服務器。服務器發送的IP包，主要是為了發送確認收到。
第五步:服務器回傳自身網頁
百度服務器開始把自己的主頁內容，也就是上圖的內容回傳給阿呆，我們假設百度回傳的內容只有一個ip包（實際可能很多）那么回傳的過程也很好理解，類似於第四步，一個ip包的內容是要發送的數據，一個ip發送的內容是：確認收到。服務器發送內容為百度主頁的ip包，阿呆發送內容為“確認收到”的ip包
同樣，這兩個ip包也只發送了一個數據，這個數據是百度的主頁內容。
簡而言之,tcp的可靠傳輸機制就是己方發送數據，對方發送確認
第六步：釋放TCP連接（四次揮手）
tcp連接是耗費資源的，包括內存資源和端口資源，所以當我們傳輸完數據之后，是時候說再見了，於是我們就有了四次揮手說拜拜。
為了方便我們更好地理解tcp。我們可以把tcp連接看成兩根水管兒，如上圖所示，一個藍水管，一個紅水管。對於阿呆而言，藍水管是出水管負責發送數據給服務器，而紅水管是進水管負責接收來自於服務器的數據，對於服務器而言，藍水管是進水管負責接收阿呆發的數據，紅水管是出水管負責給阿呆發送數據
我們關閉TCP連接，其實就是要關閉這兩根水管。我們利用四次對話來關閉這兩根管道。
- 通話A_阿呆to服務器：老鐵，我沒水(數據)要送了，准備關出水管了（藍水管）（服務器的進水管）。
- 通話B_服務器to阿呆：阿呆啊，你的所有水，我都接收完畢，你可以關掉藍水管了。
於是，阿呆就關掉了他的出水管（藍水管）
- 通話C_服務器to阿呆：阿呆啊，我沒水要送了，准備關出水管了（紅水管）（阿呆的進水管）。
- 通話D_阿呆to服務器：老哥，你的出水管里的水(數據)我已經接收完畢，請放心關閉。
於是，服務器就關掉了他的出水管（紅水管）
到此為止，TCP進程釋放資源完畢。
從tcp建立連接到tcp釋放連接我們一共用了11個ip包。tcp建立連接（三次握手）用了3個包；tcp傳送數據用了4個包，其中兩個用於傳送數據，兩個用來確認收到數據；關閉tcp連接（四次揮手）用了4個包。