目錄

OSI 的五層模型分別是？各自的功能是什么？

應(yīng)用層

傳輸層

網(wǎng)絡(luò)層

數(shù)據(jù)鏈路層

物理層

OSI 的七層模型分別是？

TCP連接的建立

三次握手中客戶端和服務(wù)端是什么狀態(tài)

為什么是三次，不是兩次？

四次可以不？

為什么客戶端和服務(wù)端的初始化序號ISN不同

什么是SYN攻擊，如何解決？

四次揮手流程

為什么 TIME-WAIT 狀態(tài)必須等待 2MSL 的時(shí)間呢？

TIME_WAIT 狀態(tài)會導(dǎo)致什么問題，怎么解決

TCP與UDP有哪些區(qū)別？各自應(yīng)用場景？

應(yīng)用場景

TCP無界，UDP有界是指？

TCP面向字節(jié)流 無界，UDP面向報(bào)文 有界；

TCP字節(jié)流和UDP數(shù)據(jù)報(bào)區(qū)別

TCP如何進(jìn)行面向字節(jié)流的數(shù)據(jù)傳輸

TCP的主要特點(diǎn)

UDP的主要特點(diǎn)

TCP如何實(shí)現(xiàn)可靠傳輸

談下你對流量控制的理解？

談?wù)勀銓瑒哟翱诘牧私?#xff1f;

TCP 如何進(jìn)行擁塞控制原理

慢啟動+擁塞窗口+閾值+擁塞避免

快重傳，快恢復(fù)

剛剛提到的超時(shí)重傳的原理是？

談?wù)勀銓νＶ沟却齾f(xié)議的理解？

談?wù)勀銓?ARQ 協(xié)議的理解？

為什么ARP查詢要在廣播幀中發(fā)送,而ARP響應(yīng)要用單播幀

什么是粘包和拆包？

怎么解決拆包和粘包？

TCP 最大連接數(shù)限制

HTTP1.0，1.1，2.0 的版本區(qū)別

POST和GET有哪些區(qū)別？各自應(yīng)用場景？

HTTP 狀態(tài)碼

301 302應(yīng)用場景

在交互過程中如果數(shù)據(jù)傳送完了，還不想斷開連接怎么辦，怎么維持？

HTTP 如何實(shí)現(xiàn)長連接？在什么時(shí)候會超時(shí)？

談下你對 HTTP 長連接和短連接的理解？分別應(yīng)用于哪些場景？

應(yīng)用場景

簡單說下 HTTPS 和 HTTP 的區(qū)別

HTTPS 的工作過程？

總結(jié)

為什么HTTPS數(shù)據(jù)傳輸是用對稱加密？

為什么需要 CA 認(rèn)證機(jī)構(gòu)頒發(fā)證書？

什么是數(shù)字簽名？

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

瀏覽器是如何確保 CA 證書的合法性？

只有認(rèn)證機(jī)構(gòu)可以生成證書嗎？

本地隨機(jī)數(shù)被竊取怎么辦？

用了 HTTPS 會被抓包嗎？

既然 HTTPS 不能防抓包，那 HTTPS 有什么意義？

Cookie 和 Session 有什么區(qū)別？

GET請求中URL編碼的意義

forward 和 redirect 的區(qū)別？

轉(zhuǎn)發(fā)：forward

重定向:redirect

體會

在瀏覽器中輸入 URL 地址到顯示主頁的過程？

URL 與 URI的關(guān)系

DNS 的解析過程

談?wù)勀銓τ蛎彺娴牧私?#xff1f;

以根域名為例

以本地域名服務(wù)器為例

DNS 為什么用 UDP

簡單說下怎么實(shí)現(xiàn) DNS 劫持

什么是SQL 注入？舉個例子？

實(shí)例

應(yīng)對方法

IP 分類

IPV4 地址不夠如何解決

NAT是指？

IP地址和MAC地址有什么區(qū)別？各自的用處？

ARP 協(xié)議的工作原理？

ARP欺騙？

ICMP 有哪些應(yīng)用？

功能

類型

應(yīng)用

OSI 的五層模型分別是？各自的功能是什么？

應(yīng)用層

我們最接近的一層，應(yīng)用程序均在這一層實(shí)現(xiàn)，通信時(shí)信息向下傳也就是傳輸層

以 Http 請求為例

發(fā)送方：URL解析，生成HTTP請求信息，DNS域名轉(zhuǎn)化IP

接收方：收到了傳輸層傳來的數(shù)據(jù)，可是這些傳過來的數(shù)據(jù)五花八門，有html格式的，有mp4格式的，各種各樣。因此我們需要指定這些數(shù)據(jù)的格式規(guī)則，收到后才好解讀渲染。最常見的 Http 數(shù)據(jù)包中，就會指定該數(shù)據(jù)包是 什么格式的文件了。

傳輸層

傳輸層負(fù)責(zé)接受應(yīng)用層的數(shù)據(jù) 和 向應(yīng)用層傳輸數(shù)據(jù)；其中兩個重要的協(xié)議TCP和UDP；

TCP：建立連接，數(shù)據(jù)分割，生成報(bào)文（可靠傳輸，擁塞控制等）

UDP：生成報(bào)文（盡最大能力交付）

TCP 和 UDP 報(bào)文中兩個重要的字段就是 源端口和目標(biāo)端口；向應(yīng)用層傳輸數(shù)據(jù)時(shí)，通過端口區(qū)分不同的應(yīng)用程序，以供特定的應(yīng)用程序來接受處理

從宏觀 網(wǎng)絡(luò)傳輸上看 傳輸層負(fù)責(zé)端到端的數(shù)據(jù)傳輸；

網(wǎng)絡(luò)層

為網(wǎng)絡(luò)中數(shù)據(jù)傳輸提供支持，將數(shù)據(jù)傳輸?shù)侥繕?biāo)主機(jī)；重要的協(xié)議 IP；

IP數(shù)據(jù)報(bào)兩個關(guān)鍵的字段 源地址 目標(biāo)地址?

IP協(xié)議將傳輸層的報(bào)文作為數(shù)據(jù)部分，進(jìn)行封裝、分片等操作，得到IP報(bào)文并發(fā)送；IP協(xié)議可以為我們尋找到目標(biāo)主機(jī)所在的位置；

數(shù)據(jù)鏈路層

決定 數(shù)據(jù)要去的下一個位置，通過網(wǎng)絡(luò)中的設(shè)備的IP和MAC地址映射關(guān)系，確定下一跳；

同時(shí)負(fù)責(zé) 數(shù)據(jù)的封幀?和 差錯檢測 透明傳輸；

封裝成幀：數(shù)據(jù)的封幀 遵循以太網(wǎng)協(xié)議。以太網(wǎng)協(xié)議規(guī)定，一組電信號構(gòu)成一個數(shù)據(jù)包，我們把這個數(shù)據(jù)包稱之為幀。每一個楨由標(biāo)頭(Head)和數(shù)據(jù)(Data)兩部分組成。MTU：最大傳輸單元；幀數(shù)據(jù)部分，受MTU限制大小<=1500字節(jié)【以太網(wǎng)標(biāo)準(zhǔn)】假如需要傳送的數(shù)據(jù)很大的話，就分成多個楨來進(jìn)行傳送。

差錯檢驗(yàn)：因?yàn)槲锢韺涌赡軐?dǎo)致比特傳輸差錯，數(shù)據(jù)鏈路層保證向上層（傳輸層）提供的數(shù)據(jù)是無差錯的；常用的校驗(yàn)方法 CRC校驗(yàn)

透明傳輸：幀頭 幀尾出現(xiàn)在數(shù)據(jù)部分時(shí)，使用轉(zhuǎn)義字符

物理層

將數(shù)據(jù)轉(zhuǎn)化成電信號，讓其可以在物理介質(zhì)中傳播；調(diào)制解調(diào)

OSI 的七層模型分別是？

將應(yīng)用層分成：

會話層：負(fù)責(zé)建?、管理和終?表示層實(shí)體之間的通信會話

表示層：負(fù)責(zé)把數(shù)據(jù)轉(zhuǎn)換成兼容另?個系統(tǒng)能識別的格式；

應(yīng)用層：負(fù)責(zé)給應(yīng)?程序提供統(tǒng)?的接?；

TCP連接的建立

三次握手

客戶端向服務(wù)端發(fā)送連接請求；服務(wù)端向客戶端發(fā)送確認(rèn)請求；客戶端向服務(wù)端發(fā)送確認(rèn)的確認(rèn)，同時(shí)帶有應(yīng)用數(shù)據(jù)； 連接建立

具體細(xì)節(jié)：客戶端A 服務(wù)端B

客戶端向服務(wù)端發(fā)送連接請求: A ->B 序號sqe = x；確認(rèn)號 ack = 0； 同步意向SYN = 1；確認(rèn)號標(biāo)志 ACK = 0;

服務(wù)端向客戶端發(fā)送確認(rèn)請求: B->A 序號 Sqe = y; 確認(rèn)號 ack = x+1; 同步意向SYN = 1；確認(rèn)號標(biāo)志 ACK = 1;

客戶端向服務(wù)端發(fā)送確認(rèn)的確認(rèn): A - >B 序號 sqe = x+1；確認(rèn)號 ack = y+1； 同步意向 SYN = 0；確認(rèn)號標(biāo)志ACK = 1；

sqe：數(shù)據(jù)包序號

ack：確認(rèn)收到數(shù)據(jù)，并提供 準(zhǔn)備接受下一個數(shù)據(jù)的序號

SYN：建立連接意向（發(fā)起連接時(shí)為 1，三次握手的前兩次）

ACK：ack是否有效；

三次握手中客戶端和服務(wù)端是什么狀態(tài)

客戶端A 服務(wù)端B

開始：A:closed; B:closed

客戶端向服務(wù)端發(fā)送連接請求: A: SYN-sent; B: Listen

服務(wù)端向客戶端發(fā)送確認(rèn)請求: A: 收到之后 established B: 發(fā)送之后 SYN_recvd

客戶端向服務(wù)端發(fā)送確認(rèn)的確認(rèn): A:established B: 收到之后 established

為什么是三次，不是兩次？

“第三次握手”是客戶端向服務(wù)器端發(fā)送數(shù)據(jù)，這個數(shù)據(jù)就是要告訴服務(wù)器，客戶端有沒有收到服務(wù)器“第二次握手”時(shí)傳過去的數(shù)據(jù)。

若發(fā)送的這個數(shù)據(jù)是“收到了”的信息，接收后服務(wù)器就正常建立TCP連接，否則建立TCP連接失敗，服務(wù)器關(guān)閉連接端口。由此減少服務(wù)器開銷和接收到失效請求發(fā)生的錯誤。

