Page protected with pending changes

HTTP

HTTP
HTTP
국제표준
  • RFC1945 HTTP/1.0
  • RFC 9110 HTTP 시맨틱스
  • RFC 911 HTTP 캐싱
  • RFC 9112 HTTP/1.1
  • RFC 9113 HTTP/2
  • RFC 7541 HTTP/2: HPACK 헤더 압축
  • RFC 8164 HTTP/2: HTTP/2를 위한 기회주의적 보안
  • RFC 8336 HTTP/2: 더 오리진 HTTP/2 프레임
  • RFC 8441 HTTP/2: HTTP/2를 사용한 부트스트래핑 웹소켓
  • RFC 9114 HTTP/3
  • RFC 9204 HTTP/3: QPACK: 필드 압축
개발자초기 CERN; IETF, W3C
소개했다1991년; 33년전(1991년)
웹사이트https://httpwg.org/specs/
HTTP
요청방법
머리글 필드
응답상태코드
보안 접근 제어 방법
보안 취약성
인터넷 프로토콜 스위트
응용 계층
트랜스포트 레이어
인터넷 계층
링크 계층

HTTP(Hypertext Transfer Protocol)는 분산, 협업, 하이퍼미디어 정보 시스템을 위한 인터넷 프로토콜 모음 모델의 응용 프로그램 계층 프로토콜입니다.[1] HTTP는 월드 와이드 웹을 위한 데이터 통신의 기초이며, 하이퍼텍스트 문서는 예를 들어 마우스 클릭 또는 웹 브라우저의 화면을 탭하여 사용자가 쉽게 액세스할 수 있는 다른 리소스에 대한 하이퍼링크를 포함합니다.

HTTP의 개발은 1989년 CERN에서 Tim Berners-Lee에 의해 시작되었으며, 0.9라는 이름의 첫 번째 HTTP 버전을 사용하는 클라이언트와 서버의 동작을 설명하는 간단한 문서에 요약되어 있습니다.[2] 그 버전은 그 후에 개발되었고, 결국 대중 1.0이 되었습니다.[3]

초기 HTTP Requests for Comments (RFC)의 개발은 몇 년 후 인터넷 엔지니어링 태스크 포스 (IETF)와 월드 와이드 웹 컨소시엄 (W3C)의 협력된 노력으로 시작되었으며 나중에 IETF로 작업이 옮겨졌습니다.

HTTP/1은 1996년에 최종화되어 완전히 문서화되었습니다(버전 1.0으로).[4] 1997년에 (버전 1.1로) 진화한 후 1999년, 2014년, 2022년에 사양이 업데이트되었습니다.[5]

HTTPS라는 이름의 보안 변형은 85% 이상의 웹 사이트에서 사용됩니다.[6] 2015년에 발표된 HTTP/2는 HTTP의 시맨틱스를 보다 효율적으로 "on the wire"로 표현합니다. 2024년 1월 현재 36%의[7] 웹사이트에서 사용되고 있으며 거의 모든 웹 브라우저(98% 이상의 사용자)에서 지원하고 있습니다.[8] 또한 TLS 1.2 이상이 필요한 애플리케이션 계층 프로토콜 협상(ALPN) 확장을[9] 사용하는 TLS(Transport Layer Security)를 통한 주요 웹 서버에서도 지원됩니다.[10][11]

HTTP/2의 후속작인 HTTP/3는 2022년에 발표되었습니다.[12] 현재 28%의[13] 웹 사이트에서 사용되며 대부분의 웹 브라우저에서 지원됩니다. 즉 (적어도 부분적으로) 97%의 사용자가 지원합니다.[14] HTTP/3는 기본 전송 프로토콜에 대해 TCP 대신 QUIC를 사용합니다. HTTP/2와 마찬가지로 이전의 주요 버전의 프로토콜을 사용하지 않습니다. HTTP/3 지원은 클라우드플레어와 구글 크롬에 먼저 추가되었으며 [15][16]파이어폭스에서도 활성화됩니다.[17] HTTP/3는 서버에서 활성화된 경우 실제 웹 페이지에 대해 더 낮은 지연 시간을 가지며 HTTP/2보다 더 빠르게 로드되며, 어떤 경우에는 HTTP/1.1보다 3배 이상 빠릅니다(여전히 일반적으로만 활성화됨).[18]

기술개요

HTTP는 클라이언트-서버 모델에서 요청-응답 프로토콜로 기능합니다. 예를 들어, 웹 브라우저가 클라이언트일 수 있는 반면, 웹 서버라는 이름의 프로세스는 하나 이상의 웹 사이트를 호스팅하는 컴퓨터에서 실행될 수 있습니다. 클라이언트는 HTTP 요청 메시지를 서버에 제출합니다. HTML 파일 및 기타 콘텐츠와 같은 리소스를 제공하거나 클라이언트를 대신하여 다른 기능을 수행하는 서버는 응답 메시지를 클라이언트에 반환합니다. 응답에는 요청에 대한 완료 상태 정보가 포함되며 메시지 본문에 요청된 내용이 포함될 수도 있습니다.

웹 브라우저는 사용자 에이전트(UA)의 예입니다. 다른 유형의 사용자 에이전트에는 검색 공급자(웹 크롤러), 음성 브라우저, 모바일 앱 및 웹 콘텐츠에 액세스, 소비 또는 표시하는 기타 소프트웨어가 사용되는 인덱싱 소프트웨어가 포함됩니다.

HTTP는 중간 네트워크 요소가 클라이언트와 서버 간의 통신을 개선하거나 활성화할 수 있도록 설계되었습니다. 트래픽이 많은 웹 사이트는 종종 응답 시간을 향상시키기 위해 업스트림 서버를 대신하여 콘텐츠를 제공하는 웹 캐시 서버의 혜택을 받습니다. 웹 브라우저는 이전에 액세스한 웹 리소스를 캐시하고 가능할 때마다 재사용하여 네트워크 트래픽을 줄입니다. 사설 네트워크 경계에 있는 HTTP 프록시 서버는 외부 서버와 메시지를 중계함으로써 글로벌하게 라우팅 가능한 주소가 없는 클라이언트의 통신을 용이하게 할 수 있습니다.

중간 HTTP 노드(프록시 서버, 웹 캐시 등)가 그 기능을 수행할 수 있도록 하기 위해, 일부 HTTP 헤더(HTTP 요청/응답에서 발견됨)는 홉 바이 홉으로 관리되는 반면, 다른 HTTP 헤더는 엔드 투 엔드로 관리됩니다(소스 클라이언트 및 대상 웹 서버에 의해서만 관리됨).

HTTP는 인터넷 프로토콜 제품군의 프레임워크 내에서 설계된 응용 프로그램 계층 프로토콜입니다. 그 정의는 기본적이고 신뢰할 수 있는 전송 계층 프로토콜을 가정합니다.[19] 최신 버전의 HTTP/3에서는 더 이상 TCP(Transmission Control Protocol)가 사용되지 않지만 이전 버전은 여전히 더 많이 사용되며 TCP를 가장 일반적으로 사용합니다. 또한 HTTP/3도 (간접적으로) HTTPU 및 SSDP(Simple Service Discovery Protocol)와 같이 항상 기반으로 하는 UDP(User Dataagram Protocol)와 같은 신뢰할 수 없는 프로토콜을 사용하도록 조정되었습니다.

HTTP 리소스는 URI(Uniform Resource Identifier) 체계 http 및 https를 사용하여 URL(Uniform Resource Locator)에 의해 식별되고 네트워크에 위치합니다. RFC 3986에 정의된 바와 같이 URI는 HTML 문서에서 하이퍼링크로 인코딩되어 상호 연결된 하이퍼텍스트 문서를 형성합니다.

HTTP/1.0에서는 모든 리소스 요청에 대해 동일한 서버에 대한 별도의 TCP 연결이 이루어집니다.[20]

