網路知識（上）

一、HTTP基礎

??常見的HTTP相關問題可以分為5大類：

1. HTTP 基本概念
2. Get 與 Post
3. HTTP 特性
4. HTTPS 與 HTTP
5. HTTP/1.1、HTTP/2、HTTP/3 演變

??用圖表示的話：

1.1 HTTP 基本概念

??HTTP 是超文本傳輸協議，也就是HyperText Transfer Protocol，它可以拆成三個部分：超文本、傳輸、協議，

??HTTP協議是一個用在計算機世界里的協議，它使用計算機能夠理解的語言確立了一種計算機之間交流通信的規范（兩個以上的參與者），以及相關的各種控制和錯誤處理方式（行為約定和規范），
??HTTP 協議是一個雙向協議，
??HTTP 是一個在計算機世界里專門用來在兩點之間傳輸資料的約定和規范，
??HTTP 傳輸的內容是「超文本」，超文本是文字、圖片、視頻等的混合體，最關鍵有超鏈接，能從一個超文本跳轉到另外一個超文本，HTML 就是最常見的超文本了，它本身只是純文字檔案，但內部用很多標簽定義了圖片、視頻等的鏈接，再經過瀏覽器的解釋，呈現給我們的就是一個文字、有畫面的網頁了，
??綜合以上特點：HTTP 是一個在計算機世界里專門在「兩點」之間「傳輸」文字、圖片、音頻、視頻等「超文本」資料的「約定和規范」，

1.1.1 狀態碼

• 1xx
  ?1xx 類狀態碼屬于提示資訊，是協議處理中的一種中間狀態，實際用到的比較少，
• 2xx
  ?2xx 類狀態碼表示服務器成功處理了客戶端的請求，也是我們最愿意看到的狀態，
  ?「200 OK」是最常見的成功狀態碼，表示一切正常，如果是非 HEAD 請求，服務器回傳的回應頭都會有 body 資料，
  ?「204 No Content」也是常見的成功狀態碼，與 200 OK 基本相同，但回應頭沒有 body 資料，
  ?「206 Partial Content」是應用于 HTTP 分塊下載或斷點續傳，表示回應回傳的 body 資料并不是資源的全部，而是其中的一部分，也是服務器處理成功的狀態，
• 3xx
  ?3xx 類狀態碼表示客戶端請求的資源發送了變動，需要客戶端用新的 URL 重新發送請求獲取資源，也就是重定向，
  ?「301 Moved Permanently」表示永久重定向，說明請求的資源已經不存在了，需改用新的 URL 再次訪問，
  ?「302 Found」表示臨時重定向，說明請求的資源還在，但暫時需要用另一個 URL 來訪問，
  ?301 和 302 都會在回應頭里使用欄位 Location ，指明后續要跳轉的 URL，瀏覽器會自動重定向新的URL，
  ?「304 Not Modified」不具有跳轉的含義，表示資源未修改，重定向已存在的緩沖檔案，也稱快取重定向，用于快取控制，
• 4xx
  ?4xx 類狀態碼表示客戶端發送的報文有誤，服務器無法處理，也就是錯誤碼的含義，
  ?「400 Bad Request」表示客戶端請求的報文有錯誤，但只是個籠統的錯誤，
  ?「403 Forbidden」表示服務器禁止訪問資源，并不是客戶端的請求出錯，
  ?「404 Not Found」表示請求的資源在服務器上不存在或未找到，所以無法提供給客戶端，
• 5xx
  ?5xx 類狀態碼表示客戶端請求報文正確，但是服務器處理時內部發生了錯誤，屬于服務器端的錯誤碼，
  ?「500 Internal Server Error」與 400 型別，是個籠統通用的錯誤碼，服務器發生了什么錯誤，我們并不知道，
  ?「501 Not Implemented」表示客戶端請求的功能還不支持，類似“即將開業，敬請期待”的意思，
  ?「502 Bad Gateway」通常是服務器作為網關或代理時回傳的錯誤碼，表示服務器自身作業正常，訪問后端服務器發生了錯誤，
  ?「503 Service Unavailable」表示服務器當前很忙，暫時無法回應服務器，類似“網路服務正忙，請稍后重試”的意思，

1.1.2 http 常見欄位

• 1、Host 欄位
  ?客戶端發送請求時，用來指定服務器的域名，
  
  ?有了 Host 欄位，就可以將請求發往「同一臺」服務器上的不同網站，
• 2、Content-Length 欄位
  ?服務器在回傳資料時，會有 Content-Length 欄位，表明本次回應的資料長度，
  
  ?該欄位的意思：本次服務器回應的資料長度是 1000 個位元組，后面的位元組就屬于下一個回應，
• 3、Connection 欄位
  ?Connection 欄位最常用于客戶端要求服務器使用 TCP 持久連接，以便其他請求復用，
  
  ?HTTP/1.1 版本的默認連接都是持久連接，但為了兼容老版本的 HTTP，需要指定 Connection 首部欄位的值為 Keep-Alive ，
• 4、Content-Type 欄位
  ?Content-Type 欄位用于服務器回應時，告訴客戶端，本次資料是什么格式，
  
  ?上面的型別表明，發送的是網頁，而且編碼是UTF-8，客戶端請求的時候，可以使用 Accept 欄位宣告自己可以接受哪些資料格式，
• 5、Content-Encoding 欄位
  ?Content-Encoding 欄位說明資料的壓縮方法，表示服務器回傳的資料使用了什么壓縮格式，
  
  ?上面表示服務器回傳的資料采用了 gzip 方式壓縮，告知客戶端需要用此方式解壓，客戶端在請求時，用 Accept-Encoding 欄位說明自己可以接受哪些壓縮方法，

1.2 GET 與 POST

??Get 方法的含義是請求從服務器獲取資源，這個資源可以是靜態的文本、頁面、圖片視頻等，
??POST 方法則是相反操作，它向 URI 指定的資源提交資料，資料就放在報文的 body 里，
??GET 和 POST 方法都是安全和冪等的嗎？

在 HTTP 協議里，所謂的「安全」是指請求方法不會「破壞」服務器上的資源，
所謂的「冪等」，意思是多次執行相同的操作，結果都是「相同」的，

??GET 方法就是安全且冪等的，因為它是「只讀」操作，無論操作多少次，服務器上的資料都是安全的，且每次的結果都是相同的，
??POST 因為是「新增或提交資料」的操作，會修改服務器上的資源，所以是不安全的，且多次提交資料就會創建多個資源，所以不是冪等的，

1.3 HTTP 特性

1.3.1 優點

??HTTP 最凸出的優點是「簡單、靈活和易于擴展、應用廣泛和跨平臺」，

• 1、簡單
  ?HTTP 基本的報文格式就是 header + body ，頭部資訊也是 key-value 簡單文本的形式，易于理解，降低了學習和使用的門檻，
• 2、靈活和易于擴展
  ?HTTP協議里的各類請求方法、URI/URL、狀態碼、頭欄位等每個組成要求都沒有被固定死，都允許開發人員自定義和擴充，
  ?同時 HTTP 由于是作業在應用層（ OSI 第七層），則它下層可以隨意變化，
  ?HTTPS 也就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層，HTTP/3 甚至把 TCP 層換成了基于 UDP 的 QUIC，
• 3、應用廣泛和跨平臺

1.3.2 缺點

??HTTP 協議里有優缺點一體的雙刃劍，分別是「無狀態、明文傳輸」，同時還有一大缺點「不安全」，
??無狀態的好處，因為服務器不會去記憶 HTTP 的狀態，所以不需要額外的資源來記錄狀態資訊，這能減輕服務器的負擔，能夠把更多的 CPU 和記憶體用來對外提供服務，
??無狀態的壞處，既然服務器沒有記憶能力，它在完成有關聯性的操作時會非常麻煩，例如登錄->添加購物車->下單->結算->支付，這系列操作都要知道用戶的身份才行，但服務器不知道這些請求是有關聯的，每次都要問一遍身份資訊，
??對于無狀態的問題，解法方案有很多種，其中比較簡單的方式用 Cookie 技術，

Cookie 通過在請求和回應報文中寫入 Cookie 資訊來控制客戶端的狀態，

??HTTP 比較嚴重的缺點就是不安全：

1、通信使用明文（不加密），內容可能會被竊聽，比如，賬號資訊容易泄漏，
2、不驗證通信方的身份，因此有可能遭遇偽裝，比如，訪問假的淘寶、拼多多，
3、無法證明報文的完整性，所以有可能已遭篡改，比如，網頁上植入垃圾廣告，視覺污染，

??HTTP 的安全問題，可以用 HTTPS 的方式解決，也就是通過引入 SSL/TLS 層，使得在安全上達到了極致，

1.3.3 HTTP/1.1 的性能

??HTTP 協議是基于 TCP/IP，并且使用了「請求 - 應答」的通信模式，
??HTTP/1.1 提出了長連接的通信方式，也叫持久連接，這種方式的好處在于減少了 TCP 連接的重復建立和斷開所造成的額外開銷，減輕了服務器端的負載，

持久連接的特點是，只要任意一端沒有明確提出斷開連接，則保持 TCP 連接狀態，

??HTTP/1.1 采用了長連接的方式，這使得管道（pipeline）網路傳輸成為了可能，即可在同一個 TCP 連接里面，客戶端可以發起多個請求，只要第一個請求發出去了，不必等其回來，就可以發第二個請求出去，可以減少整體的回應時間，
??舉例來說，客戶端需要請求兩個資源，以前的做法是，在同一個TCP連接里面，先發送 A 請求，然后等待服務器做出回應，收到后再發出 B 請求，管道機制則是允許瀏覽器同時發出 A 請求和 B 請求，
??但是服務器還是按照順序，先回應 A 請求，完成后再回應 B 請求，要是前面的回應特別慢，后面就會有許多請求排隊等著，這稱為「隊頭堵塞」，
??「請求 - 應答」的模式加劇了 HTTP 的性能問題，因為當順序發送的請求序列中的一個請求因為某種原因被阻塞時，在后面排隊的所有請求也一同被阻塞了，會招致客戶端一直請求不到資料，這也就是「隊頭阻塞」，
??因此，HTTP/1.1 的性能一般般，后續的 HTTP/2 和 HTTP/3 就是在優化 HTTP 的性能，

1.4 HTTP 與 HTTPS

??HTTP 與 HTTPS 有哪些區別？

1. HTTP 是超文本傳輸協議，資訊是明文傳輸，存在安全風險的問題，HTTPS 則解決 HTTP 不安全的缺陷，在 TCP 和 HTTP 網路層之間加入了 SSL/TLS 安全協議，使得報文能夠加密傳輸，
2. HTTP 連接建立相對簡單， TCP 三次握手之后便可進行 HTTP 的報文傳輸，而 HTTPS 在 TCP三次握手之后，還需進行 SSL/TLS 的握手程序，才可進入加密報文傳輸，
3. HTTP 的埠號是 80，HTTPS 的埠號是 443，
4. HTTPS 協議需要向 CA（證書權威機構）申請數字證書，來保證服務器的身份是可信的，

??HTTP 由于是明文傳輸，所以安全上存在以下三個風險：

1. 竊聽風險，比如通信鏈路上可以獲取通信內容，
2. 篡改風險，比如強制植入垃圾廣告，視覺污染，
3. 冒充風險，比如冒充淘寶網站，用戶錢容易沒，

??HTTP 與 HTTPS兩者分層區別：

??HTTPS 在 HTTP 與 TCP 層之間加入了 SSL/TLS 協議，可以很好的解決了上述的風險：

1. 資訊加密：互動資訊無法被竊取，
2. 校驗機制：無法篡改通信內容，篡改了就不能正常顯示，
3. 身份證書：證明淘寶是真的淘寶網，

??說的專業些：

1. 混合加密的方式實作資訊的機密性，解決了竊聽的風險，
2. 摘要演算法的方式來實作完整性，它能夠為資料生成獨一無二的「指紋」，指紋用于校驗資料的完整性，解決了篡改的風險，
3. 將服務器公鑰放入到數字證書中，解決了冒充的風險，

1.4.1 混合加密

??通過混合加密的方式可以保證資訊的機密性，解決了竊聽的風險，

??HTTPS 采用的是對稱加密和非對稱加密結合的「混合加密」方式：

1、在通信建立前采用非對稱加密的方式交換「會話秘鑰」，后續就不再使用非對稱加密，
2、在通信程序中全部使用對稱加密的「會話秘鑰」的方式加密明文資料，

??采用「混合加密」的方式的原因：

1、對稱加密只使用一個密鑰，運算速度快，密鑰必須保密，無法做到安全的密鑰交換，
2、非對稱加密使用兩個密鑰：公鑰和私鑰，公鑰可以任意分發而私鑰保密，解決了密鑰交換問題但速度慢，

1.4.2 摘要演算法

??摘要演算法用來實作完整性，能夠為資料生成獨一無二的「指紋」，用于校驗資料的完整性，解決了篡改的風險，

??客戶端在發送明文之前會通過摘要演算法算出明文的「指紋」，發送的時候把「指紋 + 明文」一同加密成密文后，發送給服務器，服務器解密后，用相同的摘要演算法算出發送過來的明文，通過比較客戶端攜帶的「指紋」和當前算出的「指紋」做比較，若「指紋」相同，說明資料是完整的，

1.4.3 數字證書

??客戶端先向服務器端索要公鑰，然后用公鑰加密資訊，服務器收到密文后，用自己的私鑰解密，
??這就存在些問題，如何保證公鑰不被篡改和信任度？所以這里就需要借助第三方權威機構 CA （數字證書認證機構），將服務器公鑰放在數字證書（由數字證書認證機構頒發）中，只要證書是可信的，公鑰就是可信的，

1.4.4 HTTPS 是如何建立連接的？其間互動了什么？

??SSL/TLS 協議基本流程：

客戶端向服務器索要并驗證服務器的公鑰，
雙方協商生產「會話秘鑰」，
雙方采用「會話秘鑰」進行加密通信，

??前兩步也就是 SSL/TLS 的建立程序，也就是握手階段，SSL/TLS 的「握手階段」涉及四次通信：

??SSL/TLS 協議建立的詳細流程：

• 1、ClientHello
  ?首先，由客戶端向服務器發起加密通信請求，也就是 ClientHello 請求，在這一步，客戶端主要向服務器發送以下資訊：

（1）客戶端支持的 SSL/TLS 協議版本，如 TLS 1.2 版本，
（2）客戶端生產的亂數（ Client Random ），后面用于生產「會話秘鑰」，
（3）客戶端支持的密碼套件串列，如 RSA 加密演算法，

