41道計算機網路高頻面試題（附帶答案）

帥地發表於2021-07-22

計算機網路面試題

史上最全，不接受反駁！！！！！！！文末也給出了 PDF 版本哦

1、說一說三次握手

當面試官問你為什麼需要有三次握手、三次握手的作用、講講三次三次握手的時候，我想很多人會這樣回答：

首先很多人會先講下握手的過程：

1、第一次握手：客戶端給伺服器傳送一個 SYN 報文。

2、第二次握手：伺服器收到 SYN 報文之後，會應答一個 SYN+ACK 報文。

3、第三次握手：客戶端收到 SYN+ACK 報文之後，會回應一個 ACK 報文。

4、伺服器收到 ACK 報文之後，三次握手建立完成。

作用是為了確認雙方的接收與傳送能力是否正常。

這裡我順便解釋一下為啥只有三次握手才能確認雙方的接受與傳送能力是否正常，而兩次卻不可以：
第一次握手：客戶端傳送網路包，服務端收到了。這樣服務端就能得出結論：客戶端的傳送能力、服務端的接收能力是正常的。

第二次握手：服務端發包，客戶端收到了。這樣客戶端就能得出結論：服務端的接收、傳送能力，客戶端的接收、傳送能力是正常的。不過此時伺服器並不能確認客戶端的接收能力是否正常。

第三次握手：客戶端發包，服務端收到了。這樣服務端就能得出結論：客戶端的接收、傳送能力正常，伺服器自己的傳送、接收能力也正常。

因此，需要三次握手才能確認雙方的接收與傳送能力是否正常。

這樣回答其實也是可以的，但我覺得，這個過程的我們應該要描述的更詳細一點，因為三次握手的過程中，雙方是由很多狀態的改變的，而這些狀態，也是面試官可能會問的點。所以我覺得在回答三次握手的時候，我們應該要描述的詳細一點，而且描述的詳細一點意味著可以扯久一點。加分的描述我覺得應該是這樣：

剛開始客戶端處於 closed 的狀態，服務端處於 listen 狀態。然後

1、第一次握手：客戶端給服務端發一個 SYN 報文，並指明客戶端的初始化序列號 ISN(c)。此時客戶端處於 SYN_Send 狀態。

2、第二次握手：伺服器收到客戶端的 SYN 報文之後，會以自己的 SYN 報文作為應答，並且也是指定了自己的初始化序列號 ISN(s)，同時會把客戶端的 ISN + 1 作為 ACK 的值，表示自己已經收到了客戶端的 SYN，此時伺服器處於 SYN_REVD 的狀態。

3、第三次握手：客戶端收到 SYN 報文之後，會傳送一個 ACK 報文，當然，也是一樣把伺服器的 ISN + 1 作為 ACK 的值，表示已經收到了服務端的 SYN 報文，此時客戶端處於 establised 狀態。

4、伺服器收到 ACK 報文之後，也處於 establised 狀態，此時，雙方以建立起了連結

三次握手的作用

三次握手的作用也是有好多的，多記住幾個，保證不虧。例如：

1、確認雙方的接受能力、傳送能力是否正常。

2、指定自己的初始化序列號，為後面的可靠傳送做準備。

1、（ISN）是固定的嗎

三次握手的一個重要功能是客戶端和服務端交換ISN(Initial Sequence Number), 以便讓對方知道接下來接收資料的時候如何按序列號組裝資料。

如果ISN是固定的，攻擊者很容易猜出後續的確認號，因此 ISN 是動態生成的。

2、什麼是半連線佇列

伺服器第一次收到客戶端的 SYN 之後，就會處於 SYN_RCVD 狀態，此時雙方還沒有完全建立其連線，伺服器會把此種狀態下請求連線放在一個佇列裡，我們把這種佇列稱之為半連線佇列。當然還有一個全連線佇列，就是已經完成三次握手，建立起連線的就會放在全連線佇列中。如果佇列滿了就有可能會出現丟包現象。

這裡在補充一點關於SYN-ACK 重傳次數的問題：　伺服器傳送完SYN－ACK包，如果未收到客戶確認包，伺服器進行首次重傳，等待一段時間仍未收到客戶確認包，進行第二次重傳，如果重傳次數超過系統規定的最大重傳次數，系統將該連線資訊從半連線佇列中刪除。注意，每次重傳等待的時間不一定相同，一般會是指數增長，例如間隔時間為 1s, 2s, 4s, 8s,

3、三次握手過程中可以攜帶資料嗎

很多人可能會認為三次握手都不能攜帶資料，其實第三次握手的時候，是可以攜帶資料的。也就是說，第一次、第二次握手不可以攜帶資料，而第三次握手是可以攜帶資料的。

為什麼這樣呢？大家可以想一個問題，假如第一次握手可以攜帶資料的話，如果有人要惡意攻擊伺服器，那他每次都在第一次握手中的 SYN 報文中放入大量的資料，因為攻擊者根本就不理伺服器的接收、傳送能力是否正常，然後瘋狂著重複發 SYN 報文的話，這會讓伺服器花費很多時間、記憶體空間來接收這些報文。也就是說，第一次握手可以放資料的話，其中一個簡單的原因就是會讓伺服器更加容易受到攻擊了。

而對於第三次的話，此時客戶端已經處於 established 狀態，也就是說，對於客戶端來說，他已經建立起連線了，並且也已經知道伺服器的接收、傳送能力是正常的了，所以能攜帶資料頁沒啥毛病。

2、說一說四次揮手

四次揮手也一樣，千萬不要對方一個 FIN 報文，我方一個 ACK 報文，再我方一個 FIN 報文，我方一個 ACK 報文。然後結束，最好是說的詳細一點，例如想下面這樣就差不多了，要把每個階段的狀態記好，我上次面試就被問了幾個了，呵呵。我答錯了，還以為自己答對了，當時還解釋的頭頭是道，呵呵。

剛開始雙方都處於 establised 狀態，假如是客戶端先發起關閉請求，則：

1、第一次揮手：客戶端傳送一個 FIN 報文，報文中會指定一個序列號。此時客戶端處於CLOSED_WAIT1狀態。

2、第二次握手：服務端收到 FIN 之後，會傳送 ACK 報文，且把客戶端的序列號值 + 1 作為 ACK 報文的序列號值，表明已經收到客戶端的報文了，此時服務端處於 CLOSE_WAIT2狀態。