대신 HTTP/1.1에서는 TCP 연결을 재사용하여 여러 리소스 요청(즉, HTML 페이지, 프레임, 이미지, 스크립트, 스타일시트 등)을 할 수 있습니다.[21][22]

따라서 HTTP/1.1 통신은 TCP 연결 설정이 특히 트래픽이 높은 조건에서 상당한 오버헤드를 나타내므로 지연 시간이 줄어듭니다.[23]

HTTP/2는 동일한 클라이언트-서버 모델 및 동일한 프로토콜 방식을 유지하기 위해 이전 HTTP/1.1을 수정한 것입니다.

  • 텍스트 대신 메타데이터(HTTP 헤더)의 압축 바이너리 표현을 사용하여 헤더가 훨씬 적은 공간을 필요로 합니다.
  • 2~8개의 TCP/IP 연결 대신 액세스된 서버 도메인당 하나의 TCP/IP(일반적으로 암호화된) 연결을 사용합니다.
  • HTTP 요청 및 응답을 세분화하여 작은 패킷으로 전송하는 TCP/IP 연결당 하나 이상의 양방향 스트림을 사용하여 HOLB(head-of-line blocking) 문제를 거의 해결합니다.[note 1]
  • 서버 응용 프로그램이 새로운 데이터를 사용할 수 있을 때마다(클라이언트가 폴링 방법을 사용하여 서버에 주기적으로 새로운 데이터를 요청하지 않고) 클라이언트에 데이터를 보낼 수 있도록 푸시 기능을 추가합니다.[24]

따라서 HTTP/2 통신은 HTTP/1.1 통신보다 훨씬 적은 지연 시간과 더 빠른 속도를 경험합니다.

HTTP/3는 TCP 대신 QUIC + UDP 전송 프로토콜을 사용하기 위해 이전 HTTP/2를 수정한 것입니다. 그 버전 이전에는 TCP/IP 연결이 사용되었지만 지금은 IP 계층만 사용됩니다(TCP와 같은 UDP가 기반이 됩니다). 이를 통해 통신의 평균 속도가 약간 향상되고 모든 스트림의 데이터 흐름을 일시적으로 차단하거나 속도를 늦출 수 있는 TCP 연결 혼잡(다른 형태의 "헤드 오브 라인 차단") 문제가 가끔 발생하는 것을 방지할 수 있습니다.

역사

팀 버너스리

하이퍼텍스트라는 용어는 1965년 테드 넬슨(Ted Nelson)이 Xanadu Project(자나두 프로젝트)에서 만들어졌으며, 이는 바네바 부시(Vannevar Bush)가 1945년 에세이 "As We May Think(우리가 생각하는 대로)"에서 설명한 마이크로필름 기반 정보 검색 및 관리 "memex" 시스템에 대한 1930년대 비전에서 영감을 받았습니다. CERN의 Tim Berners-Lee와 그의 팀은 HTML과 웹 서버 및 웹 브라우저라는 클라이언트 사용자 인터페이스에 대한 관련 기술과 함께 원본 HTTP를 발명한 것으로 인정받고 있습니다. 버너스 리(Berners-Lee)는 자신의 또 다른 아이디어인 "월드와이드웹(WorldWideWeb)" 프로젝트의 채택을 돕기 위해 HTTP를 설계했습니다.

최초의 웹 서버는 1990년에 가동되었습니다.[25][26] 사용된 프로토콜에는 서버에서 페이지를 요청하는 GET라는 한 가지 방법만 있었습니다.[27] 서버의 응답은 항상 HTML 페이지였습니다.[2]

HTTP 마일스톤 버전 요약

버전 도입연도 현황
HTTP/0.9 1991 구식
HTTP/1.0 1996 구식
HTTP/1.1 1997 표준.
HTTP/2 2015 표준.
HTTP/3 2022 표준.
HTTP/0.9
1991년 최초로 문서화된 HTTP 공식 버전은 700단어 길이 미만의 일반 문서로 작성되었으며, 이 버전은 GET 방식만 지원하는 HTTP/0.9로 명명되어 클라이언트가 HTML 문서를 서버에서 검색할 수 있을 뿐 다른 파일 형식이나 정보 업로드는 지원하지 않습니다.[2]
HTTP/1.0-draft
1992년부터 다음 전체 버전을 향한 기본 프로토콜의 진화를 명시하기 위해 새로운 문서가 작성되었습니다. 0.9 버전의 단순 요청 방식과 클라이언트 HTTP 버전을 포함하는 전체 GET 요청을 모두 지원했습니다. 이것은 HTTP/1.0에 대한 최종 작업 이전의 많은 비공식 HTTP/1.0 초안 중 첫 번째였습니다.[3]
W3C HTTP 워킹 그룹
HTTP 프로토콜의 새로운 기능이 요구되고 공식 RFC로서 완전히 문서화되어야 한다고 결정한 후, 1995년 초에 확장된 운영, 확장된 협상, 풍부한 메타 정보를 포함하는 프로토콜을 표준화하고 확장하기 위한 목적으로 HTTP Working Group(HTTP WG, Dave Raggett이 주도함)이 구성되었습니다. 추가적인 메소드와 헤더 필드를 추가함으로써 더 효율적이 된 보안 프로토콜로 묶여 있습니다.[28][29]
HTTP WG는 1995년 안에 새로운 버전의 프로토콜을 HTTP/1.0과 HTTP/1.1로 개정하여 발표할 계획이었지만, 많은 개정이 있었기 때문에 그 일정은 1년 이상 지속되었습니다.[30]
HTTP WG는 또한 이전 버전의 성능, 낮은 지연 시간 응답 등 남아있는 모든 문제를 해결할 HTTP-NG(HTTP Next Generation)라는 훨씬 미래 버전을 지정할 계획이었지만 이 작업은 몇 년 후에 시작되어 결코 완료되지 않았습니다.
HTTP/1.0
1996년 5월, RFC 1945는 이전 4년 동안 많은 웹 브라우저와 웹 서버에서 이미 사용되었던 표준 HTTP/1.0 초안으로 사용되었던 것을 최종 HTTP/1.0 개정판으로 출판되었습니다.
1996년 초, 개발자들은 HTTP/1.1 규격의 초안을 사용하여 HTTP/1.0 프로토콜의 비공식적인 확장(즉, 킵얼라이브 연결 등)을 제품에 포함시키기 시작했습니다.[31]
HTTP/1.1
1996년 초부터 주요 웹 브라우저 및 웹 서버 개발자들도 사전 표준 HTTP/1.1 초안 사양에 따라 지정된 새로운 기능을 구현하기 시작했습니다. 새로운 버전의 브라우저와 서버를 최종 사용자가 빠르게 채택했습니다. 1996년 3월, 한 웹 호스팅 회사는 인터넷에서 사용 중인 브라우저의 40% 이상이 새로운 HTTP/1.1 헤더 "호스트"를 사용하여 가상 호스팅을 가능하게 했다고 보고했습니다. 같은 웹 호스팅 회사는 1996년 6월까지 서버에 액세스하는 모든 브라우저의 65%가 사전 표준 HTTP/1.1을 준수했다고 보고했습니다.[32]
1997년 1월, RFC 2068은 HTTP/1.1 규격으로 공식 출시되었습니다.
1999년 6월, RFC 2616은 이전(구시대) HTTP/1.1 사양에 기초한 모든 개선 및 업데이트를 포함하도록 출시되었습니다.
W3C HTTP-NG 워킹 그룹
이전 HTTP Working Group의 1995년 계획을 재개하여 1997년 HTTP-NG Working Group이 구성되어 HTTP-NG(HTTP New Generation)라는 이름의 새로운 HTTP 프로토콜을 개발했습니다. 새로운 프로토콜이 하나의 TCP/IP 연결 내에서 HTTP 트랜잭션의 다중화를 사용하기 위해 몇 가지 제안/초안이 제작되었지만 1999년에 이 그룹은 기술적 문제를 IETF에 전달하는 활동을 중단했습니다.[33]
IETF HTTP Working Group이 다시 시작됨
2007년에 IETF HTTP Working Group(HTTP WG bis 또는 HTTPbis)이 먼저 재가동되어 이전 HTTP/1.1 사양을 수정 및 명확화하고, 두 번째로 향후 HTTP/2 사양(이름은 httpbis)을 작성 및 정제하였습니다.[34][35]
SPDY: 구글이 개발한 비공식 HTTP 프로토콜
2009년, 민간 기업인 구글은 SPDY라는 이름의 새로운 HTTP 이진 프로토콜을 개발하고 테스트했다고 발표했습니다. 암묵적인 목표는 웹 트래픽(특히 미래의 웹 브라우저와 서버 간)의 속도를 크게 높이는 것이었습니다.
SPDY는 많은 테스트에서 HTTP/1.1보다 훨씬 빨랐기 때문에 크롬과 다른 주요 웹 브라우저에서 빠르게 채택되었습니다.[36]
단일 TCP/IP 연결을 통해 HTTP 스트림을 다중화하는 아이디어 중 일부는 W3C HTTP-NG Working Group의 작업을 포함하여 다양한 소스에서 가져온 것입니다.
HTTP/2
2012년 1월-3월, HTTP Working Group(HTTPbis)은 새로운 HTTP/2 프로토콜에 초점을 맞출 필요성을 발표했습니다(HTTP/1.1 사양의 개정을 완료하면서), SPDY를 위해 수행된 아이디어와 작업을 고려할 수 있습니다.[37][38]
새로운 버전의 HTTP를 개발하기 위해 무엇을 해야 할지에 대해 몇 달 후, SPDY에서 도출하기로 결정했습니다.[39]
2015년 5월, HTTP/2는 RFC 7540으로 발표되었으며, 이미 SPDY를 지원하는 모든 웹 브라우저에서 빠르게 채택되었으며 웹 서버에서도 더 느리게 채택되었습니다.
2014년 HTTP/1.1 업데이트
2014년 6월, HTTP 워킹 그룹은 RFC2616을 폐지하는 업데이트된 6개의 부분 HTTP/1.1 사양을 공개했습니다.
  • 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/0.9 감가상각
