自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

你知道嗎?如何學(xué)習(xí)TCP協(xié)議

移動(dòng)開(kāi)發(fā)
TCP協(xié)議的學(xué)習(xí)可以說(shuō)枯燥無(wú)比,尤其是學(xué)生階段,根本不知道用在什么地方,根本不知道重要性是什么。事實(shí)上是,基于目前的網(wǎng)絡(luò)發(fā)展和分布式發(fā)展,TCP簡(jiǎn)直就是基礎(chǔ)中的基礎(chǔ)。許多網(wǎng)絡(luò)的問(wèn)題,配置,入侵,防御乃至架構(gòu),都涉及到TCP的具體應(yīng)用及機(jī)制。

TCP協(xié)議目前是事實(shí)上的網(wǎng)絡(luò)基礎(chǔ)。許多更高層的應(yīng)用協(xié)議HTTP,FTP都基于TCP。

TCP協(xié)議的學(xué)習(xí)可以說(shuō)枯燥無(wú)比,尤其是學(xué)生階段,根本不知道用在什么地方,根本不知道重要性是什么。事實(shí)上是,基于目前的網(wǎng)絡(luò)發(fā)展和分布式發(fā)展,TCP簡(jiǎn)直就是基礎(chǔ)中的基礎(chǔ)。許多網(wǎng)絡(luò)的問(wèn)題,配置,入侵,防御乃至架構(gòu),都涉及到TCP的具體應(yīng)用及機(jī)制。

你知道嗎?如何學(xué)習(xí)TCP協(xié)議

以下是我總結(jié)的TCP學(xué)習(xí)過(guò)程,

1、了解學(xué)習(xí)TCP協(xié)議的重要性和必要性,了解TCP協(xié)議為什么被發(fā)展出來(lái)

2、學(xué)習(xí)TCP協(xié)議的三次握手以及四次揮手,重點(diǎn)了解為什么要三次握手,為什么要四次揮手,在整個(gè)過(guò)程中狀態(tài)是如何變遷的。(經(jīng)典的狀態(tài)圖以及握手揮手圖)

a、為什么要三次握手?不是一次,兩次或者四次。我們來(lái)論證一下,如果只有一次會(huì)發(fā)生什么情況,a向b發(fā)起連接請(qǐng)求,假設(shè)b沒(méi)收到,則b其實(shí)完全不知道a發(fā)起了請(qǐng)求,而a也完全不知道b收沒(méi)收到,所以一次握手是不可靠的;如果兩次握手呢,a向b發(fā)起連接請(qǐng)求,b收到a的請(qǐng)求給a回復(fù)一個(gè)請(qǐng)求,假設(shè)此時(shí)a收到了b的回復(fù),a知道了b已經(jīng)ready了,可b完全不知道a是否ready,有可能a并沒(méi)有收到b的請(qǐng)求,也有可能收到了,但這些b都完全不知道,所以只是單向的建立了連接;如果是四次握手呢,其實(shí)第2次讓a知道b ready了,第三次讓b知道a也ready了,第四次完全就是多余了,會(huì)浪費(fèi)網(wǎng)絡(luò)資源。

b、為什么要四次揮手?不是3次?實(shí)際上兩邊連接完全可以分開(kāi)看,用2次揮手?jǐn)嚅_(kāi)其中一邊連接,用另外2次揮手?jǐn)嚅_(kāi)另一邊的連接,最終完成整個(gè)連接關(guān)閉。之所以這樣設(shè)計(jì),是因?yàn)橛锌赡苣骋贿厰?shù)據(jù)還未傳輸完,連接還未關(guān)閉。因?yàn)門(mén)CP被設(shè)計(jì)為全雙工協(xié)議,可以任何一邊單向發(fā)送數(shù)據(jù)。

1、握手及揮手過(guò)程

你知道嗎?如何學(xué)習(xí)TCP協(xié)議

2、TCP的狀態(tài)轉(zhuǎn)換圖

