推薦： 瘋狂創(chuàng)客圈 高質(zhì)量 博文

史上最全 Java 面試題 30 專題 總目錄

史上最全 Java 面試題：網(wǎng)絡(luò)協(xié)議 篇

HTTP協(xié)議

當(dāng)你用瀏覽器打開一個鏈接的時候，計算機(jī)做了哪些工作步驟。

? （1）、解析域名。

? （2）、發(fā)起TCP的3次握手。

? （3）、建立TCP請求后發(fā)起HTTP請求。

? （4）、服務(wù)器相應(yīng)HTTP請求。

? （5）、瀏覽器得到HTML代碼，進(jìn)行解析和處理JSON數(shù)據(jù)，并請求HTML代碼中的靜態(tài)資源（JS、CSS、圖片等）。

? （6）、瀏覽器對頁面進(jìn)行渲染。

HTTP有哪些method。

? ★ GET：獲取資源。

? ★ POST：表單提交。

? ★ HEAD：獲取報頭信息，HEAD 方法與 GET 方法類似，但并不會返回響應(yīng)主體。

? ★ PUT 與PATCH：更新資源，PUT 對后臺來說 PUT 方法的參數(shù)是一個完整的資源對象，它包含了對象的所有字段，PATCH 對后臺來說 PATCH 方法的參數(shù)只包含我們需要修改的資源對象的字段。

? ★ DELETE：刪除資源。

? ★ OPTIONS：獲取目標(biāo)資源所支持的通信選項,使用 OPTIONS 方法對服務(wù)器發(fā)起請求,以檢測服務(wù)器支持哪些 HTTP 方法。

HTTPS的加密方式是什么，講講整個加密解密流程。

加密方式： 1）、對稱密碼算法：指加密和解密使用相同的密鑰，速度高，可加密內(nèi)容較大，用來加密會話過程中的消息。典型算法DES、AES、RC5、IDEA（分組加密）RC4。

? 2）、非對稱密碼算法：又稱為公鑰加密算法，是指加密和解密使用不同的密鑰，加密速度較慢，但能提供更好的身份認(rèn)證技術(shù)，用來加密對稱加密的密鑰（公開的密鑰用于加密，私有的密鑰用于解密）典型的算法RSA、DSA、DH。

? 3）、散列算法：將文件內(nèi)容通過此算法加密變成固定長度的值（散列值），這個過程可以使用密鑰也可以不使用。這種散列變化是不可逆的，也就是說不能從散列值編程原文，因此散列變化通道常用語驗證原文是否被篡改。典型的算法MD5、SHA、BASE64、CRC等。

Http與Https的區(qū)別：

HTTP 的URL 以http:// 開頭，而HTTPS 的URL 以https:// 開頭

HTTP 是不安全的，而 HTTPS 是安全的

HTTP 標(biāo)準(zhǔn)端口是80 ，而 HTTPS 的標(biāo)準(zhǔn)端口是443

在OSI 網(wǎng)絡(luò)模型中，HTTP工作于應(yīng)用層，而HTTPS 的安全傳輸機(jī)制工作在傳輸層

HTTP 無法加密，而HTTPS 對傳輸?shù)臄?shù)據(jù)進(jìn)行加密

HTTP無需證書，而HTTPS 需要CA機(jī)構(gòu)頒發(fā)的SSL證書

什么是Http協(xié)議無狀態(tài)協(xié)議?怎么解決Http協(xié)議無狀態(tài)協(xié)議?

無狀態(tài)協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息

也就是說，當(dāng)客戶端一次HTTP請求完成以后，客戶端再發(fā)送一次HTTP請求，HTTP并不知道當(dāng)前客戶端是一個”老用戶“。

可以使用Cookie來解決無狀態(tài)的問題，Cookie就相當(dāng)于一個通行證，第一次訪問的時候給客戶端發(fā)送一個Cookie，當(dāng)客戶端再次來的時候，拿著Cookie(通行證)，那么服務(wù)器就知道這個是”老用戶“

URI和URL的區(qū)別

URI，是uniform resource identifier，統(tǒng)一資源標(biāo)識符，用來唯一的標(biāo)識一個資源。

Web上可用的每種資源如HTML文檔、圖像、視頻片段、程序等都是一個來URI來定位的

URI一般由三部組成：

①訪問資源的命名機(jī)制

②存放資源的主機(jī)名

③資源自身的名稱，由路徑表示，著重強(qiáng)調(diào)于資源。

URL是uniform resource locator，統(tǒng)一資源定位器，它是一種具體的URI，即URL可以用來標(biāo)識一個資源，而且還指明了如何locate這個資源。

URL是Internet上用來描述信息資源的字符串，主要用在各種WWW客戶程序和服務(wù)器程序上，特別是著名的Mosaic。

采用URL可以用一種統(tǒng)一的格式來描述各種信息資源，包括文件、服務(wù)器的地址和目錄等。URL一般由三部組成：

①協(xié)議(或稱為服務(wù)方式)

②存有該資源的主機(jī)IP地址(有時也包括端口號)

③主機(jī)資源的具體地址。如目錄和文件名等

常見的HTTP相應(yīng)狀態(tài)碼

200：請求被正常處理

204：請求被受理但沒有資源可以返回

206：客戶端只是請求資源的一部分，服務(wù)器只對請求的部分資源執(zhí)行GET方法，相應(yīng)報文中通過Content-Range指定范圍的資源。

301：永久性重定向

302：臨時重定向

303：與302狀態(tài)碼有相似功能，只是它希望客戶端在請求一個URI的時候，能通過GET方法重定向到另一個URI上

304：發(fā)送附帶條件的請求時，條件不滿足時返回，與重定向無關(guān)

