前言

金九銀十馬上要到了，整理了50道計(jì)算機(jī)網(wǎng)絡(luò)面試題，每一道都非常的經(jīng)典，大廠也非常喜歡問。希望大家看完后，都能找到理想的offer哈~

公眾號(hào)：?撿田螺的小男孩，原文鏈接：https://juejin.cn/post/6988794419910541348?utm_source=tuicool&utm_medium=referral

1. HTTP 常用的請(qǐng)求方式，區(qū)別和用途？

GET?: 發(fā)送請(qǐng)求，獲取服務(wù)器數(shù)據(jù)

POST?：向URL指定的資源提交數(shù)據(jù)

PUT?：向服務(wù)器提交數(shù)據(jù)，以修改數(shù)據(jù)

HEAD?:請(qǐng)求頁面的首部，獲取資源的元信息

DELETE?：刪除服務(wù)器上的某些資源。

CONNECT?：建立連接隧道，用于代理服務(wù)器；

OPTIONS?：列出可對(duì)資源實(shí)行的請(qǐng)求方法，常用于跨域

TRACE?：追蹤請(qǐng)求-響應(yīng)的傳輸路徑

2. HTTP 常用的狀態(tài)碼及含義？

1xx：接受的請(qǐng)求正在處理 （信息性狀態(tài)碼）

2xx：表示請(qǐng)求正常處理完畢 （成功狀態(tài)碼）

3xx：表示重定向狀態(tài)，需要重新請(qǐng)求 （重定向狀態(tài)碼）

4xx：服務(wù)器無法處理請(qǐng)求 （客戶端錯(cuò)誤狀態(tài)碼）

5xx：服務(wù)器處理請(qǐng)求出錯(cuò) （服務(wù)端錯(cuò)誤狀態(tài)碼）

常用狀態(tài)碼如下：

101 切換請(qǐng)求協(xié)議，從 HTTP 切換到 WebSocket

200 請(qǐng)求成功，表示正常返回信息。

301 永久重定向，會(huì)緩存

302 臨時(shí)重定向，不會(huì)緩存

400 請(qǐng)求錯(cuò)誤

403 服務(wù)器禁止訪問

404 找不到與 URI相匹配的資源。

500 常見的服務(wù)器端錯(cuò)誤

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

DNS解析，查找真正的ip地址

與服務(wù)器建立TCP連接

發(fā)送HTTP請(qǐng)求

服務(wù)器處理請(qǐng)求并返回HTTP報(bào)文

瀏覽器解析渲染頁面

連接結(jié)束

4. 如何理解HTTP協(xié)議是無狀態(tài)的

每次HTTP請(qǐng)求都是獨(dú)立的，無相關(guān)的，默認(rèn)不需要保存上下文信息的。我們來看個(gè)便于理解的例子：

有狀態(tài)：

A：今天吃啥子？

B：羅非魚！

A：味道怎么樣呀？

B：還不錯(cuò)，好香。

無狀態(tài)：

A：今天吃啥子？

B：羅非魚！

A：味道怎么樣呀？

B：？?。可?？什么鬼？什么味道怎么樣？

加下cookie這玩意：

A：今天吃啥子？

B：羅非魚

A：你今天吃的羅非魚味道怎么樣呀？

B：還不錯(cuò)，好香。

5. HTTP 1.0，1.1，2.0 的版本區(qū)別

HTTP 1.0

HTTP 1.0規(guī)定瀏覽器與服務(wù)器只保持?短暫的連接?，瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接，服務(wù)器完成請(qǐng)求處理后立即斷開TCP連接。它也可以強(qiáng)制開啟長(zhǎng)鏈接，例如設(shè)置?Connection: keep-alive?這個(gè)字段

HTTP 1.1

引入了長(zhǎng)連接，即?TCP連接默認(rèn)不關(guān)閉，可以被多個(gè)請(qǐng)求復(fù)用?。

引入了管道機(jī)制（pipelining），即在同一個(gè)TCP連接里面，客戶端可以同時(shí)發(fā)送多個(gè)請(qǐng)求。

緩存處理，引入了更多的緩存控制策略，如?Cache-Control?、?Etag/If-None-Match?等。

錯(cuò)誤狀態(tài)管理，新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如409表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突。

HTTP 2

采用了?多路復(fù)用?，即在一個(gè)連接里，客戶端和瀏覽器都可以同時(shí)發(fā)送多個(gè)請(qǐng)求或回應(yīng)，而且不用按照順序一一對(duì)應(yīng)。

服務(wù)端推送，HTTP 2允許服務(wù)器未經(jīng)請(qǐng)求，主動(dòng)向客戶端發(fā)送資源

6. 說下計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)

計(jì)算機(jī)網(wǎng)路體系結(jié)構(gòu)主要有ISO七層模型、TCP/IP 四層模型、五層體系結(jié)構(gòu)

ISO七層模型

ISO七層模型是國(guó)際標(biāo)準(zhǔn)化組織（ISO）制定的一個(gè)用于計(jì)算機(jī)或通信系統(tǒng)間互聯(lián)的標(biāo)準(zhǔn)體系。

應(yīng)用層：網(wǎng)絡(luò)服務(wù)與最終用戶的一個(gè)接口，協(xié)議有：?HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP

表示層：數(shù)據(jù)的表示、安全、壓縮。

會(huì)話層：建立、管理、終止會(huì)話。對(duì)應(yīng)主機(jī)進(jìn)程，指本地主機(jī)與遠(yuǎn)程主機(jī)正在進(jìn)行的會(huì)話

傳輸層：定義傳輸數(shù)據(jù)的協(xié)議端口號(hào)，以及流控和差錯(cuò)校驗(yàn)。協(xié)議有：?TCP UDP，數(shù)據(jù)包一旦離開網(wǎng)卡即進(jìn)入網(wǎng)絡(luò)傳輸層

網(wǎng)絡(luò)層：進(jìn)行邏輯地址尋址，實(shí)現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇。協(xié)議有：?ICMP IGMP IP（IPV4 IPV6）

數(shù)據(jù)鏈路層：建立邏輯連接、進(jìn)行硬件地址尋址、差錯(cuò)校驗(yàn)等功能。

物理層：建立、維護(hù)、斷開物理連接。

TCP/IP 四層模型

應(yīng)用層：對(duì)應(yīng)于OSI參考模型的（應(yīng)用層、表示層、會(huì)話層），為用戶提供所需要的各種服務(wù)，例如：FTP、Telnet、DNS、SMTP等

傳輸層:對(duì)應(yīng)OSI的傳輸層，為應(yīng)用層實(shí)體提供端到端的通信功能，保證了數(shù)據(jù)包的順序傳送及數(shù)據(jù)的完整性。定義了TCP和UDP兩層協(xié)議。

網(wǎng)際層：對(duì)應(yīng)于OSI參考模型的網(wǎng)絡(luò)層，主要解決主機(jī)到主機(jī)的通信問題。三個(gè)主要協(xié)議：網(wǎng)際協(xié)議（IP）、互聯(lián)網(wǎng)組管理協(xié)議（IGMP）和互聯(lián)網(wǎng)控制報(bào)文協(xié)議（ICMP）

網(wǎng)絡(luò)接口層：與OSI參考模型的數(shù)據(jù)鏈路層、物理層對(duì)應(yīng)。它負(fù)責(zé)監(jiān)視數(shù)據(jù)在主機(jī)和網(wǎng)絡(luò)之間的交換。

五層體系結(jié)構(gòu)

應(yīng)用層：通過應(yīng)用進(jìn)程間的交互來完成特定網(wǎng)絡(luò)應(yīng)用。對(duì)應(yīng)于OSI參考模型的（應(yīng)用層、表示層、會(huì)話層），應(yīng)用層協(xié)議很多，如?域名系統(tǒng)DNS?，HTTP協(xié)議，支持電子郵件的?SMTP協(xié)議?等等。我們把應(yīng)用層交互的數(shù)據(jù)單元稱為報(bào)文。

傳輸層：負(fù)責(zé)向兩臺(tái)主機(jī)進(jìn)程之間的通信提供通用的數(shù)據(jù)傳輸服務(wù)。對(duì)應(yīng)OSI參考模型的傳輸層，協(xié)議有傳輸控制協(xié)議 TCP 和 用戶數(shù)據(jù)協(xié)議 UDP。

網(wǎng)絡(luò)層：對(duì)應(yīng)OSI參考模型的的網(wǎng)絡(luò)層

數(shù)據(jù)鏈路層：對(duì)應(yīng)OSI參考模型的的數(shù)據(jù)鏈路層

物理層：對(duì)應(yīng)OSI參考模型的的物理層層。在物理層上所傳送的數(shù)據(jù)單位是比特。 物理層(physical layer)的作用是實(shí)現(xiàn)相鄰計(jì)算機(jī)節(jié)點(diǎn)之間比特流的透明傳送，盡可能屏蔽掉具體傳輸介質(zhì)和物理設(shè)備的差異。

7. POST和GET有哪些區(qū)別？

請(qǐng)求參數(shù)?：GET 把參數(shù)包含在 URL 中，用&連接起來；POST 通過 request body 傳遞參數(shù)。

請(qǐng)求緩存?：GET請(qǐng)求會(huì)被主動(dòng)Cache，而POST請(qǐng)求不會(huì)，除非手動(dòng)設(shè)置。

收藏為書簽?：GET請(qǐng)求支持收藏為書簽，POST請(qǐng)求不支持。

安全性?：POST比GET安全，GET請(qǐng)求在瀏覽器回退時(shí)是無害的，而POST會(huì)再次請(qǐng)求。

歷史記錄?：GET請(qǐng)求參數(shù)會(huì)被完整保留在瀏覽歷史記錄里，而POST中的參數(shù)不會(huì)被保留。

編碼方式?：GET請(qǐng)求只能進(jìn)行url編碼，而POST支持多種編碼方式。

參數(shù)數(shù)據(jù)類型?：GET只接受ASCII字符，而POST沒有限制數(shù)據(jù)類型。

數(shù)據(jù)包?: GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包；POST可能產(chǎn)生兩個(gè)TCP數(shù)據(jù)包。

8. 在交互過程中如果數(shù)據(jù)傳送完了，還不想斷開連接怎么辦，怎么維持？

在 HTTP 中響應(yīng)體的 Connection 字段指定為?keep-alive

