[計網]傳送層

Tue, 2019 Nov 12

3.1

章節

Multiplexing, demuliplexing
Reliable data transfer
Flow control (發送端可以解決)
Congestion control (網路中途，透過預測的方式)

探討

如何辨識目的地

Network layer: host
Transport layer: process

TCP

congestion control
Flow control
connection setup

UDP

unordered delivery
best-effort (速度不受到影響，盡可能送出封包

非transport layer所處理的

Delay guarantee

3.2 Multiplexing , Demutiplxing

Multiplexing與Demutiplxing

透過IP, port辨識目的地，UDP，只需要ip與port即可發送訊息，保存在transport layer的header

TCP

connection oriented demux有四個欄位，多出source IP, dest. IP用於辨識來源host

source IP
source port
dest. IP
dest. Port

Welcome socket, 可以透過同一個process處理Port監聽

3.3 UDP

Bare Bones，捨棄無法接受的封包，不做handshaking，因此速度快，可容忍資料遺失應用適合，檢查資料錯誤（checksum）, length

使用udp到協定

DNS（要求速度）
SNMP
可容忍資料遺失應用程式

3.3.2 Checksum

16 bit，將資料分成多份16bit之後相加，溢位後加到最小位bit上。

example，傳輸資料為

1011 0100 1010 1111 1001 0000 1010 0000

step 1

將資料以多個16 bit 分組，之後相加如下。

   1011 0100 1010 1111
   1001 0000 1010 0000
=========================
 1 0100 0101 0100 1111

可以發現結果多出一個bit，將它加到最小位得到

 0100 0101 0101 0000

step 2

將總和取一補數，得出checksum

~(0100 0101 0101 0000)
=======================
  1011 1010 1010 1111

setp 3 驗證

checksum與數值相加應該全部都是1才算正確，以下示範驗證。

 0100 0101 0101 0000
 1011 1010 1010 1111
=====================
 1111 1111 1111 1111

可以看到得出的結果全部都是1

不過Checksum依然有缺陷，如果任意兩個不同的bit在不同的16 bit word中反轉， 1011 0100 1010 1110與1001 0000 1010 0001(顛倒了最小位)的總和與原本正確的相同，這時就會被當成正確的傳輸。

3.4 Reliable Data Transfer

下層沒有可靠的機制，設計機制讓資料可以可靠傳輸。接收端檢查，若錯誤則重新傳送。採用FSM

不可靠的原因

Bit error（介質受到干擾，使高低位元滑動）
Loss of Packet（大多可能因為queue滿而遺失）

假設傳送不會發生錯誤與遺失

如果

接受到往app layer送
送出時往下層送

Rdt2 sender

ACKs:對
NAks:錯

產生封包送封包
等nak,ack 決定要不要重送
收到ack回到原始狀態

Rdt2 receiver

如果正確會傳ack
否則回傳nak

Rdt2依然不一定穩定，如ack,nak不一定正確

Rdt2.1 sender

ACK,NAK也可能出現問題，以及重複封包序列。加入錯誤檢查碼，並且回傳ack或nak。

如果ack封包錯誤則當成nak處理，不過需要透過編號判斷封包是否正確， stop and wait，確定封包正確再切換編號，處理兩個編號的手法相同， receiver ack與nak要加上checksum

corrupt()錯誤封包

Rdt2.2

只發送ack，並且nak改成不正確序號的ack，之後接收者只需根據正不正確決定序號

Rdt3.0

考慮遺失資料，超時，可以透過發送端決定超時，為了避免重複接收使用序號，如果封包出錯則等到timeout,而timeout都會重新發送封包，收到時將計時器停下，接收端不需要修改。

尚未接收到封包無法得知封包是否丟失，透過超時計時器處理，不過可能因此重送，透過序號判斷是否為當前傳送的Data。

不過性能不佳，採用pipelining可能缺少足夠的編號，並且需要buffer,

處理相關問題的演算法

go-back-n: 不需buffer但需要重送ack非依序收到的部分
select repeat: 需要buffer只需要重送錯誤的訊息

3.4.3 go-back-n

不需要buffer, cumulative ACKs回傳最大收到編號

3.4.4 SR (Select Repeat)

接受者與發送者都有base index，設封包發送數量為N

最差的情況可能發送者的base為0，但接收者為N

3.5 TCP

In-order, pipelining

Flow control透過window size調整， Receive windows

congestion control: 擁塞控制可以限制TCP發送速度

3.6. congestion control

Congestion產生原因

可能導致

丟失，因為 queue
長延遲

只考慮網路問題

無限queue，不會發生重傳

考慮有限

重傳時可以預測一定有queue位置，都是packet lost才重送的話，可以使接收速率為R/2

交叉

3.7 congestion control

進入

緩慢增加速度（線性）AIMD，直到壅塞之後減半速度，再次嘗試加速壅塞=》透過 window size進行處理，除2
Slow start: 每次乘2成，如果壅塞嚴重則退回1 MSS

TCP

嚴重 slow
普通壅塞 AIMD

透過擁塞時，除2產生的值作為ssthresh，並且AIMD

註解：

duplicate ack不大嚴重因為packet依然可以傳送，雖然可能丟失部分封包
timeout 代表嚴重無法成功送到，使任何ack都無法收到

TCP Rene

TCP Tahoe

補充：Duplicate ack實際上可能是底下routing路徑修改

3.7.1 網路公平性

有效的網路條件

一個使用者完全使用頻寬
多個使用者平分

使用者加入：趨近公平的速度

TCP不公平

多個TCP連線在同主機，可能佔用多個頻寬
網路上可能有UDP封包，而TCP被降速

Network