防范常見(jiàn)的 Web 攻擊

1、什么是SQL注入攻擊

攻擊者在HTTP請(qǐng)求中注入惡意的SQL代碼，服務(wù)器使用參數(shù)構(gòu)建數(shù)據(jù)庫(kù)SQL命令時(shí)，惡意SQL被一起構(gòu)造，并在數(shù)據(jù)庫(kù)中執(zhí)行。
用戶登錄，輸入用戶名 lianggzone，密碼 ‘ or ‘1’=’1 ，如果此時(shí)使用參數(shù)構(gòu)造的方式，就會(huì)出現(xiàn)
select * from user where name = ‘lianggzone’ and password = ‘’ or ‘1’=‘1’
不管用戶名和密碼是什么內(nèi)容，使查詢出來(lái)的用戶列表不為空。如何防范SQL注入攻擊使用預(yù)編譯的PrepareStatement是必須的，但是一般我們會(huì)從兩個(gè)方面同時(shí)入手。

• Web端
  1）有效性檢驗(yàn)。
  2）限制字符串輸入的長(zhǎng)度。
• 服務(wù)端
  1）不用拼接SQL字符串。
  2）使用預(yù)編譯的PrepareStatement。
  3）有效性檢驗(yàn)。(為什么服務(wù)端還要做有效性檢驗(yàn)？第一準(zhǔn)則，外部都是不可信的，防止攻擊者繞過(guò)Web端請(qǐng)求)
  4）過(guò)濾SQL需要的參數(shù)中的特殊字符。比如單引號(hào)、雙引號(hào)。

2、什么是XSS攻擊

跨站點(diǎn)腳本攻擊，指攻擊者通過(guò)篡改網(wǎng)頁(yè)，嵌入惡意腳本程序，在用戶瀏覽網(wǎng)頁(yè)時(shí)，控制用戶瀏覽器進(jìn)行惡意操作的一種攻擊方式。如何防范XSS攻擊
1）前端，服務(wù)端，同時(shí)需要字符串輸入的長(zhǎng)度限制。
2）前端，服務(wù)端，同時(shí)需要對(duì)HTML轉(zhuǎn)義處理。將其中的”<”,”>”等特殊字符進(jìn)行轉(zhuǎn)義編碼。
防 XSS 的核心是必須對(duì)輸入的數(shù)據(jù)做過(guò)濾處理。

3、什么是CSRF攻擊

跨站點(diǎn)請(qǐng)求偽造，指攻擊者通過(guò)跨站請(qǐng)求，以合法的用戶的身份進(jìn)行非法操作?？梢赃@么理解CSRF攻擊：攻擊者盜用你的身份，以你的名義向第三方網(wǎng)站發(fā)送惡意請(qǐng)求。CRSF能做的事情包括利用你的身份發(fā)郵件，發(fā)短信，進(jìn)行交易轉(zhuǎn)賬，甚至盜取賬號(hào)信息。如何防范CSRF攻擊。

• 安全框架，例如Spring Security。
• token機(jī)制。在HTTP請(qǐng)求中進(jìn)行token驗(yàn)證，如果請(qǐng)求中沒(méi)有token或者token內(nèi)容不正確，則認(rèn)為CSRF攻擊而拒絕該請(qǐng)求。
• 驗(yàn)證碼。通常情況下，驗(yàn)證碼能夠很好的遏制CSRF攻擊，但是很多情況下，出于用戶體驗(yàn)考慮，驗(yàn)證碼只能作為一種輔助手段，而不是最主要的解決方案。
• referer識(shí)別。在HTTP Header中有一個(gè)字段Referer，它記錄了HTTP請(qǐng)求的來(lái)源地址。如果Referer是其他網(wǎng)站，就有可能是CSRF攻擊，則拒絕該請(qǐng)求。但是，服務(wù)器并非都能取到Referer。很多用戶出于隱私保護(hù)的考慮，限制了Referer的發(fā)送。在某些情況下，瀏覽器也不會(huì)發(fā)送Referer，例如HTTPS跳轉(zhuǎn)到HTTP。
  1）驗(yàn)證請(qǐng)求來(lái)源地址；
  2）關(guān)鍵操作添加驗(yàn)證碼；
  3）在請(qǐng)求地址添加 token 并驗(yàn)證。

4、什么是文件上傳漏洞

