當前位置：首頁 > 编程语言 > java >内容正文

java

Java 面试知识点解析(五)——网络协议篇

發布時間：2025/3/21 java 12 豆豆

生活随笔收集整理的這篇文章主要介紹了 Java 面试知识点解析(五)——网络协议篇小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

前言：

在遨游了一番 Java Web 的世界之后，發現了自己的一些缺失，所以就著一篇深度好文：知名互聯網公司校招 Java 開發崗面試知識點解析?，來好好的對 Java 知識點進行復習和學習一番，大部分內容參照自這一篇文章，有一些自己補充的，也算是重新學習一下 Java 吧。

前序文章鏈接：

Java 面試知識點解析(一)——基礎知識篇

Java 面試知識點解析(二)——高并發編程篇

Java 面試知識點解析(三)——JVM篇

Java 面試知識點解析(四)——版本特性篇

前排引用說明及好文推薦：面試/筆試第一彈 —— 計算機網絡面試問題集錦——書呆子Rico

（一）網絡基礎知識

1）Http和Https的區別？

答：Http協議運行在TCP之上，明文傳輸，客戶端與服務器端都無法驗證對方的身份；Https是身披SSL(Secure Socket Layer)外殼的Http，運行于SSL上，SSL運行于TCP之上，是添加了加密和認證機制的HTTP。二者之間存在如下不同：

端口不同：Http與Http使用不同的連接方式，用的端口也不一樣，前者是80，后者是443；
資源消耗：和HTTP通信相比，Https通信會由于加減密處理消耗更多的CPU和內存資源；
開銷：Https通信需要證書，而證書一般需要向認證機構購買；

Https的加密機制是一種共享密鑰加密和公開密鑰加密并用的混合加密機制。

2）對稱加密與非對稱加密

答：

對稱密鑰加密是指加密和解密使用同一個密鑰的方式，這種方式存在的最大問題就是密鑰發送問題，即如何安全地將密鑰發給對方；而非對稱加密是指使用一對非對稱密鑰，即公鑰和私鑰，公鑰可以隨意發布，但私鑰只有自己知道。發送密文的一方使用對方的公鑰進行加密處理，對方接收到加密信息后，使用自己的私鑰進行解密。

由于非對稱加密的方式不需要發送用來解密的私鑰，所以可以保證安全性；但是和對稱加密比起來，它非常的慢，所以我們還是要用對稱加密來傳送消息，但對稱加密所使用的密鑰我們可以通過非對稱加密的方式發送出去。

3）三次握手與四次揮手

答：

(1). 三次握手（我要和你建立鏈接，你真的要和我建立鏈接么，我真的要和你建立鏈接，成功）

第一次握手：Client將標志位SYN置為1，隨機產生一個值seq=J，并將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。
第二次握手：Server收到數據包后由標志位SYN=1知道Client請求建立連接，Server將標志位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，并將該數據包發送給Client以確認連接請求，Server進入SYN_RCVD狀態。
第三次握手：Client收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=K+1，并將該數據包發送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨后Client與Server之間可以開始傳輸數據了。

(2). 四次揮手（我要和你斷開鏈接；好的，斷吧。我也要和你斷開鏈接；好的，斷吧）：

第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。
第二次揮手：Server收到FIN后，發送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號），Server進入CLOSE_WAIT狀態。此時TCP鏈接處于半關閉狀態，即客戶端已經沒有要發送的數據了，但服務端若發送數據，則客戶端仍要接收。
第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。
第四次揮手：Client收到FIN后，Client進入TIME_WAIT狀態，接著發送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。

(3). 通俗一點的理解就是：

4）為什么 TCP 鏈接需要三次握手，兩次不可以么？

答：“三次握手” 的目的是為了防止已失效的鏈接請求報文突然又傳送到了服務端，因而產生錯誤。