3、第三次揮手：如果服務端也想斷開連線了，和客戶端的第一次揮手一樣，發給 FIN 報文，且指定一個序列號。此時服務端處於 LAST_ACK 的狀態。

4、第四次揮手：客戶端收到 FIN 之後，一樣傳送一個 ACK 報文作為應答，且把服務端的序列號值 + 1 作為自己 ACK 報文的序列號值，此時客戶端處於 TIME_WAIT 狀態。需要過一陣子以確保服務端收到自己的 ACK 報文之後才會進入 CLOSED 狀態

5、服務端收到 ACK 報文之後，就處於關閉連線了，處於 CLOSED 狀態。

這裡特別需要主要的就是TIME_WAIT這個狀態了，這個是面試的高頻考點，就是要理解，為什麼客戶端傳送 ACK 之後不直接關閉，而是要等一陣子才關閉。這其中的原因就是，要確保伺服器是否已經收到了我們的 ACK 報文，如果沒有收到的話，伺服器會重新發 FIN 報文給客戶端，客戶端再次收到 FIN 報文之後，就知道之前的 ACK 報文丟失了，然後再次傳送 ACK 報文。

至於 TIME_WAIT 持續的時間至少是一個報文的來回時間。一般會設定一個計時，如果過了這個計時沒有再次收到 FIN 報文，則代表對方成功就是 ACK 報文，此時處於 CLOSED 狀態。

這裡我給出每個狀態所包含的含義，有興趣的可以看看。

LISTEN - 偵聽來自遠方TCP埠的連線請求；

SYN-SENT -在傳送連線請求後等待匹配的連線請求；

SYN-RECEIVED - 在收到和傳送一個連線請求後等待對連線請求的確認；

ESTABLISHED- 代表一個開啟的連線，資料可以傳送給使用者；

FIN-WAIT-1 - 等待遠端TCP的連線中斷請求，或先前的連線中斷請求的確認；

FIN-WAIT-2 - 從遠端TCP等待連線中斷請求；

CLOSE-WAIT - 等待從本地使用者發來的連線中斷請求；

CLOSING -等待遠端TCP對連線中斷的確認；

LAST-ACK - 等待原來發向遠端TCP的連線中斷請求的確認；

TIME-WAIT -等待足夠的時間以確保遠端TCP接收到連線中斷請求的確認；

CLOSED - 沒有任何連線狀態；

3、說一說POST與GET有哪些區別

使用場景

GET 用於獲取資源，而 POST 用於傳輸實體主體。

引數

GET 和 POST 的請求都能使用額外的引數，但是 GET 的引數是以查詢字串出現在 URL 中，而 POST 的引數儲存在實體主體中。不能因為 POST 引數儲存在實體主體中就認為它的安全性更高，因為照樣可以通過一些抓包工具（Fiddler）檢視。

因為 URL 只支援 ASCII 碼，因此 GET 的引數中如果存在中文等字元就需要先進行編碼。例如 中文 會轉換為 %E4%B8%AD%E6%96%87，而空格會轉換為 %20。POST 引數支援標準字符集。

GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1Copy to clipboardErrorCopied
POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2Copy to clipboardErrorCopied

安全性

安全的 HTTP 方法不會改變伺服器狀態，也就是說它只是可讀的。

GET 方法是安全的，而 POST 卻不是，因為 POST 的目的是傳送實體主體內容，這個內容可能是使用者上傳的表單資料，上傳成功之後，伺服器可能把這個資料儲存到資料庫中，因此狀態也就發生了改變。

安全的方法除了 GET 之外還有：HEAD、OPTIONS。

不安全的方法除了 POST 之外還有 PUT、DELETE。

冪等性

冪等的 HTTP 方法，同樣的請求被執行一次與連續執行多次的效果是一樣的，伺服器的狀態也是一樣的。換句話說就是，冪等方法不應該具有副作用（統計用途除外）。

所有的安全方法也都是冪等的。

在正確實現的條件下，GET，HEAD，PUT 和 DELETE 等方法都是冪等的，而 POST 方法不是。

GET /pageX HTTP/1.1 是冪等的，連續呼叫多次，客戶端接收到的結果都是一樣的：

GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1Copy to clipboardErrorCopied

POST /add_row HTTP/1.1 不是冪等的，如果呼叫多次，就會增加多行記錄：

POST /add_row HTTP/1.1   -> Adds a 1nd row
POST /add_row HTTP/1.1   -> Adds a 2nd row
POST /add_row HTTP/1.1   -> Adds a 3rd rowCopy to clipboardErrorCopied

DELETE /idX/delete HTTP/1.1 是冪等的，即使不同的請求接收到的狀態碼不一樣：

DELETE /idX/delete HTTP/1.1   -> Returns 200 if idX exists
DELETE /idX/delete HTTP/1.1   -> Returns 404 as it just got deleted
DELETE /idX/delete HTTP/1.1   -> Returns 404Copy to clipboardErrorCopied

可快取

如果要對響應進行快取，需要滿足以下條件：

請求報文的 HTTP 方法本身是可快取的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可快取，POST 在多數情況下不可快取的。
響應報文的狀態碼是可快取的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
響應報文的 Cache-Control 首部欄位沒有指定不進行快取。

XMLHttpRequest

為了闡述 POST 和 GET 的另一個區別，需要先了解 XMLHttpRequest：

XMLHttpRequest 是一個 API，它為客戶端提供了在客戶端和伺服器之間傳輸資料的功能。它提供了一個通過 URL 來獲取資料的簡單方式，並且不會使整個頁面重新整理。這使得網頁只更新一部分頁面而不會打擾到使用者。XMLHttpRequest 在 AJAX 中被大量使用。

在使用 XMLHttpRequest 的 POST 方法時，瀏覽器會先傳送 Header 再傳送 Data。但並不是所有瀏覽器會這麼做，例如火狐就不會。
而 GET 方法 Header 和 Data 會一起傳送。

另外，已經把這些整理成 PDF 了，送給大家：500道面試題必知必會（附答案）

4、面試官：說一說TCP與UDP的區別

TCP協議的主要特點

（1）TCP是面向連線的運輸層協議；所謂面向連線就是雙方傳輸資料之前，必須先建立一條通道，例如三次握手就是建議通道的一個過程，而四次揮手則是結束銷燬通道的一個其中過程。

