[WEEK08] TCP와 UDP

TCP 3/4-way Handshake

3-way handshake: 연결 성립

TCP는 정확한 전송을 보장하기 위해 3-way handshake 과정을 거쳐 연결을 성립한다.

1. 클라이언트가 서버에 SYN(x) 패킷을 보냄
2. 서버가 SYN(x)를 받고, 클라이언트로 받았다는 신호 ACK(x+1)와 SYN(y) 패킷을 보냄
3. 클라이언트는 서버의 응답 ACK(x+1)과 SYN(y) 패킷을 받고 서버로 ACK(y+1)을 보냄

---

4-way handshake: 연결 해제

1. 클라이언트는 서버에게 연결을 종료한다는 FIN 플래그를 전송한다.
2. 서버는 FIN을 받고 확인했다는 ACK를 클라이언트에 전송한다. 이 때 모든 데이터를 보내기 위해 CLOSE_WAIT 상태가 된다.
3. 데이터를 모두 보냈다면 연결이 종료되었다는 FIN 플래그를 클라이언트에 전송한다.
4. 클라이언트는 FIN을 받고 확인했다는 ACK를 서버에 전송한다. 이 때 아직 서버로부터 받지 못한 데이터가 있을 수도 있으므로 TIME_WAIT 상태가 된다.

• 서버는 ACK를 받은 이후 소켓을 닫는다(Closed).
• 클라이언트도 TIME_WAIT이 끝나면 닫는다(Closed).

---

TCP/IP

TCP란?

• 신뢰성 있는 네트워크를 보장하는, 전이중 연결을 제공하는 통신 프로토콜
• '신뢰성 있는 네트워크'를 보장하는 데에는 4가지 이슈가 있다.
  • 패킷의 손실
  • 패킷의 순서가 바뀜
  • Congestion (네트워크 혼잡 문제)
  • Overload
• 흐름제어Flow Control 
  • 송신측과 수신측의 데이터 처리속도 차이를 해결하는 기법
  • 수신측이 패킷을 지나치게 많이 받지 않도록 조절함
  • 기본 개념은 수신측이 송신측에게 현재 자신의 상태를 feedback한다는 것이다
• 혼잡 제어Congestion Control
  • 송신측의 데이터 전달과 네이트워크 데이터 처리 속도 차이를 해결하는 기법
• 전송의 과정
  • 응용 계층 : 송신측의 응용 계층이 소켓에 데이터를 씀
  • 전송 계층 : 데이터를 세그먼트에 감싸고 네트워크 계층에 넘겨줌
  • 아랫단에서 수신측 노드로 전송이 된다. 이 때 송신측은 send buffer에 데이터를 저장하고 수신측은 receive buffer에 데이터를 저장한다.
  • 응용프로그램에서 준비가 되면 buffer에 있는 데이터를 읽음
  • 따라서 흐름제어의 핵심은 수신측 buffer가 넘치지 않게 하는 것이다.
  • 수신측은 수신측 buffer의 남은 공간을 알리는 RWNDreceive window를 사용함

---

흐름 제어

• 수신측이 송신측보다 데이터 처리 속도가 느린 경우 문제가 발생할 수 있다.
• 수신측에서 제한된 저장 용량을 초과한 이후에 도착하는 데이터는 손실될 수 있으며, 이 경우 불필요한 응답과 데이터 전송이 발생할 수 있다.
• 이러한 위험을 줄이려면 송신측의 데이터 전송량을 수신측의 상태에 따라 조절해야 한다.
• 해결방법
  • Stop and Wait : 매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송하는 방법
  • Sliding Window (Go Back N ARQ)
    • 수신측에서 설정한 window 크기 만큼 송신측에서 확인 응답없이 세그먼트를 전송할 수 있게 해서 데이터 흐름을 동적으로 조절하는 기법
    • 전송은 되었지만 ACKed를 받지 못한 바이트의 수를 확인하기 위해 사용함
    • 먼저 window에 포함된 모든 패킷을 전송하고, 그 패킷들의 전달이 확인되면 window를 옆으로 옮겨서 그 다음 패킷들을 전송함
    • TCP/IP를 사용하는 모든 호스트들은 송신용 윈도우와 수신용 window(총 2개)를 가진다. 호스트들은 실제 데이터를 보내기 전 3-way handshaking을 통해 수신 호스트의 수신 윈도우 사이즈에 자신의 송신 윈도우 사이즈를 맞추게 된다.

