即時通訊初學(xué)者必知必會的20個網(wǎng)絡(luò)編程和通信安全知識點

Posted on 2025-02-27 13:04 Jack Jiang 閱讀(82) 評論(0) 編輯收藏

本文引用自公眾號“計算科學(xué)與信息化”，原題“運維必知的20個網(wǎng)絡(luò)安全知識點!”，下文進行了排版和內(nèi)容優(yōu)化。

1、引言

即時通訊IM應(yīng)用開發(fā)的初學(xué)者很容易迷失在網(wǎng)絡(luò)編程的復(fù)雜性以及通信安全的各種概念里，本文不涉及深度理論知識，盡量通過一句話或幾句話讓你快速了解20個相關(guān)的網(wǎng)絡(luò)編程和通信安全知識點，希望能助你愉快地開始即時通訊應(yīng)用開發(fā)。

技術(shù)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發(fā)布于：http://www.52im.net/thread-217-1-1.html）

2、什么是SQL注入攻擊

攻擊者在 HTTP 請求中注入惡意的 SQL 代碼，服務(wù)器使用參數(shù)構(gòu)建數(shù)據(jù)庫 SQL 命令時，惡意SQL 被一起構(gòu)造，并在數(shù)據(jù)庫中執(zhí)行。

注入方法：

用戶登錄，輸入用戶名 lianggzone，密碼 ‘ or ‘1’=’1 ，如果此時使用參數(shù)構(gòu)造的方式，就會出現(xiàn)：

select * from user where name = ‘lianggzone’ and password = ‘’ or ‘1’=‘1’

不管用戶名和密碼是什么內(nèi)容，使查詢出來的用戶列表不為空。如何防范 SQL 注入攻擊使用預(yù)編譯的 PrepareStatement 是必須的，但是一般我們會從兩個方面同時入手。

Web端預(yù)防：

1）有效性檢驗；
2）限制字符串輸入的長度。

服務(wù)端預(yù)防：

1）不用拼接 SQL 字符串；
2）使用預(yù)編譯的 PrepareStatement；
3）有效性檢驗。(為什么服務(wù)端還要做有效性檢驗？第一準則，外部都是不可信的，防止攻擊者繞過 Web 端請求)；
4）過濾 SQL 需要的參數(shù)中的特殊字符。比如單引號、雙引號。

3、什么是XSS攻擊

跨站點腳本攻擊，指攻擊者通過篡改網(wǎng)頁，嵌入惡意腳本程序，在用戶瀏覽網(wǎng)頁時，控制用戶瀏覽器進行惡意操作的一種攻擊方式。

如何防范XSS攻擊？

1）前端，服務(wù)端，同時需要字符串輸入的長度限制；
2）前端，服務(wù)端，同時需要對 HTML 轉(zhuǎn)義處理。將其中的”<”,”>”等特殊字符進行轉(zhuǎn)義編碼。

預(yù)防XSS 的核心是必須對輸入的數(shù)據(jù)做過濾處理。

4、什么是CSRF攻擊

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

如何防范CSRF攻擊？

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

5、文件上傳漏洞

文件上傳漏洞，指的是用戶上傳一個可執(zhí)行的腳本文件，并通過此腳本文件獲得了執(zhí)行服務(wù)端命令的能力。

許多第三方框架、服務(wù)，都曾經(jīng)被爆出文件上傳漏洞，比如很早之前的 Struts2，以及富文本編輯器等等，可被攻擊者上傳惡意代碼，有可能服務(wù)端就被人黑了。

如何防范文件上傳攻擊？

1）判斷文件類型：在判斷文件類型的時候，可以結(jié)合使用 MIME Type，后綴檢查等方式。因為對于上傳文件，不能簡單地通過后綴名稱來判斷文件的類型，因為攻擊者可以將可執(zhí)行文件的后綴名稱改為圖片或其他后綴類型，誘導(dǎo)用戶執(zhí)行；
2）對上傳的文件類型進行白名單校驗：只允許上傳可靠的類型；
3）上傳的文件需要進行重新命名：使攻擊者無法猜想上傳文件的訪問路徑，將極大地增加攻擊成本，同時向shell.php.rar.ara 這種文件，因為重命名而無法成功實施攻擊；
4）限制上傳文件的大??；
5）單獨設(shè)置文件服務(wù)器的域名。

6、什么是DDoS攻擊

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

DDos 預(yù)防：

1）限制同時打開 SYN 半鏈接的數(shù)目；
2）縮短 SYN 半鏈接的 Time out 時間；
3）關(guān)閉不必要的服務(wù)。

7、什么是ARP協(xié)議

1）概述：

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

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

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

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

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

網(wǎng)絡(luò)上的主機接收到免費 ARP 報文時，會更新自己的 ARP 緩沖區(qū)。將新的映射關(guān)系更新到自己的 ARP 表中。

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

