網(wǎng)絡(luò)協(xié)議

1. 服務(wù)器輸入url到返回頁(yè)面的全過(guò)程（俗稱(chēng)天龍八步）

   • 1.根據(jù)域名，進(jìn)行DNS域名解析；

     我們?cè)跒g覽器輸入網(wǎng)址攒盈，其實(shí)就是要向服務(wù)器請(qǐng)求我們想要的頁(yè)面內(nèi)容，所有瀏覽器首先要確認(rèn)的是域名所對(duì)應(yīng)的服務(wù)器在哪里哎榴。將域名解析成對(duì)應(yīng)的服務(wù)器IP地址這項(xiàng)工作型豁，是由DNS服務(wù)器來(lái)完成的。

     客戶(hù)端收到你輸入的域名地址后尚蝌，它首先去找本地的hosts文件迎变，檢查在該文件中是否有相應(yīng)的域名、IP對(duì)應(yīng)關(guān)系飘言，如果有衣形，則向其IP地址發(fā)送請(qǐng)求，如果沒(méi)有姿鸿，再去找DNS服務(wù)器谆吴。一般用戶(hù)很少去編輯修改hosts文件。

   • 2.拿到解析的IP地址苛预，建立TCP連接句狼；

     費(fèi)了一頓周折終于拿到服務(wù)器IP了，下一步自然就是鏈接到該服務(wù)器热某。對(duì)于客戶(hù)端與服務(wù)器的TCP鏈接腻菇，必然要說(shuō)的就是『三次握手』。

     <img src="https://user-gold-cdn.xitu.io/2017/11/20/15fd7aab5ef0ab84?imageslim" alt="img" style="zoom:50%;" />

     客戶(hù)端發(fā)送一個(gè)帶有SYN標(biāo)志的數(shù)據(jù)包給服務(wù)端昔馋，服務(wù)端收到后筹吐，回傳一個(gè)帶有SYN/ACK標(biāo)志的數(shù)據(jù)包以示傳達(dá)確認(rèn)信息，最后客戶(hù)端再回傳一個(gè)帶ACK標(biāo)志的數(shù)據(jù)包秘遏，代表握手結(jié)束丘薛，連接成功。

     上圖也可以這么理解：

     客戶(hù)端：“你好邦危，在家不榔袋，有你快遞周拐。”

     服務(wù)端：“在的凰兑，送來(lái)就行妥粟。”

     客戶(hù)端：“好嘞吏够」锤”

   • 3.向IP地址，發(fā)送HTTP請(qǐng)求锅知；

     與服務(wù)器建立了連接后播急，就可以向服務(wù)器發(fā)起請(qǐng)求了。

     <img src="https://user-gold-cdn.xitu.io/2017/11/20/15fd7aab5edfbd5b?imageslim" alt="img" style="zoom:50%;" />

     請(qǐng)求行包括請(qǐng)求方法售睹、URI桩警、HTTP版本。首部字段傳遞重要信息，包括請(qǐng)求首部字段、通用首部字段和實(shí)體首部字段味混。我們可以從報(bào)文中看到發(fā)出的請(qǐng)求的具體信息叹哭。具體每個(gè)首部字段的作用徙瓶，這里不做過(guò)多闡述。

   • 4.服務(wù)器處理請(qǐng)求；

     服務(wù)器端收到請(qǐng)求后的由web服務(wù)器（準(zhǔn)確說(shuō)應(yīng)該是http服務(wù)器）處理請(qǐng)求，諸如Apache蒜鸡、Ngnix、IIS等牢裳。web服務(wù)器解析用戶(hù)請(qǐng)求逢防，知道了需要調(diào)度哪些資源文件，再通過(guò)相應(yīng)的這些資源文件處理用戶(hù)請(qǐng)求和參數(shù)蒲讯，并調(diào)用數(shù)據(jù)庫(kù)信息胞四，最后將結(jié)果通過(guò)web服務(wù)器返回給瀏覽器客戶(hù)端。

     <img src="https://user-gold-cdn.xitu.io/2017/11/20/15fd7aab7ec68a75?imageslim" alt="img" style="zoom:50%;" />

   • 5.返回響應(yīng)結(jié)果伶椿；

     在HTTP里，有請(qǐng)求就會(huì)有響應(yīng)氓侧，哪怕是錯(cuò)誤信息脊另。在響應(yīng)結(jié)果中都會(huì)有個(gè)一個(gè)HTTP狀態(tài)碼，比如我們熟知的200约巷、301偎痛、404、500等独郎。通過(guò)這個(gè)狀態(tài)碼我們可以知道服務(wù)器端的處理是否正常踩麦，并能了解具體的錯(cuò)誤枚赡。

     <img src="https://user-gold-cdn.xitu.io/2017/11/20/15fd7aab87da17f8?imageslim" alt="img" style="zoom:80%;" />

   • 6.關(guān)閉TCP連接；

     為了避免服務(wù)器與客戶(hù)端雙方的資源占用和損耗谓谦，當(dāng)雙方?jīng)]有請(qǐng)求或響應(yīng)傳遞時(shí)贫橙，任意一方都可以發(fā)起關(guān)閉請(qǐng)求。與創(chuàng)建TCP連接的3次握手類(lèi)似反粥，關(guān)閉TCP連接卢肃，需要4次握手。

     <img src="https://user-gold-cdn.xitu.io/2017/11/20/15fd7aab945db09e?imageslim" alt="img" style="zoom:67%;" />

     上圖可以這么理解：

     客戶(hù)端：“兄弟才顿，我這邊沒(méi)數(shù)據(jù)要傳了莫湘，咱關(guān)閉連接吧≈Ｆ”

     服務(wù)端：“收到幅垮，我看看我這邊有木有數(shù)據(jù)了∥沧椋”

     服務(wù)端：“兄弟忙芒，我這邊也沒(méi)數(shù)據(jù)要傳你了，咱可以關(guān)閉連接了演怎∝罢”

     客戶(hù)端：“好嘞∫”

   • 7.瀏覽器解析HTML甘桑；

   • 8.瀏覽器布局渲染；

2. DNS 是什么歹叮？DNS 的查詢(xún)過(guò)程跑杭？怎么減少DNS的傳輸時(shí)間

   • DNS 主要的作用就是將人們所熟悉的網(wǎng)址 (域名) “翻譯”成電腦可以理解的 IP 地址，這個(gè)過(guò)程叫做 DNS 域名解析咆耿。

   • 域名的結(jié)構(gòu)

     • www.tmall.com對(duì)應(yīng)的真正的域名為www.tmall.com.德谅。末尾的.稱(chēng)為根域名，因?yàn)槊總€(gè)域名都有根域名萨螺，因此我們通常省略窄做。

     • 根域名的下一級(jí)，叫做"頂級(jí)域名"（top-level domain慰技，縮寫(xiě)為T(mén)LD）椭盏，比如.com、.net吻商；

     • 再下一級(jí)叫做"次級(jí)域名"（second-level domain掏颊，縮寫(xiě)為SLD），比如www.tmall.com里面的.tmall，這一級(jí)域名是用戶(hù)可以注冊(cè)的乌叶；

     • 再下一級(jí)是主機(jī)名（host）盆偿，比如www.tmall.com里面的www，又稱(chēng)為"三級(jí)域名"准浴，這是用戶(hù)在自己的域里面為服務(wù)器分配的名稱(chēng)事扭，是用戶(hù)可以任意分配的。

   • DNS查詢(xún)過(guò)程

     (1)先在本機(jī)的DNS里頭查兄裂，如果有就直接返回了句旱。

     (2)本機(jī)DNS里頭發(fā)現(xiàn)沒(méi)有，就去根服務(wù)器里查晰奖。根服務(wù)器發(fā)現(xiàn)這個(gè)域名是屬于com域谈撒，，因此根域DNS服務(wù)器會(huì)返回它所管理的com域中的DNS 服務(wù)器的IP地址匾南，意思是“雖然我不知道你要查的那個(gè)域名的地址啃匿，但你可以去com域問(wèn)問(wèn)看”

     (3)本機(jī)的DNS接到又會(huì)向com域的DNS服務(wù)器發(fā)送查詢(xún)消息。com 域中也沒(méi)有www.tmall.com這個(gè)域名的信息蛆楞，和剛才一樣溯乒，com域服務(wù)器會(huì)返回它下面的tmall.com域的DNS服務(wù)器的IP地址。

3. 一個(gè) TCP 連接上面能發(fā)多少個(gè) HTTP 請(qǐng)求

   • 一個(gè) TCP 連接可以對(duì)應(yīng)幾個(gè) HTTP 請(qǐng)求豹爹？

   在 HTTP/1.0 中裆悄，一個(gè)服務(wù)器在發(fā)送完一個(gè) HTTP 響應(yīng)后，會(huì)斷開(kāi) TCP 鏈接臂聋。但是這樣每次請(qǐng)求都會(huì)重新建立和斷開(kāi) TCP 連接光稼，代價(jià)過(guò)大。所以雖然標(biāo)準(zhǔn)中沒(méi)有設(shè)定孩等，某些服務(wù)器對(duì) Connection: keep-alive 的 Header 進(jìn)行了支持艾君。意思是說(shuō)，完成這個(gè) HTTP 請(qǐng)求之后肄方，不要斷開(kāi) HTTP 請(qǐng)求使用的 TCP 連接冰垄。這樣的好處是連接可以被重新使用，之后發(fā)送 HTTP 請(qǐng)求的時(shí)候不需要重新建立 TCP 連接权她，以及如果維持連接虹茶，那么 SSL 的開(kāi)銷(xiāo)也可以避免。

