1.6W字！梳理50道經典計算機網絡面試題（收藏版）

前言

金九銀十立刻要到了，整理了50道計算機網絡面試題，每一道都很是的經典，大廠也很是喜歡問。但願你們看完後，都能找到理想的offer哈~css

公衆號：撿田螺的小男孩

1. HTTP 經常使用的請求方式，區別和用途？

GET: 發送請求，獲取服務器數據
POST：向URL指定的資源提交數據
PUT：向服務器提交數據，以修改數據
HEAD:請求頁面的首部，獲取資源的元信息
DELETE：刪除服務器上的某些資源。
CONNECT：創建鏈接隧道，用於代理服務器；
OPTIONS：列出可對資源實行的請求方法，經常使用於跨域
TRACE：追蹤請求-響應的傳輸路徑

2. HTTP 經常使用的狀態碼及含義？

1xx：接受的請求正在處理（信息性狀態碼）
2xx：表示請求正常處理完畢（成功狀態碼）
3xx：表示重定向狀態，須要從新請求（重定向狀態碼）
4xx：服務器沒法處理請求（客戶端錯誤狀態碼）
5xx：服務器處理請求出錯（服務端錯誤狀態碼）

經常使用狀態碼以下：html

101 切換請求協議，從 HTTP 切換到 WebSocket
200 請求成功，表示正常返回信息。
301 永久重定向，會緩存
302 臨時重定向，不會緩存
400 請求錯誤
403 服務器禁止訪問
404 找不到與 URI相匹配的資源。
500 常見的服務器端錯誤

3. 從瀏覽器地址欄輸入url到顯示主頁的過程

DNS解析，查找真正的ip地址
與服務器創建TCP鏈接
發送HTTP請求
服務器處理請求並返回HTTP報文
瀏覽器解析渲染頁面
鏈接結束

4. 如何理解HTTP協議是無狀態的

每次HTTP請求都是獨立的，無相關的，默認不須要保存上下文信息的。咱們來看個便於理解的例子：前端

有狀態：web

A：今天吃啥子？
B：羅非魚！
A：味道怎麼樣呀？
B：還不錯，好香。

無狀態：面試

A：今天吃啥子？
B：羅非魚！
A：味道怎麼樣呀？
B：？啊？啥？什麼鬼？什麼味道怎麼樣？

加下cookie這玩意：算法

A：今天吃啥子？
B：羅非魚
A：你今天吃的羅非魚味道怎麼樣呀？
B：還不錯，好香。

5. HTTP 1.0，1.1，2.0 的版本區別

HTTP 1.0sql

HTTP 1.0規定瀏覽器與服務器只保持短暫的鏈接，瀏覽器的每次請求都須要與服務器創建一個TCP鏈接，服務器完成請求處理後當即斷開TCP鏈接。它也能夠強制開啓長連接，例如設置Connection: keep-alive 這個字段

HTTP 1.1數據庫

引入了長鏈接，即TCP鏈接默認不關閉，能夠被多個請求複用。
引入了管道機制（pipelining），即在同一個TCP鏈接裏面，客戶端能夠同時發送多個請求。
緩存處理，引入了更多的緩存控制策略，如Cache-Control、Etag/If-None-Match等。
錯誤狀態管理，新增了24個錯誤狀態響應碼，如409表示請求的資源與資源的當前狀態發生衝突。

HTTP 2編程

採用了多路複用，即在一個鏈接裏，客戶端和瀏覽器均可以同時發送多個請求或迴應，並且不用按照順序一一對應。
服務端推送，HTTP 2容許服務器未經請求，主動向客戶端發送資源

6. 說下計算機網絡體系結構

計算機網路體系結構主要有ISO七層模型、TCP/IP 四層模型、五層體系結構segmentfault

ISO七層模型

ISO七層模型是國際標準化組織（ISO）制定的一個用於計算機或通訊系統間互聯的標準體系。

應用層：網絡服務與最終用戶的一個接口，協議有：HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP
表示層：數據的表示、安全、壓縮。
會話層：創建、管理、終止會話。對應主機進程，指本地主機與遠程主機正在進行的會話
傳輸層：定義傳輸數據的協議端口號，以及流控和差錯校驗。協議有：TCP UDP，數據包一旦離開網卡即進入網絡傳輸層
網絡層：進行邏輯地址尋址，實現不一樣網絡之間的路徑選擇。協議有：ICMP IGMP IP（IPV4 IPV6）
數據鏈路層：創建邏輯鏈接、進行硬件地址尋址、差錯校驗等功能。
物理層：創建、維護、斷開物理鏈接。

TCP/IP 四層模型

應用層：對應於OSI參考模型的（應用層、表示層、會話層），爲用戶提供所須要的各類服務，例如：FTP、Telnet、DNS、SMTP等
傳輸層:對應OSI的傳輸層，爲應用層實體提供端到端的通訊功能，保證了數據包的順序傳送及數據的完整性。定義了TCP和UDP兩層協議。
網際層：對應於OSI參考模型的網絡層，主要解決主機到主機的通訊問題。三個主要協議：網際協議（IP）、互聯網組管理協議（IGMP）和互聯網控制報文協議（ICMP）
網絡接口層：與OSI參考模型的數據鏈路層、物理層對應。它負責監視數據在主機和網絡之間的交換。

五層體系結構

應用層：經過應用進程間的交互來完成特定網絡應用。對應於OSI參考模型的（應用層、表示層、會話層），應用層協議不少，如域名系統DNS，HTTP協議，支持電子郵件的 SMTP協議等等。咱們把應用層交互的數據單元稱爲報文。
傳輸層：負責向兩臺主機進程之間的通訊提供通用的數據傳輸服務。對應OSI參考模型的傳輸層，協議有傳輸控制協議 TCP 和用戶數據協議 UDP。
網絡層：對應OSI參考模型的的網絡層
數據鏈路層：對應OSI參考模型的的數據鏈路層
物理層：對應OSI參考模型的的物理層層。在物理層上所傳送的數據單位是比特。物理層(physical layer)的做用是實現相鄰計算機節點之間比特流的透明傳送，儘量屏蔽掉具體傳輸介質和物理設備的差別。

7. POST和GET有哪些區別？

請求參數：GET 把參數包含在 URL 中，用&鏈接起來；POST 經過 request body 傳遞參數。
請求緩存：GET請求會被主動Cache，而POST請求不會，除非手動設置。
收藏爲書籤：GET請求支持收藏爲書籤，POST請求不支持。
安全性：POST比GET安全，GET請求在瀏覽器回退時是無害的，而POST會再次請求。
歷史記錄：GET請求參數會被完整保留在瀏覽歷史記錄裏，而POST中的參數不會被保留。
編碼方式：GET請求只能進行url編碼，而POST支持多種編碼方式。
參數數據類型：GET只接受ASCII字符，而POST沒有限制數據類型。
數據包: GET產生一個TCP數據包；POST可能產生兩個TCP數據包。

8. 在交互過程當中若是數據傳送完了，還不想斷開鏈接怎麼辦，怎麼維持？

在 HTTP 中響應體的 Connection 字段指定爲keep-alive

9. HTTP 如何實現長鏈接？在何時會超時？