文件上傳漏洞，指的是用戶上傳一個(gè)可執(zhí)行的腳本文件，并通過(guò)此腳本文件獲得了執(zhí)行服務(wù)端命令的能力。
許多第三方框架、服務(wù)，都曾經(jīng)被爆出文件上傳漏洞，比如很早之前的Struts2，以及富文本編輯器等等，可被攻擊者上傳惡意代碼，有可能服務(wù)端就被人黑了。如何防范文件上傳漏洞

• 文件上傳的目錄設(shè)置為不可執(zhí)行。
  1）判斷文件類型。在判斷文件類型的時(shí)候，可以結(jié)合使用MIME Type，后綴檢查等方式。因?yàn)閷?duì)于上傳文件，不能簡(jiǎn)單地通過(guò)后綴名稱來(lái)判斷文件的類型，因?yàn)楣粽呖梢詫⒖蓤?zhí)行文件的后綴名稱改為圖片或其他后綴類型，誘導(dǎo)用戶執(zhí)行。
  2）對(duì)上傳的文件類型進(jìn)行白名單校驗(yàn)，只允許上傳可靠類型。
  3）上傳的文件需要進(jìn)行重新命名，使攻擊者無(wú)法猜想上傳文件的訪問(wèn)路徑，將極大地增加攻擊成本，同時(shí)向shell.php.rar.ara這種文件，因?yàn)橹孛鵁o(wú)法成功實(shí)施攻擊。
  4）限制上傳文件的大小。
  5）單獨(dú)設(shè)置文件服務(wù)器的域名。

5、DDos 攻擊

客戶端向服務(wù)端發(fā)送請(qǐng)求鏈接數(shù)據(jù)包，服務(wù)端向客戶端發(fā)送確認(rèn)數(shù)據(jù)包，客戶端不向服務(wù)端發(fā)送確認(rèn)數(shù)據(jù)包，服務(wù)器一直等待來(lái)自客戶端的確認(rèn)
沒(méi)有徹底根治的辦法，除非不使用TCP

• DDos 預(yù)防：
  1）限制同時(shí)打開(kāi)SYN半鏈接的數(shù)目
  2）縮短SYN半鏈接的Time out 時(shí)間
  3）關(guān)閉不必要的服務(wù)

重要協(xié)議分布圖

1、arp協(xié)議的工作原理

地址解析協(xié)議，即ARP（Address Resolution Protocol），是根據(jù)IP地址獲取物理地址的一個(gè)TCP/IP協(xié)議。

• 發(fā)送ARP請(qǐng)求的以太網(wǎng)數(shù)據(jù)幀 廣播 到以太網(wǎng)上的每個(gè)主機(jī)，ARP請(qǐng)求幀中包含了目的主機(jī)的IP地址。
• 目的主機(jī)收到了該ARP請(qǐng)求之后，會(huì)發(fā)送一個(gè)ARP應(yīng)答，里面包含了目的主機(jī)的MAC地址。

ARP協(xié)議工作原理：

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

主機(jī)（網(wǎng)絡(luò)接口）新加入網(wǎng)絡(luò)時(shí)（也可能只是mac地址發(fā)生變化，接口重啟等）， 會(huì)發(fā)送免費(fèi)ARP報(bào)文把自己IP地址與Mac地址的映射關(guān)系廣播給其他主機(jī)。

網(wǎng)絡(luò)上的主機(jī)接收到免費(fèi)ARP報(bào)文時(shí)，會(huì)更新自己的ARP緩沖區(qū)。將新的映射關(guān)系更新到自己的ARP表中。

某個(gè)主機(jī)需要發(fā)送報(bào)文時(shí)，首先檢查 ARP 列表中是否有對(duì)應(yīng) IP 地址的目的主機(jī)的 MAC 地址，如果有，則直接發(fā)送數(shù)據(jù)，如果沒(méi)有，就向本網(wǎng)段的所有主機(jī)發(fā)送 ARP 數(shù)據(jù)包，該數(shù)據(jù)包包括的內(nèi)容有：源主機(jī) IP 地址，源主機(jī) MAC 地址，目的主機(jī)的 IP 地址等。

