TCP·UDP·흐름 및 혼잡 제어·웹 보조 프로토콜

TCP는 순서와 재전송을 관리하는 바이트 스트림, UDP는 기본 전달 기능을 제공하는 데이터그램이다. TCP 연결·확인 응답·흐름 제어·혼잡 제어를 구분하고 DNS·HTTP·DHCP·ARP·ICMP의 역할을 웹 통신 흐름에 연결한다.

그림으로 확인하기

좌우로 이동해 그림을 확인하세요.그림 크게 보기

TCP와 UDP가 제공하는 서비스

전송 계층은 네트워크 계층의 호스트 간 전달을 바탕으로 응용 프로그램 사이의 통신을 지원한다. TCP와 UDP는 출발지·목적지 포트 번호를 사용하여 데이터를 적절한 통신 종단에 전달한다.

TCP에서 100바이트를 두 번 보냈다고 수신 측이 반드시 100바이트씩 두 번 읽는 것은 아니다. 200바이트를 한 번에 읽거나 여러 번에 나누어 읽을 수 있으므로, 응용 메시지의 끝은 길이 필드·구분자·고정 길이 같은 응용 계층 규칙으로 판별해야 한다.

UDP의 데이터그램 경계 보존은 모든 데이터그램이 도착한다는 뜻이 아니다. 도착한 데이터그램도 수신 버퍼가 충분하지 않으면 API에 따라 잘릴 수 있다. UDP 위에 재전송·순서 제어를 추가하는 것은 가능하므로, “UDP를 사용하면 응용도 반드시 신뢰성이 없다”는 단정은 틀리다.

TCP도 상대의 영구 장애까지 극복하여 데이터를 무조건 전달하는 것은 아니다. 실패하면 응용에 오류를 알릴 수 있으며, TCP의 확인 응답은 상대 TCP의 수신 확인이지 상대 업무의 저장·결제 완료 확인이 아니다. 또한 TCP 자체는 데이터 암호화를 제공하지 않는다.

포트와 헤더를 읽는 기준

IP 주소와 포트 번호

IP 주소는 IP 통신에서 인터페이스와 경로를 식별하는 데 사용하고, 포트 번호는 해당 호스트에서 전송 계층 통신 종단을 구분하는 데 사용한다. 포트 필드는 TCP·UDP 모두 16비트이므로 숫자 범위는 0~65535다. 이 범위의 모든 번호를 일반 응용이 같은 조건으로 사용할 수 있다는 뜻은 아니다.

TCP 연결은 일반적으로 출발지 IP·출발지 포트·목적지 IP·목적지 포트의 조합으로 구분한다. 전송 프로토콜까지 포함하면 흔히 5-튜플이라고 한다. 따라서 여러 클라이언트가 같은 서버의 TCP 443번 포트에 동시에 연결할 수 있다. TCP 53번과 UDP 53번은 전송 프로토콜이 다른 통신 종단이다.

대표 포트는 서비스 판별에 도움이 되지만, 포트 번호만으로 실제 응용·암호화 여부·안전성을 확정할 수는 없다.

TCP 헤더의 주요 필드

의사 헤더는 출발지·목적지 IP 등 전송에 관련된 정보를 체크섬 계산에 포함하기 위한 것이다. TCP 헤더 앞에 독립된 의사 헤더를 붙여 전송한다는 뜻은 아니다.

주요 플래그는 SYN(순서 번호 동기화), ACK(확인 응답 번호 유효), FIN(해당 방향의 송신 종료), RST(연결 초기화·중단), PSH(데이터 전달 촉진), URG(긴급 포인터 유효)다. PSH를 응용 메시지의 끝 표시로 사용한다고 일반화하면 안 된다.

UDP 헤더는 출발지 포트·목적지 포트·길이·체크섬의 네 필드로 이루어지며 각 필드는 2바이트다. UDP 길이에는 UDP 헤더와 UDP 데이터가 포함된다. 일반적인 IPv4 UDP에서는 체크섬을 생략할 수 있지만, IPv6 UDP에서는 기본적으로 필수다. 특수한 터널링 예외를 일반 UDP 규칙으로 확대하지 않는다.

TCP 순서 번호와 누적 확인 응답

