용어 사전

예를 들어 Alt-Svc: h3=":443"을 받은 브라우저는 다음 요청부터 같은 서버에 HTTP/3로 연결을 시도한다. 그래서 첫 접속은 TCP(HTTP/1.1이나 HTTP/2)로 시작하는 경우가 많다.

원본 서버까지 가지 않아 RTT가 짧아지고 원본의 부하도 준다. 이미지·JS 같은 정적 파일에 많이 쓰고, TLS 종료와 공격 방어를 맡기기도 한다. Amazon CloudFront, Cloudflare가 대표적이다.

브라우저·OS 캐시에 답이 없으면 리졸버가 루트 네임서버 → TLD 네임서버 → 권한 네임서버 순서로 물어서 IP를 찾는다. 한 서버가 전부 아는 게 아니라, 각 단계가 "다음에 누구에게 물어보라"고 알려 주는 분산 구조다. 받은 답은 TTL 동안 캐시한다. 조회는 보통 UDP 53번 포트로 하고, 응답이 크면 TCP로 다시 묻는다.

서버 상태를 바꾸지 않아야 하고(안전), 여러 번 보내도 결과가 같아야 한다(멱등). 그래서 캐시하거나 다시 시도해도 된다. 데이터를 만들 때는 POST, 바꿀 때는 PUT·PATCH, 지울 때는 DELETE를 쓴다.

한 IP 주소에서 여러 사이트를 운영할 수 있는 것(가상 호스팅)이 이 헤더 덕분이다. HTTP/1.1에서는 반드시 넣어야 한다. HTTP/2·3에서는 :authority라는 필드가 같은 역할을 한다.

요청은 메서드(GET, POST…), 경로, 헤더, 본문으로, 응답은 상태 코드(200, 404…), 헤더, 본문으로 이뤄진다. 요청끼리 서로를 기억하지 않는(stateless) 규칙이라, 로그인 같은 상태는 쿠키나 토큰으로 이어 간다.

연결과 암호화 준비를 1 RTT에 끝내고, 전에 접속한 서버라면 0-RTT로 바로 데이터를 보낼 수도 있다. HTTP/2는 한 TCP 연결에 여러 요청을 싣기 때문에 패킷 하나가 빠지면 뒤의 모든 요청이 기다리는데(head-of-line blocking), QUIC은 요청(스트림)마다 따로 처리해서 그 영향을 줄인다. 사용자의 IP가 바뀌어도(와이파이 → LTE) 연결을 이어 갈 수 있다.

주고받는 내용(경로, 헤더, 본문)은 가려지지만, 접속한 서버의 IP와 (SNI에 담긴) 도메인 이름은 네트워크에서 보일 수 있다. 기본 포트는 443이다.

이름에 HTTPS가 들어가지만 레코드 종류의 이름이다. 브라우저가 IP와 함께 이 레코드를 받으면, Alt-Svc를 기다리지 않고 첫 접속부터 HTTP/3를 시도할 수 있다.

IPv4는 32비트(예: 203.0.113.10), IPv6는 128비트(예: 2001:db8::1)다. 사람은 도메인을 기억하고, 실제 연결은 IP로 한다. 그 사이를 DNS가 잇는다. 한 IP 뒤에 여러 사이트가 있을 수 있어서, HTTP의 Host 헤더나 TLS의 SNI로 어느 사이트인지 따로 알린다.

새 연결마다 드는 TCP·TLS 준비 왕복을 아낀다. HTTP/1.1부터 기본 동작이고, Connection: keep-alive 헤더는 HTTP/1.0 시절에 이를 켜던 방법이다. 오래 쓰지 않으면 서버가 정한 시간 뒤 닫는다. 이름이 비슷한 TCP keepalive는 연결이 살아 있는지 확인하는 신호를 보내는 다른 기능이다.

