電腦網路面試八股文_ZenDei技術網路在線

## 網路分層結構電腦網路體系大致分為三種，OSI七層模型、TCP/IP四層模型和五層模型。一般面試的時候考察比較多的是五層模型。最全面的Java面試網站：[最全面的Java面試網站](https://topjavaer.cn) ![](http://img.topjavaer.cn/img/t ...

網路分層結構

電腦網路體系大致分為三種，OSI七層模型、TCP/IP四層模型和五層模型。一般面試的時候考察比較多的是五層模型。最全面的Java面試網站：最全面的Java面試網站

五層模型：應用層、傳輸層、網路層、數據鏈路層、物理層。

應用層：為應用程式提供交互服務。在互聯網中的應用層協議很多，如功能變數名稱系統DNS、HTTP協議、SMTP協議等。
傳輸層：負責向兩台主機進程之間的通信提供數據傳輸服務。傳輸層的協議主要有傳輸控制協議TCP和用戶數據協議UDP。
網路層：選擇合適的路由和交換結點，確保數據及時傳送。主要包括IP協議。
數據鏈路層：在兩個相鄰節點之間傳送數據時，數據鏈路層將網路層交下來的 IP 數據報組裝成幀，在兩個相鄰節點間的鏈路上傳送幀。
物理層：實現相鄰節點間比特流的透明傳輸，儘可能屏蔽傳輸介質和物理設備的差異。

本文已經收錄到Github倉庫，該倉庫包含電腦基礎、Java基礎、多線程、JVM、資料庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分散式、微服務、設計模式、架構、校招社招分享等核心知識點，歡迎star~

Github地址：Github地址

如果訪問不了Github，可以訪問gitee地址。

鏈接：gitee地址

ISO七層模型是國際標準化組織（International Organization for Standardization）制定的一個用於電腦或通信系統間互聯的標準體系。

應用層：網路服務與最終用戶的一個介面，常見的協議有：HTTP FTP SMTP SNMP DNS.
表示層：數據的表示、安全、壓縮。，確保一個系統的應用層所發送的信息可以被另一個系統的應用層讀取。
會話層：建立、管理、終止會話,對應主機進程，指本地主機與遠程主機正在進行的會話.
傳輸層：定義傳輸數據的協議埠號，以及流控和差錯校驗,協議有TCP UDP.
網路層：進行邏輯地址定址，實現不同網路之間的路徑選擇,協議有ICMP IGMP IP等.
數據鏈路層：在物理層提供比特流服務的基礎上，建立相鄰結點之間的數據鏈路。
物理層：建立、維護、斷開物理連接。

TCP/IP 四層模型

應用層：對應於OSI參考模型的（應用層、表示層、會話層）。
傳輸層: 對應OSI的傳輸層，為應用層實體提供端到端的通信功能，保證了數據包的順序傳送及數據的完整性。
網際層：對應於OSI參考模型的網路層，主要解決主機到主機的通信問題。
網路介面層：與OSI參考模型的數據鏈路層、物理層對應。

三次握手

假設發送端為客戶端，接收端為服務端。開始時客戶端和服務端的狀態都是CLOSED。

第一次握手：客戶端向服務端發起建立連接請求，客戶端會隨機生成一個起始序列號x，客戶端向服務端發送的欄位中包含標誌位SYN=1，序列號seq=x。第一次握手前客戶端的狀態為CLOSE，第一次握手後客戶端的狀態為SYN-SENT。此時服務端的狀態為LISTEN。
第二次握手：服務端在收到客戶端發來的報文後，會隨機生成一個服務端的起始序列號y，然後給客戶端回覆一段報文，其中包括標誌位SYN=1，ACK=1，序列號seq=y，確認號ack=x+1。第二次握手前服務端的狀態為LISTEN，第二次握手後服務端的狀態為SYN-RCVD，此時客戶端的狀態為SYN-SENT。（其中SYN=1表示要和客戶端建立一個連接，ACK=1表示確認序號有效）
第三次握手：客戶端收到服務端發來的報文後，會再向服務端發送報文，其中包含標誌位ACK=1，序列號seq=x+1，確認號ack=y+1。第三次握手前客戶端的狀態為SYN-SENT，第三次握手後客戶端和服務端的狀態都為ESTABLISHED。此時連接建立完成。

兩次握手可以嗎？

之所以需要第三次握手，主要為了防止已失效的連接請求報文段突然又傳輸到了服務端，導致產生問題。

比如客戶端A發出連接請求，可能因為網路阻塞原因，A沒有收到確認報文，於是A再重傳一次連接請求。
然後連接成功，等待數據傳輸完畢後，就釋放了連接。
然後A發出的第一個連接請求等到連接釋放以後的某個時間才到達服務端B，此時B誤認為A又發出一次新的連接請求，於是就向A發出確認報文段。
如果不採用三次握手，只要B發出確認，就建立新的連接了，此時A不會響應B的確認且不發送數據，則B一直等待A發送數據，浪費資源。

四次揮手

A的應用進程先向其TCP發出連接釋放報文段（FIN=1，seq=u），並停止再發送數據，主動關閉TCP連接，進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。
B收到連接釋放報文段後即發出確認報文段（ACK=1，ack=u+1，seq=v），B進入CLOSE-WAIT（關閉等待）狀態，此時的TCP處於半關閉狀態，A到B的連接釋放。
A收到B的確認後，進入FIN-WAIT-2（終止等待2）狀態，等待B發出的連接釋放報文段。
B發送完數據，就會發出連接釋放報文段（FIN=1，ACK=1，seq=w，ack=u+1），B進入LAST-ACK（最後確認）狀態，等待A的確認。
A收到B的連接釋放報文段後，對此發出確認報文段（ACK=1，seq=u+1，ack=w+1），A進入TIME-WAIT（時間等待）狀態。此時TCP未釋放掉，需要經過時間等待計時器設置的時間2MSL（最大報文段生存時間）後，A才進入CLOSED狀態。B收到A發出的確認報文段後關閉連接，若沒收到A發出的確認報文段，B就會重傳連接釋放報文段。