避免錯誤連接，造成服務(wù)器長時(shí)間等待

1.某個客戶端發(fā)來的錯誤連接請求(比如由于超時(shí)被客戶端丟棄的連接)，發(fā)送到服務(wù)端；2. 服務(wù)端發(fā)送確認(rèn)請求；3.客戶端收到請求之后會直接丟棄（任務(wù)是錯誤請求數(shù)據(jù)）4. 服務(wù)端則會任務(wù)，連接已經(jīng)建立，持續(xù)等待--；

三次握手的話，3.中 客戶端根據(jù)歷史信息，知道這是錯誤鏈接，可以直接向服務(wù)端發(fā)送一個rst報(bào)文，終止這次連接

同步雙方的初始化序號

一來一回同步雙方的序號，序號的作用: 數(shù)據(jù)去重，數(shù)據(jù)排序，數(shù)據(jù)校驗(yàn)等

四次可以不？

可以，但三次足夠四次浪費(fèi)了資源；

為什么客戶端和服務(wù)端的初始化序號ISN不同

區(qū)分報(bào)文，根據(jù)序號將不屬于本連接的報(bào)文丟棄；

什么是SYN攻擊，如何解決？

偽造不同客戶端IP 向服務(wù)端發(fā)送請求；使服務(wù)器長時(shí)間進(jìn)入SYN-RCVD狀態(tài)；

解決方法：

SYN泛洪攻擊原理及預(yù)防策略詳解

四次揮手流程

四次揮手中，主動分手的一方需要等待被分手的一方進(jìn)行一定的準(zhǔn)備工作；

大致流程：

第一次揮手：A 告訴 B ，‘’我要分手“；

第二次揮手：B回復(fù)A，“ 嗯，我知道了，我準(zhǔn)備以下 ”

第三次揮手：B告訴A，‘’我準(zhǔn)備好了可以分手了‘’

第四次揮手：A告訴B，‘’有緣再見‘’

等待一會兒，A拉黑了聯(lián)系方式（A怕有緣再見的消息，B沒有收到），B如果沒有收到有緣再見會重新發(fā)送‘’我準(zhǔn)備好了可以分手了‘’；

這里 第二次揮手的準(zhǔn)備是指 "當(dāng)B把自己該發(fā)送的數(shù)據(jù)發(fā)送完成";

具體細(xì)節(jié)

客戶端A 向服務(wù)端B發(fā)起釋放連接請求

1. A—>B：序號seq = x，FIN=1
   客戶端A 停止發(fā)送數(shù)據(jù)，處于FIN_WAIT1狀態(tài)
2. B—>A：序號seq = y，確認(rèn)號ack = x+1，FIN=0；
   服務(wù)端B收到 FIN報(bào)文之后，會發(fā)送一個 ack=x+1?的ACK報(bào)文，處于CLOSE_WAIT狀態(tài)；
   客戶端A收到ACK報(bào)文之后，由FIN_WAIT1->FIN_WAIT2狀態(tài)，現(xiàn)在客戶端A只需等待服務(wù)端B發(fā)送FIN報(bào)文請求釋放連接即可
3. B—>A：序號seq = z，確認(rèn)號ack = x+1（如果步驟2之后直接3，B也正好沒有想傳的數(shù)據(jù)時(shí)），FIN=1;
   當(dāng)服務(wù)端B也把自己該發(fā)送的數(shù)據(jù)發(fā)送完成，也會給客戶端發(fā)送一個FIN報(bào)文，且指定一個序列號，此時(shí)服務(wù)端B 由CLOSE_WAIT->LAST_ACK狀態(tài)，等待客戶端A的ACK報(bào)文;
4. A—>B：序號seq = x+1，確認(rèn)號ack = z+1，FIN=0，此時(shí)客戶端處于 TIME_WAIT （時(shí)間等待）狀態(tài), 服務(wù)端B收到后 —>CLOSED

• FIN：和SYN相反，SYN請求建立連接，那么FIN報(bào)文就是請求斷開連接
• seq：報(bào)文首個字節(jié)的序號
• ACK：確認(rèn)報(bào)文
• ack：確認(rèn)號，希望收到下一個報(bào)文的首個字節(jié)的序號

為什么 TIME-WAIT 狀態(tài)必須等待 2MSL 的時(shí)間呢？

1. 為了保證 A 發(fā)送的最后一個 ACK 報(bào)文段能夠到達(dá) B。這個 ACK 報(bào)文段有可能丟失，因而使處在 LAST-ACK 狀態(tài)的 B 收不到對已發(fā)送的 FIN + ACK 報(bào)文段的確認(rèn)。B 會超時(shí)重傳這個 FIN+ACK 報(bào)文段，而 A 就能在 2MSL 時(shí)間內(nèi)（超時(shí) + 1MSL 傳輸）收到這個重傳的 FIN+ACK 報(bào)文段。接著 A 重傳一次確認(rèn)，重新啟動 2MSL 計(jì)時(shí)器。最后，A 和 B 都正常進(jìn)入到 CLOSED 狀態(tài)。如果 A 在 TIME-WAIT 狀態(tài)不等待一段時(shí)間，而是在發(fā)送完 ACK 報(bào)文段后立即釋放連接，那么就無法收到 B 重傳的 FIN + ACK 報(bào)文段，因而也不會再發(fā)送一次確認(rèn)報(bào)文段，這樣，B 就無法按照正常步驟進(jìn)入 CLOSED 狀態(tài)。

2. 防止已失效的連接請求報(bào)文段出現(xiàn)在本連接中。A 在發(fā)送完最后一個 ACK 報(bào)文段后，再經(jīng)過時(shí)間 2MSL，就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失。這樣就可以使下一個連接中不會出現(xiàn)這種舊的連接請求報(bào)文段。

TIME_WAIT 狀態(tài)會導(dǎo)致什么問題，怎么解決

我們考慮高并發(fā)短連接的業(yè)務(wù)場景，在高并發(fā)短連接的 TCP 服務(wù)器上，當(dāng)服務(wù)器處理完請求后主動請求關(guān)閉連接，這樣服務(wù)器上會有大量的連接處于 TIME_WAIT 狀態(tài)，服務(wù)器維護(hù)每一個連接需要一個 socket，也就是每個連接會占用一個文件描述符，而文件描述符的使用是有上限的，如果持續(xù)高并發(fā)，會導(dǎo)致一些正常的 連接失敗。

解決方案：使得服務(wù)器處于 TIME-WAIT 狀態(tài)下的端口能夠快速回收和重用。不再等待 2MSL 的時(shí)間

TCP與UDP有哪些區(qū)別？各自應(yīng)用場景？

TCP是面向連接(Connection oriented)的協(xié)議，UDP是無連接(Connection less)協(xié)議；

TCP無界，UDP有界；

TCP可靠，UDP不可靠；

TCP有序，UDP無序；

TCP有流量控制（擁塞控制），UDP沒有；

TCP的頭部比UDP大；

TCP 一對一，UDP隨意

應(yīng)用場景

TCP應(yīng)用場景：效率要求相對低，但對準(zhǔn)確性要求相對高的場景。因?yàn)閭鬏斨行枰獙?shù)據(jù)確認(rèn)、重發(fā)、排序等操作，相比之下效率沒有UDP高。舉幾個例子：文件傳輸（準(zhǔn)確高要求高、但是速度可以相對慢）、接受郵件、遠(yuǎn)程登錄。

UDP應(yīng)用場景：效率要求相對高，對準(zhǔn)確性要求相對低的場景。舉幾個例子：QQ聊天、在線視頻、網(wǎng)絡(luò)語音電話（即時(shí)通訊，速度要求高，但是出現(xiàn)偶爾斷續(xù)不是太大問題，并且此處完全不可以使用重發(fā)機(jī)制）、廣播通信（廣播、多播）。

TCP無界，UDP有界是指？

TCP面向字節(jié)流 無界，UDP面向報(bào)文 有界；

TCP通過字節(jié)流傳輸，即TCP將應(yīng)用程序看成是一連串的無結(jié)構(gòu)的字節(jié)流，（并不是說不用報(bào)文傳輸）。每個TCP套接口有一個發(fā)送緩沖區(qū)，如果字節(jié)流太長時(shí)，TCP會將其拆分進(jìn)行發(fā)送。當(dāng)字節(jié)流太短時(shí)，TCP會等待緩沖區(qū)中的字節(jié)流達(dá)到一定程度時(shí)再構(gòu)成報(bào)文發(fā)送出去，TCP發(fā)給對方的數(shù)據(jù)，對方在收到數(shù)據(jù)時(shí)必須給矛確認(rèn)，只有在收到對方的確認(rèn)時(shí)，本方TCP才會把TCP發(fā)送緩沖區(qū)中的數(shù)據(jù)刪除。

而UDP傳輸報(bào)文的方式是由應(yīng)用程序控制的，應(yīng)用層交給UDP多長的報(bào)文，UDP照樣發(fā)送，既不拆分，也不合并，而是保留這些報(bào)文的邊界，即一次發(fā)送一個報(bào)文。

有界與無界之分是根據(jù)接收報(bào)文來劃分的

對于TCP協(xié)議，客戶端連續(xù)發(fā)送數(shù)據(jù)，只要服務(wù)端的這個函數(shù)的緩沖區(qū)足夠大，會一次性接收過來，即客戶端是分好幾次發(fā)過來，是有邊界的，而服務(wù)端卻一次性接收過來，所以證明是無邊界的；

而對于UDP協(xié)議，客戶端連續(xù)發(fā)送數(shù)據(jù)，即使服務(wù)端的這個函數(shù)的緩沖區(qū)足夠大，也只會一次一次的接收，發(fā)送多少次接收多少次，即客戶端分幾次發(fā)送過來，服務(wù)端就必須按幾次接收，從而證明，這種UDP的通訊模式是有邊界的。

TCP字節(jié)流和UDP數(shù)據(jù)報(bào)區(qū)別

兩者的區(qū)別在于TCP接收的是一堆數(shù)據(jù)，而每次取多少由主機(jī)決定;而UDP發(fā)的是數(shù)據(jù)報(bào)，客戶發(fā)送多少就接收多少。

擁有這些區(qū)別的原因是由于TCP和UDP的特性不同而決定的。TCP是面向連接的，也就是說，在連接持續(xù)的過程中，socket中收到的數(shù)據(jù)都是由同一臺主機(jī)發(fā)出的，因此，知道保證數(shù)據(jù)是有序的到達(dá)就行了，至于每次讀取多少數(shù)據(jù)自己看著辦。