바이트 수로 계산한다

TCP의 순서 번호와 확인 응답 번호는 32비트이며, 한 연결의 양방향이 각각 독립된 번호 공간을 사용한다. 계산에서는 문제에 제시된 송신 방향을 고정한다.

데이터의 시작 순서 번호 = S
데이터 길이 = L바이트

데이터가 차지하는 번호 = S ~ S + L - 1
이 구간까지 빈틈없이 수신했을 때 다음 확인 응답 번호 = S + L

SYN과 FIN은 각각 순서 번호 공간을 1만큼 사용한다. 데이터가 없고 SYN·FIN도 없는 순수 ACK는 순서 번호를 소비하지 않는다. 큰 번호가 경계를 넘는 문제에서는 2^32를 법으로 순환하지만, 아래 예제에서는 번호 순환이 없다고 가정한다.

순서 번호 1001에서 300바이트를 보냈다면 바이트 번호는 1001~1300이다. 앞선 데이터도 모두 수신했다면 확인 응답 번호는 1301이다. 데이터 길이가 300이라고 확인 응답 번호가 300이 되는 것은 아니다.

뒤의 데이터가 먼저 도착한 경우

확인 응답 번호가 A라면 그 번호보다 앞선 바이트를 연속해서 받았다는 뜻이다. 이를 누적 확인 응답이라고 한다.

다음 예제는 수신자가 순서가 뒤바뀐 데이터를 버퍼에 보관하고, 각 수신 사건 직후 확인 응답을 보낸다고 가정한다. 실제 TCP는 지연 ACK 등으로 ACK 전송 횟수가 달라질 수 있다.

두 번째 사건에서 높은 번호의 데이터가 도착해도 중간이 비었으므로 ACK를 1701로 전진시킬 수 없다. 세 번째 사건에서 빈 구간이 채워지면 이미 보관한 뒤쪽 데이터까지 이어져 ACK가 1701로 이동한다.

선택적 확인 응답인 SACK은 연속 구간 뒤에서 이미 받은 데이터 구간을 추가로 알리는 기능이다. SACK을 사용해도 TCP 헤더의 기본 ACK 필드가 누적 확인 응답이라는 의미는 바뀌지 않는다.

연결 설정과 종료

3-way handshake

클라이언트 초기 순서 번호가 1000, 서버 초기 순서 번호가 5000이고, 세 교환에 응용 데이터가 없다고 가정한다.

클라이언트는 SYN을 보낸 뒤 SYN-SENT, 서버는 수신 대기인 LISTEN에서 SYN-RECEIVED로 진행한다. 클라이언트가 정상 SYN+ACK를 처리하고 ACK를 보내면 클라이언트는 ESTABLISHED가 되며, 서버는 그 ACK를 받아 ESTABLISHED가 된다. 상태는 양 끝에 각각 존재하므로 항상 동시에 같은 상태가 되는 것은 아니다.

세 번의 교환은 양방향 초기 순서 번호와 연결 상태를 맞추기 위한 것이다. 사용자 인증이나 서버 인증서를 검증하는 절차와는 다르다. 세 번째 ACK에는 응용 데이터가 함께 실릴 수 있으므로 항상 제어 정보만 담긴 독립 패킷이라고 단정하지 않는다.

종료는 방향별로 이루어진다

FIN은 “내가 보내는 방향의 데이터가 끝났다”는 의미다. FIN을 받은 쪽이 반대 방향으로 더 보낼 데이터가 있다면 계속 보낼 수 있다. 이것이 반쪽 닫힘, 즉 half-close다.

A가 먼저 종료하고 B가 나중에 종료하며, FIN과 ACK를 각각 따로 보내는 정상 사례는 다음과 같다.

이 예제가 흔히 말하는 4-way 종료다. ACK와 FIN을 결합하거나 양쪽이 동시에 종료할 수 있으므로 정상 종료가 언제나 정확히 네 패킷이라는 규칙은 아니다. RST를 이용한 중단도 FIN을 이용한 정상 종료와 구분한다.

TIME-WAIT의 목적