第四次揮手為什麼要等待2MSL？

保證A發送的最後一個ACK報文段能夠到達B。這個ACK報文段有可能丟失，B收不到這個確認報文，就會超時重傳連接釋放報文段，然後A可以在2MSL時間內收到這個重傳的連接釋放報文段，接著A重傳一次確認，重新啟動2MSL計時器，最後A和B都進入到CLOSED狀態，若A在TIME-WAIT狀態不等待一段時間，而是發送完ACK報文段後立即釋放連接，則無法收到B重傳的連接釋放報文段，所以不會再發送一次確認報文段，B就無法正常進入到CLOSED狀態。
防止已失效的連接請求報文段出現在本連接中。A在發送完最後一個ACK報文段後，再經過2MSL，就可以使這個連接所產生的所有報文段都從網路中消失，使下一個新的連接中不會出現舊的連接請求報文段。

給大家分享一個Github倉庫，上面有大彬整理的300多本經典的電腦書籍PDF，包括C語言、C++、Java、Python、前端、資料庫、操作系統、電腦網路、數據結構和演算法、機器學習、編程人生等，可以star一下，下次找書直接在上面搜索，倉庫持續更新中~

Github地址

如果訪問不了Github，可以訪問碼雲地址。

碼雲地址

為什麼是四次揮手？

因為當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。但是在關閉連接時，當Server端收到Client端發出的連接釋放報文時，很可能並不會立即關閉SOCKET，所以Server端先回覆一個ACK報文，告訴Client端我收到你的連接釋放報文了。只有等到Server端所有的報文都發送完了，這時Server端才能發送連接釋放報文，之後兩邊才會真正的斷開連接。故需要四次揮手。

說說TCP報文首部有哪些欄位，其作用又分別是什麼？

16位埠號：源埠號，主機該報文段是來自哪裡；目標埠號，要傳給哪個上層協議或應用程式
32位序號：一次TCP通信（從TCP連接建立到斷開）過程中某一個傳輸方向上的位元組流的每個位元組的編號。
32位確認號：用作對另一方發送的tcp報文段的響應。其值是收到的TCP報文段的序號值加1。
4位頭部長度：表示tcp頭部有多少個32bit字（4位元組）。因為4位最大能標識15，所以TCP頭部最長是60位元組。
6位標誌位：URG(緊急指針是否有效)，ACk（表示確認號是否有效），PSH（緩衝區尚未填滿），RST（表示要求對方重新建立連接），SYN（建立連接消息標誌接），FIN（表示告知對方本端要關閉連接了）
16位視窗大小：是TCP流量控制的一個手段。這裡說的視窗，指的是接收通告視窗。它告訴對方本端的TCP接收緩衝區還能容納多少位元組的數據，這樣對方就可以控制發送數據的速度。
16位校驗和：由發送端填充，接收端對TCP報文段執行CRC演算法以檢驗TCP報文段在傳輸過程中是否損壞。註意，這個校驗不僅包括TCP頭部，也包括數據部分。這也是TCP可靠傳輸的一個重要保障。
16位緊急指針：一個正的偏移量。它和序號欄位的值相加表示最後一個緊急數據的下一位元組的序號。因此，確切地說，這個欄位是緊急指針相對當前序號的偏移，不妨稱之為緊急偏移。TCP的緊急指針是發送端向接收端發送緊急數據的方法。

TCP有哪些特點？

TCP是面向連接的運輸層協議。
點對點，每一條TCP連接只能有兩個端點。
TCP提供可靠交付的服務。
TCP提供全雙工通信。
面向位元組流。

TCP的粘包和拆包

TCP是面向流，沒有界限的一串數據。TCP底層並不瞭解上層業務數據的具體含義，它會根據TCP緩衝區的實際情況進行包的劃分，所以在業務上認為，一個完整的包可能會被TCP拆分成多個包進行發送，也有可能把多個小的包封裝成一個大的數據包發送，這就是所謂的TCP粘包和拆包問題。

為什麼會產生粘包和拆包呢?

要發送的數據小於TCP發送緩衝區的大小，TCP將多次寫入緩衝區的數據一次發送出去，將會發生粘包；
接收數據端的應用層沒有及時讀取接收緩衝區中的數據，將發生粘包；
要發送的數據大於TCP發送緩衝區剩餘空間大小，將會發生拆包；
待發送數據大於MSS（最大報文長度），TCP在傳輸前將進行拆包。即TCP報文長度-TCP頭部長度>MSS。

解決方案：

發送端將每個數據包封裝為固定長度
在數據尾部增加特殊字元進行分割
將數據分為兩部分，一部分是頭部，一部分是內容體；其中頭部結構大小固定，且有一個欄位聲明內容體的大小。

TCP和UDP的區別？

TCP面向連接；UDP是無連接的，即發送數據之前不需要建立連接。
TCP提供可靠的服務；UDP不保證可靠交付。
TCP面向位元組流，把數據看成一連串無結構的位元組流；UDP是面向報文的。
TCP有擁塞控制；UDP沒有擁塞控制，因此網路出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如實時視頻會議等）。
每一條TCP連接只能是點到點的；UDP支持一對一、一對多、多對一和多對多的通信方式。
TCP首部開銷20位元組；UDP的首部開銷小，只有8個位元組。

TCP 和 UDP 分別對應的常見應用層協議有哪些？

