DNS, HTTP와 HTTPS

1. DNS의 역할

DNS는 사람이 기억하기 쉬운 도메인 이름을 IP 주소와 다른 자원 정보로 변환하는 분산 계층형 시스템이다.

www.example.com
   │
   ├─ com        : 최상위 도메인(TLD)
   ├─ example    : 등록 도메인
   └─ www        : 호스트 또는 서비스 이름

주요 레코드는 다음과 같다.

2. DNS 질의 흐름

사용자의 스텁 리졸버는 보통 재귀 DNS 서버에 질의를 맡긴다. 캐시에 없으면 재귀 서버가 루트, TLD, 권한 서버를 따라간다.

Browser/OS
   │ 1. www.example.com?
   ▼
Recursive Resolver
   │ 캐시 미스
   ├─► Root Server      : .com 서버 위치는?
   ├─► .com TLD Server  : example.com 권한 서버는?
   └─► Authoritative NS : www.example.com의 A/AAAA는?
   │
   ▼
IP 주소 응답 + TTL 동안 캐시

• 재귀 질의: 질의를 받은 서버가 최종 결과까지 찾아 응답한다.
• 반복 질의: 현재 서버가 알고 있는 다음 권한 서버 정보를 알려준다.
• TTL: 캐시가 레코드를 유지할 수 있는 시간이다.

DNS는 일반적으로 UDP 53을 사용하지만 응답이 크거나 영역 전송 등에서는 TCP를 사용할 수 있다.

3. HTTP 요청과 응답

HTTP는 클라이언트와 서버가 자원을 요청·응답하는 응용 계층 프로토콜이다.

GET /employees/10 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer <token>

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

{"empId":10,"name":"Kim"}

HTTP 메시지는 시작줄, 헤더, 빈 줄, 선택적 본문으로 구성된다.

4. 메서드와 상태코드

멱등은 같은 요청을 여러 번 수행해도 최종 자원 상태가 한 번 수행한 것과 같다는 뜻이다. 응답 코드까지 항상 같다는 뜻은 아니다.

401 Unauthorized는 보통 인증이 필요하거나 실패했다는 의미이고, 403 Forbidden은 신원이 확인되어도 권한이 없다는 의미로 사용한다.

5. 쿠키와 세션

HTTP 자체는 요청 사이의 상태를 자동으로 기억하지 않는 stateless 프로토콜이다. 쿠키와 서버 세션 등을 이용해 로그인 상태를 연결한다.

1) Client ── 로그인 요청 ─────────► Server
2) Client ◄─ Set-Cookie: sid=ABC ── Server
3) Client ── Cookie: sid=ABC ─────► Server
4) Server는 sid로 서버 측 세션 조회

• 쿠키: 브라우저가 저장하고 요청에 포함하는 작은 값이다.
• 세션: 서버가 사용자 상태를 저장하고 세션 식별자를 쿠키 등으로 전달하는 방식이다.
• Secure는 HTTPS에서만 전송, HttpOnly는 자바스크립트 접근 제한, SameSite는 교차 사이트 요청 전송을 제어한다.

인증 토큰을 쿠키나 Authorization 헤더로 전달할 수 있으며 저장 위치에 따라 XSS·CSRF 위험과 대응이 달라진다.

6. HTTP 캐시

캐시는 같은 자원의 반복 전송을 줄인다.

• Cache-Control: max-age=60: 일정 시간 동안 신선한 응답으로 사용
• ETag: 자원 버전을 식별
• If-None-Match: 보유한 ETag와 같은지 조건부 요청
• 304 Not Modified: 본문을 다시 보내지 않고 기존 캐시 사용

최초 요청  ─────────► 200 OK + ETag: "v1" + Body
재검증 요청 ────────► If-None-Match: "v1"
변경 없음   ◄──────── 304 Not Modified

7. HTTPS와 TLS

HTTPS는 HTTP를 TLS로 보호한다. TLS는 서버 인증, 기밀성, 무결성을 제공한다.

