URI, URL, URN부터 웹 브라우저 요청 흐름까지 한 번에 이해하기

웹 개발을 공부하다 보면 정말 자주 보는 단어들이 있다.

URI
URL
URN
HTTP
DNS
TCP/IP

특히 URL은 인터넷을 사용하면서 수도 없이 봤다.

예를 들어 Google에서 hello를 검색하면 주소창에는 대략 이런 주소가 나타난다.

https://www.google.com/search?q=hello&hl=ko

그런데 생각해보면 나는 지금까지 이 주소를 그냥

"웹사이트 주소"

정도로만 생각하고 있었다.

하지만 이 한 줄 안에는 생각보다 많은 정보가 들어 있다.

어떤 방식으로 접근할 것인지

어느 서버로 갈 것인지

어떤 경로의 리소스를 원하는지

서버에게 어떤 데이터를 전달할 것인지

그리고 주소창에 URL을 입력하고 Enter를 누르는 순간
브라우저 뒤에서는 DNS 조회부터 HTTP 메시지 생성, TCP/IP 통신, 서버 응답까지 여러 과정이 진행된다.

이번 글에서는 URI, URL, URN의 차이부터 시작해서

브라우저 주소창에 URL을 입력했을 때 실제로 무슨 일이 일어나는가?

까지 정리해보고자 한다.

---

URI란 무엇일까?

먼저 가장 큰 개념인 URI부터 알아보자.

URI의 풀네임은

Uniform Resource Identifier

이다.

단어를 하나씩 뜯어보면 이해하기 쉽다.

---

Uniform

Uniform은 통일된 방식이라는 의미다.

인터넷에는 정말 다양한 종류의 리소스가 존재한다.

HTML 문서

이미지

동영상

파일

API

게시글

사용자 정보

이런 리소스들을 제각각 다른 방법으로 식별하면 사용하기 굉장히 불편할 것이다.

그래서

리소스를 식별하는 통일된 방법

을 사용하는 것이다.

---

Resource

Resource는 자원이라는 의미다.

웹에서 식별할 수 있는 대상이라면 거의 무엇이든 Resource가 될 수 있다.

예를 들어

웹 페이지

이미지

회원 정보

상품 정보

파일

API 결과

등을 생각할 수 있다.

즉 Resource라고 해서 반드시 실제 파일이어야 하는 것은 아니다.

URI를 통해 식별할 수 있는 대상이라면 Resource가 될 수 있다.

---

Identifier

Identifier는 식별자라는 의미다.

쉽게 말하면

다른 것과 구분할 수 있도록 해주는 정보

다.

학교에 학생이 수천 명 있어도

학번

을 이용하면 특정 학생을 구분할 수 있는 것과 비슷하다.

따라서 URI를 정말 쉽게 표현하면

인터넷의 어떤 Resource를 다른 Resource와 구분하기 위한 통일된 식별 방법

이라고 이해할 수 있다.

---

URI, URL, URN은 무슨 관계일까?

여기서 우리가 많이 들어봤던

URL
URN

이 등장한다.

URI는 Resource를 식별하는 큰 개념이고,
Resource를 식별하는 방법은 크게 위치와 이름이라는 관점으로 나누어 생각할 수 있다.

URI
│
├── URL
│   └── Resource의 위치로 식별
│
└── URN
    └── Resource의 이름으로 식별

각각의 풀네임은 다음과 같다.

URI
Uniform Resource Identifier

URL
Uniform Resource Locator

URN
Uniform Resource Name

---

URL이란?

URL에서 중요한 단어는

Locator

다.

즉,

Resource가 어디에 있는지를 이용해서 Resource를 식별한다.

예를 들어

https://www.google.com/search?q=hello

라는 URL은

https를 사용해서

www.google.com이라는 서버의

/search라는 위치에 접근한다.

는 정보를 가지고 있다.

즉 Resource의 위치(Location)를 기반으로 식별하는 방식이다.

---

URN이란?

URN에서는

Name

이 중요하다.

즉 Resource의 위치가 아니라

Resource 자체에 부여된 이름으로 식별한다.

예를 들어 강의 자료에서는 다음과 같은 예시가 등장한다.

urn:isbn:8960777331

책에는 ISBN이라는 고유한 번호가 있다.

책이

서울의 서점에 있든

미국 도서관에 있든

내 책장에 있든

책 자체의 ISBN은 변하지 않는다.

그래서

URL
→ Resource가 있는 위치

URN
→ Resource에 부여된 이름