基於TCP的應用層協議有：HTTP、FTP、SMTP、TELNET、SSH

HTTP：HyperText Transfer Protocol（超文本傳輸協議），預設埠80
FTP: File Transfer Protocol (文件傳輸協議), 預設埠(20用於傳輸數據，21用於傳輸控制信息)
SMTP: Simple Mail Transfer Protocol (簡單郵件傳輸協議) ,預設埠25
TELNET: Teletype over the Network (網路電傳), 預設埠23
SSH：Secure Shell（安全外殼協議），預設埠 22

基於UDP的應用層協議：DNS、TFTP、SNMP

DNS : Domain Name Service (功能變數名稱服務),預設埠 53
TFTP: Trivial File Transfer Protocol (簡單文件傳輸協議)，預設埠69
SNMP：Simple Network Management Protocol（簡單網路管理協議），通過UDP埠161接收，只有Trap信息採用UDP埠162。

說說TCP是如何確保可靠性的呢？

首先，TCP的連接是基於三次握手，而斷開則是基於四次揮手。確保連接和斷開的可靠性。
其次，TCP的可靠性，還體現在有狀態;TCP會記錄哪些數據發送了，哪些數據被接收了，哪些沒有被接受，並且保證數據包按序到達，保證數據傳輸不出差錯。
再次，TCP的可靠性，還體現在可控制。它有數據包校驗、ACK應答、超時重傳(發送方)、失序數據重傳（接收方）、丟棄重覆數據、流量控制（滑動視窗）和擁塞控制等機制。

說下TCP的滑動視窗機制

TCP 利用滑動視窗實現流量控制。流量控制是為了控制發送方發送速率，保證接收方來得及接收。 TCP會話的雙方都各自維護一個發送視窗和一個接收視窗。接收視窗大小取決於應用、系統、硬體的限制。發送視窗則取決於對端通告的接收視窗。接收方發送的確認報文中的window欄位可以用來控制發送方視窗大小，從而影響發送方的發送速率。將接收方的確認報文window欄位設置為 0，則發送方不能發送數據。

TCP頭包含window欄位，16bit位，它代表的是視窗的位元組容量，最大為65535。這個欄位是接收端告訴發送端自己還有多少緩衝區可以接收數據。於是發送端就可以根據這個接收端的處理能力來發送數據，而不會導致接收端處理不過來。接收視窗的大小是約等於發送視窗的大小。

詳細講一下擁塞控制？

防止過多的數據註入到網路中。幾種擁塞控制方法：慢開始( slow-start )、擁塞避免( congestion avoidance )、快重傳( fast retransmit )和快恢復( fast recovery )。

慢開始

把擁塞視窗 cwnd 設置為一個最大報文段MSS的數值。而在每收到一個對新的報文段的確認後，把擁塞視窗增加至多一個MSS的數值。每經過一個傳輸輪次，擁塞視窗 cwnd 就加倍。為了防止擁塞視窗cwnd增長過大引起網路擁塞，還需要設置一個慢開始門限ssthresh狀態變數。

當 cwnd < ssthresh 時，使用慢開始演算法。

當 cwnd > ssthresh 時，停止使用慢開始演算法而改用擁塞避免演算法。

當 cwnd = ssthresh 時，既可使用慢開始演算法，也可使用擁塞控制避免演算法。

擁塞避免

讓擁塞視窗cwnd緩慢地增大，每經過一個往返時間RTT就把發送方的擁塞視窗cwnd加1，而不是加倍。這樣擁塞視窗cwnd按線性規律緩慢增長。

無論在慢開始階段還是在擁塞避免階段，只要發送方判斷網路出現擁塞（其根據就是沒有收到確認），就要把慢開始門限ssthresh設置為出現擁塞時的發送方視窗值的一半（但不能小於2）。然後把擁塞視窗cwnd重新設置為1，執行慢開始演算法。這樣做的目的就是要迅速減少主機發送到網路中的分組數，使得發生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。

快重傳

有時個別報文段會在網路中丟失，但實際上網路並未發生擁塞。如果發送方遲遲收不到確認，就會產生超時，就會誤認為網路發生了擁塞。這就導致發送方錯誤地啟動慢開始，把擁塞視窗cwnd又設置為1，因而降低了傳輸效率。

快重傳演算法可以避免這個問題。快重傳演算法首先要求接收方每收到一個失序的報文段後就立即發出重覆確認，使發送方及早知道有報文段沒有到達對方。

發送方只要一連收到三個重覆確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待重傳計時器到期。由於發送方儘早重傳未被確認的報文段，因此採用快重傳後可以使整個網路吞吐量提高約20%。

快恢復

當發送方連續收到三個重覆確認，就會把慢開始門限ssthresh減半，接著把cwnd值設置為慢開始門限ssthresh減半後的數值，然後開始執行擁塞避免演算法，使擁塞視窗緩慢地線性增大。

在採用快恢復演算法時，慢開始演算法只是在TCP連接建立時和網路出現超時時才使用。採用這樣的擁塞控制方法使得TCP的性能有明顯的改進。

HTTP協議的特點？

HTTP允許傳輸任意類型的數據。傳輸的類型由Content-Type加以標記。
無狀態。對於客戶端每次發送的請求，伺服器都認為是一個新的請求，上一次會話和下一次會話之間沒有聯繫。
支持客戶端/伺服器模式。

HTTP報文格式

HTTP請求由請求行、請求頭部、空行和請求體四個部分組成。

請求行：包括請求方法，訪問的資源URL，使用的HTTP版本。GET和POST是最常見的HTTP方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。
請求頭：格式為“屬性名:屬性值”，服務端根據請求頭獲取客戶端的信息，主要有cookie、host、connection、accept-language、accept-encoding、user-agent。
請求體：用戶的請求數據如用戶名，密碼等。