9. HTTP 如何實(shí)現(xiàn)長(zhǎng)連接？在什么時(shí)候會(huì)超時(shí)？

HTTP 如何實(shí)現(xiàn)長(zhǎng)連接？

HTTP分為長(zhǎng)連接和短連接，其實(shí)?本質(zhì)上說的是TCP的長(zhǎng)短連接?。TCP連接是一個(gè)雙向的通道，它是可以保持一段時(shí)間不關(guān)閉的，因此TCP連接才有真正的長(zhǎng)連接和短連接這一個(gè)說法。

長(zhǎng)連接是指的是TCP連接，而不是HTTP連接。

TCP 長(zhǎng)連接可以復(fù)用一個(gè)TCP連接來發(fā)起多次HTTP請(qǐng)求，這樣可以減少資源消耗，比如一次請(qǐng)求HTML，短連接可能還需要請(qǐng)求后續(xù)的JS/CSS/圖片等

要實(shí)現(xiàn)HTTP長(zhǎng)連接，在響應(yīng)頭設(shè)置?Connection為keep-alive?，HTTP1.1 默認(rèn)是長(zhǎng)連接，而HTTP 1.0協(xié)議也支持長(zhǎng)連接，但是默認(rèn)是關(guān)閉的。

在什么時(shí)候會(huì)超時(shí)呢？

HTTP 一般會(huì)有httpd守護(hù)進(jìn)程，里面可以設(shè)置 keep-alive timeout，當(dāng) tcp 鏈接閑置超過這個(gè)時(shí)間就會(huì)關(guān)閉，也可以在HTTP的header里面設(shè)置超時(shí)時(shí)間

TCP 的 keep-alive 包含三個(gè)參數(shù)，支持在系統(tǒng)內(nèi)核的 net.ipv4 里面設(shè)置：當(dāng) TCP 連接之后，閑置了 tcp_keepalive_time，則會(huì)發(fā)生偵測(cè)包，如果沒有收到對(duì)方的 ACK，那么會(huì)每隔 tcp_keepalive_intvl 再發(fā)一次，直到發(fā)送了 tcp_keepalive_probes，就會(huì)丟棄該連接。

tcp_keepalive_intvl = 15

tcp_keepalive_probes = 5

tcp_keepalive_time = 1800

10. 講一下HTTP與HTTPS 的區(qū)別。

HTTP，超文本傳輸協(xié)議，英文是?Hyper Text Transfer Protocol?，是一個(gè)基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)的協(xié)議。HTTP存在這?幾個(gè)問題?：

請(qǐng)求信息明文傳輸，容易被竊聽截取。

數(shù)據(jù)的完整性未校驗(yàn)，容易被篡改

沒有驗(yàn)證對(duì)方身份，存在冒充危險(xiǎn)

HTTPS就是為了解決HTTP存在問題的。HTTPS，英文是HyperText Transfer Protocol over Secure Socket Layer，可以這么理解Https是身披SSL(Secure Socket Layer)的HTTP，即?HTTPS 協(xié)議 = HTTP+SSL/TLS?。通過 SSL證書來驗(yàn)證服務(wù)器的身份，并為瀏覽器和服務(wù)器之間的傳輸數(shù)據(jù)進(jìn)行?加密?。

它們主要區(qū)別：

數(shù)據(jù)是否加密: Http 是明文傳輸，HTTPS是密文

默認(rèn)端口: Http默認(rèn)端口是80，Https默認(rèn)端口是443

資源消耗：和HTTP通信相比，Https通信會(huì)消耗更多的CPU和內(nèi)存資源，因?yàn)樾枰咏饷芴幚恚?/p>

安全性: http不安全，https比較安全。

11 . Https 流程是怎樣的？

HTTPS = HTTP + SSL/TLS，即用SSL/TLS對(duì)數(shù)據(jù)進(jìn)行加密和解密，Http進(jìn)行傳輸。

SSL，即Secure Sockets Layer（安全套接層協(xié)議），是網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。

TLS，即Transport Layer Security(安全傳輸層協(xié)議)，它是SSL 3.0的后續(xù)版本。

用戶在瀏覽器里輸入一個(gè)https網(wǎng)址，然后連接到server的443端口。

服務(wù)器必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請(qǐng)，區(qū)別就是自己頒發(fā)的證書需要客戶端驗(yàn)證通過。這套證書其實(shí)就是一對(duì)公鑰和私鑰。

服務(wù)器將自己的數(shù)字證書（含有公鑰）發(fā)送給客戶端。

客戶端收到服務(wù)器端的數(shù)字證書之后，會(huì)對(duì)其進(jìn)行檢查，如果不通過，則彈出警告框。如果證書沒問題，則生成一個(gè)密鑰（對(duì)稱加密），用證書的公鑰對(duì)它加密。

客戶端會(huì)發(fā)起HTTPS中的第二個(gè)HTTP請(qǐng)求，將加密之后的客戶端密鑰發(fā)送給服務(wù)器。

服務(wù)器接收到客戶端發(fā)來的密文之后，會(huì)用自己的私鑰對(duì)其進(jìn)行非對(duì)稱解密，解密之后得到客戶端密鑰，然后用客戶端密鑰對(duì)返回?cái)?shù)據(jù)進(jìn)行對(duì)稱加密，這樣數(shù)據(jù)就變成了密文。

服務(wù)器將加密后的密文返回給客戶端。

客戶端收到服務(wù)器發(fā)返回的密文，用自己的密鑰（客戶端密鑰）對(duì)其進(jìn)行對(duì)稱解密，得到服務(wù)器返回的數(shù)據(jù)。

12. 對(duì)稱加密與非對(duì)稱加密有什么區(qū)別

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

非對(duì)稱加密：非對(duì)稱加密算法需要兩個(gè)密鑰（公開密鑰和私有密鑰）。公鑰與私鑰是成對(duì)存在的，如果用公鑰對(duì)數(shù)據(jù)進(jìn)行加密，只有對(duì)應(yīng)的私鑰才能解密。

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

XSS 攻擊，全稱?跨站腳本攻擊（Cross-Site Scripting）?，這會(huì)與層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，因此有人將跨站腳本攻擊縮寫為XSS。它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當(dāng)用戶瀏覽該頁之時(shí)，嵌入其中Web里面的html代碼會(huì)被執(zhí)行，從而達(dá)到惡意攻擊用戶的特殊目的。XSS攻擊一般分三種類型：?存儲(chǔ)型 、反射型 、DOM型XSS

XSS是如何攻擊的？

拿反射型舉個(gè)例子吧，流程圖如下：

如何解決XSS攻擊問題

14. 請(qǐng)?jiān)敿?xì)介紹一下TCP 的三次握手機(jī)制

開始客戶端和服務(wù)器都處于 CLOSED 狀態(tài)，然后服務(wù)端開始監(jiān)聽某個(gè)端口，進(jìn)入 LISTEN 狀態(tài)

第一次握手(SYN=1, seq=x)，發(fā)送完畢后，客戶端進(jìn)入 SYN_SEND 狀態(tài)

第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1)， 發(fā)送完畢后，服務(wù)器端進(jìn)入 SYN_RCV狀態(tài)。

第三次握手(ACK=1，ACKnum=y+1)，發(fā)送完畢后，客戶端進(jìn)入 ESTABLISHED 狀態(tài)，當(dāng)服務(wù)器端接收到這個(gè)包時(shí)

15. TCP握手為什么是三次，不能是兩次？不能是四次？

TCP握手為什么是三次呢？為了方便理解，我們以談戀愛為個(gè)例子：兩個(gè)人能走到一起，最重要的事情就是相愛，就是?我愛你，并且我知道，你也愛我?，接下來我們以此來模擬三次握手的過程：

為什么握手不能是兩次呢？

如果只有兩次握手，女孩子可能就不知道，她的那句?我也愛你?，男孩子是否?收到?，戀愛關(guān)系就不能愉快展開。

為什么握手不能是四次呢？

因?yàn)槲帐植荒苁撬拇文?？因?yàn)槿我呀?jīng)夠了，三次已經(jīng)能讓雙方都知道：你愛我，我也愛你。而四次就多余了。

16. TCP四次揮手過程?

第一次揮手(FIN=1，seq=u)，發(fā)送完畢后，客戶端進(jìn)入FIN_WAIT_1 狀態(tài)

第二次揮手(ACK=1，ack=u+1,seq =v)，發(fā)送完畢后，服務(wù)器端進(jìn)入CLOSE_WAIT 狀態(tài)，客戶端接收到這個(gè)確認(rèn)包之后，進(jìn)入 FIN_WAIT_2 狀態(tài)

第三次揮手(FIN=1，ACK1,seq=w,ack=u+1)，發(fā)送完畢后，服務(wù)器端進(jìn)入LAST_ACK 狀態(tài)，等待來自客戶端的最后一個(gè)ACK。

第四次揮手(ACK=1，seq=u+1,ack=w+1)，客戶端接收到來自服務(wù)器端的關(guān)閉請(qǐng)求，發(fā)送一個(gè)確認(rèn)包，并進(jìn)入 TIME_WAIT狀態(tài)，?等待了某個(gè)固定時(shí)間（兩個(gè)最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后?，沒有收到服務(wù)器端的 ACK ，認(rèn)為服務(wù)器端已經(jīng)正常關(guān)閉連接，于是自己也關(guān)閉連接，進(jìn)入 CLOSED 狀態(tài)。服務(wù)器端接收到這個(gè)確認(rèn)包之后，關(guān)閉連接，進(jìn)入 CLOSED 狀態(tài)。

17. TCP四次揮手過程中，客戶端為什么需要等待 2MSL,才進(jìn)入CLOSED狀態(tài)

2MSL，2 Maximum Segment Lifetime，即兩個(gè)最大段生命周期

1個(gè) MSL 保證四次揮手中主動(dòng)關(guān)閉方最后的 ACK 報(bào)文能最終到達(dá)對(duì)端

1個(gè) MSL 保證對(duì)端沒有收到 ACK 那么進(jìn)行重傳的 FIN 報(bào)文能夠到達(dá)

18. 為什么需要四次揮手？

舉個(gè)例子吧

小明和小紅打電話聊天，通話差不多要結(jié)束時(shí)，小紅說“我沒啥要說的了”，小明回答“我知道了”。但是小明可能還會(huì)有要說的話，小紅不能要求小明跟著自己的節(jié)奏結(jié)束通話，于是小明可能又嘰嘰歪歪說了一通，最后小明說“我說完了”，小紅回答“知道了”，這樣通話才算結(jié)束。