正常的情況：A 發出連接請求，但因連接請求報文丟失而未收到確認，于是 A 再重傳一次連接請求。后來收到了確認，建立了連接。數據傳輸完畢后，就釋放了連接。A 共發送了兩個連接請求報文段，其中第一個丟失，第二個到達了 B。沒有 “已失效的連接請求報文段”。
現假定出現了一種異常情況：即 A 發出的第一個連接請求報文段并沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達 B。本來這是一個早已失效的報文段。但 B 收到此失效的連接請求報文段后，就誤認為是 A 再次發出的一個新的連接請求。于是就向 A 發出確認報文段，同意建立連接。

假設不采用“三次握手”，那么只要 B 發出確認，新的連接就建立了。由于現在 A 并沒有發出建立連接的請求，因此不會理睬 B 的確認，也不會向 B 發送數據。但 B 卻以為新的運輸連接已經建立，并一直等待 A 發來數據。這樣，B 的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現象發生。

5）為什么要四次揮手？

答：TCP 協議是一種面向連接的、可靠的、基于字節流的運輸層通信協議。TCP 是全雙工模式，這就意味著，當 A 向 B 發出 FIN 報文段時，只是表示 A 已經沒有數據要發送了，而此時 A 還是能夠接受到來自 B 發出的數據；B 向 A 發出 ACK 報文段也只是告訴 A ，它自己知道 A 沒有數據要發了，但 B 還是能夠向 A 發送數據。

所以想要愉快的結束這次對話就需要四次揮手。

6）TCP 協議如何來保證傳輸的可靠性

答：TCP 提供一種面向連接的、可靠的字節流服務。其中，面向連接意味著兩個使用 TCP 的應用（通常是一個客戶和一個服務器）在彼此交換數據之前必須先建立一個 TCP 連接。在一個 TCP 連接中，僅有兩方進行彼此通信；而字節流服務意味著兩個應用程序通過 TCP 鏈接交換 8 bit 字節構成的字節流，TCP 不在字節流中插入記錄標識符。

對于可靠性，TCP通過以下方式進行保證：

數據包校驗：目的是檢測數據在傳輸過程中的任何變化，若校驗出包有錯，則丟棄報文段并且不給出響應，這時TCP發送數據端超時后會重發數據；
對失序數據包重排序：既然TCP報文段作為IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段的到達也可能會失序。TCP將對失序數據進行重新排序，然后才交給應用層；
丟棄重復數據：對于重復數據，能夠丟棄重復數據；
應答機制：當TCP收到發自TCP連接另一端的數據，它將發送一個確認。這個確認不是立即發送，通常將推遲幾分之一秒；
超時重發：當TCP發出一個段后，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段；
流量控制：TCP連接的每一方都有固定大小的緩沖空間。TCP的接收端只允許另一端發送接收端緩沖區所能接納的數據，這可以防止較快主機致使較慢主機的緩沖區溢出，這就是流量控制。TCP使用的流量控制協議是可變大小的滑動窗口協議。

7）客戶端不斷進行請求鏈接會怎樣？DDos(Distributed Denial of Service)攻擊？

答：服務器端會為每個請求創建一個鏈接，并向其發送確認報文，然后等待客戶端進行確認

(1). DDos 攻擊：

客戶端向服務端發送請求鏈接數據包
服務端向客戶端發送確認數據包
客戶端不向服務端發送確認數據包，服務器一直等待來自客戶端的確認

(2). DDos 預防：（沒有徹底根治的辦法，除非不使用TCP）

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

8）GET 與 POST 的區別？

答：GET與POST是我們常用的兩種HTTP Method，二者之間的區別主要包括如下五個方面：

(1). 從功能上講，GET一般用來從服務器上獲取資源，POST一般用來更新服務器上的資源；

(2). 從REST服務角度上說，GET是冪等的，即讀取同一個資源，總是得到相同的數據，而POST不是冪等的，因為每次請求對資源的改變并不是相同的；進一步地，GET不會改變服務器上的資源，而POST會對服務器資源進行改變；

(3). 從請求參數形式上看，GET請求的數據會附在URL之后，即將請求數據放置在HTTP報文的請求頭中，以?分割URL和傳輸數據，參數之間以&相連。特別地，如果數據是英文字母/數字，原樣發送；否則，會將其編碼為 application/x-www-form-urlencoded MIME 字符串(如果是空格，轉換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進制表示的ASCII)；而POST請求會把提交的數據則放置在是HTTP請求報文的請求體中。

