TCP·UDP·DNS·HTTP·TLS 프로토콜 분석

참조모델·캡슐화·Ethernet·IPv6 전달 경계와 시간초과·재시도·멱등성과 부분실패에서 관찰 위치와 재시도의 책임을 먼저 연결한다. TCP 바이트·윈도, DNS 캐시, 인증서 검증 축은 서로 다른 기준으로 판정한다.

0. 패킷 한 줄은 대화의 한 장면일 뿐이다

패킷 분석기에서 SYN, ACK, 200 같은 값을 찾는 일은 어렵지 않다. 어려운 것은 그 값을 누가 누구에게, 어떤 상태에서, 무엇을 기대하며 보냈는지 판단하는 일이다. 같은 ACK도 연결 수립, 데이터 확인, 종료 과정에서 의미가 다르고, 응답이 없다는 증상도 DNS 질의 실패·TCP 연결 실패·TLS 인증 실패·HTTP 처리 지연으로 갈린다.

프로토콜 분석은 필드를 많이 외우는 기술이 아니다. 먼저 대화의 양 끝과 방향을 식별하고, 메시지를 시간순으로 놓은 뒤, 명세가 정한 상태와 기대 응답에 맞는지 확인한다. 이 절은 TCP·UDP 위에서 DNS, HTTP와 TLS가 어떻게 이어지는지를 동일한 읽기법으로 설명한다.

프로토콜 분석: 필드·상태·시간·방향을 규칙과 대조한다

프로토콜 분석은 포착한 메시지의 필드, 대화 상태, 시간간격과 방향을 해당 프로토콜의 형식·순서·오류 처리 규칙과 대조하여 정상 동작과 위반·실패 경계를 판단하는 일이다. 앞 절의 참조모델·PDU·전달경계를 바탕으로 실제 대화 상태를 읽는다.

분석 결과는 정상/비정상 한 단어가 아니라 다음 네 문장으로 남긴다.

1. 관찰: 어느 지점·방향·시간에 어떤 원시 필드가 보였다.
2. 기대: 현재 상태에서 명세상 어떤 다음 메시지나 상태가 기대된다.
3. 차이: 실제 메시지·시간·반복이 기대와 어떻게 달랐다.
4. 한계: 암호화·포착 누락·내부 상태처럼 이 증거만으로 확인할 수 없는 것이 있다.

전체에서 어디인가: 이름에서 보호된 응답까지

사용자가 https://service.example 주소를 지정하면 DNS로 사용할 주소를 찾고, 대표 TCP 경로에서 연결·순서·확인·윈도·재전송 상태를 만든다. 그 바이트 흐름 위의 TLS 합의·인증이 보호채널을 제공하고 HTTP가 메서드·대상·필드·상태·콘텐츠 의미를 주고받는다. DNS 캐시와 질의, TCP 수립과 종료를 각각 실제 대화로 확인한다. DNS의 UDP/TCP는 실제 포착을 따르며, 아래 HTTP/3의 QUIC 경계는 이 대표 TCP 경로와 구분한다.

이 그림은 HTTPS의 대표 경로다. 모든 HTTP가 반드시 TCP를 사용한다는 뜻은 아니다. HTTP/3은 QUIC 위에서 HTTP 의미를 전달한다. 반대로 DNS도 한 전송방식으로 고정해 추측하지 않고 실제 캡처의 전송 프로토콜과 포트를 확인한다.

먼저 알아둘 것

프로토콜은 메시지 형식뿐 아니라 순서·시간·오류 처리의 약속이며, 송신 측은 상위 PDU를 아래 계층에 캡슐화하고 수신 측은 역순으로 해석하고, 이름·네트워크 주소·링크 주소·포트는 서로 다른 대상을 구별한다. 시간초과는 기다림을 끝내는 정책이고 재시도는 새 시도이므로, 중복 실행이 안전한지는 별도의 멱등성 조건을 확인해야 한다. 이 기초는 앞의 프로토콜·계층·주소·이름·경로, 시간초과·재시도·멱등성과 부분실패, 참조모델·캡슐화·Ethernet·IPv6 전달 경계에서 배웠다.

1. TCP와 UDP: 종단 프로그램 사이 전달방식이 다르다

TCP: 상태를 가진 신뢰 가능한 바이트 스트림

전송 제어 프로토콜(Transmission Control Protocol, TCP)은 두 종단의 포트 사이에 연결 상태를 만들고, 순서번호·확인응답·재전송·흐름제어를 사용해 신뢰 가능한 순서 있는 바이트 스트림을 제공하는 전송 프로토콜이다. 바이트 스트림은 응용이 보낸 메시지 경계를 보존한다는 뜻이 아니다. 한 번 보낸 데이터가 여러 TCP 세그먼트로 나뉘거나 여러 번의 쓰기가 한 읽기로 보일 수 있으므로 응용 프로토콜이 자기 메시지 경계를 정의해야 한다.

