[네트워크] transport layer!

Transport layer

• reliable이 핵심! 즉, packet이 왔으면 정확한지 확인하고 전달하는 구간이다! 
• communication between process!!
• TCP(reliable) , UDP(unreliable)
• port number

그림1. TCP,UDP data format

Connection-oriented demux

• TCP socket은 UDP와 다르게 source IP, source Port, dest IP, dest Port로 identify된다. (UDP는 dest IP, dest Port)
• 이게 뭔뜻인고 하니, 우선 UDP 의 경우 host 내 포트에 위치한 프로세스의 소켓으로 여러 소켓들이 들어온다.
• 반면, TCP는 host의 포트에 위치한 프로세스에 여러 source로부터 소켓이 들어올 경우, 소켓이 fork되어 분리된다.
• 그림2를 봐라. 같은 프로세스가 여러 socket을 갖는 TCP 의 모습이다. (다시 정리하자면, host(IP)내 port는 하나의 process와 대응되고, UDP에서는 이 process가 하나의 socket을 갖는 반면, TCP는 하나의 process에 여러 socket이 대응된다.)
• 왤까? 내생각엔 TCP는 reliable 데이터 전송을 위해 source와 destination간의 hand shaking과정을 거치며 자체 채널을 구축한다. 따라서 destination의 process은 각 source에 대해 개별적으로 대응할 socket이 필요할듯하다. UDP처럼 한 소켓으로 여러 source를 대응하면, state를 개별적으로 저장하여 각기 다른 대응이 불가능할테니 말이다.

그림2 TCP socket

UDP

• best effort : reliable은 보장하지 않는 대신에, 현재 traffic에서 가장 best한 service를 user에게 제공하는 방식!!
• DNS, SNMP
• checksum은 제공한다.  아예 unreliable하다고 단정지으면 억울할듯

그림3 UDP data format

Checksum

• error check
• sender은 segment내의 모든 비트를 16bit씩 쪼개주고, 더한다. 이후 carry를 더해주고, 1's complement를 취해준다. 이녀석을 보내주면 receiver은 checksum을 다시 구하고 비교해서 두 값이 서로 일치하는지 체크한다.
• 모든 error에 대한 대비책이 될 순 당연히 없다.

그림4 checksum

Principle of rdt (reliable data transfer)

• rdt 1.0
• socket에 state가 존재한다.(FSM : finite state machines)
• no bit error, no packet loss 가정한다.
• rdt 2.0
• bit error이 일어날 수 있다. -> checksum을 통해 감지 -> 어떻게 recover??
• ACK, NAK 으로 확인하고 resend!
• rdt 2.1
• ACK, NAK 도 bit error이 일어날 수 있다.
• sequence number을 packet에 부과한다. (0,1만 부과해도 됨) -> sender 와 receiver 사이의 sync 를 맞춰줄 수 있다.
• rdt 2.2
• NAK을 제거한다. (그 전 sequence number + ACK으로 하면 됨)
• rdt 3.0
• packet loss가 일어날 수 있다.
• timeout 기능을 추가한다.(sender) -> timeout시 resend
• pipelined protocol
• timeout 의 오버헤드가 지나치게 크다. 
• 여러개를 슉슉 보내자!
• GBN(Go-back-N), Selective Repeat

그림5 timeout overhead

그림6 pipelined protocol

• GBN(Go-back-N)
• 전송 실패가 뜬 packet부터 순서대로 다시 보내버림(오버헤드)
• Selective Repeat
• 전송 실패가 뜬 packet만 다시보낸다.
• buffer에 실패 이후의 packet들을 임시보관

그림7 Go-back-N

그림8 Selective repeat

여기서 개념 정리하고 가자!

• window size : RTT(Round Trip delay Time)동안 전송할 수 있는 패킷의 수
• sequence number : 임의로 지정해준 패킷 번호(그림8에선 9이다.)

그림9 Go-back-N 의 sender packets

문제를 풀어볼까?

그림10 window/seqnum 관련 예제

• 그림  (a)와 그림 (b)를 보면, (a)는 보내는 패킷 하나가 loss가 일어났고, (b)에는 돌아오는 window size만큼의 패킷이 loss가 일어났다. 그런데 문제는 receiver입장에서 이 둘을 구분할 방법이 없다. 아마 receiver은 (a)와 같이 loss가 일어났다 생각할테고, 그에 따라 sender 와 receiver에 packet이 서로 sync가 안맞게 된다.
• 이 일이 발생한건 window size에 비해 sequence number이 작아서이다. 한번에 loss가 일어날 수 있는 최대의 packet수는 window size인데 (왜냐면 RTT동안 window size만큼만 보내므로) 이 문제를 피하기 위해선 sequence number의 크기가 window size보다 2배이상 커야한다.
• 그 이유는 sequence number이 한바퀴 돌아 0으로 오는걸 피해야 하기 때문이다. 0에서 시작한 packet이 RTT동안 최대 window size-1만큼 보내고, 최대 window size-1큼의 loss가 일어난후 1만큼 다시 보내는 것이 sequence number을 최대한 소비하는 방식인데, 이만큼 소비한 이후에도 0으로 돌아와선 안된다.
• windowsize -1 + windowsize -1 + 1 = windowsize*2 -1 보다 sequence number가 커야 가능한 일이다.
• 헷갈리다면 window size 3, sequence number 5,6 을 두고 한번 직접 해봐라.

-> 마무리 rdt는 transport layer에서 핵심적인 내용이다. rdt는 내가 보기에 TCP 뿐 아니라 UDP에도 적용된다고 보는 것이 합리적이며, 다시말해 UDP역시 어느정도의 reliable data transfer을 위해 노력한다.(UDP header에는 checksum 이 존재하고 이는 rdt2.0버전을 함유함을 의미함) 다만 UDP의 헤더에는 sequence number가 없다는 것, 즉 rdt 2.0까지만을 제공한다고 생각하는 게 맞을듯하다.

TCP 

• reliable data (congestion control, flow control)
• ACK를 보낼때 받고싶은 sequence number을 보냄 (그림12)

그림11 TCP data format

• TCP fast transmit
• time out overhead를 피하기 위해 같은 seq의 ack를 3회이상 받으면 resend 수행

그림12 TCP fast transmit

• TCP flow control
• receiver가 buffer을 갖고, sender의 보내는 속도를 조절한다.
• 그림14를 보면 rwnd가 수신 윈도우 크기(수신측 버퍼 여유 용량)이다. 다시말해 sender의 window size(awnd)는 rwnd보다 작거나 같도록 receiver이 조절한다. 

그림13 TCP flow control

그림14 TCP flow control

• TCP congestion control
• Tahoe : 초기 cwnd(혼잡 윈도우)는 1, 지수적으로 증가하다가 threshold지나면서 선형적 증가하다 data loss(3 duplicated ACK / timeout)시 다시 1로 떨어진다.(그림 16)
• Reno :  data loss(3 duplicated ACK / timeout) 시 cwnd는 절반으로 줄어들고, 다시 선형적 증가한다.(그림 16)

그림15 Tahoe 방식

그림16 TCP congestion control

• window size 
• awnd = minimum [ cwnd, rwnd ]
• awnd : 전송 윈도우 크기
• cwnd : 혼잡 윈도우 크기
• rwnd : 수신 윈도우 크기(수신 측 버퍼 여유 용량)