<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                企業??AI智能體構建引擎,智能編排和調試,一鍵部署,支持知識庫和私有化部署方案 廣告
                # 一、傳輸控制協議TCP ## 1、傳輸控制協議TCP概述 ### 1.1 TCP的主要特點 1. TCP是**面向連接的**運輸層協議。應用程序在使用TCP協議傳輸數據之前,必須先建立連接;數據傳輸完成后,必須釋放已經建立的連接。 2. TCP只能提供**一對一**服務。每一條TCP的連接只能是2個端點,一對一的的建立。 3. TCP提供**可靠的交付**。通過TCP連接傳送的數據,無差錯、不丟失、不重復,并且按序到達。 4. TCP提供**全雙工通信**。TCP連接允許通信雙方的應用進程在任何時候都能互相發送數據,TCP連接的兩端都設有`發送緩存`和`接收緩存`,用來臨時存放雙方通信的數據。 5. TCP是**面向字節流**的。 > 面向字節流:雖然應用程序和TCP的交互是一次一個數據塊(大小不等),但是TCP把應用程序交下來的數據僅僅看做成`無結構的字節流`。TCP有一個緩沖,并且TCP不關心應用程序一次會發送多長的數據到TCP緩沖中,TCP會根據對方給出的窗口值和網絡擁塞的程度來決定一個報文段應包含多少個字節。如果應用進程一次發送到TCP緩沖中的數據塊太長,TCP就會把數據塊劃分短一點再傳送;同樣,如果應用進程一次發送到TCP緩沖的數據塊很短,TCP則會等待足夠多的字節后再構成報文段發送出去。 > UDP面向報文,是應用層交給UDP一個報文,UDP既不拆分也不合并,就會在報文上加上UDP首部后發送整個報文出去。 :-: ![](https://img.kancloud.cn/55/53/55539add0f139e25c76357fe5df72189_860x401.png) ### 1.2 TCP的連接 TCP把`連接`作為基本的抽象。其大部分特性都與TCP是面向連接的這個基本特性有關。 TCP連接的端點叫做socket;IP地址拼接上端口號就構成了一個socket。`socket = IP地址:端口號` 每一條TCP連接唯一的被通信兩端的兩個端點(即兩個socket)所確定。`TCP連接 = {socket1, socket2} = {(IP1:Port1), (IP2:Port2)}` ## 2、可靠傳輸的工作原理 ### 2.1 理想的傳輸條件 理想的傳輸條件一般需具備以下兩個條件: * 傳輸信道不產生差錯 * 不管發送方以多快的速度發送數據,接收方總是來得及處理收到的數據 但是,實際的網絡不能具備上述兩個理想的條件。需要使用一些可靠的傳輸協議來實現。當出現差錯時讓發送方重傳出現差錯的數據,同時在接收方來不及處理收到的數據時,及時告訴發送方適當減緩發送數據的速度。這樣,不可靠的傳輸信道就能夠實現可靠傳輸了。 ### 2.2 停止等待協議 全雙工通信的雙方既是發送方又是接收方。我們把傳送的數據稱之為分組。`停止等待`就是每發完一個分組就停止發送,等待對方的確認。在收到確認后再發送下一個分組。 #### 2.2.1 無差錯傳輸情況 :-: ![](https://img.kancloud.cn/70/b6/70b636485728a4c3ec7aa0b4d6ae84e0_423x460.png) #### 2.2.2 有差錯傳輸情況 * 超時重傳:只要超過一定的時間沒有收到確認,就認為剛才發送的分組丟失了,因而就會重傳前面發送過的分組。要實現超時重傳,就要在每發完一個分組時,設置一個`超時計時器`。 1. 發送完一個分組后,必須暫時保留已發送的分組(在發生超時重傳時使用);只有在收到相應的確認后才能清除暫時保留的分組副本 2. 分組和確認分組都必須進行編號。這樣才能明確是哪一個發送出去的分組收到了確認,而哪一個分組還沒有收到確認 3. 超時計時器的重傳時間,應當比數據在分組傳輸的平均往返時間更長一些 :-: ![](https://img.kancloud.cn/a7/63/a763cb0dc737173c4a85beb9fc97cc05_610x460.png) * 確認丟失:當一定時間沒有收到確認后,就會重傳分組;接收方收到后,就會丟棄重復的分組,然后重傳相應的確認分組 :-: ![](https://img.kancloud.cn/b1/08/b1080e0e54036687f093433fccc381b4_617x460.png) * 確認遲到:當一定時間沒有收到確認,重傳后收到重傳分組確認,然后又收到了開始發送分組的確認,這種情況下就直接丟棄此時收到的確認分組 :-: ![](https://img.kancloud.cn/d4/b8/d4b8d0b87c5f7de09b66780de60eaaa2_642x460.png) 通過上述的確認和重傳機制,我們就可以在不可靠的傳輸網絡上實現可靠的通信。 #### 2.2.3 信道利用率 停止等待協議的優點是簡單易實現,但是缺點也很明顯,就是信道利用率太低。 為了提高傳輸效率,發送方可以不使用低效率的停止等待協議,而是采用流水線傳輸。流水線傳輸就是發送方可連續發送多個分組,不必每發完一個分組就停頓下來等待對方的確認。這樣可以使信道上一直有數據不間斷的在傳送。這樣就可以獲得更高的信道利用率。 ### 連續ARQ協議 連續ARQ協議是指發送方維持著一個一定大小的發送窗口,位于發送窗口內的分組都可以連續發送出去,而不需要中途等待對方的確認。而當發送方每收到一個確認后,就會把發送窗口向前滑動一個分組的位置。 接收方一般都是采用`積累確認`的方式。這樣接收方就不需要對收到的分組逐個發送確認,而是在收到幾個分組后,對按序到達的最后一個分組發送確認,這就表示到這個分組為止的所有分組都收到了。 * 優點:簡單,容易實現,即使確認丟失也不必重傳 * 缺點:不能想發送方正確的發映出接收方已經正確的收到所有分組的信息 > 如果發送方發送了前5個分組,而中間的第3個分組丟失了。這時接收方只是對前兩個分組發出確認。發送方無法知道后面三個分組的下落,而只好把后面的三個分組都再重傳一次。 :-: ![](https://img.kancloud.cn/28/57/285700c38baa50a86a7cd6b98e50b555_586x319.png) ## 2、TCP報文段的首部格式 TCP雖然是面向字節流的,但是TCP傳送的數據單元是報文段。一個TCP報文段分`首部`和`數據`兩部分。TCP報文段的前20個字節是固定的,后面有4n個字節是根據需要而增加的選項(n是正整數)。因此TCP報文段的首部最小長度是20字節。 :-: ![](https://img.kancloud.cn/d9/c9/d9c9a6fac89034490134b90808b55712_741x488.png) ### 2.1 首部字段含義解釋 * `源端口`和`目的端口`:各占2各字節,分別寫入端口號和目標端口號 * `序號`:占4個字節。序號的范圍是[0, 2<sup>32</sup>-1] 共2<sup>32</sup>(即4294967296)個序號。序號增加到2<sup>32</sup>-1后,下一個序號就又回到0。在TCP連接的傳輸的字節流中,每一個字節都是按順序編號。 * `確認號`:占4個字節,是期望收到發送方下一個報文段的第一個數據字節的序號。 > 例如,接收方收到了發送方的一個報文段,其序號字段值為**201**,且數據長度為**200**;那么接收方期望收到的下一個數據序號就是**401**。因此接收方發送給發送方的確認報文段中就會把確認號設置為**401**。`也就說明了:若確認號為N,那么表明到序號N-1為止的所有數據都已正確收到` * `數據偏移`:占4位,指出TCP報文段的數據部分起始處距離TCP報文段的起始處有多遠。`實際上指出了TCP報文段的首部長度`。 * `保留`:占6位,保留位今后使用。 * 后面有一個控制位,用來說明報文段的性質 1. `緊急URG`:當URG=1時,說明緊急指針字段有效。告訴系統此報文段中有緊急數據,應盡快傳送,而不是按原先的排隊順序傳送 2. `確認ACK`:僅當ACK=1時確認號字段才有效;當ACK=0時,確認號字段無效。`TCP 連接規定,在連接建立后所有傳送的報文段都必須把ACK置為1` 3. `推送PSH`:當兩個應用進程進行交互式的通信時,有時在一端的應用進程希望在鍵入一個命令后立即就能收到對方的響應。在這種情況下,TCP就可以使用推送(push)操作。這時,發送方TCP把PSH置為1,并立即創建一個報文段發送出去。接收方TCP收到PSH=1的報文段,就盡快地(即“推送”向前)交付接收應用進程。而不用再等到整個緩存都填滿了后再向上交付。 4. `復位RST`:當RST=1時,表名TCP連接中出現了嚴重錯誤(如由于主機崩潰或其他原因),必須釋放連接,然后再重新建立傳輸連接。RST置為1還用來拒絕一個非法的報文段或拒絕打開一個連接。 5. `同步SYN`:在連接建立時用來同步序號。當SYN=1而ACK=0時,表明這是一個連接請求報文段。對方若同意建立連接,則應在響應的報文段中使SYN=1和ACK=1,因此SYN置為1就表示這是一個連接請求或連接接受報文。 6. `終止FIN`:用來釋放一個連接。當FIN=1時,表明此報文段的發送發的數據已發送完畢,并要求釋放運輸連接。 * `窗口`:占2字節。窗口值是[0,2<sup>16</sup>-1]之間的整數。窗口指的是發送本報文段的一方的接受窗口(而不是自己的發送窗口)。之所以要有這個限制,是因為接收方的數據緩存空間是有限的。總之,窗口值作為接收方讓發送方設置其發送窗口的依據。 * `校驗和`:占2字節。檢驗和字段檢驗的范圍包括首部和數據這兩部分。和UDP用戶數據報一樣,在計算檢驗和時,要在TCP報文段的前面加上12字節的偽首部。偽首部的格式和UDP用戶數據報的偽首部一樣。但應把偽首部第4個字段中的17改為6(TCP的協議號是6); 把第5字段中的UDP中的長度改為TCP長度。接收方收到此報文段后,仍要加上這個偽首部來計算檢驗和。 * `緊急指針`:占2字節。緊急指針僅在URG=1時才有意義,他指出報文段找那個緊急數據的字節數。 ## 2、TCP可靠傳輸的實現 ### 2.1 以字節為單位的滑動窗口 * 發送窗口構造 TCP的發送窗口是以字節為單位的。假設A收到了B發來的確認報文段,其中窗口是**10**,確認號是**31**(這表明B期望收到的下一個序號是31,且序號到30為止的數據都已經收到了)。根據這兩個值(窗口和確認號),A就可以構造出自己的發送窗口。在沒有收到B的確認的情況下,A可以連續把窗口內的數據都發送出去。`凡是已經發送出去的數據,在未收到確認之前都必須暫時保留,以便超時重傳時使用`。 :-: ![](https://img.kancloud.cn/07/be/07be3f34c52c0fcdfaebb897d73b0055_675x315.png) * 發送窗口變化 發送窗口的位置由窗口前沿和后沿的位置共同確定。 a. 發送窗口后沿的位置變化有2種,`即不動`(沒有收到新的確認)`和前移`(收到了新的確認)。發送窗口后沿不可能向后移動,因為不能撤銷已收到的確認。 b. 發送窗口前沿的位置通常情況下都是`向前移動`;但是在以下2種特殊情況下也有可能`保持不動`: > 1. 沒有收到新的確認,對應通知的窗口大小也不變 > 2. 收到了新的確認但是對方通知的窗口縮小了,使得發送窗口的前沿正好不動 c. 發送窗口前沿也有可能`向后收縮`。這種情況發生在對方通知的窗口縮小了。但是TCP的標準`強烈不贊成這樣做`。因為很可能發送方在收到這個通知以前已經發送了窗口中的許多數據,現在又要收縮窗口,不讓發送這些數據,這樣就會產生一些錯誤。 * 緩存和窗口 發送緩存用來暫時存放: > 1. 發送方準備發送給對方TCP的數據 > 2. TCP已發送出但尚未收到確認的數據 已收到確認的數據應當從緩存中刪除,因此發送緩存和發送窗口的后沿是重合的。發送應用程序必須控制寫入緩存的速率,不能太快,不然發送緩存很快就會沒有存放數據的空間。 接收緩存用來暫時存放: > 1. 按序到達的,但尚未被應用程序讀取的數據 > 2. 未按序到達的數據 當接收應用程序來不及讀取收到的數據,接收緩存最終就會被填滿,使接收窗口減小到零。當接收應用程序能夠及時的從接收緩存中讀取收到的數據時,接收窗口就可以增大,最大為接收緩存的大小。 要點小結: > 1. 雖然A的發送窗口是根據B的接收窗口設置的,但在同一時刻,A的發送窗口并不總是和B的接收窗口一樣大。通過網絡傳送的窗口值需要經歷一定的時間滯后,改時間并不確定。 > 2. 對于不按序到達的數據,TCP通常是先臨時存放在接收窗口,等字節流中所缺少的字節收到后,再按序上交給應用程序。 > 3. TCP 要求接收方必須要有累計確認的功能,這樣可以減少傳輸開銷 ## 3、 TCP流量控制 ### 3.1 利用滑動窗口實現流量控制 流量控制:讓發送方的發送速率不要太快,要讓接收方來得及接收。利用滑動窗口機制可以很方便的在TCP連接上實現對發送方的流量控制。 TCP流量控制舉例:假設A主機和B主機,每次發送100字節,B通知A窗口大小為300 :-: ![](https://img.kancloud.cn/d7/2a/d72aecd8e8b64b0ed13dccf2031b9696_742x578.png) 避免死鎖:TCP為每一個連接設有一個持續計數器。只要TCP連接的一方收到對方零窗口通知,就啟動持續計時器。若持續計時器設置的時間到期,就發送一個零窗口探測報文段(只攜帶1字節的數據),而對方就在確認這個探測報文段時給出了當前的窗口值。若果窗口扔為零,那么收到這個報文段的一方就重新設置持續計數器。如果新的窗口不是0,那么就打破了死鎖的僵局。 ## 4 TCP的擁塞控制 ### 4.1 擁塞控制的一般原理 在計算機網絡中的鏈路容量(寬帶)、交換節點中的緩存和處理機等,都是網絡資源。在某段時間,若對網絡中某一資源的需求超過了該資源所能提供的可用部分,網絡的性能就會變壞。這種情況就叫做擁塞。 擁塞控制就是防止過多的數據注入到網絡中,這樣就可以使網絡中的路由器或鏈路不至于過載。 :-: ![](https://img.kancloud.cn/dd/ab/ddab61dcad6f8fe31e0c7d8f683d40cc_611x421.png) ## 4.2 TCP的擁塞控制方法 TCP進行擁塞控制的方法有四種,分別是:`慢開始`,`擁塞避免`,`快重傳`,`快恢復`。 * 慢開始 當主機開始發送數據時,由于并不清楚網絡的負荷情況,如果立即把大量數據字節注入到網絡,就有可能引起網絡發生擁塞。經驗證明,比較好的方法是先探測一下,即`由小到大逐漸增大發送窗口`,也就是說,`由小到大逐漸增大到擁塞窗口值`。 cwnd: 發送方的擁塞窗口,開始發送時設置為:cwnd=1 > **慢開始算法:** ??? ????在剛剛開始發送報文段時,先把擁塞窗口 cwnd 設置為1個最大報文段MSS的數值,而后每收到一個對新的報文段的確認,就把擁塞窗口增加1個MSS的數值,這樣擁塞窗口cwnd的值就隨著傳輸輪次(一個輪次即發送完一個cwnd的MSS)呈指數級增長,事實上,慢啟動的速度一點也不慢,只是它的起點比較低一點而已。用這樣的方法逐步增大發送方的擁塞窗口 cwnd ,可以使分組注入到網絡的速率更加合理。 > **慢開始門限ssthresh:** 為了防止擁塞窗口cwnd增長過大引起網絡擁塞,還需要設置一個慢開始門限ssthresh狀態變量(如何設置ssthresh)。慢開始門限ssthresh的用法如下: ??? ????當 cwnd < ssthresh 時,使用上述的慢開始算法。 ??????? 當 cwnd >?ssthresh 時,停止使用慢開始算法而改用擁塞避免算法。 ??????? 當 cwnd = ssthresh 時,既可使用慢開始算法,也可使用擁塞控制避免算法。 * 擁塞避免 讓擁塞窗口cwnd緩慢的增大,即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1,而不是像慢開始那樣加倍增加。因此在擁塞避免階段就產生了`加法增大`的特點。這表明在擁塞避免階段,擁塞窗口cwnd`按線性規律增長緩慢`,比慢開始算法的擁塞窗口增城速率緩慢的多。擁塞避免并非完全能夠避免擁塞,而是把擁塞窗口控制位按線性規律增長,使網絡比較不容易出現擁塞。 > **擁塞避免算法:** ??????? 當cwnd >= ssthresh時,就會進入“擁塞避免算法”,讓擁塞窗口cwnd緩慢地增大,每收到1個ACK擁塞窗口cwnd = cwnd + 1/cwnd,即每經過一個傳輸輪次就把發送方的擁塞窗口cwnd加1。這樣擁塞窗口cwnd按線性規律緩慢增長,比慢開始算法的擁塞窗口增長速率緩慢得多。 * 快重傳 采用快重傳算法可以讓發送方`盡早知道發生了個別報文段的丟失。`快重傳算法首先要求接收方不要等待自己發送數據時才進行捎帶確認,而是要立即發送確認,即使收到了失序的報文段,也要立即發出對方已收到報文段的重復確認。 * 快恢復 發送方知道當前只是丟失了個別的報文段。于是不啟動慢開始,而是執行快恢復算法。 ## 5、TCP的運輸連接管理 TCP 是面向連接的協議。運輸連接是用來傳送TCP報文的。TCP運輸連接的建立和釋放是每一次面向連接的通信中必不可少的過程。運輸連接有三個階段:`連接建立`、`數據傳送`和`連接釋放`。運輸連接管理就是使運輸連接的建立和釋放都能夠正常的進行。 在TCP連接建立過程中要解決以下三個問題: 1. 要使每一方能夠確知對方的存在 2. 要允許雙方協商一些參數,`如:最大窗口值,是否使用窗口擴大選項和時間戳選項等` 3. 能夠對運輸實體資源(緩存大小、連接表中的項目等)進行分配 ### 5.1、TCP的連接建立 TCP建立連接的過程叫握手,握手需要在客戶和服務器之間交換三個TCP報文段 :-: ![](https://img.kancloud.cn/ba/f0/baf00e706eb51b9efdce8108f97ffb45_646x445.png) * 1)第一次握手:建立連接時,客戶端發送syn包(syn=j)到服務器,并進入SYN\_SENT狀態,等待服務器確認;SYN:同步序列編號(Synchronize Sequence Numbers)。 * 2)第二次握手:服務器收到syn包,必須確認客戶的SYN(ack=j+1),同時自己也發送一個SYN包(syn=k),即SYN+ACK包,此時服務器進入SYN\_RECV狀態。 * 3)第三次握手:客戶端收到服務器的SYN+ACK包,向服務器發送確認包ACK(ack=k+1),此包發送完畢,客戶端和服務器進入ESTABLISHED(TCP連接成功)狀態,完成三次握手。 > 四報文握手:B 發送給 A 的報文段,可拆成兩個報文段。先發送一個確認報文段(ACK = 1,ack = x + 1),然后再發送一個同步報文段(SYN = 1,seq = y)。這樣的過程就變成了`四報文握手`,與三報文握手效果一致 ### 5.2、 TCP連接釋放 TCP建立連接的過程叫揮手,握手需要在客戶和服務器之間交換四個TCP報文段 :-: ![](https://img.kancloud.cn/eb/4e/eb4e002450a0d02650098ad657744a77_1350x790.png) * 1)A的應用進程先向其TCP發出連接釋放報文段(**FIN=1,序號seq=u**),并停止再發送數據,主動關閉TCP連接,進入FIN-WAIT-1(終止等待1)狀態,等待B的確認。 * 2)B收到連接釋放報文段后即發出確認報文段,(**ACK=1,確認號ack=u+1,序號seq=v**),B進入CLOSE-WAIT(關閉等待)狀態,此時的TCP處于半關閉狀態,A到B的連接釋放。 * 3)A收到B的確認后,進入FIN-WAIT-2(終止等待2)狀態,等待B發出的連接釋放報文段。 * 4)B沒有要向A發出的數據,B發出連接釋放報文段(**FIN=1,ACK=1,序號seq=w,確認號ack=u+1),**B進入LAST-ACK**(最后確認)狀態,等待A的確認。 * 5)A收到B的連接釋放報文段后,對此發出確認報文段(**ACK=1,seq=u+1,ack=w+1**),A進入TIME-WAIT(時間等待)狀態。此時TCP未釋放掉,需要經過時間等待計時器設置的時間2MSL后,A才進入CLOSED狀態。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看