當前位置:首頁 » 網路連接 » 計算機網路傳輸層問題
擴展閱讀
電腦開機黑屏只能動滑鼠 2025-02-25 08:42:44
哪個網站可以查企業補貼 2025-02-25 08:32:54

計算機網路傳輸層問題

發布時間: 2023-12-12 22:13:33

計算機網路傳輸層

端到端的連接

網路層:提供主機之間的邏輯通信
傳輸層慎銷寬:提供應用進程之間的邏輯通信
位於網路層之上、依賴網路層服務、對網路層服務進行可能的增強

接收端:多路分用
相同目的地址目的埠號的UDP會被導向同一個socket
每個srcIp srcPort DestIp DestPort 導向自寬亮己獨有的socket(創建多個socket)
(伺服器也可以讓一個進程創建多個線程與tcp連接綁定)
發送端:多路復用

什麼是可靠? 不錯、不亂、不丟

可靠數據傳輸協議

GBN
1.發送方 分組頭部包含k-bit序列號
窗口尺寸為N,最多允許N個分組未確認

序列號 :表示本報文段所發送數據的第一個位元組的編號。而不是報文段的編號(這里防止被攻擊混入其他的段難以檢測的問題)。
建立TCP連接時,雙方隨即選擇序列號

ACKs 表示接收方期望收到發送方下一個報文段的第一個位元組數據的編號。
累計確認:該序列號之前所有的位元組均已被正確接收到(GBN)

TCP在IP層提供的不可靠服務基礎上實現可靠數據傳輸服務
流水線機制
累積確認
TCP使用單一重傳定時器
觸發重傳的事件
超時
收到重復ACK
漸進式
暫不考慮重復ACK
暫不考慮流量控制
暫不考慮擁塞控制

1.點對點 一個sender 一個 reciever

2.可靠的、按序的位元組流

3.流水線機制

案例:

何時應該指數性增長切換為線性增長(擁塞避免)?
當CongWin達到Loss事件前值的1/2時.
實現方法:利用一個變數 Threshold, Loss事件發生時, Threshold被設為Loss事件前CongWin值的1/2。

Loss事件處理辦法
3個重復ACKs:CongWin切到一半然後線性增長
Timeout事件:CongWin直接設為1個MSS,然後指數增長,達到threshold後, 再線性增長(擁塞更嚴重了)

TCP擁塞控制演算法

4.接收方/發送方緩存

5.全雙工:同一連接中能傳輸雙數據流

6.面向連接(連接管理)

TCP連接包括:兩台主機上的緩存、連接狀態變數、socket等
客戶端初始化的序列號是隨機的

7.流量控制機制:發送方不會傳輸的太多、太快以至於淹沒接收方(buffer溢出)

8.復用/分用

1.基於「盡力而為」的網路層,沒有做(可靠性)
丟失
非按序到達

2.基於Internet IP協議
復用/分用
簡單的錯誤校驗

3.無連接
UDP發送方和接收方之間不需要握手
每個UDP段的處理獨立於其他段

UPD優點:
1.無需建立連接(減少延遲)-DNS
2.實現簡單,無需維護連接狀態
3.頭部開銷小(8byte)
4.沒有擁塞控制:應用可更斗簡好的控制發送時間和速率

常用於流媒體應用
1.容忍丟失
2.速率敏感

DNS/SNMP

在UDP上實現可靠數據傳輸

UDP校驗和:檢測UDP段在傳輸過程中是否發生錯誤

Ⅱ [計算機網路之六] 傳輸層

  傳輸層向它上面的應用層提供通信服務,它屬於面向通信部分的最高層,同時也是用戶功能中的最底層。

  從傳輸層的角度,通信的真正端點並不是主機而是主機中的進程。

  傳輸層有 分用 復用 的功能。 「復用」 是指在發送方不同的應用進程都可以使用同一個運輸層協議傳送數據, 「分用」 是指接收方的運輸層在剝去報文的首部後能夠把這些數據正確交付目的應用進程。

  網路層和運輸層有明顯的區別,網路層為主機之間提供邏輯通信,而運輸層為應用進程之間提供端到端的邏輯通信。

知名埠號 :0~1023
登記埠號 :1024~49151
客戶端短暫埠號 :49152~65535


① 無連接。 發送數據之前不需要建立連接,因此減少了開銷和發送數據之前的時延。
② 盡最大努力交付。 即不保證可靠交付,因此主機不需要維持復雜的連接狀態表。
③ 面向報文的。 對應用層交下來的報文,既不合並,也不拆分,而是保留這些報文的邊界,UDP 一次交付一個完整的報文。

  用戶數據報 UDP 有兩個欄位:數據欄位和首部欄位。首部欄位很簡單,只有 8 個位元組,由四個欄位組成,每個欄位的長度都是兩個位元組。各欄位意義如下:

① 源埠 在需要對方回信時選用。不需要時可用全0。
② 目的埠 目的埠號。這在終點交付報文時必須使用。
③ 長度 用戶數據報的長度,最小值為 8 (僅有首部)。
④ 檢驗和 檢測用戶數據報在傳輸中是否有錯。有錯就丟棄。

  用戶數據報首部檢驗和的計算和校驗都要計算出一個偽首部。


① 面向連接。

  應用程序在使用 TCP 協議之前,必須先建立 TCP 連接;傳送數據完畢後,必須釋放已經建立的 TCP 連接。類似於打電話:通話前要先撥號建立連接,通話結束後要掛機釋放連接。

② 一對一。

  TCP 連接只能是點對點的(一對一)。

③ 可靠交付。

  通過 TCP 連接傳送的數據,無差錯、不丟失、不重復,並且按序到達。

④ 全雙工通信。

  通信雙方的應用進程在任何時候都能發送和接收數據,TCP 連接的兩端都設有發送緩存和接收緩存,用來臨時存放雙向通信的數據。

⑤ 面向位元組流。

  TCP 中的 「流」 指的是流入到進程或從進程流出的位元組序列。

  「面向位元組流」 的含義:雖然應用程序和 TCP 的互動式一次一個數據塊(大小不等),但 TCP 把應用程序交下來的數據僅僅看成是一連串無結構的位元組流。TCP 並不知道所傳送的位元組流的含義。TCP 不保證接收方應用程序鎖收到的數據塊和發送方應用程序所發出的數據塊具有對應的大小關系。但接收方應用程序收到的位元組流必須和發送方應用程序發出的位元組流完全一樣,當然接收方的應用程序必須有能力識別收到的位元組流,把它還原成有意義的應用層數據。

  TCP 連接是協議軟體提供的一種抽象,每一條 TCP 連接唯一地被通信兩端的兩個端點(即兩個套接字)所確定,即:

  TCP 連接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}

  IP1 和 IP2 分別是兩個端點主機的 IP 地址,port1 和 port2 分別是兩端端點主機中的埠號。


  網路只能提供最大努力的服務,是不可靠的,因此 TCP 必須採用適當的措施才能使得兩個運輸層之間的通信變得可靠。當出現差錯時讓發送方重傳出現差錯的數據,同時在接收方來不及處理收到的數據時,及時告知發送方適當降低發送數據的速度,這樣就可以在不可靠的傳輸信道實現可靠傳輸。

  ARQ(Auto Repeat-reQuest):自動重傳請求。

  發送方每發送完一個分組就停止發送,等待接收方確認,在收到確認後再發送下一個分組。
  A 是發送方,B 是接收方。

  A 每發送一個分組後,等待 B 對該分組的確認後,再接著發送下一個分組。

【發送方】A 發送的分組在傳輸過程中出錯,可能是丟失了,也可能是分組受到干擾出錯了
【接收方】這時 B 直接丟棄分組,什麼也不做(也不通知 A 受到的分組有差錯)。

【解決方案】發送方在每發送完一個分組時設置一個 超時計數器 ,只要超過一段時間仍然沒有接收到確認,就認為剛才發送的分組丟失了,因而重傳前面發送過的分組,這叫 超時重傳 。反之在超時計時器到期之前收到了相應的確認,就撤銷該超時計時器。

第一,A 在發送完一個分組後, 必須暫時保留已發送的分組的副本 (在發生超時重傳時使用)。只有在收到相應的確認後才能清楚暫時保留的分組副本。

第二,分組和確認分組都必須進行 編號 。這樣才能明確是哪一個發送出去的分組受到了確認,而哪一個分組還沒有收到確認。

第三,超時計時器設置的 重傳時間應當比數據在分組傳輸的平均往返時間更長一些

【發送方】超時重傳時間內沒有收到確認報文,無法確認是發送出錯、丟失,還是接收方的確認丟失,超時計時器到期後就要重傳。
【接收方】丟棄收到的重復分組,不向上層交付;向發送方發送確認。

【發送方】收下遲到的確認,並且丟棄

  發送方大部分時間都在等待確認,信道的利用率低

  使用流水線的 ARQ 可以提高信道利用率

【發送方】維持一個發送窗口,位於發送窗口內的分組都可連續發送出去,而不需要等待對方的確認。

