웹 통신에 쓰이는 프로토콜
브라우저로 웹 페이지를 열 때는 앞선 편에서 정리한 프로토콜이 한꺼번에 동작한다.
| 구성 | 하는 일 | 계층(2편 기준) |
|---|---|---|
| DNS | 도메인 이름으로 서버의 IP 주소를 찾는다 | 응용 |
| HTTP/HTTPS | 클라이언트와 서버가 요청과 응답으로 대화하는 규칙 | 응용 |
| TCP/IP | 데이터가 인터넷을 오가는 방식을 정한다 | 전송/인터넷 |
HTTP는 응용 계층 프로토콜이고 TCP 위에서, 또는 TLS로 암호화한 TCP 위에서 전달된다. HTTPS는 HTTP를 암호화한 안전한 버전이다. 데이터는 한 덩어리가 아니라 작은 패킷 여러 개로 나뉘어 오가고 각 패킷의 헤더에는 서버와 클라이언트의 IP 주소, 패킷 번호, 전체 패킷 수 같은 정보가 들어 있다. 패킷은 서로 다른 경로로 갈 수 있어서 순서가 뒤바뀌어 도착해도 헤더 정보로 올바른 순서로 다시 맞춘다. 일부가 유실되면 파일 전체가 아니라 빠진 패킷만 다시 요청하면 된다.
클라이언트와 서버
인터넷에 연결된 컴퓨터는 클라이언트와 서버로 나뉜다. 클라이언트는 사용자의 기기와 그 위의 웹 접속 소프트웨어(보통 브라우저)이고 서버는 웹 페이지나 앱을 저장한 컴퓨터다. HTTP는 클라이언트-서버 프로토콜이라서 요청은 항상 클라이언트(브라우저)가 시작한다. 서버가 먼저 요청을 보내지는 않는다.
서버는 겉으로는 한 대처럼 보이지만 실제로는 부하를 나눠 맡는 여러 서버(로드 밸런싱)이거나, 문서를 그때그때 만들어 내는 캐시/데이터베이스 같은 다른 소프트웨어일 수도 있다. 한 서버 머신에서 여러 서버 프로그램이 돌 수 있고 HTTP/1.1의 Host 헤더 덕분에 같은 IP 주소를 공유할 수도 있다. 브라우저와 서버 사이에는 요청을 중계하는 프록시도 있다. 프록시는 캐싱/필터링/로드 밸런싱/인증/로깅 같은 일을 한다. 이렇게 보면 서브넷이나 라우터도 이 요청이 지나가는 길목이다.
URL과 URI
웹 주소를 정확히 부르면 URL이다. URI는 웹의 리소스를 식별하는 이름이고, 가장 흔한 URI의 종류가 웹 주소로 알려진 URL이다. 정리하면 URL은 URI의 한 종류다. 다음 예시로 구성 요소를 나눠 보면 (예시는 직접 만든 주소)
https://www.example.com:443/docs/page?lang=ko&sort=new#intro| 구성 | 예시 | 설명 |
|---|---|---|
| 스킴(프로토콜) | https | 리소스를 요청할 때 브라우저가 쓸 프로토콜 |
| 권한(도메인 + 포트) | www.example.com:443 | 어느 서버인지와 접속할 포트. HTTP 80/HTTPS 443이면 생략 가능 |
| 경로 | /docs/page | 서버에서 리소스의 위치. 지금은 실제 파일 위치가 아닌 추상화된 경로가 많다 |
| 쿼리 | ?lang=ko&sort=new | 서버에 추가로 전달하는 키/값 쌍, &로 구분 |
| 프래그먼트 | #intro | 리소스 안의 특정 위치. 서버로는 전송되지 않는다 |
도메인 대신 IP 주소를 쓸 수도 있지만 훨씬 불편해서 드물다. 이 도메인이 IP로 바뀌는 과정이 DNS의 주제다. 문서 안의 링크에는 일부가 생략된 상대 URL도 쓰이는데 브라우저가 현재 문서의 URL로 빠진 부분을 채운다.
요청과 응답의 구조
HTTP 메시지는 요청과 응답 두 종류이고, 사람이 읽을 수 있게 설계됐다. 요청의 구성은 이렇다.
| 요청 구성 | 설명 |
|---|---|
| 메서드 | 하려는 동작. 리소스를 가져오는 GET, 폼 값을 보내는 POST 등 |
| 경로 | 가져올 리소스의 경로(URL에서 스킴/도메인/포트를 뺀 부분) |
| HTTP 버전 | 사용하는 프로토콜 버전 |
| 헤더(선택) | 서버에 전달하는 추가 정보 |
| 본문(선택) | POST처럼 보낼 데이터가 있을 때 |
응답은 HTTP 버전, 상태 코드와 상태 메시지, 헤더, 그리고 가져온 리소스를 담은 본문(선택)으로 이루어진다. 자주 보는 상태 코드는 아래와 같다.
| 코드 | 의미 |
|---|---|
| 200 | 요청 성공 |
| 301 | 리소스가 영구적으로 새 위치로 이동(응답에 새 위치가 포함) |
| 400 | 요청 형식이 잘못되어 서버가 처리할 수 없음 |
| 403 | 서버가 접근을 허용하지 않음(누군지는 알지만 권한이 없는 경우) |
| 404 | 요청한 리소스를 찾을 수 없음 |
| 503 | 서버 쪽 문제로 처리할 수 없음(점검 중처럼 일시적인 경우가 많음) |
HTTP 자체는 상태를 저장하지 않는(stateless) 프로토콜이라 연속된 두 요청 사이에 연결 고리가 없다. 그래서 쇼핑몰 장바구니처럼 맥락이 필요한 서비스는 쿠키로 세션을 만든다. HTTP가 상태가 없다는 것과 세션이 없다는 것은 다르다.
한 번의 웹 접속 흐름
주소를 입력하고 페이지가 뜨기까지를 순서대로 정리하면 이렇다.
| 단계 | 일어나는 일 |
|---|---|
| 1 | 브라우저가 DNS로 서버의 실제 IP 주소를 찾는다 |
| 2 | 브라우저가 서버와 TCP 연결을 맺는다(왕복이 여러 번 필요) |
| 3 | 브라우저가 HTTP 요청 메시지를 보내고, 이 메시지는 TCP/IP로 전달된다 |
| 4 | 서버가 요청을 승인하면 200 상태 코드와 함께 파일을 작은 패킷으로 나눠 보낸다 |
| 5 | 브라우저가 패킷을 모아 페이지를 완성해 보여 준다 |
| 6 | 연결을 닫거나 다음 요청에 재사용한다 |
HTTP/1.0은 요청마다 TCP 연결을 새로 열어서 비효율적이었고, HTTP/1.1이 연결을 재사용하는 지속 연결을 도입했다. HTTP/2는 한 연결에서 메시지를 동시에 여러 개 주고받는 멀티플렉싱으로 더 효율을 높였다. 페이지 하나는 HTML뿐 아니라 CSS/JavaScript/이미지 같은 여러 리소스로 이루어져서 브라우저는 HTML을 받은 뒤 필요한 리소스를 추가로 요청한다.
핵심 복습
| 키워드 | 한 줄 정리 |
|---|---|
| 클라이언트/서버 | 요청은 항상 브라우저(클라이언트)가 시작 |
| 프록시 | 브라우저와 서버 사이에서 캐싱/필터링/로드 밸런싱 등을 수행 |
| URI/URL | URI는 리소스 식별자, URL은 그중 웹 주소 |
| URL 구성 | 스킴/도메인/포트/경로/쿼리/프래그먼트 |
| HTTP 메시지 | 요청은 메서드+경로+버전+헤더, 응답은 버전+상태 코드+헤더+본문 |
| 상태 코드 | 200 성공, 301 이동, 403 권한 없음, 404 없음, 503 서버 문제 |
| stateless | HTTP는 상태를 저장하지 않고 쿠키로 세션을 보완 |
| 접속 흐름 | DNS 조회 → TCP 연결 → HTTP 요청 → 응답(패킷) → 페이지 완성 |
📍 참고 자료
확인일: 2026-10-03
