幾道網絡面試題！看看你都會嗎？
- 應用層 ======
1.1 http 協議格式是什麼
- 請求報文格式：請求行、請求頭、空一行、請求體
請求行包括：請求方法、統一資源定位符（URL）、http 協議及版本
- 響應報文格式：狀態行、響應頭、空一行、響應體
狀態行包括：協議及版本、狀態碼、狀態碼解釋
1.2 http 和 https 的區別
http：由於 http 是明文傳輸，所以其安全性低，易受攻擊，無法確認對方的身份，也無法確保數據的完整性；http 協議默認端口號是 80 端口；它的優點是簡單快速，使用很靈活；http 服務器的程序規模小所以通信速度很快；與 https 相比，http 沒有額外的費用。
https：由於 https 使用 ssh 加密傳輸協議，信息是密文，所以它的安全性高，可以認證雙方的身份，防止信息被截取篡改；https 協議默認端口號是 443 端口；它會加重服務器負擔，需要資源來支撐，降低用戶的訪問速度。
1.3 http 常見狀態碼
1.4 cookie 和 session 的區別
1、數據存放位置不同：cookie 數據存放在客戶的瀏覽器上，session 數據放在服務器上。
2、安全程度不同：cookie 不是很安全，別人可以分析存放在本地的 cookie 並進行 cookie 欺騙, 考慮到安全應當使用 session。
3、性能使用程度不同：session 會在一定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能, 考慮到減輕服務器性能方面，應當使用 cookie。
4、數據存儲大小不同：單個 cookie 保存的數據不能超過 4K，很多瀏覽器都限制一個站點最多保存 20 個 cookie，而 session 則存儲與服務端，瀏覽器對其沒有限制。
5、會話機制不同：session 會話機制：session 會話機制是一種服務器端機制，它使用類似於哈希表（可能還有哈希表）的結構來保存信息。cookies 會話機制：cookie 是服務器存儲在本地計算機上的小塊文本，並隨每個請求發送到同一服務器。
1.5 get 和 post 的區別
他們本質都是 TCP 連接，並無區別，但是由於 http 的規定以及瀏覽器和服務器的限制，導致他們在應用過程中可能有所不同
1、get 方法的特點
①請求數據會附在 URL 之後（放在請求行中，以 ？分割 URL 和傳輸數據，多個參數用 & 連接）
②get 是會被瀏覽器主動緩存的，如果下一次傳輸的數據相同，那麼就會返回緩存中的內容，可以更快的展示數據
③get 方法的 UR 一般都有長度限制，但是需要注意的是 http 協議中並未規定 get 請求的長度。這個長度限制主要是由瀏覽器和 web 服務器決定的，並且各個瀏覽器對長度限制各不相同
④get 方法只產生一個 TCP 數據包，瀏覽器會把請求頭和請求數據一併發送出去，服務器響應 200 ok（返回數據）
2、post 方法的特點
①根據 http 規範，post 可能改變服務器上的資源的請求（點贊就是 post 請求），因爲有可能修改服務器上的資源，所以不符合安全性和冪等性
②因爲 post 方法是放在請求數據的，所以它的請求信息是沒有長度限制的
③post 方法會產生兩個 TCP 數據包，瀏覽器會先將請求頭髮送給服務器，待服務器返回 100 continue，瀏覽器再發送請求數據，服務器響應 200 ok（返回數據），這個看起來 get 比 post 快一些，但是實際上，在網絡狀況良好的情況下，他們的傳輸速度基本相同。
- 傳輸層 ======
2.1 講講三次握手
1、建立客戶端向服務端的連接：發送客戶端的請求連接數據包 SYN 到服務端
2、響應客戶端的連接並建立服務端的連接：服務端發送響應客戶端連接的數據包 ACK 和服務端的請求連接數據包 SYN 到客戶端
3、響應服務端的連接：客戶端發送響應服務端連接的數據包 ACK 到服務端
服務端新建套接字，綁定地址信息後開始監聽，進入 LISTEN 狀態。客戶端新建套接字綁定地址信息後調用 connect，發送連接請求 SYN，並進入 SYN_SENT 狀態，等待服務器的確認。服務端一旦監聽到連接請求，就會將連接放入內核等待隊列中，並向客戶端發送 SYN 和確認報文段 ACK，進入 SYN_RECD 狀態。客戶端收到 SYN+ACK 報文後向服務端發送確認報文段 ACK，並進入 ESTABLISHED 狀態，開始讀寫數據。服務端一旦收到客戶端的確認報文，就進入 ESTABLISHED 狀態，就可以進行讀寫數據了
2.1.1 爲什麼是三次握手，而不是兩次或四次
兩次不安全，四次沒必要
tcp 通信需要確保雙方都具有數據收發的能力，得到 ACK 響應則認爲對方具有數據收發的能力，因此雙方都要發送 SYN 確保對方具有通信的能力。第一次握手是客戶端發送 SYN，服務端接收，服務端得出客戶端的發送能力和服務端的接收能力都正常；第二次握手是服務端發送 SYN+ACK，客戶端接收，客戶端得出客戶端發送接收能力正常，服務端發送接收能力也都正常，但是此時服務器並不能確認客戶端的接收能力是否正常；第三次握手客戶端發送 ACK，服務器接收，服務端才能得出客戶端發送接收能力正常，服務端自己發送接收能力也都正常。
2.2 講講四次揮手
1、客戶端向服務端發送斷開連接請求 FIN
2、服務端響應客戶端的斷開連接請求，發送 ACK 響應包給客戶端
3、服務端向客戶端發送斷開連接請求 FIN
4、客戶端響應服務端的斷開連接請求，發送 ACK 響應給客戶端
客戶端主動調用 close 時，向服務端發送結束報文段 FIN 報，同時進入 FIN_WAIT1 狀態；服務器會收到結束報文段 FIN 報，服務器返回確認報文段 ACK 並進入 CLOSE_WAIT 狀態，此時如果服務端有數據要發送的話，客戶端依然需要接收。客戶端收到服務器對結束報文段的確認，就會進入到 FIN_WAIT2 狀態，開始等待服務器的結束報文段；服務器端數據發送完畢後，當服務器真正調用 close 關閉連接時，會向客戶端發送結束報文段 FIN 包，此時服務器進入 LAST_ACK 狀態，等待最後一個 ACK 的帶來；客戶端收到服務器發來的結束報文段, 進入 TIME_WAIT, 併發出送確認報文段 ACK；服務器收到了對結束報文段確認的 ACK，進入 CLOSED 狀態，斷開連接。而客戶端要等待 2MSL 的時間，纔會進入到 CLOSED 狀態
2.2.1 爲什麼握手是三次，而揮手需要四次呢
-
第二步屬於系統自動響應數據包
-
第三步是程序手動調用 close() 方法發送關閉連接的請求數據包
其實在 TCP 握手的時候，接收端將 SYN 包和 ACK 確認包合併到一個包中發送的，所以減少了一次包的發送。對於四次揮手，由於 TCP 是全雙工通信，主動關閉方發送 FIN 請求不代表完全斷開連接，只能表示主動關閉方不再發送數據了。而接收方可能還要發送數據，就不能立即關閉服務器端到客戶端的數據通道，所以就不能將服務端的 FIN 包和對客戶端的 ACK 包合併發送，只能先確認 ACK，等服務器無需發送數據時在發送 FIN 包，所以四次揮手時需要四次數據包的交互
2.2.2 一臺主機上出現大量的 TIME_WAIT 是什麼原因？應該如何處理？
TIME_WAIT 是主動關閉方出現的，一臺主機出現大量的 TIME_WAIT 證明這臺主機上發起大量的主動關閉連接。常見於一些爬蟲服務器。這時候我們應該調整 TIME_WAIT 的等待時間，或者開啓套接字地址重用選項
2.2.3 一臺主機上出現大量的 CLOSE_WAIT 是什麼原因？應該如何處理？
CLOSE_WAIT 是被動關閉方收到 FIN 請求進行回覆之後的狀態，等待上層程序進一步處理，若出現大量 CLOSE_WAIT，有可能是被動關閉方主機程序中忘了最後一步斷開連接後調用 close 釋放資源。這是一個 BUG，只需要加上對應的 close 即可解決問題
2.3 TCP 是如何保證可靠性的
可靠性和提高性能可參考此鏈接！！！
確認應答、超時重傳、連接管理、流量控制、擁塞控制
2.4 TCP 是如何提高性能的
滑動窗口、延遲應答、捎帶應答
2.5 TCP 和 UDP 的區別
TCP 是可靠，穩定的，TCP 的可靠體現在 TCP 在傳遞數據之前，會有三次握手來建立連接，而且在數據傳遞時，有確認應答、超時重傳、連接管理、流量管理、擁塞控制機制，在數據傳完後，還會四次揮手斷開連接用來節約系統資源。但是它相對 UDP 較慢，效率低，佔用系統資源高，而且在數據傳遞時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間，而且要在每臺設備上維護所有的傳輸連接，每個連接都會佔用系統的 CPU、內存等硬件資源。
UDP 沒有 TCP 的確認應答、超時重傳、連接管理、流量管理、擁塞控制等機制，是一個無狀態的傳輸協議，所以它在傳遞數據時非常快。但是 UDP 不可靠、不穩定，因爲 UDP 沒有 TCP 那些可靠的機制，在數據傳遞時，如果網絡質量不好，就會很容易丟包。
總的來說
TCP 是面向連接的，UDP 無連接
TCP 是可靠的，UDP 不可靠
TCP 只支持對點的通信；UDP 支持一對一，一對多，多對一，多對多通信
TCP 是面向字節流的；UDP 是面向數據報的
TCP 首部開銷大，20 個字節；UDP 只有 8 個字節
TCP 可以保證傳輸的順序，UDP 不可以保證
- 其他問題 =======
3.1 瀏覽器輸入 URL 後發生了什麼
1、首先，在瀏覽器地址欄中輸入 url，先解析 url，檢測 url 地址是否合法
2、瀏覽器先查看瀏覽器緩存——系統緩存——路由器緩存，如果緩存中有，直接在屏幕上顯示內容，如果沒有，到第三步
瀏覽器緩存：瀏覽器會記錄 DNS 一段時間，因此只有第一個地方解析 DNS 請求
操作系統緩存：如果在瀏覽器中不包含這個記錄，則會使用系統調用操作系統，獲取操作系統記錄（保存最近的 DNS 查詢緩存）
路由器緩存：如果上述兩個步驟均不能獲取 DNS 記錄，繼續搜索路由器緩存
3、在發送 http 請求前，需要域名解析（DNS 解析），獲取相應的 IP 地址
4、瀏覽器向服務器發起 TCP 連接，與瀏覽器建立三次握手
5、握手成功後，瀏覽器向服務器發送 http 請求，請求數據包
6、服務器處理收到的請求，將數據返回至瀏覽器
7、四次揮手釋放 TCP 連接
8、瀏覽器收到 http 響應
9、瀏覽器解析響應，如果響應可以緩存，則存入緩存
10、瀏覽器發送請求獲取嵌入在 HTML 的資源（對於未知類型，會彈出對話框）
11、瀏覽器發送異步請求
12、頁面渲染全部結束
3.2 電腦網絡不通如何解決
（1）排除接觸故障
查看網線是否連接正常。如果網絡連接圖標上顯示 “紅叉”，則說明網絡連接不正常。可檢查主機網卡口上的網線、交換器（路由器）上網線是否正常連接
（2）使用 ipconfig 查看計算機的上網參數
①單擊 “開始 | 所有程序 | 附件 | 命令提示符 “，打開命令提示符窗口
②輸入 ipconfig，按 Enter 確認，可以看到機器的配置信息，輸入 ipconfig/all, 可以看到 IP 地址和網卡物理地址等相關網絡詳細信息。
（3）使用 ping 命令測試網絡的連通性
在命令提示符窗口中輸入 "ping 127.0.0.1"，數據顯示本機分別發送和接受了 4 個數據包，丟包率爲零，可以判斷本機網絡協議工作正常，如顯示” 請求超時 “，則表明本機網卡的安裝或 TCP/IP 協議有問題，接下來就應該檢查網卡和 TCP/IP 協議，可以通過重新安裝該協議來解決。安裝方法：右擊 “本地連接”——屬性——安裝——協議，選擇 TCP/IP 協議確定安裝。
（4）ping 本機 IP
如果 ping 127.0.0.1 正常，則可以 “ping 本機 IP” 來判斷本機的網卡是否正常工作。如不能 ping 通，說明本機的網卡驅動程序不正確，或者網卡與網線之間連接有故障，也有可能是本地的路由表面收到了破壞，此時應檢查本機網卡的狀態是否爲已連接，網絡參數是否設置正確，如果正確可是不能 ping 通，就應該重新安裝網卡驅動程序。丟失率爲零，可以判斷網卡安裝配置沒有問題，工作正常。
（5）ping 網關 IP
網關地址能被 ping 通的話，表明本機網絡連接已經正常，如果命令不成功，可能是網關設備自身存在問題，也可能是本機上網參數設置有誤，檢查網絡參數。如果 ping 網關 IP 正常，可網頁卻無法打開，同時 QQ 可以正確登錄。則一般是 DNS 填寫不正確，請聯繫運行商詢問 DNS 地址，也可詢問鄰居他們是怎麼設置的，一個地區的同一運行商所用的 DNS 都是一樣的。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/q5MKaHr5PI164ZffJOpqCw