中文字幕 - 色网,91探花国产在线播放,亚洲人成色777777精品音频,国内精品久久久久久久久久久,操逼视频观看,黄色片在线网站,AV高清无码在线,婷婷丁香五月花

我梳理了50道計(jì)算機(jī)網(wǎng)絡(luò)面試題，每一道題目都特別經(jīng)典，大廠也非常喜歡問。相信大家看完，會(huì)有新的收獲滴~

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

思路: 這道面試題主要考察候選人，是否掌握HTTP狀態(tài)碼這個(gè)基礎(chǔ)知識點(diǎn)。

不管是不是面試需要，我們都要知道，日常開發(fā)中的這幾個(gè)狀態(tài)碼的含義哈：

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

思路: 這道題主要考察候選人，是否掌握HTTP請求方式這個(gè)基礎(chǔ)知識點(diǎn)，我們用得比較多就是GET和POST啦。

3. 請簡單說一下你了解的端口及對應(yīng)的服務(wù)？

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

思路: 這道題主要考察候選人，計(jì)算機(jī)網(wǎng)絡(luò)體系結(jié)構(gòu)這個(gè)基礎(chǔ)知識點(diǎn)。計(jì)算機(jī)網(wǎng)路體系結(jié)構(gòu)呢，有三層：ISO七層模型、TCP/IP四層模型、五層體系結(jié)構(gòu)。大家可以記住這個(gè)圖，如下

4.1 ISO七層模型

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

★
應(yīng)用層：網(wǎng)絡(luò)服務(wù)與最終用戶的一個(gè)接口，常見的協(xié)議有：HTTP FTP ?SMTP SNMP DNS.
表示層：數(shù)據(jù)的表示、安全、壓縮。，確保一個(gè)系統(tǒng)的應(yīng)用層所發(fā)送的信息可以被另一個(gè)系統(tǒng)的應(yīng)用層讀取。
會(huì)話層：建立、管理、終止會(huì)話,對應(yīng)主機(jī)進(jìn)程，指本地主機(jī)與遠(yuǎn)程主機(jī)正在進(jìn)行的會(huì)話.
傳輸層：定義傳輸數(shù)據(jù)的協(xié)議端口號，以及流控和差錯(cuò)校驗(yàn),協(xié)議有TCP UDP.
網(wǎng)絡(luò)層：進(jìn)行邏輯地址尋址，實(shí)現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇,協(xié)議有ICMP IGMP IP等.
數(shù)據(jù)鏈路層：在物理層提供比特流服務(wù)的基礎(chǔ)上，建立相鄰結(jié)點(diǎn)之間的數(shù)據(jù)鏈路。
物理層：建立、維護(hù)、斷開物理連接。
”

4.2 TCP/IP 四層模型

★
應(yīng)用層：對應(yīng)于OSI參考模型的（應(yīng)用層、表示層、會(huì)話層）。
傳輸層: 對應(yīng)OSI的傳輸層，為應(yīng)用層實(shí)體提供端到端的通信功能，保證了數(shù)據(jù)包的順序傳送及數(shù)據(jù)的完整性。
網(wǎng)際層：對應(yīng)于OSI參考模型的網(wǎng)絡(luò)層，主要解決主機(jī)到主機(jī)的通信問題。
網(wǎng)絡(luò)接口層：與OSI參考模型的數(shù)據(jù)鏈路層、物理層對應(yīng)。
”

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

★
應(yīng)用層：對應(yīng)于OSI參考模型的（應(yīng)用層、表示層、會(huì)話層）。
傳輸層：對應(yīng)OSI參考模型的的傳輸層
網(wǎng)絡(luò)層：對應(yīng)OSI參考模型的的網(wǎng)絡(luò)層
數(shù)據(jù)鏈路層：對應(yīng)OSI參考模型的的數(shù)據(jù)鏈路層
物理層：對應(yīng)OSI參考模型的的物理層。
”

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

思路: 這道題主要考察候選人，是否理解Http協(xié)議，它為什么是無狀態(tài)的呢？如何使它有狀態(tài)呢？

如何理解無狀態(tài)這個(gè)詞呢？

★
當(dāng)瀏覽器第一次發(fā)送請求給服務(wù)器時(shí)，服務(wù)器響應(yīng)了；如果同個(gè)瀏覽器發(fā)起第二次請求給服務(wù)器時(shí)，它還是會(huì)響應(yīng)，但是呢，服務(wù)器不知道你就是剛才的那個(gè)瀏覽器。簡言之，服務(wù)器不會(huì)去記住你是誰，所以是無狀態(tài)協(xié)議。
”

可以通過一個(gè)生活中的例子，來更好理解并記住它：

有狀態(tài)場景：

小紅：今天吃啥子？
小明：羅非魚~
小紅：味道怎么樣呀？
小明：還不錯(cuò)，好香。

無狀態(tài)的場景：

小紅：今天吃啥子？
小明：羅非魚~
小紅：味道怎么樣呀？
小明：？??？你說啥？什么鬼？什么味道怎么樣？

Http加了Cookie的話：

小紅：今天吃啥子？
小明：羅非魚~
小紅：你今天吃的羅非魚，味道怎么樣呀？
小明：還不錯(cuò)，好香。

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

思路: 這道題主要考察的知識點(diǎn)是HTTP的請求過程，DNS解析，TCP三次握手，四次揮手這幾個(gè)要點(diǎn)，我們都可以講下。

DNS解析，查找域名對應(yīng)的IP地址。
與服務(wù)器通過三次握手，建立TCP連接
向服務(wù)器發(fā)送HTTP請求
服務(wù)器處理請求，返回網(wǎng)頁內(nèi)容
瀏覽器解析并渲染頁面
TCP四次揮手，連接結(jié)束

