[Computer Network] UDP & TCP

✅ UDP (User Datagram Protocol)

1️⃣ UDP는 빠르다.

▪️ UDP는 TCP와 다르게 다중화/역다중화, 간단한 오류 검사 기능만을 제공한다. 

▪️ TCP는 신뢰적 전송, 혼잡제어, 흐름제어 등 UDP보다 더 많은 기능을 제공한다.

▪️ 따라서 UDP는 TCP보다 빠르다. UDP하에서 애플리케이션 프로세스가 데이터를 UDP에게 전달하면, 데이터를 UDP 세그먼트로 만들고 즉시 그 세그먼트를 계층으로 전달한다. 

▪️ UDP는 실시간 애플리케이션에 적합하다. 실시간 애플리케이션은 최소 전송률을 요구하고, 지연 전송을 원하지 않고, 조금의 데이터 손실은 허용한다. 따라서 TCP보다 UDP가 적합하다. 

2️⃣ 신뢰적 데이터 전송을 보장하지 않는다. 

▪️ 송신한 세그먼트가 손실될 수 있다.

▪️ 송신한 세그먼트의 도착 순서가 달라질 수 있다.

▪️ 아이러니하게, 신뢰적 전송이 매우 중요한 애플리케이션에서 UDP를 사용하는 경우가 있다. 이는 애플리케이션 레벨에서 신뢰성 보장 기능을 직접 구현한 경우다. 

3️⃣ 사전 연결 설정이 없다.

▪️ UDP는 사전 연결 설정을 하지 않는다. 따라서 사전 연결 설정을 위한 지연이 없다.

▪️ 지연이 없기 때문에 빠르다. 이는 DNS, SNMP가 UDP에서 동작하는 이유다.

▪️ TCP는 데이터 전송을 시작 하기전에 사전 연결 설정을 한다. (Tree-way handshake)

4️⃣ 연결 상태를 유지하지 않는다.

▪️ TCP는 종단 시스템에서 연결 상태를 유지한다. (송수신 버퍼, 혼잡제어, 신뢰적 전송을 위한 여러 파라미터를 유지)

▪️ 반면, UDP는 연결 상태를 유지하지 않는다. 따라서 일반적으로 특정 애플리케이션에 할당된 서버는 TCP보다 UDP에서 동작할 때 좀 더 많은 클라이언트를 수용할 수 있다.

5️⃣ 적은 패킷 헤더 오버헤드

▪️ TCP 세그먼트가 20Byte의 헤더 오버헤드를 갖는 반면, UDP는 8Byte의 오버헤드를 갖는다. 

6️⃣ UDP CheckSum 

▪️ 송신을 할때 UDP 세그먼트를 16비트 워드로 단위로 나누고, 각 워드를 모두 더하고 1의 보수 연산을 수행하여 checksum을 만든다. 

▪️ 세그먼트 수신을 하면, 다시 세그먼트를 16비트 워드 단위로 나누고, 각 워드를 모두 더하고 여기에 checksum까지 더한다. 그 결과를 봤을 때 비트가 0이 없고 모두 1이라면, 전송 과정에서 오류가 발생하지 않았음을 알 수 있다.

UDP는 Checksum으로 단지 오류여부만 확인한다. 후속 조치는 하지 않는다. 

📋 UDP CheckSum 예제 

아래와 같은 3개의 16비트 워드가 있다고 하자 (UDP 세그먼트를 16비트 단위로 쪼갠것이다.)

0110011001100000

0101010101010101

1000111100001100

 

이 3비트를 보두 합하면, 

 

010010101100010 <- 이렇게 된다. 여기에 1의 보수를 취하면,

 

1011010100111101 <- 이렇게 된다. 이것이 checksum 이다. 수신측에서는 UDP 세그먼트와 checksum을 수신하면, 다시 세그먼트를 3개의 16비트 워드로 나누고 거기에 checksum을 더한다. 

 

0110011001100000 

0101010101010101

1000111100001100 (3개의 16비트워드)

+

1011010100111101 (checksum)

---------------------

1111111111111111 (결과)

 

결과의 모든 비트가 1이므로 전송과정에서 오류가 없었음을 알 수 있다.

 

UDP  세그먼트 구조

---

✅ TCP의 신뢰적인 데이터 전송 메커니즘