RFC 7230 부록-A에서 HTTP/1.1 버전 이상을 지원하는 서버에 대해 HTTP/0.9가 권장되지 않았습니다.[40]

HTTP/0.9는 요청에서 헤더 필드를 지원하지 않았으므로 이름 기반 가상 호스트(Host Header 필드 검사에 의한 리소스 선택)를 지원하는 메커니즘이 없습니다. 이름 기반 가상 호스트를 구현하는 모든 서버는 HTTP/0.9에 대한 지원을 비활성화해야 합니다. HTTP/0.9로 보이는 대부분의 요청은 실제로 클라이언트가 요청 대상을 제대로 인코딩하지 못해 발생한 HTTP/1.x 요청입니다.

2016년부터 사용자 에이전트(브라우저 등) 및 웹 서버의 많은 제품 관리자 및 개발자들은 주로 다음과 같은 이유로 HTTP/0.9 프로토콜에 대한 지원을 점진적으로 중단하고 거부할 계획을 시작했습니다.[41]
  • RFC 문서가 작성된 적이 없을 정도로 간단합니다(오리지널 문서만 있음).[2]
  • HTTP 헤더가 없고 보안상의 이유로 요즘 요구되는 많은 기능이 부족합니다.
  • 그것은 1999년 이후로 널리 퍼지지 않았습니다.2000(HTTP/1.0 및 HTTP/1.1 때문에)은 일부 매우 오래된 네트워크 하드웨어, 즉 라우터에서만 일반적으로 사용됩니다.
[주2]
HTTP/3
2020년에 HTTP/3 초안이 발표되고 주요 웹 브라우저와 웹 서버가 채택되기 시작했습니다.
2022년 6월 6일, IETF는 HTTP/3를 RFC 9114로 표준화했습니다.[42]
2022년 업데이트 및 리팩터링
2022년 6월 RFC 배치가 발표되었는데, 이전 문서의 많은 부분을 삭제하고 몇 가지 사소한 변경 사항과 HTTP 의미론 설명을 별도의 문서로 리팩토링하는 것을 도입했습니다.
  • RFC 9110, HTTP 시맨틱스
  • RFC 911, HTTP 캐싱
  • RFC 9112, HTTP/1.1
  • RFC 9113, HTTP/2
  • RFC 9114, HTTP/3 (위 섹션 참조)
  • RFC 9204, QPACK: HTTP/3를 위한 필드 압축
  • RFC 9218 HTTP를 위한 확장 가능한 우선순위 체계

HTTP 데이터 교환

HTTP는 상태 비저장 응용 프로그램 수준 프로토콜이며 클라이언트와 서버 간에 데이터를 교환하려면 신뢰할 수 있는 네트워크 전송 연결이 필요합니다.[19] HTTP 구현에서 TCP/IP 연결은 잘 알려진 포트(일반적으로 연결이 암호화되지 않은 경우 포트 80 또는 연결이 암호화된 경우 포트 443)를 사용하여 사용됩니다.[43][44] HTTP/2에서는 TCP/IP 연결과 여러 프로토콜 채널이 사용됩니다. HTTP/3에서는 응용 프로그램 전송 프로토콜 QUIC over UDP가 사용됩니다.

연결을 통한 요청 및 응답 메시지

데이터는 세션 계층 전송 연결에 의해 교환되는 일련의 요청-응답 메시지를 통해 교환됩니다.[19] HTTP 클라이언트는 처음에 연결을 설정하는 서버(실제 또는 가상)에 연결하려고 합니다. 해당 포트에서 수신 중인 HTTP(S) 서버는 연결을 수락한 다음 클라이언트의 요청 메시지를 기다립니다. 클라이언트는 HTTP 요청 메시지를 보냅니다. 요청을 수신하면 서버는 헤더와 필요한 경우 본문을 포함하는 HTTP 응답 메시지를 다시 보냅니다. 이 응답 메시지의 본문은 일반적으로 요청된 리소스이지만 오류 메시지 또는 기타 정보도 반환될 수 있습니다. 클라이언트 또는 서버는 언제든지(여러 가지 이유로) 연결을 닫을 수 있습니다. 연결을 닫는 것은 일반적으로 서버 또는 클라이언트에 전송된 마지막 요청/응답 메시지에서 하나 이상의 HTTP 헤더를 사용하여 미리 통지됩니다.[21]

지속적인 연결

본문: HTTP 영구접속

HTTP/0.9에서 TCP/IP 연결은 서버 응답이 전송된 후에 항상 닫혀 있으므로 절대 지속되지 않습니다.

HTTP/1.0에서 RFC 1945에 명시된 바와 같이 TCP/IP 연결은 응답이 전송된 후 서버에 의해 항상 닫아야 합니다.[note 3]

HTTP/1.1에서는 하나 이상의 요청/응답에 대해 연결을 재사용할 수 있도록 keep-alive-mechanism이 공식적으로 도입되었습니다. 이러한 지속적인 연결은 클라이언트가 첫 번째 요청을 보낸 후 TCP 3-Way-Handshake 연결을 재협상할 필요가 없기 때문에 요청 지연 시간을 눈에 띄게 줄입니다. 또 다른 긍정적인 부작용은 일반적으로 TCP의 느린 시작 메커니즘으로 인해 시간이 지남에 따라 연결이 더 빨라진다는 것입니다.

