本文對網(wǎng)絡(luò)知識進(jìn)行總結(jié)各谚。

1.網(wǎng)絡(luò)基礎(chǔ)

1.1 GET和POST的請求的區(qū)別

POST弓叛、GET是http的兩種請求方式状植，其主要區(qū)別如下：

• 應(yīng)用場景： GET請求是一個冪等的請求葛超，一般GET請求不會對資源服務(wù)器產(chǎn)生影響官扣，而POST非冪等請求墩莫，會對資源服務(wù)器產(chǎn)生影響芙委。
• 是否緩存： 瀏覽器一般會對GET請求進(jìn)行緩存，但是很少對POST請求進(jìn)行緩存狂秦。
• 發(fā)送報文形式： GET請求灌侣，實(shí)體部分為空。POST請求報文實(shí)體部分一般為向服務(wù)器發(fā)送數(shù)據(jù)裂问。
• 安全性： GET接口請求參數(shù)放到URL中侧啼，這樣對于POST請求是不安全的牛柒，因?yàn)樵L問的記錄保存在歷史記錄中。
• 請求長度： 由于瀏覽器對url的限制痊乾，所以會影響get請求發(fā)送時的長度皮壁。這個是瀏覽器自身限制，非RFC限制哪审。
• 請求參數(shù)： POST支持更多的請求參數(shù)蛾魄。

注：冪等的請求： 一個HTTP方法是冪等的，指的是同樣的請求被執(zhí)行一次與連續(xù)執(zhí)行多次的效果是一樣的湿滓，服務(wù)器的狀態(tài)也是一樣的滴须。換句話說就是，冪等方法不應(yīng)該具有副作用（統(tǒng)計用途除外）茉稠。在正確實(shí)現(xiàn)的條件下描馅， GET， HEAD 而线， PUT和 DELETE 等方法都是冪等的铭污，而 POST 方法不是。

1.2 POST和PUT請求的區(qū)別

• PUT請求是向服務(wù)器發(fā)送數(shù)據(jù)膀篮，從而修改數(shù)據(jù)內(nèi)容嘹狞，但是不會增加數(shù)據(jù)種類，也就是無論P(yáng)UT幾次誓竿，其結(jié)果一樣磅网。（更新數(shù)據(jù)）
• POST請求是向服務(wù)器發(fā)送數(shù)據(jù)，從而改變數(shù)據(jù)資源和種類筷屡，他會新建新的資源涧偷。（新增數(shù)據(jù)）

1.3 常見HTTP請求和響應(yīng)頭

HTTP請求頭有如下：

• Referer：發(fā)出請求頁面url
• Accept-Charset：瀏覽器能夠處理的內(nèi)容
• Accept-Encoding：瀏覽器能夠顯示的字符集
• Connection：瀏覽器和服務(wù)器之間的連接
• Cookie：當(dāng)前頁面設(shè)置的cookie
• Host：當(dāng)前頁面所在的域名
• Referer：發(fā)送頁面請求的url
• User-Agent：瀏覽器用戶代理字符串
  HTTP響應(yīng)頭：
• Date：表示用戶發(fā)送消息的時間
• Server：服務(wù)器名稱
• Cache-Control：控制緩存
• Content-Type：返回的文檔類型

1.4 HTTP 和 HTTPS 區(qū)別

• HTTPS需要CA證書，費(fèi)用較高毙死；而HTTP協(xié)議不需要
• HTTPS是超文本傳輸協(xié)議燎潮，信息是明文傳輸，HTTPS則是具有安全性的SSL加密傳輸協(xié)議
• 使用連接方式不同扼倘，端口也不同确封，HTTP是80，HTTPS是443
• HTTP連接是簡單的再菊，無狀態(tài)爪喘；而HTTPS是具有SSL和HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議纠拔，比HTTP更安全秉剑。

1.5 TCP三次握手

image.png

• 第一次握手：客戶端發(fā)送SYN報文，進(jìn)行SYN_SEND狀態(tài)稠诲，等待服務(wù)端確認(rèn)秃症。
• 第二次握手：服務(wù)端收到SYN報文候址，需要給客戶端發(fā)送ACK確認(rèn)報文吕粹，同時服務(wù)端也向客戶端發(fā)送一個SYN報文种柑，即SYN+ACK報文，這個SYN報文和上面第一次握手報文不一樣匹耕，這是服務(wù)端的報文聚请，服務(wù)端進(jìn)行SYN_RCVD狀態(tài)。
• 第三次握手：客戶端收到SYN+ACK報文稳其，向服務(wù)端發(fā)送確認(rèn)包（ACK）驶赏，客戶端進(jìn)入ESTABLISHED狀態(tài)，待服務(wù)端收到客戶端發(fā)送的ACK后既鞠，服務(wù)端也進(jìn)入ESTABLISHED狀態(tài)煤傍，并完成三次握手。