而UDP是無連接的協(xié)議，也就是說，只要知道接收端的IP和端口，且網(wǎng)絡(luò)是可達(dá)的，任何主機(jī)都可以向接收端發(fā)送數(shù)據(jù)。這時(shí)候，如果一次能讀取超過一個報(bào)文的數(shù)據(jù)，則會亂套。比如，主機(jī)A向發(fā)送了報(bào)文P1，主機(jī)B發(fā)送了報(bào)文P2，如果能夠讀取超過一個報(bào)文的數(shù)據(jù)，那么就會將P1和P2的數(shù)據(jù)合并在了一起，這樣的數(shù)據(jù)是沒有意義的。

TCP如何進(jìn)行面向字節(jié)流的數(shù)據(jù)傳輸

而TCP是把字節(jié)數(shù)據(jù)丟到TCP緩沖區(qū)，等發(fā)送時(shí)會不時(shí)地從緩存中取一塊數(shù)據(jù)并臨時(shí)加上TCP首部字段，形成TCP報(bào)文段，并下傳到網(wǎng)絡(luò)層，網(wǎng)絡(luò)層進(jìn)一步封裝；接受方接收到TCP數(shù)據(jù)報(bào)后，舍棄TCP首部，然后按序放入TCP緩存區(qū)中。由于放入TCP緩存區(qū)時(shí)，已經(jīng)是純粹的字節(jié)數(shù)據(jù)了，難以區(qū)分哪些字節(jié)數(shù)據(jù)原本是"打算當(dāng)作一個整體"讀取的，所以TCP會有粘包、拆包問題。（TCP開發(fā)，往往需要自己給TCP數(shù)據(jù)添加一些邊界標(biāo)識和數(shù)據(jù)長度，方便處理粘包、拆包問題）。

從緩存中取一塊數(shù)據(jù)的大小受限于 MSS最大傳輸單元

TCP的主要特點(diǎn)

1. 面向連接，數(shù)據(jù)傳輸前需要建立連接
2. 點(diǎn)對點(diǎn)，主機(jī)對主機(jī)
3. 可靠傳輸，無差錯，不丟失，按序達(dá)
4. 擁塞控制，網(wǎng)絡(luò)出現(xiàn)擁塞會使源主機(jī)的發(fā)送速率降低
5. 全雙工，發(fā)送端雙方都有緩存來臨時(shí)存放數(shù)據(jù)
6. 字節(jié)流，TCP 把應(yīng)用程序交下來的數(shù)據(jù)僅僅看成是一連串的無結(jié)構(gòu)的字節(jié)流。

UDP的主要特點(diǎn)

1. UDP 是無連接的；
2. UDP 使用盡最大努力交付，即不保證可靠交付，因此主機(jī)不需要維持復(fù)雜的鏈接狀態(tài)（這里面有許多參數(shù)）；
3. UDP 沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機(jī)的發(fā)送速率降低（對實(shí)時(shí)應(yīng)用很有用，如 直播，實(shí)時(shí)視頻會議等）；
4. UDP 支持一對一、一對多、多對一和多對多的交互通信；
5. UDP 的首部開銷小，只有 8 個字節(jié)，比 TCP 的 20 個字節(jié)的首部要短。

TCP如何實(shí)現(xiàn)可靠傳輸

1. 數(shù)據(jù)包校驗(yàn)：目的是檢測數(shù)據(jù)在傳輸過程中的任何變化，若校驗(yàn)出包有錯，則丟棄報(bào)文段并且不給出響應(yīng)，這時(shí) TCP 發(fā)送數(shù)據(jù)端超時(shí)后會重發(fā)數(shù)據(jù)；
2. 序號：對失序數(shù)據(jù)包重排序，既然 TCP 報(bào)文段作為 IP 數(shù)據(jù)報(bào)來傳輸，而 IP 數(shù)據(jù)報(bào)的到達(dá)可能會失序，因此 TCP 報(bào)文段的到達(dá)也可能會失序。TCP 將對失序數(shù)據(jù)進(jìn)行重新排序；對于重復(fù)數(shù)據(jù)，能夠丟棄重復(fù)數(shù)據(jù)；然后才交給應(yīng)用層；
3. 應(yīng)答機(jī)制：當(dāng) TCP 收到發(fā)自 TCP 連接另一端的數(shù)據(jù)，它將發(fā)送一個確認(rèn)。告訴對方此數(shù)據(jù)已收到；
4. 重傳機(jī)制（超時(shí)重傳，快速重傳）：滑動窗口協(xié)議提升重傳機(jī)制的效率；累計(jì)確認(rèn)提升滑動窗口協(xié)議傳輸效率；選擇性確認(rèn)在累計(jì)確認(rèn)的基礎(chǔ)上提升了丟失報(bào)文后 數(shù)據(jù)傳輸?shù)男?#xff1b;
5. 流量控制：TCP 連接的每一方都有固定大小的緩沖空間。TCP 的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)，這可以防止較快主機(jī)致使較慢主機(jī)的緩沖區(qū)溢出，這就是流量控制。TCP 使用的流量控制協(xié)議是可變大小的滑動窗口協(xié)議。

談下你對流量控制的理解？

TCP 利用滑動窗口實(shí)現(xiàn)流量控制。流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來得及接收。接收方發(fā)送的確認(rèn)報(bào)文中的窗口字段可以用來控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。將窗口字段設(shè)置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。

談?wù)勀銓瑒哟翱诘牧私?#xff1f;

滑動窗口是一種考慮對方緩存情況的流量控制技術(shù)；

滑動窗口包含的數(shù)據(jù)由兩部分組成 （發(fā)送窗口）已發(fā)送未確認(rèn)數(shù)據(jù)，（可用窗口）未發(fā)送數(shù)據(jù)； 窗口的大小重復(fù)考慮接收方緩存的接受能力；

當(dāng)可用為 0 時(shí)，發(fā)送方一般不能再發(fā)送數(shù)據(jù)報(bào)

但有兩種情況除外，一種情況是可以發(fā)送緊急數(shù)據(jù)，例如，允許用戶終止在遠(yuǎn)端機(jī)上的運(yùn)行進(jìn)程。另一種情況是發(fā)送方可以發(fā)送一個 1 字節(jié)的數(shù)據(jù)報(bào)來通知接收方重新聲明它希望接收的下一字節(jié)及發(fā)送方的滑動窗口大小。

隨著收到ACK包的到來，窗口慢慢移動；繼續(xù)傳輸數(shù)據(jù)；

TCP 如何進(jìn)行擁塞控制原理

TCP的擁塞控制采用了四種算法：1.慢啟動2.擁塞避免3.快重傳4.快恢復(fù)

慢啟動+擁塞窗口+閾值+擁塞避免

發(fā)送數(shù)據(jù)的size為擁塞窗口和接受窗口的較小者

慢啟動：擁塞窗口 初始化1 每經(jīng)過一個往返時(shí)間RTT?指數(shù)級翻倍增長

擁塞避免：擁塞窗口到達(dá) 閾值 后+1增長；

快重傳，快恢復(fù)

快重傳：在 TCP 傳輸過程中，如果發(fā)生了丟包，接收端就會發(fā)送之前重復(fù) ACK，比如 第 5 個包丟了，6、7 達(dá)到，然后接收端會為 5，6，7 都發(fā)送第4個包的 ACK，這個時(shí)候發(fā)送端受到了 3 個重復(fù)的 ACK，意識到丟包了，就會馬上進(jìn)行重傳，而不用等到 RTO （超時(shí)重傳的時(shí)間）

快恢復(fù)：出現(xiàn)擁塞（丟包），擁塞窗口不是 降為1，而是降為原來的1/2, 擁塞窗口大小變?yōu)閾砣撝? 接著 擁塞窗口再進(jìn)行線性增加，以適應(yīng)網(wǎng)絡(luò)狀況

剛剛提到的超時(shí)重傳的原理是？

超時(shí)重傳時(shí)間：

超時(shí)重傳時(shí)間我們一般用 RTO（Retransmission Timeout） 來表示，那么，這個 RTO 設(shè)置為多少最合適呢，也就是說經(jīng)過多長時(shí)間進(jìn)行重傳最好？

在這之前，我們先講解一下 RTT（Round-Trip Time 往返時(shí)延） 的概念：就是報(bào)文段的往返時(shí)間顯然超時(shí)重傳的

顯然RTO應(yīng)略微大于RTT即可

• 如果RTO遠(yuǎn)大于RTT，就會造成網(wǎng)絡(luò)空閑時(shí)間過長，效率下降
• 如果RTO小于RTT，那么就會造成不必要的重傳，資源浪費(fèi)

如果超時(shí)重傳也失敗了，每次的等待時(shí)間都會成倍增長，1-2-4-8，但是這會導(dǎo)致一個問題，就是周期太長了，效率比較低，那么有沒有什么改進(jìn)的方法呢？——快速重傳

談?wù)勀銓νＶ沟却齾f(xié)議的理解？

它的基本原理就是每發(fā)完一個分組就停止發(fā)送，等待對方確認(rèn)。在收到確認(rèn)后再發(fā)下一個分組；

在停止等待協(xié)議中，若接收方收到重復(fù)分組，就丟棄該分組，但同時(shí)還要發(fā)送確認(rèn)。主要包括以下幾種情況：

• 無差錯情況
• 出現(xiàn)差錯情況：發(fā)送包丟失、確認(rèn)包丟失（超時(shí)重傳）和確認(rèn)遲到（無為）。

談?wù)勀銓?ARQ 協(xié)議的理解？

Automatic Repeat-reQuest 自動重傳請求

自動重傳請求 ARQ 協(xié)議

其實(shí)是停止等待協(xié)議的一部分，不過主要是針對異常情況；

超時(shí)重傳是指只要超過一段時(shí)間仍然沒有收到確認(rèn)，就重傳前面發(fā)送過的分組（認(rèn)為剛才發(fā)送過的分組丟失了）。因此每發(fā)送完一個分組需要設(shè)置一個超時(shí)計(jì)時(shí)器，其重傳時(shí)間應(yīng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r(shí)間更長一些。

這種自動重傳方式常稱為自動重傳請求 ARQ。

連續(xù) ARQ 協(xié)議

連續(xù) ARQ 協(xié)議可提高信道利用率。發(fā)送方維持一個發(fā)送窗口，凡位于發(fā)送窗口內(nèi)的分組可以連續(xù)發(fā)送出去，而不需要等待對方確認(rèn)。接收方一般采用累計(jì)確認(rèn)，對按序到達(dá)的最后一個分組發(fā)送確認(rèn)，表明到這個分組為止的所有分組都已經(jīng)正確收到了，常用于滑動窗口一起用

為什么ARP查詢要在廣播幀中發(fā)送,而ARP響應(yīng)要用單播幀

查詢前是不知道目的主機(jī)具體的mac地址，通過廣播的方式，讓局域網(wǎng)所有主機(jī)收到這個以太網(wǎng)幀，而只有目的主機(jī)會從接收的幀中解出ip數(shù)據(jù)報(bào)并知道了源主機(jī)的ip地址，然后發(fā)送一個arp響應(yīng)的時(shí)候就只需要單播就能找到源主機(jī)了

什么是粘包和拆包？

在進(jìn)行 Java NIO 學(xué)習(xí)時(shí)，可能會發(fā)現(xiàn)：如果客戶端連續(xù)不斷的向服務(wù)端發(fā)送數(shù)據(jù)包時(shí)，服務(wù)端接收的數(shù)據(jù)會出現(xiàn)兩個數(shù)據(jù)包粘在一起的情況。

1. TCP 是基于字節(jié)流的，雖然應(yīng)用層和 TCP 傳輸層之間的數(shù)據(jù)交互是大小不等的數(shù)據(jù)塊，但是 TCP 把這些數(shù)據(jù)塊僅僅看成一連串無結(jié)構(gòu)的字節(jié)流，沒有邊界；
2. 從?TCP 的幀結(jié)構(gòu)也可以看出，在 TCP 的首部沒有表示數(shù)據(jù)長度的字段。

基于上面，在使用 TCP 傳輸數(shù)據(jù)時(shí)，才有粘包或者拆包現(xiàn)象發(fā)生的可能。一個數(shù)據(jù)包中包含了發(fā)送端發(fā)送的兩個數(shù)據(jù)包的信息，這種現(xiàn)象即為粘包。

粘包：

1. 要發(fā)送的數(shù)據(jù)小于TCP發(fā)送緩沖區(qū)的大小，TCP將多次寫入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去；
2. 接收數(shù)據(jù)端的應(yīng)用層沒有及時(shí)讀取接收緩沖區(qū)中的數(shù)據(jù)；
3. 數(shù)據(jù)發(fā)送過快，數(shù)據(jù)包堆積導(dǎo)致緩沖區(qū)積壓多個數(shù)據(jù)后才一次性發(fā)送出去(如果客戶端每發(fā)送一條數(shù)據(jù)就睡眠一段時(shí)間就不會發(fā)生粘包)；

拆包：

過大的數(shù)據(jù)（大于MSS）會被拆分，報(bào)文傳輸中 又出現(xiàn)粘包，不屬于同一數(shù)據(jù)段的部分合在了一起；

怎么解決拆包和粘包？

分包機(jī)制一般有兩個通用的解決方法：

1. 特殊字符控制；
2. 在包頭首都添加數(shù)據(jù)包的長度。

如果使用 netty 的話，就有專門的編碼器和解碼器解決拆包和粘包問題了。

tips：UDP 沒有粘包問題，但是有丟包和亂序。不完整的包是不會有的，收到的都是完全正確的包。傳送的數(shù)據(jù)單位協(xié)議是 UDP 報(bào)文或用戶數(shù)據(jù)報(bào)，發(fā)送的時(shí)候既不合并，也不拆分。

TCP 最大連接數(shù)限制

端口

如何標(biāo)識一個TCP連接

在確定最大連接數(shù)之前，先來看看系統(tǒng)如何標(biāo)識一個tcp連接。系統(tǒng)用一個4四元組來唯一標(biāo)識一個TCP連接：{local ip, local port,remote ip,remote port}。

client最大tcp連接數(shù)

client每次發(fā)起tcp連接請求時(shí)，除非綁定端口，通常會讓系統(tǒng)選取一個空閑的本地端口（local port），該端口是獨(dú)占的，不能和其他tcp連接共享。tcp端口的數(shù)據(jù)類型是unsigned short，因此本地端口個數(shù)最大只有65536，端口0有特殊含義，不能使用，這樣可用端口最多只有65535，所以在全部作為client端的情況下，最大tcp連接數(shù)為65535，這些連接可以連到不同的server ip。

server最大tcp連接數(shù)

server通常固定在某個本地端口上監(jiān)聽，等待client的連接請求。

不考慮地址重用（unix的SO_REUSEADDR選項(xiàng)）的情況下，即使server端有多個ip，本地監(jiān)聽端口也是獨(dú)占的，因此server端tcp連接4元組中只有remote ip（也就是client ip）和remote port（客戶端port）是可變的，因此最大tcp連接為客戶端ip數(shù)×客戶端port數(shù)

對IPV4，不考慮ip地址分類等因素，最大tcp連接數(shù)約為2的32次方（ip數(shù)）×2的16次方（port數(shù)），也就是server端單機(jī)最大tcp連接數(shù)約為2的48次方。

實(shí)際的tcp連接數(shù)

上面給出的是理論上的單機(jī)最大連接數(shù)，在實(shí)際環(huán)境中，受到機(jī)器資源、操作系統(tǒng)等的限制，特別是sever端，其最大并發(fā)tcp連接數(shù)遠(yuǎn)不能達(dá)到理論上限。在unix/linux下限制連接數(shù)的主要因素是內(nèi)存和允許的文件描述符個數(shù)（每個tcp連接都要占用一定內(nèi)存，每個socket就是一個文件描述符），另外1024以下的端口通常為保留端口。在默認(rèn)2.6內(nèi)核配置下，經(jīng)過試驗(yàn)，每個socket占用內(nèi)存在15~20k之間。

影響一個socket占用內(nèi)存的參數(shù)包括：

rmem_max

wmem_max

tcp_rmem

tcp_wmem

tcp_mem

grep skbuff /proc/slabinfo

對server端，通過增加內(nèi)存、修改最大文件描述符個數(shù)等參數(shù)，單機(jī)最大并發(fā)TCP連接數(shù)超過10萬 是沒問題的，國外 Urban Airship 公司在產(chǎn)品環(huán)境中已做到 50 萬并發(fā) 。在實(shí)際應(yīng)用中，對大規(guī)模網(wǎng)絡(luò)應(yīng)用，還需要考慮C10K 問題。

HTTP1.0，1.1，2.0 的版本區(qū)別

HTTP 1.0 : 默認(rèn)短連接，每次請求和響應(yīng)，都要建立連接，連接無法復(fù)用；HTTP1.0 其實(shí)也可以強(qiáng)制開啟長鏈接，例如接受Connection: keep-alive這個字段，但是，這不是標(biāo)準(zhǔn)字段，不同實(shí)現(xiàn)的行為可能不一致，因此不是根本的解決辦法。

HTTP 1.1：默認(rèn)長連接，TCP連接復(fù)用，一方主動放棄來連接才斷開；管道機(jī)制排隊(duì)等待，多個請求可以同時(shí)發(fā)送，但請求必須一個一個處理，出現(xiàn)隊(duì)列等待阻塞；

HTTP 2.0: 多路復(fù)用；二進(jìn)制數(shù)據(jù)；Header壓縮； 服務(wù)推送

多路復(fù)用：同時(shí)發(fā)送或者接受多個請求和響應(yīng)，請求和響應(yīng)有編號，同一個連接并發(fā)處理多個請求，不需要等待，解決隊(duì)列等待阻塞；

POST和GET有哪些區(qū)別？各自應(yīng)用場景？

POST：提交數(shù)據(jù)，可能會修改服務(wù)器的數(shù)據(jù)；對服務(wù)器可能有威脅（注冊信息，上傳文件）

GET：只讀服務(wù)器數(shù)據(jù)；對服務(wù)器沒有威脅（查看頁面）

HTTP 狀態(tài)碼

2 成功；3重定向；4客戶端請求報(bào)文錯誤； 5服務(wù)端錯誤

301：永久重定向，請求資源不在，用新的URL訪問，表示該資源已經(jīng)永久改變了位置。

302：臨時(shí)重定向，資源還在，但用另外一個URL訪問

403：禁止訪問的資源

404：資源無

501：功能還不支持

502：后端服務(wù)器異常

503：服務(wù)器忙，由于臨時(shí)的服務(wù)器維護(hù)或者過載，服務(wù)器當(dāng)前無法處理請求。這個狀況是臨時(shí)的，并且將在一段時(shí)間以后恢復(fù)。某一時(shí)刻大量登錄，比如學(xué)校返校登記網(wǎng)站。由于需要48核酸證明，某一時(shí)段會過載登錄。

301 302應(yīng)用場景

301

網(wǎng)頁開發(fā)過程中，時(shí)常會遇到網(wǎng)站目錄結(jié)構(gòu)的調(diào)整，將頁面轉(zhuǎn)移到一個新地址；網(wǎng)頁擴(kuò)展名的改變，這些變化都會導(dǎo)致網(wǎng)頁地址發(fā)生改變，此時(shí)用戶收藏夾和搜索引擎數(shù)據(jù)庫中的舊地址是一個錯誤的地址，訪問之后會出現(xiàn)404頁面，直接導(dǎo)致網(wǎng)站流量的損失。或者是我們需要多個域名跳轉(zhuǎn)至同一個域名，例如本站主站點(diǎn)域名為 http://www.conimi.com?，而還有一個域名 http://www.nico.cc，由于對該域名設(shè)置了301重定向，當(dāng)輸入http://www.nico.cc?時(shí)，自動跳轉(zhuǎn)至 http://www.conimi.com?。

302

302重定向（302 Move Temporarily），指頁面暫時(shí)性轉(zhuǎn)移，表示資源或頁面暫時(shí)轉(zhuǎn)移到另一個位置，常被用作網(wǎng)址劫持，容易導(dǎo)致網(wǎng)站降權(quán)，嚴(yán)重時(shí)網(wǎng)站會被封掉，不推薦使用。

在交互過程中如果數(shù)據(jù)傳送完了，還不想斷開連接怎么辦，怎么維持？

在 HTTP 中響應(yīng)體的 Connection 字段指定為 keep-alive

connetion:keep-alive;

HTTP 如何實(shí)現(xiàn)長連接？在什么時(shí)候會超時(shí)？

實(shí)際上 HTTP 沒有長短鏈接，只有 TCP 有，TCP 長連接可以復(fù)用一個 TCP 鏈接來發(fā)起多次 HTTP 請求，這樣可以減少資源消耗，比如一次請求 HTML，可能還需要請求后續(xù)的 JS/CSS/圖片等

通過在頭部（請求和響應(yīng)頭）設(shè)置 Connection: keep-alive，HTTP1.0協(xié)議支持，但是默認(rèn)關(guān)閉，從HTTP1.1協(xié)議以后，連接默認(rèn)都是長連接

1、HTTP 一般會有 httpd 守護(hù)進(jìn)程，里面可以設(shè)置 keep-alive timeout，當(dāng) tcp 鏈接閑置超過這個時(shí)間就會關(guān)閉，也可以在 HTTP 的 header 里面設(shè)置超時(shí)時(shí)間

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

（1）tcp_keepalive_intvl = 15
（2）tcp_keepalive_probes = 5
（3）tcp_keepalive_time = 1800

談下你對 HTTP 長連接和短連接的理解？分別應(yīng)用于哪些場景？

在 HTTP/1.0 中默認(rèn)使用短連接。也就是說，客戶端和服務(wù)器每進(jìn)行一次 HTTP 操作，就建立一次連接，任務(wù)結(jié)束就中斷連接。當(dāng)客戶端瀏覽器訪問的某個 HTML 或其他類型的 Web 頁中包含有其他的 Web 資源（如：JavaScript 文件、圖像文件、CSS 文件等），每遇到這樣一個 Web 資源，瀏覽器就會重新建立一個 HTTP 會話。

而從 HTTP/1.1 起，默認(rèn)使用長連接，用以保持連接特性。使用長連接的 HTTP 協(xié)議，會在響應(yīng)頭加入這行代碼：

Connection:keep-alive

在使用長連接的情況下，當(dāng)一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸 HTTP 數(shù)據(jù)的 TCP 連接不會關(guān)閉，客戶端再次訪問這個服務(wù)器時(shí)，會繼續(xù)使用這一條已經(jīng)建立的連接。

Keep-Alive 不會永久保持連接，它有一個保持時(shí)間，可以在不同的服務(wù)器軟件（如：Apache）中設(shè)定這個時(shí)間。實(shí)現(xiàn)長連接需要客戶端和服務(wù)端都支持長連接。

應(yīng)用場景

長連接多用于操作頻繁，點(diǎn)對點(diǎn)的通。 數(shù)據(jù)庫的連接用長連接， 如果用短連接頻繁的通信會造成 socket 錯誤，而且頻繁的 socket創(chuàng)建也是對資源的浪費(fèi)。

短連接 多用于 服務(wù)端連接多，每個連接操作不頻繁。WEB 網(wǎng)站的 http 服務(wù)一般都用，因?yàn)殚L連接對于服務(wù)端來說會耗費(fèi)一定的資源，像 WEB 網(wǎng)站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源， 如果用長連接，而且同時(shí)有成千上萬的用戶，如果每個用戶都占用一個連接的話，那可想而知吧。所以并發(fā)量大，但每個用戶無需頻繁操作情況下需用短連接。