HTTP/1.1 就把 Connection 頭寫(xiě)進(jìn)標(biāo)準(zhǔn)隅要，并且默認(rèn)開(kāi)啟持久連接蝴罪，除非請(qǐng)求中寫(xiě)明 Connection: close，那么瀏覽器和服務(wù)器之間是會(huì)維持一段時(shí)間的 TCP 連接拾徙，不會(huì)一個(gè)請(qǐng)求結(jié)束就斷掉。

• 一個(gè) TCP 連接中 HTTP 請(qǐng)求發(fā)送可以一起發(fā)送么感局？

HTTP/1.1 存在一個(gè)問(wèn)題尼啡，單個(gè) TCP 連接在同一時(shí)刻只能處理一個(gè)請(qǐng)求暂衡，意思是說(shuō)：兩個(gè)請(qǐng)求的生命周期不能重疊，任意兩個(gè) HTTP 請(qǐng)求從開(kāi)始到結(jié)束的時(shí)間在同一個(gè) TCP 連接里不能重疊崖瞭。但是狂巢，HTTP2 提供了 Multiplexing 多路傳輸特性，可以在一個(gè) TCP 連接中同時(shí)完成多個(gè) HTTP 請(qǐng)求书聚。

在 HTTP/1.1 存在 Pipelining 技術(shù)可以完成這個(gè)多個(gè)請(qǐng)求同時(shí)發(fā)送唧领，但是由于瀏覽器默認(rèn)關(guān)閉，所以可以認(rèn)為這是不可行的雌续。在 HTTP2 中由于 Multiplexing 特點(diǎn)的存在斩个，多個(gè) HTTP 請(qǐng)求可以在同一個(gè) TCP 連接中并行進(jìn)行。

• 瀏覽器對(duì)同一 Host 建立 TCP 連接到數(shù)量有沒(méi)有限制驯杜？

有受啥。Chrome 最多允許對(duì)同一個(gè) Host 建立六個(gè) TCP 連接。不同的瀏覽器有一些區(qū)別鸽心。

• 收到的 HTML 如果包含幾十個(gè)圖片標(biāo)簽滚局，這些圖片是以什么方式、什么順序顽频、建立了多少連接藤肢、使用什么協(xié)議被下載下來(lái)的呢？

如果圖片都是 HTTPS 連接并且在同一個(gè)域名下糯景，那么瀏覽器在 SSL 握手之后會(huì)和服務(wù)器商量能不能用 HTTP2嘁圈，如果能的話(huà)就使用 Multiplexing 功能在這個(gè)連接上進(jìn)行多路傳輸。不過(guò)也未必會(huì)所有掛在這個(gè)域名的資源都會(huì)使用一個(gè) TCP 連接去獲取莺奸，但是可以確定的是 Multiplexing 很可能會(huì)被用到丑孩。

如果發(fā)現(xiàn)用不了 HTTP2 呢？或者用不了 HTTPS（現(xiàn)實(shí)中的 HTTP2 都是在 HTTPS 上實(shí)現(xiàn)的灭贷，所以也就是只能使用 HTTP/1.1）温学。那瀏覽器就會(huì)在一個(gè) HOST 上建立多個(gè) TCP 連接，連接數(shù)量的最大限制取決于瀏覽器設(shè)置甚疟，這些連接會(huì)在空閑的時(shí)候被瀏覽器用來(lái)發(fā)送新的請(qǐng)求仗岖，如果所有的連接都正在發(fā)送請(qǐng)求呢？那其他的請(qǐng)求就只能等等了览妖。

4. RPC相對(duì)于傳統(tǒng)的API調(diào)用的優(yōu)點(diǎn)

   • RPC

   RPC 采用客戶(hù)端—服務(wù)器(Client/Server)的工作模式轧拄。請(qǐng)求程序就是一個(gè)客戶(hù)端(Client)， 而服務(wù)提供程序就是一個(gè)服務(wù)器(Server)讽膏。當(dāng)執(zhí)行一個(gè)遠(yuǎn)程過(guò)程調(diào)用時(shí)檩电，客戶(hù)端程序首先發(fā)送一 個(gè)帶有參數(shù)的調(diào)用信息到服務(wù)端，然后等待服務(wù)端響應(yīng)。在服務(wù)端俐末，服務(wù)進(jìn)程保持睡眠狀態(tài)直到 客戶(hù)端的調(diào)用信息到達(dá)為止料按。當(dāng)一個(gè)調(diào)用信息到達(dá)時(shí)，服務(wù)端獲得進(jìn)程參數(shù)卓箫，計(jì)算出結(jié)果载矿，并向 客戶(hù)端發(fā)送應(yīng)答信息，然后等待下一個(gè)調(diào)用烹卒。最后闷盔，客戶(hù)端接收來(lái)自服務(wù)端的應(yīng)答信息，獲得進(jìn) 程結(jié)果旅急，然后調(diào)用執(zhí)行并繼續(xù)進(jìn)行逢勾。

   • RPC與HTTP
     • 用信息占比少，畢竟HTTP工作在第七層坠非，包含了大量的HTTP頭等信息敏沉。
     • 效率低，還是因?yàn)榈谄邔拥木壒省?/li>
     • 可讀性似乎沒(méi)有必要炎码，因?yàn)槲覀兛梢砸刖W(wǎng)關(guān)增加可讀性盟迟。
     • 使用HTTP協(xié)議調(diào)用遠(yuǎn)程方法比較復(fù)雜，要封裝各種參數(shù)名和參數(shù)值潦闲。

5. UDP和TCP

   • udp和tcp 流式傳輸和數(shù)據(jù)包傳輸區(qū)別體現(xiàn)在哪攒菠。

   結(jié)合TCP的概念，水池就好比接收緩存歉闰，倒水就相當(dāng)于發(fā)送數(shù)據(jù)辖众，接水就相當(dāng)于讀取數(shù)據(jù)。好比你通過(guò)TCP連接給另一端發(fā)送數(shù)據(jù)和敬，你只調(diào)用了一次 write凹炸，發(fā)送了100個(gè)字節(jié)，但是對(duì)方可以分10次收完昼弟，每次10個(gè)字節(jié);你也可以調(diào)用10次write啤它，每次10個(gè)字節(jié)，但是對(duì)方可以一次就收完舱痘。 (假設(shè)數(shù)據(jù)都能到達(dá))但是变骡，你發(fā)送的數(shù)據(jù)量不能大于對(duì)方的接收緩存(流量控制)，如果你硬是要發(fā)送過(guò)量數(shù)據(jù)芭逝，則對(duì)方的緩存滿(mǎn)了就會(huì)把多出的數(shù)據(jù)丟棄塌碌。

   UDP和TCP不同，發(fā)送端調(diào)用了幾次write旬盯，接收端必須用相同次數(shù)的read讀完台妆。UPD是基于報(bào)文的翎猛，在接收的時(shí)候，每次最多只能讀取一個(gè) 報(bào)文接剩，報(bào)文和報(bào)文是不會(huì)合并的办成，如果緩沖區(qū)小于報(bào)文長(zhǎng)度，則多出的部分會(huì)被丟棄搂漠。也就說(shuō)，如果不指定MSG_PEEK標(biāo)志某弦，每次讀取操作將消耗一個(gè)報(bào)文桐汤。

   • TCP比UDP多消耗哪些系統(tǒng)資源？

     • TCP建立連接時(shí)三次握手靶壮，斷開(kāi)連接時(shí)四次揮手怔毛；

     • TCP數(shù)據(jù)包頭部20字節(jié)，UDP數(shù)據(jù)包頭部8字節(jié)腾降；

     • TCP有流量控制和擁塞控制拣度。

   • TCP和UDP區(qū)別

     • 1 基于連接和無(wú)連接；
     • 2 TCP是可靠螃壤，保證數(shù)據(jù)正確抗果；UDP不可靠，不保證數(shù)據(jù)正確奸晴；
     • 3 TCP保證數(shù)據(jù)順序到達(dá)冤馏；UDP不保證數(shù)據(jù)順序到達(dá)；
     • 4 TCP速度慢寄啼，因?yàn)門(mén)CP必須創(chuàng)建連接逮光；UDP速度較快，不需要建立連接墩划；
     • 5 因?yàn)樯鲜鲩_(kāi)銷(xiāo)涕刚，TCP是一個(gè)重量級(jí)協(xié)議；UDP是一個(gè)輕量級(jí)的協(xié)議乙帮；
     • 6 一個(gè)TCP數(shù)據(jù)包報(bào)頭的大小是20字節(jié)杜漠；一個(gè)UDP數(shù)據(jù)報(bào)報(bào)頭是8個(gè)字節(jié)；
     • 7 TCP有流量控制和擁塞控制蚣旱；UDP不能進(jìn)行流量控制碑幅；
     • 8 TCP面向字節(jié)流；UDP面向報(bào)文塞绿；

