七層模型

應(yīng)用層：用戶接口、應(yīng)用程序

表示層：數(shù)據(jù)表示、壓縮和加密

會(huì)話層：會(huì)話的建立和結(jié)束

傳輸層：端到端控制

網(wǎng)絡(luò)層：路由、尋找

數(shù)據(jù)鏈路層：保證無(wú)差錯(cuò)的忽略鏈路的data link

物理層：傳輸比特流

TCP和UDP的區(qū)別

TCP（傳輸控制協(xié)議）：面向連接，提供可靠的數(shù)據(jù)傳輸，用于傳輸大量數(shù)據(jù)，使用數(shù)據(jù)流模式，速度慢，建立連接是開(kāi)銷較大。

UDP（用戶數(shù)據(jù)協(xié)議）：非面向連接，傳輸不可靠，用于傳輸少量的數(shù)據(jù)，速度快。

UDP可以實(shí)現(xiàn)一對(duì)多？？

HTTP、HTTPS

1、HTTP是超文本傳輸協(xié)議，信息是明文傳輸，HTTPS是具有安全性的SSL加密傳輸協(xié)議。

2、HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

3、HTTP連接簡(jiǎn)單，無(wú)狀態(tài)；HTTPS協(xié)議是由HTTP+SSL協(xié)議構(gòu)成的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議。

HTTP為什么底層是TCP不是UDP ?

TCP是基于流式傳輸?shù)模趺丛O(shè)計(jì)協(xié)議，進(jìn)行協(xié)議的解析？

TCP為什么是三次握手和四次揮手？

TCP三次握手：

????????1、由客戶端發(fā)送一個(gè)叫做SYN（SYN=J）包到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，然后等待服務(wù)器響應(yīng)。

????????2、服務(wù)器接收到SYN包，必須確定客戶端的SYN（ACK=J+1），同時(shí)也發(fā)送一個(gè)SYN（SYN=K）包，也就是SYN+ACK，進(jìn)入SYM_RECV狀態(tài) 。

????????3、接收到服務(wù)器發(fā)來(lái)的SYN+ACK包，并向服務(wù)器發(fā)送確認(rèn)包ACK(ACK=K+1)，發(fā)完之后，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手

TCP四次揮手（客戶端關(guān)閉）：

????????1、客戶端發(fā)送一個(gè)FIN的報(bào)文給服務(wù)器之后，進(jìn)入等待服務(wù)器的響應(yīng)

????????2、服務(wù)器收到FIN后，并確認(rèn)是由客戶端發(fā)起的，同時(shí)也會(huì)發(fā)送一條ACK=X+1的報(bào)文

????????3、等到客戶端接收到ACK報(bào)文之后，服務(wù)器關(guān)閉了與客戶端的連接，會(huì)發(fā)送一個(gè)FIN報(bào)文給客戶端

????4、客戶端收到由服務(wù)器發(fā)送的FIN報(bào)文后，就會(huì)關(guān)閉與服務(wù)器的連接，并且發(fā)送ACK給服務(wù)器

為啥是三次握手，四次揮手？

????????1、連接時(shí)，服務(wù)端收到了客戶端的SYN連接請(qǐng)求的報(bào)文之后，可以直接發(fā)送SYN+ACK報(bào)文，其中ACK報(bào)文是用來(lái)響應(yīng)，SYN報(bào)文是用來(lái)同步的。

????????2、關(guān)閉時(shí)，服務(wù)端收到FIN報(bào)文后，很可能并不會(huì)馬上就關(guān)閉Socket連接，所以只能先回復(fù)一個(gè)ACK報(bào)文，告訴客戶端，你發(fā)的FIN報(bào)文我收到了，只有等到服務(wù)器的所有報(bào)文發(fā)送完了，服務(wù)器才會(huì)發(fā)送FIN報(bào)文，所以才需要四次揮手。

TCP是如何保證可靠的？

擁塞控制

TCP 的擁塞控制主要是四個(gè)算法：慢啟動(dòng)、擁塞避免、擁塞發(fā)生、快速恢復(fù)。