7. 說下HTTP/1.0，1.1，2.0的區(qū)別

思路: 這道題主要考察的知識點(diǎn)是HTTP幾個(gè)版本的區(qū)別，我們記住HTTP/1.0默認(rèn)是短連接，可以強(qiáng)制開啟，HTTP/1.1默認(rèn)長連接，HTTP/2.0采用多路復(fù)用就差不多啦。

HTTP/1.0

默認(rèn)使用短連接，每次請求都需要建立一個(gè)TCP連接。它可以設(shè)置Connection: keep-alive?這個(gè)字段，強(qiáng)制開啟長連接。

HTTP/1.1

引入了持久連接，即TCP連接默認(rèn)不關(guān)閉，可以被多個(gè)請求復(fù)用。
分塊傳輸編碼，即服務(wù)端沒產(chǎn)生一塊數(shù)據(jù)，就發(fā)送一塊，用”流模式”取代”緩存模式”。
管道機(jī)制，即在同一個(gè)TCP連接里面，客戶端可以同時(shí)發(fā)送多個(gè)請求。

HTTP/2.0

二進(jìn)制協(xié)議，1.1版本的頭信息是文本（ASCII編碼），數(shù)據(jù)體可以是文本或者二進(jìn)制；2.0中，頭信息和數(shù)據(jù)體都是二進(jìn)制。
完全多路復(fù)用，在一個(gè)連接里，客戶端和瀏覽器都可以同時(shí)發(fā)送多個(gè)請求或回應(yīng)，而且不用按照順序一一對應(yīng)。
報(bào)頭壓縮，HTTP協(xié)議不帶有狀態(tài)，每次請求都必須附上所有信息。Http/2.0引入了頭信息壓縮機(jī)制，使用gzip或compress壓縮后再發(fā)送。
服務(wù)端推送，允許服務(wù)器未經(jīng)請求，主動(dòng)向客戶端發(fā)送資源。

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

思路: 這道題主要考察的知識點(diǎn)是POST和GET的區(qū)別，可以從數(shù)據(jù)包、編碼方式、請求參數(shù)、收藏為書簽、歷史記錄、安全性等幾方面去回答哈。

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

這個(gè)問題記住keep-alive就好，也就是說，在HTTP中響應(yīng)體的Connection字段指定為keep-alive即可

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

思路: 這道題實(shí)際上是考察TCP長連接的知識點(diǎn)，HTTP的長連接實(shí)質(zhì)是指TCP的長連接。至于什么時(shí)候超時(shí)，我們記住這幾個(gè)參數(shù)如tcp_keepalive_time、tcp_keepalive_probes就好啦

什么是HTTP的長連接？

HTTP分為長連接和短連接，本質(zhì)上說的是TCP的長短連接。TCP連接是一個(gè)雙向的通道，它是可以保持一段時(shí)間不關(guān)閉的，因此TCP連接才具有真正的長連接和短連接這一說法哈。
TCP長連接可以復(fù)用一個(gè)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)都是長連接。

在什么時(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ā)生偵測包，如果沒有收到對方的ACK，那么會(huì)每隔 tcp_keepalive_intvl再發(fā)一次，直到發(fā)送了tcp_keepalive_probes，就會(huì)丟棄該連接。
”

1.?tcp_keepalive_intvl?=?15
2.?tcp_keepalive_probes?=?5
3.?tcp_keepalive_time?=?1800

11. HTTP 與 HTTPS 的區(qū)別。

思路: 這道題實(shí)際上考察的知識點(diǎn)是HTTP與HTTPS的區(qū)別，這個(gè)知識點(diǎn)非常重要，可以從安全性、數(shù)據(jù)是否加密、默認(rèn)端口等這幾個(gè)方面去回答哈。其實(shí)，當(dāng)你理解HTTPS的整個(gè)流程，就可以很好回答這個(gè)問題啦。

我的答案如下：

HTTP，即超文本傳輸協(xié)議，是一個(gè)基于TCP/IP通信協(xié)議來傳遞明文數(shù)據(jù)的協(xié)議。HTTP會(huì)存在這幾個(gè)問題：

請求信息是明文傳輸，容易被竊聽截取。
沒有驗(yàn)證對方身份，存在被冒充的風(fēng)險(xiǎn)
數(shù)據(jù)的完整性未校驗(yàn)，容易被中間人篡改

為了解決Http存在的問題，Https出現(xiàn)啦。

Https是什么？

HTTPS= HTTP+SSL/TLS，可以理解Https是身披SSL(Secure Socket Layer，安全套接層)的HTTP。

它們主要區(qū)別如下：

12 . Https流程是怎樣的？

思路: 這道題實(shí)際上考察的知識點(diǎn)是HTTPS的工作流程，大家需要回答這幾個(gè)要點(diǎn)，公私鑰、數(shù)字證書、加密、對稱加密、非對稱加密。

HTTPS = HTTP + SSL/TLS，也就是用SSL/TLS對數(shù)據(jù)進(jìn)行加密和解密，Http進(jìn)行傳輸。
SSL，即Secure Sockets Layer（安全套接層協(xié)議），是網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。
TLS，即Transport Layer Security(安全傳輸層協(xié)議)，它是SSL3.0的后續(xù)版本。

