網絡協議面試題（史上最全、持續更新、吐血推薦）

文章很長，建議收藏起來，慢慢讀! 瘋狂創客圈爲小夥伴奉上如下珍貴的學習資源：

• 瘋狂創客圈 經典圖書 ： 《Netty Zookeeper Redis 高併發實戰》 面試必備 + 大廠必備 + 漲薪必備
• 瘋狂創客圈 經典圖書 ： 《SpringCloud、Nginx高併發核心編程》 面試必備 + 大廠必備 + 漲薪必備
• 資源寶庫： Java程序員必備 網盤資源大集合 價值>1000元 隨便取 GO->【博客園總入口 】
• 獨孤九劍：Netty靈魂實驗 ： 本地 100W鏈接 高併發實驗，瞬間提高Java內力
• 技術、面試交流：和大廠 小夥伴、技術高手、架構師 進行 純粹的的技術問題交流、探討求助、問題圍觀學習

---

推薦： 瘋狂創客圈 高質量 博文

高併發 必讀 的精彩博文
nacos 實戰（史上最全）	sentinel （史上最全+入門教程）
Zookeeper 分佈式鎖 （圖解+秒懂+史上最全）	Webflux（史上最全）
SpringCloud gateway （史上最全）	TCP/IP（圖解+秒懂+史上最全）
10分鐘看懂， Java NIO 底層原理	Feign原理 （圖解）
更多精彩博文 .....	請參見【 瘋狂創客圈 高併發 總目錄 】

---

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

精心梳理、吐血推薦、史上最強、建議收藏	阿里、京東、美團、頭條.... 隨意挑、橫着走！！！
1.Java算法面試題（史上最強、持續更新、吐血推薦）	2.Java基礎面試題（史上最全、持續更新、吐血推薦）
3.JVM面試題（史上最強、持續更新、吐血推薦）	四、架構設計面試題 （史上最全、持續更新、吐血推薦）
五、Spring面試題 專題	六、SpringMVC面試題 專題
7.SpringBoot - 面試題（史上最強、持續更新）	八、Tomcat面試題 專題部分
9.網絡協議面試題（史上最全、持續更新、吐血推薦）	十、TCP/IP協議（圖解+秒懂+史上最全）
11.JUC併發包與容器 - 面試題（史上最強、持續更新）	十二、設計模式面試題 （史上最全、持續更新、吐血推薦）
13.死鎖面試題（史上最強、持續更新）	15.Zookeeper 分佈式鎖 （圖解+秒懂+史上最全）
1四、Redis 面試題 - 收藏版（史上最強、持續更新）	1六、Zookeeper 面試題（史上最強、持續更新）
1七、分佈式事務面試題 （史上最全、持續更新、吐血推薦）	1八、一致性協議 （史上最全）
1九、Zab協議 (史上最全)	20、Paxos 圖解 (秒懂)
2一、raft 圖解 (秒懂)	2六、消息隊列、RabbitMQ、Kafka、RocketMQ面試題 （史上最全、持續更新）
22.Linux面試題（史上最全、持續更新、吐血推薦）	2三、Mysql 面試題（史上最強、持續更新）
2四、SpringCloud 面試題 - 收藏版（史上最強、持續更新）	2五、Netty 面試題 （史上最強、持續更新）
2七、內存泄漏 內存溢出（史上最全）	2八、JVM 內存溢出 實戰 （史上最全）

---

史上最全 Java 面試題：網絡協議 篇

HTTP協議

當你用瀏覽器打開一個連接的時候，計算機作了哪些工做步驟。

​ （1）、解析域名。

​ （2）、發起TCP的3次握手。

​ （3）、創建TCP請求後發起HTTP請求。

​ （4）、服務器相應HTTP請求。

​ （5）、瀏覽器獲得HTML代碼，進行解析和處理JSON數據，並請求HTML代碼中的靜態資源（JS、CSS、圖片等）。

​ （6）、瀏覽器對頁面進行渲染。

HTTP有哪些method。

​ ★ GET：獲取資源。

​ ★ POST：表單提交。

​ ★ HEAD：獲取報頭信息，HEAD 方法與 GET 方法相似，但並不會返回響應主體。

​ ★ PUT 與PATCH：更新資源，PUT 對後臺來講 PUT 方法的參數是一個完整的資源對象，它包含了對象的全部字段，PATCH 對後臺來講 PATCH 方法的參數只包含咱們須要修改的資源對象的字段。

​ ★ DELETE：刪除資源。