HTTP 如何實現長鏈接？

HTTP分爲長鏈接和短鏈接，其實本質上說的是TCP的長短鏈接。TCP鏈接是一個雙向的通道，它是能夠保持一段時間不關閉的，所以TCP鏈接纔有真正的長鏈接和短鏈接這一個說法。
長鏈接是指的是TCP鏈接，而不是HTTP鏈接。
TCP 長鏈接能夠複用一個TCP鏈接來發起屢次HTTP請求，這樣能夠減小資源消耗，好比一次請求HTML，短鏈接可能還須要請求後續的JS/CSS/圖片等

要實現HTTP長鏈接，在響應頭設置Connection爲keep-alive，HTTP1.1 默認是長鏈接，而HTTP 1.0協議也支持長鏈接，可是默認是關閉的。

在何時會超時呢？

HTTP 通常會有httpd守護進程，裏面能夠設置 keep-alive timeout，當 tcp 連接閒置超過這個時間就會關閉，也能夠在HTTP的header裏面設置超時時間
TCP 的 keep-alive 包含三個參數，支持在系統內核的 net.ipv4 裏面設置：當 TCP 鏈接以後，閒置了 tcp_keepalive_time，則會發生偵測包，若是沒有收到對方的 ACK，那麼會每隔 tcp_keepalive_intvl 再發一次，直到發送了 tcp_keepalive_probes，就會丟棄該鏈接。

tcp_keepalive_intvl = 15
tcp_keepalive_probes = 5
tcp_keepalive_time = 1800

10. 講一下HTTP與HTTPS 的區別。

HTTP，超文本傳輸協議，英文是Hyper Text Transfer Protocol，是一個基於TCP/IP通訊協議來傳遞數據的協議。HTTP存在這幾個問題：

請求信息明文傳輸，容易被竊聽截取。
數據的完整性未校驗，容易被篡改
沒有驗證對方身份，存在冒充危險

HTTPS就是爲了解決HTTP存在問題的。HTTPS，英文是HyperText Transfer Protocol over Secure Socket Layer，能夠這麼理解Https是身披SSL(Secure Socket Layer)的HTTP，即HTTPS 協議 = HTTP+SSL/TLS。經過 SSL證書來驗證服務器的身份，併爲瀏覽器和服務器之間的傳輸數據進行加密。

它們主要區別：

數據是否加密: Http 是明文傳輸，HTTPS是密文
默認端口: Http默認端口是80，Https默認端口是443
資源消耗：和HTTP通訊相比，Https通訊會消耗更多的CPU和內存資源，由於須要加解密處理；
安全性: http不安全，https比較安全。

11 . Https 流程是怎樣的？

HTTPS = HTTP + SSL/TLS，即用SSL/TLS對數據進行加密和解密，Http進行傳輸。
SSL，即Secure Sockets Layer（安全套接層協議），是網絡通訊提供安全及數據完整性的一種安全協議。
TLS，即Transport Layer Security(安全傳輸層協議)，它是SSL 3.0的後續版本。

用戶在瀏覽器裏輸入一個https網址，而後鏈接到server的443端口。
服務器必需要有一套數字證書，能夠本身製做，也能夠向組織申請，區別就是本身頒發的證書須要客戶端驗證經過。這套證書其實就是一對公鑰和私鑰。
服務器將本身的數字證書（含有公鑰）發送給客戶端。
客戶端收到服務器端的數字證書以後，會對其進行檢查，若是不經過，則彈出警告框。若是證書沒問題，則生成一個密鑰（對稱加密），用證書的公鑰對它加密。
客戶端會發起HTTPS中的第二個HTTP請求，將加密以後的客戶端密鑰發送給服務器。
服務器接收到客戶端發來的密文以後，會用本身的私鑰對其進行非對稱解密，解密以後獲得客戶端密鑰，而後用客戶端密鑰對返回數據進行對稱加密，這樣數據就變成了密文。
服務器將加密後的密文返回給客戶端。
客戶端收到服務器發返回的密文，用本身的密鑰（客戶端密鑰）對其進行對稱解密，獲得服務器返回的數據。

12. 對稱加密與非對稱加密有什麼區別

對稱加密：加密和解密使用相同密鑰的加密算法。

非對稱加密：非對稱加密算法須要兩個密鑰（公開密鑰和私有密鑰）。公鑰與私鑰是成對存在的，若是用公鑰對數據進行加密，只有對應的私鑰才能解密。

13. 什麼是XSS攻擊，如何避免?

XSS 攻擊，全稱跨站腳本攻擊（Cross-Site Scripting），這會與層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，所以有人將跨站腳本攻擊縮寫爲XSS。它指的是惡意攻擊者往Web頁面裏插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web裏面的html代碼會被執行，從而達到惡意攻擊用戶的特殊目的。XSS攻擊通常分三種類型：存儲型、反射型、DOM型XSS

XSS是如何攻擊的？

拿反射型舉個例子吧，流程圖以下：

如何解決XSS攻擊問題

不相信用戶的輸入，對輸入進行過濾，過濾標籤等，只容許合法值。
HTML 轉義
對於連接跳轉，如 <a href="xxx" 等，要校驗內容，禁止以script開頭的非法連接。
限制輸入長度等等

14. 請詳細介紹一下TCP 的三次握手機制

開始客戶端和服務器都處於 CLOSED 狀態，而後服務端開始監聽某個端口，進入 LISTEN 狀態

第一次握手(SYN=1, seq=x)，發送完畢後，客戶端進入 SYN_SEND 狀態
第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1)，發送完畢後，服務器端進入 SYN_RCV狀態。
第三次握手(ACK=1，ACKnum=y+1)，發送完畢後，客戶端進入 ESTABLISHED 狀態，當服務器端接收到這個包時

15. TCP握手爲何是三次，不能是兩次？不能是四次？

TCP握手爲何是三次呢？爲了方便理解，咱們以談戀愛爲個例子：兩我的能走到一塊兒，最重要的事情就是相愛，就是我愛你，而且我知道，你也愛我，接下來咱們以此來模擬三次握手的過程：

爲何握手不能是兩次呢？

若是隻有兩次握手，女孩子可能就不知道，她的那句我也愛你，男孩子是否收到，戀愛關係就不能愉快展開。

爲何握手不能是四次呢？

由於握手不能是四次呢？由於三次已經夠了，三次已經能讓雙方都知道：你愛我，我也愛你。而四次就多餘了。

16. TCP四次揮手過程?

第一次揮手(FIN=1，seq=u)，發送完畢後，客戶端進入FIN_WAIT_1 狀態
第二次揮手(ACK=1，ack=u+1,seq =v)，發送完畢後，服務器端進入CLOSE_WAIT 狀態，客戶端接收到這個確認包以後，進入 FIN_WAIT_2 狀態
第三次揮手(FIN=1，ACK1,seq=w,ack=u+1)，發送完畢後，服務器端進入LAST_ACK 狀態，等待來自客戶端的最後一個ACK。
第四次揮手(ACK=1，seq=u+1,ack=w+1)，客戶端接收到來自服務器端的關閉請求，發送一個確認包，並進入 TIME_WAIT狀態，等待了某個固定時間（兩個最大段生命週期，2MSL，2 Maximum Segment Lifetime）以後，沒有收到服務器端的 ACK ，認爲服務器端已經正常關閉鏈接，因而本身也關閉鏈接，進入 CLOSED 狀態。服務器端接收到這個確認包以後，關閉鏈接，進入 CLOSED 狀態。

