java學習之TCP 協議,很詳細,值得收藏下

TCP協議目前是事實上的網絡基礎。許多更高層的應用協議HTTP,FTP都基於TCP。

TCP協議的學習可以說枯燥無比,尤其是學生階段,根本不知道用在什麼地方,根本不知道重要性是什麼。事實上是,基於目前的網絡發展和分佈式發展,TCP簡直就是基礎中的基礎。許多網絡的問題,配置,入侵,防禦乃至架構,都涉及到TCP的具體應用及機制。

以下是我總結的TCP學習過程,

1. 瞭解學習TCP協議的重要性和必要性,瞭解TCP協議為什麼被髮展出來

推薦這個問題下的各個回答:TCP/IP 協議到底在講什麼?

https://www.zhihu.com/question/51074319

2. 學習TCP協議的三次握手以及四次揮手,重點了解為什麼要三次握手,為什麼要四次揮手,在整個過程中狀態是如何變遷的。(經典的狀態圖以及握手揮手圖)

a.為什麼要三次握手?不是一次,兩次或者四次。我們來論證一下,如果只有一次會發生什麼情況,a向b發起連接請求,假設b沒收到,則b其實完全不知道a發起了請求,而a也完全不知道b收沒收到,所以一次握手是不可靠的;如果兩次握手呢,a向b發起連接請求,b收到a的請求給a回覆一個請求,假設此時a收到了b的回覆,a知道了b已經ready了,可b完全不知道a是否ready,有可能a並沒有收到b的請求,也有可能收到了,但這些b都完全不知道,所以只是單向的建立了連接;如果是四次握手呢,其實第2次讓a知道b ready了,第三次讓b知道a也ready了,第四次完全就是多餘了,會浪費網絡資源。

b.為什麼要四次揮手?不是3次?實際上兩邊連接完全可以分開看,用2次揮手斷開其中一邊連接,用另外2次揮手斷開另一邊的連接,最終完成整個連接關閉。之所以這樣設計,是因為有可能某一邊數據還未傳輸完,連接還未關閉。因為TCP被設計為全雙工協議,可以任何一邊單向發送數據。

1. 握手及揮手過程

java學習之TCP 協議,很詳細,值得收藏下

2. TCP的狀態轉換圖

3. 學習TCP協議是如何保持可靠性設計的。

主要目的是用來參考,以便在其他通信場合時用作架構和設計的參考

1).包應答序列號及包重組。

面臨的問題:網絡傳輸中,會出現數據的破壞,丟包,重複,分片混亂等問題。

本質上,要想保證傳輸的可靠性,則需要對傳輸的內容進行驗證。

a. 對於網絡數據的破壞(比如宇宙射線影響偷笑導致發射火箭的數據中某一位從0變為1),採取的策略是丟棄重新發送,以確保不會出現致命的錯誤。TCP在自身協議中單獨劃了一塊checksum用於這種校驗,校驗算法本質上是將整塊數據通過某個函數映射到16位的校驗位上(比如用字符相加的和來校驗)

b. 對於數據傳輸正確,但是分片亂序,重複等問題,或是丟包,採取的策略並非丟棄而是自行進行包重組。

考慮兩種情況:第一種情況是某個包缺少了,導致整個數據中間缺了一段1000字節,那麼如何通知到對方自己少了哪一段數據;另一種情況是由於網絡或者重發機制的原因導致某一個包收到多次,如何把多餘的包都排除掉,僅保留已有數據。

TCP在設計時候充分考慮這點,其中SYN和ACK就是用來確保這個過程的,SYN發送的是字節順序,ACK則應答收到的字節序加1。這樣,無論是發送方還是接收方,都可以準確的維護一張發送接收字節的列表。從而可以知道對方還需要哪些字節,或自己已經接收了哪些字節。

2).重發機制

a. 超時重發

為了保證數據一定被接收到,就必須妥善處理超時,對於超時沒得到響應,則最好的辦法是重新發送。

首先將數據拷貝到發送緩衝區,每個包在發送時都會啟動一個定時器,如果定時器超時前收到了對方應答,則發送成功,清除緩衝區,否則重傳數據包,直到達到最大次數。

TCP在每次發包時都會計算往返時間極其偏差,通過這個記錄可以大致判斷雙方的網絡情況從而確定超時時間。通常剛開始超時時間較長(如6s),而後可能到0.5s這樣較小的時間。