HTTP/1.1은 클라이언트가 각 응답을 대기하기 전에 여러 요청을 보낼 수 있도록 하여 영구 연결을 사용할 때 지연 시간을 더욱 줄이기 위해 HTTP 파이프라인을 추가했습니다. 이 최적화는 몇 개의 웹 서버와 많은 프록시 서버, 특히 클라이언트와 서버 사이의 인터넷/Intranet에 배치된 투명 프록시 서버가 파이프라인 요청을 제대로 처리하지 않았기 때문에 결코 안전하다고 생각되지 않았습니다. 첫 번째 요청 후 더 많은 데이터를 보았거나 일부 프록시가 응답을 정상적으로 반환하는 등의 이유로 연결을 닫았습니다.) 이 외에도 HEAD 및 일부 GET 요청(즉, 실제 파일 요청으로 제한되고 쿼리 문자열이 명령어로 사용되지 않는 URL 등)만 안전하고 idempotent 모드로 파이프라인될 수 있습니다. 파이프라이닝을 가능하게 함으로써 도입된 문제들로 수년간 어려움을 겪은 후, 이 기능은 처음에 비활성화되었다가 HTTP/2의 채택이 발표되었기 때문에 대부분의 브라우저에서 제거되었습니다.

HTTP/2는 하나의 TCP/IP 연결을 통해 많은 동시 요청/응답을 다중화함으로써 영구 연결의 사용을 확장했습니다.

HTTP/3는 TCP/IP 연결을 사용하지 않고 QUIC + UDP를 사용합니다(기술 개요 참조).

콘텐츠 검색 최적화

HTTP/0.9
요청된 리소스는 항상 전체적으로 전송되었습니다.
HTTP/1.0
HTTP/1.0은 조건부 GET 요청을 허용하기 위해 클라이언트에 의해 캐시된 리소스를 관리하기 위해 헤더를 추가했습니다. 실제로 서버는 클라이언트에 의해 마지막으로 수정된 시간을 알 수 없거나 GET 요청에 대한 마지막 전체 응답 이후 변경된 경우에만 요청된 리소스의 전체 콘텐츠를 반환해야 합니다. 이러한 헤더 중 하나인 "Content-Encoding"은 리소스의 반환된 내용이 압축되었는지 여부를 지정하기 위해 추가되었습니다.
리소스 내용의 총 길이를 미리 알 수 없는 경우(즉, 동적으로 생성되었기 때문에 등) 헤더 "Content-Length: number" 는 HTTP 헤더에 존재하지 않았으며 클라이언트는 서버가 연결을 닫았을 때 컨텐츠가 완전히 전송되었다고 가정했습니다. 이 메커니즘은 성공적으로 완료된 리소스 전송과 중단된 리소스 전송을 구분할 수 없습니다(서버/네트워크 오류 또는 다른 것 때문).
HTTP/1.1
HTTP/1.1이 도입되었습니다.
  • 캐시된 리소스의 조건부 검색을 더 잘 관리하기 위한 새 헤더.
  • 서버가 콘텐츠의 길이를 미리 알지 못하는 경우에도(즉, 동적으로 생성되기 때문에 등) 안정적으로 콘텐츠를 전송할 수 있도록 청크 전송 인코딩(chunked transfer encoding).
  • 바이트 범위 서빙 - 클라이언트가 리소스의 하나 이상의 부분(예: 전체 콘텐츠의 첫 번째 부분, 중간 또는 끝 부분 등)만 요청할 수 있고 서버는 일반적으로 요청된 부분(들)만 보냅니다. 이는 시간, 대역폭 및 시스템 리소스 등을 절약하기 위해 브라우저에 의해 콘텐츠의 일부만 표시되거나 이미 보이는 부분에 동적으로 추가되어야 할 때(즉, 웹 페이지의 첫 번째 또는 다음 n개의 주석만 표시) 중단된 다운로드를 재개하는 데 유용합니다.
HTTP/2, HTTP/3
HTTP/2 및 HTTP/3은 모두 위에서 언급한 HTTP/1.1의 기능을 유지하고 있습니다.

HTTP 인증

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

HTTP는 서버가 클라이언트 요청에 도전하고 클라이언트가 인증 정보를 제공하는 데 사용할 수 있는 확장 가능한 일련의 도전 응답 인증 체계를 통해 액세스 제어 및 인증을 위한 일반적인 프레임워크를 제공합니다.[1]

위에서 설명한 인증 메커니즘은 HTTP 프로토콜에 속하며 클라이언트 및 서버 HTTP 소프트웨어(하나 이상의 웹 리소스에 대한 클라이언트 액세스를 허용하기 전에 인증이 필요하도록 구성된 경우)에 의해 관리되며 웹 응용 프로그램 세션을 사용하는 웹 응용 프로그램에 의해 관리되지 않습니다.

인증 영역

HTTP 인증 규격은 또한 주어진 루트 URI에 공통적인 리소스 분할을 위한 임의의 구현별 구성을 제공합니다. 영역 값 문자열이 있는 경우 표준 루트 URI와 결합하여 챌린지의 보호 공간 구성 요소를 형성합니다. 이를 통해 서버는 하나의 루트 URI 아래에 별도의 인증 범위를 정의할 수 있습니다.[1]

HTTP 응용 프로그램 세션

HTTP는 상태 비저장 프로토콜입니다. 상태 비저장 프로토콜은 웹 서버가 여러 요청 기간 동안 각 사용자에 대한 정보나 상태를 유지할 필요가 없습니다.

일부 웹 응용 프로그램은 사용자 세션을 관리해야 하므로 상태 또는 서버 측 세션을 구현합니다. 예를 들어 HTTP 쿠키[45] 또는 웹 양식 내의 숨겨진 변수를 사용합니다.

응용 프로그램 사용자 세션을 시작하려면 웹 응용 프로그램 로그인을 통한 대화형 인증을 수행해야 합니다. 사용자 세션을 중지하려면 사용자가 로그아웃 작업을 요청해야 합니다. 이러한 작업은 HTTP 인증이 아니라 사용자 정의 관리 웹 응용프로그램 인증을 사용합니다.

HTTP/1.1 요청 메시지

요청 메시지는 클라이언트가 대상 서버로 보냅니다.[note 4]

구문 요청

클라이언트가 서버에 요청 메시지를 전송합니다.[46] 요청 메시지는 다음과 같습니다. 

얻다 /images/logo.png HTTP/1.1
  • 0개 이상의 요청 헤더 필드(HTTP/1.1의 경우 적어도 1개 이상의 헤더), 각각은 대소문자를 구분하지 않는 필드 이름, 콜론, 선택적 선행 공백, 필드 값, 선택적 후행 공백, 캐리지 리턴 및 라인 피드로 구성됩니다.
호스트: www.example.com 수락 언어: en
  • 객차 반송 및 라인 피드로 구성된 빈 라인;
  • 선택적 메시지 본문

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

RFC 1945의 HTTP/1.0 규격 이전에 HTTP 클라이언트와의 호환성을 유지하기 위해 경로 이름만 포함하는 요청 줄이 서버에 의해 허용됩니다.[47]

요청방법

telnet을 사용하여 이루어진 HTTP/1.1 요청입니다. 요청 메시지, 응답 헤더 섹션 및 응답 본문이 강조 표시됩니다.

HTTP는 식별된 리소스에 대해 수행할 원하는 작업을 나타내는 메서드(때로는 동사라고 하지만 사양에서는 동사에 대해 언급하지 않음)를 정의합니다. 이 리소스가 나타내는 것은 기존 데이터든 동적으로 생성된 데이터든 서버의 구현에 따라 달라집니다. 종종 리소스는 서버에 상주하는 파일 또는 실행 파일의 출력에 해당합니다. HTTP/1.0 사양은[48] GET, HEAD 및 POST 메서드를 정의하고 PUT, DELETE, LINK 및 UNLINK 메서드를 추가 메서드로 나열했습니다. 그러나 HTTP/1.1 규격은[49] 공식적으로 PUT, DELETE, CONNECT, Options, TRACE의 다섯 가지 새로운 방식을 정의하고 추가했습니다. 모든 클라이언트는 모든 방법을 사용할 수 있으며 서버는 모든 방법 조합을 지원하도록 구성할 수 있습니다. 방법을 중간자에게 알 수 없는 경우 안전하지 않고 idempotent가 아닌 방법으로 처리됩니다. 정의할 수 있는 방법의 수에는 제한이 없으며, 이를 통해 기존 인프라를 파괴하지 않고도 향후 방법을 지정할 수 있습니다. 예를 들어 WebDAV는 7개의 새로운 메서드를 정의하고 RFC 5789는 PATCH 메서드를 지정했습니다.

