# 計算機網路筆記-ch3

socket : 一種OS提供的procceses通訊機制。應用層可以透過API socket來使用網路socket，以進行資料交換。

## Transport service and protocol
Transport layer 提供了應用層裡processes在不同host中的logical communication.
Sender會將應用層的message切成一塊一塊的segments，並往網路層傳送。
Receiver則會將segment重組為message，並往應用層做傳輸。
可以把hosts比喻為一個家，而process就如同是家裡面的kids，app messages就是信封裡面的letters。
當今天小孩們(process)要互相傳遞信件給對方，小孩們會先將信封交給Ann(老大)，藉由他們將信件拿到郵局寄，郵局再將信封傳遞到另一個家庭，Bill(老大)則將信封依照姓名(prot number)發給小孩們(processes)。

### Network Layer : logical communication between <font color = red>**host**</font>
### Transport Layer : logical communication between <font color=red>**process**</font>

### TCP VS. UDP
* TCP :
1. 可靠的, 按照順序的傳輸
2. 有congestion control
3. 有flow control
4. 有連線建立
* UDP :
1. 不可靠的, 傳輸不會按照順序
2. 只要收到資料就盡全力的傳輸
* 兩個protocol皆不包含delay保證 與 頻寬保證 等等。

## Multiplexing/demultiplexing
### multiplexing at sender
multiplexing at sender :
收集多個多個socket的資料，用header(稍後將用在解多工)將每個messages片段封裝成segments。
demultiplexing at receiver :
利用header的資訊去傳遞received segment到正確的socket。

### How demultiplexing works
host receives IP datagrams，
每個datagram 都有 source IP 跟 destination IP。
每個datagram也會包含一個segment，
每個segment中都會包含一個source port number 跟 destination port number。

### host 使用 IP address & port numbers 去找到正確的socket
當我們要傳送資料時，我們會先建立一個有標明host-local port num的socket。(以port number去產生socket)
當要建立Datagram去傳進UDP socket時，必須標明IP address跟port#。
當host收到UDP segment時會透過segment裡的destination port#將segment送到指定的socket。(利用IP與prot number去識別UDP socket)
不同來源的source port numbers 或 IP addresses，只要是同一個destination IP address 與 port numbers，就都會傳遞到同一個socket。

### Connection-oriented demultiplexing
TCP socket 會有
1. source IP address
2. source port number
3. dest IP address
4. dest IP address

demux : receiver 利用以上四個元素去傳送segment到指定的socket。
當今天有很多的segment指定要到同一個dest port number，server會支援許多同時可以使用的TCP sockets。

### UDP<font color=red>在demultiplexing時只有使用destination port number(only)</font>
TCP 在demultiplexing時會用到4個元素，
而UDP就只用dest port#(header中會有src與dest的port#)。

## UDP: User Datagram Protocol
1. no frills, 沒有多餘設計的Internet transport protocol
2. best effort, 盡力的服務，但不可靠
3. 會造成封包遺失、傳遞順序不正確
4. UDP傳遞間沒有hand-shacking
5. 每個UDP segment都是獨自處理的

## 為什麼要用UDP呢
1. no connection, 可以省去建立連線時的RTT delay
2. simple, 沒有連線狀態
3. small header size
4. no cogestion control, UDP不會管接收端的接收狀況，他會一直拼命的快速傳遞，導致常常可能封包遺失，但UDP不會有congestion的問題。可以利用這點來處理congestion的問題。
## UDP的應用
1. 多媒體串流(可以容忍遺失，但對於速率有要求)
2. DNS
3. SNMP(Simple Network Management Protocol)
4. HTTP/3

### 由於下層沒有服務(如congestion control)，上層要自己加
1. add needed reliability at application layer
2. add congestion control at application layer

### UDP傳遞流程
sender actions:
1. 應用層會送message下來
2. 決定UDP segment 的 header 要放甚麼
3. 創造UDP segment
4. 將segment往網路層送

receiver actions:
1. 由網路層拿到segment
2. 進行UDP checksum
3. 取出應用層的message
4. 藉由socket將訊息解多工到應用層

### UDP 結構
### UDP checksum
目的: 為了偵測傳遞時是否有傳遞錯誤
sender會將segment(包含UDP header 跟 IP address)分成一列一列(一列16-bit)。接著會將他們全部做相加，如有overflow會再將overflow與sum做相加，最後再取1補數作為checksum。checksum value會放在UDP的header中的欄位裡。
receiver收到segment後，會先計算收到的segment的checksum，接著再看看是不是與header內的checksum相符。相符:代表應該沒有error(實際上還是有可能會有，因為加法不是一個很好的方式)，不相符:偵測到error。

## Principles of reliable data transfer
Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)。

### rdt 1.0
使用可靠通道的可靠傳輸。
1. 沒有bit error
2. 沒有資料遺失

### rdt 2.0
可能產生位元錯誤的通道。
會利用 ACKs 與 NAKs 來確定資料的傳送有無錯誤。
當收到NAKs時，會重新傳送封包。

### rdt 2.1
改善2.0致命的缺點 -- ACK/NAK 有可能會損毀(garbled、corrupted)。
改善方法:
1. 如果ACK/NAK損壞了，傳送端會重新傳送封包
2. 傳送端會在每個封包加上sequence number
3. 接受端會刪掉重複(duplicate)傳遞的封包