當(dāng)本網(wǎng)絡(luò)的所有主機(jī)收到該 ARP 數(shù)據(jù)包時(shí)：
（A）首先檢查數(shù)據(jù)包中的 IP 地址是否是自己的 IP 地址，如果不是，則忽略該數(shù)據(jù)包。
（B）如果是，則首先從數(shù)據(jù)包中取出源主機(jī)的 IP 和 MAC 地址寫(xiě)入到 ARP 列表中，如果已經(jīng)存在，則覆蓋。
（C） 然后將自己的 MAC 地址寫(xiě)入 ARP 響應(yīng)包中，告訴源主機(jī)自己是它想要找的 MAC 地址。
（D）源主機(jī)收到 ARP 響應(yīng)包后。將目的主機(jī)的 IP 和 MAC 地址寫(xiě)入 ARP 列表，并利用此信息發(fā)送數(shù)據(jù)。如果源主機(jī)一直沒(méi)有收到 ARP 響應(yīng)數(shù)據(jù)包，表示 ARP 查詢失敗。ARP高速緩存（即ARP表）是 ARP地址解析協(xié)議能夠高效運(yùn)行的關(guān)鍵

2、什么是RARP？工作原理

概括： 反向地址轉(zhuǎn)換協(xié)議，網(wǎng)絡(luò)層協(xié)議，RARP與ARP工作方式相反。 RARP使只知道自己硬件地址的主機(jī)能夠知道其IP地址。RARP發(fā)出要反向解釋的物理地址并希望返回其IP地址，應(yīng)答包括能夠提供所需信息的RARP服務(wù)器發(fā)出的IP地址。
原理：

(1)網(wǎng)絡(luò)上的每臺(tái)設(shè)備都會(huì)有一個(gè)獨(dú)一無(wú)二的硬件地址，通常是由設(shè)備廠商分配的MAC地址。主機(jī)從網(wǎng)卡上讀取MAC地址，然后在網(wǎng)絡(luò)上發(fā)送一個(gè)RARP請(qǐng)求的廣播數(shù)據(jù)包，請(qǐng)求RARP服務(wù)器回復(fù)該主機(jī)的IP地址。

(2)RARP服務(wù)器收到了RARP請(qǐng)求數(shù)據(jù)包，為其分配IP地址，并將RARP回應(yīng)發(fā)送給主機(jī)。

(3)PC1收到RARP回應(yīng)后，就使用得到的IP地址進(jìn)行通訊。

3、dns是什么？dns的工作原理

將主機(jī)域名轉(zhuǎn)換為ip地址，屬于應(yīng)用層協(xié)議，使用UDP傳輸。（DNS應(yīng)用層協(xié)議，以前有個(gè)考官問(wèn)過(guò)）

過(guò)程：
總結(jié)： 瀏覽器緩存，系統(tǒng)緩存，路由器緩存，IPS服務(wù)器緩存，根域名服務(wù)器緩存，頂級(jí)域名服務(wù)器緩存，主域名服務(wù)器緩存。
一、主機(jī)向本地域名服務(wù)器的查詢一般都是采用遞歸查詢。
二、本地域名服務(wù)器向根域名服務(wù)器的查詢的迭代查詢。
1)當(dāng)用戶輸入域名時(shí)，瀏覽器先檢查自己的緩存中是否 這個(gè)域名映射的ip地址，有解析結(jié)束。
2）若沒(méi)命中，則檢查操作系統(tǒng)緩存（如Windows的hosts）中有沒(méi)有解析過(guò)的結(jié)果，有解析結(jié)束。
3）若無(wú)命中，則請(qǐng)求本地域名服務(wù)器解析（ LDNS）。
4）若LDNS沒(méi)有命中就直接跳到根域名服務(wù)器請(qǐng)求解析。根域名服務(wù)器返回給LDNS一個(gè) 主域名服務(wù)器地址。
5） 此時(shí)LDNS再發(fā)送請(qǐng)求給上一步返回的gTLD（ 通用頂級(jí)域）， 接受請(qǐng)求的gTLD查找并返回這個(gè)域名對(duì)應(yīng)的Name Server的地址
6） Name Server根據(jù)映射關(guān)系表找到目標(biāo)ip，返回給LDNS
7） LDNS緩存這個(gè)域名和對(duì)應(yīng)的ip， 把解析的結(jié)果返回給用戶，用戶根據(jù)TTL值緩存到本地系統(tǒng)緩存中，域名解析過(guò)程至此結(jié)束

4、rip協(xié)議是什么？rip的工作原理

RIP動(dòng)態(tài)路由選擇協(xié)議（網(wǎng)絡(luò)層協(xié)議）
RIP是一種基于距離矢量（Distance-Vector）算法的協(xié)議，它使用跳數(shù)（Hop Count）作為度量來(lái)衡量到達(dá)目的網(wǎng)絡(luò)的路由距離。RIP通過(guò)UDP報(bào)文進(jìn)行路由信息的交換，使用的端口號(hào)為520。

