網絡協議常見面試題

時間 2019-11-17

原文原文鏈接

一）網絡基礎知識

1）Http和Https的區別？

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

端口不一樣：Http與Http使用不一樣的鏈接方式，用的端口也不同，前者是80，後者是443；php
資源消耗：和HTTP通訊相比，Https通訊會因爲加減密處理消耗更多的CPU和內存資源；html
開銷：Https通訊須要證書，而證書通常須要向認證機構購買；java

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

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

答：正則表達式

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

因爲非對稱加密的方式不須要發送用來解密的私鑰，因此能夠保證安全性；可是和對稱加密比起來，它很是的慢，因此咱們仍是要用對稱加密來傳送消息，但對稱加密所使用的密鑰咱們能夠經過非對稱加密的方式發送出去。sql

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狀態，完成四次揮手。

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 76616C756532   6E616D6531：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支持一對1、一對多、多對1、多對多的通訊模式；
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服務

11）TCP 的擁塞避免機制

答：

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

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

擁塞控制的方法：

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

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

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

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

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

快恢復：快重傳配合使用的還有快恢復算法，當發送方連續收到三個重複確認時，就執行「乘法減少」算法，把ssthresh門限減半，可是接下去並不執行慢開始算法：由於若是網絡出現擁塞的話就不會收到好幾個重複的確認，因此發送方如今認爲網絡可能沒有出現擁塞。因此此時不執行慢開始算法，而是將cwnd設置爲ssthresh的大小，而後執行擁塞避免算法。

12）瀏覽器中輸入：「`www.liangsonghua.me`」以後都發生了什麼？請詳細闡述。

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

答：

由域名→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：

一樣地，會話狀態也能夠保存在服務器端。客戶端請求服務器，若是服務器記錄該用戶狀態，就獲取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文件中，對於傳遞的參數咱們通常是使用#和

不能識別此Latex公式:來獲取參數值。當使用#時，變量是佔位符，就是通常咱們使用javajdbc的PrepareStatement時的佔位符，全部能夠防止sql注入；當使用複製代碼

時，變量就是直接追加在sql中，通常會有sql注入問題。

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

19）XSS 攻擊

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

(1). XSS攻擊的危害：

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

(2). 緣由解析：

主要緣由：過於信任客戶端提交的數據！
解決辦法：不信任任何客戶端提交的數據，只要是客戶端提交的數據就應該先進行相應的過濾處理而後方可進行下一步的操做。
進一步分析細節：客戶端提交的數據原本就是應用所須要的，可是惡意攻擊者利用網站對客戶端提交數據的信任，在數據中插入一些符號以及javascript代碼，那麼這些數據將會成爲應用代碼中的一部分了，那麼攻擊者就能夠肆無忌憚地展開攻擊啦，所以咱們毫不能夠信任任何客戶端提交的數據！！！

(3). XSS 攻擊分類：

1. 反射性 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>！複製代碼

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

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

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

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

<input type=「text」 name=「content」 value=「這裏是用戶填寫的數據」>複製代碼

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

<script>alert(‘foolish!’)；</script> <!--或者html其餘標籤（破壞樣式）、一段攻擊型代碼-->複製代碼

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

(4). 修復漏洞方針：

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

將重要的cookie標記爲http only, 這樣的話Javascript 中的document.cookie語句就不能獲取到cookie了（若是在cookie中設置了HttpOnly屬性，那麼經過js腳本將沒法讀取到cookie信息，這樣能有效的防止XSS攻擊）；
表單數據規定值的類型，例如：年齡應爲只能爲int、name只能爲字母數字組合。。。。
對數據進行Html Encode 處理
過濾或移除特殊的Html標籤，例如: <script>, <iframe> , < for <, > for>, &quot for
過濾JavaScript 事件的標籤，例如「onclick=」, 「onfocus」等等。

須要注意的是，在有些應用中是容許html標籤出現的，甚至是javascript代碼出現。所以，咱們在過濾數據的時候須要仔細分析哪些數據是有特殊要求（例如輸出須要html代碼、javascript代碼拼接、或者此表單直接容許使用等等），而後區別處理！

20）OSI 網絡體系結構與 TCP/IP 協議模型

答：OSI 是一個理論上的網絡通訊模型，而 TCP/IP 則是實際上的網絡通訊標準。可是，它們的初衷是同樣的，都是爲了使得兩臺計算機可以像兩個知心朋友那樣可以互相準確理解對方的意思並作出優雅的迴應。如今，咱們對 OSI 七層模型的各層進行簡要的介紹：

1). 物理層

參考模型的最低層，也是OSI模型的第一層，實現了相鄰計算機節點之間比特流的透明傳送，並儘量地屏蔽掉具體傳輸介質和物理設備的差別，使其上層(數據鏈路層)沒必要關心網絡的具體傳輸介質。