307：臨時重定向，與302類似，只是強(qiáng)制要求使用POST方法

400：請求報文語法有誤，服務(wù)器無法識別

401：請求需要認(rèn)證

403：請求的對應(yīng)資源禁止被訪問

404：服務(wù)器無法找到對應(yīng)資源

500：服務(wù)器內(nèi)部錯誤

503：服務(wù)器正忙

HTTP優(yōu)化方案

我下面就簡要概括一下：

TCP復(fù)用：TCP連接復(fù)用是將多個客戶端的HTTP請求復(fù)用到一個服務(wù)器端TCP連接上，而HTTP復(fù)用則是一個客戶端的多個HTTP請求通過一個TCP連接進(jìn)行處理。前者是負(fù)載均衡設(shè)備的獨特功能；而后者是HTTP 1.1協(xié)議所支持的新功能

內(nèi)容緩存：將經(jīng)常用到的內(nèi)容進(jìn)行緩存起來，那么客戶端就可以直接在內(nèi)存中獲取相應(yīng)的數(shù)據(jù)了。

壓縮：將文本數(shù)據(jù)進(jìn)行壓縮，減少帶寬

SSL加速（SSL Acceleration）：使用SSL協(xié)議對HTTP協(xié)議進(jìn)行加密，在通道內(nèi)加密并加速

TCP緩沖：通過采用TCP緩沖技術(shù)，可以提高服務(wù)器端響應(yīng)時間和處理效率，減少由于通信鏈路問題給服務(wù)器造成的連接負(fù)擔(dān)。

GET方法與POST方法的區(qū)別

區(qū)別一：

get重點在從服務(wù)器上獲取資源，post重點在向服務(wù)器發(fā)送數(shù)據(jù)；

區(qū)別二：

get傳輸數(shù)據(jù)是通過URL請求，以field（字段）= value的形式，置于URL后，并用"?"連接，多個請求數(shù)據(jù)間用"&"連接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，這個過程用戶是可見的；

post傳輸數(shù)據(jù)通過Http的post機(jī)制，將字段與對應(yīng)值封存在請求實體中發(fā)送給服務(wù)器，這個過程對用戶是不可見的；

區(qū)別三：

Get傳輸?shù)臄?shù)據(jù)量小，因為受URL長度限制，但效率較高；

Post可以傳輸大量數(shù)據(jù)，所以上傳文件時只能用Post方式；

區(qū)別四：

get是不安全的，因為URL是可見的，可能會泄露私密信息，如密碼等；

post較get安全性較高；

區(qū)別五：

get方式只能支持ASCII字符，向服務(wù)器傳的中文字符可能會亂碼。

post支持標(biāo)準(zhǔn)字符集，可以正確傳遞中文字符。

HTTP請求報文與響應(yīng)報文格式

請求報文包含三部分：

a、請求行：包含請求方法、URI、HTTP版本信息

b、請求首部字段

c、請求內(nèi)容實體

響應(yīng)報文包含三部分：

a、狀態(tài)行：包含HTTP版本、狀態(tài)碼、狀態(tài)碼的原因短語

b、響應(yīng)首部字段

c、響應(yīng)內(nèi)容實體

Session和cookie的區(qū)別。

? （1）、Cookie保存在客戶端，未設(shè)置存儲時間的Cookie，關(guān)閉瀏覽器會話Cookie就會被刪除；設(shè)置了存儲時間的Cookie保存在用戶設(shè)備的磁盤中知道過期，同時Cookie在客戶端所以可以偽造，不是十分安全，敏感數(shù)據(jù)不易保存。Session保存在服務(wù)器端，存儲在IIS的進(jìn)程開辟的內(nèi)存中，而Session過多會消耗服務(wù)器資源，所以盡量少使用Session。

? （2）、Session是服務(wù)器用來跟蹤用戶的一種手段，每個Session都有一個唯一標(biāo)識：session ID。當(dāng)服務(wù)端生成一個Session時就會向客戶端發(fā)送一個Cookie保存到客戶端，這個Cookie保存的是Session的SessionId這樣才能保證客戶端發(fā)起請求后，用戶能夠與服務(wù)器端成千上萬的Session進(jìn)行匹配，同時也保證了不同頁面之間傳值的正確性.

? （3）、存儲數(shù)據(jù)類型不同：Session能夠存儲任意的JAVA對象，Cookie只能存儲String類型的對象。

? （4）、長于10K的數(shù)據(jù)，不要用到Cookies。

http的請求報文是什么樣的？

請求報文有4部分組成:

請求行
請求頭部
空行
請求體

請求行包括：請求方法字段、URL字段、HTTP協(xié)議版本字段。它們用空格分隔。例如，GET /index.html HTTP/1.1。
請求頭部:請求頭部由關(guān)鍵字/值對組成，每行一對，關(guān)鍵字和值用英文冒號“:”分隔

User-Agent：產(chǎn)生請求的瀏覽器類型。
Accept：客戶端可識別的內(nèi)容類型列表。
Host：請求的主機(jī)名，允許多個域名同處一個IP地址，即虛擬主機(jī)。

請求體: post put等請求攜帶的數(shù)據(jù)

http的響應(yīng)報文是什么樣的？

請求報文有4部分組成:

響應(yīng)行
響應(yīng)頭
空行
響應(yīng)體

響應(yīng)行： 由協(xié)議版本，狀態(tài)碼和狀態(tài)碼的原因短語組成，例如HTTP/1.1 200 OK。
響應(yīng)頭：響應(yīng)部首組成
響應(yīng)體：服務(wù)器響應(yīng)的數(shù)據(jù)

聊一聊HTTP的部首有哪些？

內(nèi)容很多，重點看標(biāo)『✨』內(nèi)容

