HTTP

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 역사
3. 기술적 개요
- 3.1. 연결 관리
- 3.2. HTTP 메시지
  - 3.2.1. 요청 메시지
  - 3.2.2. 응답 메시지
4. 보안
- 4.1. HTTP 인증
5. 확장 프로토콜
참조

1. 개요

HTTP는 웹에서 데이터를 주고받는 데 사용되는 응용 계층 프로토콜이다. 팀 버너스 리가 개발했으며, 1991년 HTTP/0.9 버전을 시작으로 여러 버전이 출시되었다. HTTP/1.0, HTTP/1.1을 거쳐, 현재는 HTTP/2와 HTTP/3가 사용되고 있다. HTTP는 클라이언트-서버 모델을 기반으로 하며, 요청-응답 방식으로 작동한다. 웹 브라우저는 클라이언트 역할을 하고, 웹 서버는 서버 역할을 한다. HTTP는 평문 통신을 하므로 보안을 위해 HTTPS를 사용한다. HTTP는 확장 프로토콜을 통해 다양한 기능을 제공하며, 웹DAV, WebSocket 등이 있다.

더 읽어볼만한 페이지

HTTP - HTTPS
HTTPS는 HTTP에 보안 기능이 더해진 통신 규약으로, 웹 브라우저와 서버 간 통신을 암호화하여 보안을 강화하지만, 인증서 비용, 서버 부하, 혼합 콘텐츠 문제 등의 단점도 존재한다.
HTTP - HTTP 쿠키
HTTP 쿠키는 웹 서버가 사용자 브라우저에 저장하는 작은 텍스트 파일로, 웹 사이트가 방문 기록, 로그인 정보 등을 기억하여 HTTP의 상태 비저장성을 보완하고 세션 관리, 개인 설정, 사용자 추적 등에 활용되지만 개인 정보 보호 및 보안 문제에 대한 논란이 있다.
응용 계층 프로토콜 - 실시간 전송 프로토콜
실시간 전송 프로토콜(RTP)은 스트리밍 미디어의 실시간 전송을 위해 설계된 프로토콜로, IP 네트워크에서 오디오/비디오 전송의 표준으로 사용되며, 멀티미디어 데이터 전송, 타임스탬프, 순서 제어, QoS 피드백 등을 제공한다.
응용 계층 프로토콜 - D-Bus
D-Bus는 2002년에 시작된 프로세스 간 통신 시스템으로, 시스템 버스와 세션 버스를 통해 정보 공유, 모듈성, 권한 격리를 제공하며, 일대일 요청-응답 및 발행/구독 통신 방식을 지원한다.
월드 와이드 웹 - 구글
구글은 래리 페이지와 세르게이 브린이 개발한 웹 검색 엔진에서 출발하여 검색 기술 혁신을 통해 유튜브, 안드로이드 등 다양한 서비스를 제공하는 세계적인 기술 기업으로 성장했지만, 개인정보보호 및 독점 논란에도 직면하고 있다.
월드 와이드 웹 - 온라인 언론
온라인 언론은 인터넷을 통해 뉴스 및 정보를 제공하며, 디지털 기술 발달과 함께 성장하여 시민 저널리즘 부상, 정보 전달 속도 혁신 등의 특징을 보이지만 정보 신뢰성 문제, 전통 언론 쇠퇴 등의 과제를 안고 있다.

HTTP
개요
이름	하이퍼텍스트 전송 프로토콜
영어 이름	Hypertext Transfer Protocol
약칭	HTTP
HTTP 로고
목적	하이퍼텍스트 등의 전송
개발	티ム・버너즈＝리 인터넷 엔지니어링 태스크 포스 (IETF) 월드 와이드 웹 컨소시엄 (W3C)
최초 공개일	1991년
영향을 준 프로토콜	HTTP/2 HTTP/3 WebDAV
OSI 모델 계층	응용 계층
기본 포트	80
주요 특징
지속적 연결	지속적 연결
보안	HTTPS
새로운 기능	HTTP/2 HTTP/3
관련 기술	QUIC
요청 메서드
종류	OPTIONS GET HEAD PUT DELETE TRACE CONNECT
헤더 필드
종류	Cookie ETag 리퍼러 X-Forwarded-For
상태 코드
종류	302 Found 403 Forbidden 404 Not Found 503 Service Unavailable
인증 방식
종류	Basic 인증 Digest 인증
보안 취약점
종류	HTTP 헤더 인젝션
표준
HTTP/2	HTTP/2: HPACK 헤더 압축 HTTP/2: HTTP/2를 위한 기회적 보안 HTTP/2: ORIGIN HTTP/2 프레임 HTTP/2: HTTP/2로 WebSocket 부트스트래핑
HTTP/3	HTTP/3: QPACK: 필드 압축

2. 역사

하이퍼텍스트라는 용어는 1965년 제너두 프로젝트에서 테드 넬슨이 만들었으며, 제너두 프로젝트는 《As We May Think》(1945년)라는 수필에서 마이크로필름 기반 정보 수신 및 관리 "메멕스" 시스템을 기술한 버니바 부시의 비전(1930년대)에 의해 영감을 받았다.^[87] 팀 버너스 리와 그의 팀은 CERN에서 HTML뿐 아니라 웹 브라우저 및 텍스트 기반 웹 브라우저 관련 기술과 더불어 오리지널 HTTP를 발명하였다. 버너스 리는 1989년에 "월드와이드웹" 프로젝트를 제안하였으며, 이것이 현재의 월드 와이드 웹이다.^[85]