이라고 이해할 수 있다.

위치는 바뀔 수 있지만
이름 자체는 유지될 수 있다는 차이가 있다.

다만 URN만 가지고 실제 Resource를 찾아가는 방식은 URL만큼 보편적으로 사용되고 있지 않다.

그래서 이후 웹 개발에서는 URI라는 말을 사용할 때
실제로는 URL을 이야기하는 경우가 많다.

---

RFC에 나오는 URL과 URN 예시

강의 자료에는 URI 표준의 예시로 다음과 같은 주소가 등장한다.

foo://example.com:8042/over/there?name=ferret#nose

처음 보면 굉장히 복잡해 보이지만
사실 여러 영역이 합쳐진 것이다.

foo://example.com:8042/over/there?name=ferret#nose

foo
└─ scheme

example.com:8042
└─ authority

/over/there
└─ path

name=ferret
└─ query

nose
└─ fragment

반면 URN 예시는 다음과 같다.

urn:example:animal:ferret:nose

첫 번째는 Resource가 존재하는 위치를 표현하는 URL의 형태이고,
두 번째는 Resource에 이름을 부여해서 식별하는 URN의 형태라고 이해할 수 있다.

---

우리가 실제로 사용하는 URL을 분석해보자

이제 실제로 익숙한 URL을 하나 가져와보자.

Google에서 hello를 검색했다고 해보자.

https://www.google.com:443/search?q=hello&hl=ko

이 주소를 구성 요소별로 나누면 다음과 같다.

https
→ scheme

www.google.com
→ host

443
→ port

/search
→ path

q=hello&hl=ko
→ query

URL의 전체적인 문법은 다음과 같다.

scheme://[userinfo@]host[:port][/path][?query][#fragment]

처음에는 상당히 복잡해 보이지만
하나씩 보면 그렇게 어렵지 않다.

---

1. Scheme

먼저 scheme이다.

https://www.google.com
^^^^^

여기서는

https

가 Scheme이다.

Scheme에는 주로 어떤 프로토콜을 사용할 것인지가 들어간다.

예를 들어

http

https

ftp

등이 있다.

---

프로토콜이란?

프로토콜(Protocol)은 쉽게 말하면

통신을 하기 위해 서로 정해놓은 규칙

이다.

사람끼리 대화할 때도 서로 같은 언어와 규칙을 사용해야 한다.

한 사람은 한국어를 사용하고
다른 사람은 전혀 이해하지 못하는 언어를 사용한다면 제대로 대화하기 어렵다.

컴퓨터도 마찬가지다.

데이터를 어떤 형식으로 보낼 것인지

어떤 방식으로 요청할 것인지

어떤 방식으로 응답할 것인지

같은 규칙이 필요하다.

이러한 약속을 Protocol이라고 한다.

---

HTTP와 HTTPS의 차이는?

웹에서 가장 많이 보는 Scheme은

http

https

다.

HTTP는

HyperText Transfer Protocol

이고,

HTTPS는 HTTP 통신에 TLS를 통한 보안 기능을 적용한 형태라고 이해하면 된다.

HTTP 통신을 그대로 사용하면
네트워크를 통해 전달되는 정보가 보호되지 않을 수 있다.

HTTPS에서는 TLS를 통해 통신 내용을 암호화하고
서버 인증 및 데이터 무결성 보호 등을 제공한다.

그래서 현재 대부분의 웹 서비스는 HTTPS를 사용한다.

주소창에서 흔히 보는

https://

가 바로 이것이다.

---

2. Userinfo

URL의 전체 문법을 다시 보자.

scheme://[userinfo@]host[:port][/path][?query][#fragment]

여기에는 userinfo라는 것도 존재한다.

Userinfo는 URL 안에 사용자 정보를 포함해서 인증 등에 사용하는 영역이다.

형태는 대략

scheme://userinfo@host

처럼 표현될 수 있다.

하지만 현재 일반적인 웹 서비스에서는
거의 사용하지 않는 방식이다.

따라서

"URL 문법상 이런 영역도 존재한다."

정도로 알고 넘어가면 될 것 같다.

---

3. Host

다음은 Host다.

https://www.google.com:443/search?q=hello&hl=ko
        ^^^^^^^^^^^^^^

여기서는

www.google.com

이 Host다.

Host에는

Domain Name

또는

IP Address

를 사용할 수 있다.

예를 들어

www.google.com

처럼 Domain Name을 사용할 수도 있고,

200.200.200.2