​ ★ OPTIONS：獲取目標資源所支持的通訊選項,使用 OPTIONS 方法對服務器發起請求,以檢測服務器支持哪些 HTTP 方法。

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

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

​ 2）、非對稱密碼算法：又稱爲公鑰加密算法，是指加密和解密使用不一樣的密鑰，加密速度較慢，但能提供更好的身份認證技術，用來加密對稱加密的密鑰（公開的密鑰用於加密，私有的密鑰用於解密）典型的算法RSA、DSA、DH。

​ 3）、散列算法：將文件內容經過此算法加密變成固定長度的值（散列值），這個過程可使用密鑰也能夠不使用。這種散列變化是不可逆的，也就是說不能從散列值編程原文，所以散列變化通道經常使用語驗證原文是否被篡改。典型的算法MD五、SHA、BASE6四、CRC等。

Http與Https的區別：

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

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

HTTP 標準端口是80 ，而 HTTPS 的標準端口是443

在OSI 網絡模型中，HTTP工做於應用層，而HTTPS 的安全傳輸機制工做在傳輸層

HTTP 沒法加密，而HTTPS 對傳輸的數據進行加密

HTTP無需證書，而HTTPS 須要CA機構頒發的SSL證書

什麼是Http協議無狀態協議?怎麼解決Http協議無狀態協議?

無狀態協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息

也就是說，當客戶端一次HTTP請求完成之後，客戶端再發送一次HTTP請求，HTTP並不知道當前客戶端是一個」老用戶「。

可使用Cookie來解決無狀態的問題，Cookie就至關於一個通行證，第一次訪問的時候給客戶端發送一個Cookie，當客戶端再次來的時候，拿着Cookie(通行證)，那麼服務器就知道這個是」老用戶「

URI和URL的區別

URI，是uniform resource identifier，統一資源標識符，用來惟一的標識一個資源。

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

URI通常由三部組成：

①訪問資源的命名機制

②存放資源的主機名

③資源自身的名稱，由路徑表示，着重強調於資源。

URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL能夠用來標識一個資源，並且還指明瞭如何locate這個資源。

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

採用URL能夠用一種統一的格式來描述各類信息資源，包括文件、服務器的地址和目錄等。URL通常由三部組成：

①協議(或稱爲服務方式)

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

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

常見的HTTP相應狀態碼

200：請求被正常處理

204：請求被受理但沒有資源能夠返回

206：客戶端只是請求資源的一部分，服務器只對請求的部分資源執行GET方法，相應報文中經過Content-Range指定範圍的資源。

301：永久性重定向

302：臨時重定向

303：與302狀態碼有類似功能，只是它但願客戶端在請求一個URI的時候，能經過GET方法重定向到另外一個URI上

304：發送附帶條件的請求時，條件不知足時返回，與重定向無關

307：臨時重定向，與302相似，只是強制要求使用POST方法

400：請求報文語法有誤，服務器沒法識別

401：請求須要認證

403：請求的對應資源禁止被訪問

404：服務器沒法找到對應資源

500：服務器內部錯誤

503：服務器正忙

HTTP優化方案

我下面就簡要歸納一下：

TCP複用：TCP鏈接複用是將多個客戶端的HTTP請求複用到一個服務器端TCP鏈接上，而HTTP複用則是一個客戶端的多個HTTP請求經過一個TCP鏈接進行處理。前者是負載均衡設備的獨特功能；然後者是HTTP 1.1協議所支持的新功能

內容緩存：將常常用到的內容進行緩存起來，那麼客戶端就能夠直接在內存中獲取相應的數據了。

壓縮：將文本數據進行壓縮，減小帶寬

SSL加速（SSL Acceleration）：使用SSL協議對HTTP協議進行加密，在通道內加密並加速

TCP緩衝：經過採用TCP緩衝技術，能夠提升服務器端響應時間和處理效率，減小因爲通訊鏈路問題給服務器形成的鏈接負擔。

GET方法與POST方法的區別

區別一：

get重點在從服務器上獲取資源，post重點在向服務器發送數據；

區別二：

get傳輸數據是經過URL請求，以field（字段）= value的形式，置於URL後，並用"?"鏈接，多個請求數據間用"&"鏈接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，這個過程用戶是可見的；

post傳輸數據經過Http的post機制，將字段與對應值封存在請求實體中發送給服務器，這個過程對用戶是不可見的；

區別三：

Get傳輸的數據量小，由於受URL長度限制，但效率較高；

Post能夠傳輸大量數據，因此上傳文件時只能用Post方式；

區別四：

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

post較get安全性較高；

區別五：

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

post支持標準字符集，能夠正確傳遞中文字符。

HTTP請求報文與響應報文格式

請求報文包含三部分：

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

b、請求首部字段

c、請求內容實體

響應報文包含三部分：

a、狀態行：包含HTTP版本、狀態碼、狀態碼的緣由短語

b、響應首部字段

c、響應內容實體

Session和cookie的區別。

​ （1）、Cookie保存在客戶端，未設置存儲時間的Cookie，關閉瀏覽器會話Cookie就會被刪除；設置了存儲時間的Cookie保存在用戶設備的磁盤中知道過時，同時Cookie在客戶端因此能夠僞造，不是十分安全，敏感數據不易保存。Session保存在服務器端，存儲在IIS的進程開闢的內存中，而Session過多會消耗服務器資源，因此儘可能少使用Session。

​ （2）、Session是服務器用來跟蹤用戶的一種手段，每一個Session都有一個惟一標識：session ID。當服務端生成一個Session時就會向客戶端發送一個Cookie保存到客戶端，這個Cookie保存的是Session的SessionId這樣才能保證客戶端發起請求後，用戶可以與服務器端成千上萬的Session進行匹配，同時也保證了不一樣頁面之間傳值的正確性.

​ （3）、存儲數據類型不一樣：Session可以存儲任意的JAVA對象，Cookie只能存儲String類型的對象。

​ （4）、長於10K的數據，不要用到Cookies。

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

請求報文有4部分組成:

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

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

1. User-Agent：產生請求的瀏覽器類型。
2. Accept：客戶端可識別的內容類型列表。
3. Host：請求的主機名，容許多個域名同處一個IP地址，即虛擬主機。

• 請求體: post put等請求攜帶的數據

http的響應報文是什麼樣的？

請求報文有4部分組成:

• 響應行
• 響應頭
• 空行
• 響應體

• 響應行： 由協議版本，狀態碼和狀態碼的緣由短語組成，例如HTTP/1.1 200 OK。
• 響應頭：響應部首組成
• 響應體：服務器響應的數據

聊一聊HTTP的部首有哪些？

內容不少，重點看標『✨』內容

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

• Cache-Control 控制緩存 ✨
• Connection 鏈接管理、逐條首部 ✨
• Upgrade 升級爲其餘協議
• via 代理服務器的相關信息
• Wraning 錯誤和警告通知
• Transfor-Encoding 報文主體的傳輸編碼格式 ✨
• Trailer 報文末端的首部一覽
• Pragma 報文指令
• Date 建立報文的日期

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

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

響應首部字段（Response Header Fields）:從服務器向客戶端響應時使用的字段

• Accept-Ranges 能接受的字節範圍
• Age 推算資源建立通過時間
• Location 令客戶端重定向的URI ✨
• vary 代理服務器的緩存信息
• ETag 可以表示資源惟一資源的字符串 ✨
• WWW-Authenticate 服務器要求客戶端的驗證信息
• Proxy-Authenticate 代理服務器要求客戶端的驗證信息
• Server 服務器的信息 ✨
• Retry-After 和狀態碼503 一塊兒使用的首部字段，表示下次請求服務器的時間

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

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

聊一聊HTTP的狀態碼有哪些？

內容不少，重點看標『✨』內容

2XX 成功

• 200 OK，表示從客戶端發來的請求在服務器端被正確處理 ✨
• 201 Created 請求已經被實現，並且有一個新的資源已經依據請求的須要而創建
• 202 Accepted 請求已接受，可是還沒執行，不保證完成請求
• 204 No content，表示請求成功，但響應報文不含實體的主體部分
• 206 Partial Content，進行範圍請求 ✨

3XX 重定向

• 301 moved permanently，永久性重定向，表示資源已被分配了新的 URL
• 302 found，臨時性重定向，表示資源臨時被分配了新的 URL ✨
• 303 see other，表示資源存在着另外一個 URL，應使用 GET 方法丁香獲取資源
• 304 not modified，表示服務器容許訪問資源，但因發生請求未知足條件的狀況
• 307 temporary redirect，臨時重定向，和302含義相同

4XX 客戶端錯誤

• 400 bad request，請求報文存在語法錯誤 ✨
• 401 unauthorized，表示發送的請求須要有經過 HTTP 認證的認證信息 ✨
• 403 forbidden，表示對請求資源的訪問被服務器拒絕 ✨
• 404 not found，表示在服務器上沒有找到請求的資源 ✨
• 408 Request timeout, 客戶端請求超時
• 409 Confict, 請求的資源可能引發衝突

5XX 服務器錯誤

• 500 internal sever error，表示服務器端在執行請求時發生了錯誤 ✨
• 501 Not Implemented 請求超出服務器能力範圍，例如服務器不支持當前請求所須要的某個功能，或者請求是服務器不支持的某個方法
• 503 service unavailable，代表服務器暫時處於超負載或正在停機維護，沒法處理請求
• 505 http version not supported 服務器不支持，或者拒絕支持在請求中使用的 HTTP 版本

一樣是重定向307，303，302的區別？

302是http1.0的協議狀態碼，在http1.1版本的時候爲了細化302狀態碼又出來了兩個303和307。

303明確表示客戶端應當採用get方法獲取資源，他會把POST請求變爲GET請求進行重定向。 307會遵守瀏覽器標準，不會從post變爲get。

HTTP的keep-alive是幹什麼的？

在早期的HTTP/1.0中，每次http請求都要建立一個鏈接，而建立鏈接的過程須要消耗資源和時間，爲了減小資源消耗，縮短響應時間，就須要重用鏈接。在後來的HTTP/1.0中以及HTTP/1.1中，引入了重用鏈接的機制，就是在http請求頭中加入Connection: keep-alive來告訴對方這個請求響應完成後不要關閉，下一次我們還用這個請求繼續交流。協議規定HTTP/1.0若是想要保持長鏈接，須要在請求頭中加上Connection: keep-alive。

keep-alive的優勢：

• 較少的CPU和內存的使用（因爲同時打開的鏈接的減小了）
• 容許請求和應答的HTTP管線化
• 下降擁塞控制 （TCP鏈接減小了）
• 減小了後續請求的延遲（無需再進行握手）
• 報告錯誤無需關閉TCP連

HTTP2相對於HTTP1.x有什麼優點和特色？

二進制分幀

幀：HTTP/2 數據通訊的最小單位消息：指 HTTP/2 中邏輯上的 HTTP 消息。例如請求和響應等，消息由一個或多個幀組成。

流：存在於鏈接中的一個虛擬通道。流能夠承載雙向消息，每一個流都有一個惟一的整數ID

HTTP/2 採用二進制格式傳輸數據，而非 HTTP 1.x 的文本格式，二進制協議解析起來更高效。

服務器推送

服務端能夠在發送頁面HTML時主動推送其它資源，而不用等到瀏覽器解析到相應位置，發起請求再響應。例如服務端能夠主動把JS和CSS文件推送給客戶端，而不須要客戶端解析HTML時再發送這些請求。

服務端能夠主動推送，客戶端也有權利選擇是否接收。若是服務端推送的資源已經被瀏覽器緩存過，瀏覽器能夠經過發送RST_STREAM幀來拒收。主動推送也遵照同源策略，服務器不會隨便推送第三方資源給客戶端。

頭部壓縮

HTTP/1.x會在請求和響應中中重複地攜帶不常改變的、冗長的頭部數據，給網絡帶來額外的負擔。

• HTTP/2在客戶端和服務器端使用「首部表」來跟蹤和存儲以前發送的鍵－值對，對於相同的數據，再也不經過每次請求和響應發送
• 首部表在HTTP/2的鏈接存續期內始終存在，由客戶端和服務器共同漸進地更新;
• 每一個新的首部鍵－值對要麼被追加到當前表的末尾，要麼替換表中以前的值。

你能夠理解爲只發送差別數據，而不是所有發送，從而減小頭部的信息量

多路複用

HTTP 1.x 中，若是想併發多個請求，必須使用多個 TCP 連接，且瀏覽器爲了控制資源，還會對單個域名有 6-8個的TCP連接請求限制。

HTTP2中：

• 同域名下全部通訊都在單個鏈接上完成。
• 單個鏈接能夠承載任意數量的雙向數據流。
• 數據流以消息的形式發送，而消息又由一個或多個幀組成，多個幀之間能夠亂序發送，由於根據幀首部的流標識能夠從新組裝

HTTPS 是什麼？

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

爲何有了HTTP爲何還要HTTPS？

https是安全版的http，由於http協議的數據都是明文進行傳輸的，因此對於一些敏感信息的傳輸就很不安全，HTTPS就是爲了解決HTTP的不安全而生的。

HTTPS是如何保證安全的？

過程比較複雜，咱們得先理解兩個概念

對稱加密：即通訊的雙方都使用同一個祕鑰進行加解密，好比特務接頭的暗號，就屬於對稱加密

