計算機網絡基礎面試題彙總

計算機網絡基礎面試題彙總

網絡協議和網絡編程 重難點 參考資料來源於 netty權威指南（高性能的服務端開發） netty實戰 Unix網絡編程 AIO 鳥哥的linux私房菜 《劉超的趣談網絡協議》 《圖解http》

1. 計算機網絡體系知識

1.1 計算機網絡體系結構

概念	基礎知識
定義	計算機網絡的各層 + 其協議的集合
作用	定義該計算機網絡的所能完成的功能
結構介紹	計算機網絡體系結構分爲3種：OSI體系結構、TCP / IP體系結構、五層體系結構，OSI體系結構：概念清楚 & 理念完整，但複雜/不實用；TCP / IP體系結構：含了一系列構成互聯網基礎的網絡協議，是Internet的核心協議 & 被廣泛應用於局域網 和 廣域網；五層體系結構(課本)：融合了OSI 與 TCP / IP的體系結構，目的是爲了學習/講解計算機原理。

• TCP / IP的體系結構詳細介紹
  

由於 TCP / IP體系結構較爲廣泛，故主要講解

---

1.2 OSI與TCP/IP各層的結構與功能,都有哪些協議?

層級	主要任務	使用協議	協議特點
應用層	任務是通過應用進程間的交互來完成特定網絡應用	域名系統DNS/HTTP協議/SMTP協議/文件傳輸FTP/TFTP/虛擬終端Telnet/SSH/動態主機配置協議DHCP	把應用層交互的數據單元稱爲報文
運輸層	負責向兩臺主機進程之間的通信提供通用的數據傳輸服務	主要使用兩種協議:TCP/UDP	傳輸控制協議TCP（Transmission Control Protocol）–提供面向連接的，可靠的數據傳輸服務。用戶數據協議 UDP（User Datagram Protocol）–提供無連接的，盡最大努力的數據傳輸服務（不保證數據傳輸的可靠性）。
網絡層	任務就是選擇合適的網間路由和交換結點， 確保數據及時傳送	IP，ICMP，RIP，OSPF，BGP，IGMP	IP 數據報
數據鏈路層	通常簡稱爲鏈路層。兩臺主機之間的數據傳輸，提供封裝成幀以及錯誤檢測功能	SLIP，CSLIP，PPP，ARP，RARP，MTU	數據鏈路層將網絡層交下來的 IP 數據報組裝成幀
物理層	實現相鄰計算機節點之間比特流的透明傳送，儘可能屏蔽掉具體傳輸介質和物理設備的差異	-	傳送的數據單位是比特

• 2、TCP和UDP分別對應的常見應用層協議
• TCP對應的應用層協議

FTP：定義了文件傳輸協議，使用21端口，下載文件，上傳主頁，都要用到FTP服務
Telnet：它是一種用於遠程登陸的端口，用戶可以以自己的身份遠程連接到計算機上 23端口
SMTP：定義了簡單郵件傳送協議 25號端口
POP3：它是和SMTP對應，POP3用於接收郵件 110端口
HTTP：從Web服務器傳輸超文本到本地瀏覽器的傳送協議

• UDP對應的應用層協議

DNS：用於域名解析服務，將域名地址轉換爲IP地址。DNS用的是53號端口
SNMP：簡單網絡管理協議，使用161號端口，是用來管理網絡設備的
TFTP(Trival File Transfer Protocal)：簡單文件傳輸協議，該協議在熟知端口69上使用UDP服務

• 網絡層的ARP協議工作原理
  網絡層的ARP協議完成了IP地址與物理地址的映射

---

1.3 TCP 三次握手和四次揮手(面試必備)

1、爲了準確無誤地把數據送達目標處，TCP協議採用了三次握手策略。

客戶端–發送帶有 SYN 標誌的數據包–一次握手–服務端
服務端–發送帶有 SYN/ACK 標誌的數據包–二次握手–客戶端
客戶端–發送帶有帶有 ACK 標誌的數據包–三次握手–服務端

• 2 爲什麼要三次握手
  三次握手的目的是建立可靠的通信信道，說到通訊，簡單來說就是數據的發送與接收，而三次握手最主要的目的就是雙方確認自己與對方的發送與接收是正常的。三次握手就能確認雙發收發功能都正常，缺一不可。

