테마
01. 인터넷 네트워크와 HTTP 시작
학습 목표
- HTTP를 이해하기 전에 왜 네트워크 기초가 필요한지 설명할 수 있다.
- IP의 역할과 한계를 구분할 수 있다.
- TCP가 무엇을 보완하는지, UDP와 무엇이 다른지 설명할 수 있다.
- TCP 3-way handshake의 목적을 큰 흐름으로 이해할 수 있다.
- Port와 DNS가 왜 필요한지 실무적인 감각으로 설명할 수 있다.
- HTTP가 결국 이 네트워크 기반 위에서 동작한다는 점을 연결해서 이해할 수 있다.
전체 구조
1. 왜 HTTP 앞에 네트워크를 먼저 알아야 할까?
HTTP는 그냥 “웹에서 쓰는 규칙”이 아니다. 실제로는 인터넷 네트워크 위에서 동작하는 애플리케이션 계층 프로토콜이다.
즉, 브라우저가 만든 HTTP 요청도 결국은 네트워크를 타고 서버까지 전달되어야 한다.
HTTP만 따로 떼어 외우면 이런 질문에서 자꾸 막힌다.
- 왜 요청을 보내도 응답이 안 올 수 있을까?
- 왜 HTTP/1.1은 연결 비용을 신경 쓰고, HTTP/2나 HTTP/3은 성능 이야기를 많이 할까?
- 왜 도메인을 쓰는데 실제 통신은 IP 주소로 이루어질까?
이 질문들의 바닥에는 모두 네트워크가 있다.
핵심 직관: HTTP는 “내용을 어떻게 주고받을지”를 정하는 규칙이고, 네트워크는 “그 내용을 실제로 어떻게 전달할지”를 담당한다.
2. 인터넷 통신의 가장 단순한 그림
인터넷 통신을 아주 단순하게 줄이면 다음 세 요소가 있다.
- 클라이언트: 요청을 보내는 쪽
- 서버: 요청을 받아 처리하고 응답하는 쪽
- 인터넷 네트워크: 둘 사이에서 데이터를 전달하는 경로
여기서 중요한 점은, 클라이언트와 서버가 직접 붙어 있는 것이 아니라 네트워크를 사이에 두고 떨어져 있다는 사실이다.
그래서 “상대가 누구인지”, “어디로 보내야 하는지”, “잘 도착했는지”, “어떤 프로그램이 받아야 하는지” 같은 정보가 필요하다.
이 문제를 차례대로 해결하는 것이 IP, TCP/UDP, Port, DNS다.
3. IP: 인터넷에서 목적지를 찾는 기본 주소 체계
IP가 하는 일
IP(Internet Protocol)는 인터넷에서 어느 컴퓨터로 보낼지를 지정하는 기본 규칙이다.
쉽게 말해 IP 주소는 인터넷 세계의 주소다.
브라우저가 서버에 데이터를 보내려면 최소한 아래 정보가 필요하다.
- 출발지 IP 주소
- 목적지 IP 주소
- 전달할 데이터
패킷이라는 포장 단위
네트워크에서는 데이터를 보통 패킷(Packet) 단위로 나눠서 보낸다.
택배 상자에 주소표를 붙이듯, 데이터에도 출발지와 목적지 정보가 붙는다.
| 구성 요소 | 의미 |
|---|---|
| 출발지 IP | 누가 보냈는가 |
| 목적지 IP | 어디로 보내야 하는가 |
| 데이터 | 실제 전달할 내용 |
그런데 IP만으로는 부족하다
IP는 목적지를 향해 보내는 일은 하지만, 그것만으로는 실무에 필요한 통신 품질을 보장하지 못한다.
| IP의 한계 | 왜 문제인가 |
|---|---|
| 비연결성 | 상대 서버가 꺼져 있어도 일단 보낸다 |
| 비신뢰성 | 중간에 패킷이 사라져도 모를 수 있다 |
| 순서 보장 없음 | 여러 패킷이 뒤죽박죽 도착할 수 있다 |
| 프로그램 구분 불가 | 같은 컴퓨터 안에서 어떤 앱이 받아야 하는지 모른다 |
한 줄 정리: IP는 “어디로 보낼지”는 해결하지만, “정확하게 잘 도착했는지”까지는 책임지지 않는다.
4. TCP: 연결과 신뢰를 보완하는 전송 규칙
TCP가 필요한 이유
TCP(Transmission Control Protocol)는 IP 위에서 동작하면서, IP의 부족한 부분을 많이 보완한다.
TCP를 쓰면 다음 성질을 기대할 수 있다.
- 연결 지향: 보내기 전에 상대와 연결을 확인한다
- 전달 보장: 보내고 끝이 아니라, 잘 받았는지 확인한다
- 순서 보장: 먼저 보낸 것이 먼저 오도록 맞춘다
그래서 HTTP/1.1, HTTP/2는 기본적으로 TCP 위에서 동작한다.
TCP 3-way handshake
TCP는 실제 데이터를 보내기 전에 먼저 “우리 통신해도 되지?”를 확인한다.
이 과정을 대표적으로 3-way handshake라고 부른다.
단계로 보기
TCP 연결은 세 번의 확인으로 시작한다
1 / 3SYN
클라이언트가 서버에게 연결을 시작해도 되는지 묻는다. 아직 데이터 전송이 아니라 연결 준비 요청이다.
스스로 확인
TCP는 왜 데이터를 바로 보내지 않고 3-way handshake를 먼저 할까?
이 흐름을 실무 감각으로 풀어 쓰면 이렇다.
- 클라이언트가 “연결할래?” 하고 요청한다.
- 서버가 “좋아, 너 요청 받았어”라고 답한다.
- 클라이언트가 “응답 확인했어”라고 마무리한다.
이제야 본격적인 데이터 전송을 시작한다.
TCP의 장점과 비용
TCP는 신뢰성이 높다. 대신 그만큼 절차가 더 많고, 연결을 맺고 관리하는 비용이 있다.
| 항목 | TCP의 성격 |
|---|---|
| 연결 설정 | 필요 |
| 전달 확인 | 가능 |
| 순서 보장 | 가능 |
| 신뢰성 | 높음 |
| 오버헤드 | UDP보다 큼 |
핵심 직관: TCP는 그냥 “빨리 보내는 규칙”이 아니라, 실수 없이 보내기 위한 약속이다.
5. UDP: 단순함이 강점인 전송 방식
UDP(User Datagram Protocol)는 TCP보다 훨씬 단순하다.
- 연결을 먼저 맺지 않는다
- 전달 보장을 기본 제공하지 않는다
- 순서 보장도 기본 제공하지 않는다
- 대신 구조가 단순하고 가볍다
그래서 “신뢰성은 애플리케이션이 직접 챙기고, 전송 계층은 최대한 가볍게 가겠다”는 상황에서 유리하다.
TCP와 UDP 비교
| 항목 | TCP | UDP |
|---|---|---|
| 연결 설정 | 있음 | 없음 |
| 전달 보장 | 있음 | 없음 |
| 순서 보장 | 있음 | 없음 |
| 속성 | 신뢰 중심 | 단순함 중심 |
| 대표 활용 | HTTP/1.1, HTTP/2 | DNS, 실시간 스트리밍, QUIC 기반 통신 |
그럼 UDP는 왜 아직 중요한가?
예전에는 “신뢰성이 없으니 TCP보다 못한 것 아닌가?”라고 오해하기 쉬웠다.
하지만 요즘은 꼭 그렇지 않다.
- DNS 질의처럼 짧고 빠른 요청에는 UDP가 잘 맞는다
- 실시간 통신에서는 약간의 손실보다 지연 감소가 더 중요할 수 있다
- HTTP/3는 QUIC이라는 방식을 통해 UDP 위에서 더 빠른 연결과 복구 전략을 구현한다
6. Port: 같은 컴퓨터 안에서 어떤 프로그램이 받을까?
IP 주소는 컴퓨터를 찾는 주소다.
그런데 실제 컴퓨터 안에는 여러 프로그램이 동시에 네트워크를 사용한다.
예를 들어 한 서버 안에 이런 프로그램이 같이 있을 수 있다.
- 웹 서버
- API 서버
- 데이터베이스
- SSH 서버
이때 “이 패킷을 어느 프로그램이 받아야 하지?”를 구분해 주는 번호가 Port다.
아파트 비유
- IP 주소: 아파트 건물 주소
- Port 번호: 몇 동 몇 호
즉, IP만 알면 건물까지만 간다. 실제로 누구에게 전달할지는 Port가 알려준다.
자주 보는 포트
| 포트 | 의미 |
|---|---|
| 80 | HTTP 기본 포트 |
| 443 | HTTPS 기본 포트 |
| 22 | SSH |
| 3306 | MySQL |
| 5432 | PostgreSQL |
브라우저에서
https://example.com처럼 포트를 생략해도 되는 이유는, 프로토콜별 기본 포트가 약속되어 있기 때문이다.
7. DNS: 사람이 읽는 이름을 IP 주소로 바꾸는 시스템
왜 DNS가 필요한가?
IP 주소는 기계가 다루기 좋지만 사람이 외우기에는 불편하다.
172.217.175.110은 외우기 어렵다- 서버 IP는 운영 중에 바뀔 수도 있다
그래서 우리는 google.com처럼 도메인 이름을 쓰고, 실제 통신 직전에 DNS가 이를 IP 주소로 바꿔 준다.
DNS를 전화번호부로 이해하기
- 사람은 이름을 기억한다
- 컴퓨터는 IP 주소를 사용한다
- DNS는 둘 사이를 연결하는 전화번호부 역할을 한다
브라우저 입장에서 보는 흐름
8. 정리: HTTP는 결국 이 기반 위에서 동작한다
지금까지 본 개념을 한 줄로 연결하면 이렇다.
- DNS가 도메인을 IP로 바꾼다.
- IP가 목적지 컴퓨터까지 데이터를 보낸다.
- TCP 또는 UDP가 전송 방식을 담당한다.
- Port가 어떤 프로그램이 받을지 구분한다.
- 그 위에서 HTTP가 요청과 응답의 의미를 정한다.
이 장에서 중요한 것은 “HTTP만 따로 떠 있는 것이 아니라, 네트워크 계층 위에서 작동하는 규칙”이라는 감각을 잡는 것이다.
다음 장에서는 이 기반 위에서 실제로 우리가 매일 보는 URI/URL과 브라우저 요청 흐름을 이어서 정리한다.
핵심 암기 포인트
IP: 목적지 컴퓨터를 찾기 위한 주소 체계. 하지만 연결, 전달 보장, 순서 보장까지는 해결하지 못한다.
TCP: 연결 지향, 전달 보장, 순서 보장. HTTP/1.1과 HTTP/2의 기반이다.
UDP: 단순하고 가볍다. DNS나 QUIC/HTTP/3 같은 상황에서 중요하다.
Port: 같은 IP 안에서 어떤 프로그램이 받을지 구분하는 번호다.
DNS: 사람이 읽는 도메인 이름을 실제 통신 가능한 IP 주소로 바꿔 준다.
핵심 연결: HTTP는 네트워크 위에서 동작하는 애플리케이션 계층 프로토콜이다.
확인 질문
- IP만으로는 왜 안정적인 웹 통신을 보장하기 어려운가?
- TCP 3-way handshake는 왜 필요한가?
- UDP는 “기능이 적다”는 점이 왜 오히려 장점이 될 수 있는가?
- IP 주소와 Port 번호의 역할 차이는 무엇인가?
- 사용자가
https://example.com을 입력했을 때 DNS는 어떤 일을 하는가?