• 工作原理：
  RIP路由協(xié)議用“更新（UNPDATES）”和“請(qǐng)求（REQUESTS）”這兩種分組來(lái)傳輸信息的。每個(gè)具有RIP協(xié)議功能的路由器每隔30秒用UDP520端口給與之直接相連的機(jī)器廣播更新信息。并且在（ 用“路程段數(shù)”（即“跳數(shù)”）作為網(wǎng)絡(luò)距離的尺度。每個(gè)路由器在）給相鄰路由器發(fā)出路由信息時(shí)，都會(huì)給每個(gè)路徑加上內(nèi)部距離。

• 路由器的收斂機(jī)制：
  任何距離向量路由選擇協(xié)議（如RIP）都有一個(gè)問(wèn)題，路由器不知道網(wǎng)絡(luò)的全局情況，路由器必須依靠相鄰路由器來(lái)獲取網(wǎng)絡(luò)的可達(dá)信息。由于路由選擇更新信息在網(wǎng)絡(luò)上傳播慢，距離向量路由選擇算法有一個(gè)慢收斂問(wèn)題，這個(gè)問(wèn)題將導(dǎo)致不一致性產(chǎn)生。

• RIP較少路由收斂機(jī)制帶來(lái)的問(wèn)題：
  1）記數(shù)到無(wú)窮大機(jī)制： RIP協(xié)議允許最大跳數(shù)為15。大于15的目的地被認(rèn)為是不可達(dá)。 當(dāng)路徑的跳數(shù)超過(guò)15，這條路徑才從路由表中刪除。
  2） 水平分割法： 路由器不向路徑到來(lái)的方向回傳此路徑。當(dāng)打開(kāi)路由器接口后，路由器記錄路徑是從哪個(gè)接口來(lái)的，并且不向此接口回傳此路徑。
  3） 破壞逆轉(zhuǎn)的水平分割法： 忽略在更新過(guò)程中從一個(gè)路由器獲取的路徑又傳回該路由器
  4）保持定時(shí)器法： 防止路由器在路徑從路由表中刪除后一定的時(shí)間內(nèi)（通常為180秒）接受新的路由信息。 保證每個(gè)路由器都收到了路徑不可達(dá)信息
  5） 觸發(fā)更新法： 當(dāng)某個(gè)路徑的跳數(shù)改變了，路由器立即發(fā)出更新信息，不管路由器是否到達(dá)常規(guī)信息更新時(shí)間都發(fā)出更新信息。

• RIP的缺點(diǎn)
  由于15跳為最大值，RIP只能應(yīng)用于小規(guī)模網(wǎng)絡(luò)；2、收斂速度慢；3、根據(jù)跳數(shù)選擇的路由，不一定是最優(yōu)路由。

5、OSPF協(xié)議？OSPF的工作原理

OSPF（Open Shortest Pass First,開(kāi)放最短路徑優(yōu)先協(xié)議），是一個(gè)最常用的內(nèi)部網(wǎng)管協(xié)議，是一個(gè)鏈路狀態(tài)協(xié)議。(網(wǎng)絡(luò)層協(xié)議,)

• 原理：
  OSPF組播的方式在所有開(kāi)啟OSPF的接口發(fā)送Hello包，用來(lái)確定是否有OSPF鄰居，若發(fā)現(xiàn)了，則建立OSPF鄰居關(guān)系，形成鄰居表，之后互相發(fā)送LSA（鏈路狀態(tài)通告）相互通告路由，形成LSDB（鏈路狀態(tài)數(shù)據(jù)庫(kù)）。再通過(guò)SPF算法，計(jì)算最佳路徑（cost最小）后放入路由表。

TCP與UDP區(qū)別總結(jié)？