• 2、SeverHello
  ?服務器收到客戶端請求后，向客戶端發出回應，也就是 SeverHello ，服務器回應的內容有如下內容：

（1）確認 SSL/ TLS 協議版本，如果瀏覽器不支持，則關閉加密通信，
（2）服務器生產的亂數（ Server Random ），后面用于生產「會話秘鑰」，
（3）確認的密碼套件串列，如 RSA 加密演算法，
（4）服務器的數字證書，

• 3、客戶端回應
  ?客戶端收到服務器的回應之后，首先通過瀏覽器或者作業系統中的 CA 公鑰，確認服務器的數字證書的真實性，如果證書沒有問題，客戶端會從數字證書中取出服務器的公鑰，然后使用它加密報文，向服務器發送如下資訊：

（1）一個亂數（ pre-master key ），該亂數會被服務器公鑰加密，
（2）加密通信演算法改變通知，表示隨后的資訊都將用「會話秘鑰」加密通信，
（3）客戶端握手結束通知，表示客戶端的握手階段已經結束，這一項同時把之前所有內容的發生的資料做個摘要，用來供服務端校驗，

??上面第一項的亂數是整個握手階段的第三個亂數，這樣服務器和客戶端就同時有三個亂數，接著就用雙方協商的加密演算法，各自生成本次通信的「會話秘鑰」，

• 4、服務器的最后回應
  ?服務器收到客戶端的第三個亂數（ pre-master key ）之后，通過協商的加密演算法，計算出本次通信的「會話秘鑰」，然后，向客戶端發生最后的資訊：

（1）加密通信演算法改變通知，表示隨后的資訊都將用「會話秘鑰」加密通信，
（2）服務器握手結束通知，表示服務器的握手階段已經結束，這一項同時把之前所有內容的發生的資料做個摘要，用來供客戶端校驗，

?至此，整個 SSL/TLS 的握手階段全部結束，接下來，客戶端與服務器進入加密通信，就完全是使用普通的 HTTP 協議，只不過用「會話秘鑰」加密內容，

1.5 HTTP/1.1、HTTP/2、HTTP/3

1.5.1 HTTP/1.1

??HTTP/1.1 相比 HTTP/1.0 性能上的改進：

1、使用 TCP 長連接的方式改善了 HTTP/1.0 短連接造成的性能開銷，
2、支持管道（pipeline）網路傳輸，只要第一個請求發出去了，不必等其回來，就可以發第二個請求出去，可以減少整體的回應時間，

??HTTP/1.1 還是有性能瓶頸：

1、請求 / 回應頭部（Header）未經壓縮就發送，首部資訊越多延遲越大，只能壓縮 Body 的部分；
2、發送冗長的首部，每次互相發送相同的首部造成的浪費較多；
3、服務器是按請求的順序回應的，如果服務器回應慢，會招致客戶端一直請求不到資料，也就是隊頭阻塞；
4、沒有請求優先級控制；
5、請求只能從客戶端開始，服務器只能被動回應，

1.5.2 HTTP/2

??HTTP/2 協議是基于 HTTPS 的，HTTP/2 相比 HTTP/1.1 性能上的改進：

• 1、頭部壓縮
  ?HTTP/2 會壓縮頭（Header）如果你同時發出多個請求，他們的頭是一樣的或是相似的，那么，協議會幫你消除重復的部分，這就是所謂的 HPACK 演算法：在客戶端和服務器同時維護一張頭資訊表，所有欄位都會存入這個表，生成一個索引號，以后就不發送同樣欄位了，只發送索引號，這樣就提高速度了，
• 2、二進制格式
  ?HTTP/2 不再像 HTTP/1.1 里的純文本形式的報文，而是全面采用了二進制格式，頭資訊和資料體都是二進制，并且統稱為幀（frame）：頭資訊幀和資料幀，
  
  ?這樣雖然對人不友好，但是對計算機非常友好，因為計算機只懂二進制，那么收到報文后，無需再將明文的報文轉成二進制，而是直接決議二進制報文，這增加了資料傳輸的效率，
• 3、資料流
  ?HTTP/2 的資料包不是按順序發送的，同一個連接里面連續的資料包，可能屬于不同的回應，因此，必須要對資料包做標記，指出它屬于哪個回應，每個請求或回應的所有資料包，稱為一個資料流（ Stream ），每個資料流都標記著一個獨一無二的編號，其中規定客戶端發出的資料流編號為奇數， 服務器發出的資料流編號為偶數，
  ?客戶端還可以指定資料流的優先級，優先級高的請求，服務器就先回應該請求，
  
• 4、多路復用
  ?HTTP/2 是可以在一個連接中并發多個請求或回應，而不用按照順序一一對應，移除了 HTTP/1.1 中的串行請求，不需要排隊等待，也就不會再出現「隊頭阻塞」問題，降低了延遲，大幅度提高了連接的利用率，
  ?舉例來說，在一個 TCP 連接里，服務器收到了客戶端 A 和 B 的兩個請求，如果發現 A 處理程序非常耗時，于是就回應 A 請求已經處理好的部分，接著回應 B 請求，完成后，再回應 A 請求剩下的部分，
  
• 5、 服務器推送
  ?HTTP/2 還在一定程度上改善了傳統的「請求 - 應答」作業模式，服務不再是被動地回應，也可以主動向客戶端發送訊息，
  ?舉例來說，在瀏覽器剛請求 HTML 的時候，就提前把可能會用到的 JS、CSS 檔案等靜態資源主動發給客戶端，減少延時的等待，也就是服務器推送（Server Push，也叫 Cache Push），

1.5.3 HTTP/3

??HTTP/2 主要的問題在于，多個 HTTP 請求在復用一個 TCP 連接，下層的 TCP 協議是不知道有多少個HTTP 請求的，所以一旦發生了丟包現象，就會觸發 TCP 的重傳機制，這樣在一個 TCP 連接中的所有的 HTTP 請求都必須等待這個丟了的包被重傳回來，

1、HTTP/1.1 中的管道（ pipeline）傳輸中如果有一個請求阻塞了，那么佇列后請求也統統被阻塞住了，
2、HTTP/2 多個請求復用一個TCP連接，一旦發生丟包，就會阻塞住所有的 HTTP 請求，

??這都是基于 TCP 傳輸層的問題，所以 HTTP/3 把 HTTP 下層的 TCP 協議改成了 UDP，

??UDP 發生是不管順序，也不管丟包的，所以不會出現 HTTP/1.1 的隊頭阻塞 和 HTTP/2 的一個丟包全部重傳問題，
??大家都知道 UDP 是不可靠傳輸的，但基于 UDP 的 QUIC 協議 可以實作類似 TCP 的可靠性傳輸，

1、QUIC 有自己的一套機制可以保證傳輸的可靠性的，當某個流發生丟包時，只會阻塞這個流，其他流不會受到影響，
2、TLS3 升級成了最新的 1.3 版本，頭部壓縮演算法也升級成了 QPack ，
3、HTTPS 要建立一個連接，要花費 6 次互動，先是建立三次握手，然后是 TLS/1.3 的三次握手，QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次互動合并成了 3 次，減少了互動次數，

??QUIC 是一個在 UDP 之上的偽 TCP + TLS + HTTP/2 的多路復用的協議，
??QUIC 是新協議，對于很多網路設備，根本不知道什么是 QUIC，只會當做 UDP，這樣會出現新的問題，所以 HTTP/3 現在普及的進度非常的緩慢，

二、IP

2.1 IP初識

??IP 在 TCP/IP 參考模型中處于第三層，也就是網路層，網路層的主要作用是：實作主機與主機之間的通信，也叫點對點（end to end）通信，

??IP 的作用是主機之間通信用的，而 MAC 的作用則是實作「直連」
的兩個設備之間通信，而 IP 則負責在「沒有直連」的兩個網路之間進行通信傳輸，

2.2 IP基礎

??在 TCP/IP 網路通信時，為了保證能正常通信，每個設備都需要配置正確的 IP 地址，否則無法實作正常的通信，
??IP 地址（IPv4 地址）由 32 位正整數來表示，IP 地址在計算機是以二進制的方式處理的，
??為了方便記憶采用了點分十進制的標記方式，也就是將 32 位 IP 地址以每 8 位為組，共分為 4組，每組以" . "隔開，再將每組轉換成十進制，

??IP 地址最大值也就是2³²，也就說，最大允許 43 億左右臺計算機連接到網路，
??實際上，IP 地址并不是根據主機臺數來配置的，而是以網卡，像服務器、路由器等設備都是有 2 個以上的網卡，也就是它們會有 2 個以上的 IP 地址，

??因此，讓 43 億臺計算機全部連網其實是不可能的，更何況 IP 地址是由「網路標識」和「主機標識」這兩個部分組成的，所以實際能夠連接到網路的計算機個數更是少了很多，
??目前的手機、IPad 等電子設備之和肯定超過了43億，是怎么能夠支持這么多 IP 的呢？答案是根據一種可以更換 IP 地址的技術 NAT ，使得可連接計算機數超過 43 億臺，

2.2.1 IP 地址的分類

??IP 地址分類成了 5 種型別，分別是 A 類、B 類、C 類、D 類、E 類，

??上圖中黃色部分為分類號，用以區分 IP 地址類別，
??對于 A、B、C 類主要分為兩個部分，分別是網路號和主機號，這很好理解，好比我是 A 小區 1棟 101 號，你是 B 小區 1 棟 101 號，
??A、B、C 分類對應的地址范圍、最大主機個數：

• 1、A、B、C 分類地址最大主機個數是如何計算的呢？
  ??最大主機個數，就是要看主機號的位數，如 C 類地址的主機號占 8 位，那么 C 類地址的最大主機個數：2⁸-2=254，
  ??為什么要減 2 呢？因為在 IP 地址中，有兩個 IP 是特殊的，分別是主機號全為 1 和 全為 0 地址，
  

主機號全為 1 指定某個網路下的所有主機，用于廣播，
主機號全為 0 指定某個網路，

??因此，在分配程序中，應該去掉這兩種情況，

• 2、廣播地址用于什么？
  ??廣播地址用于在同一個鏈路中相互連接的主機之間發送資料包，
  ??在準備上課的時候，通常班長會喊：“上課， 全體起立！”，班里的同學聽到這句話全部都站起來，這個句話就有廣播的含義，
  ??當主機號全為 1 時，就表示該網路的廣播地址，例如把 172.20.0.0/16 用二進制表示如下：

10101100.00010100.00000000.00000000

??將這個地址的主機部分全部改為 1，則形成廣播地址：

10101100.00010100. 11111111.11111111

??再將這個地址用十進制表示，則為 172.20.255.255 ，
??廣播地址可以分為本地廣播和直接廣播兩種：

1. 在本網路內廣播的叫做本地廣播，例如網路地址為 192.168.0.0/24 的情況下，廣播地址是192.168.0.255 ，因為這個廣播地址的 IP 包會被路由器屏蔽，所以不會到達 192.168.0.0/24 以外的其他鏈路上，
2. 在不同網路之間的廣播叫做直接廣播，例如網路地址為 192.168.0.0/24 的主機向192.168.1.255/24 的目標地址發送 IP 包，收到這個包的路由器，將資料轉發給 192.168.1.0/24，從而使得所有 192.168.1.1~192.168.1.254 的主機都能收到這個包（由于直接廣播有一定的安全問題，多數情況下會在路由器上設定為不轉發，） ，

• 3、什么是 D、E 類地址？
  ??而 D 類和 E 類地址是沒有主機號的，所以不可用于主機 IP，D 類常被用于多播，E 類是預留的分類，暫時未使用，
  
• 4、多播地址用于什么？
  ??多播用于將包發送給特定組內的所有主機，
  
  ??多播使用的 D 類地址，其前四位是 1110 就表示是多播地址，而剩下的 28 位是多播的組編號，從 224.0.0.0 ~ 239.255.255.255 都是多播的可用范圍，其劃分為以下三類：

1、224.0.0.0 ~ 224.0.0.255 為預留的組播地址，只能在局域網中，路由器是不會進行轉發的，
2、224.0.1.0 ~ 238.255.255.255 為用戶可用的組播地址，可以用于 Internet 上，
3、239.0.0.0 ~ 239.255.255.255 為本地管理組播地址，可供內部網在內部使用，僅在特定的本地范圍內有效，

• 5、IP 分類的優點
  ??不管是路由器還是主機決議到一個 IP 地址時候，我們判斷其 IP 地址的首位是否為 0，為 0 則為 A 類地址，那么就能很快的找出網路地址和主機地址，

第一位是0則為A類地址，否則繼續判斷；
第二位是0則為B類地址，否則繼續判斷；
第三位是0則為C類地址，否則繼續判斷；
第四位是0則為D類地址，否則為E類地址，

??所以，這種分類地址的優點就是簡單明了、選路（基于網路地址）簡單，

• 6、IP 分類的缺點
  ??缺點一：同一網路下沒有地址層次，比如一個公司里用了 B 類地址，但是可能需要根據生產環境、測驗環境、開發環境來劃分地址層次，而這種 IP 分類是沒有地址層次劃分的功能，所以這就缺少地址的靈活性，
  ??缺點二：A、B、C類有個尷尬處境，就是不能很好的與現實網路匹配，

1)C 類地址能包含的最大主機數量實在太少了，只有 254 個，估計一個網吧都不夠用，
2)而 B 類地址能包含的最大主機數量又太多了，6 萬多臺機器放在一個網路下面，一般的企業基本達不到這個規模，閑著的地址就是浪費，

??這兩個缺點，都可以在 CIDR 無分類地址解決，

2.2.2 無分類地址 CIDR

??無分類地址的方案，即 CIDR，這種方式不再有分類地址的概念，32 位元的 IP 地址被劃分為兩部分，前面是網路號，后面是主機號，

• 1、怎么劃分網路號和主機號的呢？
  ?形式 a.b.c.d/x ，其中 /x 表示前 x 位屬于網路號， x 的范圍是 0 ~ 32 ，這就使得 IP 地址更加具有靈活性，
  ?比如 10.100.122.2/24，這種地址表示形式就是 CIDR，/24 表示前 24 位是網路號，剩余的 8 位是主機號，
  
  ?還有另一種劃分網路號與主機號形式，那就是子網掩碼，掩碼的意思就是掩蓋掉主機號，剩余的就是網路號，
  ?將子網掩碼和 IP 地址按位計算 AND，就可得到網路號，
  
• 2、為什么要分離網路號和主機號？
  ?因為兩臺計算機要通訊，首先要判斷是否處于同一個廣播域內，即網路地址是否相同，如果網路地址相同，表明接受方在本網路上，那么可以把資料包直接發送到目標主機，
  ?路由器尋址作業中，也就是通過這樣的方式來找到對應的網路號的，進而把資料包轉發給對應的網路內，
  