你知道嗎?如何學(xué)習(xí)TCP協(xié)議

3、學(xué)習(xí)TCP協(xié)議是如何保持可靠性設(shè)計(jì)的。

主要目的是用來(lái)參考,以便在其他通信場(chǎng)合時(shí)用作架構(gòu)和設(shè)計(jì)的參考

1)包應(yīng)答序列號(hào)及包重組。

面臨的問(wèn)題:網(wǎng)絡(luò)傳輸中,會(huì)出現(xiàn)數(shù)據(jù)的破壞,丟包,重復(fù),分片混亂等問(wèn)題。

本質(zhì)上,要想保證傳輸?shù)目煽啃裕瑒t需要對(duì)傳輸?shù)膬?nèi)容進(jìn)行驗(yàn)證。

a、對(duì)于網(wǎng)絡(luò)數(shù)據(jù)的破壞(比如宇宙射線影響偷笑導(dǎo)致發(fā)射火箭的數(shù)據(jù)中某一位從0變?yōu)?),采取的策略是丟棄重新發(fā)送,以確保不會(huì)出現(xiàn)致命的錯(cuò)誤。TCP在自身協(xié)議中單獨(dú)劃了一塊checksum用于這種校驗(yàn),校驗(yàn)算法本質(zhì)上是將整塊數(shù)據(jù)通過(guò)某個(gè)函數(shù)映射到16位的校驗(yàn)位上(比如用字符相加的和來(lái)校驗(yàn))

你知道嗎?如何學(xué)習(xí)TCP協(xié)議

b、對(duì)于數(shù)據(jù)傳輸正確,但是分片亂序,重復(fù)等問(wèn)題,或是丟包,采取的策略并非丟棄而是自行進(jìn)行包重組。

考慮兩種情況:第一種情況是某個(gè)包缺少了,導(dǎo)致整個(gè)數(shù)據(jù)中間缺了一段1000字節(jié),那么如何通知到對(duì)方自己少了哪一段數(shù)據(jù);另一種情況是由于網(wǎng)絡(luò)或者重發(fā)機(jī)制的原因?qū)е履骋粋€(gè)包收到多次,如何把多余的包都排除掉,僅保留已有數(shù)據(jù)。

TCP在設(shè)計(jì)時(shí)候充分考慮這點(diǎn),其中SYN和ACK就是用來(lái)確保這個(gè)過(guò)程的,SYN發(fā)送的是字節(jié)順序,ACK則應(yīng)答收到的字節(jié)序加1。這樣,無(wú)論是發(fā)送方還是接收方,都可以準(zhǔn)確的維護(hù)一張發(fā)送接收字節(jié)的列表。從而可以知道對(duì)方還需要哪些字節(jié),或自己已經(jīng)接收了哪些字節(jié)。

你知道嗎?如何學(xué)習(xí)TCP協(xié)議

2)重發(fā)機(jī)制

a、超時(shí)重發(fā)

為了保證數(shù)據(jù)一定被接收到,就必須妥善處理超時(shí),對(duì)于超時(shí)沒(méi)得到響應(yīng),則最好的辦法是重新發(fā)送。

首先將數(shù)據(jù)拷貝到發(fā)送緩沖區(qū),每個(gè)包在發(fā)送時(shí)都會(huì)啟動(dòng)一個(gè)定時(shí)器,如果定時(shí)器超時(shí)前收到了對(duì)方應(yīng)答,則發(fā)送成功,清除緩沖區(qū),否則重傳數(shù)據(jù)包,直到達(dá)到最大次數(shù)。

TCP在每次發(fā)包時(shí)都會(huì)計(jì)算往返時(shí)間極其偏差,通過(guò)這個(gè)記錄可以大致判斷雙方的網(wǎng)絡(luò)情況從而確定超時(shí)時(shí)間。通常剛開(kāi)始超時(shí)時(shí)間較長(zhǎng)(如6s),而后可能到0.5s這樣較小的時(shí)間。

b、高速重發(fā)