1. TCP面向連接（如打電話要先撥號(hào)建立連接）提供可靠的服務(wù);UDP是無(wú)連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接，;UDP盡最大努力交付，即不保證可靠交付。（由于UDP無(wú)需建立連接，因此UDP不會(huì)引入建立連接的時(shí)延，TCP需要在端系統(tǒng)中維護(hù)連接狀態(tài)，比如接受和發(fā)送緩存，擁塞控制，序號(hào)與確認(rèn)號(hào)的參數(shù)等，故TCP會(huì)比UDP慢）
2. UDP具有較好的實(shí)時(shí)性，工作效率比TCP高，適用于對(duì)高速傳輸和實(shí)時(shí)性有較高的通信或廣播通信。
3. 每一條TCP連接只能是一對(duì)一的;UDP支持一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多的交互通信
4. UDP分組首部開(kāi)銷小，TCP首部開(kāi)銷20字節(jié);UDP的首部開(kāi)銷小，只有8個(gè)字節(jié)。
5. TCP面向字節(jié)流，實(shí)際上是TCP把數(shù)據(jù)看成一連串無(wú)結(jié)構(gòu)的字節(jié)流;UDP是面向報(bào)文的（一次交付一個(gè)完整的報(bào)文，報(bào)文不可分割，報(bào)文是UDP數(shù)據(jù)報(bào)處理的最小單位）。
6. UDP適合一次性傳輸較小數(shù)據(jù)的網(wǎng)絡(luò)應(yīng)用，如DNS，SNMP等

什么是三次握手四次揮手？tcp為什么要三次握手？

為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤

第一次握手：建立連接時(shí)，客戶端發(fā)送syn包(syn=j)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)；
第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k），即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)；
第三次握手：客戶端收到服務(wù)器的SYN＋ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。
完成三次握手，客戶端與服務(wù)器開(kāi)始傳送數(shù)據(jù)

1. 客戶端先發(fā)送FIN，進(jìn)入FIN_WAIT1狀態(tài)，用來(lái)關(guān)閉Client到Server的數(shù)據(jù)傳送
2. 服務(wù)端收到FIN，發(fā)送ACK，進(jìn)入CLOSE_WAIT狀態(tài)，客戶端收到這個(gè)ACK，進(jìn)入FIN_WAIT2狀態(tài)
3. 服務(wù)端發(fā)送FIN，進(jìn)入LAST_ACK狀態(tài)，用來(lái)關(guān)閉Server到Client的數(shù)據(jù)傳送
4. 客戶端收到FIN，發(fā)送ACK，進(jìn)入TIME_WAIT狀態(tài)，服務(wù)端收到ACK，進(jìn)入CLOSE狀態(tài)（等待2MSL時(shí)間，約4分鐘。主要是防止最后一個(gè)ACK丟失。）
   第一次揮手：主動(dòng)關(guān)閉方發(fā)送一個(gè)FIN，用來(lái)關(guān)閉主動(dòng)方到被動(dòng)關(guān)閉方的數(shù)據(jù)傳送，也就是主動(dòng)關(guān)閉方告訴被動(dòng)關(guān)閉方：我已經(jīng)不 會(huì)再給你發(fā)數(shù)據(jù)了(當(dāng)然，在fin包之前發(fā)送出去的數(shù)據(jù)，如果沒(méi)有收到對(duì)應(yīng)的ack確認(rèn)報(bào)文，主動(dòng)關(guān)閉方依然會(huì)重發(fā)這些數(shù)據(jù))，但是，此時(shí)主動(dòng)關(guān)閉方還可 以接受數(shù)據(jù)。
   第二次揮手：被動(dòng)關(guān)閉方收到FIN包后，發(fā)送一個(gè)ACK給對(duì)方，確認(rèn)序號(hào)為收到序號(hào)+1（與SYN相同，一個(gè)FIN占用一個(gè)序號(hào)）。
   第三次揮手：被動(dòng)關(guān)閉方發(fā)送一個(gè)FIN，用來(lái)關(guān)閉被動(dòng)關(guān)閉方到主動(dòng)關(guān)閉方的數(shù)據(jù)傳送，也就是告訴主動(dòng)關(guān)閉方，我的數(shù)據(jù)也發(fā)送完了，不會(huì)再給你發(fā)數(shù)據(jù)了。
   第四次揮手：主動(dòng)關(guān)閉方收到FIN后，發(fā)送一個(gè)ACK給被動(dòng)關(guān)閉方，確認(rèn)序號(hào)為收到序號(hào)+1，至此，完成四次揮手。

GET 和 POST 的區(qū)別

• get是獲取數(shù)據(jù)，post是修改數(shù)據(jù)
• get把請(qǐng)求的數(shù)據(jù)放在url上， 以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連，所以get不太安全。而post把數(shù)據(jù)放在HTTP的包體內(nèi)（requrest body）
• get提交的數(shù)據(jù)最大是2k（ 限制實(shí)際上取決于瀏覽器）， post理論上沒(méi)有限制。
• GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包，瀏覽器會(huì)把http header和data一并發(fā)送出去，服務(wù)器響應(yīng)200(返回?cái)?shù)據(jù)); POST產(chǎn)生兩個(gè)TCP數(shù)據(jù)包，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 ok(返回?cái)?shù)據(jù))。
• GET請(qǐng)求會(huì)被瀏覽器主動(dòng)緩存，而POST不會(huì)，除非手動(dòng)設(shè)置。
• GET是冪等的，而POST不是冪等的

Cookies和session區(qū)別

Cookie和Session都是客戶端與服務(wù)器之間保持狀態(tài)的解決方案

1. 存儲(chǔ)的位置不同，cookie：存放在客戶端，session：存放在服務(wù)端。Session存儲(chǔ)的數(shù)據(jù)比較安全
2. 存儲(chǔ)的數(shù)據(jù)類型不同
   兩者都是key-value的結(jié)構(gòu)，但針對(duì)value的類型是有差異的
   cookie：value只能是字符串類型，session：value是Object類型
3. 存儲(chǔ)的數(shù)據(jù)大小限制不同
   cookie：大小受瀏覽器的限制，很多是是4K的大小， session：理論上受當(dāng)前內(nèi)存的限制，
4. 生命周期的控制
   cookie的生命周期當(dāng)瀏覽器關(guān)閉的時(shí)候，就消亡了
   (1)cookie的生命周期是累計(jì)的，從創(chuàng)建時(shí)，就開(kāi)始計(jì)時(shí)，20分鐘后，cookie生命周期結(jié)束，
   (2)session的生命周期是間隔的，從創(chuàng)建時(shí)，開(kāi)始計(jì)時(shí)如在20分鐘，沒(méi)有訪問(wèn)session，那么session生命周期被銷毀

session 的工作原理？

session 的工作原理是客戶端登錄完成之后，服務(wù)器會(huì)創(chuàng)建對(duì)應(yīng)的 session，session 創(chuàng)建完之后，會(huì)把 session 的 id 發(fā)送給客戶端，客戶端再存儲(chǔ)到瀏覽器中。這樣客戶端每次訪問(wèn)服務(wù)器時(shí)，都會(huì)帶著 sessionid，服務(wù)器拿到 sessionid 之后，在內(nèi)存找到與之對(duì)應(yīng)的 session 這樣就可以正常工作了。

一次完整的HTTP請(qǐng)求過(guò)程

域名解析 --> 發(fā)起TCP的3次握手 --> 建立TCP連接后發(fā)起http請(qǐng)求 --> 服務(wù)器響應(yīng)http請(qǐng)求，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，并請(qǐng)求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對(duì)頁(yè)面進(jìn)行渲染呈現(xiàn)給用戶。

HTTPS和HTTP的區(qū)別

1. HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，因此使用HTTP協(xié)議傳輸隱私信息非常不安全， HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全。
2. https協(xié)議需要到ca申請(qǐng)證書(shū)，一般免費(fèi)證書(shū)較少，因而需要一定費(fèi)用。
3. http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

OSI 的七層模型都有哪些？

• 物理層：利用傳輸介質(zhì)為數(shù)據(jù)鏈路層提供物理連接，實(shí)現(xiàn)比特流的透明傳輸。
• 數(shù)據(jù)鏈路層：接收來(lái)自物理層的位流形式的數(shù)據(jù)，并封裝成幀，傳送到上一層
• 網(wǎng)絡(luò)層：將網(wǎng)絡(luò)地址翻譯成對(duì)應(yīng)的物理地址，并通過(guò)路由選擇算法為分組通過(guò)通信子網(wǎng)選擇最適當(dāng)?shù)穆窂健?/li>
• 傳輸層：在源端與目的端之間提供可靠的透明數(shù)據(jù)傳輸
• 會(huì)話層：負(fù)責(zé)在網(wǎng)絡(luò)中的兩節(jié)點(diǎn)之間建立、維持和終止通信
• 表示層：處理用戶信息的表示問(wèn)題，數(shù)據(jù)的編碼，壓縮和解壓縮，數(shù)據(jù)的加密和解密
• 應(yīng)用層：為用戶的應(yīng)用進(jìn)程提供網(wǎng)絡(luò)通信服務(wù)

http長(zhǎng)連接和短連接的區(qū)別

在HTTP/1.0中默認(rèn)使用短連接。也就是說(shuō)，客戶端和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接，任務(wù)結(jié)束就中斷連接。而從HTTP/1.1起，默認(rèn)使用長(zhǎng)連接，用以保持連接特性。