처럼 IP 주소를 직접 사용할 수도 있다.

결국 Host는

어느 서버로 요청을 보낼 것인가?

를 결정하는 정보라고 생각할 수 있다.

---

4. PORT

다음은 PORT다.

https://www.google.com:443/search?q=hello&hl=ko
                      ^^^

여기서는

443

이 PORT 번호다.

IP 주소가

"어느 컴퓨터인가?"

를 구분한다면,

PORT는

"그 컴퓨터의 어느 통신 Endpoint로 접근할 것인가?"

를 구분하는 데 사용된다.

HTTP와 HTTPS에는 일반적으로 사용하는 기본 PORT가 있다.

HTTP
→ 80

HTTPS
→ 443

그래서 다음 두 주소는 기본 HTTPS PORT를 사용하는 경우 같은 의미로 볼 수 있다.

https://www.google.com:443

https://www.google.com

기본 PORT는 생략할 수 있기 때문이다.

그래서 평소 웹사이트 주소에서

:443

을 거의 보지 못했던 것이다.

---

5. Path

다음은 Path다.

https://www.google.com:443/search?q=hello&hl=ko
                          ^^^^^^^

여기서는

/search

가 Path다.

Path는

Resource가 위치한 경로

를 나타낸다.

그리고 일반적으로 계층적인 구조를 가진다.

예를 들어

/home/file1.jpg

라면

home
↓
file1.jpg

라는 경로를 생각할 수 있다.

웹 API에서도 많이 볼 수 있다.

/members

전체 회원과 관련된 Resource라고 생각할 수 있고,

/members/100

이라면

100번 회원

을 표현하는 식이다.

또

/items/iphone12

처럼 특정 상품 Resource를 표현할 수도 있다.

백엔드 개발을 하다 보면 정말 많이 보게 되는 부분이다.

예를 들어 Spring에서

@GetMapping("/members/{id}")

를 작성하는 것도 결국 URL의 Path와 연결되는 개념이다.

---

6. Query

다음은 Query다.

https://www.google.com/search?q=hello&hl=ko
                              ^^^^^^^^^^^^^

여기서는

q=hello&hl=ko

가 Query다.

Query는 일반적으로

key=value

형태로 작성한다.

그리고

?

로 시작한다.

여러 값을 전달하고 싶다면

&

를 이용해서 연결할 수 있다.

예를 들어

?keyA=valueA&keyB=valueB

처럼 사용할 수 있다.

Google 예시를 다시 보면

?q=hello&hl=ko

이고 이를 나누면

q=hello

hl=ko

다.

쉽게 생각하면

q
→ 검색어

hello
→ 검색할 내용

hl
→ 언어 관련 파라미터

ko
→ 한국어

정도로 볼 수 있다.

즉 서버에게

"hello를 검색해줘. 그리고 언어 설정은 ko야."

라는 추가적인 정보를 전달하는 것이다.

Query는

Query Parameter

Query String

등으로 부르기도 한다.

---

7. Fragment

마지막은 Fragment다.

강의 자료에서는 다음과 같은 예시가 나온다.

https://docs.spring.io/.../getting-started.html#getting-started-introducing-spring-boot

여기서

#getting-started-introducing-spring-boot

부분이 Fragment다.

Fragment는 HTML 문서 내부의 특정 위치를 가리키는
북마크 같은 용도로 사용할 수 있다.

예를 들어 굉장히 긴 문서가 있을 때

페이지 맨 위부터 보여줘

가 아니라

이 문서의 특정 제목 부분부터 보여줘

라고 지정할 수 있는 것이다.

여기서 중요한 특징이 하나 있다.

Fragment는 서버에 전송되는 정보가 아니다.

브라우저가 받아온 Resource 안에서
특정 위치를 찾아가는 용도로 사용된다.

---

URL 구조 전체 정리

지금까지의 내용을 하나로 합쳐보자.

https://www.google.com:443/search?q=hello&hl=ko

를 분석하면

https
→ Scheme
→ 어떤 Protocol을 사용할 것인가?

www.google.com
→ Host
→ 어느 서버인가?

443
→ Port
→ 서버의 어느 통신 Endpoint인가?

/search
→ Path
→ 어떤 Resource 경로인가?

q=hello&hl=ko
→ Query
→ 서버에 어떤 추가 정보를 전달할 것인가?

그리고 URL 문법상 추가로

userinfo

fragment

도 존재한다.

전체 문법은 다시 다음과 같다.

scheme://[userinfo@]host[:port][/path][?query][#fragment]

---

정보처리기사 실기에서도 URL 구조가 나온다

개인적으로 이 부분은 조금 더 주의해서 봐야 할 것 같다.

현재 정보처리기사 실기도 준비하고 있는데
URL의 구성 요소를 구분하는 내용이 시험에서도 등장할 수 있기 때문이다.

그래서 최소한 다음 구조 정도는 기억해두려고 한다.

scheme://[userinfo@]host[:port][/path][?query][#fragment]

그리고 각각의 의미도 연결해서 기억해야겠다.

scheme
→ 접근 방식 / Protocol

userinfo
→ 사용자 정보

host
→ Domain 또는 IP

port
→ 접속 PORT

path
→ Resource 경로

query
→ 서버에 전달하는 Parameter

fragment
→ 문서 내부 특정 위치

단순히 순서만 외우기보다는
실제 URL 하나를 가져와서 직접 분해해보는 게 훨씬 기억에 잘 남는 것 같다.

---

이제 진짜 궁금한 것

여기까지 URL의 구조를 이해했다.

그런데 진짜 궁금한 것은 이것이다.

브라우저에

https://www.google.com/search?q=hello&hl=ko

를 입력하고 Enter를 누르면

대체 내 컴퓨터에서는 무슨 일이 일어나는 걸까?

주소를 입력하자마자 Google 서버에서
검색 결과가 순간적으로 나타난다.

하지만 그 짧은 시간 동안
뒤에서는 생각보다 많은 과정이 일어난다.

이제 웹 브라우저의 요청 흐름을 살펴보자.

---

웹 브라우저 요청 흐름

상황을 단순하게 만들어보자.

내 컴퓨터의 IP가

100.100.100.1

이고,

Google 서버의 IP가

200.200.200.2

라고 가정해보자.

그리고 브라우저에 다음 URL을 입력한다.

https://www.google.com/search?q=hello&hl=ko

이제 브라우저가 해야 할 일이 시작된다.

---

1. 먼저 Google의 IP 주소를 알아내야 한다

URL에는

www.google.com

이라는 Domain Name이 들어 있다.

하지만 실제 IP 통신을 하기 위해서는
목적지의 IP 주소가 필요하다.

그래서 브라우저는 먼저 DNS 조회를 진행한다.

DNS는 이전 글에서도 정리했듯이
Domain Name을 IP 주소로 변환해주는 시스템이다.

쉽게 말하면 인터넷의 전화번호부와 비슷하다.

www.google.com
↓
DNS 조회
↓
200.200.200.2

강의에서는 이해를 위해 Google 서버의 IP 주소를 다음과 같이 가정했다.

Google Server

IP
200.200.200.2

이제 브라우저는

www.google.com

이라는 이름뿐만 아니라

200.200.200.2

라는 실제 목적지 IP 주소까지 알아냈다.

---

2. PORT 번호도 알아야 한다

그다음 필요한 것은 PORT다.

우리가 입력한 URL은

https://www.google.com/search?q=hello&hl=ko

이다.

여기에는 PORT 번호가 보이지 않는다.

하지만 앞에서 살펴봤듯이 HTTPS는 일반적으로

443

PORT를 사용한다.

따라서 생략된 PORT까지 포함해서 생각하면

https://www.google.com:443/search?q=hello&hl=ko

라고 볼 수 있다.

결국 브라우저가 알아낸 목적지는 단순히

200.200.200.2

만 있는 것이 아니라

IP
200.200.200.2

PORT
443

라고 생각할 수 있다.

즉 이제

어느 컴퓨터로 갈 것인지
+
그 컴퓨터의 어느 통신 Endpoint로 접근할 것인지

까지 알아낸 것이다.

---

3. 브라우저가 HTTP 요청 메시지를 만든다

목적지를 알아냈다면
이제 브라우저는 서버에게 무엇을 원하는지 알려줘야 한다.

우리가 입력한 URL을 다시 보자.

https://www.google.com/search?q=hello&hl=ko

여기에서

/search

라는 Path로 접근하고,

q=hello&hl=ko

라는 Query Parameter를 전달하고 있다.

이를 바탕으로 브라우저는 다음과 같은 HTTP 요청 메시지를 만든다.

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

처음 보면 뭔가 복잡해 보이지만
지금 단계에서는 대략 이렇게 읽으면 된다.

GET
→ 서버의 Resource를 조회하고 싶다.

/search?q=hello&hl=ko
→ /search에 접근하면서
  q=hello, hl=ko라는 값을 전달한다.

