기술 학습 노트

테마

HTTP 기초제 2장

브라우저는 URL을 어떻게 해석하고 HTTP 요청으로 바꿀까?

02. URI와 브라우저 요청 흐름 ​

학습 목표 ​

  1. URI, URL, URN의 관계를 구분할 수 있다.
  2. URL의 각 구성 요소가 무엇을 의미하는지 설명할 수 있다.
  3. path, query, fragment의 차이를 실무 감각으로 이해할 수 있다.
  4. 사용자가 URL을 입력했을 때 브라우저 안에서 어떤 일이 벌어지는지 큰 흐름을 설명할 수 있다.
  5. 브라우저 요청 흐름이 01장에서 배운 DNS, TCP, Port와 어떻게 이어지는지 연결해서 이해할 수 있다.

전체 구조 ​

1. 왜 URI를 먼저 정리해야 할까? ​

HTTP를 공부하다 보면 URL, URI, endpoint, path, query string 같은 용어가 계속 나온다.
그런데 이 단어들의 관계가 머릿속에서 정리되지 않으면, 뒤에서 API 설계나 브라우저 요청 흐름을 배울 때 계속 헷갈린다.

특히 실무에서 자주 생기는 혼동은 다음과 같다.

  • URL과 URI를 완전히 다른 것으로 생각하는 경우
  • query와 path의 역할을 섞어 생각하는 경우
  • fragment도 서버로 전송된다고 오해하는 경우

이번 장의 목적은 이 용어들을 엄밀하게 외우는 것이 아니라, 브라우저와 서버가 무엇을 보고 통신하는지를 정확히 잡는 것이다.

2. URI, URL, URN ​

URI는 가장 큰 개념이다 ​

URI(Uniform Resource Identifier)는 말 그대로 리소스를 식별하는 통합된 방식이다.

여기서 리소스는 HTML 문서만 뜻하지 않는다. 다음은 모두 리소스가 될 수 있다.

  • 회원 정보
  • 상품 상세 화면
  • 이미지 파일
  • 동영상
  • 검색 결과
  • 실시간 교통 정보

즉, 구분하고 가리킬 수 있는 대상이라면 URI로 식별할 수 있다고 생각하면 된다.

URL과 URN의 관계 ​

URI 아래에는 대표적으로 URL과 URN이 있다.

URL: 위치로 식별 ​

URL은 리소스가 어디 있는지를 알려주는 방식이다.

예:

  • https://example.com/members/100
  • https://example.com/search?q=http

브라우저에서 주소창에 입력하는 대부분의 값이 URL이다.

URN: 이름으로 식별 ​

URN은 리소스의 이름 자체를 부여하는 방식이다.

예:

  • urn:isbn:8960777331

이름 자체는 안정적일 수 있지만, 실제 웹에서 “그 이름만으로 바로 리소스를 찾아가는” 체계는 보편적으로 쓰이지 않는다.
그래서 일반 웹 개발에서는 URI를 설명할 때 사실상 URL 중심으로 이해해도 충분하다.

실무 기준 정리: 개념적으로는 URI > URL 관계를 알고, 실전에서는 대부분 URL을 다룬다고 보면 된다.

3. URL은 어떤 조각으로 이루어져 있을까? ​

다음 URL을 예시로 보자.

text
https://www.example.com:443/members/100?tab=profile&lang=ko#activity

이 URL은 다음 요소로 나눌 수 있다.

URL 구성 요소 정리 ​

요소예시의미실무 메모
schemehttps어떤 방식으로 접근할지http, https, ftp 등이 있음
hostwww.example.com접속할 서버 이름도메인 또는 IP 주소
port443서버 안의 어느 프로그램으로 갈지생략 가능, http=80, https=443
path/members/100리소스의 계층적 경로보통 디렉터리처럼 설계
query?tab=profile&lang=ko추가 조건/파라미터key=value, 여러 개면 &로 연결
fragment#activity문서 내부 위치 정보서버로 전송되지 않음

scheme ​

scheme은 보통 프로토콜 정보를 담는다.

  • http면 기본 포트는 80
  • https면 기본 포트는 443

그래서 https://example.com처럼 포트를 생략해도, 브라우저는 기본적으로 443을 떠올린다.

host ​

host는 목적지 서버다. 보통 도메인 이름이 오지만, IP 주소를 직접 넣을 수도 있다.

  • www.example.com
  • 203.0.113.10

path ​

path는 리소스의 경로다. 보통 계층 구조처럼 설계한다.

예:

  • /members
  • /members/100
  • /products/iphone-16

이 구조를 잘 설계하는 것이 뒤에서 배울 리소스 중심 URI 설계의 출발점이다.

query ​

query는 ?로 시작하고, 주로 key=value 형태로 전달된다.

예:

  • ?q=http
  • ?page=2&sort=latest

이 값은 보통 검색, 필터, 정렬, 페이지 번호 같은 추가 조건을 전달할 때 많이 사용한다.

