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

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

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

HTTP協(xié)議

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

? （1）、解析域名。

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

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

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

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

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

HTTP有哪些method。

? ★ GET：獲取資源。

? ★ POST：表單提交。

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

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

? ★ DELETE：刪除資源。

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

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

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

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

? 3）、散列算法：將文件內(nèi)容通過此算法加密變成固定長度的值（散列值），這個(gè)過程可以使用密鑰也可以不使用。這種散列變化是不可逆的，也就是說不能從散列值編程原文，因此散列變化通道常用語驗(yàn)證原文是否被篡改。典型的算法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 對(duì)傳輸?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é)議對(duì)于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息

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

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

URI和URL的區(qū)別

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

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

URI一般由三部組成：

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

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

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

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

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

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

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

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

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

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

200：請(qǐng)求被正常處理

204：請(qǐng)求被受理但沒有資源可以返回

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

301：永久性重定向

302：臨時(shí)重定向

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

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

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

400：請(qǐng)求報(bào)文語法有誤，服務(wù)器無法識(shí)別

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

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

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

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

503：服務(wù)器正忙

HTTP優(yōu)化方案

我下面就簡要概括一下：

TCP復(fù)用：TCP連接復(fù)用是將多個(gè)客戶端的HTTP請(qǐng)求復(fù)用到一個(gè)服務(wù)器端TCP連接上，而HTTP復(fù)用則是一個(gè)客戶端的多個(gè)HTTP請(qǐng)求通過一個(gè)TCP連接進(jìn)行處理。前者是負(fù)載均衡設(shè)備的獨(dú)特功能；而后者是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é)議對(duì)HTTP協(xié)議進(jìn)行加密，在通道內(nèi)加密并加速

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

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

區(qū)別一：

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

區(qū)別二：

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

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

區(qū)別三：

Get傳輸?shù)臄?shù)據(jù)量小，因?yàn)槭躑RL長度限制，但效率較高；

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

區(qū)別四：

get是不安全的，因?yàn)閁RL是可見的，可能會(huì)泄露私密信息，如密碼等；

post較get安全性較高；

區(qū)別五：

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

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

HTTP請(qǐng)求報(bào)文與響應(yīng)報(bào)文格式

請(qǐng)求報(bào)文包含三部分：

a、請(qǐng)求行：包含請(qǐng)求方法、URI、HTTP版本信息

b、請(qǐng)求首部字段

c、請(qǐng)求內(nèi)容實(shí)體

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

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

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

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

Session和cookie的區(qū)別。

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

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

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

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

http的請(qǐng)求報(bào)文是什么樣的？

請(qǐng)求報(bào)文有4部分組成:

請(qǐng)求行
請(qǐng)求頭部
空行
請(qǐng)求體

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

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

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

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

請(qǐng)求報(bào)文有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)容很多，重點(diǎn)看標(biāo)『✨』內(nèi)容

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

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

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

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

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

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

實(shí)體首部字段（Entiy Header Fields）:針對(duì)請(qǐng)求報(bào)文和響應(yīng)報(bào)文的實(shí)體部分使用首部

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

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

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

2XX 成功

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

3XX 重定向

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

4XX 客戶端錯(cuò)誤

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

5XX 服務(wù)器錯(cuò)誤

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

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

302是http1.0的協(xié)議狀態(tài)碼，在http1.1版本的時(shí)候?yàn)榱思?xì)化302狀態(tài)碼又出來了兩個(gè)303和307。

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

HTTP的keep-alive是干什么的？

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

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

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

HTTP2相對(duì)于HTTP1.x有什么優(yōu)勢(shì)和特點(diǎn)？

二進(jìn)制分幀

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

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

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

服務(wù)器推送

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

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

頭部壓縮

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

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

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

多路復(fù)用

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

HTTP2中：

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

HTTPS 是什么？

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

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

