1. http,https默認(rèn)端口都為多少泡一，區(qū)別？

2. http協(xié)議的組成

3. OSI七層模型

4. url 和 uri

5. http1.0和http1.1觅廓，http2.0的區(qū)別鼻忠？

6. get/post方法區(qū)別？

7. cookie和session區(qū)別杈绸？

8. 打開(kāi)瀏覽器粥烁，在地址欄中輸入U(xiǎn)RL，然后就看到網(wǎng)頁(yè)蝇棉，原理是什么讨阻？

9. http協(xié)議下，為什么請(qǐng)求和響應(yīng)能做到準(zhǔn)確無(wú)誤篡殷，一一對(duì)應(yīng)

10. DNS劫持

11. SSL和TLS

HTTP

超文本傳輸協(xié)議钝吮，一種運(yùn)用廣泛的網(wǎng)絡(luò)協(xié)議，所有的www文件都必須遵守這個(gè)標(biāo)準(zhǔn)

http通常承載于 tcp協(xié)議 之上板辽，有時(shí)也承載于 TLS 和 SSL 協(xié)議層之上奇瘦，這就是 HTTPS

HTTP默認(rèn)端口 80

HTTPS默認(rèn)端口 443

HTTP協(xié)議的特點(diǎn)：

1. 支持客戶/服務(wù)器模式

http是一種客戶請(qǐng)求，服務(wù)器應(yīng)答式的應(yīng)用層傳輸協(xié)議

2. 簡(jiǎn)單快速

客戶端向服務(wù)器發(fā)送請(qǐng)求數(shù)據(jù)時(shí)劲弦，只需傳送方法和路徑耳标，請(qǐng)求方法常用的有 GET， HEAD邑跪， PUT

3. 靈活性

http允許傳輸任意類型的數(shù)據(jù)對(duì)象次坡，正在傳輸?shù)念愋陀?Content-Type 加以標(biāo)記

4. 無(wú)連接，無(wú)狀態(tài)

每次http請(qǐng)求都是獨(dú)立的画畅，每次只處理一個(gè)請(qǐng)求砸琅，服務(wù)器對(duì)客戶端的請(qǐng)求作出響應(yīng)后,馬上斷開(kāi)連接，任意兩個(gè)請(qǐng)求之間沒(méi)有什么必然的聯(lián)系轴踱，但實(shí)際過(guò)程中并不是這樣的症脂，會(huì)引入 Cookie 和 Session 機(jī)制來(lái)關(guān)聯(lián)請(qǐng)求

HTTP請(qǐng)求由請(qǐng)求行，請(qǐng)求頭，請(qǐng)求體三部分組成：

1. 請(qǐng)求行

請(qǐng)求行包含三部分：

• method

• uri

• http版本诱篷，提示信息

image.png

1.1 method

1.2 URI 統(tǒng)一資源標(biāo)示符

URL 統(tǒng)一資源定位符

image.png

URI包含 URN 和 URL壶唤，URN作用相當(dāng)于 一個(gè)人的名字，URL 就像一個(gè)人的地址棕所，URN確定了身份闸盔，URL 提供了找到他的方式

讓URI成為 URL的 就是 “訪問(wèn)機(jī)制” “網(wǎng)絡(luò)位置”

• ftp://ftp.is.co.za/rfc/rfc1808.txt (also a URL because of the protocol)

• http://www.ietf.org/rfc/rfc2396.txt (also a URL because of the protocol)

• ldap://[2001:db8::7]/c=GB?objectClass?one (also a URL because of the protocol)

• mailto:John.Doe@example.com (also a URL because of the protocol)

• news:comp.infosystems.www.servers.unix (also a URL because of the protocol)

• tel:+1-816-555-1212

• telnet://192.0.2.16:80/ (also a URL because of the protocol)

• urn:oasis:names:specification:docbook:dtd:xml:4.1.2

OSI七層模型

image.png

image.png

image.png

image.png

應(yīng)用層：用來(lái)生成報(bào)文

傳輸層：用來(lái)切割報(bào)文的