최초로 문서화된 HTTP 버전은 '''[http://www.w3.org/pub/WWW/Protocols/HTTP/AsImplemented.html HTTP V0.9]'''(1991년)이다. 이 버전은 서버로부터 페이지를 요청하는 GET이라는 이름의 하나의 메소드만 있었다.^[85] 서버로부터의 응답은 무조건 HTML 문서였다.^[86]

1995년 데이브 레겟은 HTTP 워킹 그룹(HTTP WG)을 이끌었으며, 확장된 조작, 확장된 협상, 더 보강된 메타 정보, 추가 메소드와 헤더 필드를 통한 더 효율적인 보안 프로토콜을 갖춘 프로토콜 확장을 목표로 했다.^[87]^[88] 1996년 RFC 1945에서 HTTP v1.0을 공식 도입하였다.

HTTP WG는 1995년 12월 새로운 표준을 출간하기로 계획하였으며,^[89] 당시 개발 중인 RFC 2068(HTTP-NG)에 기반한 이전 표준 HTTP/1.1에 대한 지원이 1996년 초 주요 브라우저 개발자들에 의해 빠르게 채택되었다. 1996년 3월, HTTP/1.1을 지원한 웹 브라우저에는 아레나,^[90] 넷스케이프 2.0,^[90] 넷스케이프 내비게이터 골드 2.01,^[90] 모자이크 2.7, 링크스 2.5, 인터넷 익스플로러 2.0 등이 있었다. 새로운 브라우저의 최종 사용자 채택 속도는 빨랐다. 1996년 3월, 한 웹 호스팅 회사는 인터넷 사용 브라우저 중 40% 이상이 HTTP 1.1과 호환된다고 보고했다. 같은 해 6월에는 서버에 접근하는 모든 브라우저의 65%가 HTTP/1.1과 호환된다고 보고했다.^[91] RFC 2068에 정의된 HTTP/1.1 표준은 1997년 1월에 공식 출시되었고, 1999년 6월 RFC 2616으로 개선 및 업데이트되었다.

2007년, HTTP/1.1 사양 개정 및 명확화를 위해 '''[http://trac.tools.ietf.org/wg/httpbis/trac/wiki HTTPbis 워킹 그룹]'''이 창설되었다. 2014년 6월, WG는 RFC 2616을 대체하는 업데이트된 6 파트 사양을 출시하였다.

RFC 7230, ''HTTP/1.1: 메시지 구문 및 라우팅''
RFC 7231, ''HTTP/1.1: 의미론 및 콘텐츠''
RFC 7232, ''HTTP/1.1: 조건부 요청''
RFC 7233, ''HTTP/1.1: 범위 요청''
RFC 7234, ''HTTP/1.1: 캐싱''
RFC 7235, ''HTTP/1.1: 인증''

HTTP/2는 2015년 5월 RFC 7540으로 출판되었다. HTTP/3는 2022년 6월 6일, IETF에 의해 RFC 9114로 표준화되었다.^[39]

버전	도입 연도	현재 상태	사용량	지원
HTTP/0.9	1991년	구식	0%	100%
HTTP/1.0	1996년	구식	0%	100%
HTTP/1.1	1997년	표준	33.8%	100%
HTTP/2	2015년	표준	35.3%	66.2%
HTTP/3	2022년	표준	30.9%	30.9%

2. 1. HTTP/0.9

1991년에 처음 문서화된 버전이다.^[69] 팀 버너스 리와 그의 팀은 CERN에서 HTML뿐 아니라 웹 브라우저 및 텍스트 기반 웹 브라우저 관련 기술과 더불어 오리지널 HTTP를 발명하였다. 이 프로토콜의 최초 버전은 서버로부터 페이지를 요청하는 GET이라는 이름의 하나의 메소드만 있었다.^[85] 서버로부터의 응답은 무조건 HTML 문서였다.^[86] 문서화된 최초의 HTTP 버전은 '''[http://www.w3.org/pub/WWW/Protocols/HTTP/AsImplemented.html HTTP V0.9]'''(1991년)이다.

1991년, 문서화된 최초의 공식 HTTP 버전이 700단어 미만의 일반 문서로 작성되었으며, 이 버전은 HTTP/0.9로 명명되었다. 이 버전은 GET 메서드만 지원하여 클라이언트가 서버에서 HTML 문서만 검색할 수 있었고, 다른 파일 형식이나 정보 업로드는 지원하지 않았다.^[1]

HTTP/0.9는 요청에 헤더 필드를 지원하지 않으므로, 이름 기반 가상 호스트를 지원하는 메커니즘이 없다. 이름 기반 가상 호스트를 구현하는 모든 서버는 HTTP/0.9 지원을 비활성화해야 한다.^[37]

2016년 이후, 사용자 에이전트(브라우저 등)와 웹 서버의 많은 제품 관리자와 개발자는 다음과 같은 이유로 HTTP/0.9 프로토콜에 대한 지원을 점진적으로 중단하고 폐기할 계획을 세우기 시작했다:^[38]