• 3、怎么進行子網劃分？
  ?我們知道可以通過子網掩碼劃分出網路號和主機號，那實際上子網掩碼還有一個作用，那就是劃分子網，
  ?子網劃分實際上是將主機地址分為兩個部分：子網網路地址和子網主機地址，形式如下：
  

未做子網劃分的 ip 地址：網路地址＋主機地址，
做子網劃分后的 ip 地址：網路地址＋（子網網路地址＋子網主機地址），

?假設對 C 類地址進行子網劃分，網路地址 192.168.1.0，使用子網掩碼 255.255.255.192 對其進行子網劃分，C 類地址中前 24 位是網路號，最后 8 位是主機號，根據子網掩碼可知從 8 位主機號中借用 2 位作為子網號，

?由于子網網路地址被劃分成 2 位，那么子網地址就有 4 個，分別是 00、01、10、11，具體劃分如下：

?劃分后的 4 個子網如下表格：

2.2.3 公有 IP 地址與私有 IP 地址

??在 A、B、C 分類地址，實際上有分公有 IP 地址和私有 IP 地址，

??平時我們辦公室、家里、學校用的 IP 地址，一般都是私有 IP 地址，因為這些地址允許組織內部的 IT人員自己管理、自己分配，而且可以重復，因此，你學校的某個私有 IP 地址和我學校的可以是一樣的，
??公有 IP 地址是有個組織統一分配的，假設你要開一個博客網站，那么你就需要去申請購買一個公有 IP，這樣全世界的人才能訪問，并且公有 IP 地址基本上要在整個互聯網范圍內保持唯一，

• 1、公有 IP 地址由誰管理呢
  ?私有 IP 地址通常是內部的 IT 人員管理，公有 IP 地址是由 ICANN 組織管理，中文叫「互聯網名稱與數字地址分配機構」，
  ?IANA 是 ICANN 的其中一個機構，它負責分配互聯網 IP 地址，是按洲的方式層層分配，
  

ARIN 北美地區
LACNIC 拉丁美洲和一些加勒比群島
RIPE NCC 歐洲、中東和中亞
AfriNIC 非洲地區
APNIC 亞太地區

?在中國是由 CNNIC 的機構進行管理，它是中國國內唯一指定的全域 IP 地址管理的組織，

2.2.4 IP 地址與路由控制

??IP地址的網路地址這一部分是用于進行路由控制，路由控制表中記錄著網路地址與下一步應該發送至路由器的地址，在主機和路由器上都會有各自的路由器控制表，
??在發送 IP 包時，首先要確定 IP 包首部中的目標地址，再從路由控制表中找到與該地址具有相同網路地址的記錄，根據該記錄將 IP 包轉發給相應的下一個路由器，如果路由控制表中存在多條相同網路地址的記錄，就選擇相同位數最多的網路地址，也就是最長匹配，
??例子：

1. 主機 A 要發送一個 IP 包，其源地址是 10.1.1.30 和目標地址是 10.1.2.10 ，由于沒有在主機 A的路由表找到與目標地址 10.1.2.10 的網路地址，于是包被轉發到默認路由（路由器 1 ）；
2. 路由器 1 收到 IP 包后，也在路由器 1 的路由表匹配與目標地址相同的網路地址記錄，發現匹配到了，于是就把 IP 資料包轉發到了 10.1.0.2 這臺路由器 2；
3. 路由器 2 收到后，同樣對比自身的路由表，發現匹配到了，于是把 IP 包從路由器 2 的10.1.2.1 這個介面出去，最終經過交換機把 IP 資料包轉發到了目標主機，

??環回地址是在同一臺計算機上的程式之間進行網路通信時所使用的一個默認地址，計算機使用一個特殊的 IP 地址 127.0.0.1 作為環回地址，與該地址具有相同意義的是一個叫做localhost 的主機名，使用這個 IP 或主機名時，資料包不會流向網路，

2.2.5 IP 分片與重組

??每種資料鏈路的最大傳輸單元 MTU 都是不相同的，如 FDDI 資料鏈路 MTU 4352、以太網的 MTU 是1500 位元組等，每種資料鏈路的 MTU 之所以不同，是因為每個不同型別的資料鏈路的使用目的不同，使用目的不同，可承載的 MTU 也就不同，
??們最常見資料鏈路是以太網，它的 MTU 是 1500 位元組，那么當 IP 資料包大小大于 MTU 時， IP 資料包就會被分片，經過分片之后的 IP 資料報在被重組的時候，只能由目標主機進行，路由器是不會進行重組的，假設發送方發送一個 4000 位元組的大資料報，若要傳輸在以太網鏈路，則需要把資料報分片成 3 個小資料報進行傳輸，再交由接收方重組成大資料報，

??在分片傳輸中，一旦某個分片丟失，則會造成整個 IP 資料報作廢，所以 TCP 引入了 MSS 也就是在TCP 層進行分片不由 IP 層分片，那么對于 UDP 我們盡量不要發送一個大于 MTU 的資料報文，

2.2.6 IPv6 基本認識

??IPv4 的地址是 32 位的，大約可以提供 42 億個地址， IPv6 的地址是 128 位的， IPv6 除了有更多的地址之外，還有更好的安全性和擴展性，說簡單點就是 IPv6 相比于 IPv4 能帶來更好的網路體驗，

• 1、IPv6 的亮點
  ?IPv6 可自動配置，即使沒有 DHCP 服務器也可以實作自動分配IP地址，
  ?IPv6 包頭包首部長度采用固定的值 40 位元組，去掉了包頭校驗和，簡化了首部結構，減輕了路由器負荷，大大提高了傳輸的性能，
  ?IPv6 有應對偽造 IP 地址的網路安全功能以及防止線路竊聽的功能，大大提升了安全性，
• 2、IPv6 地址的標識方法
  ?IPv4 地址長度共 32 位，是以每 8 位作為一組，并用點分十進制的表示方式，
  ?IPv6 地址長度是 128 位，是以每 16 位作為一組，每組用冒號 「:」 隔開，
  
  ?如果出現連續的 0 時還可以將這些 0 省略，并用兩個冒號 「::」隔開，但是，一個 IP 地址中只允許出現一次兩個連續的冒號，示例：
  
• 3、IPv6 地址的結構
  ?IPv6 的地址主要有以下型別地址：

單播地址，用于一對一的通信
組播地址，用于一對多的通信
任播地址，用于通信最近的節點，最近的節點是由路由協議決定
沒有廣播地址

• 4、IPv6 單播地址型別
  ?對于一對一通信的 IPv6 地址，主要劃分了三類單播地址，每類地址的有效范圍都不同：

在同一鏈路單播通信，不經過路由器，可以使用鏈路本地單播地址，IPv4 沒有此型別；
在內網里單播通信，可以使用唯一本地地址，相當于 IPv4 的私有 IP；
在互聯網通信，可以使用全域單播地址，相當于 IPv4 的公有 IP，

2.2.7 IPv4 首部與 IPv6 首部

??IPv4 首部與 IPv6 首部的差異：

??IPv6 相比 IPv4 的首部改進：

1. 取消了首部校驗和欄位， 因為在資料鏈路層和傳輸層都會校驗，因此 IPv6 直接取消了 IP 的校驗，
2. 取消了分片/重新組裝相關欄位， 分片與重組是耗時的程序，IPv6 不允許在中間路由器進行分片與重組，這種操作只能在源與目標主機，這將大大提高了路由器轉發的速度，
3. 取消選項欄位， 選項欄位不再是標準 IP 首部的一部分了，但它并沒有消失，而是可能出現在IPv6 首部中的「下一個首部」指出的位置上，洗掉該選項欄位使的 IPv6 的首部成為固定長度的40 位元組，

2.3 IP 協議

??與 IP 協議相關的重要且常見的技術：

DNS 域名決議
ARP 與 RARP 協議
DHCP 動態獲取 IP 地址
NAT 網路地址轉換
ICMP 互聯網控制報文協議
IGMP 因特網組管理協

2.3.1 DNS

??DNS 可以將域名網址自動轉換為具體的 IP 地址，
??DNS 中的域名都是用句點來分隔的，比如 www.server.com ，這里的句點代表了不同層次之間的界限，在域名中，越靠右的位置表示其層級越高，
??根域是在最頂層，它的下一層就是 com 頂級域，再下面是 server.com，因此，域名的層級關系類似一個樹狀結構：

根 DNS 服務器
頂級域 DNS 服務器（com）
權威 DNS 服務器（server.com）

??根域的 DNS 服務器資訊保存在互聯網中所有的 DNS 服務器中，這樣一來，任何 DNS 服務器就都可以找到并訪問根域 DNS 服務器了，因此，客戶端只要能夠找到任意一臺 DNS 服務器，就可以通過它找到根域 DNS 服務器，然后再一路順藤摸瓜找到位于下層的某臺目標 DNS 服務器，

• 域名決議的作業流程
  ?瀏覽器首先看一下自己的快取里有沒有，如果沒有就向作業系統的快取要，還沒有就檢查本機域名決議檔案 hosts ，如果還是沒有，就會 DNS 服務器進行查詢，查詢的程序如下：

1. 客戶端首先會發出一個 DNS 請求，問 www.server.com 的 IP 是啥，并發給本地 DNS 服務器（也就是客戶端的 TCP/IP 設定中填寫的 DNS 服務器地址），
2. 本地域名服務器收到客戶端的請求后，如果快取里的表格能找到 www.server.com，則它直接回傳IP 地址，如果沒有，本地 DNS 會去問它的根域名服務器：“老大， 能告訴我 www.server.com 的IP 地址嗎？” 根域名服務器是最高層次的，它不直接用于域名決議，但能指明一條道路，
3. 根 DNS 收到來自本地 DNS 的請求后，發現后置是 .com，說“www.server.com 這個域名歸.com 區域管理”，我給你 .com 頂級域名服務器地址給你，你去問問它吧，”
4. 本地 DNS 收到頂級域名服務器的地址后，發起請求問“老二， 你能告訴我 www.server.com 的 IP地址嗎？”
5. 頂級域名服務器說：“我給你負責 www.server.com 區域的權威 DNS 服務器的地址，你去問它應該能問到”，
6. 本地 DNS 于是轉向問權威 DNS 服務器：“老三，www.server.com對應的IP是啥呀？” server.com的權威 DNS 服務器，它是域名決議結果的原出處，為啥叫權威呢？就是我的域名我做主，
7. 權威 DNS 服務器查詢后將對應的 IP 地址 X.X.X.X 告訴本地 DNS，
8. 本地 DNS 再將 IP 地址回傳客戶端，客戶端和目標建立連接，

2.3.2 ARP

??在傳輸一個 IP 資料報的時候，確定了源 IP 地址和目標 IP 地址后，就會通過主機「路由表」確定 IP 資料包下一跳，然而，網路層的下一層是資料鏈路層，所以我們還要知道「下一跳」的 MAC 地址，
??由于主機的路由表中可以找到下一跳的 IP 地址，所以可以通過ARP 協議，求得下一跳的 MAC 地址，
??簡單地說，ARP 是借助 ARP 請求與 ARP 回應兩種型別的包確定 MAC 地址的，

1、主機會通過廣播發送 ARP 請求，這個包中包含了想要知道的 MAC 地址的主機 IP 地址，
2、當同個鏈路中的所有設備收到 ARP 請求時，會去拆開 ARP 請求包里的內容，如果 ARP 請求包中的目標 IP 地址與自己的 IP 地址一致，那么這個設備就將自己的 MAC 地址塞入 ARP 回應包回傳給主機，

??作業系統通常會把第一次通過 ARP 獲取的 MAC 地址快取起來，以便下次直接從快取中找到對應 IP 地址的 MAC 地址，不過，MAC 地址的快取是有一定期限的，超過這個期限，快取的內容將被清除，

• RARP 協議
  ??ARP 協議是已知 IP 地址求 MAC 地址，那 RARP 協議正好相反，它是已知 MAC 地址求 IP 地址，例如將列印機服務器等小型嵌入式設備接入到網路時就經常會用得到，
  ??通常需要架設一臺 RARP 服務器，在這個服務器上注冊設備的 MAC 地址及其 IP 地址，然后再將這個設備接入到網路，接著發生的：

1、該設備會發送一條「我的 MAC 地址是XXXX，請告訴我，我的IP地址應該是什么」的請求資訊，
2、RARP 服務器接到這個訊息后回傳「MAC地址為 XXXX 的設備，IP地址為 XXXX」的資訊給這個設備，

??設備就根據從 RARP 服務器所收到的應答資訊設定自己的 IP 地址，

2.3.3 DHCP

??我們的電腦通常都是通過 DHCP 動態獲取 IP 地址，這是DHCP常規的應用，其4個步驟：

說明一點，DHCP 客戶端行程監聽的是 68 埠號，DHCP 服務端行程監聽的是 67 埠號，

?? 4 個步驟的詳細描述：

1. 客戶端首先發起 DHCP 發現報文（DHCP DISCOVER） 的 IP 資料報，由于客戶端沒有 IP 地址，也不知道 DHCP 服務器的地址，所以使用的是 UDP 廣播通信，其使用的廣播目的地址是255.255.255.255（埠 67） 并且使用 0.0.0.0（埠 68） 作為源 IP 地址，DHCP 客戶端將該IP 資料報傳遞給鏈路層，鏈路層然后將幀廣播到所有的網路中設備，
2. DHCP 服務器收到 DHCP 發現報文時，用 DHCP 提供報文（DHCP OFFER） 向客戶端做出回應，該報文仍然使用 IP 廣播地址 255.255.255.255，該報文資訊攜帶服務器提供可租約的 IP 地址、子網掩碼、默認網關、DNS 服務器以及 IP 地址租用期，
3. 客戶端收到一個或多個服務器的 DHCP 提供報文后，從中選擇一個服務器，并向選中的服務器發送 DHCP 請求報文（DHCP REQUEST進行回應，回顯配置的引數，
4. 最后，服務端用 DHCP ACK 報文對 DHCP 請求報文進行回應，應答所要求的引數，

??一旦客戶端收到 DHCP ACK 后，互動便完成了，并且客戶端能夠在租用期內使用 DHCP 服務器分配的IP 地址，
??如果租約的 DHCP IP 地址快期后，客戶端會向服務器發送 DHCP 請求報文：

1）服務器如果同意繼續租用，則用 DHCP ACK 報文進行應答，客戶端就會延長租期，
2）服務器如果不同意繼續租用，則用 DHCP NACK 報文，客戶端就要停止使用租約的 IP 地址，