什么是TCP粘包/拆包？發(fā)生原因？解決方案 一個(gè)完整的業(yè)務(wù)可能會(huì)被TCP拆分成多個(gè)包進(jìn)行發(fā)送，也有可能把多個(gè)小的包封裝成一個(gè)大的數(shù)據(jù)包發(fā)送，這個(gè)就是TCP的拆包和粘包問(wèn)題。
原因：

1. 應(yīng)用程序?qū)懭霐?shù)據(jù)的字節(jié)大小大于套接字發(fā)送緩沖區(qū)的大小.
2. 進(jìn)行MSS大小的TCP分段。( MSS=TCP報(bào)文段長(zhǎng)度-TCP首部長(zhǎng)度)
3. 以太網(wǎng)的payload大于MTU進(jìn)行IP分片。（ MTU指：一種通信協(xié)議的某一層上面所能通過(guò)的最大數(shù)據(jù)包大小。）

解決方案：

1. 消息定長(zhǎng)。
2. 在包尾部增加回車(chē)或者空格符等特殊字符進(jìn)行分割
3. 將消息分為消息頭和消息尾。
4. 使用其它復(fù)雜的協(xié)議，如RTMP協(xié)議等。

TCP如何保證可靠傳輸？

1. 三次握手。
2. 將數(shù)據(jù)截?cái)酁楹侠淼拈L(zhǎng)度。應(yīng)用數(shù)據(jù)被分割成 TCP 認(rèn)為最適合發(fā)送的數(shù)據(jù)塊（按字節(jié)編號(hào)，合理分片）
3. 超時(shí)重發(fā)。當(dāng) TCP 發(fā)出一個(gè)段后，它啟動(dòng)一個(gè)定時(shí)器，如果不能及時(shí)收到一個(gè)確認(rèn)就重發(fā)
4. 確認(rèn)應(yīng)答：對(duì)于收到的請(qǐng)求，給出確認(rèn)響應(yīng)
5. 校驗(yàn)和：校驗(yàn)出包有錯(cuò)，丟棄報(bào)文段，不給出響應(yīng)
6. 序列號(hào)：對(duì)失序數(shù)據(jù)進(jìn)行重新排序，然后才交給應(yīng)用層
7. 丟棄重復(fù)數(shù)據(jù)：對(duì)于重復(fù)數(shù)據(jù) ， 能夠丟棄重復(fù)數(shù)據(jù)
8. 流量控制。TCP 連接的每一方都有固定大小的緩沖空間。TCP 的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)。這將防止較快主機(jī)致使較慢主機(jī)的緩沖區(qū)溢出。
9. 擁塞控制。當(dāng)網(wǎng)絡(luò)擁塞時(shí)，減少數(shù)據(jù)的發(fā)送。

常見(jiàn)的狀態(tài)碼有哪些？

• 200 OK //客戶端請(qǐng)求成功403 Forbidden //服務(wù)器收到請(qǐng)求，但是拒絕提供服務(wù)
• 404 Not Found //請(qǐng)求資源不存在，eg：輸入了錯(cuò)誤的URL
• 500 Internal Server Error //服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤URI和URL的區(qū)別URI，統(tǒng)一資源標(biāo)識(shí)符，用來(lái)唯一的標(biāo)識(shí)一個(gè)資源。URL可以用來(lái)標(biāo)識(shí)一個(gè)資源，而且還指明了如何定位這個(gè)資源。

什么是SSL ？https是如何保證數(shù)據(jù)傳輸?shù)陌踩⊿SL是怎么工作保證安全的）