17. TCP四次揮手過程當中，客戶端爲何須要等待 2MSL,才進入CLOSED狀態

2MSL，2 Maximum Segment Lifetime，即兩個最大段生命週期

1個 MSL 保證四次揮手中主動關閉方最後的 ACK 報文能最終到達對端

1個 MSL 保證對端沒有收到 ACK 那麼進行重傳的 FIN 報文可以到達

18. 爲何須要四次揮手？

舉個例子吧

小明和小紅打電話聊天，通話差很少要結束時，小紅說「我沒啥要說的了」，小明回答「我知道了」。可是小明可能還會有要說的話，小紅不能要求小明跟着本身的節奏結束通話，因而小明可能又嘰嘰歪歪說了一通，最後小明說「我說完了」，小紅回答「知道了」，這樣通話纔算結束。

19. Session和Cookie的區別。

咱們先來看Session和Cookie的定義：

Cookie是服務器發送到用戶瀏覽器，並保存在瀏覽器本地的一小塊文本串數據。它會在瀏覽器下次向同一服務器再發起請求時，被攜帶發送到服務器。一般，它用於告知服務端兩個請求是否來自同一瀏覽器，同樣用於保持用戶的登陸狀態等。Cookie使基於無狀態的 HTTP 協議記錄穩定的狀態信息成爲了可能。
session指的就是服務器和客戶端一次會話的過程。 Session利用Cookie進行信息處理的，當用戶首先進行了請求後，服務端就在用戶瀏覽器上建立了一個Cookie，當這個Session結束時，其實就是意味着這個Cookie就過時了。Session對象存儲着特定用戶會話所需的屬性及配置信息。

Session 和 Cookie 到底有什麼不一樣呢？

存儲位置不同，Cookie 保存在客戶端，Session 保存在服務器端。
存儲數據類型不同，Cookie 只能保存ASCII，Session能夠存任意數據類型，通常狀況下咱們能夠在 Session 中保持一些經常使用變量信息，好比說 UserId 等。
有效期不一樣，Cookie 可設置爲長時間保持，好比咱們常用的默認登陸功能，Session 通常有效時間較短，客戶端關閉或者 Session 超時都會失效。
隱私策略不一樣，Cookie 存儲在客戶端，比較容易遭到不法獲取，早期有人將用戶的登陸名和密碼存儲在 Cookie 中致使信息被竊取；Session 存儲在服務端，安全性相對 Cookie 要好一些。
存儲大小不一樣，單個Cookie保存的數據不能超過4K，Session可存儲數據遠高於 Cookie。

來看個圖吧：

用戶第一次請求服務器時，服務器根據用戶提交的信息，建立對應的Session ，請求返回時將此Session的惟一標識信息 SessionID 返回給瀏覽器，瀏覽器接收到服務器返回的SessionID信息後，會將此信息存入Cookie 中，同時 Cookie 記錄此SessionID 屬於哪一個域名。

當用戶第二次訪問服務器時，請求會自動判斷此域名下是否存在Cookie信息，若是存在，則自動將Cookie信息也發送給服務端，服務端會從Cookie中獲取 SessionID，再根據 SessionID 查找對應的 Session 信息，若是沒有找到說明用戶沒有登陸或者登陸失效，若是找到 Session 證實用戶已經登陸可執行後面操做。

20. TCP 是如何保證可靠性的

首先，TCP的鏈接是基於三次握手，而斷開則是四次揮手。確保鏈接和斷開的可靠性。
其次，TCP的可靠性，還體如今有狀態;TCP會記錄哪些數據發送了，哪些數據被接受了，哪些沒有被接受，而且保證數據包按序到達，保證數據傳輸不出差錯。
再次，TCP的可靠性，還體如今可控制。它有數據包校驗、ACK應答、超時重傳(發送方)、失序數據重傳（接收方）、丟棄重複數據、流量控制（滑動窗口）和擁塞控制等機制。

21. TCP 和 UDP 的區別

TCP面向鏈接（（如打電話要先撥號創建鏈接）;UDP是無鏈接的，即發送數據以前不須要創建鏈接。
TCP要求安全性，提供可靠的服務，經過TCP鏈接傳送的數據，不丟失、不重複、安全可靠。而UDP盡最大努力交付，即不保證可靠交付。
TCP是點對點鏈接的，UDP一對一，一對多，多對多均可以
TCP傳輸效率相對較低,而UDP傳輸效率高，它適用於對高速傳輸和實時性有較高的通訊或廣播通訊。
TCP適合用於網頁，郵件等;UDP適合用於視頻，語音廣播等
TCP面向字節流，UDP面向報文

22. TCP報文首部有哪些字段，說說其做用

16位端口號：源端口號，主機該報文段是來自哪裏；目標端口號，要傳給哪一個上層協議或應用程序
32位序號：一次TCP通訊（從TCP鏈接創建到斷開）過程當中某一個傳輸方向上的字節流的每一個字節的編號。
32位確認號：用做對另外一方發送的tcp報文段的響應。其值是收到的TCP報文段的序號值加1。
4位頭部長度：表示tcp頭部有多少個32bit字（4字節）。由於4位最大能標識15，因此TCP頭部最長是60字節。
6位標誌位：URG(緊急指針是否有效)，ACk（表示確認號是否有效），PSH（緩衝區還沒有填滿），RST（表示要求對方從新創建鏈接），SYN（創建鏈接消息標誌接），FIN（表示告知對方本端要關閉鏈接了）
16位窗口大小：是TCP流量控制的一個手段。這裏說的窗口，指的是接收通告窗口。它告訴對方本端的TCP接收緩衝區還能容納多少字節的數據，這樣對方就能夠控制發送數據的速度。
16位校驗和：由發送端填充，接收端對TCP報文段執行CRC算法以檢驗TCP報文段在傳輸過程當中是否損壞。注意，這個校驗不只包括TCP頭部，也包括數據部分。這也是TCP可靠傳輸的一個重要保障。
16位緊急指針：一個正的偏移量。它和序號字段的值相加表示最後一個緊急數據的下一字節的序號。所以，確切地說，這個字段是緊急指針相對當前序號的偏移，不妨稱之爲緊急偏移。TCP的緊急指針是發送端向接收端發送緊急數據的方法。

23. HTTP狀態碼301和302的區別？

301（永久移動）請求的網頁已被永久移動到新位置。服務器返回此響應（做爲對GET或HEAD請求的響應）時，會自動將請求者轉到新位置。
302：（臨時移動）服務器目前正從不一樣位置的網頁響應請求，但請求者應繼續使用原有位置來進行之後的請求。此代碼與響應GET和HEAD請求的301代碼相似，會自動將請求者轉到不一樣的位置。

HTTP狀態碼301與302的區別：

它們之間關鍵區別在，資源是否存在有效性；
301資源還在只是換了一個位置，返回的是新位置的內容；
302資源暫時失效，返回的是一個臨時的代替頁上。

24. 聊聊TCP 的重傳機制

超時重傳

TCP 爲了實現可靠傳輸，實現了重傳機制。最基本的重傳機制，就是超時重傳，即在發送數據報文時，設定一個定時器，每間隔一段時間，沒有收到對方的ACK確認應答報文，就會重發該報文。

這個間隔時間，通常設置爲多少呢？咱們先來看下什麼叫RTT（Round-Trip Time，往返時間）。

RTT就是，一個數據包從發出去到回來的時間，即數據包的一次往返時間。超時重傳時間，就是Retransmission Timeout ，簡稱RTO。

RTO設置多久呢？

若是RTO比較小，那極可能數據都沒有丟失，就重發了，這會致使網絡阻塞，會致使更多的超時出現。
若是RTO比較大，等到花兒都謝了仍是沒有重發，那效果就很差了。

通常狀況下，RTO略大於RTT，效果是最好的。一些小夥伴會問，超時時間有沒有計算公式呢?有的！有個標準方法算RTO的公式，也叫Jacobson / Karels 算法。咱們一塊兒來看下計算RTO的公式

1. 先計算SRTT（計算平滑的RTT）

SRTT = (1 - α) * SRTT + α * RTT  //求 SRTT 的加權平均
複製代碼

2. 再計算RTTVAR (round-trip time variation)

RTTVAR = (1 - β) * RTTVAR + β * (|RTT - SRTT|) //計算 SRTT 與真實值的差距
複製代碼

3. 最終的RTO

RTO = µ * SRTT + ∂ * RTTVAR  =  SRTT + 4·RTTVAR  
複製代碼

其中，α = 0.125，β = 0.25， μ = 1，∂ = 4，這些參數都是大量結果得出的最優參數。

可是，超時重傳會有這些缺點：

當一個報文段丟失時，會等待必定的超時週期而後才重傳分組，增長了端到端的時延。

當一個報文段丟失時，在其等待超時的過程當中，可能會出現這種狀況：其後的報文段已經被接收端接收但卻遲遲得不到確認，發送端會認爲也丟失了，從而引發沒必要要的重傳，既浪費資源也浪費時間。

而且，TCP有個策略，就是超時時間間隔會加倍。超時重傳須要等待很長時間。所以，還可使用快速重傳機制。

快速重傳

快速重傳機制，它不以時間驅動，而是以數據驅動。它基於接收端的反饋信息來引起重傳。

一塊兒來看下快速重傳流程：

發送端發送了 1，2，3，4，5,6 份數據:

第一份 Seq=1 先送到了，因而就 Ack 回 2；
第二份 Seq=2 也送到了，假設也正常，因而ACK 回 3；
第三份 Seq=3 因爲網絡等其餘緣由，沒送到；
第四份 Seq=4 也送到了，可是由於Seq3沒收到。因此ACK回3；
後面的 Seq=4,5的也送到了，可是ACK仍是回覆3，由於Seq=3沒收到。
發送端連着收到三個重複冗餘ACK=3的確認（其實是4個，可是前面一個是正常的ACK，後面三個纔是重複冗餘的），便知道哪一個報文段在傳輸過程當中丟失了，因而在定時器過時以前，重傳該報文段。
最後，接收到收到了 Seq3，此時由於 Seq=4，5，6都收到了，因而ACK回7.

但快速重傳還可能會有個問題：ACK只向發送端告知最大的有序報文段，究竟是哪一個報文丟失了呢？並不肯定！那到底該重傳多少個包呢？

是重傳 Seq3 呢？仍是重傳 Seq三、Seq四、Seq五、Seq6 呢？由於發送端並不清楚這三個連續的 ACK3 是誰傳回來的。

帶選擇確認的重傳（SACK）

爲了解決快速重傳的問題：應該重傳多少個包? TCP提供了SACK方法（帶選擇確認的重傳，Selective Acknowledgment）。

SACK機制就是，在快速重傳的基礎上，接收端返回最近收到的報文段的序列號範圍，這樣發送端就知道接收端哪些數據包沒收到，醬紫就很清楚該重傳哪些數據包啦。SACK標記是加在TCP頭部選項字段裏面的。

如上圖中，發送端收到了三次一樣的ACK=30的確認報文，因而就會觸發快速重發機制，經過SACK信息發現只有30~39這段數據丟失，因而重發時就只選擇了這個30~39的TCP報文段進行重發。

D-SACK

D-SACK，即Duplicate SACK（重複SACK），在SACK的基礎上作了一些擴展，，主要用來告訴發送方，有哪些數據包本身重複接受了。DSACK的目的是幫助發送方判斷，是否發生了包失序、ACK丟失、包重複或僞重傳。讓TCP能夠更好的作網絡流控。來看個圖吧：

25. IP地址有哪些分類？

一句話歸納，IP地址 = 網絡號+主機號。

網絡號：它標誌主機（或路由器）所鏈接到的網絡，網絡地址表示屬於互聯網的哪個網絡
主機號：它標誌該主機（或路由器），主機地址表示其屬於該網絡中的哪一臺主機

IP地址分爲A，B，C，D，E 五大類：

A類地址(1~126)：以0開頭，網絡號佔前8位，主機號佔後24位。
B類地址(128~191)：以10開頭，網絡號佔前16位，主機號佔後16位。
C類地址(192~223)：以110開頭，網絡號佔前24位，主機號佔後8位。
D類地址(224~239)：以1110開頭，保留位多播地址。
E類地址(240~255)：以11110開頭，保留位爲未來使用

26. 聊聊TCP的滑動窗口

TCP 發送一個數據，須要收到確認應答，纔會發送下一個數據。這樣有個缺點，就是效率會比較低。

這就好像咱們面對面聊天，你說完一句，我應答後，你纔會說下一句。那麼，若是我在忙其餘事情，沒有可以及時回覆你。你說完一句後，要等到我忙完回覆你，你才說下句，這顯然很不現實。

爲了解決這個問題，TCP引入了窗口，它是操做系統開闢的一個緩存空間。窗口大小值表示無需等待確認應答，而能夠繼續發送數據的最大值。

TCP頭部有個字段叫win，也即那個16位的窗口大小，它告訴對方本端的TCP接收緩衝區還能容納多少字節的數據，這樣對方就能夠控制發送數據的速度，從而達到流量控制的目的。

通俗點講，就是接受方每次收到數據包，在發送確認報文的時候，同時告訴發送方，本身的緩存區還有多少空餘空間，緩衝區的空餘空間，咱們就稱之爲接受窗口大小。這就是win。

TCP 滑動窗口分爲兩種: 發送窗口和接收窗口。發送端的滑動窗口包含四大部分，以下：

已發送且已收到ACK確認
已發送但未收到ACK確認
未發送但能夠發送
未發送也不能夠發送

虛線矩形框，就是發送窗口。
SND.WND: 表示發送窗口的大小,上圖虛線框的格子數就是14個。
SND.UNA: 一個絕對指針，它指向的是已發送但未確認的第一個字節的序列號。
SND.NXT：下一個發送的位置，它指向未發送但能夠發送的第一個字節的序列號。

