TCP & UDP

DNS가 IP 주소를 알려주면, 장치는 올바른 목적지로 패킷을 보낼 수 있습니다. 하지만 IP는 독립적인 패킷을 네트워크를 통해 이동시킬 뿐이며, 패킷이 도착했는지, 올바른 순서로 도착했는지, 또는 네트워크가 혼잡한지는 추적하지 않습니다.

웹 페이지를 여러 개의 패킷으로 나누면, 일부는 순서가 뒤바뀐 채 도착할 수 있고, 일부는 지연될 수 있으며, 일부는 완전히 유실될 수도 있습니다. 추가적인 조정이 없다면, 수신 애플리케이션은 원래 데이터를 올바르게 복원할 신뢰할 수 있는 방법이 없습니다.

전송 프로토콜은 네 가지 기본 문제를 해결합니다: 순서 보장(데이터를 올바르게 재조립), 신뢰성(유실된 데이터 감지 및 재전송), 다중화(여러 애플리케이션이 하나의 IP 주소를 공유할 수 있게 함), 그리고 혼잡 제어(네트워크가 과부하되지 않도록 방지).

간단히 말해, IP는 “이 패킷은 어디로 가야 하는가?”에 답합니다.
전송 프로토콜은 “이 대화는 어떻게 동작해야 하는가?”에 답합니다.

데이터가 서버의 IP 주소에 도달하면, 운영 체제는 여전히 어떤 프로그램이 이를 처리해야 하는지 결정해야 합니다. 하나의 기계에서 웹 서버, 데이터베이스 서버, SSH 서비스, 그리고 많은 다른 애플리케이션이 동시에 실행될 수 있습니다.

이때 포트 번호가 필요합니다. 포트는 TCP와 UDP 같은 전송 프로토콜에서 사용하는 논리적인 통신 종단점입니다. 이를 통해 시스템은 들어오는 트래픽을 분리하고 올바른 애플리케이션 프로세스에 전달할 수 있습니다.

예를 들어, 포트 80은 일반적으로 HTTP에 사용되고, 포트 443은 HTTPS에, 포트 22는 SSH에 사용됩니다. 보안 웹사이트에 접속할 때 브라우저는 서버의 IP 주소와 포트 443에 연결하여 HTTPS로 통신하고 싶다는 것을 알립니다.

포트가 없다면 한 기계에서는 한 번에 하나의 네트워크 애플리케이션만 실행할 수 있습니다. 포트 덕분에 하나의 IP 주소에서 수천 개의 동시 통신이 가능합니다.

전송 제어 프로토콜(Transmission Control Protocol, TCP)은 완전하고 정확한 데이터 전달이 필요한 애플리케이션을 위해 설계되었습니다. 원시 IP와 달리 TCP는 통신을 개별 패킷이 아니라 연속적인 바이트 스트림으로 처리합니다.

각 데이터 세그먼트에는 시퀀스 번호가 할당됩니다. 수신자는 이 번호를 사용해 애플리케이션에 전달하기 전에 데이터를 올바른 순서로 재정렬합니다. 세그먼트가 누락되면 TCP는 그 간격을 감지하고 재전송을 요청합니다.

TCP에는 흐름 제어도 포함되어 있어, 빠른 송신자가 느린 수신자를 압도하지 않도록 합니다. 이를 위해 슬라이딩 윈도우 메커니즘을 사용해 확인되지 않은 데이터가 동시에 얼마나 많이 전송 중일 수 있는지 제한합니다.

마지막으로 TCP는 혼잡 제어를 구현합니다. 네트워크 상태를 모니터링하고 라우터에 과부하가 걸리지 않도록 전송 속도를 조정합니다. 이를 통해 네트워크 전체의 안정성을 보호하면서도, 조건이 허용될 때는 처리량을 최대화합니다.

TCP는 연결 지향적이므로, 데이터 전송이 시작되기 전에 양쪽이 통신에 동의해야 합니다. 이 과정은 클라이언트와 서버가 모두 데이터를 주고받을 준비가 되어 있고 가능하다는 것을 보장합니다.

먼저, 클라이언트는 SYN (synchronize) 패킷을 보냅니다. 이 패킷은 초기 시퀀스 번호를 제안하고 연결을 열고자 하는 의사를 알립니다.