第一次握手	Client 什麼都不能確認；Server 確認了對方發送正常，自己接收正常
第二次握手	Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：對方發送正常，自己接收正常
第三次握手	Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：自己發送、接收正常，對方發送、接收正常

三次握手的缺陷：
引起SYN Flood 攻擊：SYN-Flood攻擊是當前網絡上最爲常見的DDoS攻擊，也是最爲經典的拒絕服務攻擊。通過向網絡服務所在端口發送大量的僞造源地址的攻擊報文，就可能造成目標服務器中的半開連接隊列被佔滿，從而阻止其他合法用戶進行訪問.
如何解決：待補充。

• 3 爲什麼要傳回 SYN
  接收端傳回發送端所發送的 SYN 是爲了告訴發送端，我接收到的信息確實就是你所發送的信號了。SYN 是 TCP/IP 建立連接時使用的握手信號。在客戶機和服務器之間建立正常的 TCP 網絡連接時，客戶機首先發出一個 SYN 消息，服務器使用 SYN-ACK 應答表示接收到了這個消息，最後客戶機再以ACK(Acknowledgement[漢譯：確認字符 ,在數據通信傳輸中，接收站發給發送站的一種傳輸控制字符。它表示確認發來的數據已經接受無誤。 ]）消息響應。這樣在客戶機和服務器之間才能建立起可靠的TCP連接，數據纔可以在客戶機和服務器之間傳遞。

• 4、傳了 SYN,爲啥還要傳 ACK
  雙方通信無誤必須是兩者互相發送信息都無誤。傳了 SYN，證明發送方到接收方的通道沒有問題，但是接收方到發送方的通道還需要 ACK 信號來進行驗證。
  

• 斷開一個 TCP 連接則需要“四次揮手”：

客戶端-發送一個 FIN，用來關閉客戶端到服務器的數據傳送;
服務器-收到這個 FIN，它發回一 個 ACK，確認序號爲收到的序號加1 。和 SYN 一樣，一個 FIN 將佔用一個序號;
服務器-關閉與客戶端的連接，發送一個FIN給客戶端;
客戶端-發回 ACK 報文確認，並將確認序號設置爲收到序號加1;

• 5 爲什麼要四次揮手
  任何一方都可以在數據傳送結束後發出連接釋放的通知，待對方確認後進入半關閉狀態。當另一方也沒有數據再發送的時候，則發出連接釋放通知，對方確認後就完全關閉了TCP連接。不足4次無法確定雙方都沒有數據發送。
• 6 爲什麼TIME_WAIT狀態還需要等2MSL後才能返回到CLOSED狀態？
  網絡是不可靠，無法保證(客戶端)最後發送的ACK報文一定會被對方收到，TIME_WAIT狀態用來重發可能丟失的ACK報文。

---

1.4 TCP,UDP 協議的區別

• 1、對比

運輸層協議	特點	使用時機
UDP	UDP 在傳送數據之前不需要先建立連接，遠地主機在收到 UDP 報文後，不需要給出任何確認。雖然 UDP 不提供可靠交付，但在某些情況下 UDP 確是一種最有效的工作方式（一般用於即時通信）	QQ 語音、 QQ 視頻 、直播等等
TCP	提供面向連接的服務。在傳送數據之前必須先建立連接，數據傳送結束後要釋放連接。 TCP 不提供廣播或多播服務。由於 TCP 要提供可靠的，面向連接的傳輸服務（TCP的可靠體現在TCP在傳遞數據之前，會有三次握手來建立連接，而且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制，在數據傳完後，還會斷開連接用來節約系統資源），這一難以避免增加了許多開銷，如確認，流量控制，計時器以及連接管理等。這不僅使協議數據單元的首部增大很多，還要佔用許多處理機資源。	TCP 一般用於文件傳輸、發送和接收郵件、遠程登錄等場景。

• 2、TCP 協議如何保證可靠傳輸（流量控制與擁塞避免）

序號	特點
1	應用數據被分割成 TCP 認爲最適合發送的數據塊。
2	TCP 給發送的每一個包進行編號，接收方對數據包進行排序，把有序數據傳送給應用層。
3	校驗和 ：TCP 將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP 將丟棄這個報文段和不確認收到此報文段。（CRC校驗：課本知識）
4	TCP 的接收端會丟棄重複的數據。
5	流量控制： TCP 連接的每一方都有固定大小的緩衝空間，TCP的接收端只允許發送端發送接收端緩衝區能接納的數據。當接收方來不及處理髮送方的數據，能提示發送方降低發送的速率，防止包丟失。TCP 使用的流量控制協議是可變大小的滑動窗口協議。 （TCP 利用滑動窗口實現流量控制）
6	擁塞控制： 當網絡擁塞時，減少數據的發送。
7	ARQ協議： 也是爲了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止發送，等待對方確認。在收到確認後再發下一個分組。
8	超時重傳： 當 TCP 發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。

• 3、ARQ協議
  自動重傳請求（Automatic Repeat-reQuest，ARQ）是OSI模型中數據鏈路層和傳輸層的錯誤糾正協議之一。它通過使用確認和超時這兩個機制，在不可靠服務的基礎上實現可靠的信息傳輸。如果發送方在發送後一段時間之內沒有收到確認幀，它通常會重新發送。ARQ包括停止等待ARQ協議和連續ARQ協議。

協議	原理	優缺點
停止等待ARQ協議	原理就是每發完一個分組就停止發送，等待對方確認（回覆ACK）。如果過了一段時間（超時時間後），還是沒有收到 ACK 確認，說明沒有發送成功，需要重新發送，直到收到確認後再發下一個分組；在停止等待協議中，若接收方收到重複分組，就丟棄該分組，但同時還要發送確認	優點： 簡單，缺點： 信道利用率低，等待時間長
連續ARQ協議	連續 ARQ 協議可提高信道利用率。發送方維持一個發送窗口，凡位於發送窗口內的分組可以連續發送出去，而不需要等待對方確認。接收方一般採用累計確認，對按序到達的最後一個分組發送確認，表明到這個分組爲止的所有分組都已經正確收到了。	優點： 信道利用率高，容易實現，即使確認丟失，也不必重傳。缺點： 不能向發送方反映出接收方已經正確收到的所有分組的信息。 比如：發送方發送了 5條 消息，中間第三條丟失（3號），這時接收方只能對前兩個發送確認。發送方無法知道後三個分組的下落，而只好把後三個全部重傳一次。這也叫 Go-Back-N（回退 N），表示需要退回來重傳已經發送過的 N 個消息。

• 4、擁塞控制（課本知識）
  擁塞控制是爲了防止過多的數據注入到網絡中，這樣就可以使網絡中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提，就是網絡能夠承受現有的網絡負荷。擁塞控制是一個全局性的過程，涉及到所有的主機，所有的路由器，以及與降低網絡傳輸性能有關的所有因素。相反，流量控制往往是點對點通信量的控制，是個端到端的問題。流量控制所要做到的就是抑制發送端發送數據的速率，以便使接收端來得及接收。
  TCP的擁塞控制採用了四種算法，即 慢開始 、 擁塞避免 、快重傳 和 快恢復。在網絡層也可以使路由器採用適當的分組丟棄策略（如主動隊列管理 AQM），以減少網絡擁塞的發生。

慢開始	慢開始算法的思路是當主機開始發送數據時，如果立即把大量數據字節注入到網絡，那麼可能會引起網絡阻塞，因爲現在還不知道網絡的符合情況。經驗表明，較好的方法是先探測一下，即由小到大逐漸增大發送窗口，也就是由小到大逐漸增大擁塞窗口數值。cwnd初始值爲1，每經過一個傳播輪次，cwnd加倍。
擁塞避免	擁塞避免算法的思路是讓擁塞窗口cwnd緩慢增大，即每經過一個往返時間RTT就把發送放的cwnd加1.
快重傳與快恢復	在 TCP/IP 中，快速重傳和恢復（fast retransmit and recovery，FRR）是一種擁塞控制算法，它能快速恢復丟失的數據包。沒有 FRR，如果數據包丟失了，TCP 將會使用定時器來要求傳輸暫停。在暫停的這段時間內，沒有新的或複製的數據包被髮送。有了 FRR，如果接收機接收到一個不按順序的數據段，它會立即給發送機發送一個重複確認。如果發送機接收到三個重複確認，它會假定確認件指出的數據段丟失了，並立即重傳這些丟失的數據段。當有單獨的數據包丟失時，快速重傳和恢復（FRR）能最有效地工作。當有多個數據信息包在某一段很短的時間內丟失時，它則不能很有效地工作。

• 算法細節：

爲了防止cwnd增長過大引起網絡擁塞，還需設置一個慢開始門限ssthresh狀態變量
ssthresh的用法如下：
1、當cwnd<ssthresh時，使用慢開始算法（指數規律增長）
2、當cwnd>ssthresh時，改用擁塞避免算法（加法增大）
3、當cwnd=ssthresh時，慢開始與擁塞避免算法任意
發送方判斷網絡出現擁塞
把慢開始門限設置爲出現擁塞時的發送窗口大小的一半。然後把擁塞窗口設置爲1，執行慢開始算法

---

2. http詳解（http協議、報文結構，斷點續傳，多線程下載，什麼是長連接）

2.1 http協議簡介

---

2.2. HTTP協議的交互流程，從輸入網址到獲得頁面的詳細過程？ （有贊）

HTTP協議採用 請求 / 響應 的工作方式
具體工作流程如下：

• HTTP協議的交互流程，常見面試題（百世匯通筆試題）（有贊面試）

步驟	過程簡介	詳解
1	DNS解析	查詢DNS，獲取域名對應的IP地址； 瀏覽器搜索自身的dns緩存/搜索操作系統的dns緩存/讀取本地的host文件/發起一個dns的系統調用，寬帶運營商查看本身緩存 運營商發起一個迭代的DNS解析請求
2	TCP連接	瀏覽器獲得域名對應的IP地址後，發起http三次握手
3	發送HTTP請求	tcp/ip連接建立起來後，瀏覽器就可以向服務器發送http請求了
4	服務器處理請求並返回HTTP報文	服務器接受請求，根據路徑參數，經過後端的一些處理生成html頁面代碼返回給瀏覽器
5	瀏覽器解析渲染頁面	瀏覽器拿到完整的html頁面代碼開始解析和渲染，如果遇到引用的外部js，css，圖片等靜態資源，他們同樣也是一個個的http請求，都需要經過上面的步驟
6	連接結束	瀏覽器根據拿到的資源對頁面進行渲染，最終把一個完整的頁面呈現給用戶

---

2.3. HTTP報文詳解-請求報文

HTTP在 應用層 交互數據的方式 = 報文
HTTP的報文分爲：請求報文 & 響應報文

• 分別用於 發送請求 & 響應請求時

下面，將詳細介紹這2種報文
HTTP的請求報文由 請求行、請求頭 & 請求體 組成，如下圖

• 組成1：請求行

作用	聲明 請求方法 、主機域名、資源路徑 & 協議版本
結構	請求行的組成 = 請求方法 + 請求路徑 + 協議版本

• 注：空格不能省

• 組成介紹
  

此處特意說明GET、PSOT方法的區別：

• 示例
  設：請求報文采用GET方法、 URL地址 = http://www.tsinghua.edu.cn/chn/yxsz/index.htm；HTTP1.1版本
  則 請求行是：GET /chn/yxsz/index.htm HTTP/1.1

• 組成2：請求頭
  作用：聲明 客戶端、服務器 / 報文的部分信息
  使用方式：採用”header（字段名）：value (值)“的方式
  常用請求頭

1. 請求和響應報文的通用Header
   
2. 常見請求Header
   

• 舉例：
  (URL地址：http://www.tsinghua.edu.cn/chn/yxsz/index.htm）
  Host：www.tsinghua.edu.cn (表示主機域名）
  User-Agent：Mozilla/5.0 (表示用戶代理是使用Netscape瀏覽器）

• 組成3：請求體
  
  作用：存放 需發送給服務器的數據信息

可選部分，如 GET請求就無請求數據
使用方式：共3種

• 總結
  關於 請求報文的總結如下
  
• 請求報文示例
  

---

2.4 HTTP報文詳解-響應報文

• 報文結構
  HTTP的響應報文包括：狀態行、響應頭 & 響應體
  

其中，響應頭、響應體 與請求報文的請求頭、請求體類似
這2種報文最大的不同在於 狀態行 & 請求行
下面，將詳細介紹每個組成部分

• 結構詳細介紹

組成1：狀態行

作用	聲明 協議版本，狀態碼，狀態碼描述
組成	狀態行有協議版本、狀態碼 &狀態信息組成

其中，空格不能省

具體介紹

• 狀態行 示例
  HTTP/1.1 202 Accepted(接受)、HTTP/1.1 404 Not Found(找不到)

• 組成2：響應頭

作用	聲明客戶端、服務器 / 報文的部分信息
使用方式	採用”header（字段名）：value（值）“的方式

常用請求頭

1. 請求和響應報文的通用Header
   
2. 常見響應Header
   
   組成3：響應體
   

• 作用：存放需返回給客戶端的數據信息

• 使用方式：和請求體是一致的，同樣分爲：任意類型的數據交換格式、鍵值對形式和分部分形式

• 響應報文 總結
  

---

2.5 HTTP報文總結

下面，簡單總結兩種報文結構

---

2.6 HTTP1.1 與 HTTP1.0的區別

HTTP1.1也是當前使用最爲廣泛的HTTP協議。 主要區別主要體現在：

區別	詳解
長連接	在HTTP/1.0中，默認使用的是短連接，也就是說每次請求都要重新建立一次連接。HTTP 是基於TCP/IP協議的,每一次建立或者斷開連接都需要三次握手四次揮手的開銷，如果每次請求都要這樣的話，開銷會比較大。因此最好能維持一個長連接，可以用個長連接來發多個請求。HTTP 1.1起，默認使用長連接 ,默認開啓Connection： keep-alive。 HTTP/1.1的持續連接有非流水線方式和流水線方式 。流水線方式是客戶在收到HTTP的響應報文之前就能接着發送新的請求報文。與之相對應的非流水線方式是客戶在收到前一個響應後才能發送下一個請求。
錯誤狀態響應碼	在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。
緩存處理	在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來做爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
帶寬優化及網絡連接的使用	HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，並且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和連接。

---

2.7 HTTP 與HTTPS的區別 （政採雲問到了，特別深入）

區別	詳解
端口	HTTP的URL由“http://”起始且默認使用端口80，而HTTPS的URL由“https://”起始且默認使用端口443。
安全性和資源消耗	HTTP協議運行在TCP之上，所有傳輸的內容都是明文，客戶端和服務器端都無法驗證對方的身份。HTTPS是運行在SSL/TLS之上的HTTP協議，SSL/TLS 運行在TCP之上。所有傳輸的內容都經過加密，加密採用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。所以說，HTTP 安全性沒有 HTTPS高，但是 HTTPS 比HTTP耗費更多服務器資源。

對稱加密：密鑰只有一個，加密解密爲同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；
非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。

補充 SSL 與 TLS區別 ：後續補充 20200307 （政採雲問到了）

---

2.8、https協議的交互流程/SSL的交互流程？ 政採雲問到了

• 1、什麼是ssl？
  安全套接字協議是web瀏覽器與web服務器之間安全交換信息的協議
• 2、ssl協議的三個特性
  1、保密：在握手協議中定義了會話密鑰後，所有的消息都被加密
  2、鑑別：可選的客戶端認證，和強制的服務器端認證
  3、完整性：傳送的消息包括消息完整性檢查（MAC）
• 3、交互過程

1、客戶端請求建立ssl連接，並將自己支持的一套加密規則發送給網站
2、網站從中選出一組加密算法與hash算法，並將自己的身份信息以證書的形式發回瀏覽器。（證書裏面包括網站地址，加密公鑰、以及證書的頒佈機構）
3、獲得網站證書之後瀏覽器要做以下工作：
驗證證書的合法性
如果證書受信任，瀏覽器會生成一串隨機數的密碼，並用證書中提供的公鑰加密
加密好的隨機數發給服務器
4、獲得到客戶端發的加密了的隨機數之後，服務器用自己的私鑰進行解密，得到這個隨機數，把這個隨機數作爲對稱加密的密鑰
5、之後服務器與客戶之間就可以用隨機數對各自的信息進行加密，解密

---

2.9 HTTP處理長連接的方式

在HTTP/1.0中默認使用短連接。也就是說，客戶端和服務器每進行一次HTTP操作，就建立一次連接，任務結束就中斷連接。當客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。
而從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭加入這行代碼：

Connection:keep-alive

在使用長連接的情況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。
HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。

---

2.10 HTTP是不保存狀態的協議,如何保存用戶狀態?

HTTP 是一種不保存狀態，即無狀態（stateless）協議。也就是說 HTTP 協議自身不對請求和響應之間的通信狀態進行保存。那麼我們保存用戶狀態呢？Session 機制的存在就是爲了解決這個問題，Session 的主要作用就是通過服務端記錄用戶的狀態。典型的場景是購物車，當你要添加商品到購物車的時候，系統不知道是哪個用戶操作的，因爲 HTTP 協議是無狀態的。服務端給特定的用戶創建特定的 Session 之後就可以標識這個用戶並且跟蹤這個用戶了（一般情況下，服務器會在一定時間內保存這個 Session，過了時間限制，就會銷燬這個Session）。

在服務端保存 Session 的方法很多，最常用的就是內存和數據庫(比如是使用內存數據庫redis保存)。既然 Session 存放在服務器端，那麼我們如何實現 Session 跟蹤呢？大部分情況下，我們都是通過在 Cookie 中附加一個 Session ID 來方式來跟蹤。

• Cookie 被禁用怎麼辦?
  最常用的就是利用 URL 重寫把 Session ID 直接附加在URL路徑的後面

---

2.11 Cookie的作用是什麼?和Session有什麼區別？

Cookie 和 Session都是用來跟蹤瀏覽器用戶身份的會話方式，但是兩者的應用場景不太一樣。
Cookie 一般用來保存用戶信息 比如①我們在 Cookie 中保存已經登錄過得用戶信息，下次訪問網站的時候頁面可以自動幫你登錄的一些基本信息給填了；②一般的網站都會有保持登錄也就是說下次你再訪問網站的時候就不需要重新登錄了，這是因爲用戶登錄的時候我們可以存放了一個 Token 在 Cookie 中，下次登錄的時候只需要根據 Token 值來查找用戶即可(爲了安全考慮，重新登錄一般要將 Token 重寫)；③登錄一次網站後訪問網站其他頁面不需要重新登錄。Session 的主要作用就是通過服務端記錄用戶的狀態。 典型的場景是購物車，當你要添加商品到購物車的時候，系統不知道是哪個用戶操作的，因爲 HTTP 協議是無狀態的。服務端給特定的用戶創建特定的 Session 之後就可以標識這個用戶並且跟蹤這個用戶了。

Cookie 數據保存在客戶端(瀏覽器端)，Session 數據保存在服務器端。

Cookie 存儲在客戶端中，而Session存儲在服務器上，相對來說 Session 安全性更高。如果要在 Cookie 中存儲一些敏感信息，不要直接寫入 Cookie 中，最好能將 Cookie 信息加密然後使用到的時候再去服務器端解密。

---

3. 面試題總結

3.1、http協議常見的狀態碼有哪些？

可以分爲5類

類型	詳情	常用的狀態碼
1xx	什麼都沒做直接返回	HTTP/1.1 200 OK 響應狀態行，HTTP/1.1 200 OK
2xx	成功返回	200 正確 //客戶端請求成功，204 服務器成功處理了請求，但是沒有返回任何內容
3xx	做了一些事情，沒有全部完成	301 請求的網頁已永久移動到新位置，請求的url已移走 //重定向， 302 請求的網頁臨時移動到新位置，搜索引擎索引中保存原來的url //重定向 會考到背後的邏輯，304 頁面沒有改變
4xx	客戶端錯誤	400 bad request //客戶端請求有語法錯誤，不能被服務器所理解 ，401 Unauthorized //請求未經授權，403 Forbidden //服務器收到請求，但是拒絕提供服務， 404 未找到頁面 //請求資源不存在，410 請求的資源永久刪除後，服務器返回此響應
5xx	服務器錯誤	、500 服務器出錯.無法完成請求， 503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間後可能恢復正常

---

3.2、http中重定向和請求轉發的區別？

• 本質區別：轉發是服務器行爲，重定向是客戶端行爲。
  重定向特點：兩次請求，瀏覽器地址發生變化，可以訪問自己web之外的資源，傳輸的數據會丟失。
  請求轉發特點：一次請求，瀏覽器地址不變，訪問的是自己本身的web資源，傳輸的數據不會丟失。

---

3.3、web登錄 java安全問題

• 1、http協議傳輸的安全問題：網絡傳輸中，通過fiddler或wireshark可以捕獲http報文中包含的敏感信息，談到Java應用安全，主要涉及哪些安全機制？
  第一，運行時安全機制 就是限制Java運行時的行爲，不要做越權或者不靠譜的事情，在類加載過程中，進行字節碼驗證，以防止不合規的代碼影響JVM運行或者載入其他惡意代碼；類加載器本身也可以對代碼之間進行隔離，利用SecurityManger機制和相關的組件，限制代碼的運行時行爲能力，可以看到，Java的安全模型是以代碼爲中心的，貫穿了從類加載，如URLClassLoader加載網絡上的Java類等，到應用程序運行時權限檢查等全過程
  第二，Java提供的安全框架API，這是構建安全通信等應用的基礎(和廠商相關) 加密、解密API/授權、鑑權API/安全通信相關的類庫，比如基本HTTPS通信協議
  第三， 就是JDK集成的各種安全工具
  keytool，這是個強大的工具，可以管理安全場景中不可或缺的祕鑰、證書等，並且可以管理Java程序使用的keystore文件。 jarsigner，用於對jar文件進行簽名或者驗證

• 2、加密算法能保證密碼安全嗎？
  常見的加密算法有對稱和非對稱加密
  1、對稱加密：加密和解密使用相同的密鑰加密
  前端加密是寫在js裏，但是js有風險被直接破解從而識別加密算法
  2、非對稱加密：需要兩個密鑰，公鑰和私鑰是一對，如果用公開密鑰對數據進行加密，只有用對應的私鑰才能解密，
  1、https可以保證傳輸過程中信息不被別人截獲，https是應用層協議，下層採用ssl保證信息安全，但是在客戶端和服務端，密文同樣可以被截獲
  2、https報文在傳輸過程中，如果客戶端被惡意引導安裝了“中間人”的web信任證書，那麼https中“中間人攻擊”一樣會將明文密碼泄漏給別人。（數字摘要）
  3、結論是：無論http還是https，密碼必須密文傳輸
  使用哪個不可逆加密散列函數MD5，並且，使用服務器緩存生成隨機的驗證字段，併發送給客戶端，當客戶端登錄時，把這個字段一併發送給服務器，用於校驗。

方案1：驗證碼 利用開源的驗證碼生成工具Kaptcha，在服務端存放生成的驗證碼值以及一個驗證碼的生成圖片，將圖片以base64編碼，並返回給view，在view中解碼base64並加載圖片。
方案2：token令牌
前後端分離場景。用戶登錄時，根據用戶的username作爲key，生成隨機令牌（例如UUID)作爲value緩存在redis中，並將token返回給客戶端，當客戶端登錄時，完成校驗，並刪除redis的那條緩存記錄（或者是設置超期，保存半小時）

• 3、客戶端不斷進行請求鏈接會怎樣？DDos(Distributed Denial of Service)攻擊？
  服務器端會爲每個請求創建一個鏈接，並向其發送確認報文，然後等待客戶端進行確認
  1、DDos攻擊
  客戶端向服務端發送請求鏈接數據包 -> 服務端向客戶端發送確認數據包 -> 客戶端不向服務端發送確認數據包,服務器一直等待來自客戶端的確認
  2、DDos預防 ( 沒有徹底根治的辦法，除非不使用TCP )
  限制同時打開SYN半鏈接的數目/縮短SYN半鏈接的Time out 時間/關閉不必要的服務
• 4、XSS攻擊
  XSS是指惡意攻擊者利用網站沒有對用戶提交數據進行轉義處理或者過濾不足的缺點，進而添加一些腳本代碼嵌入到web頁面中去，使別的用戶訪問都會執行相應的嵌入代碼，從而盜取用戶資料、利用用戶身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式
  1、XSS攻擊的危害
  盜取各類用戶帳號，如機器登錄帳號、用戶網銀帳號、各類管理員帳號/非法轉賬/強制發送電子郵件/控制受害者機器向其它網站發起攻擊
  2、原因解析(過於信任客戶端提交的數據)
  解決辦法：不信任任何客戶端提交的數據，只要是客戶端提交的數據就應該先進行相應的過濾處理然後方可進行下一步的操作
  反射性XSS攻擊 (非持久性XSS攻擊)攻擊者注入的數據反映在響應中
  正常：http://www.test.com/message.php?send=Hello,World！
  異常：http://www.test.com/message.php?send= //當其他用戶取出數據顯示的時候，將會執行這些攻擊性代碼
  3、修復漏洞方針

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

---

參考資料：1、https://mp.weixin.qq.com/s/pB_xYEFkTIlCTWyGRExy3Q
2、圖解http
3、https://snailclimb.gitee.io/javaguide