UDP具備差錯校驗(yàn)機(jī)制，不過筆者我不熟就不班門弄斧了。這里還有個復(fù)用、分用的概念，TCP也是如此。簡單的說，復(fù)用就是指多個傳輸端口可以共用一個傳輸協(xié)議，分用則是指當(dāng)接收到數(shù)據(jù)時，通過一個傳輸協(xié)議可以回傳給多個傳輸端口。

TCP

TCP協(xié)議是一種挺復(fù)雜的傳輸協(xié)議，它是一種傳輸層的傳輸控制協(xié)議，它的特點(diǎn)是需要連接、可靠交付、面向字節(jié)流、流量控制、擁塞控制。

首先，需要連接是指客戶端在發(fā)起HTTP請求是，需要先跟服務(wù)端建立連接，建立連接的過程我們稱之為三次握手。

1. 客戶端向服務(wù)端發(fā)送同步報文SYN
2. 服務(wù)端收到報文后向客戶端發(fā)送同步確認(rèn)報文SYN,ACK
3. 客戶端再向服務(wù)端發(fā)送確認(rèn)報文ACK

三次握手示意圖

建立連接后，客戶端斷就可以多次向服務(wù)請求數(shù)據(jù)，最后再斷開連接，多次請求數(shù)據(jù)主要依賴HTTP的長連接屬性。斷開連接的過程我們稱之為四次揮手

1. 客戶端不需要在發(fā)送數(shù)據(jù)時會向服務(wù)端發(fā)送結(jié)束報文FIN。
2. 服務(wù)端收到后回復(fù)確認(rèn)結(jié)束報文ACK，意思就是‘我知道你不再發(fā)數(shù)據(jù)了’。
3. 服務(wù)端不需要在發(fā)送數(shù)據(jù)時會向客戶端發(fā)送結(jié)束報文FIN,ACK。
4. 客戶端收到后回復(fù)確認(rèn)結(jié)束報文ACK。
當(dāng)雙發(fā)都確認(rèn)結(jié)束后，這條傳輸通道就關(guān)閉了。

這里面有個小概念是全雙工通道，意思是通道的雙發(fā)都可以主動向?qū)Ψ桨l(fā)消息。而不是兩條通道。

四次揮手示意圖

可靠交付和面向字節(jié)流我們可以合起來理解，面向字節(jié)流的特性決定了TCP會通過自身的一套方式對應(yīng)用層提交的數(shù)據(jù)進(jìn)行拆分或合并，也就是說應(yīng)用層一次性給10個字節(jié)，TCP并不一定一次性將這10個字節(jié)對外傳輸。數(shù)據(jù)被拆分或合并后，為了保證數(shù)據(jù)的準(zhǔn)確性其傳輸必須是有序的，前一部分?jǐn)?shù)據(jù)確認(rèn)抵達(dá)后才會繼續(xù)傳輸下一部分?jǐn)?shù)據(jù)。如果其中因?yàn)榫W(wǎng)絡(luò)問題觸發(fā)了超時重傳，那么重復(fù)的數(shù)據(jù)將被摒棄，因此TCP傳輸是不重復(fù)的。有序、準(zhǔn)確、不重復(fù)決定了TCP是可靠交付。

流量控制涉及到一個叫滑動窗口的概念。數(shù)據(jù)發(fā)送時會進(jìn)入發(fā)送緩沖區(qū)待命，每一次發(fā)送的數(shù)據(jù)量就是一個發(fā)送窗口。由于雙發(fā)所處的網(wǎng)絡(luò)環(huán)境、設(shè)備環(huán)境可能不一致，當(dāng)一方發(fā)送數(shù)據(jù)過多時就會導(dǎo)致接收方緩沖區(qū)溢出，因此發(fā)送方的每一次發(fā)送窗口大小是由接收方動態(tài)決定的，這個機(jī)制就是所謂的流量控制。發(fā)送窗口是有編號的，并且是按序增大，假設(shè)接收方先接收到序號為3的數(shù)據(jù)，并未接收到1、2號數(shù)據(jù)，就會將序號為3的數(shù)據(jù)先放在數(shù)據(jù)緩存區(qū)，等待1、2號數(shù)據(jù)到達(dá)后才提交給應(yīng)用層，所以我們說TCP傳輸是有序的。

流量控制-滑動窗口示意圖

擁塞控制主要方式是慢開始、擁塞避免。接收方會給發(fā)送方一個門限初始值，在達(dá)到門限值之前發(fā)送方每次發(fā)送的數(shù)據(jù)量呈指數(shù)增長，即1、2、4、8、16這樣的方式，當(dāng)達(dá)到門限值16后改為加法增長，17、18、19...當(dāng)?shù)竭_(dá)某個數(shù)值時，比如20，發(fā)現(xiàn)接收方的確認(rèn)速度變慢了（可能因此網(wǎng)絡(luò)擁塞等因素），就會將每次發(fā)送數(shù)據(jù)量重新從1、2、4...開始恢復(fù)。有一種變種控制方式快恢復(fù)、快重傳是指遇到擁塞后，數(shù)據(jù)量不會重新從1開始，而是從擁塞值的一半開始（比如20的一半，10）。