메서드 이름은 대소문자를 구분합니다.[50][51] 이것은 대소문자를 구분하지 않는 HTTP 헤더 필드 이름과 대조적입니다.[52]

얻다
GET 메서드는 대상 리소스에 해당 상태의 표현을 전송하도록 요청합니다. GET 요청은 데이터만 검색해야 하며 다른 효과는 없어야 합니다. (이것은 일부 다른 HTTP 메서드에서도 마찬가지입니다.)[1] 변경하지 않고 리소스를 검색할 경우 URL을 통해 주소를 지정할 수 있으므로 POST보다 GET를 사용하는 것이 좋습니다. 이렇게 하면 북마크 및 공유가 가능하고 GET 응답이 캐싱에 적합하므로 대역폭을 절약할 수 있습니다. W3C는 이러한 구분에 대해 "웹 애플리케이션 설계는 위의 원칙에 의해 알려져야 하지만 관련된 제한 사항에 의해서도 알려져야 한다"는 지침 원칙을 발표했습니다.[53] 아래의 안전한 방법을 참조하십시오.

머리
HEAD 메서드는 GET 요청에 대해 대상 리소스가 해당 상태의 표현을 전송하도록 요청하지만 응답 본문에 포함된 표현 데이터는 전송하지 않습니다. 이는 전체 표현을 전송할 필요 없이 응답 헤더에서 표현 메타데이터를 검색하는 데 유용합니다. 상태 코드를 통해 페이지를 사용할 수 있는지 확인하고 파일 크기를 빠르게 찾는 것이 사용됩니다.Content-Length).

포스트.
POST 메서드는 대상 리소스가 대상 리소스의 의미론에 따라 요청에 포함된 표현을 처리할 것을 요청합니다. 예를 들어, 인터넷 포럼에 메시지를 게시하거나 메일링 목록을 구독하거나 온라인 쇼핑 거래를 완료하는 데 사용됩니다.[54]

놓다
PUT 메서드는 대상 리소스가 요청에 포함된 표현에 의해 정의된 상태로 상태를 만들거나 업데이트할 것을 요청합니다. POST와의 차이점은 클라이언트가 서버의 대상 위치를 지정한다는 것입니다.[55]

삭제
DELETE 메서드는 대상 리소스의 상태를 삭제하도록 요청합니다.

연결하다
CONNECT 메서드는 중개자에게 요청 대상에서 식별된 발신지 서버에 대한 TCP/IP 터널을 설정할 것을 요청합니다. TLS를 사용하는 하나 이상의 HTTP 프록시를 통한 연결을 보안하는 데 자주 사용됩니다.[56][57] HTTP CONNECT method 참조.

옵션들
Options 메서드는 대상 리소스가 지원하는 HTTP 메서드를 전송하도록 요청합니다. 특정 리소스 대신 '*'를 요청하여 웹 서버의 기능을 확인하는 데 사용할 수 있습니다.

추적하다
TRACE 메서드는 대상 리소스가 수신한 요청을 응답 본문에서 전송하도록 요청합니다. 이렇게 하면 클라이언트가 중개인에 의해 변경 또는 추가된 사항을 확인할 수 있습니다.

패치
PATCH 메서드는 요청에 포함된 표현에 정의된 부분 업데이트에 따라 대상 리소스의 상태를 수정할 것을 요청합니다. 이렇게 하면 파일이나 문서를 완전히 전송할 필요 없이 일부를 업데이트하여 대역폭을 절약할 수 있습니다.[58]

모든 범용 웹 서버는 적어도 GET 및 HEAD 방법을 구현해야 하며, 다른 모든 방법은 사양에서 선택 사항으로 간주됩니다.[51]

요청 방법의 속성
요청방법 RFC 요청에 페이로드 바디가 있습니다. 응답에 페이로드 바디가 있습니다. 안전한 멱살잡이 캐시 가능
얻다 RFC 9110 선택적. 네. 네. 네. 네.
머리 RFC 9110 선택적. 아니요. 네. 네. 네.
포스트. RFC 9110 네. 네. 아니요. 아니요. 네.
놓다 RFC 9110 네. 네. 아니요. 네. 아니요.
삭제 RFC 9110 선택적. 네. 아니요. 네. 아니요.
연결하다 RFC 9110 선택적. 네. 아니요. 아니요. 아니요.
옵션들 RFC 9110 선택적. 네. 네. 네. 아니요.
추적하다 RFC 9110 아니요. 네. 네. 네. 아니요.
패치 RFC 5789 네. 네. 아니요. 아니요. 아니요.

안전한 방법

요청 방법은 해당 방법을 사용하는 요청이 서버에 의도된 영향을 미치지 않는 경우 안전합니다. 메소드 GET, HEAD, Options 및 TRACE는 안전하다고 정의됩니다. 즉, 안전한 방법은 읽기 전용입니다. 그러나 로그 파일에 요청 정보를 추가하거나 광고 계정을 청구하는 등의 부작용은 클라이언트가 정의상 요청하지 않기 때문에 배제하지 않습니다.

반면 POST, PUT, DELETE, CONNECT, PATCH 방법은 안전하지 않습니다. 서버 상태를 수정하거나 이메일을 보내는 등의 다른 효과가 있을 수 있습니다. 따라서 이러한 방법은 일반적으로 적합한 웹 로봇이나 웹 크롤러에서는 사용되지 않습니다. 적합하지 않은 일부 방법은 컨텍스트나 결과에 관계없이 요청을 하는 경향이 있습니다.

GET 요청의 규정된 안전성에도 불구하고 실제로 서버에 의한 처리는 기술적으로 제한되지 않습니다. 부주의하거나 의도적으로 불규칙한 프로그래밍으로 인해 GET 요청이 서버에서 사소한 변경 사항이 발생할 수 있습니다. 이는 웹 캐싱, 검색 엔진 및 기타 자동화된 에이전트가 서버에서 의도하지 않은 변경을 수행할 때 발생할 수 있는 문제 때문에 권장되지 않습니다. 예를 들어, 웹 사이트는 임의로 가져온 경우에도 GET를 사용하더라도 단순히 기사를 삭제하는 https://example.com/article/1234/delete, 와 같은 URL을 통해 리소스를 삭제할 수 있습니다. 적절하게 코드화된 웹 사이트는 이 작업에 대해 DELETE 또는 POST 방법이 필요하며, 이 방법은 악의적이지 않은 봇이 만들지 않습니다.

실제로 발생하는 한 가지 예는 사용자가 보고 있는 페이지의 임의의 URL을 미리 불러와 레코드가 자동으로 변경되거나 대량으로 삭제되는 짧은 기간의 Google Web Accelerator 베타입니다. 베타는 광범위한 비판에 따라 첫 출시 후 몇 주 만에 중단되었습니다.[60][59]

멱등법

참고 항목: 아이덴티티 § 컴퓨터 과학의 의미

요청 방법은 해당 방법과 동일한 여러 요청이 단일 요청과 동일한 효과를 갖는 경우 idempotent입니다. PUT 및 DELETE 메서드와 안전한 메서드는 idempotent로 정의됩니다. 안전한 방법은 서버에 아무런 영향을 미치지 않도록 설계되어 있기 때문에 매우 무력합니다. 반면 PUT 및 DELETE 방법은 연속적으로 동일한 요청이 무시되므로 무력합니다. 예를 들어, 웹사이트는 사용자의 기록된 이메일 주소를 수정하기 위해 PUT 엔드포인트를 설정할 수 있습니다. 이 엔드포인트가 올바르게 구성된 경우 사용자의 전자 메일 주소를 이미 기록된 것과 동일한 전자 메일 주소로 변경하도록 요청하는 모든 요청(예: 성공적인 요청 후 중복 요청)은 효과가 없습니다. 마찬가지로 특정 사용자를 삭제하라는 요청은 해당 사용자가 이미 삭제된 경우에는 효과가 없습니다.