---

혼잡 제어

• 네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 혼잡Congestion이라고 하며, 혼잡 현상을 방지 및 제거하는 기능을 혼잡제어라고 한다.
• 흐름제어가 송신측과 수신측 사이의 전송 속도 차이를 다루는 데 비해, 혼잡제어는 호스트와 라우터를 포함한 더 넓은 관점에서 전송 문제를 다룬다.
• 송신측의 데이터는 지역망이나 인터넷을 통해 연결된 대형 네트워크를 통해 전달된다. 만약 한 라우터에 데이터가 몰릴 경우 자신에게 온 데이터를 모두 처리할 수 없다. 이 경우 호스트들은 재전송을 하게 되고 혼잡을 가중시켜 오버플로우나 데이터 손실을 발생시킨다. 따라서 이러한 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송 속도를 강제로 줄이게 된다.
• 해결방법
  • Slow Start: 연결 초기 또는 타임아웃 후 혼잡 윈도우 크기를 지수적으로 빠르게 증가시킴
  • Congestion Avoidance: 임계값 도달 후 혼잡 윈도우 크기를 선형적으로 천천히 증가시키며 혼잡을 피함
  • Fast Retransmit: 중복 ACK를 여러 개 수신하면 타임아웃 전에 손실된 것으로 의심되는 세그먼트를 즉시 재전송함
  • Fast Recovery: 고속 재전송으로 손실을 감지한 후 혼잡 윈도우를 완전히 줄이지 않고 빠르게 회복함

---

TCP와 UDP

UDP란?

• UDP
  • 데이터를 데이터그램 단위로 처리하는 프로토콜
  • 비연결성, 신뢰성 없는 전송 프로토콜
  • 데이터그램 단위로 쪼개면서 전송함 → 전송 계층에서 사용
• TCP와 UDP의 등장 배경
  • IP는 호스트-호스트만을 지원하기 때문에, 하나의 장비 안에서 수많은 프로그램들이 통신하는 경우 IP만으로는 한계가 존재함 → 포트 번호의 등장
  • IP에서 오류가 발생하면 ICMP에서 알려주지만, 따로 대체를 하지는 못하기 때문에 IP의 상위 개념에서 처리해야 함 → TCP/UDP의 등장
• TCP는 자동으로 데이터의 분실, 중복, 순서의 뒤바뀜 등을 자동으로 보정해 송수신 데이터의 정확한 전달을 보장하지만, UDP는 TCP와 같은 보정 기능이 없어 응용프로그램에서 오류를 처리해야 한다.
• UDP를 쓰는 이유?
  • 데이터의 처리가 TCP보다 빠름
  • UDP header가 TCP보다 간단해서 용량이 더 가볍고 속도도 더 빠름
  • 주로 실시간 방송과 온라인 게임에서 사용됨
• DNS에서 UDP를 쓰는 이유?
  • 요청의 양이 작아 UDP request에 담길 수 있음
  • 3-way handshaking으로 연결을 유지할 필요 없음 (오버헤드 발생)
  • 요청에 대한 손실은 응용 계층에서 제어 가능
  • 데이터 크기가 512바이트(UDP 제한)가 넘을 경우에는 TCP를 사용함

구분	TCP	UDP
연결 방식	연결 지향 (Connection-oriented) - 통신 전에 연결 설정 필요	비연결 지향 (Connectionless) - 연결 설정 없이 바로 통신
신뢰성	높음 - 데이터 전송 보장, 순서 보장, 오류 제어, 흐름 제어	낮음 - 데이터 전송 보장 안 함, 순서 보장 안 함
데이터 순서	순서 보장	순서 보장 안 함
속도/오버헤드	느림 - 연결 설정 및 신뢰성 보장을 위한 추가 오버헤드 발생	빠름 - 오버헤드가 적음
사용 예시	웹 브라우징 (HTTP), 파일 전송 (FTP), 이메일 (SMTP) 등	온라인 게임, 스트리밍 (영상, 음성), DNS 등

 

---

[참고자료]

[TCP] 3 way handshake & 4 way handshake | 👨🏻‍💻 Tech Interview

UDP | 👨🏻‍💻 Tech Interview

TCP/IP (흐름제어/혼잡제어) | 👨🏻‍💻 Tech Interview