慢啟動(dòng)算法：

????????慢啟動(dòng)的算法如下(cwnd 全稱 Congestion Window)：

? ? ? ? ? ? ? ? 1、連接建好的開(kāi)始先初始化 cwnd = 1，表明可以傳一個(gè) MSS（Max Segment Size）大小的數(shù)據(jù)。

? ? ? ? ? ? ? ? 2、每當(dāng)收到一個(gè) ACK，cwnd++;?呈線性上升。

? ? ? ? ? ? ? ? 3、每當(dāng)過(guò)了一個(gè) RTT，cwnd = cwnd*2;?呈指數(shù)上升。

? ? ? ? ? ? ? ? 4、還有一個(gè) ssthresh（slow start threshold），是一個(gè)上限，當(dāng)?cwnd >= ssthresh時(shí)，就會(huì)進(jìn)入「擁塞避免算法」。

擁塞避免算法：

????????前面說(shuō)過(guò)，還有一個(gè) ssthresh（slow start threshold），是一個(gè)上限，當(dāng)?cwnd >= ssthresh?時(shí)，就會(huì)進(jìn)入擁塞避免算法。一般來(lái)說(shuō) ssthresh 的值是 65535 字節(jié)，當(dāng) cwnd 達(dá)到這個(gè)值時(shí)后，算法如下：

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

? ? ? ? ? ? ? ? 2、當(dāng)每過(guò)一個(gè) RTT 時(shí)，cwnd = cwnd + 1。

????????這樣就可以避免增長(zhǎng)過(guò)快導(dǎo)致網(wǎng)絡(luò)擁塞，慢慢的增加調(diào)整到網(wǎng)絡(luò)的最佳值。很明顯，是一個(gè)線性上升的算法。

擁塞狀態(tài)時(shí)的算法：

當(dāng)丟包的時(shí)候，會(huì)有兩種情況：

????????1、等到 RTO 超時(shí)，重傳數(shù)據(jù)包。TCP 認(rèn)為這種情況太糟糕，反應(yīng)也很強(qiáng)烈。

????????????????????sshthresh = cwnd/2。

????????????????????cwnd 重置為 1。

????????????????????進(jìn)入慢啟動(dòng)過(guò)程。

????????2、快速重傳（Fast Retransmit）算法，也就是在收到 3 個(gè) duplicate ACK 時(shí)就開(kāi)啟重傳，而不用等到 RTO 超時(shí)。

????????????????????TCP Tahoe 的實(shí)現(xiàn)和 RTO 超時(shí)一樣。

????????????????????TCP Reno的實(shí)現(xiàn)是：

????????????????????????????cwnd = cwnd/2。

????????????????????????????sshthresh = cwnd。

????????????????????????????進(jìn)入快速恢復(fù)算法（Fast Recovery）。

上面我們可以看到 RTO 超時(shí)后，sshthresh 會(huì)變成 cwnd 的一半，這意味著，如果 cwnd<=sshthresh 時(shí)出現(xiàn)的丟包，那么 TCP 的 sshthresh 就會(huì)減了一半，然后等 cwnd 又很快地以指數(shù)級(jí)增漲爬到這個(gè)地方時(shí)，就會(huì)成慢慢的線性增漲。我們可以看到，TCP 是怎么通過(guò)這種強(qiáng)烈地震蕩快速而小心得找到網(wǎng)站流量的平衡點(diǎn)的。 ?

快速恢復(fù)算法：

????????TCP Reno 這個(gè)算法定義在 RFC5681。快速重傳和快速恢復(fù)算法一般同時(shí)使用。快速恢復(fù)算法是認(rèn)為，你還有 3 個(gè) Duplicated Acks 說(shuō)明網(wǎng)絡(luò)也不那么糟糕，所以沒(méi)有必要像 RTO 超時(shí)那么強(qiáng)烈。注意，正如前面所說(shuō)，進(jìn)入 Fast Recovery 之前，cwnd 和 sshthresh 已被更新： ?

