網(wǎng)絡(luò)分層結(jié)構(gòu)

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

五層模型：應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、物理層。

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

本文已經(jīng)收錄到Github倉庫，該倉庫包含計算機基礎(chǔ)、Java基礎(chǔ)、多線程、JVM、數(shù)據(jù)庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服務(wù)、設(shè)計模式、架構(gòu)、校招社招分享等核心知識點，歡迎star~

Github地址

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

gitee地址

ISO七層模型是國際標準化組織（International Organization for Standardization）制定的一個用于計算機或通信系統(tǒng)間互聯(lián)的標準體系。

• 應(yīng)用層：網(wǎng)絡(luò)服務(wù)與最終用戶的一個接口，常見的協(xié)議有：HTTP FTP SMTP SNMP DNS.
• 表示層：數(shù)據(jù)的表示、安全、壓縮。，確保一個系統(tǒng)的應(yīng)用層所發(fā)送的信息可以被另一個系統(tǒng)的應(yīng)用層讀取。
• 會話層：建立、管理、終止會話,對應(yīng)主機進程，指本地主機與遠程主機正在進行的會話.
• 傳輸層：定義傳輸數(shù)據(jù)的協(xié)議端口號，以及流控和差錯校驗,協(xié)議有TCP UDP.
• 網(wǎng)絡(luò)層：進行邏輯地址尋址，實現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇,協(xié)議有ICMP IGMP IP等.
• 數(shù)據(jù)鏈路層：在物理層提供比特流服務(wù)的基礎(chǔ)上，建立相鄰結(jié)點之間的數(shù)據(jù)鏈路。
• 物理層：建立、維護、斷開物理連接。

TCP/IP 四層模型

• 應(yīng)用層：對應(yīng)于OSI參考模型的（應(yīng)用層、表示層、會話層）。
• 傳輸層: 對應(yīng)OSI的傳輸層，為應(yīng)用層實體提供端到端的通信功能，保證了數(shù)據(jù)包的順序傳送及數(shù)據(jù)的完整性。
• 網(wǎng)際層：對應(yīng)于OSI參考模型的網(wǎng)絡(luò)層，主要解決主機到主機的通信問題。
• 網(wǎng)絡(luò)接口層：與OSI參考模型的數(shù)據(jù)鏈路層、物理層對應(yīng)。

三次握手

假設(shè)發(fā)送端為客戶端，接收端為服務(wù)端。開始時客戶端和服務(wù)端的狀態(tài)都是CLOSED。

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

兩次握手可以嗎？

之所以需要第三次握手，主要為了防止已失效的連接請求報文段突然又傳輸?shù)搅朔?wù)端，導(dǎo)致產(chǎn)生問題。

• 比如客戶端A發(fā)出連接請求，可能因為網(wǎng)絡(luò)阻塞原因，A沒有收到確認報文，于是A再重傳一次連接請求。
• 然后連接成功，等待數(shù)據(jù)傳輸完畢后，就釋放了連接。
• 然后A發(fā)出的第一個連接請求等到連接釋放以后的某個時間才到達服務(wù)端B，此時B誤認為A又發(fā)出一次新的連接請求，于是就向A發(fā)出確認報文段。
• 如果不采用三次握手，只要B發(fā)出確認，就建立新的連接了，此時A不會響應(yīng)B的確認且不發(fā)送數(shù)據(jù)，則B一直等待A發(fā)送數(shù)據(jù)，浪費資源。

四次揮手

1. A的應(yīng)用進程先向其TCP發(fā)出連接釋放報文段（FIN=1，seq=u），并停止再發(fā)送數(shù)據(jù)，主動關(guān)閉TCP連接，進入FIN-WAIT-1（終止等待1）狀態(tài)，等待B的確認。
2. B收到連接釋放報文段后即發(fā)出確認報文段（ACK=1，ack=u+1，seq=v），B進入CLOSE-WAIT（關(guān)閉等待）狀態(tài)，此時的TCP處于半關(guān)閉狀態(tài)，A到B的連接釋放。
3. A收到B的確認后，進入FIN-WAIT-2（終止等待2）狀態(tài)，等待B發(fā)出的連接釋放報文段。
4. B發(fā)送完數(shù)據(jù)，就會發(fā)出連接釋放報文段（FIN=1，ACK=1，seq=w，ack=u+1），B進入LAST-ACK（最后確認）狀態(tài)，等待A的確認。
5. A收到B的連接釋放報文段后，對此發(fā)出確認報文段（ACK=1，seq=u+1，ack=w+1），A進入TIME-WAIT（時間等待）狀態(tài)。此時TCP未釋放掉，需要經(jīng)過時間等待計時器設(shè)置的時間2MSL（最大報文段生存時間）后，A才進入CLOSED狀態(tài)。B收到A發(fā)出的確認報文段后關(guān)閉連接，若沒收到A發(fā)出的確認報文段，B就會重傳連接釋放報文段。

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

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