포트 번호는 한 호스트 안에서 전송 접점을 구별하는 값이다. 양 끝 IP 주소와 포트의 네 값, 즉 출발 IP·출발 포트·목적 IP·목적 포트를 4-tuple(네 값 묶음)이라고 한다. TCP 안에서는 이 묶음과 방향으로 대화 후보를 구별한다. 주소변환(Network Address Translation, NAT)은 네트워크 경계에서 관찰되는 IP 주소나 포트 값을 바꾸는 기능이다. NAT·중계 전후에는 같은 대화의 4-tuple이 달라질 수 있으므로 포착 위치와 변환 기록을 함께 본다.

순서번호는 TCP 바이트 흐름의 위치를 나타내고, 확인번호는 수신자가 다음에 기대하는 순서번호를 누적해 알린다. TCP 머리의 Window는 수신자가 받아들일 여유를 알리는 수신 윈도다. 혼잡 윈도는 네트워크 혼잡을 통제하려고 송신자가 내부에 유지하는 제한이며 TCP 머리 필드로 직접 전송되지 않는다.

TCP 머리는 다섯 질문으로 읽는다

Checksum, Data Offset, Options 같은 필드도 중요하지만 목적에 맞게 연다. 분석기가 표시한 relative sequence number는 보기 쉽게 기준을 바꾼 값일 수 있으므로 원시 순서번호와 구분한다. ACK라는 말도 제어 비트와 확인번호를 함께 가리킬 수 있어 답안에는 어느 쪽인지 적는다.

연결 수립과 종료: 번호보다 상태 전이를 읽는다

SYN은 양쪽이 초기 순서번호와 선택사항을 맞추며 연결상태를 만드는 사건이다. SYN과 FIN은 순서번호 공간 하나를 소비하므로 위 예의 확인번호가 1 증가한다. 데이터 확인번호는 마지막으로 본 패킷 번호가 아니라 다음에 기대하는 바이트 위치다.

종료는 양 방향을 독립적으로 닫을 수 있어 흔히 네 세그먼트로 그리지만, ACK와 FIN이 합쳐지거나 재전송될 수 있다. 따라서 실제 캡처가 언제나 정확히 네 줄이어야 한다고 판정하지 않는다. RST는 정상 종료 교환과 달리 연결을 즉시 중단하는 신호이므로 앞선 상태와 송신 주체를 확인한다.

FIN은 한 방향의 끝이다. 클라이언트가 FIN을 보냈어도 서버는 자기 방향을 닫기 전까지 남은 데이터를 보낼 수 있다. 이를 반닫힘(half-close)이라고 한다. 예를 들어 클라이언트가 seq 7001부터 데이터 300바이트와 FIN을 함께 보내고 그 앞까지 공백이 없다면 서버의 다음 기대번호는 7001+300+1=7302다. 데이터 없는 순수 ACK는 순서번호 공간을 소비하지 않는다. 이 확인은 바이트와 종료 신호의 수신이며 응용의 업무 처리 완료를 뜻하지 않는다.

손실을 복구한다: 순서·누적 ACK·재전송 타이머

TCP 재전송은 보낸 순서범위가 확인되지 않았다고 판단해 같은 바이트 범위를 다시 보내는 동작이다. 송신자는 확인되지 않은 바이트를 보관하고, 수신자는 순서번호로 다음 기대 위치를 판단한다. 중간 바이트가 빠지면 이후 데이터가 도착해도 같은 다음 기대번호를 반복해서 알릴 수 있다. 송신자는 재전송 시간초과 또는 손실을 시사하는 ACK 패턴에 따라 누락 데이터를 다시 보낸다. 같은 순서범위가 다시 나타났다고 모두 네트워크 중복은 아니며 캡처 중복 가능성도 함께 본다.

재전송 시간초과(Retransmission Timeout, RTO)는 고정 숫자 하나가 아니다. 왕복시간(Round-Trip Time, RTT)은 한 지점에서 보낸 사건과 그에 대응하는 응답·확인이 같은 지점에 돌아오기까지의 경과시간이다. RFC 6298의 기본 구조는 측정한 RTT로 평활 왕복시간과 변동을 추정하고 RTO = 평활 RTT + 변동 여유로 잡으며, 타임아웃이 반복되면 기다림을 늘린다. 너무 짧으면 아직 오는 패킷을 잃었다고 오판하고, 너무 길면 실제 손실 회복이 늦다.

흐름제어에서는 수신자가 Window로 받을 여유를 광고한다. 수신 윈도가 작거나 0에 가까우면 수신 응용의 소비·버퍼 상태를 의심하며, 이를 곧 네트워크 혼잡으로 단정하지 않는다.

원시 Window와 계산된 바이트 윈도를 구별한다. Window 필드는 16비트지만 RFC 7323 §§2.2–2.3의 Window Scale을 합의한 연결에서는 각 방향의 합의된 shift를 적용한다. SYN 비트가 없는 세그먼트에서 원시 Window가 900이고 그 값을 광고한 방향의 shift가 3이면 수신 여유는 900×2³=7200바이트다. SYN·SYN+ACK의 Window에는 이 확대를 적용하지 않는다. 분석기가 이미 계산한 윈도를 표시한다면 다시 곱하지 않으며, 수립 패킷이 빠져 확대 조건을 모르면 원시 값만으로 정확한 rwnd를 확정하지 않는다.

순서번호를 실제 바이트로 따라간다