19. Session和Cookie的區(qū)別。

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

Cookie是服務(wù)器發(fā)送到用戶瀏覽器，并保存在瀏覽器本地的一小塊文本串?dāng)?shù)據(jù)。它會(huì)在瀏覽器下次向同一服務(wù)器再發(fā)起請(qǐng)求時(shí)，被攜帶發(fā)送到服務(wù)器。通常，它用于告知服務(wù)端兩個(gè)請(qǐng)求是否來自同一瀏覽器，一樣用于保持用戶的登錄狀態(tài)等。Cookie使基于無狀態(tài)的 HTTP 協(xié)議記錄穩(wěn)定的狀態(tài)信息成為了可能。

session指的就是服務(wù)器和客戶端一次會(huì)話的過程。 Session利用Cookie進(jìn)行信息處理的，當(dāng)用戶首先進(jìn)行了請(qǐng)求后，服務(wù)端就在用戶瀏覽器上創(chuàng)建了一個(gè)Cookie，當(dāng)這個(gè)Session結(jié)束時(shí)，其實(shí)就是意味著這個(gè)Cookie就過期了。Session對(duì)象存儲(chǔ)著特定用戶會(huì)話所需的屬性及配置信息。

Session 和 Cookie 到底有什么不同呢？

存儲(chǔ)位置不一樣，Cookie 保存在客戶端，Session 保存在服務(wù)器端。

存儲(chǔ)數(shù)據(jù)類型不一樣，Cookie 只能保存ASCII，Session可以存任意數(shù)據(jù)類型，一般情況下我們可以在 Session 中保持一些常用變量信息，比如說 UserId 等。

有效期不同，Cookie 可設(shè)置為長(zhǎng)時(shí)間保持，比如我們經(jīng)常使用的默認(rèn)登錄功能，Session 一般有效時(shí)間較短，客戶端關(guān)閉或者 Session 超時(shí)都會(huì)失效。

隱私策略不同，Cookie 存儲(chǔ)在客戶端，比較容易遭到不法獲取，早期有人將用戶的登錄名和密碼存儲(chǔ)在 Cookie 中導(dǎo)致信息被竊??；Session 存儲(chǔ)在服務(wù)端，安全性相對(duì) Cookie 要好一些。

存儲(chǔ)大小不同， 單個(gè)Cookie保存的數(shù)據(jù)不能超過4K，Session可存儲(chǔ)數(shù)據(jù)遠(yuǎn)高于 Cookie。

來看個(gè)圖吧：

用戶第一次請(qǐng)求服務(wù)器時(shí)，服務(wù)器根據(jù)用戶提交的信息，創(chuàng)建對(duì)應(yīng)的Session ，請(qǐng)求返回時(shí)將此Session的唯一標(biāo)識(shí)信息 SessionID 返回給瀏覽器，瀏覽器接收到服務(wù)器返回的SessionID信息后，會(huì)將此信息存入Cookie 中，同時(shí) Cookie 記錄此SessionID 屬于哪個(gè)域名。

當(dāng)用戶第二次訪問服務(wù)器時(shí)，請(qǐng)求會(huì)自動(dòng)判斷此域名下是否存在Cookie信息，如果存在，則自動(dòng)將Cookie信息也發(fā)送給服務(wù)端，服務(wù)端會(huì)從Cookie中獲取 SessionID，再根據(jù) SessionID 查找對(duì)應(yīng)的 Session 信息，如果沒有找到說明用戶沒有登錄或者登錄失效，如果找到 Session 證明用戶已經(jīng)登錄可執(zhí)行后面操作。

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

首先，TCP的連接是基于?三次握手?，而斷開則是?四次揮手?。確保連接和斷開的可靠性。

其次，TCP的可靠性，還體現(xiàn)在?有狀態(tài)?;TCP會(huì)記錄哪些數(shù)據(jù)發(fā)送了，哪些數(shù)據(jù)被接受了，哪些沒有被接受，并且保證數(shù)據(jù)包按序到達(dá)，保證數(shù)據(jù)傳輸不出差錯(cuò)。

再次，TCP的可靠性，還體現(xiàn)在?可控制?。它有數(shù)據(jù)包校驗(yàn)、ACK應(yīng)答、?超時(shí)重傳(發(fā)送方)?、失序數(shù)據(jù)重傳（接收方）、丟棄重復(fù)數(shù)據(jù)、流量控制（滑動(dòng)窗口）和擁塞控制等機(jī)制。

21. TCP 和 UDP 的區(qū)別

TCP面向連接（（如打電話要先撥號(hào)建立連接）;UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。

TCP要求安全性，提供可靠的服務(wù)，通過TCP連接傳送的數(shù)據(jù)，不丟失、不重復(fù)、安全可靠。而UDP盡最大努力交付，即不保證可靠交付。

TCP是點(diǎn)對(duì)點(diǎn)連接的，UDP一對(duì)一，一對(duì)多，多對(duì)多都可以

TCP傳輸效率相對(duì)較低,而UDP傳輸效率高，它適用于對(duì)高速傳輸和實(shí)時(shí)性有較高的通信或廣播通信。

TCP適合用于網(wǎng)頁，郵件等;UDP適合用于視頻，語音廣播等

TCP面向字節(jié)流，UDP面向報(bào)文

22. TCP報(bào)文首部有哪些字段，說說其作用

16位端口號(hào)?：源端口號(hào)，主機(jī)該報(bào)文段是來自哪里；目標(biāo)端口號(hào)，要傳給哪個(gè)上層協(xié)議或應(yīng)用程序

32位序號(hào)?：一次TCP通信（從TCP連接建立到斷開）過程中某一個(gè)傳輸方向上的字節(jié)流的每個(gè)字節(jié)的編號(hào)。

32位確認(rèn)號(hào)?：用作對(duì)另一方發(fā)送的tcp報(bào)文段的響應(yīng)。其值是收到的TCP報(bào)文段的序號(hào)值加1。

4位頭部長(zhǎng)度?：表示tcp頭部有多少個(gè)32bit字（4字節(jié)）。因?yàn)?位最大能標(biāo)識(shí)15，所以TCP頭部最長(zhǎng)是60字節(jié)。

6位標(biāo)志位?：URG(緊急指針是否有效)，ACk（表示確認(rèn)號(hào)是否有效），PSH（緩沖區(qū)尚未填滿），RST（表示要求對(duì)方重新建立連接），SYN（建立連接消息標(biāo)志接），F(xiàn)IN（表示告知對(duì)方本端要關(guān)閉連接了）

16位窗口大小?：是TCP流量控制的一個(gè)手段。這里說的窗口，指的是接收通告窗口。它告訴對(duì)方本端的TCP接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù)，這樣對(duì)方就可以控制發(fā)送數(shù)據(jù)的速度。

16位校驗(yàn)和?：由發(fā)送端填充，接收端對(duì)TCP報(bào)文段執(zhí)行CRC算法以檢驗(yàn)TCP報(bào)文段在傳輸過程中是否損壞。注意，這個(gè)校驗(yàn)不僅包括TCP頭部，也包括數(shù)據(jù)部分。這也是TCP可靠傳輸?shù)囊粋€(gè)重要保障。

16位緊急指針?：一個(gè)正的偏移量。它和序號(hào)字段的值相加表示最后一個(gè)緊急數(shù)據(jù)的下一字節(jié)的序號(hào)。因此，確切地說，這個(gè)字段是緊急指針相對(duì)當(dāng)前序號(hào)的偏移，不妨稱之為緊急偏移。TCP的緊急指針是發(fā)送端向接收端發(fā)送緊急數(shù)據(jù)的方法。

23. HTTP狀態(tài)碼301和302的區(qū)別？

301（永久移動(dòng)）請(qǐng)求的網(wǎng)頁已被永久移動(dòng)到新位置。服務(wù)器返回此響應(yīng)（作為對(duì)GET或HEAD請(qǐng)求的響應(yīng)）時(shí)，會(huì)自動(dòng)將請(qǐng)求者轉(zhuǎn)到新位置。

302：（臨時(shí)移動(dòng)）服務(wù)器目前正從不同位置的網(wǎng)頁響應(yīng)請(qǐng)求，但請(qǐng)求者應(yīng)繼續(xù)使用原有位置來進(jìn)行以后的請(qǐng)求。此代碼與響應(yīng)GET和HEAD請(qǐng)求的301代碼類似，會(huì)自動(dòng)將請(qǐng)求者轉(zhuǎn)到不同的位置。

HTTP狀態(tài)碼301與302的區(qū)別：

它們之間關(guān)鍵區(qū)別在，資源是否存在有效性；

301資源還在只是換了一個(gè)位置，返回的是新位置的內(nèi)容；

302資源暫時(shí)失效，返回的是一個(gè)臨時(shí)的代替頁上。

24. 聊聊TCP 的重傳機(jī)制

超時(shí)重傳

TCP 為了實(shí)現(xiàn)可靠傳輸，實(shí)現(xiàn)了重傳機(jī)制。最基本的重傳機(jī)制，就是?超時(shí)重傳?，即在發(fā)送數(shù)據(jù)報(bào)文時(shí)，設(shè)定一個(gè)定時(shí)器，每間隔一段時(shí)間，沒有收到對(duì)方的ACK確認(rèn)應(yīng)答報(bào)文，就會(huì)重發(fā)該報(bào)文。

這個(gè)間隔時(shí)間，一般設(shè)置為多少呢？我們先來看下什么叫?RTT（Round-Trip Time，往返時(shí)間）?。

RTT就是，一個(gè)數(shù)據(jù)包從發(fā)出去到回來的時(shí)間，即?數(shù)據(jù)包的一次往返時(shí)間?。超時(shí)重傳時(shí)間，就是Retransmission Timeout ，簡(jiǎn)稱?RTO?。

RTO設(shè)置多久呢？

如果RTO比較小，那很可能數(shù)據(jù)都沒有丟失，就重發(fā)了，這會(huì)導(dǎo)致網(wǎng)絡(luò)阻塞，會(huì)導(dǎo)致更多的超時(shí)出現(xiàn)。

如果RTO比較大，等到花兒都謝了還是沒有重發(fā)，那效果就不好了。