HTTP/1.1
→ HTTP/1.1 형식으로 통신한다.

Host: www.google.com
→ 요청을 보내려는 Host는 www.google.com이다.

즉 브라우저는 URL을 보고

"www.google.com 서버에서
hello라는 검색어를 한국어 설정으로 검색하고 싶어."

라는 요청을 HTTP 메시지 형태로 만들어낸 것이다.

---

그런데 HTTP 메시지만 인터넷에 던지면 되는 걸까?

현재 브라우저가 만든 것은 다음과 같은 HTTP 메시지다.

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

하지만 이것만 그대로 인터넷에 던지는 것은 아니다.

앞에서 IP와 TCP를 공부하면서 살펴봤듯이
인터넷을 통해 데이터를 전달하기 위해서는 TCP/IP 계층을 거쳐야 한다.

즉 HTTP 메시지가 실제 네트워크를 통해 전달될 수 있도록
아래 계층으로 내려가면서 필요한 정보들이 추가된다.

---

4. Socket 라이브러리를 통해 전달한다

강의 자료에서는 전체적인 과정을 다음과 같이 설명했다.

1. 웹 브라우저가 HTTP 메시지 생성

2. Socket 라이브러리를 통해 전달
   - TCP/IP 연결(IP, PORT)
   - 데이터 전달

3. TCP/IP 패킷 생성
   - HTTP 메시지 포함

먼저 브라우저가 만든 HTTP 메시지는
Socket 라이브러리를 통해 OS의 TCP/IP 계층으로 전달된다.

구조를 단순화하면 다음과 같다.

웹 브라우저
    │
    │ HTTP 메시지 생성
    ▼
Socket Library
    │
    ▼
TCP/IP
    │
    ▼
Network Interface

Socket은 애플리케이션이 네트워크 통신 기능을 사용할 수 있도록
연결해주는 인터페이스라고 생각하면 이해하기 쉽다.

즉 웹 브라우저가 직접 랜카드를 제어하면서

패킷 만들고...

네트워크 장비 제어하고...

TCP 연결하고...

하는 것이 아니라,

Socket을 통해 운영체제의 네트워크 기능을 사용한다.

---

5. TCP/IP 연결을 준비한다

Socket을 통해 데이터를 전달하기 위해
목적지의 IP와 PORT 정보가 사용된다.

앞에서 이미 알아냈던 정보다.

목적지 IP
200.200.200.2

목적지 PORT
443

HTTPS 요청이므로 이 목적지를 기준으로
서버와 통신할 준비를 한다.

그리고 HTTP 메시지를 실제 네트워크로 보내기 위해
TCP/IP 계층에서 필요한 정보들이 붙는다.

---

6. HTTP 메시지를 TCP/IP 패킷에 담는다

현재 우리가 가지고 있는 것은

HTTP 메시지

다.

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

TCP/IP 계층에서는 여기에 네트워크 전송에 필요한 정보를 추가한다.

강의 자료에서는 이를 단순화해서 다음과 같이 표현했다.

┌──────────────────────────────┐
│ 출발지 IP, PORT               │
│ 목적지 IP, PORT               │
│ 기타 TCP/IP 정보              │
├──────────────────────────────┤
│                              │
│ GET /search?q=hello&hl=ko    │
│ HTTP/1.1                     │
│ Host: www.google.com         │
│                              │
└──────────────────────────────┘

즉,

TCP/IP 패킷
        +
HTTP 메시지

형태가 만들어지는 것이다.

조금 더 계층적으로 생각하면 앞에서 공부했던 것처럼

HTTP 메시지
↓
TCP 정보 추가
↓
IP 정보 추가
↓
네트워크 인터페이스를 통해 전송

과 같은 흐름이다.

---

7. 패킷이 인터넷을 통해 Google 서버로 이동한다

이제 만들어진 패킷은
실제 인터넷으로 나간다.

내 컴퓨터
IP: 100.100.100.1

        │
        │ HTTP 요청이 들어있는
        │ TCP/IP 패킷
        ▼

     인터넷

        │
        ▼

Google Server
IP: 200.200.200.2

인터넷에는 수많은 네트워크 장비와 노드가 존재한다.

패킷은 이런 네트워크를 거치면서
목적지인 Google 서버까지 전달된다.

내 컴퓨터
↓
네트워크 장비
↓
인터넷
↓
여러 네트워크 구간
↓
Google Server