比起超時(shí)才重新發(fā)送,TCP還設(shè)計(jì)了更為巧妙的方式來(lái)做重發(fā)。稱為快速重發(fā)。即目標(biāo)主機(jī)在確認(rèn)時(shí)總是確認(rèn)排在最先的缺失包,當(dāng)發(fā)送方發(fā)現(xiàn)連續(xù)收到3個(gè)同樣的ack時(shí),則表明該包已經(jīng)丟了,需要快速重新發(fā)送,這樣能否避免要等到超時(shí)才能重發(fā)。

3)流量控制(滑動(dòng)窗口)

a、滑動(dòng)窗口協(xié)議

滑動(dòng)窗口本質(zhì)上是為了在通信過(guò)程中同步收發(fā)雙方的速率。通過(guò)發(fā)送端的發(fā)送窗口和接收端的接收窗口來(lái)保證發(fā)送的可靠性,同時(shí)協(xié)調(diào)發(fā)送的速度。

你知道嗎?如何學(xué)習(xí)TCP協(xié)議

對(duì)于發(fā)送端來(lái)說(shuō),整個(gè)窗口分為下面四段,一是已經(jīng)發(fā)送也收到確認(rèn)回復(fù)的;二是已經(jīng)發(fā)送但尚未收到回復(fù)的;三是還沒(méi)有發(fā)送但即將發(fā)送的(接收方有空間,只是發(fā)送方尚未發(fā)送而已);四是沒(méi)發(fā)送,但是接收方已經(jīng)沒(méi)空間的

同理,對(duì)于接收方來(lái)說(shuō),整個(gè)窗口分為三段,一是已經(jīng)接收并且已經(jīng)回復(fù)ACK的;二是已經(jīng)接收的;三是為接收也沒(méi)準(zhǔn)備接收的

而所謂的滑動(dòng),則是將窗口從上一次收到的連續(xù)ACK的位置整個(gè)劃到下一次收到連續(xù)ACK的位置而已。注意連續(xù)二字,不連續(xù)則不能算作已經(jīng)接收完畢。

你知道嗎?如何學(xué)習(xí)TCP協(xié)議

b、滑動(dòng)窗口的收縮與擴(kuò)張

滑動(dòng)窗口最牛逼的地方在于動(dòng)態(tài)的調(diào)整收發(fā)雙方的窗口大小,以便使得收發(fā)雙方通信同步而不僅僅是對(duì)于發(fā)送接收字節(jié)的管理。

在TCP協(xié)議中,有16個(gè)字節(jié)專門(mén)用來(lái)放window大小,是接收端主機(jī)向發(fā)送方主機(jī)通知自己可以接納的數(shù)據(jù)大小,而發(fā)送方會(huì)根據(jù)該窗口數(shù)據(jù)發(fā)送不超過(guò)這個(gè)限度的數(shù)據(jù)。接收方可以根據(jù)自己的處理能力不斷的增大或者縮小這個(gè)值,而發(fā)送方主機(jī)則只要保持與之同步即可。

當(dāng)收縮到最小(即0窗口)時(shí),按照約定發(fā)送方不能再給接收方發(fā)送數(shù)據(jù)了,那豈不是陷入死局,大家從此斷開(kāi)?實(shí)際上發(fā)送方會(huì)一段時(shí)間后重試,如果還不行拉長(zhǎng)一段時(shí)間后再重試,直到達(dá)到最大重試次數(shù)。

你知道嗎?如何學(xué)習(xí)TCP協(xié)議

4)擁塞控制

擁塞控制的起因是,作為T(mén)CP本身雖然已經(jīng)有了各種校驗(yàn)和檢測(cè)方法保證通信雙方能否互相通信并且能夠同步雙方的情況了。但是它還忽略了一個(gè)關(guān)鍵因素—網(wǎng)絡(luò)狀況。網(wǎng)絡(luò)是通路,如果這個(gè)通路太擁擠,應(yīng)該適當(dāng)減少發(fā)送,而如果這個(gè)通路比較寬松,則可以適當(dāng)增加發(fā)送。