3）當本網(wǎng)絡(luò)的所有主機收到該 ARP 數(shù)據(jù)包時：

首先檢查數(shù)據(jù)包中的 IP 地址是否是自己的 IP 地址，如果不是，則忽略該數(shù)據(jù)包。

如果是，則首先從數(shù)據(jù)包中取出源主機的 IP 和 MAC 地址寫入到 ARP 列表中，如果已經(jīng)存在，則覆蓋。

然后將自己的 MAC 地址寫入 ARP 響應(yīng)包中，告訴源主機自己是它想要找的 MAC地址。

源主機收到 ARP 響應(yīng)包后。將目的主機的 IP 和 MAC 地址寫入 ARP 列表，并利用此信息發(fā)送數(shù)據(jù)。如果源主機一直沒有收到 ARP 響應(yīng)數(shù)據(jù)包，表示 ARP 查詢失敗。ARP 高速緩存（即 ARP 表）是 ARP 地址解析協(xié)議能夠高效運行的關(guān)鍵。

4）如何防范ARP攻擊：

1）MAC地址綁定：使網(wǎng)絡(luò)中每一臺計算機的IP地址與硬件地址一一對應(yīng)，不可更改；
2）使用靜態(tài)ARP緩存：用手工方法更新緩存中的記錄，使ARP欺騙無法進行；
3）使用ARP服務(wù)器：通過該服務(wù)器查找自己的ARP轉(zhuǎn)換表來響應(yīng)其他機器的ARP廣播。確保這臺ARP服務(wù)器不被黑；
4）使用ARP欺騙防護軟件：如ARP防火墻；
5）及時發(fā)現(xiàn)正在進行ARP欺騙的主機并將其隔離；
6）使用最新版本DNS服務(wù)器軟件并及時安裝補??；
7）關(guān)閉DNS服務(wù)器的遞歸功能：DNS服務(wù)器利用緩存中的記錄信息回答查詢請求或是DNS服務(wù)器通過查詢其它服務(wù)器獲得查詢信息并將它發(fā)送給客戶機，這兩種查詢方式稱為遞歸查詢，這種查詢方式容易導(dǎo)致DNS欺騙。
8）限制區(qū)域傳輸范圍：限制域名服務(wù)器做出響應(yīng)的地址、限制域名服務(wù)器做出響應(yīng)的遞歸請求地址、限制發(fā)出請求的地址。
9）限制動態(tài)更新；
10）采用分層的DNS體系結(jié)構(gòu)；
11）檢查源代碼：如果發(fā)生了URL重定向，就一定會發(fā)現(xiàn)。不過，檢查用戶連接的每一個頁面的源代碼對普通用戶來說是不切實際的想法；
12）確保應(yīng)用有效和能適當?shù)馗櫽脩簦簾o論是使用cookie還是會話ID，都應(yīng)該確保要盡可能的長和隨機。

8、RARP工作原理

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

原理：

1）網(wǎng)絡(luò)上的每臺設(shè)備都會有一個獨一無二的硬件地址，通常是由設(shè)備廠商分配的MAC地址。主機從網(wǎng)卡上讀取 MAC 地址，然后在網(wǎng)絡(luò)上發(fā)送一個 RARP 請求的廣播數(shù)據(jù)包，請求 RARP服務(wù)器回復(fù)該主機的 IP 地址；
2）RARP 服務(wù)器收到了 RARP 請求數(shù)據(jù)包，為其分配 IP 地址，并將 RARP 回應(yīng)發(fā)送給主機；
3）PC1 收到 RARP 回應(yīng)后，就使用得到的 IP 地址進行通訊。

9、DNS工作原理

將主機域名轉(zhuǎn)換為 ip 地址，屬于應(yīng)用層協(xié)議，使用 UDP 傳輸。

過程總結(jié)：瀏覽器緩存，系統(tǒng)緩存，路由器緩存，IPS 服務(wù)器緩存，根域名服務(wù)器緩存，頂級域名服務(wù)器緩存，主域名服務(wù)器緩存。

兩種查詢方式：

1）機向本地域名服務(wù)器的查詢一般都是采用遞歸查詢；
2）本地域名服務(wù)器向根域名服務(wù)器的查詢的迭代查詢。

具體是：