客戶端發(fā)起Https請求，連接到服務(wù)器的443端口。
服務(wù)器必須要有一套數(shù)字證書（證書內(nèi)容有公鑰、證書頒發(fā)機(jī)構(gòu)、失效日期等）。
服務(wù)器將自己的數(shù)字證書發(fā)送給客戶端（公鑰在證書里面，私鑰由服務(wù)器持有）。
客戶端收到數(shù)字證書之后，會(huì)驗(yàn)證證書的合法性。如果證書驗(yàn)證通過，就會(huì)生成一個(gè)隨機(jī)的對稱密鑰，用證書的公鑰加密。
客戶端將公鑰加密后的密鑰發(fā)送到服務(wù)器。
服務(wù)器接收到客戶端發(fā)來的密文密鑰之后，用自己之前保留的私鑰對其進(jìn)行非對稱解密，解密之后就得到客戶端的密鑰，然后用客戶端密鑰對返回?cái)?shù)據(jù)進(jìn)行對稱加密，醬紫傳輸?shù)臄?shù)據(jù)都是密文啦。
服務(wù)器將加密后的密文返回到客戶端。
客戶端收到后，用自己的密鑰對其進(jìn)行對稱解密，得到服務(wù)器返回的數(shù)據(jù)。

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

思路: 這道題考查的知識點(diǎn)，也是HTTP狀態(tài)碼，302和301都有重定向的含義，但是它們也是有區(qū)別的。

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

網(wǎng)上有個(gè)很形象的例子比喻：

★
當(dāng)一個(gè)網(wǎng)站或者網(wǎng)頁24—48小時(shí)內(nèi)臨時(shí)移動(dòng)到一個(gè)新的位置，這時(shí)候就要進(jìn)行302跳轉(zhuǎn)，打個(gè)比方說，我有一套房子，但是最近走親戚去親戚家住了，過兩天我還回來的。而使用301跳轉(zhuǎn)的場景就是之前的網(wǎng)站因?yàn)槟撤N原因需要移除掉，然后要到新的地址訪問，是永久性的，就比如你的那套房子其實(shí)是租的，現(xiàn)在租期到了，你又在另一個(gè)地方找到了房子，之前租的房子不住了。
”

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

思路: 這道題考查的知識點(diǎn)，不僅僅是數(shù)字簽名，數(shù)字證書，很可能面試官也會(huì)問你https的原理的，因?yàn)閔ttps原理跟數(shù)字證書有關(guān)的哈，大家需要掌握https原理哦。

數(shù)字證書是指在互聯(lián)網(wǎng)通訊中標(biāo)志通訊各方身份信息的一個(gè)數(shù)字認(rèn)證，人們可以在網(wǎng)上用它來識別對方的身份。它的出現(xiàn)，是為了避免身份被篡改冒充的。比如Https的數(shù)字證書，就是為了避免公鑰被中間人冒充篡改：

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

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

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

思路: 這道題考察的知識點(diǎn)是對稱加密與非對稱加密算法，什么是對稱加密，什么是非對稱加密呢？

對稱加密：指加密和解密使用同一密鑰，優(yōu)點(diǎn)是運(yùn)算速度較快，缺點(diǎn)是如何安全將密鑰傳輸給另一方。常見的對稱加密算法有：DES、AES等。

非對稱加密：指的是加密和解密使用不同的密鑰（即公鑰和私鑰）。公鑰與私鑰是成對存在的，如果用公鑰對數(shù)據(jù)進(jìn)行加密，只有對應(yīng)的私鑰才能解密。常見的非對稱加密算法有RSA。

16. 說說DNS的解析過程？

思路: 這道題考察的知識點(diǎn)是DNS域名解析，http請求的過程，是涉及到DNS域名解析的，這道面試題也挺經(jīng)典的，大家可以看下《圖解HTTP》那本書哈。

★
DNS，英文全稱是domain name system，域名解析系統(tǒng)，是Internet上作為域名和IP相互映射的一個(gè)分布式數(shù)據(jù)庫。它的作用很明確，就是可以根據(jù)域名查出對應(yīng)的IP地址。在瀏覽器緩存、本地DNS服務(wù)器、根域名服務(wù)器都是怎么查找的，大家回答的時(shí)候都可以說下哈。
”

DNS的解析過程如下圖：

假設(shè)你要查詢www.baidu.com的IP地址:

★
首先會(huì)查找瀏覽器的緩存,看看是否能找到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ù)器再向其中一個(gè)負(fù)責(zé).com的頂級域名服務(wù)器發(fā)送一個(gè)請求，返回負(fù)責(zé).baidu的權(quán)威域名服務(wù)器的IP地址列表。
本地DNS服務(wù)器再向其中一個(gè)權(quán)威域名服務(wù)器發(fā)送一個(gè)請求，返回www.baidu.com所對應(yīng)的IP地址。
”

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

思路: 這道題考察的知識點(diǎn)是CSRF攻擊，它是屬于網(wǎng)絡(luò)安全這塊的知識點(diǎn)，還有Xss攻擊、SQL注入、DDoS等這些常見的網(wǎng)絡(luò)攻擊，我們都需要知道攻擊的流程哈。

什么是CSRF 攻擊？

★
CSRF，跨站請求偽造（英文全稱是Cross-site request forgery），是一種挾制用戶在當(dāng)前已登錄的Web應(yīng)用程序上執(zhí)行非本意的操作的攻擊方法。
”

CSRF是如何攻擊的呢？

來看一個(gè)來自百度百科的例子哈：

Tom 登陸銀行，沒有退出，瀏覽器包含了Tom在銀行的身份認(rèn)證信息。
黑客Jerry將偽造的轉(zhuǎn)賬請求，包含在在帖子
Tom在銀行網(wǎng)站保持登陸的情況下，瀏覽帖子
將偽造的轉(zhuǎn)賬請求連同身份認(rèn)證信息，發(fā)送到銀行網(wǎng)站
銀行網(wǎng)站看到身份認(rèn)證信息，以為就是Tom的合法操作，最后造成Tom資金損失。