通用首部字段（General Header Fields）：請求報文和響應(yīng)報文兩方都會使用的首部

Cache-Control 控制緩存 ✨
Connection 連接管理、逐條首部 ✨
Upgrade 升級為其他協(xié)議
via 代理服務(wù)器的相關(guān)信息
Wraning 錯誤和警告通知
Transfor-Encoding 報文主體的傳輸編碼格式 ✨
Trailer 報文末端的首部一覽
Pragma 報文指令
Date 創(chuàng)建報文的日期

請求首部字段（Reauest Header Fields）:客戶端向服務(wù)器發(fā)送請求的報文時使用的首部

Accept 客戶端或者代理能夠處理的媒體類型 ✨
Accept-Encoding 優(yōu)先可處理的編碼格式
Accept-Language 優(yōu)先可處理的自然語言
Accept-Charset 優(yōu)先可以處理的字符集
If-Match 比較實體標(biāo)記（ETage） ✨
If-None-Match 比較實體標(biāo)記（ETage）與 If-Match相反 ✨
If-Modified-Since 比較資源更新時間（Last-Modified）✨
If-Unmodified-Since比較資源更新時間（Last-Modified），與 If-Modified-Since相反 ✨
If-Rnages 資源未更新時發(fā)送實體byte的范圍請求
Range 實體的字節(jié)范圍請求 ✨
Authorization web的認(rèn)證信息 ✨
Proxy-Authorization 代理服務(wù)器要求web認(rèn)證信息
Host 請求資源所在服務(wù)器 ✨
From 用戶的郵箱地址
User-Agent 客戶端程序信息 ✨
Max-Forwrads 最大的逐跳次數(shù)
TE 傳輸編碼的優(yōu)先級
Referer 請求原始放的url
Expect 期待服務(wù)器的特定行為

響應(yīng)首部字段（Response Header Fields）:從服務(wù)器向客戶端響應(yīng)時使用的字段

Accept-Ranges 能接受的字節(jié)范圍
Age 推算資源創(chuàng)建經(jīng)過時間
Location 令客戶端重定向的URI ✨
vary 代理服務(wù)器的緩存信息
ETag 能夠表示資源唯一資源的字符串 ✨
WWW-Authenticate 服務(wù)器要求客戶端的驗證信息
Proxy-Authenticate 代理服務(wù)器要求客戶端的驗證信息
Server 服務(wù)器的信息 ✨
Retry-After 和狀態(tài)碼503 一起使用的首部字段，表示下次請求服務(wù)器的時間

實體首部字段（Entiy Header Fields）:針對請求報文和響應(yīng)報文的實體部分使用首部

Allow 資源可支持http請求的方法 ✨
Content-Language 實體的資源語言
Content-Encoding 實體的編碼格式
Content-Length 實體的大小（字節(jié)）
Content-Type 實體媒體類型
Content-MD5 實體報文的摘要
Content-Location 代替資源的yri
Content-Rnages 實體主體的位置返回
Last-Modified 資源最后的修改資源 ✨
Expires 實體主體的過期資源 ✨

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

內(nèi)容很多，重點看標(biāo)『✨』內(nèi)容

2XX 成功

200 OK，表示從客戶端發(fā)來的請求在服務(wù)器端被正確處理 ✨
201 Created 請求已經(jīng)被實現(xiàn)，而且有一個新的資源已經(jīng)依據(jù)請求的需要而建立
202 Accepted 請求已接受，但是還沒執(zhí)行，不保證完成請求
204 No content，表示請求成功，但響應(yīng)報文不含實體的主體部分
206 Partial Content，進(jìn)行范圍請求 ✨

3XX 重定向

301 moved permanently，永久性重定向，表示資源已被分配了新的 URL
302 found，臨時性重定向，表示資源臨時被分配了新的 URL ✨
303 see other，表示資源存在著另一個 URL，應(yīng)使用 GET 方法丁香獲取資源
304 not modified，表示服務(wù)器允許訪問資源，但因發(fā)生請求未滿足條件的情況
307 temporary redirect，臨時重定向，和302含義相同

4XX 客戶端錯誤

400 bad request，請求報文存在語法錯誤 ✨
401 unauthorized，表示發(fā)送的請求需要有通過 HTTP 認(rèn)證的認(rèn)證信息 ✨
403 forbidden，表示對請求資源的訪問被服務(wù)器拒絕 ✨
404 not found，表示在服務(wù)器上沒有找到請求的資源 ✨
408 Request timeout, 客戶端請求超時
409 Confict, 請求的資源可能引起沖突

5XX 服務(wù)器錯誤

500 internal sever error，表示服務(wù)器端在執(zhí)行請求時發(fā)生了錯誤 ✨
501 Not Implemented 請求超出服務(wù)器能力范圍，例如服務(wù)器不支持當(dāng)前請求所需要的某個功能，或者請求是服務(wù)器不支持的某個方法
503 service unavailable，表明服務(wù)器暫時處于超負(fù)載或正在停機(jī)維護(hù)，無法處理請求
505 http version not supported 服務(wù)器不支持，或者拒絕支持在請求中使用的 HTTP 版本

同樣是重定向307，303，302的區(qū)別？

302是http1.0的協(xié)議狀態(tài)碼，在http1.1版本的時候為了細(xì)化302狀態(tài)碼又出來了兩個303和307。

303明確表示客戶端應(yīng)當(dāng)采用get方法獲取資源，他會把POST請求變?yōu)镚ET請求進(jìn)行重定向。 307會遵照瀏覽器標(biāo)準(zhǔn)，不會從post變?yōu)間et。

HTTP的keep-alive是干什么的？