一般情況下，RTO略大于RTT，效果是最好的。一些小伙伴會(huì)問，超時(shí)時(shí)間有沒有計(jì)算公式呢?有的！有個(gè)標(biāo)準(zhǔn)方法算RTO的公式，也叫?Jacobson / Karels 算法?。我們一起來看下計(jì)算RTO的公式

1. 先計(jì)算SRTT（計(jì)算平滑的RTT）

SRTT = (1 - α) * SRTT + α * RTT? //求 SRTT 的加權(quán)平均

復(fù)制代碼

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

RTTVAR = (1 - β) * RTTVAR + β * (|RTT - SRTT|) //計(jì)算 SRTT 與真實(shí)值的差距

復(fù)制代碼

3. 最終的RTO

RTO = μ * SRTT + ? * RTTVAR? =? SRTT + 4·RTTVAR?

復(fù)制代碼

其中，?α = 0.125，β = 0.25， μ = 1，? = 4?，這些參數(shù)都是大量結(jié)果得出的最優(yōu)參數(shù)。

但是，超時(shí)重傳會(huì)有這些缺點(diǎn)：

當(dāng)一個(gè)報(bào)文段丟失時(shí)，會(huì)等待一定的超時(shí)周期然后才重傳分組，增加了端到端的時(shí)延。

當(dāng)一個(gè)報(bào)文段丟失時(shí)，在其等待超時(shí)的過程中，可能會(huì)出現(xiàn)這種情況：其后的報(bào)文段已經(jīng)被接收端接收但卻遲遲得不到確認(rèn)，發(fā)送端會(huì)認(rèn)為也丟失了，從而引起不必要的重傳，既浪費(fèi)資源也浪費(fèi)時(shí)間。

并且，TCP有個(gè)策略，就是超時(shí)時(shí)間間隔會(huì)加倍。超時(shí)重傳需要?等待很長(zhǎng)時(shí)間?。因此，還可以使用?快速重傳?機(jī)制。

快速重傳

快速重傳機(jī)制，它不以時(shí)間驅(qū)動(dòng)，而是以數(shù)據(jù)驅(qū)動(dòng)。它基于接收端的反饋信息來引發(fā)重傳。

一起來看下快速重傳流程：

發(fā)送端發(fā)送了 1，2，3，4，5,6 份數(shù)據(jù):

第一份 Seq=1 先送到了，于是就 Ack 回 2；

第二份 Seq=2 也送到了，假設(shè)也正常，于是ACK 回 3；

第三份 Seq=3 由于網(wǎng)絡(luò)等其他原因，沒送到；

第四份 Seq=4 也送到了，但是因?yàn)镾eq3沒收到。所以ACK回3；

后面的 Seq=4,5的也送到了，但是ACK還是回復(fù)3，因?yàn)镾eq=3沒收到。

發(fā)送端連著收到三個(gè)重復(fù)冗余ACK=3的確認(rèn)（實(shí)際上是4個(gè)，但是前面一個(gè)是正常的ACK，后面三個(gè)才是重復(fù)冗余的），便知道哪個(gè)報(bào)文段在傳輸過程中丟失了，于是在定時(shí)器過期之前，重傳該報(bào)文段。

最后，接收到收到了 Seq3，此時(shí)因?yàn)?Seq=4，5，6都收到了，于是ACK回7.

但?快速重傳?還可能會(huì)有個(gè)問題：ACK只向發(fā)送端告知最大的有序報(bào)文段，到底是哪個(gè)報(bào)文丟失了呢？?并不確定?！那到底該重傳多少個(gè)包呢？

是重傳 Seq3 呢？還是重傳 Seq3、Seq4、Seq5、Seq6 呢？因?yàn)榘l(fā)送端并不清楚這三個(gè)連續(xù)的 ACK3 是誰傳回來的。

帶選擇確認(rèn)的重傳（SACK）

為了解決快速重傳的問題：?應(yīng)該重傳多少個(gè)包?? TCP提供了?SACK方法?（帶選擇確認(rèn)的重傳，Selective Acknowledgment）。

SACK機(jī)制就是，在快速重傳的基礎(chǔ)上，接收端返回最近收到的報(bào)文段的序列號(hào)范圍，這樣發(fā)送端就知道接收端哪些數(shù)據(jù)包沒收到，醬紫就很清楚該重傳哪些數(shù)據(jù)包啦。SACK標(biāo)記是加在TCP頭部?選項(xiàng)?字段里面的。

如上圖中，發(fā)送端收到了三次同樣的ACK=30的確認(rèn)報(bào)文，于是就會(huì)觸發(fā)快速重發(fā)機(jī)制，通過SACK信息發(fā)現(xiàn)只有?30~39?這段數(shù)據(jù)丟失，于是重發(fā)時(shí)就只選擇了這個(gè)?30~39?的TCP報(bào)文段進(jìn)行重發(fā)。

D-SACK

D-SACK，即Duplicate SACK（重復(fù)SACK），在SACK的基礎(chǔ)上做了一些擴(kuò)展，，主要用來告訴發(fā)送方，有哪些數(shù)據(jù)包自己重復(fù)接受了。DSACK的目的是幫助發(fā)送方判斷，是否發(fā)生了包失序、ACK丟失、包重復(fù)或偽重傳。讓TCP可以更好的做網(wǎng)絡(luò)流控。來看個(gè)圖吧：

25. IP地址有哪些分類？

一句話概括，IP地址 = 網(wǎng)絡(luò)號(hào)+主機(jī)號(hào)。

網(wǎng)絡(luò)號(hào)：它標(biāo)志主機(jī)（或路由器）所連接到的網(wǎng)絡(luò)，網(wǎng)絡(luò)地址表示屬于互聯(lián)網(wǎng)的哪一個(gè)網(wǎng)絡(luò)

主機(jī)號(hào)：它標(biāo)志該主機(jī)（或路由器），主機(jī)地址表示其屬于該網(wǎng)絡(luò)中的哪一臺(tái)主機(jī)

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

A類地址(1~126)：以0開頭，網(wǎng)絡(luò)號(hào)占前8位，主機(jī)號(hào)占后24位。

B類地址(128~191)：以10開頭，網(wǎng)絡(luò)號(hào)占前16位，主機(jī)號(hào)占后16位。

C類地址(192~223)：以110開頭，網(wǎng)絡(luò)號(hào)占前24位，主機(jī)號(hào)占后8位。

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

E類地址(240~255)：以11110開頭，保留位為將來使用

26. 聊聊TCP的滑動(dòng)窗口

TCP 發(fā)送一個(gè)數(shù)據(jù)，需要收到確認(rèn)應(yīng)答，才會(huì)發(fā)送下一個(gè)數(shù)據(jù)。這樣有個(gè)缺點(diǎn)，就是效率會(huì)比較低。

這就好像我們面對(duì)面聊天，你說完一句，我應(yīng)答后，你才會(huì)說下一句。那么，如果我在忙其他事情，沒有能夠及時(shí)回復(fù)你。你說完一句后，要等到我忙完回復(fù)你，你才說下句，這顯然很不現(xiàn)實(shí)。

為了解決這個(gè)問題，TCP引入了?窗口?，它是操作系統(tǒng)開辟的一個(gè)緩存空間。窗口大小值表示無需等待確認(rèn)應(yīng)答，而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值。

TCP頭部有個(gè)字段叫win，也即那個(gè)?16位的窗口大小?，它告訴對(duì)方本端的TCP接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù)，這樣對(duì)方就可以控制發(fā)送數(shù)據(jù)的速度，從而達(dá)到?流量控制?的目的。

通俗點(diǎn)講，就是接受方每次收到數(shù)據(jù)包，在發(fā)送確認(rèn)報(bào)文的時(shí)候，同時(shí)告訴發(fā)送方，自己的緩存區(qū)還有多少空余空間，緩沖區(qū)的空余空間，我們就稱之為接受窗口大小。這就是win。

TCP 滑動(dòng)窗口分為兩種: 發(fā)送窗口和接收窗口。?發(fā)送端的滑動(dòng)窗口?包含四大部分，如下：

已發(fā)送且已收到ACK確認(rèn)

已發(fā)送但未收到ACK確認(rèn)

未發(fā)送但可以發(fā)送

未發(fā)送也不可以發(fā)送

虛線矩形框，就是發(fā)送窗口。

SND.WND: 表示發(fā)送窗口的大小,上圖虛線框的格子數(shù)就是14個(gè)。

SND.UNA: 一個(gè)絕對(duì)指針，它指向的是已發(fā)送但未確認(rèn)的第一個(gè)字節(jié)的序列號(hào)。

SND.NXT：下一個(gè)發(fā)送的位置，它指向未發(fā)送但可以發(fā)送的第一個(gè)字節(jié)的序列號(hào)。

接收方的滑動(dòng)窗口包含三大部分，如下：

已成功接收并確認(rèn)

未收到數(shù)據(jù)但可以接收

未收到數(shù)據(jù)并不可以接收的數(shù)據(jù)

虛線矩形框，就是接收窗口。

REV.WND: 表示接收窗口的大小,上圖虛線框的格子就是9個(gè)。

REV.NXT:下一個(gè)接收的位置，它指向未收到但可以接收的第一個(gè)字節(jié)的序列號(hào)。

27. 聊聊五層計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)中，每一層對(duì)應(yīng)的網(wǎng)絡(luò)協(xié)議有哪些？

28. 聊聊TCP的流量控制

TCP三次握手，發(fā)送端和接收端進(jìn)入到ESTABLISHED狀態(tài)，它們即可以愉快地傳輸數(shù)據(jù)啦。

但是發(fā)送端不能瘋狂地向接收端發(fā)送數(shù)據(jù)，因?yàn)榻邮斩私邮詹贿^來的話，接收方只能把處理不過來的數(shù)據(jù)存在緩存區(qū)里。如果緩存區(qū)都滿了，發(fā)送方還在瘋狂發(fā)送數(shù)據(jù)的話，接收方只能把收到的數(shù)據(jù)包丟掉，這就浪費(fèi)了網(wǎng)絡(luò)資源啦。

TCP 提供一種機(jī)制可以讓發(fā)送端根據(jù)接收端的實(shí)際接收能力控制發(fā)送的數(shù)據(jù)量，這就是?流量控制?。

TCP通過滑動(dòng)窗口來控制流量，我們看下流量控制的?簡(jiǎn)要流程?吧：

