即時通訊初學者必知必會的20個網絡編程和通信安全知識點

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

本文引用自公眾號“計算科學與信息化”，原題“運維必知的20個網絡安全知識點!”，下文進行了排版和內容優化。

1、引言

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

技術交流：

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

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

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

2、什么是SQL注入攻擊

攻擊者在 HTTP 請求中注入惡意的 SQL 代碼，服務器使用參數構建數據庫 SQL 命令時，惡意SQL 被一起構造，并在數據庫中執行。

注入方法：

用戶登錄，輸入用戶名 lianggzone，密碼 ‘ or ‘1’=’1 ，如果此時使用參數構造的方式，就會出現：

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

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

Web端預防：

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

服務端預防：

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

3、什么是XSS攻擊

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

如何防范XSS攻擊？

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

預防XSS 的核心是必須對輸入的數據做過濾處理。

4、什么是CSRF攻擊

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

如何防范CSRF攻擊？

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

5、文件上傳漏洞

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

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

如何防范文件上傳攻擊？

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

6、什么是DDoS攻擊

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

DDos 預防：

1）限制同時打開 SYN 半鏈接的數目；
2）縮短 SYN 半鏈接的 Time out 時間；
3）關閉不必要的服務。

7、什么是ARP協議

1）概述：

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

發送 ARP 請求的以太網數據幀廣播到以太網上的每個主機，ARP 請求幀中包含了目的主機的 IP 地址。目的主機收到了該 ARP 請求之后，會發送一個 ARP 應答，里面包含了目的主機的 MAC 地址。

2）ARP 協議工作原理：

每個主機都會在自己的 ARP 緩沖區中建立一個 ARP 列表，以表示 IP 地址和 MAC 地址之間的對應關系。

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

網絡上的主機接收到免費 ARP 報文時，會更新自己的 ARP 緩沖區。將新的映射關系更新到自己的 ARP 表中。

某個主機需要發送報文時，首先檢查 ARP 列表中是否有對應 IP 地址的目的主機的 MAC地址，如果有，則直接發送數據，如果沒有，就向本網段的所有主機發送 ARP 數據包，該數據包包括的內容有：源主機 IP 地址，源主機 MAC 地址，目的主機的 IP 地址等。

3）當本網絡的所有主機收到該 ARP 數據包時：

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

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

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

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

4）如何防范ARP攻擊：

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

8、RARP工作原理

反向地址轉換協議，網絡層協議，RARP 與 ARP 工作方式相反。RARP 使只知道自己硬件地址的主機能夠知道其 IP 地址。RARP 發出要反向解釋的物理地址并希望返回其 IP地址，應答包括能夠提供所需信息的 RARP 服務器發出的 IP 地址。

原理：

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

9、DNS工作原理

將主機域名轉換為 ip 地址，屬于應用層協議，使用 UDP 傳輸。

過程總結：瀏覽器緩存，系統緩存，路由器緩存，IPS 服務器緩存，根域名服務器緩存，頂級域名服務器緩存，主域名服務器緩存。

兩種查詢方式：

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

具體是：

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

DNS攻擊：

DNS攻擊防范：

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

10、RIP的工作原理

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

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

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

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

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

RIP的特點：

1）由于15跳為最大值，RIP 只能應用于小規模網絡；
2）收斂速度慢；
3）根據跳數選擇的路由，不一定是最優路由。

OSPF 協議的工作原理：OSPF（Open Shortest Pass First,開放最短路徑優先協議），是一個最常用的內部網管協議，是一個鏈路狀態協議(網絡層協議)。

原理：OSPF 組播的方式在所有開啟 OSPF 的接口發送 Hello 包，用來確定是否有 OSPF 鄰居，若發現了，則建立 OSPF 鄰居關系，形成鄰居表，之后互相發送 LSA（鏈路狀態通告）相互通告路由，形成 LSDB（鏈路狀態數據庫）。再通過 SPF 算法，計算最佳路徑（cost 最小）后放入路由表

11、TCP與UDP區別

直接說結論：

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

* 相關文章：一泡尿的時間，快速搞懂TCP和UDP的區別。

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

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

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

完成三次握手，客戶端與服務器開始傳送數據：

四次揮手：

客戶端先發送 FIN，進入 FIN_WAIT1 狀態，用來關閉 Client 到 Server 的數據傳送服務端收到 FIN，發送 ACK，進入 CLOSE_WAIT 狀態，客戶端收到這個 ACK，進入 FIN_WAIT2狀態。

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

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

12、GET和POST的區別

get 是獲取數據，post 是修改數據：

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

Cookies 和 session 區別：

Cookie 和 Session 都是客戶端與服務器之間保持狀態的解決方案：

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

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

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

13、Session的工作原理

session 的工作原理是客戶端登錄完成之后，服務器會創建對應的 session，session 創建完之后，會把 session 的 id 發送給客戶端，客戶端再存儲到瀏覽器中。

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

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

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

15、HTTPS和HTTP的區別

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

16、OSI的七層模型

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

17、OSI的七層模型

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

原因：

1）應用程序寫入數據的字節大小大于套接字發送緩沖區的大小；
2）進行MSS 大小的 TCP分段。( MSS=TCP 報文段長度-TCP 首部長度)3. 以太網的 payload 大于 MTU進行 IP 分片。（ MTU 指：一種通信協議的某一層上面所能通過的最大數據包大小。）

解決方案：

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

18、TCP如何保證可靠傳輸

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

19、常見的狀態碼

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