본문으로 건너뛰기

TCP와 UDP

TCP/UDP 면접 질문 및 답변​

TCP와 UDP의 주요 차이점은 무엇인가요?​

TCP는 연결형 프로토콜로, 3-way handshake 과정을 통해 서버와 클라이언트 간 연결을 설정한 후 데이터를 전송합니다. TCP는 데이터가 손실되거나 순서가 바뀌었을 경우 이를 복구하거나 재조립하여 신뢰성을 보장합니다. 반면 UDP는 비연결형 프로토콜로, 연결 설정 없이 데이터를 전송합니다. 이로 인해 속도가 빠르지만 데이터의 신뢰성이나 순서를 보장하지 않습니다. 따라서 TCP는 신뢰성이 중요한 애플리케이션에 적합하고, UDP는 실시간성이 중요한 애플리케이션에 적합합니다.

TCP의 3-way handshake 과정에 대해 설명해 주세요.​

TCP의 3-way handshake는 서버와 클라이언트 간 연결 설정을 위한 과정입니다.

1단계: SYN (클라이언트 → 서버) - 클라이언트가 서버로 SYN 패킷을 전송합니다. 이 패킷에는 클라이언트가 생성한 초기 시퀀스 번호(예: Seq=1000)가 포함되어 있습니다. 이는 연결 요청을 의미합니다.

2단계: SYN + ACK (서버 → 클라이언트) - 서버는 클라이언트의 요청을 수락하고, SYN + ACK 패킷을 보냅니다.

3단계: ACK (클라이언트 → 서버) - 클라이언트는 서버의 응답을 확인한 뒤, ACK 패킷을 보냅니다. 이 패킷이 도착하면 연결이 수립되고, 양측이 데이터를 주고받을 준비를 마칩니다.

UDP는 신뢰성이 없다고 하는데, 이를 보완하기 위해 애플리케이션 수준에서 어떤 방법을 사용할 수 있을까요?​

UDP는 비연결형 프로토콜로, 수신 여부를 확인하지 않기 때문에 데이터가 유실되거나 순서가 어긋날 수 있습니다. 이를 보완하기 위해 애플리케이션 수준에서, 수신자가 ACK를 보내고, 송신자가 일정시간 이후까지 ACK를 받지 못 하면 데이터를 다시 보내는 방법이 있습니다. 비디오나 음성 스트리밍에서는 손실된 패킷을 재전송하지 않고, 이전 데이터로 보완하거나 보간할 수도 있습니다. 또한, 데이터 패킷에 체크섬을 추가해 데이터 손상을 감지하고, 손상된 데이터를 재요청하는 방식도 사용할 수 있습니다.

그럼 그냥 TCP 쓰면 되는 거 아님? 왜 UDP 고집하지?

위와 같은 방식들을 사용하면 기능적으로 TCP와 유사해질 수 있다. 하지만 여전히 다른 점이 있다.

  • TCP처럼 연결 설정(3-way handshake)이나 과도한 재전송을 강제하지 않아 여전히 지연 시간을 줄일 수 있다.
  • 개발자가 필요한 신뢰성 수준만 선택적으로 구현할 수 있다. TCP는 프로토콜 자체에 신뢰성과 흐름 제어가 포함되어 있어, 필요하지 않아도 모든 기능이 동작하지만 UDP 기반 시스템은 필요한 기능만 구현할 수 있어서 더 효율적이다.
  • TCP는 연결 설정과 유지에 따른 오버헤드가 존재하지만, UDP는 연결 설정이 없고 필요 없는 기능을 제거한 상태에서 동작하므로 가벼운 통신이 가능하다.
  • UDP는 TCP와 달리 멀티캐스트나 브로드캐스트를 지원한다.

TCP의 흐름 제어와 혼잡 제어의 차이점에 대해 설명해주세요.​