簡單說下 HTTPS 和 HTTP 的區(qū)別

HTTPS 比HTTP多 加密傳輸；

具體實(shí)現(xiàn)方法是 ：連接時(shí)需要先 建立SSL/TLS的連接 再建立三次握手；

建立SSL/TLS的連接基本流程：客戶端向服務(wù)器索要并驗(yàn)證服務(wù)器的公鑰；雙方協(xié)商?生成 會話 密鑰；采用密鑰 進(jìn)行加密通信

SSL/TLS 主要技術(shù)包括 非對稱加密 數(shù)字證書 數(shù)字簽名；

非對稱加密：主要是用于 后續(xù)對稱加密的傳輸?shù)?密鑰交換

數(shù)字證書：驗(yàn)證非對稱加密時(shí)，公鑰的真實(shí)性

數(shù)字簽名：驗(yàn)證 建立SSL/TLS的連接時(shí)，雙方傳輸?shù)臄?shù)據(jù)是否遭到篡改，同時(shí) 驗(yàn)證數(shù)據(jù)來源

HTTPS 的工作過程？

主要工作過程就是 是通過非對稱加密 獲取 用于對稱加密的密鑰，而后通過對稱加密進(jìn)行數(shù)據(jù)傳輸；

具體細(xì)節(jié)如下

1.客戶端 發(fā)送請求信息 信息 包括 客戶端支持的加密算法列表、隨機(jī)數(shù)1

加密算法 包括：作為 計(jì)算 對稱加密 會話密鑰 的算法；用于摘要計(jì)算的 hash算法 ；等

2.服務(wù)端 發(fā)送響應(yīng)信息 包括 數(shù)字證書，確認(rèn)的加密算法?、隨機(jī)數(shù)2

3.客戶端 驗(yàn)證 服務(wù)器數(shù)字證書的合法性，約定好的hash算法計(jì)算客戶端摘要，從數(shù)字證書獲取 服務(wù)器的公鑰 加密響應(yīng)數(shù)據(jù)

響應(yīng)數(shù)據(jù) 包括 隨機(jī)數(shù)3、客戶端摘要；

此時(shí)客戶端使用約定好的加密算法 利用 三個隨機(jī)數(shù) 計(jì)算會話密鑰

4.服務(wù)端 使用自己的私鑰 解密數(shù)據(jù)；解析驗(yàn)證客戶端摘要； 使用約定好的加密算法 利用 三個隨機(jī)數(shù) 計(jì)算會話密鑰；約定好的hash算法計(jì)算服務(wù)端摘要

至此一個非對稱加密的過程結(jié)束

后續(xù)使用對稱加密傳輸數(shù)據(jù)

摘要用于驗(yàn)證雙方數(shù)據(jù)的完整性

總結(jié)

① 證書驗(yàn)證階段

1. 瀏覽器發(fā)起 HTTPS 請求
2. 服務(wù)端返回 HTTPS 證書
3. 客戶端驗(yàn)證證書是否合法，如果不合法則提示告警

② 數(shù)據(jù)傳輸階段

1. 當(dāng)證書驗(yàn)證合法后，在本地生成隨機(jī)數(shù)
2. 通過公鑰加密隨機(jī)數(shù)，并把加密后的隨機(jī)數(shù)傳輸?shù)椒?wù)端
3. 服務(wù)端通過私鑰對隨機(jī)數(shù)進(jìn)行解密
4. 服務(wù)端通過客戶端傳入的隨機(jī)數(shù)構(gòu)造對稱加密算法，對返回結(jié)果內(nèi)容進(jìn)行加密后傳輸

為什么HTTPS數(shù)據(jù)傳輸是用對稱加密？

首先，非對稱加密的加解密效率是非常低的，而 http 的應(yīng)用場景中通常端與端之間存在大量的交互，非對稱加密的效率是無法接受的；另外，在 HTTPS 的場景中只有服務(wù)端保存了私鑰，一對公私鑰只能實(shí)現(xiàn)單向的加解密，所以 HTTPS 中內(nèi)容傳輸加密采取的是對稱加密，而不是非對稱加密。

為什么需要 CA 認(rèn)證機(jī)構(gòu)頒發(fā)證書？

HTTP 協(xié)議被認(rèn)為不安全是因?yàn)閭鬏斶^程容易被監(jiān)聽者勾線監(jiān)聽、偽造服務(wù)器，而 HTTPS 協(xié)議主要解決的便是網(wǎng)絡(luò)傳輸?shù)陌踩詥栴}。首先我們假設(shè)不存在認(rèn)證機(jī)構(gòu)，任何人都可以制作證書，這帶來的安全風(fēng)險(xiǎn)便是經(jīng)典的 “中間人攻擊”?問題。

“中間人攻擊”的具體過程如下：

過程原理：

1. 本地請求被劫持（如DNS劫持等），所有請求均發(fā)送到中間人的服務(wù)器
2. 中間人服務(wù)器返回中間人自己的證書
3. 客戶端創(chuàng)建隨機(jī)數(shù)，通過中間人證書的公鑰對隨機(jī)數(shù)加密后傳送給中間人，然后憑隨機(jī)數(shù)構(gòu)造對稱加密對傳輸內(nèi)容進(jìn)行加密傳輸
4. 中間人因?yàn)閾碛锌蛻舳说碾S機(jī)數(shù)，可以通過對稱加密算法進(jìn)行內(nèi)容解密
5. 中間人以客戶端的請求內(nèi)容再向正規(guī)網(wǎng)站發(fā)起請求
6. 因?yàn)橹虚g人與服務(wù)器的通信過程是合法的，正規(guī)網(wǎng)站通過建立的安全通道返回加密后的數(shù)據(jù)
7. 中間人憑借與正規(guī)網(wǎng)站建立的對稱加密算法對內(nèi)容進(jìn)行解密
8. 中間人通過與客戶端建立的對稱加密算法對正規(guī)內(nèi)容返回的數(shù)據(jù)進(jìn)行加密傳輸
9. 客戶端通過與中間人建立的對稱加密算法對返回結(jié)果數(shù)據(jù)進(jìn)行解密

由于缺少對證書的驗(yàn)證，所以客戶端雖然發(fā)起的是 HTTPS 請求，但客戶端完全不知道自己的網(wǎng)絡(luò)已被攔截，傳輸內(nèi)容被中間人全部竊取。

什么是數(shù)字簽名？

數(shù)字簽名 是 非對稱加密 和 摘要算法 的應(yīng)用

兩端都有對方的 公鑰

約定hash 為 傳輸?shù)脑瓟?shù)據(jù) 計(jì)算 獨(dú)一無二的 指紋；

將 指紋和原數(shù)據(jù) 利用公鑰加密，傳輸給對方

對方使用自己的私鑰解密，并使用 約定hash 為 獲取的數(shù)據(jù) 計(jì)算摘要與“指紋”對比

一致則表明數(shù)據(jù)來源于對方，且數(shù)據(jù)并未被篡改

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

對稱加密中，雙方使用公鑰進(jìn)行解密。雖然數(shù)字簽名可以保證數(shù)據(jù)不被替換，但是數(shù)據(jù)是由公鑰加密的，如果公鑰也被替換，則仍然可以偽造數(shù)據(jù)，因?yàn)橛脩舨恢缹Ψ教峁┑墓€其實(shí)是假的。

中間人可以偽造證書與客戶端來連接，將服務(wù)端的數(shù)據(jù)篡改，貍貓換太子；

為了保證發(fā)送方的公鑰是真的，CA 證書機(jī)構(gòu)會負(fù)責(zé)頒發(fā)一個證書，里面的公鑰保證是真的，用戶請求服務(wù)器時(shí)，服務(wù)器將證書發(fā)給用戶，這個證書是經(jīng)由系統(tǒng)內(nèi)置證書的備案的，且與域名綁定；

瀏覽器是如何確保 CA 證書的合法性？

瀏覽器發(fā)起 HTTPS 請求時(shí)，服務(wù)器會返回網(wǎng)站的 SSL 證書，瀏覽器需要對證書做以下驗(yàn)證：

1. 驗(yàn)證域名、有效期等信息是否正確。證書上都有包含這些信息，比較容易完成驗(yàn)證；
2. 判斷證書來源是否合法。每份簽發(fā)證書都可以根據(jù)驗(yàn)證鏈查找到對應(yīng)的根證書，操作系統(tǒng)、瀏覽器會在本地存儲權(quán)威機(jī)構(gòu)的根證書，利用本地根證書可以對對應(yīng)機(jī)構(gòu)簽發(fā)證書完成來源驗(yàn)證；