TCP的擁塞控制包括:慢啟動(dòng),擁塞避免,擁塞發(fā)生,快速恢復(fù)。

慢啟動(dòng)每次將擁塞窗口的大小設(shè)置為1個(gè)數(shù)據(jù)段,之后每次收到確認(rèn)應(yīng)答則擁塞窗口加1

你知道嗎?如何學(xué)習(xí)TCP協(xié)議

由于這很容易造成指數(shù)級(jí)的增長(zhǎng)放大,于是又引入一個(gè)慢啟動(dòng)閾值的概念,即當(dāng)tcp通信開(kāi)始時(shí),網(wǎng)絡(luò)吞吐會(huì)急劇上升,當(dāng)?shù)竭_(dá)一個(gè)閾值之后,則開(kāi)始下降然后緩慢上升。

你知道嗎?如何學(xué)習(xí)TCP協(xié)議

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

  • SYN攻擊。主要是建聯(lián)時(shí)攻擊。攻擊方發(fā)起SYN請(qǐng)求,被攻擊方收到請(qǐng)求后回應(yīng)ACK,此時(shí)攻擊方本應(yīng)當(dāng)回應(yīng)此ACK使得被攻擊方變?yōu)閑stablish狀態(tài),然而攻擊方此時(shí)不做回應(yīng),使得被攻擊方維護(hù)的未連接隊(duì)列中該記錄存活時(shí)間因?yàn)槌瑫r(shí)重試而增加,而短期大量該類型攻擊淹沒(méi)可使得被攻擊方未連接隊(duì)列不斷增長(zhǎng),讓系統(tǒng)響應(yīng)變慢,網(wǎng)絡(luò)擁堵甚至系統(tǒng)崩潰。
  • RST攻擊。RST復(fù)位主要是通信任何一方認(rèn)為異常的連接則可以清除該連接的緩沖區(qū),并向?qū)Ψ桨l(fā)送RST標(biāo)志強(qiáng)制關(guān)閉連接。RST攻擊主要是用來(lái)斷一個(gè)已有連接的,比如A與B連接中,此時(shí)C冒出來(lái)偽裝成A向B發(fā)送一個(gè)帶RST位的請(qǐng)求,則B將清除所有與A的“記憶”,下次A再來(lái)時(shí),B將不認(rèn)識(shí)A;當(dāng)然了,如果C冒充A向B發(fā)送一個(gè)SYN請(qǐng)求,則B會(huì)主動(dòng)發(fā)起RST復(fù)位。這類攻擊主要用來(lái)癱瘓重要連接,從而趁虛而入。
責(zé)任編輯:未麗燕 來(lái)源: ImportNew
相關(guān)推薦

2020-02-20 08:30:49

OSPF網(wǎng)絡(luò)協(xié)議路由協(xié)議

2024-01-15 12:16:37

2021-08-29 18:01:57

HTTP協(xié)議版本

2024-10-12 14:58:07

2023-01-13 17:02:10

操作系統(tǒng)鴻蒙

2024-07-08 00:00:01

多線程ThreadC#

2023-03-21 07:39:51

CentOS掛載硬盤(pán)

2024-12-03 00:38:37

數(shù)據(jù)湖存儲(chǔ)COS

2023-02-28 07:39:18

2024-02-23 08:09:43

Rediskey名字數(shù)據(jù)庫(kù)

2024-10-05 00:00:00

HTTPS性能HTTP/2

2025-01-16 16:41:00

ObjectConditionJDK

2024-10-15 10:32:30

2021-07-16 16:40:35

Chia協(xié)議奇亞

2024-03-28 10:25:58

開(kāi)源協(xié)議開(kāi)源軟件

2015-07-03 11:20:41

編程學(xué)習(xí)方法

2023-12-12 08:41:01

2023-12-20 08:23:53

NIO組件非阻塞

2024-04-30 09:02:48

2023-04-26 10:21:04

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)