接收方的滑動窗口包含三大部分，以下：

已成功接收並確認
未收到數據但能夠接收
未收到數據並不能夠接收的數據

虛線矩形框，就是接收窗口。
REV.WND: 表示接收窗口的大小,上圖虛線框的格子就是9個。
REV.NXT:下一個接收的位置，它指向未收到但能夠接收的第一個字節的序列號。

27. 聊聊五層計算機網絡體系結構中，每一層對應的網絡協議有哪些？

28. 聊聊TCP的流量控制

TCP三次握手，發送端和接收端進入到ESTABLISHED狀態，它們便可以愉快地傳輸數據啦。

可是發送端不能瘋狂地向接收端發送數據，由於接收端接收不過來的話，接收方只能把處理不過來的數據存在緩存區裏。若是緩存區都滿了，發送方還在瘋狂發送數據的話，接收方只能把收到的數據包丟掉，這就浪費了網絡資源啦。

TCP 提供一種機制可讓發送端根據接收端的實際接收能力控制發送的數據量，這就是流量控制。

TCP經過滑動窗口來控制流量，咱們看下流量控制的簡要流程吧：

首先雙方三次握手，初始化各自的窗口大小，均爲 400 個字節。

假如當前發送方給接收方發送了200個字節，那麼，發送方的SND.NXT會右移200個字節，也就是說當前的可用窗口減小了200 個字節。
接受方收到後，放到緩衝隊列裏面，REV.WND =400-200=200字節，因此win=200字節返回給發送方。接收方會在 ACK 的報文首部帶上縮小後的滑動窗口200字節
發送方又發送200字節過來，200字節到達，繼續放到緩衝隊列。不過這時候，因爲大量負載的緣由，接受方處理不了這麼多字節，只能處理100字節，剩餘的100字節繼續放到緩衝隊列。這時候，REV.WND = 400-200-100=100字節，即win=100返回發送方。
發送方繼續幹活，發送100字節過來，這時候，接受窗口win變爲0。
發送方中止發送，開啓一個定時任務，每隔一段時間，就去詢問接受方，直到win大於0，才繼續開始發送。

29. 說下ARP 協議的工做原理？

ARP 協議協議，即Address Resolution Protocol，地址解析協議，用於實現IP地址到MAC地址的映射。

首先，每臺主機都會在本身的 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查詢失敗。

30. 說下TCP的擁塞控制

擁塞控制是做用於網絡的，防止過多的數據包注入到網絡中，避免出現網絡負載過大的狀況。它的目標主要是最大化利用網絡上瓶頸鍊路的帶寬。它跟流量控制又有什麼區別呢？流量控制是做用於接收者的，根據接收端的實際接收能力控制發送速度，防止分組丟失的。

咱們能夠把網絡鏈路比喻成一根水管，若是咱們想最大化利用網絡來傳輸數據，那就是儘快讓水管達到最佳充滿狀態。

發送方維護一個擁塞窗口cwnd（congestion window） 的變量，用來估算在一段時間內這條鏈路（水管）能夠承載和運輸的數據（水）的數量。它大小表明着網絡的擁塞程度，而且是動態變化的，可是爲了達到最大的傳輸效率，咱們該如何知道這條水管的運送效率是多少呢？

一個比較簡單的方法就是不斷增長傳輸的水量，直到水管快要爆裂爲止（對應到網絡上就是發生丟包），用 TCP 的描述就是：

只要網絡中沒有出現擁塞，擁塞窗口的值就能夠再增大一些，以便把更多的數據包發送出去，但只要網絡出現擁塞，擁塞窗口的值就應該減少一些，以減小注入到網絡中的數據包數。

實際上，擁塞控制主要有這幾種經常使用算法

慢啓動
擁塞避免
擁塞發生
快速恢復

慢啓動算法

慢啓動算法，表面意思就是，別急慢慢來。它表示TCP創建鏈接完成後，一開始不要發送大量的數據，而是先探測一下網絡的擁塞程度。由小到大逐漸增長擁塞窗口的大小，若是沒有出現丟包，每收到一個ACK，就將擁塞窗口cwnd大小就加1（單位是MSS）。每輪次發送窗口增長一倍，呈指數增加，若是出現丟包，擁塞窗口就減半，進入擁塞避免階段。

TCP鏈接完成，初始化cwnd = 1，代表能夠傳一個MSS單位大小的數據。
每當收到一個ACK，cwnd就加一;
每當過了一個RTT，cwnd就增長一倍; 呈指數讓升

爲了防止cwnd增加過大引發網絡擁塞，還需設置一個慢啓動閥值ssthresh（slow start threshold）狀態變量。當cwnd到達該閥值後，就好像水管被關小了水龍頭同樣，減小擁塞狀態。即當cwnd >ssthresh時，進入了擁塞避免算法。

擁塞避免算法

通常來講，慢啓動閥值ssthresh是65535字節，cwnd到達慢啓動閥值後

每收到一個ACK時，cwnd = cwnd + 1/cwnd
當每過一個RTT時，cwnd = cwnd + 1

顯然這是一個線性上升的算法，避免過快致使網絡擁塞問題。

擁塞發生

當網絡擁塞發生丟包時，會有兩種狀況：

RTO超時重傳
快速重傳

若是是發生了RTO超時重傳，就會使用擁塞發生算法

慢啓動閥值sshthresh = cwnd /2
cwnd 重置爲 1
進入新的慢啓動過程

這真的是辛辛苦苦幾十年，一朝回到解放前。其實還有更好的處理方式，就是快速重傳。發送方收到3個連續重複的ACK時，就會快速地重傳，沒必要等待RTO超時再重傳。

慢啓動閥值ssthresh 和 cwnd 變化以下：

擁塞窗口大小 cwnd = cwnd/2
慢啓動閥值 ssthresh = cwnd
進入快速恢復算法

快速恢復

快速重傳和快速恢復算法通常同時使用。快速恢復算法認爲，還有3個重複ACK收到，說明網絡也沒那麼糟糕，因此沒有必要像RTO超時那麼強烈。

正如前面所說，進入快速恢復以前，cwnd 和 sshthresh已被更新：

- cwnd = cwnd /2
- sshthresh = cwnd
複製代碼

而後，真正的快速算法以下：

cwnd = sshthresh + 3
重傳重複的那幾個ACK（即丟失的那幾個數據包）
若是再收到重複的 ACK，那麼 cwnd = cwnd +1
若是收到新數據的 ACK 後, cwnd = sshthresh。由於收到新數據的 ACK，代表恢復過程已經結束，能夠再次進入了擁塞避免的算法了。

31. TCP 和 UDP 分別對應的常見應用層協議有哪些？

基於TCP的應用層協議有：HTTP、FTP、SMTP、TELNET、SSH

HTTP：HyperText Transfer Protocol（超文本傳輸協議），默認端口80
FTP: File Transfer Protocol (文件傳輸協議), 默認端口(20用於傳輸數據，21用於傳輸控制信息)
SMTP: Simple Mail Transfer Protocol (簡單郵件傳輸協議) ,默認端口25
TELNET: Teletype over the Network (網絡電傳), 默認端口23
SSH： Secure Shell（安全外殼協議），默認端口 22

