date: 2019-07-20 20:37:37
TCP/IP協(xié)議族
應(yīng)用層(HTTP/FTP)
傳輸層(TCP/UDP)
網(wǎng)絡(luò)層(IP)
網(wǎng)絡(luò)接口層(把0芬为、1序列劃分為數(shù)據(jù)幀從一個節(jié)點(diǎn)傳輸?shù)脚R近的另一個節(jié)點(diǎn))
HTTP
無狀態(tài)、無連接 (自HTTP1.1起，可以keep aliva)
-
請求格式
請求行：請求方法 URL 協(xié)議版本
請求頭：多個kv對
請求體：請求數(shù)據(jù)
-
響應(yīng)格式
狀態(tài)行：協(xié)議版本 狀態(tài)碼 狀態(tài)碼描述
響應(yīng)頭：多個kv對
響應(yīng)體：響應(yīng)數(shù)據(jù)
-
常見通用頭
Content-Type
Accept
Content-Length
Content-Encoding
Accept-Encoding
ETag
Cache-Control
-
常見請求頭
Authorization
User-Agent
If-Modified-Since
If-Node-Match
Cookie
Referer
Host
-
常見響應(yīng)頭
Date
Last-Modified
Transfer-Encoding
Set-Cookie
Location
Server
HTTPS
對稱加密存在被黑客截獲消息后偽裝的問題
非對稱加密存在公鑰權(quán)威性問題
于是衍生出了CA機(jī)構(gòu)拴曲，用于暴保障權(quán)威性
TCP
基本性質(zhì)
面向連接、可靠的字節(jié)流服務(wù)梭灿，使用校驗和重傳的方式來保證可靠傳輸
給數(shù)據(jù)分節(jié)進(jìn)行排序阴汇，并使用累計確認(rèn)來保證數(shù)據(jù)的順序不變和非重復(fù)
使用滑動窗口機(jī)制來實(shí)現(xiàn)流量控制
三次握手：建立連接
第一次：客戶端說：我要和你(服務(wù)端)建立連接
第二次：服務(wù)端說：好的，可以尼桶，你確認(rèn)要和我建立連接嗎
第三次：客戶端說：確認(rèn) => 建立連接
三次握手是為了防止已失效的連接請求報文段突然又傳送到了服務(wù)端操灿，因而產(chǎn)生錯誤
如果只需要請求+返回就建立連接，那么在這種情況下如果一個歷史的連接建立請求被阻塞在網(wǎng)絡(luò)中泵督，一段時間后到達(dá)服務(wù)端的話趾盐，服務(wù)端會直接返回確認(rèn)并建立連接，但是客戶端已經(jīng)不需要了小腊，服務(wù)端會一直等待這個連接傳入數(shù)據(jù)救鲤，造成資源浪費(fèi)。
四次揮手：斷開連接
第一次：主機(jī)1：我沒什么要對你說的了秩冈，我想關(guān)閉連接可以嗎
第二次：主機(jī)2：可以
第三次：主機(jī)2：我也沒什么要對你說的了本缠，我想關(guān)閉連接可以嗎
第四次：主機(jī)1：可以 => 主機(jī)2收到后就關(guān)閉連接；主機(jī)1發(fā)送完成后等待2MSL后關(guān)閉連接
TCP是全雙工模式漩仙，四次揮手是需要雙方都確認(rèn)沒有數(shù)據(jù)要發(fā)送后才可以關(guān)閉
主機(jī)1為啥要等2MSL搓茬？
-
保證TCP協(xié)議的全雙工連接能夠可靠關(guān)閉
如果由于網(wǎng)絡(luò)延遲等原因，主機(jī)2遲遲沒有收到主機(jī)1的最后確認(rèn)信息队他，會一直重復(fù)發(fā)送FIN信號卷仑。
-
保證這次連接的重復(fù)數(shù)據(jù)段從網(wǎng)絡(luò)中消失
一種極端情況，兩個端口關(guān)閉后馬上又在相同的端口建立的新的連接麸折，如果原來的數(shù)據(jù)傳輸有延遲锡凝，那么會被混淆到新的連接里。
滑動窗口限流
如果發(fā)送方把數(shù)據(jù)發(fā)送得過快垢啼，接收方可能會來不及接收窜锯，這就會造成數(shù)據(jù)的丟失。所謂流量控制就是讓發(fā)送方的發(fā)送速率不要太快芭析，要讓接收方來得及接收锚扎。即接收方通知發(fā)送方，我目前能接收多少數(shù)據(jù)
擁塞控制 (逐步試探的過程)
-
慢開始算法
- 最開始時發(fā)送最小單位馁启，如果網(wǎng)絡(luò)狀況允許驾孔，就逐漸翻倍擴(kuò)大每次發(fā)送的數(shù)據(jù)量芍秆。
-
擁塞避免
當(dāng)慢開始算法一直翻倍到某個閾值，接下來就是每次把發(fā)送的數(shù)據(jù)量加一個單位翠勉，避免一直翻倍造成網(wǎng)絡(luò)擁塞妖啥。
當(dāng)遇到網(wǎng)絡(luò)擁塞時，馬上把慢開始閾值調(diào)成原來的一半对碌，并且把每次發(fā)送的數(shù)據(jù)量降到1荆虱，重新開始執(zhí)行慢開始算法
-
快重傳
- 當(dāng)接收方還沒收到3就已經(jīng)收到456時，對于456的響應(yīng)都是2朽们，這樣發(fā)送方就知道缺失了3怀读，馬上發(fā)送缺失的3
-
快恢復(fù)
- 當(dāng)有數(shù)據(jù)丟失發(fā)送后，就想應(yīng)對網(wǎng)絡(luò)擁塞一樣把慢開始閾值調(diào)低一半华坦，但是并不把每次發(fā)送的數(shù)據(jù)量降到1后逐步翻倍愿吹，而是降到新閾值的一半后重新開始逐步加1。
UDP
不可靠惜姐，數(shù)據(jù)報有長度犁跪，無連接，支持多播和廣播
IP
不可靠