????????????????cwnd = cwnd /2。

????????????????sshthresh = cwnd。

? ??????然后，真正的 Fast Recovery 算法如下：

????????????????cwnd = sshthresh + 3 * MSS?（3 的意思是確認(rèn)有 3 個(gè)數(shù)據(jù)包被收到了）。

????????????????重傳 Duplicated ACKs 指定的數(shù)據(jù)包。

????????????????如果再收到 duplicated ACKs，那么?cwnd = cwnd + 1。

????????????????如果收到了新的 ACK，那么?cwnd = sshthresh，然后就進(jìn)入了擁塞避免的算法了。

為什么要使用HTTP？為什么不直接用TCP？

如何保證HTTP傳輸?shù)竭_(dá)？

HTTP頭部有哪些內(nèi)容？

TCP頭部多長(zhǎng)，IP呢

HTTP有哪些部分

HTTP協(xié)議GET、 POST的區(qū)別

HTTP超文本傳輸協(xié)議，是短連接，是客戶端主動(dòng)發(fā)送請(qǐng)求，服務(wù)器做出響應(yīng)，服務(wù)器響應(yīng)之后，鏈接斷開(kāi)。HTTP是一個(gè)屬于應(yīng)用層面向?qū)ο蟮膮f(xié)議，HTTP有兩類報(bào)文：請(qǐng)求報(bào)文和響應(yīng)報(bào)文。

HTTP請(qǐng)求報(bào)文：一個(gè)HTTP請(qǐng)求報(bào)文由請(qǐng)求行、請(qǐng)求頭部、空行和請(qǐng)求數(shù)據(jù)4部分組成。

HTTP響應(yīng)報(bào)文：由三部分組成：狀態(tài)行、消息報(bào)頭、響應(yīng)正文。

區(qū)別：

? ? ? ? 1、GET請(qǐng)求：參數(shù)在地址后拼接，沒(méi)有請(qǐng)求數(shù)據(jù)，不安全（因?yàn)樗袇?shù)都拼接在地址后面），不適合傳輸大量數(shù)據(jù)（長(zhǎng)度有限制，為1024個(gè)字節(jié)）。

? ??????????????GET提交、請(qǐng)求的數(shù)據(jù)會(huì)附在URL之后，即把數(shù)據(jù)放置在HTTP協(xié)議頭<requestline>中。以分割URL和傳輸數(shù)據(jù)，多個(gè)參數(shù)用&連接。如果數(shù)據(jù)是英文字母或數(shù)字，原樣發(fā)送，如果是空格，轉(zhuǎn)換為+，如果是中文/其他字符，則直接把字符串用BASE64加密。

? ? ? ? ????POST請(qǐng)求：參數(shù)在請(qǐng)求數(shù)據(jù)區(qū)放著，相對(duì)GET請(qǐng)求更安全，并且數(shù)據(jù)大小沒(méi)有限制。把提交的數(shù)據(jù)放置在HTTP包的包體<request-body>中。

????????2、GET提交的數(shù)據(jù)會(huì)在地址欄顯示出來(lái)，而POST提交，地址欄不會(huì)改變。

????????GET提交時(shí)，傳輸數(shù)據(jù)就會(huì)受到URL長(zhǎng)度限制，POST由于不是通過(guò)URL傳值，理論上書(shū)不受限。

????????POST的安全性要比GET的安全性高；

????????通過(guò)GET提交數(shù)據(jù)，用戶名和密碼將明文出現(xiàn)在URL上，比如登陸界面有可能被瀏覽器緩存。

HTTPS：安全超文本傳輸協(xié)議（Secure Hypertext Transfer Protocol），它是一個(gè)安全通信通道，基于HTTP開(kāi)發(fā)，用于客戶計(jì)算機(jī)和服務(wù)器之間交換信息，使用安全套結(jié)字層（SSI）進(jìn)行信息交換，即HTTP的安全版。

HTTP請(qǐng)求的哪些方法用過(guò)？什么時(shí)候選擇GET、POST、PUT？