송신자의 초기 SYN 번호를 1000으로 정하면 SYN이 번호 하나를 사용하므로 첫 데이터는 1001에서 시작한다. 아래는 설명을 위해 수신자가 각 사건 뒤 즉시 누적 ACK를 보내고, 순서 밖 데이터도 보관하는 예다. 구간 [a,b)는 a부터 b−1까지의 바이트를 뜻하며 실제 ACK 빈도는 구현·지연 ACK 정책에 따라 달라질 수 있다.

ACK 2501은 이 방향의 2500번 바이트까지 연속 수신했다는 뜻이다. 응용이 이 1500바이트를 읽거나 업무 처리를 끝냈다는 뜻은 아니다. 한 번의 반복 ACK만으로 재전송 알고리즘이 반드시 즉시 동작한다고 단정할 수 없으며, 처음 공백이 생긴 이유도 손실·순서 역전·관찰 누락을 추가로 대조해야 한다.

혼잡을 통제한다: cwnd는 패킷 필드가 아니라 송신자의 내부 제한이다

네트워크 혼잡은 일정 구간의 도착 부하가 병목의 처리능력을 넘어 대기열·지연·폐기 가능성이 커지는 상태다. 혼잡 윈도(congestion window, cwnd)는 네트워크가 감당할 수 있다고 송신자가 추정해, 확인 없이 전송 중일 수 있는 데이터 양을 제한하는 내부 상태다. 수신 윈도(receive window, rwnd)는 수신자가 TCP 머리로 광고하지만 cwnd와 slow start threshold(ssthresh)는 송신기 내부값이다. 실제 전송 가능량은 개념적으로 min(rwnd, cwnd)와 아직 확인되지 않은 바이트의 관계로 제한된다.

RFC 5681의 고전적 손실 기반 흐름은 다음과 같다.

1. Slow Start: cwnd가 작을 때 ACK를 받으며 빠르게 전송범위를 늘려 가용 용량을 탐색한다.
2. Congestion Avoidance: ssthresh 부근 이후에는 증가를 완만하게 하여 혼잡을 피한다.
3. Fast Retransmit: 같은 누락을 시사하는 중복 ACK가 세 번 도착하면 RTO를 기다리지 않고 재전송한다.
4. Fast Recovery: 손실 뒤 cwnd·ssthresh를 줄이고 ACK 진행을 보며 회복한다.
5. Timeout: 더 심한 손실 신호로 보고 전송범위를 크게 줄이며 RTO를 지수적으로 늘린다.

현행 대표 알고리즘인 CUBIC은 한 번의 손실 전 윈도 크기를 기준으로 시간을 따라 오목하게 접근하고 이후 볼록하게 새 용량을 탐색하며, 혼잡 사건에는 곱셈식으로 윈도를 줄인다. 이는 대표 구현 선택이지 모든 TCP가 같은 알고리즘·상수를 쓴다는 뜻이 아니다. 패킷에는 cwnd가 없으므로 캡처만 보고 정확한 cwnd를 측정했다고 쓰지 않고 송신 호스트 지표와 함께 확인한다.

두 제한을 숫자로 적용해 보자. 이미 바이트 단위로 해석한 rwnd가 6000, 호스트 내부에서 확인한 cwnd가 4000이고, 보냈지만 아직 확인받지 않은 데이터가 2500바이트라고 하자. 다른 제한과 번호 경계 문제는 제외한 이 예에서 전송 중일 수 있는 상한은 min(6000,4000)=4000, 추가 전송 여유는 4000−2500=1500바이트다.

직접 풀어 보기 — 자체 조건 변경

확인 문제로 cwnd만 8000으로 늘리면 추가 여유는 얼마인가?

UDP: 연결 상태 없이 데이터그램 경계를 전달한다

사용자 데이터그램 프로토콜(User Datagram Protocol, UDP)은 출발·목적 포트, 길이와 체크섬의 작은 머리를 사용해 독립 데이터그램을 전달하는 전송 프로토콜이다. UDP 자체는 연결수립, 순서 재배열, 전달 확인, 재전송과 혼잡제어 상태를 제공하지 않는다. 그래서 UDP는 무조건 빠르다가 아니라 필요한 보장을 응용이 어디에서 책임지는지 묻는다.

UDP는 한 데이터그램의 경계를 보존한다. 수신자는 도착한 데이터그램 하나를 읽지만, 손실·중복·순서 역전 가능성을 응용 프로토콜이 고려해야 한다. 체크섬이 있다고 전달 성공이나 중복 방지가 보장되는 것도 아니다. 포착에서 요청은 있으나 응답이 없다면 서버 미응답, 역방향 손실, 정책 차단과 포착지점 누락을 구분한다.

TCP와 UDP를 같은 축으로 비교한다

선택은 속도 한 축이 아니다. 메시지 경계, 손실·순서·중복 처리, 지연 민감도, 혼잡에 대한 책임과 응용 구현 복잡성을 함께 본다.

2. DNS: 이름을 분산된 기록에서 해석한다

