傳輸層提供的服務

• 地位
  

• 概述

進程 端口號 傳輸層協議之間的關系

socket套接字

• 解決了每次傳輸 需要重復輸入協議（TCP/UDP）以及對方的IP地址和端口號的問題 它的本質是一種數據結構
• 例如進程1與進程5之間需要傳輸數據 因為他們都是使用的TCP協議 所以就會創建一個TCP套接字
• 在這個套接字里面需要指明對方的IP地址和端口號
• 接下來如果兩個進程之間需要有多次的數據傳輸 就可以直接用套接字來說明傳輸方向

有鏈接 VS 無連接 | 可靠 VS 不可靠

• 在下面兩張圖中 左邊指的是TCP 右邊指的是UDP
  

UDP數據報及檢驗

• UDP
  
• TCP
  

數據報格式

檢驗方法

• 對于一組數據
  
• 對于多組數據
  
• 說明
  
• 小節
  

TCP

TCP協議的三大階段

• 一次鏈接可以傳輸多個報文
  

• 這里引入了換一個概念就是MSS 表示我們傳輸時報文段的最大長度

• 這里重點說一下這句話“TCP是面向字節流的 UDP是面向報文的”

• 怎么樣來理解呢

• 對于TCP協議而言 它將應用層交給他的數據看作是一連串的字節流 不管關心數據到底是報文Y的還是報文Z的 只是根據MSS的限制將它拆分成合適的大小進行傳輸

• 跟前面UDP不同的是 UDP數據報每次運輸的都是一個完整的報文

• 這便是 面向字節流和面向報文的含義

TCP報文段格式（很重要）

建立連接（三次握手）（超級超級重要）

• 因為我們的TCP協議是在建立連接的基礎之上的 所以我們在傳輸數據之前必須有一個建立連接的過程
• 在前面的學習中我們知道當SYN=1的時候 表示這是一個連接請求或者接受報文 對應到下圖中顯然只有握手1是在請求連接 只有握手2是在同意請求連接
• 則顯然只有握手1和握手2的SYN=1
• seq表示傳輸的數據的起始位置 ack=667 說明的是我（接收方）希望你下一次給我發送的數據是從667開始的
• 這里還需要提一下窗口值的概念
• 例如A發送給B的時候設置window=200 ack=100意思是告訴B 你下一次給我發送數據的時候要從100這個位置開始 并且的接收能力是200 換句話說 從100開始 我（A）還允許你給我發200B的數據
  
• 特別要注意的是 對于握手2 他雖然表示的同意連接 也就是他的TCP報文段只由首部構成 并沒有任何的數據部分 但是他仍然需要消耗一個序號 即他返回的ack需要在seq（起始位置）的基礎上+1
• 為什么說需要特別注意呢 因為握手3可以選擇要不要攜帶數據 他在不帶數據的情況下跟握手2不同的是 他并不需要消耗一個序號
  
• 三次握手的狀態變化

數據傳輸

釋放連接（四次揮手）

• 在前面我們學習了FIN=1表示發送方的數據已經全部發送完畢
• 但是我們的TCP是提供全雙工通信的 也就是雙向的 這是一個傳輸層的協議
• 不同于我們數據鏈路層實現流量控制與可靠傳輸時候學習的S-W，GBN，SR等協議 他們都是有明確的發送方和接受方的 也就說明他們是工作在半雙工條件下的協議
• 在四次揮手中只有揮手1（表示客戶傳輸完畢）和揮手3（表示服務器傳輸完畢）表示數據傳輸完畢 也就是說他們是都可以作為發送方的
• 揮手2和揮手4是我們各自作為接收方告訴對面數據已經被接收 而這恰恰又體現了TCP是一種可靠 有連接的傳輸服務
• 特別需要說明的是揮手1和揮手3可以攜帶數據 但是他們一般不攜帶數據
• 而揮手2是可以攜帶數據的 因為揮手1僅僅是進程A單方面結束了數據傳送
• 揮手4是不可以攜帶數據的 因為揮手3之后已經代表數據傳送結束了
  #### 四次揮手的狀態變化
• 對于TIME-WAIT這個狀態是用于我們防止我們的服務器沒有接收到揮手4 假如真的傳輸失敗了
• 那么這個時間段的等待就是非常有必要的 因為對于我們的服務器而言 他長時間沒有收到我們A給他發送的揮手4
• 他就會重新發送揮手3 這樣我們的進程A就會收到 然后重新發送揮手4
• 如果這一段時間什么也沒有收到 那么我們的客戶進程就默認對面已經收到了我們發出的揮手4