6. TCP為什么可靠

   tcp有個(gè)以字節(jié)為單位的滑動(dòng)窗口沟涨，它把要發(fā)送的數(shù)據(jù)都以字節(jié)形式存儲(chǔ)在這個(gè)滑動(dòng)窗口當(dāng)中。每次發(fā)送完窗口的數(shù)據(jù)后异吻，都會(huì)先保留數(shù)據(jù)裹赴，只有當(dāng)收到對(duì)方的數(shù)據(jù)確認(rèn)收到信號(hào)時(shí)再清除這些數(shù)據(jù)喜庞，如果超時(shí)沒(méi)有收到確認(rèn)信號(hào)的話(huà)就要重傳。這就是tcp的確認(rèn)重傳機(jī)制棋返。

   主要是利用了tcp首部的各個(gè)信號(hào)位延都。確認(rèn)最后一個(gè)到達(dá)的字符的序號(hào)。所以u(píng)dp相比之下容易丟包睛竣，報(bào)文亂序晰房。

7. TCP為什么四次揮手

   • 因?yàn)門(mén)CP是全雙工通信的。

   （1）第一次揮手

   ? 因此當(dāng)主動(dòng)方發(fā)送斷開(kāi)連接的請(qǐng)求（即FIN報(bào)文）給被動(dòng)方時(shí)射沟，僅僅代表主動(dòng)方不會(huì)再發(fā)送數(shù)據(jù)報(bào)文了殊者，但主動(dòng)方仍可以接收數(shù)據(jù)報(bào)文。

   ? （2）第二次揮手

   ? 被動(dòng)方此時(shí)有可能還有相應(yīng)的數(shù)據(jù)報(bào)文需要發(fā)送验夯，因此需要先發(fā)送ACK報(bào)文猖吴，告知主動(dòng)方“我知道你想斷開(kāi)連接的請(qǐng)求了”。這樣主動(dòng)方便不會(huì)因?yàn)闆](méi)有收到應(yīng)答而繼續(xù)發(fā)送斷開(kāi)連接的請(qǐng)求（即FIN報(bào)文）挥转。

   （3）第三次揮手

   ? 被動(dòng)方在處理完數(shù)據(jù)報(bào)文后海蔽，便發(fā)送給主動(dòng)方FIN報(bào)文；這樣可以保證數(shù)據(jù)通信正嘲笠ィ可靠地完成党窜。發(fā)送完FIN報(bào)文后，被動(dòng)方進(jìn)入LAST_ACK階段（超時(shí)等待）借宵。

   （4）第四揮手

   ? 如果主動(dòng)方及時(shí)發(fā)送ACK報(bào)文進(jìn)行連接中斷的確認(rèn)刑然，這時(shí)被動(dòng)方就直接釋放連接，進(jìn)入可用狀態(tài)暇务。

   • 為什么time-_wait

   （1）A不能保證最后的ACK能達(dá)到B泼掠，如果最后的ACK丟失， 那么B顯然收不到, B于是發(fā)起了重傳FIN的操作垦细， 此時(shí)如果A處于CLOSED的狀態(tài)择镇， 就沒(méi)辦法給對(duì)端發(fā)ACK了，所以A應(yīng)該等一段時(shí)間括改，這段時(shí)間就是所謂的TIME_WAIT腻豌。

   （2）保證新舊四元組互不干擾，假設(shè)tcp連接是：A(1.2.3.4:8888)------B(6.7.8.9:9999), 這就是一個(gè)tcp四元組嘱能。 當(dāng)tcp連接關(guān)閉后吝梅， 四元組釋放。 后面的新連接可能會(huì)重用到這個(gè)四元組（有這個(gè)可能性）惹骂， 那么問(wèn)題就來(lái)了： 新四元組和舊四元組完全一致苏携， 他們的網(wǎng)絡(luò)包會(huì)混亂嗎？所以对粪，可以考慮這樣一個(gè)機(jī)制：讓舊四元組對(duì)應(yīng)的所有網(wǎng)絡(luò)包都消失后（等一段時(shí)間）右冻，才允許新四元組建立装蓬，頗有點(diǎn)鎖的味道。這個(gè)等一段時(shí)間就是2MSL纱扭。

   • 連接過(guò)程中客戶(hù)端和服務(wù)器都處于什么狀態(tài)
     1. 客戶(hù)端進(jìn)程發(fā)出連接釋放報(bào)文牍帚，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報(bào)文首部乳蛾，F(xiàn)IN=1暗赶，其序列號(hào)為seq=u（等于前面已經(jīng)傳送過(guò)來(lái)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1），此時(shí)肃叶，客戶(hù)端進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)忆首。 TCP規(guī)定，F(xiàn)IN報(bào)文段即使不攜帶數(shù)據(jù)被环，也要消耗一個(gè)序號(hào)。
     2. 服務(wù)器收到連接釋放報(bào)文详幽，發(fā)出確認(rèn)報(bào)文筛欢，ACK=1，ack=u+1唇聘，并且?guī)献约旱男蛄刑?hào)seq=v版姑，此時(shí)，服務(wù)端就進(jìn)入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)迟郎。TCP服務(wù)器通知高層的應(yīng)用進(jìn)程剥险，客戶(hù)端向服務(wù)器的方向就釋放了，這時(shí)候處于半關(guān)閉狀態(tài)宪肖，即客戶(hù)端已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了表制，但是服務(wù)器若發(fā)送數(shù)據(jù)，客戶(hù)端依然要接受控乾。這個(gè)狀態(tài)還要持續(xù)一段時(shí)間么介，也就是整個(gè)CLOSE-WAIT狀態(tài)持續(xù)的時(shí)間。
     3. 客戶(hù)端收到服務(wù)器的確認(rèn)請(qǐng)求后蜕衡，此時(shí)壤短，客戶(hù)端就進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務(wù)器發(fā)送連接釋放報(bào)文（在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù)）慨仿。
     4. 服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后久脯，就向客戶(hù)端發(fā)送連接釋放報(bào)文，F(xiàn)IN=1镰吆，ack=u+1帘撰，由于在半關(guān)閉狀態(tài)，服務(wù)器很可能又發(fā)送了一些數(shù)據(jù)万皿，假定此時(shí)的序列號(hào)為seq=w骡和，此時(shí)相赁，服務(wù)器就進(jìn)入了LAST-ACK（最后確認(rèn)）狀態(tài)，等待客戶(hù)端的確認(rèn)慰于。
     5. 客戶(hù)端收到服務(wù)器的連接釋放報(bào)文后钮科，必須發(fā)出確認(rèn)，ACK=1婆赠，ack=w+1绵脯，而自己的序列號(hào)是seq=u+1，此時(shí)休里，客戶(hù)端就進(jìn)入了TIME-WAIT（時(shí)間等待）狀態(tài)蛆挫。注意此時(shí)TCP連接還沒(méi)有釋放，必須經(jīng)過(guò)2?*?MSL（最長(zhǎng)報(bào)文段壽命）的時(shí)間后妙黍，當(dāng)客戶(hù)端撤銷(xiāo)相應(yīng)的TCB后悴侵，才進(jìn)入CLOSED狀態(tài)。
     6. 服務(wù)器只要收到了客戶(hù)端發(fā)出的確認(rèn)拭嫁，立即進(jìn)入CLOSED狀態(tài)可免。同樣，撤銷(xiāo)TCB后做粤，就結(jié)束了這次的TCP連接浇借。可以看到怕品，服務(wù)器結(jié)束TCP連接的時(shí)間要比客戶(hù)端早一些妇垢。
        <img src="https://img-blog.csdn.net/20170606084851272?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcXpjc3U=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="img" style="zoom:50%;" />