首先雙方三次握手，初始化各自的窗口大小，均為 400 個(gè)字節(jié)。

SND.NXT

29. 說下ARP 協(xié)議的工作原理？

ARP 協(xié)議協(xié)議，即?Address Resolution Protocol?，地址解析協(xié)議，用于實(shí)現(xiàn)IP地址到MAC地址的映射。

首先，每臺(tái)主機(jī)都會(huì)在自己的 ARP 緩沖區(qū)中建立一個(gè) ARP 列表，以表示 IP 地址和 MAC 地址的對(duì)應(yīng)關(guān)系。

當(dāng)源主機(jī)需要將一個(gè)數(shù)據(jù)包要發(fā)送到目的主機(jī)時(shí)，會(huì)首先檢查自己的ARP列表，是否存在該IP地址對(duì)應(yīng)的MAC地址；如果存在﹐就直接將數(shù)據(jù)包發(fā)送到這個(gè)MAC地址；如果不存在，就向本地網(wǎng)段發(fā)起一個(gè)ARP請(qǐng)求的廣播包，查詢此目的主機(jī)對(duì)應(yīng)的MAC地址。此ARP請(qǐng)求的數(shù)據(jù)包里，包括源主機(jī)的IP地址、硬件地址、以及目的主機(jī)的IP地址。

網(wǎng)絡(luò)中所有的主機(jī)收到這個(gè)ARP請(qǐng)求后，會(huì)檢查數(shù)據(jù)包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此數(shù)據(jù)包；如果相同，該主機(jī)首先將發(fā)送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已經(jīng)存在該IP的信息，則將其覆蓋，然后給源主機(jī)發(fā)送一個(gè) ARP響應(yīng)數(shù)據(jù)包，告訴對(duì)方自己是它需要查找的MAC地址。

源主機(jī)收到這個(gè)ARP響應(yīng)數(shù)據(jù)包后，將得到的目的主機(jī)的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息開始數(shù)據(jù)的傳輸。如果源主機(jī)一直沒有收到ARP響應(yīng)數(shù)據(jù)包，表示ARP查詢失敗。

30. 說下TCP的擁塞控制

擁塞控制是?作用于網(wǎng)絡(luò)的，防止過多的數(shù)據(jù)包注入到網(wǎng)絡(luò)中，避免出現(xiàn)網(wǎng)絡(luò)負(fù)載過大的情況?。它的目標(biāo)主要是最大化利用網(wǎng)絡(luò)上瓶頸鏈路的帶寬。它跟?流量控制?又有什么區(qū)別呢？流量控制是作用于接收者的，根據(jù)?接收端的實(shí)際接收能力控制發(fā)送速度?，防止分組丟失的。

我們可以把網(wǎng)絡(luò)鏈路比喻成一根水管，如果我們想最大化利用網(wǎng)絡(luò)來傳輸數(shù)據(jù)，那就是盡快讓水管達(dá)到最佳充滿狀態(tài)。

發(fā)送方維護(hù)一個(gè)?擁塞窗口cwnd（congestion window）?的變量，用來估算在一段時(shí)間內(nèi)這條鏈路（水管）可以承載和運(yùn)輸?shù)臄?shù)據(jù)（水）的數(shù)量。它大小代表著網(wǎng)絡(luò)的擁塞程度，并且是動(dòng)態(tài)變化的，但是為了達(dá)到最大的傳輸效率，我們?cè)撊绾沃肋@條水管的運(yùn)送效率是多少呢？

一個(gè)比較簡(jiǎn)單的方法就是不斷增加傳輸?shù)乃?，直到水管快要爆裂為止（?duì)應(yīng)到網(wǎng)絡(luò)上就是發(fā)生丟包），用 TCP 的描述就是：

只要網(wǎng)絡(luò)中沒有出現(xiàn)擁塞，擁塞窗口的值就可以再增大一些，以便把更多的數(shù)據(jù)包發(fā)送出去，但只要網(wǎng)絡(luò)出現(xiàn)擁塞，擁塞窗口的值就應(yīng)該減小一些，以減少注入到網(wǎng)絡(luò)中的數(shù)據(jù)包數(shù)。

實(shí)際上，擁塞控制主要有這幾種常用算法

慢啟動(dòng)

擁塞避免

擁塞發(fā)生

快速恢復(fù)

慢啟動(dòng)算法

慢啟動(dòng)算法，表面意思就是，別急慢慢來。它表示TCP建立連接完成后，一開始不要發(fā)送大量的數(shù)據(jù)，而是先探測(cè)一下網(wǎng)絡(luò)的擁塞程度。由小到大逐漸增加擁塞窗口的大小，如果沒有出現(xiàn)丟包，?每收到一個(gè)ACK，就將擁塞窗口cwnd大小就加1（單位是MSS）?。?每輪次?發(fā)送窗口增加一倍，呈指數(shù)增長(zhǎng)，如果出現(xiàn)丟包，擁塞窗口就減半，進(jìn)入擁塞避免階段。

TCP連接完成，初始化cwnd = 1，表明可以傳一個(gè)MSS單位大小的數(shù)據(jù)。

每當(dāng)收到一個(gè)ACK，cwnd就加一;

每當(dāng)過了一個(gè)RTT，cwnd就增加一倍; 呈指數(shù)讓升

為了防止cwnd增長(zhǎng)過大引起網(wǎng)絡(luò)擁塞，還需設(shè)置一個(gè)?慢啟動(dòng)閥值ssthresh?（slow start threshold）狀態(tài)變量。當(dāng)?cwnd?到達(dá)該閥值后，就好像水管被關(guān)小了水龍頭一樣，減少擁塞狀態(tài)。即當(dāng)?cwnd >ssthresh?時(shí)，進(jìn)入了?擁塞避免?算法。

擁塞避免算法

一般來說，慢啟動(dòng)閥值ssthresh是65535字節(jié)，?cwnd?到達(dá)?慢啟動(dòng)閥值?后

每收到一個(gè)ACK時(shí)，cwnd = cwnd + 1/cwnd

當(dāng)每過一個(gè)RTT時(shí)，cwnd = cwnd + 1

顯然這是一個(gè)線性上升的算法，避免過快導(dǎo)致網(wǎng)絡(luò)擁塞問題。

擁塞發(fā)生

當(dāng)網(wǎng)絡(luò)擁塞發(fā)生?丟包?時(shí)，會(huì)有兩種情況：

RTO超時(shí)重傳

快速重傳

如果是發(fā)生了?RTO超時(shí)重傳?，就會(huì)使用擁塞發(fā)生算法

慢啟動(dòng)閥值sshthresh = cwnd /2

cwnd 重置為 1

進(jìn)入新的慢啟動(dòng)過程

這真的是?辛辛苦苦幾十年，一朝回到解放前?。其實(shí)還有更好的處理方式，就是?快速重傳?。發(fā)送方收到3個(gè)連續(xù)重復(fù)的ACK時(shí)，就會(huì)快速地重傳，不必等待?RTO超時(shí)?再重傳。

慢啟動(dòng)閥值ssthresh 和 cwnd 變化如下：

擁塞窗口大小 cwnd = cwnd/2

慢啟動(dòng)閥值 ssthresh = cwnd

進(jìn)入快速恢復(fù)算法

快速恢復(fù)

快速重傳和快速恢復(fù)算法一般同時(shí)使用?？焖倩謴?fù)算法認(rèn)為，還有3個(gè)重復(fù)ACK收到，說明網(wǎng)絡(luò)也沒那么糟糕，所以沒有必要像RTO超時(shí)那么強(qiáng)烈。

正如前面所說，進(jìn)入快速恢復(fù)之前，cwnd 和 sshthresh已被更新：

- cwnd = cwnd /2- sshthresh = cwnd復(fù)制代碼

然后，真正的快速算法如下：

cwnd = sshthresh + 3

重傳重復(fù)的那幾個(gè)ACK（即丟失的那幾個(gè)數(shù)據(jù)包）

如果再收到重復(fù)的 ACK，那么 cwnd = cwnd +1

如果收到新數(shù)據(jù)的 ACK 后, cwnd = sshthresh。因?yàn)槭盏叫聰?shù)據(jù)的 ACK，表明恢復(fù)過程已經(jīng)結(jié)束，可以再次進(jìn)入了擁塞避免的算法了。

31. TCP 和 UDP 分別對(duì)應(yīng)的常見應(yīng)用層協(xié)議有哪些？

基于TCP的應(yīng)用層協(xié)議有：HTTP、FTP、SMTP、TELNET、SSH

HTTP?：HyperText Transfer Protocol（超文本傳輸協(xié)議），默認(rèn)端口80

FTP?: File Transfer Protocol (文件傳輸協(xié)議), 默認(rèn)端口(20用于傳輸數(shù)據(jù)，21用于傳輸控制信息)

SMTP?: Simple Mail Transfer Protocol (簡(jiǎn)單郵件傳輸協(xié)議) ,默認(rèn)端口25

TELNET?: Teletype over the Network (網(wǎng)絡(luò)電傳), 默認(rèn)端口23

SSH?： Secure Shell（安全外殼協(xié)議），默認(rèn)端口 22

基于UDP的應(yīng)用層協(xié)議：DNS、TFTP、SNMP

DNS?: Domain Name Service (域名服務(wù)),默認(rèn)端口 53

TFTP?: Trivial File Transfer Protocol (簡(jiǎn)單文件傳輸協(xié)議)，默認(rèn)端口69

SNMP?：Simple Network Management Protocol（簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議），通過UDP端口161接收，只有Trap信息采用UDP端口162。

32. 半連接隊(duì)列和 SYN Flood 攻擊的關(guān)系

TCP進(jìn)入三次握手前，服務(wù)端會(huì)從?CLOSED?狀態(tài)變?yōu)?LISTEN?狀態(tài),同時(shí)在內(nèi)部創(chuàng)建了兩個(gè)隊(duì)列：半連接隊(duì)列（SYN隊(duì)列）和全連接隊(duì)列（ACCEPT隊(duì)列）。

什么是?半連接隊(duì)列（SYN隊(duì)列）?呢? 什么是?全連接隊(duì)列（ACCEPT隊(duì)列）?呢？回憶下TCP三次握手的圖：

TCP三次握手時(shí)，客戶端發(fā)送SYN到服務(wù)端，服務(wù)端收到之后，便回復(fù)?ACK和SYN?，狀態(tài)由?LISTEN變?yōu)镾YN_RCVD?，此時(shí)這個(gè)連接就被推入了?SYN隊(duì)列?，即半連接隊(duì)列。