（2）每一條TCP連線只能有兩個端點（即兩個套接字），只能是點對點的；

（3）TCP提供可靠的傳輸服務。傳送的資料無差錯、不丟失、不重複、按序到達；

（4）TCP提供全雙工通訊。允許通訊雙方的應用程式在任何時候都可以傳送資料，因為兩端都設有傳送快取和接受快取；

（5）面向位元組流。雖然應用程式與TCP互動是一次一個大小不等的資料塊，但TCP把這些資料看成一連串無結構的位元組流，它不保證接收方收到的資料塊和傳送方傳送的資料塊具有對應大小關係，例如，傳送方應用程式交給傳送方的TCP10個資料塊，但就受訪的TCP可能只用了4個資料塊久保收到的位元組流交付給上層的應用程式，但位元組流完全一樣。

TCP的可靠性原理

可靠傳輸有如下兩個特點:

a.傳輸通道無差錯,保證傳輸資料正確;

b.不管傳送方以多快的速度傳送資料,接收方總是來得及處理收到的資料;

（1）首先，採用三次握手來建立TCP連線，四次握手來釋放TCP連線，從而保證建立的傳輸通道是可靠的。

（2）其次，TCP採用了連續ARQ協議（回退N，Go-back-N；超時自動重傳）來保證資料傳輸的正確性，使用滑動視窗協議來保證接方能夠及時處理所接收到的資料，進行流量控制。

（3）最後，TCP使用慢開始、擁塞避免、快重傳和快恢復來進行擁塞控制，避免網路擁塞。

UDP協議特點

（１）UDP是無連線的傳輸層協議；

（２）UDP使用盡最大努力交付，不保證可靠交付；

（３）UDP是面向報文的，對應用層交下來的報文，不合並，不拆分，保留原報文的邊界；

（４）UDP沒有擁塞控制，因此即使網路出現擁塞也不會降低傳送速率；

（５）UDP支援一對一　一對多　多對多的互動通訊；

（６）UDP的首部開銷小，只有８位元組．

TCP和UDP的區別

(1)TCP是可靠傳輸,UDP是不可靠傳輸;

(2)TCP面向連線,UDP無連線;

(3)TCP傳輸資料有序,UDP不保證資料的有序性;

(4)TCP不儲存資料邊界,UDP保留資料邊界;

(5)TCP傳輸速度相對UDP較慢;

(6)TCP有流量控制和擁塞控制,UDP沒有;

(７)TCP是重量級協議,UDP是輕量級協議;

(８)TCP首部較長２０位元組,UDP首部較短８位元組;

基於TCP和UDP的常用協議

HTTP、HTTPS、FTP、TELNET、SMTP(簡單郵件傳輸協議)協議基於可靠的TCP協議。TFTP、DNS、DHCP、TFTP、SNMP(簡單網路管理協議)、RIP基於不可靠的UDP協議

TCP 和 UDP 的常用場景，這個問的好挺多的，例如我當時面試時，就被問過：QQ 登入的過程中，用到了 TCP 和 UDP，QQ 通話呢？

5、面試題：說一說HTTP1.0，1.1，2.0 的區別

HTTP/1.0

1996年5月，HTTP/1.0 版本釋出，為了提高系統的效率，HTTP/1.0規定瀏覽器與伺服器只保持短暫的連線，瀏覽器的每次請求都需要與伺服器建立一個TCP連線，伺服器完成請求處理後立即斷開TCP連線，伺服器不跟蹤每個客戶也不記錄過去的請求。

這種方式就好像我們打電話的時候，只能說一件事兒一樣，說完之後就要結束通話，想要說另外一件事兒的時候就要重新撥打電話。

HTTP/1.0中瀏覽器與伺服器只保持短暫的連線，連線無法複用。也就是說每個TCP連線只能傳送一個請求。傳送資料完畢，連線就關閉，如果還要請求其他資源，就必須再新建一個連線。

我們知道TCP連線的建立需要三次握手，是很耗費時間的一個過程。所以，HTTP/1.0版本的效能比較差。

HTTP1.0 其實也可以強制開啟長連結，例如接受Connection: keep-alive 這個欄位，但是，這不是標準欄位，不同實現的行為可能不一致，因此不是根本的解決辦法。

HTTP/1.1

為了解決HTTP/1.0存在的缺陷，HTTP/1.1於1999年誕生。相比較於HTTP/1.0來說，最主要的改進就是引入了持久連線。所謂的持久連線即TCP連線預設不關閉，可以被多個請求複用。

由於之前打一次電話只能說一件事兒，效率很低。後來人們提出一種想法，就是電話打完之後，先不直接結束通話，而是持續一小段時間，這一小段時間內，如果還有事情溝通可以再次進行溝通。

客戶端和伺服器發現對方一段時間沒有活動，就可以主動關閉連線。或者客戶端在最後一個請求時，主動告訴服務端要關閉連線。

HTTP/1.1版還引入了管道機制（pipelining），即在同一個TCP連線裡面，客戶端可以同時傳送多個請求。這樣就進一步改進了HTTP協議的效率。

有了持久連線和管道，大大的提升了HTTP的效率。但是服務端還是順序執行的，效率還有提升的空間。

HTTP/2

HTTP/2 是 HTTP 協議自 1999 年 HTTP 1.1 釋出後的首個更新，主要基於 SPDY 協議。

HTTP/2 為了解決HTTP/1.1中仍然存在的效率問題，HTTP/2 採用了多路複用。即在一個連線裡，客戶端和瀏覽器都可以同時傳送多個請求或回應，而且不用按照順序一一對應。能這樣做有一個前提，就是HTTP/2進行了二進位制分幀，即 HTTP/2 會將所有傳輸的資訊分割為更小的訊息和幀（frame）,並對它們採用二進位制格式的編碼。

也就是說，老闆可以同時下達多個命令，員工也可以收到了A請求和B請求，於是先回應A請求，結果發現處理過程非常耗時，於是就傳送A請求已經處理好的部分，接著回應B請求，完成後，再傳送A請求剩下的部分。A請求的兩部分響應在組合到一起發給老闆。

而這個負責拆分、組裝請求和二進位制幀的一層就叫做二進位制分幀層。

除此之外，還有一些其他的優化，比如做Header壓縮、服務端推送等。

Header壓縮就是壓縮老闆和員工之間的對話。