userinfo ​

URL 문법에는 userinfo도 있지만, 브라우저 기반 웹 개발에서는 거의 사용하지 않는다.
그래서 실무에서는 보통 scheme, host, port, path, query, fragment 정도를 중심으로 보면 충분하다.

4. Query와 Fragment는 무엇이 다를까? ​

둘 다 URL 뒤쪽에 붙기 때문에 헷갈리기 쉽다.
하지만 브라우저와 서버 입장에서 보면 역할이 완전히 다르다.

Query는 서버에 전달된다 ​

예:

text
https://example.com/search?q=http&lang=ko

서버는 여기서 /search와 q=http, lang=ko를 보고 검색 결과를 만들 수 있다.

Fragment는 서버에 전달되지 않는다 ​

예:

text
https://example.com/docs#install

브라우저는 서버에 /docs를 요청한다.
#install은 브라우저가 응답 문서를 받은 뒤, 그 문서 안의 특정 위치로 스크롤하거나 이동할 때 사용한다.

항목QueryFragment
시작 문자?#
서버 전송 여부전송됨전송되지 않음
주 용도검색, 필터, 옵션 전달문서 내부 북마크, SPA 라우팅 등

핵심 암기 포인트: query는 서버가 읽고, fragment는 브라우저가 읽는다.

5. 브라우저는 URL을 입력받으면 무엇을 할까? ​

이제 01장에서 배운 네트워크 흐름과 URL 개념을 연결해 보자.

사용자가 주소창에 URL을 입력하면 브라우저는 대략 다음 순서로 움직인다.

  1. URL을 해석한다.
  2. host를 DNS로 조회한다.
  3. scheme에 따라 port를 정한다.
  4. 서버와 TCP 연결을 맺는다.
  5. HTTP 요청 메시지를 만든다.
  6. 서버 응답을 받는다.
  7. HTML을 파싱하고 추가 리소스를 요청한다.
  8. 최종 화면을 렌더링한다.

요청 흐름을 그림으로 다시 보면 ​

6. 브라우저는 어떤 HTTP 요청을 만들까? ​

예를 들어 사용자가 다음 URL을 입력했다고 하자.

text
https://www.example.com/search?q=http&lang=ko

브라우저는 내부적으로 대략 이런 요청을 만든다.

http
GET /search?q=http&lang=ko HTTP/1.1
Host: www.example.com

여기서 주목할 점은 다음과 같다.

  • 메서드는 일단 GET
  • 서버로 가는 대상은 path + query
  • Host 헤더로 어느 도메인을 요청하는지 알린다

서버는 응답으로 대략 이런 형태를 돌려준다.

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

<html>...</html>

이 응답을 받은 브라우저는 HTML을 바로 화면에 그리는 것이 아니라, 먼저 파싱한다.
그 과정에서 CSS, JavaScript, 이미지가 더 필요하면 추가 요청을 보낸다.

중요한 감각: 브라우저가 한 번 요청해서 한 번 응답 받고 끝나는 경우도 있지만, 실제 화면 하나를 그리기 위해서는 여러 개의 추가 요청이 이어지는 경우가 많다.

7. 정리 ​

이번 장의 핵심은 세 가지다.

  1. URI는 상위 개념이고, 실무에서는 URL 중심으로 이해하면 된다.
  2. URL은 scheme, host, port, path, query, fragment 같은 조각으로 이루어진다.
  3. 브라우저는 URL을 입력받으면 DNS 조회, 연결, HTTP 요청/응답, 파싱, 렌더링 순서로 동작한다.

다음 장에서는 이 흐름 위에서 HTTP가 가지는 더 본질적인 성격, 즉 클라이언트-서버 구조, 무상태, 비연결성을 정리한다.

핵심 암기 포인트 ​

URI: 리소스를 식별하는 상위 개념.

URL: 리소스의 위치로 식별하는 방식. 실무에서 대부분 이것을 사용한다.

URN: 리소스의 이름으로 식별하는 방식. 일반 웹 개발에서는 드물다.

path: 리소스의 계층적 경로.

query: 서버에 전달되는 추가 조건 정보.

fragment: 브라우저 내부에서만 사용하는 위치 정보. 서버로 전송되지 않는다.

브라우저 요청 흐름: URL 해석 → DNS → 연결 → HTTP 요청 → HTTP 응답 → 파싱 → 렌더링.

확인 질문 ​

  1. URI와 URL의 관계를 한 문장으로 설명하면 어떻게 표현할 수 있을까?
  2. https://example.com/products/10?view=full#review에서 서버가 실제로 받는 정보는 어디까지일까?
  3. scheme과 port는 왜 서로 연결해서 이해해야 할까?
  4. query와 fragment는 왜 용도와 동작 방식이 완전히 다를까?
  5. 브라우저가 HTML 응답을 받은 뒤에도 추가 요청을 보내는 이유는 무엇일까?