[스터디] HTTP 기초 (URL과 리소스, HTTP 메시지)

본 게시글은 CS 지식 스터디에서 HTTP에 관해 발표하기 위해 'HTTP 완벽 가이드(인사이트)'의 1장 ~ 3장 내용을 요약한 게시물입니다.

1. HTTP 개관

HTTP(Hypertext Transfer Protocol)은 WWW(Word Wide Web)에서 통신하는 데 사용하는 프로토콜 프로그램이다.

1.1 HTTP

• HTTP는 JPEG 이미지, HTML 페이지, 텍스트 파일, MPEG 동영상 등 파일을 웹 서버로부터 빠르고, 정확하게 웹 브라우저로 옮겨준다.
• 신뢰성 있는 데이터 전송 프로토콜(TCP)를 사용하기 때문에, 데이터가 지구 반대편에서 오더라도 전송 중 손상되거나 꼬이지 않음을 보장한다.
• (덕분에 웹 개발자도 전송 중 파일이 파괴되거나 왜곡되는 걸 걱정할 필요없다.)

• HTTP/3 에서 변경사항

2022년에 표준화된 HTTP 최신 버전인 HTTP/3에서는 UDP 기반의 QUIC 프로토콜을 사용하여 통신한다. TCP의 핸드쉐이킹 과정으로 인한 속도 한계를 개선하고자, UDP를 사용하고 QUIC라는 새로운 계층을 추가함으로서 통신의 신뢰성을 제공한다.

 

1.2 웹 클라이언트와 서버

웹 서버는 HTTP 프로토콜을 이용하여 인터넷의 데이터를 저장하고, 클라이언트가 요청한 데이터를 제공한다.

1.3 리소스

웹 서버는 리소스를 관리하고 제공한다.

• 정적 파일: 텍스트 파일, HTML 파일, JPEG 이미지 파일, MPEG 동영상 파일 등
• 동적 콘텐츠 리소스: 사용자와 요청에 따라 다른 콘텐츠를 생성하여 제공 (JSP, thymeleaf 등)

 

1.3.1 미디어 타입

HTTP는 웹에서 전송되는 객체 각각에 MIME(Multipurpose Internet Mail Extensions) 타입이라는 데이터 포맷 라벨을 붙인다.

MIME 타입을 통해 웹브라우저는 객체가 다룰 수 있는 객체인지 확인한다.

 

유형	MIME 타입
HTML 문서	text/html
plain 텍스트	text/plain
JSON	application/json
HTML 폼 (파일 포함 가능)	multipart/form-data
JPEG 이미지	image/jpeg
GIF 이미지	image/gif

전체 MIME 미디어 타입 목록 Media Types

 

1.3.2 URI

웹 서버 리소스는 각자 이름을 갖고 있기 때문에, 클라이언트는 관심 있는 리소스를 지목할 수 있다.

서버 리소스 이름은 URI(uniform resource identifier, 통합 자원 식별자) 로 불린다.

예시) http://www.joes-hardware.com/specials/saw-blade.gif

http:// : HTTP 프로토콜을 이용하라

www.joes-hardware.com : 서버 주소로 이동하라

/specials/saw-blade.gif : /specials/saw-blade.gif 라는 리소스를 가져와라.

 

1.3.3 URL

URL이 URI의 가장 흔한 형태. 오늘날 대부분의 URI는 URL이다.

예시) https://grm-project-template-bucket.s3.ap-northeast-2.amazonaws.com/organization/k-digital/logo/logo.png

 

URL 문법

• URL 문법

URL로 인터넷 상의 모든 리소스를 찾을 수 있지만, 그 리소스들은 다른 스킴(HTTP, FTP, SMTP)을 통해 접근할 수 있으며, URL 문법도 달라진다.

대부분의 URL 스킴의 문법은 아래와 같다.

<스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>

 

컴포넌트	설명
스킴	리소스를 가져오려면 어떤 프로토콜을 사용하여 서버에 접근해야 하는지 가리킨다.
사용자 이름	몇몇 스킴은 리소스에 접근하기 위해 사용자 이름을 필요로 한다.
비밀번호	사용자의 비밀번호를 가리키며, 사용자 이름에 콜론(:) 이어서 기술한다.
호스트	리소스를 호스팅하는 서버의 호스트 명이나 IP 주소.
포트	리소스를 호스팅하는 서버가 열어놓은 포트번호. 많은 스킴이 기본 포트를 가지고 있다. (HTTP의 기본 포트는 80)
경로	이전 컴포넌트와 빗금(/)으로 구분되어 있으며, 서버 내 리소스가 어디에 있는지를 가리킨다.
파라미터	특정 스킴에서 입력 파라미터를 기술하는 용도로 사용한다. 파라미터는 세미콜론(;)으로 구분하여 기술하며, 여러 개를 가질 수 있다.
질의	스킴에서 애플리케이션(데이터베이스, 게시판, 검색엔진, 기타 인터넷 게이트웨이)에 파라미터를 전달할 때 쓰인다. URL의 끝에 ?로 구분한다.
프래그먼트	리소스의 조각이나 일부를 가리키는 이름이다. URL이 특정 객체를 가리킬 경우 사용되며, # 문자로 구분한다.

 