最后給大家分享一個Github倉庫，上面有大彬整理的300多本經(jīng)典的計算機書籍PDF，包括C語言、C++、Java、Python、前端、數(shù)據(jù)庫、操作系統(tǒng)、計算機網(wǎng)絡(luò)、數(shù)據(jù)結(jié)構(gòu)和算法、機器學習、編程人生等，可以star一下，下次找書直接在上面搜索，倉庫持續(xù)更新中~

Github地址

為什么是四次揮手？

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

說說TCP報文首部有哪些字段，其作用又分別是什么？

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

TCP有哪些特點？

• TCP是面向連接的運輸層協(xié)議。
• 點對點，每一條TCP連接只能有兩個端點。
• TCP提供可靠交付的服務(wù)。
• TCP提供全雙工通信。
• 面向字節(jié)流。

TCP和UDP的區(qū)別？

1. TCP面向連接；UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。
2. TCP提供可靠的服務(wù)；UDP不保證可靠交付。
3. TCP面向字節(jié)流，把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流；UDP是面向報文的。
4. TCP有擁塞控制；UDP沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機的發(fā)送速率降低（對實時應(yīng)用很有用，如實時視頻會議等）。
5. 每一條TCP連接只能是點到點的；UDP支持一對一、一對多、多對一和多對多的通信方式。
6. TCP首部開銷20字節(jié)；UDP的首部開銷小，只有8個字節(jié)。

TCP 和 UDP 分別對應(yīng)的常見應(yīng)用層協(xié)議有哪些？

基于TCP的應(yīng)用層協(xié)議有：HTTP、FTP、SMTP、TELNET、SSH

• HTTP：HyperText Transfer Protocol（超文本傳輸協(xié)議），默認端口80
• FTP: File Transfer Protocol (文件傳輸協(xié)議), 默認端口(20用于傳輸數(shù)據(jù)，21用于傳輸控制信息)
• SMTP: Simple Mail Transfer Protocol (簡單郵件傳輸協(xié)議) ,默認端口25
• TELNET: Teletype over the Network (網(wǎng)絡(luò)電傳), 默認端口23
• SSH：Secure Shell（安全外殼協(xié)議），默認端口 22

基于UDP的應(yīng)用層協(xié)議：DNS、TFTP、SNMP

• DNS : Domain Name Service (域名服務(wù)),默認端口 53
• TFTP: Trivial File Transfer Protocol (簡單文件傳輸協(xié)議)，默認端口69
• SNMP：Simple Network Management Protocol（簡單網(wǎng)絡(luò)管理協(xié)議），通過UDP端口161接收，只有Trap信息采用UDP端口162。

TCP的粘包和拆包

TCP是面向流，沒有界限的一串數(shù)據(jù)。TCP底層并不了解上層業(yè)務(wù)數(shù)據(jù)的具體含義，它會根據(jù)TCP緩沖區(qū)的實際情況進行包的劃分，所以在業(yè)務(wù)上認為，一個完整的包可能會被TCP拆分成多個包進行發(fā)送，也有可能把多個小的包封裝成一個大的數(shù)據(jù)包發(fā)送，這就是所謂的TCP粘包和拆包問題。

為什么會產(chǎn)生粘包和拆包呢?

• 要發(fā)送的數(shù)據(jù)小于TCP發(fā)送緩沖區(qū)的大小，TCP將多次寫入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去，將會發(fā)生粘包；
• 接收數(shù)據(jù)端的應(yīng)用層沒有及時讀取接收緩沖區(qū)中的數(shù)據(jù)，將發(fā)生粘包；
• 要發(fā)送的數(shù)據(jù)大于TCP發(fā)送緩沖區(qū)剩余空間大小，將會發(fā)生拆包；
• 待發(fā)送數(shù)據(jù)大于MSS（最大報文長度），TCP在傳輸前將進行拆包。即TCP報文長度-TCP頭部長度>MSS。

解決方案：

