傳輸層 -
目標 - 了解傳輸層服務背後的運作原則
服務 - multiplexing(多工) 與 demultiplexing(解多工) / 可靠資料傳輸 / 控制流 / 壅塞控制
TCP / UDP / TCP的壅塞控制
傳輸層服務及協定
- 在不同主機上的應用處理程予之間提供有邏輯的溝通
- 傳輸層協定是在終端機上運作
- 送端將訊息分成segments (區段)，通過網路層
- 收端將區段重組成訊息，通過應用層
- 一個應用程式會有一個以上的傳輸協定 Internet有TCP跟UDP
傳輸層與網路層
- 傳輸層是在processes之間有邏輯地溝通 (依靠並增強網路層傳輸) - 人 - segment
- 網路層是在hosts之間有邏輯地溝通 - 地點 - package
傳輸層協定
- TCP - 可靠有順序
- 壅塞控制
- 流量控制
- 先設定connection
- UDP - 不可靠，無順序地傳輸
- 沒有多餘的最有效IP
- 不可用服務
- 傳輸時間與頻寬保證
多工與解多工
- 多工 - 用於處理多個socket內的資料並加上傳輸header
- 解多工 - 用herder資訊來傳輸要被接收的區端到正確的socket
解多工的運作方式
- 主機接收每一個datagram的來源IP與目標IP
- 每個datagram都會帶一個傳輸層的segment
- 每個segment都有來源與目的端的port number
傳送時 - 先建一個socket，包含主機本地的port，當要建datagram傳到UDP socket時必定要指定目的端IP跟port。
收到時 - 當host收到UDP segment會先檢查segment內的目的port，引導UDP segment到欲傳到的port。IP datagram有相同目的port，來源的IP, port也許會不同，但最後都會送到相同的socket。
TCP ( Connection-oriented demux )
- TCP socket 會有四個確定的元件
- 來源IP, port number
- 目的IP, port number 以上組成TCP的socket
- demux : 使用以上四個值來引導segment到適當的socket
- 伺服器主機會同時提供多個TCP socket(多執行緖應用)，每個socket個自確定的四個元件
- 網路伺服器有不同socket對應到每個連接中的client
- 如間歇性的HTTP有不同的socket給每個要求
UDP (User Datagram protocol)
- 沒有多餘設計的網路傳輸協定
- 盡力的服務，不可靠
- segment會流失、傳送的順序會錯
- 收送端之間不會作handshaking這個動作
- 每個UDP segment獨自處理
UDP使用於容許掉封包的應用
- 多媒體串流
- DNS
- SNMP
若在UDP上進行可靠傳輸
- 加可靠功能於應用層，應用個別錯誤復原
UDP的segment header (32bits)
- source port & dest port
- length顯示包含header的UDP segment長度
為什麼UDP要存在
- 無連線建立(會增加延遲)
- 簡單，沒有連接狀態
- 小型header
- 無壅塞控制(要爆就給他爆，能多快就多快)
UDP checksum (檢查但不重送)
- 目的 : 為了檢測封包錯誤
- 送端
- checksum加在segment裡面，放在checksum field
- 收端
- 計算checksum，若不等於checksumfield裡面的值，則有錯，反之
可靠傳輸的原則 - 網路作業的10大重點之一，於應用、傳輸、鏈結都很重要
- UDP的通道特點將決定TCP的複雜度
- 要增加送收端的可靠傳輸協定(rdt)
- 考慮只有單一方向性的資料傳送 (實際會是雙向)
- 使用finite state machines (FMS) 來指定送收者
rdt1.0 - 通過可靠通道進行可靠傳輸
- 底層的可靠通道是完美可靠的，不會有錯誤或掉封包
- sender傳資料到底下通道，receiver讀資料從底下通道
rdt2.0 - 通道有一個位元的錯誤
- 底下通道錯掉了一個封包 (利用checksum檢查出來)
- 解決如何恢復這個錯誤
- ACKs : 接收端明確地告知送端「封包已成功送達」
- NAKs : 接收端明確地告知送端「封包有錯誤!」 ，當送端得知NAK，會重傳封包
- 錯誤偵測
- 接收端回傳msg(ACK,NAK)給送端
rdt2.1
- rdt2.0有著致命的錯誤
- ACK/NAK被破壞，送端不知道接收端發生什麼事
- 不能只做重送動作，可能造成重覆封包
- 處理重覆
- 當ACK/NAK壞掉時重送封包
- 傳送端在每個封包加序號(0,1)
- 接收端丟棄重覆封包
- 送端送一個封包，然後等待收端回應
- 送端
- 在封包上加序號
- 序號0,1就足夠了
- 必須檢查ACK跟NAK是否被破壞
- 收端
- 必須檢查封包是否重覆，依照封包序號狀態是0還1
- 收端並不曉得送端是否確實收到ACK/NAK
rdt2.2 - NAK-free protocol
- 跟rdt2.1相同的運作方式，但只有使用ACK
- 用只傳ACK的方式告知送端來取代NAK
- ACK要明確地包含序號
- 當我們送端收到相同的ACK時就等同於沒有傳成功(收到NAK)，要重送封包
rdt3.0 - 通道發生錯誤跟掉封包
- 新的假設是底下的通道會掉封包(data跟ACK都有可能)，checksum、序號、ACK不足以應付這些錯誤
- 方法 : 送端在一合理的時間內等待ACK
- 如果沒等到ACK，就重傳
- 如果其實ACK沒掉，只是delay了，雖然會造成重送，但是序號能解決此問題
- 收端必須指定ACK的序號
- 需要一個計時器
- 實際運作後，若發生delay，每次寄收都會變成2次作業，效率變差，雖然能達到可靠傳輸，但是每次只能傳一封包，造成效率變差，所以讓以下Pipelined protocols產生。
Pipelined protocols
- pipeling : 送端允許送多個、"in-flight"(還在傳)、有未傳送成功(ACK)的封包
- 封包序號要加大
- 送收雙方要有緩衝(buffering)
- utilization rate提高至三倍
- Go-back-N : 回到掉的那個封包
- 送端可回到第N個unacked(未確認收到的)封包
- 收端只回傳累積到的ack號碼，確認收到的第幾個封包正確，重傳下一個
- 送端會有timer給最舊未ack的封包，如果timer時間一到，就會重傳所有封包
- 無視重覆傳送的，又收到就丟
- 例如從pkt2一直收不到ack2，之後的3收到ack1就確認ack2掉了，重傳2pkt開始4個
- Selective Repeat
- 送端可回到第N個未確認收到的封包
- 收端會給每個封包個別的ack
- 送端替每個未收到ack的封包計時，時間一到，就重傳那些沒有收到ack的封包
- buffers是為了能夠有序地傳到下一層
- 送端只重送沒有收到ack的封包，替每個未收到ack的封包計時
- 要Window內原本預計送到的封包都確定送達，才會移至下一個Window區端傳送
TCP概述
- point to point - one sender one receiver
- 可靠且有序，不會有訊息被邊緣化
- pipe lined - TCP會做壅塞及流量控制，利用Window大小
- 全雙工資料
- 在同一條connection進行雙工資料互通
- MSS : maximum segment size
- connection-oriented
- 資料交換前會先handshaking
- flow controlled
- sender不會讓receiver超載
TCP segment structure中幾個重要元件
- ACK - 確認封包是否有正確傳送
- RST,SYN,FIN - 建立連線封包，確認是否穩定
- checksum
- source port / dest port
- sequence number / ack number (計數器)
seq.numbers - 資料流的序號
acknowledgments -對送端來說是累積的ACK數，對收端來說是想要的資料序號
- 送端送 Seq=42(給第42個檔案), ACK=79(ACK數有79個)
- 收端回 Seq=79(收到第79個檔案), ACK =43(想要第43個檔案)
- 送端送 Seq=43(給第43個檔案), ACK =80(ACK累積到80個，也代表確定收到)
- 都是屬於自己的
如何設定timeout的時間
- 比RTT長，但是RTT有變化
- 過短，造成不必要的傳輸
- 過長，對於segment的掉落反應慢
如何估計RTT
- 樣本RTT - 計算從segment送出到ACK回傳時間，不計重傳時間，再利用指數平滑法估計RTT要多長，不能只用「現在的」樣本，包含最近的RTT計算平均。
timeout interval = estimatedRTT + safety margin (4*DevRTT)
- DevRTT是估計RTT與樣本RTT的偏差值
TCP的可靠傳輸 - IPS建造了rdt在不可靠的IP(網際協定)服務上 (TCP/IP)
- pipelined segment
- cumulative acks
- single retransmission timer
重傳的原因
- 超過時間
- 重覆的ack
TCP sender 程式事件
-data rcvd from app
- 幫每個segment上序號，序號是segment中第一筆資料在byte-stream中的位置
- 如果timer沒跑，則幫忙開啟，timer是替最舊的unacked segment設的
-timeout
- timeout發生就重傳資料
- 重新計時
- ack rcvd
- 如果有unacked的segment
- 更新現在是哪個資料已被acked了
- 仍有unacked segment的話，開始計時
TCP fast retransmit
- timeout期間會相較其他來得長，若segment掉了，之後會收到重覆的ACK，所以可以利用重覆的ACK來偵測出是哪個資料掉了
- triple duplicate ACKs - 回傳3個相同的ack，就重送unacked區端中最小的那個，不用等到timeout再傳。
TCP flow control
- receiver會告訴裝segment的rwnd值(buffer剩多少空間)，避免超載
- RcvBuffer : 大小是根據socket來設，典型是4096bytes，現在很多會自動調整了
- sender會限制unacked的數量不得超過收端rwnd的值
- 將保證收端buffer不會爆
TCP Connection Management
- 在資料交換前，送/收端先進得handshake
- 允許建立連線、連線參數
- 雙向交握是否總是能在網路下運作?
- 可變動的delay
- 由於訊息流失，重傳訊息
- 訊息重新排列
- 無法看到另外一邊的狀態
- 三方交握解決了以上的問題，收到訊息才會建立連線，不會有傳送失敗的問題。
- closing a connection
- 在TCP segment上附 FIN bit = 1，client, server就會關閉連接
- 要確認對方是否收到FIN, ACK，會造成無限loop，同時的FIN交換能夠解決
- 告訴伺服器「可以準備關囉!」(FIN)，伺服器回報「我知道了」(ACK)，伺服器傳完「傳完要關了」(FIN)，告訴伺服器「我知道了」(ACK)，伺服器收到關掉，收端等segment存活時間*2，確定伺服器已關，這邊也就關掉了。
- 要由我方這邊等待伺服器傳FIN，也由我方傳ACK告知伺服器，我方稍等是否能關了。
TCP congestion control
- sender會慢慢提升傳輸率，探測可使用的頻寬大小 ，直到loss發生
- 以加法(A)的方式提升(I)，以乘法(M)方式減少(D)，當發生loss，就直接減半，因為會掉就代表buffer已滿，要直接減半才能確實恢復好的狀態。(AIMD)
- Slow Start
- 一開始只傳一個，之後沒事就翻倍成長，一開始雖然慢但後期呈指數成長
loss有兩種
- 因為timeout得知loss，嚴重性高，cwnd重設為1，用slowstart指數增加，再用AIMD增加
－當cwnd達到timeout前的1/2大小(ssthresh)，就從指數成長變成線性成長
- ssthresh是變數，會變成上次發生loss時的一半
- 因為收到三個重複的ACK得知loss，將cwnd砍到原本的一半就好
TCP是公平的
- 二台同時連接時會平均分配傳輸率
- loss時會將window減半，避免擁塞則使用加法增加
超級感謝！ XDDD
回覆刪除