3장 - Transport layer

flow control : rcv가 감당하지 못할 정도로 x

congestion control : network가 감당하지 못할 정도로 x

 

Transport layer

process간 logical 통신 제공

send side : message를 segment로 쪼갬

rcv side : segment를 message로 다시 합침

 * network layer는 host간 logical 통신 제공

 

가정에 비유

hosts = house

process = kid

app message : letters

transport protocol : demux to kids

 

TCP : reliable, in-order(byte stream을 순서대로 붙임)

UDP : best effort : 최선을 다하지만 보장은 못함

 

 

Multiplexing / demultiplexing

sender에서 mux(transport header붙이고 나중에 demux에서 사용)일어나고 rcv에서 demux(port 번호를 보고 맞는 socket으로 보냄)일어남

 

Demux 과정

host는 ip datagram을 수신한다

각 datagram에는 src ip주소와, dst ip 주소가 존재하고 transport layer segment가 존재한다.

각 segment에는 src, dst 포트 번호가 존재한다

host는 ip 주소와 port 번호를 이용하여 적절한 socket으로 보낸다.

 

 

Connectionless demux(UDP)

UDP 소켓은 dst ip주소, dst port number로 구성된 두 요소에 의해서만 식별가능 -> 출발지 ip주소와 포트번호가 모두 달라도 같은 dst ip주소, dst port number를 가진다면 같은 소켓으로 향함.

 

같은 socket으로 감

 

Connection-oriented demux(TCP)

src ip 주소, scr port number

dst ip주소, dst port number

총 4개로 식별

 

서버는 여러개 TCP 소켓을 open

 

 

 

UDP

best effort -> loss, out of order가능

각 udp segment는 독립적임

 * TCP는 byte stream 형태이기 때문에 segment에 sequence number가 붙음

 

UDP use

streaming multimedia(loss tolerant, rate sensitive)

DNS

SNMP

 

Why UDP?

연결설정없음 : delay없음

연결 상태가 없음 : 어떤 것도 기록하지않기 때문에 좀더 많은 클라이언트를 수용 가능

작은 패킷 헤더 오버헤드

congestion control이 없음 -> TCP는 congestion control을 하기 때문에 수신 여부를 확인응답할 때까지 데이터의 세그먼트 재전송을 계속한다 -> 실시간 스트리밍 같은 app에서 지연시간이 너무 길어짐.

 

UDP 트래픽은 조절되지 않는다. -> 허용이 되는 한 어떤 속도로도 전송가능

 

UDP checksum

오류 검출

16bit단위로 더하고 1의 보수를 취함

수신자에서 계산했을때 하나라도 0이 나오지 않는다면 오류 발생

 

*왜 UDP가 체크섬을 제공할까?

출발지와 목적지 사이 링크 중에서 하나가 오류 검사를 제공하지 않는 프로토콜을 사용할 수도 있기 때문이다.

 

UDP header : 8byte

TCP : 20byte

멀티미디어 애플리케이션을 UDP위에서 동작시키는 것이 일반적이지만 논의의 여지가 있음

-> UDP는 혼잡제어를 하지 않음 -> 만약 모두가 혼잡제어를 하지 않고 높은 비트의 비디오 스트리밍을 하게 된다면 소수의 UDP 패킷만이 무사히 통과가능

 

UDP header  8byte

 

포트번호는 정확한 프로세스에게 넘기게 해줌

출발지 포트번호	목적지 포트번호
길이	체크섬

Reliable data transfer

application, transport, link layer에서 중요함

* 매 홉마다 error 확인하고 다시 전송하면 되는데 왜 transport layer에서 또 할까?

queue에 다 찰 수 있기 때문이다.

 

 

단방향 데이터 전송에서도 양방향으로 패킷을 전달해야함 -> 제어 패킷을 전송

 

Finite State Machine(FSM)

FSM 개요

ARQ : Automatic Repeat reQuest

 

rdt1.0 

그냥 보내면 됨

 

rdt2.0 : 비트 에러 발생 가능 가정

1. 재전송을 통해 회복함

2. 오류검출

3. feedback

ACK : 패킷을 잘 받았다고 전달

NACK : 패킷에 에러가 있다고 전달 -> NAK수신되면 마지막 패킷 재전송

 

rdt 2.0

sender의 'wait for ACK or NAK' state에서 isNAK이면 재전송

rcv에서는 corrupt이면 NAK 전송

 

문제점

ACK/NAK에 에러가 생긴다면?

해결

1. ack/nak을 재전송

- 계속 오류생겨서 계속 재전송할 수도 있음 

2. sequence number 추가

3. rcv는 중복 패킷받으면 버림

 

stop and wait : sender가 하나를 보내고 rcv의 응답을 기다림

 

sender FSM

receiver FSM