對稱加密雖然很簡單性能也好，可是沒法解決首次把祕鑰發給對方的問題，很容易被hacker攔截祕鑰。

非對稱加密：

1. 私鑰 + 公鑰= 密鑰對
2. 即用私鑰加密的數據,只有對應的公鑰才能解密,用公鑰加密的數據,只有對應的私鑰才能解密
3. 由於通訊雙方的手裏都有一套本身的密鑰對,通訊以前雙方會先把本身的公鑰都先發給對方
4. 而後對方再拿着這個公鑰來加密數據響應給對方,等到到了對方那裏,對方再用本身的私鑰進行解密

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

解決方案：

那麼結合兩種加密方式，將對稱加密的密鑰使用非對稱加密的公鑰進行加密，而後發送出去，接收方使用私鑰進行解密獲得對稱加密的密鑰，而後雙方可使用對稱加密來進行溝通。

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

若是此時在客戶端和服務器之間存在一箇中間人,這個中間人只須要把本來雙方通訊互發的公鑰,換成本身的公鑰,這樣中間人就能夠輕鬆解密通訊雙方所發送的全部數據。

因此這個時候須要一個安全的第三方頒發證書（CA），證實身份的身份，防止被中間人攻擊。

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

可是問題來了，若是中間人篡改了證書，那麼身份證實是否是就無效了？這個證實就白買了，這個時候須要一個新的技術，數字簽名。

數字簽名就是用CA自帶的HASH算法對證書的內容進行HASH獲得一個摘要，再用CA的私鑰加密，最終組成數字簽名。

當別人把他的證書發過來的時候,我再用一樣的Hash算法,再次生成消息摘要，而後用CA的公鑰對數字簽名解密,獲得CA建立的消息摘要,二者一比,就知道中間有沒有被人篡改了。

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

IO模型

nio和 bio 、aio的區別

消息時的系統通訊，一般基於網絡協議實現。常見的協議包括TCP/IP,UDP/IP。

TCP/IP等協議用於數據傳輸，但要完成通訊，還須要對數據進行處理。例如讀取和寫入數據。

I/O能夠分爲兩種：同步IO和異步IO,同步I/O最多見的是 BIO(Blocking IO)、NIO(Non-Blocking IO)

BIO：是當發起I/O的讀或寫操做時，均爲阻塞方式，直到應用程序讀到了流或者將流寫入數據。

NIO：基於事件驅動思想，常採用reactor（反應器）模式。當發起 IO請求時，應用程序是非阻塞的。當SOCKET有流可讀或寫的時候，

由操做系統通知應用程序，應用程序再將流讀取到緩衝區或者寫入系統。

AIO：一樣基於事件驅動的思想，一般採用Proactor(前攝器模式)實現。對於讀操做，操做系統將數據讀到緩衝區，並通知應用程序，對於寫操做，操做系統將write方法傳遞的流寫入並主動通知

應用程序。它節省了NIO中遍歷事件通知隊列的代價。

阻塞　某個請求發出後，因爲該請求操做須要的條件不知足，請求操做一直阻塞，不會返回，直到條件知足。

非阻塞　請求發出後，若該請求須要的條件不知足，則當即返回一個標誌信息告知條件不知足，而不會一直等待。通常須要經過循環判斷請求條件是否知足來獲取請求結果。

這裏注意比較NIO和AIO的不一樣，AIO是操做系統完成IO並通知應用程序，NIO是操做系統通知應用程序，由應用程序完成。

reactor 模型

當客戶端請求抵達後，服務處理程序使用多路分配策略，由一個非阻塞的線程來接收全部的請求，而後派發這些請求至相關的工做線程進行處理

TCP協議

網絡的七層結構及其做用

自上而下是：

應用層（數據）：肯定進程之間通訊的性質以知足用戶須要以及提供網絡與用戶應用

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

會話層（數據）：提供包括訪問驗證和會話管理在內的創建和維護應用之間通訊的機制，如服務器驗證用戶登陸即是由會話層完成的

傳輸層（段）：實現網絡不一樣主機上用戶進程之間的數據通訊，可靠

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

網絡層（包）：提供邏輯地址（IP）、選路，數據從源端到目的端的

傳輸

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

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

TCP協議

TCP/IP協議按照層次分爲如下四層。應用層、傳輸層、網絡層、數據鏈路層。

TCP（Transmission Control Protocol，傳輸控制協議）是面向鏈接的協議，也就是說，在收發數據前，必須和對方創建可靠的鏈接。一個TCP鏈接必需要通過三次「對話」才能創建起來，其中的過程很是複雜，

