[Network] TCP와 UDP

1️⃣ TCP (Transmission Control Protocal)

클라이언트와 서버가 연결된 상태에서 데이터를 주고 받는 연결 지향적 프로토콜

• 장치들 사이에 연결을 설정해 신뢰성을 보장(안정적으로, 순서대로, 에러 없이)하는 연결형 서비스
• 연속성보다 신뢰성있는 전송이 중요한 경우(ex-파일전송)에 사용됨
  ​

특징

• 연결형 서비스로 가상회선 방식을 제공함
  • 가상회선방식을 제공하는 것 = 발신지와 수신지를 연결하여 패킷을 전송하기 위한 논리적 경로를 배정하는 것
  • 3-way handshaking 과정을 통해 연결을 설정하고, 4-way hankshaking 과정을 통해 연결을 해제함

• 흐름 제어(Flow control)
  • 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지함

• 혼잡 제어(Congestion control)
  • 네트워크 내의 패킷 수가 과도하게 증가하지 않도록 방지

• 높은 신뢰성 보장
  • 신뢰성이 높은 전송을 하기 때문에 UDP보다 속도가 느림

• 전이중(Full-Duplex), 점대점(Point to Point)방식
  • 전이중: 전송이 양방향으로 동시에 가능
  • 점대점: 각 연결이 정확히 2개의 종단점을 가지고 있음 = 멀티캐스트,브로드캐스트는 불가

​

TCP 패킷(세그먼트) 구조

• TCP 세그먼트 = 세그먼트 헤더(TCP 헤더) + 데이터
• (데이터 섹션의 길이) = (전체 IP 데이터그램의 길이) - (TCP 헤더) - (캡슐화된 IP 헤더의 길이)

• 소스 포트(SP, Source Port)
  • 송신자의 포트 번호를 나타내며, 이 포트는 세그먼트를 보내는 응용 프로그램이나 서비스를 식별하는 데 사용됨

• 목적지 포트(DP, Destination Port)
  • 수신자의 포트 번호를 나타냄

• 시퀀스 번호(Sequence Number)
  • 세그먼트에서 전송되는 데이터의 순서를 나타내는 값으로, 시퀀스 번호를 사용해 수신자는 세그먼트의 순서대로 조립할 수 있음

• 확인 응답 번호(Acknowledgment Number)
  • ACK 플래그가 설정된 경우, 다음에 기대되는 수신자의 시퀀스 번호를 나타내며, 이 값은 데이터의 수신 확인에 사용됨

• 헤더 길이(THL, Header Length)
  • 세그먼트 헤더의 길이를 4바이트 단위로 나타냄

• 컨트롤 플래그(Control Flags)
  • TCP의 여러 제어 정보를 나타내는 비트 필드
  • 예를 들어, URG(긴급), ACK(확인), PSH(푸시), RST(리셋), SYN(연결 설정), FIN(연결 종료) 등이 여기에 포함됨

• 윈도우 크기(Window Size)
  • 수신자가 현재로서 처리할 수 있는 바이트 수를 나타냄
  • 유동적으로 조절되며, 흐름 제어에 사용됨

• 체크섬(Checksum)
  • 오류 검출을 위한 체크섬 값으로, TCP 헤더와 데이터의 오류를 감지하는 데 사용됨

• 긴급 포인터(Urgent Pointer)
  • URG 플래그가 설정된 경우, 긴급 데이터의 끝을 가리키는 오프셋을 나타냄

• 옵션(Option)
  • 필요한 경우 여러가지 TCP 옵션을 나타냄

​

TCP 연결/해제

• SYN (SYnchronize sequence Numbers): 연결 확인을 위한 무작위 숫자 값 = 내 말 들려?
• ACK (ACKnowledgements): Client나 Sever로부터 받은 SYN에 1을 더해 SYN을 잘 받았다는 응답 = 잘 들려!