怎么解決CSRF攻擊呢？

檢查Referer字段。
添加校驗(yàn)token。

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

為了大家方便記憶，我還是畫個(gè)思維導(dǎo)圖吧，如下：

19. 說說 WebSocket與socket的區(qū)別

思路: 這是一個(gè)比較基礎(chǔ)的知識點(diǎn)，經(jīng)常有小伙伴會(huì)搞混。

Socket其實(shí)就是等于IP地址 + 端口 + 協(xié)議。

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

WebSocket是一個(gè)持久化的協(xié)議，它是伴隨H5而出的協(xié)議，用來解決http不支持持久化連接的問題。
Socket一個(gè)是網(wǎng)編編程的標(biāo)準(zhǔn)接口，而WebSocket則是應(yīng)用層通信協(xié)議。

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

思路: 這是涉及網(wǎng)絡(luò)安全的一個(gè)知識點(diǎn)，DDos還會(huì)挺常見的，如SYN Flood。

★
DOS: (Denial of Service),翻譯過來就是拒絕服務(wù),一切能引起DOS行為的攻擊都被稱為DOS攻擊。最常見的DoS攻擊就有計(jì)算機(jī)網(wǎng)絡(luò)寬帶攻擊、連通性攻擊。
DDoS: (Distributed Denial of Service),翻譯過來是分布式拒絕服務(wù)。是指處于不同位置的多個(gè)攻擊者同時(shí)向一個(gè)或幾個(gè)目標(biāo)發(fā)動(dòng)攻擊，或者一個(gè)攻擊者控制了位于不同位置的多臺機(jī)器并利用這些機(jī)器對受害者同時(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ī)對IP地址源做出大量回應(yīng)，從而形成拒絕服務(wù)攻擊。
”

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

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

21.1 XSS是如何攻擊的呢？

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

21.2 如何解決XSS攻擊問題？

對輸入進(jìn)行過濾，過濾標(biāo)簽等，只允許合法值。
HTML轉(zhuǎn)義
對于鏈接跳轉(zhuǎn)，如?等，要校驗(yàn)內(nèi)容，禁止以script開頭的非法鏈接。
限制輸入長度

`22. Http請求的過程與原理`

思路: HTTP請求，一個(gè)非常非常基礎(chǔ)的知識點(diǎn)，一定需要掌握的。其實(shí)覺得跟瀏覽器地址欄輸入url到顯示主頁這道題有點(diǎn)類似。

我的答案如下：

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

客戶端進(jìn)行DNS域名解析，得到對應(yīng)的IP地址
根據(jù)這個(gè)IP，找到對應(yīng)的服務(wù)器建立連接（三次握手）
建立TCP連接后發(fā)起HTTP請求（一個(gè)完整的http請求報(bào)文）
服務(wù)器響應(yīng)HTTP請求，客戶端得到html代碼
客戶端解析html代碼，用html代碼中的資源(如js,css,圖片等等)渲染頁面。
服務(wù)器關(guān)閉TCP連接（四次揮手）

`23. ?forward和redirect的區(qū)別？`

思路: 這道題有點(diǎn)偏Java web方向的。以前記得剛出來實(shí)習(xí)找工作的時(shí)候，面試官可喜歡問這道題啦，當(dāng)時(shí)我記的答案就是，forward是轉(zhuǎn)發(fā)，redirect是重定向。

我的答案如下：

★直接轉(zhuǎn)發(fā)方式（Forward），客戶端和瀏覽器只發(fā)出一次請求，Servlet、HTML、JSP或其它信息資源，由第二個(gè)信息資源響應(yīng)該請求，在請求對象request中，保存的對象對于每個(gè)信息資源是共享的。間接轉(zhuǎn)發(fā)方式（Redirect）實(shí)際是兩次HTTP請求，服務(wù)器端在響應(yīng)第一次請求的時(shí)候，讓瀏覽器再向另外一個(gè)URL發(fā)出請求，從而達(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 的工作原理

`24. 聊聊SQL注入？`

思路: SQL注入是最經(jīng)典的安全問題。無論你是前端開發(fā)還是后端開發(fā)，都必須掌握的。

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

`24.1 SQL注入是如何攻擊的？`

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

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

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

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

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

select?*?from?staff?where?name=''?or?'1'='1';

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

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

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

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

因?yàn)?code style="font-size: 14px;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;">#{}是一個(gè)參數(shù)占位符，對于字符串類型，會(huì)自動(dòng)加上""，其他類型不加。由于Mybatis采用預(yù)編譯，其后的參數(shù)不會(huì)再進(jìn)行SQL編譯，所以一定程度上防止SQL注入。
${}是一個(gè)簡單的字符串替換，字符串是什么，就會(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)限。

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

我們先來看Session和Cookie的概念吧：

Cookie是保存在客戶端的一小塊文本串的數(shù)據(jù)?？蛻舳讼蚍?wù)器發(fā)起請求時(shí)，服務(wù)端會(huì)向客戶端發(fā)送一個(gè)Cookie，客戶端就把Cookie保存起來。在客戶端下次向同一服務(wù)器再發(fā)起請求時(shí)，Cookie被攜帶發(fā)送到服務(wù)器。服務(wù)器就是根據(jù)這個(gè)Cookie來確認(rèn)身份的。
session指的就是服務(wù)器和客戶端一次會(huì)話的過程。Session利用Cookie進(jìn)行信息處理的，當(dāng)用戶首先進(jìn)行了請求后，服務(wù)端就在用戶瀏覽器上創(chuàng)建了一個(gè)Cookie，當(dāng)這個(gè)Session結(jié)束時(shí)，其實(shí)就是意味著這個(gè)Cookie就過期了。Session對象存儲(chǔ)著特定用戶會(huì)話所需的屬性及配置信息。