TCP選項有哪些

TCP首部選項字段多達40B，一些經常使用的字段有：
　　
　　1）選項結束字段（EOP，0x00），佔1B，一個報文段僅用一次。放在末尾用於填充，用途是說明：首部已經沒有更多的消息，應用數據在下一個32位字開始處
　　2）無操做字段（NOP, 0x01），佔1B，也用於填充，放在選項的開頭
　　3）MSS（最大報文段長度），格式以下：種類（1B，值爲2），長度（1B，值爲4），數值（2B）
　　用於在鏈接開始時肯定MSS的大小，若是沒有肯定，就用默認的（通常實現是536B）
　　4）窗口擴大因子，格式以下：種類（1B，值爲3），長度（1B，值爲3),數值（1B）
　　新窗口值 = 首部窗口值 * 2的（擴大因子）次方
　　當通訊雙方認爲首部的窗口值還不夠大的時候，在鏈接開始時用這個來定義更大的窗口。僅在鏈接開始時有效。一經定義，通訊過程當中沒法更改。
　　5）時間戳（應用測試RTT和防止序號繞回）
　　6）容許SACK和SACK選項

TCP三次握手：

發送方：我要和你創建連接？

接收方：你真的要和我創建連接麼？

發送方：我真的要和你創建連接，成功。

爲何 TCP 鏈接須要三次握手，兩次不能夠麼，爲何？

爲了防止已失效的鏈接請求報文忽然又傳送到了服務端，於是產生錯誤。客戶端發出的鏈接請求報文並未丟失，而是在某個網絡節點長時間滯留了，以至延誤到連接釋放之後的某個時間纔到達 Server 。

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

1、SYN洪泛攻擊

服務器處於SYN_Wait的狀態：

　　1）假裝的IP向服務器發送一個SYN請求創建鏈接，而後服務器向該IP回覆SYN和ACK，可是找不到該IP對應的主機，當超時時服務器收不到ACK會重複發送。當大量的攻擊者請求創建鏈接時，服務器就會存在大量未完成三次握手的鏈接，服務器主機backlog被耗盡而不能響應其它鏈接。即SYN泛洪攻擊 （屬於DOS的一種，發送大量的半鏈接請求，耗費CPU和內存資源，引發網絡堵塞甚至系統癱瘓）
　　
　　當你在服務器上看到大量的半鏈接狀態時，特別是源IP地址是隨機的，基本上能夠判定這是一次SYN攻擊.在Linux下能夠以下命令檢測是否被Syn攻擊

netstat -n -p TCP | grep SYN_RECV

防範措施：
　　一、下降SYN timeout時間，使得主機儘快釋放半鏈接的佔用
　　二、採用SYN cookie設置，若是短期內連續收到某個IP的重複SYN請求，則認爲受到了該IP的攻擊，丟棄來自該IP的後續請求報文
　　三、在網關處設置過濾，拒絕將一個源IP地址不屬於其來源子網的包進行更遠的路由
　　
　　2）當一個主機向服務器發送SYN請求鏈接，服務器回覆ACK和SYN後，攻擊者截獲ACK和SYN。而後假裝成原始主機繼續與服務器進行通訊。

2、DOS攻擊 拒絕服務攻擊

DDoS（分佈式拒絕服務攻擊）
DOS攻擊利用合理的服務請求佔用過多的服務資源，使正經常使用戶的請求沒法獲得相應。

常見的DOS攻擊有計算機網絡帶寬攻擊和連通性攻擊。

帶寬攻擊指以極大的通訊量衝擊網絡，使得全部可用網絡資源都被消耗殆盡，最後致使合法的用戶請求沒法經過。

連通性攻擊指用大量的鏈接請求衝擊計算機，使得全部可用的操做系統資源都被消耗殆盡，最終計算機沒法再處理合法用戶的請求。

3、死亡值ping

許多操做系統的TCP/IP協議棧規定ICMP包大小爲64KB（網間控制報文），且在對包的標題頭進行讀取以後，要根據該標題頭裏包含的信息來爲有效載荷生成緩衝區。
」死亡值ping」就是故意產生畸形的測試ping包，聲稱本身的尺寸超過ICMP上限，也就是加載的尺寸超過64KB上限，使未採起保護措施的網絡系統出現內存分配錯誤，致使TCP/IP協議棧崩潰，最終接收方宕機。

什麼是 TCP 四次揮手？

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