網(wǎng)絡(luò)層：決定發(fā)往哪里去，按什么順序發(fā)橙凳，網(wǎng)絡(luò)層可以看成是個(gè)指路牌，即根據(jù)報(bào)文在路由表里尋找目標(biāo)服務(wù)器的地址笑撞。

鏈路層：鏈路層是用來(lái)檢測(cè)岛啸、確認(rèn)報(bào)文數(shù)據(jù)，然后就是作為接口茴肥，對(duì)接服務(wù)器或硬件的坚踩。

HTTP1.0，1.1瓤狐，2.0之間的區(qū)別：

http1.0 和 http1.1 區(qū)別：

• 緩存處理

• 帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用

• Host頭處理

• 長(zhǎng)連接 keep live

• 錯(cuò)誤通知的管理

1.1 緩存處理

http1.0主要持有它的頭部當(dāng)中的if-modify-since這個(gè)參數(shù)來(lái)作為緩存判斷的標(biāo)準(zhǔn)瞬铸，而http1.1則引入了更多的緩存策略。比如說(shuō)e_ tag础锐、if-none_match, e_tag是配合in_none_match來(lái)使用嗓节。就是說(shuō)http1.0和http1.1主要在緩存策略上有很大的不同

1.2 帶寬優(yōu)化及網(wǎng)絡(luò)連接使用

斷點(diǎn)續(xù)傳

在http1.0存在著一些浪費(fèi)帶寬的情況，比如說(shuō)客戶端只請(qǐng)求服務(wù)端的一小部分皆警，但是服務(wù)端卻把所有的東西都返回回來(lái)了拦宣，但是又不支持?jǐn)帱c(diǎn)續(xù)傳功能，而在http 1.1中引入了一個(gè)range范圍的頭部區(qū)域信姓，它允許只請(qǐng)求網(wǎng)絡(luò)資源的一部分鸵隧。這樣就方便了開(kāi)發(fā)者的選擇。

1.3 Host頭處理

在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址意推，因此豆瘫，請(qǐng)求消息中的URL并沒(méi)有傳遞主機(jī)名（hostname）。但隨著虛擬主機(jī)技術(shù)的發(fā)展菊值，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)（Multi-homed Web Servers）外驱，并且它們共享一個(gè)IP地址。HTTP1.1的請(qǐng)求消息和響應(yīng)消息都應(yīng)支持Host頭域腻窒，且請(qǐng)求消息中如果沒(méi)有Host頭域會(huì)報(bào)告一個(gè)錯(cuò)誤（400 Bad Request）

一個(gè)ip地址可以分配多個(gè)虛擬主機(jī)略步，最終請(qǐng)求都到這一個(gè)ip，需要區(qū)分是哪個(gè)域名請(qǐng)求過(guò)來(lái)的定页，必須有Host頭處理

1.4 長(zhǎng)連接

HTTP 1.1支持長(zhǎng)連接（PersistentConnection）和請(qǐng)求的流水線（Pipelining）處理趟薄，在一個(gè)TCP連接上可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲典徊，在HTTP1.1中默認(rèn)開(kāi)啟Connection： keep-alive杭煎，一定程度上彌補(bǔ)了HTTP1.0每次請(qǐng)求都要?jiǎng)?chuàng)建連接的缺點(diǎn)恩够。

1.5 錯(cuò)誤通知

在HTTP1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如409（Conflict）表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突羡铲；410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除蜂桶。

http1.1 和 http 2.0 區(qū)別：

• 新的傳輸格式：2.0采用二進(jìn)制格式，1.0基于文本格式

• 多路復(fù)用：連接共享也切，不同request可以使用同一個(gè)連接傳輸（最后根據(jù)每個(gè)request上id號(hào)組合成正常請(qǐng)求）

• header壓縮：由于1.X中header帶有大量的信息扑媚，并且得重復(fù)傳輸，2.0使用encoder來(lái)減少需要傳輸?shù)膆earder大小

• 服務(wù)端推送：同google的SPDUY（1.0的一種升級(jí)）一樣

GET和POST區(qū)別雷恃？

image.png

（https://blog.fundebug.com/2019/02/22/compare-http-method-get-and-post/）

