三天吃透計算機網路八股文-有解無憂

網路分層結構

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

五層模型：應用層、傳輸層、網路層、資料鏈路層、物理層，

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

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

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地址

為什么是四次揮手？

因為當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和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拆分成多個包進行發送，也有可能把多個小的包封裝成一個大的資料包發送，這就是所謂的TCP粘包和拆包問題，

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

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

解決方案：

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

說說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="https://www.cnblogs.com/tyson03/archive/2023/04/16/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，作業程序如下：

ping通知系統，新建一個固定格式的ICMP請求資料包
ICMP協議，將該資料包和目標機器B的IP地址打包，一起轉交給IP協議層
IP層協議將本機IP地址為源地址，機器B的IP地址為目標地址，加上一些其他的控制資訊，構建一個IP資料包
先獲取目標機器B的MAC地址，
資料鏈路層構建一個資料幀，目的地址是IP層傳過來的MAC地址，源地址是本機的MAC地址
機器B收到后，對比目標地址，和自己本機的MAC地址是否一致，符合就處理回傳，不符合就丟棄，
根據目的主機回傳的ICMP回送回答報文中的時間戳，從而計算出往返時間
最終顯示結果有這幾項：發送到目的主機的IP地址、發送 & 收到 & 丟失的分組數、往返時間的最小、最大& 平均值

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/550241.html

標籤：其他

上一篇：Rust編程語言入門之智能指標

下一篇：c/c++快樂演算法第三天