❓ SYN에 무작위 값을 넣어 보내는 이유
연결 시 사용하는 포트 번호는 유한 범위 내에서 사용되기 때문에 시간이 지나면 재사용될 수 있음
서버 측에서는 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순차적인 숫자가 전송된다면 이전의 연결에서 오는 패킷으로 인식할 수도 있기 때문에 난수를 사용하는 것!

​
✨ TCP 연결 과정 (3-way handshaking)

1. Client → Server : 내 말 들려?
2. S → C : 어 잘 들려! 내 말은 들려?
3. C → Server : 잘 들려!

0. 연결을 수립하기 전 기본 상태 (CLOSED)
1. 클라이언트가 서버에게 SYN를 보내고 SYN_SENT 상태로 대기함 (-> SYN(a))
   이때 서버는 LISTEN 상태로 포트 서비스가 가능한 상태여야 함

2. 서버는 자신의 상태를 SYN_RECEIVED(상대 응답 기다리는 중)로 바꾸고, SYN과 ACK를 보냄 (-> SYN(b)+ACK(a+1))

3. SYN과 응답 ACK를 받은 클라이언트는 ESTABLISHED 상태(연결 수립 완료)로 변경하고 서버에게 ACK를 보냄 (→ ACK(b+1))

4. 응답 ACK를 받은 서버는 ESTABLISHED로 자신의 상태를 변경함

​
​

✨ TCP 해제 과정 (4-way handshaking)

1. Client → Server : 나는 다 보냈어! 이제 끊자!
2. S → C : 알겠어! 잠시만~
3. S → C : 나도 끊을게!
4. C → S : 알았어!

1. 클라이언트가 FIN(연결 끊자!)을 보내고 FIN-WAIT-1 상태로 대기함

2. 서버는 자신의 상태를 CLOSE-WAIT 상태로 바꾸고, 클라이언트에게 응답으로 ACK(알겠어! 잠시만~)를 전달함
   동시에 해당 포트에 연결되어 있는 애플리케이션에게 Close를 요청함

3. ACK를 받은 클라이언트는 상태를 FIN-WAIT-2 상태로 변경함

4. Close 요청을 받은 서버 애플리케이션은 종료 프로세스를 진행하고 FIN(나도 끊을게!)을 클라이언트로 보내 LAST_ACK 상태로 바꿈

5. FIN을 받은 클라이언트는 ACK(알겠어!)를 서버에 다시 전송하고 TIME-WAIT으로 상태를 바꿈

6. TIME-WAIT에서 일정 시간이 지나면 CLOSE 상태로 바뀜
   ACK를 받은 서버도 포트를 CLOSED로 닫음

❓ 바로 CLOSED하지 않고 TIME-WAIT 상태로 기다리는 이유?
혹시 모를 전송 실패에 대비하기 위함
TIME-WAIT이 없다면, 패킷의 손실이 발생하거나 통신자 간 연결 해제가 제대로 되지 않을 수 있음

❓ 왜 해제는 4번 할까?
연결을 시작할 때는 서로 통신 중이 아닌 상태에서 Handshake를 시도하므로, SYN과 ACK를 동시에 보낼 수 있음 (아무것도 안하고 있으니까)
But, 연결을 해제 할때는 이미 상호 통신 중이기 때문에 FIN 과 ACK를 동시에 보낼 수 없음 (-> 일방적으로 종료 할 수 없음)

흐름 제어 (Flow Control)

송신측과 수신측 사이의 데이터 속도 차이를 해결하기 위한 기법
즉, 수신측이 패킷을 지나치게 많이 받지 않도록 조절하는 것

송신측 전송량이 수신측 수신량보다 클 경우, 전송된 패킷은 수신측의 큐를 넘어 손실될 수 있기 때문에 송신측의 패킷 전송량을 제어해야 함!

❓ 흐름제어 vs 혼잡제어

