HTTP協(xié)議
-
TCP/IP 協(xié)議族：
TCP/IP 協(xié)議族是Internet最基本的協(xié)議翰灾，HTTP協(xié)議是它的一個子集。TCP/IP協(xié)議族按層次分為以下四層：- 應(yīng)用層：向用戶提供應(yīng)用服務(wù)時通信的協(xié)議们镜，FTP(文件傳輸協(xié)議)和DNS(域名系統(tǒng))服務(wù)就是其中的兩類
-
傳輸層：傳輸層對接上層應(yīng)用層晕讲，在傳輸層有兩個性質(zhì)不同的協(xié)議：TCP和UDP组橄；</br>
- TCP協(xié)議是全雙工的衣吠，即發(fā)送數(shù)據(jù)和接收數(shù)據(jù)是同步進(jìn)行的，TCP協(xié)議在建立和斷開連接時有三次握手和四次揮手小压，因此在傳輸?shù)倪^程中更穩(wěn)定可靠但同時就沒UDP那么高效了;
- UDP協(xié)議是面向無連接的线梗，UDP協(xié)議不保證有序且不丟失的傳遞到對端，也就是說不夠穩(wěn)定怠益，但也正因如此仪搔，UDP協(xié)議比TCP更加高效和輕便;
- 網(wǎng)絡(luò)層：網(wǎng)絡(luò)層規(guī)定了數(shù)據(jù)通過怎樣的傳輸路線到達(dá)對方計(jì)算機(jī)傳送給對方（IP協(xié)議等）
- 鏈路層：用來處理連接網(wǎng)絡(luò)的硬件部分，包括控制操作系統(tǒng)蜻牢、硬件的設(shè)備驅(qū)動烤咧、NIC（網(wǎng)絡(luò)適配器偏陪，即網(wǎng)卡），及光纖等物理可見部分煮嫌，硬件上的范疇均在鏈路層的作用范圍之內(nèi)
- HTTP/1.0:短連接笛谦，瀏覽器的每次請求都需要與服務(wù)器建立一個TCP連接，服務(wù)器完成請求處理后立即斷開TCP連接
- HTTP/1.1:長連接昌阿，加入keep-alive后實(shí)現(xiàn)長連接饥脑，如果開啟 keep-alive，則服務(wù)端在返回 response 后/客戶端接收完響應(yīng)報(bào)文后不關(guān)閉TCP連接宝泵；在 HTTP/1.1協(xié)議中好啰，默認(rèn)開啟keep-alive
- HTTP/2.0多路復(fù)用：每個HTTP請求都有一個序列標(biāo)識符，這樣瀏覽器可以并發(fā)多個請求儿奶，服務(wù)器接收到數(shù)據(jù)后，再根據(jù)序列標(biāo)識符重新排序成不同的請求報(bào)文鳄抒，而不會導(dǎo)致數(shù)據(jù)錯亂闯捎；同樣，服務(wù)端也可以并發(fā)返回多個響應(yīng)給瀏覽器许溅；并且同一個域名下的所有請求都復(fù)用同一個TCP連接瓤鼻，極大增加了服務(wù)器處理并發(fā)的上限
- WebSocket：WebSocket是HTML5提出的一種客戶端和服務(wù)端通訊的全雙工協(xié)議，由客戶端發(fā)起請求贤重，建立連接之后不僅客戶端可以主動向服務(wù)端發(fā)送請求茬祷，服務(wù)端可以主動向客戶端推送信息
-
HTTP/3.0：HTTP/2.0使用了多路復(fù)用，一般來說同一域名下只需要使用一個TCP連接并蝗，但當(dāng)這個連接中出現(xiàn)了丟包的情況祭犯，那就會導(dǎo)致整個TCP都要開始等待重傳，也就導(dǎo)致了后面的所有數(shù)據(jù)都被阻塞了滚停。Google基于UDP協(xié)議推出了一個的 QUIC 協(xié)議沃粗，并且使用在了HTTP/3上，QUIC主要特點(diǎn)如下：
- 避免包阻塞：在基于UDP的QUIC協(xié)議中键畴，不同的流之間的數(shù)據(jù)傳輸真正實(shí)現(xiàn)了相互獨(dú)立互不干擾最盅，某個流的數(shù)據(jù)包在出問題需要重傳時，并不會對其他流的數(shù)據(jù)包傳輸產(chǎn)生影響
- 快速重啟會話：普通基于tcp的連接起惕，是基于兩端的ip和端口和協(xié)議來建立的涡贱。在網(wǎng)絡(luò)切換場景，例如手機(jī)端切換了無線網(wǎng)惹想，使用4G網(wǎng)絡(luò)问词，會改變本身的ip，這就導(dǎo)致tcp連接必須重新創(chuàng)建勺馆。而QUIC協(xié)議使用特有的UUID來標(biāo)記每一次連接戏售，在網(wǎng)絡(luò)環(huán)境發(fā)生變化的時候侨核，只要UUID不變，就能不需要握手灌灾，繼續(xù)傳輸數(shù)據(jù)
HTTPS
HTTP是明文傳輸協(xié)議搓译，HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議锋喜，比HTTP協(xié)議安全
-
加密方式：對稱加密+非對稱加密
- 在交換密鑰環(huán)節(jié)使用非對稱加密方式些己，之后的建立通信交換報(bào)文階段則使用對稱加密方式
-
數(shù)字簽名:解決報(bào)文可能遭篡改問題
- 將一段文本先用Hash函數(shù)生成消息摘要，然后用發(fā)送者的私鑰加密生成數(shù)字簽名嘿般，與原文文一起傳送給接收者
-
數(shù)字證書:解決通信方身份可能被偽裝的問題
- 數(shù)字證書認(rèn)證機(jī)構(gòu)處于客戶端與服務(wù)器雙方都可信賴的第三方機(jī)構(gòu)的立場上
-
HTTPS請求流程：
- 客戶端發(fā)起一個HTTPS的請求段标；
- 服務(wù)端把事先配置好的公鑰證書返回給客戶端
- 客戶端驗(yàn)證公鑰證書，如果驗(yàn)證通過則繼續(xù)炉奴，不通過則顯示警告信息逼庞；
- 客戶端生成加密所使用的對稱密鑰，然后用證書的公鑰加密這個對稱密鑰瞻赶，發(fā)給服務(wù)端
- 服務(wù)端使用自己的私鑰解密這個消息赛糟，得到對稱密鑰，至此砸逊，客戶端和服務(wù)端雙方都持有了相同的對稱密鑰
- 服務(wù)端使用對稱密鑰加密“明文內(nèi)容A”璧南，發(fā)送給客戶端；客戶端使用對稱密鑰解密響應(yīng)的密文师逸，得到“明文內(nèi)容A”
-
HTTP與HTTPS的區(qū)別
- HTTPS比HTTP更加安全司倚，對搜索引擎更友好，利于SEO,谷歌篓像、百度優(yōu)先索引HTTPS網(wǎng)頁动知；
- HTTPS需要用到SSL證書
- HTTPS標(biāo)準(zhǔn)端口443，HTTP標(biāo)準(zhǔn)端口80
- HTTPS基于傳輸層遗淳，HTTP基于應(yīng)用層
- HTTPS在瀏覽器顯示綠色安全鎖拍柒，HTTP沒有顯示
TCP
-
三次握手流程：
- 客戶端發(fā)送SYN，表明要向服務(wù)器建立連接屈暗。同時帶上序列號ISN
- 服務(wù)端返回ACK（序號為客戶端序列號+1）作為確認(rèn)拆讯。同時發(fā)送SYN作為應(yīng)答（SYN的序列號為服務(wù)端唯一的序號）
- 客戶端發(fā)送ACK確認(rèn)收到回復(fù)（序列號為服務(wù)端序列號+1）
-
為什么是三次握手
- 第一次握手：證明了發(fā)送方能發(fā)數(shù)據(jù)
- 第二次握手：ack確保了接收方能收數(shù)據(jù)，syn確保了接收方能發(fā)數(shù)據(jù)
- 第三次握手：確保了發(fā)送方能收數(shù)據(jù)
- 四次握手浪費(fèi)养叛，兩次握手不能保證雙方同時具備收發(fā)功能
-
四次揮手流程：
- 客戶端發(fā)送FIN种呐，表示要單方面關(guān)閉數(shù)據(jù)的傳輸
- 服務(wù)端收到后，發(fā)送一個ACK作為確認(rèn)（序列號為收到的序列號+1）
- 等服務(wù)器數(shù)據(jù)傳輸完畢弃甥，服務(wù)端也發(fā)送一個FIN標(biāo)識爽室，表示關(guān)閉這個方向的數(shù)據(jù)傳輸
- 客戶端回復(fù)ACK以確認(rèn)回復(fù)
-
為什么是四次揮手
- tcp支持半關(guān)閉（發(fā)送一方結(jié)束發(fā)送還能接收數(shù)據(jù)的功能）
- 因此每個方向都要單獨(dú)關(guān)閉，且收到關(guān)閉通知需要發(fā)送確認(rèn)回復(fù)
-
time_wait狀態(tài)
- 也稱為2MSL等待狀態(tài)淆攻，報(bào)文段最大生存時間阔墩，根據(jù)不同的tcp實(shí)現(xiàn)自行設(shè)定嘿架。常用值為30s，1min啸箫，2min耸彪。linux一般為30s
- 主動關(guān)閉的一方發(fā)送最后一個ack所處的狀態(tài)，這個狀態(tài)必須維持的等待時間
- 該狀態(tài)是為了防止最后這個ack丟失了忘苛，接收方?jīng)]有收到蝉娜，讓發(fā)送方重新發(fā)送ack
- 但是在這2MSL等待時間內(nèi)，該連接將不能被使用扎唾，多并發(fā)的短連接情況下召川，會出現(xiàn)大量的Time_wait狀態(tài)，很多時候linux上報(bào)too many open files 胸遇，說端口不夠用了荧呐，就需要檢查一些代碼里面是不是創(chuàng)建大量的socket連接，而這些socket連接并不是關(guān)閉后就立馬釋放的狐榔，如果是服務(wù)端開發(fā)坛增，可設(shè)置keep-alive，讓客戶端主動關(guān)閉連接解決這個問題
-
滑動窗口協(xié)議
- 發(fā)送方和接收方速率不匹配時薄腻，保證可靠傳輸和包亂序的問題
- 接收方根據(jù)目前緩沖區(qū)大小，通知發(fā)送方目前能接收的最大值届案。發(fā)送方根據(jù)接收方的處理能力來發(fā)送數(shù)據(jù)庵楷。通過這種協(xié)調(diào)機(jī)制，防止接收端處理不過來
-
超時與重傳
- tcp通過在發(fā)送時設(shè)置定時器解決數(shù)據(jù)和確認(rèn)可能丟失的問題楣颠，定時器時間到了還沒收到確認(rèn)尽纽，就重傳該數(shù)據(jù)
-
主動的快速重傳機(jī)制
- 如果包沒有送達(dá)，就一直ack最后那個可能被丟的包童漩，發(fā)送方連續(xù)收到相同的ack弄贿，就重傳，不用等待超時
-
SACK
- 基于快速重傳矫膨，同時在tcp頭里加了一個SACK的東西,SACK記錄一個數(shù)值范圍差凹，表示哪些數(shù)據(jù)收到了,解決了客戶端應(yīng)該發(fā)送哪些超時包的問題
-
超時重傳引發(fā)的問題-擁塞
- 當(dāng)網(wǎng)絡(luò)延遲突然增加時，tcp會重傳數(shù)據(jù)侧馅，但是過多的重傳會導(dǎo)致網(wǎng)絡(luò)負(fù)擔(dān)加重危尿，從而導(dǎo)致更大的延時和丟包，進(jìn)入惡性循環(huán)
-
解決辦法：
- 慢啟動：降低分組進(jìn)入網(wǎng)絡(luò)的傳輸速率
- 擁塞避免：處理丟失分組的算法
- 快速重傳/恢復(fù)