??DHCP 互動中，全程都是使用 UDP 廣播通信，

• 如果 DHCP 服務器和客戶端不是在同一個局域網內，路由器又不會轉發廣播包，那不是每個網路都要配一個 DHCP 服務器？
  ?為了解決這一問題，就出現了 DHCP 中繼代理，有了 DHCP 中繼代理以后，對不同網段的 IP 地址分配也可以由一個 DHCP 服務器統一進行管理，
  

1、DHCP 客戶端會向 DHCP 中繼代理發送 DHCP 請求包，而 DHCP 中繼代理在收到這個廣播包以后，再以單播的形式發給 DHCP 服務器，
2、服務器端收到該包以后再向 DHCP 中繼代理回傳應答，并由 DHCP 中繼代理將此包廣播給DHCP 客戶端 ，

?因此，DHCP 服務器即使不在同一個鏈路上也可以實作統一分配和管理IP地址，

2.3.4 NAT

??網路地址轉換 NAT 的方法，可以緩解了 IPv4 地址耗盡的問題，簡單的來說 NAT 就是同個公司、家庭、教室內的主機對外部通信時，把私有 IP 地址轉換成公有 IP 地址，

??在進行轉換的時候，可以把 IP 地址 + 埠號一起進行轉換，這種轉換技術就叫網路地址與埠轉換 NAPT，示例：

??圖中有兩個客戶端 192.168.1.10 和 192.168.1.11 同時與服務器 183.232.231.172 進行通信，并且這兩個客戶端的本地埠都是 1025，此時，兩個私有 IP 地址都轉換 IP 地址為公有地址 120.229.175.121，但是以不同的埠號作為區分，
??于是，生成一個 NAPT 路由器的轉換表，就可以正確地轉換地址跟埠的組合，令客戶端 A、B 能同時與服務器之間進行通信，

• 1、NAT的缺點

1、外部無法主動與 NAT 內部服務器建立連接，因為 NAPT 轉換表沒有轉換記錄，
2、轉換表的生成與轉換操作都會產生性能開銷，
3、通信程序中，如果 NAT 路由器重啟了，所有的 TCP 連接都將被重置，

• 2、如何解決 NAT 潛在的問題呢
  ?第一種就是改用 IPv6，IPv6 可用范圍非常大，以至于每臺設備都可以配置一個公有 IP 地址，
  ?第二種 NAT 穿透技術，NAT 穿越技術擁有這樣的功能，它能夠讓網路應用程式主動發現自己位于 NAT 設備之后，并且會主動獲得 NAT 設備的公有 IP，并為自己建立埠映射條目，注意這些都是 NAT設備后的應用程式自動完成的，
  ?也就是說，在 NAT 穿透技術中，NAT設備后的應用程式處于主動地位，它已經明確地知道 NAT 設備要修改它外發的資料包，于是它主動配合 NAT 設備的操作，主動地建立好映射，這樣就不像以前由 NAT設備來建立映射了，
  ?簡單點說，就是客戶端主動從 NAT 設備獲取公有 IP 地址，然后自己建立埠映射條目，然后用這個條目對外通信，就不需要 NAT 設備來進行轉換了，

2.3.5 ICMP

??ICMP 全稱是 Internet Control Message Protocol，也就是互聯網控制報文協議，
??ICMP 主要的功能包括：確認 IP 包是否成功送達目標地址、報告發送程序中 IP 包被廢棄的原因和改善網路設定等，
??在 IP 通信中如果某個 IP 包因為某種原因未能達到目標地址，那么這個具體的原因將由 ICMP 負責通知，

??上圖例子，主機 A 向主機 B 發送了資料包，由于某種原因，途中的路由器 2 未能發現主機B 的存在，這時，路由器 2 就會向主機 A 發送一個 ICMP 目標不可達資料包，說明發往主機B 的包未能成功，
??ICMP 的這種通知訊息會使用 IP 進行發送 ，
??因此，從路由器 2 回傳的 ICMP 包會按照往常的路由控制先經過路由器 1 再轉發給主機 A ，收到該 ICMP 包的主機 A 則分解 ICMP 的首部和資料域以后得知具體發生問題的原因，
??ICMP 大致可以分為兩大類：

一類是用于診斷的查詢訊息，也就是「查詢報文型別」；
另一類是通知出錯原因的錯誤訊息，也就是「差錯報文型別」，

??分的具體些：

2.3.6 IGMP

??IGMP 是因特網組管理協議，作業在主機（組播成員）和最后一跳路由之間，如圖中的藍色部分，

??IGMP 報文向路由器申請加入和退出組播組，默認情況下路由器是不會轉發組播包到連接中的主機，除非主機通過 IGMP 加入到組播組，主機申請加入到組播組時，路由器就會記錄 IGMP 路由器表，路由器后續就會轉發組播包到對應的主機了，
??IGMP 報文采用 IP 封裝，IP 頭部的協議號為 2，而且 TTL 欄位值通常為 1，因為 IGMP 是作業在主機與連接的路由器之間，
??IGMP 分為了三個版本分別是，IGMPv1、IGMPv2、IGMPv3，
??以 IGMPv2 作為例子，說說常規查詢與回應和離開組播組這兩個作業機制，

• 1、常規查詢與回應作業機制
  

1. 路由器會周期性發送目的地址為 224.0.0.1 （表示同一網段內所有主機和路由器） IGMP 常規查詢報文，
2. 主機1 和 主機 3 收到這個查詢，隨后會啟動「報告延遲計時器」，計時器的時間是隨機的，通常是 0~10 秒，計時器超時后主機就會發送 IGMP 成員關系報告報文（源 IP 地址為自己主機的 IP地址，目的 IP 地址為組播地址），如果在定時器超時之前，收到同一個組內的其他主機發送的成員關系報告報文，則自己不再發送，這樣可以減少網路中多余的 IGMP 報文數量，
3. 路由器收到主機的成員關系報文后，就會在 IGMP 路由表中加入該組播組，后續網路中一旦該組播地址的資料到達路由器，它會把資料包轉發出去，

• 2、離開組播組作業機制
  ?離開組播組的情況一，網段中仍有該組播組：
  

1. 主機 1 要離開組 224.1.1.1，發送 IGMPv2 離組報文，報文的目的地址是 224.0.0.2（表示發向網段內的所有路由器）
2. 路由器 收到該報文后，以 1 秒為間隔連續發送 IGMP 特定組查詢報文（共計發送 2 個），以便確認該網路是否還有 224.1.1.1 組的其他成員，
3. 主機 3 仍然是組 224.1.1.1 的成員，因此它立即回應這個特定組查詢，路由器知道該網路中仍然存在該組播組的成員，于是繼續向該網路轉發 224.1.1.1 的組播資料包，

?離開組播組的情況二，網段中沒有該組播組：

1. 主機 1 要離開組播組 224.1.1.1，發送 IGMP 離組報文，
2. 路由器收到該報文后，以 1 秒為間隔連續發送 IGMP 特定組查詢報文（共計發送 2 個），此時在該網段內，組 224.1.1.1 已經沒有其他成員了，因此沒有主機回應這個查詢，
3. 一定時間后，路由器認為該網段中已經沒有 224.1.1.1 組播組成員了，將不會再向這個網段轉發該組播地址的資料包，

問：假設一臺機器加入組播地址，需要把IP改成組播地址嗎？如果離開某個組播地址，需要 dhcp 重新請求個IP嗎？
答：組播地址不是用于機器 ip 地址的，因為組播地址沒有網路號和主機號，所以跟 dhcp 沒關系，組播地址一般是用于 udp 協議，機器發送 UDP 組播資料時，目標地址填的是組播地址，那么在組播組內的機器都能收到資料包，
是否加入組播組和離開組播組，是由 socket 一個介面實作的，主機 ip 是不用改變的，

三、Ping

??在判斷與對方網路是否暢通，使用的最多的莫過于 ping 命令，

3.1 IP協議的助手 —— ICMP 協議

??ping 是基于 ICMP 協議作業的，ICMP 全稱是 Internet Control Message Protocol，也就是互聯網控制報文協議，
??ICMP 主要的功能包括：確認 IP 包是否成功送達目標地址、報告發送程序中 IP 包被廢棄的原因和改善網路設定等，
??在 IP 通信中如果某個 IP 包因為某種原因未能達到目標地址，那么這個具體的原因將由 ICMP 負責通知，

??如上圖例子，主機 A 向主機 B 發送了資料包，由于某種原因，途中的路由器 2 未能發現主機B 的存在，這時，路由器 2 就會向主機 A 發送一個 ICMP 目標不可達資料包，說明發往主機B 的包未能成功，
??ICMP 的這種通知訊息會使用 IP 進行發送 ，
??因此，從路由器 2 回傳的 ICMP 包會按照往常的路由控制先經過路由器 1 再轉發給主機 A ，收到該 ICMP 包的主機 A 則分解 ICMP 的首部和資料域以后得知具體發生問題的原因，
??ICMP 報文是封裝在 IP 包里面，它作業在網路層，是 IP 協議的助手，

3.2 查詢報文型別

??回送訊息用于進行通信的主機或路由器之間，判斷所發送的資料包是否已經成功到達對端的一種訊息， ping 命令就是利用這個訊息實作的，

??可以向對端主機發送回送請求的訊息（ ICMP Echo Request Message ，型別 8 ），也可以接收對端主機發回來的回送應答訊息（ ICMP Echo Reply Message ，型別 0 ），

??相比原生的 ICMP，這里多了兩個欄位：

識別符號：用以區分是哪個應用程式發 ICMP 包，比如用行程 PID 作為識別符號；
序號：序列號從 0 開始，每發送一次新的回送請求就會加 1 ， 可以用來確認網路包是否有丟失，

??在選項資料中， ping 還會存放發送請求的時間值，來計算往返時間，說明路程的長短，

3.3 查詢報文型別

??幾個常用的 ICMP 差錯報文的例子：

目標不可達訊息 —— 型別 為 3
原點抑制訊息 —— 型別 4
重定向訊息 —— 型別 5
超時訊息 —— 型別 11

??IP 路由器無法將 IP 資料包發送給目標地址時，會給發送端主機回傳一個目標不可達的 ICMP 訊息，并在這個訊息中顯示不可達的具體原因，原因記錄在 ICMP 包頭的代碼欄位，由此，根據 ICMP 不可達的具體訊息，發送端主機也就可以了解此次發送不可達的具體原因，
?? 6 種常見的目標不可達型別的代碼：

??正常情況下，發送端主機發送 IP 資料報時，將 IP 首部的分片禁止標志位設定為 1 ，根據這個標志位，途中的路由器遇到超過 MTU 大小的資料包時，不會進行分片，而是直接拋棄，
??隨后，通過一個 ICMP 的不可達訊息型別，代碼為 4（原點抑制訊息） 的報文，告知發送端主機，
??ICMP 原點抑制訊息的目的就是為了緩和網路擁堵情況，

當路由器向低速線路發送資料時，其發送佇列的快取變為零而無法發送出去時，可以向 IP 包的源地址發送一個 ICMP 原點抑制訊息，收到這個訊息的主機借此了解在整個線路的某一處發生了擁堵的情況，從而增大 IP 包的傳輸間隔，減少網路擁堵的情況，然而，由于這種 ICMP 可能會引起不公平的網路通信，一般不被使用，

• 1、重定向訊息
  ?如果路由器發現發送端主機使用了「不是最優」的路徑發送資料，那么它會回傳一個 ICMP 重定向訊息給這個主機，
  ?在這個訊息中包含了最合適的路由資訊和源資料，這主要發生在路由器持有更好的路由資訊的情況下，路由器會通過這樣的 ICMP 訊息告知發送端，讓它下次發給另外一個路由器，
• 2、超時訊息
  ?IP 包中有一個欄位叫做 TTL （ Time To Live ，生存周期），它的值隨著每經過一次路由器就會減1，直到減到 0 時該 IP 包會被丟棄，此時，路由器將會發送一個 ICMP 超時訊息給發送端主機，并通知該包已被丟棄，
  ?設定 IP 包生存周期的主要目的，是為了在路由控制遇到問題發生回圈狀況時，避免 IP 包無休止地在網路上被轉發，
  

3.4 ping

??重點來看 ping 的發送和接收程序，
??ping 命令執行的時候，源主機首先會構建一個 ICMP 回送請求訊息資料包，
??ICMP 資料包內包含多個欄位，最重要的是兩個：

第一個是型別，對于回送請求訊息而言該欄位為 8 ；
另外一個是序號，主要用于區分連續 ping 的時候發出的多個資料包，

??每發出一個請求資料包，序號會自動加 1 ，為了能夠計算往返時間 RTT ，它會在報文的資料部分插入發送時間，

??然后，由 ICMP 協議將這個資料包連同地址 192.168.1.2 一起交給 IP 層，IP 層將以 192.168.1.2 作為目的地址，本機 IP 地址作為源地址，協議欄位設定為 1 表示是 ICMP 協議，再加上一些其他控制資訊，構建一個 IP 資料包，

??接下來，需要加入 MAC 頭，如果在本地 ARP 映射表中查找出 IP 地址 192.168.1.2 所對應的 MAC地址，則可以直接使用；如果沒有，則需要發送 ARP 協議查詢 MAC 地址，獲得 MAC 地址后，由資料鏈路層構建一個資料幀，目的地址是 IP 層傳過來的 MAC 地址，源地址則是本機的 MAC 地址；還要附加上一些控制資訊，依據以太網的介質訪問規則，將它們傳送出去，

??主機 B 收到這個資料幀后，先檢查它的目的 MAC 地址，并和本機的 MAC 地址對比，如符合，則接收，否則就丟棄，
??接收后檢查該資料幀，將 IP 資料包從幀中提取出來，交給本機的 IP 層，同樣，IP 層檢查后，將有用的資訊提取后交給 ICMP 協議，
??主機 B 會構建一個 ICMP 回送回應訊息資料包，回送回應資料包的型別欄位為 0 ，序號為接收到的請求資料包中的序號，然后再發送出去給主機 A，

??在規定的時候間內，源主機如果沒有接到 ICMP 的應答包，則說明目標主機不可達；如果接收到了ICMP 回送回應訊息，則說明目標主機可達，
??此時，源主機會檢查，用當前時刻減去該資料包最初從源主機上發出的時刻，就是 ICMP 資料包的時間延遲，

??這只是最簡單的，同一個局域網里面的情況，如果跨網段的話，還會涉及網關的轉發、路由器的轉發等等，
??但是對于 ICMP 的頭來講，是沒什么影響的，會影響的是根據目標 IP 地址，選擇路由的下一跳，還有每經過一個路由器到達一個新的局域網，需要換 MAC 頭里面的 MAC 地址，
??說了這么多，可以看出 ping 這個程式是使用了 ICMP 里面的 ECHO REQUEST（型別為 8 ） 和ECHO REPLY （型別為 0），