만약 순서가 바뀐 패킷이 수신되면, 수신자는 이미 전에 수신한 패킷에 대한 ACK를 전송

만약 손상된 패킷이 수신되면 NAK 송신 -> 송신자는 ACK를 두번 수신하면 수신자가 두번 ACK한 패킷의 다음 패킷을 정확하게 수신하지 못했다는 것을 안다.

 

 

 

rdt 2.2

NAK 안보냄 -> 가장 최근에 제대로 받은 pkt의 ACK만 보냄

 

rcv에서 0을 기다리는데 1이오면 ACK1이 잘 안받아진것임

 

rdt3.0

pkt loss가 일어나면 무한정 기다리게됨 -> timer 필요함

loss안 일어났는데 delay pkt(ACK)가능

손상된 pkt와도 아무일 안해도됨 -> timer가 언젠간 끝남

 

pipelined protocol : 앞의 task가 끝나기 전에 밀어 넣음 

Go-Back-N, selective repeat

cumulative ack : 어디까진 잘 받았다~

 

Go-Back-N

가장 오래되고 unack 상태인 pkt에만 timer 설정

timeout 되면 다시 다보냄

 

1번 받고 2번을 기다리는데 3번이 오면 1번 ACK을 보냄 (가장 최근 ack보내기)

순서가 다른 pkt은 버림(구현에 따라 다름)

 

timeout되면 손상안되거나 분실 안되도 모두 재전송함 -> Selectice repeat등장

 

Selective repeat

https://hwanine.github.io/network/SelectiveRepeat/

네트워크 - Selective Repeat의 동작과 마주하는 딜레마와 극복

ACK못받은거만 재전송

 

 

 

rcv_base보다 작은 ACK을 받음 -> ACK loss 발생-> ACK 재전송

아무리 앞 것을 받아도 rcv_base-N까지임 -> rcv_base까지 왔다는 것은 적어도 sender가 rcv_base-1까진 보냈다는 것

즉 sender도 rcv_base-N-1까지는 잘 받음

https://hwanine.github.io/network/SelectiveRepeat/

SR의 딜레마

sender side를 못봄

재전송인지 새거인지 모름

2*window_size <= Seqence number space

 

 

TCP

p2p

byte stream

pipeline

full duplex(양방향 통신)

cumulative ack(만약 2면 1까진 잘받음)

sequence number : first bte in segment's data

ack num : 만약 8이면 7까진 잘받았고 8번을 기다린다는 뜻

 

tcp의 순서번호는 0부터 시작안함

https://www.quora.com/In-TCP-connection-the-initial-sequence-number-is-not-0-zero-Why

In TCP connection, the initial sequence number is not '0' (zero). Why?

 

 

tcp는 기본적으로 piggybacking(ack과 data를 한번에 보냄)

 

 

그렇다면 timeout value를 어떻게 설정할까

longer that RTT

너무 짧으면 필요없는 재전송이 일어남

너무 길면 너무 느려짐

EstimatedRTT = (1-a)*EstimatedRTT(과거 측정값) + a*sampleRTT(현재)

a=1이면 현재가 중요하다는 뜻

(1-a)^(k-1) RTT -> 지수적으로 영향감소

exponential weighted moving average(ewma)

여기에 safety margin을 더함

 

DevRTT = (1-B)*DevRTT + B* | sampleRTT(확률 변수) - EstimatedRTT(평균) |

뒤의 항 : sampleRTT가 평균값에 대해 얼마나 변하는지 측정

 

TimeoutInterval = EstimatedRTT + 4*DevRTT

 

 

TCP rdt

단일 재전송 타이머 사용

 

재전송은 timeout 과 duplicate ack으로 인해 발생

dup ack : 1,2,3받고 5번 받으면 3번 ACK계속 보냄

 

 

 

 

tcp fast retransmit

timeout 기다리지말고 바로 보내자

 

1 2 3    5 6 7

4번만 잃었다고 판단 -> 4ACK이 3번 왔다는 것은 5,6,7은 잘 받았다는 것임

triple dup ack

 

flow control

rwnd 값을 적어서 보냄(속도 조절용)

tcp는 데이터를 수신버퍼에 저장한다. -> 바로 데이터를 안읽을 수도 있음

rwnd=0일 때 송신자가 1 바이트 데이터로 세그먼트를 계속 전송하도록 요구(안보내면 몰라서 계속 못보냄)

Connection 

 

초기에 seq num 설정

동기화 : seq num을 동기화 시킴

 

왜 time_wait이 필요한가

https://docs.likejazz.com/time-wait/

TIME_WAIT 상태란 무엇인가 · The Missing Papers

 

Congestion control

core는 그냥 패킷을 포워딩만 해줌 -> end host에서 판단해야함

buffer overflow로 인한 패킷 손실, long delay로 혼잡 판단