3.判斷證書是否被篡改。需要與 CA 公鑰進(jìn)行校驗(yàn)；如果此時(shí)證書被篡改，CA公鑰無法解密，瀏覽器會提示警告，用戶可以選擇繼續(xù)訪問，之后瀏覽器會使用 對方的公鑰傳輸 用于對稱加密的密鑰信息

以上任意一步都滿足的情況下瀏覽器才認(rèn)為證書是合法的。

這里插一個我想了很久的但其實(shí)答案很簡單的問題：
既然證書是公開的，如果要發(fā)起中間人攻擊，我在官網(wǎng)上下載一份證書作為我的服務(wù)器證書，那客戶端肯定會認(rèn)同這個證書是合法的，如何避免這種證書冒用的情況？
其實(shí)這就是非加密對稱中公私鑰的用處，雖然中間人可以得到證書，但證書中室友CA簽名的，這個簽名是由CA私鑰加密的無法解析，同時(shí)簽名的數(shù)據(jù)包含服務(wù)器的公鑰信息。中間人無法獲得CA私鑰，無法簽名，也就無法篡改。

只有認(rèn)證機(jī)構(gòu)可以生成證書嗎？

如果需要瀏覽器不提示安全風(fēng)險(xiǎn)，那只能使用認(rèn)證機(jī)構(gòu)簽發(fā)的證書。

但瀏覽器通常只是提示安全風(fēng)險(xiǎn)，并不限制網(wǎng)站不能訪問，所以從技術(shù)上誰都可以生成證書，只要有證書就可以完成網(wǎng)站的HTTPS 傳輸。例如早期的 12306 采用的便是手動安裝私有證書的形式實(shí)現(xiàn) HTTPS 訪問。

這種情況下就可能出現(xiàn)中間人攻擊

本地隨機(jī)數(shù)被竊取怎么辦？

證書驗(yàn)證是采用非對稱加密實(shí)現(xiàn)，但是傳輸過程是采用對稱加密，而其中對稱加密算法中重要的隨機(jī)數(shù)是由本地生成并且存儲于本地的HTTPS

如何保證隨機(jī)數(shù)不會被竊取？其實(shí) HTTPS 并不包含對隨機(jī)數(shù)的安全保證，HTTPS保證的只是傳輸過程安全，而隨機(jī)數(shù)存儲于本地，本地的安全屬于另一安全范疇，應(yīng)對的措施有安裝殺毒軟件、反木馬、瀏覽器升級修復(fù)漏洞等。

用了 HTTPS 會被抓包嗎？

HTTPS 的數(shù)據(jù)是加密的，常規(guī)下抓包工具代理請求后抓到的包內(nèi)容是加密狀態(tài)，無法直接查看。但是，正如前文所說，瀏覽器只會提示安全風(fēng)險(xiǎn)，如果用戶授權(quán)仍然可以繼續(xù)訪問網(wǎng)站，完成請求。因此，只要客戶端是我們自己的終端，我們授權(quán)的情況下，便可以組建中間人網(wǎng)絡(luò)，而抓包工具便是作為中間人的代理。

通常HTTPS抓包工具的使用方法是會生成一個證書，用戶需要手動把證書安裝到客戶端中，然后終端發(fā)起的所有請求通過該證書完成與抓包工具的交互，然后抓包工具再轉(zhuǎn)發(fā)請求到服務(wù)器，最后把服務(wù)器返回的結(jié)果在控制臺輸出后再返回給終端，從而完成整個請求的閉環(huán)。

既然 HTTPS 不能防抓包，那 HTTPS 有什么意義？?

HTTPS可以防止用戶在不知情的情況下通信鏈路被監(jiān)聽，對于主動授信的抓包操作是不提供防護(hù)的，因?yàn)檫@個場景用戶是已經(jīng)對風(fēng)險(xiǎn)知情。要防止被抓包，需要采用應(yīng)用級的安全防護(hù)，例如采用私有的對稱加密，同時(shí)做好移動端的防反編譯加固，防止本地算法被破解。

Cookie 和 Session 有什么區(qū)別？

Cookie 將登陸等信息保存在客戶端

Session將信息保存在服務(wù)端

1、由于HTTP協(xié)議是無狀態(tài)的協(xié)議，所以服務(wù)端需要記錄用戶的狀態(tài)時(shí)，就需要用某種機(jī)制來識具體的用戶，這個機(jī)制就是Session.典型的場景比如購物車。

當(dāng)你點(diǎn)擊下單按鈕時(shí)，由于HTTP協(xié)議無狀態(tài)，所以并不知道是哪個用戶操作的，所以服務(wù)端要為特定的用戶創(chuàng)建了特定的Session，用用于標(biāo)識這個用戶，并且跟蹤用戶，這樣才知道購物車?yán)锩嬗袔妆緯?/p>

這個Session是保存在服務(wù)端的，有一個唯一標(biāo)識。在服務(wù)端保存Session的方法很多，內(nèi)存、數(shù)據(jù)庫、文件都有。集群的時(shí)候也要考慮Session的轉(zhuǎn)移，在大型的網(wǎng)站，一般會有專門的Session服務(wù)器集群，用來保存用戶會話，這個時(shí)候 Session 信息都是放在內(nèi)存的，使用一些緩存服務(wù)比如Memcached之類的來放 Session。

2、思考一下服務(wù)端如何識別特定的客戶？這個時(shí)候Cookie就登場了。每次HTTP請求的時(shí)候，客戶端都會發(fā)送相應(yīng)的Cookie信息到服務(wù)端。實(shí)際上大多數(shù)的應(yīng)用都是用 Cookie 來實(shí)現(xiàn)Session跟蹤的，第一次創(chuàng)建Session的時(shí)候，服務(wù)端會在HTTP協(xié)議中告訴客戶端，需要在 Cookie 里面記錄一個Session ID，以后每次請求把這個會話ID發(fā)送到服務(wù)器，我就知道你是誰了。

有人問，如果客戶端的瀏覽器禁用了 Cookie 怎么辦？一般這種情況下，會使用一種叫做URL重寫的技術(shù)來進(jìn)行會話跟蹤，即每次HTTP交互，URL后面都會被附加上一個諸如 sid=xxxxx 這樣的參數(shù)，服務(wù)端據(jù)此來識別用戶。

3、Cookie其實(shí)還可以用在一些方便用戶的場景下，設(shè)想你某次登陸過一個網(wǎng)站，下次登錄的時(shí)候不想再次輸入賬號了，怎么辦？這個信息可以寫到Cookie里面，訪問網(wǎng)站的時(shí)候，網(wǎng)站頁面的腳本可以讀取這個信息，就自動幫你把用戶名給填了，能夠方便一下用戶。這也是Cookie名稱的由來，給用戶的一點(diǎn)甜頭。

所以，總結(jié)一下：

Session是在服務(wù)端保存的一個數(shù)據(jù)結(jié)構(gòu)，用來跟蹤用戶的狀態(tài)，這個數(shù)據(jù)可以保存在集群、數(shù)據(jù)庫、文件中。

Cookie是客戶端保存用戶信息的一種機(jī)制，用來記錄用戶的一些信息，也是實(shí)現(xiàn)Session的一種方式。

GET請求中URL編碼的意義

請求數(shù)據(jù)信息在URL 中

以鍵值對的形式展現(xiàn)

鍵值對： key=value

鍵值對連接使用 &

如果鍵值對中就包含 = 或 & 這種特殊字符的時(shí)候，使用 轉(zhuǎn)義字符 %+特殊字符

forward 和 redirect 的區(qū)別？

其實(shí)都是資源跳轉(zhuǎn)方式

轉(zhuǎn)發(fā)：forward?

在服務(wù)器內(nèi)部的資源跳轉(zhuǎn)方式

1. 瀏覽器地址欄不發(fā)生變化
2. 只能轉(zhuǎn)發(fā)當(dāng)前服務(wù)器內(nèi)部資源
3. 轉(zhuǎn)發(fā)是一次請求

重定向:redirect

重定向：客戶端服務(wù)器請求服務(wù)，服務(wù)器響應(yīng)另一個服務(wù)器的地址，是客戶端向該服務(wù)器發(fā)出請求（各種網(wǎng)絡(luò)請求重新定個方向轉(zhuǎn)到其它位置）

1. 地址欄發(fā)生變化
2. 重定向可以訪問其他站點(diǎn)(服務(wù)器)的資源
3. 重定向是兩次請求。不能使用request對象來共享數(shù)據(jù)

體會

不涉及到數(shù)據(jù)共享，用重定向；需要共享用轉(zhuǎn)發(fā)

有時(shí)候，數(shù)據(jù)共享，可能會導(dǎo)致非必要參數(shù)的顯示

Forward 和 Redirect 代表了兩種請求轉(zhuǎn)發(fā)方式：直接轉(zhuǎn)發(fā)和間接轉(zhuǎn)發(fā)。

直接轉(zhuǎn)發(fā)方式（Forward）：客戶端和瀏覽器只發(fā)出一次請求，Servlet、HTML、JSP 或其它信息資源，由第二個信息資源響應(yīng)該請求，在請求對象 request 中，保存的對象對于每個信息資源是共享的。

間接轉(zhuǎn)發(fā)方式（Redirect）：實(shí)際是兩次 HTTP 請求，服務(wù)器端在響應(yīng)第一次請求的時(shí)候，讓瀏覽器再向另外一個 URL 發(fā)出請求，從而達(dá)到轉(zhuǎn)發(fā)的目的。

在瀏覽器中輸入 URL 地址到顯示主頁的過程？

URL解析（URL 包括 協(xié)議名稱；服務(wù)器域名；訪問的數(shù)據(jù)位置）

生成HTTP報(bào)文

DNS域名解析

傳輸層數(shù)據(jù)分割與封裝，建立連接；網(wǎng)絡(luò)層封裝，確定目標(biāo)地址

發(fā)送請求

服務(wù)器收到請求，根據(jù)請求資源返回

瀏覽器解析渲染頁面：瀏覽器解析并渲染視圖，若遇到對 js 文件、css 文件及圖片等靜態(tài)資源的引用，則重復(fù)上述步驟并向服務(wù)器請求這些資源；瀏覽器根據(jù)其請求到的資源、數(shù)據(jù)渲染頁面，最終向用戶呈現(xiàn)一個完整的頁面。

URL 與 URI的關(guān)系