8. TCP 的三次握手改成兩次握手可以嗎？

   不可以肉康，一句話(huà)闯估，主要防止已經(jīng)失效的連接請(qǐng)求報(bào)文突然又傳送到了服務(wù)器，從而產(chǎn)生錯(cuò)誤吼和。

   如果使用的是兩次握手建立連接睬愤，假設(shè)有這樣一種場(chǎng)景，客戶(hù)端發(fā)送了第一個(gè)請(qǐng)求連接并且沒(méi)有丟失纹安，只是因?yàn)樵诰W(wǎng)絡(luò)結(jié)點(diǎn)中滯留的時(shí)間太長(zhǎng)了尤辱，由于TCP的客戶(hù)端遲遲沒(méi)有收到確認(rèn)報(bào)文，以為服務(wù)器沒(méi)有收到厢岂，此時(shí)重新向服務(wù)器發(fā)送這條報(bào)文光督，此后客戶(hù)端和服務(wù)器經(jīng)過(guò)兩次握手完成連接，傳輸數(shù)據(jù)塔粒，然后關(guān)閉連接结借。此時(shí)此前滯留的那一次請(qǐng)求連接，網(wǎng)絡(luò)通暢了到達(dá)了服務(wù)器卒茬，這個(gè)報(bào)文本該是失效的船老，但是咖熟，兩次握手的機(jī)制將會(huì)讓客戶(hù)端和服務(wù)器再次建立連接，這將導(dǎo)致不必要的錯(cuò)誤和資源的浪費(fèi)柳畔。

   如果采用的是三次握手馍管，就算是那一次失效的報(bào)文傳送過(guò)來(lái)了，服務(wù)端接受到了那條失效報(bào)文并且回復(fù)了確認(rèn)報(bào)文薪韩，但是客戶(hù)端不會(huì)再次發(fā)出確認(rèn)确沸。由于服務(wù)器收不到確認(rèn)，就知道客戶(hù)端并沒(méi)有請(qǐng)求連接俘陷。

   • 連接過(guò)程中客戶(hù)端和服務(wù)器都處于什么狀態(tài)罗捎。

     1. CP服務(wù)器進(jìn)程先創(chuàng)建傳輸控制塊TCB，時(shí)刻準(zhǔn)備接受客戶(hù)進(jìn)程的連接請(qǐng)求拉盾，此時(shí)服務(wù)器就進(jìn)入了LISTEN（監(jiān)聽(tīng)）狀態(tài)桨菜；
     2. TCP客戶(hù)進(jìn)程也是先創(chuàng)建傳輸控制塊TCB，然后向服務(wù)器發(fā)出連接請(qǐng)求報(bào)文捉偏，這是報(bào)文首部中的同部位SYN=1倒得，同時(shí)選擇一個(gè)初始序列號(hào) seq=x ，此時(shí)告私，TCP客戶(hù)端進(jìn)程進(jìn)入了 SYN-SENT（同步已發(fā)送狀態(tài)）狀態(tài)。TCP規(guī)定承桥，SYN報(bào)文段（SYN=1的報(bào)文段）不能攜帶數(shù)據(jù)驻粟，但需要消耗掉一個(gè)序號(hào)。
     3. TCP服務(wù)器收到請(qǐng)求報(bào)文后凶异，如果同意連接蜀撑，則發(fā)出確認(rèn)報(bào)文。確認(rèn)報(bào)文中應(yīng)該 ACK=1剩彬，SYN=1酷麦，確認(rèn)號(hào)是ack=x+1，同時(shí)也要為自己初始化一個(gè)序列號(hào) seq=y喉恋，此時(shí)沃饶，TCP服務(wù)器進(jìn)程進(jìn)入了SYN-RCVD（同步收到）狀態(tài)。這個(gè)報(bào)文也不能攜帶數(shù)據(jù)轻黑，但是同樣要消耗一個(gè)序號(hào)糊肤。
     4. TCP客戶(hù)進(jìn)程收到確認(rèn)后，還要向服務(wù)器給出確認(rèn)氓鄙。確認(rèn)報(bào)文的ACK=1馆揉，ack=y+1，自己的序列號(hào)seq=x+1抖拦，此時(shí)升酣，TCP連接建立舷暮，客戶(hù)端進(jìn)入ESTABLISHED（已建立連接）狀態(tài)。TCP規(guī)定噩茄，ACK報(bào)文段可以攜帶數(shù)據(jù)下面，但是如果不攜帶數(shù)據(jù)則不消耗序號(hào)。
     5. 當(dāng)服務(wù)器收到客戶(hù)端的確認(rèn)后也進(jìn)入ESTABLISHED狀態(tài)巢墅，此后雙方就可以開(kāi)始通信了诸狭。

 <img src="/Users/anyao/Library/Application Support/typora-user-images/image-20200403164645409.png" alt="image-20200403164645409" style="zoom:30%;" />

• 第二次握手后沒(méi)有回復(fù)會(huì)怎么樣。

  如果使用的是兩次握手建立連接君纫，假設(shè)有這樣一種場(chǎng)景驯遇，客戶(hù)端發(fā)送了第一個(gè)請(qǐng)求連接并且沒(méi)有丟失，只是因?yàn)樵诰W(wǎng)絡(luò)結(jié)點(diǎn)中滯留的時(shí)間太長(zhǎng)了蓄髓，由于TCP的客戶(hù)端遲遲沒(méi)有收到確認(rèn)報(bào)文叉庐，以為服務(wù)器沒(méi)有收到，此時(shí)重新向服務(wù)器發(fā)送這條報(bào)文会喝，此后客戶(hù)端和服務(wù)器經(jīng)過(guò)兩次握手完成連接陡叠，傳輸數(shù)據(jù)，然后關(guān)閉連接肢执。此時(shí)此前滯留的那一次請(qǐng)求連接枉阵，網(wǎng)絡(luò)通暢了到達(dá)了服務(wù)器，這個(gè)報(bào)文本該是失效的预茄，但是兴溜，兩次握手的機(jī)制將會(huì)讓客戶(hù)端和服務(wù)器再次建立連接，這將導(dǎo)致不必要的錯(cuò)誤和資源的浪費(fèi)耻陕。

9. WebSocket

   因?yàn)?HTTP 協(xié)議有一個(gè)缺陷：通信只能由客戶(hù)端發(fā)起拙徽。只能是客戶(hù)端向服務(wù)器發(fā)出請(qǐng)求，服務(wù)器返回查詢(xún)結(jié)果诗宣。這種單向請(qǐng)求的特點(diǎn)膘怕，注定了如果服務(wù)器有連續(xù)的狀態(tài)變化，客戶(hù)端要獲知就非常麻煩召庞。我們只能使用"輪詢(xún)"：每隔一段時(shí)候岛心，就發(fā)出一個(gè)詢(xún)問(wèn)，了解服務(wù)器有沒(méi)有新的信息篮灼。最典型的場(chǎng)景就是聊天室鹉梨。

   它的最大特點(diǎn)就是，服務(wù)器可以主動(dòng)向客戶(hù)端推送信息穿稳，客戶(hù)端也可以主動(dòng)向服務(wù)器發(fā)送信息存皂，是真正的雙向平等對(duì)話(huà)，屬于服務(wù)器推送技術(shù)的一種。

   其他特點(diǎn)包括：

   （1）建立在 TCP 協(xié)議之上旦袋，服務(wù)器端的實(shí)現(xiàn)比較容易骤菠。

   （2）與 HTTP 協(xié)議有著良好的兼容性。默認(rèn)端口也是80和443疤孕，并且握手階段采用 HTTP 協(xié)議商乎，因此握手時(shí)不容易屏蔽，能通過(guò)各種 HTTP 代理服務(wù)器祭阀。

   （3）數(shù)據(jù)格式比較輕量射赛，性能開(kāi)銷(xiāo)小回右，通信高效孵滞。

   （4）可以發(fā)送文本诬滩，也可以發(fā)送二進(jìn)制數(shù)據(jù)。

   （5）沒(méi)有同源限制伦腐，客戶(hù)端可以與任意服務(wù)器通信赢底。

   （6）協(xié)議標(biāo)識(shí)符是ws（如果加密，則為wss）柏蘑，服務(wù)器網(wǎng)址就是 URL幸冻。

10. HTTP 請(qǐng)求常用的首部有哪些

在請(qǐng)求中，HTTP報(bào)文由方法咳焚、URI洽损、HTTP版本、HTTP首部字段等部分構(gòu)成革半。在響應(yīng)中碑定，HTTP報(bào)文由HTTP版本、狀態(tài)碼（數(shù)字和原因短語(yǔ)）督惰、HTTP首部字段3部分構(gòu)成不傅。

