http,https默認(rèn)端口都為多少，區(qū)別？
http協(xié)議的組成
OSI七層模型
url 和 uri
http1.0和http1.1，http2.0的區(qū)別？
get/post方法區(qū)別？
cookie和session區(qū)別？
打開瀏覽器，在地址欄中輸入URL，然后就看到網(wǎng)頁，原理是什么？
http協(xié)議下，為什么請求和響應(yīng)能做到準(zhǔn)確無誤，一一對應(yīng)
DNS劫持
SSL和TLS
HTTP
超文本傳輸協(xié)議，一種運用廣泛的網(wǎng)絡(luò)協(xié)議，所有的www文件都必須遵守這個標(biāo)準(zhǔn)
http通常承載于 tcp協(xié)議 之上，有時也承載于 TLS 和 SSL 協(xié)議層之上，這就是 HTTPS
HTTP默認(rèn)端口 80
HTTPS默認(rèn)端口 443
HTTP協(xié)議的特點：
- 支持客戶/服務(wù)器模式
http是一種客戶請求，服務(wù)器應(yīng)答式的應(yīng)用層傳輸協(xié)議
- 簡單快速
客戶端向服務(wù)器發(fā)送請求數(shù)據(jù)時，只需傳送方法和路徑，請求方法常用的有 GET， HEAD， PUT
- 靈活性
http允許傳輸任意類型的數(shù)據(jù)對象，正在傳輸?shù)念愋陀?Content-Type 加以標(biāo)記
- 無連接，無狀態(tài)
每次http請求都是獨立的，每次只處理一個請求，服務(wù)器對客戶端的請求作出響應(yīng)后,馬上斷開連接，任意兩個請求之間沒有什么必然的聯(lián)系，但實際過程中并不是這樣的，會引入 Cookie 和 Session 機制來關(guān)聯(lián)請求
HTTP請求由請求行，請求頭，請求體三部分組成：
- 請求行
請求行包含三部分：
method
uri
http版本，提示信息
1.1 method
1.2 URI 統(tǒng)一資源標(biāo)示符
URL 統(tǒng)一資源定位符
URI包含 URN 和 URL，URN作用相當(dāng)于 一個人的名字，URL 就像一個人的地址，URN確定了身份，URL 提供了找到他的方式
讓URI成為 URL的 就是 “訪問機制” “網(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七層模型
應(yīng)用層：用來生成報文
傳輸層：用來切割報文的
網(wǎng)絡(luò)層：決定發(fā)往哪里去，按什么順序發(fā)，網(wǎng)絡(luò)層可以看成是個指路牌，即根據(jù)報文在路由表里尋找目標(biāo)服務(wù)器的地址。
鏈路層：鏈路層是用來檢測、確認(rèn)報文數(shù)據(jù)，然后就是作為接口，對接服務(wù)器或硬件的。
HTTP1.0，1.1，2.0之間的區(qū)別：
http1.0 和 http1.1 區(qū)別：
緩存處理
帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用
Host頭處理
長連接 keep live
錯誤通知的管理
1.1 緩存處理
http1.0主要持有它的頭部當(dāng)中的if-modify-since這個參數(shù)來作為緩存判斷的標(biāo)準(zhǔn)，而http1.1則引入了更多的緩存策略。比如說e_ tag、if-none_match, e_tag是配合in_none_match來使用。就是說http1.0和http1.1主要在緩存策略上有很大的不同
1.2 帶寬優(yōu)化及網(wǎng)絡(luò)連接使用
斷點續(xù)傳
在http1.0存在著一些浪費帶寬的情況，比如說客戶端只請求服務(wù)端的一小部分，但是服務(wù)端卻把所有的東西都返回回來了，但是又不支持?jǐn)帱c續(xù)傳功能，而在http 1.1中引入了一個range范圍的頭部區(qū)域，它允許只請求網(wǎng)絡(luò)資源的一部分。這樣就方便了開發(fā)者的選擇。
1.3 Host頭處理
在HTTP1.0中認(rèn)為每臺服務(wù)器都綁定一個唯一的IP地址，因此，請求消息中的URL并沒有傳遞主機名（hostname）。但隨著虛擬主機技術(shù)的發(fā)展，在一臺物理服務(wù)器上可以存在多個虛擬主機（Multi-homed Web Servers），并且它們共享一個IP地址。HTTP1.1的請求消息和響應(yīng)消息都應(yīng)支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）
一個ip地址可以分配多個虛擬主機，最終請求都到這一個ip，需要區(qū)分是哪個域名請求過來的，必須有Host頭處理
1.4 長連接
HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲，在HTTP1.1中默認(rèn)開啟Connection： keep-alive，一定程度上彌補了HTTP1.0每次請求都要創(chuàng)建連接的缺點。
1.5 錯誤通知
在HTTP1.1中新增了24個錯誤狀態(tài)響應(yīng)碼，如409（Conflict）表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個資源被永久性的刪除。
http1.1 和 http 2.0 區(qū)別：
新的傳輸格式：2.0采用二進(jìn)制格式，1.0基于文本格式
多路復(fù)用：連接共享，不同request可以使用同一個連接傳輸（最后根據(jù)每個request上id號組合成正常請求）
header壓縮：由于1.X中header帶有大量的信息，并且得重復(fù)傳輸，2.0使用encoder來減少需要傳輸?shù)膆earder大小
服務(wù)端推送：同google的SPDUY（1.0的一種升級）一樣
GET和POST區(qū)別？
（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)我們打開瀏覽器輸入網(wǎng)址到頁面展示到我們面前，究竟發(fā)生了什么呢？
（https://zhuanlan.zhihu.com/p/88940868）
HTTP協(xié)議下，請求和響應(yīng)這么做到一一對應(yīng)的
互聯(lián)網(wǎng)通信都是通過套接字來進(jìn)行通信的，套接字，是支持TCP/IP網(wǎng)絡(luò)通信的基本操作單元，可以看作不同主機之間進(jìn)程進(jìn)行相互通信的端點，簡單說就是通信雙方的一種約定，用套接字相關(guān)函數(shù)來完成相關(guān)通信。
簡單可以舉例為： 套接字 = ip address + tcp/udp + 端口號
socket通信靠四元組進(jìn)行通信：
源ip 源端口 目的ip 目的端口
這四個值在一起起到了唯一定義一條連接，兩個不同的tcp連接不能擁有4個完全相同的地址組件值
有的連接共享了相同的目的端口號，有點連接使用了相同的源ip地址，有的使用了相同的目的ip地址，但沒有兩個不同的tcp連接4個值完全相同
一. HTTP通信傳輸
通信過程
客戶端輸入URL回車，DNS解析域名得到服務(wù)器的IP地址，服務(wù)器在80端口監(jiān)聽客戶端請求，端口通過TCP/IP協(xié)議（可以通過Socket實現(xiàn)）建立連接。HTTP屬于TCP/IP模型中的運用層協(xié)議，所以通信的過程其實是對應(yīng)數(shù)據(jù)的入棧和出棧。
報文從應(yīng)用層傳送到運輸層，運輸層通過TCP三次握手和服務(wù)器建立連接，四次揮手釋放連接。
（https://zhuanlan.zhihu.com/p/74466717）
三次握手
為什么需要三次握手呢？
為了防止已失效的連接請求報文又發(fā)送到服務(wù)端，因而產(chǎn)生錯誤
比如：client發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡(luò)結(jié)點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達(dá)server。本來這是一個早已失效的報文段，但是server收到此失效的連接請求報文段后，就誤認(rèn)為是client再次發(fā)出的一個新的連接請求，于是就向client發(fā)出確認(rèn)報文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)，新的連接就建立了，由于client并沒有發(fā)出建立連接的請求，因此不會理睬server的確認(rèn)，也不會向server發(fā)送數(shù)據(jù)，但server卻以為新的運輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。所以沒有采用“三次握手”，這種情況下server的很多資源就白白浪費掉了。
四次揮手
[圖片上傳中...(image-218763-1574231629256-1)]
為什么需要四次揮手呢？
為什么需要四次揮手呢？TCP是全雙工模式，當(dāng)client發(fā)出FIN報文段時，只是表示client已經(jīng)沒有數(shù)據(jù)要發(fā)送了，client告訴server，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了；但是，這個時候client還是可以接受來server的數(shù)據(jù)；當(dāng)server返回ACK報文段時，表示它已經(jīng)知道client沒有數(shù)據(jù)發(fā)送了，但是server還是可以發(fā)送數(shù)據(jù)到client的；當(dāng)server也發(fā)送了FIN報文段時，這個時候就表示server也沒有數(shù)據(jù)要發(fā)送了，就會告訴client，我也沒有數(shù)據(jù)要發(fā)送了，如果收到client確認(rèn)報文段，之后彼此就會愉快的中斷這次TCP連接。
什么是全雙工呢？
（https://blog.csdn.net/yimingsilence/article/details/72854516）
二. HTTPS實現(xiàn)原理
client向server發(fā)送請求https://baidu.com，然后連接到server的443端口，發(fā)送的信息主要是隨機值1和客戶端支持的加密算法。
server接收到信息之后給予client響應(yīng)握手信息，包括隨機值2和匹配好的協(xié)商加密算法，這個加密算法一定是client發(fā)送給server加密算法的子集。
隨即server給client發(fā)送第二個響應(yīng)報文是數(shù)字證書。服務(wù)端必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請。區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過，才可以繼續(xù)訪問，而使用受信任的公司申請的證書則不會彈出提示頁面，這套證書其實就是一對公鑰和私鑰。傳送證書，這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發(fā)機構(gòu)，過期時間、服務(wù)端的公鑰，第三方證書認(rèn)證機構(gòu)(CA)的簽名，服務(wù)端的域名信息等內(nèi)容。
客戶端解析證書，這部分工作是由客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發(fā)機構(gòu)，過期時間等等，如果發(fā)現(xiàn)異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那么就生成一個隨即值（預(yù)主秘鑰）。
客戶端認(rèn)證證書通過之后，接下來是通過隨機值1、隨機值2和預(yù)主秘鑰組裝會話秘鑰。然后通過證書的公鑰加密會話秘鑰。
傳送加密信息，這部分傳送的是用證書加密后的會話秘鑰，目的就是讓服務(wù)端使用秘鑰解密得到隨機值1、隨機值2和預(yù)主秘鑰。
服務(wù)端解密得到隨機值1、隨機值2和預(yù)主秘鑰，然后組裝會話秘鑰，跟客戶端會話秘鑰相同。
客戶端通過會話秘鑰加密一條消息發(fā)送給服務(wù)端，主要驗證服務(wù)端是否正常接受客戶端加密的消息。
同樣服務(wù)端也會通過會話秘鑰加密一條消息回傳給客戶端，如果客戶端能夠正常接受的話表明SSL層連接建立完成了。
HTTP 狀態(tài)碼
具體應(yīng)用
參考文獻(xiàn)（https://juejin.im/post/5dc63c5bf265da4d17138c2d?utm_source=gold_browser_extension）