흐름 제어는 송신 측이 수신 측의 처리 속도를 초과하지 않도록 데이터를 조절하는 메커니즘이고, 혼잡 제어는 네트워크 혼잡 상태를 감지하고 혼잡 윈도우 크기를 동적으로 조정하여 트래픽 혼잡을 방지하거나 완화하기 위한 메커니즘입니다.

흐름 제어 더 알아보기

흐름 제어는 송신 측이 수신 측의 처리 속도를 초과하지 않도록 데이터를 조절하는 메커니즘이다. 수신 측은 Receive Window 값을 통해 수용 가능한 데이터 크기를 송신 측에 전달하고, 송신 측이 이 값을 기준으로 데이터 전송 속도를 조절한다. 참고로 Receive Window는 TCP 헤더의 Window Size 필드에 저장된 값으로, 수신 측이 현재 수용 가능한 데이터의 최대 크기를 나타낸다.

TCP의 TIME_WAIT 상태란 무엇인가요? 왜 필요하며, 어떤 문제를 방지하기 위한 것인지 설명해주세요.​

TIME_WAIT는 TCP 연결이 종료된 후 연결 종료를 시작한 측이 일정 시간동안 대기하는 상태입니다. 이유는, 네트워크에서 지연된 패킷이 도착할 수 있는데, 기다리지 않고 연결 종료 후 즉시 해당 포트를 재사용하면 이후에 새로 생성된 연결이 이전 연결의 패킷과 혼동될 수 있기 때문입니다. TIME_WAIT 상태 동안 해당 포트는 사용되지 않으므로 이러한 문제를 방지합니다. 또한 상대방이 마지막 ACK를 받지 못해 FIN 패킷을 다시 보낼 경우, TIME_WAIT 상태에서 이를 처리할 수 있습니다.

경고

연결 종료가 많이 발생하면 TIME_WAIT 상태의 소켓이 증가해 포트 부족 문제가 생길수도 있다.

TCP와 UDP의 헤더 구조를 비교하고, 각각의 필드가 어떤 역할을 하는지 설명해 주세요.​

TCP 헤더 구조​

  • 20~60바이트 크기로 가변적
  • Source Port / Destination Port: 송신 측과 수신 측 포트 번호.
  • Sequence Number: 데이터 순서를 나타내는 번호.
  • Acknowledgment Number: 수신한 데이터에 대한 확인 응답 번호.
  • Flags: TCP의 상태 제어를 위한 플래그(SYN, ACK, FIN 등).
  • Window Size: 흐름 제어를 위한 수신 윈도우 크기.
  • Checksum: 데이터 무결성 검사를 위한 값.
  • Options: 선택적 필드로, 연결 성능 향상을 위한 추가 정보.

UDP 헤더 구조​

  • 고정 크기 8바이트
  • Source Port / Destination Port: 송신 측과 수신 측 포트 번호.
  • Length: UDP 헤더와 데이터의 총 길이.
  • Checksum: 데이터 무결성 검사를 위한 값.

요약​

TCP 헤더는 더 많은 필드를 포함하여 연결 상태를 유지하고 데이터 신뢰성을 보장합니다. 하지만 UDP 헤더는 데이터 전송을 위해 포트번호, 길이, 체크섬의 최소한의 정보만을 포함하며, 연결을 설정하거나 데이터 순서를 보장하는 기능이 없습니다.

TCP에서 Retransmission(재전송)이 발생하는 이유는 무엇이며, 이를 감지하기 위한 메커니즘에는 어떤 것들이 있나요?​

TCP에서 재전송은 데이터 패킷이 손실되거나 손상되어 수신 측에서 확인 응답을 받지 못했을 때 발생합니다.