11. 常見(jiàn)的 HTTP 狀態(tài)碼

    分類(lèi)	分類(lèi)描述
    1XX	信息秘车，服務(wù)器收到請(qǐng)求典勇，需要請(qǐng)求者繼續(xù)執(zhí)行操作
    2XX	成功，操作被成功接收并處理
    3XX	重定向叮趴，需要進(jìn)一步的操作以完成請(qǐng)求
    4XX	客戶(hù)端錯(cuò)誤割笙，請(qǐng)求包含語(yǔ)法錯(cuò)誤或無(wú)法完成請(qǐng)求
    5XX	服務(wù)器錯(cuò)誤，服務(wù)器在處理請(qǐng)求的過(guò)程中發(fā)生了錯(cuò)誤

    • 301和302區(qū)別：

    301重定向是永久的重定向，搜索引擎在抓取新內(nèi)容的同時(shí)也將舊的網(wǎng)址替換為重定向之后的網(wǎng)址伤溉。

    302重定向是臨時(shí)的重定向般码，搜索引擎會(huì)抓取新的內(nèi)容而保留舊的網(wǎng)址。

    • 502, 503和504的區(qū)別

    502

    災(zāi)難事件： 在某個(gè)連著兩天的早晨9：00 左右乱顾，我們的服務(wù)器不幸掛掉了板祝，影響了一批用戶(hù)上班（早上著急上班騎不了自行車(chē)了，/捂臉）走净。當(dāng)時(shí)打開(kāi)我們的app和公司內(nèi)部系統(tǒng)券时，報(bào)錯(cuò)都是502。

    問(wèn)題原因：服務(wù)器冷不丁壞掉了

    解釋?zhuān)撼霈F(xiàn)502錯(cuò)誤伏伯，通常意味著一兩個(gè)機(jī)器已經(jīng)不正確橘洞，簡(jiǎn)單點(diǎn)說(shuō)，就是機(jī)器掛掉了舵鳞。理論點(diǎn)兒說(shuō)震檩，nginx執(zhí)行請(qǐng)求的時(shí)候，卻收到了上游服務(wù)器的無(wú)效響應(yīng)

    503

    災(zāi)難事件：臨時(shí)的服務(wù)器維護(hù)/過(guò)載蜓堕，服務(wù)器當(dāng)前無(wú)法處理請(qǐng)求抛虏，報(bào)503

    問(wèn)題原因：請(qǐng)求用戶(hù)量太多，服務(wù)器為了保護(hù)自己不掛掉套才，機(jī)智的拒絕某些用戶(hù)的訪問(wèn)迂猴，這些用戶(hù)就會(huì)收到503這個(gè)錯(cuò)誤

    解決辦法： 等一會(huì)兒仔訪問(wèn)該網(wǎng)站或者嘗試強(qiáng)刷新頁(yè)面，問(wèn)題一般就能夠解決了背伴。

    504

    事件描述：dns查詢(xún)過(guò)程超時(shí)沸毁，返回504；摸不著頭腦傻寂，不管訪問(wèn)什么網(wǎng)站息尺，都報(bào)504這個(gè)錯(cuò)誤

    問(wèn)題原因：nginx或者后端配置不正確

    解決辦法：上網(wǎng)查nginx或后端的配置參數(shù)是否正確或者合理

    解釋?zhuān)?實(shí)際上504很少會(huì)遇到，通常這個(gè)錯(cuò)誤是由于nginx配置不當(dāng)引起的疾掰，比如你將你的nginx的超時(shí)時(shí)間設(shè)

    置為300搂誉，那么如果此次請(qǐng)求的響應(yīng)時(shí)間超過(guò)了300，你就會(huì)看到504這個(gè)報(bào)錯(cuò)静檬。明白了吧炭懊。官方說(shuō)法：請(qǐng)求超時(shí)

    <img src="https://segmentfault.com/img/bV3Isu?w=660&h=833" alt="圖片描述" style="zoom:60%;" />

12. 5XX狀態(tài)碼

    500	Internal Server Error	服務(wù)器內(nèi)部錯(cuò)誤，無(wú)法完成請(qǐng)求
    501	Not Implemented	服務(wù)器不支持請(qǐng)求的功能拂檩，無(wú)法完成請(qǐng)求
    502	Bad Gateway	作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請(qǐng)求時(shí)侮腹，從遠(yuǎn)程服務(wù)器接收到了一個(gè)無(wú)效的響應(yīng)
    503	Service Unavailable	由于超載或系統(tǒng)維護(hù)，服務(wù)器暫時(shí)的無(wú)法處理客戶(hù)端的請(qǐng)求稻励。延時(shí)的長(zhǎng)度可包含在服務(wù)器的Retry-After頭信息中
    504	Gateway Time-out	充當(dāng)網(wǎng)關(guān)或代理的服務(wù)器父阻，未及時(shí)從遠(yuǎn)端服務(wù)器獲取請(qǐng)求
    505	HTTP Version not supported	服務(wù)器不支持請(qǐng)求的HTTP協(xié)議的版本，無(wú)法完成處理

13. Cookie Session區(qū)別

    本來(lái) session 是一個(gè)抽象概念，開(kāi)發(fā)者為了實(shí)現(xiàn)中斷和繼續(xù)等操作加矛，將 user agent 和 server 之間一對(duì)一的交互钠署，抽象為“會(huì)話(huà)”，進(jìn)而衍生出“會(huì)話(huà)狀態(tài)”荒椭，也就是 session 的概念谐鼎。

    而 cookie 是一個(gè)實(shí)際存在的東西，http 協(xié)議中定義在 header 中的字段趣惠±旯鳎可以認(rèn)為是 session 的一種后端無(wú)狀態(tài)實(shí)現(xiàn)。

    而我們今天常說(shuō)的 “session”味悄，是為了繞開(kāi) cookie 的各種限制草戈，通常借助 cookie 本身和后端存儲(chǔ)實(shí)現(xiàn)的，一種更高級(jí)的會(huì)話(huà)狀態(tài)實(shí)現(xiàn)侍瑟。

    1唐片，session 在服務(wù)器端，cookie 在客戶(hù)端（瀏覽器）

    2涨颜，session 默認(rèn)被存在在服務(wù)器的一個(gè)文件里（不是內(nèi)存）

    3费韭，session 的運(yùn)行依賴(lài) session id，而 session id 是存在 cookie 中的庭瑰，也就是說(shuō)星持，如果瀏覽器禁用了 cookie ，同時(shí) session 也會(huì)失效（但是可以通過(guò)其它方式實(shí)現(xiàn)弹灭，比如在 url 中傳遞 session_id）

    4督暂，session 可以放在 文件、數(shù)據(jù)庫(kù)穷吮、或內(nèi)存中都可以逻翁。

    5，用戶(hù)驗(yàn)證這種場(chǎng)合一般會(huì)用 session捡鱼。

因此八回，維持一個(gè)會(huì)話(huà)的核心就是客戶(hù)端的唯一標(biāo)識(shí)，即 session id [網(wǎng)絡(luò)協(xié)議.md](網(wǎng)絡(luò)協(xié)議.md) 

14. 為什么基于TCP的HTTP是無(wú)狀態(tài)呢堰汉？

    首先TCP是有狀態(tài)的辽社，在一次TCP連接之中伟墙，每一次的數(shù)據(jù)交換都和上一次緊密相關(guān)的翘鸭，TCP報(bào)文存在ACK字段用于確認(rèn)上次接收的報(bào)文，并且TCP在建立連接時(shí)交換了很多的連接配置信息戳葵，例如收就乓、發(fā)緩存大小，報(bào)文序號(hào)等。所以生蚁，每一次TCP數(shù)據(jù)交換兩方都是能夠確切知道對(duì)方的信息的噩翠。

因?yàn)镠TTP是短連接，即每次“請(qǐng)求-響應(yīng)”都是一次TCP連接邦投。比如用戶(hù)一次請(qǐng)求就是一次TCP連接伤锚，服務(wù)器響應(yīng)結(jié)束后斷開(kāi)連接。而每次TCP連接是沒(méi)有關(guān)聯(lián)的志衣，因此HTTP是無(wú)狀態(tài)的屯援。如果想要使得每次TCP連接之間有關(guān)聯(lián)，服務(wù)器和瀏覽器就得存儲(chǔ)相關(guān)的信息念脯，這個(gè)就是Cookie和Session的作用狞洋。 

15. osi七層模型，tcp/ip四層模型

    • osi七層模型：
    1. 物理層:建立绿店、維護(hù)吉懊、斷開(kāi)物理連接
    2. 數(shù)據(jù)鏈路層:建立邏輯連接，進(jìn)行硬件地址尋址假勿、差錯(cuò)校驗(yàn)等功能
    3. 網(wǎng)絡(luò)層:進(jìn)行邏輯地址尋址借嗽，實(shí)現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇
    4. 傳輸層:定義傳輸數(shù)據(jù)的協(xié)議端口號(hào)，以及流控和差錯(cuò)校驗(yàn)转培。eg. TCP淹魄、UDP，數(shù)據(jù)包一旦離開(kāi)網(wǎng)卡即進(jìn)入網(wǎng)絡(luò)傳輸層
    5. 會(huì)話(huà)層:建立堡距、管理甲锡、終止會(huì)話(huà)
    6. 表示層:數(shù)據(jù)的表示、安全羽戒、壓縮 應(yīng)用層:網(wǎng)絡(luò)服務(wù)與最終用戶(hù)的一個(gè)接口缤沦。eg. HTTP、FTP易稠、SMTP
    7. 應(yīng)用層:網(wǎng)絡(luò)服務(wù)與最終用戶(hù)的一個(gè)接口缸废。eg. HTTP、FTP驶社、SMTP
    • tcp/ip四層模型：鏈路層企量、網(wǎng)絡(luò)層、傳輸層亡电、應(yīng)用層届巩。