• 發(fā)送端將每個數(shù)據(jù)包封裝為固定長度
• 在數(shù)據(jù)尾部增加特殊字符進行分割
• 將數(shù)據(jù)分為兩部分，一部分是頭部，一部分是內(nèi)容體；其中頭部結(jié)構(gòu)大小固定，且有一個字段聲明內(nèi)容體的大小。

說說TCP是如何確?？煽啃缘哪?？

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

說下TCP的滑動窗口機制

TCP 利用滑動窗口實現(xiàn)流量控制。流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來得及接收。 TCP會話的雙方都各自維護一個發(fā)送窗口和一個接收窗口。接收窗口大小取決于應(yīng)用、系統(tǒng)、硬件的限制。發(fā)送窗口則取決于對端通告的接收窗口。接收方發(fā)送的確認報文中的window字段可以用來控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。將接收方的確認報文window字段設(shè)置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。

TCP頭包含window字段，16bit位，它代表的是窗口的字節(jié)容量，最大為65535。這個字段是接收端告訴發(fā)送端自己還有多少緩沖區(qū)可以接收數(shù)據(jù)。于是發(fā)送端就可以根據(jù)這個接收端的處理能力來發(fā)送數(shù)據(jù)，而不會導(dǎo)致接收端處理不過來。接收窗口的大小是約等于發(fā)送窗口的大小。

詳細講一下?lián)砣刂疲?/h2>

防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中。 幾種擁塞控制方法：慢開始( slow-start )、擁塞避免( congestion avoidance )、快重傳( fast retransmit )和快恢復(fù)( fast recovery )。

慢開始

把擁塞窗口 cwnd 設(shè)置為一個最大報文段MSS的數(shù)值。而在每收到一個對新的報文段的確認后，把擁塞窗口增加至多一個MSS的數(shù)值。每經(jīng)過一個傳輸輪次，擁塞窗口 cwnd 就加倍。 為了防止擁塞窗口cwnd增長過大引起網(wǎng)絡(luò)擁塞，還需要設(shè)置一個慢開始門限ssthresh狀態(tài)變量。

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

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

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

擁塞避免

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

無論在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（其根據(jù)就是沒有收到確認），就要把慢開始門限ssthresh設(shè)置為出現(xiàn)擁塞時的發(fā)送 方窗口值的一半（但不能小于2）。然后把擁塞窗口cwnd重新設(shè)置為1，執(zhí)行慢開始算法。這樣做的目的就是要迅速減少主機發(fā)送到網(wǎng)絡(luò)中的分組數(shù)，使得發(fā)生 擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。

快重傳

有時個別報文段會在網(wǎng)絡(luò)中丟失，但實際上網(wǎng)絡(luò)并未發(fā)生擁塞。如果發(fā)送方遲遲收不到確認，就會產(chǎn)生超時，就會誤認為網(wǎng)絡(luò)發(fā)生了擁塞。這就導(dǎo)致發(fā)送方錯誤地啟動慢開始，把擁塞窗口cwnd又設(shè)置為1，因而降低了傳輸效率。

快重傳算法可以避免這個問題?？熘貍魉惴ㄊ紫纫蠼邮辗矫渴盏揭粋€失序的報文段后就立即發(fā)出重復(fù)確認，使發(fā)送方及早知道有報文段沒有到達對方。

發(fā)送方只要一連收到三個重復(fù)確認就應(yīng)當立即重傳對方尚未收到的報文段，而不必繼續(xù)等待重傳計時器到期。由于發(fā)送方盡早重傳未被確認的報文段，因此采用快重傳后可以使整個網(wǎng)絡(luò)吞吐量提高約20%。

快恢復(fù)

當發(fā)送方連續(xù)收到三個重復(fù)確認，就會把慢開始門限ssthresh減半，接著把cwnd值設(shè)置為慢開始門限ssthresh減半后的數(shù)值，然后開始執(zhí)行擁塞避免算法，使擁塞窗口緩慢地線性增大。

在采用快恢復(fù)算法時，慢開始算法只是在TCP連接建立時和網(wǎng)絡(luò)出現(xiàn)超時時才使用。 采用這樣的擁塞控制方法使得TCP的性能有明顯的改進。

HTTP協(xié)議的特點？

1. HTTP允許傳輸任意類型的數(shù)據(jù)。傳輸?shù)念愋陀蒀ontent-Type加以標記。
2. 無狀態(tài)。對于客戶端每次發(fā)送的請求，服務(wù)器都認為是一個新的請求，上一次會話和下一次會話之間沒有聯(lián)系。
3. 支持客戶端/服務(wù)器模式。