3.5 traceroute

??有一款充分利用 ICMP 差錯報文型別的應用叫做 traceroute （在UNIX、MacOS中是這個命令，而在Windows中對等的命令叫做 tracert ），

3.5.1 traceroute作用一

??traceroute 的第一個作用就是故意設定特殊的 TTL，來追蹤去往目的地時沿途經過的路由器，
??traceroute 的引數指向某個目的 IP 地址，示例：

traceroute 192.168.1.100

??traceroute的原理就是利用 IP 包的生存期限 從 1 開始按照順序遞增的同時發送 UDP 包，強制接收 ICMP 超時訊息的一種方法，

?比如，將 TTL 設定 為 1 ，則遇到第一個路由器，就犧牲了，接著回傳 ICMP 差錯報文網路包，型別是時間超時，
?接下來將 TTL 設定為 2 ，第一個路由器過了，遇到第二個路由器也犧牲了，也同時回傳了 ICMP 差錯報文資料包，如此往復，直到到達目的主機，
?這樣的程序，traceroute 就可以拿到了所有的路由器 IP，

??當然有的路由器根本就不會回傳這個 ICMP，所以對于有的公網地址，是看不到中間經過的路由的，
??traceroute 在發送 UDP 包時，會填入一個不可能的埠號值作為 UDP 目標埠號（大于 3000），當目的主機，收到 UDP 包后，會回傳 ICMP 差錯報文訊息，但這個差錯報文訊息的型別是「埠不可達」，所以，當差錯報文型別是埠不可達時，說明發送方發出的 UDP 包到達了目的主機，

3.5.2 traceroute作用二

??traceroute 還有一個作用是故意設定不分片，從而確定路徑的 MTU，這樣做的目的是為了路徑MTU發現，
??因為有的時候我們并不知道路由器的 MTU 大小，以太網的資料鏈路上的 MTU 通常是 1500 位元組，但是非以外網的 MTU 值就不一樣了，所以我們要知道 MTU 的大小，從而控制發送的包大小，

??作業原理：首先在發送端主機發送 IP 資料報時，將 IP 包首部的分片禁止標志位設定為 1，根據這個標志位，途中的路由器不會對大資料包進行分片，而是將包丟棄，隨后，通過一個 ICMP 的不可達訊息將資料鏈路上 MTU 的值一起給發送主機，不可達訊息的型別為「需要進行分片但設定了不分片位」，
發送主機端每次收到 ICMP 差錯報文時就減少包的大小，以此來定位一個合適的 MTU 值，以便能到達目標主機，

四、從URL到網頁

??圖較簡單的網路拓撲模型：

4.1 HTTP

??首先瀏覽器做的第一步作業就是要對 URL 進行決議，從而生成發送給 Web 服務器的請求資訊， URL 里的各個元素的代表什么，見下圖：

??URL 實際上是請求服務器里的檔案資源，當沒有路徑名時，就代表訪問根目錄下事先設定的默認檔案，也就是 /index.html 或者 /default.html這些檔案，這樣就不會發生混亂了，
??對 URL 進行決議之后，瀏覽器確定了 Web 服務器和檔案名，接下來就是根據這些資訊來生成 HTTP請求訊息了，

4.2 DNS

??通過瀏覽器決議 URL 并生成 HTTP 訊息后，需要委托作業系統將訊息發送給 Web 服務器，但在發送之前，還有一項作業需要完成，那就是查詢服務器域名對應的 IP 地址，因為委托作業系統發送訊息時，必須提供通信物件的 IP 地址，
??所以，有一種服務器就專門保存了 Web 服務器域名與 IP 的對應關系，它就是 DNS 服務器，
??這些知識點可以參考之前章節，

DNS 中的域名都是用句點來分隔的，比如 www.server.com ，這里的句點代表了不同層次之間的界限，在域名中，越靠右的位置表示其層級越高，

??根域是在最頂層，它的下一層就是 com 頂級域，再下面是 server.com，所以域名的層級關系類似一個樹狀結構：

根 DNS 服務器
頂級域 DNS 服務器（com）
權威 DNS 服務器（server.com）

??根域的 DNS 服務器資訊保存在互聯網中所有的 DNS 服務器中，這樣一來，任何 DNS 服務器就都可以找到并訪問根域 DNS 服務器了，因此，客戶端只要能夠找到任意一臺 DNS 服務器，就可以通過它找到根域 DNS 服務器，然后再一路順藤摸瓜找到位于下層的某臺目標 DNS 服務器，
??DNS 的決議程序：

1. 客戶端首先會發出一個 DNS 請求，問 www.server.com 的 IP 是啥，并發給本地 DNS 服務器（也就是客戶端的 TCP/IP 設定中填寫的 DNS 服務器地址），
2. 本地域名服務器收到客戶端的請求后，如果快取里的表格能找到 www.server.com，則它直接回傳
   IP 地址，如果沒有，本地 DNS 會去問它的根域名服務器：“老大， 能告訴我 www.server.com 的IP 地址嗎？” 根域名服務器是最高層次的，它不直接用于域名決議，但能指明一條道路，
3. 根 DNS 收到來自本地 DNS 的請求后，發現后置是 .com，說：“www.server.com 這個域名歸.com 區域管理”，我給你 .com 頂級域名服務器地址給你，你去問問它吧，”
4. 本地 DNS 收到頂級域名服務器的地址后，發起請求問“老二， 你能告訴我 www.server.com 的 IP地址嗎？”
5. 頂級域名服務器說：“我給你負責 www.server.com 區域的權威 DNS 服務器的地址，你去問它應該能問到”，
6. 本地 DNS 于是轉向問權威 DNS 服務器：“老三，www.server.com對應的IP是啥呀？” server.com的權威 DNS 服務器，它是域名決議結果的原出處，為啥叫權威呢？就是我的域名我做主，
7. 權威 DNS 服務器查詢后將對應的 IP 地址 X.X.X.X 告訴本地 DNS，
8. 本地 DNS 再將 IP 地址回傳客戶端，客戶端和目標建立連接，

??圖示：

4.3 協議堆疊

??通過 DNS 獲取到 IP 后，就可以把 HTTP 的傳輸作業交給作業系統中的協議堆疊，
??協議堆疊的內部分為幾個部分，分別承擔不同的作業，上下關系是有一定的規則的，上面的部分會向下面的部分委托作業，下面的部分收到委托的作業并執行，

??應用程式（瀏覽器）通過呼叫 Socket 庫，來委托協議堆疊作業，協議堆疊的上半部分有兩塊，分別是負責收發資料的 TCP 和 UDP 協議，它們兩會接受應用層的委托執行收發資料的操作，
??協議堆疊的下面一半是用 IP 協議控制網路包收發操作，在互聯網上傳資料時，資料會被切分成一塊塊的網路包，而將網路包發送給對方的操作就是由 IP 負責的，
??此外 IP 中還包括 ICMP 協議和 ARP 協議，

ICMP 用于告知網路包傳送程序中產生的錯誤以及各種控制資訊，
ARP 用于根據 IP 地址查詢相應的以太網 MAC 地址，

??IP 下面的網卡驅動程式負責控制網卡硬體，而最下面的網卡則負責完成實際的收發操作，也就是對網線中的信號執行發送和接收操作，

4.4 TCP

??HTTP 是基于 TCP 協議傳輸的， TCP 報文頭部的格式：

??源埠號和目標埠號是不可少的，如果沒有這兩個埠號，資料就不知道應該發給哪個應用，接下來有包的序號，這個是為了解決包亂序的問題，
??還有應該有的是確認號，目的是確認發出去對方是否有收到，如果沒有收到就應該重新發送，直到送達，這個是為了解決不丟包的問題，
??接下來還有一些狀態位，例如 SYN 是發起一個連接， ACK 是回復， RST 是重新連接， FIN 是結束連接等，TCP 是面向連接的，因而雙方要維護連接的狀態，這些帶狀態位的包的發送，會引起雙方的狀態變更，
??還有一個重要的就是視窗大小，TCP 要做流量控制，通信雙方各宣告一個視窗（快取大小），標識自己當前能夠的處理能力，別發送的太快，撐死我，也別發的太慢，餓死我，
??除了做流量控制以外，TCP還會做擁塞控制，對于真正的通路堵車不堵車，它無能為力，唯一能做的就是控制自己，也即控制發送的速度，

4.4.1 三次握手

??在 HTTP 傳輸資料之前，首先需要 TCP 建立連接，TCP 連接的建立，通常稱為三次握手，

1. 一開始，客戶端和服務端都處于 CLOSED 狀態，先是服務端主動監聽某個埠，處于 LISTEN狀態，
2. 然后客戶端主動發起連接 SYN ，之后處于 SYN-SENT 狀態，
3. 服務端收到發起的連接，回傳 SYN ，并且 ACK 客戶端的 SYN ，之后處于 SYN-RCVD 狀態，
4. 客戶端收到服務端發送的 SYN 和 ACK 之后，發送 ACK 的 ACK ，之后處于
   ESTABLISHED 狀態，因為它一發一收成功了，
5. 服務端收到 ACK 的 ACK 之后，處于 ESTABLISHED 狀態，因為它也一發一收了，

??三次握手目的是保證雙方都有發送和接收的能力，
??TCP 的連接狀態查看，在 Linux 可以通過 netstat -napt 命令查看，

??如果 HTTP 請求訊息比較長，超過了 MSS 的長度，這時 TCP 就需要把 HTTP 的資料拆解成一塊塊的資料發送，而不是一次性發送所有資料，

4.4.2 TCP分割資料

??如果 HTTP 請求訊息比較長，超過了 MSS 的長度，這時 TCP 就需要把 HTTP 的資料拆解成一塊塊的資料發送，而不是一次性發送所有資料，

MTU ：一個網路包的最大長度，以太網中一般為 1500 位元組，
MSS ：除去 IP 和 TCP 頭部之后，一個網路包所能容納的 TCP 資料的最大長度，

??資料會被以 MSS 的長度為單位進行拆分，拆分出來的每一塊資料都會被放進單獨的網路包中，也就是在每個被拆分的資料加上 TCP 頭資訊，然后交給 IP 模塊來發送資料，

4.4.3 TCP 報文生成

??TCP 協議里面會有兩個埠，一個是瀏覽器監聽的埠（通常是隨機生成的），一個是 Web 服務器監聽的埠（HTTP 默認埠號是 80 ， HTTPS 默認埠號是 443 ），
??在雙方建立了連接后，TCP 報文中的資料部分就是存放 HTTP 頭部 + 資料，組裝好 TCP 報文之后，就需交給下面的網路層處理，

4.5 IP

??TCP 模塊在執行連接、收發、斷開等各階段操作時，都需要委托 IP 模塊將資料封裝成網路包發送給通信物件，
?? IP 報文頭部的格式：

??在 IP 協議里面需要有源地址 IP 和 目標地址 IP：

源地址IP，即是客戶端輸出的 IP 地址；
目標地址，即通過 DNS 域名決議得到的 Web 服務器 IP，

??因為 HTTP 是經過 TCP 傳輸的，所以在 IP 包頭的協議號，要填寫為 06 （十六進制），表示協議為TCP，
??假設客戶端有多個網卡，就會有多個 IP 地址，那 IP 頭部的源地址應該選擇哪個 IP 呢？這個時候就需要根據路由表規則，來判斷哪一個網卡作為源地址 IP，
??在 Linux 作業系統，我們可以使用 route -n 命令查看當前系統的路由表，

??舉個例子，根據上面的路由表，我們假設 Web 服務器的目標地址是 192.168.10.200 ，

1. 首先先和第一條目的子網掩碼（ Genmask ）進行 與運算，得到結果為 192.168.10.0 ，但是第一
   個條目的 Destination 是 192.168.3.0 ，兩者不一致所以匹配失敗，
2. 再與第二條目的子網掩碼進行 與運算，得到的結果為 192.168.10.0 ，與第二條目的 Destination
   192.168.10.0 匹配成功，所以將使用 eth1 網卡的 IP 地址作為 IP 包頭的源地址，

??假設 Web 服務器的目標地址是 10.100.20.100 ，那么依然依照上面的路由表規則判斷，判斷后的結果是和第三條目匹配，第三條目比較特殊，它目標地址和子網掩碼都是 0.0.0.0 ，這表示默認網關，如果其他所有條目都無法匹配，就會自動匹配這一行，并且后續就把包發給路由器， Gateway 即是路由器的 IP 地址，
??至此，網路包的報文：

4.6 MAC

??生成了 IP 頭部之后，接下來網路包還需要在 IP 頭部的前面加上 MAC 頭部，MAC 頭部是以太網使用的頭部，它包含了接收方和發送方的 MAC 地址等資訊，

??在 MAC 包頭里需要發送方 MAC 地址和接收方目標 MAC 地址，用于兩點之間的傳輸，一般在 TCP/IP 通信里，MAC 包頭的協議型別只使用：

0800 ： IP 協議
0806 ： ARP 協議

??發送方的 MAC 地址獲取就比較簡單，MAC 地址是在網卡生產時寫入到 ROM 里的，只要將這個值讀取出來寫入到 MAC 頭部就可以了，
??接收方的 MAC 地址有點復雜，只要告訴以太網對方的 MAC 的地址，以太網就會幫我們把包發送過去，那么很顯然這里應該填寫對方的 MAC 地址，所以先得搞清楚應該把包發給誰，這個只要查一下路由表就知道，在路由表中找到相匹配的條目，然后把包發給 Gateway 列中的 IP 地址就可以了，
??從IP到MAC的獲悉是用ARP 協議實作的，ARP 協議會在以太網中以廣播的形式，對以太網所有的設備喊出：“這個 IP 地址是誰的？請把你的MAC 地址告訴我”，

作業系統會把本次查詢結果放到一塊叫做 ARP 快取的記憶體空間留著以后用，不過快取的時間就幾分鐘，

??在發包時：先查詢 ARP 快取，如果其中已經保存了對方的 MAC 地址，就不需要發送 ARP 查詢，直接使用ARP 快取中的地址，當 ARP 快取中不存在對方 MAC 地址時，則發送 ARP 廣播查詢，
??在 Linux 系統中，我們可以使用 arp -a 命令來查看 ARP 快取的內容，

??至此，網路包的報文：

4.7 網卡