▪️ Checksum : Checksum을 사용하여 수신자가 패킷 비트 오류를 검출하고 복구할 수 있도록 한다.

▪️ ACK(Acknowledgement : 긍정 확인응답) : 수신자가 세그먼트를 정상적으로 수신하면, 송신측으로 보내는 확인 메세지이다. ex) ACK+358 : 현재 357번 패킷까지 수신 완료했고, 다음에는 358번 패킷을 전송하라는 뜻

▪️ NACK(Acknowledgement : 부정 확인응답) : 수신자가 세그먼트를 수신하지 못할때, 송신측으로 보내는 부정 확인 메세지이다. 

▪️ Timer(타이머) : 수신자가 보낸 피드백(ACK 또는 NACK)은 네트워크 지연 또는 패킷 손실에 따라 송신자에게 도착하지 못할 수 있다. 이런 경우를 대비하여 송신자는 패킷을 전송하고 일정 시간이 지나면 재전송을 한다. (불필요한 재전송 발생 가능)

▪️ Sequence number(순서번호) : 송신자가 패킷마다 순서 번호를 붙인다. 수신자는 수신된 패킷의 순서 번호를 통해 이미 받은 패킷인지 또는 처음 받는 패킷인지 판별할 수 있다. 

▪️ Window&Pipelining(파이프라이닝) : 송신자와 수신자가 한 개의 파이프로 연결되있다고 생각해보자. 파이프를 최대한 활용하기 위해서는 파이프를 패킷으로 꽉 채워야한다. 파이프라이닝이란 링크 사용율을 높이려고 하는 것이다. 송신자는 아직 긍정확인(ACK)을 받지 않은 상태에서 세그먼트를 지속적으로 보낼 수 있다. 단, 그 양은 Window로 한정되어있다. 요약하자면, Window는 수신자로부터 ACK를 받지 않은 상태에서 송신할 수 있는 최대 세그먼트의 양이다.

▪️ 파이프 라인 오류 회복의 두 가지 기본적인 접근 방법으로 Go-Back-N과  Selective Reapeat 등이 있다.

1️⃣ Go-Back-N ARQ(Automatic Repaet Request)

▪️ 손실된 패킷이후의 패킷들을 모두 재전송 받음

▪️ 구현이 간단하다

2️⃣ Selective Repeat ARQ(Automatic Repaet Request)

▪️ 손실된 패킷만 선택적으로 재전송

▪️ 복잡하다.

 

---

✅ TCP (Transmission Control Protocol) 

1️⃣ TCP는 연결지향형이다.

▪️ 데이터 전송을 하기전에 사전 연결 설정을 한다. 이를 3-way handshake라고 한다.

2️⃣ TCP는 신뢰적인 데이터 전송을 보장한다.

▪️ Checksum(체크섬), ACK/NACK(응답 메세지), Sequence number(순서번호), Timer(타이머) 등을 사용하여 목적지로 전송되지 않은 데이터를 재전송한다.

3️⃣ UDP보다 느리다.

▪️ TCP는 많은 기능을 지원하기 때문에 헤더가 복잡하고 오버헤드가 크다. 따라서 UDP보다 느리다.

4️⃣ 파이프라이닝

▪️ TCP는 Throughput(처리율, bps)을 높이기 위해 Pipelining(파이프라이닝)을 한다.

5️⃣ 흐름제어

▪️ TCP는 Flow Control(흐름제어)를 한다. 흐름제어란 송신자가 수신자의 패킷 수신 버퍼 사이즈를 고려하여, 송신 속도를 조절하는 것 이다.

6️⃣ 혼잡제어

▪️ TCP는 Congestion Control(혼잡제어)를 한다. 네트워크 딜레이가 심하거나 데이터 Loss가 발생할때 TCP는 Pipelining의 정도를 조절한다. (=cwnd(Congestion Window Size)를 조절한다.)

7️⃣ TCP 기타 특징 

▪️ TCP는 Point-To-Point 연결이다. 송신자 1명과 수신자 1명이 연결된다.

▪️ TCP는 전송하는 데이터를 byte stream으로 본다. TCP는 애플리케이션이 보내는 모든 메세지를 버퍼에 담아두고 이를 바이트의 연속으로 본다. 전송 할 때는 MSS 만큼 잘라서 전송한다. (전송은 flow control과 congestion control에 의해 제어된다. )