HTTP報文格式

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

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

請求報文示例：

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響應(yīng)也由四個部分組成，分別是：狀態(tài)行、響應(yīng)頭、空行和響應(yīng)體。

• 狀態(tài)行：協(xié)議版本，狀態(tài)碼及狀態(tài)描述。
• 響應(yīng)頭：響應(yīng)頭字段主要有connection、content-type、content-encoding、content-length、set-cookie、Last-Modified，、Cache-Control、Expires。
• 響應(yīng)體：服務(wù)器返回給客戶端的內(nèi)容。

響應(yīng)報文示例：

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

<html>
    <body>響應(yīng)體</body>
</html>

HTTP狀態(tài)碼有哪些？

HTTP 狀態(tài)碼是服務(wù)器端返回給客戶端的響應(yīng)狀態(tài)碼，根據(jù)狀態(tài)碼我們就能知道服務(wù)器端想要給客戶端表達的具體含義，比如 200 就表示請求訪問成功，500 就表示服務(wù)器端程序出錯等。HTTP 狀態(tài)碼可分為 5 大類：

1. 1XX：消息狀態(tài)碼。
2. 2XX：成功狀態(tài)碼。
3. 3XX：重定向狀態(tài)碼。
4. 4XX：客戶端錯誤狀態(tài)碼。
5. 5XX：服務(wù)端錯誤狀態(tài)碼。

這 5 大類中又包含了很多具體的狀態(tài)碼。

1XX為消息狀態(tài)碼，其中：

• 100：Continue 繼續(xù)?？蛻舳藨?yīng)繼續(xù)其請求。
• 101：Switching Protocols 切換協(xié)議。服務(wù)器根據(jù)客戶端的請求切換協(xié)議。只能切換到更高級的協(xié)議，例如，切換到 HTTP 的新版本協(xié)議。

2XX為成功狀態(tài)碼，其中：

• 200：OK 請求成功。一般用于 GET 與 POST 請求。
• 201：Created 已創(chuàng)建。成功請求并創(chuàng)建了新的資源。
• 202：Accepted 已接受。已經(jīng)接受請求，但未處理完成。
• 203：Non-Authoritative Information 非授權(quán)信息。請求成功。但返回的 meta 信息不在原始的服務(wù)器，而是一個副本。
• 204：No Content 無內(nèi)容。服務(wù)器成功處理，但未返回內(nèi)容。在未更新網(wǎng)頁的情況下，可確保瀏覽器繼續(xù)顯示當前文檔。
• 205：Reset Content 重置內(nèi)容。服務(wù)器處理成功，用戶終端（例如：瀏覽器）應(yīng)重置文檔視圖?？赏ㄟ^此返回碼清除瀏覽器的表單域。
• 206：Partial Content 部分內(nèi)容。服務(wù)器成功處理了部分 GET 請求。

3XX為重定向狀態(tài)碼，其中：

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

4XX為客戶端錯誤狀態(tài)碼，其中：

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

5XX為服務(wù)端錯誤狀態(tài)碼，其中：

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

總結(jié)一下：

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

HTTP 協(xié)議包括哪些請求？

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

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

HTTP狀態(tài)碼301和302的區(qū)別？

• 301：（永久性轉(zhuǎn)移）請求的網(wǎng)頁已被永久移動到新位置。服務(wù)器返回此響應(yīng)時，會自動將請求者轉(zhuǎn)到新位置。
• 302：（暫時性轉(zhuǎn)移）服務(wù)器目前正從不同位置的網(wǎng)頁響應(yīng)請求，但請求者應(yīng)繼續(xù)使用原有位置來進行以后的請求。此代碼與響應(yīng)GET和HEAD請求的301代碼類似，會自動將請求者轉(zhuǎn)到不同的位置。

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

POST和GET的區(qū)別？