延伸問題：

二次握手可以嗎嘱蛋？

TCP建立之前蚯姆，需要確認(rèn)客戶端和服務(wù)端雙方包容和發(fā)包能力。

• 第一次握手： 客戶端發(fā)送網(wǎng)絡(luò)包洒敏，服務(wù)端接收到龄恋，這樣服務(wù)端能得到結(jié)論：客戶端的發(fā)送能力、服務(wù)端的接收能力政策凶伙。
• 第二次握手： 服務(wù)端發(fā)包郭毕，客戶端收到，這樣客戶端能收到結(jié)論：服務(wù)端發(fā)送能力函荣、接收能力正常显押，客戶端接收、發(fā)送能力正常傻挂，但是客戶端不明確服務(wù)端是否知道客戶端接收能力正常乘碑。
• 第三次握手： 客戶端發(fā)包，服務(wù)端接收到踊谋，這樣服務(wù)端就能確定蝉仇，客戶端的接收能力正常。

進(jìn)一步學(xué)習(xí)殖蚕，可閱讀鏈接：淘寶二面轿衔，面試官居然把TCP三次握手問的這么詳細(xì)

1.6 TCP四次揮手

image.png

• 第一次揮手：客戶端發(fā)起FIN包（FIN = 1），客戶端進(jìn)入FIN_WAIT_1狀態(tài)睦疫。TCP規(guī)定害驹，即使FIN包不攜帶數(shù)據(jù)，也要消耗一個序號蛤育。
• 第二次揮手：服務(wù)端收到FIN包宛官，發(fā)出ACK（ACK = u + 1）葫松，并攜帶自己的序號seq = v，服務(wù)端進(jìn)入CLOSE_WAIT_1狀態(tài)底洗，這時客戶端已經(jīng)沒有數(shù)據(jù)需要發(fā)送腋么，這時如果服務(wù)端如果有數(shù)據(jù)要發(fā)送，客戶端依舊需要接受亥揖，客戶端接受到ACK和seq后珊擂，進(jìn)行FIN_WAIT_2狀態(tài)。
• 第三次揮手：服務(wù)端數(shù)據(jù)發(fā)送完畢费变，向客戶端發(fā)送FIN包（seq = w摧扇，ACK = u + 1），半連接狀態(tài)服務(wù)端可能還會發(fā)送其他數(shù)據(jù)給客戶端挚歧，加入發(fā)送數(shù)據(jù)是seq = w扛稽，服務(wù)端此時進(jìn)入LAST_ACK狀態(tài)。
• 第四次揮手：刻度端收到FIN包后滑负，發(fā)出確認(rèn)包（ACK = 1在张，seq = u + 1），此時客戶端進(jìn)入TIME_WAIT狀態(tài)橙困，此時TCP連接還沒釋放瞧掺。經(jīng)過2 * MSL后，才進(jìn)入CLOSED狀態(tài)凡傅。服務(wù)端在接受到確認(rèn)包后辟狈，就進(jìn)入了CLOSED狀態(tài)，可以看出服務(wù)端比客戶端更快斷開連接夏跷。

延伸問題：

為什么建立連接握手三次哼转，關(guān)閉連接時需要是四次呢？

其實(shí)在TCP握手的時候槽华，接受端發(fā)送SYN+ACK的包是將ACK和SYN合并在一起壹蔓，合到一個包中，所以減少了一個包的發(fā)送猫态，減少了一次請求佣蓉。

對于四次揮手，由于TCP是全雙工通信亲雪，在主動關(guān)閉方發(fā)送確認(rèn)包后勇凭，接受可能還需要接受數(shù)據(jù)，不能馬上關(guān)閉通信通道义辕，所以不能將服務(wù)端的FIN包和ACK進(jìn)行合并虾标，只能先確定ACK，等待服務(wù)端沒有再發(fā)送數(shù)據(jù)時灌砖，發(fā)送FIN包璧函，所以四次揮手是四次數(shù)據(jù)包的交互傀蚌。

1.7 TCP和UDP

TCP和UDP都是屬于傳輸層協(xié)議，都屬于TCP/IP協(xié)議族：