▪️ 송신자와 수신자간 TCP 연결이 확립되면, TCP는 full duplex를 지원한다. (양쪽 모두 송신, 수신 가능)

---

📌 TCP : 3-way-handshake

▪️ TCP는 연결지향형이다. 따라서 통신을 하기 전에 사전 연결 설정을 한다. 이는 3개의 특별한 패킷을 주고 받으면서 진행된다. 연결과정은 아래와

1. 클라이언트는 서버에게 연결을 요청한다.

2. 서버는 클라이언트에게 ACK 응답을 한다.(클라이언트는 서버의 ACK를 받음으로서 현재 서버가 alive 상태임을 확인)

3. 클라이언트는 서버에게 ACK 응답을 한다.(서버는 클라이언트의 ACK를 받음으로서 현재 클라이언트가 alive임을 확인한다.)

4. 연결 확립(Established)

---

📌 TCP : 4-way-handshake

▪️ 4-way-handshake는 TCP가 연결을 종료하는 방법이다.

1. 클라이언트가 서버에게 종료요청

2. 서버가 응답

3. 서버가 클라이언트에 종료요청

4. 클라이언트가 응답

5. 연결 종료(Close)

https://media.geeksforgeeks.org/wp-content/uploads/CN.png

---

📌 TCP : 2-way-handshake?

▪️  TCP는 왜 3-way-handshake를 할까? 이러한 의문에 기반하여 2-way-handshake의 문제점을 알아보자

▪️ 2-way-handshake를 한다면 클라이언트는 서버에게 연결 요청을 하고(1), 서버는 그것에 대한 응답(2)을 함으로써 연결확립이된다. 이 때 만약 서버에 들어온 연결 요청이 사실은 긴 시간지연으로 타이머를 초과해서 재전송된 요청이라면 그리고 클라이언트와 서버의 TCP 통신은 이전에 끝난 상황이라면, 해당 요청은 연결을 확립해주면 안되는 요청이다. 

▪️ 따라서, 서버는 클라이언트의 연결 요청에 대해 다시 한 번 클라이언트가 가용상태(Alive)인지 확인해야한다. 그렇기 때문에 클라이언트가 서버에게 "나는 현재 가용상태이다. " 라고 다시 한 번 서버에게 응답하는 과정이 필요하다.

---

📌 TCP : Flow Control (흐름제어)

▪️ 송신자가 보낸 TCP 세그먼트는 링크계층, 네트워크 계층을 거쳐 수신자의 TCP 소켓 버퍼로 들어간다. 만약 송신자가 세그먼트를 보내는 속도가 수신자가 TCP 소켓 버퍼에서 세그먼트를 가져가는 속도보다 빠르다면, 언젠간 수신 버퍼는 세그먼트들로 꽉 차게 된다. 버퍼가 꽉차게 되면 더 이상 세그먼트를 수신할 수 없다. 이런 문제를 방지하기 위해 송신자는 세그먼트 전송 속도를 조절하는데 이것이 바로 Flow Control이다.

▪️ 송신자는 수신 버퍼의 빈 버퍼 사이즈(Free Buffer Space, rwnd)가 오버플로우 되지 않도록 전송 속도를 조절한다. 송신자는 수신 버퍼의 빈 버퍼 사이즈를 어떻게 알까? 수신자는 긍정(ACK)/부정(NACK) 응답을 보낼 때 TCP 헤더의 rwnd에 현재 수신버퍼의 빈 사이즈를 전송하기 때문에 알 수 있다.

 

수신측 버퍼

---

📌 Congestion Control (혼잡제어)

▪️ 네트워크가 혼잡해지면 딜레이가 커지고 패킷 유실(loss)이 발생한다. 

▪️ 딜레이가 커지고 패킷이 loss 되면, 호스트들은 재전송을 하게 되는데, 이렇게 되면 네트워크는 더욱 혼잡해진다.

▪️ 호스트가 네트워크에 패킷 전송을 많이 하다보면, 어느 순간에 네트워크 혼잡이 커진다.

📋 End-End Congestion Control

▪️ End 시스템에서 Congestion Control을 하는 방식이다. 호스트들(End Systems)은 딜레이와 loss를 통해 네트워크가 혼잡 상황인 것을 감지한다. 그리고 그것에 따른 리액션을 취한다. (인터넷 철학 : 데이터를 전송하는 것 이외의 모든 복잡성은 Edge로 몬다.) TCP가 선택하고 있는 방법이다.