(4). 就安全性而言，POST的安全性要比GET的安全性高，因為GET請求提交的數據將明文出現在URL上，而且POST請求參數則被包裝到請求體中，相對更安全。

(5). 從請求的大小看，GET請求的長度受限于瀏覽器或服務器對URL長度的限制，允許發送的數據量比較小，而POST請求則是沒有大小限制的。

為什么在GET請求中會對URL進行編碼？

我們知道，在GET請求中會對URL中非西文字符進行編碼，這樣做的目的就是為了?避免歧義。看下面的例子，

針對 “name1=value1&name2=value2” 的例子，我們來談一下數據從客戶端到服務端的解析過程。首先，上述字符串在計算機中用ASCII嗎表示為：

6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C7565326E616D6531：name1 3D：= 76616C756531：value1 26：&6E616D6532：name2 3D：= 76616C756532：value2

服務端在接收到該數據后就可以遍歷該字節流，一個字節一個字節的吃，當吃到3D這字節后，服務端就知道前面吃得字節表示一個key，再往后吃，如果遇到26，說明從剛才吃的3D到26子節之間的是上一個key的value，以此類推就可以解析出客戶端傳過來的參數。

現在考慮這樣一個問題，如果我們的參數值中就包含=或&這種特殊字符的時候該怎么辦？比如，“name1=value1”，其中value1的值是“va&lu=e1”字符串，那么實際在傳輸過程中就會變成這樣“name1=va&lu=e1”。這樣，我們的本意是只有一個鍵值對，但是服務端卻會解析成兩個鍵值對，這樣就產生了歧義。

那么，如何解決上述問題帶來的歧義呢？解決的辦法就是對參數進行URL編碼：例如，我們對上述會產生歧義的字符進行URL編碼后結果：“name1=va%26lu%3D”，這樣服務端會把緊跟在“%”后的字節當成普通的字節，就是不會把它當成各個參數或鍵值對的分隔符。

9）TCP與UDP的區別

答：TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)協議屬于傳輸層協議，它們之間的區別包括：

TCP是面向連接的，UDP是無連接的；
TCP是可靠的，UDP是不可靠的；
TCP只支持點對點通信，UDP支持一對一、一對多、多對一、多對多的通信模式；
TCP是面向字節流的，UDP是面向報文的；
TCP有擁塞控制機制;UDP沒有擁塞控制，適合媒體通信；
TCP首部開銷(20個字節)比UDP的首部開銷(8個字節)要大；

10）TCP和UDP分別對應的常見應用層協議

答：

(1). TCP 對應的應用層協議：

FTP：定義了文件傳輸協議，使用21端口。常說某某計算機開了FTP服務便是啟動了文件傳輸服務。下載文件，上傳主頁，都要用到FTP服務。
Telnet：它是一種用于遠程登陸的端口，用戶可以以自己的身份遠程連接到計算機上，通過這種端口可以提供一種基于DOS模式下的通信服務。如以前的BBS是-純字符界面的，支持BBS的服務器將23端口打開，對外提供服務。
SMTP：定義了簡單郵件傳送協議，現在很多郵件服務器都用的是這個協議，用于發送郵件。如常見的免費郵件服務中用的就是這個郵件服務端口，所以在電子郵件設置-中常看到有這么SMTP端口設置這個欄，服務器開放的是25號端口。
POP3：它是和SMTP對應，POP3用于接收郵件。通常情況下，POP3協議所用的是110端口。也是說，只要你有相應的使用POP3協議的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陸進郵箱界面，直接用郵件程序就可以收到郵件（如是163郵箱就沒有必要先進入網易網站，再進入自己的郵-箱來收信）。
HTTP：從Web服務器傳輸超文本到本地瀏覽器的傳送協議。

(2). UDP 對應的應用層協議：