• GET 和 POST 最本質(zhì)的區(qū)別是規(guī)范上的區(qū)別，在規(guī)范中，定義 GET 請求是用來獲取資源的，也就是進行查詢操作的，而 POST 請求是用來傳輸實體對象的，因此會使用 POST 來進行添加、修改和刪除等操作。
• GET請求參數(shù)通過URL傳遞，POST的參數(shù)放在請求體中。
• GET 請求可以直接進行回退和刷新，不會對用戶和程序產(chǎn)生任何影響；而 POST 請求如果直接回滾和刷新將會把數(shù)據(jù)再次提交。
• GET產(chǎn)生一個TCP數(shù)據(jù)包；POST產(chǎn)生兩個TCP數(shù)據(jù)包。對于GET方式的請求，瀏覽器會把請求頭和請求體一并發(fā)送出去；而對于POST，瀏覽器先發(fā)送請求頭，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送請求體。
• GET 請求一般會被緩存，比如常見的 CSS、JS、HTML 請求等都會被緩存；而 POST 請求默認是不進行緩存的。
• GET請求參數(shù)會被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會被保留。

URI和URL的區(qū)別

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

如何理解HTTP協(xié)議是無狀態(tài)的

當瀏覽器第一次發(fā)送請求給服務(wù)器時，服務(wù)器響應(yīng)了；如果同個瀏覽器發(fā)起第二次請求給服務(wù)器時，它還是會響應(yīng)，但是呢，服務(wù)器不知道你就是剛才的那個瀏覽器。簡言之，服務(wù)器不會去記住你是誰，所以是無狀態(tài)協(xié)議。

HTTP長連接和短連接？

HTTP短連接：瀏覽器和服務(wù)器每進行一次HTTP操作，就建立一次連接，任務(wù)結(jié)束就中斷連接。HTTP1.0默認使用的是短連接。

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

HTTP/1.1起，默認使用長連接。要使用長連接，客戶端和服務(wù)器的HTTP首部的Connection都要設(shè)置為keep-alive，才能支持長連接。

HTTP 如何實現(xiàn)長連接？

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

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

如何設(shè)置長連接？

通過在頭部（請求和響應(yīng)頭）設(shè)置Connection字段指定為keep-alive，HTTP/1.0協(xié)議支持，但是是默認關(guān)閉的，從HTTP/1.1以后，連接默認都是長連接。

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

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

TCP 的keep-alive包含三個參數(shù)，支持在系統(tǒng)內(nèi)核的net.ipv4里面設(shè)置；當 TCP 連接之后，閑置了tcp_keepalive_time，則會發(fā)生偵測包，如果沒有收到對方的ACK，那么會每隔 tcp_keepalive_intvl再發(fā)一次，直到發(fā)送了tcp_keepalive_probes，就會丟棄該連接。

HTTP1.1和 HTTP2.0的區(qū)別？

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

• 新的二進制格式：HTTP1.1 基于文本格式傳輸數(shù)據(jù)；HTTP2.0采用二進制格式傳輸數(shù)據(jù)，解析更高效。

• 多路復(fù)用：在一個連接里，允許同時發(fā)送多個請求或響應(yīng)，并且這些請求或響應(yīng)能夠并行的傳輸而不被阻塞，避免 HTTP1.1 出現(xiàn)的”隊頭堵塞”問題。

• 頭部壓縮，HTTP1.1的header帶有大量信息，而且每次都要重復(fù)發(fā)送；HTTP2.0 把header從數(shù)據(jù)中分離，并封裝成頭幀和數(shù)據(jù)幀，使用特定算法壓縮頭幀，有效減少頭信息大小。并且HTTP2.0在客戶端和服務(wù)器端記錄了之前發(fā)送的鍵值對，對于相同的數(shù)據(jù)，不會重復(fù)發(fā)送。比如請求a發(fā)送了所有的頭信息字段，請求b則只需要發(fā)送差異數(shù)據(jù)，這樣可以減少冗余數(shù)據(jù)，降低開銷。

• 服務(wù)端推送：HTTP2.0允許服務(wù)器向客戶端推送資源，無需客戶端發(fā)送請求到服務(wù)器獲取。

HTTPS與HTTP的區(qū)別？

1. HTTP是超文本傳輸協(xié)議，信息是明文傳輸；HTTPS則是具有安全性的ssl加密傳輸協(xié)議。
2. HTTP和HTTPS用的端口不一樣，HTTP端口是80，HTTPS是443。
3. HTTPS協(xié)議需要到CA機構(gòu)申請證書，一般需要一定的費用。
4. HTTP運行在TCP協(xié)議之上；HTTPS運行在SSL協(xié)議之上，SSL運行在TCP協(xié)議之上。

什么是數(shù)字證書？

服務(wù)端可以向證書頒發(fā)機構(gòu)CA申請證書，以避免中間人攻擊（防止證書被篡改）。證書包含三部分內(nèi)容：證書內(nèi)容、證書簽名算法和簽名，簽名是為了驗證身份。