2). 數據鏈路層（data link layer）

接收來自物理層的位流形式的數據，並封裝成幀，傳送到上一層；一樣，也未來自上層的數據幀，拆裝爲位流形式的數據轉發到物理層。這一層在物理層提供的比特流的基礎上，經過差錯控制、流量控制方法，使有差錯的物理線路變爲無差錯的數據鏈路，即提供可靠的經過物理介質傳輸數據的方法。

3). 網絡層

將網絡地址翻譯成對應的物理地址，並經過路由選擇算法爲分組經過通訊子網選擇最適當的路徑。

4). 傳輸層（transport layer）

在源端與目的端之間提供可靠的透明數據傳輸，使上層服務用戶沒必要關係通訊子網的實現細節。在協議棧中，傳輸層位於網絡層之上，傳輸層協議爲不一樣主機上運行的進程提供邏輯通訊，而網絡層協議爲不一樣主機提供邏輯通訊，以下圖所示。

實際上，網絡層能夠看做是傳輸層的一部分，其爲傳輸層提供服務。但對於終端系統而言，網絡層對它們而言是透明的，它們知道傳輸層的存在，也就是說，在邏輯上它們認爲是傳輸層爲它們提供了端對端的通訊，這也是分層思想的妙處。

5). 會話層（Session Layer）

會話層是OSI模型的第五層，是用戶應用程序和網絡之間的接口，負責在網絡中的兩節點之間創建、維持和終止通訊。

6). 表示層（Presentation Layer）：數據的編碼，壓縮和解壓縮，數據的加密和解密

表示層是OSI模型的第六層，它對來自應用層的命令和數據進行解釋，以確保一個系統的應用層所發送的信息能夠被另外一個系統的應用層讀取。

7). 應用層（Application layer）：爲用戶的應用進程提供網絡通訊服務

21）網絡層的 ARP 協議工做原理？

答：地址解析協議(ARP) 是經過解析網路層地址來找尋數據鏈路層地址的一個在網絡協議包中極其重要的網絡傳輸協議。

網絡層的ARP協議完成了IP地址與物理地址的映射。首先，每臺主機都會在本身的ARP緩衝區中創建一個ARP列表，以表示IP地址和MAC地址的對應關係。當源主機須要將一個數據包要發送到目的主機時，會首先檢查本身ARP列表中是否存在該IP地址對應的MAC地址：若是有，就直接將數據包發送到這個MAC地址；若是沒有，就向本地網段發起一個ARP請求的廣播包，查詢此目的主機對應的MAC地址。此ARP請求數據包裏包括源主機的IP地址、硬件地址、以及目的主機的IP地址。網絡中全部的主機收到這個ARP請求後，會檢查數據包中的目的IP是否和本身的IP地址一致。若是不相同就忽略此數據包；若是相同，該主機首先將發送端的MAC地址和IP地址添加到本身的ARP列表中，若是ARP表中已經存在該IP的信息，則將其覆蓋，而後給源主機發送一個ARP響應數據包，告訴對方本身是它須要查找的MAC地址；源主機收到這個ARP響應數據包後，將獲得的目的主機的IP地址和MAC地址添加到本身的ARP列表中，並利用此信息開始數據的傳輸。若是源主機一直沒有收到ARP響應數據包，表示ARP查詢失敗。

22）IP地址的分類

答：整個的因特網就是一個單一的、抽象的網絡。IP 地址就是給因特網上的每個主機（或路由器）的每個接口分配一個在全世界範圍是惟一的 32 位標識符，它是一個邏輯地址，用以屏蔽掉物理地址的差別。IP地址編址方案將IP地址空間劃分爲A、B、C、D、E五類，其中A、B、C是基本類，D、E類做爲多播和保留使用，爲特殊地址。

每一個IP地址包括兩個標識碼（ID），即網絡ID和主機ID。同一個物理網絡上的全部主機都使用同一個網絡ID，網絡上的一個主機（包括網絡上工做站，服務器和路由器等）有一個主機ID與其對應。A~E類地址的特色以下：

A類地址：以0開頭，第一個字節範圍：0~127；
B類地址：以10開頭，第一個字節範圍：128~191；
C類地址：以110開頭，第一個字節範圍：192~223；
D類地址：以1110開頭，第一個字節範圍爲224~239；
E類地址：以1111開頭，保留地址

1). A類地址：1字節的網絡地址 + 3字節主機地址，網絡地址的最高位必須是「0」