우리는 브라우저에서 검색 버튼 한 번 눌렀을 뿐인데
뒤에서는 이런 과정이 진행되고 있었던 것이다.

---

8. Google 서버에 요청 패킷이 도착한다

결국 패킷이 목적지인 Google 서버에 도착한다.

Google Server

IP
200.200.200.2

서버는 전달받은 패킷에서
필요한 정보를 처리하고 최종적으로 HTTP 요청 메시지를 확인한다.

우리가 보낸 HTTP 메시지는 다음과 같았다.

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

서버 입장에서는 이를 보고

/search Resource에 대한 요청이구나.

q = hello구나.

hl = ko구나.

와 같이 요청을 해석할 수 있다.

즉 우리가 URL에서 보았던

Path

Query Parameter

가 실제 서버에게 전달되어
요청을 처리하는 데 사용되는 것이다.

---

9. 서버가 요청을 처리한다

이제 Google 서버는 요청 내용을 기반으로
필요한 작업을 수행한다.

예를 들어

q=hello

이므로 hello라는 검색어에 맞는 검색 결과를 찾는다.

그리고

hl=ko

라는 Parameter도 함께 전달되었으므로
해당 요청에 필요한 처리를 진행한다.

실제 Google 검색 시스템 내부는 당연히 이것보다 훨씬 복잡하겠지만,
현재 네트워크 흐름을 이해하기 위해서는

HTTP 요청 도착
↓
서버가 요청 분석
↓
필요한 로직 수행
↓
응답 데이터 생성

정도로 생각하면 충분하다.

---

10. 서버가 HTTP 응답 메시지를 만든다

요청 처리가 끝났다면
이제 Google 서버가 클라이언트에게 결과를 보내야 한다.

강의 자료에서는 다음과 같은 HTTP 응답을 예시로 보여준다.

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423

<html>
    <body>
        ...
    </body>
</html>

처음 보는 정보들이 또 등장한다.

하나씩 아주 간단하게만 살펴보자.

---

HTTP/1.1 200 OK

200 OK

는 요청이 정상적으로 처리되었다는 의미다.

우리가 웹 개발을 하다 보면 자주 보게 되는

200
404
500

같은 숫자들이 바로 HTTP Status Code다.

여기서는

200 OK

이므로

"네 요청 정상적으로 처리했어."

라는 의미라고 생각하면 된다.

---

Content-Type

다음은

Content-Type: text/html;charset=UTF-8

이다.

쉽게 말하면

"내가 지금 보내는 데이터가 어떤 종류인지"

를 알려주는 정보다.

여기서는

text/html

이므로

"내가 보내는 데이터는 HTML이야."

라고 알려주고 있다.

그리고

charset=UTF-8

을 통해 문자 인코딩 정보도 전달하고 있다.

---

Content-Length

Content-Length: 3423

은 응답으로 전달되는 데이터의 크기를 나타낸다.

강의 자료의 예시에서는

3423

이라는 값을 사용하고 있다.

---

그리고 실제 HTML

Header 아래에는 실제 응답 데이터가 들어간다.

<html>
    <body>
        ...
    </body>
</html>

즉 서버는

HTTP 응답 정보

+

실제 HTML 데이터

를 함께 전달한다.

---

11. 응답도 다시 TCP/IP 패킷으로 전달된다

여기서 중요한 점이 있다.

Google 서버가 HTTP 응답을 만들었다고 해서
HTML이 순간이동해서 내 브라우저로 오는 것은 아니다.

요청을 보낼 때와 똑같이
응답 역시 네트워크를 통해 전달되어야 한다.

Google Server
↓
HTTP 응답 메시지 생성
↓
TCP/IP 계층
↓
패킷 생성
↓
인터넷
↓
내 컴퓨터

즉 이번에는 방향만 반대다.

요청

내 컴퓨터
──────────────→
Google Server

응답

내 컴퓨터
←──────────────
Google Server

서버가 만든 HTTP 응답 메시지도
TCP/IP 패킷 안에 담겨 인터넷을 통해 내 컴퓨터로 전달된다.

---

12. 내 브라우저에 응답 패킷이 도착한다

수많은 인터넷 구간을 거친 응답 패킷이
결국 내 컴퓨터에 도착한다.

Google Server
IP: 200.200.200.2

        │
        │ 응답 패킷
        ▼

     인터넷

        │
        ▼

내 컴퓨터
IP: 100.100.100.1

내 컴퓨터에서는 네트워크 계층을 거쳐
최종적으로 웹 브라우저가 HTTP 응답 메시지를 전달받는다.