服務(wù)端把證書傳輸給瀏覽器，瀏覽器從證書里取公鑰。證書可以證明該公鑰對應(yīng)本網(wǎng)站。

數(shù)字簽名的制作過程：

1. CA使用證書簽名算法對證書內(nèi)容進行hash運算。
2. 對hash后的值用CA的私鑰加密，得到數(shù)字簽名。

瀏覽器驗證過程：

1. 獲取證書，得到證書內(nèi)容、證書簽名算法和數(shù)字簽名。
2. 用CA機構(gòu)的公鑰對數(shù)字簽名解密（由于是瀏覽器信任的機構(gòu)，所以瀏覽器會保存它的公鑰）。
3. 用證書里的簽名算法對證書內(nèi)容進行hash運算。
4. 比較解密后的數(shù)字簽名和對證書內(nèi)容做hash運算后得到的哈希值，相等則表明證書可信。

HTTPS原理

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

1. 協(xié)商加密算法 。在Client Hello里面客戶端會告知服務(wù)端自己當前的一些信息，包括客戶端要使用的TLS版本，支持的加密算法，要訪問的域名，給服務(wù)端生成的一個隨機數(shù)（Nonce）等。需要提前告知服務(wù)器想要訪問的域名以便服務(wù)器發(fā)送相應(yīng)的域名的證書過來。

2. 服務(wù)端響應(yīng)Server Hello，告訴客戶端服務(wù)端選中的加密算法。

3. 接著服務(wù)端給客戶端發(fā)來了2個證書。第二個證書是第一個證書的簽發(fā)機構(gòu)（CA）的證書。

4. 客戶端使用證書的認證機構(gòu)CA公開發(fā)布的RSA公鑰對該證書進行驗證，下圖表明證書認證成功。

5. 驗證通過之后，瀏覽器和服務(wù)器通過密鑰交換算法產(chǎn)生共享的對稱密鑰。

6. 開始傳輸數(shù)據(jù)，使用同一個對稱密鑰來加解密。

DNS 的解析過程？

1. 瀏覽器搜索自己的DNS緩存
2. 若沒有，則搜索操作系統(tǒng)中的DNS緩存和hosts文件
3. 若沒有，則操作系統(tǒng)將域名發(fā)送至本地域名服務(wù)器，本地域名服務(wù)器查詢自己的DNS緩存，查找成功則返回結(jié)果，否則依次向根域名服務(wù)器、頂級域名服務(wù)器、權(quán)限域名服務(wù)器發(fā)起查詢請求，最終返回IP地址給本地域名服務(wù)器
4. 本地域名服務(wù)器將得到的IP地址返回給操作系統(tǒng)，同時自己也將IP地址緩存起來
5. 操作系統(tǒng)將 IP 地址返回給瀏覽器，同時自己也將IP地址緩存起來
6. 瀏覽器得到域名對應(yīng)的IP地址

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

1. 解析域名，找到主機 IP。
2. 瀏覽器利用 IP 直接與網(wǎng)站主機通信，三次握手，建立 TCP 連接。瀏覽器會以一個隨機端口向服務(wù)端的 web 程序 80 端口發(fā)起 TCP 的連接。
3. 建立 TCP 連接后，瀏覽器向主機發(fā)起一個HTTP請求。
4. 參數(shù)從客戶端傳遞到服務(wù)器端。
5. 服務(wù)器端得到客戶端參數(shù)之后，進行相應(yīng)的業(yè)務(wù)處理，再將結(jié)果封裝成 HTTP 包，返回給客戶端。
6. 服務(wù)器端和客戶端的交互完成，斷開 TCP 連接（4 次揮手）。
7. 瀏覽器解析響應(yīng)內(nèi)容，進行渲染，呈現(xiàn)給用戶。

DNS 域名解析的過程

在網(wǎng)絡(luò)中定位是依靠 IP 進行身份定位的，所以 URL 訪問的第一步便是先要得到服務(wù)器端的 IP 地址。而得到服務(wù)器的 IP 地址需要使用 DNS（Domain Name System，域名系統(tǒng)）域名解析，DNS 域名解析就是通過 URL 找到與之相對應(yīng)的 IP 地址。

DNS 域名解析的大致流程如下：