請求報文示例：

POST /xxx HTTP/1.1 請求行
Accept:image/gif.image/jpeg, 請求頭部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=dabin 請求體

HTTP響應也由四個部分組成，分別是：狀態行、響應頭、空行和響應體。

狀態行：協議版本，狀態碼及狀態描述。
響應頭：響應頭欄位主要有connection、content-type、content-encoding、content-length、set-cookie、Last-Modified，、Cache-Control、Expires。
響應體：伺服器返回給客戶端的內容。

響應報文示例：

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
    <body>響應體</body>
</html>

HTTP狀態碼有哪些？

HTTP 狀態碼是伺服器端返回給客戶端的響應狀態碼，根據狀態碼我們就能知道伺服器端想要給客戶端表達的具體含義，比如 200 就表示請求訪問成功，500 就表示伺服器端程式出錯等。HTTP 狀態碼可分為 5 大類：

1XX：消息狀態碼。
2XX：成功狀態碼。
3XX：重定向狀態碼。
4XX：客戶端錯誤狀態碼。
5XX：服務端錯誤狀態碼。

這 5 大類中又包含了很多具體的狀態碼。

1XX為消息狀態碼，其中：

100：Continue 繼續。客戶端應繼續其請求。
101：Switching Protocols 切換協議。伺服器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到 HTTP 的新版本協議。

2XX為成功狀態碼，其中：

200：OK 請求成功。一般用於 GET 與 POST 請求。
201：Created 已創建。成功請求並創建了新的資源。
202：Accepted 已接受。已經接受請求，但未處理完成。
203：Non-Authoritative Information 非授權信息。請求成功。但返回的 meta 信息不在原始的伺服器，而是一個副本。
204：No Content 無內容。伺服器成功處理，但未返回內容。在未更新網頁的情況下，可確保瀏覽器繼續顯示當前文檔。
205：Reset Content 重置內容。伺服器處理成功，用戶終端（例如：瀏覽器）應重置文檔視圖。可通過此返回碼清除瀏覽器的表單域。
206：Partial Content 部分內容。伺服器成功處理了部分 GET 請求。

3XX為重定向狀態碼，其中：

300：Multiple Choices 多種選擇。請求的資源可包括多個位置，相應可返回一個資源特征與地址的列表用於用戶終端（例如：瀏覽器）選擇。
301：Moved Permanently 永久移動。請求的資源已被永久的移動到新 URI，返回信息會包括新的 URI，瀏覽器會自動定向到新 URI。今後任何新的請求都應使用新的 URI 代替。
302：Found 臨時移動，與 301 類似。但資源只是臨時被移動。客戶端應繼續使用原有URI。
303：See Other 查看其它地址。與 301 類似。使用 GET 和 POST 請求查看。
304：Not Modified 未修改。所請求的資源未修改，伺服器返回此狀態碼時，不會返回任何資源。客戶端通常會緩存訪問過的資源，通過提供一個頭信息指出客戶端希望只返回在指定日期之後修改的資源。
305：Use Proxy 使用代理。所請求的資源必須通過代理訪問。
306：Unused 已經被廢棄的 HTTP 狀態碼。
307：Temporary Redirect 臨時重定向。與 302 類似。使用 GET 請求重定向。

4XX為客戶端錯誤狀態碼，其中：

400：Bad Request 客戶端請求的語法錯誤，伺服器無法理解。
401：Unauthorized 請求要求用戶的身份認證。
402：Payment Required 保留，將來使用。
403：Forbidden 伺服器理解請求客戶端的請求，但是拒絕執行此請求。
404：Not Found 伺服器無法根據客戶端的請求找到資源（網頁）。通過此代碼，網站設計人員可設置"您所請求的資源無法找到"的個性頁面。
405：Method Not Allowed 客戶端請求中的方法被禁止。
406：Not Acceptable 伺服器無法根據客戶端請求的內容特性完成請求。
407：Proxy Authentication Required 請求要求代理的身份認證，與 401 類似，但請求者應當使用代理進行授權。
408：Request Time-out 伺服器等待客戶端發送的請求時間過長，超時。
409：Conflict 伺服器完成客戶端的 PUT 請求時可能返回此代碼，伺服器處理請求時發生了衝突。
410：Gone 客戶端請求的資源已經不存在。410 不同於 404，如果資源以前有現在被永久刪除了可使用 410 代碼，網站設計人員可通過 301 代碼指定資源的新位置。
411：Length Required 伺服器無法處理客戶端發送的不帶 Content-Length 的請求信息。
412：Precondition Failed 客戶端請求信息的先決條件錯誤。
413：Request Entity Too Large 由於請求的實體過大，伺服器無法處理，因此拒絕請求。為防止客戶端的連續請求，伺服器可能會關閉連接。如果只是伺服器暫時無法處理，則會包含一個 Retry-After 的響應信息。
414：Request-URI Too Large 請求的 URI 過長（URI通常為網址），伺服器無法處理。
415：Unsupported Media Type 伺服器無法處理請求附帶的媒體格式。
416：Requested range not satisfiable 客戶端請求的範圍無效。
417：Expectation Failed 伺服器無法滿足 Expect 的請求頭信息。

5XX為服務端錯誤狀態碼，其中：

500：Internal Server Error 伺服器內部錯誤，無法完成請求。
501：Not Implemented 伺服器不支持請求的功能，無法完成請求。
502：Bad Gateway 作為網關或者代理工作的伺服器嘗試執行請求時，從遠程伺服器接收到了一個無效的響應。
503：Service Unavailable 由於超載或系統維護，伺服器暫時的無法處理客戶端的請求。延時的長度可包含在伺服器的Retry-After頭信息中。
504：Gateway Time-out 充當網關或代理的伺服器，未及時從遠端伺服器獲取請求。
505：HTTP Version not supported 伺服器不支持請求的HTTP協議的版本，無法完成處理。