📋Network-Assisted Congestion Control

▪️ 패킷이 딜레이 되고 loss 되는 실제 위치는 네트워크의 라우터이다. Network-Assisted Congestion Control은 네트워크의 어떤 라우터에서 혼잡(Congestion)이 발생하면, 호스트들에게 알리는 방식이다.

---

📌 TCP : Congestion Control (혼잡제어)

📋 AIMD (Additive increase multiplicative decrease) 

▪️ AIMD 방식은 매 RTT마다 1 MSS씩 TCP Congestion Window(송신측이 Ack 없이 한번에 data를 보내는 크기, cwnd) 그러다가 loss가 발생하면 cwnd를 절반으로 줄인다. 이를 반복해 나가는 방식이다.

 

https://slideplayer.com/slide/3729208/

---

📋 Slow Start

▪️ Slow Start는 말그대로 "느리게 시작하다."가 아니다. 이를 살펴보며 알아보자.

▪️ 시작 cwnd는 1 MSS이고 매 RTT마다 cwnd를 두 배씩 늘려나간다. (cwnd는 지수적으로 증가한다.) ssthresh는 OS가 초기화한 값인데, 어떤 임계값이다. cwnd는 지수적으로 증가하다가 ssthresh 보다 높아지면 매 RTT마다 cwnd를 1씩 증가 시킨다.(이 때가 slow strat phase 이다.) 이렇게 진행하다가 loss가 발생하면 ssthresh를 현재 cwnd의 절반으로 설정한다. 

▪️ TCP는 loss 발생 여부를 Time Out 또는 3 duplicate ACK으로 탐지할 수 있다. Time Out은 패킷이 유실되거나 딜레이가 많이 큰 상황이라 좋지 않은 경우고 3 duplicate ACK일 경우는 그래도 어느정도 네트워크 전송이 가능하다는 뜻이다.

▪️ loss가 발생했을때 cwnd도 조정을 해야한다. 이는 loss의 종류에 따라 달라진다. 아래와 같이 loss에 반응하는 2가지 TCP 방식이 존재한다.

 

✔️TCP Tahoe

▪️ loss를 Time Out 또는 3 Duplicate ACK로 감지하면, cwnd를 1로 만든다.  

 

✔️TCP RENO

▪️ loss를 3 Duplicate ACK로 감지하면(Time out loss보다 나음), cwnd를 반으로 줄인다.

▪️ 현재 가장 많이쓰는 버전

 

https://citricks.net/wp-content/uploads/TCP-Congestion-Control-Slow-to-CA.png

▪️ 운영체제가 초기에 설정한 ssthresh의 값은 8이다. TCP Tahoe를 보자 ssthresh에 도달하기 전까지 cwnd는 지수적으로 증가한다. ssthresh에 도달하면 cwnd를 1씩 증가시킨다. 그러다가 9번째 round에서 cwnd가 12가 되자 loss가 발생했다. 따라서 ssthresh는 절반이 되고, TCP Tahoe는 cwnd를 1로 만든다. 그리곤 또다시 지수적으로 증가하다가 ssthresh를 만나면 1씩 증가한다. TCP Reno의 경우는 어떨까? 9번째 round에서 12인 cwnd는 Reno일 경우 절반으로 줄여진다. 그럼 6이 되는데 ssthresh도 6이된다. 이럴 경우 cwnd와 ssthresh가 같아져서 TCP Reno의 경우 loss를 경험하면 1씩 증가한다.  

---

📌 TCP Fairness

 

▪️ TCP connection 1,2가 있고 bottleneck 라우터 R이 있다. 이 경우 두 connection은 라우터에 대해 공평하게 네트워크를 사용할 수 있을까?

 

 

▪️ 위 그림의 파란 대각선(R)은 두 connection이 라우터 R까지의 링크를 full로 사용하는 라인이다. 만약 두 connection의 링크 사용률이 R을 넘어서면 두 connection의 사용률에 대해 각각 절반으로 줄인다. 이를 반복하게 되면 두 connection은 링크를 공평하게 절반씩 사용하게 된다. 아래 그림을 보면 반복적으로 equl bandwidth share(y=x) 라인에 근접하게됨을 알 수 있다.