??IP 生成的網路包只是存放在記憶體中的一串二進制數字資訊，沒有辦法直接發送給對方，因此，我們需要將數字資訊轉換為電信號，才能在網線上傳輸，也就是說，這才是真正的資料發送程序，負責執行這一操作的是網卡，要控制網卡還需要靠網卡驅動程式，
??網卡驅動從 IP 模塊獲取到包之后，會將其復制到網卡內的快取區中，接著會在其開頭加上報頭和起始幀分界符，在末尾加上用于檢測錯誤的幀校驗序列，

起始幀分界符是一個用來表示包起始位置的標記；
末尾的 FCS （幀校驗序列）用來檢查包傳輸程序是否有損壞，

??最后網卡會將包轉為電信號，通過網線發送出去，

4.8 交換機

??交換機的設計是將網路包原樣轉發到目的地，交換機作業在
MAC 層，也稱為二層網路設備，

• 1、交換機的包接收操作
  ?首先，電信號到達網線介面，交換機里的模塊進行接收，接下來交換機里的模塊將電信號轉換為數字信號，然后通過包末尾的 FCS 校驗錯誤，如果沒問題則放到緩沖區，這部分操作基本和計算機的網卡相同，但交換機的作業方式和網卡不同，
  ?計算機的網卡本身具有 MAC 地址，并通過核對收到的包的接收方 MAC 地址判斷是不是發給自己的，如果不是發給自己的則丟棄；相對地，交換機的埠不核對接收方 MAC 地址，而是直接接收所有的包并存放到緩沖區中，因此，和網卡不同，交換機的埠不具有 MAC 地址，
  ?將包存入緩沖區后，接下來需要查詢一下這個包的接收方 MAC 地址是否已經在 MAC 地址表中有記錄了，
  ?交換機的 MAC 地址表主要包含兩個資訊：

一個是設備的 MAC 地址，
另一個是該設備連接在交換機的哪個埠上，

?舉個例子，如果收到的包的接收方 MAC 地址為 00-02-B3-1C-9C-F9 ，則與圖中表中的第 3 行匹配，根據埠列的資訊，可知這個地址位于 3 號埠上，然后就可以通過交換電路將包發送到相應的埠了，
?所以，交換機根據 MAC 地址表查找 MAC 地址，然后將信號發送到相應的埠，

• 2、當 MAC 地址表找不到指定的 MAC 地址會怎么樣？
  ?地址表中找不到指定的 MAC 地址，這可能是因為具有該地址的設備還沒有向交換機發送過包，或者這個設備一段時間沒有作業導致地址被從地址表中洗掉了，這種情況下，交換機無法判斷應該把包轉發到哪個埠，只能將包轉發到除了源埠之外的所有埠上，無論該設備連接在哪個埠上都能收到這個包，
  ?因為以太網的設計本來就是將包發送到整個網路的，然后只有相應的接收者才接收包，而其他設備則會忽略這個包，
  ?不用過于擔心成網路擁塞的問題，因為發送了包之后目標設備會作出回應，只要回傳了回應包，交換機就可以將它的地址寫入 MAC 地址表，下次也就不需要把包發到所有埠了，
  ?此外，如果接收方 MAC 地址是一個廣播地址，那么交換機會將包發送到除源埠之外的所有埠，以下兩個屬于廣播地址：

MAC 地址中的 FF:FF:FF:FF:FF:FF
IP 地址中的 255.255.255.255

4.9 路由器

??網路包經過交換機之后，現在到達了路由器，并在此被轉發到下一個路由器或目標設備，這一步轉發的作業原理和交換機類似，也是通過查表判斷包轉發的目標，
??過在具體的操作程序上，路由器和交換機是有區別的：

1、因為路由器是基于 IP 設計的，俗稱三層網路設備，路由器的各個埠都具有 MAC 地址和 IP 地址；
2、交換機是基于以太網設計的，俗稱二層網路設備，交換機的埠不具有 MAC 地址，

4.9.1 路由器基本原理

??路由器的埠具有 MAC 地址，因此它就能夠成為以太網的發送方和接收方；同時還具有 IP 地址，從這個意義上來說，它和計算機的網卡是一樣的，
??當轉發包時，首先路由器埠會接收發給自己的以太網包，然后路由表查詢轉發目標，再由相應的埠作為發送方將以太網包發送出去，

4.9.2 路由器的包接收操作

??首先，電信號到達網線介面部分，路由器中的模塊會將電信號轉成數字信號，然后通過包末尾的 FCS進行錯誤校驗，如果沒問題則檢查 MAC 頭部中的接收方 MAC 地址，看看是不是發給自己的包，如果是就放到接識訓沖區中，否則就丟棄這個包，總的來說，路由器的埠都具有 MAC 地址，只接收與自身地址匹配的包，遇到不匹配的包則直接丟棄，

4.9.3 查詢路由表確定輸出埠

??完成包接收操作之后，路由器就會去掉包開頭的 MAC 頭部，MAC 頭部的作用就是將包送達路由器，其中的接收方 MAC 地址就是路由器埠的 MAC 地址，因此，當包到達路由器之后，MAC 頭部的任務就完成了，于是 MAC 頭部就會被丟棄，
??接下來，路由器會根據 MAC 頭部后方的 IP 頭部中的內容進行包的轉發操作，
??轉發操作分為幾個階段，首先是查詢路由表判斷轉發目標，

??舉個例子：假設地址為 10.10.1.101 的計算機要向地址為 192.168.1.100 的服務器發送一個包，這個包先到達圖中的路由器，判斷轉發目標的第一步，就是根據包的接收方 IP 地址查詢路由表中的目標地址欄，以找到相匹配的記錄，路由匹配和前面講的一樣，每個條目的子網掩碼和 192.168.1.100 IP 做 & 與運算后，得到的結果與對應條目的目標地址進行匹配，如果匹配就會作為候選轉發目標，如果不匹配就繼續與下個條目進行路由匹配，
??如第二條目的子網掩碼 255.255.255.0 與 192.168.1.100 IP 做 & 與運算后，得到結果是192.168.1.0 ，這與第二條目的目標地址 192.168.1.0 匹配，該第二條目記錄就會被作為轉發目標，實在找不到匹配路由時，就會選擇默認路由，路由表中子網掩碼為 0.0.0.0 的記錄表示「默認路由」，

4.9.4 路由器的發送操作

??接下來就會進入包的發送操作，首先，需要根據路由表的網關列判斷對方的地址：

如果網關是一個 IP 地址，則這個IP 地址就是我們要轉發到的目標地址，還未抵達終點，還需繼續需要路由器轉發，
如果網關為空，則 IP 頭部中的接收方 IP 地址就是要轉發到的目標地址，也是就終于找到 IP 包頭里的目標地址了，說明已抵達終點，

??知道對方的 IP 地址之后，接下來需要通過 ARP 協議根據 IP 地址查詢 MAC 地址，并將查詢的結果作為接收方 MAC 地址，路由器也有 ARP 快取，因此首先會在 ARP 快取中查詢，如果找不到則發送 ARP 查詢請求，
??接下來是發送方 MAC 地址欄位，這里填寫輸出埠的 MAC 地址，還有一個以太型別欄位，填寫0080 （十六進制）表示 IP 協議，
??網路包完成后，接下來會將其轉換成電信號并通過埠發送出去，
??發送出去的網路包會通過交換機到達下一個路由器，由于接收方 MAC 地址就是下一個路由器的地址，所以交換機會根據這一地址將包傳輸到下一個路由器，接下來，下一個路由器會將包轉發給再下一個路由器，經過層層轉發之后，網路包就到達了最終的目的地，
??在網路包傳輸的程序中，源 IP 和目標 IP 始終是不會變的，一直變化的是 MAC 地址，因為需要 MAC 地址在以太網內進行兩個設備之間的包傳輸，

4.10 服務器 與 客戶端

??資料包抵達服務器后，服務器會先扒開資料包的 MAC 頭部，查看是否和服務器自己的 MAC 地址符合，符合就將包收起來，接著繼續扒開資料包的 IP 頭，發現 IP 地址符合，根據 IP 頭中協議項，知道自己上層是 TCP 協議，
??于是，扒開 TCP 的頭，里面有序列號，需要看一看這個序列包是不是我想要的，如果是就放入快取中然后回傳一個 ACK，如果不是就丟棄，TCP頭部里面還有埠號， HTTP 的服務器正在監聽這個埠號，
??于是，服務器自然就知道是 HTTP 行程想要這個包，于是就將包發給 HTTP 行程，服務器的 HTTP 行程看到，原來這個請求是要訪問一個頁面，于是就把這個網頁封裝在 HTTP 回應報文里，
??HTTP 回應報文也需要穿上 TCP、IP、MAC 頭部，不過這次是源地址是服務器 IP 地址，目的地址是客戶端 IP 地址，穿好頭部衣服后，從網卡出去，交由交換機轉發到出城的路由器，路由器就把回應資料包發到了下一個路由器，就這樣跳，
??最后跳到了客戶端的城門把手的路由器，路由器扒開 IP 頭部發現是要找城內的人，于是又把包發給了城內的交換機，再由交換機轉發到客戶端，客戶端收到了服務器的回應資料包后，同樣也非常的高興，客戶能拆快遞了！于是，客戶端開始扒皮，把收到的資料包的皮扒剩 HTTP 回應報文后，交給瀏覽器去渲染頁面，一份特別的資料包快遞，就這樣顯示出來了！最后，客戶端要離開了，向服務器發起了 TCP 四次揮手，至此雙方的連接就斷開了，

1、在發送資料包時，如果目標主機不是本地局域網，填入的MAC地址是路由器，也就是把資料包轉發給路由器，路由器一直轉發下一個路由器，直到轉發到目標主機的路由器，發現 IP 地址是自己局域網內的主機，就會 arp 請求獲取目標主機的 MAC 地址，從而轉發到這個服務器主機，
2、轉發的程序中，源IP地址和目標IP地址是不會變的，源MAC地址和目標MAC地址是會變化的，

五、三次握手和四次揮手

5.1 TCP 基本認識

??序列號：在建立連接時由計算機生成的亂數作為其初始值，通過 SYN 包傳給接收端主機，每發送一次資料，就「累加」一次該「資料位元組數」的大小，用來解決網路包亂序問題，
??確認應答號：指下一次「期望」收到的資料的序列號，發送端收到這個確認應答以后可以認為在這個序號以前的資料都已經被正常接收，用來解決不丟包的問題，
??控制位：

ACK：該位為 1 時，「確認應答」的欄位變為有效，TCP 規定除了最初建立連接時的 SYN包之外該位必須設定為 1 ，
RST：該位為 1 時，表示 TCP 連接中出現例外必須強制斷開連接，
SYN：該位為 1 時，表示希望建立連接，并在其「序列號」的欄位進行序列號初始值的設定，
FIN：該位為 1 時，表示今后不會再有資料發送，希望斷開連接，當通信結束希望斷開連接時，通信雙方的主機之間就可以相互交換 FIN 位為 1 的 TCP 段，

5.1.1 TCP 作業在哪一層

??IP 層是「不可靠」的，它不保證網路包的交付、不保證網路包的按序交付、也不保證網路包中的資料的完整性，如果需要保障網路資料包的可靠性，那么就需要由上層（傳輸層）的 TCP 協議來負責，

??TCP 是一個作業在傳輸層的可靠資料傳輸的服務，它能確保接收端接收的網路包是無損壞、無間隔、非冗余和按序的，

5.1.2 什么是 TCP 連接

??TCP 是面向連接的、可靠的、基于位元組流的傳輸層通信協議，

1. 面向連接：一定是「一對一」才能連接，不能像 UDP 協議可以一個主機同時向多個主機發送訊息，也就是一對多是無法做到的；
2. 可靠的：無論的網路鏈路中出現了怎樣的鏈路變化，TCP 都可以保證一個報文一定能夠到達接收端；
3. 位元組流：訊息是「沒有邊界」的，所以無論我們訊息有多大都可以進行傳輸，并且訊息是「有序的」，當「前一個」訊息沒有收到的時候，即使它先收到了后面的位元組，那么也不能扔給應用層去處理，同時對「重復」的報文會自動丟棄，

??TCP 連接：簡單來說就是，用于保證可靠性和流量控制維護的某些狀態資訊，這些資訊的組合，包括Socket、序列號和視窗大小稱為連接，
??因此，建立一個 TCP 連接是需要客戶端與服務器端達成上述三個資訊的共識，

Socket：由 IP 地址和埠號組成
序列號：用來解決亂序問題等
視窗大小：用來做流量控制

5.1.3 如何唯一確定一個 TCP 連接

??TCP 四元組可以唯一的確定一個連接，四元組包括如下：源地址、源埠、目的地址、目的埠，
??源地址和目的地址的欄位（32位）是在 IP 頭部中，作用是通過 IP 協議發送報文給對方主機，
??源埠和目的埠的欄位（16位）是在 TCP 頭部中，作用是告訴 TCP 協議應該把報文發給哪個行程，

5.1.4 TCP 的最大連接數

??服務器通常固定在某個本地埠上監聽，等待客戶端的連接請求，因此，客戶端 IP 和 埠是可變的，其理論值計算公式如下:

??對 IPv4，客戶端的 IP 數最多為 2³²，客戶端的埠數最多為 2^ 16^，也就是服務端單機最大 TCP 連接數，約為 2⁴⁸，
??當然，服務端最大并發 TCP 連接數遠不能達到理論上限：

首先主要是檔案描述符限制，Socket 都是檔案，所以首先要通過 ulimit 組態檔描述符的數目；
另一個是記憶體限制，每個 TCP 連接都要占用一定記憶體，作業系統的記憶體是有限的，

5.1.5 UDP 和 TCP的區別

??UDP 不提供復雜的控制機制，利用 IP 提供面向「無連接」的通信服務，
??UDP 協議頭部只有 8 個位元組（ 64 位），UDP 的頭部格式如下：

目標和源埠：主要是告訴 UDP 協議應該把報文發給哪個行程，
包長度：該欄位保存了 UDP 首部的長度跟資料的長度之和，
校驗和：校驗和是為了提供可靠的 UDP 首部和資料而設計，