基於UDP的應用層協議：DNS、TFTP、SNMP

DNS : Domain Name Service (域名服務),默認端口 53
TFTP: Trivial File Transfer Protocol (簡單文件傳輸協議)，默認端口69
SNMP：Simple Network Management Protocol（簡單網絡管理協議），經過UDP端口161接收，只有Trap信息採用UDP端口162。

32. 半鏈接隊列和 SYN Flood 攻擊的關係

TCP進入三次握手前，服務端會從CLOSED狀態變爲LISTEN狀態,同時在內部建立了兩個隊列：半鏈接隊列（SYN隊列）和全鏈接隊列（ACCEPT隊列）。

什麼是半鏈接隊列（SYN隊列） 呢? 什麼是全鏈接隊列（ACCEPT隊列） 呢？回憶下TCP三次握手的圖：

TCP三次握手時，客戶端發送SYN到服務端，服務端收到以後，便回覆ACK和SYN，狀態由LISTEN變爲SYN_RCVD，此時這個鏈接就被推入了SYN隊列，即半鏈接隊列。
當客戶端回覆ACK, 服務端接收後，三次握手就完成了。這時鏈接會等待被具體的應用取走，在被取走以前，它被推入ACCEPT隊列，即全鏈接隊列。

SYN Flood是一種典型的DoS (Denial of Service，拒絕服務) 攻擊，它在短期內，僞造不存在的IP地址,向服務器大量發起SYN報文。當服務器回覆SYN+ACK報文後，不會收到ACK迴應報文，致使服務器上創建大量的半鏈接半鏈接隊列滿了，這就沒法處理正常的TCP請求啦。

主要有 syn cookie和SYN Proxy防火牆等方案應對。

syn cookie：在收到SYN包後，服務器根據必定的方法，以數據包的源地址、端口等信息爲參數計算出一個cookie值做爲本身的SYNACK包的序列號，回覆SYN+ACK後，服務器並不當即分配資源進行處理，等收到發送方的ACK包後，從新根據數據包的源地址、端口計算該包中的確認序列號是否正確，若是正確則創建鏈接，不然丟棄該包。
SYN Proxy防火牆：服務器防火牆會對收到的每個SYN報文進行代理和迴應，並保持半鏈接。等發送方將ACK包返回後，再從新構造SYN包發到服務器，創建真正的TCP鏈接。

33. 有了IP地址，爲何還要用MAC地址？

簡而言之，標識網絡中的一臺計算機，比較經常使用的就是IP地址和MAC地址，但計算機的IP地址可由用戶自行更改，管理起來就相對困難，而MAC地址不可更改，因此通常會把IP地址和MAC地址組合起來使用。

那隻使用MAC地址不用IP地址行不行呢？不行的！由於最先就是MAC地址先出現的，而且當時並不用IP地址，只用MAC地址，後來隨着網絡中的設備愈來愈多，整個路由過程愈來愈複雜，便出現了子網的概念。對於目的地址在其餘子網的數據包，路由只須要將數據包送到那個子網便可。

那爲何要用IP地址呢？是由於IP地址是和地域相關的，對於同一個子網上的設備，IP地址的前綴都是同樣的，這樣路由器經過IP地址的前綴就知道設備在在哪一個子網上了，而只用MAC地址的話，路由器則須要記住每一個MAC地址在哪一個子網，這須要路由器有極大的存儲空間，是沒法實現的。

IP地址能夠比做爲地址，MAC地址爲收件人，在一次通訊過程當中，二者是缺一不可的。

34. 聊聊保活計時器的做用

除時間等待計時器外，TCP 還有一個保活計時器（keepalive timer）。設想這樣的場景：客戶已主動與服務器創建了TCP鏈接。但後來客戶端的主機忽然發生故障。顯然，服務器之後就不能再收到客戶端發來的數據。所以，應當有措施使服務器不要再白白等待下去。這就須要使用保活計時器了。

服務器每收到一次客戶的數據，就從新設置保活計時器，時間的設置一般是兩個小時。若兩個小時都沒有收到客戶端的數據，服務端就發送一個探測報文段，之後則每隔 75秒鐘發送一次。若連續發送10個探測報文段後仍然無客戶端的響應，服務端就認爲客戶端出了故障，接着就關閉這個鏈接。

35. 聊聊ARP協議

ARP協議，地址解析協議，是一個由IP地址獲取MAC物理地址的TCP/IP協議。

什麼是IP地址，什麼是MAC地址？

IP地址：是互聯網協議地址，它是IP協議提供的一種統一的地址格式，它爲互聯網上的每個網絡和每一臺主機分配一個邏輯地址，以此來屏蔽物理地址的差別。
MAC地址：以太網地址或物理地址，它是一個用來確認網絡設備位置的位址。

爲何須要ARP協議呢？

在網絡訪問層中，同一局域網中的一臺主機要和另外一臺主機進行通訊，須要經過MAC地址進行定位，而後才能進行數據包的發送。

而在網絡層和傳輸層中，計算機之間是經過IP地址定位目標主機，對應的數據報文只包含目標主機的IP地址，而沒有 MAC 地址。

所以，在發送以前須要根據IP地址獲取 MAC 地址，而後才能將數據包發送到正確的目標主機，而這個獲取過程是經過ARP協議完成的。

ARP的工做流程

當主機A與主機B要通訊時，工做流程以下：

查詢本地ARP緩存表,看是否有IP地址及其對應的MAC地址。
若是沒匹配到主機B的MAC地址，主機A會在局域網內廣播發送一個ARP請求分組，局域網內全部主機都會收到該請求分組。
主機B收到請求分組報文，發現報文中的IP與本身匹配，就A的IP和MAC地址添加到本地ARP緩存表中。
主機B向主機A響應一個含自身MAC地址的報文。
主機A收到報文後，將B的IP和MAC地址添加至ARP緩存表中。

36. TCP的粘包和拆包

TCP是面向流，沒有界限的一串數據。TCP底層並不瞭解上層業務數據的具體含義，它會根據TCP緩衝區的實際狀況進行包的劃分，因此在業務上認爲，一個完整的包可能會被TCP拆分紅多個包進行發送，也有可能把多個小的包封裝成一個大的數據包發送，這就是所謂的TCP粘包和拆包問題。

爲何會產生粘包和拆包呢?

要發送的數據小於TCP發送緩衝區的大小，TCP將屢次寫入緩衝區的數據一次發送出去，將會發生粘包；
接收數據端的應用層沒有及時讀取接收緩衝區中的數據，將發生粘包；
要發送的數據大於TCP發送緩衝區剩餘空間大小，將會發生拆包；
待發送數據大於MSS（最大報文長度），TCP在傳輸前將進行拆包。即TCP報文長度-TCP頭部長度>MSS。

解決方案：

發送端將每一個數據包封裝爲固定長度
在數據尾部增長特殊字符進行分割
將數據分爲兩部分，一部分是頭部，一部分是內容體；其中頭部結構大小固定，且有一個字段聲明內容體的大小。

37. forward 和 redirect 的區別？

