HTTP에 대하여

HTTP

• 사용자와 밀접하게 맞닿아 있는 프로토콜
• 웹 세상의 기반이 되는 가장 중요한 프로토콜

HTTP는...

1. 요청-응답 기반 프로토콜이다
2. 미디어 독립적 프로토콜이다
3. 상태를 유지하지 않는 프로토콜이다
4. 지속 연결을 지원하는 프로토콜이다

1) 요청-응답 기반 프로토콜

• HTTP는 '클라이언트 - 서버 구조 기반의 요청 - 응답 프로토콜' -> HTTP 요청 메시지와 HTTP 응답 메시지는 메시지 형태가 다름

2) 미디어 독립적 프로토콜

• HTTP를 정의한 공식 문서(RFC 9110) -> HTTP가 요청하는 대상은 '자원'이다. HTTP는 자원의 특성을 제한하지 않으며, 자원과 상호작용하는 데 사용할 수 있는 인터페이스를 정의할 뿐이다. 대부분의 자원은 URL로 식별된다.
• 즉, HTTP는 주고받을 자원의 특성과 무관하게 그저 자원을 주고 받을 수단(인터페이스) 역할만 함
• HTTP를 통해 HTML, JPEG, PNG, JSON, XML, PDF 등 다양한 종류의 자원 송수신 가능
• 미디어 타입 : HTTP에서 메시지로 주고받는 자원의 종류. 웹 세상의 확장자 -> MIME 타입이라고도 함
• 즉, HTTP는 주고받을 미디어 타입에 특별히 제한을 두지 않고 동작하는 미디어 독립적 프로토콜

 

 

 

미디어 타입의 구성과 종류

• 슬래시를 기준으로 '타입/서브타입' 형식으로 구성 -> 타입: 데이터의 유형 -> 서브타입: 주어진 타입에 대한 세부 유형
• 미디어 타입에는 부가적인 설명을 위해 선택적으로 매개변수 포함 가능 -> '타입/서브타입; 매개변수 = 값'의 형식으로 표현 ex) type/html;charset=UTF-8
• 미디어 타입의 종류는 매우 다양하며, 새로운 미디어 타입을 등록할 수도 있음

타입	타입 설명	서브타입	서브타입 설명
text	일반 텍스트 형식의 데이터	text/plain, text/html, text/css, text/javascript	텍스트 문서, HTML 문서, CSS 문서, 자바스크립트 문서
image	이미지 형식의 데이터	image/png, image/jpeg, image/webp, image/gif	PNG, JPEG, WebP, GIF 이미지
video	비디오 형식의 데이터	video/mp4, video/ogg, video/webm	MP4, OGG, WebM 비디오
audio	오디오 형식의 데이터	audio/midi, audio/wav	MIDI, WAV 오디오
application	일반적인 바이너리 데이터	application/octet-stream, application/pdf, application/xml, application/json, application/x-www-form-urlencoded	알 수 없는 바이너리 데이터, PDF, XML, JSON, URL 인코딩된 데이터
multipart	여러 다른 미디어 타입을 가질 수 있는 여러 요소로 구성된 데이터	multipart/form-data, multipart/encrypted	HTML 입력 폼 데이터, 암호화된 데이터