發送方：我要和你斷開鏈接！

接收方：好的，斷吧。

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

發送方：好的，斷吧。

問題：爲何要有TIME_WAIT狀態？

TIME_WAIT狀態存在有兩個緣由。
1、可靠終止TCP鏈接。若是最後一個ACK報文由於網絡緣由被丟棄，此時server由於沒有收到ACK而超時重傳FIN報文，處於TIME_WAIT狀態的client能夠繼續對FIN報文作回覆，向server發送ACK報文。

2、保證讓遲來的TCP報文段有足夠的時間被識別和丟棄。鏈接結束了，網絡中的延遲報文也應該被丟棄掉，以避免影響馬上創建的新鏈接。

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

爲何常說 TCP 有粘包和拆包的問題而不說 UDP ？

由前兩節可知，UDP 是基於報文發送的，UDP首部採用了 16bit 來指示 UDP 數據報文的長度，所以在應用層能很好的將不一樣的數據報文區分開，從而避免粘包和拆包的問題。

而 TCP 是基於字節流的，雖然應用層和 TCP 傳輸層之間的數據交互是大小不等的數據塊，可是 TCP 並無把這些數據塊區分邊界，僅僅是一連串沒有結構的字節流；另外從 TCP 的幀結構也能夠看出，在 TCP 的首部沒有表示數據長度的字段，基於上面兩點，在使用 TCP 傳輸數據時，纔有粘包或者拆包現象發生的可能。

什麼是粘包、拆包？

假設 Client 向 Server 連續發送了兩個數據包，用 packet1 和 packet2 來表示，那麼服務端收到的數據能夠分爲三種狀況，現列舉以下：

第一種狀況，接收端正常收到兩個數據包，即沒有發生拆包和粘包的現象。

第二種狀況，接收端只收到一個數據包，可是這一個數據包中包含了發送端發送的兩個數據包的信息，這種現象即爲粘包。這種狀況因爲接收端不知道這兩個數據包的界限，因此對於接收端來講很難處理。

第三種狀況，這種狀況有兩種表現形式，以下圖。接收端收到了兩個數據包，可是這兩個數據包要麼是不完整的，要麼就是多出來一塊，這種狀況即發生了拆包和粘包。這兩種狀況若是不加特殊處理，對於接收端一樣是很差處理的。

爲何會發生 TCP 粘包、拆包？

• 要發送的數據大於 TCP 發送緩衝區剩餘空間大小，將會發生拆包。
• 待發送數據大於 MSS（最大報文長度），TCP 在傳輸前將進行拆包。
• 要發送的數據小於 TCP 發送緩衝區的大小，TCP 將屢次寫入緩衝區的數據一次發送出去，將會發生粘包。
• 接收數據端的應用層沒有及時讀取接收緩衝區中的數據，將發生粘包。

粘包、拆包解決辦法

因爲 TCP 自己是面向字節流的，沒法理解上層的業務數據，因此在底層是沒法保證數據包不被拆分和重組的，這個問題只能經過上層的應用協議棧設計來解決，根據業界的主流協議的解決方案，概括以下：

• 消息定長：發送端將每一個數據包封裝爲固定長度（不夠的能夠經過補 0 填充），這樣接收端每次接收緩衝區中讀取固定長度的數據就天然而然的把每一個數據包拆分開來。
• 設置消息邊界：服務端從網絡流中按消息邊界分離出消息內容。在包尾增長回車換行符進行分割，例如 FTP 協議。
• 將消息分爲消息頭和消息體：消息頭中包含表示消息總長度（或者消息體長度）的字段。
• 更復雜的應用層協議好比 Netty 中實現的一些協議都對粘包、拆包作了很好的處理。

問題：說說TCP 滑動窗口

窗口是緩存的一部分，用來暫時存放字節流。發送方和接收方各有一個窗口，接收方經過 TCP 報文段中的窗口字段告訴發送方本身的窗口大小，發送方根據這個值和其它信息設置本身的窗口大小。

發送窗口內的字節都容許被髮送，接收窗口內的字節都容許被接收。若是發送窗口左部的字節已經發送而且收到了確認，那麼就將發送窗口向右滑動必定距離，直到左部第一個字節不是已發送而且已確認的狀態；接收窗口的滑動相似，接收窗口左部字節已經發送確認並交付主機，就向右滑動接收窗口。

接收窗口只會對窗口內最後一個按序到達的字節進行確認，例如接收窗口已經收到的字節爲 {31, 34, 35}，其中 {31} 按序到達，而 {34, 35} 就不是，所以只對字節 31 進行確認。發送方獲得一個字節的確認以後，就知道這個字節以前的全部字節都已經被接收。