總結一下：

HTTP 狀態碼分為 5 大類：1XX：表示消息狀態碼；2XX：表示成功狀態碼；3XX：表示重定向狀態碼；4XX：表示客戶端錯誤狀態碼；5XX：表示服務端錯誤狀態碼。其中常見的具體狀態碼有：200：請求成功；301：永久重定向；302：臨時重定向；404：無法找到此頁面；405：請求的方法類型不支持；500：伺服器內部出錯。

HTTP 協議包括哪些請求？

HTTP協議中共定義了八種方法來表示對Request-URI指定的資源的不同操作方式，具體如下：

GET：向特定的資源發出請求。
POST：向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的創建和/或已有資源的修改。
OPTIONS：返回伺服器針對特定資源所支持的HTTP請求方法。也可以利用向Web伺服器發送'*'的請求來測試伺服器的功能性。
HEAD：向伺服器索要與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以在不必傳輸整個響應內容的情況下，就可以獲取包含在響應消息頭中的元信息。
PUT：向指定資源位置上傳其最新內容。
DELETE：請求伺服器刪除Request-URI所標識的資源。
TRACE：回顯伺服器收到的請求，主要用於測試或診斷。
CONNECT：HTTP/1.1協議中預留給能夠將連接改為管道方式的代理伺服器。

HTTP狀態碼301和302的區別？

301：（永久性轉移）請求的網頁已被永久移動到新位置。伺服器返回此響應時，會自動將請求者轉到新位置。
302：（暫時性轉移）伺服器目前正從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以後的請求。此代碼與響應GET和HEAD請求的301代碼類似，會自動將請求者轉到不同的位置。

舉個形象的例子：當一個網站或者網頁24—48小時內臨時移動到一個新的位置，這時候就要進行302跳轉，打個比方說，我有一套房子，但是最近走親戚去親戚家住了，過兩天我還回來的。而使用301跳轉的場景就是之前的網站因為某種原因需要移除掉，然後要到新的地址訪問，是永久性的，就比如你的那套房子其實是租的，現在租期到了，你又在另一個地方找到了房子，之前租的房子不住了。

POST和GET的區別？

GET 和 POST 最本質的區別是規範上的區別，在規範中，定義 GET 請求是用來獲取資源的，也就是進行查詢操作的，而 POST 請求是用來傳輸實體對象的，因此會使用 POST 來進行添加、修改和刪除等操作。
GET請求參數通過URL傳遞，POST的參數放在請求體中。
GET 請求可以直接進行回退和刷新，不會對用戶和程式產生任何影響；而 POST 請求如果直接回滾和刷新將會把數據再次提交。
GET產生一個TCP數據包；POST產生兩個TCP數據包。對於GET方式的請求，瀏覽器會把請求頭和請求體一併發送出去；而對於POST，瀏覽器先發送請求頭，伺服器響應100 continue，瀏覽器再發送請求體。
GET 請求一般會被緩存，比如常見的 CSS、JS、HTML 請求等都會被緩存；而 POST 請求預設是不進行緩存的。
GET請求參數會被完整保留在瀏覽器歷史記錄里，而POST中的參數不會被保留。

URI和URL的區別

URI，全稱是Uniform Resource Identifier)，中文翻譯是統一資源標誌符，主要作用是唯一標識一個資源。
URL，全稱是Uniform Resource Location)，中文翻譯是統一資源定位符，主要作用是提供資源的路徑。打個經典比喻吧，URI像是身份證，可以唯一標識一個人，而URL更像一個住址，可以通過URL找到這個人。

如何理解HTTP協議是無狀態的

當瀏覽器第一次發送請求給伺服器時，伺服器響應了；如果同個瀏覽器發起第二次請求給伺服器時，它還是會響應，但是呢，伺服器不知道你就是剛纔的那個瀏覽器。簡言之，伺服器不會去記住你是誰，所以是無狀態協議。

HTTP長連接和短連接？

HTTP短連接：瀏覽器和伺服器每進行一次HTTP操作，就建立一次連接，任務結束就中斷連接。HTTP1.0預設使用的是短連接。

HTTP長連接：指的是復用TCP連接。多個HTTP請求可以復用同一個TCP連接，這就節省了TCP連接建立和斷開的消耗。

HTTP/1.1起，預設使用長連接。要使用長連接，客戶端和伺服器的HTTP首部的Connection都要設置為keep-alive，才能支持長連接。

HTTP 如何實現長連接？

HTTP分為長連接和短連接，本質上說的是TCP的長短連接。TCP連接是一個雙向的通道，它是可以保持一段時間不關閉的，因此TCP連接才具有真正的長連接和短連接這一說法哈。

TCP長連接可以復用一個TCP連接，來發起多次的HTTP請求，這樣就可以減少資源消耗，比如一次請求HTML，如果是短連接的話，可能還需要請求後續的JS/CSS。

如何設置長連接？

通過在頭部（請求和響應頭）設置Connection欄位指定為keep-alive，HTTP/1.0協議支持，但是是預設關閉的，從HTTP/1.1以後，連接預設都是長連接。

HTTP長連接在什麼時候會超時？

HTTP一般會有httpd守護進程，裡面可以設置keep-alive timeout，當tcp連接閑置超過這個時間就會關閉，也可以在HTTP的header裡面設置超時時間。

