計算機網絡高頻面試八股文

網絡分層結構
三次握手
兩次握手可以嗎？
四次揮手
第四次揮手為什么要等待2MSL？
為什么是四次揮手？
TCP有哪些特點？
說說TCP報文首部有哪些字段，其作用又分別是什么？
TCP和UDP的區別？
TCP 和 UDP 分別對應的常見應用層協議有哪些？
TCP的粘包和拆包
說說TCP是如何確保可靠性的呢？
說下TCP的滑動窗口機制
詳細講一下擁塞控制？
HTTP協議的特點？
HTTP報文格式
HTTP狀態碼有哪些？
HTTP 協議包括哪些請求？
HTTP狀態碼301和302的區別？
URI和URL的區別
POST和GET的區別？
如何理解HTTP協議是無狀態的
HTTP長連接和短連接？
HTTP 如何實現長連接？
HTTP長連接在什么時候會超時？
HTTP1.1和 HTTP2.0的區別？
HTTPS與HTTP的區別？
什么是數字證書？
HTTPS原理
DNS 的解析過程？
瀏覽器中輸入URL返回頁面過程？
什么是cookie和session？
cookie和session的區別？
什么是對稱加密和非對稱加密？
說說 WebSocket與socket的區別
ARP協議的工作過程？
ICMP協議的功能
什么是DoS、DDoS、DRDoS攻擊？
什么是CSRF攻擊，如何避免
什么是XSS攻擊？
如何解決XSS攻擊問題？
防盜鏈
說下ping的原理

網絡分層結構

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

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

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

分享一份大彬精心整理的大廠面試手冊，包含計算機基礎、Java基礎、多線程、JVM、數據庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服務、設計模式、架構、校招社招分享等高頻面試題，非常實用，有小伙伴靠著這份手冊拿過字節offer~

需要的小伙伴可以自行下載：

http://mp.weixin.qq.com/s?__biz=Mzg2OTY1NzY0MQ==&mid=2247485445&idx=1&sn=1c6e224b9bb3da457f5ee03894493dbc&chksm=ce98f543f9ef7c55325e3bf336607a370935a6c78dbb68cf86e59f5d68f4c51d175365a189f8#rd

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,deflateusername=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公鑰對該證書進行驗證，下圖表明證書認證成功。
驗證通過之后，瀏覽器和服務器通過密鑰交換算法產生共享的對稱密鑰。
開始傳輸數據，使用同一個對稱密鑰來加解密。

瀏覽器中輸入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，工作過程如下：

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

最后給大家分享200多本計算機經典書籍PDF電子書，包括C語言、C++、Java、Python、前端、數據庫、操作系統、計算機網絡、數據結構和算法、機器學習、編程人生等，感興趣的小伙伴可以自取：

https://mp.weixin.qq.com/s?__biz=Mzg2OTY1NzY0MQ==&mid=2247486208&idx=1&sn=dbeedf47c50b1be67b2ef31a901b8b56&chksm=ce98f646f9ef7f506a1f7d72fc9384ba1b518072b44d157f657a8d5495a1c78c3e5de0b41efd&token=1652861108&lang=zh_CN#rd