둘째, 서버는 SYN-ACK로 응답합니다. 이는 클라이언트의 요청을 확인하고 서버의 초기 시퀀스 번호를 제공합니다.

마지막으로, 클라이언트는 서버의 시퀀스 번호를 수신했음을 확인하기 위해 ACK를 보냅니다. 이 시점에서 양쪽은 시퀀스 번호를 동기화했으며 연결이 공식적으로 설정됩니다.

이 핸드셰이크가 완료된 후에야 TCP는 애플리케이션 데이터를 전송하기 시작합니다.

TCP는 데이터 스트림의 각 바이트에 sequence number를 할당합니다. 이를 통해 수신자는 누락되었거나 순서가 바뀐 세그먼트를 감지하고 원래 메시지를 올바르게 재구성할 수 있습니다.

수신자는 다음에 기대하는 바이트를 나타내는 ACK (acknowledgment) 번호를 돌려보냅니다. 송신자가 일정 시간 안에 ACK를 받지 못하면, 해당 세그먼트가 손실되었다고 가정합니다.

손실이 감지되면 TCP는 retransmission을 수행하여 누락된 데이터를 다시 보냅니다. 이 메커니즘은 혼잡이나 네트워크 불안정으로 인해 패킷이 드롭되더라도 신뢰성을 보장합니다.

TCP는 흐름 제어를 위해 sliding window도 사용합니다. 모든 패킷마다 ACK를 기다리는 대신, 송신자는 허용된 윈도우 크기 내에서 여러 세그먼트를 전송할 수 있습니다. 이는 효율성을 높이면서도 엄격한 전달 보장을 유지합니다.

사용자 데이터그램 프로토콜(UDP)는 연결 없는 프로토콜입니다. TCP와 달리 데이터를 보내기 전에 핸드셰이크를 수행하지 않습니다. 송신자는 단순히 패킷을 목적지 IP와 포트로 전송합니다.

UDP는 신뢰성을 위해 시퀀스 번호를 추적하지 않고, 승인을 기다리지 않으며, 손실된 패킷을 재전송하지도 않습니다. 패킷이 손실되면 그대로 사라집니다.

이러한 조정 메커니즘을 제거했기 때문에 UDP는 훨씬 더 낮은 오버헤드와 지연시간을 가집니다. 따라서 라이브 스트리밍, 온라인 게임, DNS 쿼리처럼 완벽한 전달보다 속도가 더 중요한 사용 사례에 적합합니다.

요약하면, UDP는 신뢰성보다 성능과 간단함을 우선합니다.

TCP는 데이터가 누락되거나 손상되면 기능이 깨지는 애플리케이션에 이상적입니다. 웹 페이지, API, 파일 다운로드, 이메일은 모두 완전하고 올바른 순서의 데이터를 필요로 합니다. 단 하나의 바이트만 빠져도 결과가 손상될 수 있습니다.

UDP는 가끔 패킷이 손실되어도 괜찮은 애플리케이션에 더 적합합니다. 실시간 비디오, 음성 통화, 게임, 그리고 DNS 같은 작은 상태 비저장 쿼리는 완벽함보다 속도를 우선합니다. 재전송을 기다리면 눈에 띄는 지연이 생깁니다.

핵심 판단 기준은 이것입니다:
정확성과 완전성이 필수라면 TCP를 사용하세요.
응답성과 낮은 지연 시간이 중요하다면 UDP가 더 적합할 수 있습니다.

대상 포트가 닫혀 있거나 방화벽에 의해 차단되어 있으면, 서버는 즉시 connection refused 메시지로 응답할 수 있습니다. 이는 해당 머신에 도달할 수는 있지만, 그 포트에서 동작 중인 애플리케이션이 없다는 뜻입니다.

클라이언트가 SYN을 보냈지만 SYN-ACK를 끝내 받지 못하면, 연결 시도는 결국 timeout 됩니다. 이는 보통 서버가 다운되었거나, 도달할 수 없거나, 경로상의 방화벽에 의해 필터링되고 있음을 의미합니다.

패킷 손실이 높으면 TCP는 누락된 확인 응답을 감지하고 retransmissions를 수행합니다. 신뢰성은 유지되지만, 성능은 크게 저하됩니다.

혼잡이 심할 때 TCP는 혼잡 제어 알고리즘을 통해 전송 속도를 줄입니다. 연결은 계속 유지되지만, 처리량은 감소하고 지연 시간은 증가합니다.