• 공통점: 송신자의 데이터 전송 속도를 제어함으로써 오류를 줄이는 기능
• 차이점: 흐름제어는 송수신 측 사이에 패킷 수를 제어하는 기능이지만, 혼잡제어는 네트워크 내의 패킷 수를 조절하는 기능임

​

✨ Stop and Wait

매번 전송한 패킷에 대한 응답을 받아야 그 다음 패킷을 전송할 수 있음 (Give & Take 방식)
매번 확인 응답을 받을 때까지 기다려야 하기 때문에 비효율적임

​

✨ 슬라이딩 윈도우 (Sliding Window)

수신측에서 설정된 윈도우 크기 만큼 송신측에서 확인 응답 없이 세그먼트를 전송할 수 있게 하여, 데이터 흐름을 동적으로 조절하는 기법

Stop and Wait의 비효율성을 개선한 기법임

1. 아래 그림처럼 송신 측에서는 1~5까지의 프레임이 전송 가능함
2. 1~5까지를 윈도우에 담고, 먼저 1,2를 전송함
3. 송신측의 윈도우는 3,4,5만큼 크기가 줄어들게 됨
4. 수신측에서 0,1 데이터를 정상적으로 수신했음을 알리는 ACK를 송신측으로 보냄
5. 송신측은 ACK를 받고 ACK의 프레임 수만큼 오른쪽으로 윈도우의 경계를 확장시킴

혼잡 제어 (Congestion control)

송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법

• 송신측의 데이터는 지역망이나 인터넷으로 연결된 대형 네트워크를 통해 전달되는데,
  만약 한 라우터에 데이터가 몰릴 경우, 자신에게 온 데이터를 모두 처리할 수 없게 됨
• 이런 경우 호스트들은 또 다시 재전송을 하게되고 결국 혼잡만 가중시켜 오버플로우나 데이터 손실을 발생시키게 됨

따라서 이러한 네트워크의 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송속도를 강제로 줄이게 되는데, 이러한 작업을 혼잡제어라고 함
​

✨ AIMD (Additive Increse, Multiplicative Decrease)

송신측이 전송 속도(윈도우 크기)를 패킷 손실이 일어날 때까지 증가시키는 방법

• Additive Increase: 송신측의 윈도우 크기를 패킷 손실이 감지될까지 매 RTT마다 1MSS(Maximum Segment Size)씩 증가시킴
• Multiplicative Decrease: 패킷 손실이 감지되었다면, 송신측의 윈도우 크기를 절반으로 감소시킴

윈도우 크기를 1MSS씩밖에 증가시키지 않기 때문에, 빠른 속도로 통신하기까지 오래 걸린다는 단점이 있음
​

✨ Slow Start (느린 시작)

송신측이 윈도우 크기를 1부터 패킷 손실이 일어날 때까지 지수승으로 증가시키는 방법

처음에는 윈도우 크기가 1이라 속도가 느리지만, 지수승으로 윈도우 크기가 커지므로 속도도 빠르게 증가함. 대신 혼잡 현상이 발생하면 윈도우 크기를 1로 떨어트리게 됨
​

---

✨ 혼잡제어 버전1. TCP Tahoe

TCP 타호는 처음에는 Slow Start를 사용하다가 임계점에 도달하면 AIMD 방식을 사용함

3 duplicate ACKs 혹은 Time out을 만나면 임계점을 윈도우 크기의 절반으로 줄이고 윈도우 크기를 1로 줄임
이때, 3 duplicate ACKs는 송신측이 3번 이상 중복된 승인 번호를 받은 상황으로, 정상적으로 데이터가 전송되지 않음을 의미
​
TCP Tahoe 방식은 3 duplicate ACKs를 만나고 window size가 다시 1부터 키워나가야 하므로 속도가 느림 -> 이를 해결할 수 있는 방식이 TCP Reno

​

✨ 혼잡제어 버전2. TCP Reno

TCP Reno는 TCP Tahoe와 비슷하지만 3 dupicate ACKs와 Time out을 구분한다는 점이 다름

