學(xué)完計算機(jī)網(wǎng)絡(luò)，秋招穩(wěn)的一筆
二哥編程知識星球 （戳鏈接加入）已經(jīng)有 390 多名 小伙伴加入了！這是一個 Java 學(xué)習(xí)指南 + 編程實戰(zhàn)的私密圈子，你可以向二哥提問、幫你制定學(xué)習(xí)計劃、跟著二哥一起做實戰(zhàn)項目，沖沖沖。
Java程序員進(jìn)階之路網(wǎng)址：https://tobebetterjavaer.com
大家好，我是二哥呀，今天繼續(xù)來給大家分享三弟的面渣逆襲！
這次帶來的是計算機(jī)網(wǎng)絡(luò)六十二問，三萬字，七十圖詳解，大概是全網(wǎng)最全的計算機(jī)網(wǎng)絡(luò)面試題。
建議大家收藏了慢慢看，秋招、春招、金九銀十、金三銀四沖！
基礎(chǔ)
1.說下計算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)
計算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)，一般有三種：OSI 七層模型、TCP/IP 四層模型、五層結(jié)構(gòu)。
簡單說，OSI 是一個理論上的網(wǎng)絡(luò)通信模型，TCP/IP 是實際上的網(wǎng)絡(luò)通信模型，五層結(jié)構(gòu)就是為了介紹網(wǎng)絡(luò)原理而折中的網(wǎng)絡(luò)通信模型。
OSI 七層模型
OSI 七層模型是國際標(biāo)準(zhǔn)化組織（International Organization for Standardization）制定的一個用于計算機(jī)或通信系統(tǒng)間互聯(lián)的標(biāo)準(zhǔn)體系。
應(yīng)用層：通過應(yīng)用進(jìn)程之間的交互來完成特定網(wǎng)絡(luò)應(yīng)用，應(yīng)用層協(xié)議定義的是應(yīng)用進(jìn)程間通信和交互的規(guī)則，常見的協(xié)議有：HTTP FTP SMTP SNMP DNS. 表示層：數(shù)據(jù)的表示、安全、壓縮。確保一個系統(tǒng)的應(yīng)用層所發(fā)送的信息可以被另一個系統(tǒng)的應(yīng)用層讀取。 會話層：建立、管理、終止會話，是用戶應(yīng)用程序和網(wǎng)絡(luò)之間的接口。 運(yùn)輸層：提供源端與目的端之間提供可靠的透明數(shù)據(jù)傳輸，傳輸層協(xié)議為不同主機(jī)上運(yùn)行的進(jìn)程提供邏輯通信。 網(wǎng)絡(luò)層：將網(wǎng)絡(luò)地址翻譯成對應(yīng)的物理地址，實現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇, 協(xié)議有 ICMP IGMP IP 等. 數(shù)據(jù)鏈路層：在物理層提供比特流服務(wù)的基礎(chǔ)上，建立相鄰結(jié)點(diǎn)之間的數(shù)據(jù)鏈路。 物理層：建立、維護(hù)、斷開物理連接。
TCP/IP 四層模型
應(yīng)用層：對應(yīng)于 OSI 參考模型的（應(yīng)用層、表示層、會話層）。 傳輸層: 對應(yīng) OSI 的傳輸層，為應(yīng)用層實體提供端到端的通信功能，保證了數(shù)據(jù)包的順序傳送及數(shù)據(jù)的完整性。 網(wǎng)際層：對應(yīng)于 OSI 參考模型的網(wǎng)絡(luò)層，主要解決主機(jī)到主機(jī)的通信問題。 網(wǎng)絡(luò)接口層：與 OSI 參考模型的數(shù)據(jù)鏈路層、物理層對應(yīng)。
五層體系結(jié)構(gòu)
應(yīng)用層：對應(yīng)于 OSI 參考模型的（應(yīng)用層、表示層、會話層）。 傳輸層：對應(yīng) OSI 參考模型的的傳輸層 網(wǎng)絡(luò)層：對應(yīng) OSI 參考模型的的網(wǎng)絡(luò)層 數(shù)據(jù)鏈路層：對應(yīng) OSI 參考模型的的數(shù)據(jù)鏈路層 物理層：對應(yīng) OSI 參考模型的的物理層。
2.說一下每一層對應(yīng)的網(wǎng)絡(luò)協(xié)議有哪些？
一張表格總結(jié)常見網(wǎng)絡(luò)協(xié)議：
3.那么數(shù)據(jù)在各層之間是怎么傳輸?shù)哪兀?/span>
對于發(fā)送方而言，從上層到下層層層包裝，對于接收方而言，從下層到上層，層層解開包裝。
發(fā)送方的應(yīng)用進(jìn)程向接收方的應(yīng)用進(jìn)程傳送數(shù)據(jù) AP 先將數(shù)據(jù)交給本主機(jī)的應(yīng)用層，應(yīng)用層加上本層的控制信息 H5 就變成了下一層的數(shù)據(jù)單元 傳輸層收到這個數(shù)據(jù)單元后，加上本層的控制信息 H4，再交給網(wǎng)絡(luò)層，成為網(wǎng)絡(luò)層的數(shù)據(jù)單元 到了數(shù)據(jù)鏈路層，控制信息被分成兩部分，分別加到本層數(shù)據(jù)單元的首部（H2）和尾部（T2） 最后的物理層，進(jìn)行比特流的傳輸
這個過程類似寫信，寫一封信，每到一層，就加一個信封，寫一些地址的信息。到了目的地之后，又一層層解封，傳向下一個目的地。
網(wǎng)絡(luò)綜合
4.從瀏覽器地址欄輸入 url 到顯示主頁的過程？
這道題，大概的過程比較簡單，但是有很多點(diǎn)可以細(xì)挖：DNS 解析、TCP 三次握手、HTTP 報文格式、TCP 四次揮手等等。
DNS 解析：將域名解析成對應(yīng)的 IP 地址。 TCP 連接：與服務(wù)器通過三次握手，建立 TCP 連接 向服務(wù)器發(fā)送 HTTP 請求 服務(wù)器處理請求，返回 HTTp 響應(yīng) 瀏覽器解析并渲染頁面 斷開連接：TCP 四次揮手，連接結(jié)束
我們以輸入 www.baidu.com 為例：
各個過程都使用了哪些協(xié)議？
5.說說 DNS 的解析過程？
DNS，英文全稱是 domain name system，域名解析系統(tǒng)，它的作用也很明確，就是域名和 IP 相互映射。
DNS 的解析過程如下圖：
假設(shè)你要查詢 www.baidu.com 的 IP 地址:
首先會查找瀏覽器的緩存,看看是否能找到www.baidu.com對應(yīng)的 IP 地址，找到就直接返回；否則進(jìn)行下一步。 將請求發(fā)往給本地 DNS 服務(wù)器，如果查找到也直接返回，否則繼續(xù)進(jìn)行下一步；
本地 DNS 服務(wù)器向根域名服務(wù)器發(fā)送請求，根域名服務(wù)器返回負(fù)責(zé) com的頂級域名服務(wù)器的 IP 地址的列表。本地 DNS 服務(wù)器再向其中一個負(fù)責(zé) com的頂級域名服務(wù)器發(fā)送一個請求，返回負(fù)責(zé)baidu.com的權(quán)限域名服務(wù)器的 IP 地址列表。本地 DNS 服務(wù)器再向其中一個權(quán)限域名服務(wù)器發(fā)送一個請求，返回www.baidu.com所對應(yīng)的 IP 地址。
6.說說 WebSocket 與 Socket 的區(qū)別？
Socket 其實就是等于 IP 地址 + 端口 + 協(xié)議。
具體來說，Socket 是一套標(biāo)準(zhǔn)，它完成了對 TCP/IP 的高度封裝，屏蔽網(wǎng)絡(luò)細(xì)節(jié)，以方便開發(fā)者更好地進(jìn)行網(wǎng)絡(luò)編程。
WebSocket 是一個持久化的協(xié)議，它是伴隨 H5 而出的協(xié)議，用來解決 http 不支持持久化連接的問題。 Socket 一個是網(wǎng)編編程的標(biāo)準(zhǔn)接口，而 WebSocket 則是應(yīng)用層通信協(xié)議。
7.說一下你了解的端口及對應(yīng)的服務(wù)？
HTTP
8.說說 HTTP 常用的狀態(tài)碼及其含義？
HTTP 狀態(tài)碼首先應(yīng)該知道個大概的分類：
1XX：信息性狀態(tài)碼 2XX：成功狀態(tài)碼 3XX：重定向狀態(tài)碼 4XX：客戶端錯誤狀態(tài)碼 5XX：服務(wù)端錯誤狀態(tài)碼
幾個常用的，面試之外，也應(yīng)該記住：
之前寫過一篇：程序員五一被拉去相親，結(jié)果徹底搞懂了 HTTP 常用狀態(tài)碼，還比較有意思，可以看看。
說一下 301 和 302 的區(qū)別？
301：永久性移動，請求的資源已被永久移動到新位置。服務(wù)器返回此響應(yīng)時，會返回新的資源地址。 302：臨時性性移動，服務(wù)器從另外的地址響應(yīng)資源，但是客戶端還應(yīng)該使用這個地址。
用一個比喻，301 就是嫁人的新垣結(jié)衣，302 就是有男朋友的長澤雅美。
9.HTTP 有哪些請求方式？
其中，POST、DELETE、PUT、GET 的含義分別對應(yīng)我們最熟悉的增、刪、改、查。
10.說?下 GET 和 POST 的區(qū)別？
可以從以下幾個方面來說明 GET 和 POST 的區(qū)別：
從 HTTP 報文層面來看，GET 請求將信息放在 URL，POST 將請求信息放在請求體中。這一點(diǎn)使得 GET 請求攜帶的數(shù)據(jù)量有限，因為 URL 本身是有長度限制的，而 POST 請求的數(shù)據(jù)存放在報文體中，因此對大小沒有限制。而且從形式上看，GET 請求把數(shù)據(jù)放 URL 上不太安全，而 POST 請求把數(shù)據(jù)放在請求體里想比較而言安全一些。 從數(shù)據(jù)庫層面來看，GET 符合冪等性和安全性，而 POST 請求不符合。這個其實和 GET/POST 請求的作用有關(guān)。按照 HTTP 的約定，GET 請求用于查看信息，不會改變服務(wù)器上的信息；而 POST 請求用來改變服務(wù)器上的信息。正因為 GET 請求只查看信息，不改變信息，對數(shù)據(jù)庫的一次或多次操作獲得的結(jié)果是一致的，認(rèn)為它符合冪等性。安全性是指對數(shù)據(jù)庫操作沒有改變數(shù)據(jù)庫中的數(shù)據(jù)。 從其他層面來看，GET 請求能夠被緩存，GET 請求能夠保存在瀏覽器的瀏覽記錄里，GET 請求的 URL 能夠保存為瀏覽器書簽。這些都是 POST 請求所不具備的。緩存是 GET 請求被廣泛應(yīng)用的根本，他能夠被緩存也是因為它的冪等性和安全性，除了返回結(jié)果沒有其他多余的動作，因此絕大部分的 GET 請求都被 CDN 緩存起來了，大大減少了 Web 服務(wù)器的負(fù)擔(dān)。
11.GET 的長度限制是多少？
HTTP 中的 GET 方法是通過 URL 傳遞數(shù)據(jù)的，但是 URL 本身其實并沒有對數(shù)據(jù)的長度進(jìn)行限制，真正限制 GET 長度的是瀏覽器。
例如 IE 瀏覽器對 URL 的最大限制是 2000 多個字符，大概 2kb 左右，像 Chrome、Firefox 等瀏覽器支持的 URL 字符數(shù)更多，其中 FireFox 中 URL 的最大長度限制是 65536 個字符，Chrome 則是 8182 個字符。
這個長度限制也不是針對數(shù)據(jù)部分，而是針對整個 URL。
12.HTTP 請求的過程與原理？
HTTP 協(xié)議定義了瀏覽器怎么向服務(wù)器請求文檔，以及服務(wù)器怎么把文檔傳給瀏覽器。
每個服務(wù)器都有一個進(jìn)程，它不斷監(jiān)聽 TCP 的端口 80，以便發(fā)現(xiàn)是否有瀏覽器向它發(fā)出連接建立請求 監(jiān)聽到連接請求，就會建立 TCP 連接 瀏覽器向服務(wù)器發(fā)出瀏覽某個頁面的請求，服務(wù)器接著就返回所請求的頁面作為響應(yīng) 最后，釋放 TCP 連接
在瀏覽器和服務(wù)器之間的請求和響應(yīng)的交互，必須按照規(guī)定的格式和遵循一定的規(guī)則，這些格式和規(guī)則就是超文本傳輸協(xié)議 HTTP。
PS:這道題和上面瀏覽器輸入網(wǎng)址發(fā)生了什么那道題大差不差。
13.說一下 HTTP 的報文結(jié)構(gòu)？
HTTP 報文有兩種，HTTP 請求報文和 HTTP 響應(yīng)報文：
HTTP 請求報文
HTTP 請求報文的格式如下：
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*
HTTP 請求報文的第一行叫做請求行，后面的行叫做首部行，首部行后還可以跟一個實體主體。請求首部之后有一個空行，這個空行不能省略，它用來劃分首部與實體。
請求行包含三個字段：
方法字段：包括 POST、GET 等請方法。 URL 字段 HTTP 版本字段。
HTTP 響應(yīng)報文
HTTP 響應(yīng)報文的格式如下：
HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84
<html>
<body>Hello World</body>
</html>
HTTP 響應(yīng)報文的第一行叫做狀態(tài)行，后面的行是首部行，最后是實體主體。
狀態(tài)行包含了三個字段：協(xié)議版本字段、狀態(tài)碼和相應(yīng)的狀態(tài)信息。
實體部分是報文的主要部分，它包含了所請求的對象。
首部行首部可以分為四種首部，請求首部、響應(yīng)首部、通用首部和實體首部。通用首部和實體首部在請求報文和響應(yīng)報文中都可以設(shè)置，區(qū)別在于請求首部和響應(yīng)首部。
常見的請求首部有 Accept 可接收媒體資源的類型、Accept-Charset 可接收的字符集、Host 請求的主機(jī)名。
常見的響應(yīng)首部有 ETag 資源的匹配信息，Location 客戶端重定向的 URI。
常見的通用首部有 Cache-Control 控制緩存策略、Connection 管理持久連接。
常見的實體首部有 Content-Length 實體主體的大小、Expires 實體主體的過期時間、Last-Modified 資源的最后修改時間。
14.URI 和 URL 有什么區(qū)別?
URI，統(tǒng)一資源標(biāo)識符(Uniform Resource Identifier， URI)，標(biāo)識的是 Web 上每一種可用的資源，如 HTML 文檔、圖像、視頻片段、程序等都是由一個 URI 進(jìn)行標(biāo)識的。 URL，統(tǒng)一資源定位符（Uniform Resource Location)，它是 URI 的一種子集，主要作用是提供資源的路徑。
它們的主要區(qū)別在于，URL 除了提供了資源的標(biāo)識，還提供了資源訪問的方式。這么比喻，URI 像是身份證，可以唯一標(biāo)識一個人，而 URL 更像一個住址，可以通過 URL 找到這個人——人類住址協(xié)議://地球/中國/北京市/海淀區(qū)/xx 職業(yè)技術(shù)學(xué)院/14 號宿舍樓/525 號寢/張三.男。
15.說下 HTTP/1.0，1.1，2.0 的區(qū)別？
關(guān)鍵需要記住 HTTP/1.0 默認(rèn)是短連接，可以強(qiáng)制開啟，HTTP/1.1 默認(rèn)長連接，HTTP/2.0 采用多路復(fù)用。
HTTP/1.0
默認(rèn)使用短連接，每次請求都需要建立一個 TCP 連接。它可以設(shè)置 Connection: keep-alive這個字段，強(qiáng)制開啟長連接。
HTTP/1.1
引入了持久連接，即 TCP 連接默認(rèn)不關(guān)閉，可以被多個請求復(fù)用。 分塊傳輸編碼，即服務(wù)端每產(chǎn)生一塊數(shù)據(jù)，就發(fā)送一塊，用” 流模式” 取代” 緩存模式”。 管道機(jī)制，即在同一個 TCP 連接里面，客戶端可以同時發(fā)送多個請求。
HTTP/2.0
二進(jìn)制協(xié)議，1.1 版本的頭信息是文本（ASCII 編碼），數(shù)據(jù)體可以是文本或者二進(jìn)制；2.0 中，頭信息和數(shù)據(jù)體都是二進(jìn)制。 完全多路復(fù)用，在一個連接里，客戶端和瀏覽器都可以同時發(fā)送多個請求或回應(yīng)，而且不用按照順序一一對應(yīng)。 報頭壓縮，HTTP 協(xié)議不帶有狀態(tài)，每次請求都必須附上所有信息。Http/2.0 引入了頭信息壓縮機(jī)制，使用 gzip 或 compress 壓縮后再發(fā)送。 服務(wù)端推送，允許服務(wù)器未經(jīng)請求，主動向客戶端發(fā)送資源。
16.HTTP/3 了解嗎？
HTTP/3 主要有兩大變化，傳輸層基于 UDP、使用QUIC 保證 UDP 可靠性。
HTTP/2 存在的一些問題，比如重傳等等，都是由于 TCP 本身的特性導(dǎo)致的，所以 HTTP/3 在 QUIC 的基礎(chǔ)上進(jìn)行發(fā)展而來，QUIC（Quick UDP Connections）直譯為快速 UDP 網(wǎng)絡(luò)連接，底層使用 UDP 進(jìn)行數(shù)據(jù)傳輸。
HTTP/3 主要有這些特點(diǎn)：
使用 UDP 作為傳輸層進(jìn)行通信 在 UDP 的基礎(chǔ)上 QUIC 協(xié)議保證了 HTTP/3 的安全性，在傳輸?shù)倪^程中就完成了 TLS 加密握手 HTTPS 要建??個連接，要花費(fèi) 6 次交互，先是建?三次握?，然后是 TLS/1.3 的三次握?。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，減少了交互次數(shù)。 QUIC 有??的?套機(jī)制可以保證傳輸?shù)目煽啃缘?。?dāng)某個流發(fā)?丟包時，只會阻塞這個流，其他流不會受到影響。
我們拿一張圖看一下 HTTP 協(xié)議的變遷：
17.HTTP 如何實現(xiàn)長連接？在什么時候會超時？
什么是 HTTP 的長連接？
HTTP 分為長連接和短連接，本質(zhì)上說的是 TCP 的長短連接。TCP 連接是一個雙向的通道，它是可以保持一段時間不關(guān)閉的，因此 TCP 連接才具有真正的長連接和短連接這一說法。 TCP 長連接可以復(fù)用一個 TCP 連接，來發(fā)起多次的 HTTP 請求，這樣就可以減少資源消耗，比如一次請求 HTML，如果是短連接的話，可能還需要請求后續(xù)的 JS/CSS。
如何設(shè)置長連接？
通過在頭部（請求和響應(yīng)頭）設(shè)置 Connection 字段指定為keep-alive，HTTP/1.0 協(xié)議支持，但是是默認(rèn)關(guān)閉的，從 HTTP/1.1 以后，連接默認(rèn)都是長連接。
在什么時候會超時呢？
HTTP 一般會有 httpd 守護(hù)進(jìn)程，里面可以設(shè)置 keep-alive timeout，當(dāng) tcp 連接閑置超過這個時間就會關(guān)閉，也可以在 HTTP 的 header 里面設(shè)置超時時間 TCP 的 keep-alive 包含三個參數(shù)，支持在系統(tǒng)內(nèi)核的 net.ipv4 里面設(shè)置；當(dāng) TCP 連接之后，閑置了 tcp_keepalive_time，則會發(fā)生偵測包，如果沒有收到對方的 ACK，那么會每隔 tcp_keepalive_intvl 再發(fā)一次，直到發(fā)送了 tcp_keepalive_probes，就會丟棄該連接。
1. tcp_keepalive_intvl = 15
2. tcp_keepalive_probes = 5
3. tcp_keepalive_time = 1800
18.說說 HTTP 與 HTTPS 有哪些區(qū)別？
HTTP 是超?本傳輸協(xié)議，信息是明?傳輸，存在安全?險的問題。HTTPS 則解決 HTTP 不安全的缺陷，在 TCP 和 HTTP ?絡(luò)層之間加?了 SSL/TLS 安全協(xié)議，使得報?能夠加密傳輸。 HTTP 連接建?相對簡單， TCP 三次握?之后便可進(jìn)? HTTP 的報?傳輸。? HTTPS 在 TCP 三次握?之后，還需進(jìn)? SSL/TLS 的握?過程，才可進(jìn)?加密報?傳輸。 HTTP 的端?號是 80，HTTPS 的端?號是 443。 HTTPS 協(xié)議需要向 CA（證書權(quán)威機(jī)構(gòu)）申請數(shù)字證書，來保證服務(wù)器的身份是可信的。
19.為什么要用 HTTPS？解決了哪些問題？
因為 HTTP 是明?傳輸，存在安全上的風(fēng)險：
竊聽?險，?如通信鏈路上可以獲取通信內(nèi)容，用戶賬號被盜。
篡改?險，?如強(qiáng)制植?垃圾?告，視覺污染。
冒充?險，?如冒充淘寶?站，用戶金錢損失。
所以引入了 HTTPS，HTTPS 在 HTTP 與 TCP 層之間加?了 SSL/TLS 協(xié)議，可以很好的解決了這些風(fēng)險：
信息加密：交互信息?法被竊取。 校驗機(jī)制：?法篡改通信內(nèi)容，篡改了就不能正常顯示。 身份證書：能證明淘寶是真淘寶。
所以 SSL/TLS 協(xié)議是能保證通信是安全的。
20.HTTPS 工作流程是怎樣的？
這道題有幾個要點(diǎn)：公私鑰、數(shù)字證書、加密、對稱加密、非對稱加密。
HTTPS 主要工作流程：
客戶端發(fā)起 HTTPS 請求，連接到服務(wù)端的 443 端口。 服務(wù)端有一套數(shù)字證書（證書內(nèi)容有公鑰、證書頒發(fā)機(jī)構(gòu)、失效日期等）。 服務(wù)端將自己的數(shù)字證書發(fā)送給客戶端（公鑰在證書里面，私鑰由服務(wù)器持有）。 客戶端收到數(shù)字證書之后，會驗證證書的合法性。如果證書驗證通過，就會生成一個隨機(jī)的對稱密鑰，用證書的公鑰加密。 客戶端將公鑰加密后的密鑰發(fā)送到服務(wù)器。 服務(wù)器接收到客戶端發(fā)來的密文密鑰之后，用自己之前保留的私鑰對其進(jìn)行非對稱解密，解密之后就得到客戶端的密鑰，然后用客戶端密鑰對返回數(shù)據(jù)進(jìn)行對稱加密，醬紫傳輸?shù)臄?shù)據(jù)都是密文啦。 服務(wù)器將加密后的密文返回到客戶端。 客戶端收到后，用自己的密鑰對其進(jìn)行對稱解密，得到服務(wù)器返回的數(shù)據(jù)。
這里還畫了一張更詳盡的圖：
21.客戶端怎么去校驗證書的合法性？
首先，服務(wù)端的證書從哪來的呢？
為了讓服務(wù)端的公鑰被?家信任，服務(wù)端的證書都是由 CA （_Certificate Authority_，證書認(rèn)證機(jī)構(gòu)）簽名的，CA 就是?絡(luò)世界?的公安局、公證中?，具有極?的可信度，所以由它來給各個公鑰簽名，信任的??簽發(fā)的證書，那必然證書也是被信任的。
CA 簽發(fā)證書的過程，如上圖左邊部分：
?先 CA 會把持有者的公鑰、?途、頒發(fā)者、有效時間等信息打成?個包，然后對這些信息進(jìn)? Hash 計算，得到?個 Hash 值； 然后 CA 會使???的私鑰將該 Hash 值加密，?成 Certificate Signature，也就是 CA 對證書做了簽名； 最后將 Certificate Signature 添加在?件證書上，形成數(shù)字證書；
客戶端校驗服務(wù)端的數(shù)字證書的過程，如上圖右邊部分：
?先客戶端會使?同樣的 Hash 算法獲取該證書的 Hash 值 H1； 通常瀏覽器和操作系統(tǒng)中集成了 CA 的公鑰信息，瀏覽器收到證書后可以使? CA 的公鑰解密 Certificate Signature 內(nèi)容，得到?個 Hash 值 H2 ； 最后?較 H1 和 H2，如果值相同，則為可信賴的證書，否則則認(rèn)為證書不可信。
假如在 HTTPS 的通信過程中，中間人篡改了證書原文，由于他沒有 CA 機(jī)構(gòu)的私鑰，所以 CA 公鑰解密的內(nèi)容就不一致。
22.如何理解 HTTP 協(xié)議是無狀態(tài)的？
這個無狀態(tài)的的狀態(tài)值的是什么？是客戶端的狀態(tài)，所以字面意思，就是 HTTP 協(xié)議中服務(wù)端不會保存客戶端的任何信息。
比如當(dāng)瀏覽器第一次發(fā)送請求給服務(wù)器時，服務(wù)器響應(yīng)了；如果同個瀏覽器發(fā)起第二次請求給服務(wù)器時，它還是會響應(yīng)，但是呢，服務(wù)器不知道你就是剛才的那個瀏覽器。
那有什么辦法記錄狀態(tài)呢？
主要有兩個辦法，Session 和 Cookie。
23.說說 Session 和 Cookie 有什么聯(lián)系和區(qū)別?
先來看看什么是 Session 和 Cookie ：
Cookie 是保存在客戶端的一小塊文本串的數(shù)據(jù)?？蛻舳讼蚍?wù)器發(fā)起請求時，服務(wù)端會向客戶端發(fā)送一個 Cookie，客戶端就把 Cookie 保存起來。在客戶端下次向同一服務(wù)器再發(fā)起請求時，Cookie 被攜帶發(fā)送到服務(wù)器。服務(wù)端可以根據(jù)這個 Cookie 判斷用戶的身份和狀態(tài)。 Session 指的就是服務(wù)器和客戶端一次會話的過程。它是另一種記錄客戶狀態(tài)的機(jī)制。不同的是 cookie 保存在客戶端瀏覽器中，而 session 保存在服務(wù)器上。客戶端瀏覽器訪問服務(wù)器的時候，服務(wù)器把客戶端信息以某種形式記錄在服務(wù)器上，這就是 session?？蛻舳藶g覽器再次訪問時只需要從該 session 中查找用戶的狀態(tài)。
Session 和 Cookie 到底有什么不同呢？
存儲位置不一樣，Cookie 保存在客戶端，Session 保存在服務(wù)器端。 存儲數(shù)據(jù)類型不一樣，Cookie 只能保存 ASCII，Session 可以存任意數(shù)據(jù)類型，一般情況下我們可以在 Session 中保持一些常用變量信息，比如說 UserId 等。 有效期不同，Cookie 可設(shè)置為長時間保持，比如我們經(jīng)常使用的默認(rèn)登錄功能，Session 一般有效時間較短，客戶端關(guān)閉或者 Session 超時都會失效。 隱私策略不同，Cookie 存儲在客戶端，比較容易遭到不法獲取，早期有人將用戶的登錄名和密碼存儲在 Cookie 中導(dǎo)致信息被竊??；Session 存儲在服務(wù)端，安全性相對 Cookie 要好一些。 存儲大小不同， 單個 Cookie 保存的數(shù)據(jù)不能超過 4K，Session 可存儲數(shù)據(jù)遠(yuǎn)高于 Cookie。
Session 和 Cookie 有什么關(guān)聯(lián)呢？
可以使用 Cookie 記錄 Session 的標(biāo)識。
用戶第一次請求服務(wù)器時，服務(wù)器根據(jù)用戶提交的信息，創(chuàng)建對應(yīng)的 Session，請求返回時將此 Session 的唯一標(biāo)識信息 SessionID 返回給瀏覽器，瀏覽器接收到服務(wù)器返回的 SessionID 信息后，會將此信息存入 Cookie 中，同時 Cookie 記錄此 SessionID 是屬于哪個域名。 當(dāng)用戶第二次訪問服務(wù)器時，請求會自動判斷此域名下是否存在 Cookie 信息，如果存在，則自動將 Cookie 信息也發(fā)送給服務(wù)端，服務(wù)端會從 Cookie 中獲取 SessionID，再根據(jù) SessionID 查找對應(yīng)的 Session 信息，如果沒有找到，說明用戶沒有登錄或者登錄失效，如果找到 Session 證明用戶已經(jīng)登錄可執(zhí)行后面操作。
分布式環(huán)境下 Session 怎么處理呢？
分布式環(huán)境下，客戶端請求經(jīng)過負(fù)載均衡，可能會分配到不同的服務(wù)器上，假如一個用戶的請求兩次沒有落到同一臺服務(wù)器上，那么在新的服務(wù)器上就沒有記錄用戶狀態(tài)的 Session。
這時候怎么辦呢？
可以使用 Redis 等分布式緩存來存儲 Session，在多臺服務(wù)器之間共享。
客戶端無法使用 Cookie 怎么辦？
有可能客戶端無法使用 Cookie，比如瀏覽器禁用 Cookie，或者客戶端是安卓、IOS 等等。
這時候怎么辦？SessionID 怎么存？怎么傳給服務(wù)端呢？
首先是 SessionID 的存儲，可以使用客戶端的本地存儲，比如瀏覽器的 sessionStorage。
接下來怎么傳呢？
拼接到 URL 里：直接把 SessionID 作為 URL 的請求參數(shù) 放到請求頭里：把 SessionID 放到請求的 Header 里，比較常用。
TCP
24.詳細(xì)說一下 TCP 的三次握手機(jī)制
PS:TCP 三次握手是最重要的知識點(diǎn)，一定要熟悉到問到即送分。
TCP 提供面向連接的服務(wù)，在傳送數(shù)據(jù)前必須建立連接，TCP 連接是通過三次握手建立的。
三次握手的過程：
最開始，客戶端和服務(wù)端都處于 CLOSE 狀態(tài)，服務(wù)端監(jiān)聽客戶端的請求，進(jìn)入 LISTEN 狀態(tài)
客戶端端發(fā)送連接請求，第一次握手 (SYN=1, seq=x)，發(fā)送完畢后，客戶端就進(jìn)入 SYN_SENT 狀態(tài)
服務(wù)端確認(rèn)連接，第二次握手 (SYN=1, ACK=1, seq=y, ACKnum=x+1)， 發(fā)送完畢后，服務(wù)器端就進(jìn)入 SYN_RCV 狀態(tài)。
客戶端收到服務(wù)端的確認(rèn)之后，再次向服務(wù)端確認(rèn)，這就是**第三次握手 **(ACK=1，ACKnum=y+1)，發(fā)送完畢后，客戶端進(jìn)入 ESTABLISHED 狀態(tài)，當(dāng)服務(wù)器端接收到這個包時，也進(jìn)入 ESTABLISHED 狀態(tài)。
TCP 三次握手通俗比喻：
在二十年前的農(nóng)村，電話沒有普及，手機(jī)就更不用說了，所以，通信基本靠吼。
老張和老王是鄰居，這天老張下地了，結(jié)果家里有事，熱心的鄰居老王趕緊跑到村口，開始叫喚老王。
老王：老張唉！我是老王，你能聽到嗎？ 老張一聽，是老王的聲音：老王老王，我是老張，我能聽到，你能聽到嗎？ 老王一聽，嗯，沒錯，是老張：老張，我聽到了，我有事要跟你說。
"你老婆要生了，趕緊回家吧！"
老張風(fēng)風(fēng)火火地趕回家，老婆順利地生了個帶把的大胖小子。握手的故事充滿了幸福和美滿。
25.TCP 握手為什么是三次，為什么不能是兩次？不能是四次？
為什么不能是兩次？
為了防止服務(wù)器端開啟一些無用的連接增加服務(wù)器開銷 防止已失效的連接請求報文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯誤。
由于網(wǎng)絡(luò)傳輸是有延時的(要通過網(wǎng)絡(luò)光纖和各種中間代理服務(wù)器)，在傳輸?shù)倪^程中，比如客戶端發(fā)起了 SYN=1 的第一次握手。
如果服務(wù)器端就直接創(chuàng)建了這個連接并返回包含 SYN、ACK 和 Seq 等內(nèi)容的數(shù)據(jù)包給客戶端，這個數(shù)據(jù)包因為網(wǎng)絡(luò)傳輸?shù)脑騺G失了，丟失之后客戶端就一直沒有接收到服務(wù)器返回的數(shù)據(jù)包。
如果沒有第三次握手告訴服務(wù)器端客戶端收的到服務(wù)器端傳輸?shù)臄?shù)據(jù)的話，服務(wù)器端是不知道客戶端有沒有接收到服務(wù)器端返回的信息的。
服務(wù)端就認(rèn)為這個連接是可用的，端口就一直開著，等到客戶端因超時重新發(fā)出請求時，服務(wù)器就會重新開啟一個端口連接。這樣一來，就會有很多無效的連接端口白白地開著，導(dǎo)致資源的浪費(fèi)。
還有一種情況是已經(jīng)失效的客戶端發(fā)出的請求信息，由于某種原因傳輸?shù)搅朔?wù)器端，服務(wù)器端以為是客戶端發(fā)出的有效請求，接收后產(chǎn)生錯誤。
所以我們需要“第三次握手”來確認(rèn)這個過程：
通過第三次握手的數(shù)據(jù)告訴服務(wù)端，客戶端有沒有收到服務(wù)器“第二次握手”時傳過去的數(shù)據(jù)，以及這個連接的序號是不是有效的。若發(fā)送的這個數(shù)據(jù)是“收到且沒有問題”的信息，接收后服務(wù)器就正常建立 TCP 連接，否則建立 TCP 連接失敗，服務(wù)器關(guān)閉連接端口。由此減少服務(wù)器開銷和接收到失效請求發(fā)生的錯誤。
為什么不是四次？
簡單說，就是三次揮手已經(jīng)足夠創(chuàng)建可靠的連接，沒有必要再多一次握手導(dǎo)致花費(fèi)更多的時間建立連接。
26.三次握手中每一次沒收到報文會發(fā)生什么情況？
第一次握手服務(wù)端未收到 SYN 報文
服務(wù)端不會進(jìn)行任何的動作，而客戶端由于一段時間內(nèi)沒有收到服務(wù)端發(fā)來的確認(rèn)報文，等待一段時間后會重新發(fā)送 SYN 報文，如果仍然沒有回應(yīng)，會重復(fù)這個過程，直到發(fā)送次數(shù)超過最大重傳次數(shù)限制，就會返回連接建立失敗。
第二次握手客戶端未收到服務(wù)端響應(yīng)的 ACK 報文
客戶端會繼續(xù)重傳，直到次數(shù)限制；而服務(wù)端此時會阻塞在 accept()處，等待客戶端發(fā)送 ACK 報文
第三次握手服務(wù)端為收到客戶端發(fā)送過來的 ACK 報文
服務(wù)端同樣會采用類似客戶端的超時重傳機(jī)制，如果重試次數(shù)超過限制，則 accept()調(diào)用返回-1，服務(wù)端建立連接失?。欢藭r客戶端認(rèn)為自己已經(jīng)建立連接成功，因此開始向服務(wù)端發(fā)送數(shù)據(jù)，但是服務(wù)端的 accept()系統(tǒng)調(diào)用已經(jīng)返回，此時不在監(jiān)聽狀態(tài)，因此服務(wù)端接收到客戶端發(fā)送來的數(shù)據(jù)時會發(fā)送 RST 報文給客戶端，消除客戶端單方面建立連接的狀態(tài)。
27.第二次握手傳回了 ACK，為什么還要傳回 SYN？
ACK 是為了告訴客戶端傳來的數(shù)據(jù)已經(jīng)接收無誤。
而傳回 SYN 是為了告訴客戶端，服務(wù)端響應(yīng)的確實是客戶端發(fā)送的報文。
28.第 3 次握手可以攜帶數(shù)據(jù)嗎？
第 3 次握手是可以攜帶數(shù)據(jù)的。
此時客戶端已經(jīng)處于 ESTABLISHED 狀態(tài)。對于客戶端來說，它已經(jīng)建立連接成功，并且確認(rèn)服務(wù)端的接收和發(fā)送能力是正常的。
第一次握手不能攜帶數(shù)據(jù)是出于安全的考慮，因為如果允許攜帶數(shù)據(jù)，攻擊者每次在 SYN 報文中攜帶大量數(shù)據(jù)，就會導(dǎo)致服務(wù)端消耗更多的時間和空間去處理這些報文，會造成 CPU 和內(nèi)存的消耗。
29.說說半連接隊列和 SYN Flood 攻擊的關(guān)系？
什么是半連接隊列？
TCP 進(jìn)入三次握手前，服務(wù)端會從 CLOSED 狀態(tài)變?yōu)?LISTEN 狀態(tài), 同時在內(nèi)部創(chuàng)建了兩個隊列：半連接隊列（SYN 隊列）和全連接隊列（ACCEPT 隊列）。
顧名思義，半連接隊列存放的是三次握手未完成的連接，全連接隊列存放的是完成三次握手的連接。
TCP 三次握手時，客戶端發(fā)送 SYN 到服務(wù)端，服務(wù)端收到之后，便回復(fù) ACK 和 SYN，狀態(tài)由 LISTEN 變?yōu)?SYN_RCVD，此時這個連接就被推入了 SYN 隊列，即半連接隊列。 當(dāng)客戶端回復(fù) ACK, 服務(wù)端接收后，三次握手就完成了。這時連接會等待被具體的應(yīng)用取走，在被取走之前，它被推入 ACCEPT 隊列，即全連接隊列。
什么是 SYN Flood ？
SYN Flood 是一種典型的 DDos 攻擊，它在短時間內(nèi)，偽造不存在的 IP 地址, 向服務(wù)器發(fā)送大量 SYN 報文。當(dāng)服務(wù)器回復(fù) SYN+ACK 報文后，不會收到 ACK 回應(yīng)報文，那么 SYN 隊列里的連接舊不會出對隊，久?久之就會占滿服務(wù)端的 SYN 接收隊列（半連接隊列），使得服務(wù)器不能為正常?戶服務(wù)。
那有什么應(yīng)對方案呢？
主要有 syn cookie 和 SYN Proxy 防火墻等。
syn cookie：在收到 SYN 包后，服務(wù)器根據(jù)一定的方法，以數(shù)據(jù)包的源地址、端口等信息為參數(shù)計算出一個 cookie 值作為自己的 SYNACK 包的序列號，回復(fù) SYN+ACK 后，服務(wù)器并不立即分配資源進(jìn)行處理，等收到發(fā)送方的 ACK 包后，重新根據(jù)數(shù)據(jù)包的源地址、端口計算該包中的確認(rèn)序列號是否正確，如果正確則建立連接，否則丟棄該包。 SYN Proxy 防火墻：服務(wù)器防火墻會對收到的每一個 SYN 報文進(jìn)行代理和回應(yīng)，并保持半連接。等發(fā)送方將 ACK 包返回后，再重新構(gòu)造 SYN 包發(fā)到服務(wù)器，建立真正的 TCP 連接。
30.說說 TCP 四次揮手的過程？
PS：問完三次握手，常常也會順道問問四次揮手，所以也是必須掌握知識點(diǎn)。
TCP 四次揮手過程：
數(shù)據(jù)傳輸結(jié)束之后，通信雙方都可以主動發(fā)起斷開連接請求，這里假定客戶端發(fā)起 客戶端發(fā)送釋放連接報文，第一次揮手 (FIN=1，seq=u)，發(fā)送完畢后，客戶端進(jìn)入 FIN_WAIT_1 狀態(tài)。 服務(wù)端發(fā)送確認(rèn)報文，第二次揮手 (ACK=1，ack=u+1,seq =v)，發(fā)送完畢后，服務(wù)器端進(jìn)入 CLOSE_WAIT 狀態(tài)，客戶端接收到這個確認(rèn)包之后，進(jìn)入 FIN_WAIT_2 狀態(tài)。 服務(wù)端發(fā)送釋放連接報文，第三次揮手 (FIN=1，ACK1,seq=w,ack=u+1)，發(fā)送完畢后，服務(wù)器端進(jìn)入 LAST_ACK 狀態(tài)，等待來自客戶端的最后一個 ACK。 客戶端發(fā)送確認(rèn)報文，第四次揮手 (ACK=1，seq=u+1,ack=w+1)，客戶端接收到來自服務(wù)器端的關(guān)閉請求，發(fā)送一個確認(rèn)包，并進(jìn)入 TIME_WAIT 狀態(tài)，等待了某個固定時間（兩個最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，沒有收到服務(wù)器端的 ACK ，認(rèn)為服務(wù)器端已經(jīng)正常關(guān)閉連接，于是自己也關(guān)閉連接，進(jìn)入 CLOSED 狀態(tài)。服務(wù)器端接收到這個確認(rèn)包之后，關(guān)閉連接，進(jìn)入 CLOSED 狀態(tài)。
大白話說四次揮手：
假如單身狗博主有一個女朋友—由于博主上班九九六，下班肝博客，導(dǎo)致沒有時間陪女朋友，女朋友忍無可忍。
女朋友：狗男人，最近你都不理我，你是不是不愛我了？你是不是外面有別的狗子了？我要和你分手？ 沙雕博主一愣，怒火攻心：分手就分手，不陪你鬧了，等我把東西收拾收拾。
沙雕博主小心翼翼地裝起了自己的青軸機(jī)械鍵盤。
哼，蠢女人，我已經(jīng)收拾完了，我先滾為敬，再見！ 女朋友：滾，滾的遠(yuǎn)遠(yuǎn)的，越遠(yuǎn)越好，我一輩子都不想再見到你。
揮手的故事總充滿了悲傷和遺憾！
31.TCP 揮手為什么需要四次呢？
再來回顧下四次揮手雙方發(fā) FIN 包的過程，就能理解為什么需要四次了。
關(guān)閉連接時，客戶端向服務(wù)端發(fā)送 FIN時，僅僅表示客戶端不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)。服務(wù)端收到客戶端的 FIN報文時，先回一個ACK應(yīng)答報文，而服務(wù)端可能還有數(shù)據(jù)需要處理和發(fā)送，等服務(wù)端不再發(fā)送數(shù)據(jù)時，才發(fā)送FIN報文給客戶端來表示同意現(xiàn)在關(guān)閉連接。
從上面過程可知，服務(wù)端通常需要等待完成數(shù)據(jù)的發(fā)送和處理，所以服務(wù)端的 ACK 和 FIN 一般都會分開發(fā)送，從而比三次握手導(dǎo)致多了一次。
32.TCP 四次揮手過程中，為什么需要等待 2MSL, 才進(jìn)入 CLOSED 關(guān)閉狀態(tài)？
為什么需要等待？
1. 為了保證客戶端發(fā)送的最后一個 ACK 報文段能夠到達(dá)服務(wù)端。 這個 ACK 報文段有可能丟失，因而使處在 LAST-ACK 狀態(tài)的服務(wù)端就收不到對已發(fā)送的 FIN + ACK 報文段的確認(rèn)。服務(wù)端會超時重傳這個 FIN+ACK 報文段，而客戶端就能在 2MSL 時間內(nèi)（超時 + 1MSL 傳輸）收到這個重傳的 FIN+ACK 報文段。接著客戶端重傳一次確認(rèn)，重新啟動 2MSL 計時器。最后，客戶端和服務(wù)器都正常進(jìn)入到 CLOSED 狀態(tài)。
2. 防止已失效的連接請求報文段出現(xiàn)在本連接中?？蛻舳嗽诎l(fā)送完最后一個 ACK 報文段后，再經(jīng)過時間 2MSL，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失。這樣就可以使下一個連接中不會出現(xiàn)這種舊的連接請求報文段。
為什么等待的時間是 2MSL？
MSL 是 Maximum Segment Lifetime，報?最??存時間，它是任何報?在?絡(luò)上存在的最?時間，超過這個時間報?將被丟棄。
TIME_WAIT 等待 2 倍的 MSL，?較合理的解釋是：?絡(luò)中可能存在來?發(fā)送?的數(shù)據(jù)包，當(dāng)這些發(fā)送?的數(shù)據(jù)包被接收?處理后?會向?qū)?發(fā)送響應(yīng)，所以?來?回需要等待 2 倍的時間。
?如如果被動關(guān)閉?沒有收到斷開連接的最后的 ACK 報?，就會觸發(fā)超時重發(fā) Fin 報?，另??接收到 FIN 后，會重發(fā) ACK 給被動關(guān)閉?， ?來?去正好 2 個 MSL。
33.保活計時器有什么用？
除時間等待計時器外，TCP 還有一個保活計時器（keepalive timer）。
設(shè)想這樣的場景：客戶已主動與服務(wù)器建立了 TCP 連接。但后來客戶端的主機(jī)突然發(fā)生故障。顯然，服務(wù)器以后就不能再收到客戶端發(fā)來的數(shù)據(jù)。因此，應(yīng)當(dāng)有措施使服務(wù)器不要再白白等待下去。這就需要使用?；钣嫊r器了。
服務(wù)器每收到一次客戶端的數(shù)據(jù)，就重新設(shè)置?；钣嫊r器，時間的設(shè)置通常是兩個小時。若兩個小時都沒有收到客戶端的數(shù)據(jù)，服務(wù)端就發(fā)送一個探測報文段，以后則每隔 75 秒鐘發(fā)送一次。若連續(xù)發(fā)送 10 個探測報文段后仍然無客戶端的響應(yīng)，服務(wù)端就認(rèn)為客戶端出了故障，接著就關(guān)閉這個連接。
34.CLOSE-WAIT 和 TIME-WAIT 的狀態(tài)和意義？
CLOSE-WAIT 狀態(tài)有什么意義？
服務(wù)端收到客戶端關(guān)閉連接的請求并確認(rèn)之后，就會進(jìn)入 CLOSE-WAIT 狀態(tài)。此時服務(wù)端可能還有一些數(shù)據(jù)沒有傳輸完成，因此不能立即關(guān)閉連接，而 CLOSE-WAIT 狀態(tài)就是為了保證服務(wù)端在關(guān)閉連接之前將待發(fā)送的數(shù)據(jù)處理完。
TIME-WAIT 有什么意義？
TIME-WAIT 狀態(tài)發(fā)生在第四次揮手，當(dāng)客戶端向服務(wù)端發(fā)送 ACK 確認(rèn)報文后進(jìn)入 TIME-WAIT 狀態(tài)。
它存在的意義主要是兩個：
防?舊連接的數(shù)據(jù)包
如果客戶端收到服務(wù)端的 FIN 報文之后立即關(guān)閉連接，但是此時服務(wù)端對應(yīng)的端口并沒有關(guān)閉，如果客戶端在相同端口建立新的連接，可能會導(dǎo)致新連接收到舊連接殘留的數(shù)據(jù)包，導(dǎo)致不可預(yù)料的異常發(fā)生。
保證連接正確關(guān)閉
假設(shè)客戶端最后一次發(fā)送的 ACK 包在傳輸?shù)臅r候丟失了，由于 TCP 協(xié)議的超時重傳機(jī)制，服務(wù)端將重發(fā) FIN 報文，如果客戶端沒有維持 TIME-WAIT 狀態(tài)而直接關(guān)閉的話，當(dāng)收到服務(wù)端重新發(fā)送的 FIN 包時，客戶端就會使用 RST 包來響應(yīng)服務(wù)端，導(dǎo)致服務(wù)端以為有錯誤發(fā)生，然而實際關(guān)閉連接過程是正常的。
35.TIME_WAIT 狀態(tài)過多會導(dǎo)致什么問題？怎么解決？
TIME_WAIT 狀態(tài)過多會導(dǎo)致什么問題?
如果服務(wù)器有處于 TIME-WAIT 狀態(tài)的 TCP，則說明是由服務(wù)器?主動發(fā)起的斷開請求。
過多的 TIME-WAIT 狀態(tài)主要的危害有兩種：
第?是內(nèi)存資源占?；
第?是對端?資源的占?，?個 TCP 連接?少消耗?個本地端?；
怎么解決 TIME_WAIT 狀態(tài)過多？
服務(wù)器可以設(shè)置 SO_REUSEADDR 套接字來通知內(nèi)核，如果端口被占用，但是 TCP 連接位于 TIME_WAIT 狀態(tài)時可以重用端口。 還可以使用長連接的方式來減少 TCP 的連接和斷開，在長連接的業(yè)務(wù)里往往不需要考慮 TIME_WAIT 狀態(tài)。
36.說說 TCP 報文首部的格式？
看一下 TCP 報文首部的格式：
16 位端口號：源端口號，主機(jī)該報文段是來自哪里；目標(biāo)端口號，要傳給哪個上層協(xié)議或應(yīng)用程序 32 位序號：一次 TCP 通信（從 TCP 連接建立到斷開）過程中某一個傳輸方向上的字節(jié)流的每個字節(jié)的編號。 32 位確認(rèn)號：用作對另一方發(fā)送的 tcp 報文段的響應(yīng)。其值是收到的 TCP 報文段的序號值加 1。 4 位首部長度：表示 tcp 頭部有多少個 32bit 字（4 字節(jié)）。因為 4 位最大能標(biāo)識 15，所以 TCP 頭部最長是 60 字節(jié)。 6 位標(biāo)志位：URG(緊急指針是否有效)，ACk（表示確認(rèn)號是否有效），PST（緩沖區(qū)尚未填滿），RST（表示要求對方重新建立連接），SYN（建立連接消息標(biāo)志接），F(xiàn)IN（表示告知對方本端要關(guān)閉連接了） 16 位窗口大小：是 TCP 流量控制的一個手段。這里說的窗口，指的是接收通告窗口。它告訴對方本端的 TCP 接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù)，這樣對方就可以控制發(fā)送數(shù)據(jù)的速度。 16 位校驗和：由發(fā)送端填充，接收端對 TCP 報文段執(zhí)行 CRC 算法以檢驗 TCP 報文段在傳輸過程中是否損壞。注意，這個校驗不僅包括 TCP 頭部，也包括數(shù)據(jù)部分。這也是 TCP 可靠傳輸?shù)囊粋€重要保障。 16 位緊急指針：一個正的偏移量。它和序號字段的值相加表示最后一個緊急數(shù)據(jù)的下一字節(jié)的序號。因此，確切地說，這個字段是緊急指針相對當(dāng)前序號的偏移，不妨稱之為緊急偏移。TCP 的緊急指針是發(fā)送端向接收端發(fā)送緊急數(shù)據(jù)的方法。
37.TCP 是如何保證可靠性的？
TCP 主要提供了檢驗和、序列號/確認(rèn)應(yīng)答、超時重傳、最大消息長度、滑動窗口控制等方法實現(xiàn)了可靠性傳輸。
連接管理：TCP 使用三次握手和四次揮手保證可靠地建立連接和釋放連接，這里就不用多說了。 校驗和：TCP 將保持它首部和數(shù)據(jù)的檢驗和。這是一個端到端的檢驗和，目的是檢測數(shù)據(jù)在傳輸過程中的任何變化。如果接收端的檢驗和有差錯，TCP 將丟棄這個報文段和不確認(rèn)收到此報文段。
TCP 校驗和
序列號/確認(rèn)應(yīng)答：TCP 給發(fā)送的每一個包進(jìn)行編號，接收方會對收到的包進(jìn)行應(yīng)答，發(fā)送方就會知道接收方是否收到對應(yīng)的包，如果發(fā)現(xiàn)沒有收到，就會重發(fā)，這樣就能保證數(shù)據(jù)的完整性。就像老師上課，會問一句，這一章聽懂了嗎？沒聽懂再講一遍。
**流量控制：**TCP 連接的每一方都有固定大小的緩沖空間，TCP 的接收端只允許發(fā)送端發(fā)送接收端緩沖區(qū)能接納的數(shù)據(jù)。當(dāng)接收方來不及處理發(fā)送方的數(shù)據(jù)，能提示發(fā)送方降低發(fā)送的速率，防止包丟失。TCP 使用的流量控制協(xié)議是可變大小的滑動窗口協(xié)議。（TCP 利用滑動窗口實現(xiàn)流量控制）
最大消息長度：在建立 TCP 連接的時候，雙方約定一個最大的長度（MSS）作為發(fā)送的單位，重傳的時候也是以這個單位來進(jìn)行重傳。理想的情況下是該長度的數(shù)據(jù)剛好不被網(wǎng)絡(luò)層分塊。
**超時重傳：**超時重傳是指發(fā)送出去的數(shù)據(jù)包到接收到確認(rèn)包之間的時間，如果超過了這個時間會被認(rèn)為是丟包了，需要重傳。
**擁塞控制：**如果網(wǎng)絡(luò)非常擁堵，此時再發(fā)送數(shù)據(jù)就會加重網(wǎng)絡(luò)負(fù)擔(dān)，那么發(fā)送的數(shù)據(jù)段很可能超過了最大生存時間也沒有到達(dá)接收方，就會產(chǎn)生丟包問題。為此 TCP 引入慢啟動機(jī)制，先發(fā)出少量數(shù)據(jù)，就像探路一樣，先摸清當(dāng)前的網(wǎng)絡(luò)擁堵狀態(tài)后，再決定按照多大的速度傳送數(shù)據(jù)。
38.說說 TCP 的流量控制？
TCP 提供了一種機(jī)制，可以讓發(fā)送端根據(jù)接收端的實際接收能力控制發(fā)送的數(shù)據(jù)量，這就是流量控制。
TCP 通過滑動窗口來控制流量，我們看下簡要流程：
首先雙方三次握手，初始化各自的窗口大小，均為 400 個字節(jié)。
假如當(dāng)前發(fā)送方給接收方發(fā)送了 200 個字節(jié)，那么，發(fā)送方的 SND.NXT會右移 200 個字節(jié)，也就是說當(dāng)前的可用窗口減少了 200 個字節(jié)。接受方收到后，放到緩沖隊列里面，REV.WND =400-200=200 字節(jié)，所以 win=200 字節(jié)返回給發(fā)送方。接收方會在 ACK 的報文首部帶上縮小后的滑動窗口 200 字節(jié) 發(fā)送方又發(fā)送 200 字節(jié)過來，200 字節(jié)到達(dá)，繼續(xù)放到緩沖隊列。不過這時候，由于大量負(fù)載的原因，接受方處理不了這么多字節(jié)，只能處理 100 字節(jié)，剩余的 100 字節(jié)繼續(xù)放到緩沖隊列。這時候，REV.WND = 400-200-100=100 字節(jié)，即 win=100 返回發(fā)送方。 發(fā)送方繼續(xù)發(fā)送 100 字節(jié)過來，這時候，接收窗口 win 變?yōu)?0。 發(fā)送方停止發(fā)送，開啟一個定時任務(wù)，每隔一段時間，就去詢問接受方，直到 win 大于 0，才繼續(xù)開始發(fā)送。
39.詳細(xì)說說 TCP 的滑動窗口？
TCP 發(fā)送一個數(shù)據(jù)，如果需要收到確認(rèn)應(yīng)答，才會發(fā)送下一個數(shù)據(jù)。這樣的話就會有個缺點(diǎn)：效率會比較低。
“用一個比喻，我們在微信上聊天，你打完一句話，我回復(fù)一句之后，你才能打下一句。假如我沒有及時回復(fù)呢？你是把話憋著不說嗎？然后傻傻等到我回復(fù)之后再接著發(fā)下一句？”
為了解決這個問題，TCP 引入了窗口，它是操作系統(tǒng)開辟的一個緩存空間。窗口大小值表示無需等待確認(rèn)應(yīng)答，而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值。
TCP 頭部有個字段叫 win，也即那個 16 位的窗口大小，它告訴對方本端的 TCP 接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù)，這樣對方就可以控制發(fā)送數(shù)據(jù)的速度，從而達(dá)到流量控制的目的。
“通俗點(diǎn)講，就是接受方每次收到數(shù)據(jù)包，在發(fā)送確認(rèn)報文的時候，同時告訴發(fā)送方，自己的緩存區(qū)還有多少空余空間，緩沖區(qū)的空余空間，我們就稱之為接受窗口大小。這就是 win?！?/p>
TCP 滑動窗口分為兩種: 發(fā)送窗口和接收窗口。發(fā)送端的滑動窗口包含四大部分，如下：
已發(fā)送且已收到 ACK 確認(rèn) 已發(fā)送但未收到 ACK 確認(rèn) 未發(fā)送但可以發(fā)送 未發(fā)送也不可以發(fā)送
深藍(lán)色框里就是發(fā)送窗口。 SND.WND: 表示發(fā)送窗口的大小, 上圖虛線框的格子數(shù)是 10 個，即發(fā)送窗口大小是 10。 SND.NXT：下一個發(fā)送的位置，它指向未發(fā)送但可以發(fā)送的第一個字節(jié)的序列號。 SND.UNA: 一個絕對指針，它指向的是已發(fā)送但未確認(rèn)的第一個字節(jié)的序列號。
接收方的滑動窗口包含三大部分，如下：
已成功接收并確認(rèn) 未收到數(shù)據(jù)但可以接收 未收到數(shù)據(jù)并不可以接收的數(shù)據(jù)
藍(lán)色框內(nèi)，就是接收窗口。 REV.WND: 表示接收窗口的大小, 上圖虛線框的格子就是 9 個。 REV.NXT: 下一個接收的位置，它指向未收到但可以接收的第一個字節(jié)的序列號。
40.了解 Nagle 算法和延遲確認(rèn)嗎？
Nagle 算法和延遲確認(rèn)是干什么的？
當(dāng)我們 TCP 報?的承載的數(shù)據(jù)?常?的時候，例如?個字節(jié)，那么整個?絡(luò)的效率是很低的，因為每個 TCP 報?中都會有 20 個字節(jié)的 TCP 頭部，也會有 20 個字節(jié)的 IP 頭部，?數(shù)據(jù)只有?個字節(jié)，所以在整個報?中有效數(shù)據(jù)占有的比例就會?常低。
這就好像快遞員開著?貨?送?個?包裹?樣浪費(fèi)。
那么就出現(xiàn)了常?的兩種策略，來減少?報?的傳輸，分別是：
Nagle 算法 延遲確認(rèn)
Nagle 算法
Nagle 算法：任意時刻，最多只能有一個未被確認(rèn)的小段。所謂 “小段”，指的是小于 MSS 尺寸的數(shù)據(jù)塊，所謂 “未被確認(rèn)”，是指一個數(shù)據(jù)塊發(fā)送出去后，沒有收到對方發(fā)送的 ACK 確認(rèn)該數(shù)據(jù)已收到。
Nagle 算法的策略：
沒有已發(fā)送未確認(rèn)報?時，?刻發(fā)送數(shù)據(jù)。 存在未確認(rèn)報?時，直到「沒有已發(fā)送未確認(rèn)報?」或「數(shù)據(jù)?度達(dá)到 MSS ??」時，再發(fā)送數(shù)據(jù)。
只要沒滿?上?條件中的?條，發(fā)送??直在囤積數(shù)據(jù)，直到滿?上?的發(fā)送條件。
延遲確認(rèn)
事實上當(dāng)沒有攜帶數(shù)據(jù)的 ACK，它的?絡(luò)效率也是很低的，因為它也有 40 個字節(jié)的 IP 頭 和 TCP 頭，但卻沒有攜帶數(shù)據(jù)報?。
為了解決 ACK 傳輸效率低問題，所以就衍?出了 TCP 延遲確認(rèn)。
TCP 延遲確認(rèn)的策略：
當(dāng)有響應(yīng)數(shù)據(jù)要發(fā)送時，ACK 會隨著響應(yīng)數(shù)據(jù)?起?刻發(fā)送給對? 當(dāng)沒有響應(yīng)數(shù)據(jù)要發(fā)送時，ACK 將會延遲?段時間，以等待是否有響應(yīng)數(shù)據(jù)可以?起發(fā)送 如果在延遲等待發(fā)送 ACK 期間，對?的第?個數(shù)據(jù)報??到達(dá)了，這時就會?刻發(fā)送 ACK
一般情況下，Nagle 算法和延遲確認(rèn)不能一起使用，Nagle 算法意味著延遲發(fā)，延遲確認(rèn)意味著延遲接收，兩個湊在一起就會造成更大的延遲，會產(chǎn)生性能問題。
41.說說 TCP 的擁塞控制？
什么是擁塞控制？不是有了流量控制嗎？
前?的流量控制是避免發(fā)送?的數(shù)據(jù)填滿接收?的緩存，但是并不知道整個?絡(luò)之中發(fā)?了什么。
?般來說，計算機(jī)?絡(luò)都處在?個共享的環(huán)境。因此也有可能會因為其他主機(jī)之間的通信使得?絡(luò)擁堵。
在?絡(luò)出現(xiàn)擁堵時，如果繼續(xù)發(fā)送?量數(shù)據(jù)包，可能會導(dǎo)致數(shù)據(jù)包時延、丟失等，這時 TCP 就會重傳數(shù)據(jù)，但是?重傳就會導(dǎo)致?絡(luò)的負(fù)擔(dān)更重，于是會導(dǎo)致更?的延遲以及更多的丟包，這個情況就會進(jìn)?惡性循環(huán)被不斷地放?....
所以，TCP 不能忽略整個網(wǎng)絡(luò)中發(fā)?的事，它被設(shè)計成?個?私的協(xié)議，當(dāng)?絡(luò)發(fā)送擁塞時，TCP 會?我犧牲，降低發(fā)送的數(shù)據(jù)流。
于是，就有了擁塞控制，控制的?的就是避免發(fā)送?的數(shù)據(jù)填滿整個?絡(luò)。
就像是一個水管，不能讓太多的水（數(shù)據(jù)流）流入水管，如果超過水管的承受能力，水管會被撐爆（丟包）。
發(fā)送方維護(hù)一個擁塞窗口 cwnd（congestion window） 的變量，調(diào)節(jié)所要發(fā)送數(shù)據(jù)的量。
什么是擁塞窗?？和發(fā)送窗?有什么關(guān)系呢？
擁塞窗? cwnd是發(fā)送?維護(hù)的?個的狀態(tài)變量，它會根據(jù)?絡(luò)的擁塞程度動態(tài)變化的。
發(fā)送窗? swnd 和接收窗? rwnd 是約等于的關(guān)系，那么由于加?了擁塞窗?的概念后，此時發(fā)送窗?的值是 swnd = min(cwnd, rwnd)，也就是擁塞窗?和接收窗?中的最?值。
擁塞窗? cwnd 變化的規(guī)則：
只要?絡(luò)中沒有出現(xiàn)擁塞， cwnd 就會增?； 但?絡(luò)中出現(xiàn)了擁塞， cwnd 就減少；
擁塞控制有哪些常用算法？
擁塞控制主要有這幾種常用算法：
慢啟動 擁塞避免 擁塞發(fā)生 快速恢復(fù)
慢啟動算法
慢啟動算法，慢慢啟動。
它表示 TCP 建立連接完成后，一開始不要發(fā)送大量的數(shù)據(jù)，而是先探測一下網(wǎng)絡(luò)的擁塞程度。由小到大逐漸增加擁塞窗口的大小，如果沒有出現(xiàn)丟包，每收到一個 ACK，就將擁塞窗口 cwnd 大小就加 1（單位是 MSS）。每輪次發(fā)送窗口增加一倍，呈指數(shù)增長，如果出現(xiàn)丟包，擁塞窗口就減半，進(jìn)入擁塞避免階段。
舉個例子：
連接建?完成后，?開始初始化 cwnd = 1 ，表示可以傳?個 MSS ??的數(shù)據(jù)。 當(dāng)收到?個 ACK 確認(rèn)應(yīng)答后，cwnd 增加 1，于是?次能夠發(fā)送 2 個 當(dāng)收到 2 個的 ACK 確認(rèn)應(yīng)答后， cwnd 增加 2，于是就可以?之前多發(fā) 2 個，所以這?次能夠發(fā)送 4 個 當(dāng)這 4 個的 ACK 確認(rèn)到來的時候，每個確認(rèn) cwnd 增加 1， 4 個確認(rèn) cwnd 增加 4，于是就可以?之前多發(fā) 4 個，所以這?次能夠發(fā)送 8 個。
發(fā)包的個數(shù)是指數(shù)性的增?。
為了防止 cwnd 增長過大引起網(wǎng)絡(luò)擁塞，還需設(shè)置一個慢啟動閥值 ssthresh（slow start threshold）狀態(tài)變量。當(dāng)cwnd到達(dá)該閥值后，就好像水管被關(guān)小了水龍頭一樣，減少擁塞狀態(tài)。即當(dāng) cwnd >ssthresh 時，進(jìn)入了擁塞避免算法。
擁塞避免算法
一般來說，慢啟動閥值 ssthresh 是 65535 字節(jié)，cwnd到達(dá)慢啟動閥值后
每收到一個 ACK 時，cwnd = cwnd + 1/cwnd 當(dāng)每過一個 RTT 時，cwnd = cwnd + 1
顯然這是一個線性上升的算法，避免過快導(dǎo)致網(wǎng)絡(luò)擁塞問題。
接著上面慢啟動的例子，假定 ssthresh 為 8 ：：
當(dāng) 8 個 ACK 應(yīng)答確認(rèn)到來時，每個確認(rèn)增加 1/8，8 個 ACK 確認(rèn) cwnd ?共增加 1，于是這?次能夠發(fā)送 9 個 MSS ??的數(shù)據(jù)，變成了線性增?。
擁塞發(fā)生
當(dāng)網(wǎng)絡(luò)擁塞發(fā)生丟包時，會有兩種情況：
RTO 超時重傳 快速重傳
如果是發(fā)生了 RTO 超時重傳，就會使用擁塞發(fā)生算法
慢啟動閥值 sshthresh = cwnd /2 cwnd 重置為 1 進(jìn)入新的慢啟動過程
這種方式就像是飆車的時候急剎車，還飛速倒車，這。。。
其實還有更好的處理方式，就是快速重傳。發(fā)送方收到 3 個連續(xù)重復(fù)的 ACK 時，就會快速地重傳，不必等待 RTO 超時再重傳。
發(fā)?快速重傳的擁塞發(fā)?算法：
擁塞窗口大小 cwnd = cwnd/2 慢啟動閥值 ssthresh = cwnd 進(jìn)入快速恢復(fù)算法
快速恢復(fù)
快速重傳和快速恢復(fù)算法一般同時使用。快速恢復(fù)算法認(rèn)為，還有 3 個重復(fù) ACK 收到，說明網(wǎng)絡(luò)也沒那么糟糕，所以沒有必要像 RTO 超時那么強(qiáng)烈。
正如前面所說，進(jìn)入快速恢復(fù)之前，cwnd 和 sshthresh 已被更新：
cwnd = cwnd /2
- sshthresh = cwnd
然后，進(jìn)?快速恢復(fù)算法如下：
cwnd = sshthresh + 3 重傳重復(fù)的那幾個 ACK（即丟失的那幾個數(shù)據(jù)包） 如果再收到重復(fù)的 ACK，那么 cwnd = cwnd +1 如果收到新數(shù)據(jù)的 ACK 后, cwnd = sshthresh。因為收到新數(shù)據(jù)的 ACK，表明恢復(fù)過程已經(jīng)結(jié)束，可以再次進(jìn)入了擁塞避免的算法了。
42.說說 TCP 的重傳機(jī)制？
重傳包括超時重傳、快速重傳、帶選擇確認(rèn)的重傳（SACK）、重復(fù) SACK 四種。
超時重傳
超時重傳，是 TCP 協(xié)議保證數(shù)據(jù)可靠性的另一個重要機(jī)制，其原理是在發(fā)送某一個數(shù)據(jù)以后就開啟一個計時器，在一定時間內(nèi)如果沒有得到發(fā)送的數(shù)據(jù)報的 ACK 報文，那么就重新發(fā)送數(shù)據(jù)，直到發(fā)送成功為止。
超時時間應(yīng)該設(shè)置為多少呢？
先來看下什么叫 RTT（Round-Trip Time，往返時間）。
RTT 就是數(shù)據(jù)完全發(fā)送完，到收到確認(rèn)信號的時間，即數(shù)據(jù)包的一次往返時間。
超時重傳時間，就是 RTO（Retransmission Timeout)。那么，RTO 到底設(shè)置多大呢？
如果 RTO 設(shè)置很大，等了很久都沒重發(fā)，這樣肯定就不行。 如果 RTO 設(shè)置很小，那很可能數(shù)據(jù)都沒有丟失，就開始重發(fā)了，這會導(dǎo)致網(wǎng)絡(luò)阻塞，從而惡性循環(huán)，導(dǎo)致更多的超時出現(xiàn)。
一般來說，RTO 略微大于 RTT，效果是最佳的。
其實，RTO 有個標(biāo)準(zhǔn)方法的計算公式，也叫 Jacobson / Karels 算法。
首先計算 SRTT（即計算平滑的 RTT）
SRTT = (1 - α) * SRTT + α * RTT //求 SRTT 的加權(quán)平均
其次，計算 RTTVAR (round-trip time variation)
RTTVAR = (1 - β) * RTTVAR + β * (|RTT - SRTT|) //計算 SRTT 與真實值的差距
最后，得出最終的 RTO
RTO = μ * SRTT + ? * RTTVAR = SRTT + 4·RTTVAR
在 Linux 下，α = 0.125，β = 0.25， μ = 1，? = 4。別問這些參數(shù)是怎么來的，它們是大量實踐，調(diào)出的最優(yōu)參數(shù)。
超時重傳不是十分完美的重傳方案，它有這些缺點(diǎn)：
當(dāng)一個報文丟失時，會等待一定的超時周期，才重傳分組，增加了端到端的時延。 當(dāng)一個報文丟失時，在其等待超時的過程中，可能會出現(xiàn)這種情況：其后的報文段已經(jīng)被接收端接收但卻遲遲得不到確認(rèn)，發(fā)送端會認(rèn)為也丟失了，從而引起不必要的重傳，既浪費(fèi)資源也浪費(fèi)時間。
并且，對于 TCP，如果發(fā)生一次超時重傳，時間間隔下次就會加倍。
快速重傳
TCP 還有另外?種快速重傳（Fast Retransmit）機(jī)制，它不以時間為驅(qū)動，?是以數(shù)據(jù)驅(qū)動重傳。
它不以時間驅(qū)動，而是以數(shù)據(jù)驅(qū)動。它是基于接收端的反饋信息來引發(fā)重傳的。
可以用它來解決超時重發(fā)的時間等待問題，快速重傳流程如下：
在上圖，發(fā)送?發(fā)出了 1，2，3，4，5 份數(shù)據(jù)：
第?份 Seq1 先送到了，于是就 Ack 回 2； 結(jié)果 Seq2 因為某些原因沒收到，Seq3 到達(dá)了，于是還是 Ack 回 2； 后?的 Seq4 和 Seq5 都到了，但還是 Ack 回 2，因為 Seq2 還是沒有收到； 發(fā)送端收到了三個 Ack = 2 的確認(rèn)，知道了 Seq2 還沒有收到，就會在定時器過期之前，重傳丟失的 Seq2。 最后，收到了 Seq2，此時因為 Seq3，Seq4，Seq5 都收到了，于是 Ack 回 6 。
快速重傳機(jī)制只解決了?個問題，就是超時時間的問題，但是它依然?臨著另外?個問題。就是重傳的時候，是重傳之前的?個，還是重傳所有的問題。
?如對于上?的例?，是重傳 Seq2 呢？還是重傳 Seq2、Seq3、Seq4、Seq5 呢？因為發(fā)送端并不清楚這連續(xù)的三個 Ack 2 是誰傳回來的。
根據(jù) TCP 不同的實現(xiàn)，以上兩種情況都是有可能的。可?，這是?把雙刃劍。
為了解決不知道該重傳哪些 TCP 報?，于是就有 SACK ?法。
帶選擇確認(rèn)的重傳（SACK）
為了解決應(yīng)該重傳多少個包的問題? TCP 提供了帶選擇確認(rèn)的重傳（即 SACK，Selective Acknowledgment）。
SACK 機(jī)制就是，在快速重傳的基礎(chǔ)上，接收方返回最近收到報文段的序列號范圍，這樣發(fā)送方就知道接收方哪些數(shù)據(jù)包是沒收到的。這樣就很清楚應(yīng)該重傳哪些數(shù)據(jù)包。
如上圖中，發(fā)送?收到了三次同樣的 ACK 確認(rèn)報?，于是就會觸發(fā)快速重發(fā)機(jī)制，通過 SACK 信息發(fā)現(xiàn)只有 200~299 這段數(shù)據(jù)丟失，則重發(fā)時，就只選擇了這個 TCP 段進(jìn)?重發(fā)。
重復(fù) SACK（D-SACK）
D-SACK，英文是 Duplicate SACK，是在 SACK 的基礎(chǔ)上做了一些擴(kuò)展，主要用來告訴發(fā)送方，有哪些數(shù)據(jù)包，自己重復(fù)接受了。
DSACK 的目的是幫助發(fā)送方判斷，是否發(fā)生了包失序、ACK 丟失、包重復(fù)或偽重傳。讓 TCP 可以更好的做網(wǎng)絡(luò)流控。
例如 ACK 丟包導(dǎo)致的數(shù)據(jù)包重復(fù)：
接收?發(fā)給發(fā)送?的兩個 ACK 確認(rèn)應(yīng)答都丟失了，所以發(fā)送?超時后，重傳第?個數(shù)據(jù)包（3000 ~
3499）
于是接收?發(fā)現(xiàn)數(shù)據(jù)是重復(fù)收到的，于是回了?個 SACK = 3000~3500，告訴「發(fā)送?」 3000~3500 的數(shù)據(jù)早已被接收了，因為 ACK 都到了 4000 了，已經(jīng)意味著 4000 之前的所有數(shù)據(jù)都已收到，所以這個 SACK 就代表著 D-SACK 。這樣發(fā)送?就知道了，數(shù)據(jù)沒有丟，是接收?的 ACK 確認(rèn)報?丟了。
43.說說 TCP 的粘包和拆包？
TCP 的粘包和拆包更多的是業(yè)務(wù)上的概念！
什么是 TCP 粘包和拆包？
TCP 是面向流，沒有界限的一串?dāng)?shù)據(jù)。TCP 底層并不了解上層業(yè)務(wù)數(shù)據(jù)的具體含義，它會根據(jù) TCP 緩沖區(qū)的實際情況進(jìn)行包的劃分，所以在業(yè)務(wù)上認(rèn)為，一個完整的包可能會被 TCP 拆分成多個包進(jìn)行發(fā)送，也有可能把多個小的包封裝成一個大的數(shù)據(jù)包發(fā)送，這就是所謂的 TCP 粘包和拆包問題。
為什么會產(chǎn)生粘包和拆包呢?
要發(fā)送的數(shù)據(jù)小于 TCP 發(fā)送緩沖區(qū)的大小，TCP 將多次寫入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去，將會發(fā)生粘包； 接收數(shù)據(jù)端的應(yīng)用層沒有及時讀取接收緩沖區(qū)中的數(shù)據(jù)，將發(fā)生粘包； 要發(fā)送的數(shù)據(jù)大于 TCP 發(fā)送緩沖區(qū)剩余空間大小，將會發(fā)生拆包； 待發(fā)送數(shù)據(jù)大于 MSS（最大報文長度），TCP 在傳輸前將進(jìn)行拆包。即 TCP 報文長度 - TCP 頭部長度 > MSS。
那怎么解決呢？
發(fā)送端將每個數(shù)據(jù)包封裝為固定長度 在數(shù)據(jù)尾部增加特殊字符進(jìn)行分割 將數(shù)據(jù)分為兩部分，一部分是頭部，一部分是內(nèi)容體；其中頭部結(jié)構(gòu)大小固定，且有一個字段聲明內(nèi)容體的大小。
UDP
UDP 問的不多，基本上是被拿來和 TCP 比較。
44.說說 TCP 和 UDP 的區(qū)別？
最根本區(qū)別：TCP 是面向連接，而 UDP 是無連接。
可以這么形容：TCP 是打電話，UDP 是大喇叭。
說說 TCP 和 UDP 的應(yīng)用場景？
TCP 應(yīng)用場景： 效率要求相對低，但對準(zhǔn)確性要求相對高的場景。因為傳輸中需要對數(shù)據(jù)確認(rèn)、重發(fā)、排序等操作，相比之下效率沒有 UDP 高。例如：文件傳輸（準(zhǔn)確高要求高、但是速度可以相對慢）、收發(fā)郵件、遠(yuǎn)程登錄。 UDP 應(yīng)用場景： 效率要求相對高，對準(zhǔn)確性要求相對低的場景。例如：QQ 聊天、在線視頻、網(wǎng)絡(luò)語音電話（即時通訊，速度要求高，但是出現(xiàn)偶爾斷續(xù)不是太大問題，并且此處完全不可以使用重發(fā)機(jī)制）、廣播通信（廣播、多播）。
45.為什么 QQ 采用 UDP 協(xié)議？
PS：這是多年前的老題了，拉出來懷懷舊。
首先，QQ 并不是完全基于 UDP 實現(xiàn)。比如在使用 QQ 進(jìn)行文件傳輸?shù)然顒拥臅r候，就會使用 TCP 作為可靠傳輸?shù)谋ＷC。 使用 UDP 進(jìn)行交互通信的好處在于，延遲較短，對數(shù)據(jù)丟失的處理比較簡單。同時，TCP 是一個全雙工協(xié)議，需要建立連接，所以網(wǎng)絡(luò)開銷也會相對大。 如果使用 QQ 語音和 QQ 視頻的話，UDP 的優(yōu)勢就更為突出了，首先延遲較小。最重要的一點(diǎn)是不可靠傳輸，這意味著如果數(shù)據(jù)丟失的話，不會有重傳。因為用戶一般來說可以接受圖像稍微模糊一點(diǎn)，聲音稍微不清晰一點(diǎn)，但是如果在幾秒鐘以后再出現(xiàn)之前丟失的畫面和聲音，這恐怕是很難接受的。 由于 QQ 的服務(wù)器設(shè)計容量是海量級的應(yīng)用，一臺服務(wù)器要同時容納十幾萬的并發(fā)連接，因此服務(wù)器端只有采用 UDP 協(xié)議與客戶端進(jìn)行通訊才能保證這種超大規(guī)模的服務(wù)
簡單總結(jié)一下：UDP 協(xié)議是無連接方式的協(xié)議，它的效率高，速度快，占資源少，對服務(wù)器的壓力比較小。但是其傳輸機(jī)制為不可靠傳送，必須依靠輔助的算法來完成傳輸控制。QQ 采用的通信協(xié)議以 UDP 為主，輔以 TCP 協(xié)議。
46.UDP 協(xié)議為什么不可靠？
UDP 在傳輸數(shù)據(jù)之前不需要先建立連接，遠(yuǎn)地主機(jī)的運(yùn)輸層在接收到 UDP 報文后，不需要確認(rèn)，提供不可靠交付?？偨Y(jié)就以下四點(diǎn)：
不保證消息交付：不確認(rèn)，不重傳，無超時 不保證交付順序：不設(shè)置包序號，不重排，不會發(fā)生隊首阻塞 不跟蹤連接狀態(tài)：不必建立連接或重啟狀態(tài)機(jī) 不進(jìn)行擁塞控制：不內(nèi)置客戶端或網(wǎng)絡(luò)反饋機(jī)制
47.DNS 為什么要用 UDP?
更準(zhǔn)確地說，DNS 既使用 TCP 又使用 UDP。
當(dāng)進(jìn)行區(qū)域傳送（主域名服務(wù)器向輔助域名服務(wù)器傳送變化的那部分?jǐn)?shù)據(jù)）時會使用 TCP，因為數(shù)據(jù)同步傳送的數(shù)據(jù)量比一個請求和應(yīng)答的數(shù)據(jù)量要多，而 TCP 允許的報文長度更長，因此為了保證數(shù)據(jù)的正確性，會使用基于可靠連接的 TCP。
當(dāng)客戶端想 DNS 服務(wù)器查詢域名（域名解析）的時候，一般返回的內(nèi)容不會超過 UDP 報文的最大長度，即 512 字節(jié)，用 UDP 傳輸時，不需要創(chuàng)建連接，從而大大提高了響應(yīng)速度，但這要求域名解析服務(wù)器和域名服務(wù)器都必須自己處理超時和重傳從而保證可靠性。
IP
48.IP 協(xié)議的定義和作用？
IP 協(xié)議是什么？
IP 協(xié)議（Internet Protocol）又被稱為互聯(lián)網(wǎng)協(xié)議，是支持網(wǎng)間互聯(lián)的數(shù)據(jù)包協(xié)議，工作在網(wǎng)際層，主要目的就是為了提高網(wǎng)絡(luò)的可擴(kuò)展性。
通過網(wǎng)際協(xié)議 IP，可以把參與互聯(lián)的，性能各異的網(wǎng)絡(luò)看作一個統(tǒng)一的網(wǎng)絡(luò)。
和傳輸層 TCP 相比，IP 協(xié)議是一種無連接/不可靠、盡力而為的數(shù)據(jù)包傳輸服務(wù)，和 TCP 協(xié)議一起構(gòu)成了 TCP/IP 協(xié)議的核心。
IP 協(xié)議有哪些作用？
IP 協(xié)議主要有以下幾個作用：
尋址和路由：在 IP 數(shù)據(jù)報中攜帶源 IP 地址和目的 IP 地址來表示該數(shù)據(jù)包的源主機(jī)和目標(biāo)主機(jī)。IP 數(shù)據(jù)報在傳輸過程中，每個中間節(jié)點(diǎn)（IP 網(wǎng)關(guān)、路由器）只根據(jù)網(wǎng)絡(luò)地址來進(jìn)行轉(zhuǎn)發(fā)，如果中間節(jié)點(diǎn)是路由器，則路由器會根據(jù)路由表選擇合適的路徑。IP 協(xié)議根據(jù)路由選擇協(xié)議提供的路由信息對 IP 數(shù)據(jù)報進(jìn)行轉(zhuǎn)發(fā)，直至目標(biāo)主機(jī)。 分段和重組：IP 數(shù)據(jù)報在傳輸過程中可能會經(jīng)過不同的網(wǎng)絡(luò)，在不同的網(wǎng)絡(luò)中數(shù)據(jù)報的最大長度限制是不同的，IP 協(xié)議通過給每個 IP 數(shù)據(jù)報分配一個標(biāo)識符以及分段與組裝的相關(guān)信息，使得數(shù)據(jù)報在不同的網(wǎng)絡(luò)中能夠被傳輸，被分段后的 IP 數(shù)據(jù)報可以獨(dú)立地在網(wǎng)絡(luò)中進(jìn)行轉(zhuǎn)發(fā)，在達(dá)到目標(biāo)主機(jī)后由目標(biāo)主機(jī)完成重組工作，恢復(fù)出原來的 IP 數(shù)據(jù)報。
傳輸層協(xié)議和網(wǎng)絡(luò)層協(xié)議有什么區(qū)別？
網(wǎng)絡(luò)層協(xié)議負(fù)責(zé)提供主機(jī)間的邏輯通信；傳輸層協(xié)議負(fù)責(zé)提供進(jìn)程間的邏輯通信。
49.IP 地址有哪些分類？
一個 IP 地址在這鞥個互聯(lián)網(wǎng)范圍內(nèi)是惟一的，一般可以這么認(rèn)為，IP 地址 = {<網(wǎng)絡(luò)號>，<主機(jī)號>}。
網(wǎng)絡(luò)號：它標(biāo)志主機(jī)所連接的網(wǎng)絡(luò)地址表示屬于互聯(lián)網(wǎng)的哪一個網(wǎng)絡(luò)。 主機(jī)號：它標(biāo)志主機(jī)地址表示其屬于該網(wǎng)絡(luò)中的哪一臺主機(jī)。
IP 地址分為 A，B，C，D，E 五大類：
A 類地址 (1~126)：以 0 開頭，網(wǎng)絡(luò)號占前 8 位，主機(jī)號占后面 24 位。 B 類地址 (128~191)：以 10 開頭，網(wǎng)絡(luò)號占前 16 位，主機(jī)號占后面 16 位。 C 類地址 (192~223)：以 110 開頭，網(wǎng)絡(luò)號占前 24 位，主機(jī)號占后面 8 位。 D 類地址 (224~239)：以 1110 開頭，保留為多播地址。 E 類地址 (240~255)：以 1111 開頭，保留位為將來使用
50.域名和 IP 的關(guān)系？一個 IP 可以對應(yīng)多個域名嗎？
IP 地址在同一個網(wǎng)絡(luò)中是惟一的，用來標(biāo)識每一個網(wǎng)絡(luò)上的設(shè)備，其相當(dāng)于一個人的身份證號 域名在同一個網(wǎng)絡(luò)中也是惟一的，就像是一個人的名字、綽號
假如你有多個不用的綽號，你的朋友可以用其中任何一個綽號叫你，但你的身份證號碼卻是惟一的。但同時你的綽號也可能和別人重復(fù)，假如你不在，有人叫你的綽號，其它人可能就答應(yīng)了。
一個域名可以對應(yīng)多個 IP，但這種情況 DNS 做負(fù)載均衡的，在用戶訪問過程中，一個域名只能對應(yīng)一個 IP。
而一個 IP 卻可以對應(yīng)多個域名，是一對多的關(guān)系。
51.IPV4 地址不夠如何解決？
我們知道，IP 地址有 32 位，可以標(biāo)記 2 的 32 次方個地址，聽起來很多，但是全球的網(wǎng)絡(luò)設(shè)備數(shù)量已經(jīng)遠(yuǎn)遠(yuǎn)超過這個數(shù)字，所以 IPV4 地址已經(jīng)不夠用了，那怎么解決呢？
DHCP：動態(tài)主機(jī)配置協(xié)議，動態(tài)分配 IP 地址，只給接入網(wǎng)絡(luò)的設(shè)備分配 IP 地址，因此同一個 MAC 地址的設(shè)備，每次接入互聯(lián)網(wǎng)時，得到的 IP 地址不一定是相同的，該協(xié)議使得空閑的 IP 地址可以得到充分利用。 CIDR：無類別域間路由。CIDR 消除了傳統(tǒng)的 A 類、B 類、C 類地址以及劃分子網(wǎng)的概念，因而更加有效地分配 IPv4 的地址空間，但無法從根本上解決地址耗盡的問題。 NAT：網(wǎng)絡(luò)地址轉(zhuǎn)換協(xié)議，我們知道屬于不同局域網(wǎng)的主機(jī)可以使用相同的 IP 地址，從而一定程度上緩解了 IP 資源枯竭的問題，然而主機(jī)在局域網(wǎng)中使用的 IP 地址是不能在公網(wǎng)中使用的，當(dāng)局域網(wǎng)主機(jī)想要與公網(wǎng)主機(jī)進(jìn)行通信時，NAT 方法可以將該主機(jī) IP 地址轉(zhuǎn)換為全球 IP 地址。該協(xié)議能夠有效解決 IP 地址不足的問題。 IPv6：作為接替 IPv4 的下一代互聯(lián)網(wǎng)協(xié)議，其可以實現(xiàn) 2 的 128 次方個地址，而這個數(shù)量級，即使給地球上每一粒沙子都分配一個 IP 地址也夠用，該協(xié)議能夠從根本上解決 IPv4 地址不夠用的問題。
52.說下 ARP 協(xié)議的工作過程？
ARP 協(xié)議，Address Resolution Protocol，地址解析協(xié)議，它是用于實現(xiàn) IP 地址到 MAC 地址的映射。
首先，每臺主機(jī)都會在自己的 ARP 緩沖區(qū)中建立一個 ARP 列表，以表示 IP 地址和 MAC 地址的對應(yīng)關(guān)系。 當(dāng)源主機(jī)需要將一個數(shù)據(jù)包要發(fā)送到目的主機(jī)時，會首先檢查自己的 ARP 列表，是否存在該 IP 地址對應(yīng)的 MAC 地址；如果有﹐就直接將數(shù)據(jù)包發(fā)送到這個 MAC 地址；如果沒有，就向本地網(wǎng)段發(fā)起一個 ARP 請求的廣播包，查詢此目的主機(jī)對應(yīng)的 MAC 地址。此 ARP 請求的數(shù)據(jù)包里，包括源主機(jī)的 IP 地址、硬件地址、以及目的主機(jī)的 IP 地址。 網(wǎng)絡(luò)中所有的主機(jī)收到這個 ARP 請求后，會檢查數(shù)據(jù)包中的目的 IP 是否和自己的 IP 地址一致。如果不相同，就會忽略此數(shù)據(jù)包；如果相同，該主機(jī)首先將發(fā)送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已經(jīng)存在該 IP 的信息，則將其覆蓋，然后給源主機(jī)發(fā)送一個 ARP 響應(yīng)數(shù)據(jù)包，告訴對方自己是它需要查找的 MAC 地址。 源主機(jī)收到這個 ARP 響應(yīng)數(shù)據(jù)包后，將得到的目的主機(jī)的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息開始數(shù)據(jù)的傳輸。如果源主機(jī)一直沒有收到 ARP 響應(yīng)數(shù)據(jù)包，表示 ARP 查詢失敗。
53.為什么既有 IP 地址，又有 MAC 地址？
MAC 地址和 IP 地址都有什么作用？
MAC 地址是數(shù)據(jù)鏈路層和物理層使用的地址，是寫在網(wǎng)卡上的物理地址，用來定義網(wǎng)絡(luò)設(shè)備的位置，不可變更。 IP 地址是網(wǎng)絡(luò)層和以上各層使用的地址，是一種邏輯地址。IP 地址用來區(qū)別網(wǎng)絡(luò)上的計算機(jī)。
為什么有了 MAC 地址還需要 IP 地址？
如果我們只使用 MAC 地址進(jìn)行尋址的話，我們需要路由器記住每個 MAC 地址屬于哪個子網(wǎng)，不然一次路由器收到數(shù)據(jù)包都要滿世界尋找目的 MAC 地址。而我們知道 MAC 地址的長度為 48 位，也就是最多共有 2 的 48 次方個 MAC 地址，這就意味著每個路由器需要 256T 的內(nèi)存，顯然是不現(xiàn)實的。
和 MAC 地址不同，IP 地址是和地域相關(guān)的，在一個子網(wǎng)中的設(shè)備，我們給其分配的 IP 地址前綴都是一樣的，這樣路由器就能根據(jù) IP 地址的前綴知道這個設(shè)備屬于哪個子網(wǎng)，剩下的尋址就交給子網(wǎng)內(nèi)部實現(xiàn)，從而大大減少了路由器所需要的內(nèi)存。
為什么有了 IP 地址還需要 MAC 地址？
只有當(dāng)設(shè)備連入網(wǎng)絡(luò)時，才能根據(jù)他進(jìn)入了哪個子網(wǎng)來為其分配 IP 地址，在設(shè)備還沒有 IP 地址的時候，或者在分配 IP 的過程中。我們需要 MAC 地址來區(qū)分不同的設(shè)備。 IP 地址可以比作為地址，MAC 地址為收件人，在一次通信過程中，兩者是缺一不可的。
54.ICMP 協(xié)議的功能？
ICMP（Internet Control Message Protocol） ，網(wǎng)際控制報文協(xié)議。
ICMP 協(xié)議是一種面向無連接的協(xié)議，用于傳輸出錯報告控制信息。 它是一個非常重要的協(xié)議，它對于網(wǎng)絡(luò)安全具有極其重要的意義。它屬于網(wǎng)絡(luò)層協(xié)議，主要用于在主機(jī)與路由器之間傳遞控制信息，包括報告錯誤、交換受限控制和狀態(tài)信息等。 當(dāng)遇到 IP 數(shù)據(jù)無法訪問目標(biāo)、IP 路由器無法按當(dāng)前的傳輸速率轉(zhuǎn)發(fā)數(shù)據(jù)包等情況時，會自動發(fā)送 ICMP 消息。
比如我們?nèi)粘Ｊ褂玫帽容^多的 ping，就是基于 ICMP 的。
55.說下 ping 的原理？
ping，Packet Internet Groper，是一種因特網(wǎng)包探索器，用于測試網(wǎng)絡(luò)連接量的程序。Ping 是工作在 TCP/IP 網(wǎng)絡(luò)體系結(jié)構(gòu)中應(yīng)用層的一個服務(wù)命令， 主要是向特定的目的主機(jī)發(fā)送 ICMP（Internet Control Message Protocol 因特網(wǎng)報文控制協(xié)議） 請求報文，測試目的站是否可達(dá)及了解其有關(guān)狀態(tài)。
一般來說，ping 可以用來檢測網(wǎng)絡(luò)通不通。它是基于ICMP協(xié)議工作的。假設(shè)機(jī)器 A ping 機(jī)器 B，工作過程如下：
ping 通知系統(tǒng)，新建一個固定格式的 ICMP 請求數(shù)據(jù)包 ICMP 協(xié)議，將該數(shù)據(jù)包和目標(biāo)機(jī)器 B 的 IP 地址打包，一起轉(zhuǎn)交給 IP 協(xié)議層 IP 層協(xié)議將本機(jī) IP 地址為源地址，機(jī)器 B 的 IP 地址為目標(biāo)地址，加上一些其他的控制信息，構(gòu)建一個 IP 數(shù)據(jù)包 先獲取目標(biāo)機(jī)器 B 的 MAC 地址。 數(shù)據(jù)鏈路層構(gòu)建一個數(shù)據(jù)幀，目的地址是 IP 層傳過來的 MAC 地址，源地址是本機(jī)的 MAC 地址 機(jī)器 B 收到后，對比目標(biāo)地址，和自己本機(jī)的 MAC 地址是否一致，符合就處理返回，不符合就丟棄。 根據(jù)目的主機(jī)返回的 ICMP 回送回答報文中的時間戳，從而計算出往返時間 最終顯示結(jié)果有這幾項：發(fā)送到目的主機(jī)的 IP 地址、發(fā)送 & 收到 & 丟失的分組數(shù)、往返時間的最小、最大 & 平均值
網(wǎng)絡(luò)安全
56.說說有哪些安全攻擊？
網(wǎng)絡(luò)安全攻擊主要分為兩種類型，被動攻擊和主動攻擊：
被動攻擊：是指攻擊者從網(wǎng)絡(luò)上竊聽他人的通信內(nèi)容，通常把這類攻擊稱為截獲，被動攻擊主要有兩種形式：消息內(nèi)容泄露攻擊和流量分析攻擊。由于攻擊者沒有修改數(shù)據(jù)，使得這種攻擊很難被檢測到。
主動攻擊：直接對現(xiàn)有的數(shù)據(jù)和服務(wù)造成影響，常見的主動攻擊類型有：
篡改：攻擊者故意篡改網(wǎng)絡(luò)上送的報文，甚至把完全偽造的報文傳送給接收方。
惡意程序：惡意程序種類繁多，包括計算機(jī)病毒、計算機(jī)蠕蟲、特洛伊木馬、后門入侵、流氓軟件等等。
拒絕服務(wù) Dos：攻擊者向服務(wù)器不停地發(fā)送分組，使服務(wù)器無法提供正常服務(wù)。
57.DNS 劫持了解嗎？
DNS 劫持即域名劫持，是通過將原域名對應(yīng)的 IP 地址進(jìn)行替換，從而使用戶訪問到錯誤的網(wǎng)站，或者使用戶無法正常訪問網(wǎng)站的一種攻擊方式。
域名劫持往往只能在特定的網(wǎng)絡(luò)范圍內(nèi)進(jìn)行，范圍外的 DNS 服務(wù)器能夠返回正常的 IP 地址。攻擊者可以冒充原域名所屬機(jī)構(gòu)，通過電子郵件的方式修改組織機(jī)構(gòu)的域名注冊信息，或者將域名轉(zhuǎn)讓給其它主持，并將新的域名信息保存在所指定的 DNS 服務(wù)器中，從而使用戶無法對原域名來進(jìn)行解析以訪問目標(biāo)地址。
DNS 劫持的步驟是什么樣的？
獲取要劫持的域名信息：攻擊者會首先訪問域名查詢要劫持的站點(diǎn)的域名信息。 控制域名響應(yīng)的 E-Mail 賬號：在獲取到域名信息后，攻擊者通過暴力破解或者專門的方法破解公司注冊域名時使用的 E-mail 賬號所對應(yīng)的密碼，更高級的攻擊者甚至能夠直接對 E-Mail 進(jìn)行信息竊取。 修改注冊信息：當(dāng)攻擊者破解了 E-Mail 后，會利用相關(guān)的更改功能修改該域名的注冊信息，包括域名擁有者信息，DNS 服務(wù)器信息等。 使用 E-Mail 收發(fā)確認(rèn)函：在修改完注冊信息后，攻擊者 E-Mail 在真正擁有者之前收到修改域名注冊信息的相關(guān)確認(rèn)信息，并回復(fù)確認(rèn)修改文件，待網(wǎng)絡(luò)公司恢復(fù)已成功修改信件后，攻擊者便成功完成 DNS 劫持。
怎么應(yīng)對 DNS 劫持？
直接通過 IP 地址訪問網(wǎng)站，避開 DNS 劫持 由于域名劫持往往只能在特定的網(wǎng)絡(luò)范圍內(nèi)進(jìn)行，因此一些高級用戶可以通過網(wǎng)絡(luò)設(shè)置讓 DNS 指向正常的域名服務(wù)器以實現(xiàn)對目標(biāo)網(wǎng)址的正常訪問，例如計算機(jī)首選 DNS 服務(wù)器的地址固定為 8.8.8.8。
58.什么是 CSRF 攻擊？如何避免？
什么是 CSRF 攻擊？
CSRF，跨站請求偽造（英文全稱是 Cross-site request forgery），是一種挾持用戶在當(dāng)前已登錄的 Web 應(yīng)用程序上執(zhí)行非本意的操作的攻擊方法。
CSRF 是如何攻擊的呢？
來看一個例子：
用戶登陸銀行，沒有退出，瀏覽器包含了 用戶 在銀行的身份認(rèn)證信息。 攻擊者將偽造的轉(zhuǎn)賬請求，包含在在帖子 用戶在銀行網(wǎng)站保持登陸的情況下，瀏覽帖子 將偽造的轉(zhuǎn)賬請求連同身份認(rèn)證信息，發(fā)送到銀行網(wǎng)站 銀行網(wǎng)站看到身份認(rèn)證信息，以為就是 用戶的合法操作，最后造成用戶資金損失。
怎么應(yīng)對 CSRF 攻擊呢？
檢查 Referer 字段
HTTP 頭中的 Referer 字段記錄了該 HTTP 請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求來自于同一個網(wǎng)站，而如果黑客要對其實施 CSRF 攻擊，他一般只能在他自己的網(wǎng)站構(gòu)造請求。因此，可以通過驗證 Referer 值來防御 CSRF 攻擊。
添加校驗 token
以在 HTTP 請求中以參數(shù)的形式加入一個隨機(jī)產(chǎn)生的 token，并在服務(wù)器端建立一個攔截器來驗證這個 token，如果請求中沒有 token 或者 token 內(nèi)容不正確，則認(rèn)為可能是 CSRF 攻擊而拒絕該請求。
敏感操作多重校驗
對一些敏感的操作，除了需要校驗用戶的認(rèn)證信息，還可以通過郵箱確認(rèn)、驗證碼確認(rèn)這樣的方式多重校驗。
59.什么是 DoS、DDoS、DRDoS 攻擊？
DOS: (Denial of Service), 翻譯過來就是拒絕服務(wù), 一切能引起拒絕 行為的攻擊都被稱為 DOS 攻擊。最常見的 DoS 攻擊就有計算機(jī)網(wǎng)絡(luò)寬帶攻擊、連通性攻擊。 DDoS: (Distributed Denial of Service)，翻譯過來是分布式拒絕服務(wù)。是指處于不同位置的多個攻擊者同時向一個或幾個目標(biāo)發(fā)動攻擊，或者一個攻擊者控制了位于不同位置的多臺機(jī)器，并利用這些機(jī)器對受害者同時實施攻擊。
主要形式有流量攻擊和資源耗盡攻擊，常見的 DDoS 攻擊有：SYN Flood、Ping of Death、ACK Flood、UDP Flood 等。
DRDoS: (Distributed Reflection Denial of Service)，中文是分布式反射拒絕服務(wù)，該方式靠的是發(fā)送大量帶有被害者 IP 地址的數(shù)據(jù)包給攻擊主機(jī)，然后攻擊主機(jī)對 IP 地址源做出大量回應(yīng)，從而形成拒絕服務(wù)攻擊。
如何防范 DDoS?
針對 DDoS 中的流量攻擊，最直接的方法是增加帶寬，理論上只要帶寬大于攻擊流量就可以了，但是這種方法成本非常高。在有充足帶寬的前提下，我們應(yīng)該盡量提升路由器、網(wǎng)卡、交換機(jī)等硬件設(shè)施的配置。
針對資源耗盡攻擊，我們可以升級主機(jī)服務(wù)器硬件，在網(wǎng)絡(luò)帶寬得到保證的前提下，使得服務(wù)器能夠有效對抗海量的 SYN 攻擊包。我們也可以安裝專業(yè)的抗 DDoS 防火墻，從而對抗 SYN Flood 等流量型攻擊。瓷碗，負(fù)載均衡，CDN 等技術(shù)都能有效對抗 DDos 攻擊。
60.什么是 XSS 攻擊，如何避免?
XSS 攻擊也是比較常見，XSS，叫跨站腳本攻擊（Cross-Site Scripting），因為會與層疊樣式表 (Cascading Style Sheets, CSS) 的縮寫混淆，因此有人將跨站腳本攻擊縮寫為 XSS。它指的是惡意攻擊者往 Web 頁面里插入惡意 html 代碼，當(dāng)用戶瀏覽網(wǎng)頁的時候，嵌入其中 Web 里面的 html 代碼會被執(zhí)行，從而達(dá)到惡意攻擊用戶的特殊目的。
XSS 攻擊一般分三種類型：存儲型 、反射型 、DOM 型 XSS
XSS 是如何攻擊的呢？
簡單說，XSS 的攻擊方式就是想辦法“教唆”用戶的瀏覽器去執(zhí)行一些這個網(wǎng)頁中原本不存在的前端代碼。
拿反射型舉個例子吧，流程圖如下：
攻擊者構(gòu)造出特殊的 URL，其中包含惡意代碼。 用戶打開帶有惡意代碼的 URL 時，訪問正常網(wǎng)站服務(wù)器 網(wǎng)站服務(wù)端將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器。 用戶瀏覽器接收到響應(yīng)后解析執(zhí)行，混在其中的惡意代碼也被執(zhí)行，請求惡意服務(wù)器，發(fā)送用戶數(shù)據(jù) 攻擊者就可以竊取用戶的數(shù)據(jù)，以此冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。
如何應(yīng)對 XSS 攻擊？
對輸入進(jìn)行過濾，過濾標(biāo)簽等，只允許合法值。 HTML 轉(zhuǎn)義 對于鏈接跳轉(zhuǎn)，如 <a href="xxx"等，要校驗內(nèi)容，禁止以 script 開頭的非法鏈接。限制輸入長度
61.對稱加密與非對稱加密有什么區(qū)別？
對稱加密：指加密和解密使用同一密鑰，優(yōu)點(diǎn)是運(yùn)算速度較快，缺點(diǎn)是如何安全將密鑰傳輸給另一方。常見的對稱加密算法有：DES、AES 等。
非對稱加密：指的是加密和解密使用不同的密鑰（即公鑰和私鑰）。公鑰與私鑰是成對存在的，如果用公鑰對數(shù)據(jù)進(jìn)行加密，只有對應(yīng)的私鑰才能解密。常見的非對稱加密算法有 RSA。
62.RSA 和 AES 算法有什么區(qū)別？
RSA
采用非對稱加密的方式，采用公鑰進(jìn)行加密，私鑰解密的形式。其私鑰長度一般較長，由于需要大數(shù)的乘冪求模等運(yùn)算，其運(yùn)算速度較慢，不合適大量數(shù)據(jù)文件加密。
AES
采用對稱加密的方式，其秘鑰長度最長只有 256 個比特，加密和解密速度較快，易于硬件實現(xiàn)。由于是對稱加密，通信雙方在進(jìn)行數(shù)據(jù)傳輸前需要獲知加密密鑰。
沒有什么使我停留——除了目的，縱然岸旁有玫瑰、有綠蔭、有寧靜的港灣，我是不系之舟。
推薦閱讀：
面渣逆襲 Java SE 篇?? 面渣逆襲 Java 集合框架篇?? 面渣逆襲 Java 并發(fā)編程篇?? 面渣逆襲 JVM 篇?? 面渣逆襲 Spring 篇?? 面渣逆襲 Redis 篇?? 面渣逆襲 MyBatis 篇?? 面渣逆襲 MySQL 篇?? 面渣逆襲操作系統(tǒng)篇??