도메인 이름 시스템(Domain Name System, DNS)은 계층적인 도메인 이름공간과 그 정보를 나누어 관리하는 이름서버, 질의를 수행하는 해석기(resolver)를 사용해 이름에 관한 자원 레코드를 찾는 분산 데이터 체계다. 해석기는 응용의 질문을 DNS 질의로 만들고, 이름서버는 자신이 가진 정보·위임·응답 상태에 따라 답한다.

자원 레코드(Resource Record, RR)는 이름에 관한 형식화된 정보 단위이며 이름, 유형, 클래스, 생존시간(Time to Live, TTL), 데이터 길이와 데이터로 표현된다. 여기서 DNS TTL은 캐시된 레코드를 얼마 동안 재사용할 수 있는지 나타내는 시간 경계이고 IPv6 Hop Limit과 다른 개념이다. 이 절은 확인된 양의 레코드 캐시만 다루며 DNS negative caching은 확보한 근거 범위에서 제외한다.

DNS는 UDP와 TCP를 모두 사용한다. 포착한 응답의 TC 비트가 잘림(truncation)을 나타내면 resolver가 TCP로 다시 질의하는 흐름을 고려한다. 그러나 TCP는 잘린 응답을 재시도할 때만 사용하는 방식이 아니다. RFC 7766 §5에 따라 처음부터 TCP로 질의할 수 있고 이미 열린 연결을 재사용할 수도 있다. 따라서 분석에서는 실제 질의·응답의 전송방식을 확인하며, 이 절은 연결 풀이나 타임아웃 운영정책까지 다루지는 않는다.

이름 해석: 질문을 권한 있는 정보 쪽으로 좁혀 간다

이 그림은 역할을 설명하는 대표 흐름이다. 실제 해석기는 캐시·정책·병렬 질의에 따라 모든 단계를 매번 밟지 않을 수 있다. 분석할 때는 클라이언트가 누구에게 물었는가, 그 서버가 최종 답·위임·오류 중 무엇을 보냈는가, 같은 ID와 질문에 대한 응답인가, TTL 안의 캐시인지를 본다.

양의 주소 레코드를 10:00:00에 TTL 60초로 캐시했다고 하자. 다른 정책 조건을 제외하면 10:00:40의 같은 질문은 남은 20초 안이므로 그 레코드를 재사용할 수 있지만, 10:01:01에는 61초가 지나 만료했으므로 그 캐시만으로 답하면 안 된다. 그 사이 권한 이름서버의 주소가 바뀌어도 캐시가 매번 서버를 조회하는 것은 아니다. TTL 0인 레코드는 진행 중인 질의 처리에는 쓸 수 있지만 뒤의 별도 질의를 위해 캐시해 재사용하는 기록으로 두지 않는다(RFC 1035 §4.1.3). 이 시간 계산은 양의 레코드에 대한 것이며 오류 응답의 캐시 정책과 섞지 않는다.

직접 풀어 보기 — 양의 캐시 기록의 자체 조건 변경

같은 10:00:00 캐시 기록의 TTL만 30초로 바꾸면 10:00:40에 그 기록을 재사용할 수 있는가? 남은 시간 또는 경과시간을 근거로 답한다.

DNS 메시지는 머리와 네 구역으로 읽는다

ID만으로 장시간의 모든 DNS 대화를 구별하지 않는다. 양 끝 주소·포트, 전송방식, 질문 이름·유형과 근접 시간을 함께 맞춘다. 응답 없음은 DNS 서버 자체 원인으로 단정하지 않고 요청이 서버에 도착했는지와 응답이 클라이언트까지 왔는지를 포착지점별로 나눈다.

3. HTTP: 의미와 전송 문법을 분리해 읽는다

하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol, HTTP)은 자원에 대한 요청과 응답의 의미를 메서드, 대상, 필드, 상태코드와 콘텐츠로 표현하는 응용 프로토콜이다. 메서드는 요청의 의도, 상태코드는 처리 결과의 분류, 필드는 메시지에 관한 추가 제어정보를 나타낸다.

RFC 9110은 HTTP 버전들이 공유하는 의미를 정의한다. HTTP/1.1의 메시지 문법은 RFC 9112, HTTP/2의 이진 프레임과 스트림은 RFC 9113, HTTP/3가 QUIC에서 HTTP 의미를 전달하는 방식은 RFC 9114가 맡는다. 의미와 전송 문법을 분리하면 200 같은 상태 의미는 이어지면서도 패킷에서 보이는 모양이 버전별로 다른 이유를 설명할 수 있다.

HTTP/1.1 요청·응답은 시작줄→필드→콘텐츠 경계로 읽는다

요청                                              응답
[메서드 대상 HTTP-버전]                          [HTTP-버전 상태코드 사유]
[필드 이름: 값]                                  [필드 이름: 값]
...                                               ...
[빈 줄로 머리 구역 종료]                         [빈 줄로 머리 구역 종료]
[선택적 콘텐츠]                                  [선택적 콘텐츠]

먼저 메서드와 요청 대상을 보고 무엇을 하려 했는지 확인한다. 다음으로 Host 등 라우팅·표현·조건·인증에 관여하는 필드를 목적에 맞게 읽는다. 응답에서는 상태코드 계열과 콘텐츠 경계를 확인하고, 요청부터 첫 응답 바이트·완료까지 시간을 나눈다.