16. 數(shù)據(jù)鏈路層詳細(xì)介紹

    數(shù)據(jù)鏈路層是處于物理層和網(wǎng)絡(luò)層之間，依靠著物理層給網(wǎng)絡(luò)層提供服務(wù)份乒。物理層中是把電壓的高低或者光的閃滅轉(zhuǎn)換成計(jì)算機(jī)識(shí)別的二進(jìn)制流恕汇，而數(shù)據(jù)鏈路層則是把這些二進(jìn)制流轉(zhuǎn)換為幀腕唧，然后再進(jìn)行傳輸。

    • 鏈路層的功能
      • 鏈路管理瘾英，幀同步
      • 流量控制枣接，差錯(cuò)控制
      • 數(shù)據(jù)和控制信息分開(kāi)
      • 透明傳輸和尋址
    • 差錯(cuò)控制

    當(dāng)數(shù)據(jù)信號(hào)從發(fā)送端發(fā)送到物理線(xiàn)路時(shí)，由于物理線(xiàn)路存在噪聲缺谴，因此數(shù)據(jù)信號(hào)經(jīng)過(guò)物理線(xiàn)路的噪聲但惶，到達(dá)接收端時(shí)，已經(jīng)是數(shù)據(jù)+噪聲的疊加湿蛔。這就是差錯(cuò)的來(lái)源榆骚。用檢錯(cuò)碼來(lái)檢測(cè)幀傳輸過(guò)程中是否發(fā)生了差錯(cuò)，如果發(fā)生了錯(cuò)誤煌集，就需要滑動(dòng)窗口協(xié)議來(lái)解決妓肢。滑動(dòng)窗口協(xié)議分為兩種類(lèi)型：

    •     - 多幀發(fā)送協(xié)議：分為兩種類(lèi)型苫纤，后退N幀（GBN）拉回重發(fā)方式和選擇重發(fā)（SR）方式碉钠。前者是只要有一幀發(fā)送失敗，則當(dāng)前發(fā)送的全部幀都重新發(fā)送卷拘，這樣就會(huì)導(dǎo)致重發(fā)很多幀喊废，流量控制不佳。后者是當(dāng)前發(fā)送的幀中有差錯(cuò)栗弟，在下次發(fā)送的時(shí)候只是重新發(fā)送錯(cuò)誤的幀就行了污筷。  
          - 單幀停止等待協(xié)議：發(fā)送端發(fā)送1幀之后，需要等待接受端返回確認(rèn)幀乍赫，如果接收到ack瓣蛀，表示OK，發(fā)送下一幀雷厂；如果接收到nak惋增，表示傳輸錯(cuò)誤，重新發(fā)送該幀改鲫。
      

    • 滑動(dòng)窗口機(jī)制诈皿？
      在GBN和SR中，發(fā)送端可以連續(xù)發(fā)送多個(gè)數(shù)據(jù)幀像棘，從流量控制的角度出發(fā)稽亏，發(fā)送端連續(xù)發(fā)送數(shù)據(jù)幀的數(shù)量必然會(huì)收到限制：

      • 接收端的緩沖區(qū)可以用于接受新的幀的容量
      • 接收端處理數(shù)據(jù)幀的速度
      • 接收端需要等待重傳的幀的數(shù)量

    引入滑動(dòng)窗口的目的：對(duì)可以連續(xù)發(fā)出的最多幀數(shù)（已發(fā)出但未確認(rèn)的幀）作限制

    發(fā)送窗口（Ws）：表示在收到對(duì)方確認(rèn)的信息之前，以連續(xù)發(fā)出的最多數(shù)據(jù)幀數(shù)
    接受窗口（Wr）：可以連續(xù)接收的最多數(shù)據(jù)幀數(shù)（只有序號(hào)在窗口內(nèi)的幀才可以接收缕题，否則丟棄）

17. tcp中滑動(dòng)窗口的原理

    • 發(fā)送窗口

    對(duì)于TCP會(huì)話(huà)的發(fā)送方截歉，任何時(shí)候在其發(fā)送緩存內(nèi)的數(shù)據(jù)都可以分為4類(lèi)，“已經(jīng)發(fā)送并得到對(duì)端ACK的”避除，“已經(jīng)發(fā)送但還未收到對(duì)端ACK的”怎披，“未發(fā)送但對(duì)端允許發(fā)送的”，“未發(fā)送且對(duì)端不允許發(fā)送”瓶摆×构洌“已經(jīng)發(fā)送但還未收到對(duì)端ACK的”和“未發(fā)送但對(duì)端允許發(fā)送的”這兩部分?jǐn)?shù)據(jù)稱(chēng)之為發(fā)送窗口。當(dāng)收到接收方新的ACK對(duì)于發(fā)送窗口中后續(xù)字節(jié)的確認(rèn)是群井，窗口滑動(dòng)状飞。

    • 接受窗口

    對(duì)于TCP的接收方，在某一時(shí)刻在它的接收緩存內(nèi)存在3種书斜∥鼙玻“已接收”，“未接收準(zhǔn)備接收”荐吉，“未接收并未準(zhǔn)備接收”（由于ACK直接由TCP協(xié)議棻涸悖回復(fù)，默認(rèn)無(wú)應(yīng)用延遲样屠，不存在“已接收未回復(fù)ACK”）穿撮。其中“未接收準(zhǔn)備接收”稱(chēng)之為接收窗口。

    重傳機(jī)制

    TCP要保證所有的數(shù)據(jù)包都可以到達(dá)痪欲，所以悦穿，必需要有重傳機(jī)制。

    注意业踢，接收端給發(fā)送端的Ack確認(rèn)只會(huì)確認(rèn)最后一個(gè)連續(xù)的包栗柒，比如，發(fā)送端發(fā)了1,2,3,4,5一共五份數(shù)據(jù)知举，接收端收到了1瞬沦，2，于是回ack 3雇锡，然后收到了4（注意此時(shí)3沒(méi)收到）蛙埂，此時(shí)的TCP會(huì)怎么辦？我們要知道遮糖，因?yàn)檎缜懊嫠f(shuō)的绣的，SeqNum和Ack是以字節(jié)數(shù)為單位，所以ack的時(shí)候欲账，不能跳著確認(rèn)屡江，只能確認(rèn)最大的連續(xù)收到的包，不然赛不，發(fā)送端就以為之前的都收到了惩嘉。

    <img src="/Users/anyao/Library/Application Support/typora-user-images/image-20200403225330066.png" alt="image-20200403225330066" style="zoom:40%;" />

18. 超時(shí)重傳機(jī)制

    一種是不回ack，死等3踢故，當(dāng)發(fā)送方發(fā)現(xiàn)收不到3的ack超時(shí)后文黎，會(huì)重傳3惹苗。一旦接收方收到3后，會(huì)ack 回 4——意味著3和4都收到了耸峭。

    但是桩蓉，這種方式會(huì)有比較嚴(yán)重的問(wèn)題，那就是因?yàn)橐赖?劳闹，所以會(huì)導(dǎo)致4和5即便已經(jīng)收到了院究，而發(fā)送方也完全不知道發(fā)生了什么事，因?yàn)闆](méi)有收到Ack本涕，所以业汰，發(fā)送方可能會(huì)悲觀地認(rèn)為也丟了，所以有可能也會(huì)導(dǎo)致4和5的重傳菩颖。

    對(duì)此有兩種選擇：

    • 一種是僅重傳timeout的包样漆。也就是第3份數(shù)據(jù)。
    • 另一種是重傳timeout后所有的數(shù)據(jù)晦闰，也就是第3氛濒，4，5這三份數(shù)據(jù)鹅髓。

    這兩種方式有好也有不好舞竿。第一種會(huì)節(jié)省帶寬，但是慢窿冯，第二種會(huì)快一點(diǎn)骗奖，但是會(huì)浪費(fèi)帶寬，也可能會(huì)有無(wú)用功醒串。但總體來(lái)說(shuō)都不好执桌。因?yàn)槎荚诘萾imeout，timeout可能會(huì)很長(zhǎng)（在下篇會(huì)說(shuō)TCP是怎么動(dòng)態(tài)地計(jì)算出timeout的）

    快速重傳機(jī)制

    于是芜赌，TCP引入了一種叫Fast Retransmit 的算法仰挣，不以時(shí)間驅(qū)動(dòng)，而以數(shù)據(jù)驅(qū)動(dòng)重傳缠沈。也就是說(shuō)膘壶，如果，包沒(méi)有連續(xù)到達(dá)洲愤，就ack最后那個(gè)可能被丟了的包颓芭，如果發(fā)送方連續(xù)收到3次相同的ack，就重傳柬赐。Fast Retransmit的好處是不用等timeout了再重傳亡问。

    比如：如果發(fā)送方發(fā)出了1，2肛宋，3州藕，4束世，5份數(shù)據(jù)，第一份先到送了床玻，于是就ack回2毁涉，結(jié)果2因?yàn)槟承┰驔](méi)收到，3到達(dá)了笨枯，于是還是ack回2薪丁，后面的4和5都到了遇西，但是還是ack回2馅精，因?yàn)?還是沒(méi)有收到，于是發(fā)送端收到了三個(gè)ack=2的確認(rèn)粱檀，知道了2還沒(méi)有到洲敢，于是就馬上重轉(zhuǎn)2。然后茄蚯，接收端收到了2压彭，此時(shí)因?yàn)?，4渗常，5都收到了壮不，于是ack回6。示意圖如下：

    <img src="/Users/anyao/Library/Application Support/typora-user-images/image-20200403224652497.png" alt="image-20200403224652497" style="zoom:40%;" />

    Fast Retransmit只解決了一個(gè)問(wèn)題皱碘，就是timeout的問(wèn)題询一，它依然面臨一個(gè)艱難的選擇，就是癌椿，是重傳之前的一個(gè)還是重傳所有的問(wèn)題健蕊。對(duì)于上面的示例來(lái)說(shuō)，是重傳#2呢還是重傳#2踢俄，#3缩功，#4，#5呢都办？因?yàn)榘l(fā)送端并不清楚這連續(xù)的3個(gè)ack(2)是誰(shuí)傳回來(lái)的嫡锌？也許發(fā)送端發(fā)了20份數(shù)據(jù)，是#6琳钉，#10世舰，#20傳來(lái)的呢。這樣槽卫，發(fā)送端很有可能要重傳從2到20的這堆數(shù)據(jù)（這就是某些TCP的實(shí)際的實(shí)現(xiàn)）跟压。可見(jiàn)歼培，這是一把雙刃劍震蒋。

    SACK 方法

    <img src="/Users/anyao/Library/Application Support/typora-user-images/image-20200403224744731.png" alt="image-20200403224744731" style="zoom:33%;" />

    這里還需要注意一個(gè)問(wèn)題——接收方Reneging茸塞，所謂Reneging的意思就是接收方有權(quán)把已經(jīng)報(bào)給發(fā)送端SACK里的數(shù)據(jù)給丟了。這樣干是不被鼓勵(lì)的查剖，因?yàn)檫@個(gè)事會(huì)把問(wèn)題復(fù)雜化了钾虐，但是，接收方這么做可能會(huì)有些極端情況笋庄，比如要把內(nèi)存給別的更重要的東西效扫。所以，發(fā)送方也不能完全依賴(lài)SACK直砂，還是要依賴(lài)ACK菌仁，并維護(hù)Time-Out，如果后續(xù)的ACK沒(méi)有增長(zhǎng)静暂，那么還是要把SACK的東西重傳济丘，另外，接收端這邊永遠(yuǎn)不能把SACK的包標(biāo)記為Ack洽蛀。