擁塞控制示意圖

DNS解析

DNS解析實(shí)際上是將域名映射為IP地址的一個過程，采用的是UDP+明文的方式進(jìn)行傳輸。DNS主要通過遞歸查詢和迭代查詢兩種方式解析域名。

遞歸查詢是一種層層向上的查詢方式，由本地DNS > 根域DNS > 頂級DNS > 權(quán)限D(zhuǎn)NS向上查詢，直到一方返回結(jié)果。

迭代查詢則是本地DNS直接向各級DNS進(jìn)行查詢方式，各級DNS會告知本地DNS“A可能知道結(jié)果”，本地DNS直接去找“A”獲取IP地址。

DNS解析轉(zhuǎn)發(fā)是指DNS服務(wù)器為了減小壓力，將DNS解析請求轉(zhuǎn)發(fā)給了其他網(wǎng)絡(luò)營運(yùn)商（比如移動轉(zhuǎn)發(fā)給電信），由該營運(yùn)商提供解析結(jié)果。由于這種轉(zhuǎn)發(fā)的方式，客戶端可能會獲得跟自身所處網(wǎng)絡(luò)環(huán)境不一樣的網(wǎng)絡(luò)營運(yùn)商的地址，就可能會出現(xiàn)請求響應(yīng)慢的問題。

DNS劫持是指偽裝的DNS服務(wù)器通過53端口截獲了DNS解析請求，并返回給客戶端虛假的IP地址。我們可以通過httpDNS的請求方式，即使用HTTP協(xié)議直接向DNS服務(wù)器的80端口發(fā)起GET請求，并將目標(biāo)域名和自身的IP地址拼接在URL參數(shù)上。

HTTP2.0

HTTP1.x版本在通過一個TCP鏈接中多次發(fā)起請求，后發(fā)起的請求會被先發(fā)起的請求阻塞，也就是請求是串行的，必須等到前一個請求返回結(jié)果后才能接著處理下一個請求。針對這種現(xiàn)象，在請求數(shù)較多的情況下HTTP會建立多個TCP連接來獲取數(shù)據(jù)，但是建立TCP鏈接需要經(jīng)歷握手與揮手流程，對時間和性能上也存在著一定的損耗。
2.0版本通過多路復(fù)用的方式解決了這個問題，同一個TCP連接通過輪詢的方式來發(fā)送請求，即前一個請求在等待數(shù)據(jù)的過程中，會接著判斷隊列中是否有其他請求，如果有則直接發(fā)送下一個請求。
2.0版本具備頭部壓縮特性，會對HTTP請求頭進(jìn)行數(shù)據(jù)壓縮，以達(dá)到更快的請求速度。
2.0版本采取了二進(jìn)制格式傳遞數(shù)據(jù)，而非文本傳輸。
2.0版本使得服務(wù)端在建立連接后，能夠主動推送數(shù)據(jù)給客戶端。

HTTPS

HTTP的數(shù)據(jù)傳輸采用的是明文方式，安全性無法得到保障，因此產(chǎn)生了SSL協(xié)議用于HTTP數(shù)據(jù)加密，我們也就稱之為HTTPS。SSL是早期的協(xié)議，現(xiàn)在一般采用是TLS。
TLS/SSL同樣也位于應(yīng)用層，嚴(yán)格上來說是位于HTTP應(yīng)用層之下，TCP傳輸層之上的一個中間層。
當(dāng)一個HTTPS請求發(fā)送給服務(wù)器時，會經(jīng)歷以下幾個握手流程：

1. 客戶端將支持的加密算法、隨機(jī)數(shù)A、TLS版本傳輸給服務(wù)端；
2. 服務(wù)端選擇一套算法、隨機(jī)數(shù)B、證書傳輸給客戶端；
3. 客戶端進(jìn)行證書校驗(yàn)、產(chǎn)生一個預(yù)主秘鑰C，通過證書中的公鑰對秘鑰進(jìn)行加密；
4. 客戶端將加密后的預(yù)主秘鑰C發(fā)送給服務(wù)端，服務(wù)端通過私鑰進(jìn)行解密得到秘鑰C；
5. 雙發(fā)通過隨機(jī)數(shù)A、隨機(jī)數(shù)B、預(yù)主秘鑰C組裝成會話秘鑰后，使用會話秘鑰發(fā)送一次加密的握手消息，來驗(yàn)證會話秘鑰是否有效。
6. 驗(yàn)證成功后開始數(shù)據(jù)交互。

TLS握手流程示意圖

`文中圖片均來自慕課網(wǎng)--于海老師的教案`