GET 같은 안전한 메서드는 요청한 자원의 상태를 바꾸는 의미를 의도하지 않고, 멱등 메서드는 같은 의도의 요청을 여러 번 적용해도 의도된 효과가 한 번과 같아야 한다. 그러나 전송 재시도가 업무 부작용까지 자동으로 안전하게 만드는 것은 아니다. 서버 구현과 인증·결제 같은 업무 의미를 함께 확인한다.

문법을 실제 값에 연결하면 다음처럼 읽는다. TLS가 있으면 복호화 가능한 관찰점이나 서버 로그에서 읽는 HTTP/1.1 교육 예이며, 표시된 줄 구분은 메시지의 줄 경계를 나타낸다.

요청                 응답
GET /status HTTP/1.1  HTTP/1.1 200 OK
Host: service.example Content-Length: 2
[빈 줄]              [빈 줄]
                     OK

요청의 GET은 자원을 가져오려는 메서드, /status는 요청 대상, Host는 대상 서비스 이름이다. 응답의 200은 성공 계열 상태코드이며 뒤의 OK는 사유 문구다. 빈 줄 뒤의 OK가 실제 콘텐츠이고, 콘텐츠 뒤에 별도 줄바꿈이 없다고 가정한 이 예의 영문 두 글자는 2바이트이므로 Content-Length: 2와 맞는다. 사유 문구와 콘텐츠는 위치와 역할이 다르다.

콘텐츠 길이는 글자 수가 아니라 바이트 수다. 위 GET의 200 응답에 Content-Type: text/plain; charset=utf-8을 쓰고 콘텐츠를 줄바꿈 없는 성공으로 바꾸면 두 글자지만 UTF-8에서는 6바이트다. Transfer-Encoding이 없는 이 조건에서는 Content-Length: 6이어야 선언 길이와 콘텐츠가 맞는다. 글자 수 2를 그대로 쓰면 메시지 경계가 틀어지며, 200이라는 상태만으로 올바른 응답이라고 판정할 수 없다. 실제 경계는 메서드·상태·전송 코딩도 함께 확인한다. 예를 들어 HEAD 응답과 204 응답에는 본문이 없고, 송신자는 Transfer-Encoding과 Content-Length를 함께 보내면 안 된다(RFC 9112 §§6.2–6.3).

직접 풀어 보기 — 자체 조건 변경

독립적으로 판정해 보자. 상태줄은 그대로 두고 콘텐츠를 FAIL, 길이를 4로 바꿨다고 하자. 업무의 정상 판정 기준이 콘텐츠 OK일 때 HTTP 상태와 업무 결과를 각각 판정하자.

HTTP/1.1·2·3: 의미는 이어지고 운반방식은 달라진다

HTTP/3의 기본 분석에서는 먼저 HTTP 의미를 QUIC 스트림 위에서 전달한다는 경계를 확인한다. QUIC 연결·스트림과 HTTP 메시지를 구별하고, TCP 순서번호를 그대로 적용하지 않는다. QUIC 손실복구와 QPACK 헤더 압축의 세부 동작은 이 기본 경계를 익힌 뒤 별도로 학습한다.

4. TLS 1.3과 PKIX: 보호채널과 인증근거를 나눈다

전송계층 보안(Transport Layer Security, TLS) 1.3은 통신 양 끝이 프로토콜 버전·암호 매개변수와 키를 합의하고, 선택한 인증방식으로 상대를 확인한 뒤 응용 데이터를 기밀성·무결성이 보호된 기록으로 교환하게 하는 프로토콜이다. 현행 명세인 RFC 9846은 RFC 8446을 폐기했다.

TLS 핸드셰이크는 보호채널에 쓸 매개변수·키·인증 상태를 합의하는 대화이고, TLS record는 합의한 키와 상태로 핸드셰이크 또는 응용 데이터를 보호해 운반하는 단위다. 모든 TLS 연결이 인증서만 사용하는 것은 아니다. 이 절의 대표 흐름은 웹에서 흔한 서버 인증서 기반 TLS 1.3이다.

공개키 기반구조 X.509(Public-Key Infrastructure using X.509, PKIX)는 인증서 발급자 관계와 경로 검증 규칙으로 공개키를 이름·주체와 연결해 신뢰를 판단하는 체계다. 인증서 파일이 존재하는 것과 현재 접속 대상에 유효하게 신뢰되는 것은 다르다.

서비스 신원검증(service identity verification)은 클라이언트가 신뢰할 수 있는 입력으로 얻은 reference identifier와 서버 인증서가 제시한 presented identifier를 적합한 유형의 규칙으로 비교하는 과정이다. RFC 5280의 인증경로 검증이 성공해도 이 일치검사가 실패하면 의도한 서비스로 인증하면 안 된다. 두 검증을 하나로 합치거나 인증서의 Common Name 문자열만 임의 비교하지 않는다.