TCP 的keep-alive包含三個參數，支持在系統內核的net.ipv4裡面設置；當 TCP 連接之後，閑置了tcp_keepalive_time，則會發生偵測包，如果沒有收到對方的ACK，那麼會每隔 tcp_keepalive_intvl再發一次，直到發送了tcp_keepalive_probes，就會丟棄該連接。

HTTP1.1和 HTTP2.0的區別？

HTTP2.0相比HTTP1.1支持的特性：

新的二進位格式：HTTP1.1 基於文本格式傳輸數據；HTTP2.0採用二進位格式傳輸數據，解析更高效。
多路復用：在一個連接里，允許同時發送多個請求或響應，並且這些請求或響應能夠並行的傳輸而不被阻塞，避免 HTTP1.1 出現的”隊頭堵塞”問題。
頭部壓縮，HTTP1.1的header帶有大量信息，而且每次都要重覆發送；HTTP2.0 把header從數據中分離，並封裝成頭幀和數據幀，使用特定演算法壓縮頭幀，有效減少頭信息大小。並且HTTP2.0在客戶端和伺服器端記錄了之前發送的鍵值對，對於相同的數據，不會重覆發送。比如請求a發送了所有的頭信息欄位，請求b則只需要發送差異數據，這樣可以減少冗餘數據，降低開銷。
服務端推送：HTTP2.0允許伺服器向客戶端推送資源，無需客戶端發送請求到伺服器獲取。

HTTPS與HTTP的區別？

HTTP是超文本傳輸協議，信息是明文傳輸；HTTPS則是具有安全性的ssl加密傳輸協議。
HTTP和HTTPS用的埠不一樣，HTTP埠是80，HTTPS是443。
HTTPS協議需要到CA機構申請證書，一般需要一定的費用。
HTTP運行在TCP協議之上；HTTPS運行在SSL協議之上，SSL運行在TCP協議之上。

什麼是數字證書？

服務端可以向證書頒發機構CA申請證書，以避免中間人攻擊（防止證書被篡改）。證書包含三部分內容：證書內容、證書簽名演算法和簽名，簽名是為了驗證身份。

服務端把證書傳輸給瀏覽器，瀏覽器從證書里取公鑰。證書可以證明該公鑰對應本網站。

數字簽名的製作過程：

CA使用證書簽名演算法對證書內容進行hash運算。
對hash後的值用CA的私鑰加密，得到數字簽名。

瀏覽器驗證過程：

獲取證書，得到證書內容、證書簽名演算法和數字簽名。
用CA機構的公鑰對數字簽名解密（由於是瀏覽器信任的機構，所以瀏覽器會保存它的公鑰）。
用證書里的簽名演算法對證書內容進行hash運算。
比較解密後的數字簽名和對證書內容做hash運算後得到的哈希值，相等則表明證書可信。

HTTPS原理

首先是TCP三次握手，然後客戶端發起一個HTTPS連接建立請求，客戶端先發一個Client Hello的包，然後服務端響應Server Hello，接著再給客戶端發送它的證書，然後雙方經過密鑰交換，最後使用交換的密鑰加解密數據。

協商加密演算法 。在Client Hello裡面客戶端會告知服務端自己當前的一些信息，包括客戶端要使用的TLS版本，支持的加密演算法，要訪問的功能變數名稱，給服務端生成的一個隨機數（Nonce）等。需要提前告知伺服器想要訪問的功能變數名稱以便伺服器發送相應的功能變數名稱的證書過來。
服務端響應Server Hello，告訴客戶端服務端選中的加密演算法。
接著服務端給客戶端發來了2個證書。第二個證書是第一個證書的簽發機構（CA）的證書。
客戶端使用證書的認證機構CA公開發佈的RSA公鑰對該證書進行驗證，下圖表明證書認證成功。
驗證通過之後，瀏覽器和伺服器通過密鑰交換演算法產生共用的對稱密鑰。
開始傳輸數據，使用同一個對稱密鑰來加解密。

DNS 的解析過程？

瀏覽器搜索自己的DNS緩存
若沒有，則搜索操作系統中的DNS緩存和hosts文件
若沒有，則操作系統將功能變數名稱發送至本地功能變數名稱伺服器，本地功能變數名稱伺服器查詢自己的DNS緩存，查找成功則返回結果，否則依次向根功能變數名稱伺服器、頂級功能變數名稱伺服器、許可權功能變數名稱伺服器發起查詢請求，最終返回IP地址給本地功能變數名稱伺服器
本地功能變數名稱伺服器將得到的IP地址返回給操作系統，同時自己也將IP地址緩存起來
操作系統將 IP 地址返回給瀏覽器，同時自己也將IP地址緩存起來
瀏覽器得到功能變數名稱對應的IP地址

瀏覽器中輸入URL返回頁面過程？

解析功能變數名稱，找到主機 IP。
瀏覽器利用 IP 直接與網站主機通信，三次握手，建立 TCP 連接。瀏覽器會以一個隨機埠向服務端的 web 程式 80 埠發起 TCP 的連接。
建立 TCP 連接後，瀏覽器向主機發起一個HTTP請求。
參數從客戶端傳遞到伺服器端。
伺服器端得到客戶端參數之後，進行相應的業務處理，再將結果封裝成 HTTP 包，返回給客戶端。
伺服器端和客戶端的交互完成，斷開 TCP 連接（4 次揮手）。
瀏覽器解析響應內容，進行渲染，呈現給用戶。

DNS 功能變數名稱解析的過程

在網路中定位是依靠 IP 進行身份定位的，所以 URL 訪問的第一步便是先要得到伺服器端的 IP 地址。而得到伺服器的 IP 地址需要使用 DNS（Domain Name System，功能變數名稱系統）功能變數名稱解析，DNS 功能變數名稱解析就是通過 URL 找到與之相對應的 IP 地址。