Session 和Cookie的區(qū)別主要有這些：

來看個(gè)圖吧：

★
用戶第一次請求服務(wù)器時(shí)，服務(wù)器根據(jù)用戶提交的信息，創(chuàng)建對應(yīng)的Session，請求返回時(shí)將此Session的唯一標(biāo)識信息SessionID返回給瀏覽器，瀏覽器接收到服務(wù)器返回的SessionID信息后，會(huì)將此信息存入Cookie中，同時(shí)Cookie記錄此SessionID是屬于哪個(gè)域名。
當(dāng)用戶第二次訪問服務(wù)器時(shí)，請求會(huì)自動(dòng)判斷此域名下是否存在Cookie信息，如果存在，則自動(dòng)將Cookie信息也發(fā)送給服務(wù)端，服務(wù)端會(huì)從Cookie中獲取SessionID，再根據(jù) SessionID查找對應(yīng)的 Session信息，如果沒有找到，說明用戶沒有登錄或者登錄失效，如果找到Session證明用戶已經(jīng)登錄可執(zhí)行后面操作。
”

26. IP地址有哪些分類？

一般可以這么認(rèn)為，IP地址=網(wǎng)絡(luò)號+主機(jī)號。

網(wǎng)絡(luò)號：它標(biāo)志主機(jī)所連接的網(wǎng)絡(luò)地址表示屬于互聯(lián)網(wǎng)的哪一個(gè)網(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)：以11110開頭，保留位為將來使用

27. 說下ARP 協(xié)議的工作過程？

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

★

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

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

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

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

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

★
簡而言之，標(biāo)識網(wǎng)絡(luò)中的一臺計(jì)算機(jī)，比較常用的就是IP地址和MAC地址，但計(jì)算機(jī)的IP地址可由用戶自行更改，管理起來就相對困難，而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)的概念。對于目的地址在其他子網(wǎng)的數(shù)據(jù)包，路由只需要將數(shù)據(jù)包送到那個(gè)子網(wǎng)即可。
那為什么要用IP地址呢？是因?yàn)镮P地址是和地域相關(guān)的，對于同一個(gè)子網(wǎng)上的設(shè)備，IP地址的前綴都是一樣的，這樣路由器通過IP地址的前綴就知道設(shè)備在在哪個(gè)子網(wǎng)上了，而只用MAC地址的話，路由器則需要記住每個(gè)MAC地址在哪個(gè)子網(wǎng)，這需要路由器有極大的存儲(chǔ)空間，是無法實(shí)現(xiàn)的。
IP地址可以比作為地址，MAC地址為收件人，在一次通信過程中，兩者是缺一不可的。
”

35. 說下ping的原理

★
ping，Packet Internet Groper，是一種因特網(wǎng)包探索器，用于測試網(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é)議）?請求報(bào)文，測試目的站是否可達(dá)及了解其有關(guān)狀態(tài)
”

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

ping通知系統(tǒng)，新建一個(gè)固定格式的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)建一個(gè)IP數(shù)據(jù)包
先獲取目標(biāo)機(jī)器B的MAC地址。
數(shù)據(jù)鏈路層構(gòu)建一個(gè)數(shù)據(jù)幀，目的地址是IP層傳過來的MAC地址，源地址是本機(jī)的MAC地址
機(jī)器B收到后，對比目標(biāo)地址，和自己本機(jī)的MAC地址是否一致，符合就處理返回，不符合就丟棄。
根據(jù)目的主機(jī)返回的ICMP回送回答報(bào)文中的時(shí)間戳，從而計(jì)算出往返時(shí)間
最終顯示結(jié)果有這幾項(xiàng)：發(fā)送到目的主機(jī)的IP地址、發(fā)送 & 收到 & 丟失的分組數(shù)、往返時(shí)間的最小、最大& 平均值

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

思路: TCP連接的三次握手機(jī)制，最重要的知識點(diǎn)，必須得會(huì)，通訊過程以及客戶端、服務(wù)器的對應(yīng)的狀態(tài)都需要記住哈。

TCp提供可靠的連接服務(wù)，連接是通過三次握手進(jìn)行初始化的。三次握手的目的就是同步連接雙方的序列號和確認(rèn)號并交換TCP窗口大小信息。我們一起來看下流程圖哈：

第一次握手(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í)，也進(jìn)入ESTABLISHED狀態(tài)。

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

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

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

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

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

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

38. 說說TCP四次揮手過程

思路: TCP的四次揮手，也是最重要的知識點(diǎn)，一般跟三次握手會(huì)一起考的，必須得記住。

第一次揮手(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)閉請求，發(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)。

39. TCP揮手為什么需要四次呢？

思路： TCP揮手為什么需要四次呢？為了方便大家理解，再舉個(gè)生活的例子吧。

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

40. TCP四次揮手過程中，為什么需要等待2MSL,才進(jìn)入CLOSED關(guān)閉狀態(tài)

思路： 這個(gè)問得頻率特別高。去面試前，一定要把這道題拿下哈。

2MSL，two Maximum Segment Lifetime，即兩個(gè)最大段生命周期。假設(shè)主動(dòng)發(fā)起揮手的是客戶端，那么需要2MSL的原因是：