https是安全版的http，因?yàn)閔ttp協(xié)議的數(shù)據(jù)都是明文進(jìn)行傳輸?shù)模詫?duì)于一些敏感信息的傳輸就很不安全，HTTPS就是為了解決HTTP的不安全而生的。

HTTPS是如何保證安全的？

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

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

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

非對(duì)稱加密：

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

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

解決方案：

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

此時(shí)又帶來一個(gè)問題，中間人問題：

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

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

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

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

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

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

這個(gè)時(shí)候就能最大程度保證通信的安全了。

IO模型

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

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

TCP/IP等協(xié)議用于數(shù)據(jù)傳輸，但要完成通信，還需要對(duì)數(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(shí)，均為阻塞方式，直到應(yīng)用程序讀到了流或者將流寫入數(shù)據(jù)。

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

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

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

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

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

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

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

reactor 模型

當(dāng)客戶端請(qǐng)求抵達(dá)后，服務(wù)處理程序使用多路分配策略，由一個(gè)非阻塞的線程來接收所有的請(qǐng)求，然后派發(fā)這些請(qǐng)求至相關(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ù)）：主要解決用戶信息的語法表示問題，如加密解密

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

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

與不可靠的傳輸，傳輸層的錯(cuò)誤檢測(cè)，流量控制等

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

傳輸

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

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

TCP協(xié)議

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

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

TCP選項(xiàng)有哪些

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

TCP三次握手：

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

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

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

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

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

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

一、SYN洪泛攻擊

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

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

netstat -n -p TCP | grep SYN_RECV

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

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

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

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

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

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

三、死亡值ping

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

什么是 TCP 四次揮手？

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

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

接收方：好的，斷吧。

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

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

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

TIME_WAIT狀態(tài)存在有兩個(gè)原因。
一、可靠終止TCP連接。如果最后一個(gè)ACK報(bào)文因?yàn)榫W(wǎng)絡(luò)原因被丟棄，此時(shí)server因?yàn)闆]有收到ACK而超時(shí)重傳FIN報(bào)文，處于TIME_WAIT狀態(tài)的client可以繼續(xù)對(duì)FIN報(bào)文做回復(fù)，向server發(fā)送ACK報(bào)文。

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

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

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

由前兩節(jié)可知，UDP 是基于報(bào)文發(fā)送的，UDP首部采用了 16bit 來指示 UDP 數(shù)據(jù)報(bào)文的長度，因此在應(yīng)用層能很好的將不同的數(shù)據(jù)報(bào)文區(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ù)長度的字段，基于上面兩點(diǎn)，在使用 TCP 傳輸數(shù)據(jù)時(shí)，才有粘包或者拆包現(xiàn)象發(fā)生的可能。

什么是粘包、拆包？

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

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

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

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

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

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

粘包、拆包解決辦法

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

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

問題：說說TCP 滑動(dòng)窗口

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

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

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

說說TCP 流量控制？

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

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

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

UDP 協(xié)議

UDP 是什么？

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

問題：UDP 主要特點(diǎn)

UDP 是無連接的。

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

UDP 是面向報(bào)文的。

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

tcp與UDP的區(qū)別

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

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

TCP 只支持點(diǎn)對(duì)點(diǎn)通信；UDP 支持一對(duì)一、一對(duì)多、多對(duì)一、多對(duì)多的通信模式。

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

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

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

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

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

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

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

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

問題：對(duì)比一下UDP 、TCP 首部格式？

UDP 首部字段如下：

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

TCP 首部字段如下：

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

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

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

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

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

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

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

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

ACK：該位設(shè)為 1，確認(rèn)應(yīng)答的字段有效，TCP規(guī)定除了最初建立連接時(shí)的 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，表示希望建立連接，并在其序列號(hào)的字段進(jìn)行序列號(hào)初值設(shè)定；

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

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

窗口：窗口值作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)。之所以要有這個(gè)限制，是因?yàn)榻邮辗降臄?shù)據(jù)緩存空間是有限的。

總結(jié)

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

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