최종 ACK가 손실되면 상대가 FIN을 재전송할 수 있다. TIME-WAIT는 이에 다시 ACK를 보낼 수 있게 하고, 이전 연결의 지연된 세그먼트가 후속 연결과 혼동되는 위험을 줄인다. 기본적인 대기 기준은 최대 세그먼트 수명 MSL의 두 배인 2MSL이다. MSL을 모든 운영체제에 공통된 특정 초 단위 값으로 외우지 않는다.

TIME-WAIT는 정상적인 상태다. 앞의 사례에서는 능동 종료자인 A가 들어가지만, A가 항상 웹 클라이언트인 것은 아니다. 동시 종료에서는 양쪽 모두 들어갈 수 있다. CLOSE-WAIT는 상대의 송신 종료를 받은 뒤 자기 응용이 송신을 끝내기를 기다리는 상태이므로 TIME-WAIT와 원인이 다르다.

흐름 제어와 슬라이딩 윈도

수신자를 보호하는 흐름 제어

송신 속도가 수신 응용의 처리 속도보다 빠르면 수신 버퍼가 부족해질 수 있다. TCP 수신자는 수신 윈도 rwnd를 광고하여 받아들일 수 있는 범위를 알린다. 송신자는 확인 응답에 따라 이미 보낸 범위와 새로 보낼 수 있는 범위를 이동시킨다. 이런 방식을 슬라이딩 윈도라고 한다.

윈도는 “한 패킷의 크기”나 “초당 전송 속도”가 아니다. 여기서 TCP 윈도는 기본적으로 아직 확인되지 않은 데이터를 얼마나 둘 수 있는가와 관련된 바이트 단위 제한이다.

수신 윈도가 0이 되었다고 연결이 즉시 끊어지는 것은 아니다. 수신 응용이 버퍼를 비워 윈도가 다시 열릴 수 있으며, TCP는 0 윈도 탐사를 통해 상태 갱신을 확인할 수 있다. 이 탐사는 혼잡에 따른 재전송이나 유휴 연결 확인용 keepalive와 목적이 다르다.

수신 윈도와 혼잡 윈도를 함께 적용한다

혼잡 윈도 cwnd는 송신자가 네트워크 혼잡을 고려해 관리하는 제한이다. TCP 헤더의 Window 필드로 상대에게 전달되는 수신 윈도와 다르다.

일반적인 기본 계산에서 다른 제한과 재전송 복구의 특수 규칙을 제외하면 다음과 같이 판단한다.

W = min(rwnd, cwnd)
F = 이미 보냈지만 아직 확인되지 않은 데이터량

새로 보낼 수 있는 데이터량 = max(0, W - F)

rwnd=12000바이트, cwnd=8000바이트, 미확인 데이터 F=5000바이트라면 W=8000바이트이고 추가 송신 여유는 3000바이트다. 두 윈도를 더한 20000바이트를 보내는 것이 아니다. 윈도가 줄어 F보다 작아져도 계산 결과를 음수 송신량으로 해석하지 않고 새 데이터 송신 여유가 없다고 판단한다.

MSS와 MTU

MSS는 한 TCP 세그먼트의 데이터 부분 크기와 관련된 값이고, 링크 MTU는 해당 링크가 실어 나를 수 있는 IP 패킷 크기를 제한한다. IPv4 헤더 20바이트, TCP 헤더 20바이트, IP 옵션·TCP 옵션·추가 캡슐화가 없고 MTU가 1500바이트인 단순 사례에서는 세그먼트에 담을 수 있는 데이터가 1460바이트다.

TCP 데이터 최대 크기 = 1500 - 20 - 20 = 1460바이트

모든 연결의 실제 TCP 데이터 크기가 1460바이트인 것은 아니다. 헤더 옵션·경로 MTU·상대가 알린 MSS 등에 영향을 받는다. TCP가 응용 데이터를 나누는 세그먼트화와 IP 패킷을 나누는 단편화도 서로 다른 계층의 동작이다.

혼잡 제어와 손실 복구

네트워크를 보호하는 혼잡 제어

여러 송신자가 공유 경로에 과도한 데이터를 보내면 라우터 등의 대기열이 길어지고 손실과 지연이 늘어난다. 수신 버퍼가 넉넉해도 이 현상은 발생할 수 있다. 혼잡 제어는 이러한 경로의 과부하를 줄이기 위한 전송 조절이다.