• 여러 미디어 타입 특징 : 별표 문자
  • ex) text/* = text 타입의 모든 서브 타입
  • / = 모든 미디어 타입

3) 스테이트리스 프로토콜

• HTTP는 상태를 유지하지 않는 스테이트리스 프로토콜 -> 서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않는다는 의미 -> 클라이언트의 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주 (but, cookie와 웹 스토리지 기술을 통해 보완)

 

 

왜? 유지하지 않을까?

 

 

HTTP 서버는 일반적으로 많은 클라이언트와 동시에 상호작용

-> 모든 클라이언트의 상태 정보를 유지하는 것은 서버에 큰 부담

 

특정 클라이언트가 특정 서버에 종속되는 상황 방지
-> HTTP가 상태를 유지하는 프로토콜이라면 클라이언트는 자신의 상태를 기얷하는 특정 서버하고만 통신

 

 

스테이트리스 프로토콜 : 확장성과 견고성

• (확장성: 얼마든지 클라이언트, 서버가 확장되더라도 HTTP 프로토콜이 문제 없이 동작하는 것)
• (견고성: 동작하는 과정에서 몇 개가 다운되더라도 문제없이 동작하는 것)
• HTTP가 처음 만들어졌을 때부터 오늘날까지 이어지는 중요한 설계 목표
• 상태를 유지하지 않는 특성은... -> 특정 클라이언트가 특정 서버에 종속되지 않게 함 -> 서버에 문제가 생겨도 다른 서버로 대체 용이
  
  >>> 따라서 확장성, 견고성에 유리

4) 지속 연결 프로토콜

• 비지속 연결 -> 초기의 HTTP 버전 (HTTP 1.0 이하) -> TCP 연결 수립한 후, 요청에 대한 응답을 받으면 연결 종료 -> 추가적인 요청-응답을 하기 위해서는 다시 TCP 연결 수립부터 반복
• 지속 연결 또는 킵 얼라이브 -> 최근 대부분으로 사용되는 HTTP 버전 (HTTP 1.1 이상) -> 하나의 TCP 연결상에서 여러 개의 요청 - 응답을 주고받을 수 있는 기술

 

---

 

HTTP 메시지 구조

 

• 시작 라인, 필드 라인, 메시지 본문으로 구성
• 필드 라인은 없거나 여러 개 있을 수 있음
• 메시지 본문은 없을 수 있음
• 필드 라인과 메시지 본문 사이에는 빈 줄바꿈이 있음

HTTP 1.1 버전 기준 서술; 대중적으로 사용, 평문 메시지라 학습에 용이

 

HTTP 메시지 구조: 시작 라인(start-line)

• HTTP 메시지는 HTTP 요청 메시지일 수도 있고, HTTP 응답 메시지일 수도 있음
  • HTTP 메시지가 HTTP 요청 메시지일 경우: 시작 라인 = '요청 라인'
  • HTTP 메시지가 HTTP 응답 메시지일 경우: 시작 라인 = '상태 라인'

 

HTTP 메시지 구조: 시작 라인(start-line) - 요청 라인

• 요청 라인 = 메서드<공백>요청 대상<공백>HTTP 버전<줄바꿈>
• 메서드(method)
  • 클라이언트가 서버의 자원(요청 대상)에 대해 수행할 작업의 종류
  • 대표적으로 GET, POST, PUT, DELETE 등
• 요청 대상(request-target)
  • HTTP 요청을 보낼 서버의 자원
  • 보통 (쿼리가 포함된) URI의 경로가 명시
  • 예) 클라이언트가 "http://www.example.com/hello?q=world"로 요청 -> 요청 대상은 "/hello?q=world"
  • 만약 하위 경로가 없더라도 요청 대상은 슬래시(/)로 표기
  • 예) 클라이언트가 "http://www.example.com"으로 요청 -> 요청 대상은 "/"

 

HTTP 버전(HTTP-version)

• 사용된 HTTP 버전
• 'HTTP/<버전>'이라는 표기 방식을 따르며, HTTP 1.1은 HTTP/1.1로 표기

 

HTTP 메시지 구조: 시작 라인(start-line) - 상태 라인

 

 

 

• 상태 코드(status code), 이유 구문(reason phrase)
  • 상태 코드 - 요청에 대한 결과를 나타내는 세 자리 정수
  • 이유 구문 - 상태 코드에 대한 문자열 형태의 설명
  • (예: HTTP/1.1 200 OK, HTTP/1.1 404 Not Found)

필드 라인 또는 헤더 라인(header-line)

• 0개 이상의 HTTP 헤더(HTTP header) 명시
• HTTP 헤더 - HTTP 통신에 필요한 부가 정보
• 콜론(:)을 기준으로 헤더 이름(header-name)과 하나 이상의 헤더값(header-value)으로 구성

예시

 

메시지 본문(message-body)

• HTTP 요청 혹은 응답 메시지에서 본문이 필요할 경우 선택적으로 메시지 본문에 명시
• 다양한 콘텐츠 타입이 사용 가능

 

HTTP 메서드 정리

HTTP 메서드	설명
GET	자원을 습득하기 위한 메서드
HEAD	GET과 동일하나, 헤더만을 응답받는 메서드
POST	서버로 하여금 특정 작업을 처리하게끔 하는 메서드
PUT	자원을 대체하기 위한 메서드
PATCH	자원에 대한 부분적 수정을 위한 메서드
DELETE	자원을 삭제하기 위한 메서드
CONNECT	자원에 대한 양방향 연결을 시작하는 메서드
OPTIONS	사용 가능한 메서드 등 통신 옵션을 확인하는 메서드
TRACE	자원에 대한 루프백 테스트를 수행하는 메서드

 

 

개발자 입장에서 생각해보는 HTTP 메시지

• 어떤 URI(URL)에 어떤 메서드로 요청 받았을 때 서버는 어떻게 행동해야 할까? -> 이 설계는 오로지 (서버를 개발하는) 개발자의 몫
  • 어떤 메서드는 구현할 수도 있고, 어떤 메서드는 구현하지 않을 수도 있음
  • 같은 URL에 대해 메서드별 동작을 여러 개 구현할 수도 있음

HTTP 상태 코드

• 상태 코드는 요청에 대한 결과를 나타내는 세 자리 정수
  • 상태 코드의 종류는 백의 자리 수를 기준으로 유형을 구분

상태 코드	설명
100번대(100~199)	정보성 상태 코드
200번대(200~299)	성공 상태 코드
300번대(300~399)	리다이렉션 상태 코드
400번대(400~499)	클라이언트 에러 상태 코드
500번대(500~599)	서버 에러 상태 코드

---

• 200번대: 성공 상태 코드
  • '요청이 성공했음'을 의미
  • 주요 상태 코드: 200(OK), 201(Created), 202(Accepted), 204(No Content)

상태 코드	이유 구문	설명
200	OK	요청이 성공했음
201	Created	요청이 성공했으며, 새로운 자원이 생성되었음
202	Accepted	요청을 잘 받았으나, 아직 요청한 작업을 끝내지 않았음
204	No Content	요청이 성공했지만, 메시지 본문으로 표시할 데이터가 없음

---

• 300번대: 리다이렉션 상태 코드
  • 리다이렉션(redirection)이란?
    • '요청을 완수하기 위해 추가적인 조치가 필요한 상태(인터넷 공식 문서 RFC 9110)'
    • 클라이언트가 요청한 자원이 다른 곳에 있을 때, 클라이언트의 요청을 다른 곳으로 이동시키는 것

 

리다이렉션의 종류

• 영구적 리다이렉션
• 일시적인 리다이렉션

---

• 영구적 리다이렉션(permanent redirection)
  • 자원의 위치가 새로운 곳으로 이동하여 경로가 영구적으로 재지정
  • 이 경우 기존의 URL에 요청 메시지를 보내면 항상 새로운 URL로 리다이렉트

상태 코드	이유 구문	설명
301	Moved Permanently	영구적 리다이렉션, 재요청 메서드 변경될 수 있음
308	Permanent Redirect	영구적 리다이렉션, 재요청 메서드 변경되지 않음

---

• 일시적인 리다이렉션(temporary redirection)
  • 자원의 위치가 임시로 변경되었거나, 임시로 사용할 URL이 필요한 경우에 주로 사용
  • 어떤 URL에 대해 일시적인 리다이렉션이 걸린 상태 코드를 응답받았다면 여전히 요청을 보낼 URL은 기억

상태 코드	이유 구문	설명
302	Found	일시적 리다이렉션, 재요청 메서드 변경될 수 있음
303	See Other	일시적 리다이렉션, 재요청 메서드 GET으로 변경
307	Temporary Redirect	일시적 리다이렉션, 재요청 메서드 변경되지 않음

---

• 400번대: 클라이언트 에러 상태 코드
  • '클라이언트에 의한 에러가 있음'을 알려 주는 상태 코드

상태 코드	이유 구문	설명
400	Bad Request	클라이언트의 요청이 잘못되었음
401	Unauthorized	요청한 자원에 대한 유효한 인증이 없음
403	Forbidden	요청한 자원에 대한 권한 없음
404	Not Found	요청한 자원을 찾을 수 없음
405	Method Not Allowed	요청한 메서드를 지원하지 않음

---

인증(Authentication) 여부 vs 권한 부여(Authorization) 여부

• 인증: 자신이 누구인지 증명하는 것
• 권한 부여/인가: 인증된 주체에게 작업을 허용하는 것

---

• 500번대: 서버 에러 상태 코드
  • 클라이언트가 올바르게 요청을 보냈을지라도 발생할 수 있는 서버 에러에 대한 상태 코드

상태 코드	이유 구문	설명
500	Internal Server Error	요청을 처리할 수 없음
502	Bad Gateway	중간 서버의 통신 오류
503	Service Unavailable	현재는 요청을 처리할 수 없으나 추후 가능할 수도 있음

 

 

HTTP의 여러 버전

• HTTP/0.9
  • 현재 거의 사용되지 않는 초창기 HTTP 버전
  • 사용 가능한 메서드 : get
  • 헤더 지원 X
• HTTP/1.0
  • HEAD, POST 등 GET 이외에 메서드 도입
  • 헤더 지원 시작
  • 공식적으로 지속 연결 미지원
• HTTP/1.1
  • 오늘날까지 널리 사용되는 버전
  • 지속 연결 공식적 지원
  • 파이프라이닝, 콘텐츠 협상 기능 등 다양한 기능 추가
  • 메시지 본문 = 평문
  • 고질적 문제 : HOL 블로킹 (Head-of-line blocking)
    • 같은 큐에 대기하며 순차적으로 처리되는 여러 패킷이 있을 경우
    • 첫번째 패킷의 처리 지연으로 인해 나머지 패킷 처리도 모두 지연되는 문제 상황
• HTTP/2.0
  • 오늘날까지 널리 사용되는 버전
  • HTTP/1.1의 효율과 성능을 높이기 위한 버전
  • 메시지 본문 = 바이너리 데이터
  • 헤더 압축 전송 가능
  • 서버 푸시 기능 제공 -> 클라이언트가 요청하지 않았더라도 미래에 필요할 것으로 예상되는 자원 미리 전송하는 기능
  • HTTP 멀티플렉싱 기능 제공 (HOL 블로킹 완화) -> 여러 스트림을 활용해 병렬적으로 메시지를 주고받는 기술 -> 요청 - 응답 단위는 하나의 스트림에서 이루어짐 -> 스트림을 독립적인 송수신 가능 -> 별도의 스트림을 통해 여러 데이터를 병렬적으로 주고받으며 HOL 블로킹 완화
• HTTP/3.0
  • 오늘날 점차 사용 확대되는 버전
  • 이전까지의 HTTP 버전 - TCP 기반 동작
  • HTTP/3.0 - UDP 기반 프로토콜인 QUIC 기반으로 동작
  • 연결형 프로토콜 기반 송수신 속도 <= 비연결형 프로토콜 기반 송수신 속도 -> 빠른 송수신 가능