• 3 duplicate ACKs를 만나면 window size를 절반으로 줄이고 임계점을 그 값으로 설정함
• Time out을 만나면 window size를 1로 줄임. 이때 임계점은 변하지 않음

2️⃣ UDP (User Datagram Protocol)

비연결형 프로토콜

• 즉, 연결을 위해 할당되는 논리적인 경로가 없고, 각각의 패킷은 다른 경로로 전송되며, 독립적인 관계를 지님
• 신뢰성보다는 연속성있는 전송이 필요할 때(실시간 스트리밍 서비스 등) 사용함

❓ 실시간 스트리밍인데 패킷 순서가 바뀌면 안되지 않나요?

• 123456으로 보낸게 124536으로 오면 그대로 12456으로 스트리밍 되는 것
• 극단적으로 654321로 오진 않음
• UDP는 전송 프로토콜이고, RTP 등의 프로토콜에서 이를 해석할 때 처리해준다.
• 서비스가 추구하는 특징에 따라 그에 알맞은 프로토콜을 사용함
  • ex) 넷플릭스는 TCP를 사용함

​

특징

• 비연결형 서비스로 데이터그램 방식을 제공함
  • 데이터의 전송 순서가 바뀔 수 있음

• 데이터 수신 여부를 확인하지 않음
  • TCP의 3-way handshaking과 같은 연결을 설정하고 해제하는 과정이 존재하지 않음

• 신뢰성이 낮음
  • 흐름 제어/혼잡제어가 없어서 제대로 전송되었는지, 오류가 없는지 확인할 수 없음

• TCP보다 속도가 빠름
  • 연결 할당/해제,흐름/혼잡 제어가 없기때문에 속도가 빠르고 네트워크 부하가 적음

• 1:1 & 1:N & N:N 통신이 가능함

​

UDP 패킷(데이터그램) 구조

UDP(User Datagram Protocol) 패킷은 사용자 데이터그램이라고 부르기도 함

데이터그램 방식은 패킷 교환에서 비연결형 서비스를 이용해 패킷을 독립적으로 전송하는 방식(UDP)을 가리킴

3️⃣ TCP와 UDP 비교

프로토콜 종류	TCP	UDP
연결 방식	연결형 서비스	비연결형 서비스
패킷 교환 방식	가상 회선 방식	데이터그램 방식
전송 순서	전송 순서 보장	전송 순서가 바뀔 수 있음
수신 여부 확인	수신 여부를 확인함	수신 여부를 확인하지 않음
통신 방식	1:1 통신	1:1 OR 1:N OR N:N 통신
신뢰성	높다.	낮다.
속도	느리다.	빠르다.

참고자료

https://dev-coco.tistory.com/144
https://dev-coco.tistory.com/161
https://baebalja.tistory.com/443
https://medium.com/pplink/%EC%8B%A4%EC%8B%9C%EA%B0%84-%EC%8A%A4%ED%8A%B8%EB%A6%AC%EB%B0%8D-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%A0%84%EC%86%A1%ED%95%98%EB%8A%94%EA%B1%B0%EC%95%BC-a3e38716e06d
https://lactea.kr/entry/Network-%E2%80%93-tcp-%EC%97%B0%EA%B2%B0-%EB%B6%84%EC%84%9D
https://chunggaeguri.tistory.com/entry/Network-TCP-3-Way-Handshake
https://blog.skby.net/슬라이딩-윈도우sliding-window/
https://evan-moon.github.io/2019/11/26/tcp-congestion-control/
https://blog.skby.net/tcp-혼잡제어/
https://hanamon.kr/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EA%B8%B0%EB%B3%B8-%EB%8F%84%EB%A9%94%EC%9D%B8%EA%B3%BC-dns-%EB%84%A4%EC%9E%84%EC%84%9C%EB%B2%84%EB%9E%80-%EA%B0%9C%EB%85%90%ED%8E%B8/
https://ooeunz.tistory.com/91