URL，即統(tǒng)一資源定位符 (Uniform Resource Locator )，URL 其實(shí)就是我們平時(shí)上網(wǎng)時(shí)輸入的網(wǎng)址，它標(biāo)識一個互聯(lián)網(wǎng)資源，并指定對其進(jìn)行操作或獲取該資源的方法。例如 https://leetcode-cn.com/problemset/all/?這個 URL，標(biāo)識一個特定資源并表示該資源的某種形式是可以通過 HTTP 協(xié)議從相應(yīng)位置獲得。

URL包含以下信息：

1、用于訪問資源的協(xié)議

2、服務(wù)器的位置（無論是通過IP地址還是域名）

3、服務(wù)器上的端口號（可選）

4、資源在服務(wù)器目錄結(jié)構(gòu)中的位置

而 URI 則是統(tǒng)一資源標(biāo)識符，并不是一個直接訪問的鏈接，而是相對地址

URL 是 URI 的一個子級，兩者都定義了資源是什么，而 URL 還定義了如何能訪問到該資源。URI 是一種語義上的抽象概念，可以是絕對的，也可以是相對的，而URL則必須提供足夠的信息來定位，是絕對的。簡單地說，只要能唯一標(biāo)識資源的就是 URI，在 URI 的基礎(chǔ)上給出其資源的訪問方式的就是 URL。

DNS 的解析過程

根域名：.?根域的DNS服務(wù)器保存著互聯(lián)網(wǎng)中所有的DNS服務(wù)器

頂級域名：com、cn、net、org、edu、gov?等

二級域名：baidu?等（我們需要注冊的就是到這個層級的，因?yàn)槎売蛎鸵呀?jīng)是全球唯一的了。）

主機(jī)名：www、mail等

DNS 的解析過程

主機(jī) 問 本地DNS

本地DNS 問?根DNS

根DNS 讓 本地服務(wù)器 找?頂級域名

頂級域名 讓 本地服務(wù)器 找?二級域名

具體細(xì)節(jié)

1. 主機(jī)向本地域名服務(wù)器的查詢一般都是采用遞歸查詢。所謂遞歸查詢就是：如果主機(jī)所詢問的本地域名服務(wù)器不知道被查詢的域名的 IP 地址，那么本地域名服務(wù)器就以 DNS 客戶的身份，向根域名服務(wù)器繼續(xù)發(fā)出查詢請求報(bào)文(即替主機(jī)繼續(xù)查詢)，而不是讓主機(jī)自己進(jìn)行下一步查詢。因此，遞歸查詢返回的查詢結(jié)果或者是所要查詢的 IP 地址，或者是報(bào)錯，表示無法查詢到所需的 IP 地址。
2. 本地域名服務(wù)器向根域名服務(wù)器的查詢的迭代查詢。迭代查詢的特點(diǎn)：當(dāng)根域名服務(wù)器收到本地域名服務(wù)器發(fā)出的迭代查詢請求報(bào)文時(shí)，要么給出所要查詢的 IP 地址，要么告訴本地服務(wù)器：“你下一步應(yīng)當(dāng)向哪一個域名服務(wù)器進(jìn)行查詢”。然后讓本地服務(wù)器進(jìn)行后續(xù)的查詢。根域名服務(wù)器通常是把自己知道的頂級域名服務(wù)器的 IP 地址告訴本地域名服務(wù)器，讓本地域名服務(wù)器再向頂級域名服務(wù)器查詢。頂級域名服務(wù)器在收到本地域名服務(wù)器的查詢請求后，要么給出所要查詢的 IP 地址，要么告訴本地服務(wù)器下一步應(yīng)當(dāng)向哪一個權(quán)限域名服務(wù)器進(jìn)行查詢。最后，本地域名服務(wù)器得到了所要解析的 IP 地址或報(bào)錯，然后把這個結(jié)果返回給發(fā)起查詢的主機(jī)。

談?wù)勀銓τ蛎彺娴牧私?#xff1f;

以根域名為例

所有域名查詢都必須先查詢根域名，因?yàn)橹挥懈蛎拍芨嬖V你，某個頂級域名由哪臺服務(wù)器管理。事實(shí)上也確實(shí)如此，ICANN 維護(hù)著一張列表，里面記載著頂級域名和對應(yīng)的托管商。

比如，我要訪問www.example.com，就必須先詢問 ICANN 的根域名列表，它會告訴我.com域名由 Verisign 托管，我必須去找 Verisign，它會告訴我example.com服務(wù)器在哪里。

再比如，我要訪問abc.xyz，也必須先去詢問根域名列表，它會告訴我.xyz域名由 CentralNic 公司托管。根域名列表還記載，.google由谷歌公司托管，.apple由蘋果公司托管等等。

由于根域名列表很少變化，大多數(shù) DNS 服務(wù)商都會提供它的緩存，所以根域名的查詢事實(shí)上不是那么頻繁。

以本地域名服務(wù)器為例

為了提高 DNS 查詢效率，并減輕服務(wù)器的負(fù)荷和減少因特網(wǎng)上的 DNS 查詢報(bào)文數(shù)量，在域名服務(wù)器中廣泛使用了高速緩存，用來存放最近查詢過的域名以及從何處獲得域名映射信息的記錄。

由于名字到地址的綁定并不經(jīng)常改變，為保持高速緩存中的內(nèi)容正確，域名服務(wù)器應(yīng)為每項(xiàng)內(nèi)容設(shè)置計(jì)時(shí)器并處理超過合理時(shí)間的項(xiàng)（例如：每個項(xiàng)目兩天）。當(dāng)域名服務(wù)器已從緩存中刪去某項(xiàng)信息后又被請求查詢該項(xiàng)信息，就必須重新到授權(quán)管理該項(xiàng)的域名服務(wù)器綁定信息。當(dāng)權(quán)限服務(wù)器回答一個查詢請求時(shí)，在響應(yīng)中都指明綁定有效存在的時(shí)間值。增加此時(shí)間值可減少網(wǎng)絡(luò)開銷，而減少此時(shí)間值可提高域名解析的正確性。

不僅在本地域名服務(wù)器中需要高速緩存，在主機(jī)中也需要。許多主機(jī)在啟動時(shí)從本地服務(wù)器下載名字和地址的全部數(shù)據(jù)庫，維護(hù)存放自己最近使用的域名的高速緩存，并且只在從緩存中找不到名字時(shí)才使用域名服務(wù)器。維護(hù)本地域名服務(wù)器數(shù)據(jù)庫的主機(jī)應(yīng)當(dāng)定期地檢查域名服務(wù)器以獲取新的映射信息，而且主機(jī)必須從緩存中刪除無效的項(xiàng)。由于域名改動并不頻繁，大多數(shù)網(wǎng)點(diǎn)不需花精力就能維護(hù)數(shù)據(jù)庫的一致性。

DNS 為什么用 UDP

其實(shí) DNS 的整個過程是既使用 TCP 又使用 UDP。

當(dāng)進(jìn)行區(qū)域傳送（主域名服務(wù)器 向 輔助域名服務(wù)器傳送 變化的那部分?jǐn)?shù)據(jù) ）時(shí)會使用 TCP，因?yàn)閿?shù)據(jù)同步傳送的數(shù)據(jù)量比一個請求和應(yīng)答的數(shù)據(jù)量要多，而 TCP 允許的報(bào)文長度更長，因此為了保證數(shù)據(jù)的正確性，會使用基于可靠連接的 TCP。

使用UDP的原因是 UDP極其適合傳輸 數(shù)據(jù)量不超過500字節(jié)的數(shù)據(jù)；這種數(shù)據(jù)量不會分割 一定程度上 規(guī)避了UDP傳輸不可靠等問題，又發(fā)揮了UDP高效等優(yōu)點(diǎn)

當(dāng)客戶端向 DNS 服務(wù)器查詢域名 ( 域名解析) 的時(shí)候，一般返回的內(nèi)容不會超過即 500字節(jié)。用 UDP 傳輸時(shí)，不需要經(jīng)過 TCP 三次握手的過程，從而大大提高了響應(yīng)速度，但這要求域名解析器和域名服務(wù)器都必須自己處理超時(shí)和重傳從而保證可靠性。

我們知道UDP是不可靠的傳輸協(xié)議，為了減少UDP包丟失的風(fēng)險(xiǎn)，我們最好能控制UDP包在下層協(xié)議的傳輸過程中不要被切割。不過鑒于Internet上的標(biāo)準(zhǔn)MTU值為576字節(jié)，所以建議在進(jìn)行Internet的UDP編程時(shí)，最好將UDP的數(shù)據(jù)長度控制在 (576-8-20)548字節(jié)以內(nèi)。

簡單說下怎么實(shí)現(xiàn) DNS 劫持

DNS 劫持即域名劫持，是通過將原域名對應(yīng)的 IP 地址進(jìn)行替換從而使得用戶訪問到錯誤的網(wǎng)站或者使得用戶無法正常訪問網(wǎng)站的一種攻擊方式。域名劫持往往只能在特定的網(wǎng)絡(luò)范圍內(nèi)進(jìn)行，范圍外的 DNS 服務(wù)器能夠返回正常的 IP 地址。攻擊者可以冒充原域名所屬機(jī)構(gòu)，通過電子郵件的方式修改組織機(jī)構(gòu)的域名注冊信息，或者將域名轉(zhuǎn)讓給其它組織，并將新的域名信息保存在所指定的 DNS 服務(wù)器中，從而使得用戶無法通過對原域名進(jìn)行解析來訪問目的網(wǎng)址。

用戶端的一些預(yù)防手段：

直接通過 IP 地址訪問網(wǎng)站，避開 DNS 劫持。
由于域名劫持往往只能在特定的網(wǎng)絡(luò)范圍內(nèi)進(jìn)行，因此一些高級用戶可以通過網(wǎng)絡(luò)設(shè)置讓 DNS 指向正常的域名服務(wù)器以實(shí)現(xiàn)對目的網(wǎng)址的正常訪問，例如將計(jì)算機(jī)首選 DNS 服務(wù)器的地址固定為 8.8.8.8。

什么是SQL 注入？舉個例子？

概念：SQL注入就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令。

總體思路：(1). 尋找到SQL注入的位置；(2). 判斷服務(wù)器類型和后臺數(shù)據(jù)庫類型；(3). 針對不同的服務(wù)器和數(shù)據(jù)庫特點(diǎn)進(jìn)行SQL注入攻擊

實(shí)例

比如，在一個登錄界面，要求輸入用戶名和密碼，可以這樣輸入實(shí)現(xiàn)免帳號登錄：

用戶名： ‘or 1 = 1 --

密 碼：

用戶一旦點(diǎn)擊登錄，如若沒有做特殊處理，那么這個非法用戶就很得意的登陸進(jìn)去了。這是為什么呢?

下面我們分析一下：從理論上說，后臺認(rèn)證程序中會有如下的SQL語句：

