計算機網路和網際網路 - Transport layer
Router 沒到這一層 (只到網路層)，所以 Transport layer 被使用在 end system
Contents:
+ Principles behind transport layer services (2020.9.13)
+ What does transport service supply?
+ Attributes
+ Transport layer vs. Network layer
+ TCP (Connection-oriented transport)
+ UDP
+ Reference
Principles behind transport layer services (2020.9.13)
+ Multiplexing(往下送)/demultiplexing(往上送)
+ Reliable data transfer (在不可靠的環境下提供可靠服務)
+ Flow control (控制傳速)
+ Congestion control (TCP ability, 擁塞控制)
Multiplexing(往下送)/demultiplexing(往上送)
- Multiplexing: gathering data from multiple sockets and enveloping data with header (later used for demultiplexing)
- Demultiplexing: delivering received segments to correct socket
Header includes: source port, destination port, sequence number
Reliable data transfer (在不可靠的環境下提供可靠服務)
- Rdt 1.0: 可的傳輸+可靠的 channel (2020.10.13)
理想狀況，但現實很難達成
Co bit errors, no loss of packets
- Rdt 2.0: channel with bit errors (2020.10.15)
Checksum to detect it errors, recovery from errors
-> ACK (OK)/NAK (error) back to sender
-> sender re-transmits pkt on receipt of NAK
- Rdt 2.1: sender, handles garbled ACK/NAKs (2020.10.15)
- Rdt 3.0 ….
- finally => 活下來的其中一個 protocol -> TCP
What does transport service supply?
Send side: breaks app layer messages into segments and passes to network layer
Receive side: reassembles segments into messages and passes to app layer
Attributes
- No delay guarantee (時間不保證)
- No bandwidth guarantee (不保證用多少頻寬傳送)
- 一定送到
Transport layer vs. Network layer
Transport layer => IP address + port (將封包傳送到某台機器的某的port)
Network layer => IP address (將封包傳送到某台機器)
TCP (Connection-oriented transport)
TCP service [RFC793]
TCP segment structure
TCP seq. #s and ACKs
TCP Connection Management
TCP Congestion control
TCP service [RFC793]
- point-to-point: one sender, one receiver
- reliable: 可靠的，封包不會掉 (connection-oriented)
- in-order: 封包傳送有序
=> if loss 封包 => acknowledgements + re-transmissions
Re-transmissions are triggered by:
1. timeout events
2. duplicate ACKs
- Byte stream: 以 byte 為單位，每一組 segment 都有 sequence number (my guess, not sure)，no message boundaries
- sender & receiver buffers: 在沒收到 ACK 之前的封包通通要 buffer
- MSS: Max segment size
- flow control (流量控制): sender won’t overwhelm receiver
receiver 控制 sender 的傳速
- congestion control (壅塞控制): when network congested, senders slow down
=> TCP 判斷方式：if loss packets, congestion => slow down
- it doesn’t provide: timing (不保證何時會到), 不保證傳輸擁有最小頻寬
TCP segment structure
Sequence number
- Sequence number = application data 第一個 byte 的 Sequence number
- So next sequence number = current sequence number + data length
Acknowledgement number
ACK N = ANK N-1 以前的 byte 都收到了
Receive window
For flow control (receiver tells sender)
If == 0, 即使連線已經建好也不能傳送 data
Flag
- U (URG) = urgent data (通常不使用)
- P (PSH) = 強制 sender buffer 裡的 data 全都送到 receiver (generally not used)
- R (RST, reset) — 為1表示出現嚴重差錯，可能需要重新建立TCP連接。還可以用於拒絕連接請求。
- S (SYN) — 為1表示這個封包是要建連線的封包，用於建立連接和使順序號同步
- F (FIN, finish) — 為1表示傳送方沒有資料要傳輸了，代表連線即將結束。
TCP seq. #s and ACKs
ACK 79 (from Host A) = 希望收到 Seq 79 from Host B = Seq 78 以前的 bytes 已收到
ACK 43 (from Host B) = 希望收到 ACK 43 (?可能打錯)from Host A = Seq 42 以前的 bytes已收到
Out-of-order: 例如 Seq 70(後送) 比 Seq 53 (先送) 先到 receiver => How to handle in receiver’s buffer? “Depend on implementor”
TCP Connection Management
在送 data 之前，sender 和 receiver 要先建立連線
- Initialize TCP variables:
seq. number,buffers,flow control info
Three way handshake
Step 1: client host sends TCP SYN segment to server
=> specifies initial client seq. # (no data sent)
Step 2: server host receives SYN and replies with SYN + ACK segment
=> server allocates buffers
=> specifies initial server seq. #
Step 3: client receives SYN + ACK and replies with ACK segment which may contain data
Closing a connection (When data transmission ends)
clientSocket.close();TCP Congestion control
一開始先一直增加傳送速度，直到 loss bytes
Three mechanisms:
AIMD
Slow start
Conservation after timeout events
AIMD (additive increase, multiplicative decrease)
每一個 RTT 加一個 MSS 的大小在 Congestion Window (線性)
CongWin = Congestion Window
Slow start (但是指數加速)
傳送速度指數上升
Summary
- 當 CongWin 低於閾值 (Threshold) 時，sender 是 slow start phase
=> 速度以指數上升
- 當 CongWin 高於閾值 (Threshold) 時，sender 是 congestion-avoidance phase
=> 速度以線性上升
- 當收到 triple duplicate ACK
=> 閾值 set to CongWin/2, CongWin set to 閾值
- 當發生 timeout
=> 閾值 set to CongWin/2, CongWin set to 1 MSS
UDP
UDP service [RFC768]
UDP checksum
Socket programming with UDP
UDP service [RFC768]
- Best effort (可能會 lost packets)
- Unreliable data transfer between sending and receiving process
- Unordered
- It doesn’t provide: connection setup, reliability, flow control, congestion control, timing (不保證何時會到), 不保證傳輸擁有最小頻寬, bandwidth guarantee
- No handshaking
- 每個封包獨立傳送 (So receive out of order or lost)
- Often used for streaming multimedia apps
1. Loss tolerant -> e.p. 聽音樂掉一封包無感覺2. Rate sensitive
UDP checksum
Goal: detect errors in transmitted segment (例如1變0，0變1)
if computed checksum equals received checksum field value=> No errors detected (But not equal to no error)else=> error detected
Socket programming with UDP
- Packet based I/O
- Class (Java): DatagramSocket, DatagramPacket
Reference
[1] 黃能富教授 — 計算機網路概論
[2] 黃能富教授計算機網路概論講義 (私人連結)