1）當用戶輸入域名時，瀏覽器先檢查自己的緩存中是否有這個域名映射的 ip 地址，如果有解析結(jié)束；
2）若沒命中，則檢查操作系統(tǒng)緩存（如 Windows 的 hosts）中有沒有解析過的結(jié)果，有解析結(jié)束；
3）若無命中，則請求本地域名服務(wù)器解析（ LDNS）；
4）若 LDNS 沒有命中就直接跳到根域名服務(wù)器請求解析。根域名服務(wù)器返回給 LDNS一個主域名服務(wù)器地址；
5）此時 LDNS 再發(fā)送請求給上一步返回的 gTLD（通用頂級域），接受請求的 gTLD 查找并返回這個域名對應(yīng)的 Name Server 的地址；
6）Name Server 根據(jù)映射關(guān)系表找到目標 ip，返回給 LDNS；
7）LDNS 緩存這個域名和對應(yīng)的 ip，把解析的結(jié)果返回給用戶，用戶根據(jù) TTL 值緩存到本地系統(tǒng)緩存中，域名解析過程至此結(jié)束。

DNS攻擊：

DNS攻擊防范：

1）安全更新：及時升級所有相關(guān)軟件和操作系統(tǒng)補丁，并確保所有設(shè)備都有最新版本的安全防護軟件；
2）配置正確的權(quán)限：只給予必要用戶相應(yīng)權(quán)限，并禁止使用弱密碼進行登錄；
3）加密傳輸：使用加密技術(shù)（例如SSL / TLS）來保護敏感數(shù)據(jù)在傳輸過程中不受干擾或泄露；
4）多層次驗證機制: 在登錄系統(tǒng)前先經(jīng)過多重身份驗證, 以此增強賬戶安全性；
5）增加容錯機制: 對于核心業(yè)務(wù)建立冷備和熱備，在一旦發(fā)生故障時，可以快速切換到備份系統(tǒng)上，降低業(yè)務(wù)中斷的風(fēng)險。

10、RIP的工作原理

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

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

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

RIP 較少路由收斂機制帶來的問題：

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

RIP的特點：

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

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

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

11、TCP與UDP區(qū)別

直接說結(jié)論：

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

* 相關(guān)文章：一泡尿的時間，快速搞懂TCP和UDP的區(qū)別。

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

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

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

完成三次握手，客戶端與服務(wù)器開始傳送數(shù)據(jù)：

四次揮手：

客戶端先發(fā)送 FIN，進入 FIN_WAIT1 狀態(tài)，用來關(guān)閉 Client 到 Server 的數(shù)據(jù)傳送服務(wù)端收到 FIN，發(fā)送 ACK，進入 CLOSE_WAIT 狀態(tài)，客戶端收到這個 ACK，進入 FIN_WAIT2狀態(tài)。

服務(wù)端發(fā)送 FIN，進入 LAST_ACK 狀態(tài)，用來關(guān)閉 Server 到 Client 的數(shù)據(jù)傳送客戶端收到 FIN，發(fā)送 ACK，進入 TIME_WAIT 狀態(tài)，服務(wù)端收到 ACK，進入 CLOSE 狀態(tài)（等待 2MSL 時間，約 4 分鐘。主要是防止最后一個 ACK 丟失。）

1）第一次揮手：主動關(guān)閉方發(fā)送一個 FIN，用來關(guān)閉主動方到被動關(guān)閉方的數(shù)據(jù)傳送，也就是主動關(guān)閉方告訴被動關(guān)閉方：我已經(jīng)不會再給你發(fā)數(shù)據(jù)了(當然，在 fin 包之前發(fā)送出去的數(shù)據(jù)，如果沒有收到對應(yīng)的 ack 確認報文，主動關(guān)閉方依然會重發(fā)這些數(shù)據(jù))，但是，此時主動關(guān)閉方還可以接受數(shù)據(jù)；
2）第二次揮手：被動關(guān)閉方收到 FIN 包后，發(fā)送一個 ACK 給對方，確認序號為收到序號+1（與SYN 相同，一個 FIN 占用一個序號）；
3）第三次揮手：被動關(guān)閉方發(fā)送一個 FIN，用來關(guān)閉被動關(guān)閉方到主動關(guān)閉方的數(shù)據(jù)傳送，也就是告訴主動關(guān)閉方，我的數(shù)據(jù)也發(fā)送完了，不會再給你發(fā)數(shù)據(jù)了；
4）第四次揮手：主動關(guān)閉方收到 FIN 后，發(fā)送一個 ACK 給被動關(guān)閉方，確認序號為收到序號+1，至此，完成四次揮手。

12、GET和POST的區(qū)別

get 是獲取數(shù)據(jù)，post 是修改數(shù)據(jù)：

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

Cookies 和 session 區(qū)別：

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

1）存儲的位置不同：
cookie：存放在客戶端，session：存放在服務(wù)端。Session 存儲的數(shù)據(jù)比較安全
2）存儲的數(shù)據(jù)類型不同：
兩者都是 key-value 的結(jié)構(gòu)，但針對 value 的類型是有差異的cookie：value 只能是字符串類型，session：value 是 Object 類型
3）存儲的數(shù)據(jù)大小限制不同：
cookie：大小受瀏覽器的限制，很多是 4K 的大小， session：理論上受當前內(nèi)存的限制，
4）生命周期的控制.