Client                                      Server
  │── ClientHello: 지원 버전·암호군 ───────►│
  │◄─ ServerHello + 인증서 + 키교환 정보 ───│
  │   인증서 체인·도메인·유효기간 검증       │
  │── 키교환 완료·암호화된 확인 ───────────►│
  │◄════════ 대칭키로 암호화된 HTTP ═══════►│

핵심 과정은 다음과 같다.

1. 사용할 TLS 버전과 암호 알고리즘을 협상한다.
2. 서버가 인증서와 공개키 관련 정보를 제공한다.
3. 클라이언트는 신뢰하는 CA 체인, 도메인, 유효기간 등을 검증한다.
4. 키교환으로 세션용 대칭키를 만든다.
5. 이후 애플리케이션 데이터는 빠른 대칭키 암호와 무결성 보호를 사용한다.

인증서가 있다고 서버가 안전한 코드만 실행한다는 뜻은 아니다. 인증서는 해당 공개키와 도메인 신원의 연결을 검증하는 것이 핵심이다.

8. HTTP 버전과 REST 기초

• HTTP/1.1: 지속 연결과 파이프라이닝 개념을 제공하지만 요청 순서에 따른 제약이 있다.
• HTTP/2: 하나의 TCP 연결에서 여러 스트림을 다중화하고 헤더를 압축한다.
• HTTP/3: QUIC을 사용하며 UDP 위에서 연결·암호화·다중화를 구현한다.

REST는 자원을 URI로 식별하고 HTTP 메서드와 상태코드를 의미에 맞게 사용하는 아키텍처 스타일이다. 모든 HTTP API가 자동으로 REST인 것은 아니다.

curl -i https://api.example.com/employees/10
curl -X POST -H 'Content-Type: application/json' \
     -d '{"name":"Kim"}' \
     https://api.example.com/employees

9. 기타 응용 프로토콜

10. DNS 무결성과 프라이버시

DNSSEC는 응답을 암호화하지 않고, DoH/DoT만으로 권한 데이터의 서명 진위가 자동 보장되는 것도 아니다. CNAME과 대상 A/AAAA의 TTL은 독립적으로 만료될 수 있다.

11. HTTP 메서드와 조건부 요청

• GET: safe, idempotent
• PUT: idempotent지만 safe하지 않음
• POST: 일반적으로 safe·idempotent가 아님

GET /item/10 HTTP/1.1
If-None-Match: "v1"

변경이 없으면 304 Not Modified로 기존 본문을 재사용한다. 갱신 요청에 If-Match를 사용하면 ETag가 일치할 때만 변경하여 오래된 화면의 덮어쓰기를 막을 수 있다.

12. HTTP 버전과 HOL

HTTP/1.1 : 같은 연결의 응답 순서 때문에 HOL 가능
HTTP/2   : 여러 스트림을 한 TCP 연결에 multiplex
           단, TCP 패킷 손실은 여러 스트림에 영향
HTTP/3   : QUIC 독립 스트림으로 전송계층 HOL 완화

13. TLS 인증서와 0-RTT

브라우저는 신뢰 체인, 유효기간, 접속 호스트 이름을 검증하고 환경과 정책에 따라 폐기 정보도 확인한다. CA 서명이 유효해도 인증서 이름이 접속 호스트와 다르면 실패해야 한다. SNI는 서버 이름을, ALPN은 HTTP/2 같은 상위 프로토콜을 협상한다.

TLS 1.3의 0-RTT는 재연결 지연을 줄이지만 replay 가능성이 있으므로 상태 변경 요청은 멱등성·중복 방어를 확인해야 한다.

14. 쿠키와 CORS

Secure는 HTTPS 전송, HttpOnly는 스크립트 접근 제한, SameSite는 교차 사이트 전송을 제어한다. 비단순 교차 출처 요청은 브라우저가 OPTIONS preflight로 허용 origin·method·header를 확인한다.

확인 문제

1. DNSSEC와 DoH의 역할 차이는?
2. If-None-Match가 일치할 때 대표 응답은?
3. GET과 PUT의 safe·idempotent 성질은?
4. 인증서 CA 서명이 유효해도 호스트명이 다르면?
5. TLS 1.3 0-RTT의 주의점은?