String?sql?=?“select?*?from?user_table?where?username=’?“+userName+”?’?and?password=’?“+password+”?‘”;?

因此，當(dāng)輸入了上面的用戶名和密碼，上面的SQL語句變成：

SELECT * FROM user_table WHERE username=’’or 1 = 1 –- and password=’’

分析上述SQL語句我們知道，username=‘' or 1=1 這個語句一定會成功；然后后面加兩個 -，這意味著注釋，它將后面的語句注釋，讓他們不起作用。這樣，上述語句永遠(yuǎn)都能正確執(zhí)行，用戶輕易騙過系統(tǒng)，獲取合法身份。

應(yīng)對方法

(1)參數(shù)綁定

使用預(yù)編譯手段，綁定參數(shù)是最好的防SQL注入的方法。目前許多的ORM框架及JDBC等都實(shí)現(xiàn)了SQL預(yù)編譯和參數(shù)綁定功能，攻擊者的惡意SQL會被當(dāng)做SQL的參數(shù)而不是SQL命令被執(zhí)行。在mybatis的mapper文件中，對于傳遞的參數(shù)我們一般是使用 # 和$來獲取參數(shù)值。

<mapper?namespace="userMapper">

????<update?id="update"?parameterType="com.itheima.domain.User">

????????update user set username=#{username},password=#{password} where id=#{id}

????</update></mapper>

當(dāng)使用$時(shí)，變量就是直接追加在sql中，一般會有sql注入問題。

當(dāng)使用#時(shí)，變量是占位符，就是一般我們使用javajdbc的PrepareStatement時(shí)的占位符，所以可以防止sql注入；

PreparedStatement?s?=?null;//定義sql語句String?sql?=?"select * from users where username = ? and password = ?";s?=?c.prepareStatement(sql);s.setString(1,username);s.setString(2,password);

c 是 Connection 數(shù)據(jù)庫連接對象

(2)使用正則表達(dá)式過濾傳入的參數(shù)

IP 分類

IP: 網(wǎng)絡(luò)號+主機(jī)號

A：0XXX;

B：10XX;

C：110X;

D：111X; 保留位多播地址。

E：1111;

另一種分類方式：CIDR 通過子網(wǎng)掩碼劃分

IP: a.b.c.d/x

前 x 位是網(wǎng)絡(luò)號，也是子網(wǎng)掩碼的位數(shù)

IPV4 地址不夠如何解決

目前主要有以下兩種方式：

1、其實(shí)我們平時(shí)上網(wǎng)，電腦的 IP 地址都是屬于私有地址，我無法出網(wǎng)關(guān)，我們的數(shù)據(jù)都是通過網(wǎng)關(guān)來中轉(zhuǎn)的，這個其實(shí) NAT 協(xié)議，可以用來暫緩 IPV4 地址不夠；

2、IPv6 ：作為接替 IPv4 的下一代互聯(lián)網(wǎng)協(xié)議，其可以實(shí)現(xiàn) 2 的 128 次方個地址，而這個數(shù)量級，即使是給地球上每一顆沙子都分配一個IP地址，該協(xié)議能夠從根本上解決 IPv4 地址不夠用的問題。

NAT是指？

NAT: 區(qū)域內(nèi)使用私用IP，與外界通信時(shí)將私有IP轉(zhuǎn)化成公用IP

內(nèi)網(wǎng)有很多計(jì)算機(jī)，每個計(jì)算機(jī)的私有地址向外界請求都轉(zhuǎn)化成公有地址 這并不會緩解IP危機(jī)

因此引入NAPT（Network Address Port Translation）

概念：即網(wǎng)絡(luò)地址端口轉(zhuǎn)換，可將多個內(nèi)部地址映射為一個合法公網(wǎng)地址，以不同的端口號 與 不同的內(nèi)部地址相對應(yīng)，也就是<不同的內(nèi)部地址+內(nèi)部端口>與<一個外部地址+不同外部端口>之間的轉(zhuǎn)換。

IP地址和MAC地址有什么區(qū)別？各自的用處？

IP 是用來尋址；

MAC用來確認(rèn)身份以及 尋址過程中的實(shí)際路徑傳輸；

尋址過程中的實(shí)際路徑傳輸?shù)囊馑际?：尋址過程每次數(shù)據(jù) 傳輸 都必須要通過 ARP 和 目標(biāo)IP ，得到下一跳的MAC，通過MAC將數(shù)據(jù)傳輸過去；

ARP 協(xié)議的工作原理？

首先檢查自己 ARP 列表中是否存在該 IP 地址對應(yīng)的 MAC 地址，如果沒有以廣播的方式 問 目標(biāo)IP的MAC；具體細(xì)節(jié)如下：

網(wǎng)絡(luò)層的 ARP 協(xié)議完成了 IP 地址與物理地址的映射。

首先，每臺主機(jī)都會在自己的 ARP 緩沖區(qū)中建立一個 ARP 列表，以表示 IP 地址和 MAC 地址的對應(yīng)關(guān)系。

當(dāng)源主機(jī)需要將一個數(shù)據(jù)包要發(fā)送到目的主機(jī)時(shí)，會首先檢查自己 ARP 列表中是否存在該 IP 地址對應(yīng)的 MAC 地址：如果有，就直接將數(shù)據(jù)包發(fā)送到這個 MAC 地址；如果沒有，就向本地網(wǎng)段發(fā)起一個 ARP 請求的廣播包，查詢此目的主機(jī)對應(yīng)的 MAC 地址。

此 ARP 請求數(shù)據(jù)包里包括源主機(jī)的 IP 地址、硬件地址、以及目的主機(jī)的 IP 地址。

網(wǎng)絡(luò)中所有的主機(jī)收到這個 ARP 請求后，會檢查數(shù)據(jù)包中的目的 IP 是否和自己的 IP 地址一致。

如果不相同就忽略此數(shù)據(jù)包；

如果相同，該主機(jī)首先將發(fā)送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已經(jīng)存在該 IP 的信息，則將其覆蓋，然后給源主機(jī)發(fā)送一個 ARP 響應(yīng)數(shù)據(jù)包，告訴對方自己是它需要查找的 MAC 地址；

源主機(jī)收到這個 ARP 響應(yīng)數(shù)據(jù)包后，將得到的目的主機(jī)的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息開始數(shù)據(jù)的傳輸。如果源主機(jī)一直沒有收到 ARP 響應(yīng)數(shù)據(jù)包，表示 ARP 查詢失敗

ARP欺騙？

當(dāng)主機(jī)A發(fā)起ARP請求時(shí)，在本網(wǎng)段內(nèi)詢問 IP地址的歸屬者（MAC）；

主機(jī)B冒充IP地址的歸屬者，A向該IP發(fā)送的數(shù)據(jù)全部流入到B中；

ICMP 有哪些應(yīng)用？

功能

• 確認(rèn)IP包是否成功送達(dá)
• 報(bào)告發(fā)送中IP包被廢棄的原因

類型

ICMP報(bào)文的種類有兩種，即ICMP差錯報(bào)文和ICMP詢問報(bào)文。

差錯報(bào)告報(bào)文有五種（細(xì)分的話不止，詳情可百度）：終點(diǎn)不可達(dá)、源點(diǎn)抑制（Source quench）（已棄用）、時(shí)間超過、參數(shù)問題、改變路由（重定向）（Redirect）。

訪問報(bào)文有兩種（同樣不止，詳細(xì)百度）：回送請求和回答報(bào)文，時(shí)間戳請求（棄用）和回答報(bào)文。

應(yīng)用

ICMP 主要有兩個應(yīng)用，一個是 Ping，一個是 Traceroute。

1. Ping

Ping 是 ICMP 的一個重要應(yīng)用，主要用來測試兩臺主機(jī)之間的連通性。

Ping 的原理是通過向目的主機(jī)發(fā)送 ICMP Echo 請求報(bào)文，目的主機(jī)收到之后會發(fā)送 Echo 回答報(bào)文。Ping 會根據(jù)時(shí)間和成功響應(yīng)的次數(shù)估算出數(shù)據(jù)包往返時(shí)間以及丟包率。

大致流程：

構(gòu)造ICMP數(shù)據(jù)包–>構(gòu)造IP數(shù)據(jù)包–>構(gòu)造以太網(wǎng)數(shù)據(jù)幀----物理傳輸?shù)侥繕?biāo)主機(jī)---->獲取以太網(wǎng)數(shù)據(jù)幀–>解析出IP數(shù)據(jù)包–>解析出ICMP數(shù)據(jù)包–>發(fā)送回送應(yīng)答報(bào)文

2. Traceroute

Traceroute 是 ICMP 的另一個應(yīng)用，用來跟蹤一個分組從源點(diǎn)到終點(diǎn)的路徑。

Traceroute 發(fā)送的 IP 數(shù)據(jù)報(bào) 封裝的是無法交付的 UDP 用戶數(shù)據(jù)報(bào)，并由目的主機(jī)發(fā)送終點(diǎn)不可達(dá)差錯報(bào)告報(bào)文。

• 源主機(jī)向目的主機(jī)發(fā)送一連串的 IP 數(shù)據(jù)報(bào)。第一個數(shù)據(jù)報(bào) P1 的生存時(shí)間 TTL 設(shè)置為 1，當(dāng) P1 到達(dá)路徑上的第一個路由器 R1 時(shí)，R1 收下它并把 TTL 減 1，此時(shí) TTL 等于 0，R1 就把 P1 丟棄，并向源主機(jī)發(fā)送一個 ICMP 時(shí)間超過差錯報(bào)告報(bào)文；
• 源主機(jī)接著發(fā)送第二個數(shù)據(jù)報(bào) P2，并把 TTL 設(shè)置為 2。P2 先到達(dá) R1，R1 收下后把 TTL 減 1 再轉(zhuǎn)發(fā)給 R2，R2 收下后也把 TTL 減 1，由于此時(shí) TTL 等于 0，R2 就丟棄 P2，并向源主機(jī)發(fā)送一個 ICMP 時(shí)間超過差錯報(bào)文。
• 不斷執(zhí)行這樣的步驟，直到最后一個數(shù)據(jù)報(bào)剛剛到達(dá)目的主機(jī)，主機(jī)不轉(zhuǎn)發(fā)數(shù)據(jù)報(bào)，也不把 TTL 值減 1。但是因?yàn)閿?shù)據(jù)報(bào)封裝的是無法交付的 UDP，因此目的主機(jī)要向源主機(jī)發(fā)送 ICMP 終點(diǎn)不可達(dá)差錯報(bào)告報(bào)文。
• 之后源主機(jī)知道了到達(dá)目的主機(jī)所經(jīng)過的路由器 IP 地址以及到達(dá)每個路由器的往返時(shí)間。