URL 인코딩

역사적으로 많은 컴퓨터 애플리케이션이 US-ASCII 문자 집합을 사용해왔다.

유럽 언어나 한글을 비롯한 비 라틴계 언어는 지원되지 않는다. 이런 것들을 지원하기 위해 URL 설계자들은 이스케이프 문자열을 쓸 수 있게 설계했다.

 

인코딩은 안전하지 않는 문자(ASCII로 표현 불가능한 문자)를 퍼센티지 기호(%)로 시작해, ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 이스케이프 문자 로 바꾼다.

 

URL 인코딩 해보기

console.log(`${encodeURIComponent("가")}`);

문자	ASCII 코드	URL의 예
~	126 (0x7E)	%7E
빈 문자	32 (0x20)	%20
한글 ‘가’		%EA%B0%80

• 반드시 인코딩 해야 하는 문자 목록 (다른 용도로 사용되는 예약어)

% / . .. # ? ; : $ + @ & = { } | \ ~ [ ] ` < > “

 

대표적인 스킴 목록

• 대표적인 스킴 목록

1. http : 하이퍼텍스트 전송 프로토콜, 기본 포트 값 80
2. https : 커넥션 양 끝단에서 암호화를 위한 SSL 추가, 기본 포트 값 443
3. mailto : 이메일 주소
4. ftp : 파일 전송 프로토콜
5. rtsp, rtspu : 오디오 및 비디오 실시간 스트리밍 프로토콜
6. file : 주어진 호스트 기기(로컬 디스크, 네트워크 파일 시스템)에 바로 접근
7. telnet : 대화형 서비스에 접근

 

 

1.3.4 URN

URN 은 한 리소스에 대해 그 리소스의 위치에 영향을 받지 않는 유일무이한 이름 역할을 한다.

리소스의 위치가 바뀌더라도 문제없이 동작한다.

웹 URL을 대체하는 용도로는 거의 사용되지 않고 있다.

사용하는 분야 : 도서(ISBN, ISSN), 네임스페이스 관리(UUID 식별자), 표준 및 프로토콜 식별(urn:ietf:2141)

예시) urn:ietf:2141 : 어디에 있거나 상관없이 인터넷 표준 문서 ‘RFC 2141’을 지칭한다.

 

1.4 트랜잭션

HTTP 트랜잭션은 요청 명령(클라이언트→서버)와 응답 결과(서버→클라이언트)로 구성된다.

상호작용은 HTTP 메시지 를 이용해 이뤄진다.

 

1.5 HTTP 메시지

HTTP 메시지는 시작줄, 헤더 블록, 본문 세 부분으로 나눠진다. (각 줄은 캐리지 리턴(CRLF)로 구분된다)

• 시작줄 : 어떤 메시지인지 서술
• 헤더 블록 : 속성
• 본문 : 데이터 (없을 수 있음)

요청 메시지 문법

<메서드> <요청 URL> <버전>
<헤더>

<엔티티 본문>

• 메서드

클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작

메서드	설명
GET	리소스를 달라고 요청
HEAD	GET처럼 동작하지만, 서버는 응답으로 헤더만 돌려준다. (리소스를 가져오지 않고도 리소스에 대해 무엇인가 알 수 있음)
PUT	요청의 본문으로 새 문서를 만들거나, 리소스가 이미 존재하면 본문을 사용하여 교체
POST	서버에 입력 데이터를 전송
TRACE	방화벽, 프락시, 게이트웨이를 지나면서 요청이 수정될 수 있다. 이를 확인하기 위해 자신의 요청이 서버에 도착했을 때 어떻게 보이게 되는지 알아봄.
OPTIONS	서버가 어떤 메서드를 지원하는지 물어봄.
DELETE	리소스를 삭제함.

• 헤더

요청과 응답에서 이름/값 쌍 형식으로 추가 메시지를 더함.

예시)

Content-Type: image/gif
Content-Length: 8572
Server: Test Server
        Version 1.0

 

• 엔티티 본문

메시지가 보내고자 하는 리소스. 텍스트 데이터나 바이너리 데이터 모두 가능하다.

 

응답 메시지 문법

<버전> <상태 코드> <사유 구절>
<헤더>

<엔티티 본문>

 

• 상태 코드

100-199 정보성 상태 코드

상태 코드	사유 구절	의미
100	Continue	요청의 시작 부분 일부가 받아들여졌으며, 나머지를 계속 보내야 함

200-299 성공 상태 코드 (요청 성공)

상태 코드	사유 구절	의미
200	OK	요청이 성공적으로 수행됨
201	Created	요청이 성공하여 새로운 리소스가 생성됨
202	Accepted	요청이 접수되었으나, 아직 처리되지 않음
206	Partial Content	클라이언트의 범위 요청에 따라 일부 콘텐츠만 제공됨 (동영상 스트리밍 등 범위 요청에서 사용)