服務端推送就是員工事先把一些老闆可能詢問的事情提現傳送到老闆的手機（快取）上。這樣老闆想要知道的時候就可以直接讀取簡訊（快取）了。

目前，主流的HTTP協議還是HTTP/1.1 和 HTTP/2。並且各大網站的HTTP/2的使用率也在逐年增加。

6、什麼是SQL 注入？舉個例子？

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

1). SQL隱碼攻擊的總體思路

　　(1). 尋找到SQL隱碼攻擊的位置
　　(2). 判斷伺服器型別和後臺資料庫型別
　　(3). 針對不通的伺服器和資料庫特點進行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). 使用正規表示式過濾傳入的引數

7、談一談 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 事件的標籤，例如 “οnclick=”, “onfocus” 等等。

需要注意的是，在有些應用中是允許html標籤出現的，甚至是javascript程式碼出現。因此，我們在過濾資料的時候需要仔細分析哪些資料是有特殊要求（例如輸出需要html程式碼、javascript程式碼拼接、或者此表單直接允許使用等等），然後區別處理！

8、在互動過程中如果資料傳送完了，還不想斷開連線怎麼辦，怎麼維持？

在 HTTP 中響應體的 Connection 欄位指定為 keep-alive

connetion:keep-alive;

9、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”，這樣服務端會把緊跟在“%”後的位元組當成普通的位元組，就是不會把它當成各個引數或鍵值對的分隔符

另外，已經把這些整理成 PDF 了，送給大家：500道面試題必知必會（附答案）

10、HTTP 哪些常用的狀態碼及使用場景？

狀態碼分類

1xx：表示目前是協議的中間狀態，還需要後續請求

2xx：表示請求成功

3xx：表示重定向狀態，需要重新請求

4xx：表示請求報文錯誤

5xx：伺服器端錯誤

常用狀態碼

101 切換請求協議，從 HTTP 切換到 WebSocket

200 請求成功，有響應體

301 永久重定向：會快取

302 臨時重定向：不會快取

304 協商快取命中

403 伺服器禁止訪問

404 資源未找到

400 請求錯誤

500 伺服器端錯誤

503 伺服器繁忙

11、HTTP 如何實現長連線？在什麼時候會超時？

通過在頭部（請求和響應頭）設定 Connection: keep-alive，HTTP1.0協議支援，但是預設關閉，從HTTP1.1協議以後，連線預設都是長連線

1、HTTP 一般會有 httpd 守護程式，裡面可以設定 keep-alive timeout，當 tcp 連結閒置超過這個時間就會關閉，也可以在 HTTP 的 header 裡面設定超時時間

2、TCP 的 keep-alive 包含三個引數，支援在系統核心的 net.ipv4 裡面設定：當 TCP 連結之後，閒置了 tcp_keepalive_time，則會發生偵測包，如果沒有收到對方的 ACK，那麼會每隔 tcp_keepalive_intvl 再發一次，直到傳送了 tcp_keepalive_probes，就會丟棄該連結。

（1）tcp_keepalive_intvl = 15
（2）tcp_keepalive_probes = 5
（3）tcp_keepalive_time = 1800

實際上 HTTP 沒有長短連結，只有 TCP 有，TCP 長連線可以複用一個 TCP 連結來發起多次 HTTP 請求，這樣可以減少資源消耗，比如一次請求 HTML，可能還需要請求後續的 JS/CSS/圖片等

12、HTTP狀態碼301和302的區別，都有哪些用途？

一. 301重定向的概念

301重定向（301 Move Permanently），指頁面永久性轉移，表示為資源或頁面永久性地轉移到了另一個位置。301是HTTP協議中的一種狀態碼，當使用者或搜尋引擎向伺服器發出瀏覽請求時，伺服器返回的HTTP資料流中頭資訊（header）中包含狀態碼 301 ，表示該資源已經永久改變了位置。

301重定向是一種非常重要的"自動轉向“技術，網址重定向最為可行的一種方法。

二. 哪些情況需要做301重定向？

網頁開發過程中，時常會遇到網站目錄結構的調整，將頁面轉移到一個新地址；網頁副檔名的改變，這些變化都會導致網頁地址發生改變，此時使用者收藏夾和搜尋引擎資料庫中的舊地址是一個錯誤的地址，訪問之後會出現404頁面，直接導致網站流量的損失。或者是我們需要多個域名跳轉至同一個域名，例如本站主站點域名為 www.conimi.com ，而還有一個域名 www.nico.cc，由於對該域名設定了301重定向，當輸入www.nico.cc 時，自動跳轉至 www.conimi.com 。

三. 301重定向有什麼優點？

有利於網站首選域的確定，對於同一資源頁面多條路徑的301重定向有助於URL權重的集中。例如 www.conimi.com和 conimi.com 是兩個不同的域名，但是指向的內容完全相同，搜尋引擎會對兩個域名收錄情況不同，這樣導致網站權重和排名被分散；對conimi.com 做301重定向跳轉至www.conimi.com 後，權重和排名集中到www.conimi.com，從而提升自然排名。

四. 302重定向又是什麼鬼？

302重定向（302 Move Temporarily），指頁面暫時性轉移，表示資源或頁面暫時轉移到另一個位置，常被用作網址劫持，容易導致網站降權，嚴重時網站會被封掉，不推薦使用。

五. 301與302的區別

301重定向是頁面永久性轉移，搜尋引擎在抓取新內容的同時也將舊的網址替換成重定向之後的網址；

302重定向是頁面暫時性轉移，搜尋引擎會抓取新的內容而儲存舊的網址並認為新的網址只是暫時的。

13、IP地址有哪些分類？

A類地址(1~126)：網路號佔前8位，以0開頭，主機號佔後24位。

B類地址(128~191)：網路號佔前16位，以10開頭，主機號佔後16位。

C類地址(192~223)：網路號佔前24位，以110開頭，主機號佔後8位。

D類地址(224~239)：以1110開頭，保留位多播地址。

E類地址(240~255)：以1111開頭，保留位今後使用

14、簡單說下每一層對應的網路協議有哪些？

計算機五層網路體系中涉及的協議非常多，下面就常用的做了列舉：

15、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 查詢失敗

另外，已經把這些整理成 PDF 了，送給大家：500道面試題必知必會（附答案）

16、TCP 的主要特點是什麼？

