TCP知識概要

談下你對五層網絡協議體系結構的理解?

應用,主機,網絡,數據,數據單位數據庫

  1. 應用層 - 應用間通訊協議,不一樣應用使用不一樣協議 HTTP,SMTP
  2. 運輸層 - 主機間通訊服務,運輸層複用、分用
  3. 網絡層 - 選擇合適 網間路由、交換結點,經過 多鏈路、多通訊子網
  4. 數據鏈路層 - 切割報文,讓他在鏈路上 一段段 傳輸
  5. 物理層 - 數據單位是比特,讓比特流運輸無視設備差別

應用層

應用層指的是完成應用進程間的通訊的網絡協議。應用層協議定義的是應用進程間的通訊和交互規則緩存

對於不一樣的網絡應用須要不一樣的應用層協議。如域名系統 DNS,互聯網的 HTTP 協議,郵件的 SMTP 協議等等。服務器

域名系統

域名系統(Domain Name System縮寫DNS,Domain是因特網的一項核心服務,它做爲能夠將域名和IP地址相互映射的分佈式數據庫,可以令人不用去記住可以被機器直接讀取的IP數串。網絡

HTTP協議

超文本傳輸協議(HTTP,HyperText Transfer Protocol)是互聯網上應用最普遍的網絡協議。全部的 WWW(萬維網) 文件都必須遵照這個標準。設計 HTTP 最初的目的是爲了提供一種發佈和接收 HTML 頁面的方法。(百度百科)多線程

運輸層

運輸層是完成兩臺主機進程之間的通訊提供通用的數據傳輸服務通用的是指多種應用可使用同一個運輸層服務。分佈式

因爲主機可同時運行多線程,所以運輸層有複用分用的功能。線程

  • 複用就是指多個應用層進程可同時使用下面運輸層服務
  • 分用是運輸層把收到的信息分別交付上面應用層中的相應進程。

運輸層主要使用如下兩種協議

  1. 傳輸控制協議 TCP(Transmisson Control Protocol)--提供面向鏈接的,可靠的數據傳輸服務。
  2. 用戶數據協議 UDP(User Datagram Protocol)--提供無鏈接的,盡最大努力的數據傳輸服務(不保證數據傳輸的可靠性)。

UDP 的主要特色

  • UDP 是無鏈接的;
  • UDP 使用盡最大努力交付,即不保證可靠交付,所以主機不須要維持複雜的連接狀態(這裏面有許多參數);
  • UDP 是面向報文的;
  • UDP 沒有擁塞控制,所以網絡出現擁塞不會使源主機的發送速率下降(對實時應用頗有用,如 直播,實時視頻會議等);
  • UDP 支持一對1、一對多、多對一和多對多的交互通訊;
  • UDP 的首部開銷小,只有8個字節,比TCP的20個字節的首部要短。

TCP 的主要特色

  • TCP 是面向鏈接的。(就好像打電話同樣,通話前須要先撥號創建鏈接,通話結束後要掛機釋放鏈接);
  • 每一條 TCP 鏈接只能有兩個端點,每一條TCP鏈接只能是點對點的(一對一);
  • TCP 提供可靠交付的服務。經過TCP鏈接傳送的數據,無差錯、不丟失、不重複、而且按序到達;
  • TCP 提供全雙工通訊。TCP 容許通訊雙方的應用進程在任什麼時候候都能發送數據。TCP 鏈接的兩端都設有發送緩存和接收緩存,用來臨時存放雙方通訊的數據;
  • 面向字節流。TCP 中的「流」(Stream)指的是流入進程或從進程流出的字節序列。「面向字節流」的含義是:雖然應用程序和 TCP 的交互是一次一個數據塊(大小不等),但 TCP 把應用程序交下來的數據僅僅當作是一連串的無結構的字節流。

TCP\UDP的區別

TCP提供可靠的通訊傳輸 | UDP則常被用於讓廣播和細節控制交給應用的通訊傳輸。
設計

圖片描述

網絡層

主機間通訊會通過多鏈路多通訊子網。網絡層是選擇合適的網間路由交換結點, 確保數據及時傳送。code

在發送數據時,網絡層把運輸層產生的報文段或用戶數據報封裝成分組和包進行傳送。在 TCP / IP 體系結構中,因爲網絡層使用 IP 協議,所以分組也叫 IP 數據報,簡稱數據報。cdn

數據鏈路層

數據鏈路層簡稱爲鏈路層。主機通訊老是在一段一段的鏈路上傳送的,這就須要使用專門的鏈路層的協議。

傳送數據時,數據鏈路層將數據報文組裝成幀傳輸,每一幀包括數據和必要的控制信息(如:同步信息,地址信息,差錯控制等)。

在接收數據時,控制信息使接收端可以知道一個幀從哪一個比特開始和到哪一個比特結束。
數據鏈路層在收到一個幀後,就可從中提出數據部分,上交給網絡層。

控制信息還使接收端可以檢測到所收到的幀中有無差錯。若是發現差錯,數據鏈路層就簡單地丟棄這個出了差錯的幀,避免浪費網絡資源。

若是須要改正數據在鏈路層傳輸時出現差錯(這就是說,數據鏈路層不只要檢錯,並且還要糾錯),那麼就要採用可靠性傳輸協議來糾正出現的差錯。這種方法會使鏈路層的協議複雜些。

物理層

在物理層上所傳送的數據單位是比特。
物理層是實現相鄰節點之間比特流的透明傳送,儘量屏蔽物理設備的差別。「透明傳送比特流」表示經實際電路傳送後的比特流沒有發生變化

TCP 三次握手和四次揮手

圖片描述

TCP 三次握手 - 創建一個鏈接:

  • 客戶端–發送帶有 SYN 標誌的數據包給服務端 - 一次握手
  • 服務端–發送帶有 SYN/ACK 標誌的數據包給客戶端 – 二次握手
  • 客戶端–發送帶有帶有 ACK 標誌的數據包給服務端 – 三次握手

什麼是半鏈接隊列?

服務器第一次收到客戶端的 SYN 以後,就會處於 SYN_RCVD 狀態,此時雙方尚未徹底創建其鏈接,服務器會把此種狀態下請求鏈接放在一個隊列裏,咱們把這種隊列稱之爲半鏈接隊列。
固然還有一個全鏈接隊列,就是已經完成三次握手,創建起鏈接的就會放在全鏈接隊列中。若是隊列滿了就有可能會出現丟包現象。

這裏在補充一點關於SYN-ACK 重傳次數的問題: 服務器發送完SYN-ACK包,如未收到客戶確認包,服務器進行首次重傳,等待一段時間仍未收到客戶確認包,進行第二次重傳。若是重傳次數超過系統規定的最大重傳次數,系統將該鏈接信息從半鏈接隊列中刪除。 注意,每次重傳等待的時間不必定相同,通常會是指數增加,例如間隔時間爲 1s,2s,4s,8s......

SYN攻擊 - 典型的DDOS攻擊之一


攻擊原理:在三次握手中,Server發送SYN-ACK後,收到Client的ACK以前的TCP鏈接稱爲半鏈接(half-open connect),此時Server處於SYN_RCVD狀態,當收到ACK後,Server轉入ESTABLISHED狀態。


SYN攻擊就是Client在短期內僞造大量不存在的IP地址,並向Server不斷地發送SYN包,Server回覆確認包,並等待Client的確認,因爲源地址是不存在的,所以,Server須要不斷重發直至超時,這些僞造的SYN包將產時間佔用未鏈接隊列,致使正常的SYN請求由於隊列滿而被丟棄,從而引發網絡堵塞甚至系統癱瘓。


檢測SYN攻擊的方式很是簡單,即當Server上有大量半鏈接狀態且源IP地址是隨機的,則能夠判定遭到SYN攻擊了,使用以下命令可讓之現行:netstat -nap | grep SYN_RECV

ISN(Initial Sequence Number)是固定的嗎?

ISN隨時間而變化,所以每一個鏈接都將具備不一樣的ISN。ISN能夠看做是一個32比特的計數器,每4ms加1 。這樣選擇序號的目的在於防止在網絡中被延遲的分組在之後又被傳送,而致使某個鏈接的一方對它作錯誤的解釋。 三次握手的其中一個重要功能是客戶端和服務端交換 ISN(Initial Sequence Number),以便讓對方知道接下來接收數據的時候如何按序列號組裝數據。若是 ISN 是固定的,攻擊者很容易猜出後續的確認號,所以 ISN 是動態生成的。

三次握手過程當中能夠攜帶數據嗎?

第一次、第二次握手不能夠攜帶數據.第三次握手的時候,是能夠攜帶數據的。 由於第一次握手能夠攜帶數據的話,若是有人要惡意攻擊服務器,那他重複在第一次握手中的 SYN 報文中放入大量的數據,這會讓服務器花費不少時間、內存空間來接收這些報文。

簡單的緣由就是會讓服務器更加容易受到攻擊了。而對於第三次的話,此時客戶端已經處於 ESTABLISHED 狀態。對於客戶端來講已經創建起鏈接了,而且也已經知道服務器的接收、發送能力是正常,能攜帶數據也沒啥毛病

爲何要三次握手

三次握手的目的是創建可靠的通訊信道,說到通信,簡單來講就是數據的發送與接收,而三次握手最主要的目的就是雙方確認本身與對方的發送與接收是正常的。

  • 第一次握手:Client 什麼都不能確認;Server 確認了對方發送正常
  • 第二次握手:Client 確認了:本身發送、接收正常,對方發送、接收正常;Server 確認了:本身接收正常,對方發送正常
  • 第三次握手:Client 確認了:本身發送、接收正常,對方發送、接收正常;Server 確認了:本身發送、接收正常,對方發送接收正常

因此三次握手就能確認雙發收發功能都正常,缺一不可。

爲何要傳回 SYN

接收端傳回發送端所發送的 SYN 是爲了告訴發送端,我接收到的信息確實就是你所發送的信號了。

傳了 SYN,爲啥還要傳 ACK

雙方通訊無誤必須是二者互相發送信息都無誤。傳了 SYN,證實發送方到接收方的通道沒有問題,可是接收方到發送方的通道還須要 ACK 信號來進行驗證。

爲何不須要四次握手 -

徹底可靠的通訊協議是不存在的。在通過三次握手以後,客戶端和服務端已經能夠確認以前的通訊情況,都收到了確認信息。因此即使再增長握手次數也不能保證後面的通訊徹底可靠,因此是沒有必要的。

TCP 四次揮手 - 斷開一個鏈接:

  • 客戶端-發送一個 FIN,用來關閉客戶端到服務器的數據傳送
  • 服務器-收到這個 FIN,它發回一 個 ACK,確認序號爲收到的序號加1 。和 SYN 同樣,一個 FIN 將佔用一個序號
  • 服務器-關閉與客戶端的鏈接,發送一個FIN給客戶端
  • 客戶端-發回 ACK 報文確認,並將確認序號設置爲收到序號加1

爲何要四次揮手

ACK報文是用來應答的,SYN報文是用來同步的。 當服務端收到FIN報文時,並不會當即關閉SOCKET,只能先回復一個ACK報文,告訴客戶端,"你發的FIN報文我收到了"。只有等到我服務端全部的報文都發送完了,我才能發送FIN報文,所以不能一塊兒發送。故須要四次揮手。

2MSL等待狀態
TIME_WAIT狀態也成爲2MSL等待狀態。每一個具體TCP實現必須選擇一個報文段最大生存時間MSL(Maximum Segment Lifetime),它是任何報文段被丟棄前在網絡內的最長時間。這個時間是有限的,由於TCP報文段以IP數據報在網絡內傳輸,而IP數據報則有限制其生存時間的TTL字段。

四次揮手釋放鏈接時,等待2MSL的意義?

爲了保證客戶端發送的最後一個ACK報文段可以到達服務器。由於這個ACK有可能丟失,從而致使處在LAST-ACK狀態的服務器收不到對FIN-ACK的確認報文。服務器會超時重傳這個FIN-ACK,接着客戶端再重傳一次確認,從新啓動時間等待計時器。最後客戶端和服務器都能正常的關閉。

假設客戶端不等待2MSL,而是在發送完ACK以後直接釋放關閉,一但這個ACK丟失的話,服務器就沒法正常的進入關閉鏈接狀態。

爲何TIME_WAIT狀態須要通過2MSL才能返回到CLOSE狀態?

理論上,四個報文都發送完畢,就能夠直接進入CLOSE狀態了,可是可能網絡是不可靠的,有可能最後一個ACK丟失。因此TIME_WAIT狀態就是用來重發可能丟失的ACK報文。

相關文章
相關標籤/搜索