[CS/네트워크] 3. Transport layer

1. Socket programming

1.1. UDP

no connection, out-of-order 전송

 

1.2. TCP

connection 기반, in-order 전송, reliable

 

1.3. Latency

 

 

2. Transport layer vs Network layer

Transport layer	Network layer
logical communication between process	logical communication between host

 

 

3. Multiplexing vs Demultiplexing

Multiplexing	Demultiplexing
여러 message를 쪼개서 하나의 segment로 제작	segment를 쪼개서 각 message를 올바른 socket으로 전달

connectionless demux on UDP -> Dest IP/Dest port #

conncetion-oriented demux on TCP -> Dest IP/Dest port #, Src IP/Src port #

 

 

4. UDP

best effort, connectionless, checksum(무결성 확인 가능, recovery 불가)

pros	simple, fast, small header, blast away(no congestion control)
cons	can be lost, out-of-order 전송

 

4.1. UDP checksum

error detection만 가능, segment data의 합을 가지고 확인

 

 

5. TCP

5.1. RDT

reliable data transfer

rdt 1.0	no error
rdt 2.0	bit error     - error detection     - feedback ACK/NAK
rdt 2.1	ACK/NAK corrupted 가능     - sequence #(0,1)로 관리
rdt 2.2	NAK-free     - ACK + sequence #
rdt 2.3	bit error, data loss     - timer 설정, 시간 대에 ACK 안오면 retransmission     - duplicated packet이나 ACK 가능

 

5.2. ARQ

automatic repeat request

 

STOP and WAIT

RTT만큼 기다리고 ACK이 오면, 다음 packet 전송

 

PIPELINED

packet들 먼저 전송, receiver에서 받으면 ACK을 전송

ACK을 마지막에 모아서 전송 = Go-Back-N

ACK을 각자 도착시 전송 = Selective Repeat

 

GO-BACK-N

receiver는 중간에 loss 발생시 마지막으로 받은 data의 seq #로 ACK을 보냄

    (ex) [1, 2, "", 4, 5] -> ACK 2

out-of-order로 와도 NAK 보냄

window로 보내는 packet seq 관리

timeout시 loss된 것부터 전부다 전송 in window

 

SELECTIVE-REPEAT

loss가 발생한 packet만 retransmission

receiver에 buffer가 있어서 out-of-order로 packet이 와도 reorder 가능

    *DILEMA - data seq #가 [01230123]일 때의 문제

      sender측의 packet 전송 loss는 문제 X -> 그냥 재전송 요청하면 됨

      receiver측의 AKC loss about 0, 1, 2

      ->  sender의 retransmission about 0, 1, 2 packet

      ->  on sender w = [012]30123

      ->  on receiver w = 012[301]23

      ->  receiver는 new data라고 인식 + ACK 0,1 + seq 3 request

일반적으로 window size < seq #/2 가 좋다.

 

5.2.1. ARQ throughput 분석

* a = 거리, P = loss나 error 확률

- a small

거리가 가까워 propagation delay가 없다. 모두 비슷한 성능을 보인다.

- a big, P small

stop and wait은 구리다. GBN과 SR은 비슷하다.

- a and P big

모두 retransmission해야 하는 GBN은 구려진다.

SR이 좋지만, 구현이 어렵고 복잡하다.

 

5.3. Flow control

receiver의 buffer가 full이면, sender에서 전송을 줄임

receiver가 sender에게 rwnd 정보를 전달하여 flow를 control

 

* congestion control과의 차이

network 내 sender와 receiver의 buffer를 보고 window size를 조절해서 해결

 

5.4. 2-way handshake

 

5.5. 3-way handshake (SYN)

 

5.6. 4-way handshake (FIN)

 

5.7. congestion control

AIMD cwnd +1씩 증가. loss 발생시 cwnd x0.5

SLOW START cwnd x2씩 증가하다, ssthresh=cwnd부터 +1씩 증가. loss 발생시 cwnd = 1

CONGESTION AVOIDANCE ssthresh=cwnd x= 0.5부터 +1씩 증가

FAST RETRANSMIT 3 duplicated ACK이 들어오면 timer와 관계없이 retransmit

FAST RECOVERY fast retransmit 수행 후, cwnd = 0인 slow start가 아니라 congestion avoidance 수행

 

TCP Tahoe - fast retransmit 시작

3 duplicated ACK & Loss

(1) timer 상관없이 retransmit

(2) slow start 재실행

 

TCP Reno - fast recovery 시작

Loss면 Slow Start를 수행

3 duplicated ACK

(1) retransmit

(2) cwnd x= 0.5

(3) wait for loss packet's ACK

(4) congestion avoidance

 

TCP new Reno

TCP Reno에서 여러 packet이 loss시 하나씩 해결하다 느려짐

손실된 packet의 모든 ACK을 확인하고 congestion avoidance로 진입

 

Congestion Control Mecahnism

 

 

5.9. TCP fairness

bandwidth R이면 모든 node에 R/N 할당해주기

*UDP의 문제

TCP/UDP가 path를 공유할 경우, congestion이 발생하면, TCP 사용량만 감소

*Parallel TCP connection 문제

특정 App은 TCP를 여러개 열어둘 수 있음. router 입장에서는 fair하지만, App 입장에서는 아님

 

 

5.10. congestion detection

ECN bit in segment 사용.

router에서 congestion이 발생하면 ECN=1로 설정

receiver가 ECN=1이면 sender에게 congestion 발생을 전달함.