TCP 是面向連線的。（就好像打電話一樣，通話前需要先撥號建立連線，通話結束後要掛機釋放連線）；
每一條 TCP 連線只能有兩個端點，每一條 TCP 連線只能是點對點的（一對一）；
TCP 提供可靠交付的服務。通過 TCP 連線傳送的資料，無差錯、不丟失、不重複、並且按序到達；
TCP 提供全雙工通訊。TCP 允許通訊雙方的應用程式在任何時候都能傳送資料。TCP 連線的兩端都設有傳送快取和接收快取，用來臨時存放雙方通訊的資料；
面向位元組流。TCP 中的“流”（Stream）指的是流入程式或從程式流出的位元組序列。“面向位元組流”的含義是：雖然應用程式和 TCP 的互動是一次一個資料塊（大小不等），但 TCP 把應用程式交下來的資料僅僅看成是一連串的無結構的位元組流。

17、UDP 的主要特點是什麼？

UDP 是無連線的；
UDP 使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持複雜的連結狀態（這裡面有許多引數）；
UDP 是面向報文的；
UDP 沒有擁塞控制，因此網路出現擁塞不會使源主機的傳送速率降低（對實時應用很有用，如直播，實時視訊會議等）；
UDP 支援一對一、一對多、多對一和多對多的互動通訊；
UDP 的首部開銷小，只有 8 個位元組，比 TCP 的 20 個位元組的首部要短。

18、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 服務。

19、為什麼 TIME-WAIT 狀態必須等待 2MSL 的時間呢？

1、為了保證 A 傳送的最後一個 ACK 報文段能夠到達 B。這個 ACK 報文段有可能丟失，因而使處在 LAST-ACK 狀態的 B 收不到對已傳送的 FIN + ACK 報文段的確認。B 會超時重傳這個 FIN+ACK 報文段，而 A 就能在 2MSL 時間內（超時 + 1MSL 傳輸）收到這個重傳的 FIN+ACK 報文段。接著 A 重傳一次確認，重新啟動 2MSL 計時器。最後，A 和 B 都正常進入到 CLOSED 狀態。如果 A 在 TIME-WAIT 狀態不等待一段時間，而是在傳送完 ACK 報文段後立即釋放連線，那麼就無法收到 B 重傳的 FIN + ACK 報文段，因而也不會再傳送一次確認報文段，這樣，B 就無法按照正常步驟進入 CLOSED 狀態。

2、防止已失效的連線請求報文段出現在本連線中。A 在傳送完最後一個 ACK 報文段後，再經過時間 2MSL，就可以使本連線持續的時間內所產生的所有報文段都從網路中消失。這樣就可以使下一個連線中不會出現這種舊的連線請求報文段。

20、保活計時器的作用？

除時間等待計時器外，TCP 還有一個保活計時器（keepalive timer）。設想這樣的場景：客戶已主動與伺服器建立了 TCP 連線。但後來客戶端的主機突然發生故障。顯然，伺服器以後就不能再收到客戶端發來的資料。因此，應當有措施使伺服器不要再白白等待下去。這就需要使用保活計時器了。

伺服器每收到一次客戶的資料，就重新設定保活計時器，時間的設定通常是兩個小時。若兩個小時都沒有收到客戶端的資料，服務端就傳送一個探測報文段，以後則每隔 75 秒鐘傳送一次。若連續傳送 10個探測報文段後仍然無客戶端的響應，服務端就認為客戶端出了故障，接著就關閉這個連線。

21、TCP 協議是如何保證可靠傳輸的？

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

22、談談你對停止等待協議的理解？

停止等待協議是為了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止傳送，等待對方確認。在收到確認後再發下一個分組；在停止等待協議中，若接收方收到重複分組，就丟棄該分組，但同時還要傳送確認。主要包括以下幾種情況：無差錯情況、出現差錯情況（超時重傳）、確認丟失和確認遲到、確認丟失和確認遲到。

23、談談你對 ARQ 協議的理解？

自動重傳請求 ARQ 協議

停止等待協議中超時重傳是指只要超過一段時間仍然沒有收到確認，就重傳前面傳送過的分組（認為剛才傳送過的分組丟失了）。因此每傳送完一個分組需要設定一個超時計時器，其重傳時間應比資料在分組傳輸的平均往返時間更長一些。這種自動重傳方式常稱為自動重傳請求 ARQ。

連續 ARQ 協議

連續 ARQ 協議可提高通道利用率。傳送方維持一個傳送視窗，凡位於傳送視窗內的分組可以連續傳送出去，而不需要等待對方確認。接收方一般採用累計確認，對按序到達的最後一個分組傳送確認，表明到這個分組為止的所有分組都已經正確收到了。

24、談談你對滑動視窗的瞭解？

TCP 利用滑動視窗實現流量控制的機制。滑動視窗（Sliding window）是一種流量控制技術。早期的網路通訊中，通訊雙方不會考慮網路的擁擠情況直接傳送資料。由於大家不知道網路擁塞狀況，同時傳送資料，導致中間節點阻塞掉包，誰也發不了資料，所以就有了滑動視窗機制來解決此問題。

TCP 中採用滑動視窗來進行傳輸控制，滑動視窗的大小意味著接收方還有多大的緩衝區可以用於接收資料。傳送方可以通過滑動視窗的大小來確定應該傳送多少位元組的資料。當滑動視窗為 0 時，傳送方一般不能再傳送資料包，但有兩種情況除外，一種情況是可以傳送緊急資料，例如，允許使用者終止在遠端機上的執行程式。另一種情況是傳送方可以傳送一個 1 位元組的資料包來通知接收方重新宣告它希望接收的下一位元組及傳送方的滑動視窗大小。

25、談下你對流量控制的理解？

TCP 利用滑動視窗實現流量控制。流量控制是為了控制傳送方傳送速率，保證接收方來得及接收。接收方傳送的確認報文中的視窗欄位可以用來控制傳送方視窗大小，從而影響傳送方的傳送速率。將視窗欄位設定為 0，則傳送方不能傳送資料。

另外，已經把這些整理成 PDF 了，送給大家：500道面試題必知必會（附答案）

26、談下你對 TCP 擁塞控制的理解？使用了哪些演算法？

擁塞控制和流量控制不同，前者是一個全域性性的過程，而後者指點對點通訊量的控制。在某段時間，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的效能就要變壞。這種情況就叫擁塞。