반대로 경로가 한산해도 수신 응용이 느리면 흐름 제어가 필요하다. 패킷 손실은 혼잡을 추정하는 신호가 될 수 있지만, 모든 손실이 반드시 혼잡 때문인 것은 아니다.

고전 TCP 혼잡 제어의 네 기능

다음은 기본적인 Reno 계열 설명이다. 실제 구현의 초기 윈도·증가 방식·손실 반응이 모두 하나의 고정 규칙인 것은 아니므로 계산 문제에서 지정한 알고리즘과 초기 조건을 따른다.

RTT는 데이터를 보내고 관련 확인 응답을 받기까지의 왕복 시간이다. ssthresh는 느린 시작과 혼잡 회피를 구분하는 임계값이다.

초기 cwnd=1 MSS, ssthresh=8 MSS, 손실·지연 ACK가 없으며 매 단계에 윈도만큼 보내고 전부 확인받는 단순 모형에서는 다음과 같이 계산할 수 있다. 여기서는 임계값에 도달하면 혼잡 회피로 전환한다고 정한다.

cwnd: 1 → 2 → 4 → 8 → 9 → 10 MSS
      느린 시작       혼잡 회피

이 예제의 초기 1 MSS는 계산을 위한 가정이지 모든 TCP의 고정 초기값이 아니다. “느린 시작”이라는 이름만 보고 선형 증가라고 판단하지 않는다.

오류 검출과 재전송의 구분

오류를 검출했다고 자동으로 원래 데이터를 복원한 것은 아니다. TCP의 신뢰성은 체크섬 하나가 아니라 순서 번호·확인 응답·재전송 등 여러 기능의 결합으로 설명한다.

ARQ의 기본 비교는 다음과 같다. 정지-대기는 한 단위를 보내고 확인을 기다린다. Go-Back-N은 손실된 단위 이후의 미확인 구간을 다시 보내는 방식으로 설명하고, Selective Repeat는 필요한 단위만 선택해 재전송한다. 이러한 일반 ARQ 모형과 TCP의 모든 실제 구현을 완전히 같은 것으로 취급하지 않는다.

DNS: 이름을 자원 정보로 해석한다

조회 주체와 계층

DNS는 Domain Name System의 약자로, 도메인 이름에 관한 자원 레코드를 분산 관리하는 응용 계층 시스템이다. 주소를 찾는 데 널리 사용하지만 모든 질의 결과가 IP 주소인 것은 아니다.

호스트의 리졸버는 설정된 재귀 리졸버에 조회를 요청할 수 있다. 재귀 리졸버는 캐시가 없으면 루트·최상위 도메인·해당 도메인의 권한 서버로 이어지는 위임 정보를 따라 조회한다. 권한 서버는 자신이 담당하는 영역의 정보에 권한 있는 응답을 제공한다.

재귀 질의는 질의를 받은 서버가 최종 답이나 오류를 구해 응답하도록 요청하는 방식이다. 반복 질의에서는 서버가 자신이 아는 답이나 다음에 물을 서버 정보를 제공하고 질의자가 다음 조회를 수행한다. 일반 사용자의 호스트가 매번 직접 루트 서버부터 전부 조회한다고 단정하지 않는다.

주요 자원 레코드

DNS의 TTL은 자원 레코드의 캐시 유효 시간을 초 단위로 나타낸다. 패킷의 라우터 통과 수명을 다루는 IP의 TTL과는 다르다. TTL=300인 응답을 받은 뒤 120초가 지났다면 단순 계산상 남은 캐시 수명은 180초다. TTL은 서버에서 레코드를 영구 보관하는 기간이나 주소 변경이 전 세계에 전파되는 고정 시간을 뜻하지 않는다.

DNS는 UDP만 사용하는가

일반적인 DNS 서비스의 포트는 UDP·TCP 모두 53번이다. UDP 질의 응답이 널리 쓰이지만, TCP도 지원하며 영역 전송과 잘린 응답 이후 재시도 등에 사용한다. TCP는 이런 사례에만 제한되는 것도 아니다.