• 1、TCP 和 UDP 區別
  ?1）連接，TCP 是面向連接的傳輸層協議，傳輸資料前先要建立連接，UDP 是不需要連接，即刻傳輸資料，
  ?2）服務物件，TCP 是一對一的兩點服務，即一條連接只有兩個端點，
  UDP 支持一對一、一對多、多對多的互動通信，
  ?3）可靠性，TCP 是可靠交付資料的，資料可以無差錯、不丟失、不重復、按需到達，UDP 是盡最大努力交付，不保證可靠交付資料，
  ?4）擁塞控制、流量控制，TCP 有擁塞控制和流量控制機制，保證資料傳輸的安全性，UDP 則沒有，即使網路非常擁堵了，也不會影響 UDP 的發送速率，
  ?5）首部開銷，TCP 首部長度較長，會有一定的開銷，首部在沒有使用「選項」欄位時是 20 個位元組，如果使用了「選項」欄位則會變長的，UDP 首部只有 8 個位元組，并且是固定不變的，開銷較小，
  ?6）傳輸方式，TCP 是流式傳輸，沒有邊界，但保證順序和可靠，UDP 是一個包一個包的發送，是有邊界的，但可能會丟包和亂序，
  ?7）分片不同，
  ??TCP 的資料大小如果大于 MSS 大小，則會在傳輸層進行分片，目標主機收到后，也同樣在傳輸層組裝 TCP 資料包，如果中途丟失了一個分片，只需要傳輸丟失的這個分片，
  ??UDP 的資料大小如果大于 MTU 大小，則會在 IP 層進行分片，目標主機收到后，在 IP 層組裝完資料，接著再傳給傳輸層，但是如果中途丟了一個分片，則就需要重傳所有的資料包，這樣傳輸效率非常差，所以通常 UDP 的報文應該小于 MTU，
• 2、TCP 和 UDP 應用場景
  ?由于 TCP 是面向連接，能保證資料的可靠性交付，因此經常用于：

FTP 檔案傳輸；
HTTP / HTTPS，

??由于 UDP 面向無連接，它可以隨時發送資料，再加上UDP本身的處理既簡單又高效，因此經常用于：

包總量較少的通信，如 DNS 、 SNMP 等；
視頻、音頻等多媒體通信；
廣播通信，

??為什么 UDP 頭部沒有「首部長度」欄位，而 TCP 頭部有「首部長度」欄位呢？原因是 TCP 有可變長的「選項」欄位，而 UDP 頭部長度則是不會變化的，無需多一個欄位去記錄UDP 的首部長度，

• 3、為什么 UDP 頭部有「包長度」欄位，而 TCP 頭部則沒有「包長度」欄位呢？
  ? TCP 是如何計算負載資料長度：
  
  ?IP 總長度 和 IP 首部長度，在 IP 首部格式是已知的，TCP 首部長度，則是在 TCP 首部格式已知的，所以就可以求得 TCP 資料的長度，
  ?為了網路設備硬體設計和處理方便，首部長度需要是 4 位元組的整數倍，如果去掉 UDP 「包長度」欄位，那 UDP 首部長度就不是 4 位元組的整數倍了，所以可能是為了補全 UDP 首部長度是 4 位元組的整數倍，才補充了「包長度」欄位，

5.2 TCP 連接建立

??TCP 是面向連接的協議，所以使用 TCP 前必須先建立連接，而建立連接是通過三次握手來進行的，

??一開始，客戶端和服務端都處于 CLOSED 狀態，先是服務端主動監聽某個埠，處于 LISTEN狀態：

??客戶端會隨機初始化序號（ client_isn ），將此序號置于 TCP 首部的「序號」欄位中，同時把SYN 標志位置為 1 ，表示 SYN 報文，接著把第一個 SYN 報文發送給服務端，表示向服務端發起連接，該報文不包含應用層資料，之后客戶端處于 SYN-SENT 狀態，

??服務端收到客戶端的 SYN 報文后，首先服務端也隨機初始化自己的序號（ server_isn ），將此序號填入 TCP 首部的「序號」欄位中，其次把 TCP 首部的「確認應答號」欄位填入 client_isn +1 , 接著把 SYN 和 ACK 標志位置為 1 ，最后把該報文發給客戶端，該報文也不包含應用層資料，之后服務端處于 SYN-RCVD 狀態，

??客戶端收到服務端報文后，還要向服務端回應最后一個應答報文，首先該應答報文 TCP 首部ACK 標志位置為 1 ，其次「確認應答號」欄位填入 server_isn + 1 ，最后把報文發送給服務端，這次報文可以攜帶客戶到服務器的資料，之后客戶端處于 ESTABLISHED 狀態，服務器收到客戶端的應答報文后，也進入 ESTABLISHED 狀態，

從上面的程序可以發現第三次握手是可以攜帶資料的，前兩次握手是不可以攜帶資料的，

??一旦完成三次握手，雙方都處于 ESTABLISHED 狀態，此時連接就已建立完成，客戶端和服務端就可以相互發送資料了，
??TCP 的連接狀態查看，在 Linux 可以通過 netstat -napt 命令查看，

5.2.1 為什么是三次握手？不是兩次、四次？

??一般來說，因為三次握手才能保證雙方具有接收和發送的能力，
?? TCP 連接：是用于保證可靠性和流量控制維護的某些狀態資訊，這些資訊的組合，包括Socket、序列號和視窗大小，
??所以，重要的是為什么三次握手才可以初始化Socket、序列號和視窗大小并建立 TCP 連接，
??三個方面分析三次握手的原因：

三次握手才可以阻止重復歷史連接的初始化（主要原因）；
三次握手才可以同步雙方的初始序列號；
三次握手才可以避免資源浪費，

• 1、避免歷史連接
  ?簡單來說，三次握手的首要原因是為了防止舊的重復連接初始化造成混亂，
  
  ??客戶端連續發送多次 SYN 建立連接的報文，在網路擁堵情況下：

?一個「舊 SYN 報文」比「最新的 SYN 」 報文早到達了服務端；
?那么此時服務端就會回一個 SYN + ACK 報文給客戶端；
?客戶端收到后可以根據自身的背景關系，判斷這是一個歷史連接（序列號過期或超時），那么客戶端就會發送 RST 報文給服務端，表示中止這一次連接，

??如果是兩次握手連接，就不能判斷當前連接是否是歷史連接，三次握手則可以在客戶端（發送方）準備發送第三次報文時，客戶端因有足夠的背景關系來判斷當前連接是否是歷史連接：

?如果是歷史連接（序列號過期或超時），則第三次握手發送的報文是 RST 報文，以此中止歷史連接；
?如果不是歷史連接，則第三次發送的報文是 ACK 報文，通信雙方就會成功建立連接；

??所以，TCP 使用三次握手建立連接的最主要原因是防止歷史連接初始化了連接，

• 2、同步雙方初始序列號
  ?TCP 協議的通信雙方， 都必須維護一個「序列號」， 序列號是可靠傳輸的一個關鍵因素，它的作用：

?接收方可以去除重復的資料；
?接收方可以根據資料包的序列號按序接收；
?可以標識發送出去的資料包中， 哪些是已經被對方收到的，

??可見，序列號在 TCP 連接中占據著非常重要的作用，所以當客戶端發送攜帶「初始序列號」的 SYN報文的時候，需要服務端回一個 ACK 應答報文，表示客戶端的 SYN 報文已被服務端成功接收，那當服務端發送「初始序列號」給客戶端的時候，依然也要得到客戶端的應答回應，這樣一來一回，才能確保雙方的初始序列號能被可靠的同步，

??四次握手其實也能夠可靠的同步雙方的初始化序號，但由于第二步和第三步可以優化成一步，所以就成了「三次握手」，
??而兩次握手只保證了一方的初始序列號能被對方成功接收，沒辦法保證雙方的初始序列號都能被確認接收，

• 3、避免資源浪費
  ?如果只有「兩次握手」，當客戶端的 SYN 請求連接在網路中阻塞，客戶端沒有接收到 ACK 報文，就會重新發送 SYN ，由于沒有第三次握手，服務器不清楚客戶端是否收到了自己發送的建立連接的ACK 確認信號，所以每收到一個 SYN 就只能先主動建立一個連接，這會造成什么情況呢？如果客戶端的 SYN 阻塞了，重復發送多次 SYN 報文，那么服務器在收到請求后就會建立多個冗余的無效鏈接，造成不必要的資源浪費，
  
  ??即兩次握手會造成訊息滯留情況下，服務器重復接受無用的連接請求 SYN 報文，而造成重復分配資源，
• 小節
  ??TCP 建立連接時，通過三次握手能防止歷史連接的建立，能減少雙方不必要的資源開銷，能幫助雙方同步初始化序列號，序列號能夠保證資料包不重復、不丟棄和按序傳輸，
  ??不使用「兩次握手」和「四次握手」的原因：

「兩次握手」：無法防止歷史連接的建立，會造成雙方資源的浪費，也無法可靠的同步雙方序列號；
「四次握手」：三次握手就已經理論上最少可靠連接建立，所以不需要使用更多的通信次數，

5.2.2 一些常見問題

• 1、為什么客戶端和服務端的初始序列號 ISN 是不相同的？
  ??如果一個已經失效的連接被重用了，但是該舊連接的歷史報文還殘留在網路中，如果序列號相同，那么就無法分辨出該報文是不是歷史報文，如果歷史報文被新的連接接收了，則會產生資料錯亂，
  ??所以，每次建立連接前重新初始化一個序列號主要是為了通信雙方能夠根據序號將不屬于本連接的報文段丟棄，
  ??另一方面是為了安全性，防止黑客偽造的相同序列號的 TCP 報文被對方接收，
• 2、既然 IP 層會分片，為什么 TCP 層還需要 MSS 呢？
  ??們先來認識下 MTU 和 MSS：
  

MTU ：一個網路包的最大長度，以太網中一般為 1500 位元組；
MSS ：除去 IP 和 TCP 頭部之后，一個網路包所能容納的 TCP 資料的最大長度，

??如果在 TCP 的整個報文（頭部 + 資料）交給 IP 層進行分片，會有什么例外呢？當 IP 層有一個超過 MTU 大小的資料（TCP 頭部 + TCP 資料）要發送，那么 IP 層就要進行分片，把資料分片成若干片，保證每一個分片都小于 MTU，把一份 IP 資料報進行分片以后，由目標主機的 IP層來進行重新組裝后，再交給上一層 TCP 傳輸層，
??這存在隱患的，那么當如果一個 IP 分片丟失，整個 IP 報文的所有分片都得重傳，因為 IP 層本身沒有超時重傳機制，它由傳輸層的 TCP 來負責超時和重傳，
??當接收方發現 TCP 報文（頭部 + 資料）的某一片丟失后，則不會回應 ACK 給對方，那么發送方的TCP 在超時后，就會重發「整個 TCP 報文（頭部 + 資料）」，因此，可以得知由 IP 層進行分片傳輸，是非常沒有效率的，
??所以，為了達到最佳的傳輸效能 TCP 協議在建立連接的時候通常要協商雙方的 MSS 值，當 TCP 層發現資料超過 MSS 時，則就先會進行分片，當然由它形成的 IP 包的長度也就不會大于 MTU ，自然也就不用 IP 分片了，

??經過 TCP 層分片后，如果一個 TCP 分片丟失后，進行重發時也是以 MSS 為單位，而不用重傳所有的分片，大大增加了重傳的效率，

5.2.3 SYN 攻擊

??TCP 連接建立是需要三次握手，假設攻擊者短時間偽造不同 IP 地址的 SYN 報文，服務端每接收到一個 SYN 報文，就進入 SYN_RCVD 狀態，但服務端發送出去的 ACK + SYN 報文，無法得到未知 IP 主機的 ACK 應答，久而久之就會占滿服務端的 SYN 接收佇列（未連接佇列），使得服務器不能為正常用戶服務，

• 1、避免 SYN 攻擊方式一
  ?其中一種解決方式是通過修改 Linux 內核引數，控制佇列大小和當佇列滿時應做什么處理，
  ?當網卡接收資料包的速度大于內核處理的速度時，會有一個佇列保存這些資料包，控制該佇列的最大值：net.core.netdev_max_backlog，
  ?SYN_RCVD 狀態連接的最大個數：net.ipv4.tcp_max_syn_backlog，
  ?超出處理能時，對新的 SYN 直接回報 RST，丟棄連接：net.ipv4.tcp_abort_on_overflow，
• 2、避免 SYN 攻擊方式二
  ? Linux 內核的 SYN （未完成連接建立）佇列與 Accpet （已完成連接建立）佇列的作業流程：
  
  ?正常流程：

當服務端接收到客戶端的 SYN 報文時，會將其加入到內核的「 SYN 佇列」；
接著發送 SYN + ACK 給客戶端，等待客戶端回應 ACK 報文；
服務端接收到 ACK 報文后，從「 SYN 佇列」移除放入到「 Accept 佇列」；
應用通過呼叫 accpet() socket 介面，從「 Accept 佇列」取出連接，

?應用程式過慢，如果應用程式過慢時，就會導致「 Accept 佇列」被占滿：

?受到 SYN 攻擊：

?如果不斷受到 SYN 攻擊，就會導致「 SYN 佇列」被占滿，
?tcp_syncookies 的方式可以應對 SYN 攻擊，設定方式為：
net.ipv4.tcp_syncookies = 1，此時的流程：

?此時的流程：

當 「 SYN 佇列」滿之后，后續服務器收到 SYN 包，不進入「 SYN 佇列」；
計算出一個 cookie 值，再以 SYN + ACK 中的「序列號」回傳客戶端；
服務端接收到客戶端的應答報文時，服務器會檢查這個 ACK 包的合法性，如果合法，直接放入到「 Accept 佇列」；
最后應用通過呼叫 accpet() socket 介面，從「 Accept 佇列」取出的連接，

5.3 TCP 連接斷開

??TCP 斷開連接是通過四次揮手方式，

??流程：

?客戶端打算關閉連接，此時會發送一個 TCP 首部 FIN 標志位被置為 1 的報文，也即 FIN報文，之后客戶端進入 FIN_WAIT_1 狀態，
?服務端收到該報文后，就向客戶端發送 ACK 應答報文，接著服務端進入 CLOSED_WAIT 狀態，
?客戶端收到服務端的 ACK 應答報文后，之后進入 FIN_WAIT_2 狀態，
?等待服務端處理完資料后，也向客戶端發送 FIN 報文，之后服務端進入 LAST_ACK 狀態，
?客戶端收到服務端的 FIN 報文后，回一個 ACK 應答報文，之后進入 TIME_WAIT 狀態，
?服務器收到了 ACK 應答報文后，就進入了 CLOSED 狀態，至此服務端已經完成連接的關閉，
?客戶端在經過 2MSL 一段時間后，自動進入 CLOSED 狀態，至此客戶端也完成連接的關閉，

??需要注意是：主動關閉連接的，才有 TIME_WAIT 狀態，

5.3.1 為什么揮手需要四次

??回顧下四次揮手雙方發 FIN 包的程序：

?關閉連接時，客戶端向服務端發送 FIN 時，僅僅表示客戶端不再發送資料了但是還能接收資料，
?服務器收到客戶端的 FIN 報文時，先回一個 ACK 應答報文，而服務端可能還有資料需要處理和發送，等服務端不再發送資料時，才發送 FIN 報文給客戶端來表示同意現在關閉連接，