擁塞控制就是為了防止過多的資料注入到網路中，這樣就可以使網路中的路由器或鏈路不致於過載。擁塞控制所要做的都有一個前提，就是網路能夠承受現有的網路負荷。擁塞控制是一個全域性性的過程，涉及到所有的主機，所有的路由器，以及與降低網路傳輸效能有關的所有因素。相反，流量控制往往是點對點通訊量的控制，是個端到端的問題。流量控制所要做到的就是抑制傳送端傳送資料的速率，以便使接收端來得及接收。

為了進行擁塞控制，TCP 傳送方要維持一個擁塞視窗(cwnd) 的狀態變數。擁塞控制視窗的大小取決於網路的擁塞程度，並且動態變化。傳送方讓自己的傳送視窗取為擁塞視窗和接收方的接受視窗中較小的一個。

TCP 的擁塞控制採用了四種演算法，即：慢開始、擁塞避免、快重傳和快恢復。在網路層也可以使路由器採用適當的分組丟棄策略（如：主動佇列管理 AQM），以減少網路擁塞的發生。

慢開始：

慢開始演算法的思路是當主機開始傳送資料時，如果立即把大量資料位元組注入到網路，那麼可能會引起網路阻塞，因為現在還不知道網路的符合情況。經驗表明，較好的方法是先探測一下，即由小到大逐漸增大傳送視窗，也就是由小到大逐漸增大擁塞視窗數值。cwnd 初始值為 1，每經過一個傳播輪次，cwnd 加倍。

擁塞避免：

擁塞避免演算法的思路是讓擁塞視窗 cwnd 緩慢增大，即每經過一個往返時間 RTT 就把傳送方的 cwnd 加 1。

快重傳與快恢復：

在 TCP/IP 中，快速重傳和快恢復（fast retransmit and recovery，FRR）是一種擁塞控制演算法，它能快速恢復丟失的資料包。

沒有 FRR，如果資料包丟失了，TCP 將會使用定時器來要求傳輸暫停。在暫停的這段時間內，沒有新的或複製的資料包被髮送。有了 FRR，如果接收機接收到一個不按順序的資料段，它會立即給傳送機傳送一個重複確認。如果傳送機接收到三個重複確認，它會假定確認件指出的資料段丟失了，並立即重傳這些丟失的資料段。

有了 FRR，就不會因為重傳時要求的暫停被耽誤。當有單獨的資料包丟失時，快速重傳和快恢復（FRR）能最有效地工作。當有多個資料資訊包在某一段很短的時間內丟失時，它則不能很有效地工作。

27、什麼是粘包？

在進行 Java NIO 學習時，可能會發現：如果客戶端連續不斷的向服務端傳送資料包時，服務端接收的資料會出現兩個資料包粘在一起的情況。

TCP 是基於位元組流的，雖然應用層和 TCP 傳輸層之間的資料互動是大小不等的資料塊，但是 TCP 把這些資料塊僅僅看成一連串無結構的位元組流，沒有邊界；
從 TCP 的幀結構也可以看出，在 TCP 的首部沒有表示資料長度的欄位。

基於上面兩點，在使用 TCP 傳輸資料時，才有粘包或者拆包現象發生的可能。一個資料包中包含了傳送端傳送的兩個資料包的資訊，這種現象即為粘包。

接收端收到了兩個資料包，但是這兩個資料包要麼是不完整的，要麼就是多出來一塊，這種情況即發生了拆包和粘包。拆包和粘包的問題導致接收端在處理的時候會非常困難，因為無法區分一個完整的資料包。

28、TCP 黏包是怎麼產生的？

傳送方產生粘包

採用 TCP 協議傳輸資料的客戶端與伺服器經常是保持一個長連線的狀態（一次連線發一次資料不存在粘包），雙方在連線不斷開的情況下，可以一直傳輸資料。但當傳送的資料包過於的小時，那麼 TCP 協議預設的會啟用 Nagle 演算法，將這些較小的資料包進行合併傳送（緩衝區資料傳送是一個堆壓的過程）；這個合併過程就是在傳送緩衝區中進行的，也就是說資料傳送出來它已經是粘包的狀態了。

接收方產生粘包

接收方採用 TCP 協議接收資料時的過程是這樣的：資料到接收方，從網路模型的下方傳遞至傳輸層，傳輸層的 TCP 協議處理是將其放置接收緩衝區，然後由應用層來主動獲取（C 語言用 recv、read 等函式）；這時會出現一個問題，就是我們在程式中呼叫的讀取資料函式不能及時的把緩衝區中的資料拿出來，而下一個資料又到來並有一部分放入的緩衝區末尾，等我們讀取資料時就是一個粘包。（放資料的速度 > 應用層拿資料速度）

29、怎麼解決拆包和粘包？

分包機制一般有兩個通用的解決方法：

特殊字元控制；
在包頭首都新增資料包的長度。

如果使用 netty 的話，就有專門的編碼器和解碼器解決拆包和粘包問題了。

tips：UDP 沒有粘包問題，但是有丟包和亂序。不完整的包是不會有的，收到的都是完全正確的包。傳送的資料單位協議是 UDP 報文或使用者資料包，傳送的時候既不合並，也不拆分。

30、forward 和 redirect 的區別？

Forward 和 Redirect 代表了兩種請求轉發方式：直接轉發和間接轉發。

直接轉發方式（Forward）：客戶端和瀏覽器只發出一次請求，Servlet、HTML、JSP 或其它資訊資源，由第二個資訊資源響應該請求，在請求物件 request 中，儲存的物件對於每個資訊資源是共享的。

間接轉發方式（Redirect）：實際是兩次 HTTP 請求，伺服器端在響應第一次請求的時候，讓瀏覽器再向另外一個 URL 發出請求，從而達到轉發的目的。

舉個通俗的例子：

直接轉發就相當於：“A 找 B 借錢，B 說沒有，B 去找 C 借，借到借不到都會把訊息傳遞給 A”；

間接轉發就相當於："A 找 B 借錢，B 說沒有，讓 A 去找 C 借"。

31、HTTP 方法有哪些？

客戶端傳送的請求報文第一行為請求行，包含了方法欄位。