TLS 1.3의 session resumption은 이전 연결에서 얻은 사전공유키(Pre-Shared Key, PSK)를 사용해 새 핸드셰이크 비용을 줄일 수 있다. 0-RTT(Zero Round-Trip Time) early data는 핸드셰이크 완료 전에 일부 응용 데이터를 보내 지연을 줄이지만 replay될 수 있으므로, 재실행되어도 안전하다고 별도 정책으로 확인한 요청에만 허용해야 한다. 암호화되었다는 이유만으로 replay 안전성이 생기지는 않는다.

인증서 기반 TLS 1.3: 합의→인증→완료→응용 데이터

ServerHello 뒤의 핸드셰이크 메시지는 handshake traffic key로 암호화된다. Finished 자체도 이 보호 안에 있으며, 보호된 record가 Finished 뒤에 처음 만들어지는 것은 아니다. Certificate는 공개키와 이름·발급관계를 제시하고, CertificateVerify는 해당 개인키 보유와 현재 핸드셰이크의 결합을 증명하며, Finished는 합의된 키와 핸드셰이크 무결성을 확인한다. 클라이언트 인증이 요구되거나 사전공유키를 쓰면 흐름은 달라질 수 있다.

캡처에서 ClientHello는 있으나 ServerHello가 없으면 버전·정책·경로·서버 도달을 나누고, TLS 경고가 보이면 앞선 메시지와 인증 검증 로그를 함께 본다. 암호화된 뒤에는 키 없이 HTTP 의미가 보이지 않는 것이 정상일 수 있다.

위 그림은 0-RTT를 제외한 인증서 기반의 기본 흐름이다. 서버가 상대 Finished보다 먼저 응용 데이터를 보낼 때는 핸드셰이크가 아직 완료되지 않았으므로 상대의 신원이나 상대가 현재 살아 있는 참여자인지까지 확인된 것은 아니다(RFC 9846 §4.5.3). 서버는 자신의 Finished를 보낸 뒤 application traffic key로 응용 데이터를 보낼 수 있으므로 반드시 클라이언트 Finished 수신까지 기다리는 것은 아니다. 클라이언트는 서버 인증과 Finished를 검증하고 자신의 Finished를 보낸 뒤 일반 응용 데이터를 보낸다. handshake traffic key와 application traffic key의 전환, 상대의 Finished 검증, 양방향 완료는 서로 구별되는 사건이다. 0-RTT 조기 데이터와 추가 클라이언트 인증은 별도 조건·보안 경계를 갖는다.

인증서 검증은 서명만 맞음으로 끝나지 않는다

1. 신뢰경로: 최종 인증서에서 신뢰하도록 설정된 anchor까지 발급자 관계가 이어지는가.
2. 서명: 경로의 인증서 서명이 해당 발급자 공개키로 검증되는가.
3. 유효기간: 검증 시각이 각 인증서의 허용기간 안인가.
4. 제약과 용도: 기본 제약, 이름 제약, 키 사용과 확장 키 사용이 경로와 현재 용도를 허용하는가.
5. 서비스 신원: 신뢰한 source domain 등으로 만든 reference identifier가 인증서의 적합한 subjectAltName presented identifier와 일치하는가.
6. 정책상 폐기상태: 환경의 검증정책이 요구하는 폐기정보를 확인했는가.

RFC 5280의 인증경로 검증과 RFC 9525의 서비스 신원검증은 서로 다른 축이며 둘 다 성공해야 인증서 기반 서버 인증을 완성할 수 있다. HTTPS는 HTTP의 의미를 TLS 보호채널로 운반하는 사용형태이며, TLS가 서버 응용의 권한 오류·입력검증 실패·악성 콘텐츠까지 해결하지는 않는다.

예를 들어 사용자가 신뢰할 수 있게 지정한 접속 이름이 service.example이면 이것이 비교 기준인 reference identifier다. 서버 인증서의 적합한 subjectAltName에 제시된 DNS 이름이 api.example뿐이라면 이것은 presented identifier이며 두 이름이 일치하지 않는다. 경로·서명·기간 검증이 모두 통과했더라도 의도한 서비스의 인증은 실패한다.

직접 풀어 보기 — 자체 조건 변경

확인 문제로 인증서 이름을 service.example로 고쳤지만 검증 시각이 유효기간 뒤라면 어떨까?

5. 패킷에서 상태를 복원하는 절차

아홉 단계로 프로토콜 대화를 읽는다

1. 질문·시간범위 고정: 어떤 사용자 동작의 어느 실패를 설명할지 정한다.
2. 포착점·방향 확인: 클라이언트·서버·중간 지점 중 어디에서 본 것인지 표시한다.
3. 대화 후보 분리: 주소·포트·프로토콜·DNS ID·HTTP stream 등 적합한 키를 쓴다.
4. 계층 열기: Ethernet→IPv6→TCP/UDP→응용 순으로 선언 길이와 종류를 확인한다.
5. 시간순 배열: 요청·응답, seq/ack, 핸드셰이크를 한 방향씩 놓는다.
6. 상태기계 대조: 현재 메시지 뒤 기대할 다음 상태·메시지를 명세와 맞춘다.
7. 시간·반복 측정: RTT, 응답단계 시간, 재전송과 반복 질의를 구분한다.
8. 다른 증거 대조: 서버·TLS 인증·응용 로그와 호스트 내부 지표를 같은 사건에 연결한다.
9. 판정과 한계 기록: 관찰→기대→차이→원인 후보→추가 검증 순으로 쓴다.