따라서 “DNS는 UDP 53번만 사용한다”는 설명은 틀리다. 암호화된 별도 전송 방식까지 고려하면 DNS 통신의 모든 형태가 반드시 평문 53번인 것도 아니다. 여기서는 기본 DNS와 TCP/UDP 사용 구분을 중심으로 이해한다.

HTTP: 자원에 대한 요청과 응답

HTTP와 DNS의 역할 차이

DNS로 통신할 주소를 찾는 일과 HTTP로 자원을 요청하는 일은 다르다. 이름 해석이 성공해도 TCP 연결·TLS 협상·HTTP 처리가 실패할 수 있다. 반대로 캐시나 기존 연결을 사용하면 새 요청마다 DNS 조회와 연결 설정을 모두 반복하지 않을 수 있다.

HTTP 요청에는 메서드·요청 대상·헤더·필요한 경우 본문이 있고, 응답에는 상태 코드·헤더·필요한 경우 본문이 있다. 모든 응답에 본문이 있는 것은 아니다. HEAD에 대한 응답, 204·304 같은 응답은 본문 사용 규칙을 따로 갖는다.

HTTP의 무상태성은 각 요청의 의미를 이전 요청의 처리 상태에 의존하지 않고 해석할 수 있다는 성질이다. TCP 연결을 재사용하지 못한다거나, 로그인 상태를 유지하는 응용을 만들 수 없다는 뜻이 아니다. 응용은 쿠키·세션 식별자 등을 이용해 상태를 관리할 수 있다.

주요 메서드와 멱등성

안전한 메서드는 클라이언트가 서버 상태 변경을 요청하는 의미를 갖지 않는 메서드다. 멱등성은 같은 요청을 여러 번 수행해도 의도한 서버 상태 변화의 효과가 한 번 수행한 것과 같다는 뜻이다.

멱등성을 HTTP 응답 코드가 항상 같다는 뜻으로 읽으면 안 된다. DELETE를 처음 수행한 결과와 다시 수행한 결과의 상태 코드는 다를 수 있다. 또한 안전한 메서드라도 접근 로그 기록과 같은 부수 효과까지 전혀 없다는 뜻은 아니다.

상태 코드

404를 수신했다면 적어도 HTTP 응답을 줄 수 있는 상대까지 통신한 것이다. 다만 그 응답 주체가 중간 프록시일 수도 있으므로 반드시 원본 서버까지 도달했다고 단정하지 않는다.

HTTP 버전과 HTTPS

HTTP/1.1과 HTTP/2는 TCP를 기반으로 사용하고, HTTP/3는 UDP 위에서 동작하는 QUIC을 사용한다. QUIC이 신뢰성·혼잡 제어·보안 기능을 제공하므로 HTTP/3를 “UDP라서 손실된 웹 문서를 복구하지 못하는 방식”이라고 설명하면 틀리다.

일반적인 HTTP 서비스의 기본 포트는 80, HTTPS는 443이다. HTTPS는 HTTP 통신에 TLS 기반 보호를 적용한다. 전통적인 HTTPS 예제는 TCP 연결 뒤 TLS를 협상하지만, HTTP/3의 연결 구조를 같은 단계로 복사하지 않는다. 기본 포트와 다른 포트를 사용할 수도 있다.

DHCP: 주소와 네트워크 설정을 임대한다

DHCPv4의 기본 흐름

DHCP는 호스트에 IP 주소·서브넷 마스크·기본 게이트웨이·DNS 서버 등 네트워크 설정을 전달할 수 있는 응용 계층 프로토콜이다. DHCPv4에서 서버는 UDP 67번, 클라이언트는 UDP 68번을 사용한다. 다음은 주소를 처음 얻는 대표적인 DORA 절차다.

초기 주소 탐색에는 브로드캐스트가 사용되지만 네 메시지가 모든 상황에서 반드시 브로드캐스트인 것은 아니다. 클라이언트 상태·서버 응답 조건·중계 에이전트의 존재에 따라 전달 방식이 달라진다. 주소 갱신을 처음부터 DORA 네 단계를 다시 실행하는 절차로만 설명해서도 안 된다.