b. 高速重發

比起超時才重新發送,TCP還設計了更為巧妙的方式來做重發。稱為快速重發。即目標主機在確認時總是確認排在最先的缺失包,當發送方發現連續收到3個同樣的ack時,則表明該包已經丟了,需要快速重新發送,這樣能否避免要等到超時才能重發。

更多可以參考這裡

https://wizardforcel.gitbooks.io/network-basic/content/8.html

3).流量控制(滑動窗口)

a. 滑動窗口協議

滑動窗口本質上是為了在通信過程中同步收發雙方的速率。通過發送端的發送窗口和接收端的接收窗口來保證發送的可靠性,同時協調發送的速度。

對於發送端來說,整個窗口分為下面四段,一是已經發送也收到確認回覆的;二是已經發送但尚未收到回覆的;三是還沒有發送但即將發送的(接收方有空間,只是發送方尚未發送而已);四是沒發送,但是接收方已經沒空間的

同理,對於接收方來說,整個窗口分為三段,一是已經接收並且已經回覆ACK的;二是已經接收的;三是為接收也沒準備接收的

而所謂的滑動,則是將窗口從上一次收到的連續ACK的位置整個劃到下一次收到連續ACK的位置而已。注意連續二字,不連續則不能算作已經接收完畢。

java學習之TCP 協議,很詳細,值得收藏下

b. 滑動窗口的收縮與擴張

滑動窗口最牛逼的地方在於動態的調整收發雙方的窗口大小,以便使得收發雙方通信同步而不僅僅是對於發送接收字節的管理。

在TCP協議中,有16個字節專門用來放window大小,是接收端主機向發送方主機通知自己可以接納的數據大小,而發送方會根據該窗口數據發送不超過這個限度的數據。接收方可以根據自己的處理能力不斷的增大或者縮小這個值,而發送方主機則只要保持與之同步即可。

當收縮到最小(即0窗口)時,按照約定發送方不能再給接收方發送數據了,那豈不是陷入死局,大家從此斷開?實際上發送方會一段時間後重試,如果還不行拉長一段時間後再重試,直到達到最大重試次數。

java學習之TCP 協議,很詳細,值得收藏下

4).擁塞控制

擁塞控制的起因是,作為TCP本身雖然已經有了各種校驗和檢測方法保證通信雙方能否互相通信並且能夠同步雙方的情況了。但是它還忽略了一個關鍵因素—網絡狀況。網絡是通路,如果這個通路太擁擠,應該適當減少發送,而如果這個通路比較寬鬆,則可以適當增加發送。

TCP的擁塞控制包括:慢啟動,擁塞避免,擁塞發生,快速恢復。

慢啟動每次將擁塞窗口的大小設置為1個數據段,之後每次收到確認應答則擁塞窗口加1

java學習之TCP 協議,很詳細,值得收藏下

由於這很容易造成指數級的增長放大,於是又引入一個慢啟動閾值的概念,即當tcp通信開始時,網絡吞吐會急劇上升,當到達一個閾值之後,則開始下降然後緩慢上升。

java學習之TCP 協議,很詳細,值得收藏下

4.TCP中的各種異常攻擊情況

1).SYN攻擊。主要是建聯時攻擊。攻擊方發起SYN請求,被攻擊方收到請求後回應ACK,此時攻擊方本應當回應此ACK使得被攻擊方變為establish狀態,然而攻擊方此時不做回應,使得被攻擊方維護的未連接隊列中該記錄存活時間因為超時重試而增加,而短期大量該類型攻擊淹沒可使得被攻擊方未連接隊列不斷增長,讓系統響應變慢,網絡擁堵甚至系統崩潰。

2).RST攻擊。RST復位主要是通信任何一方認為異常的連接則可以清除該連接的緩衝區,並向對方發送RST標誌強制關閉連接。RST攻擊主要是用來斷一個已有連接的,比如A與B連接中,此時C冒出來偽裝成A向B發送一個帶RST位的請求,則B將清除所有與A的“記憶”,下次A再來時,B將不認識A;當然了,如果C冒充A向B發送一個SYN請求,則B會主動發起RST復位。這類攻擊主要用來癱瘓重要連接,從而趁虛而入。


分享到:


相關文章: