# Chapter 3 Transport Layer
### 3.1 transport-layer services
+ Transport services and protocols
+ reliable, in-order delivery (TCP)
+ congestion control
+ flow control
+ connection setup
+ unreliable, unordered delivery: UDP
+ no-frills extension of “best-effort”IP
+ services not available:
+ delay guarantees
+ bandwidth guarantees
---
### 3.2 multiplexing and demultiplexing
+ Multiplexing/demultiplexing
+ 
+ How demultiplexing works
+ host uses IP addresses & port numbersto direct segment to appropriate socket
+ 
+ Connectionless demultiplexing UDP
+ 
+ **同一DST的東西都會被送到同一個SOCKET**
+ 
+ Connection-oriented demux TCP
+ TCP socket identified by 4-tuple:
+ source IP address
+ source port number
+ dest IP address
+ dest port number
+ **demux: receiver uses all four values to direct segment to appropriate socket**
+ server host may support many simultaneous TCP sockets:
+ each socket identified by its own 4-tuple
+ web servers have different sockets for each connecting client
+ non-persistent HTTP will have different socket for each request
+ 
+ DEMULTIPLEX IN CONCLUDE
+ ==In TCP, the receiver host uses all of source IP, source port, destination IP and destination port to direct datagram to appropriate socket. While in UDP, the receiver only checks destination port number to direct the datagram.==

:::info
Threaded server:
A threaded web server is one that handles each request with a new thread, as opposed to handling each request with a new process.
Multi-threading
pros: consume less memory and are generally faster.
cons: web server crashing if one of its modules isn't working correctly. Also, if it does crash, it's more likely to crash all of the threads (ie. all of the requests being handled at the time)
:::
---
### 3.3 connectionless transport: UDP
+ UDP: User Datagram Protocol [RFC 768]
+ “best effort”service, UDP segments may be:
+ lost
+ delivered out-of-order to app
+ connectionless:
+ each UDP segment handled independently of others
+ no handshaking between UDP sender, receiver
+ UDP use:
+ streaming multimedia apps (loss tolerant, rate sensitive)
+ DNS
+ SNMP
+ reliable transfer over UDP:
+ add reliability at application layer
+ application-specific error recovery
+ **why is there a UDP?**
+ no connection establishment (which can add delay)
+ simple: no connection state at sender, receiver
+ small header size
+ no congestion control: UDP can blast away as fast as desired
+ UDP checksum
+ detect “errors”(e.g., flipped bits) in transmitted segment
+ sender:
+ treat segment contents, including header fields, as sequence of 16-bit integers
+ checksum: addition (one’s complement sum) of segment contents
+ sender puts checksum value into UDP checksum field
+ receiver:
+ compute checksum of received segment
+ check if computed checksum equals checksum field value:
+ NO -error detected
+ YES -no error detected. But maybe errors nonetheless?More later
+ 
+ when adding numbers, a carryout from the most significant bit needs to be added to the result

---
### 3.4 principles of reliable data transfer

+ Principles of reliable data transfer
+ 
+ characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)
+ 
+ **rdt1.0**: reliable transfer over a reliable channel
+ 完全不考慮underlying channel有出錯的可能
+ underlying channel perfectly reliable
+ no bit errors
+ no loss of packets
+ bit 不會出錯封包不會掉順序不會亂
+ separate FSMs for sender, receiver:
+ sender sends data into underlying channel
+ receiver reads data from underlying channel
+ 
:::info
+ underlying channel may flip bits in packet
+ checksum to detect bit errors
+ how to recover from errors:
+ acknowledgements (ACKs):receiver explicitly tells sender that pkt received OK
+ negative acknowledgements (NAKs):receiver explicitly tells sender that pkt had errors
+ sender retransmits pkt on receipt of NAK
:::
+ **rdt2.0+**: channel with bit errors
+ error detection
+ feedback: control msgs (ACK,NAK) from receiver to sender
+ 收到ACK後才能回到狀態一繼續等待傳送,若是NAK也不用回到wait的狀態,就直接重新再傳送一遍