반대로 POST, CONNECT 및 PATCH 방법은 반드시 무력한 것은 아니며, 따라서 동일한 POST 요청을 여러 번 보내는 것은 서버의 상태를 더 수정하거나 여러 개의 이메일을 보내는 것과 같은 추가적인 영향을 미칠 수 있습니다. 어떤 경우에는 이것이 원하는 효과이지만 다른 경우에는 실수로 발생할 수 있습니다. 예를 들어, 첫 번째 클릭이 처리되고 있다는 명확한 피드백이 주어지지 않은 경우, 사용자는 버튼을 다시 클릭하여 실수로 여러 번의 POST 요청을 보낼 수 있습니다. 웹 브라우저는 페이지를 다시 로드하는 경우 POST 요청을 다시 제출할 수 있는 경우 사용자에게 경고하기 위해 경고 대화 상자를 표시할 수 있지만 POST 요청을 두 번 이상 제출해서는 안 되는 경우를 처리하는 것은 일반적으로 웹 응용 프로그램에 달려 있습니다.

메소드가 idempotent인지 여부는 프로토콜이나 웹 서버에 의해 시행되지 않습니다. GET 또는 기타 요청에 의해 데이터베이스 삽입 또는 기타 비능률적 작업이 트리거되는 웹 응용 프로그램을 작성하는 것은 완벽하게 가능합니다. 그러나 사용자 에이전트가 동일한 요청을 반복하는 것이 안전하지 않을 때 안전하다고 가정하는 경우 권장 사항을 위반하면 바람직하지 않은 결과가 발생할 수 있습니다.

캐시 가능한 방법

참고 항목: 웹 캐시

요청 방법에 대한 응답이 추후 재사용을 위해 저장될 수 있는 경우 요청 방법은 캐시 가능합니다. GET, HEAD 및 POST 메서드는 캐시 가능한 것으로 정의됩니다.

반면 PUT, DELETE, CONNECT, Options, TRACE 및 PATCH 메서드는 캐시 가능하지 않습니다.

요청 헤더 필드

참고 항목: HTTP 헤더 필드 목록 § Request 필드

요청 헤더 필드를 사용하면 클라이언트가 요청 줄을 넘어 추가 정보를 전달할 수 있으며, 요청 수정자 역할을 수행합니다(프로시저의 매개 변수와 유사). 클라이언트에 대한 정보, 대상 리소스 또는 예상되는 요청 처리에 대한 정보를 제공합니다.

HTTP/1.1 응답 메시지

응답 메시지는 서버가 이전 요청 메시지에 대한 응답으로 클라이언트에 전송됩니다.[note 4]

응답 구문

서버는 클라이언트에 다음과 같은 응답 메시지를 보냅니다.[46]

  • 상태 라인은 프로토콜 버전, 스페이스, 응답 상태 코드, 다른 스페이스, 빈 이유 구문, 캐리지 리턴 및 라인 피드로 구성됩니다. 예를 들어, 다음과 같습니다. 
    HTTP/1.1 200 네 알겠습니다
  • 0개 이상의 응답 헤더 필드(각각 대소문자를 구분하지 않는 필드 이름, 콜론, 선택적 선행 공백, 필드 값, 선택적 후행 공백, 캐리지 리턴 및 라인 피드로 끝납니다. 예: 
    내용-유형: 텍스트/html
  • 객차 반송 및 라인 피드로 구성된 빈 라인;
  • 선택적 메시지 본문

응답상태코드

참고 항목: HTTP 상태 코드 목록

HTTP/1.0 및 그 이후로 HTTP 응답의 첫 번째 줄은 상태 줄이라고 불리며 숫자 상태 코드(예: "404")와 텍스트 이유 구문(예: "Not Found")을 포함합니다. 응답 상태 코드는 클라이언트의 해당 요청을 이해하고 충족시키기 위한 서버의 시도 결과를 나타내는 3자리 정수 코드입니다. 클라이언트가 응답을 처리하는 방법은 주로 상태 코드에 의존하고, 두 번째로 다른 응답 헤더 필드에 의존합니다. 클라이언트는 등록된 모든 상태 코드를 이해할 수는 없지만 클래스(상태 코드의 첫 번째 숫자로 표시됨)를 이해하고 인식되지 않은 상태 코드를 해당 클래스의 x00 상태 코드와 동일한 것으로 취급해야 합니다.

표준 이유 문구는 권장 사항에 불과하며, 웹 개발자의 재량에 따라 "로컬 등가물"로 대체할 수 있습니다. 상태 코드가 문제를 나타내는 경우 사용자 에이전트는 문제의 특성에 대한 추가 정보를 제공하기 위해 사용자에게 이유 구문을 표시할 수 있습니다. 이 표준은 또한 사용자 에이전트가 이유 구문을 해석하려고 시도할 수 있도록 허용하지만, 이는 표준에서 상태 코드가 기계로 읽을 수 있고 이유 구문이 사람이 읽을 수 있다고 명시적으로 지정하기 때문에 현명하지 못할 수 있습니다.

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

1XX (정보제공)
요청이 접수되어 계속 진행 중입니다.
2XX (성공)
요청을 성공적으로 받고 이해하고 수락했습니다.
3XX (리다이렉션)
요청을 완료하려면 추가 조치가 필요합니다.
4XX (클라이언트 오류)
요청에 잘못된 구문이 포함되어 있거나 수행할 수 없습니다.
5XX (서버 오류)
서버가 분명히 유효한 요청을 수행하지 못했습니다.

응답 헤더 필드

참고 항목: HTTP 헤더 필드 목록 § 응답 필드

응답 헤더 필드를 사용하면 서버가 상태 표시줄을 넘어 추가 정보를 전달하여 응답 수정자 역할을 수행할 수 있습니다. 서버에 대한 정보 또는 대상 리소스 또는 관련 리소스에 대한 추가 액세스에 대한 정보를 제공합니다.

각 응답 헤더 필드에는 요청 방법 또는 응답 상태 코드의 의미론에 의해 추가로 정제될 수 있는 정의된 의미가 있습니다.

요청/응답 트랜잭션의 HTTP/1.1 예

아래는 HTTP/1.1 클라이언트와 www.example.com , 포트 80에서 실행되는 HTTP/1.1 서버 간의 HTTP 트랜잭션 예입니다.

의뢰인요청

얻다 / HTTP/1.1 주인: www.example.com 사용자-에이전트: 모질라/5.0 수락: 텍스트/html, 응용프로그램/xhtml+xml, 응용프로그램/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 수락 언어: En-GB,en;q=0.5 수락-인코딩: gzip, 수축, br 연결: alive을 유지하다

클라이언트 요청(이 경우 요청 줄과 몇 개의 헤더로 구성됨) "Host: hostname" header)에 빈 줄이 이어지므로 요청이 줄의 이중 끝으로 끝나며, 각 줄은 캐리지 리턴과 줄 피드의 형태로 나타납니다. 그 "Host: hostname" 헤더 값은 단일 IP 주소를 공유하는 다양한 DNS 이름을 구분하여 이름 기반 가상 호스팅을 가능하게 합니다. HTTP/1.0에서는 옵션이지만 HTTP/1.1에서는 필수입니다. ("/"(슬래시) 파일이 있으면 보통 /index.html 파일을 가져옵니다.)

서버 응답

HTTP/1.1 200 OK Date: 2005년 5월 23일 월요일 22:38:34 GMT Content-Type: text/html; charset=UTF-8 콘텐츠 길이: 155 최종 수정: 2003년 1월 08일 수요일 23:11:55 GMT 서버: Apache/1.3.3.7 (Unix) (Red-Hat/Linux) ETag: "3f80f-1b6-3e1cb03b" 수락 범위: 바이트 연결: 닫기 <html> <head> <title> 예제 페이지</title> </body> <p>안녕하세요, 이것은 매우 간단한 HTML 문서입니다.</p> </body> </html>