L4는 패킷 내용을 열어 보지 않아 빠르고 단순하다. L7은 /api는 A 서버, /images는 B 서버처럼 내용에 따라 보낼 수 있지만, 그러려면 TLS를 풀어서(TLS 종료) 내용을 읽어야 한다. AWS에서는 NLB가 L4, ALB가 L7이다. NLB도 TLS를 풀 수는 있지만 HTTP 내용을 보고 나누지는 않는다.

Google이 처음 만들 때는 Quick UDP Internet Connections의 줄임말이었지만, 표준에서는 줄임말이 아닌 이름 그대로다. 연결 설정과 암호화 협상을 한 번의 왕복으로 합친 것이 핵심이다.

연결 준비 비용을 "몇 RTT"로 센다. TCP 연결에 1 RTT, TLS 1.3 핸드셰이크에 1 RTT가 더 들어서, 새 연결은 첫 요청 전에 2 RTT를 쓴다. 서버가 멀수록 RTT가 길어지므로, 연결을 재사용하거나 가까운 곳(CDN)에서 응답하면 빨라진다.

한 IP에서 여러 도메인을 운영할 때, 서버는 SNI를 보고 어느 인증서를 보낼지 고른다. 이 이름은 암호화 전에 보내져서 네트워크에서 보인다. 그래서 HTTPS여도 어느 사이트에 접속했는지는 드러날 수 있다. 이를 가리는 ECH(Encrypted Client Hello)가 나와 있지만 아직 모든 곳에서 쓰이지는 않는다.

SYN-ACK은 두 플래그를 함께 켠 패킷이다. 연결을 끊을 때는 FIN 플래그를 쓴다. ACK은 연결을 만들 때뿐 아니라 데이터를 주고받는 내내 쓴다.

데이터를 보내기 전에 3-way handshake로 연결을 만들고, 잃어버린 패킷은 다시 보내고, 받는 쪽과 네트워크 상태에 맞춰 보내는 속도를 조절한다(흐름 제어, 혼잡 제어). HTTP/1.1과 HTTP/2가 TCP 위에서 동작한다.

DNS 조회에서 루트 네임서버는 TLD 네임서버의 위치를, TLD 네임서버는 그 도메인의 권한 네임서버 위치를 알려 준다. 도메인을 살 때 고르는 .com, .io가 TLD다.

SSL의 뒤를 이은 표준이라 지금도 SSL이라고 부르는 경우가 많다. 핸드셰이크에서 서버 인증서를 검증하고 암호화 키를 합의한다. TLS 1.3은 이 과정을 1 RTT로 줄였다(1.2는 2 RTT). HTTPS는 HTTP를 TLS 위에서 보내는 것이다.

인증서 관리와 암호화 연산을 한곳에 모으고, L7 로드밸런서가 HTTP 내용을 보고 나눌 수 있게 된다. 그 뒤 내부 구간(로드밸런서 → 서버)을 평문으로 둘지, 다시 암호화할지는 보안 요구에 따라 정한다.

권한 네임서버가 레코드마다 정한다. 길면 조회가 줄어 빠르고, 짧으면 바꾼 값이 빨리 퍼진다. 그래서 서버 이전 전에는 TTL을 미리 낮춰 두고, 옮긴 뒤 다시 올린다. 같은 이름이 IP 패킷에도 있는데, 그쪽은 시간이 아니라 패킷이 거쳐 갈 수 있는 라우터 수(홉)의 한도다.

가볍고 빠르지만 도착과 순서를 보장하지 않는다. 필요한 보장은 그 위의 프로그램이 직접 만든다. DNS 조회, 영상 통화, 그리고 HTTP/3가 쓰는 QUIC이 UDP 위에서 동작한다.

도메인 주인이 레코드를 관리하는 곳이다(예: AWS Route 53, 도메인 등록 업체의 DNS). A 레코드(IPv4), AAAA 레코드(IPv6), CNAME(다른 이름으로 연결) 같은 레코드를 둔다. 여기서 레코드를 바꿔도 리졸버가 캐시한 값은 TTL이 끝날 때까지 남는다.