1. 先檢查瀏覽器中的 DNS 緩存，如果瀏覽器中有對應(yīng)的記錄會直接使用，并完成解析；
2. 如果瀏覽器沒有緩存，那就去查詢操作系統(tǒng)的緩存，如果查詢到記錄就可以直接返回 IP 地址，完成解析；
3. 如果操作系統(tǒng)沒有 DNS 緩存，就會去查看本地 host 文件，Windows 操作系統(tǒng)下，host 文件一般位于 "C:\Windows\System32\drivers\etc\hosts"，如果 host 文件有記錄則直接使用；
4. 如果本地 host 文件沒有相應(yīng)的記錄，會請求本地 DNS 服務(wù)器，本地 DNS 服務(wù)器一般是由本地網(wǎng)絡(luò)服務(wù)商如移動、聯(lián)通等提供。通常情況下可通過 DHCP 自動分配，當然也可以自己手動配置。目前用的比較多的是谷歌提供的公用 DNS 是 8.8.8.8 和國內(nèi)的公用 DNS 是 114.114.114.114。
5. 如果本地 DNS 服務(wù)器沒有相應(yīng)的記錄，就會去根域名服務(wù)器查詢了。為了能更高效完成全球所有域名的解析請求，根域名服務(wù)器本身并不會直接去解析域名，而是會把不同的解析請求分配給下面的其他服務(wù)器去完成。

圖片來源于網(wǎng)絡(luò)

什么是cookie和session？

由于HTTP協(xié)議是無狀態(tài)的協(xié)議，需要用某種機制來識具體的用戶身份，用來跟蹤用戶的整個會話。常用的會話跟蹤技術(shù)是cookie與session。

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

cookie工作流程：

1. servlet創(chuàng)建cookie，保存少量數(shù)據(jù)，發(fā)送給瀏覽器。
2. 瀏覽器獲得服務(wù)器發(fā)送的cookie數(shù)據(jù)，將自動的保存到瀏覽器端。
3. 下次訪問時，瀏覽器將自動攜帶cookie數(shù)據(jù)發(fā)送給服務(wù)器。

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

cookie和session的區(qū)別？

• 作用范圍不同，Cookie 保存在客戶端，Session 保存在服務(wù)器端。
• 有效期不同，Cookie 可設(shè)置為長時間保持，比如我們經(jīng)常使用的默認登錄功能，Session 一般失效時間較短，客戶端關(guān)閉或者 Session 超時都會失效。
• 隱私策略不同，Cookie 存儲在客戶端，容易被竊??；Session 存儲在服務(wù)端，安全性相對 Cookie 要好一些。
• 存儲大小不同， 單個 Cookie 保存的數(shù)據(jù)不能超過 4K；對于 Session 來說存儲沒有上限，但出于對服務(wù)器的性能考慮，Session 內(nèi)不要存放過多的數(shù)據(jù)，并且需要設(shè)置 Session 刪除機制。

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

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

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

說說 WebSocket與socket的區(qū)別

Socket是一套標準，它完成了對TCP/IP的高度封裝，屏蔽網(wǎng)絡(luò)細節(jié)，以方便開發(fā)者更好地進行網(wǎng)絡(luò)編程。Socket其實就是等于IP地址 + 端口 + 協(xié)議。

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

Socket一個是網(wǎng)編編程的標準接口，而WebSocket則是應(yīng)用層通信協(xié)議。

ARP協(xié)議的工作過程？

ARP解決了同一個局域網(wǎng)上的主機和路由器IP和MAC地址的解析。

• 每臺主機都會在自己的ARP緩沖區(qū)中建立一個ARP列表，以表示IP地址和MAC地址的對應(yīng)關(guān)系。
• 當源主機需要將一個數(shù)據(jù)包要發(fā)送到目的主機時，會首先檢查自己 ARP列表中是否存在該 IP地址對應(yīng)的MAC地址，如果有，就直接將數(shù)據(jù)包發(fā)送到這個MAC地址；如果沒有，就向本地網(wǎng)段發(fā)起一個ARP請求的廣播包，查詢此目的主機對應(yīng)的MAC地址。此ARP請求數(shù)據(jù)包里包括源主機的IP地址、硬件地址、以及目的主機的IP地址。
• 網(wǎng)絡(luò)中所有的主機收到這個ARP請求后，會檢查數(shù)據(jù)包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此數(shù)據(jù)包；如果相同，該主機首先將發(fā)送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已經(jīng)存在該IP的信息，則將其覆蓋，然后給源主機發(fā)送一個 ARP響應(yīng)數(shù)據(jù)包，告訴對方自己是它需要查找的MAC地址。
• 源主機收到這個ARP響應(yīng)數(shù)據(jù)包后，將得到的目的主機的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息開始數(shù)據(jù)的傳輸。
• 如果源主機一直沒有收到ARP響應(yīng)數(shù)據(jù)包，表示ARP查詢失敗。