DNS：用于域名解析服務，將域名地址轉換為IP地址。DNS用的是53號端口。
SNMP：簡單網絡管理協議，使用161號端口，是用來管理網絡設備的。由于網絡設備很多，無連接的服務就體現出其優勢。
TFTP(Trival File Transfer Protocal)：簡單文件傳輸協議，該協議在熟知端口69上使用UDP服務

(3). 圖示：

11）TCP 的擁塞避免機制

答：

擁塞：對資源的需求超過了可用的資源。若網絡中許多資源同時供應不足，網絡的性能就要明顯變壞，整個網絡的吞吐量隨之負荷的增大而下降。

擁塞控制：防止過多的數據注入到網絡中，使得網絡中的路由器或鏈路不致過載。

擁塞控制的方法：

(1). 慢啟動 + 擁塞避免：

慢啟動：不要一開始就發送大量的數據，先探測一下網絡的擁塞程度，也就是說由小到大逐漸增加擁塞窗口的大小;

擁塞避免：擁塞避免算法讓擁塞窗口緩慢增長，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍，這樣擁塞窗口按線性規律緩慢增長。

(2). 快重傳 + 快恢復：

快重傳：快重傳要求接收方在收到一個?失序的報文段?后就立即發出?重復確認（為的是使發送方及早知道有報文段沒有到達對方）而不要等到自己發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重復確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計時器時間到期。

快恢復：快重傳配合使用的還有快恢復算法，當發送方連續收到三個重復確認時，就執行“乘法減小”算法，把ssthresh門限減半，但是接下去并不執行慢開始算法：因為如果網絡出現擁塞的話就不會收到好幾個重復的確認，所以發送方現在認為網絡可能沒有出現擁塞。所以此時不執行慢開始算法，而是將cwnd設置為ssthresh的大小，然后執行擁塞避免算法。

12）瀏覽器中輸入：“www.xxx.com” 之后都發生了什么？請詳細闡述。

解析：經典的網絡協議問題。

答：

由域名→IP地址尋找IP地址的過程依次經過了瀏覽器緩存、系統緩存、hosts文件、路由器緩存、遞歸搜索根域名服務器。

建立TCP/IP連接（三次握手具體過程）

由瀏覽器發送一個HTTP請求

經過路由器的轉發，通過服務器的防火墻，該HTTP請求到達了服務器

服務器處理該HTTP請求，返回一個HTML文件

瀏覽器解析該HTML文件，并且顯示在瀏覽器端

這里需要注意：

HTTP協議是一種基于TCP/IP的應用層協議，進行HTTP數據請求必須先建立TCP/IP連接
可以這樣理解：HTTP是轎車，提供了封裝或者顯示數據的具體形式；Socket是發動機，提供了網絡通信的能力。
兩個計算機之間的交流無非是兩個端口之間的數據通信,具體的數據會以什么樣的形式展現是以不同的應用層協議來定義的。

13）什么是 HTTP 協議無狀態協議？怎么解決Http協議無狀態協議?

答：HTTP 是一個無狀態的協議，也就是沒有記憶力，這意味著每一次的請求都是獨立的，缺少狀態意味著如果后續處理需要前面的信息，則它必須要重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就很快。

HTTP 的這種特性有優點也有缺點：

優點：解放了服務器，每一次的請求“點到為止”，不會造成不必要的連接占用
缺點：每次請求會傳輸大量重復的內容信息，并且，在請求之間無法實現數據的共享

解決方案：

使用參數傳遞機制：
將參數拼接在請求的 URL 后面，實現數據的傳遞（GET方式），例如：/param/list?username=wmyskxz
問題：可以解決數據共享的問題，但是這種方式一不安全，二數據允許傳輸量只有1kb

使用 Cookie 技術

使用 Session 技術

14）Session、Cookie 與 Application

答：Cookie和Session都是客戶端與服務器之間保持狀態的解決方案，具體來說，cookie機制采用的是在客戶端保持狀態的方案，而session機制采用的是在服務器端保持狀態的方案。

(1). Cookie 及其相關 API ：

Cookie實際上是一小段的文本信息。客戶端請求服務器，如果服務器需要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie，而客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器，服務器檢查該Cookie，以此來辨認用戶狀態。服務器還可以根據需要修改Cookie的內容。