回退N幀協議 :如果發送方發送了多個分組,但中間的某個分組丟失了,這時接收方只能對丟失分組之前的分組發出確認,而發送方無法知道丟失分組及後面分組的接收情況,只好把丟失分組及後面的分組重傳一次,這叫 Go-back-N ,表示需要再退回來重傳已發送過的 N 個分組。


  前面 20 個位元組固定,因此 TCP 首部最小長度是 20 位元組。

  TCP 的滑動窗口以位元組為單位,窗口後沿的部分表示已發送且已收到通知,窗口裡的序號表示允許發送的序號,窗口前沿之前的數據暫時不允許發送,需要等待收到接收方的確認後前沿往前移才可發送。

描述一個發送窗口需要三個指針:P1、P2 和 P3,如圖所示:

  小於 P1 的是已發送並已收到確認的部分,而大於 P3 的是不允許發送的部分。

  P3 - P1 = A 的發送窗口

  P2 - P1 = 已發送但尚未收到確認的位元組數

  P3 - P2 = 允許發送但當前尚未發送的位元組數(又稱為 可用窗口 有效窗口

  接收方 B 接收窗口大小為20,因為未收到 31 的數據,即使已收到後面的序號 32、33 的數據,返回的確認號仍然是 31。

  現在接收方收到了 31、32、33,並返回確認號 33,接收窗口往前滑動 3 個序號,發送方接收到確認,發送窗口也向前滑動 3 個序號大小,現在 A 可以發送序號 51~53 的數據了。

  當發送方將發送窗口內的數據都發送出去,但是接收方的確認可能由於網路擁塞滯留,這時發送方發送窗口已滿,可用窗口為 0,只能等待接收方的確認報文到達。

  TCP 為了保證可靠傳輸,要求必須受到對已發送報文的確認,如果超過一定時間未受到確認報文,則重傳已發送的報文。這個時間就叫 超時重傳時間 ,很明顯超時重傳時間的大小設置應該更貼近網路的實際情況,如果網路狀況好,就設短一點,否則使網路的空閑時間增大,降低了傳輸效率;網路差就設長一點,否則會引起很多不必要的重傳,使網路負荷增大。

  TCP 採用了一種自適應的演算法:

  RTT(報文段的往返時間)、RTTs(加權平均往返時間),RTTs 的計算公式:

RTTd(RTT 的偏差的加權平均值)、RTO(RetransmissionTime-Out 超時重傳時間):

【場景】TCP 的接收方在接收對方發送過來的數據位元組流的序號不連續,形成一些不連續的位元組塊,如果簡單按照回退N幀協議處理,意味著要重傳第一個未收到的序號數據塊及之後的數據,如果能通知發送方已收到了哪些數據(選擇確認),就可以讓發送方只發送接收方未收到的數據。



  流量控制就是讓發送方的發送速率不要太快,要讓接收方來得及接收。

  當發送方收到接收方通知,將窗口縮小為 0 時,發送方將暫時不能發送數據了,必須等接收方通知更新接收窗口大小,但是這個通知又有可能丟失,導致發送方沒收到通知。

  為了避免雙方互相等待死鎖,TCP 為每個鏈接設有一個 持續計時器 ,只要 TCP 連接的一方收到對方的零窗口通知,就啟動持續計時器。若持續計時器設置的時間到期,就發送一個零窗口 探測報文段 (僅攜帶 1 位元組的數據),而對方就在確認這個探測報文段時給出了現在的窗口值。如果窗口仍然是零,那麼受到這個報文段的一方就重新設置持續計時器;如果窗口不是零,那麼死鎖的僵局就可以打破了。



【優點】提高網路利用率
【缺點】可能會發生某種程度的延遲

【場景】接收數據的主機如果每次都立刻回復確認應答的話,可能會返回一個較小的窗口,因為接收方剛接收完數,緩沖區已滿。

【糊塗窗口綜合征問題】
TCP 接收方緩存已滿,而互動式的應用進程一次只從接收緩存中讀取 1 個位元組(這樣就使接收緩存空間僅騰出 1 個位元組),然後向發送方發送確認,並把窗口設置為 1 個位元組(但發送的數據報是 40 位元組長,TCP 首部 + IP 數據報首部)。接著,發送方又發來 1 個位元組的數據(注意發送方發送的 IP 數據報是 41 位元組長)。接收方發回確認,仍然將窗口設置為 1 個位元組。這樣進行下去,使網路的效率很低。

  TCP 文件傳輸中,就採用了兩個數據段返回一次確認應答,並且等待一定時間後沒有其他數據包到達時也依然發送確認應答。

  當對網路中某一資源的需求超過了該資源所能提供的可用部分,網路的性能就要變壞,這種情況就叫做 擁塞



  慢開始(slow-start)、擁塞避免(congestion avoidance)、快重傳(fast retransmit)和快恢復(fast recovery)。

【演算法思路】

  當主機開始發送數據時,由於並不清楚網路的負荷情況,所以如果立即把大量數據位元組注入網路,那麼就有可能引起網路發生擁塞。較好的方法是先探測一下,即 由小到大逐漸增大發送窗口 ,也就是說, 由小到大逐漸增大擁塞窗口數值

【處理過程】

   慢開始門限值 ssthresh 決定了擁塞窗口達到多大時要執行什麼演算法。

① 當 cwnd < ssthresh 時,使用慢開始演算法;
② 當 cwnd > ssthresh 時,停止使用慢開始演算法而改用擁塞避免演算法;
③ 當 cwnd = ssthresh 時,既可使用慢開始演算法,也可使用擁塞避免演算法。

  在擁塞窗口 cwnd 達到門限值之前,發送方每一輪次收到確認應答後,cwnd 就增大為原來的兩倍;達到門限值後,執行擁塞避免演算法。

PS. 慢開始只是表示初始發送數據少,不代表發送速率增長速度慢,實際上是指數級增長非常快。

【演算法思路】

  讓擁塞窗口 cwnd 緩慢地增大,即每經過一個往返時間 RTT 就把發送方的擁塞窗口 cwnd 加 1,而不是像慢開始階段那樣加倍增長。擁塞避免階段有 「加法增大」 的特點,按線性規律緩慢增長,使網路比較不容易出現擁塞

【處理過程】

  在執行擁塞避免演算法階段,當網路出現超時時,發送方判斷為網路擁塞,調整門限值為當前擁塞窗口的一半,即 ssthresh = cwnd / 2,同時擁塞窗口重置為 1,即 cwnd = 1,進入慢開始階段。

【演算法原理】

① 快重傳

【場景】有時,個別報文段會在網路中丟失,但實際上網路並未發生擁塞。如果發送方遲遲收不到確認,就會產生超時,就會誤認為網路發生了擁塞,導致發送方錯誤地啟動慢開始,把擁塞窗口 cwnd 又設置為 1,因而降低了傳輸效率。

【方案】接收方不要等待自己發送數據時才進行捎帶確認,而是要立即發送確認,即使收到了失序的報文段也要立即發出對已收到的報文段的重復確認,當發送方 一連收到 3 個重復確認 ,就知道接收方確實沒有收到某個報文段,因而應當 立即進行重傳

② 快恢復:

  發送方知道只是丟失了個別的報文段,於是不啟動慢開始,而是執行快恢復演算法,調整發送方門限值 ssthresh = cwnd / 2,同時設置擁塞窗口 cwnd = ssthresh = 8,並開始執行擁塞避免演算法。


擁塞控制的流程如下:

  擁塞窗口 cwnd,接收方窗口 rwnd, 發送方發送窗口的上限值 = Min[rwnd, cwnd]

① 當 rwnd < cwnd,接收方的接收能力限制發送方窗口大小;
② 當 cwnd < rwnd,網路的擁塞程度限制發送方窗口大小。


【問題背景】

  路由器採取分組丟棄策略,即按照 先進先出(FIFO) 規則處理分組,當隊列已滿時,則丟棄後面到達的分組,這叫 尾部丟棄策略

  丟失的分組會導致發送方出現超時重傳,發送方轉而執行慢開始演算法,不同分組屬於不同 TCP 連接,導致很多 TCP 同時進入慢開始狀態,這種現象稱為 全局同步

【解決方案】

  主動隊列管理 AQM:不等到路由器的隊列長度已經達到最大值時才不得不丟棄後面到達的分組,而是在隊列長度達到某個警惕值時就主動丟棄到達的分組,這樣就提醒了發送方放慢發送的速率,因而有可能使網路擁塞的程度減輕,甚至不出現網路擁塞。


  TCP 是面向連接的協議,運輸連接有三個階段: 連接建立、數據傳送、連接釋放

  TCP 連接建立過程要解決的幾個問題:

① 使每一方能夠確知對方的存在;
② 允許雙方協商一些參數(如最大窗口值、是否使用窗口擴大選項和時間戳選項以及服務質量等);
③ 能夠對運輸實體資源(如緩存大小、連接表中的項目等)進行分配。

  TCP 建立連接的過程叫做握手,握手需要在客戶和伺服器之間交換三個 TCP 報文段,即 三次握手

  最初客戶端和服務端都處於 CLOSED(關閉) 狀態,A(Client)主動打開連接,B(Server)被動打開連接。

  一開始,B 的 TCP 伺服器進程先創建 傳輸控制塊 TCB ,准備接受客戶進程的連接請求。然後伺服器進程就處於 LISTEN(收聽)狀態,等待客戶端的連接請求。如有,即作出響應。

   第一次握手 :A 的 TCP 客戶進程也是首先創建傳輸控制塊 TCB,准備接受客戶進程的連接請求。然後在打算建立 TCP 連接時,向 B 發出連接請求報文段,這時首部中的同步位 SYN = 1,同時選擇一個初始序號 seq = x。TCP 規定,SYN 報文段(即 SYN = 1 的報文段)不能攜帶數據,但要 消耗掉一個序號 。這時,TCP 客戶進程進入 SYN-SENT(同步已發送) 狀態。

   第二次握手 :B 收到連接請求報文段後,如同意建立連接,則向 A 發送確認。在確認報文段中應把 SYN 位和 ACK 位都置 1,確認號是 ack = x + 1,同時也為自己選擇一個初始序號 seq = y。請注意,這個報文段也不能攜帶數據,但同樣 要消耗掉一個序號 。這時 TCP 伺服器進程進入 SYN-RCVD(同步收到) 狀態。

   第三次握手 :TCP 客戶進程收到 B 的確認後,還要向 B 給出確認。確認報文段的 ACK 置 1,確認號 ack = y + 1,而自己的序號 seq = x + 1。TCP 的標准規定,ACK 報文段可以攜帶數據。但 如果不攜帶數據則不消耗序號 ,在這種情況下,下一個數據報文段的序號仍是 seq = x + 1。這時,TCP 連接已經建立,A 進入 ESTABLISHED(已建立連接) 狀態。當 B 收到 A 的確認後,也進入 ESTABLISHED(已建立連接)狀態。








  數據傳輸結束後,通信的方法都可釋放連接。現在 A 和 B 都處於 ESTABLISHED 狀態。

   第一次揮手 :A 的應用進程先向其 TCP 發出連接釋放報文段,並停止再發送數據,主動關閉 TCP 連接。A 把連接釋放報文段首部的終止控制位 FIN 置 1,其序號 seq = u,它等於前面已傳送過的數據的最後一個位元組的序號加 1。這時 A 進入 FIN-WAIT-1(終止等待 1)狀態,等待 B 的確認。請注意,TCP 規定,FIN 報文段即使不攜帶數據,它也消耗掉一個序號。

   第二次揮手 :B 收到連接釋放報文後即發出確認,確認號是 ack = u + 1,而這個報文段自己的序號是 v,等於 B 前面已傳送過的最後一個位元組的序號加 1。然後 B 就進入 CLOSE-WAIT(關閉等待)狀態。TCP 伺服器進程這時應通知高層應用程序,因而從 A 到 B 這個方向的連接就釋放了,這時的 TCP 連接處於半關閉(half-close)狀態,即 A 已經沒有數據要發送了,但 B 若發送數,A 仍要接收。也就是說,從 B 到 A 這個方向的連接並未關閉,這個狀態可能會持續一段時間。A 收到來自 B 的確認後,就進入 FIN-WAIT-2(終止等待 2)狀態,等待 B 發出的連接釋放報文段。

   第三次揮手 :若 B 已經沒有要向 A 發送的數據,其應用進程就通知 TCP 釋放連接。這時 B 發出的連接釋放報文段必須使 FIN = 1。現假定 B 的序號為 w(在半關閉狀態 B 可能又發送了一些數據)。B 還必須重復上次已發送過的確認號 ack = u + 1。這時 B 就進入 LAST-ACK(最後確認)狀態,等待 A 的確認。

   第四次揮手 :A 在收到 B 的連接釋放報文段後,必須對此發出確認。在確認報文段中把 ACK 置 1,確認號 ack = w + 1,而自己的序號是 seq = u + 1(根據 TCP 標准,前面發送過的 FIN 報文段要消耗一個序號)。然後進入 TIME-WAIT(時間等待)狀態。請注意,現在 TCP 連接還沒有釋放掉。必須經過時間等待計時器(TIME-WAIT timer)設置的時間 2MSL 後,A 才進入到 CLOSED 狀態,然後撤銷傳輸控制塊,結束這次 TCP 連接。當然如果 B 一收到 A 的確認就進入 CLOSED 狀態,然後撤銷傳輸控制塊。所以在釋放連接時,B 結束 TCP 連接的時間要早於 A。




Ⅲ [計算機網路]Ch.6 傳輸層

為什麼需要兩個不同的獨立控制層

傳輸層的主要功能
傳輸層是整個協議棧(TCP/IP)的核心,傳輸層的任務是提供 可靠的、高效的 數據傳輸

傳輸層使整個報文到達了該計算機上正確的進程
傳輸層的最終目標是向它的用戶(應用層)提供高效、可靠和性價比高的服務【例如從一台主機到另一台主機的報文到底送給這台機器的email去解析,還是送給播放器播放,還是瀏覽器解析】

埠(port)定義
16 位,共有 216個埠
埠范圍:0~65535
<1023 : 用於公共應用(保留,全局分配,用於標准伺服器),IANA分配;
1024~49151 :用戶埠,注冊埠;
> 49152 : 動態埠,私人埠。

TCP (Transmission Control Protocol) 是專門為了 在不可靠的互聯網路 上提供 可靠的端到端位元組流 而設計的
TCP必須 動態地適應 不同的拓撲、帶寬、延遲、分組大小和其它的參數,並且當有錯誤的時候,能夠足夠 健壯

TCP服務模型:

TCP頭部范圍(5x4B 15x4B(最大數值))--(20B 60B)

釋放連接

兩軍隊問題

難題在於最後發送的一方永遠無法知道自己的信 對方有無收到

為了避免兩軍隊(two-army)問題,使用定時器

半開放連接(half- open)

TCP是全雙工的,連接必須是雙向的。半開半閉的連接必須殺掉

TCP 傳輸策略
發送方(Nagle』s algorithm)

接收方(Clark』s solution)

分組守恆 :當有一個老的分組離開之後才允許新的分組注入網路
TCP希望通過 動態維護窗口大小 來實現這個目標

擁塞檢測Congestiondetection 擁塞標記
所有的互聯網TCP演算法都假定 超時 由擁塞引起的 ,並且通過監視超時的情況來判斷是否出現問題

擁塞控制Congestionprevention

慢啟動演算法(Slow Start) (嘗試的過程):

如:如果試圖發送 4096 位元組沒有問題,但是發送8192位元組的時候,超時沒有收到應答,則擁塞窗口設為4096個位元組

最重要的定時器是 重傳定時器

持續定時器(persistence timer) ,用來 避免如下的死鎖 ( deadlock )發生

保活定時器(keep-alive timer)

TCP

Ⅳ 計算機網路_運輸層

在IP層看來,通信的兩端是兩個主機,IP數據報的首部明確的標志了這兩個主機的IP地址。但是兩個主機之間的通信這種說法還不夠清楚,這是因為真正進行通信的實體是在主機中的 進程 ,是兩個進程之間在交換數據。從而引出了運輸層,從運輸層的角度看來, 通信的真正端點並不是主機而是主機中的進程 (端到端的通信)。

在一個主機中經常有多個應用進程同時分別和另一個主機的多個應用進程通信。這就表明了運輸層有一個很重要的功能, 復用和分用 ,應前畝配用層不同進程的報文通過不同的埠向下交到運輸層,再往下就共用網路層提供的服務。

「運輸層提供應用進程間的邏輯通信」。「邏輯通信」的意思是:運輸層之間的通信好像是沿水平方向傳送數據。但事實上這兩個運輸層之間並沒有一條水平方向的物理連接。

TCP/IP 的運輸層有兩個不同的協議:

由此可見兩個計算機中的進程要相互通信,不僅要知道對方的IP地址,還要知道對方的埠號。

如果接收方UDP發現收到的報文中的目的埠號不正確(即不存在對應於該埠的號的應耐戚用進程),就丟棄該報文,並由網際控制報文協議ICMP發送 埠不可達 差錯報文給發送方。

在計算檢驗和時,臨時把 「偽首部」 和 UDP 用戶數據報連接在一起得到一個臨時的數據報,它不向下傳遞也不向上遞交。 偽首部僅僅是為了計算檢驗和

UDP計算檢驗和的方法和IP數據報首部檢驗和方法相類似。但不同的是,IP數據報的檢驗和 只檢驗IP數據報的首部 ,但UDP的檢驗和是 把首部和數據部分一起檢驗

計算UDP檢驗和的例子:

在發送方,先把全0放入檢驗和欄位,再把偽首部以及UDP用戶數據報看成是許多16位的字串接起來。若UDP用戶報的數據部分不是慧指偶數個位元組,則要填入一個全零位元組(先不發送)。然後按照 二進制反碼 計算出這些16位字的和。將此和的二進制反碼寫入 檢驗和欄位 後,就發送這樣的UDP數據報。在接收方,把收到的UDP數據報連通偽首部(以及可能填充全零位元組)一起,按二進制反碼求這些16位字的和。當無差錯時其結果應為全1(原本的檢驗和為0,封裝成數據報後再次相加的時候就多個檢驗和反碼相加,所以無差錯時結果為1)。

每一條TCP連接唯一地被通信兩端的兩個端點(即兩個套接字)所確定,即:

TCP發送的報文段是交給IP層傳輸的。但IP層只提供盡最大努力服務,也就是說,TCP下面的網路所提供的是不可靠傳輸,因此,TCP必須採用適當的措施才能使得兩個運輸層之間的通信變得可靠。

在這樣的理想傳輸條件下,不需要採取任何措施就能夠實現可靠傳輸。然而實際的網路都不具備以上兩個理想的條件。但我們可以使用一些可靠傳輸協議,當出現差錯時讓發送方重傳出現差錯的數據,同時在接收方來不及處理收到的數據時,及時告訴發送方適當的降低發送數據的速度,這樣一來,本來是不可靠的傳輸信道就能夠實現可靠傳輸。

停止等待協議的優點是簡單,但缺點是 信道利用率 太低。

假定AB之間有一條直通的信道來傳送分組

這里的TD是A發送分組所需要的時間(顯然TD = 分組長度 / 數據速率)再假定TA是B發送確認分組所需要的時間(A和B處理分組的時間都忽略不計)那麼A在經過TD+RTT+TA時間後才能發送下一個分組,這里的RTT是往返時間,因為只有TD是採用來傳輸有用的數據(這個數據包括了分組首部,如果可以知道傳輸更精確的數據的時間,可以計算的更精確),所有信道利用率為

為了提高傳輸效率,發送方可以不使用低效率的停止等待協議,而是採用 流水線傳輸 :就是發送方可以 連續的發送多個分組 ,不必每發完一個分組就停下來等待對方的確認。這樣可使信道上一直有數據不間斷地在傳送。顯然這種傳輸方式可以獲得很高的信道利用率

當時使用流水線傳輸時,就要使用下面介紹的 連續ARQ協議 滑動窗口協議

滑動窗口協議比較復雜,是TCP協議的精髓所在,在這里先給出ARQ協議最基本的概念,但不涉及到許多細節問題。

位於發送窗口的分組都可以連續的發送出去,而不需要等待對方的確認,發送方每收到一個確認,就把發送窗口向前滑動一個分組的位置。

詳細可以見P201

TCP雖然是面向位元組流的,但是TCP傳送的數據單元卻是報文段(可以看上述TCP面向流的概念),而且TCP的 全部功能都體現在它的首部中各個欄位

詳解請見P206,注意圖中的後沿,前沿

從下圖可以看出來,要描述一個發送窗口的狀態需要三個指針:P1,P2,P3

有很多信息見P208,這里不贅述

發送方的應用進程把位元組流寫入TCP的發送緩存,接收方的應用進程從TCP的接收緩存中讀取位元組流。下面進一步討論前面講的 窗口和緩存 的關系

發送緩存

發送窗口通常只是發送緩存的一部分,已被確認的數據應當從發送緩存中刪除,因此 發送緩存和發送窗口的後沿是重合 的。發送應用程序最後寫入發送緩存的位元組減去最後被確認的位元組,就是還保留在發送緩存中被寫入的位元組。發送應用程序必須控制寫入緩存的速率,不能太快 ,否則發送緩存就會沒有存放數據的空間。

如果收到的分組被檢測出有差錯,則要丟棄。如果接收應用程序來不及讀取收到的數據,接收緩存最終就會被填滿,使接收窗口減少到零。反之,如果接收應用程序能夠及時從接收緩存中讀取收到的數據,接收窗口就可以增大,但最大不能超過接收緩存的大小。

TCP才用了一種自適應演算法,它記錄一個報文段發出的時間,以及收到相應的確認的時間。這兩個時間之差就是報文段的往返時間RTT。

TCP 保留了 RTT 的一個 加權平均往返時間 RTTs (這又稱為平滑(smooth)的往返時間,因為是加權平均,所以是平滑的)。
第一次測量到 RTT 樣本時, RTTS 值就取為所測量到的 RTT 樣本值 。以後每測量到一個新的 RTT 樣本,就按下式重新計算一次 RTTS:

顯然,RTO 應略大於上面得出的加權平均往返時間 RTTs
RFC 2988 建議使用下式計算 RTO:

RTTD 是 RTT 的 偏差的 加權平均值,他與RTTs和新的RTT樣本之差有關。
RFC 2988 建議這樣計算 RTTD。第一次測量時,RTTD 值取為測量到的 RTT 樣本值的一半。在以後的測量中,則使用下式計算加權平均的 RTTD:

β是個小於 1 的系數,其推薦值是 1/4,即 0.25。

為了解決上面那個問題,Karn提出了一個演算法

在計算平均往返時間 RTT 時,只要**報文段重傳了,就不採用其往返時間樣本。這樣得出的加權平均平均往返時間 RTTS 和超時重傳時間 RTO 就較准確。 **

但是,這又有了新的問題、設想出現這樣的情況:報文段的時延突然增大了很多。因此在原來得出的重傳時間內,不會收到確認報文段。於是就重傳報文段。但根據Karn演算法,不考慮重傳的報文段的往返時間樣本。這樣,超時重傳時間就無法更新。

報文段每重傳一次,就把 RTO 增大一些:

系數 γ 的典型值是 2 。
當不再發生報文段的重傳時,才根據報文段的往返時延更新平均往返時延 RTT 和超時重傳時間 RTO 的數值。
實踐證明,這種策略較為合理。

接收方收到了和前面的位元組流 不連續 *的兩個位元組塊(只是未按序號,它是無差錯的)

如果這些位元組的序號都在接收窗口之內,那麼接收方就先收下這些數據,但要把這些信息准確地告訴發送方,使發送方不要再重復發送這些已收到的數據。

和前後位元組不連續的每一個位元組塊都有兩個邊界:左邊界和右邊界。圖中用四個指針標記這些邊界。第一個位元組塊的左邊界 L1 = 1501,但右邊界 R1 = 3001。左邊界指出位元組塊的第一個位元組的序號,但右邊界減 1 才是位元組塊中的最後一個序號。第二個位元組塊的左邊界 L2 = 3501,而右邊界 R2 = 4501。

詳見P211

一般說來,我們總是希望數據傳輸得更快一些。但如果發送方把數據發送得過快,
接收方就可能來不及接收,這就會造成數據的丟失。

流量控制(flow control)就是讓發送方的發送速率不要太快,既要讓接收方來得及接收,也不要使網路發生擁塞

利用 滑動窗口機制 可以很方便地在 TCP 連接上實現流量控制。

A 向 B 發送數據。在連接建立時,�B 告訴 A:「我的接收窗口 rwnd = 400(位元組)」。 看下TCP首部窗口欄位的用處

接收方的主機B一共進行了3次流量控制(藍線)

考慮一種情況,B向A發送了零窗口的報文段後不久,B的接收緩存又有了一些存儲空間。於是B向A發送了rwnd = 400的報文段,然而這個報文段在傳輸過程中丟失了。A一直等收到B發送非零窗口的通知,B也一直等A發送數據來,就形成了 死鎖 。下面的 持續計時器 就是為了打破死鎖僵局的

應用進程把數據傳送到TCP發送緩存後,剩下的發送任務就由TCP來控制了。可以用不同的機制來控制 TCP 報文段的發送時機:

至於如何控制發送的 時機 詳見P213

在某段時間,若對網路中某資源的需求超過了該資源所能提供的可用部分,網路的性能就要變壞——產生 擁塞(congestion)

出現資源擁塞的條件: 對資源需求的 總和 > 可用資源

若網路中有許多資源同時產生擁塞,網路的性能就要明顯變壞,整個網路的吞吐量將隨輸入負荷的增大而下降。

解決擁塞的要點是 平衡 ,要讓整個系統的性能想匹配(P214)。

橫坐標為 提供的負載 ,代表單位時間內輸入給網路的分組的數目(也叫作輸入負載或網路負載),縱坐標是 吞吐量 ,代表單位時間內從網路輸出的分組數目。

由於缺少緩存空間而被丟棄的分組的百分數,平均隊列長度,超時重傳的分組數,平均分組時延,分組時延的標准差等,這些指標的上升都標志著擁塞的增長。

方便起見,我們用 報文段的個數 作為窗口大小的單位

慢開始門限 ssthresh 的用法如下:

擁塞避免演算法的思路是讓擁塞窗口 cwnd 緩慢地增大,即每經過一個往返時間 RTT 就把發送方的擁塞窗口 cwnd 加 1,而不是加倍,使擁塞窗口 cwnd 按線性規律緩慢增長 ,比慢開始演算法的擁塞窗口增長速率緩慢很多。

網路出現擁塞時

當 TCP 連接進行初始化時,將擁塞窗口置為 1。圖中的窗口單位不使用位元組而使用 報文段

慢開始門限的初始值設置為 16 個報文段,即 ssthresh = 16。

發送端的發送窗口不能超過擁塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我們假定接收端窗口足夠大,因此現在發送窗口的數值等於擁塞窗口的數值。

下面的執行步驟就是按照折現上的點的順序