300-399 리다이렉션 상태 코드 (리소스가 다른 위치로 이동했거나, 대안 제공)

상태 코드	사유 구절	의미
300	Multiple Choices	요청에 대해 여러 개의 응답이 가능하며, 클라이언트가 선택해야 함.
301	Moved Permanently	요청한 리소스가 영구적으로 새로운 URL로 이동함. (다른 URL로 redirect할 때 사용)

400-499 클라이언트 에러 상태 코드 (클라이언트가 잘못된 요청을 보냄)

상태 코드	사유 구절	의미
400	Bad Request	클라이언트의 요청이 잘못되었거나 형식이 올바르지 않음.
401	Unauthorized	인증이 필요하지만 제공되지 않았거나 유효하지 않음.
403	Forbidden	서버가 요청을 이해했지만, 권한이 없어 거부됨.
404	Not Found	요청한 리소스를 찾을 수 없음.
405	Method Not Allowed	요청한 HTTP 메서드가 지원되지 않음.
408	Request Timeout	클라이언트가 정해진 시간 내에 요청을 완료하지 못함.
413	Payload Too Large	요청 본문 크기가 서버가 처리할 수 있는 한계를 초과함.

500-599 서버 에러 상태 코드 (서버 자체에서 에러 발생)

상태 코드	사유 구절	의미
500	Internal Server Error	서버에서 예상하지 못한 오류가 발생함.
501	Not Implemented	서버가 요청된 기능을 지원하지 않음.
502	Bad Gateway	게이트웨이 또는 프록시 서버가 잘못된 응답을 받음.
503	Service Unavailable	서버가 과부하 상태이거나 유지보수 중이라 요청을 처리할 수 없음.

 

 

1.6 TCP 커넥션

HTTP 메시지는 TCP(Transmission Control Protocol, 전송 제어 프로토콜) 커넥션을 통해 한 곳에서 다른 곳으로 옮겨간다.

• TCP/IP

HTTP는 애플리케이션 계층 프로토콜이다. 네트워크 통신의 핵심적인 세부사항은 신경 쓰지 않는다. 대신 신뢰성 있는 인터넷 전송 프로토콜인 TCP/IP 에게 맡긴다.

TCP는 아래를 제공한다.

• 오류 없는 데이터 전송
• 순서에 맞는 전달 (데이터는 보낸 순서대로 도착 보장)
• 조각나지 않는 데이터 스트림 (어떤 크기로든 보낼 수 있다)

 

1.7 프로토콜 버전

• HTTP/0.9
  • 1991년 HTTP 프로토타입
  • 심각한 결함 다수 존재
  • GET 메서드만 지원
• HTTP/1.0
  • 널리 쓰이기 시작한 버전
  • HTTP 헤더, 추가 메서드, 멀티 미디어 객체 처리 추가
  • 잘 정의된 명세는 아님
• HTTP/1.0+
  • 1990년대 중반 HTTP에 기능 추가
  • keep-alive 커넥션, 가상 호스팅 지원, 프락시 연결 지원 등 기능 추가
  • 공식적이진 않지만 사실상의 표준
• HTTP/1.1
  • 구조적 결함 교정, 성능 최적화
  • 잘못된 기능 제거
  • 1990년대 후반 이미 쓰임
• HTTP/2.0 (2015)
  • HTTP/1.1의 성능 한계를 해결하기 위해 개발됨.
  • 멀티플렉싱 지원 → 하나의 연결에서 여러 개의 요청 및 응답을 동시에 처리.
  • 헤더 압축(HPACK) → 중복 제거 및 크기 축소로 성능 최적화.
  • 서버 푸시(Server Push) → 서버가 클라이언트 요청 없이도 미리 리소스를 전송.
  • 스트림 우선순위 지정 → 중요한 데이터 전송 우선순위를 설정 가능.
  • 기존의 텍스트 기반 프로토콜에서 바이너리 프레이밍(Binary Framing) 방식으로 변경됨.
• HTTP/3.0 (2022)
  • TCP 대신 QUIC 프로토콜 사용 → 패킷 손실 시에도 빠른 전송 가능.
  • 0-RTT 핸드셰이크 → 연결 설정 시간을 줄여 웹사이트 로딩 속도 향상.
  • 헤드라인 블로킹(Head-of-line blocking) 문제 해결 → 패킷 손실 시 개별 스트림만 재전송.
  • 기존 HTTP/2.0보다 더 낮은 지연시간과 높은 보안성 제공.

 

출처

데이빗 고울리, 브라이언 토티, 마조리 세이어, 세일루 레디, 안슈 아가왈 공저, 『HTTP 완벽 가이드』, 인사이트(2014)

TEAM-ARK/HTTP_The_Definitive_Guide: HTTP 완벽가이드 스터디