Wireshark 4.7.3 같은 분석도구의 색상·요약 문구는 출발점이지 판정근거 전체가 아니다. 표시 필드를 원시 값과 대조하고, 도구가 추론한 재전송·문제 표시는 포착 위치와 앞뒤 패킷으로 재검증한다.

자주 틀리는 판정과 교정법

프로토콜 분석에서 확인할 학습 내용

정의에서 메시지·상태·실패 판정까지 다음 연결을 스스로 설명해 본다.

• 정의: formal-protocol-evidence-analysis와 TCP·UDP·DNS·HTTP·TLS의 정식 정의가 분석대상과 상태를 확정한다.
• 작동원리: TCP 수립·신뢰성·혼잡, DNS 해석, HTTP 메시지, TLS 핸드셰이크가 메시지 순서와 필드를 보여 준다.
• 비교: TCP/UDP, HTTP 버전, 수신/혼잡 윈도와 계층별 증거를 같은 축으로 구분한다.
• 실패조건: protocol-analysis-failure-modes가 단일 필드·도구 추론·암호화의 한계를 통제한다.
• 절차: protocol-analysis-nine-steps가 질문에서 판정·추가증거까지 재현 가능한 분석을 만든다.
• 연습(practice)·답안 전환: 아래 자체 제작 10점·25점 문제의 목차·도식·모범답안이 정의와 절차를 실제 논점으로 추적한다.

앞 절의 계층·PDU·Ethernet/IPv6 경계로 메시지를 해석하고, 다음 절에서는 패킷·로그·지표를 연결해 서비스 원인을 진단한다.

6. 기출 후보와 답안 전환

문항별 direct·partial·legacy 경계를 둔다

사람 원문검증·배점·대표성 승인 수는 0이다. 최신 연도라는 이유만으로 정확성·현행성 승인을 부여하지 않는다.

IM-0130-P03-Q03의 누락 요구를 답안 구조에서 복구한다

기존 후보 텍스트는 공식 PDF의 네 번째 요구 혼잡 윈도우 크기를 빠뜨렸다. 답안은 다음처럼 네 요구를 독립 목차로 보존한다.

1. 구성요소: cwnd·ssthresh·ACK·RTO와 송신 중 데이터
2. 감지: 중복 ACK·타임아웃 등 손실 신호와 RTT·대기 증가의 보조 관찰
3. 제어: slow start, congestion avoidance, fast retransmit/recovery, timeout backoff
4. 혼잡 윈도우 크기: 증가·감소 원리, rwnd와의 차이, 패킷에서 직접 보이지 않는 관측 한계

자동 군집 TOP-01194는 socket/WebSocket, TCP 혼잡·손실 대응, TCP 연결 생명주기의 서로 다른 세 답안 골격을 합쳤으므로 reject_and_split 후보다. 소켓·WebSocket, TCP 혼잡·손실 대응, TCP 연결 생명주기의 세 논점으로 나누고, 기존 반복점수는 무효화한 뒤 사람 군집검토 후 다시 계산한다. 분할 후보의 실제 멤버는 각각 IM-0131-P02-Q05와 IM-0116-P03-Q06, IM-0130-P03-Q03과 partial인 IM-0066-P03-Q06, 그리고 IM-0133-P01-Q13이다. 이 가운데 IM-0116-P03-Q06과 IM-0066-P03-Q06은 이번 15문항 감사 집합 밖이므로 감사 분모나 반복 근거로 세지 않는다. 공식 문항 단위와 교정된 하위 요구를 기준으로 연결한다.

시험에서는 어떻게 묻는가: 10점

다음은 자체 제작 문제다.

TCP의 연결 수립과 신뢰성 확보 원리를 설명하고, 수신 윈도와 혼잡 윈도의 차이를 제시하시오.

세그먼트 이름만 쓰지 말고 seq/ack의 의미, 재전송 조건, rwnd/cwnd의 소유자·표시 위치·제한 대상을 연결한다.

시험에서는 어떻게 묻는가: 25점

다음도 자체 제작 문제다.

사용자가 HTTPS 서비스에 접속하지 못한 상황에서 DNS, TCP, TLS 1.3과 HTTP의 메시지·상태를 패킷으로 분석하는 절차와 계층별 실패 판정기준을 설명하시오.

기술 네 개를 따로 나열하지 않고 하나의 시간선에서 이름→연결→보호채널→응용 응답의 마지막 정상과 최초 이상을 찾는다.

근거와 현행성

프로토콜 분석의 공통 프레임은 ITU-T X.200 (07/1994) §§5.1, 5.2.1, 5.2.2.1–5.2.2.7, 5.3, 5.6과 6.1–6.3의 계층·서비스·프로토콜·PDU 경계, RFC 1122 §§1.1.3, 2.4, 3.1과 §4의 인터넷 계층 경계를 엮어 교재가 제한적으로 종합했다. 어느 한 문서가 본문의 분석 절차 전체를 규범으로 정한다고 주장하지 않는다.