在早期的HTTP/1.0中，每次http請求都要創(chuàng)建一個連接，而創(chuàng)建連接的過程需要消耗資源和時間，為了減少資源消耗，縮短響應(yīng)時間，就需要重用連接。在后來的HTTP/1.0中以及HTTP/1.1中，引入了重用連接的機(jī)制，就是在http請求頭中加入Connection: keep-alive來告訴對方這個請求響應(yīng)完成后不要關(guān)閉，下一次咱們還用這個請求繼續(xù)交流。協(xié)議規(guī)定HTTP/1.0如果想要保持長連接，需要在請求頭中加上Connection: keep-alive。

keep-alive的優(yōu)點：

較少的CPU和內(nèi)存的使用（由于同時打開的連接的減少了）
允許請求和應(yīng)答的HTTP管線化
降低擁塞控制 （TCP連接減少了）
減少了后續(xù)請求的延遲（無需再進(jìn)行握手）
報告錯誤無需關(guān)閉TCP連

HTTP2相對于HTTP1.x有什么優(yōu)勢和特點？

二進(jìn)制分幀

幀：HTTP/2 數(shù)據(jù)通信的最小單位消息：指 HTTP/2 中邏輯上的 HTTP 消息。例如請求和響應(yīng)等，消息由一個或多個幀組成。

流：存在于連接中的一個虛擬通道。流可以承載雙向消息，每個流都有一個唯一的整數(shù)ID

HTTP/2 采用二進(jìn)制格式傳輸數(shù)據(jù)，而非 HTTP 1.x 的文本格式，二進(jìn)制協(xié)議解析起來更高效。

服務(wù)器推送

服務(wù)端可以在發(fā)送頁面HTML時主動推送其它資源，而不用等到瀏覽器解析到相應(yīng)位置，發(fā)起請求再響應(yīng)。例如服務(wù)端可以主動把JS和CSS文件推送給客戶端，而不需要客戶端解析HTML時再發(fā)送這些請求。

服務(wù)端可以主動推送，客戶端也有權(quán)利選擇是否接收。如果服務(wù)端推送的資源已經(jīng)被瀏覽器緩存過，瀏覽器可以通過發(fā)送RST_STREAM幀來拒收。主動推送也遵守同源策略，服務(wù)器不會隨便推送第三方資源給客戶端。

頭部壓縮

HTTP/1.x會在請求和響應(yīng)中中重復(fù)地攜帶不常改變的、冗長的頭部數(shù)據(jù)，給網(wǎng)絡(luò)帶來額外的負(fù)擔(dān)。

HTTP/2在客戶端和服務(wù)器端使用“首部表”來跟蹤和存儲之前發(fā)送的鍵－值對，對于相同的數(shù)據(jù)，不再通過每次請求和響應(yīng)發(fā)送
首部表在HTTP/2的連接存續(xù)期內(nèi)始終存在，由客戶端和服務(wù)器共同漸進(jìn)地更新;
每個新的首部鍵－值對要么被追加到當(dāng)前表的末尾，要么替換表中之前的值。

你可以理解為只發(fā)送差異數(shù)據(jù)，而不是全部發(fā)送，從而減少頭部的信息量

多路復(fù)用

HTTP 1.x 中，如果想并發(fā)多個請求，必須使用多個 TCP 鏈接，且瀏覽器為了控制資源，還會對單個域名有 6-8個的TCP鏈接請求限制。

HTTP2中：

同域名下所有通信都在單個連接上完成。
單個連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。
數(shù)據(jù)流以消息的形式發(fā)送，而消息又由一個或多個幀組成，多個幀之間可以亂序發(fā)送，因為根據(jù)幀首部的流標(biāo)識可以重新組裝

HTTPS 是什么？

HTTPS ，實際就是在 TCP 層與 HTTP 層之間加入了 SSL/TLS 來為上層的安全保駕護(hù)航，主要用到對稱加密、非對稱加密、證書，等技術(shù)進(jìn)行客戶端與服務(wù)器的數(shù)據(jù)加密傳輸，最終達(dá)到保證整個通信的安全性。

為什么有了HTTP為什么還要HTTPS？

https是安全版的http，因為http協(xié)議的數(shù)據(jù)都是明文進(jìn)行傳輸?shù)模詫τ谝恍┟舾行畔⒌膫鬏斁秃懿话踩琀TTPS就是為了解決HTTP的不安全而生的。

HTTPS是如何保證安全的？

過程比較復(fù)雜，我們得先理解兩個概念

對稱加密：即通信的雙方都使用同一個秘鑰進(jìn)行加解密，比如特務(wù)接頭的暗號，就屬于對稱加密

對稱加密雖然很簡單性能也好，但是無法解決首次把秘鑰發(fā)給對方的問題，很容易被hacker攔截秘鑰。

非對稱加密：

私鑰 + 公鑰= 密鑰對
即用私鑰加密的數(shù)據(jù),只有對應(yīng)的公鑰才能解密,用公鑰加密的數(shù)據(jù),只有對應(yīng)的私鑰才能解密
因為通信雙方的手里都有一套自己的密鑰對,通信之前雙方會先把自己的公鑰都先發(fā)給對方
然后對方再拿著這個公鑰來加密數(shù)據(jù)響應(yīng)給對方,等到到了對方那里,對方再用自己的私鑰進(jìn)行解密

非對稱加密雖然安全性更高，但是帶來的問題就是速度很慢，影響性能。

解決方案：

那么結(jié)合兩種加密方式，將對稱加密的密鑰使用非對稱加密的公鑰進(jìn)行加密，然后發(fā)送出去，接收方使用私鑰進(jìn)行解密得到對稱加密的密鑰，然后雙方可以使用對稱加密來進(jìn)行溝通。