SSL代表安全套接字層。它是一種用于加密和驗(yàn)證應(yīng)用程序（如瀏覽器）和Web服務(wù)器之間發(fā)送的數(shù)據(jù)的協(xié)議。 身份驗(yàn)證 ， 加密Https的加密機(jī)制是一種共享密鑰加密和公開(kāi)密鑰加密并用的混合加密機(jī)制。SSL/TLS協(xié)議作用：認(rèn)證用戶和服務(wù)，加密數(shù)據(jù)，維護(hù)數(shù)據(jù)的完整性的應(yīng)用層協(xié)議加密和解密需要兩個(gè)不同的密鑰，故被稱為非對(duì)稱加密；加密和解密都使用同一個(gè)密鑰的 對(duì)稱加密。 優(yōu)點(diǎn)在于加密、解密效率通常比較高HTTPS 是基于非對(duì)稱加密的， 公鑰是公開(kāi)的，
（1）客戶端向服務(wù)器端發(fā)起SSL連接請(qǐng)求；
（2） 服務(wù)器把公鑰發(fā)送給客戶端，并且服務(wù)器端保存著唯一的私鑰
（3）客戶端用公鑰對(duì)雙方通信的對(duì)稱秘鑰進(jìn)行加密，并發(fā)送給服務(wù)器端
（4）服務(wù)器利用自己唯一的私鑰對(duì)客戶端發(fā)來(lái)的對(duì)稱秘鑰進(jìn)行解密，
（5）進(jìn)行數(shù)據(jù)傳輸，服務(wù)器和客戶端雙方用公有的相同的對(duì)稱秘鑰對(duì)數(shù)據(jù)進(jìn)行加密解密，可以保證在數(shù)據(jù)收發(fā)過(guò)程中的安全，即是第三方獲得數(shù)據(jù)包，也無(wú)法對(duì)其進(jìn)行加密，解密和篡改。
因?yàn)閿?shù)字簽名、摘要是證書(shū)防偽非常關(guān)鍵的武器。 “摘要”就是對(duì)傳輸?shù)膬?nèi)容，通過(guò)hash算法計(jì)算出一段固定長(zhǎng)度的串。然后，在通過(guò)CA的私鑰對(duì)這段摘要進(jìn)行加密，加密后得到的結(jié)果就是“數(shù)字簽名”

SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說(shuō)，客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密。
如何保證公鑰不被篡改？
將公鑰放在數(shù)字證書(shū)中。只要證書(shū)是可信的，公鑰就是可信的。
公鑰加密計(jì)算量太大，如何減少耗用的時(shí)間？
每一次對(duì)話（session），客戶端和服務(wù)器端都生成一個(gè)"對(duì)話密鑰"（session key），用它來(lái)加密信息。由于"對(duì)話密鑰"是對(duì)稱加密，所以運(yùn)算速度非?？?，而服務(wù)器公鑰只用于加密"對(duì)話密鑰"本身，這樣就減少了加密運(yùn)算的消耗時(shí)間。
（1） 客戶端向服務(wù)器端索要并驗(yàn)證公鑰。
（2） 雙方協(xié)商生成"對(duì)話密鑰"。
（3） 雙方采用"對(duì)話密鑰"進(jìn)行加密通信。上面過(guò)程的前兩步，又稱為"握手階段"（handshake）。

《計(jì)算機(jī)網(wǎng)絡(luò)》書(shū)本：
SSL工作過(guò)程，A：客戶端，B：服務(wù)器端

1. 協(xié)商加密算法：A向B發(fā)送SSL版本號(hào)和可選加密算法，B選擇自己支持的算法并告知A
2. 服務(wù)器鑒別：B向A發(fā)送包含公鑰的數(shù)字證書(shū)，A使用CA公開(kāi)發(fā)布的公鑰對(duì)證書(shū)進(jìn)行驗(yàn)證
3. 會(huì)話密鑰計(jì)算：A產(chǎn)生一個(gè)隨機(jī)秘密數(shù)，用B的公鑰進(jìn)行加密后發(fā)送給B，B根據(jù)協(xié)商的算法產(chǎn)生共享的對(duì)稱會(huì)話密鑰并發(fā)送給A.
4. 安全數(shù)據(jù)傳輸：雙方用會(huì)話密鑰加密和解密它們之間傳送的數(shù)據(jù)并驗(yàn)證其完整性

TCP對(duì)應(yīng)的應(yīng)用層協(xié)議

FTP：定義了文件傳輸協(xié)議，使用21端口.
Telnet：它是一種用于遠(yuǎn)程登陸的端口,23端口
SMTP：定義了簡(jiǎn)單郵件傳送協(xié)議，服務(wù)器開(kāi)放的是25號(hào)端口。
POP3：它是和SMTP對(duì)應(yīng)，POP3用于接收郵件。
HTTP

UDP對(duì)應(yīng)的應(yīng)用層協(xié)議

DNS：用于域名解析服務(wù)，用的是53號(hào)端口
SNMP：簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議，使用161號(hào)端口
TFTP(Trival File Transfer Protocal)：簡(jiǎn)單文件傳輸協(xié)議，69文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-427398.html

到了這里，關(guān)于【面試】面試官問(wèn)的幾率較大的網(wǎng)絡(luò)安全面試題的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！