+ 
+ rdt2.1: receiver, handles garbled ACK/NAKs
+ handling duplicates:
+ sender retransmits current pkt if ACK/NAK corrupted
+ sender adds sequence numberto each pkt

+ receiver discards (doesn’t deliver up) duplicate pkt
+ 影響
+ file可能會亂掉transection交易可能被誤判為兩次
+ 所以要讓sender自己去會分辨有沒有收到duplicate packet

+ stop and wait
+ sender sends one packet,then waits for receiver response
+ tcp 跟 udp的不同
+ 最簡單最容易做但是效果也是最糟糕
+ 有一種可能是等待packet 0卻收到packet 1,這代表前一個packet很可能漏掉了這時就回傳一個ACK請sender重送上一個packet

+ 
+ 
+ note:
+ receiver can not know if its last ACK/NAK received OK at sender
+ sender twice as many states
state must “remember”whether “expected”pkt should have seq # of 0 or 1
+ rdt2.2: a NAK-free protocol
+ instead of NAK, receiver sends ACK for last pkt received OK
+ duplicate ACK at sender results in same action as NAK: retransmit current pkt
+ 
+ rdt3.0: channels with errors andloss
+ sender waits “reasonable”amount of time for ACK
+ retransmits if no ACK received in this time
+ if pkt (or ACK) just delayed (not lost):
+ retransmission will be duplicate, but seq. #’s already handles this
+ receiver must specify seq # of pkt being ACKed
+ requires countdown timer
+ 
+ 
+ 

+ stop-and-wait operation
+ 
+ 
+ + 
:::info
+ rdt3.0不能用pipel line
+ 八八八八送他序號是010101他不知道是哪個，所以sequent number最好永遠不要wrap around，才可以精準地告訴她是哪一個，要大於rtt裡inflight 的個數，而010101只適用於stop and wait
:::
+ Pipelined protocols
+ pipelining:sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts
+ range of sequence numbers must be increased
+ buffering at sender and/or receiver
+ 
+ increased utilization
+ 
+ two generic forms of pipelined protocols
+ go-Back-N
+ sender can have up to N unacked packets in pipeline
+ receiver only sends cumulative ack
+ doesn’t ack packet if there’s a gap
+ sender has timer for oldest unacked packet
+ when timer expires, retransmit all unacked packets
+ 重送之前已經送出去但還沒有被ack的封包
+ 但是很浪費因為有可能只有一個沒送到 所謂的洞
+ 收到資料不需要每個packet都回應ACK,因為pipelining是一次傳送一大堆的資料,那receiver再一次回應一大堆ACK其實是沒有必要的,假設收到12345就傳最大的5回去就好如果某個sequence number一直沒收到就在number之後的資料全都重送
+ 
+ sender extended FSM
+ 
+ receiver extended FSM
+ 
+ ACK-only: always send ACK for correctly-received pkt with highest in-orderseq #
+ may generate duplicate ACKs
+ 中間有送失敗其他的傳過來還是一直回送一樣的ack
+ need only remember expectedseqnum
+ out-of-order pkt:
+ discard (don’t buffer): no receiver buffering!
+ re-ACK pkt with highest in-order seq #
+ 