★
1.為了保證客戶端發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)服務(wù)端。 這個(gè)ACK報(bào)文段有可能丟失，因而使處在LAST-ACK狀態(tài)的服務(wù)端就收不到對已發(fā)送的FIN + ACK報(bào)文段的確認(rèn)。服務(wù)端會(huì)超時(shí)重傳這個(gè)FIN+ACK 報(bào)文段，而客戶端就能在 2MSL 時(shí)間內(nèi)（超時(shí) + 1MSL 傳輸）收到這個(gè)重傳的 FIN+ACK 報(bào)文段。接著客戶端重傳一次確認(rèn)，重新啟動(dòng)2MSL計(jì)時(shí)器。最后，客戶端和服務(wù)器都正常進(jìn)入到CLOSED狀態(tài)。
2. 防止已失效的連接請求報(bào)文段出現(xiàn)在本連接中?？蛻舳嗽诎l(fā)送完最后一個(gè)ACK報(bào)文段后，再經(jīng)過時(shí)間2MSL，就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失。這樣就可以使下一個(gè)連接中不會(huì)出現(xiàn)這種舊的連接請求報(bào)文段。
”

41. 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)文長度），TCP在傳輸前將進(jìn)行拆包。即TCP報(bào)文長度-TCP頭部長度>MSS。

解決方案：

發(fā)送端將每個(gè)數(shù)據(jù)包封裝為固定長度
在數(shù)據(jù)尾部增加特殊字符進(jìn)行分割
將數(shù)據(jù)分為兩部分，一部分是頭部，一部分是內(nèi)容體；其中頭部結(jié)構(gòu)大小固定，且有一個(gè)字段聲明內(nèi)容體的大小。

42. 聊聊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)窗口來控制流量，我們看下流量控制的簡要流程吧：

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

假如當(dāng)前發(fā)送方給接收方發(fā)送了200個(gè)字節(jié)，那么，發(fā)送方的SND.NXT會(huì)右移200個(gè)字節(jié)，也就是說當(dāng)前的可用窗口減少了200 個(gè)字節(jié)。
接受方收到后，放到緩沖隊(duì)列里面，REV.WND =400-200=200字節(jié)，所以win=200字節(jié)返回給發(fā)送方。接收方會(huì)在 ACK 的報(bào)文首部帶上縮小后的滑動(dòng)窗口200字節(jié)
發(fā)送方又發(fā)送200字節(jié)過來，200字節(jié)到達(dá)，繼續(xù)放到緩沖隊(duì)列。不過這時(shí)候，由于大量負(fù)載的原因，接受方處理不了這么多字節(jié)，只能處理100字節(jié)，剩余的100字節(jié)繼續(xù)放到緩沖隊(duì)列。這時(shí)候，REV.WND = 400-200-100=100字節(jié)，即win=100返回發(fā)送方。
發(fā)送方繼續(xù)干活，發(fā)送100字節(jié)過來，這時(shí)候，接受窗口win變?yōu)?。
發(fā)送方停止發(fā)送，開啟一個(gè)定時(shí)任務(wù)，每隔一段時(shí)間，就去詢問接受方，直到win大于0，才繼續(xù)開始發(fā)送。

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

思路講解： 我以前面試的時(shí)候，面試官就問我什么是半連接隊(duì)列、什么是全連接隊(duì)列，哈哈。我們需要掌握半連接隊(duì)列、全連接對列是啥，還需要清楚半連接隊(duì)列和 SYN Flood攻擊有什么關(guān)系。

我的答案如下：

TCP進(jìn)入三次握手前，服務(wù)端會(huì)從CLOSED狀態(tài)變?yōu)?strong style="font-weight: border;color: #0e88eb;">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是一種典型的DDos攻擊，它在短時(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請求啦。

那么有哪些方案應(yīng)對呢？主要有 syn cookie和SYN Proxy防火墻等。

★
syn cookie：在收到SYN包后，服務(wù)器根據(jù)一定的方法，以數(shù)據(jù)包的源地址、端口等信息為參數(shù)計(jì)算出一個(gè)cookie值作為自己的SYNACK包的序列號，回復(fù)SYN+ACK后，服務(wù)器并不立即分配資源進(jìn)行處理，等收到發(fā)送方的ACK包后，重新根據(jù)數(shù)據(jù)包的源地址、端口計(jì)算該包中的確認(rèn)序列號是否正確，如果正確則建立連接，否則丟棄該包。
SYN Proxy防火墻：服務(wù)器防火墻會(huì)對收到的每一個(gè)SYN報(bào)文進(jìn)行代理和回應(yīng)，并保持半連接。等發(fā)送方將ACK包返回后，再重新構(gòu)造SYN包發(fā)到服務(wù)器，建立真正的TCP連接。
”

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

思路講解： TCP滑動(dòng)窗口是個(gè)高頻考點(diǎn)，我們需要知道TCP報(bào)文首部有個(gè)字段win控制窗口大小的，同時(shí)也需要掌握，滑動(dòng)窗口是怎么滑的。

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

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

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

TCP頭部有個(gè)字段叫win，也即那個(gè)16位的窗口大小，它告訴對方本端的TCP接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù)，這樣對方就可以控制發(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è)，即發(fā)送窗口大小是14。
SND.NXT：下一個(gè)發(fā)送的位置，它指向未發(fā)送但可以發(fā)送的第一個(gè)字節(jié)的序列號。
SND.UNA: 一個(gè)絕對指針，它指向的是已發(fā)送但未確認(rèn)的第一個(gè)字節(jié)的序列號。

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

已成功接收并確認(rèn)
未收到數(shù)據(jù)但可以接收
未收到數(shù)據(jù)并不可以接收的數(shù)據(jù)

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

45. TCP的擁塞控制