（https://www.oschina.net/news/77354/http-get-post-different）

當(dāng)我們打開(kāi)瀏覽器輸入網(wǎng)址到頁(yè)面展示到我們面前疆股，究竟發(fā)生了什么呢？

（https://zhuanlan.zhihu.com/p/88940868）

HTTP協(xié)議下倒槐，請(qǐng)求和響應(yīng)這么做到一一對(duì)應(yīng)的

互聯(lián)網(wǎng)通信都是通過(guò)套接字來(lái)進(jìn)行通信的旬痹，套接字，是支持TCP/IP網(wǎng)絡(luò)通信的基本操作單元讨越，可以看作不同主機(jī)之間進(jìn)程進(jìn)行相互通信的端點(diǎn)两残，簡(jiǎn)單說(shuō)就是通信雙方的一種約定，用套接字相關(guān)函數(shù)來(lái)完成相關(guān)通信把跨。

簡(jiǎn)單可以舉例為： 套接字 = ip address + tcp/udp + 端口號(hào)

socket通信靠四元組進(jìn)行通信：

源ip 源端口 目的ip 目的端口

這四個(gè)值在一起起到了唯一定義一條連接人弓，兩個(gè)不同的tcp連接不能擁有4個(gè)完全相同的地址組件值

有的連接共享了相同的目的端口號(hào)，有點(diǎn)連接使用了相同的源ip地址着逐，有的使用了相同的目的ip地址票从，但沒(méi)有兩個(gè)不同的tcp連接4個(gè)值完全相同

一. HTTP通信傳輸

通信過(guò)程

image.png

客戶端輸入U(xiǎn)RL回車，DNS解析域名得到服務(wù)器的IP地址滨嘱，服務(wù)器在80端口監(jiān)聽(tīng)客戶端請(qǐng)求峰鄙，端口通過(guò)TCP/IP協(xié)議（可以通過(guò)Socket實(shí)現(xiàn)）建立連接。HTTP屬于TCP/IP模型中的運(yùn)用層協(xié)議太雨，所以通信的過(guò)程其實(shí)是對(duì)應(yīng)數(shù)據(jù)的入棧和出棧吟榴。

image.png

報(bào)文從應(yīng)用層傳送到運(yùn)輸層，運(yùn)輸層通過(guò)TCP三次握手和服務(wù)器建立連接囊扳，四次揮手釋放連接吩翻。

（https://zhuanlan.zhihu.com/p/74466717）

三次握手

image.png

為什么需要三次握手呢？

為了防止已失效的連接請(qǐng)求報(bào)文又發(fā)送到服務(wù)端锥咸，因而產(chǎn)生錯(cuò)誤

比如：client發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失狭瞎，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server搏予。本來(lái)這是一個(gè)早已失效的報(bào)文段熊锭，但是server收到此失效的連接請(qǐng)求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求，于是就向client發(fā)出確認(rèn)報(bào)文段碗殷，同意建立連接精绎。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)锌妻，新的連接就建立了代乃，由于client并沒(méi)有發(fā)出建立連接的請(qǐng)求，因此不會(huì)理睬server的確認(rèn)仿粹，也不會(huì)向server發(fā)送數(shù)據(jù)搁吓，但server卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來(lái)數(shù)據(jù)吭历。所以沒(méi)有采用“三次握手”堕仔，這種情況下server的很多資源就白白浪費(fèi)掉了。

四次揮手

[圖片上傳中...(image-218763-1574231629256-1)]

為什么需要四次揮手呢毒涧？

為什么需要四次揮手呢贮预？TCP是全雙工模式贝室，當(dāng)client發(fā)出FIN報(bào)文段時(shí)契讲，只是表示client已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了，client告訴server滑频，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了捡偏；但是，這個(gè)時(shí)候client還是可以接受來(lái)server的數(shù)據(jù)峡迷；當(dāng)server返回ACK報(bào)文段時(shí)银伟，表示它已經(jīng)知道client沒(méi)有數(shù)據(jù)發(fā)送了，但是server還是可以發(fā)送數(shù)據(jù)到client的绘搞；當(dāng)server也發(fā)送了FIN報(bào)文段時(shí)彤避，這個(gè)時(shí)候就表示server也沒(méi)有數(shù)據(jù)要發(fā)送了，就會(huì)告訴client夯辖，我也沒(méi)有數(shù)據(jù)要發(fā)送了琉预，如果收到client確認(rèn)報(bào)文段，之后彼此就會(huì)愉快的中斷這次TCP連接蒿褂。