브라우저 입장에서는 이제

200 OK

Content-Type: text/html

HTML 데이터

를 받은 것이다.

---

13. 브라우저가 HTML을 렌더링한다

이제 마지막 단계다.

브라우저가 응답받은 HTML을 해석한다.

예를 들어 서버에서 다음과 같은 HTML이 왔다고 해보자.

<html>
    <body>
        <h1>Hello 검색 결과</h1>
    </body>
</html>

브라우저는 이 문자열을 그대로 화면에 보여주는 것이 아니라
HTML 구조를 해석해서 우리가 보는 웹 페이지 형태로 그려준다.

이를 Rendering이라고 한다.

HTTP 응답 도착
↓
HTML 확인
↓
브라우저가 HTML 해석
↓
화면 구성
↓
사용자에게 웹 페이지 표시

즉 우리가 브라우저에서 보는 Google 검색 결과 화면은
서버로부터 받은 응답 데이터를 브라우저가 해석하고 렌더링한 결과라고 볼 수 있다.

---

전체 흐름을 한 번에 정리해보자

처음에는 그냥 브라우저에 다음 주소를 입력했을 뿐이다.

https://www.google.com/search?q=hello&hl=ko

그런데 실제로는 뒤에서 이런 과정이 일어났다.

1. 사용자가 URL 입력
        ↓
2. URL 분석
        ↓
3. DNS 조회
   www.google.com
        ↓
   200.200.200.2
        ↓
4. HTTPS 기본 PORT 확인
   443
        ↓
5. 브라우저가 HTTP 요청 메시지 생성
        ↓
6. Socket Library를 통해 전달
        ↓
7. TCP/IP 계층에서 패킷 생성
        ↓
8. 인터넷을 통해 Google Server로 전달
        ↓
9. Google Server가 HTTP 요청 분석
        ↓
10. 서버가 요청 처리
        ↓
11. HTTP 응답 메시지 생성
        ↓
12. 응답을 TCP/IP 패킷에 담아 전송
        ↓
13. 내 컴퓨터에 응답 도착
        ↓
14. 웹 브라우저가 HTML 해석
        ↓
15. 화면 Rendering

우리가 보기에는

주소 입력
↓
Enter
↓
화면 등장

이 전부인데,

그 짧은 순간에 뒤에서는
정말 많은 과정이 진행되고 있었던 것이다.

---

URI부터 웹 브라우저 요청까지 연결해보면

이번 글에서 배운 내용을 전체적으로 연결해보자.

먼저 URI는

Resource를 식별하기 위한 통일된 방법

이다.

그리고 Resource를 위치로 식별하는 것이

URL

이다.

URL 안에는 다음과 같은 정보들이 들어갈 수 있다.

scheme

userinfo

host

port

path

query

fragment

그리고 브라우저가 URL을 받으면

Host
↓
DNS
↓
IP 확인

을 진행하고,

Scheme
↓
Protocol 및 기본 PORT 확인

을 한다.

그다음

Path

Query

등을 이용해서 HTTP 요청 메시지를 만든다.

그리고 그 HTTP 메시지가

Socket

↓

TCP/IP

↓

Network

를 거쳐 서버로 전달된다.

서버는 요청을 처리한 후

HTTP Response

를 만들고,

다시 TCP/IP를 통해 브라우저에게 전달한다.

마지막으로 브라우저가 HTML을 해석하고 화면을 렌더링한다.

---

공부하고 나서

학교에서 데이터 통신이라는 과목을 들으면서
IP, TCP, DNS 같은 개념들을 이미 한 번씩 배웠었다.

그래서 이번 내용을 공부하면서

"어? 이거 어디서 봤는데?"

싶은 부분들이 꽤 있었다.

하지만 학교에서는 각각의 네트워크 개념을 중심으로 공부했다면,
이번에는 실제 웹 브라우저에서 하나의 요청이 발생했을 때

DNS

IP

PORT

TCP

HTTP

URL

이 서로 어떻게 연결되는지를 하나의 흐름으로 볼 수 있어서 좋았다.

예전에는 각각 따로 알고 있었다면

DNS는 Domain을 IP로 바꿔준다.

TCP는 신뢰성 있는 통신을 한다.

HTTP는 웹에서 사용한다.

URL은 웹 주소다.

정도로 기억하고 있었다.

그런데 이제는