RFC 문서가 작성되지 않을 정도로 단순하다(원래 문서만 존재).^[1]
HTTP 헤더가 없고, 요즘 최소한의 보안을 위해 필요한 다른 많은 기능이 부족하다.
1999년~2000년 이후 HTTP/1.0 및 HTTP/1.1 때문에 널리 사용되지 않았으며, 일반적으로 일부 오래된 네트워크 하드웨어, 즉 라우터 등에서만 사용된다.

1991년에 처음 문서화된 버전으로 메서드는 GET밖에 없었다. 응답은 단순히 문서 내용을 반환하고 연결을 끊는 것뿐이며, 응답 코드 규정도 없다. 다음은 HTTP/0.9의 요청 예시이다.

```

GET /index.html

2. 2. HTTP/1.0

1996년 5월 1945로 발표되었다. 이 RFC는 이전 4년 동안 표준 이전의 HTTP/1.0 초안으로 사용되었으며, 이미 많은 웹 브라우저와 웹 서버에서 사용되었다.

HTTP/1.0에서는 POST, HEAD 등 GET 이외의 다양한 메서드가 추가되었다. 응답에는 헤더가 붙게 되었고, 상태 코드, 콘텐츠 유형 등을 포함하게 되었다. 이전 버전인 HTTP/0.9와 구별하기 위해, 요청 프로토콜에 버전 번호를 포함하게 되었다.

HTTP/1.0의 요청 예시는 다음과 같다.

```text

GET /index.html HTTP/1.0

2. 3. HTTP/1.1

HTTP/1.1은 1997년 1월에 RFC 2068로 공식 발표되었으며, 이후 여러 번 개정되었다.^[29] 이 버전에서는 다음과 같은 주요 기능들이 추가되어 효율성을 높였다.

지속적 연결(Persistent Connection): 여러 요청/응답을 하나의 TCP 연결에서 처리하여 효율성을 높였다.
파이프라이닝(Pipelining): 응답을 기다리지 않고 여러 요청을 연속적으로 보낼 수 있게 되었다.
호스트 헤더(Host Header): 하나의 IP 주소에서 여러 도메인을 호스팅하는 가상 호스팅(Virtual Hosting)을 지원한다.
청크 전송 인코딩(Chunked Transfer Encoding): 동적으로 생성되는 콘텐츠를 효율적으로 전송할 수 있게 되었다.

1996년 3월, 아레나,^[90] 넷스케이프 2.0,^[90] 넷스케이프 내비게이터 골드 2.01,^[90] 모자이크 2.7, 링크스 2.5, 인터넷 익스플로러 2.0 등에서 HTTP/1.1을 지원하기 시작했다.^[91] 같은 해 6월에는 서버에 접근하는 브라우저의 65%가 HTTP/1.1과 호환되었다는 보고도 있었다.^[91]

1999년 6월에는 RFC 2616으로 개선 및 업데이트가 이루어졌다. 2014년 6월에는 RFC 2616을 대체하는 업데이트된 6 파트 사양이 출시되었다.

RFC 7230, ''HTTP/1.1: 메시지 구문 및 라우팅''
RFC 7231, ''HTTP/1.1: 의미론 및 콘텐츠''
RFC 7232, ''HTTP/1.1: 조건부 요청''
RFC 7233, ''HTTP/1.1: 범위 요청''
RFC 7234, ''HTTP/1.1: 캐싱''
RFC 7235, ''HTTP/1.1: 인증''

이름 기반 가상 호스트를 위해 Host 헤더 필드 규정이 추가되었다.

HTTP/1.1의 요청 예시는 다음과 같다.