什么是全雙工呢圆米？

（https://blog.csdn.net/yimingsilence/article/details/72854516）

二. HTTPS實(shí)現(xiàn)原理

image.png

• client向server發(fā)送請(qǐng)求https://baidu.com，然后連接到server的443端口啄栓，發(fā)送的信息主要是隨機(jī)值1和客戶端支持的加密算法娄帖。

• server接收到信息之后給予client響應(yīng)握手信息，包括隨機(jī)值2和匹配好的協(xié)商加密算法昙楚，這個(gè)加密算法一定是client發(fā)送給server加密算法的子集近速。

• 隨即server給client發(fā)送第二個(gè)響應(yīng)報(bào)文是數(shù)字證書。服務(wù)端必須要有一套數(shù)字證書，可以自己制作数焊，也可以向組織申請(qǐng)永淌。區(qū)別就是自己頒發(fā)的證書需要客戶端驗(yàn)證通過(guò)，才可以繼續(xù)訪問(wèn)佩耳，而使用受信任的公司申請(qǐng)的證書則不會(huì)彈出提示頁(yè)面遂蛀，這套證書其實(shí)就是一對(duì)公鑰和私鑰。傳送證書干厚，這個(gè)證書其實(shí)就是公鑰李滴，只是包含了很多信息，如證書的頒發(fā)機(jī)構(gòu)蛮瞄，過(guò)期時(shí)間所坯、服務(wù)端的公鑰，第三方證書認(rèn)證機(jī)構(gòu)(CA)的簽名挂捅，服務(wù)端的域名信息等內(nèi)容芹助。

• 客戶端解析證書，這部分工作是由客戶端的TLS來(lái)完成的闲先，首先會(huì)驗(yàn)證公鑰是否有效状土，比如頒發(fā)機(jī)構(gòu)，過(guò)期時(shí)間等等伺糠，如果發(fā)現(xiàn)異常蒙谓，則會(huì)彈出一個(gè)警告框，提示證書存在問(wèn)題训桶。如果證書沒(méi)有問(wèn)題累驮，那么就生成一個(gè)隨即值（預(yù)主秘鑰）。

• 客戶端認(rèn)證證書通過(guò)之后舵揭，接下來(lái)是通過(guò)隨機(jī)值1谤专、隨機(jī)值2和預(yù)主秘鑰組裝會(huì)話秘鑰。然后通過(guò)證書的公鑰加密會(huì)話秘鑰午绳。

• 傳送加密信息置侍，這部分傳送的是用證書加密后的會(huì)話秘鑰，目的就是讓服務(wù)端使用秘鑰解密得到隨機(jī)值1箱叁、隨機(jī)值2和預(yù)主秘鑰墅垮。

• 服務(wù)端解密得到隨機(jī)值1、隨機(jī)值2和預(yù)主秘鑰耕漱，然后組裝會(huì)話秘鑰算色，跟客戶端會(huì)話秘鑰相同。

• 客戶端通過(guò)會(huì)話秘鑰加密一條消息發(fā)送給服務(wù)端螟够，主要驗(yàn)證服務(wù)端是否正常接受客戶端加密的消息灾梦。

• 同樣服務(wù)端也會(huì)通過(guò)會(huì)話秘鑰加密一條消息回傳給客戶端峡钓，如果客戶端能夠正常接受的話表明SSL層連接建立完成了。

HTTP 狀態(tài)碼

image.png

image.png

image.png

image.png

具體應(yīng)用

image.png

參考文獻(xiàn)（https://juejin.im/post/5dc63c5bf265da4d17138c2d?utm_source=gold_browser_extension）