此時又帶來一個問題，中間人問題：

如果此時在客戶端和服務(wù)器之間存在一個中間人,這個中間人只需要把原本雙方通信互發(fā)的公鑰,換成自己的公鑰,這樣中間人就可以輕松解密通信雙方所發(fā)送的所有數(shù)據(jù)。

所以這個時候需要一個安全的第三方頒發(fā)證書（CA），證明身份的身份，防止被中間人攻擊。

證書中包括：簽發(fā)者、證書用途、使用者公鑰、使用者私鑰、使用者的HASH算法、證書到期時間等

但是問題來了，如果中間人篡改了證書，那么身份證明是不是就無效了？這個證明就白買了，這個時候需要一個新的技術(shù)，數(shù)字簽名。

數(shù)字簽名就是用CA自帶的HASH算法對證書的內(nèi)容進(jìn)行HASH得到一個摘要，再用CA的私鑰加密，最終組成數(shù)字簽名。

當(dāng)別人把他的證書發(fā)過來的時候,我再用同樣的Hash算法,再次生成消息摘要，然后用CA的公鑰對數(shù)字簽名解密,得到CA創(chuàng)建的消息摘要,兩者一比,就知道中間有沒有被人篡改了。

這個時候就能最大程度保證通信的安全了。

IO模型

nio和 bio 、aio的區(qū)別

消息時的系統(tǒng)通信，通常基于網(wǎng)絡(luò)協(xié)議實現(xiàn)。常見的協(xié)議包括TCP/IP,UDP/IP。

TCP/IP等協(xié)議用于數(shù)據(jù)傳輸，但要完成通信，還需要對數(shù)據(jù)進(jìn)行處理。例如讀取和寫入數(shù)據(jù)。

I/O可以分為兩種：同步IO和異步IO,同步I/O最常見的是 BIO(Blocking IO)、NIO(Non-Blocking IO)

BIO：是當(dāng)發(fā)起I/O的讀或?qū)懖僮鲿r，均為阻塞方式，直到應(yīng)用程序讀到了流或者將流寫入數(shù)據(jù)。

NIO：基于事件驅(qū)動思想，常采用reactor（反應(yīng)器）模式。當(dāng)發(fā)起 IO請求時，應(yīng)用程序是非阻塞的。當(dāng)SOCKET有流可讀或?qū)懙臅r候，

由操作系統(tǒng)通知應(yīng)用程序，應(yīng)用程序再將流讀取到緩沖區(qū)或者寫入系統(tǒng)。

AIO：同樣基于事件驅(qū)動的思想，通常采用Proactor(前攝器模式)實現(xiàn)。對于讀操作，操作系統(tǒng)將數(shù)據(jù)讀到緩沖區(qū)，并通知應(yīng)用程序，對于寫操作，操作系統(tǒng)將write方法傳遞的流寫入并主動通知

應(yīng)用程序。它節(jié)省了NIO中遍歷事件通知隊列的代價。

阻塞　某個請求發(fā)出后，由于該請求操作需要的條件不滿足，請求操作一直阻塞，不會返回，直到條件滿足。

非阻塞　請求發(fā)出后，若該請求需要的條件不滿足，則立即返回一個標(biāo)志信息告知條件不滿足，而不會一直等待。一般需要通過循環(huán)判斷請求條件是否滿足來獲取請求結(jié)果。

這里注意比較NIO和AIO的不同，AIO是操作系統(tǒng)完成IO并通知應(yīng)用程序，NIO是操作系統(tǒng)通知應(yīng)用程序，由應(yīng)用程序完成。

reactor 模型

當(dāng)客戶端請求抵達(dá)后，服務(wù)處理程序使用多路分配策略，由一個非阻塞的線程來接收所有的請求，然后派發(fā)這些請求至相關(guān)的工作線程進(jìn)行處理

TCP協(xié)議

網(wǎng)絡(luò)的七層結(jié)構(gòu)及其作用

自上而下是：

應(yīng)用層（數(shù)據(jù)）：確定進(jìn)程之間通信的性質(zhì)以滿足用戶需要以及提供網(wǎng)絡(luò)與用戶應(yīng)用

表示層（數(shù)據(jù)）：主要解決用戶信息的語法表示問題，如加密解密

會話層（數(shù)據(jù)）：提供包括訪問驗證和會話管理在內(nèi)的建立和維護(hù)應(yīng)用之間通信的機(jī)制，如服務(wù)器驗證用戶登錄便是由會話層完成的

傳輸層（段）：實現(xiàn)網(wǎng)絡(luò)不同主機(jī)上用戶進(jìn)程之間的數(shù)據(jù)通信，可靠

與不可靠的傳輸，傳輸層的錯誤檢測，流量控制等

網(wǎng)絡(luò)層（包）：提供邏輯地址（IP）、選路，數(shù)據(jù)從源端到目的端的

傳輸

數(shù)據(jù)鏈路層（幀）：將上層數(shù)據(jù)封裝成幀，用MAC地址訪問媒介，錯誤檢測與修正

物理層（比特流）：設(shè)備之間比特流的傳輸，物理接口，電氣特性等

TCP協(xié)議

TCP/IP協(xié)議按照層次分為以下四層。應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層。

TCP（Transmission Control Protocol，傳輸控制協(xié)議）是面向連接的協(xié)議，也就是說，在收發(fā)數(shù)據(jù)前，必須和對方建立可靠的連接。一個TCP連接必須要經(jīng)過三次“對話”才能建立起來，其中的過程非常復(fù)雜，

TCP選項有哪些