ETag(엔티 태그) 헤더 필드는 요청된 리소스의 캐시된 버전이 서버의 리소스의 현재 버전과 동일한지 여부를 결정하는 데 사용됩니다. "Content-Type" HTTP 메시지에 의해 전달되는 데이터의 인터넷 미디어 유형을 지정합니다. "Content-Length" 바이트 단위의 길이를 나타냅니다. HTTP/1.1 웹 서버는 필드를 설정하여 문서의 특정 바이트 범위에 대한 요청에 응답할 수 있는 기능을 게시합니다. "Accept-Ranges: bytes". 이것은 클라이언트가 서버에서 보낸 리소스의 특정 부분만[61] 가지고 있어야 하는 경우에 유용합니다. 이것은 바이트 서빙이라고 합니다. 언제 "Connection: close" 가 전송되면 웹 서버가 이 응답의 전송이 종료된 직후에 TCP 연결을 종료한다는 것을 의미합니다.[21]

대부분의 헤더 라인은 선택 사항이지만 일부는 필수 사항입니다. 머리글을 쓸 때 "Content-Length: number" 엔티티 본체에 대한 응답에 누락된 경우 이는 HTTP/1.0의 오류로 간주되어야 하지만 헤더의 경우 HTTP/1.1의 오류가 아닐 수 있습니다. "Transfer-Encoding: chunked" 와 있습니다. 청크 전송 인코딩은 청크 크기 0을 사용하여 콘텐츠의 끝을 표시합니다. HTTP/1.0의 일부 오래된 구현은 헤더를 생략했습니다. "Content-Length" 응답 초기에 본체 엔티티의 길이를 알 수 없었기 때문에 서버가 소켓을 닫을 때까지 클라이언트로 데이터 전송이 계속되었습니다.

A "Content-Encoding: gzip" 전송된 데이터의 본체 엔티티 부분이 gzip 알고리즘에 의해 압축되었음을 클라이언트에 알리는 데 사용할 수 있습니다.

암호화된 연결

암호화된 HTTP 연결을 설정하는 가장 일반적인 방법은 HTTPS입니다.[62] 암호화된 HTTP 연결을 설정하는 다른 두 가지 방법도 있습니다. 보안 하이퍼텍스트 전송 프로토콜을 사용하고 HTTP/1.1 업그레이드 헤더를 사용하여 TLS에 대한 업그레이드를 지정합니다. 그러나 이 두 가지에 대한 브라우저 지원은 거의 존재하지 않습니다.[63][64][65]

유사 프로토콜

  • 고퍼 프로토콜은 1990년대 초 HTTP에 의해 대체된 콘텐츠 전달 프로토콜입니다.
  • SPDY 프로토콜은 구글에서 개발된 HTTP의 대안으로 HTTP/2로 대체되었습니다.
  • 제미니 프로토콜은 개인 정보 보호 관련 기능을 의무화하는 고퍼에서 영감을 받은 프로토콜입니다.

참고 항목

HTTP
요청방법
머리글 필드
응답상태코드
보안 접근 제어 방법
보안 취약성

메모들

  1. ^ 실제로 이러한 스트림은 동시 요청/응답을 다중화하기 위한 여러 TCP/IP 하위 연결로 사용되므로 서버 측의 실제 TCP/IP 연결 수가 클라이언트당 2.8개에서 1개로 크게 줄어들고 한 번에 더 많은 클라이언트를 서비스할 수 있습니다.
  2. ^ 2022년에 HTTP/0.9 지원은 공식적으로 완전히 사용되지 않으며, 일반적으로 사용하지 않도록 설정하더라도 여전히 많은 웹 서버와 브라우저에 존재합니다(서버 응답 전용). HTTP/0.9를 해제하는 데 얼마나 걸릴지는 불분명합니다.
  3. ^ 1996년 후반부터 일부 인기 있는 HTTP/1.0 브라우저 및 서버 개발자(특히 HTTP/1.1에 대한 지원을 계획한 사람들), 는 요청/응답 쌍 이상 동안 TCP/IP 연결을 열어두고 여러 요청/응답의 교환 속도를 높이기 위해 (비공식 확장으로) 일종의 keep-alive-mechanism(새로운 HTTP 헤더를 사용함)을 배포하기 시작했습니다.[31]
  4. ^ a b HTTP/2 및 HTTP/3은 HTTP 메소드 및 헤더에 대해 상이한 표현을 갖습니다.
  5. ^ HTTP/1.0에는 몇 개의 누락된 헤더를 제외하고는 동일한 메시지가 있습니다.
  6. ^ HTTP/2 및 HTTP/3은 동일한 요청/응답 메커니즘을 사용하지만 HTTP 헤더에 대한 표현은 다릅니다.