DNS 功能變數名稱解析的大致流程如下：

先檢查瀏覽器中的 DNS 緩存，如果瀏覽器中有對應的記錄會直接使用，並完成解析；
如果瀏覽器沒有緩存，那就去查詢操作系統的緩存，如果查詢到記錄就可以直接返回 IP 地址，完成解析；
如果操作系統沒有 DNS 緩存，就會去查看本地 host 文件，Windows 操作系統下，host 文件一般位於 "C:\Windows\System32\drivers\etc\hosts"，如果 host 文件有記錄則直接使用；
如果本地 host 文件沒有相應的記錄，會請求本地 DNS 伺服器，本地 DNS 伺服器一般是由本地網路服務商如移動、聯通等提供。通常情況下可通過 DHCP 自動分配，當然也可以自己手動配置。目前用的比較多的是谷歌提供的公用 DNS 是 8.8.8.8 和國內的公用 DNS 是 114.114.114.114。
如果本地 DNS 伺服器沒有相應的記錄，就會去根功能變數名稱伺服器查詢了。為了能更高效完成全球所有功能變數名稱的解析請求，根功能變數名稱伺服器本身並不會直接去解析功能變數名稱，而是會把不同的解析請求分配給下麵的其他伺服器去完成。

圖片來源於網路

什麼是cookie和session？

由於HTTP協議是無狀態的協議，需要用某種機制來識具體的用戶身份，用來跟蹤用戶的整個會話。常用的會話跟蹤技術是cookie與session。

cookie就是由伺服器發給客戶端的特殊信息，而這些信息以文本文件的方式存放在客戶端，然後客戶端每次向伺服器發送請求的時候都會帶上這些特殊的信息。說得更具體一些：當用戶使用瀏覽器訪問一個支持cookie的網站的時候，用戶會提供包括用戶名在內的個人信息並且提交至伺服器；接著，伺服器在向客戶端回傳相應的超文本的同時也會發回這些個人信息，當然這些信息並不是存放在HTTP響應體中的，而是存放於HTTP響應頭；當客戶端瀏覽器接收到來自伺服器的響應之後，瀏覽器會將這些信息存放在一個統一的位置。自此，客戶端再向伺服器發送請求的時候，都會把相應的cookie存放在HTTP請求頭再次發回至伺服器。伺服器在接收到來自客戶端瀏覽器的請求之後，就能夠通過分析存放於請求頭的cookie得到客戶端特有的信息，從而動態生成與該客戶端相對應的內容。網站的登錄界面中“請記住我”這樣的選項，就是通過cookie實現的。

cookie工作流程：

servlet創建cookie，保存少量數據，發送給瀏覽器。
瀏覽器獲得伺服器發送的cookie數據，將自動的保存到瀏覽器端。
下次訪問時，瀏覽器將自動攜帶cookie數據發送給伺服器。

session原理：首先瀏覽器請求伺服器訪問web站點時，伺服器首先會檢查這個客戶端請求是否已經包含了一個session標識、稱為SESSIONID，如果已經包含了一個sessionid則說明以前已經為此客戶端創建過session，伺服器就按照sessionid把這個session檢索出來使用，如果客戶端請求不包含session id，則伺服器為此客戶端創建一個session，並且生成一個與此session相關聯的獨一無二的sessionid存放到cookie中，這個sessionid將在本次響應中返回到客戶端保存，這樣在交互的過程中，瀏覽器端每次請求時，都會帶著這個sessionid，伺服器根據這個sessionid就可以找得到對應的session。以此來達到共用數據的目的。這裡需要註意的是，session不會隨著瀏覽器的關閉而死亡，而是等待超時時間。

cookie和session的區別？

作用範圍不同，Cookie 保存在客戶端，Session 保存在伺服器端。
有效期不同，Cookie 可設置為長時間保持，比如我們經常使用的預設登錄功能，Session 一般失效時間較短，客戶端關閉或者 Session 超時都會失效。
隱私策略不同，Cookie 存儲在客戶端，容易被竊取；Session 存儲在服務端，安全性相對 Cookie 要好一些。
存儲大小不同，單個 Cookie 保存的數據不能超過 4K；對於 Session 來說存儲沒有上限，但出於對伺服器的性能考慮，Session 內不要存放過多的數據，並且需要設置 Session 刪除機制。

什麼是對稱加密和非對稱加密？

對稱加密：通信雙方使用相同的密鑰進行加密。特點是加密速度快，但是缺點是密鑰泄露會導緻密文數據被破解。常見的對稱加密有AES和DES演算法。

非對稱加密：它需要生成兩個密鑰，公鑰和私鑰。公鑰是公開的，任何人都可以獲得，而私鑰是私人保管的。公鑰負責加密，私鑰負責解密；或者私鑰負責加密，公鑰負責解密。這種加密演算法安全性更高，但是計算量相比對稱加密大很多，加密和解密都很慢。常見的非對稱演算法有RSA和DSA。

說說 WebSocket與socket的區別

Socket是一套標準，它完成了對TCP/IP的高度封裝，屏蔽網路細節，以方便開發者更好地進行網路編程。Socket其實就是等於IP地址 + 埠 + 協議。

WebSocket是一個持久化的協議，它是伴隨H5而出的協議，用來解決http不支持持久化連接的問題。

Socket一個是網編編程的標準介面，而WebSocket則是應用層通信協議。

ARP協議的工作過程？

ARP解決了同一個區域網上的主機和路由器IP和MAC地址的解析。