UDP

UDP全稱：用戶數(shù)據(jù)報協(xié)議蘸吓。在網(wǎng)絡(luò)中善炫，它處理數(shù)據(jù)包，是一種無連接協(xié)議美澳。在OSI中销部，其屬于IP協(xié)議上一層。UDP不提供數(shù)據(jù)包分組制跟、組裝、和對數(shù)據(jù)排序能力酱虎，當(dāng)數(shù)據(jù)包發(fā)送后雨膨，無法得知服務(wù)端是否接受成功。

特點(diǎn)：

• 面向無連接：UDP不需要像TCP那樣進(jìn)行三次握手读串，想發(fā)送就可以發(fā)送聊记。
• 單播、多播恢暖、廣播特點(diǎn)：UDP支持一對多排监、多對多、多對一的方式杰捂。
• 面向報文：發(fā)送方的UDP對應(yīng)用程序交下來的報文舆床，在添加首部后就向下交付IP層。UDP對應(yīng)用層交下來的報文嫁佳，既不合并挨队，也不拆分，而是保留這些報文的邊界蒿往。因此盛垦，應(yīng)用程序必須選擇合適大小的報文。
• 不可靠性：UDP不需要建立瓤漏，想發(fā)就發(fā)腾夯，這是不可靠的。
• 頭部開銷小蔬充，傳輸高效蝶俱。

TCP

TCP特點(diǎn)：

• 面向連接：需要三次握手才能建立可靠連接。
• 只支持單播傳輸：每條TCP連接只支持點(diǎn)對點(diǎn)連接和傳輸娃惯，不支持多播跷乐、廣播。
• 可靠傳輸：由于建立可靠的連接趾浅，以及有對應(yīng)判斷丟碼愕提、編碼馒稍，還有重傳的機(jī)制。
• 提供擁塞控制：當(dāng)連接擁塞時浅侨，能減少網(wǎng)絡(luò)的注入數(shù)據(jù)
• 全雙工通信：TCP允許通信雙方的應(yīng)用程序在任何時候都能發(fā)送數(shù)據(jù)纽谒，因?yàn)門CP連接的兩端都設(shè)有緩存，用來臨時存放雙向通信的數(shù)據(jù)如输。當(dāng)然鼓黔，TCP可以立即發(fā)送一個數(shù)據(jù)段，也可以緩存一段時間以便一次發(fā)送更多的數(shù)據(jù)段（最大的數(shù)據(jù)段大小取決于MSS）

進(jìn)一步學(xué)習(xí)不见，可閱讀鏈接：一文搞懂TCP與UDP的區(qū)別

1.8 HTTP2.0和HTTP1.1區(qū)別

• 二進(jìn)制協(xié)議： HTTP2.0是一個二進(jìn)制協(xié)議澳化。在HTTP1.1中，報文頭部是文本（ASCII編碼）稳吮，數(shù)據(jù)報可以為文本缎谷，也可以是二進(jìn)展。在HTTP2.0中灶似，報文頭部徹底是二進(jìn)制列林，消息體和數(shù)據(jù)體都是二進(jìn)制，并統(tǒng)稱為‘幀’酪惭，這個是HTTP2.0多路復(fù)用的基礎(chǔ)希痴。
• 多路復(fù)用： HTTP2.0實(shí)現(xiàn)了多路復(fù)用，雖然HTTP2.0依舊使用TCP協(xié)議春感，但是一個連接中砌创，客戶端和服務(wù)端可以同時發(fā)送、接收多個請求甥厦，避免‘隊頭阻塞’的問題
• 數(shù)據(jù)流： HTTP2.0實(shí)現(xiàn)數(shù)據(jù)流的概念纺铭，因?yàn)镠TTP2.0的數(shù)據(jù)包是不按順序，同一連接里面的數(shù)據(jù)包刀疙，可能屬于不同請求舶赔，需要對數(shù)據(jù)包做標(biāo)記，指出屬于那個請求谦秧，HTTP2.0將每個請求或響應(yīng)的數(shù)據(jù)包竟纳，成為數(shù)據(jù)流。
• 頭信息壓縮： HTTP2.0實(shí)現(xiàn)頭信息的壓縮
• 服務(wù)端推送： HTTP2.0允許服務(wù)器沒經(jīng)過請求疚鲤，主動向客戶端推送資源（靜態(tài)資源）锥累，這個稱為服務(wù)端推送。

1.9 OSI七層模型