한 서버에 몰리지 않게 나누고, 헬스체크로 응답하지 않는 서버를 빼서 장애가 사용자에게 덜 닿게 한다. 클라이언트의 TCP·TLS 연결 상대가 서버가 아니라 로드밸런서인 경우가 많다. AWS의 ALB·NLB, Nginx, HAProxy가 대표적이다.

보통 통신사(ISP)가 제공하거나, 8.8.8.8(Google), 1.1.1.1(Cloudflare) 같은 공용 리졸버를 쓴다. 리졸버가 TTL 동안 답을 캐시하기 때문에, 도메인의 IP를 바꿔도 사용자마다 바뀐 IP를 보는 시점이 다르다.

한 프로세스의 스레드들은 메모리(힙)를 함께 쓴다. 웹 서버는 요청마다 스레드 하나를 배정해 처리하는 방식이 많다(Spring MVC의 Tomcat 기본 방식). 함께 쓰는 메모리 때문에 동시에 같은 값을 고치면 문제가 생긴다.

브라우저와 OS에는 믿을 수 있는 루트 CA 목록이 미리 들어 있다. 서버 인증서의 서명을 따라 올라가 그 목록의 루트에 닿으면 믿는다. 서버가 중간 인증서를 빠뜨리고 보내면 일부 클라이언트에서만 인증서 오류가 나는 일이 생긴다.

DNS 응답, 웹 페이지, DB 조회 결과처럼 같은 것을 여러 번 쓰는 곳이면 어디든 쓴다. 빨라지는 대신 원본이 바뀌었을 때 옛 값을 보여 줄 수 있다. 그래서 캐시에는 언제까지 믿을지(TTL 같은 만료 시간)가 함께 붙는다.

연결을 만드는 비용(TCP·TLS 준비, DB 인증)을 요청마다 내지 않으려고 쓴다. Spring Boot(2.0 이상)의 기본 DB 커넥션 풀은 HikariCP다. 풀이 작으면 요청이 연결을 기다리고, 너무 크면 DB가 동시에 감당할 연결이 늘어 오히려 느려진다.

서버가 응답의 Set-Cookie 헤더로 주고, 브라우저는 요청의 Cookie 헤더로 돌려준다. HTTP가 요청끼리 기억하지 않기 때문에 로그인 세션 유지에 많이 쓴다. HttpOnly(스크립트에서 못 읽게), Secure(HTTPS에서만), SameSite(다른 사이트 요청에 붙일지) 속성으로 보안을 조절한다.

HTML로 DOM을, CSS로 CSSOM을 만들고, 둘을 합친 렌더 트리로 위치를 계산(레이아웃)한 뒤 화면에 칠한다(페인트). CSS와 동기 JS는 이 과정을 멈추게 해서, 첫 화면 속도를 볼 때 이 파일들의 크기와 순서를 먼저 본다.

TCP의 3-way handshake는 연결을, TLS 핸드셰이크는 암호화를 준비한다. 둘 다 왕복이 필요해서, 연결이 새로 생길 때마다 지연이 생긴다.

보통 /health 같은 주소에 요청을 보내 정해진 횟수만큼 연달아 실패하면 뺀다. 다시 정상 응답하면 되돌린다. 확인하는 범위(서버 프로세스만인지, DB 연결까지인지)를 어떻게 잡을지가 운영에서 자주 나오는 고민이다.

양쪽이 각자 시작 순서 번호(ISN)를 보내고, 상대가 그 번호를 받았다고 확인해 줘야 연결이 성립한다. 서버의 확인과 서버 자신의 번호를 한 번(SYN-ACK)에 합쳐서 네 번이 아니라 세 번이 된다. 클라이언트는 SYN-ACK을 받은 직후(1 RTT 뒤) 마지막 ACK과 함께 데이터를 보낼 수 있다.