當(dāng)客戶端回復(fù)ACK, 服務(wù)端接收后，三次握手就完成了。這時(shí)連接會(huì)等待被具體的應(yīng)用取走，在被取走之前，它被推入ACCEPT隊(duì)列，即全連接隊(duì)列。

SYN Flood是一種典型的DoS (Denial of Service，拒絕服務(wù)) 攻擊，它在短時(shí)間內(nèi)，偽造?不存在的IP地址?,向服務(wù)器大量發(fā)起SYN報(bào)文。當(dāng)服務(wù)器回復(fù)SYN+ACK報(bào)文后，不會(huì)收到ACK回應(yīng)報(bào)文，導(dǎo)致服務(wù)器上建立大量的半連接半連接隊(duì)列滿了，這就無法處理正常的TCP請(qǐng)求啦。

主要有?syn cookie?和?SYN Proxy防火墻?等方案應(yīng)對(duì)。

syn cookie：在收到SYN包后，服務(wù)器根據(jù)一定的方法，以數(shù)據(jù)包的源地址、端口等信息為參數(shù)計(jì)算出一個(gè)cookie值作為自己的SYNACK包的序列號(hào)，回復(fù)SYN+ACK后，服務(wù)器并不立即分配資源進(jìn)行處理，等收到發(fā)送方的ACK包后，重新根據(jù)數(shù)據(jù)包的源地址、端口計(jì)算該包中的確認(rèn)序列號(hào)是否正確，如果正確則建立連接，否則丟棄該包。

SYN Proxy防火墻：服務(wù)器防火墻會(huì)對(duì)收到的每一個(gè)SYN報(bào)文進(jìn)行代理和回應(yīng)，并保持半連接。等發(fā)送方將ACK包返回后，再重新構(gòu)造SYN包發(fā)到服務(wù)器，建立真正的TCP連接。

33. 有了IP地址，為什么還要用MAC地址？

簡(jiǎn)而言之，標(biāo)識(shí)網(wǎng)絡(luò)中的一臺(tái)計(jì)算機(jī)，比較常用的就是?IP地址和MAC地址?，但計(jì)算機(jī)的IP地址可由用戶自行更改，管理起來就相對(duì)困難，而MAC地址不可更改，所以一般會(huì)把IP地址和MAC地址組合起來使用。

那只使用MAC地址不用IP地址行不行呢？不行的！因?yàn)樽钤缇褪荕AC地址先出現(xiàn)的，并且當(dāng)時(shí)并不用IP地址，只用MAC地址，后來隨著網(wǎng)絡(luò)中的設(shè)備越來越多，整個(gè)路由過程越來越復(fù)雜，便出現(xiàn)了子網(wǎng)的概念。對(duì)于目的地址在其他子網(wǎng)的數(shù)據(jù)包，路由只需要將數(shù)據(jù)包送到那個(gè)子網(wǎng)即可。

那為什么要用IP地址呢？是因?yàn)镮P地址是和地域相關(guān)的，對(duì)于同一個(gè)子網(wǎng)上的設(shè)備，IP地址的前綴都是一樣的，這樣路由器通過IP地址的前綴就知道設(shè)備在在哪個(gè)子網(wǎng)上了，而只用MAC地址的話，路由器則需要記住每個(gè)MAC地址在哪個(gè)子網(wǎng)，這需要路由器有極大的存儲(chǔ)空間，是無法實(shí)現(xiàn)的。

IP地址可以比作為地址，MAC地址為收件人，在一次通信過程中，兩者是缺一不可的。

34. 聊聊?；钣?jì)時(shí)器的作用

除時(shí)間等待計(jì)時(shí)器外，TCP 還有一個(gè)?；钣?jì)時(shí)器（keepalive timer）。設(shè)想這樣的場(chǎng)景：客戶已主動(dòng)與服務(wù)器建立了TCP連接。但后來客戶端的主機(jī)突然發(fā)生故障。顯然，服務(wù)器以后就不能再收到客戶端發(fā)來的數(shù)據(jù)。因此，應(yīng)當(dāng)有措施使服務(wù)器不要再白白等待下去。這就需要使用?；钣?jì)時(shí)器了。

服務(wù)器每收到一次客戶的數(shù)據(jù)，就重新設(shè)置保活計(jì)時(shí)器，時(shí)間的設(shè)置通常是兩個(gè)小時(shí)。若兩個(gè)小時(shí)都沒有收到客戶端的數(shù)據(jù)，服務(wù)端就發(fā)送一個(gè)探測(cè)報(bào)文段，以后則每隔 75秒鐘發(fā)送一次。若連續(xù)發(fā)送10個(gè)探測(cè)報(bào)文段后仍然無客戶端的響應(yīng)，服務(wù)端就認(rèn)為客戶端出了故障，接著就關(guān)閉這個(gè)連接。

35. 聊聊ARP協(xié)議

ARP協(xié)議，地址解析協(xié)議，是一個(gè)由IP地址獲取MAC物理地址的TCP/IP協(xié)議。

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

IP地址：是互聯(lián)網(wǎng)協(xié)議地址，它是IP協(xié)議提供的一種統(tǒng)一的地址格式，它為互聯(lián)網(wǎng)上的每一個(gè)網(wǎng)絡(luò)和每一臺(tái)主機(jī)分配一個(gè)邏輯地址，以此來屏蔽物理地址的差異。

MAC地址：以太網(wǎng)地址或物理地址，它是一個(gè)用來確認(rèn)網(wǎng)絡(luò)設(shè)備位置的位址。

為什么需要ARP協(xié)議呢？

在網(wǎng)絡(luò)訪問層中，同一局域網(wǎng)中的一臺(tái)主機(jī)要和另一臺(tái)主機(jī)進(jìn)行通信，需要通過MAC地址進(jìn)行定位，然后才能進(jìn)行數(shù)據(jù)包的發(fā)送。

而在網(wǎng)絡(luò)層和傳輸層中，計(jì)算機(jī)之間是通過IP地址定位目標(biāo)主機(jī)，對(duì)應(yīng)的數(shù)據(jù)報(bào)文只包含目標(biāo)主機(jī)的IP地址，而沒有 MAC 地址。

因此，在發(fā)送之前需要根據(jù)IP地址獲取 MAC 地址，然后才能將數(shù)據(jù)包發(fā)送到正確的目標(biāo)主機(jī)，而這個(gè)獲取過程是通過ARP協(xié)議完成的。

ARP的工作流程

當(dāng)主機(jī)A與主機(jī)B要通信時(shí)，工作流程如下：

查詢本地ARP緩存表,看是否有IP地址及其對(duì)應(yīng)的MAC地址。

如果沒匹配到主機(jī)B的MAC地址，主機(jī)A會(huì)在局域網(wǎng)內(nèi)廣播發(fā)送一個(gè)ARP請(qǐng)求分組，局域網(wǎng)內(nèi)所有主機(jī)都會(huì)收到該請(qǐng)求分組。

主機(jī)B收到請(qǐng)求分組報(bào)文，發(fā)現(xiàn)報(bào)文中的IP與自己匹配，就A的IP和MAC地址添加到本地ARP緩存表中。

主機(jī)B向主機(jī)A響應(yīng)一個(gè)含自身MAC地址的報(bào)文。

主機(jī)A收到報(bào)文后，將B的IP和MAC地址添加至ARP緩存表中。

36. TCP的粘包和拆包

TCP是面向流，沒有界限的一串?dāng)?shù)據(jù)。TCP底層并不了解上層業(yè)務(wù)數(shù)據(jù)的具體含義，它會(huì)根據(jù)TCP緩沖區(qū)的實(shí)際情況進(jìn)行包的劃分，所以在業(yè)務(wù)上認(rèn)為，一?個(gè)完整的包可能會(huì)被TCP拆分成多個(gè)包進(jìn)行發(fā)送?，?也有可能把多個(gè)小的包封裝成一個(gè)大的數(shù)據(jù)包發(fā)送?，這就是所謂的TCP粘包和拆包問題。

為什么會(huì)產(chǎn)生粘包和拆包呢?

要發(fā)送的數(shù)據(jù)小于TCP發(fā)送緩沖區(qū)的大小，TCP將多次寫入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去，將會(huì)發(fā)生粘包；

接收數(shù)據(jù)端的應(yīng)用層沒有及時(shí)讀取接收緩沖區(qū)中的數(shù)據(jù)，將發(fā)生粘包；

要發(fā)送的數(shù)據(jù)大于TCP發(fā)送緩沖區(qū)剩余空間大小，將會(huì)發(fā)生拆包；

待發(fā)送數(shù)據(jù)大于MSS（最大報(bào)文長(zhǎng)度），TCP在傳輸前將進(jìn)行拆包。即TCP報(bào)文長(zhǎng)度-TCP頭部長(zhǎng)度>MSS。

解決方案：

發(fā)送端將每個(gè)數(shù)據(jù)包封裝為固定長(zhǎng)度

在數(shù)據(jù)尾部增加特殊字符進(jìn)行分割

將數(shù)據(jù)分為兩部分，一部分是頭部，一部分是內(nèi)容體；其中頭部結(jié)構(gòu)大小固定，且有一個(gè)字段聲明內(nèi)容體的大小。

37. forward 和 redirect 的區(qū)別？

直接轉(zhuǎn)發(fā)方式（Forward）?，客戶端和瀏覽器只發(fā)出一次請(qǐng)求，Servlet、HTML、JSP或其它信息資源，由第二個(gè)信息資源響應(yīng)該請(qǐng)求，在請(qǐng)求對(duì)象request中，保存的對(duì)象對(duì)于每個(gè)信息資源是共享的。

間接轉(zhuǎn)發(fā)方式（Redirect）?實(shí)際是兩次HTTP請(qǐng)求，服務(wù)器端在響應(yīng)第一次請(qǐng)求的時(shí)候，讓瀏覽器再向另外一個(gè)URL發(fā)出請(qǐng)求，從而達(dá)到轉(zhuǎn)發(fā)的目的。

舉個(gè)通俗的例子：

直接轉(zhuǎn)發(fā)就相當(dāng)于：“A找B借錢，B說沒有，B去找C借，借到借不到都會(huì)把消息傳遞給A”；