라우터는 보통 제한 브로드캐스트를 그대로 다른 네트워크로 전달하지 않는다. DHCP 중계 에이전트는 클라이언트와 다른 네트워크에 있는 서버 사이의 DHCP 메시지를 중계한다. 중계를 사용한다고 모든 브로드캐스트가 라우터를 통과하도록 바뀌는 것은 아니다.

ARP와 ICMP: 주소 해석과 오류 통지

ARP는 같은 링크의 다음 홉을 찾는다

ARP는 IPv4 주소에 대응하는 링크 계층 주소를 알아내는 프로토콜이다. Ethernet에서는 대개 ARP 요청을 브로드캐스트하고 대상이 응답하며, 결과를 ARP 캐시에 저장할 수 있다. ARP가 TCP나 UDP 포트를 사용하는 것은 아니다.

로컬 호스트가 원격 서버에 보낼 때는 먼저 라우팅 판단으로 다음 홉을 결정한다. 같은 서브넷의 목적지라면 그 목적지의 MAC을 찾고, 다른 서브넷이라면 선택한 게이트웨이의 MAC을 찾는다.

호스트:       192.0.2.10/24
게이트웨이:   192.0.2.1
원격 서버:    198.51.100.20

첫 Ethernet 프레임의 목적지 MAC: 게이트웨이의 MAC
IP 패킷의 목적지 주소:           198.51.100.20
ARP로 조회할 IPv4 주소:          192.0.2.1

이 예제는 직접 연결된 일반 Ethernet 네트워크이며 프록시 ARP·터널·NAT를 제외한다. ARP 요청으로 인터넷 끝의 서버 MAC을 직접 찾는 것이 아니다. IPv6는 ARP 대신 ICMPv6 기반의 이웃 탐색을 사용한다.

ICMP는 IP 처리의 제어 정보를 전달한다

ICMP는 IP 처리 중 오류와 진단 정보를 전달한다. IPv4 ICMP는 IP 안에 실리며, TCP·UDP 포트 대신 메시지 유형과 코드를 사용한다. 대표적으로 목적지 도달 불가, 시간 초과, Echo Request·Echo Reply가 있다.

ping은 대표적으로 ICMP 에코 요청과 응답을 이용한다. 경로 추적 도구는 TTL 또는 Hop Limit을 달리한 탐사와 중간 장비의 시간 초과 응답 등을 이용한다. 다만 탐사에 쓰는 상위 프로토콜은 도구·옵션에 따라 UDP·ICMP·TCP일 수 있다.

ICMP가 있다고 IP가 신뢰성 있는 전송을 보장하는 것은 아니다. ICMP 오류 통지가 모든 실패에 대해 반드시 돌아오는 것도 아니다. 방화벽이 에코 응답을 막을 수 있으므로 ping 실패만으로 HTTP 서비스까지 반드시 실패한다고 결론 내리지 않는다.

웹 접속 흐름을 계층별로 해석한다

다음은 IPv4·Ethernet·직접 서버 접속·TCP 기반 HTTPS를 가정한 예제다. 필요한 설정과 캐시가 있으면 일부 단계가 생략될 수 있다.

1. 호스트가 수동 설정 또는 DHCP로 주소·마스크·게이트웨이·DNS 서버 정보를 준비한다.
2. 이름 해석이 필요하면 DNS 캐시를 확인하고 설정된 리졸버에 질의한다. DNS 서버로 패킷을 보내기 위해서도 라우팅과 필요한 ARP가 먼저 수행될 수 있다.
3. 얻은 서버 주소에 대해 경로와 다음 홉을 결정하고, 필요한 링크 주소가 캐시에 없으면 ARP로 알아낸다.
4. 서버와 TCP 연결을 설정한다.
5. TLS를 협상한 뒤 HTTP 요청과 응답을 교환한다.
6. 전송 중 TCP가 순서·재전송·수신 윈도·혼잡 제어를 관리한다. 통신 종료 시에는 연결 재사용 여부와 종료 절차를 따른다.

ARP가 반드시 DNS보다 나중에 딱 한 번 실행되는 것은 아니다. 또한 HTTP/3, 프록시, 기존 연결 재사용을 이 예제와 같은 패킷 순서로 단정하지 않는다.

프로토콜의 책임은 장애를 분류하는 기준이지, 한 현상만으로 실제 원인을 하나로 확정하는 도구는 아니다.