TCP首部選項字段多達(dá)40B，一些常用的字段有：
　　
　　1）選項結(jié)束字段（EOP，0x00），占1B，一個報文段僅用一次。放在末尾用于填充，用途是說明：首部已經(jīng)沒有更多的消息，應(yīng)用數(shù)據(jù)在下一個32位字開始處
　　2）無操作字段（NOP, 0x01），占1B，也用于填充，放在選項的開頭
　　3）MSS（最大報文段長度），格式如下：種類（1B，值為2），長度（1B，值為4），數(shù)值（2B）
　　用于在連接開始時確定MSS的大小，如果沒有確定，就用默認(rèn)的（一般實現(xiàn)是536B）
　　4）窗口擴(kuò)大因子，格式如下：種類（1B，值為3），長度（1B，值為3),數(shù)值（1B）
　　新窗口值 = 首部窗口值 * 2的（擴(kuò)大因子）次方
　　當(dāng)通信雙方認(rèn)為首部的窗口值還不夠大的時候，在連接開始時用這個來定義更大的窗口。僅在連接開始時有效。一經(jīng)定義，通信過程中無法更改。
　　5）時間戳（應(yīng)用測試RTT和防止序號繞回）
　　6）允許SACK和SACK選項

TCP三次握手：

發(fā)送方：我要和你建立鏈接？

接收方：你真的要和我建立鏈接么？

發(fā)送方：我真的要和你建立鏈接，成功。

為什么 TCP 連接需要三次握手，兩次不可以么，為什么？

為了防止已失效的連接請求報文突然又傳送到了服務(wù)端，因而產(chǎn)生錯誤。客戶端發(fā)出的連接請求報文并未丟失，而是在某個網(wǎng)絡(luò)節(jié)點長時間滯留了，以致延誤到鏈接釋放以后的某個時間才到達(dá) Server 。

問:三次握手過程中有哪些不安全性

一、SYN洪泛攻擊

服務(wù)器處于SYN_Wait的狀態(tài)：

　　1）偽裝的IP向服務(wù)器發(fā)送一個SYN請求建立連接，然后服務(wù)器向該IP回復(fù)SYN和ACK，但是找不到該IP對應(yīng)的主機(jī)，當(dāng)超時時服務(wù)器收不到ACK會重復(fù)發(fā)送。當(dāng)大量的攻擊者請求建立連接時，服務(wù)器就會存在大量未完成三次握手的連接，服務(wù)器主機(jī)backlog被耗盡而不能響應(yīng)其它連接。即SYN泛洪攻擊 （屬于DOS的一種，發(fā)送大量的半連接請求，耗費CPU和內(nèi)存資源，引起網(wǎng)絡(luò)堵塞甚至系統(tǒng)癱瘓）
　　
　　當(dāng)你在服務(wù)器上看到大量的半連接狀態(tài)時，特別是源IP地址是隨機(jī)的，基本上可以斷定這是一次SYN攻擊.在Linux下可以如下命令檢測是否被Syn攻擊

netstat -n -p TCP | grep SYN_RECV

防范措施：
　　1、降低SYN timeout時間，使得主機(jī)盡快釋放半連接的占用
　　2、采用SYN cookie設(shè)置，如果短時間內(nèi)連續(xù)收到某個IP的重復(fù)SYN請求，則認(rèn)為受到了該IP的攻擊，丟棄來自該IP的后續(xù)請求報文
　　3、在網(wǎng)關(guān)處設(shè)置過濾，拒絕將一個源IP地址不屬于其來源子網(wǎng)的包進(jìn)行更遠(yuǎn)的路由
　　
　　2）當(dāng)一個主機(jī)向服務(wù)器發(fā)送SYN請求連接，服務(wù)器回復(fù)ACK和SYN后，攻擊者截獲ACK和SYN。然后偽裝成原始主機(jī)繼續(xù)與服務(wù)器進(jìn)行通信。

二、DOS攻擊 拒絕服務(wù)攻擊

DDoS（分布式拒絕服務(wù)攻擊）
DOS攻擊利用合理的服務(wù)請求占用過多的服務(wù)資源，使正常用戶的請求無法得到相應(yīng)。

常見的DOS攻擊有計算機(jī)網(wǎng)絡(luò)帶寬攻擊和連通性攻擊。

帶寬攻擊指以極大的通信量沖擊網(wǎng)絡(luò)，使得所有可用網(wǎng)絡(luò)資源都被消耗殆盡，最后導(dǎo)致合法的用戶請求無法通過。

連通性攻擊指用大量的連接請求沖擊計算機(jī)，使得所有可用的操作系統(tǒng)資源都被消耗殆盡，最終計算機(jī)無法再處理合法用戶的請求。

三、死亡值ping

許多操作系統(tǒng)的TCP/IP協(xié)議棧規(guī)定ICMP包大小為64KB（網(wǎng)間控制報文），且在對包的標(biāo)題頭進(jìn)行讀取之后，要根據(jù)該標(biāo)題頭里包含的信息來為有效載荷生成緩沖區(qū)。
”死亡值ping”就是故意產(chǎn)生畸形的測試ping包，聲稱自己的尺寸超過ICMP上限，也就是加載的尺寸超過64KB上限，使未采取保護(hù)措施的網(wǎng)絡(luò)系統(tǒng)出現(xiàn)內(nèi)存分配錯誤，導(dǎo)致TCP/IP協(xié)議棧崩潰，最終接收方宕機(jī)。

什么是 TCP 四次揮手？

四次揮手，簡單來說，就是：

發(fā)送方：我要和你斷開連接！

接收方：好的，斷吧。

接收方：我也要和你斷開連接！

發(fā)送方：好的，斷吧。

問題：為什么要有TIME_WAIT狀態(tài)？

