• 傳輸層的主要作用是實現(xiàn)應(yīng)用程序之間的的包傳遞惰匙。網(wǎng)絡(luò)層主要是保證不同數(shù)據(jù)鏈路的包傳遞悬槽，至于如何傳輸數(shù)據(jù)則是由傳輸層負(fù)責(zé)。

傳輸層協(xié)議簡介

• 常見的傳輸層協(xié)議主要有 TCP 協(xié)議和 UDP 協(xié)議

• TCP 協(xié)議是面向有連接的協(xié)議

  • 使用 TCP 協(xié)議傳輸數(shù)據(jù)之前一定要在發(fā)送方和接收方之間建立連接。一般情況下建立連接需要三步动壤，關(guān)閉連接需要四步

  • 建立 TCP 連接后，由于有數(shù)據(jù)重傳酥诽、流量控制等功能鞍泉，TCP 協(xié)議能夠正確處理丟包問題，保證接收方能夠收到數(shù)據(jù)肮帐，與此同時還能夠有效利用網(wǎng)絡(luò)帶寬咖驮。然而 TCP 協(xié)議中定義了很多復(fù)雜的規(guī)范，因此效率不如 UDP 協(xié)議训枢，不適合實時的視頻和音頻傳輸托修。

• UDP 協(xié)議是面向無連接的協(xié)議

  • 它只會把數(shù)據(jù)傳遞給接收端，不會關(guān)注接收端是否真的收到了數(shù)據(jù)恒界。
  • 這種特性反而適合多播睦刃，實時的視頻和音頻傳輸。因為個別數(shù)據(jù)包的丟失并不會影響視頻和音頻的整體效果十酣。

• IP 協(xié)議中的兩大關(guān)鍵要素是源 IP 地址和目標(biāo) IP 地址涩拙。而剛剛我們說過际长，傳輸層的主要作用是實現(xiàn)應(yīng)用程序之間的通信。因此傳輸層的協(xié)議中新增了三個要素：源端口號兴泥，目標(biāo)端口號和協(xié)議號工育。通過這五個信息，可以唯一識別一個通信搓彻。

• 端口用于區(qū)分同一臺主機上不同的應(yīng)用程序

  • 假設(shè)你打開了兩個瀏覽器如绸，瀏覽器 A 發(fā)出的請求不會被瀏覽器 B 接收，這就是因為 A 和 B 具有不同的端口旭贬。

• 協(xié)議號用于區(qū)分使用的是 TCP 還是 UDP

  • 因此相同兩臺主機上怔接，相同的兩個進程之間的通信，在分別使用 TCP 協(xié)議和 UDP 協(xié)議時也可以被正確的區(qū)分開來骑篙。

TCP的三次握手

第一次握手：

• 客戶端發(fā)送 SYN包 到服務(wù)器蜕提，進入數(shù)據(jù)發(fā)送(SYN_SEND)狀態(tài)，等待服務(wù)器確認(rèn)

第二次握手：

• 服務(wù)器發(fā)送 SYN+ACK(確認(rèn))包靶端，此時服務(wù)器進入 數(shù)據(jù)接收(SYN_RECV)狀態(tài)

第三次握手：

• 客戶端發(fā)送ACK(確認(rèn))包谎势，客戶端和服務(wù)器進入建成狀態(tài)

established: 已經(jīng)建立的

• 握手過程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后杨名，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)
• 理想狀態(tài)下脏榆，TCP連接一旦建立，在通信雙方中的任何一方主動關(guān)閉連接之前台谍，TCP 連接都將被一直保持下去

為什么是三次握手

• 網(wǎng)絡(luò)不可靠须喂，數(shù)據(jù)包可能丟失。

• 假設(shè)沒有第三次確認(rèn)趁蕊，客戶端發(fā)送了 SYN坞生，請求建立連接。由于延遲掷伙，服務(wù)端沒有及時收到這個包是己。于是客戶端重新發(fā)送一個 SYN 包。服務(wù)端接收到了第二個 SYN 包任柜，建立了通信卒废，一段時間后通信結(jié)束，連接關(guān)閉宙地。這時候第一次發(fā)送的 SYN 包抵達服務(wù)端摔认，此時的服務(wù)端就會建立一個新的連接。然而客戶端并沒有請求建立連接宅粥，所以也不會向服務(wù)端發(fā)送數(shù)據(jù)参袱。造成資源浪費

• 在三次握手的情況下，客戶端會接受到一個相同的 ACK 包，這時候它會拋棄這個數(shù)據(jù)包蓖柔，不會和服務(wù)端進行第三次握手辰企，因此避免了服務(wù)端建立空的連接

• 三次握手其實解決了第二步的數(shù)據(jù)包丟失問題

ACK 確認(rèn)包丟失怎么辦

• 方案一：服務(wù)端會重新向客戶端發(fā)送數(shù)據(jù)包，直至收到 ACK 包

  • 但這種做法有可能遭到 SYN 泛洪攻擊
  • 所謂的泛洪攻擊况鸣，是指發(fā)送方偽造多個 IP 地址牢贸，模擬三次握手的過程。當(dāng)服務(wù)器返回 ACK 后镐捧，攻擊方故意不確認(rèn)潜索，從而使得服務(wù)器不斷重發(fā) ACK。由于服務(wù)器長時間處于半連接狀態(tài)懂酱，最后消耗過多的 CPU 和內(nèi)存資源導(dǎo)致死機

• 方案二：服務(wù)端發(fā)送 RST 報文竹习，進入 CLOSE 狀態(tài)；客戶端如果還想重新建立 TCP 連接列牺，就必須重新開始第一次握手

  • 這個 RST 數(shù)據(jù)包的 TCP 首部中整陌，控制位中的 RST 位被設(shè)置為 1。這表示連接信息全部被初始化瞎领，原有的 TCP 通信不能繼續(xù)進行

TCP關(guān)閉的四次握手

服務(wù)器和客戶端均可以主動發(fā)起斷開TCP連接的請求泌辫，斷開過程需要經(jīng)過“四次握手”

1.（客戶端）：我要關(guān)閉了
2.（服務(wù)端）：可以
3.（服務(wù)端）：我這邊也要關(guān)閉了
4.（客戶端）：可以

關(guān)閉連接的最后一個 ACK 丟失怎么辦

• 第三步之后客戶端收到 FIN 包時，會設(shè)置一個計時器九默。如果ACK 丟失震放，那么服務(wù)端還會重發(fā) FIN ，客戶端重置計時器
• 假設(shè)在計時器失效前服務(wù)器重發(fā)的 FIN 包沒有到達客戶端驼修，客戶端就會進入 CLOSE 狀態(tài)殿遂，從而導(dǎo)致服務(wù)端永遠無法收到 ACK 確認(rèn)，也就無法關(guān)閉連接

TCP和UDP的區(qū)別

1.TCP面向鏈接乙各，UDP非面向連接
TCP的三次握手最大程度保證了墨礁，數(shù)據(jù)傳輸?shù)目煽啃?/code>