(2). Session 及其相關 API：

同樣地，會話狀態也可以保存在服務器端?？蛻舳苏埱蠓掌?#xff0c;如果服務器記錄該用戶狀態，就獲取Session來保存狀態，這時，如果服務器已經為此客戶端創建過session，服務器就按照sessionid把這個session檢索出來使用；如果客戶端請求不包含sessionid，則為此客戶端創建一個session并且生成一個與此session相關聯的sessionid，并將這個sessionid在本次響應中返回給客戶端保存。保存這個sessionid的方式可以采用?cookie機制?，這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發揮給服務器；若瀏覽器禁用Cookie的話，可以通過?URL重寫機制?將sessionid傳回服務器。

(3). Session 與 Cookie 的對比：

實現機制：Session的實現常常依賴于Cookie機制，通過Cookie機制回傳SessionID；
大小限制：Cookie有大小限制并且瀏覽器對每個站點也有cookie的個數限制，Session沒有大小限制，理論上只與服務器的內存大小有關；
安全性：Cookie存在安全隱患，通過攔截或本地文件找得到cookie后可以進行攻擊，而Session由于保存在服務器端，相對更加安全；
服務器資源消耗：Session是保存在服務器端上會存在一段時間才會消失，如果session過多會增加服務器的壓力。

(4). Application：

Application（ServletContext）：與一個Web應用程序相對應，為應用程序提供了一個全局的狀態，所有客戶都可以使用該狀態。

15）滑動窗口機制

答：由發送方和接收方在三次握手階段，互相將自己的最大可接收的數據量告訴對方。也就是自己的數據接收緩沖池的大小。這樣對方可以根據已發送的數據量來計算是否可以接著發送。在處理過程中，當接收緩沖池的大小發生變化時，要給對方發送更新窗口大小的通知。這就實現了流量的控制。

16）常用的HTTP方法有哪些？

答：

GET：用于請求訪問已經被URI（統一資源標識符）識別的資源，可以通過URL傳參給服務器
POST：用于傳輸信息給服務器，主要功能與GET方法類似，但一般推薦使用POST方式。
PUT：傳輸文件，報文主體中包含文件內容，保存到對應URI位置。
HEAD：獲得報文首部，與GET方法類似，只是不返回報文主體，一般用于驗證URI是否有效。
DELETE：刪除文件，與PUT方法相反，刪除對應URI位置的文件。
OPTIONS：查詢相應URI支持的HTTP方法。

17）常見HTTP狀態碼

答：

1xx（臨時響應）

2xx（成功）

3xx（重定向）：表示要完成請求需要進一步操作

4xx（錯誤）：表示請求可能出錯，妨礙了服務器的處理

5xx（服務器錯誤）：表示服務器在嘗試處理請求時發生內部錯誤

常見狀態碼：

200（成功）
304（未修改）：自從上次請求后，請求的網頁未修改過。服務器返回此響應時，不會返回網頁內容
401（未授權）：請求要求身份驗證
403（禁止）：服務器拒絕請求
404（未找到）：服務器找不到請求的網頁

18）SQL 注入

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

(1).SQL注入攻擊的總體思路：

尋找到SQL注入的位置

判斷服務器類型和后臺數據庫類型

針對不通的服務器和數據庫特點進行SQL注入攻擊

(2). SQL注入攻擊實例：

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

用戶名： ‘or 1 = 1 -- 密碼：

用戶一旦點擊登錄，如若沒有做特殊處理，那么這個非法用戶就很得意的登陸進去了。這是為什么呢?下面我們分析一下：從理論上說，后臺認證程序中會有如下的SQL語句：

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

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

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

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

(3). 應對方法：

1.參數綁定：

使用預編譯手段，綁定參數是最好的防SQL注入的方法。目前許多的ORM框架及JDBC等都實現了SQL預編譯和參數綁定功能，攻擊者的惡意SQL會被當做SQL的參數而不是SQL命令被執行。在mybatis的mapper文件中，對于傳遞的參數我們一般是使用#和$來獲取參數值。當使用#時，變量是占位符，就是一般我們使用javajdbc的PrepareStatement時的占位符，所有可以防止sql注入；當使用$時，變量就是直接追加在sql中，一般會有sql注入問題。