TIME_WAIT狀態(tài)存在有兩個原因。
一、可靠終止TCP連接。如果最后一個ACK報文因為網(wǎng)絡(luò)原因被丟棄，此時server因為沒有收到ACK而超時重傳FIN報文，處于TIME_WAIT狀態(tài)的client可以繼續(xù)對FIN報文做回復(fù)，向server發(fā)送ACK報文。

二、保證讓遲來的TCP報文段有足夠的時間被識別和丟棄。連接結(jié)束了，網(wǎng)絡(luò)中的延遲報文也應(yīng)該被丟棄掉，以免影響立刻建立的新連接。

問題：TCP粘包、拆包及解決辦法

為什么常說 TCP 有粘包和拆包的問題而不說 UDP ？

由前兩節(jié)可知，UDP 是基于報文發(fā)送的，UDP首部采用了 16bit 來指示 UDP 數(shù)據(jù)報文的長度，因此在應(yīng)用層能很好的將不同的數(shù)據(jù)報文區(qū)分開，從而避免粘包和拆包的問題。

而 TCP 是基于字節(jié)流的，雖然應(yīng)用層和 TCP 傳輸層之間的數(shù)據(jù)交互是大小不等的數(shù)據(jù)塊，但是 TCP 并沒有把這些數(shù)據(jù)塊區(qū)分邊界，僅僅是一連串沒有結(jié)構(gòu)的字節(jié)流；另外從 TCP 的幀結(jié)構(gòu)也可以看出，在 TCP 的首部沒有表示數(shù)據(jù)長度的字段，基于上面兩點，在使用 TCP 傳輸數(shù)據(jù)時，才有粘包或者拆包現(xiàn)象發(fā)生的可能。

什么是粘包、拆包？

假設(shè) Client 向 Server 連續(xù)發(fā)送了兩個數(shù)據(jù)包，用 packet1 和 packet2 來表示，那么服務(wù)端收到的數(shù)據(jù)可以分為三種情況，現(xiàn)列舉如下：

第一種情況，接收端正常收到兩個數(shù)據(jù)包，即沒有發(fā)生拆包和粘包的現(xiàn)象。

第二種情況，接收端只收到一個數(shù)據(jù)包，但是這一個數(shù)據(jù)包中包含了發(fā)送端發(fā)送的兩個數(shù)據(jù)包的信息，這種現(xiàn)象即為粘包。這種情況由于接收端不知道這兩個數(shù)據(jù)包的界限，所以對于接收端來說很難處理。

第三種情況，這種情況有兩種表現(xiàn)形式，如下圖。接收端收到了兩個數(shù)據(jù)包，但是這兩個數(shù)據(jù)包要么是不完整的，要么就是多出來一塊，這種情況即發(fā)生了拆包和粘包。這兩種情況如果不加特殊處理，對于接收端同樣是不好處理的。

為什么會發(fā)生 TCP 粘包、拆包？

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

粘包、拆包解決辦法

由于 TCP 本身是面向字節(jié)流的，無法理解上層的業(yè)務(wù)數(shù)據(jù)，所以在底層是無法保證數(shù)據(jù)包不被拆分和重組的，這個問題只能通過上層的應(yīng)用協(xié)議棧設(shè)計來解決，根據(jù)業(yè)界的主流協(xié)議的解決方案，歸納如下：

消息定長：發(fā)送端將每個數(shù)據(jù)包封裝為固定長度（不夠的可以通過補(bǔ) 0 填充），這樣接收端每次接收緩沖區(qū)中讀取固定長度的數(shù)據(jù)就自然而然的把每個數(shù)據(jù)包拆分開來。
設(shè)置消息邊界：服務(wù)端從網(wǎng)絡(luò)流中按消息邊界分離出消息內(nèi)容。在包尾增加回車換行符進(jìn)行分割，例如 FTP 協(xié)議。
將消息分為消息頭和消息體：消息頭中包含表示消息總長度（或者消息體長度）的字段。
更復(fù)雜的應(yīng)用層協(xié)議比如 Netty 中實現(xiàn)的一些協(xié)議都對粘包、拆包做了很好的處理。

問題：說說TCP 滑動窗口

窗口是緩存的一部分，用來暫時存放字節(jié)流。發(fā)送方和接收方各有一個窗口，接收方通過 TCP 報文段中的窗口字段告訴發(fā)送方自己的窗口大小，發(fā)送方根據(jù)這個值和其它信息設(shè)置自己的窗口大小。

發(fā)送窗口內(nèi)的字節(jié)都允許被發(fā)送，接收窗口內(nèi)的字節(jié)都允許被接收。如果發(fā)送窗口左部的字節(jié)已經(jīng)發(fā)送并且收到了確認(rèn)，那么就將發(fā)送窗口向右滑動一定距離，直到左部第一個字節(jié)不是已發(fā)送并且已確認(rèn)的狀態(tài)；接收窗口的滑動類似，接收窗口左部字節(jié)已經(jīng)發(fā)送確認(rèn)并交付主機(jī)，就向右滑動接收窗口。

接收窗口只會對窗口內(nèi)最后一個按序到達(dá)的字節(jié)進(jìn)行確認(rèn)，例如接收窗口已經(jīng)收到的字節(jié)為 {31, 34, 35}，其中 {31} 按序到達(dá)，而 {34, 35} 就不是，因此只對字節(jié) 31 進(jìn)行確認(rèn)。發(fā)送方得到一個字節(jié)的確認(rèn)之后，就知道這個字節(jié)之前的所有字節(jié)都已經(jīng)被接收。

說說TCP 流量控制？

流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來得及接收。

接收方發(fā)送的確認(rèn)報文中的窗口字段可以用來控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。將窗口字段設(shè)置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。