cookie 的生命周期當瀏覽器關(guān)閉的時候，就消亡了：

1）cookie 的生命周期是累計的，從創(chuàng)建時，就開始計時，20 分鐘后，cookie 生命周期結(jié)束；
2）session 的生命周期是間隔的，從創(chuàng)建時，開始計時如在 20 分鐘，沒有訪問 session，那么 session 生命周期被銷毀。

13、Session的工作原理

session 的工作原理是客戶端登錄完成之后，服務(wù)器會創(chuàng)建對應(yīng)的 session，session 創(chuàng)建完之后，會把 session 的 id 發(fā)送給客戶端，客戶端再存儲到瀏覽器中。

這樣客戶端每次訪問服務(wù)器時，都會帶著 sessionid，服務(wù)器拿到 sessionid 之后，在內(nèi)存找到與之對應(yīng)的 session這樣就可以正常工作了。

14、一次完整的HTTP 請求過程

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

15、HTTPS和HTTP的區(qū)別

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

16、OSI的七層模型

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

17、OSI的七層模型

在 HTTP/1.0 中默認使用短連接。也就是說，客戶端和服務(wù)器每進行一次 HTTP 操作，就建立一次連接，任務(wù)結(jié)束就中斷連接。而從 HTTP/1.1 起，默認使用長連接，用以保持連接特性。什么是 TCP粘包/拆包？發(fā)生原因？解決方案一個完整的業(yè)務(wù)可能會被 TCP 拆分成多個包進行發(fā)送，也有可能把多個小的包封裝成一個大的數(shù)據(jù)包發(fā)送，這個就是 TCP 的拆包和粘包問題。

原因：

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

解決方案：

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

18、TCP如何保證可靠傳輸

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

19、常見的狀態(tài)碼

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

20、什么是SSL

SSL 代表安全套接字層。它是一種用于加密和驗證應(yīng)用程序（如瀏覽器）和 Web 服務(wù)器之間發(fā)送的數(shù)據(jù)的協(xié)議。身份驗證，加密 Https 的加密機制是一種共享密鑰加密和公開密鑰加密并用的混合加密機制。

1）SSL/TLS 協(xié)議作用：

認證用戶和服務(wù)，加密數(shù)據(jù)，維護數(shù)據(jù)的完整性的應(yīng)用層協(xié)議加密和解密需要兩個不同的密鑰，故被稱為非對稱加密；

加密和解密都使用同一個密鑰的對稱加密。優(yōu)點在于加密、解密效率通常比較高 HTTPS 是基于非對稱加密的，公鑰是公開的

客戶端向服務(wù)器端發(fā)起 SSL 連接請求；

服務(wù)器把公鑰發(fā)送給客戶端，并且服務(wù)器端保存著唯一的私鑰

客戶端用公鑰對雙方通信的對稱秘鑰進行加密，并發(fā)送給服務(wù)器端

服務(wù)器利用自己唯一的私鑰對客戶端發(fā)來的對稱秘鑰進行解密，

進行數(shù)據(jù)傳輸，服務(wù)器和客戶端雙方用公有的相同的對稱秘鑰對數(shù)據(jù)進行加密解密，

可以保證在數(shù)據(jù)收發(fā)過程中的安全，即是第三方獲得數(shù)據(jù)包，也無法對其進行加密，解密和篡改。

* 相關(guān)文章：一分鐘理解 HTTPS 到底解決了什么問題。

2）數(shù)字簽名：

因為數(shù)字簽名、摘要是證書防偽非常關(guān)鍵的武器。“摘要”就是對傳輸?shù)膬?nèi)容，通過 hash算法計算出一段固定長度的串。然后，在通過 CA 的私鑰對這段摘要進行加密，加密后得到的結(jié)果就是“數(shù)字簽名”

SSL/TLS 協(xié)議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密。

3）如何保證公鑰不被篡改？

將公鑰放在數(shù)字證書中。只要證書是可信的，公鑰就是可信的。

4）公鑰加密計算量太大，如何減少耗用的時間？

每一次對話（session），客戶端和服務(wù)器端都生成一個"對話密鑰"（session key），用它來加密信息。由于"對話密鑰"是對稱加密，所以運算速度非?？欤?wù)器公鑰只用于加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。

1 ）客戶端向服務(wù)器端索要并驗證公鑰；
2）雙方協(xié)商生成"對話密鑰"；
3）雙方采用"對話密鑰"進行加密通信。上面過程的前兩步，又稱為"握手階段"（handshake）。

5）SSL 工作過程：

A：客戶端，B：服務(wù)器端

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