```text

GET /index.html HTTP/1.1

Host: foo.example.com

2. 4. HTTP/2

HTTP/2는 2015년 5월에 으로 발표되었다.^[70] 구글이 개발한 SPDY 프로토콜을 기반으로 만들어졌다.^[71]

HTTP/2는 다음과 같은 주요 특징을 가지고 있다.

헤더 압축(Header Compression): 중복되는 헤더 정보를 줄여 대역폭을 절약한다.
멀티플렉싱(Multiplexing): 하나의 TCP 연결에서 여러 요청/응답을 동시에 처리하여 지연 시간을 줄인다.
서버 푸시(Server Push): 클라이언트가 요청하지 않은 리소스를 서버가 미리 보내줄 수 있다.

이러한 특징들을 통해 HTTP/2는 HTTP/1.1보다 향상된 성능을 제공한다.

2. 5. HTTP/3

IETF가 HTTP-over-QUIC(hq)라는 새로운 통신 프로토콜을 개발하여 HTTP/3으로 명명했다.^[72] IETF가 제정을 추진하는 QUIC는 전송 계층 프로토콜이며, 애플리케이션 계층 프로토콜인 HTTP-over-QUIC와 구분하기 위해 명칭을 변경했다.^[73]

HTTP/2와 비교했을 때, 다중화 스트림 처리가 하위 계층인 QUIC으로 이행되었고,^[74] Head-of-line Blocking 문제를 해결하기 위해 헤더 압축 방식이 변경되었다(HTTP/3용으로 QPACK이 개발됨).^[75]

2020년에 HTTP/3의 최초 초안이 발표되었고, 주요 웹 브라우저와 웹 서버들이 이를 채택하기 시작했다. 2022년 6월 6일, IETF는 HTTP/3를 RFC 9114로 표준화했다.^[39]

3. 기술적 개요

HTTP는 클라이언트-서버 모델을 기반으로 동작하는 요청-응답 프로토콜이다. 웹 브라우저 등의 클라이언트는 서버에 요청 메시지를 보내고, 서버는 요청을 처리한 후 응답 메시지를 반환한다. HTTP는 기본적으로 상태가 없는(Stateless) 프로토콜이므로, 서버는 이전 요청에 대한 정보를 유지하지 않는다. HTTP/1.1까지는 전송 제어 프로토콜(TCP)을 전송 계층 프로토콜로 사용하며, HTTP/3는 QUIC 프로토콜을 사용한다.

3. 1. 연결 관리

HTTP/0.9에서는 각 요청마다 새로운 TCP 연결을 생성하고 닫는 방식으로 동작했다. 당시 웹 사이트는 대부분 단순한 텍스트 기반이었기 때문에 이러한 방식이 큰 문제가 되지 않았다.

HTTP/1.0에서는 `Keep-Alive` 헤더를 통해 연결을 재사용할 수 있게 되었지만, 이는 기본 동작이 아니었다.^[44] 즉, 명시적으로 `Keep-Alive` 헤더를 사용해야 연결을 유지할 수 있었다.

HTTP/1.1에서는 지속적 연결이 기본 동작으로 설정되었다. 따라서 명시적으로 연결을 닫지 않는 한 연결이 유지되어 여러 요청과 응답을 처리할 수 있게 되었다. 이는 클라이언트가 첫 번째 요청을 보낸 후 TCP 3-Way-Handshake 연결을 다시 협상할 필요가 없어 지연 시간을 줄여주고, TCP의 느린 시작 메커니즘으로 인해 시간이 지남에 따라 연결 속도가 빨라지는 장점이 있다.

HTTP/2는 한 걸음 더 나아가 하나의 TCP/IP 연결에서 여러 요청/응답을 동시에 처리하는 멀티플렉싱을 도입하여 효율성을 더욱 높였다.

HTTP/3은 TCP/IP 연결 대신 QUIC + UDP를 사용한다.

3. 2. HTTP 메시지

HTTP 메시지는 클라이언트와 서버 간의 데이터 교환 방식이다. 클라이언트와 서버는 평문(ASCII) 메시지를 통해 소통하며, 클라이언트는 요청 메시지를 서버에 보내고, 서버는 응답 메시지를 반환한다.^[40] 이러한 데이터 교환은 요청-응답 메시지 시퀀스를 통해 이루어지며, 세션 계층 전송 연결을 통해 전달된다.^[40]

HTTP/0.9에서는 요청된 리소스 전체가 전송되었다. HTTP/1.0은 캐시된 리소스 관리를 위한 헤더를 추가하여 조건부 GET 요청을 허용했다. 서버는 클라이언트가 마지막으로 수정한 시간을 알 수 없거나 변경된 경우에만 전체 콘텐츠를 반환했다. 리소스의 총 길이를 알 수 없는 경우, `Content-Length` 헤더가 없어 서버가 연결을 닫을 때 클라이언트는 콘텐츠가 모두 전송되었다고 가정했다. 이 방식은 전송 성공 여부를 구분할 수 없었다.^[43]

HTTP/1.1에서는 캐시 관리, 청크 전송 인코딩, 바이트 서빙 등 새로운 기능이 도입되었다. HTTP/2와 HTTP/3은 HTTP/1.1의 기능을 모두 유지하면서, HTTP 메서드와 헤더의 표현 방식에 차이가 있다.

HTTP 메시지는 크게 요청 메시지와 응답 메시지로 나뉜다.

요청 메시지: 클라이언트가 서버에 보내는 메시지이다. 요청 라인, 요청 헤더 필드, 빈 줄, 메시지 본문(선택 사항)으로 구성된다.
응답 메시지: 서버가 클라이언트에 보내는 메시지이다. 상태 줄, 응답 헤더 필드, 빈 줄, 메시지 본문(선택 사항)으로 구성된다.

HTTP/1.1에서는 컨트롤 데이터를 요청 라인, 상태 라인으로 표현하고, 콘텐츠를 저장하는 부분을 메시지 바디 또는 단순히 바디라고 부른다. 헤더, 콘텐츠, 트레일러는 비어있을 수도 있다.

시스템 간에 메시지를 주고받기 위해서는 연결을 확립해야 한다. HTTP/0.9~HTTP/1.1 및 HTTP/2에서는 TCP를 사용한다. HTTP/0.9에서는 클라이언트의 요청마다 TCP 연결을 확립해야 했다. HTTP/1.0의 확장으로 지속적 연결이 도입되었고, HTTP/1.1에서는 지속적 연결이 기본이 되었다.

3. 2. 1. 요청 메시지

클라이언트와 서버 사이의 소통은 평문(ASCII) 메시지로 이루어진다. 클라이언트는 서버로 요청 메시지를 보내며, 서버는 이에 대한 응답 메시지를 보낸다.^[47]

요청 메시지는 다음과 같은 구성 요소를 갖는다.

'''요청 라인''': 요청 메서드, 공백, 요청된 URI, 또 다른 공백, 프로토콜 버전, 캐리지 리턴, 라인 피드로 구성된다.
예시: `GET /images/logo.png HTTP/1.1`
'''요청 헤더 필드''': 0개 이상(HTTP/1.1의 경우 최소 1개 이상) 존재하며, 각 헤더는 대소문자를 구분하지 않는 필드 이름, 콜론, 선택적인 선행 공백, 필드 값, 선택적인 후행 공백, 캐리지 리턴 및 라인 피드로 구성된다.
예시:

```