間接轉(zhuǎn)發(fā)就相當(dāng)于："A找B借錢，B說沒有，讓A去找C借"。**

看這兩個(gè)圖，可以更容易理解一些:

Redirect 的工作原理：

forward 的工作原理

38. Nagle 算法與延遲確認(rèn)

Nagle算法

如果發(fā)送端瘋狂地向接收端發(fā)送很小的包，比如就1個(gè)字節(jié)，那么親愛的小伙伴，你們覺得會(huì)有什么問題呢？

TCP/IP協(xié)議中，無論發(fā)送多少數(shù)據(jù)，總是要在數(shù)據(jù)前面加上協(xié)議頭，同時(shí)，對(duì)方接收到數(shù)據(jù)，也需要發(fā)送ACK表示確認(rèn)。為了盡可能的利用網(wǎng)絡(luò)帶寬，TCP總是希望盡可能的發(fā)送足夠大的數(shù)據(jù)。?Nagle算法?就是為了盡可能發(fā)送大塊數(shù)據(jù)，避免網(wǎng)絡(luò)中充斥著許多小數(shù)據(jù)塊。

Nagle算法的基本定義是：?任意時(shí)刻，最多只能有一個(gè)未被確認(rèn)的小段?。 所謂“小段”，指的是小于MSS尺寸的數(shù)據(jù)塊，所謂“未被確認(rèn)”，是指一個(gè)數(shù)據(jù)塊發(fā)送出去后，沒有收到對(duì)方發(fā)送的ACK確認(rèn)該數(shù)據(jù)已收到。

Nagle算法的實(shí)現(xiàn)規(guī)則：

如果包長(zhǎng)度達(dá)到MSS，則允許發(fā)送；

如果該包含有FIN，則允許發(fā)送；

設(shè)置了TCP_NODELAY選項(xiàng)，則允許發(fā)送；

未設(shè)置TCP_CORK選項(xiàng)時(shí)，若所有發(fā)出去的小數(shù)據(jù)包（包長(zhǎng)度小于MSS）均被確認(rèn)，則允許發(fā)送；

上述條件都未滿足，但發(fā)生了超時(shí)（一般為200ms），則立即發(fā)送。

延遲確認(rèn)

如果接受方剛接收到發(fā)送方的數(shù)據(jù)包，在很短很短的時(shí)間內(nèi)，又接收到第二個(gè)包。那么請(qǐng)問接收方是一個(gè)一個(gè)地回復(fù)好點(diǎn)，還是合并一起回復(fù)好呢？

接收方收到數(shù)據(jù)包后，如果暫時(shí)沒有數(shù)據(jù)要發(fā)給對(duì)端，它可以等一段時(shí)再確認(rèn)（Linux上默認(rèn)是40ms）。如果這段時(shí)間剛好有數(shù)據(jù)要傳給對(duì)端，ACK就隨著數(shù)據(jù)傳輸，而不需要單獨(dú)發(fā)送一次ACK。如果超過時(shí)間還沒有數(shù)據(jù)要發(fā)送，也發(fā)送ACK，避免對(duì)端以為丟包。

但是有些場(chǎng)景不能延遲確認(rèn)，比如發(fā)現(xiàn)了?亂序包?、?接收到了大于一個(gè) frame 的報(bào)文，且需要調(diào)整窗口大小?等。

一般情況下，?Nagle算法和延遲確認(rèn)?不能一起使用，Nagle算法意味著延遲發(fā)，?延遲確認(rèn)?意味著延遲接收，醬紫就會(huì)造成更大的延遲，會(huì)產(chǎn)生性能問題。

39. URI和URL的區(qū)別

URI，全稱是Uniform Resource Identifier)，中文翻譯是統(tǒng)一資源標(biāo)志符，主要作用是唯一標(biāo)識(shí)一個(gè)資源。

URL，全稱是Uniform Resource Location)，中文翻譯是統(tǒng)一資源定位符，主要作用是提供資源的路徑。

打個(gè)經(jīng)典比喻吧，URI像是身份證，可以唯一標(biāo)識(shí)一個(gè)人，而URL更像一個(gè)住址，可以通過URL找到這個(gè)人。

40. 什么是數(shù)字簽名？ 什么是數(shù)字證書？

了解過?Https原理?的小伙伴，都知道數(shù)字證書這玩意。為了避免公鑰被篡改，引入了數(shù)字證書，如下：

數(shù)字證書構(gòu)成

公鑰和個(gè)人信息，經(jīng)過Hash算法加密，形成消息摘要；將消息摘要拿到擁有公信力的認(rèn)證中心（CA），用它的私鑰對(duì)消息摘要加密，形成數(shù)字簽名.

公鑰和個(gè)人信息、數(shù)字簽名共同構(gòu)成數(shù)字證書。

41. 什么是SQL 注入？舉個(gè)例子？

SQL注入是一種代碼注入技術(shù)，一般被應(yīng)用于攻擊web應(yīng)用程序。它通過在 web 應(yīng)用接口傳入一些特殊參數(shù)字符，來欺騙應(yīng)用服務(wù)器，執(zhí)行惡意的SQL命令，以達(dá)到非法獲取系統(tǒng)信息的目的。它目前是黑客對(duì)數(shù)據(jù)庫進(jìn)行攻擊的最常用手段之一。

SQL注入是如何攻擊的？

舉個(gè)常見的?業(yè)務(wù)場(chǎng)景?：在web表單搜索框輸入員工名字，然后后臺(tái)查詢出對(duì)應(yīng)名字的員工。

這種場(chǎng)景下，一般都是前端頁面把一個(gè)名字參數(shù)name傳到后臺(tái)，然后后臺(tái)通過SQL把結(jié)果查詢出來

name = "田螺"; //前端傳過來的SQL= "select*fromstaffwherename=" + name;? //根據(jù)前端傳過來的name參數(shù)，查詢數(shù)據(jù)庫員工表staff

復(fù)制代碼

因?yàn)镾QL是直接拼接的，如果我們完全信任前端傳的參數(shù)的話。假如前端傳這么一個(gè)參數(shù)時(shí)?'' or '1'='1'?，SQL就變成醬紫的啦。

select*fromstaffwherename=''or'1'='1';復(fù)制代碼

這個(gè)SQL會(huì)把所有的員工信息全都查出來了，醬紫就請(qǐng)求用戶已經(jīng)越權(quán)啦。請(qǐng)求者可以獲取所有員工的信息，信息已經(jīng)暴露了啦。

如何預(yù)防SQL注入問題

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

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

因?yàn)?#{}?是一個(gè)參數(shù)占位符，對(duì)于字符串類型，會(huì)自動(dòng)加上""，其他類型不加。由于Mybatis采用?預(yù)編譯?，其后的參數(shù)不會(huì)再進(jìn)行SQL編譯，所以一定程度上防止SQL注入。

${}?是一個(gè)簡(jiǎn)單的字符串替換，字符串是什么，就會(huì)解析成什么，存在SQL注入風(fēng)險(xiǎn)

2). 不要暴露一些不必要的日志或者安全信息，比如避免直接響應(yīng)一些sql異常信息。

如果SQL發(fā)生異常了，不要把這些信息暴露響應(yīng)給用戶，可以自定義異常進(jìn)行響應(yīng)

3). 不相信任何外部輸入?yún)?shù)，過濾參數(shù)中含有的一些數(shù)據(jù)庫關(guān)鍵詞關(guān)鍵詞

可以加個(gè)參數(shù)校驗(yàn)過濾的方法，過濾?union，or?等數(shù)據(jù)庫關(guān)鍵詞

4). 適當(dāng)?shù)臋?quán)限控制

在你查詢信息時(shí)，先校驗(yàn)下當(dāng)前用戶是否有這個(gè)權(quán)限。比如說，實(shí)現(xiàn)代碼的時(shí)候，可以讓用戶多傳一個(gè)企業(yè)Id什么的，或者獲取當(dāng)前用戶的session信息等，在查詢前，先校驗(yàn)一下當(dāng)前用戶是否是這個(gè)企業(yè)下的等等，是的話才有這個(gè)查詢員工的權(quán)限。

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

DOS?: (Denial of Service),中文名稱是拒絕服務(wù),一切能引起DOS行為的攻擊都被稱為DOS攻擊。最常見的DoS攻擊有計(jì)算機(jī)網(wǎng)絡(luò)寬帶攻擊和連通性攻擊。

DDoS?: (Distributed Denial of Service),中文名稱是分布式拒絕服務(wù)。是指處于不同位置的多個(gè)攻擊者同時(shí)向一個(gè)或數(shù)個(gè)目標(biāo)發(fā)動(dòng)攻擊，或者一個(gè)攻擊者控制了位于不同位置的多臺(tái)機(jī)器并利用這些機(jī)器對(duì)受害者同時(shí)實(shí)施攻擊。常見的DDos有SYN Flood、Ping of Death、ACK Flood、UDP Flood等。

DRDoS?: (Distributed Reflection Denial of Service)，中文名稱是分布式反射拒絕服務(wù)，該方式靠的是發(fā)送大量帶有被害者IP地址的數(shù)據(jù)包給攻擊主機(jī)，然后攻擊主機(jī)對(duì)IP地址源做出大量回應(yīng)，形成拒絕服務(wù)攻擊。

43. WebSocket與socket的區(qū)別

Socket = IP地址 + 端口 + 協(xié)議。

具體來說，Socket是一套標(biāo)準(zhǔn)，它完成了對(duì)TCP/IP的高度封裝，屏蔽網(wǎng)絡(luò)細(xì)節(jié)以方便開發(fā)者更好地進(jìn)行網(wǎng)絡(luò)編程。

WebSocket是一個(gè)持久化的協(xié)議，它是伴隨HTTP5而出的協(xié)議，用來解決?http不支持持久化連接?的問題。

Socket一個(gè)是?網(wǎng)編編程的標(biāo)準(zhǔn)接口?，而WebSocket是應(yīng)用層通信協(xié)議。

44. ICMP協(xié)議的功能

ICMP,Internet Control Message Protocol ,Internet控制消息協(xié)議。

ICMP協(xié)議是一種面向無連接的協(xié)議，用于傳輸出錯(cuò)報(bào)告控制信息。

它是一個(gè)非常重要的協(xié)議，它對(duì)于網(wǎng)絡(luò)安全具有極其重要的意義。它屬于網(wǎng)絡(luò)層協(xié)議，主要用于在主機(jī)與路由器之間傳遞控制信息，包括?報(bào)告錯(cuò)誤、交換受限控制和狀態(tài)信息?等。