實際上，為了避免此問題的產(chǎn)生，發(fā)送端主機(jī)會時不時的發(fā)送一個叫做窗口探測的數(shù)據(jù)段，此數(shù)據(jù)段僅包含一個字節(jié)來獲取最新的窗口大小信息。

UDP 協(xié)議

UDP 是什么？

UDP（User Data Protocol，用戶數(shù)據(jù)報協(xié)議），是與 TCP 相對應(yīng)的協(xié)議。它是面向非連接的協(xié)議，它不與對方建立連接，而是直接就把數(shù)據(jù)包發(fā)送過去。

問題：UDP 主要特點

UDP 是無連接的。

UDP 使用盡最大努力交付，即不保證可靠交付，因此主機(jī)不需要維持復(fù)雜的鏈接狀態(tài)（這里面有許多參數(shù)）。

UDP 是面向報文的。

UDP 沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機(jī)的發(fā)送速率降低。

tcp與UDP的區(qū)別

TCP 是面向連接的；UDP 是無連接的。

TCP 是可靠的；UDP 是不可靠的。

TCP 只支持點對點通信；UDP 支持一對一、一對多、多對一、多對多的通信模式。

TCP 是面向字節(jié)流的；UDP 是面向報文的。

TCP 有擁塞控制機(jī)制；UDP 沒有擁塞控制，適合媒體通信。

TCP 首部開銷(20 個字節(jié))，比 UDP 的首部開銷(8 個字節(jié))要大。

問題：UDP 和 TCP 的特點與區(qū)別

用戶數(shù)據(jù)報協(xié)議 UDP（User Datagram Protocol）

是無連接的，盡最大可能交付，沒有擁塞控制，面向報文（對于應(yīng)用程序傳下來的報文不合并也不拆分，只是添加 UDP 首部），支持一對一、一對多、多對一和多對多的交互通信。

傳輸控制協(xié)議 TCP（Transmission Control Protocol）

是面向連接的，提供可靠交付，有流量控制，擁塞控制，提供全雙工通信，面向字節(jié)流（把應(yīng)用層傳下來的報文看成字節(jié)流，把字節(jié)流組織成大小不等的數(shù)據(jù)塊），每一條 TCP 連接只能是點對點的（一對一）。

問題：對比一下UDP 、TCP 首部格式？

UDP 首部字段如下：

UDP 首部字段只有 8 個字節(jié)，包括源端口、目的端口、長度、檢驗和。12 字節(jié)的偽首部是為了計算檢驗和臨時添加的。

TCP 首部字段如下：

TCP 首部格式比 UDP 復(fù)雜。

序號：用于對字節(jié)流進(jìn)行編號，例如序號為 301，表示第一個字節(jié)的編號為 301，如果攜帶的數(shù)據(jù)長度為 100 字節(jié)，那么下一個報文段的序號應(yīng)為 401。

確認(rèn)號：期望收到的下一個報文段的序號。例如 B 正確收到 A 發(fā)送來的一個報文段，序號為 501，攜帶的數(shù)據(jù)長度為 200 字節(jié)，因此 B 期望下一個報文段的序號為 701，B 發(fā)送給 A 的確認(rèn)報文段中確認(rèn)號就為 701。

數(shù)據(jù)偏移：指的是數(shù)據(jù)部分距離報文段起始處的偏移量，實際上指的是首部的長度。

控制位：八位從左到右分別是 CWR，ECE，URG，ACK，PSH，RST，SYN，F(xiàn)IN。

CWR：CWR 標(biāo)志與后面的 ECE 標(biāo)志都用于 IP 首部的 ECN 字段，ECE 標(biāo)志為 1 時，則通知對方已將擁塞窗口縮小；

ECE：若其值為 1 則會通知對方，從對方到這邊的網(wǎng)絡(luò)有阻塞。在收到數(shù)據(jù)包的 IP 首部中 ECN 為 1 時將 TCP 首部中的 ECE 設(shè)為 1；

URG：該位設(shè)為 1，表示包中有需要緊急處理的數(shù)據(jù)，對于需要緊急處理的數(shù)據(jù)，與后面的緊急指針有關(guān)；

ACK：該位設(shè)為 1，確認(rèn)應(yīng)答的字段有效，TCP規(guī)定除了最初建立連接時的 SYN 包之外該位必須設(shè)為 1；

PSH：該位設(shè)為 1，表示需要將收到的數(shù)據(jù)立刻傳給上層應(yīng)用協(xié)議，若設(shè)為 0，則先將數(shù)據(jù)進(jìn)行緩存；

RST：該位設(shè)為 1，表示 TCP 連接出現(xiàn)異常必須強(qiáng)制斷開連接；

SYN：用于建立連接，該位設(shè)為 1，表示希望建立連接，并在其序列號的字段進(jìn)行序列號初值設(shè)定；

FIN：該位設(shè)為 1，表示今后不再有數(shù)據(jù)發(fā)送，希望斷開連接。當(dāng)通信結(jié)束希望斷開連接時，通信雙方的主機(jī)之間就可以相互交換 FIN 位置為 1 的 TCP 段。

每個主機(jī)又對對方的 FIN 包進(jìn)行確認(rèn)應(yīng)答之后可以斷開連接。不過，主機(jī)收到 FIN 設(shè)置為 1 的 TCP 段之后不必馬上回復(fù)一個 FIN 包，而是可以等到緩沖區(qū)中的所有數(shù)據(jù)都因為已成功發(fā)送而被自動刪除之后再發(fā) FIN 包；

窗口：窗口值作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)。之所以要有這個限制，是因為接收方的數(shù)據(jù)緩存空間是有限的。

總結(jié)

以上是生活随笔為你收集整理的网络协议面试题（史上最全、持续更新、吐血推荐）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。