+ selective repeat
+ SR 的傳送端、接收端雙方的 window \`位置\` 各自不同。
+ SR 窗格大小必須等於有限序號大小的一半。
+ 

+ sender can have up to N unack’ed packets in pipeline
+ sender window
+ N consecutive seq #’s
+ limits seq #s of sent, unACKed pkts
+ rcvr sends individual ackfor each packet
+ buffers pkts, as needed, for eventual in-order delivery to upper layer
+ sender maintains timer for each unacked packet
+ when timer expires, retransmit only that unacked packet
+ 

+ 
+ 
+

:::info
+ rdt補充
+ 為何需要:
+ 有一個送出端有一個接收端,送出端裡面有一個sending process,有一個receiver process,在application layer看起來data傳出去到下面一個reliable channel,如果channel是可靠的,那麼application接收到的自然也是reliable,如此的話當然就不用管什麼rdt了但實際上的網際網路下面都是unreliable channel,其中出問題的原因非常多可能太多人一起使用,軟體設計,硬體問題等各種原因,一定會有問題存在rdt就是要研究中間要怎麼送才能做到reliable的傳輸,就是下面雖然不可靠但要讓上層覺得是可靠的至於中間不可靠的原因就要想辦法處理掉
+ rdt1.0
+ 1.0是最簡單的想法,假設沒有bit errors,也不會有packet loss,以Finite State Machine(FSM)來看sender和receiver都只有一個狀態
+ rdt2.0
+ 可能會有bit error,就是0變成1,1變成0,可以用checksum來偵察bit error,除了檢查是否有error外還需要有回應的機制ACK(acknowledgement),回應有收到或沒收到NAK(negative acknowledgement),有收到,但是有錯誤 → 重送
+ 有個問題就是但不可靠的channel也可能會使NAK和ACK訊號出現錯誤,sender會不清楚是否該重送,如果上次傳送沒問題sender卻重送一次將產生duplicate,就是同樣的檔案有兩個,所以必須加上sequence number在每個packet上避免混淆,receiver才知道丟掉重覆的檔案
+ rdt2.1
+ 為了解決2.0隱藏的問題,2.1的sender有四個狀態,packet除了data和checksum外還加入了sequence number也就是所謂的序號,sequence number當然不可能無限制的加大下去,通常有個範圍過了後就從頭計算3.0前sequence number用0和1來解釋,packet可分成兩種,一個是加上sequence number 0的packet,另一個就是1，rceiver分成等待 sequence 1 的packet和 sequence 0 的packet
+ rdt2.2
+ 其實NAK是可以拿掉不用的,一個ACK就夠了,receiver收到OK才回覆,不OK就不用回覆了直接由sender用其他機制自己決定，先前的ACK都沒有加上編號,**收到同編號的ACK視同NAK**，sender一樣在傳送完packet 0 後等待ACK 0,如果收到ACK 1就再重送packet 0,等到ACK 0 確認傳送OK後就進入傳送packet 1的狀態。receiver這邊同理在等待0的時候如果收到packet 1,代表先前收到packet 1時回傳的ACK 1 sender可能沒收到,就再回傳一次ACK 1,sender就會送下一個packet 0過來
+ rdt3.0
+ 之前考慮的都是data error的狀況,3.0替不穩定的channel多考慮了loss的可能性解決的辦法就是加入一段限制時間,假設超過時間還沒收到就是傳送時漏掉了而這段時間多少才算合理也是一門學問,如果時間設太短,或是data 只是 delay長了點並沒有loss,就會造成資料的重覆,回傳的ACK也有一樣的問題,所以兩邊都要有sequence number3.0的sender多了一個timer的設計,一送出去就開始計時,時間內收到ACK的處理都和2.2相同,restart timer開始傳送下一個data或是重新傳送,如果時間內沒收到ACK則視同ACK錯誤,restart timer然後重新傳送
+ sender絕大部份的時間都在等待問題出在rdt3.0 protocol是stop and wait,即送出去後要等待對方的回應才能進行下一步動作這個例子可以看出來protocol設計的不好,不管資源多好都會被浪費掉要有效率一定要做到pipelining,尤其是長距離的傳送越顯重要rdt3.0前最重要的問題是因為網路的不穩造成資料的error,用pipelining雖然效率提升,但也必須要有自己一套機制來解決問題

---
### 3.5 connection-oriented transport: TCP
---
### 3.6 principles of congestion control
---
### 3.7 TCP congestion control
###### tags: `network`