TCP의 핵심·머리·상태·순서·수신윈도는 RFC 9293 §§2.2, 3.1, 3.3.2, 3.4–3.8, 3.8.1–3.8.2와 3.8.6 중 본문에서 실제 가르친 범위만, UDP의 최소 서비스·머리·체크섬은 RFC 768 Introduction, Format, Fields, IP Interface를 기준으로 했다. RFC 768에는 번호 절이 없으므로 가짜 절 번호를 만들지 않으며 UDP Options는 다루지 않는다. 네트워크 혼잡의 용어 경계는 RFC 9522 §§1.4, 2.2, TCP 혼잡제어의 Reno 기준은 RFC 5681 §§2, 3.1–3.2, RTT 기반 RTO와 backoff는 RFC 6298 §§2–3, §5, 대표 CUBIC은 RFC 9438 §§3–4, 4.3–4.6, 4.8, 4.10에서 실제 가르친 범위만 사용했다.

DNS 분산구조·구성요소·위임·처리는 RFC 1034 §§2.2, 2.4, 4.2, 4.3.2와 5.3.3, 메시지·RR·TTL과 resolver 처리는 RFC 1035 §§3.2.1, 4.1–4.2.2와 7.1–7.4를 사용했다. HTTP 공통 의미·메서드·상태는 RFC 9110 §§6, 9, 9.2와 15, HTTP/1.1 문법은 RFC 9112 §§2–5와 6.2–6.3, HTTP/2 프레임·스트림은 RFC 9113 §§2, 4.1, 5와 8.1, HTTP/3의 QUIC·request stream 경계는 RFC 9114 §§1.2, 2, 3.2, 4.1, 6, 7과 7.2만 확인했다. DNS negative caching, QUIC 손실복구와 QPACK은 포함하지 않았다.

TLS 1.3 명세는 RFC 9846 §§1–2, 4.5–4.5.3, 5와 5.2이며, PSK 재개·0-RTT와 replay 경계는 §§2.2–2.3, 8과 Appendix F.5를 사용했다. 2026-09-01 기준 폐기된 RFC 8446을 현행 명세로 인용하지 않는다. 인증서 필드·확장·경로검증은 RFC 5280 §§4.1–4.2, 5, 6과 6.1, 서비스의 reference/presented identifier와 일치 판정은 RFC 9525 §§1.2, 2, 6과 6.1을 사용했다. 패킷 분석도구는 Wireshark User’s Guide 4.7.3 §§4.10, 6.4, 7.2, 7.4, 7.5, 7.6, 7.6.3, 7.8.1–7.8.3과 7.10.1–7.10.3을 구현 예로만 사용했다. 원문 표·그림·패킷 화면을 복제하지 않고 모든 흐름·표·문제를 새로 구성했다.

기준 확인일은 2026-09-01이다. 기술 정확성·현행성·출제 적합성·기출 연결·권리에 대한 사람 승인 수는 0이며 상태는 candidate / human-validation-pending이다.

30초 정리

1. 프로토콜 분석은 필드 하나가 아니라 양 끝·방향·상태·시간순서를 명세와 대조한다.
2. TCP는 상태·순서·ACK·재전송·rwnd/cwnd를 쓰는 바이트 스트림이고 UDP는 연결 상태 없는 데이터그램이다.
3. DNS는 질문·응답코드·구역·자원 레코드·TTL을, HTTP는 버전별 운반방식과 공통 의미를 읽는다.
4. TLS 1.3은 ServerHello 뒤의 핸드셰이크부터 record를 보호하며, Finished 검증과 응용 traffic key 전환을 구분한다. 인증서는 PKIX 경로·이름·기간·용도를 검증한다.
5. 답안은 각 단계의 마지막 정상·최초 이상·추가증거와 캡처로 볼 수 없는 내부 상태를 함께 쓴다.

다시 읽을 때는 DNS로 찾고, TCP로 상태를 만들고, TLS로 보호하고, HTTP로 의미를 주고받는다를 한 시간선에 놓은 뒤 각 화살표의 기대 응답을 말해 본다.

직접 연습: 필드 값의 단위와 완료 조건을 바꾸어 본다

1. SYN이 없는 세그먼트의 원시 Window는 900이며, 이 방향의 Window Scale shift 3이 수립 때 합의되었습니다. 호스트에서 확인한 cwnd는 8000바이트, 미확인 데이터는 2500바이트입니다. 본문의 단순화 조건에서 rwnd와 추가 전송 여유는 얼마인가요? 수립 캡처가 없어서 shift를 모르는 경우에도 같은 계산을 확정할 수 있나요?

2. 순서번호 7001부터의 데이터 300바이트 뒤에 같은 세그먼트의 FIN이 있고 앞선 공백은 없습니다. 수신자가 이를 모두 받아 누적 확인하면 ACK는 얼마인가요? 이 ACK 뒤 서버가 남은 응답 데이터를 보내는 것은 모순인가요?

3. GET에 대한 200 응답이고 Transfer-Encoding·압축·끝 줄바꿈이 없으며 콘텐츠는 UTF-8 성공입니다. Content-Length를 2로 선언해도 되나요? 반대로 Content-Length를 6으로 고쳤지만 업무 기준이 본문 OK라면 정상 판정까지 성공하나요?