URL 입력
↓
DNS로 IP 확인
↓
TCP/IP 통신 준비
↓
HTTP 요청
↓
서버
↓
HTTP 응답 생성
↓
TCP/IP를 통해 응답 전송
↓
브라우저가 응답 수신
↓
HTML 해석
↓
화면 Rendering

처럼 하나의 흐름으로 연결해서 이해할 수 있게 되었다.

결국 웹 브라우저에서 주소를 입력하고 화면 하나가 뜨는 과정도
생각보다 많은 네트워크 개념이 서로 연결되어 동작한 결과였다.

---

정리

이번 글에서는 URI부터 시작해서
실제로 웹 브라우저가 서버에 요청을 보내고 응답을 받는 과정까지 정리해봤다.

가장 먼저 URI는

Uniform Resource Identifier

의 약자로,

Resource를 식별하기 위한 통일된 방법

이라고 할 수 있다.

그리고 URI는 Resource를 식별하는 방식에 따라
URL과 URN으로 나누어 생각할 수 있다.

URL
→ Resource의 위치로 식별

URN
→ Resource의 이름으로 식별

우리가 실제 웹에서 자주 사용하는 것은 대부분 URL이다.

URL의 전체 구조는 다음과 같다.

scheme://[userinfo@]host[:port][/path][?query][#fragment]

각 요소는 다음 의미를 가진다.

scheme
→ 어떤 Protocol을 사용할 것인가?

userinfo
→ 사용자 정보

host
→ 어느 서버로 갈 것인가?

port
→ 서버의 어느 통신 Endpoint에 접근할 것인가?

path
→ 어떤 Resource 경로인가?

query
→ 서버에 어떤 추가 정보를 전달할 것인가?

fragment
→ 문서 내부의 어느 위치를 가리킬 것인가?

그리고 실제 브라우저에서

https://www.google.com/search?q=hello&hl=ko

를 입력하면 대략 다음과 같은 흐름으로 동작한다.

URL 입력
↓
URL 분석
↓
DNS를 통해 Domain Name을 IP 주소로 변환
↓
IP와 PORT를 이용해 서버와 통신 준비
↓
HTTP 요청 메시지 생성
↓
Socket을 통해 TCP/IP 계층으로 전달
↓
TCP/IP 패킷 생성
↓
인터넷을 통해 서버로 전달
↓
서버가 HTTP 요청 분석
↓
요청에 맞는 로직 수행
↓
HTTP 응답 메시지 생성
↓
TCP/IP를 통해 응답 전송
↓
브라우저가 응답 수신
↓
HTML 해석
↓
Rendering
↓
사용자가 웹 페이지 확인

처음에는

URI
URL
DNS
TCP/IP
HTTP

가 서로 별개의 내용처럼 느껴졌다.

하지만 웹 브라우저의 요청 흐름을 기준으로 하나씩 연결해보니
각 개념이 왜 필요한지 훨씬 이해하기 쉬웠다.

URI와 URL은

어디에 접근할 것인가?

를 표현하고,

DNS는

그 Domain의 실제 IP 주소는 무엇인가?

를 해결한다.

TCP/IP는

그 서버까지 데이터를 어떻게 전달할 것인가?

를 담당하고,

HTTP는

클라이언트와 서버가 어떤 형식으로 요청하고 응답할 것인가?

를 정의한다.

결국 이 개념들이 각각 따로 존재하는 것이 아니라
하나의 웹 요청을 처리하기 위해 서로 연결되어 사용되고 있었다.

---

다음 글에서는 HTTP를 조금 더 자세히

이번 글에서는 웹 브라우저 요청 흐름을 이해하기 위해
HTTP 요청과 응답을 간단하게만 살펴봤다.

예를 들어 이런 메시지가 등장했다.

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

그리고 서버에서는

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423

와 같은 응답을 보냈다.

그런데 여기서 또 새로운 질문들이 생긴다.

GET은 정확히 무엇일까?

POST와 GET은 무엇이 다를까?

200, 404, 500은 어떤 의미일까?

HTTP Header에는 무엇이 들어갈까?

HTTP는 왜 Stateless라고 할까?

HTTP 메시지 구조는 정확히 어떻게 생겼을까?

이 부분부터는 HTTP 자체의 내용이 된다.

따라서 다음 글에서는
HTTP가 무엇인지부터 HTTP 메시지 구조, Method, Status Code까지 조금 더 자세하게 정리해보고자 한다.

학교에서 배웠던 네트워크 지식도 다시 꺼내보면서
이번 기회에 웹과 네트워크에 대한 CS 지식을 조금 더 단단하게 만들어봐야겠다.