### rdt 2.2
與rdt2.1一樣的功能，但只使用ACK。
1. 接受端須明確地加上經過確認封包的序號
2. 傳送重複序號的ACK => NAK，會重新傳送封包

### rdt 3.0
由於底層頻道可能會遺失封包，所以利用timer來倒數計時。
1. 時間內，無收到ACK，會重傳封包
2. 忽略掉duplicate的封包或ack

使用率(utilization)極差。

### Pipelined protocols
管線化 : 可以同時傳遞多個還沒有被確認的封包。
1. range of sequence numbers must be increased
2. buffering at sender and/or receiver
3. Two generic forms of pipelined protocols: go-Back-N, selective repeat

utilization稍好一點(EX:增加3倍)。

### GO-BACK-N
Sender:
大小最多為N的window、允許連續的(consecutive)未被確認的封包。
“comulative ACK” - ACK(n) ： 確認**小於或等於**序號 n 的所有封包。
1. timer for **oldest** in-flight packet。
2. timeout(n) : retransmit **packet n and all higher seq# packets in window**。

Receiver:
1. 只使用ACK
2. 只接受in-order seq#的封包，並傳送ACK
3. 只需記住expectedseqnum

處理out-of-order的封包:
1. 刪除(不buffer)順序亂掉的封包 => receiver<font color=red>沒有暫存器</font>
2. reACK packet with highest in-order seq#(回傳最後一個確認的ack)


### Selective Repeat
1. Receiver individually acknowledges all correctly received pkts (接收端分別確認所有正確接收的封包)
2. Buffers pkts, as needed, for eventual in-order delivery to upper layer (依需要暫存封包、 最終會依序傳送到上一層)
3. Sender only resends pkts for which ACK not received
4. Sender timer for each unACKed pkt
5. Sender window傳送端視窗 :
ƒN consecutive seq #’s (N 個連續的序號)
ƒ Again limits seq #s of sent, unACKed pkts
(再次、用來限制傳送出去的、 未確認的封包序號)

## TCP(connection-oriented transport)
1. point-to-point(one sender, one receiver)
2. reliable, in-order byte stream
3. pipeline(TCP congestion and flow control set window size)
4. send & receive buffers
5. full duplex data(bi-directional data flow in same connection)
6. connection-oriented(handshacking initializes sender, receiver state before data exchange)
7. folw controlled

### TCP seq. #’s and ACKs
* sequence number of a segment is the sequence number of the first byte in the data field
* segment的sequence number是data內第一個byte的sequence number
* 另解 : 要傳出的segment's data裡第一個byte在byte stream裡的number
* ACK is the sequence number of the next byte of data that the host is waiting for
* ACK是host正在等待的下個data中第一個byte的sequence number
* 另解 : 下一個預期會從另一端收到的第一個byte的seq #

### 互相傳遞"CIA" (必考)

### TCP RTT, time out
#### how to set TCP timeout value?
* longer than RTT (but RTT varies)
* too short : premature timeout (unnecessary retransmission)
* too long : slow reaction to segment loss

#### how to estimate RTT?
* SampleRTT (測量傳遞到接收確認的時間，不包含重傳)
* 由於SampleRTT will vary， 所以需要做點平均讓他平滑


### TCP Sender

### TCP fast retransmit
當中間有封包遺失，receiver會接受到不符合預期的封包，receiver會send重複的ACK(原先預期的封包)。當sender收到3次重複的acks時，他不會等timer，還是直接重傳。

## TCP flow control
在傳輸層中有TCP socket receiver buffers，用來暫存網路層傳來的資料，與讓應用層存取並刪除資料。
但我們必須做流量控制，不然可能會因送太快，應用層來不及拿走，buffer就滿到不能再存，進而遺失資料。

透過TCP segment結構的header-receive window來告訴sender RcvWindow。
RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead]

## Congestion Control
* 太多sources同時傳遞太快且太多資料導致網路無法handle
* 會導致較長的delay或是封包遺失
* end-end congestion control
* 利用推斷loss跟delay，去得知是否擁塞
* TCP採用的方法
* Network-assitsted congestion control
* routers會直接將擁塞的資訊透過經過的封包告訴傳送端與接收端
### AIMD
* additive-increase/multiplicative-decrease
* 方法
* 將傳送速率再每個RTT都增加1個MSS(Max Segment Size)直到發生loss
* 當偵測到loss的時候
* 如果是收到到3次重複的ACK => rate/2
* 如果是因為timeout => 降成1MSS

### TCP slow start
* 連線的初期，讓rate指數性成長
* 一開始Cwnd = 1MSS
* 每個RTT都會將Cwnd*2
* 每收到1個ACK，Cwnd就會增加一個MSS，傳出兩個MSS

### TCP 的 congestion control
* ssthresh : slow start threshold 門檻值
* 當 Cwnd 低於 ssthresh，sender使用slow start，指數成長
* 當 Cwnd 高於 ssthresh，sender會進入congestion-avoidance，線性成長
* 當 偵測到loss時
* 如果是收到到3次重複的ACK => ssthresh會被設成Cwnd/2，Cwnd會設成ssthresh+3 MSS
* 如果是因為timeout => ssthresh會被設成Cwnd/2，Cwnd會降成1MSS

###### tags: `計算機網路`