寫在最前面：本文章所有內容是本人從網絡上以及《計算機網絡第七版整理》整理而得，內容非原創~
另一部分參見：計算機網絡面試常考總結（一）
DNS：Domain Name System，域名系統，是互聯網使用的命名系統，用來便於把人們使用的機器名字轉換為IP地址。
如上圖，m.xyz.com需要查找y.abc.com的IP地址：
主機m.xyz.com向本地域名服務器進行遞歸查詢。
主機向本地域名服務器查詢時一般使用遞歸查詢。
- 遞歸查詢：就是如果本地域名服務器沒有所需域名的IP地址，本地域名服務器就以客戶的方式向其他根域名服務器繼續查詢，而不是主機自己進行查詢。
本地域名服務器向其他根域名服務器進行查詢的時一般使用迭代查詢。
- 迭代查詢： 當某個根域名服務器收到本地域名服務器的請求報文時，要么告訴它所需域名的IP地址，要么告訴它下一步應該向哪個服務器發起詢問。然后讓本地域名服務器自己去查詢。
本地域名服務器迭代查詢，先向一個根域名服務器查詢。
根域名服務器告訴本地域名服務器，下一步應該向頂級域名服務器dns.com查詢。
頂級域名服務器dns.com告訴本地域名服務器，下一步查找權限域名服務器：dns.adc.com。
本地域名服務器向權限域名服務器發起查詢。權限域名服務器告訴本地服務器所需的IP地址，本地服務器在告訴給本地主機。
補充——域名服務器的分類：
根域名服務器： 最高層也是最重要的域名服務器，所有的根域名服務器都知道所有的頂級域名服務器的域名地址和IP地址。例如：a.rootserver.net。
頂級域名服務器： 這些域名服務器負責管理在該頂級域名服務器上注冊的所有的二級域名。例如：com
權限域名服務器： 負責一個區的域名服務器，如果當前權限域名服務器不能給出所需的IP地址，則返回客戶應該找哪一個權限服務器。
本地域名服務器： 本地DNS一般是指你電腦上網時IPv4或者IPv6設置中填寫的那個DNS。這個有可能是手工指定的或者是DHCP自動分配的。當一台主機發送DNS請求報文時，這個查詢報文就發送給本地域名服務器。
簡述HTTP協議以及一次HTTP操作的。
HTTP 是面向事務的(transaction-oriented)應用層協議，它是萬維網上能夠可靠地交換文件（包括文本、聲音、圖像等各種多媒體文件）的重要基礎。
-
HTTP 是面向事務的客戶服務器協議。
-
HTTP 1.0 協議是無狀態的(stateless)。
-
HTTP 協議本身也是無連接的，雖然它使用了面向連接的 TCP 向上提供的服務。
一次HTTP操作的過程：
瀏覽器分析超鏈指向頁面的 URL。
瀏覽器向 DNS 請求解析 www.tsinghua.edu.cn 的 IP 地址。
域名系統 DNS 解析出清華大學服務器的 IP 地址。
瀏覽器與服務器建立 TCP 連接
瀏覽器發出取文件命令：GET /chn/yxsz/index.htm。
服務器給出響應，把文件 index.htm 發給瀏覽器。
TCP 連接釋放。
瀏覽器顯示“清華大學院系設置”文件 index.htm 中的所有文本。
HTTP報文的格式？
HTTP報文分為兩類：請求報文和響應報文。它們都由三部分組成：開始行、首部行、實體主體。區別就是開始行不同。
-
首部行： 用來說明服務器、瀏覽器、或報文主體的一些信息。
-
實體主體： 一般不用。
-
開始行：對於請求報文來說，就是請求行。對於響應報文來說，就是狀態行。
請求行： 包括三個內容：方法，URL以及HTTP的版本。后面有關於方法的詳解。
狀態行： 包括三個內容：HTTP版本、狀態碼以及狀態碼的簡單短語。后面有關於狀態碼的詳解。
HTTP請求報文中的方法有哪些？
get與post的區別。
| GET | POST | |
|---|---|---|
| 后退按鈕/刷新 | 無害 | 數據會被重新提交（瀏覽器應該告知用戶數據會被重新提交）。 |
| 書簽 | 可收藏為書簽 | 不可收藏為書簽 |
| 緩存 | 能被緩存 | 不能緩存 |
| 編碼類型 | application/x-www-form-urlencoded | application/x-www-form-urlencoded 或 multipart/form-data。為二進制數據使用多重編碼。 |
| 歷史 | 參數保留在瀏覽器歷史中。 | 參數不會保存在瀏覽器歷史中。 |
| 對數據長度的限制 | 是的。當發送數據時，GET 方法向 URL 添加數據；URL 的長度是受限制的（URL 的最大長度是 2048 個字符）。 | 無限制。 |
| 對數據類型的限制 | 只允許 ASCII 字符。 | 沒有限制。也允許二進制數據。 |
| 安全性 | 與 POST 相比，GET 的安全性較差，因為所發送的數據是 URL 的一部分。在發送密碼或其他敏感信息時絕不要使用 GET ！ | POST 比 GET 更安全，因為參數不會被保存在瀏覽器歷史或 web 服務器日志中。 |
| 可見性 | 數據在 URL 中對所有人都是可見的。 | 數據不會顯示在 URL 中。 |
get方法一般用於請求獲取信息，post方法一般用於向服務器提交一些修改信息。比如，我們輸入一個網頁地址，我們使用get方法獲取頁面的信息。如果我們要在某個網站上購買一件商品，我們使用post方法提交一個表單，服務器就記錄下了你要購買的商品。基於這樣的場景，可以得出：
get方法請求的內容可以添加為標簽並且能被緩存，post則不能添加為標簽和被緩存（因為post請求的內容如果能添加為標簽和被緩存的話，你下次點擊這個標簽就會直接購買商品了，很不安全）。
刷新的時候，get方法可以重新請求，無害，但是post的方法會重新提交表單（服務器這時候會告知用戶），有隱患。
此外，get的方法攜帶的數據一般放在url的后面，post方法攜帶的數據一般在http報文里面。因此，由於瀏覽器的限制，get攜帶的數據長度一般是有限制的，而post方法則無限制。
HTTP1.0、HTTP1.1和HTTP2.0的區別？
HTTP1.0與HTTP1.1區別：
HTTP1.0最早在網頁中使用是在1996年，那個時候只是使用一些較為簡單的網頁上和網絡請求上，而HTTP1.1則在1999年才開始廣泛應用於現在的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最為廣泛的HTTP協議。 主要區別主要體現在：
緩存處理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標准，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
帶寬優化及網絡連接的使用，HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，並且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和連接。
錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生沖突；410（Gone）表示服務器上的某個資源被永久性的刪除。
Host頭處理，在HTTP1.0中認為每台服務器都綁定一個唯一的IP地址，因此，請求消息中的URL並沒有傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一台物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），並且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。
長連接、持續連接，HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲，在HTTP1.1中默認開啟Connection： keep-alive，一定程度上彌補了HTTP1.0每次請求都要創建連接的缺點。
HTTP1.1與HTTP2.0的區別：
新的二進制格式（Binary Format），HTTP1.x的解析是基於文本。基於文本協議的格式解析存在天然缺陷，文本的表現形式有多樣性，要做到健壯性考慮的場景必然很多，二進制則不同，只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定采用二進制格式，實現方便且健壯。
多路復用（MultiPlexing），即連接共享，即每一個request都是是用作連接共享機制的。一個request對應一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據request的 id將request再歸屬到各自不同的服務端請求里面。
header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，而且每次都要重復發送，HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重復header的傳輸，又減小了需要傳輸的大小。
服務端推送（server push），同SPDY一樣，HTTP2.0也具有server push功能
HTTP的狀態碼以及代表的意思？
1XX——表示通知信息，如請求收到了或正在進行處理
2XX——表明請求被正常處理了
200 OK：請求已正常處理。
204 No Content：請求處理成功，但沒有任何資源可以返回給客戶端，一般在只需要從客戶端往服務器發送信息，而對客戶端不需要發送新信息內容的情況下使用。
206 Partial Content：是對資源某一部分的請求，該狀態碼表示客戶端進行了范圍請求，而服務器成功執行了這部分的GET請求。響應報文中包含由Content-Range指定范圍的實體內容。
3XX——表明瀏覽器需要執行某些特殊的處理以正確處理請求
301 Moved Permanently：資源的uri已更新，你也更新下你的書簽引用吧。永久性重定向，請求的資源已經被分配了新的URI，以后應使用資源現在所指的URI。
302 Found：資源的URI已臨時定位到其他位置了，姑且算你已經知道了這個情況了。臨時性重定向。和301相似，但302代表的資源不是永久性移動，只是臨時性性質的。換句話說，已移動的資源對應的URI將來還有可能發生改變。
303 See Other：資源的URI已更新，你是否能臨時按新的URI訪問。該狀態碼表示由於請求對應的資源存在着另一個URL，應使用GET方法定向獲取請求的資源。303狀態碼和302狀態碼有着相同的功能，但303狀態碼明確表示客戶端應當采用GET方法獲取資源，這點與302狀態碼有區別。當301,302,303響應狀態碼返回時，幾乎所有的瀏覽器都會把POST改成GET，並刪除請求報文內的主體，之后請求會自動再次發送。
304 Not Modified：資源已找到，但未符合條件請求。該狀態碼表示客戶端發送附帶條件的請求時（采用GET方法的請求報文中包含If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since中任一首部）服務端允許請求訪問資源，但因發生請求未滿足條件的情況后，直接返回304。
307 Temporary Redirect：臨時重定向。與302有相同的含義。
4XX——表明客戶端是發生錯誤的原因所在。
400 Bad Request：服務器端無法理解客戶端發送的請求，請求報文中可能存在語法錯誤。
401 Unauthorized：該狀態碼表示發送的請求需要有通過HTTP認證（BASIC認證，DIGEST認證）的認證信息。
403 Forbidden：不允許訪問那個資源。該狀態碼表明對請求資源的訪問被服務器拒絕了。（權限，未授權IP等）
404 Not Found：服務器上沒有請求的資源。路徑錯誤等。
5XX——服務器本身發生錯誤
500 Internal Server Error：貌似內部資源出故障了。該狀態碼表明服務器端在執行請求時發生了錯誤。也有可能是web應用存在bug或某些臨時故障。
503 Service Unavailable：抱歉，我現在正在忙着。該狀態碼表明服務器暫時處於超負載或正在停機維護，現在無法處理請求。
簡述HTTPS以及實現過程。（為什么要使用HTTPS、HTTPS基本概念、加密方式、實現過程）
為什么需要HTTPS（HTTP Secure 或者 HTTP over SSL）：
HTTP有很多安全漏洞：
通信使用明文（不加密），內容可能會被竊聽。
不驗證通信方的身份，因此有可能遭遇偽裝。
無法證明報文的完整性，所以有可能已遭篡改。
也就是說：HTTP+加密+認證+完整性保護=HTTPS
HTTPS是身披SSL外殼的HTTP：
HTTPS並非是應用層的一種新協議。只是通信接口部分用SSL和TLS協議代替而已。
通常情況下，HTTP直接和TCP通信。當使用SSL時，則演變成先和SSL通信，再由SSL和TCP通信。
加密方式：對稱加密與非對稱加密
對稱加密：加密和解密都是同一個密匙。
對稱加密速度快，適合Https加密算法，但是服務器和瀏覽器之間傳遞密鑰的過程被人監聽，相當明文傳輸。
非對稱加密：密鑰成對出現，分為公鑰和私鑰，公鑰加密需要私鑰解密，私鑰加密需要公鑰解密。
服務端只將公鑰暴露，瀏覽器使用公鑰對消息進行非對稱加密，服務端用私鑰解密。但是服務端向瀏覽器回復的時候，只能用私鑰進行加密，瀏覽器只能用公鑰解密。但是：公鑰是所有人都知道的，所有人都可以讀取服務端回復的消息來進行解密，所以解決不了服務端向瀏覽器傳遞消息。
HTTPS加密方式：混合加密方式，對稱加密與非對稱加密結合使用。
使用非對稱加密方式安全地交換在稍后的共享密鑰加密中要使用的密鑰。
確保交換的密鑰是安全的前提下，使用共享密鑰加密方式進行通信。
HTTPS工作流程：
步驟 1： 客戶端通過發送 Client Hello 報文開始 SSL 通信。報文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
步驟 2： 服務器可進行 SSL 通信時，會以 Server Hello 報文作為應答。和客戶端一樣，在報文中包含 SSL 版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。
步驟 3： 之后服務器發送 Certificate 報文。報文中包含公開密鑰證書。
步驟 4： 最后服務器發送 Server Hello Done 報文通知客戶端，最初階段的 SSL 握手協商部分結束。
步驟 5： SSL 第一次握手結束之后，客戶端以 Client Key Exchange 報文作為回應。報文中包含通信加密中使用的一種被稱為 Pre-master secret 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密。
步驟 6： 接着客戶端繼續發送 Change Cipher Spec 報文。該報文會提示服務器，在此報文之后的通信會采用 Pre-master secret 密鑰加密。
步驟 7： 客戶端發送 Finished 報文。該報文包含連接至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以服務器是否能夠正確解密該報文作為判定標准。
步驟 8： 服務器同樣發送 Change Cipher Spec 報文。
步驟 9： 服務器同樣發送 Finished 報文。
步驟 10： 服務器和客戶端的 Finished 報文交換完畢之后，SSL 連接
就算建立完成。當然，通信會受到 SSL 的保護。從此處開始進行應用層協議的通信，即發送 HTTP 請求。
步驟 11： 應用層協議通信，即發送 HTTP 響應。
步驟 12： 最后由客戶端斷開連接。斷開連接時，發送 close_notify 報文。上圖做了一些省略，這步之后再發送 TCP FIN 報文來關閉與 TCP 的通信。
簡述HTTPS與HTTP的區別？
HTTP：是互聯網上應用最為廣泛的一種網絡協議，是一個客戶端和服務器端請求和應答的標准（TCP），用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網絡傳輸減少。
HTTPS：是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。HTTPS協議的主要作用可以分為兩種：一種是建立一個信息安全通道，來保證數據傳輸的安全；另一種就是確認網站的真實性。
-
HTTPS協議需要到CA申請證書，一般免費證書很少，需要交費。
-
HTTP協議運行在TCP之上，所有傳輸的內容都是明文，HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，所有傳輸的內容都經過加密的。
-
HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
-
HTTPS可以有效的防止運營商劫持，解決了防劫持的一個大問題。
IP數據報格式？
IP數據報首部可以分為固定長度（20字節）和可選長度。固定長度是所有IP數據報所必須的。固定部分個字段的意義如下：
版本： 占4位，指IP協議的版本，通信雙方的協議版本必須一致。
首部長度： 占4位，可表示的最大十進制數是15（1111）。它的單位是4字節（也就是32位），因此首部長度最小值為5（固定長度部分），可選長度最長為40字節。
區分服務： 占8位，用來獲得更好的服務。
總長度： 占16位，首部和數據部分的總長度，單位為字節。因此IP數據報的最大長度為2^16-1。
標識： 占16位。當數據報的長度超過網絡的最大傳送單元使，就給該數據報的所有分片賦值相同的標識，相同的標識字段的值使分片后的各數據報片能正確的重裝成原來的數據報。
標志： 占3位，但是只有兩位具有意義。
標記字段中的最低位記為MF。MF=1表示后面還有分片，MF=0表示這是最后一個分片。
標志字段中間的一位記為DF，意思是能否分片，只有DF=0時才能分片。
片偏移： 占13位。片偏移指出：較長的分組在分片后，某片在原分組中的相對位置。也就是說，數據片相對於初始位置的距離。單位是8字節。因此，除去最后一個數據片，每個數據片的長度都是8字節的倍數。
生存時間： 占8位，TTL（Time To Live），單位為跳數，跳數表明該數據報至多能在互聯網中經過多少個路由器，每經過一個路由器就減1。
協議： 占8位，協議字段指出該數據報攜帶的數據是使用哪種協議，以便使目的主機的IP層知道應將數據部分上交給哪個協議進行處理。
協議名 ICMP IGMP IP TCP EGP IGP UDP IPv6 ESP OSPF 協議字段值 1 2 4 6 8 9 17 41 50 89 首部校驗和： 占16位，這個字段只檢驗數據報的首部，但是不包括數據部分。
在發送方，先把數據報划分為許多16位的字的序列，並把校驗和字段置為0，。
用反碼算術運算（從低位到高位計算，0+0等於0,0+1等於1,1+1等於0，但是要進1。）把所有的16位字相加后，將得到的反碼寫入校驗和字段。
接收方接收到數據報之后，將首部的所有16位字再使用反碼運算相加一次，將得到的和取反碼，即得出接收方的檢驗和的計算結果。如果結果全為0，則代表首部未發生變化，保留該數據報，反之則丟棄。
參考：原碼、補碼、反碼詳解
源地址： 占32位。
目的地址： 占32位。
UDP數據報格式？
UDP用戶數據報分為 = 首部字段 （8個字節，4個字段，每個字段2個字節）+ 數字字段。
首部字段：
-
源端口： 源端口號。在需要對方回信的時候選用，不需要填0。
-
目的端口： 目的端口號。必填。
-
長度： UDP用戶數據報的長度。最小為8。
-
檢驗和：檢測UDP用戶數據報傳輸過程中是否有錯。有錯就丟棄。
補充：UDP檢驗首部校驗和的方法：
在計算檢驗和時，需要在用戶數據報之前加12字節的偽首部。
所謂偽首部，是指他並不是UDP用戶數據報的真正首部，只是在計算檢驗和的時候，臨時加上的，檢驗和就是按照這個臨時的用戶數據報計算的。既不下傳也不向上提交。偽首部的格式如上圖。
UDP計算檢驗和與IP數據報類似，只是UDP的首部校驗和把首部和數據一起都檢驗了。步驟如下：
在發送方，首先先把全零放到檢驗和字段；
再把偽首部和UDP用戶數據報看成是由許多16位的字串連接起來的；
然后按二進制反碼計算出這些16位字的和，並將此和的反碼寫入檢驗和字段后，就發送這樣的用戶數據報。
在接收方，把收到的UDP用戶數據報連同偽首部（以及可能的填充全零字節）一起，按二進制反碼求這些16位字的和。
若無差錯時其結果應全為1；否則就是有差錯出現，可以選擇丟失，可以上傳（但是要附上錯誤信息）。
TCP報文段格式？
TCP雖然是面向字節流的，但是TCP傳輸的數據單元卻是報文段。一個報文段可以分為首部和數據兩部分。
TCP報文段的首部的前20個字節是固定的，后面的4n字節是需要增加的選項。因此TCP首部的最小長度是20字節。
首部部分字段的意義如下：
源端口和目的端口：各占2個字節，分別寫入源端口號和目的端口號。TCP的分用功能也是通過端口號實現的。
序號：占4字節。在TCP連接中傳送的字節流中的每一個字節都按照順序編號。首部中的序號字段值則代表本報文段所發送的數據的第一個字節的序號。
確認號：占4字節。代表期望收到對方下一個報文段的第一個數據字節的序號。需要注意：
若確認號=N，則表明：到序號N-1為止的所有數據都已正確收到數據偏移：占4位。他指出TCP報文段的數據起始處距離TCP報文段的起始處有多遠。一般情況下為20字節，但是首部中還有不確定的選項字段。它的單位是4字節，而它的最大值是15，因此數據偏移最大值為60字節，也就是說選項不能超過40字節。
保留：占6位。以防后續使用。
下面是6個控制位，每個占一位：
緊急URG：當URG=1時，表明緊急字段有效，它告訴系統此報文中有緊急數據，應該盡快傳送。
確認ACK：僅當ACK=1時確認號字段才有效。
推送PSH：當兩個應用進程進行交互式的通信時，有時一端的應用進程希望在鍵入一個命令后立即就能收到對方的相應，這時設置PSH=1。
復位RST：當RST=1時，表明TCP連接中出現嚴重錯誤，必須釋放連接，再重新建立運輸連接。RST=1還可以用來拒絕一個非法的報文段或拒絕打開一個連接。
同步SYN：在建立連接時用來同步序號。當SYN=1，ACK=0時代表是連接請求報文段。若對方同意建立連接，則應在相應報文段中使SYN=1，ACK=1。也就是說，SYN=1代表連接請求或者連接接受報文。
終止FIN。用於釋放一個連接。當FIN=1時，代表此報文段的發送方的數據已發送完畢，並且請求釋放運輸連接。
控制位到這結束。
窗口：占2字節。窗口值告訴對方：從本報文段中的確認號算起，接收方目前允許對方發送的數據量（以字節為單位）。之所以設置這個限制，是因為接收方的數據緩存空間是有限的。總之，窗口值作為接收方讓發送方設置其窗口大小的依據。
檢驗和：占2字節。檢驗的范圍包括首部字段和數據字段。和UDP檢驗的方法一樣，只不過把偽首部第四個字段的17改成6.
緊急指針：占2字節。只有在緊急URG=1時才有效，它指出本報文段中的緊急數據的字節數。
選項：長度可變，最大40字節
TCP最初只規定了一種選項，即最大報文長度MSS。MSS是每一個TCP報文段中的數據字段的最大長度，而並不是整個TCP報文段的長度。
以太網MAC幀格式？
以太網MAC幀較為簡單，由五個字段組成，前兩個字段分別為6字節長的目的地址和源地址。第三個字段是2字節的類型字段，用來標志上一層使用的是什么協議，以便把收到的MAC幀的數據上交給上一層的這個協議。第四個字段是數據字段，其長度為46~1500字節（46字節是因為最小長度64字節減去18字節的首部和尾部）。最后一個字段是4字節的幀檢測序列FCS（使用CRC檢測）。