19. 擁塞機(jī)制

    如果網(wǎng)絡(luò)上的延時(shí)突然增加摹迷，那么，TCP對(duì)這個(gè)事做出的應(yīng)對(duì)只有重傳數(shù)據(jù)郊供，但是峡碉，重傳會(huì)導(dǎo)致網(wǎng)絡(luò)的負(fù)擔(dān)更重，于是會(huì)導(dǎo)致更大的延遲以及更多的丟包驮审，于是鲫寄，這個(gè)情況就會(huì)進(jìn)入惡性循環(huán)被不斷地放大。試想一下头岔，如果一個(gè)網(wǎng)絡(luò)內(nèi)有成千上萬(wàn)的TCP連接都這么行事塔拳，那么馬上就會(huì)形成“網(wǎng)絡(luò)風(fēng)暴”，TCP這個(gè)協(xié)議就會(huì)拖垮整個(gè)網(wǎng)絡(luò)峡竣。

    當(dāng)擁塞發(fā)生的時(shí)候靠抑，要做自我犧牲。就像交通阻塞一樣适掰，每個(gè)車(chē)都應(yīng)該把路讓出來(lái)颂碧，而不要再去搶路了。擁塞

    控制主要是四個(gè)算法：

    ? 1）慢啟動(dòng)类浪，

    ? 2）擁塞避免载城，

    ? 3）擁塞發(fā)生，

    ? 4）快速恢復(fù)费就。

20. HTTPS 和 HTTP 有什么區(qū)別

    • HTTPS

      1.瀏覽器將自己支持的一套加密規(guī)則發(fā)送給網(wǎng)站诉瓦。

      2.網(wǎng)站從中選出一組加密算法與HASH算法，并將自己的身份信息以證書(shū)的形式發(fā)回給瀏覽器。證書(shū)里面包含了網(wǎng)站地址睬澡，加密公鑰固额，以及證書(shū)的頒發(fā)機(jī)構(gòu)等信息。

      3.獲得網(wǎng)站證書(shū)之后瀏覽器要做以下工作：

      a) 驗(yàn)證證書(shū)的合法性（頒發(fā)證書(shū)的機(jī)構(gòu)是否合法煞聪，證書(shū)中包含的網(wǎng)站地址是否與正在訪問(wèn)的地址一致等）斗躏，如果證書(shū)受信任，則瀏覽器欄里面會(huì)顯示一個(gè)小鎖頭昔脯，否則會(huì)給出證書(shū)不受信的提示啄糙。

      b) 如果證書(shū)受信任，或者是用戶(hù)接受了不受信的證書(shū)云稚，瀏覽器會(huì)生成一串隨機(jī)數(shù)的密碼隧饼，并用證書(shū)中提供的公鑰加密。

      c) 使用約定好的HASH計(jì)算握手消息碱鳞，并使用生成的隨機(jī)數(shù)對(duì)消息進(jìn)行加密桑李，最后將之前生成的所有信息發(fā)送給網(wǎng)站踱蛀。

      4.網(wǎng)站接收瀏覽器發(fā)來(lái)的數(shù)據(jù)之后要做以下的操作：

      a) 使用自己的私鑰將信息解密取出密碼窿给，使用密碼解密瀏覽器發(fā)來(lái)的握手消息，并驗(yàn)證HASH是否與瀏覽器發(fā)來(lái)的一致率拒。

      b) 使用密碼加密一段握手消息崩泡，發(fā)送給瀏覽器。

      5.瀏覽器解密并計(jì)算握手消息的HASH猬膨，如果與服務(wù)端發(fā)來(lái)的HASH一致角撞，此時(shí)握手過(guò)程結(jié)束，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機(jī)密碼并利用對(duì)稱(chēng)加密算法進(jìn)行加密勃痴。

      <img src="https://cdn.jsdelivr.net/gh/0vo/res/images/https.jpg" alt="img" style="zoom:25%;" />

    • HTTPS 和 HTTP 有什么區(qū)別

      • HTTP 明文傳輸谒所，數(shù)據(jù)都是未加密的，安全性較差沛申，HTTPS（SSL+HTTP） 數(shù)據(jù)傳輸過(guò)程是加密的劣领，安全性較好。
      • 使用 HTTPS 協(xié)議需要到 CA（Certificate Authority铁材，數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)） 申請(qǐng)證書(shū)尖淘，一般免費(fèi)證書(shū)較少，因而需要一定費(fèi)用著觉。證書(shū)頒發(fā)機(jī)構(gòu)如：Symantec村生、Comodo、GoDaddy 和 GlobalSign 等饼丘。
      • HTTP 頁(yè)面響應(yīng)速度比 HTTPS 快趁桃，主要是因?yàn)?HTTP 使用 TCP 三次握手建立連接，客戶(hù)端和服務(wù)器需要交換 3 個(gè)包，而 HTTPS除了 TCP 的三個(gè)包卫病，還要加上 ssl 握手需要的 9 個(gè)包屡穗，所以一共是 12 個(gè)包。
      • http 和 https 使用的是完全不同的連接方式忽肛，用的端口也不一樣村砂，前者是 80，后者是 443屹逛。
      • HTTPS 其實(shí)就是建構(gòu)在 SSL/TLS 之上的 HTTP 協(xié)議础废，所以，要比較 HTTPS 比 HTTP 要更耗費(fèi)服務(wù)器資源罕模。

21. 100Mbps的帶寬三個(gè)人使用评腺，每人50Mbps，tcp怎么保證速度的

    多TCP連接淑掌，可以充分利用帶寬蒿讥，用狀態(tài)表示每個(gè)TCP的連接狀況，可以共享TCP連接抛腕。

    單個(gè)TCP: 滑動(dòng)窗口芋绸、快速重傳、延遲應(yīng)答担敌、捎帶應(yīng)答

22. 一個(gè)完整的 HTTP 請(qǐng)求會(huì)涉及到哪些協(xié)議摔敛？

    <img src="https://user-gold-cdn.xitu.io/2017/11/11/690219fae5b0587fa26e2dee545e6200?imageslim" alt="img" style="zoom:60%;" />