참고문헌

  1. ^ a b c d Fielding, R.; Nottingham, M.; Reschke, J. (June 2022). HTTP Semantics. IETF. doi:10.17487/RFC9110. RFC 9110.
  2. ^ a b c d Tim Berner-Lee (1991-01-01). "The Original HTTP as defined in 1991". www.w3.org. World Wide Web Consortium. Retrieved 2010-07-24.
  3. ^ a b Tim Berner-Lee (1992). "Basic HTTP as defined in 1992". www.w3.org. World Wide Web Consortium. Retrieved 2021-10-19.
  4. ^ 1945년 RFC에서. 그런 다음 HTTP/1.1에서 이 사양을 극복했습니다.
  5. ^ RFC 2068(1997)은 1999년 RFC 2616에 의해 폐지되었고, 2014년 RFC 7230에 의해 폐지되었으며, 2022년 RFC 9110에 의해 폐지되었습니다.
  6. ^ "Usage Statistics of Default protocol https for websites". w3techs.com. Retrieved 2024-01-05.
  7. ^ "Usage Statistics of HTTP/2 for websites". w3techs.com. Retrieved 2024-01-05.
  8. ^ "Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. Retrieved 2024-01-05.
  9. ^ Friedl, S.; Popov, A.; Langley, A.; Stephan, E. (July 2014). Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension. IETF. doi:10.17487/RFC7301. RFC 7301.
  10. ^ Belshe, M.; Peon, R.; Thomson, M. "Hypertext Transfer Protocol Version 2, Use of TLS Features". Archived from the original on 2013-07-15. Retrieved 2015-02-10.
  11. ^ Benjamin, David. Using TLS 1.3 with HTTP/2. doi:10.17487/RFC8740. RFC 8740. Retrieved 2020-06-02. This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2.
  12. ^ HTTP/3. 6 June 2022. doi:10.17487/RFC9114. RFC 9114. Retrieved 2022-06-06.
  13. ^ "Usage Statistics of HTTP/3 for websites". w3techs.com. Retrieved 2024-01-08.
  14. ^ "Can I use... Support tables for HTML5, CSS3, etc". canIuse.com. Retrieved 2024-01-08.
  15. ^ Cimpanu, Catalin (26 September 2019). "Cloudflare, Google Chrome, and Firefox add HTTP/3 support". ZDNet. Retrieved 27 September 2019.
  16. ^ "HTTP/3: the past, the present, and the future". The Cloudflare Blog. 2019-09-26. Retrieved 2019-10-30.
  17. ^ "Firefox Nightly supports HTTP 3 – General – Cloudflare Community". 2019-11-19. Retrieved 2020-01-23.
  18. ^ "HTTP/3 is Fast". Request Metrics. Retrieved 2022-07-01.
  19. ^ a b c "Connections, Clients, and Servers". RFC 9110, HTTP Semantics. sec. 3.3. doi:10.17487/RFC9110. RFC 9110.
  20. ^ "Overall Operation". RFC 1945. pp. 6–8. sec. 1.3. doi:10.17487/RFC1945. RFC 1945.
  21. ^ a b c "Connection Management: Establishment". RFC 9112, HTTP/1.1. sec. 9.1. doi:10.17487/RFC9112. RFC 9112.
  22. ^ "Connection Management: Persistence". RFC 9112, HTTP/1.1. sec. 9.3. doi:10.17487/RFC9112. RFC 9112.
  23. ^ "Classic HTTP Documents". W3.org. 1998-05-14. Retrieved 2010-08-01.
  24. ^ "HTTP/2 Protocol Overview". RFC 9113, HTTP/2). sec. 2. doi:10.17487/RFC7540. RFC 7540.
  25. ^ "Invention Of The Web, Web History, Who Invented the Web, Tim Berners-Lee, Robert Cailliau, CERN, First Web Server". LivingInternet. Retrieved 2021-08-11.
  26. ^ Berners-Lee, Tim (1990-10-02). "daemon.c - TCP/IP based server for HyperText". www.w3.org. Retrieved 2021-08-11.
  27. ^ Berners-Lee, Tim. "HyperText Transfer Protocol". World Wide Web Consortium. Retrieved 31 August 2010.
  28. ^ Raggett, Dave. "Dave Raggett's Bio". World Wide Web Consortium. Retrieved 11 June 2010.
  29. ^ Raggett, Dave; Berners-Lee, Tim. "Hypertext Transfer Protocol Working Group". World Wide Web Consortium. Retrieved 29 September 2010.
  30. ^ Raggett, Dave. "HTTP WG Plans". World Wide Web Consortium. Retrieved 29 September 2010.
  31. ^ a b David Gourley; Brian Totty; Marjorie Sayer; Anshu Aggarwal; Sailu Reddy (2002). HTTP: The Definitive Guide. (excerpt of chapter: "Persistent Connections"). O'Reilly Media, inc. ISBN 9781565925090. Retrieved 2021-10-18.
  32. ^ "HTTP/1.1". Webcom.com Glossary entry. Archived from the original on 2001-11-21. Retrieved 2009-05-29.
  33. ^ "HTTP-NG Working Group". www.w3.org. World Wide Web Consortium. 1997. Retrieved 2021-10-19.
  34. ^ Web Administrator (2007). "HTTP Working Group". httpwg.org. IETF. Retrieved 2021-10-19.
  35. ^ a b Web Administrator (2007). "HTTP Working Group: charter httpbis". datatracker.ietf.org. IETF. Retrieved 2021-10-19.
  36. ^ "SPDY: An experimental protocol for a faster web". dev.chromium.org. Google. 2009-11-01. Retrieved 2021-10-19.
  37. ^ "Rechartering httpbis". IETF; HTTP WG. 2012-01-24. Retrieved 2021-10-19.
  38. ^ IESG Secretary (2012-03-19). "WG Action: RECHARTER: Hypertext Transfer Protocol Bis (httpbis)". IETF; HTTP WG. Retrieved 2021-10-19.
  39. ^ Ilya Grigorik; Surma (2019-09-03). "High Performance Browser Networking: Introduction to HTTP/2". developers.google.com. Google Inc. Retrieved 2021-10-19.
  40. ^ "Appendix-A: HTTP Version History". RFC 7230, HTTP/1.1: Message Syntax and Routing. p. 78. sec. A. doi:10.17487/RFC7230. RFC 7230.
  41. ^ Matt Menke (2016-06-30). "Intent to Deprecate and Remove: HTTP/0.9 Support". groups.google.com. Retrieved 2021-10-15.
  42. ^ HTTP/3. 6 June 2022. doi:10.17487/RFC9114. RFC 9114. Retrieved 2022-06-06.
  43. ^ "http URI Scheme". RFC 9110, HTTP Semantics. sec. 4.2.1. doi:10.17487/RFC9110. RFC 9110.
  44. ^ "https URI Scheme". RFC 9110, HTTP Semantics. sec. 4.2.2. doi:10.17487/RFC9110. RFC 9110.
  45. ^ Lee, Wei-Bin; Chen, Hsing-Bai; Chang, Shun-Shyan; Chen, Tzung-Her (2019-01-25). "Secure and efficient protection for HTTP cookies with self-verification". International Journal of Communication Systems. 32 (2): e3857. doi:10.1002/dac.3857. S2CID 59524143.
  46. ^ a b "Message format". RFC 9112: HTTP/1.1. sec. 2.1. doi:10.17487/RFC9112. RFC 9112.
  47. ^ 090502 apacheweek.com
  48. ^ Berners-Lee, Tim; Fielding, Roy T.; Nielsen, Henrik Frystyk. "Method Definitions". Hypertext Transfer Protocol – HTTP/1.0. IETF. pp. 30–32. sec. 8. doi:10.17487/RFC1945. RFC 1945.
  49. ^ "Method Definitions". RFC 2616. pp. 51–57. sec. 9. doi:10.17487/RFC2616. RFC 2616.
  50. ^ "Request Line". RFC 9112, HTTP/1.1. sec. 3. doi:10.17487/RFC9112. RFC 9112.
  51. ^ a b "Methods: Overview". RFC 9110, HTTP Semantics. sec. 9.1. doi:10.17487/RFC9110. RFC 9110.
  52. ^ "Header Fields". RFC 9110, HTTP Semantics. sec. 6.3. doi:10.17487/RFC9110. RFC 9110.
  53. ^ Jacobs, Ian (2004). "URIs, Addressability, and the use of HTTP GET and POST". Technical Architecture Group finding. W3C. Retrieved 26 September 2010.
  54. ^ "POST". RFC 9110, HTTP Semantics. sec. 9.3.3. doi:10.17487/RFC9110. RFC 9110.
  55. ^ "PUT". RFC 9110, HTTP Semantics. sec. 9.3.4. doi:10.17487/RFC9110. RFC 9110.
  56. ^ "CONNECT". RFC 9110, HTTP Semantics. sec. 9.3.6. doi:10.17487/RFC9110. RFC 9110.
  57. ^ "Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections". US-CERT. 2002-05-17. Retrieved 2007-05-10.
  58. ^ Dusseault, Lisa; Snell, James M. (March 2010). PATCH Method for HTTP. IETF. doi:10.17487/RFC5789. RFC 5789.
  59. ^ a b Ediger, Brad (2007-12-21). Advanced Rails: Building Industrial-Strength Web Apps in Record Time. O'Reilly Media, Inc. p. 188. ISBN 978-0596519728. A common mistake is to use GET for an action that updates a resource. [...] This problem came into the Rails public eye in 2005, when the Google Web Accelerator was released.
  60. ^ Cantrell, Christian (2005-06-01). "What Have We Learned From the Google Web Accelerator?". Adobe Blogs. Adobe. Archived from the original on 2017-08-19. Retrieved 2018-11-19.
  61. ^ Luotonen, Ari; Franks, John (February 22, 1996). Byte Range Retrieval Extension to HTTP. IETF. I-D draft-ietf-http-range-retrieval-00.
  62. ^ Canavan, John (2001). Fundamentals of Networking Security. Norwood, MA: Artech House. pp. 82–83. ISBN 9781580531764.
  63. ^ Zalewski, Michal. "Browser Security Handbook". Retrieved 30 April 2015.
  64. ^ "Chromium Issue 4527: implement RFC 2817: Upgrading to TLS Within HTTP/1.1". Retrieved 30 April 2015.
  65. ^ "Mozilla Bug 276813 – [RFE] Support RFC 2817 / TLS Upgrade for HTTP 1.1". Retrieved 30 April 2015.
  66. ^ Nottingham, Mark (October 2010). Web Linking. IETF. doi:10.17487/RFC5988. RFC 5988.

외부 링크

Wikibooks에는 다음과 같은 주제의 책이 있습니다: Communication Networks/HTTP Protocol
위키미디어 커먼즈에는 하이퍼텍스트 전송 프로토콜과 관련된 미디어가 있습니다.