當(dāng)遇到IP數(shù)據(jù)無法訪問目標(biāo)、IP路由器無法按當(dāng)前的傳輸速率轉(zhuǎn)發(fā)數(shù)據(jù)包等情況時(shí)，會(huì)自動(dòng)發(fā)送ICMP消息。

比如我們?nèi)粘Ｊ褂玫帽容^多的?ping?，就是基于ICMP的。

45. Http請(qǐng)求的過程與原理

HTTP是一個(gè)基于TCP/IP協(xié)議來傳遞數(shù)據(jù)的超文本傳輸協(xié)議，傳輸?shù)臄?shù)據(jù)類型有HTML文件,、圖片文件等。以訪問百度有例子，看下一次Http的請(qǐng)求過程

客戶端進(jìn)行DNS域名解析，得到對(duì)應(yīng)的IP地址

根據(jù)這個(gè)IP，找到對(duì)應(yīng)的服務(wù)器建立連接（三次握手）

建立TCP連接后發(fā)起HTTP請(qǐng)求（一個(gè)完整的http請(qǐng)求報(bào)文）

服務(wù)器響應(yīng)HTTP請(qǐng)求，客戶端得到html代碼

客戶端解析html代碼，用html代碼中的資源(如js,css,圖片等等)渲染頁面。

服務(wù)器關(guān)閉TCP連接（四次揮手）

46. 說下ping的原理

ping，?Packet Internet Groper?，是一種因特網(wǎng)包探索器，用于測(cè)試網(wǎng)絡(luò)連接量的程序。Ping是工作在TCP/IP網(wǎng)絡(luò)體系結(jié)構(gòu)中應(yīng)用層的一個(gè)服務(wù)命令， 主要是向特定的目的主機(jī)發(fā)送ICMP（Internet Control Message Protocol 因特網(wǎng)報(bào)文控制協(xié)議）?請(qǐng)求報(bào)文，測(cè)試目的站是否可達(dá)及了解其有關(guān)狀態(tài)

一般來說，ping可以用來檢測(cè)網(wǎng)絡(luò)通不通。它是基于?ICMP?協(xié)議工作的。假設(shè)?機(jī)器A?ping?機(jī)器B?，工作過程如下：

ping通知系統(tǒng)，新建一個(gè)固定格式的ICMP請(qǐng)求數(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)建一個(gè)IP數(shù)據(jù)包

先獲取目標(biāo)機(jī)器B的MAC地址。

數(shù)據(jù)鏈路層構(gòu)建一個(gè)數(shù)據(jù)幀，目的地址是IP層傳過來的?MAC地址?，源地址是本機(jī)的?MAC地址

機(jī)器B收到后，對(duì)比目標(biāo)地址，和自己本機(jī)的MAC地址是否一致，符合就處理返回，不符合就丟棄。

根據(jù)目的主機(jī)返回的ICMP回送回答報(bào)文中的時(shí)間戳，從而計(jì)算出往返時(shí)間

最終顯示結(jié)果有這幾項(xiàng)：發(fā)送到目的主機(jī)的IP地址、發(fā)送 & 收到 & 丟失的分組數(shù)、往返時(shí)間的最小、最大& 平均值

47. 如果服務(wù)器出現(xiàn)了大量 CLOSE_WAIT 狀態(tài)如何解決。

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

服務(wù)器端收到客戶端發(fā)送的?FIN?后，TCP協(xié)議棧就會(huì)自動(dòng)發(fā)送ACK，接著進(jìn)入?CLOSE_WAIT?狀態(tài)。

但是如果服務(wù)器端不執(zhí)行socket的close()操作，那么就沒法進(jìn)入LAST_ACK,導(dǎo)致大量連接處于CLOSE_WAIT狀態(tài)

所以，如果服務(wù)器出現(xiàn)了大量?CLOSE_WAIT?狀態(tài)，一般是程序Bug，或者關(guān)閉socket不及時(shí)。

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

什么是CSRF 攻擊？

CSRF，跨站請(qǐng)求偽造（英語：Cross-site request forgery），簡(jiǎn)單點(diǎn)說就是，攻擊者盜用了你的身份，以你的名義發(fā)送惡意請(qǐng)求。跟跨網(wǎng)站腳本（XSS）相比，XSS 利用的是用戶對(duì)指定網(wǎng)站的信任，CSRF 利用的是網(wǎng)站對(duì)用戶網(wǎng)頁瀏覽器的信任。

CSRF是如何攻擊的呢？

我們來看下這個(gè)例子哈（來自百度百科）

Tom 登陸銀行，沒有退出，瀏覽器包含了Tom在銀行的身份認(rèn)證信息。

黑客Jerry將偽造的轉(zhuǎn)賬請(qǐng)求，包含在在帖子

Tom在銀行網(wǎng)站保持登陸的情況下，瀏覽帖子

將偽造的轉(zhuǎn)賬請(qǐng)求連同身份認(rèn)證信息，發(fā)送到銀行網(wǎng)站

銀行網(wǎng)站看到身份認(rèn)證信息，以為就是Tom的合法操作，最后造成Tom資金損失。

如何解決CSRF攻擊

檢查Referer字段。HTTP頭中有一個(gè)Referer字段，這個(gè)字段用以標(biāo)明請(qǐng)求來源于哪個(gè)地址。

添加校驗(yàn)token。

49. RARP協(xié)議的工作原理？

ARP(地址解析協(xié)議) ,是設(shè)備通過自己知道的IP地址來獲得自己不知道的物理地址的協(xié)議。

RARP(反向地址轉(zhuǎn)換協(xié)議)以與ARP相反的方式工作。RARP發(fā)出要反向解析的物理地址并希望返回其對(duì)應(yīng)的IP地址，應(yīng)答包括由能夠提供所需信息的RARP服務(wù)器發(fā)出的IP地址。（應(yīng)用于無盤機(jī)）

RARP 工作原理如下：

發(fā)送主機(jī)發(fā)送一個(gè)本地的RARP廣播，在此廣播包中，聲明自己的MAC地址并且請(qǐng)求任何收到此請(qǐng)求的RARP服務(wù)器分配一個(gè)IP地址；

本地網(wǎng)段上的RARP服務(wù)器收到此請(qǐng)求后，檢查其RARP列表，查找該MAC地址對(duì)應(yīng)的IP地址；

如果存在，RARP服務(wù)器就給源主機(jī)發(fā)送一個(gè)響應(yīng)數(shù)據(jù)包并將此IP地址提供給對(duì)方主機(jī)使用；

如果不存在，RARP服務(wù)器對(duì)此不做任何的響應(yīng)；

源主機(jī)收到從RARP服務(wù)器的響應(yīng)信息，就利用得到的IP地址進(jìn)行通訊；如果一直沒有收到RARP服務(wù)器的響應(yīng)信息，表示初始化失敗。

.

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

DNS，?domain name system?，域名解析系統(tǒng)，是因特網(wǎng)上作為域名和IP地址相互映射的一個(gè)分布式數(shù)據(jù)庫。它的作用非常簡(jiǎn)單，就是可以根據(jù)域名查出對(duì)應(yīng)的IP地址。

解析過程如下：

首先，檢查?瀏覽器緩存?中，查找對(duì)應(yīng)的IP地址，找到就直接返回；否則下一步。

將請(qǐng)求發(fā)送給?本地DNS服務(wù)器?，在本地DNS服務(wù)器緩存中查詢，如果查找到就直接返回，否則下一步；

本地DNS服務(wù)器向?根域名服務(wù)器?發(fā)送請(qǐng)求，根域名服務(wù)器會(huì)告訴本地DNS服務(wù)器去查詢?哪個(gè)頂級(jí)域名服務(wù)器?。

本地域名服務(wù)器向頂級(jí)域名服務(wù)器發(fā)起查詢請(qǐng)求，頂級(jí)域名服務(wù)器會(huì)告訴本地DNS服務(wù)器，去查找?哪個(gè)權(quán)限域名服務(wù)器?。

本地域名服務(wù)器向權(quán)限域名服務(wù)器發(fā)起查詢請(qǐng)求，權(quán)限域名服務(wù)器告訴本地域名服務(wù)器請(qǐng)求域名所對(duì)應(yīng)的IP地址。

最后，本地域名服務(wù)器告訴主機(jī)?請(qǐng)求域名?所對(duì)應(yīng)的IP地址。

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

首先會(huì)在瀏覽器的緩存中,是否查找到www.baidu.com的對(duì)應(yīng)的IP，找到就直接返回；否則下一步。

將請(qǐng)求發(fā)送給本地DNS服務(wù)器，在本地DNS服務(wù)器緩存中查詢，如果查找到就直接返回，否則下一步；

本地DNS服務(wù)器向?根域名服務(wù)器?發(fā)送請(qǐng)求，根域名服務(wù)器返回負(fù)責(zé).com 的頂級(jí)域名服務(wù)器的IP地址的列表。

本地DNS服務(wù)器再向其中一個(gè)負(fù)責(zé)?.com?的頂級(jí)域名服務(wù)器發(fā)送一個(gè)請(qǐng)求，返回負(fù)責(zé)?.baidu的權(quán)威域名服務(wù)器的IP地址列表。

本地DNS服務(wù)器再向其中一個(gè)權(quán)威域名服務(wù)器發(fā)送一個(gè)請(qǐng)求，返回www.baidu.com所對(duì)應(yīng)的IP地址。

另外，對(duì)現(xiàn)在我們的大多數(shù)朋友來說還是學(xué)編程技術(shù)最重要！栽一棵樹最好的時(shí)間是十年前，其次是現(xiàn)在。對(duì)于準(zhǔn)備學(xué)習(xí)編程的小伙伴，如果你想更好的提升你的編程核心能力（內(nèi)功）不妨從現(xiàn)在開始！

微信公眾號(hào)：C語言編程學(xué)習(xí)基地

整理分享（多年學(xué)習(xí)的源碼、項(xiàng)目實(shí)戰(zhàn)視頻、項(xiàng)目筆記，基礎(chǔ)入門教程）

歡迎轉(zhuǎn)行和學(xué)習(xí)編程的伙伴，利用更多的資料學(xué)習(xí)成長(zhǎng)比自己琢磨更快哦！