2.使用正則表達式過濾傳入的參數

19）XSS 攻擊

答：XSS是一種經常出現在web應用中的計算機安全漏洞，與SQL注入一起成為web中最主流的攻擊方式。XSS是指惡意攻擊者利用網站沒有對用戶提交數據進行轉義處理或者過濾不足的缺點，進而添加一些腳本代碼嵌入到web頁面中去，使別的用戶訪問都會執行相應的嵌入代碼，從而盜取用戶資料、利用用戶身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。

(1). XSS攻擊的危害：

盜取各類用戶帳號，如機器登錄帳號、用戶網銀帳號、各類管理員帳號
控制企業數據，包括讀取、篡改、添加、刪除企業敏感數據的能力
盜竊企業重要的具有商業價值的資料
非法轉賬
強制發送電子郵件
網站掛馬
控制受害者機器向其它網站發起攻擊

(2). 原因解析：

主要原因：過于信任客戶端提交的數據！
解決辦法：不信任任何客戶端提交的數據，只要是客戶端提交的數據就應該先進行相應的過濾處理然后方可進行下一步的操作。
進一步分析細節：客戶端提交的數據本來就是應用所需要的，但是惡意攻擊者利用網站對客戶端提交數據的信任，在數據中插入一些符號以及javascript代碼，那么這些數據將會成為應用代碼中的一部分了，那么攻擊者就可以肆無忌憚地展開攻擊啦，因此我們絕不可以信任任何客戶端提交的數據！！！

(3). XSS 攻擊分類：

反射性 XSS 攻擊（非持久性 XSS 攻擊）：

漏洞產生的原因是攻擊者注入的數據反映在響應中。一個典型的非持久性XSS攻擊包含一個帶XSS攻擊向量的鏈接(即每次攻擊需要用戶的點擊)，例如，正常發送消息：

http://www.test.com/message.php?send=Hello,World！

接收者將會接收信息并顯示Hello,World；但是，非正常發送消息：

http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>！

接收者接收消息顯示的時候將會彈出警告窗口！

持久性XSS攻擊 (留言板場景)：

XSS攻擊向量(一般指XSS攻擊代碼)存儲在網站數據庫，當一個頁面被用戶打開的時候執行。也就是說，每當用戶使用瀏覽器打開指定頁面時，腳本便執行。與非持久性XSS攻擊相比，持久性XSS攻擊危害性更大。從名字就可以了解到，持久性XSS攻擊就是將攻擊代碼存入數據庫中，然后客戶端打開時就執行這些攻擊代碼。

例如，留言板表單中的表單域：

正常操作流程是：用戶是提交相應留言信息 —— 將數據存儲到數據庫 —— 其他用戶訪問留言板，應用去數據并顯示；而非正常操作流程是攻擊者在value填寫:

并將數據提交、存儲到數據庫中；當其他用戶取出數據顯示的時候，將會執行這些攻擊性代碼。

(4). 修復漏洞方針：

漏洞產生的根本原因是?太相信用戶提交的數據，對用戶所提交的數據過濾不足所導致的，因此解決方案也應該從這個方面入手，具體方案包括：

將重要的cookie標記為http only, 這樣的話Javascript 中的document.cookie語句就不能獲取到cookie了（如果在cookie中設置了HttpOnly屬性，那么通過js腳本將無法讀取到cookie信息，這樣能有效的防止XSS攻擊）；
表單數據規定值的類型，例如：年齡應為只能為int、name只能為字母數字組合。。。。
對數據進行Html Encode 處理
過濾或移除特殊的Html標簽，例如:

from:?https://www.cnblogs.com/wmyskxz/p/9056776.html

總結

以上是生活随笔為你收集整理的Java 面试知识点解析(五)——网络协议篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： Java集合框架之fastutil
下一篇： Java 面试知识点解析(六)——数据库