思路講解： TCP擁塞機(jī)制也是個(gè)高頻考點(diǎn)，需要掌握它跟流量控制的區(qū)別，也需要掌握擁塞控制的這幾種算法：慢啟動(dòng)算法、擁塞避免、擁塞發(fā)生、快速恢復(fù)算法。

擁塞控制是作用于網(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á)到最大的傳輸效率，我們該如何知道這條水管的運(yùn)送效率是多少呢？

一個(gè)比較簡單的方法就是不斷增加傳輸?shù)乃浚钡剿芸煲褳橹梗▽?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ù)

45.1 慢啟動(dòng)算法

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

TCP連接完成，初始化cwnd = 1，表明可以傳一個(gè)MSS單位大小的數(shù)據(jù)。
每當(dāng)收到一個(gè)ACK，cwnd就加一;
每當(dāng)過了一個(gè)RTT，cwnd就增加一倍; 呈指數(shù)讓升

為了防止cwnd增長過大引起網(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)入了擁塞避免算法。

45.2 擁塞避免算法

一般來說，慢啟動(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ò)擁塞問題。

45.3 擁塞發(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ù)算法

45.4 快速恢復(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

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

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)入了擁塞避免的算法了。

46.請簡述TCP和UDP的區(qū)別

思路： 這道題，校招的時(shí)候，問的概率高點(diǎn)，概念性的東西，TCP是面向連接，而UDP是無連接。

47. 說說TCP是如何確?？煽啃缘哪?？

思路： TCP是可靠的連接，為什么具有可靠性呢？記住這些點(diǎn)：連接和斷開的可靠性（三次握手，四次揮手）、有狀態(tài)（哪些數(shù)據(jù)發(fā)送了，哪些沒發(fā)）、可控制（超時(shí)重傳、流量控制、擁塞控制等）。

首先，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ī)制。

48. 說說TCP報(bào)文首部有哪些字段，其作用又分別是什么？

思路： 小伙伴們，可以記下這個(gè)圖。

16位端口號：源端口號，主機(jī)該報(bào)文段是來自哪里；目標(biāo)端口號，要傳給哪個(gè)上層協(xié)議或應(yīng)用程序
32位序號：一次TCP通信（從TCP連接建立到斷開）過程中某一個(gè)傳輸方向上的字節(jié)流的每個(gè)字節(jié)的編號。
32位確認(rèn)號：用作對另一方發(fā)送的tcp報(bào)文段的響應(yīng)。其值是收到的TCP報(bào)文段的序號值加1。
4位頭部長度：表示tcp頭部有多少個(gè)32bit字（4字節(jié)）。因?yàn)?位最大能標(biāo)識15，所以TCP頭部最長是60字節(jié)。
6位標(biāo)志位：URG(緊急指針是否有效)，ACk（表示確認(rèn)號是否有效），PSH（緩沖區(qū)尚未填滿），RST（表示要求對方重新建立連接），SYN（建立連接消息標(biāo)志接），F(xiàn)IN（表示告知對方本端要關(guān)閉連接了）
16位窗口大小：是TCP流量控制的一個(gè)手段。這里說的窗口，指的是接收通告窗口。它告訴對方本端的TCP接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù)，這樣對方就可以控制發(fā)送數(shù)據(jù)的速度。
16位校驗(yàn)和：由發(fā)送端填充，接收端對TCP報(bào)文段執(zhí)行CRC算法以檢驗(yàn)TCP報(bào)文段在傳輸過程中是否損壞。注意，這個(gè)校驗(yàn)不僅包括TCP頭部，也包括數(shù)據(jù)部分。這也是TCP可靠傳輸?shù)囊粋€(gè)重要保障。
16位緊急指針：一個(gè)正的偏移量。它和序號字段的值相加表示最后一個(gè)緊急數(shù)據(jù)的下一字節(jié)的序號。因此，確切地說，這個(gè)字段是緊急指針相對當(dāng)前序號的偏移，不妨稱之為緊急偏移。TCP的緊急指針是發(fā)送端向接收端發(fā)送緊急數(shù)據(jù)的方法。

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

49.1 Nagle算法

如果發(fā)送方瘋狂地向接收方發(fā)送很小的數(shù)據(jù)包，比如一次就發(fā)送1個(gè)字節(jié)，那么顯然會(huì)有問題。

★
TCP/IP協(xié)議中，無論發(fā)送多少數(shù)據(jù)，總是需要在數(shù)據(jù)前面加上協(xié)議頭，同時(shí)，對方接收到數(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ā)送出去后，沒有收到對方發(fā)送的ACK確認(rèn)該數(shù)據(jù)已收到。

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

★
如果包長度達(dá)到MSS，則允許發(fā)送；
如果該包含有FIN，則允許發(fā)送；
設(shè)置了TCP_NODELAY選項(xiàng)，則允許發(fā)送；
未設(shè)置TCP_CORK選項(xiàng)時(shí)，若所有發(fā)出去的小數(shù)據(jù)包（包長度小于MSS）均被確認(rèn)，則允許發(fā)送；
上述條件都未滿足，但發(fā)生了超時(shí)（一般為200ms），則立即發(fā)送。
”

49.2 延遲確認(rèn)

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

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

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

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

50. 說說TCP的重傳機(jī)制

思路講解： TCP的重傳機(jī)制，也是道非常高頻的面試題。重傳包括超時(shí)重傳、快速重傳、帶選擇確認(rèn)的重傳（SACK）、重復(fù)SACK四種。

50.1 超時(shí)重傳