直接轉發方式（Forward） ，客戶端和瀏覽器只發出一次請求，Servlet、HTML、JSP或其它信息資源，由第二個信息資源響應該請求，在請求對象request中，保存的對象對於每一個信息資源是共享的。
間接轉發方式（Redirect） 實際是兩次HTTP請求，服務器端在響應第一次請求的時候，讓瀏覽器再向另一個URL發出請求，從而達到轉發的目的。

舉個通俗的例子：

直接轉發就至關於：「A找B借錢，B說沒有，B去找C借，借到借不到都會把消息傳遞給A」；

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

看這兩個圖，能夠更容易理解一些:

Redirect 的工做原理：

forward 的工做原理

38. Nagle 算法與延遲確認

Nagle算法

若是發送端瘋狂地向接收端發送很小的包，好比就1個字節，那麼親愛的小夥伴，大家以爲會有什麼問題呢？

TCP/IP協議中，不管發送多少數據，老是要在數據前面加上協議頭，同時，對方接收到數據，也須要發送ACK表示確認。爲了儘量的利用網絡帶寬，TCP老是但願儘量的發送足夠大的數據。Nagle算法就是爲了儘量發送大塊數據，避免網絡中充斥着許多小數據塊。

Nagle算法的基本定義是：任意時刻，最多隻能有一個未被確認的小段。所謂「小段」，指的是小於MSS尺寸的數據塊，所謂「未被確認」，是指一個數據塊發送出去後，沒有收到對方發送的ACK確認該數據已收到。

Nagle算法的實現規則：

若是包長度達到MSS，則容許發送；
若是該包含有FIN，則容許發送；
設置了TCP_NODELAY選項，則容許發送；
未設置TCP_CORK選項時，若全部發出去的小數據包（包長度小於MSS）均被確認，則容許發送；
上述條件都未知足，但發生了超時（通常爲200ms），則當即發送。

延遲確認

若是接受方剛接收到發送方的數據包，在很短很短的時間內，又接收到第二個包。那麼請問接收方是一個一個地回覆好點，仍是合併一塊兒回覆好呢？

接收方收到數據包後，若是暫時沒有數據要發給對端，它能夠等一段時再確認（Linux上默認是40ms）。若是這段時間恰好有數據要傳給對端，ACK就隨着數據傳輸，而不須要單獨發送一次ACK。若是超過期間尚未數據要發送，也發送ACK，避免對端覺得丟包。

可是有些場景不能延遲確認，好比發現了亂序包、接收到了大於一個 frame 的報文，且須要調整窗口大小等。

通常狀況下，Nagle算法和延遲確認不能一塊兒使用，Nagle算法意味着延遲發，延遲確認意味着延遲接收，醬紫就會形成更大的延遲，會產生性能問題。

39. URI和URL的區別

URI，全稱是Uniform Resource Identifier)，中文翻譯是統一資源標誌符，主要做用是惟一標識一個資源。
URL，全稱是Uniform Resource Location)，中文翻譯是統一資源定位符，主要做用是提供資源的路徑。

打個經典比喻吧，URI像是身份證，能夠惟一標識一我的，而URL更像一個住址，能夠經過URL找到這我的。

40. 什麼是數字簽名？什麼是數字證書？

瞭解過Https原理的小夥伴，都知道數字證書這玩意。爲了不公鑰被篡改，引入了數字證書，以下：

數字證書構成

公鑰和我的信息，通過Hash算法加密，造成消息摘要；將消息摘要拿到擁有公信力的認證中心（CA），用它的私鑰對消息摘要加密，造成數字簽名.
公鑰和我的信息、數字簽名共同構成數字證書。

41. 什麼是SQL 注入？舉個例子？

SQL注入是一種代碼注入技術，通常被應用於攻擊web應用程序。它經過在 web 應用接口傳入一些特殊參數字符，來欺騙應用服務器，執行惡意的SQL命令，以達到非法獲取系統信息的目的。它目前是黑客對數據庫進行攻擊的最經常使用手段之一。

SQL注入是如何攻擊的？

舉個常見的業務場景：在web表單搜索框輸入員工名字，而後後臺查詢出對應名字的員工。

這種場景下，通常都是前端頁面把一個名字參數name傳到後臺，而後後臺經過SQL把結果查詢出來

name = "田螺"; //前端傳過來的

SQL= "select * from staff where name=" + name;  //根據前端傳過來的name參數，查詢數據庫員工表staff
複製代碼

由於SQL是直接拼接的，若是咱們徹底信任前端傳的參數的話。假如前端傳這麼一個參數時'' or '1'='1'，SQL就變成醬紫的啦。

select * from staff where name='' or '1'='1';
複製代碼

這個SQL會把全部的員工信息全都查出來了，醬紫就請求用戶已經越權啦。請求者能夠獲取全部員工的信息，信息已經暴露了啦。

如何預防SQL注入問題

1). 使用#{}而不是${}

在MyBatis中,使用#{}而不是${}，能夠很大程度防止sql注入。

由於#{}是一個參數佔位符，對於字符串類型，會自動加上""，其餘類型不加。因爲Mybatis採用預編譯，其後的參數不會再進行SQL編譯，因此必定程度上防止SQL注入。
${}是一個簡單的字符串替換，字符串是什麼，就會解析成什麼，存在SQL注入風險

2). 不要暴露一些沒必要要的日誌或者安全信息，好比避免直接響應一些sql異常信息。

若是SQL發生異常了，不要把這些信息暴露響應給用戶，能夠自定義異常進行響應

3). 不相信任何外部輸入參數，過濾參數中含有的一些數據庫關鍵詞關鍵詞

能夠加個參數校驗過濾的方法，過濾union，or等數據庫關鍵詞

4). 適當的權限控制

在你查詢信息時，先校驗下當前用戶是否有這個權限。好比說，實現代碼的時候，可讓用戶多傳一個企業Id什麼的，或者獲取當前用戶的session信息等，在查詢前，先校驗一下當前用戶是不是這個企業下的等等，是的話纔有這個查詢員工的權限。

42. 什麼是DoS、DDoS、DRDoS攻擊？

DOS: (Denial of Service),中文名稱是拒絕服務,一切能引發DOS行爲的攻擊都被稱爲DOS攻擊。最多見的DoS攻擊有計算機網絡寬帶攻擊和連通性攻擊。
DDoS: (Distributed Denial of Service),中文名稱是分佈式拒絕服務。是指處於不一樣位置的多個攻擊者同時向一個或數個目標發動攻擊，或者一個攻擊者控制了位於不一樣位置的多臺機器並利用這些機器對受害者同時實施攻擊。常見的DDos有SYN Flood、Ping of Death、ACK Flood、UDP Flood等。
DRDoS: (Distributed Reflection Denial of Service)，中文名稱是分佈式反射拒絕服務，該方式靠的是發送大量帶有被害者IP地址的數據包給攻擊主機，而後攻擊主機對IP地址源作出大量回應，造成拒絕服務攻擊。

43. WebSocket與socket的區別

Socket = IP地址 + 端口 + 協議。

具體來講，Socket是一套標準，它完成了對TCP/IP的高度封裝，屏蔽網絡細節以方便開發者更好地進行網絡編程。