ICMP協(xié)議的功能

ICMP,Internet Control Message Protocol ,Internet控制消息協(xié)議。

• ICMP協(xié)議是一種面向無連接的協(xié)議，用于傳輸出錯報告控制信息。
• 它是一個非常重要的協(xié)議，它對于網(wǎng)絡(luò)安全具有極其重要的意義。它屬于網(wǎng)絡(luò)層協(xié)議，主要用于在主機與路由器之間傳遞控制信息，包括報告錯誤、交換受限控制和狀態(tài)信息等。
• 當遇到IP數(shù)據(jù)無法訪問目標、IP路由器無法按當前的傳輸速率轉(zhuǎn)發(fā)數(shù)據(jù)包等情況時，會自動發(fā)送ICMP消息。

比如我們?nèi)粘Ｊ褂玫帽容^多的ping，就是基于ICMP的。

什么是DoS、DDoS、DRDoS攻擊？

• DOS: (Denial of Service),翻譯過來就是拒絕服務(wù),一切能引起DOS行為的攻擊都被稱為DOS攻擊。最常見的DoS攻擊就有計算機網(wǎng)絡(luò)寬帶攻擊、連通性攻擊。
• DDoS: (Distributed Denial of Service),翻譯過來是分布式拒絕服務(wù)。是指處于不同位置的多個攻擊者同時向一個或幾個目標發(fā)動攻擊，或者一個攻擊者控制了位于不同位置的多臺機器并利用這些機器對受害者同時實施攻擊。常見的DDos有SYN Flood、Ping of Death、ACK Flood、UDP Flood等。
• DRDoS: (Distributed Reflection Denial of Service)，中文是分布式反射拒絕服務(wù)，該方式靠的是發(fā)送大量帶有被害者IP地址的數(shù)據(jù)包給攻擊主機，然后攻擊主機對IP地址源做出大量回應(yīng)，從而形成拒絕服務(wù)攻擊。

什么是CSRF攻擊，如何避免

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

怎么解決CSRF攻擊呢？

• 檢查Referer字段。
• 添加校驗token。

什么是XSS攻擊？

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

如何解決XSS攻擊問題？

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

防盜鏈

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

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

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

什么是 Referer？

這里的 Referer 指的是 HTTP 頭部的一個字段，也稱為 HTTP 來源地址（HTTP Referer），用來表示從哪兒鏈接到目前的網(wǎng)頁，采用的格式是 URL。換句話說，借著 HTTP Referer 頭部網(wǎng)頁可以檢查訪客從哪里而來，這也常被用來對付偽造的跨網(wǎng)站請求。

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

什么是空 Referer，什么時候會出現(xiàn)空 Referer？

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

那么什么時候 HTTP 請求會不包含 Referer 字段呢？根據(jù) Referer 的定義，它的作用是指示一個請求是從哪里鏈接過來，那么當一個請求并不是由鏈接觸發(fā)產(chǎn)生的，那么自然也就不需要指定這個請求的鏈接來源。

比如，直接在瀏覽器的地址欄中輸入一個資源的 URL 地址，那么這種請求是不會包含 Referer 字段的，因為這是一個 “憑空產(chǎn)生” 的 HTTP 請求，并不是從一個地方鏈接過去的。

說下ping的原理

ping，Packet Internet Groper，是一種因特網(wǎng)包探索器，用于測試網(wǎng)絡(luò)連接量的程序。Ping是工作在TCP/IP網(wǎng)絡(luò)體系結(jié)構(gòu)中應(yīng)用層的一個服務(wù)命令， 主要是向特定的目的主機發(fā)送ICMP（Internet Control Message Protocol 因特網(wǎng)報文控制協(xié)議） 請求報文，測試目的站是否可達及了解其有關(guān)狀態(tài)。

一般來說，ping可以用來檢測網(wǎng)絡(luò)通不通。它是基于ICMP協(xié)議工作的。假設(shè)機器A ping機器B，工作過程如下：文章來源地址http://www.zghlxwxcb.cn/news/detail-415694.html

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

到了這里，關(guān)于三天吃透計算機網(wǎng)絡(luò)八股文的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！