HTTP中的同步和異步

Http協(xié)議30x的錯(cuò)誤是什么

Ping是什么協(xié)議

Http2.0如1.x的區(qū)別？

HTTP1.0：客戶端的每次請(qǐng)求都要建立一次單獨(dú)的連接，在處理完本次請(qǐng)求后，就自動(dòng)釋放連接

HTTP1.1：可以在一次連接中處理多個(gè)請(qǐng)求，并且多個(gè)請(qǐng)求可以疊加進(jìn)行，不需要等待一次請(qǐng)求結(jié)束后再發(fā)送下一個(gè)請(qǐng)求

HTTP2.0：兼容HTTP1.1（貌似是優(yōu)化版本，提高了Web性能）

Cookie

因?yàn)?Http?無(wú)狀態(tài)的特性，如果需要判斷是哪個(gè)用戶，這時(shí)就需要?Cookie?和?Session。

Cookie?存儲(chǔ)在客戶端，用來(lái)記錄用戶狀態(tài)，區(qū)分用戶。一般都是服務(wù)端把生成的?Cookie?通過(guò)響應(yīng)返回給客戶端，客戶端保存。

Session 存儲(chǔ)在網(wǎng)絡(luò)端，需要依賴 Cookie 機(jī)制。服務(wù)端生成了 Session 后，返回給客戶端，客戶端 setCookie:sessionID，所以下次請(qǐng)求的時(shí)候，客戶端把 Cookie 發(fā)送給服務(wù)端，服務(wù)端解析出 SessionID，在服務(wù)端根據(jù) SessionID 判斷當(dāng)前的用戶。 ?

修改 ：

? ? ? ? 1、相同?Key?值得新的?Cookie?會(huì)覆蓋舊的?Cookie。

? ? ? ? 2、覆蓋規(guī)則是 name path 和 domain 等需要與原有的一致。

刪除：

? ? ? ? 1、相同?Key?值得新的?Cookie?會(huì)覆蓋舊的?Cookie。

? ? ? ? 2、覆蓋規(guī)則是 name path 和 domain 等需要與原有的一致。

? ? ? ? 3、設(shè)置?Cookie?的?expires?為過(guò)去的一個(gè)時(shí)間點(diǎn)，或者?maxAge = 0。

如何保證?Cookie?的安全？

1、對(duì)?Cookie?進(jìn)行加密處理。

2、只在?Https?上攜帶?Cookie。

3、設(shè)置?Cookie?為?httpOnly，防止跨站腳本攻擊。

NSCache

自己設(shè)計(jì)一個(gè)緩存器

怎么實(shí)現(xiàn)LRU

MTU？

發(fā)送一個(gè)HTTP請(qǐng)求的過(guò)程

socket異常斷開(kāi)時(shí)，設(shè)計(jì)一個(gè)合理的重連機(jī)制。

斷點(diǎn)續(xù)傳怎么實(shí)現(xiàn)？需要設(shè)置什么？

斷點(diǎn)續(xù)傳可以分為兩部分：一部分是斷點(diǎn)，一部分是續(xù)傳。斷點(diǎn)續(xù)傳實(shí)質(zhì)就是能記錄上一次已下載完成的位置。

1、斷點(diǎn)續(xù)傳需要在下載過(guò)程中記錄每條線程的下載進(jìn)度。

2、每次下載開(kāi)始之前先讀取數(shù)據(jù)庫(kù)，查詢是否有未完成的記錄，有就繼續(xù)下載，沒(méi)有則創(chuàng)建新記錄插入數(shù)據(jù)庫(kù)。

3、在每次向文件中寫(xiě)入數(shù)據(jù)之后，在數(shù)據(jù)庫(kù)中更新下載進(jìn)度。

4、下載完成之后刪除數(shù)據(jù)庫(kù)中下載記錄。

描述下IM系統(tǒng)如何保證消息不丟

IM數(shù)據(jù)庫(kù)如何設(shè)計(jì)表

抓包工具抓取HTTPS的原理