每台主機都會在自己的ARP緩衝區中建立一個ARP列表，以表示IP地址和MAC地址的對應關係。
當源主機需要將一個數據包要發送到目的主機時，會首先檢查自己 ARP列表中是否存在該 IP地址對應的MAC地址，如果有，就直接將數據包發送到這個MAC地址；如果沒有，就向本地網段發起一個ARP請求的廣播包，查詢此目的主機對應的MAC地址。此ARP請求數據包里包括源主機的IP地址、硬體地址、以及目的主機的IP地址。
網路中所有的主機收到這個ARP請求後，會檢查數據包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此數據包；如果相同，該主機首先將發送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已經存在該IP的信息，則將其覆蓋，然後給源主機發送一個 ARP響應數據包，告訴對方自己是它需要查找的MAC地址。
源主機收到這個ARP響應數據包後，將得到的目的主機的IP地址和MAC地址添加到自己的ARP列表中，並利用此信息開始數據的傳輸。
如果源主機一直沒有收到ARP響應數據包，表示ARP查詢失敗。

ICMP協議的功能

ICMP,Internet Control Message Protocol ,Internet控制消息協議。

ICMP協議是一種面向無連接的協議，用於傳輸出錯報告控制信息。
它是一個非常重要的協議，它對於網路安全具有極其重要的意義。它屬於網路層協議，主要用於在主機與路由器之間傳遞控制信息，包括報告錯誤、交換受限控制和狀態信息等。
當遇到IP數據無法訪問目標、IP路由器無法按當前的傳輸速率轉發數據包等情況時，會自動發送ICMP消息。

比如我們日常使用得比較多的ping，就是基於ICMP的。

什麼是DoS、DDoS、DRDoS攻擊？

DOS: (Denial of Service),翻譯過來就是拒絕服務,一切能引起DOS行為的攻擊都被稱為DOS攻擊。最常見的DoS攻擊就有電腦網路寬頻攻擊、連通性攻擊。
DDoS: (Distributed Denial of Service),翻譯過來是分散式拒絕服務。是指處於不同位置的多個攻擊者同時向一個或幾個目標發動攻擊，或者一個攻擊者控制了位於不同位置的多台機器並利用這些機器對受害者同時實施攻擊。常見的DDos有SYN Flood、Ping of Death、ACK Flood、UDP Flood等。
DRDoS: (Distributed Reflection Denial of Service)，中文是分散式反射拒絕服務，該方式靠的是發送大量帶有被害者IP地址的數據包給攻擊主機，然後攻擊主機對IP地址源做出大量回應，從而形成拒絕服務攻擊。

什麼是CSRF攻擊，如何避免

CSRF，跨站請求偽造（英文全稱是Cross-site request forgery），是一種挾制用戶在當前已登錄的Web應用程式上執行非本意的操作的攻擊方法。

怎麼解決CSRF攻擊呢？

檢查Referer欄位。
添加校驗token。

什麼是XSS攻擊？

XSS，跨站腳本攻擊（Cross-Site Scripting）。它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web裡面的html代碼會被執行，從而達到惡意攻擊用戶的特殊目的。XSS攻擊一般分三種類型：存儲型、反射型、DOM型XSS

如何解決XSS攻擊問題？

對輸入進行過濾，過濾標簽等，只允許合法值。
HTML轉義
對於鏈接跳轉，如<a href="xxx" 等，要校驗內容，禁止以script開頭的非法鏈接。
限制輸入長度

防盜鏈

盜鏈是指服務提供商自己不提供服務的內容，通過技術手段（可以理解成爬蟲）去獲取其他網站的資源展示在自己的網站上。常見的盜鏈有以下幾種：圖片盜鏈、音頻盜鏈、視頻盜鏈等。

網站盜鏈會大量消耗被盜鏈網站的帶寬，而真正的點擊率也許會很小，嚴重損害了被盜鏈網站的利益。

被盜網站就自然會防盜鏈，可以通過經常更換圖片名，也可以通過檢測referer。因為正常用戶訪問一張圖片一定是從自己的網站點擊鏈接進去的，如果一個請求的referer是其他網站，就說明這是一個爬蟲。

什麼是 Referer？

這裡的 Referer 指的是 HTTP 頭部的一個欄位，也稱為 HTTP 來源地址（HTTP Referer），用來表示從哪兒鏈接到目前的網頁，採用的格式是 URL。換句話說，藉著 HTTP Referer 頭部網頁可以檢查訪客從哪裡而來，這也常被用來對付偽造的跨網站請求。

盜鏈網站會針對性進行反盜鏈，可以通過在請求的headers中設置referer來繞過防盜鏈，我們現在使用爬蟲抓取別人的網站也是這樣。

什麼是空 Referer，什麼時候會出現空 Referer？

首先，我們對空 Referer 的定義為，Referer 頭部的內容為空，或者，一個 HTTP 請求中根本不包含 Referer 頭部。

那麼什麼時候 HTTP 請求會不包含 Referer 欄位呢？根據 Referer 的定義，它的作用是指示一個請求是從哪裡鏈接過來，那麼當一個請求並不是由鏈接觸發產生的，那麼自然也就不需要指定這個請求的鏈接來源。

比如，直接在瀏覽器的地址欄中輸入一個資源的 URL 地址，那麼這種請求是不會包含 Referer 欄位的，因為這是一個 “憑空產生” 的 HTTP 請求，並不是從一個地方鏈接過去的。

說下ping的原理

ping，Packet Internet Groper，是一種網際網路包探索器，用於測試網路連接量的程式。Ping是工作在TCP/IP網路體繫結構中應用層的一個服務命令，主要是向特定的目的主機發送ICMP（Internet Control Message Protocol 網際網路報文控制協議）請求報文，測試目的站是否可達及瞭解其有關狀態。

一般來說，ping可以用來檢測網路通不通。它是基於ICMP協議工作的。假設機器A ping機器B，工作過程如下：