WebSocket是一個持久化的協議，它是伴隨HTTP5而出的協議，用來解決http不支持持久化鏈接的問題。
Socket一個是網編編程的標準接口，而WebSocket是應用層通訊協議。

44. ICMP協議的功能

ICMP,Internet Control Message Protocol ,Internet控制消息協議。

ICMP協議是一種面向無鏈接的協議，用於傳輸出錯報告控制信息。
它是一個很是重要的協議，它對於網絡安全具備極其重要的意義。它屬於網絡層協議，主要用於在主機與路由器之間傳遞控制信息，包括報告錯誤、交換受限控制和狀態信息等。
當遇到IP數據沒法訪問目標、IP路由器沒法按當前的傳輸速率轉發數據包等狀況時，會自動發送ICMP消息。

好比咱們平常使用得比較多的ping，就是基於ICMP的。

45. Http請求的過程與原理

HTTP是一個基於TCP/IP協議來傳遞數據的超文本傳輸協議，傳輸的數據類型有HTML文件,、圖片文件等。以訪問百度有例子，看下一次Http的請求過程

客戶端進行DNS域名解析，獲得對應的IP地址
根據這個IP，找到對應的服務器創建鏈接（三次握手）
創建TCP鏈接後發起HTTP請求（一個完整的http請求報文）
服務器響應HTTP請求，客戶端獲得html代碼
客戶端解析html代碼，用html代碼中的資源(如js,css,圖片等等)渲染頁面。
服務器關閉TCP鏈接（四次揮手）

46. 說下ping的原理

ping，Packet Internet Groper，是一種因特網包探索器，用於測試網絡鏈接量的程序。Ping是工做在TCP/IP網絡體系結構中應用層的一個服務命令，主要是向特定的目的主機發送ICMP（Internet Control Message Protocol 因特網報文控制協議）請求報文，測試目的站是否可達及瞭解其有關狀態

通常來講，ping能夠用來檢測網絡通不通。它是基於ICMP協議工做的。假設機器A ping機器B，工做過程以下：

ping通知系統，新建一個固定格式的ICMP請求數據包
ICMP協議，將該數據包和目標機器B的IP地址打包，一塊兒轉交給IP協議層
IP層協議將本機IP地址爲源地址，機器B的IP地址爲目標地址，加上一些其餘的控制信息，構建一個IP數據包
先獲取目標機器B的MAC地址。
數據鏈路層構建一個數據幀，目的地址是IP層傳過來的MAC地址，源地址是本機的MAC地址
機器B收到後，對比目標地址，和本身本機的MAC地址是否一致，符合就處理返回，不符合就丟棄。
根據目的主機返回的ICMP回送回答報文中的時間戳，從而計算出往返時間
最終顯示結果有這幾項：發送到目的主機的IP地址、發送 & 收到 & 丟失的分組數、往返時間的最小、最大& 平均值

47. 若是服務器出現了大量 CLOSE_WAIT 狀態如何解決。

咱們先來回憶下TCP的四次揮手

服務器端收到客戶端發送的FIN後，TCP協議棧就會自動發送ACK，接着進入CLOSE_WAIT狀態。
可是若是服務器端不執行socket的close()操做，那麼就無法進入LAST_ACK,致使大量鏈接處於CLOSE_WAIT狀態
因此，若是服務器出現了大量CLOSE_WAIT狀態，通常是程序Bug，或者關閉socket不及時。

48. 什麼是CSRF攻擊，如何避免

什麼是CSRF 攻擊？

CSRF，跨站請求僞造（英語：Cross-site request forgery），簡單點說就是，攻擊者盜用了你的身份，以你的名義發送惡意請求。跟跨網站腳本（XSS）相比，XSS 利用的是用戶對指定網站的信任，CSRF 利用的是網站對用戶網頁瀏覽器的信任。

CSRF是如何攻擊的呢？

咱們來看下這個例子哈（來自百度百科）

1. Tom 登錄銀行，沒有退出，瀏覽器包含了Tom在銀行的身份認證信息。
1. 黑客Jerry將僞造的轉帳請求，包含在在帖子
1. Tom在銀行網站保持登錄的狀況下，瀏覽帖子
1. 將僞造的轉帳請求連同身份認證信息，發送到銀行網站
1. 銀行網站看到身份認證信息，覺得就是Tom的合法操做，最後形成Tom資金損失。

如何解決CSRF攻擊

檢查Referer字段。HTTP頭中有一個Referer字段，這個字段用以標明請求來源於哪一個地址。
添加校驗token。

49. RARP協議的工做原理？

ARP(地址解析協議) ,是設備經過本身知道的IP地址來得到本身不知道的物理地址的協議。
RARP(反向地址轉換協議)以與ARP相反的方式工做。RARP發出要反向解析的物理地址並但願返回其對應的IP地址，應答包括由可以提供所需信息的RARP服務器發出的IP地址。（應用於無盤機）

RARP 工做原理以下：

發送主機發送一個本地的RARP廣播，在此廣播包中，聲明本身的MAC地址而且請求任何收到此請求的RARP服務器分配一個IP地址；
本地網段上的RARP服務器收到此請求後，檢查其RARP列表，查找該MAC地址對應的IP地址；
若是存在，RARP服務器就給源主機發送一個響應數據包並將此IP地址提供給對方主機使用；
若是不存在，RARP服務器對此不作任何的響應；
源主機收到從RARP服務器的響應信息，就利用獲得的IP地址進行通信；若是一直沒有收到RARP服務器的響應信息，表示初始化失敗。

50. 瞭解下DNS，解析過程？

DNS，domain name system，域名解析系統，是因特網上做爲域名和IP地址相互映射的一個分佈式數據庫。它的做用很是簡單，就是能夠根據域名查出對應的IP地址。

解析過程以下：

首先，檢查瀏覽器緩存中，查找對應的IP地址，找到就直接返回；不然下一步。
將請求發送給本地DNS服務器，在本地DNS服務器緩存中查詢，若是查找到就直接返回，不然下一步；
本地DNS服務器向根域名服務器發送請求，根域名服務器會告訴本地DNS服務器去查詢哪一個頂級域名服務器。
本地域名服務器向頂級域名服務器發起查詢請求，頂級域名服務器會告訴本地DNS服務器，去查找哪一個權限域名服務器。
本地域名服務器向權限域名服務器發起查詢請求，權限域名服務器告訴本地域名服務器請求域名所對應的IP地址。
最後，本地域名服務器告訴主機請求域名所對應的IP地址。

好比要查詢 www.baidu.com 的 IP 地址:

首先會在瀏覽器的緩存中,是否查找到www.baidu.com的對應的IP，找到就直接返回；不然下一步。

將請求發送給本地DNS服務器，在本地DNS服務器緩存中查詢，若是查找到就直接返回，不然下一步；

本地DNS服務器向根域名服務器發送請求，根域名服務器返回負責.com 的頂級域名服務器的IP地址的列表。

本地DNS服務器再向其中一個負責 .com的頂級域名服務器發送一個請求，返回負責 .baidu的權威域名服務器的IP地址列表。

本地DNS服務器再向其中一個權威域名服務器發送一個請求，返回www.baidu.com所對應的IP地址。