超時(shí)重傳，是TCP協(xié)議保證數(shù)據(jù)可靠性的另一個(gè)重要機(jī)制，其原理是在發(fā)送某一個(gè)數(shù)據(jù)以后就開啟一個(gè)計(jì)時(shí)器，在一定時(shí)間內(nèi)如果沒有得到發(fā)送的數(shù)據(jù)報(bào)的ACK報(bào)文，那么就重新發(fā)送數(shù)據(jù)，直到發(fā)送成功為止。

這個(gè)一定時(shí)間內(nèi)，一般是多少比較合理呢？來看下什么叫RTT（Round-Trip Time，往返時(shí)間）。

RTT就是數(shù)據(jù)完全發(fā)送完，到收到確認(rèn)信號的時(shí)間，即數(shù)據(jù)包的一次往返時(shí)間。超時(shí)重傳時(shí)間，就是RTO（Retransmission Timeout)。

那么，RTO到底設(shè)置多大呢？

如果RTO設(shè)置很大，等了很久都沒重發(fā)，這樣肯定就不行。
如果RTO設(shè)置很小，那很可能數(shù)據(jù)都沒有丟失，就開始重發(fā)了，這會(huì)導(dǎo)致網(wǎng)絡(luò)阻塞，從而惡性循環(huán)，導(dǎo)致更多的超時(shí)出現(xiàn)。

一般來說，RTO略微大于RTT，效果是最佳的。其實(shí)，RTO有個(gè)標(biāo)準(zhǔn)方法的計(jì)算公式，也叫Jacobson / Karels 算法。一起來看下吧：

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

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

2. 其次，計(jì)算RTTVAR (round-trip time variation)

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

3. 最后，得出最終的RTO

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

一般情況，α、β等的參數(shù)取值如下：

α?=?0.125，β?=?0.25，?μ?=?1，??=?4

別問這些參數(shù)是怎么來的，它們是大量實(shí)踐，調(diào)出的最優(yōu)參數(shù)。

超時(shí)重傳不是十分完美的重傳方案，它有這些缺點(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，如果發(fā)生一次超時(shí)重傳，時(shí)間間隔下次就會(huì)加倍。

50.2 快速重傳

其實(shí)可以使用快速重傳，來解決超時(shí)重發(fā)的時(shí)間等待問題。它不以時(shí)間驅(qū)動(dòng)，而是以數(shù)據(jù)驅(qū)動(dòng)。它是基于接收端的反饋信息來引發(fā)重傳的?？焖僦貍髁鞒倘缦拢?/p>

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

第一份 Seq=1 先送到了，于是就 Ack回2；
第二份 Seq=2 也送到了，于是ACK回3；
第三份 Seq=3 由于網(wǎng)絡(luò)等某些原因，沒送到；
第四份 Seq=4 送到了，但是由于Seq=3沒收到。因此ACK還是回3；
后面的 Seq=5,6的也送到了，ACK還是回復(fù)3，因?yàn)镾eq=3沒有收到。
發(fā)送方連著收到三個(gè)重復(fù)冗余ACK=3的確認(rèn)（其實(shí)是4個(gè)哈，但是因?yàn)榍懊娴囊粋€(gè)是正常的ACK，后面三個(gè)才是重復(fù)冗余的），于是知道哪個(gè)報(bào)文段在傳輸過程中丟失了；發(fā)送方在定時(shí)器過期之前，重傳該報(bào)文段。
最后，接收方收到了 Seq=3，此時(shí)因?yàn)?Seq=4，5，6都收到了，于是它回ACK=7。

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

★
是重傳 Seq=3 ？還是重傳 Seq=3、Seq=4、Seq=5、Seq=6 呢？因?yàn)榘l(fā)送端并不清楚這三個(gè)連續(xù)的 ACK=3 是誰傳回來的。
”

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

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

★
SACK機(jī)制就是，在快速重傳的基礎(chǔ)上，接收方返回最近收到報(bào)文段的序列號范圍，這樣發(fā)送方就知道接收方哪些數(shù)據(jù)包是沒收到的。這樣就很清楚應(yīng)該重傳哪些數(shù)據(jù)包啦。
”

如上圖中，發(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ā)。

50.4 重復(fù)SACK（D-SACK）

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

覺得文章不錯(cuò)的，歡迎點(diǎn)贊、在看和轉(zhuǎn)發(fā)，感謝感謝

參考資料

[1]

http的長連接和短連接（史上最通俗?。? https://www.jianshu.com/p/3fc3646fad80

[2]

Cookie和Session的區(qū)別: https://zhuanlan.zhihu.com/p/66754258

[3]

ARP協(xié)議的工作機(jī)制詳解: http://c.biancheng.net/view/6388.html

[4]

ARP協(xié)議工作流程: https://blog.csdn.net/qq_44041062/article/details/109844155

[5]

一文搞定所有計(jì)算機(jī)網(wǎng)絡(luò)面試題: https://segmentfault.com/a/1190000038526729

梳理50道經(jīng)典計(jì)算機(jī)網(wǎng)絡(luò)面試題

1. 說說HTTP常用的狀態(tài)碼及其含義？

2. HTTP 常用的請求方式，區(qū)別和用途？

3. 請簡單說一下你了解的端口及對應(yīng)的服務(wù)？

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

4.1 ISO七層模型

4.2 TCP/IP 四層模型

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

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

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

7. 說下HTTP/1.0，1.1，2.0的區(qū)別

8. ?POST和GET有哪些區(qū)別？

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

10. HTTP 如何實(shí)現(xiàn)長連接？在什么時(shí)候會(huì)超時(shí)？

11. HTTP 與 HTTPS 的區(qū)別。

12 . Https流程是怎樣的？

13. 說說HTTP的狀態(tài)碼，301和302的區(qū)別？

14. 說說什么是數(shù)字簽名？什么是數(shù)字證書？