GET：獲取資源，當前網路中絕大部分使用的都是 GET；
HEAD：獲取報文首部，和 GET 方法類似，但是不返回報文實體主體部分；
POST：傳輸實體主體
PUT：上傳檔案，由於自身不帶驗證機制，任何人都可以上傳檔案，因此存在安全性問題，一般不使用該方法。
PATCH：對資源進行部分修改。PUT 也可以用於修改資源，但是隻能完全替代原始資源，PATCH 允許部分修改。
OPTIONS：查詢指定的 URL 支援的方法；
CONNECT：要求在與代理伺服器通訊時建立隧道。使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通訊內容加密後經網路隧道傳輸。
TRACE：追蹤路徑。伺服器會將通訊路徑返回給客戶端。傳送請求時，在 Max-Forwards 首部欄位中填入數值，每經過一個伺服器就會減 1，當數值為 0 時就停止傳輸。通常不會使用 TRACE，並且它容易受到 XST 攻擊（Cross-Site Tracing，跨站追蹤）。

32、在瀏覽器中輸入 URL 地址到顯示主頁的過程？

DNS 解析：瀏覽器查詢 DNS，獲取域名對應的 IP 地址：具體過程包括瀏覽器搜尋自身的 DNS 快取、搜尋作業系統的 DNS 快取、讀取本地的 Host 檔案和向本地 DNS 伺服器進行查詢等。對於向本地 DNS 伺服器進行查詢，如果要查詢的域名包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析(此解析具有權威性)；如果要查詢的域名不由本地 DNS 伺服器區域解析，但該伺服器已快取了此網址對映關係，則呼叫這個 IP 地址對映，完成域名解析（此解析不具有權威性）。如果本地域名伺服器並未快取該網址對映關係，那麼將根據其設定發起遞迴查詢或者迭代查詢；
TCP 連線：瀏覽器獲得域名對應的 IP 地址以後，瀏覽器向伺服器請求建立連結，發起三次握手；
傳送 HTTP 請求：TCP 連線建立起來後，瀏覽器向伺服器傳送 HTTP 請求；
伺服器處理請求並返回 HTTP 報文：伺服器接收到這個請求，並根據路徑引數對映到特定的請求處理器進行處理，並將處理結果及相應的檢視返回給瀏覽器；
瀏覽器解析渲染頁面：瀏覽器解析並渲染檢視，若遇到對 js 檔案、css 檔案及圖片等靜態資源的引用，則重複上述步驟並向伺服器請求這些資源；瀏覽器根據其請求到的資源、資料渲染頁面，最終向使用者呈現一個完整的頁面。
連線結束。

另外，已經把這些整理成 PDF 了，送給大家：500道面試題必知必會（附答案）

33、DNS 的解析過程？

主機向本地域名伺服器的查詢一般都是採用遞迴查詢。所謂遞迴查詢就是：如果主機所詢問的本地域名伺服器不知道被查詢的域名的 IP 地址，那麼本地域名伺服器就以 DNS 客戶的身份，向根域名伺服器繼續發出查詢請求報文(即替主機繼續查詢)，而不是讓主機自己進行下一步查詢。因此，遞迴查詢返回的查詢結果或者是所要查詢的 IP 地址，或者是報錯，表示無法查詢到所需的 IP 地址。
本地域名伺服器向根域名伺服器的查詢的迭代查詢。迭代查詢的特點：當根域名伺服器收到本地域名伺服器發出的迭代查詢請求報文時，要麼給出所要查詢的 IP 地址，要麼告訴本地伺服器：“你下一步應當向哪一個域名伺服器進行查詢”。然後讓本地伺服器進行後續的查詢。根域名伺服器通常是把自己知道的頂級域名伺服器的 IP 地址告訴本地域名伺服器，讓本地域名伺服器再向頂級域名伺服器查詢。頂級域名伺服器在收到本地域名伺服器的查詢請求後，要麼給出所要查詢的 IP 地址，要麼告訴本地伺服器下一步應當向哪一個許可權域名伺服器進行查詢。最後，本地域名伺服器得到了所要解析的 IP 地址或報錯，然後把這個結果返回給發起查詢的主機。

34、談談你對域名快取的瞭解？

為了提高 DNS 查詢效率，並減輕伺服器的負荷和減少因特網上的 DNS 查詢報文數量，在域名伺服器中廣泛使用了快取記憶體，用來存放最近查詢過的域名以及從何處獲得域名對映資訊的記錄。

由於名字到地址的繫結並不經常改變，為保持快取記憶體中的內容正確，域名伺服器應為每項內容設定計時器並處理超過合理時間的項（例如：每個專案兩天）。當域名伺服器已從快取中刪去某項資訊後又被請求查詢該項資訊，就必須重新到授權管理該項的域名伺服器繫結資訊。當許可權伺服器回答一個查詢請求時，在響應中都指明繫結有效存在的時間值。增加此時間值可減少網路開銷，而減少此時間值可提高域名解析的正確性。

不僅在本地域名伺服器中需要快取記憶體，在主機中也需要。許多主機在啟動時從本地伺服器下載名字和地址的全部資料庫，維護存放自己最近使用的域名的快取記憶體，並且只在從快取中找不到名字時才使用域名伺服器。維護本地域名伺服器資料庫的主機應當定期地檢查域名伺服器以獲取新的對映資訊，而且主機必須從快取中刪除無效的項。由於域名改動並不頻繁，大多數網點不需花精力就能維護資料庫的一致性。

35、談下你對 HTTP 長連線和短連線的理解？分別應用於哪些場景？

在 HTTP/1.0 中預設使用短連線。也就是說，客戶端和伺服器每進行一次 HTTP 操作，就建立一次連線，任務結束就中斷連線。當客戶端瀏覽器訪問的某個 HTML 或其他型別的 Web 頁中包含有其他的 Web 資源（如：JavaScript 檔案、影像檔案、CSS 檔案等），每遇到這樣一個 Web 資源，瀏覽器就會重新建立一個 HTTP 會話。

而從 HTTP/1.1 起，預設使用長連線，用以保持連線特性。使用長連線的 HTTP 協議，會在響應頭加入這行程式碼：

Connection:keep-alive

在使用長連線的情況下，當一個網頁開啟完成後，客戶端和伺服器之間用於傳輸 HTTP 資料的 TCP 連線不會關閉，客戶端再次訪問這個伺服器時，會繼續使用這一條已經建立的連線。