23. 長(zhǎng)連接和短鏈接區(qū)別，應(yīng)用場(chǎng)景全封。

    在HTTP/1.0中马昙，默認(rèn)使用的是短連接。也就是說(shuō)刹悴，瀏覽器和服務(wù)器每進(jìn)行一次HTTP操作行楞，就建立一次連接，但任務(wù)結(jié)束就中斷連接土匀。如果客戶(hù)端瀏覽器訪問(wèn)的某個(gè)HTML或其他類(lèi)型的 Web頁(yè)中包含有其他的Web資源子房，如JavaScript文件、圖像文件恒削、CSS文件等池颈；當(dāng)瀏覽器每遇到這樣一個(gè)Web資源，就會(huì)建立一個(gè)HTTP會(huì)話(huà)钓丰。

    但從 HTTP/1.1起躯砰，默認(rèn)使用長(zhǎng)連接，用以保持連接特性携丁。使用長(zhǎng)連接的HTTP協(xié)議琢歇，會(huì)在響應(yīng)頭有加入這行代碼：

    Connection:keep-alive
    

    在使用長(zhǎng)連接的情況下兰怠，當(dāng)一個(gè)網(wǎng)頁(yè)打開(kāi)完成后，客戶(hù)端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的 TCP連接不會(huì)關(guān)閉李茫，如果客戶(hù)端再次訪問(wèn)這個(gè)服務(wù)器上的網(wǎng)頁(yè)揭保，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會(huì)永久保持連接魄宏，它有一個(gè)保持時(shí)間秸侣，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個(gè)時(shí)間。實(shí)現(xiàn)長(zhǎng)連接要客戶(hù)端和服務(wù)端都支持長(zhǎng)連接宠互。

    HTTP協(xié)議的長(zhǎng)連接和短連接味榛，實(shí)質(zhì)上是TCP協(xié)議的長(zhǎng)連接和短連接。

    長(zhǎng)連接多用于操作頻繁予跌，點(diǎn)對(duì)點(diǎn)的通訊搏色，而且連接數(shù)不能太多情況，券册。每個(gè)TCP連接都需要三步握手频轿，這需要時(shí)間，如果每個(gè)操作都是先連接烁焙，再操作的話(huà)那么處理速度會(huì)降低很多航邢，所以每個(gè)操作完后都不斷開(kāi)，次處理時(shí)直接發(fā)送數(shù)據(jù)包就OK了考阱，不用建立TCP連接翠忠。例如：數(shù)據(jù)庫(kù)的連接用長(zhǎng)連接鞠苟， 如果用短連接頻繁的通信會(huì)造成socket錯(cuò)誤乞榨，而且頻繁的socket 創(chuàng)建也是對(duì)資源的浪費(fèi)。

    而像WEB網(wǎng)站的http服務(wù)一般都用短鏈接当娱，因?yàn)殚L(zhǎng)連接對(duì)于服務(wù)端來(lái)說(shuō)會(huì)耗費(fèi)一定的資源吃既，而像WEB網(wǎng)站這么頻繁的成千上萬(wàn)甚至上億客戶(hù)端的連接用短連接會(huì)更省一些資源，如果用長(zhǎng)連接跨细，而且同時(shí)有成千上萬(wàn)的用戶(hù)鹦倚，如果每個(gè)用戶(hù)都占用一個(gè)連接的話(huà)，那可想而知吧冀惭。所以并發(fā)量大震叙，但每個(gè)用戶(hù)無(wú)需頻繁操作情況下需用短連好。

24. Ping用的協(xié)議

    ICMP：Internet控制報(bào)文協(xié)議散休。由于IP協(xié)議并不是一個(gè)可靠的協(xié)議媒楼，它不保證數(shù)據(jù)被成功送達(dá)，那么戚丸，如何才能保證數(shù)據(jù)的可靠送達(dá)呢划址？ 這里就需要使用到一個(gè)重要的協(xié)議模塊ICMP(網(wǎng)絡(luò)控制報(bào)文)協(xié)議。它傳遞差錯(cuò)報(bào)文以及其他需要注意的信息，經(jīng)常供IP層或更高層協(xié)議（TCP或UDP）使用夺颤。所以它經(jīng)常被認(rèn)為是IP層的一個(gè)組成部分痢缎。

25. TCP半連接客戶(hù)端怎么接消息

    tcp連接一端在進(jìn)行完三次握手以后進(jìn)入ESTABLISHED狀態(tài)，如果連接的對(duì)端在某一時(shí)刻在網(wǎng)絡(luò)中消失世澜，而本端沒(méi)有感知到独旷，還是處于ESTABLISHED狀態(tài)，那么本端的連接就被稱(chēng)為半打開(kāi)連接(Half Open)寥裂。

26. 你了解DDoS攻擊嗎势告？

    那 DDoS 攻擊究竟是什么？可能我舉個(gè)例子會(huì)更加形象點(diǎn)抚恒。我開(kāi)了一家有五十個(gè)座位的重慶火鍋店咱台，由于用料上等，童叟無(wú)欺俭驮。平時(shí)門(mén)庭若市回溺，生意特別紅火，而對(duì)面二狗家的火鍋店卻無(wú)人問(wèn)津混萝。二狗為了對(duì)付我遗遵，想了一個(gè)辦法，叫了五十個(gè)人來(lái)我的火鍋店坐著卻不點(diǎn)菜逸嘀，讓別的客人無(wú)法吃飯车要。

    上面這個(gè)例子講的就是典型的 DDoS 攻擊，全稱(chēng)是 Distributed Denial of Service崭倘，翻譯成中文就是分布式拒絕服務(wù)翼岁。一般來(lái)說(shuō)是指攻擊者利用“肉雞”對(duì)目標(biāo)網(wǎng)站在較短的時(shí)間內(nèi)發(fā)起大量請(qǐng)求，大規(guī)模消耗目標(biāo)網(wǎng)站的主機(jī)資源司光，讓它無(wú)法正常服務(wù)琅坡。在線(xiàn)游戲、互聯(lián)網(wǎng)金融等領(lǐng)域是 DDoS 攻擊的高發(fā)行業(yè)残家。

    • 如何應(yīng)對(duì) DDoS攻擊榆俺？
      • 高防服務(wù)器
        還是拿我開(kāi)的重慶火鍋店舉例，高防服務(wù)器就是我給重慶火鍋店增加了兩名保安，這兩名保安可以讓保護(hù)店鋪不受流氓騷擾，并且還會(huì)定期在店鋪周?chē)策壏乐沽髅ヲ}擾恤溶。高防服務(wù)器主要是指能獨(dú)立硬防御 50Gbps 以上的服務(wù)器，能夠幫助網(wǎng)站拒絕服務(wù)攻擊诺擅，定期掃描網(wǎng)絡(luò)主節(jié)點(diǎn)等，這東西是不錯(cuò)毫玖，就是貴~
      • 黑名單
        面對(duì)火鍋店里面的流氓掀虎，我一怒之下將他們拍照入檔凌盯，并禁止他們踏入店鋪，但是有的時(shí)候遇到長(zhǎng)得像的人也會(huì)禁止他進(jìn)入店鋪烹玉。這個(gè)就是設(shè)置黑名單驰怎，此方法秉承的就是“錯(cuò)殺一千，也不放一百”的原則二打，會(huì)封鎖正常流量县忌，影響到正常業(yè)務(wù)。
      • DDoS 清洗
        DDos 清洗继效，就是我發(fā)現(xiàn)客人進(jìn)店幾分鐘以后症杏，但是一直不點(diǎn)餐，我就把他踢出店里瑞信。DDoS 清洗會(huì)對(duì)用戶(hù)請(qǐng)求數(shù)據(jù)進(jìn)行實(shí)時(shí)監(jiān)控厉颤，及時(shí)發(fā)現(xiàn)DOS攻擊等異常流量，在不影響正常業(yè)務(wù)開(kāi)展的情況下清洗掉這些異常流量凡简。
      • CDN 加速
        CDN 加速逼友，我們可以這么理解：為了減少流氓騷擾，我干脆將火鍋店開(kāi)到了線(xiàn)上秤涩，承接外賣(mài)服務(wù)帜乞，這樣流氓找不到店在哪里，也耍不來(lái)流氓了筐眷。在現(xiàn)實(shí)中黎烈，CDN 服務(wù)將網(wǎng)站訪問(wèn)流量分配到了各個(gè)節(jié)點(diǎn)中，這樣一方面隱藏網(wǎng)站的真實(shí) IP匀谣，另一方面即使遭遇 DDoS 攻擊照棋，也可以將流量分散到各個(gè)節(jié)點(diǎn)中，防止源站崩潰振定。

27. xss跨域是什么

    它指的是惡意攻擊者往Web頁(yè)面里插入惡意html代碼必怜，當(dāng)用戶(hù)瀏覽該頁(yè)之時(shí)，嵌入其中Web里面的html代碼會(huì)被執(zhí)行后频，從而達(dá)到惡意用戶(hù)的特殊目的。

    它與SQL注入攻擊類(lèi)似暖途，SQL注入攻擊中以SQL語(yǔ)句作為用戶(hù)輸入卑惜，從而達(dá)到查詢(xún)/修改/刪除數(shù)據(jù)的目的，而在xss攻擊中驻售，通過(guò)插入惡意腳本露久，實(shí)現(xiàn)對(duì)用戶(hù)游覽器的控制，獲取用戶(hù)的一些信息欺栗。

28. RPC相對(duì)于傳統(tǒng)的API調(diào)用的優(yōu)點(diǎn)

    [圖片上傳失敗...(image-993303-1586424088414)]

29. request數(shù)據(jù)是如何流轉(zhuǎn)的

• http請(qǐng)求是如何建立起來(lái)

  <img src="http://images.haohongfan.com/socket.png?imageView2/0/w/700/h/700/q/75" alt="socket" style="zoom:100%;" />

  注冊(cè)路由：注冊(cè)一個(gè)路由及這個(gè)路由的handler到DefaultServeMux中毫痕。

  服務(wù)監(jiān)聽(tīng)及響應(yīng)：

  • ln, err := net.Listen("tcp", addr)做了初試化了socket, bind, listen的操作.
  • rw, e := l.Accept()進(jìn)行accept, 等待客戶(hù)端進(jìn)行連接
  • go c.serve(ctx) 啟動(dòng)新的goroutine來(lái)處理本次請(qǐng)求. 同時(shí)主goroutine繼續(xù)等待客戶(hù)端連接, 進(jìn)行高并發(fā)操作
  • h, _ := mux.Handler(r) 獲取注冊(cè)的路由, 然后拿到這個(gè)路由的handler, 然后將處理結(jié)果返回給客戶(hù)端