이를 감지하기 위해 타임아웃, 중복 ACK 감지, SACK 등의 메커니즘을 사용합니다.

  • 타임아웃: 송신 측이 데이터를 보낸 후 RTO 시간 동안 ACK를 받지 못하면 패킷 재전송. 비교적 느리지만 신뢰성이 높다.
  • 중복 ACK 감지: 수신 측에서 동일한 ACK를 세 번 연속으로 보내면 송신 측에서는 해당 패킷이 손실되었음을 감지하고 재전송. (만약 패킷 #3이 손실되면 수신 측이 패킷 #2에 대한 ACK를 계속 보내게 된다.)
  • SACK: SACK 옵션이 활성화 되어있으면 수신 측에서 송신 측에게 손실되지 않은 패킷 범위를 알려준다. 따라서 송신 측은 손실된 패킷만 선택적으로 재전송할 수 있다. 이는 네트워크 리소스를 절약하며, 대규모 손실 발생 시에도 효율적이다.

UDP가 비연결형 프로토콜인데도 DNS에 사용되는 이유는 무엇인가요?​

DNS 응답은 보통 512바이트 이하로 매우 작기 때문에 UDP로 충분히 처리할 수 있습니다. 따라서 요청과 응답이 더 빠르며 오버헤드가 낮은 UDP를 사용합니다. 이는 DNS 서버가 많은 요청을 처리할 때 성능에 중요한 역할을 합니다.

DNS는 요청이 실패했을 때 클라이언트가 재요청을 보내는 방식으로 작동하기에 UDP의 데이터 손실 가능성도 딱히 문제가 되지 않습니다.

정보

DNS가 항상 UDP만 사용하는 것은 아니다. 다음과 같은 경우에는 TCP를 사용한다.

  1. 응답 크기가 512바이트를 초과하는 경우
  2. 존 전송(Zone Transfer): DNS 서버 간에 도메인 정보 데이터베이스를 동기화 할 때
  3. UDP 실패시: TCP로 응답 재전송

TCP 연결을 종료할 때 4-way handshake가 필요한 이유는 무엇인가요? 그리고 그 과정에서 어떤 패킷들이 교환되나요?​

4-way handshake는 연결 종료를 안전하게 수행하고, 데이터 전송이 완전히 완료되었는지 확인하기 위해 필요합니다.

이때 FIN과 ACK 패킷을 교환하고, 종료 후에는 TIME_WAIT 상태를 통해 네트워크 안정성을 보장합니다.

TCP에서 사용하는 시퀀스 번호의 역할은 무엇인가요? 왜 필요하며, 이를 통해 TCP가 어떤 문제를 해결하나요?​

시퀀스 번호는 TCP 연결을 수립할 때 생성되는 임의의 난수입니다.

이후 전송되는 데이터 패킷에 시퀀스 번호가 포함되며, 각 데이터 패킷의 시작 바이트 위치를 나타냄으로써 순서를 보장하고, 이전 연결에서 남아 있는 지연된 패킷과 현재 연결의 패킷을 구분하기도 합니다. 또한 시퀀스 번호를 사용해 수신 측이 누락된 패킷을 감지할 수 있으며, 송신 측에서 이를 재전송 할 수 있습니다.

요약​

TCP의 시퀀스 번호는 데이터의 순서 보장, 중복 방지, 손실 복구를 가능하게 하며, 이를 통해 TCP의 신뢰성을 보장할 수 있습니다.

추가 점검 포인트​

심화 개념​

  1. TCP의 혼잡 제어 알고리즘(Slow Start, Congestion Avoidance 등)
  2. UDP와 TCP의 포트 충돌이나 잘못된 재전송 처리 같은 문제가 발생했을 때 어떻게 해결할 수 있는가?
  3. TLS가 TCP 위에서 어떻게 작동하는가?

구현 경험​

  1. TCP 소켓 프로그래밍에서 클라이언트와 서버를 구현해 본 경험이 있는가
  2. UDP를 사용해 데이터 손실을 보완하는 시스템을 설계해 본 적이 있는가
  3. 패킷 캡처 도구(예: Wireshark)를 사용해 TCP/UDP 패킷을 분석해 본 적이 있는가