??，服務端通常需要等待完成資料的發送和處理，所以服務端的 ACK 和 FIN 一般都會分開發送，從而比三次握手導致多了一次，

5.3.2 為什么 TIME_WAIT 等待的時間是 2MSL

??MSL 是 Maximum Segment Lifetime，報文最大生存時間，它是任何報文在網路上存在的最長時間，超過這個時間報文將被丟棄，因為 TCP 報文基于是 IP 協議的，而 IP 頭中有一個 TTL 欄位，是 IP 資料報可以經過的最大路由數，每經過一個處理他的路由器此值就減 1，當此值為 0 則資料報將被丟棄，同時發送 ICMP 報文通知源主機，
??MSL 與 TTL 的區別： MSL 的單位是時間，而 TTL 是經過路由跳數，所以 MSL 應該要大于等于 TTL消耗為 0 的時間，以確保報文已被自然消亡，
??TIME_WAIT 等待 2 倍的 MSL，比較合理的解釋是： 網路中可能存在來自發送方的資料包，當這些發送方的資料包被接收方處理后又會向對方發送回應，所以一來一回需要等待 2 倍的時間，

比如如果被動關閉方沒有收到斷開連接的最后的 ACK 報文，就會觸發超時重發 Fin 報文，另一方接收到 FIN 后，會重發 ACK 給被動關閉方， 一來一去正好 2 個 MSL，

??2MSL 的時間是從客戶端接收到 FIN 后發送 ACK 開始計時的，如果在 TIME-WAIT 時間內，因為客戶端的 ACK 沒有傳輸到服務端，客戶端又接收到了服務端重發的 FIN 報文，那么 2MSL 時間將重新計時，
??在 Linux 系統里 2MSL 默認是 60 秒，那么一個 MSL 也就是 30 秒，Linux 系統停留在TIME_WAIT 的時間為固定的 60 秒，其定義在 Linux 內核代碼里的名稱為 TCP_TIMEWAIT_LEN：

#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
state, about 60 seconds */

??如果要修改 TIME_WAIT 的時間長度，只能修改 Linux 內核代碼里 TCP_TIMEWAIT_LEN 的值，并重新編譯 Linux 內核，

5.3.3 為什么需要 TIME_WAIT 狀態

??主動發起關閉連接的一方，才會有 TIME-WAIT 狀態，需要 TIME-WAIT 狀態，主要是兩個原因：

?防止具有相同「四元組」的「舊」資料包被收到；
?保證「被動關閉連接」的一方能被正確的關閉，即保證最后的 ACK 能讓被動關閉方接收，從而幫助其正常關閉，

• 1、防止舊連接的資料包
  ?假設 TIME-WAIT 沒有等待時間或時間過短，被延遲的資料包抵達后會發生什么呢？
  

?如上圖黃色框框服務端在關閉連接之前發送的 SEQ = 301 報文，被網路延遲了，這時有相同埠的 TCP 連接被復用后，被延遲的 SEQ = 301 抵達了客戶端，那么客戶端是有可能正常接收這個過期的報文，這就會產生資料錯亂等嚴重的問題，

?所以，TCP 就設計出了這么一個機制，經過 2MSL 這個時間，足以讓兩個方向上的資料包都被丟棄，使得原來連接的資料包在網路中都自然消失，再出現的資料包一定都是新建立連接所產生的，

• 2、保證連接正確關閉
  ?TIME-WAIT 作用是等待足夠的時間以確保最后的 ACK 能讓被動關閉方接收，從而幫助其正常關閉，
  ?假設 TIME-WAIT 沒有等待時間或時間過短，斷開連接會造成什么問題呢？
  
  ?如上圖紅色框框客戶端四次揮手的最后一個 ACK 報文如果在網路中被丟失了，此時如果客戶端TIME-WAIT 過短或沒有，則就直接進入了 CLOSED 狀態了，那么服務端則會一直處在LASE_ACK 狀態，當客戶端發起建立連接的 SYN 請求報文后，服務端會發送 RST 報文給客戶端，連接建立的程序就會被終止，
  ?如果 TIME-WAIT 等待足夠長的情況就會遇到兩種情況：

1）服務端正常收到四次揮手的最后一個 ACK 報文，則服務端正常關閉連接，
2）服務端沒有收到四次揮手的最后一個 ACK 報文時，則會重發 FIN 關閉連接報文并等待新的ACK 報文，

?所以客戶端在 TIME-WAIT 狀態等待 2MSL 時間后，就可以保證雙方的連接都可以正常的關閉，

5.3.4 TIME_WAIT 過多有什么危害

??如果服務器有處于 TIME-WAIT 狀態的 TCP，則說明是由服務器方主動發起的斷開請求，過多的 TIME-WAIT 狀態主要的危害有兩種：

第一是記憶體資源占用；
第二是對埠資源的占用，一個 TCP 連接至少消耗一個本地埠，

??第二個危害是會造成嚴重的后果的，要知道，埠資源也是有限的，一般可以開啟的埠為 32768～61000 ，也可以通過如下引數設定指定：net.ipv4.ip_local_port_range，
??如果發起連接一方的 TIME_WAIT 狀態過多，占滿了所有埠資源，則會導致無法創建新連接，

1、客戶端受埠資源限制：客戶端TIME_WAIT過多，就會導致埠資源被占用，因為埠就65536個，被占滿就會導致無法創建新的連接，
2、服務端受系統資源限制：由于一個四元組表示 TCP 連接，理論上服務端可以建立很多連接，服務端確實只監聽一個埠 但是會把連接扔給處理執行緒，所以理論上監聽的埠可以繼續監聽，但是執行緒池處理不了那么多一直不斷的連接了，所以當服務端出現大量 TIME_WAIT 時，系統資源被占滿時，會導致處理不過來新的連接，

5.3.5 如何優化 TIME_WAIT

??給出優化 TIME-WAIT 的幾個方式，都是有利有弊：

?打開 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_timestamps 選項；
?net.ipv4.tcp_max_tw_buckets；
?程式中使用 SO_LINGER ，應用強制使用 RST 關閉，

• 1、net.ipv4.tcp_tw_reuse 和 tcp_timestamps
  ??設定net.ipv4.tcp_tw_reuse = 1Linux 內核引數開啟后，則可以復用處于 TIME_WAIT 的 socket 為新的連接所用，有一點需要注意的是，tcp_tw_reuse 功能只能用客戶端（連接發起方），因為開啟了該功能，在呼叫connect() 函式時，內核會隨機找一個 time_wait 狀態超過 1 秒的連接給新的連接復用，
  ??使用這個選項，還有一個前提，需要打開對 TCP 時間戳的支持，即
  net.ipv4.tcp_timestamps=1（默認即為 1），
  ??這個時間戳的欄位是在 TCP 頭部的「選項」里，用于記錄 TCP 發送方的當前時間戳和從對端接收到的最新時間戳，由于引入了時間戳，前面提到的 2MSL 問題就不復存在了，因為重復的資料包會因為時間戳過期被自然丟棄，
• 2、net.ipv4.tcp_max_tw_buckets
  ??這個值默認為 18000，當系統中處于 TIME_WAIT 的連接一旦超過這個值時，系統就會將所有的TIME_WAIT 連接狀態重置，這個方法過于暴力，而且治標不治本，帶來的問題遠比解決的問題多，不推薦使用，
• 3、程式中使用 SO_LINGER
  ??我們可以通過設定 socket 選項，來設定呼叫 close 關閉連接行為，

struct linger so_linger;
so_linger.l_onoff = 1;
so_linger.l_linger = 0;
setsockopt(s, SOL_SOCKET, SO_LINGER, &so_linger,sizeof(so_linger));

??如果 l_onoff 為非 0， 且 l_linger 值為 0，那么呼叫 close 后，會立該發送一個 RST 標志給對端，該TCP 連接將跳過四次揮手，也就跳過了 TIME_WAIT 狀態，直接關閉，但這為跨越 TIME_WAIT 狀態提供了一個可能，不過是一個非常危險的行為，不值得提倡，

5.3.6 如果已經建立了連接，但是客戶端突然出現故障了怎么辦

??TCP 有一個機制是保活機制，這個機制的原理是這樣的：

定義一個時間段，在這個時間段內，如果沒有任何連接相關的活動，TCP 保活機制會開始作用，每隔一個時間間隔，發送一個探測報文，該探測報文包含的資料非常少，如果連續幾個探測報文都沒有得到回應，則認為當前的 TCP 連接已經死亡，系統內核將錯誤資訊通知給上層應用程式，

??在 Linux 內核可以有對應的引數可以設定保活時間、保活探測的次數、保活探測的時間間隔，以下都為默認值：

net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75
net.ipv4.tcp_keepalive_probes=9

??tcp_keepalive_time=7200：表示保活時間是 7200 秒（2小時），也就 2 小時內如果沒有任何連接相關的活動，則會啟動保活機制，
??tcp_keepalive_intvl=75：表示每次檢測間隔 75 秒，
??tcp_keepalive_probes=9：表示檢測 9 次無回應，認為對方是不可達的，從而中斷本次的連接，
??也就是說在 Linux 系統中，最少需要經過 2 小時 11 分 15 秒才可以發現一個「死亡」連接，

??這個時間是有點長的，我們也可以根據實際的需求，對以上的保活相關的引數進行設定，如果開啟了 TCP 保活，需要考慮以下幾種情況：

1. 第一種，對端程式是正常作業的，當 TCP 保活的探測報文發送給對端, 對端會正常回應，這樣 TCP 保活時間會被重置，等待下一個 TCP 保活時間的到來，
2. 第二種，對端程式崩潰并重啟，當 TCP 保活的探測報文發送給對端后，對端是可以回應的，但由于沒有該連接的有效資訊，會產生一個 RST 報文，這樣很快就會發現 TCP 連接已經被重置，
3. 第三種，是對端程式崩潰，或對端由于其他原因導致報文不可達，當 TCP 保活的探測報文發送給對端后，石沉大海，沒有回應，連續幾次，達到保活探測次數后，TCP 會報告該 TCP 連接已經死亡，

5.4 Socket 編程

??文字描述：

?服務端和客戶端初始化 socket ，得到檔案描述符；
?服務端呼叫 bind ，將系結在 IP 地址和埠;
?服務端呼叫 listen ，進行監聽；
?服務端呼叫 accept ，等待客戶端連接；
?客戶端呼叫 connect ，向服務器端的地址和埠發起連接請求；
?服務端 accept 回傳用于傳輸的 socket 的檔案描述符；
?客戶端呼叫 write 寫入資料；服務端呼叫 read 讀取資料；
?客戶端斷開連接時，會呼叫 close ，那么服務端 read 讀取資料的時候，就會讀取到了EOF ，待處理完資料后，服務端呼叫 close ，表示連接關閉，

??需要注意的是，服務端呼叫 accept 時，連接成功了會回傳一個已完成連接的 socket，后續用來傳輸資料，所以，監聽的 socket 和真正用來傳送資料的 socket，是「兩個」 socket，一個叫作監聽 socket，一個叫作已完成連接 socket，
??成功連接建立之后，雙方開始通過 read 和 write 函式來讀寫資料，就像往一個檔案流里面寫東西一樣，

5.4.1 listen 時候引數 backlog 的意義

??Linux內核中會維護兩個佇列：

未完成連接佇列（SYN 佇列）：接收到一個 SYN 建立連接請求，處于 SYN_RCVD 狀態；
已完成連接佇列（Accpet 佇列）：已完成 TCP 三次握手程序，處于 ESTABLISHED 狀態，

int listen (int socketfd, int backlog)

??socketfd 為 socketfd 檔案描述符；
??backlog，這引數在歷史版本有一定的變化，在早期 Linux 內核 backlog 是 SYN 佇列大小，也就是未完成的佇列大小，在 Linux 內核 2.2 之后，backlog 變成 accept 佇列，也就是已完成連接建立的佇列長度，所以現在通常
認為 backlog 是 accept 佇列，但是上限值是內核引數 somaxconn 的大小，也就說 accpet 佇列長度 = min(backlog,somaxconn)，

5.4.2 accept 發生在三次握手的哪一步

??先看看客戶端連接服務端時，發送了什么？

1. 客戶端的協議堆疊向服務器端發送了 SYN 包，并告訴服務器端當前發送序列號 client_isn，客戶端進入 SYN_SENT 狀態；
2. 服務器端的協議堆疊收到這個包之后，和客戶端進行 ACK 應答，應答的值為 client_isn+1，表示對SYN 包 client_isn 的確認，同時服務器也發送一個 SYN 包，告訴客戶端當前我的發送序列號為server_isn，服務器端進入 SYN_RCVD 狀態；
3. 客戶端協議堆疊收到 ACK 之后，使得應用程式從 connect 呼叫回傳，表示客戶端到服務器端的單向連接建立成功，客戶端的狀態為 ESTABLISHED，同時客戶端協議堆疊也會對服務器端的 SYN 包進行應答，應答資料為 server_isn+1；
4. 應答包到達服務器端后，服務器端協議堆疊使得 accept 阻塞呼叫回傳，這個時候服務器端到客戶端的單向連接也建立成功，服務器端也進入 ESTABLISHED 狀態，

??們可以得知客戶端 connect 成功回傳是在第二次握手，服務端 accept 成功回傳是在三次握手成功之后，

5.4.3 客戶端呼叫 close 了，連接是斷開的流程是什么

1. 客戶端呼叫 close ，表明客戶端沒有資料需要發送了，則此時會向服務端發送 FIN 報文，進入FIN_WAIT_1 狀態；
2. 服務端接收到了 FIN 報文，TCP 協議堆疊會為 FIN 包插入一個檔案結束符 EOF 到接識訓沖區中，應用程式可以通過 read 呼叫來感知這個 FIN 包，這個 EOF 會被放在已排隊等候的其他已接收的資料之后，這就意味著服務端需要處理這種例外情況，因為 EOF 表示在該連接上再無額外資料到達，此時，服務端進入 CLOSE_WAIT 狀態；
3. 接著，當處理完資料后，自然就會讀到 EOF ，于是也呼叫 close 關閉它的套接字，這會使得客戶端會發出一個 FIN 包，之后處于 LAST_ACK 狀態；
4. 客戶端接收到服務端的 FIN 包，并發送 ACK 確認包給服務端，此時客戶端將進入 TIME_WAIT 狀態；
5. 服務端收到 ACK 確認包后，就進入了最后的 CLOSE 狀態；
6. 客戶端經過 2MSL 時間之后，也進入 CLOSE 狀態，