說說TCP 流量控制？

流量控制是爲了控制發送方發送速率，保證接收方來得及接收。

接收方發送的確認報文中的窗口字段能夠用來控制發送方窗口大小，從而影響發送方的發送速率。將窗口字段設置爲 0，則發送方不能發送數據。

實際上，爲了不此問題的產生，發送端主機會時不時的發送一個叫作窗口探測的數據段，此數據段僅包含一個字節來獲取最新的窗口大小信息。

UDP 協議

UDP 是什麼？

UDP（User Data Protocol，用戶數據報協議），是與 TCP 相對應的協議。它是面向非鏈接的協議，它不與對方創建鏈接，而是直接就把數據包發送過去。

問題：UDP 主要特色

UDP 是無鏈接的。

UDP 使用盡最大努力交付，即不保證可靠交付，所以主機不須要維持複雜的連接狀態（這裏面有許多參數）。

UDP 是面向報文的。

UDP 沒有擁塞控制，所以網絡出現擁塞不會使源主機的發送速率下降。

tcp與UDP的區別

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

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

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

TCP 是面向字節流的；UDP 是面向報文的。

TCP 有擁塞控制機制；UDP 沒有擁塞控制，適合媒體通訊。

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

問題：UDP 和 TCP 的特色與區別

用戶數據報協議 UDP（User Datagram Protocol）

是無鏈接的，盡最大可能交付，沒有擁塞控制，面向報文（對於應用程序傳下來的報文不合並也不拆分，只是添加 UDP 首部），支持一對1、一對多、多對一和多對多的交互通訊。

傳輸控制協議 TCP（Transmission Control Protocol）

是面向鏈接的，提供可靠交付，有流量控制，擁塞控制，提供全雙工通訊，面向字節流（把應用層傳下來的報文當作字節流，把字節流組織成大小不等的數據塊），每一條 TCP 鏈接只能是點對點的（一對一）。

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

UDP 首部字段以下：

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

TCP 首部字段以下：

TCP 首部格式比 UDP 複雜。

序號：用於對字節流進行編號，例如序號爲 301，表示第一個字節的編號爲 301，若是攜帶的數據長度爲 100 字節，那麼下一個報文段的序號應爲 401。

確認號：指望收到的下一個報文段的序號。例如 B 正確收到 A 發送來的一個報文段，序號爲 501，攜帶的數據長度爲 200 字節，所以 B 指望下一個報文段的序號爲 701，B 發送給 A 的確認報文段中確認號就爲 701。

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

控制位：八位從左到右分別是 CWR，ECE，URG，ACK，PSH，RST，SYN，FIN。

CWR：CWR 標誌與後面的 ECE 標誌都用於 IP 首部的 ECN 字段，ECE 標誌爲 1 時，則通知對方已將擁塞窗口縮小；

ECE：若其值爲 1 則會通知對方，從對方到這邊的網絡有阻塞。在收到數據包的 IP 首部中 ECN 爲 1 時將 TCP 首部中的 ECE 設爲 1；

URG：該位設爲 1，表示包中有須要緊急處理的數據，對於須要緊急處理的數據，與後面的緊急指針有關；

ACK：該位設爲 1，確認應答的字段有效，TCP規定除了最初創建鏈接時的 SYN 包以外該位必須設爲 1；

PSH：該位設爲 1，表示須要將收到的數據馬上傳給上層應用協議，若設爲 0，則先將數據進行緩存；

RST：該位設爲 1，表示 TCP 鏈接出現異常必須強制斷開鏈接；

SYN：用於創建鏈接，該位設爲 1，表示但願創建鏈接，並在其序列號的字段進行序列號初值設定；

FIN：該位設爲 1，表示從此再也不有數據發送，但願斷開鏈接。當通訊結束但願斷開鏈接時，通訊雙方的主機之間就能夠相互交換 FIN 位置爲 1 的 TCP 段。

每一個主機又對對方的 FIN 包進行確認應答以後能夠斷開鏈接。不過，主機收到 FIN 設置爲 1 的 TCP 段以後沒必要立刻回覆一個 FIN 包，而是能夠等到緩衝區中的全部數據都由於已成功發送而被自動刪除以後再發 FIN 包；

窗口：窗口值做爲接收方讓發送方設置其發送窗口的依據。之因此要有這個限制，是由於接收方的數據緩存空間是有限的。