Host: www.example.com

Accept-Language: en

```

'''빈 줄''': 캐리지 리턴과 라인 피드로 구성된다.
'''메시지 본문''': 선택적으로 포함될 수 있다.

HTTP/1.1 프로토콜에서 `Host: hostname`을 제외한 모든 헤더 필드는 선택 사항이다.

HTTP는 식별된 리소스에 대해 수행할 원하는 작업을 나타내기 위해 여러 메서드를 정의한다. 주요 메서드는 다음과 같다.

GET: 대상 리소스의 표현을 요청한다. GET 요청은 데이터만 검색해야 하며, URL을 통해 주소 지정이 가능하여 북마크 및 공유가 가능하고 GET 응답을 캐싱할 수 있어 대역폭을 절약할 수 있다.^[54]
HEAD: GET 요청과 유사하지만, 응답 본문에 표현 데이터가 포함되지 않는다. 상태 코드를 통해 페이지 사용 가능 여부를 확인하거나 파일의 크기를 빠르게 찾는 데 사용된다.
POST: 대상 리소스가 요청에 포함된 표현을 처리하도록 요청한다. 인터넷 포럼에 메시지를 게시하거나, 메일링 리스트를 구독하거나, 온라인 쇼핑 거래를 완료하는 데 사용된다.^[55]
PUT: 대상 리소스가 요청에 포함된 표현으로 정의된 상태로 해당 상태를 생성하거나 업데이트하도록 요청한다. POST와의 차이점은 클라이언트가 서버에서 대상 위치를 지정한다는 것이다.^[56]
DELETE: 대상 리소스가 해당 상태를 삭제하도록 요청한다.
CONNECT: 중간 서버가 요청 대상을 통해 식별된 원본 서버에 대한 TCP/IP 터널을 설정하도록 요청한다. 주로 HTTP 프록시를 통해 TLS로 연결을 보호하는 데 사용된다.^[57]^[58]
OPTIONS: 대상 리소스가 지원하는 HTTP 메서드를 전송하도록 요청한다.
TRACE: 대상 리소스가 수신된 요청을 응답 본문에 전송하도록 요청한다.
PATCH: 대상 리소스가 요청에 포함된 표현에 정의된 부분 업데이트에 따라 해당 상태를 수정하도록 요청한다. 파일을 완전히 전송하지 않고 일부를 업데이트하여 대역폭을 절약할 수 있다.^[59]

모든 범용 웹 서버는 최소한 GET 및 HEAD 메서드를 구현해야 하며, 다른 모든 메서드는 선택 사항이다.^[52]

요청 메서드의 속성
요청 메서드	RFC	요청에 페이로드 본문이 있음	응답에 페이로드 본문이 있음	안전함	멱등함	캐싱 가능
GET	9110	선택 사항	예	예	예	예
HEAD	9110	선택 사항	아니요	예	예	예
POST	9110	예	예	아니요	아니요	예
PUT	9110	예	예	아니요	예	아니요
DELETE	9110	선택 사항	예	아니요	예	아니요
CONNECT	9110	선택 사항	예	아니요	아니요	아니요
OPTIONS	9110	선택 사항	예	예	예	아니요
TRACE	9110	아니요	예	예	예	아니요
PATCH	5789	예	예	아니요	아니요	아니요

클라이언트 요청은 빈 줄 다음에 오며, 요청은 각각 캐리지 리턴과 줄 바꿈으로 구성된 두 개의 줄 끝으로 끝난다. `Host: hostname` 헤더 값은 단일 IP 주소를 공유하는 다양한 DNS 이름 간을 구별하여 이름 기반의 가상 호스팅을 허용한다. HTTP/1.0에서는 선택 사항이지만 HTTP/1.1에서는 필수 사항이다.

클라이언트는 이전 요청에 대한 서버의 응답을 기다리지 않고 다른 요청을 발행할 수 있다. ( HTTP 파이프라이닝 )

3. 2. 2. 응답 메시지

클라이언트와 서버는 평문(ASCII) 메시지로 소통한다. 클라이언트는 서버에 요청 메시지를 보내고, 서버는 응답 메시지를 보낸다.^[47]

응답 메시지는 다음과 같이 구성된다.^[47]

상태 줄: 프로토콜 버전, 공백, 응답 상태 코드, 공백, 이유 구절(생략 가능), 캐리지 리턴, 라인 피드로 구성된다. 예시는 다음과 같다.

HTTP/1.1 200 OK

응답 헤더 필드: 0개 이상 존재할 수 있으며, 각 헤더는 대소문자를 구분하지 않는 필드 이름, 콜론, 선택적 선행 공백, 필드 값, 선택적 후행 공백, 캐리지 리턴, 라인 피드로 구성된다. 예시는 다음과 같다.

Content-Type: text/html

빈 줄: 캐리지 리턴과 라인 피드로 구성된다.
메시지 본문: 선택 사항이다.

HTTP/1.0부터 HTTP 응답의 첫 줄은 "상태 줄"이라고 불리며, 숫자 "상태 코드" (예: 404)와 텍스트 "사유 구절" (예: "찾을 수 없음")을 포함한다. 상태 코드는 서버가 클라이언트의 요청을 이해하고 충족하려는 시도의 결과를 나타내는 세 자리 정수 코드이다. 클라이언트는 주로 상태 코드에 따라 응답을 처리하며, 응답 헤더 필드에 따라서도 달라진다.

상태 코드의 첫 번째 숫자는 클래스를 정의한다.

`1XX` (정보): 요청을 받았으며, 프로세스를 계속 진행 중이다.
`2XX` (성공): 요청이 성공적으로 수신, 이해 및 수락되었다.
`3XX` (리디렉션): 요청을 완료하기 위해 추가 조치가 필요하다.
`4XX` (클라이언트 오류): 요청에 잘못된 구문이 있거나 충족될 수 없다.
`5XX` (서버 오류): 서버가 유효한 요청을 충족하지 못했다.

표준 "사유 구절"은 권장 사항일 뿐이며, 웹 개발자의 재량에 따라 "로컬 동등어"로 대체될 수 있다.

ETag 헤더 필드는 요청된 리소스의 캐시된 버전이 서버의 현재 리소스 버전과 동일한지 확인하는 데 사용된다. `Content-Type`은 HTTP 메시지를 통해 전달되는 데이터의 인터넷 미디어 유형을 지정하고, `Content-Length`는 바이트 단위의 길이를 나타낸다. `Connection: close`가 전송되면 이 응답 전송이 종료된 후 웹 서버가 즉시 TCP 연결을 닫는다는 의미이다.^[43]

4. 보안

기본 HTTP는 암호화되지 않은 평문 통신을 하므로, 제3자가 데이터를 가로채거나 변조할 수 있다. HTTPS는 SSL/TLS 프로토콜을 사용하여 HTTP 통신을 암호화하여 보안을 강화한다. HTTPS는 데이터 기밀성, 무결성, 인증을 제공하여 안전한 웹 통신을 가능하게 한다.

가장 널리 사용되는 암호화된 HTTP 연결 설정 방법은 HTTPS이다.^[63] 암호화된 HTTP 연결을 설정하는 다른 두 가지 방법으로는 보안 하이퍼텍스트 전송 프로토콜을 사용하거나, HTTP/1.1 업그레이드 헤더를 사용하여 TLS로 업그레이드하는 방법이 있지만, 이 두 가지 방법에 대한 브라우저 지원은 거의 존재하지 않는다.^[64]^[65]^[66]

4. 1. HTTP 인증

HTTP는 기본 인증 및 다이제스트 인증과 같은 여러 인증 방식을 제공하며, 이는 서버가 요청된 콘텐츠를 제공하기 전에 식별하고 챌린지를 발행하는 챌린지-응답 메커니즘을 통해 작동한다.^[45]

HTTP는 확장 가능한 챌린지-응답 인증 체계를 통해 접근 제어 및 인증을 위한 일반적인 프레임워크를 제공하며, 서버는 이를 사용하여 클라이언트 요청에 도전하고 클라이언트는 인증 정보를 제공할 수 있다.^[45]

위에 설명된 인증 메커니즘은 HTTP 프로토콜에 속하며, 웹 애플리케이션 세션을 사용하는 웹 애플리케이션이 아닌 클라이언트 및 서버 HTTP 소프트웨어에 의해 관리된다(클라이언트가 하나 이상의 웹 리소스에 접근하기 전에 인증을 요구하도록 구성된 경우).

HTTP 인증 규격은 또한 주어진 루트 Uniform Resource Identifier에 공통적으로 적용되는 리소스를 추가적으로 구분하기 위한 임의의 구현 관련 구조를 제공한다. realm 값 문자열이 존재할 경우, 이는 표준 루트 URI와 결합되어 챌린지의 보호 공간 구성요소를 형성한다. 이는 결과적으로 서버가 하나의 루트 URI 아래에서 별도의 인증 범위를 정의할 수 있게 한다.

HTTP 내에서 인증을 수행하는 메커니즘이 준비되어 있다.

HTTP/1.1에서 정의된 가장 단순한 보안 기술이다. "기본 인증을 사용할 바에는 아무것도 사용하지 않는 편이 낫다"고 주장하는 사람도 있다^[83].평문으로 인증 정보를 전송하는 방식이므로, TLS (HTTPS) 등 안전이 확보된 통신로에서의 사용이 바람직하다. 일반적으로 서버는 상태 코드 401로 응답한다.

5. 확장 프로토콜

WebDAV는 HTTP를 확장하여 웹 서버의 파일을 관리하고 공동 작업을 지원하는 프로토콜이다. WebSocket은 HTTP를 기반으로 하는 양방향 통신 프로토콜이다.

참조

_[1] 웹사이트 The Original HTTP as defined in 1991 https://www.w3.org/p[...] World Wide Web Consortium 1991-01-01
_[2] 웹사이트 Basic HTTP as defined in 1992 https://www.w3.org/P[...] World Wide Web Consortium
_[3] IETF RFC RFC 1945
_[4] IETF RFC RFC 2068, RFC 2616, RFC 7230, RFC 9110
_[5] 웹사이트 Usage Statistics of Default protocol https for websites https://w3techs.com/[...]
_[6] 웹사이트 Usage Statistics of HTTP/2 for websites https://w3techs.com/[...]
_[7] 웹사이트 Usage Statistics of HTTP/3 for Websites, August 2024 https://w3techs.com/[...]
_[8] 웹사이트 Can I use... Support tables for HTML5, CSS3, etc https://caniuse.com/[...]
_[9] IETF Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension IETF 2014-07-00
_[10] 웹사이트 Hypertext Transfer Protocol Version 2, Use of TLS Features https://http2.github[...]
_[11] IETF Using TLS 1.3 with HTTP/2
_[12] IETF HTTP/3 2022-06-06
_[13] 웹사이트 Usage Statistics of HTTP/3 for websites https://w3techs.com/[...]
_[14] 웹사이트 Can I use... Support tables for HTML5, CSS3, etc https://caniuse.com/[...]
_[15] 뉴스 Cloudflare, Google Chrome, and Firefox add HTTP/3 support https://www.zdnet.co[...] 2019-09-26
_[16] 웹사이트 HTTP/3: the past, the present, and the future https://blog.cloudfl[...] 2019-09-26
_[17] 웹사이트 Firefox Nightly supports HTTP 3 – General – Cloudflare Community https://community.cl[...] 2019-11-19
_[18] 웹사이트 HTTP/3 is Fast https://requestmetri[...]
_[19] IETF RFC 1945
_[20] IETF RFC 9112, HTTP/1.1
_[21] 웹사이트 Classic HTTP Documents https://www.w3.org/P[...] W3.org 1998-05-14
_[22] IETF RFC 9113, HTTP/2
_[23] 웹사이트 Invention Of The Web, Web History, Who Invented the Web, Tim Berners-Lee, Robert Cailliau, CERN, First Web Server https://www.livingin[...]
_[24] 웹사이트 daemon.c - TCP/IP based server for HyperText https://www.w3.org/D[...] 1990-10-02
_[25] 웹사이트 HyperText Transfer Protocol https://www.w3.org/H[...] World Wide Web Consortium
_[26] 웹사이트 Dave Raggett's Bio https://www.w3.org/P[...] World Wide Web Consortium
_[27] 웹사이트 Hypertext Transfer Protocol Working Group https://www.w3.org/A[...] World Wide Web Consortium
_[28] 웹사이트 HTTP WG Plans https://www.w3.org/A[...] World Wide Web Consortium
_[29] 웹사이트 HTTP 1.1 Compliant Browsers https://www.webcom.c[...]
_[30] 웹사이트 HTTP-NG Working Group https://www.w3.org/P[...] World Wide Web Consortium
_[31] 웹사이트 HTTP Working Group https://httpwg.org/ IETF
_[32] 웹사이트 HTTP Working Group: charter httpbis https://datatracker.[...] IETF
_[33] 웹사이트 SPDY: An experimental protocol for a faster web http://dev.chromium.[...] Google 2009-11-01
_[34] 웹사이트 Rechartering httpbis https://lists.w3.org[...] IETF; HTTP WG 2012-01-24
_[35] 웹사이트 WG Action: RECHARTER: Hypertext Transfer Protocol Bis (httpbis) https://lists.w3.org[...] IETF; HTTP WG 2012-03-19
_[36] 웹사이트 High Performance Browser Networking: Introduction to HTTP/2 https://developers.g[...] Google Inc. 2019-09-03
_[37] RFC RFC 7230, HTTP/1.1: Message Syntax and Routing
_[38] 웹사이트 Intent to Deprecate and Remove: HTTP/0.9 Support https://groups.googl[...] 2016-06-30
_[39] RFC HTTP/3 2022-06-06
_[40] RFC RFC 9110, HTTP Semantics
_[41] RFC RFC 9110, HTTP Semantics
_[42] RFC RFC 9110, HTTP Semantics
_[43] RFC RFC 9112, HTTP/1.1
_[44] 서적 HTTP: The Definitive Guide. (excerpt of chapter: "Persistent Connections") https://www.oreilly.[...] O'Reilly Media, inc. 2021-10-18
_[45] RFC HTTP Semantics IETF 2022-06
_[46] 논문 Secure and efficient protection for HTTP cookies with self-verification https://onlinelibrar[...] 2019-01-25
_[47] RFC RFC 9112: HTTP/1.1
_[48] 웹사이트 Apache Week. HTTP/1.1 https://web.archive.[...] 2021-05-03
_[49] RFC Hypertext Transfer Protocol – HTTP/1.0 IETF
_[50] RFC RFC 2616
_[51] RFC RFC 9112, HTTP/1.1
_[52] RFC RFC 9110, HTTP Semantics
_[53] RFC RFC 9110, HTTP Semantics
_[54] 웹사이트 URIs, Addressability, and the use of HTTP GET and POST https://www.w3.org/2[...] W3C 2010-09-26
_[55] RFC RFC 9110, HTTP Semantics
_[56] RFC RFC 9110, HTTP Semantics
_[57] RFC RFC 9110, HTTP Semantics
_[58] 웹사이트 Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections https://www.kb.cert.[...] US-CERT 2007-05-10
_[59] RFC PATCH Method for HTTP IETF 2010-03
_[60] 서적 Advanced Rails: Building Industrial-Strength Web Apps in Record Time https://shop.oreilly[...] O'Reilly Media, Inc. 2007-12-21
_[61] 웹사이트 What Have We Learned From the Google Web Accelerator? https://web.archive.[...] Adobe 2018-11-19
_[62] RFC Byte Range Retrieval Extension to HTTP IETF 1996-02-22
_[63] 서적 Fundamentals of Networking Security Artech House
_[64] 웹사이트 Browser Security Handbook https://code.google.[...] 2015-04-30
_[65] 웹사이트 Chromium Issue 4527: implement RFC 2817: Upgrading to TLS Within HTTP/1.1 https://code.google.[...] 2015-04-30
_[66] 웹사이트 Mozilla Bug 276813 – [RFE] Support RFC 2817 / TLS Upgrade for HTTP 1.1 https://bugzilla.moz[...] 2015-04-30
_[67] RFC Web Linking IETF 2010-10
_[68] RFC The Hypertext Transfer Protocol (HTTP) is a family of stateless, application-level, request/response protocols ... HTTP is a stateless request/response protocol for exchanging 'messages' across a connection.
_[69] 웹사이트 The HTTP Protocol As Implemented In W3 https://www.w3.org/P[...]
_[70] 웹사이트 S&M vs. SPDY: Microsoft and Google battle over the future of HTTP 2.0 https://www.extremet[...] ExtremeTech 2014-09-23
_[71] 웹사이트 Can the rise of SPDY threaten HTTP? http://blog.restlet.[...] Restlet 2014-09-23
_[72] 웹사이트 Gigazine『UDPベースの「HTTP-over-QUIC」が新HTTPバージョン「HTTP/3」に名称変更される』 https://gigazine.net[...] GIGAZINE 2018-11-14
_[73] 웹사이트 IETF Meetingの資料スライド https://github.com/q[...]
_[74] 웹사이트 QUICの話 (QUICプロトコルの簡単なまとめ) https://asnokaze.hat[...] 2019-05-12
_[75] 웹사이트 QUICの話 (QUICプロトコルの簡単なまとめ) https://asnokaze.hat[...] 2019-05-12
_[76] 웹사이트 RFC 2817 Upgrading to TLS Within HTTP/1.1 https://datatracker.[...] 2019-04-26
_[77] 웹사이트 RFC 7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing https://datatracker.[...] 2019-04-26
_[78] 웹사이트 Hypertext Transfer Protocol (HTTP) Method Registry https://www.iana.org[...]
_[79] 표준 IETF RFC 9110, 6. Message Abstraction
_[80] 웹사이트 HTTP Content Coding Registry https://www.iana.org[...]
_[81] 웹사이트 RFC 1864 The Content-MD5 Header Field https://datatracker.[...] Internet Engineering Task Force 2021-01-30
_[82] 웹사이트 RFC 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content https://datatracker.[...] Internet Engineering Task Force 2021-01-30
_[83] 서적 HTTPプロトコル―セキュア&スケーラブルなWeb開発ソフトバンクパブリッシング
_[84] 웹사이트 JPNIC News & Views vol.1647【臨時号】第103回IETF報告 [第4弾] トランスポートエリア関連報告～HTTP over QUICからHTTP/3への改称～ https://www.nic.ad.j[...] 2021-06-28
_[85] 웹인용 HyperText Transfer Protocol http://www.w3.org/Hi[...] World Wide Web Consortium 2010-08-31
_[86] 웹인용 The Original HTTP as defined in 1991 http://www.w3.org/Pr[...] World Wide Web Consortium 2010-07-24
_[87] 웹인용 Dave Raggett's Bio http://www.w3.org/Pe[...] World Wide Web Consortium 2010-06-11
_[88] 웹인용 Hypertext Transfer Protocol Working Group http://www.w3.org/Ar[...] World Wide Web Consortium 2010-09-29
_[89] 웹인용 HTTP WG Plans http://www.w3.org/Ar[...] World Wide Web Consortium 2010-09-29
_[90] 웹인용 Progress on HTTP-NG http://www.w3.org/Pr[...] World Wide Web Consortium 2010-06-11
_[91] 웹인용 HTTP/1.1 http://www.webcom.co[...] 2009-05-29
_[92] 문서 HTTP 응답 코드 설명
_[93] 문서 HTTP 응답 코드 설명
_[94] 문서 HTTP 응답 코드 설명
_[95] 문서 HTTP 응답 코드 설명
_[96] 문서 HTTP 응답 코드 설명
_[97] 문서 HTTP 응답 코드 설명
_[98] 문서 HTTP 응답 코드 설명
_[99] 문서 HTTP 응답 코드 설명
_[100] 문서 HTTP 응답 코드 설명
_[101] 문서 HTTP 응답 코드 설명
_[102] 문서 HTTP 응답 코드 설명
_[103] 문서 HTTP 응답 코드 설명
_[104] 문서 HTTP 응답 코드 설명
_[105] 문서 HTTP 응답 코드 설명
_[106] 문서 프록시 서버 인증 오류
_[107] 문서 메타-정보 중복 방지
_[108] 문서 Retry-After 헤더
_[109] 문서 URI 길이 초과
_[110] 문서 서버 요청 실패
_[111] 문서 서버 기능 지원 부족
_[112] 문서 서버 과부하 또는 게이트웨이 오류
_[113] 문서 서버 일시적 과부하 또는 관리 중

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com