一個A類IP地址是指，在IP地址的四段號碼中，第一段號碼爲網絡號碼，剩下的三段號碼爲本地計算機的號碼。若是用二進制表示IP地址的話，A類IP地址就由1字節的網絡地址和3字節主機地址組成，網絡地址的最高位必須是「0」。A類IP地址中網絡的標識長度爲8位，主機標識的長度爲24位，A類網絡地址數量較少，有126個網絡，每一個網絡能夠容納主機數達1600多萬臺。

A類IP地址的地址範圍1.0.0.0到127.255.255.255（二進制表示爲：00000001 00000000 00000000 00000000 - 01111110 11111111 11111111 11111111），最後一個是廣播地址。A類IP地址的子網掩碼爲255.0.0.0，每一個網絡支持的最大主機數爲256的3次方-2=16777214臺。

2). B類地址: 2字節的網絡地址 + 2字節主機地址，網絡地址的最高位必須是「10」

一個B類IP地址是指，在IP地址的四段號碼中，前兩段號碼爲網絡號碼。若是用二進制表示IP地址的話，B類IP地址就由2字節的網絡地址和2字節主機地址組成，網絡地址的最高位必須是「10」。B類IP地址中網絡的標識長度爲16位，主機標識的長度爲16位，B類網絡地址適用於中等規模的網絡，有16384個網絡，每一個網絡所能容納的計算機數爲6萬多臺。

B類IP地址地址範圍128.0.0.0-191.255.255.255（二進制表示爲：10000000 00000000 00000000 00000000—-10111111 11111111 11111111 11111111），最後一個是廣播地址。B類IP地址的子網掩碼爲255.255.0.0，每一個網絡支持的最大主機數爲256的2次方-2=65534臺。

3). C類地址: 3字節的網絡地址 + 1字節主機地址，網絡地址的最高位必須是「110」

一個C類IP地址是指，在IP地址的四段號碼中，前三段號碼爲網絡號碼，剩下的一段號碼爲本地計算機的號碼。若是用二進制表示IP地址的話，C類IP地址就由3字節的網絡地址和1字節主機地址組成，網絡地址的最高位必須是「110」。C類IP地址中網絡的標識長度爲24位，主機標識的長度爲8位，C類網絡地址數量較多，有209萬餘個網絡。適用於小規模的局域網絡，每一個網絡最多隻能包含254臺計算機。

C類IP地址範圍192.0.0.0-223.255.255.255（二進制表示爲: 11000000 00000000 00000000 00000000 - 11011111 11111111 11111111 11111111）。C類IP地址的子網掩碼爲255.255.255.0，每一個網絡支持的最大主機數爲256-2=254臺。

4). D類地址:多播地址，用於1對多通訊，最高位必須是「1110」

　　D類IP地址在歷史上被叫作多播地址(multicast address)，即組播地址。在以太網中，多播地址命名了一組應該在這個網絡中應用接收到一個分組的站點。多播地址的最高位必須是「1110」，範圍從224.0.0.0到239.255.255.255。

5). E類地址:爲保留地址，最高位必須是「1111」

23）IP地址與物理地址

答：物理地址是數據鏈路層和物理層使用的地址，IP地址是網絡層和以上各層使用的地址，是一種邏輯地址，其中ARP協議用於IP地址與物理地址的對應。

24）影響網絡傳輸的因素有哪些？

答：將一份數據從一個地方正確地傳輸到另外一個地方所須要的時間咱們稱之爲響應時間。影響這個響應時間的因素有不少。

網絡帶寬：所謂帶寬就是一條物理鏈路在 1s 內可以傳輸的最大比特數，注意這裏是比特（bit）而不是字節數，也就是 b/s 。網絡帶寬確定是影響數據傳輸的一個關鍵環節，由於在當前的網絡環境中，平均網絡帶寬只有 1.7 MB/s 左右。
傳輸距離：也就是數據在光纖中要走的距離，雖然光的傳播速度很快，但也是有時間的，因爲數據在光纖中的移動並非走直線的，會有一個折射率，因此大概是光的 2/3，這個時間也就是咱們一般所說的傳輸延時。傳輸延時是一個沒法避免的問題，例如，你要給在杭州和青島的兩個機房的一個數據庫進行同步數據操做，那麼一定會存在約 30ms 的一個延時。
TCP 擁塞控制：咱們知道 TCP 傳輸是一個「停-等-停-等」的協議，傳輸方和接受方的步調要一致，要達到步調一致就要經過擁塞控制來調節。TCP 在傳輸時會設定一個「窗口」，這個窗口的大小是由帶寬和 RTT（Round-Trip Time，數據在兩端的來回時間，也就是響應時間）決定的。計算的公式是帶寬（b/s）xRTT（s）。經過這個值就能夠得出理論上最優的 TCP 緩衝區的大小。Linux 2.4 已經能夠自動地調整發送端的緩衝區的大小，而到 Linux 2.6.7 時接收端也能夠自動調整了。