TCP連接管理小節

TCP流量控制和可靠傳輸

• 首先TCP是一個傳輸層概念 他實現流量控制和可靠傳輸的方式和我們數據鏈路層是非常類似的
• 可靠傳輸方面 它跟我們數據鏈路層一樣 用到這個確認機制 不過來這里我們這個是對于報文段的一個確認 可以接受一個報文段就返回一個ACK
• 在重傳機制方面 也是非常類似 就是只要在規定時間之內沒有收到接受方返回的ACK那么就需要重發
• 舉個例子 對于四次揮手 我們的發送方是在最后需要CLOSE階段之前 也就是我們發送方收到揮手3之后設置一個TIME-WAIT階段
• 這個階段的時長是2倍MSl 表示我們報文段在網絡中存在的最大壽命 設置的本質原因就是 我們的需要發送方他需要確保服務器收到了我們的請求關閉數據傳送的信息 也就是我們需要收到揮手4才能進入CLOSE階段
• 假設我們服務器返回的這個ACK丟失了 那么在過了一段時間時候 客戶端進程就會重新發送 直到順利接收服務器返回的ACK
• 在流量控制方面 也是類似 引入滑動窗口機制 這個時候接收方和發送方都會維持一個窗口 根據傳輸過程中發送的 rwnd的值來告訴對方 從某個序號開始 我最多還能接受多少數據
  

可靠傳輸-擁塞控制

TCP 擁塞控制和流量控制的關系

• 之前學習的流量控制的對象是兩個進程各自的某個端口 也就是局部的控制
• 擁塞控制實現的是控制整個網絡的數據發送量 是全局的
  

慢開始 與擁塞控制算法

• 首先我們在建立TCP連接之后 就會默認使用慢開始算法 也就是說一開始的發送窗口的值為1 之后每隔一個RTT（往返時延）我們的發送窗口就會翻倍 也就是x2按指數級增長 直到達到閾值（ssthresh）
• 這里唯一需要注意的一點是 如果在閾值前一個RTT 照理來說他是需要翻倍的 但是如果發送窗口此時翻倍之后 超過了這個閾值 那么取其中的較小值作為發送窗口的大小 也就是min{閾值 cwnd}
• 之后的時間內 會自動轉為擁塞避免算法 就好比之前我們剛剛開始運動 每天的運動量都翻倍 但是隨著運動量越來越大 我們肯定需要降低他的增長速度 也就對應了這里的擁塞避免算法 使得增長速度降為線性
• 通過之前的學習我們知道一旦出現了超時重傳 可能說明我們網絡當中某些路由器的負載太大了 以至于不能及時返回確認信息 所以此時認為嚴重擁塞 那么此時會干兩件事情
• 1. 在這個RTT結束之后我們檢測到擁塞 立即將cwnd（擁塞窗口）設置為1
• 2.閾值設置為原來的一半 本質上就是降低數據的發送量
• 之后延續之前的流程 一開始還是使用慢開始 到達閾值之后使用擁塞避免算法
  
• 例題
• 對于在解決這道例題之前 我們需要明確的是 之前在擁塞控制那里玩嗎討論的前提是接收窗口足夠大 導致玩嗎每次調整發送窗口大小完全是依據擁塞窗口來調整的
• 但實際情況是 發送窗口=min{rwnd,cwnd}
• 此外還需要注意的是一般來說都會設置MSS=1KB這個條件 也就是說 我們閾值和發送/接收緩沖區的大小就是他們的值除以1KB
• 好那知道這些之后我們再去看這道例題

• 首先 我們的閾值是32 乙的接收窗口rwnd大小是16 說了乙是將數據全部存入緩存 不被取走 也就說說暫時還不交付給應用層
• 其次基本思路就是我們甲他的發送窗口不能大于乙的接收窗口rwnd 同時不能大于他的擁塞窗口
• 0時刻 閾值S=32 r=16 c=1 發送窗口：1
• 1時刻 S=32 r=15 c=2 發送窗口：2
• 2時刻。 S=32 r=13 c=4 發送窗口：4
• 3時刻。 S=32 r=9 c=8 發送窗口：8
• 4時刻。 S=32. r=1 c=16 發送窗口：1

結語

今天翻草稿箱的時候 居然還有以前寫的文章沒發出去哈哈 還有好幾篇等我稍微完善一下再發出去
該說不說 現在感覺ipad寫還行啊 感覺CSDN優化了～