Keep-Alive 不會永久保持連線，它有一個保持時間，可以在不同的伺服器軟體（如：Apache）中設定這個時間。實現長連線需要客戶端和服務端都支援長連線。

36、HTTPS 的工作過程？

1、客戶端傳送自己支援的加密規則給伺服器，代表告訴伺服器要進行連線了；

2、伺服器從中選出一套加密演算法和 hash 演算法以及自己的身份資訊（地址等）以證照的形式傳送給瀏覽器，證照中包含伺服器資訊，加密公鑰，證照的辦法機構；

3、客戶端收到網站的證照之後要做下面的事情：

驗證證照的合法性；
果驗證通過證照，瀏覽器會生成一串隨機數，並用證照中的公鑰進行加密；
用約定好的 hash 演算法計算握手訊息，然後用生成的金鑰進行加密，然後一起傳送給伺服器。

4、伺服器接收到客戶端傳送來的資訊，要做下面的事情：

4.1 用私鑰解析出密碼，用密碼解析握手訊息，驗證 hash 值是否和瀏覽器發來的一致；
4.2 使用金鑰加密訊息；

5、如果計演算法 hash 值一致，握手成功。

37、HTTP 和 HTTPS 的區別？

開銷：HTTPS 協議需要到 CA 申請證照，一般免費證照很少，需要交費；
資源消耗：HTTP 是超文字傳輸協議，資訊是明文傳輸，HTTPS 則是具有安全性的 ssl 加密傳輸協議，需要消耗更多的 CPU 和記憶體資源；
埠不同：HTTP 和 HTTPS 使用的是完全不同的連線方式，用的埠也不一樣，前者是 80，後者是 443；
安全性：HTTP 的連線很簡單，是無狀態的；HTTPS 協議是由 TSL+HTTP 協議構建的可進行加密傳輸、身份認證的網路協議，比 HTTP 協議安全

38、HTTPS 的優缺點？

優點：

使用 HTTPS 協議可認證使用者和伺服器，確保資料傳送到正確的客戶機和伺服器；
HTTPS 協議是由 SSL + HTTP 協議構建的可進行加密傳輸、身份認證的網路協議，要比 HTTP 協議安全，可防止資料在傳輸過程中不被竊取、改變，確保資料的完整性；
HTTPS 是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。

缺點：

HTTPS 協議握手階段比較費時，會使頁面的載入時間延長近 50%，增加 10% 到 20% 的耗電；
HTTPS 連線快取不如 HTTP 高效，會增加資料開銷和功耗，甚至已有的安全措施也會因此而受到影響；
SSL 證照需要錢，功能越強大的證照費用越高，個人網站、小網站沒有必要一般不會用；
SSL 證照通常需要繫結 IP，不能在同一 IP 上繫結多個域名，IPv4 資源不可能支撐這個消耗；
HTTPS 協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、伺服器劫持等方面幾乎起不到什麼作用。最關鍵的，SSL 證照的信用鏈體系並不安全，特別是在某些國家可以控制 CA 根證照的情況下，中間人攻擊一樣可行。

39、什麼是數字簽名？

為了避免資料在傳輸過程中被替換，比如黑客修改了你的報文內容，但是你並不知道，所以我們讓傳送端做一個數字簽名，把資料的摘要訊息進行一個加密，比如 MD5，得到一個簽名，和資料一起傳送。然後接收端把資料摘要進行 MD5 加密，如果和簽名一樣，則說明資料確實是真的。

40、什麼是數字證照？

對稱加密中，雙方使用公鑰進行解密。雖然數字簽名可以保證資料不被替換，但是資料是由公鑰加密的，如果公鑰也被替換，則仍然可以偽造資料，因為使用者不知道對方提供的公鑰其實是假的。所以為了保證傳送方的公鑰是真的，CA 證照機構會負責頒發一個證照，裡面的公鑰保證是真的，使用者請求伺服器時，伺服器將證照發給使用者，這個證照是經由系統內建證照的備案的。

1、由於HTTP協議是無狀態的協議，所以服務端需要記錄使用者的狀態時，就需要用某種機制來識具體的使用者，這個機制就是Session.典型的場景比如購物車。

當你點選下單按鈕時，由於HTTP協議無狀態，所以並不知道是哪個使用者操作的，所以服務端要為特定的使用者建立了特定的Session，用用於標識這個使用者，並且跟蹤使用者，這樣才知道購物車裡面有幾本書。

這個Session是儲存在服務端的，有一個唯一標識。在服務端儲存Session的方法很多，記憶體、資料庫、檔案都有。叢集的時候也要考慮Session的轉移，在大型的網站，一般會有專門的Session伺服器叢集，用來儲存使用者會話，這個時候 Session 資訊都是放在記憶體的，使用一些快取服務比如Memcached之類的來放 Session。

2、思考一下服務端如何識別特定的客戶？這個時候Cookie就登場了。每次HTTP請求的時候，客戶端都會傳送相應的Cookie資訊到服務端。實際上大多數的應用都是用 Cookie 來實現Session跟蹤的，第一次建立Session的時候，服務端會在HTTP協議中告訴客戶端，需要在 Cookie 裡面記錄一個Session ID，以後每次請求把這個會話ID傳送到伺服器，我就知道你是誰了。

有人問，如果客戶端的瀏覽器禁用了 Cookie 怎麼辦？一般這種情況下，會使用一種叫做URL重寫的技術來進行會話跟蹤，即每次HTTP互動，URL後面都會被附加上一個諸如 sid=xxxxx 這樣的引數，服務端據此來識別使用者。

3、Cookie其實還可以用在一些方便使用者的場景下，設想你某次登陸過一個網站，下次登入的時候不想再次輸入賬號了，怎麼辦？這個資訊可以寫到Cookie裡面，訪問網站的時候，網站頁面的指令碼可以讀取這個資訊，就自動幫你把使用者名稱給填了，能夠方便一下使用者。這也是Cookie名稱的由來，給使用者的一點甜頭。

所以，總結一下：

Session是在服務端儲存的一個資料結構，用來跟蹤使用者的狀態，這個資料可以儲存在叢集、資料庫、檔案中。

Cookie是客戶端儲存使用者資訊的一種機制，用來記錄使用者的一些資訊，也是實現Session的一種方式。

另外，已經把這些整理成 PDF 了，送給大家：500道面試題必知必會（附答案）

另外，這裡還有其他的面試題