Page protected with pending changes

하이퍼텍스트 전송 프로토콜

Hypertext Transfer Protocol
하이퍼텍스트 전송 프로토콜
HTTP logo.svg
국제 표준
  • RFC1945 HTTP/1.0 (1996)
  • RFC 2068 HTTP/1.1 (1997)
  • RFC 2616 HTTP/1.1(1999)
  • RFC 7230 HTTP/1.1: 메시지 구문 및 라우팅 (2014)
  • RFC 7231 HTTP/1.1: 의미론과 콘텐츠 (2014)
  • RFC 7232 HTTP/1.1: 조건부 요구(2014)
  • RFC 7233 HTTP/1.1: 범위 요구(2014)
  • RFC 7234 HTTP/1.1: 캐싱 (2014)
  • RFC 7235 HTTP/1.1: 인증(2014)
  • RFC 7540 HTTP/2 (2015)
  • RFC 7541 HTTP/2: HPACK 헤더 압축 (2015)
  • RFC 8164 HTTP/2: HTTP/2의 기회주의적 보안 (2017)
  • RFC 8336 HTTP/2: 오리진 HTTP/2 프레임 (2018)
  • RFC 8441 HTTP/2: HTTP/2에 의한 WebSockets 부트스트래핑 (2018)
  • RFC 8740 HTTP/2: HTTP/2에서의 TLS 1.3 사용(2020)
  • RFC 9114 HTTP/3
개발자초기 CERN, IETF, W3C
소개했다1991년; 31년 전(1991년)
웹 사이트https://httpwg.org/specs/

HTTP(Hypertext Transfer Protocol)는 분산형 협업 하이퍼미디어 정보 [1]시스템을 위한 인터넷 프로토콜 스위트 모델의 응용 프로그램 계층 프로토콜입니다.HTTP는 World Wide Web의 데이터 통신 기반입니다.여기서 하이퍼텍스트 문서에는 사용자가 쉽게 접근할 수 있는 다른 리소스로의 하이퍼링크가 포함되어 있습니다.예를 들어 마우스를 클릭하거나 웹 브라우저에서 화면을 탭하는 것입니다.

HTTP의 개발은 1989년 CERN에서 Tim Berners-Lee에 의해 시작되었으며 0.[2]9라는 이름의 첫 번째 HTTP 프로토콜 버전을 사용하는 클라이언트와 서버의 동작을 설명하는 간단한 문서로 요약되어 있습니다.

HTTP/3는 2022년에 발표된 최신 버전의 프로토콜로, 표준화에 앞서 25%의 웹사이트에서 이미 사용되고 있습니다.HTTP/3 는, 서버상에서 유효하게 되어 있는 경우, HTTP/2 보다 고속으로, HTTP/1.1 보다 고속으로 로딩되는 경우가 있습니다.경우에 따라서는 HTTP/1.1 보다 3배 이상 고속으로(아직도 [3]유효하게 되어 있습니다).그 이유 중 하나는 (TCP/IP의) TCP가 이전 표준과 같이 더 이상 사용되지 않기 때문입니다.

이 HTTP 프로토콜의 첫 번째 버전은 곧 더 정교한 버전으로 진화했고, 이는 먼 미래의 버전 1.0을 [4]향한 첫 번째 초안이었다.

초기 HTTP Requests for Comments(RFC; 코멘트 요구)의 개발은 몇 년 후 시작되었으며, Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)와 World Wide Web Consortium(W3C; 월드 와이드 웹 컨소시엄)이 공동으로 실시하여 나중에 IETF로 작업을 옮겼습니다.

HTTP/1은 1996년에 [5]완성되어 완전히 문서화되어 있습니다(버전 1.0).1997년에 (버전 1.1로) 진화하여 1999년과 [6]2014년에 사양이 업데이트되었습니다.

HTTPS라는 이름의 보안 변종은 79% 이상의 [7]웹사이트에서 사용되고 있습니다.

HTTP의 의미의 HTTP/2 좀 더 효율적으로 표현"는 그 줄에서"고 2015년에 발표되었다;websites,[8]지금 전송 계층 보안(TLS)의 거의 모든 웹 브라우저(사용자의 96%)[9]과 주요 인터넷 서버가 Application-Layer 의정서 협상이 TLS1.2또는 최신은(ALPN)extension[10]를 사용하여 지원되는 이상의 46%에 의해 사용하였습니다. 필수의.[11][12]

HTTP/3[13]2022년에 공개된 HTTP/2의 후속 버전입니다.[14] 웹사이트의 25%에서 사용되고 있으며 현재 많은 웹 브라우저(사용자 [15]73%)에서 지원됩니다.HTTP/3는 기본 전송 프로토콜에 TCP 대신 QUIC를 사용합니다.HTTP/2와 마찬가지로 이전 버전의 프로토콜은 사용되지 않습니다.HTTP/3에 대한 지원이 Cloudflare 및 Google Chrome에 [16][17]처음 추가되었으며 Firefox에서도 사용할 수 있습니다.[18]

기술 개요

HTTP 스킴과 WWW 도메인 이름 라벨로 시작하는 URL

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

웹 브라우저는 User Agent(UA; 사용자 에이전트)의 예입니다.다른 유형의 사용자 에이전트에는 검색 공급자( 크롤러), 음성 브라우저, 모바일 앱 및 웹 컨텐츠에 액세스, 사용 또는 표시하는 기타 소프트웨어가 있습니다.

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

중간 HTTP 노드(프록시 서버, 웹 캐시 등)가 그 기능을 실행할 수 있도록 하기 위해 일부 HTTP 헤더는 홉 바이 홉으로 관리되며 다른 HTTP 헤더는 엔드 투 엔드로 관리됩니다(송신원 클라이언트 및 타깃 웹 서버에 의해서만 관리됩니다).

HTTP인터넷 프로토콜 모음의 프레임워크 내에서 설계된 응용 프로그램 계층 프로토콜입니다.그 정의는 기초가 되는 신뢰할 수 있는 전송 계층 프로토콜을 [19]전제로 하고, 따라서 Transmission Control Protocol (TCP)이 일반적으로 사용됩니다.그러나 HTTP는 HTTPUSSDP(Simple Service Discovery Protocol) 등 신뢰할 수 없는 프로토콜을 사용하도록 조정할 수 있습니다.

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

HTTP/1.0 에서는, 자원 [20]요구 마다 같은 서버에의 개별의 접속이 확립됩니다.

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

따라서, TCP 접속의 확립에 의해서, 특히 트래픽의 높은 [23]조건하에서, 상당한 오버헤드가 발생하기 때문에, HTTP/1.1 통신의 지연은 줄어듭니다.

HTTP/2는 동일한 클라이언트-서버 모델과 동일한 프로토콜 방식을 유지하기 위해 이전 HTTP/1.1의 리비전입니다.단, 다음과 같은 차이가 있습니다.

  • 텍스트 대신 메타데이터의 압축 바이너리 표현(HTTP 헤더)을 사용하여 헤더에 필요한 공간을 대폭 줄입니다.
  • 2~8개의 TCP/IP 접속 대신 접근한 서버 도메인별로 1개의 TCP/IP 접속(통상은 암호화)을 사용한다.
  • TCP/IP 접속마다 1개 또는 여러 개의 양방향 스트림을 사용하여 HTTP 요구와 응답이 분할되어 작은 패킷으로 전송되어 HOLB(회선 블로킹의 선두)의 문제를 거의 해결합니다.[note 1]
  • (폴링 [24]방법을 사용하여 클라이언트가 정기적으로 서버에 새로운 데이터를 요구하도록 강요하지 않고) 새로운 데이터를 사용할 수 있는 경우 서버 응용 프로그램이 클라이언트에 데이터를 전송할 수 있도록 푸시 기능을 추가합니다.

따라서 HTTP/2 통신은 HTTP/1.1 통신보다 지연이 훨씬 적고 대부분의 경우 속도가 훨씬 빨라집니다.

HTTP/3는 TCP/IP 접속 대신 QUIC + UDP 트랜스포트 프로토콜을 사용하여 통신의 평균 속도를 약간 향상시키고 TCP/IP 접속의 congestion가 일시적으로 모든 스트림의 데이터 흐름을 차단하거나 느리게 하는 (매우 드문) 문제를 피하기 위한 이전 HTTP/2의 개정판입니다.회선 블로킹의 ead).

역사

하이퍼텍스트라는 용어는 1965년 테드 넬슨에 의해 Xanadu Project에서 만들어졌으며, 이는 1945년 그의 에세이 "As We May Think"에서 기술된 마이크로필름 기반의 정보 검색 및 관리 "메멕스" 시스템에 대한 Vannevar Bush의 1930년대 비전에서 영감을 얻었다.CERN의 Tim Berners-Lee와 그의 팀은 웹 서버 및 웹 브라우저라고 불리는 클라이언트 사용자 인터페이스를 위한 HTML 및 관련 기술과 함께 원본 HTTP를 개발한 것으로 인정받고 있습니다.Berners-Lee는 그의 또 다른 아이디어인 "WorldWideWeb" 프로젝트의 채택을 돕기 위해 HTTP를 설계했다. 이 프로젝트는 1989년에 처음 제안되었고, 지금은 월드와이드웹으로 알려져 있다.

최초의 웹 서버[25][26]1990년에 가동되었습니다.사용된 프로토콜은 [27]서버에 페이지를 요청하는 GET이라는 한 가지 메서드만 있었습니다.서버로부터의 응답은 항상 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워드 미만의 일반 문서로 작성되었으며, 이 버전은 HTTP/0.9로 명명되었습니다.HTTP/0.9는 GET 메서드만 지원하므로 클라이언트는 서버에서HTML 문서만 가져올 수 있으며 다른 파일 형식이나 정보 [2]업로드를 지원하지 않습니다.
HTTP/1.0 드래프트
1992년 이후, 새로운 문서는 다음 정식 버전을 향한 기본 프로토콜의 진화를 명시하기 위해 작성되었다.0.9 버전의 단순한 요청 방식과 클라이언트 HTTP 버전을 포함하는 완전한 GET 요청을 모두 지원했습니다.이것은 HTTP/1.[4]0에 관한 최종 작업에 앞서 비공식적인 HTTP/1.0 초안 중 첫 번째 초안입니다.
W3C HTTP 작업 그룹
HTTP 프로토콜의 새로운 기능이 요구되고 그것들이 공식 RFC로 완전히 문서화되어야 한다고 결정한 후, 1995년 초에 확장된 운영, 확장된 협상, 풍부한 메타 정보로 프로토콜을 표준화하고 확장하기 위한 목적으로 HTTP 작업 그룹(Dave Raggett이 이끄는 HTTP WG)이 구성되었다.추가 메서드와 헤더 [28][29]필드를 추가하여 보다 효율적인 보안 프로토콜입니다.
HTTP WG는 1995년 안에 HTTP/1.0 및 HTTP/1.1로 프로토콜의 새로운 버전을 수정하고 게시할 계획이었지만, 많은 수정사항으로 인해 그 타임라인은 1년 [30]이상 지속되었다.
HTTP WG는 또한 HTTP-NG(HTTP Next Generation)라고 불리는 먼 미래 버전의 HTTP를 지정할 계획이었지만, 이 작업은 불과 몇 년 후에 시작되어 완료되지 않았습니다.
HTTP/1.0
1996년 5월 RFC 1945는 이전 4년 동안 이미 많은 웹 브라우저와 웹 서버에서 사용되고 있는 선행 표준 HTTP/1.0 초안으로서 사용된 것을 최종 HTTP/1.0 개정판으로 발행되었습니다.
1996년 초에 개발자들은 HTTP/1.0 프로토콜(킵얼라이브 연결 등)의 비공식 확장을 제품에 포함시키기 시작했습니다. 이는 곧 출시될 HTTP/1.1 [31]규격의 초안을 사용했기 때문입니다.
HTTP/1.1
1996년 초부터 주요 웹 브라우저와 웹 서버 개발자들도 선행 표준 HTTP/1.1 드래프트 사양에 의해 지정된 새로운 기능을 구현하기 시작했습니다.최종 사용자는 새로운 버전의 브라우저와 서버를 빠르게 도입할 수 있었습니다.1996년 3월, 한 웹 호스팅 회사는 인터넷에서 사용 중인 브라우저의 40% 이상이 새로운 HTTP/1.1 헤더 "Host"를 사용하여 가상 호스팅을 활성화했다고 보고했습니다.같은 웹 호스팅 회사에서는 1996년 6월까지 서버에 액세스하는 모든 브라우저의 65%가 선행 표준 HTTP/1.1에 [32]준거하고 있다고 보고했습니다.
1997년 1월에 RFC 2068HTTP/1.1 사양으로 정식 릴리스되었습니다.
1999년 6월에 RFC 2616이 출시되어 이전의 (구식) HTTP/1.1 사양에 근거한 모든 개선과 갱신이 포함되어 있습니다.
W3C HTTP-NG 작업 그룹
이전 HTTP Working Group의 1995년 계획을 재개하여 1997년에 HTTP-NG(HTTP New Generation)라는 새로운 HTTP 프로토콜을 개발하기 위해 HTTP-NG Working Group이 결성되었습니다.새로운 프로토콜이 단일 TCP/IP 연결 내에서 HTTP 트랜잭션의 다중화를 사용하기 위해 몇 가지 제안/초안이 작성되었지만, 1999년에 이 그룹은 기술적 문제를 IETF에 [33]전달하는 활동을 중단했다.
IETF HTTP 작업 그룹이 재시작됨
2007년에 IETF HTTP 작업 그룹(HTTP WG bis 또는 HTTPbis)이 최초로 재기동되어 이전의 HTTP/1.1 사양을 수정 및 명확하게 하고, 다음으로 장래의 HTTP/2 사양(httpbis [34]라고 하는 명칭)을 기술 및 개량했습니다.

[35]

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: 인증
SPDY: 구글이 개발한 비공식 HTTP 프로토콜
2009년, 민간 회사인 구글은 SPDY라는 이름의 새로운 HTTP 바이너리 프로토콜을 개발하고 테스트했다고 발표했다.암묵적인 목적은 (특히 미래의 웹 브라우저와 그 서버 간의) 웹 트래픽 속도를 높이는 것이었습니다.
SPDY는 실제로 많은 테스트에서 HTTP/1.1보다 훨씬 빨랐기 때문에 Chromium과 다른 주요 웹 [36]브라우저에 의해 빠르게 채택되었다.
단일 TCP/IP 접속을 통한 HTTP 스트림 다중화에 대한 아이디어 중 일부는 W3C HTTP-NG Working Group의 작업을 포함하여 다양한 소스에서 가져온 것입니다.
HTTP/2
2012년 1월부터 3월까지 HTTP 워킹 그룹(HTTPbis)은 SPDY에 [37][38]대한 아이디어와 작업을 고려하여 (HTTP/1.1 사양 개정을 완료하면서) 새로운 HTTP/2 프로토콜에 초점을 맞출 필요성을 발표했습니다.
새로운 버전의 HTTP를 개발하기 위해 무엇을 해야 하는지에 대해 몇 달 후에 SPDY에서 [39]파생하기로 결정했습니다.
2015년 5월 HTTP/2는 RFC 7540으로 발행되어 이미 SPDY를 지원하는 모든 웹 브라우저에서 빠르게 채택되었으며 웹 서버에서는 더 느리게 채택되었습니다.
HTTP/0.9 폐지
RFC 7230 부록 A에서는 HTTP/1.1 버전([40]이후)을 지원하는 서버에서는 HTTP/0.9가 권장되지 않습니다.

HTTP/0.9는 요청의 헤더필드를 지원하지 않기 때문에 이름 기반의 가상 호스트를 지원하는 메커니즘은 없습니다(Host 헤더필드의 인스펙션에 의한 자원 선택).이름 베이스의 가상 호스트를 실장하는 서버는, HTTP/0.9 서포트를 무효로 할 필요가 있습니다.HTTP/0.9로 보이는 대부분의 요구는 클라이언트가 request-target을 올바르게 부호화하지 못했기 때문에 실제로는 잘못 구성된HTTP/1.x 요구입니다.

2016년 이후 많은 사용자 에이전트(브라우저 등) 및 웹 서버 제품 관리자 및 개발자들이 다음과 [41]같은 이유로 HTTP/0.9 프로토콜 지원을 점차 폐지 및 해제할 계획을 세우고 있습니다.
  • 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년 6월에 RFC 일괄이 발행되어 이전 문서의 많은 부분을 폐지하고 몇 가지 사소한 변경과 HTTP 시멘틱스 기술 리팩터링을 별도의 문서로 도입했습니다.

HTTP 데이터 교환

HTTP는 상태 비저장 응용 프로그램 수준 프로토콜이며 클라이언트와 [43]서버 간에 데이터를 교환하려면 신뢰할 수 있는 네트워크 전송 연결이 필요합니다.HTTP 실장에서는, TCP/IP 접속은 기존의 포토를 사용해 사용됩니다(통상은, 접속이 암호화되어 있지 않은 경우는 포토 80,[44][45] 또는 접속이 암호화되어 있는 경우는 포토 443 를 참조해 주세요).HTTP/2에서는 TCP/IP 연결과 여러 프로토콜 채널이 사용됩니다.HTTP/3에서는 응용 프로그램 전송 프로토콜 QUIC over UDP가 사용됩니다.

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

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

영속적인 접속

HTTP/0.9 에서는, TCP/IP 접속은 서버 응답이 송신된 후에 항상 닫히기 때문에, 영속적인 것은 아닙니다.

HTTP/1.0 에서는, RFC 1945 에 기재되어 있듯이, 응답이 송신된 후에, TCP/IP 접속은 항상 서버에 의해서 닫힐 필요가 있습니다.[note 3]

HTTP/1.1 에서는, 복수의 요구/응답에 접속을 재사용할 수 있도록, 킵 얼라이브 메카니즘이 정식으로 도입되었습니다.클라이언트는 첫 번째 요구가 송신된 후 TCP 3-Way-Handshake 접속을 재네고시에이트할 필요가 없기 때문에 이러한 영속적인 접속에 의해 요구 지연이 현저하게 감소합니다.또 다른 긍정적인 부작용은 일반적으로 TCP의 느린 시작 메커니즘으로 인해 시간이 지남에 따라 접속 속도가 빨라진다는 것입니다.

HTTP/1.1에서는 클라이언트가 각 응답을 대기하기 전에 여러 요청을 전송할 수 있도록 함으로써 영속적인 연결을 사용할 때 지연 시간을 더욱 단축하기 위해 HTTP 파이프라인도 추가되었습니다.클라이언트와 서버 사이의 인터넷/인트라넷에 배치된 소수의 웹 서버 및 많은 프록시 서버(특히 투과 프록시 서버)가 파이프라인 요구를 제대로 처리하지 않았기 때문에 이 최적화는 실제로 안전하다고 여겨지지 않았습니다(다른 요구는 폐기하고 첫 번째 요구만 처리했으며 더 많은 것을 발견했기 때문에 연결을 닫았습니다.첫 번째 요청 후 데이터 또는 일부 프록시가 잘못된 응답을 반환하는 등).또한 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:
  • 캐시된 자원의 조건부 취득을 보다 효율적으로 관리하기 위해 새로운 헤더를 사용합니다.
  • 청크 전송 부호화를 사용하면, 서버가 그 길이를 사전에 알 수 없는 경우(즉, 동적으로 생성되기 때문에)에도, 컨텐츠를 청크로 스트리밍 할 수 있습니다.
  • 바이트 범위 서비스: 클라이언트가 자원의 1개 또는 복수의 부분(즉, 콘텐츠 전체의 중간 또는 끝에 있는 부분 등)만을 요구할 수 있으며 서버는 통상적으로 요청된 부분만을 송신합니다.이는 시간, 대역폭 및 시스템 리소스 등을 확보하기 위해 브라우저에 의해 콘텐츠의 일부만 표시되거나 이미 볼 수 있는 부분에 동적으로 추가되어야 하는 경우(즉, 웹 페이지의 첫 번째 또는 다음 n개의 댓글만) 중단된 다운로드를 재개하는 데 유용합니다.
HTTP/2, HTTP/3
HTTP/2 와 HTTP/3 는, 상기의 HTTP/1.1 의 기능을 유지하고 있습니다.

HTTP 인증

HTTP는 기본 액세스 인증 다이제스트액세스 인증 의 여러 인증 방식을 제공합니다.이 인증 방식은 서버가 요청된 콘텐츠를 제공하기 전에 챌린지를 식별하여 발행하는 챌린지-리스폰스 메커니즘에 의해 동작합니다.

HTTP는 확장 가능한 일련의 챌린지/리스폰스 인증 방식을 통해 접근컨트롤과 인증을 위한 일반적인 프레임워크를 제공합니다.이러한 프레임워크는 서버에서 클라이언트 요구에 대한 챌린지 및 클라이언트가 인증 [46]정보를 제공하기 위해 사용할 수 있습니다.

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

인증 영역

HTTP 인증 사양은 특정 루트 URI에 공통되는 리소스를 추가로 분할하기 위한 임의의 구현 고유의 구성도 제공합니다.레름 값 문자열이 있는 경우 표준 루트 URI와 결합되어 챌린지의 보호 공간 구성 요소를 형성합니다.이를 통해 서버는 1개의 루트 [46]URI 아래에 별도의 인증 범위를 정의할 수 있습니다.

HTTP 응용 프로그램세션

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

일부 웹 응용 프로그램에서는 사용자 세션을 관리해야 하므로 HTTP 쿠키나 양식 내의 숨겨진 변수 등을 사용하여 상태 또는[47] 서버 세션을 구현합니다.

응용 프로그램 사용자 세션을 시작하려면 웹 응용 프로그램 로그인을 통한 대화형 인증을 수행해야 합니다.사용자 세션을 중지하려면 사용자가 로그아웃 작업을 요청해야 합니다.이러한 조작에서는 HTTP 인증이 아닌 커스텀 관리 대상 Web 애플리케이션 [46]인증을 사용합니다.

HTTP/1.1 요구 메시지

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

요청 구문

클라이언트는 [48]다음 내용으로 구성된 요청 메시지를 서버로 보냅니다.

  • 대소문자를 구분하는 요청 방식, 공백, 요청된 URL, 다른 공간, 프로토콜 버전, 캐리지 리턴 및 줄 바꿈으로 구성된 요청 줄. 예:
GET / images / logo . png HTTP / 1.1
  • 0개 이상의 요구 헤더필드(HTTP/1.1의 경우 적어도1개 이상의 헤더).각 필드는 대소문자를 구분하지 않는 필드명, 콜론, 옵션의 선행 공백, 필드값, 옵션의 후행 공백으로 구성되어 캐리지 리턴과 줄바꿈으로 끝납니다.예를 들어, 다음과 같습니다.
호스트: www.example.com Accept-Language: en
  • 캐리지 리턴 및 라인 피드로 구성된 빈 라인
  • 옵션 메시지 본문

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

RFC [49]1945의 HTTP/1.0 사양 이전에 HTTP 클라이언트와의 호환성을 유지하기 위해 패스명만을 포함한 요구 행이 서버에 의해 받아들여집니다.

요구 방식

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

HTTP는 식별된 리소스에 대해 수행할 작업을 나타내는 메서드(동사라고도 하지만 사양에서는 동사를 언급하지 않음)를 정의합니다.기존 데이터든 동적으로 생성되는 데이터든 이 리소스가 나타내는 것은 서버의 구현에 따라 달라집니다.대부분의 경우 리소스는 서버에 있는 파일 또는 실행 파일의 출력에 해당합니다.HTTP/1.0 사양에서는[50] GET, HEAD 및 POST 방식이 정의되었으며 HTTP/1.1 사양에서는[51] PUT, DELETE, CONNECT, OPTIONS 및 TRACE의 5가지 새로운 방식이 추가되었습니다.클라이언트는 임의의 메서드를 사용할 수 있으며 서버는 임의의 메서드의 조합을 지원하도록 구성할 수 있습니다.메서드가 중간에서 불분명한 경우 안전하지 않고 유휴하지 않은 메서드로 취급됩니다.정의할 수 있는 메서드의 수에 제한이 없기 때문에 기존 인프라스트럭처를 중단하지 않고 향후 메서드를 지정할 수 있습니다.예를 들어 WebDAV는 7개의 새로운 방법을 정의하고 RFC 5789는 PATCH 방식을 지정하고 있습니다.

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

얻다
GET 메서드는 타깃리소스가 상태 표현을 전송하도록 요구합니다.GET 요청은 데이터만 가져오고 다른 영향은 없습니다(이것은 다른 HTTP 메서드에도 해당됩니다).[1]변경하지 않고 리소스를 취득할 경우 URL을 통해 주소를 지정할 수 있으므로 POST보다 GET이 우선됩니다.이것에 의해 북마크와 공유가 네이블이 되어, GET 응답이 캐시에 적합하게 되어, 대역폭을 절약할 수 있습니다.W3C는 이 구별에 대한 지침 원칙을 발표하면서 "웹 애플리케이션 설계는 위의 원칙뿐만 아니라 관련 [55]제한 사항으로도 통지되어야 한다"고 말했다.아래의 안전한 방법을 참조하십시오.
머리
HEAD 메서드는 대상 리소스가 GET 요청과 같이 상태 표현을 전송하도록 요구하지만 응답 본문에 포함된 표현 데이터는 전송하지 않습니다.이는 전체 표현을 전송할 필요 없이 응답 헤더에서 표현 메타데이터를 검색할 때 유용합니다.상태 코드를 통해 페이지를 사용할 수 있는지 여부를 확인하고 파일 크기를 빠르게 찾는 등의 용도로 사용됩니다(Content-Length).
포스트.
POST 메서드는 타깃리소스가 요구에 포함된 표현을 타깃리소스의 의미에 따라 처리하도록 요구합니다.예를 들어 인터넷 포럼에 메시지를 게시하거나 메일 목록을 구독하거나 온라인 쇼핑 [56]트랜잭션을 완료하는 데 사용됩니다.
놓다
PUT 메서드는 타깃리소스가 요구에 포함된 표현에 의해 정의된 상태로 상태를 작성하거나 갱신하도록 요구합니다.POST 와의 차이점은,[57] 클라이언트가 서버상의 타겟의 장소를 지정하는 것입니다.
삭제
DELETE 메서드는 대상 리소스의 상태를 삭제하도록 요청합니다.
연결하다
CONNECT 메서드는 요청 타겟에 의해 식별된 오리진서버에 대한 TCP/IP 터널을 확립하도록 중개자에게 요구합니다.TLS를 [58][59][60]사용한1개 이상의 HTTP 프록시를 통한 접속을 보호하기 위해 자주 사용됩니다.HTTP CONNECT 방식을 참조하십시오.
옵션들
OPTIONS 메서드는 대상 리소스가 지원하는 HTTP 메서드를 전송하도록 요청합니다.특정 리소스 대신 '*'를 요청하여 웹 서버의 기능을 확인할 수 있습니다.
추적하다
TRACE 메서드는 타깃리소스가 응답 본문으로 수신한 요구를 전송하도록 요구합니다.그러면 클라이언트가 중개자에 의해 어떤 변경 또는 추가가 이루어졌는지 확인할 수 있습니다.
패치
PATCH 메서드는 요구에 포함된 표현에 정의된 부분 업데이트에 따라 타깃리소스가 상태를 변경하도록 요구합니다.이렇게 하면 파일 또는 문서의 일부를 [61]완전히 전송하지 않고도 업데이트하여 대역폭을 절약할 수 있습니다.

모든 범용 웹 서버는 적어도 GET 및 HEAD 방식을 구현해야 하며,[62] 기타 모든 방식은 사양에 따라 옵션으로 간주됩니다.

요청 메서드의 속성
의뢰방법 RFC 요청에 페이로드 본문이 있습니다. 응답에 페이로드 본문이 있습니다. 안전한 아이돌 포텐트 캐시 가능
얻다 RFC 7231 선택적. 네. 네. 네. 네.
머리 RFC 7231 선택적. 아니요. 네. 네. 네.
포스트. RFC 7231 네. 네. 아니요. 아니요. 네.
놓다 RFC 7231 네. 네. 아니요. 네. 아니요.
삭제 RFC 7231 선택적. 네. 아니요. 네. 아니요.
연결하다 RFC 7231 선택적. 네. 아니요. 아니요. 아니요.
옵션들 RFC 7231 선택적. 네. 네. 네. 아니요.
추적하다 RFC 7231 아니요. 네. 네. 네. 아니요.
패치 RFC 5789 네. 네. 아니요. 아니요. 아니요.

안전한 방법

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

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

GET 요구의 안전성은 정해져 있지만 실제로는 서버에 의한 처리가 기술적으로 제한되지 않습니다.부주의하거나 의도적으로 불규칙한 프로그래밍으로 인해 GET 요구가 서버에서 사소한 변경을 일으킬 수 있습니다.이는 캐싱, 검색 엔진 및 기타 자동 에이전트가 서버에서 의도하지 않은 변경을 수행할 때 발생할 수 있는 문제 때문에 권장되지 않습니다.예를 들어 웹 사이트에서는 https://example.com/article/1234/delete, 등의 URL을 통해 리소스를 삭제할 수 있습니다.이 URL을 임의로 가져오면 GET을 사용하여 해당 문서를 [63]삭제하기만 하면 됩니다.올바르게 코딩된 웹 사이트에서는 이 작업을 수행하려면 DELETE 또는 POST 방법이 필요한데, 악의적이지 않은 봇은 이 방법을 사용하지 않습니다.

실제로 이러한 현상이 발생하는 한 가지 예는 단명 구글 웹 액셀러레이터 베타 기간 동안 사용자가 보고 있는 페이지의 임의의 URL을 프리페트하여 레코드가 자동으로 변경 또는 삭제되도록 하는 것이다.이 베타는 광범위한 [64][63]비판에 따라 첫 출시 후 몇 주 만에 중단되었다.

Idempotent 메서드

요구 방식은 해당 메서드와 동일한 여러 요구가 하나의 요구와 동일한 효과를 갖는 경우 등가성이 있다.PUT 메서드, DELETE 메서드 및 safe 메서드는 idempotent로 정의됩니다.세이프 메서드는 서버에 전혀 영향을 주지 않는 것을 목적으로 하고 있기 때문에 충분히 유효합니다.또한 PUT 메서드와 DELETE 메서드는 연속되는 동일한 요구가 무시되기 때문에 무효입니다.예를 들어 웹 사이트는 사용자의 기록된 전자 메일 주소를 수정하도록 PUT 끝점을 설정할 수 있습니다.이 엔드포인트가 올바르게 구성되면 사용자의 전자 메일 주소를 이미 기록된 동일한 전자 메일 주소로 변경하도록 요청하는 요청(예: 성공한 요청에 따른 중복 요청)은 아무런 영향을 받지 않습니다.마찬가지로 특정 사용자가 이미 삭제된 경우 해당 사용자의 삭제 요청은 적용되지 않습니다.

한편, POST, CONNECT, PATCH의 각 메서드는 반드시 유효하다고는 할 수 없기 때문에, 같은 POST 요구를 여러 번 송신하면, 서버 상태가 한층 더 변경되거나, 복수의 E-메일을 송신하는 등, 한층 더 효과가 있는 경우가 있습니다.경우에 따라서는 이것이 바람직한 효과일 수도 있지만, 다른 경우에는 우발적으로 발생할 수도 있습니다.예를 들어 첫 번째 클릭이 처리 중이라는 명확한 피드백을 받지 못한 경우 버튼을 다시 클릭함으로써 사용자가 실수로 여러 POST 요청을 전송할 수 있습니다.페이지를 새로고침하면 POST 요구가 재발송신될 수 있는 경우에 사용자에게 경고하는 경보대화상자가 표시되는 경우가 있습니다만, POST 요구가 여러 번 송신되지 않는 경우의 처리는 일반적으로 웹 어플리케이션에 달려 있습니다.

메서드가 idempotent인지 여부는 프로토콜 또는 웹 서버에 의해 강제되지 않습니다.GET 또는 기타 요청에 의해 데이터베이스 삽입 또는 기타 비잠재적 액션이 트리거되는 웹 응용 프로그램을 작성할 수 있습니다.그러나 사용자 에이전트가 동일한 요청을 반복하는 것이 안전하지 않을 때 안전하다고 가정할 경우 권장 사항에 반하는 것은 바람직하지 않은 결과를 초래할 수 있습니다.

캐시 가능한 메서드

요청 방법은 향후 재사용을 위해 해당 방법으로 요청에 대한 응답을 저장할 수 있는 경우 캐시할 수 있습니다.GET, HEAD 및 POST 메서드는 캐시 가능으로 정의되어 있습니다.

반면 PUT, DELETE, CONNECT, OPTIONS, TRACE 및 PATCH 메서드는 캐시할 수 없습니다.

요청 헤더 필드

요청 헤더 필드를 사용하면 클라이언트는 요청 줄 너머로 추가 정보를 전달할 수 있습니다(프로시저의 파라미터와 마찬가지로).클라이언트, 대상 리소스에 대한 정보 또는 예상되는 요청 처리에 대한 정보를 제공합니다.

HTTP/1.1 응답 메시지

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

응답 구문

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

HTTP/1.1 200 OK
  • 대소문자를 구분하지 않는 0개 이상의 응답 헤더 필드 이름, 콜론, 옵션의 선행 공백, 필드 값, 옵션의 후행 공백으로 구성되며 캐리지 리턴 및 줄 바꿈으로 끝나는 다음과 같은 필드.
내용 유형: text/html
  • 캐리지 리턴 및 라인 피드로 구성된 빈 라인
  • 옵션 메시지 본문

응답 상태 코드

HTTP/1.0 이후에서는 HTTP 응답의 첫 번째 줄을 상태 행이라고 하며 숫자 상태 코드("404" 등)와 텍스트 이유 구문("Not Found")을 포함합니다.응답 상태 코드는 서버가 클라이언트의 해당 요청을 이해하고 충족시키려는 시도의 결과를 나타내는 세 자리 정수 코드입니다.클라이언트가 응답을 처리하는 방법은 주로 상태 코드에 따라 다르며, 다음으로 다른 응답 헤더 필드에 따라 달라집니다.클라이언트는 모든 등록된 상태 코드를 이해하지 못할 수 있지만 클래스(상태 코드의 첫 번째 자리)를 이해하고 인식할 수 없는 상태 코드를 해당 클래스의 x00 상태 코드와 동등하게 취급해야 합니다.

표준 이유 문구는 권장 사항일 뿐이며 웹 개발자의 재량에 따라 "로컬 동등어"로 대체할 수 있습니다.상태 코드가 문제를 나타내는 경우 사용자 에이전트는 사용자에게 이유 문구를 표시하여 문제의 성질에 대한 자세한 정보를 제공할 수 있습니다.또한 표준에서는 상태 코드가 기계에서 읽을 수 있고 이유 문구는 사람이 읽을 수 있다고 명시되어 있기 때문에 이는 현명하지 않을 수 있지만 사용자 에이전트가 이유 문구를 해석할 수 있습니다.

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

1XX(비교적)
요청이 수신되어 프로세스를 계속합니다.
2XX(성공)
요청이 정상적으로 수신, 이해 및 승인되었습니다.
3XX(리다이렉트)
요청을 완료하려면 추가 조치를 취해야 합니다.
4XX(클라이언트 오류)
요청에 잘못된 구문이 포함되어 있거나 수행할 수 없습니다.
5XX(서버 오류)
서버가 유효한 것으로 보이는 요청을 이행하지 못했습니다.

응답 헤더 필드

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

각 응답 헤더 필드는 요구 방식 또는 응답 상태 코드의 의미론에 의해 더욱 구체화될 수 있는 정의된 의미를 가진다.

HTTP/1.1 요구/응답 트랜잭션 예시

다음으로 HTTP/1.1 클라이언트와 www.example.com 포트 [note 5][note 6]80 상에서 동작하는HTTP/1.1 서버 간의 HTTP 트랜잭션 예를 나타냅니다.

클라이언트 요구

얻다 / HTTP/1.1 주인: www.example.com 사용자 에이전트: Mozilla/5.0 승낙하다: text/module, application/xhtml+xml, application/xml;q=0.9, image/avif, image/webp,*/*;q=0.8 수용 언어: en-GB,en;q=0.5 Accept-Encoding(승인 부호화): gzip, 감압, br 연결: 유지 보수 

클라이언트 요구(이 경우 요구 행과 몇 개의 헤더를 고려하여"Host: hostname"header) 뒤에 공백 행이 이어지기 때문에 요청은 캐리지 리턴 형식으로 각각 이중 끝 행으로 끝납니다."Host: hostname"header value는 단일 IP 주소를 공유하는 다양한 DNS 이름을 구분하여 이름 기반의 가상 호스팅을 가능하게 합니다.HTTP/1.0 에서는 옵션이지만, HTTP/1.1 에서는 필수입니다. ("/"(슬래시)는 보통 /index.html 파일이 있는 경우 가져옵니다.)

서버 응답

HTTP/1.1 200 확인일 : 2005년 5월 23일 (월) 22:38:34 GMT Content-Type : text / harset =UTF-8 Content-Length: 155 최종 변경:2003년 1월 08일 (수) 23:11:55 GMT Server: Apache/1.3.7 (Unix) (Red-Hat/Linux) ETag: "3f80f-1b6-3e1cb03b" Accept-Range: 바이트 연결: close <html> <헤드> <title> 페이지 </p> </body> </body> </body>

ETag(엔티티 태그) 헤더필드는 요청된 리소스의 캐시 버전이 서버 상의 현재 리소스와 동일한지 여부를 판단하기 위해 사용됩니다. "Content-Type"는 HTTP 메시지에 의해 전송되는 데이터의 인터넷미디어 유형을 지정합니다."Content-Length"길이는 바이트 단위로 나타냅니다.HTTP/1.1 서버는 필드를 설정하여 문서의 특정 바이트 범위에 대한 요청에 응답하는 기능을 게시합니다."Accept-Ranges: bytes"이것은 클라이언트가 서버에서 송신하는 자원의 특정 부분[65](바이트 서비스라고 함)만을 필요로 하는 경우에 편리합니다.언제"Connection: close"송신됩니다.이것은, [21]이 응답의 전송이 종료한 직후에, Web 서버가 TCP 접속을 닫는 것을 의미합니다.

대부분의 헤더 행은 옵션이지만 일부는 필수입니다.머리글의 경우"Content-Length: number"엔티티 본문이 있는 응답에 존재하지 않는 경우, 이것은 HTTP/1.0 의 에러로 간주됩니다만, 헤더의 경우는 HTTP/1.1 의 에러가 아닐 수 있습니다."Transfer-Encoding: chunked"존재합니다.청크 전송 부호화는 청크 크기 0을 사용하여 콘텐츠의 끝을 표시합니다.HTTP/1.0의 일부 오래된 실장에서는 헤더가 생략되어 있습니다."Content-Length"응답이 시작될 때 본문 엔티티의 길이를 알 수 없었기 때문에 서버가 소켓을 닫을 때까지 클라이언트에 대한 데이터 전송이 계속되었습니다.

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

암호화된 연결

암호화 HTTP 접속을 확립하는 가장 일반적인 방법은 [66]HTTPS입니다.암호화 HTTP 접속을 확립하는 다른 2가지 방법도 있습니다.Secure Hypertext Transfer Protocol 및 HTTP/1.1 Upgrade 헤더를 사용하여 TLS로의 업그레이드를 지정합니다.단, 이들 2개의 브라우저 지원은 [67][68][69]거의 없습니다.

유사한 프로토콜

  • Gopher 프로토콜은 1990년대 초에 HTTP로 대체된 콘텐츠 전송 프로토콜입니다.
  • SPDY 프로토콜은 HTTP/2로 대체되는 Google에서 개발한 HTTP의 대안입니다.
  • 제미니 프로토콜은 개인정보 보호 관련 기능을 요구하는 Gopher에서 영감을 받은 프로토콜입니다.

「 」를 참조해 주세요.

메모들

  1. ^ 실제로 이러한 스트림은 동시 요구/응답 다중화를 위한 여러 TCP/IP 서브 연결로 사용되므로 서버 측에서 실제 TCP/IP 연결 수가 클라이언트당 2.8개에서1개로 대폭 감소하여 더 많은 클라이언트를 동시에 처리할 수 있습니다.
  2. ^ 2021년 HTTP/0.9 지원은 공식적으로 완전히 폐지되지 않았으며, 많은 웹 서버 및 브라우저(서버 응답 전용)에서 일반적으로 비활성화되어 있더라도 여전히 존재합니다.HTTP/0.9의 폐기에 걸리는 시간은 불명확합니다.
  3. ^ 1996년 후반부터 인기 있는HTTP/1.0 브라우저와 서버의 일부 개발자(특히 HTTP/1.1에 대한 지원을 계획한 개발자)는 (새로운 HTTP 헤더를 사용하여) 요구/응답 쌍 이상의 TCP/IP 접속을 열어 주고 교환 속도를 높이기 위해 일종의 킵얼라이브 메커니즘(keep-alive-mechanism)을 도입하기 시작했습니다.nge가 여러 요청/실행됩니다.[31]
  4. ^ a b HTTP/2 와 HTTP/3 는, HTTP 메서드와 헤더의 표현이 다릅니다.
  5. ^ HTTP/1.0 에는, 몇개의 헤더가 없는 것을 제외하고, 같은 메세지가 표시됩니다.
  6. ^ HTTP/2 와 HTTP/3 는, 같은 요구/응답 메커니즘을 사용하고 있습니다만, HTTP 헤더의 표현은 다릅니다.

레퍼런스

  1. ^ a b Fielding, Roy T.; Gettys, James; Mogul, Jeffrey C.; Nielsen, Henrik Frystyk; Masinter, Larry; Leach, Paul J.; Berners-Lee, Tim (June 1999). Hypertext Transfer Protocol – HTTP/1.1. IETF. doi:10.17487/RFC2616. RFC 2616.
  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. ^ "HTTP/3 is Fast". Request Metrics. Retrieved 2022-07-01.
  4. ^ a b Tim Berner-Lee (1992). "Basic HTTP as defined in 1992". www.w3.org. World Wide Web Consortium. Retrieved 2021-10-19.
  5. ^ RFC 1945에서.그 후, 그 사양은 HTTP/1.1에 의해서 극복되었습니다.
  6. ^ RFC 2068(1997)은 1999년에 RFC 2616의해 폐지되었으며, 마찬가지로 2014년에 RFC 7230으로 대체되었습니다.
  7. ^ "Usage Statistics of Default protocol https for websites". w3techs.com. Retrieved 2022-05-05.
  8. ^ "Usage Statistics of HTTP/2 for websites". w3techs.com. Retrieved 2022-05-05.
  9. ^ "Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. Retrieved 2022-05-05.
  10. ^ "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension". IETF. July 2014. RFC 7301.
  11. ^ Belshe, M.; Peon, R.; Thomson, M. "Hypertext Transfer Protocol Version 2, Use of TLS Features". Retrieved 2015-02-10.
  12. ^ Benjamin, David. "Using TLS 1.3 with HTTP/2". tools.ietf.org. Retrieved 2020-06-02. This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2.
  13. ^ "HTTP/3". Retrieved 2022-06-06.
  14. ^ "Usage Statistics of HTTP/3 for websites". w3techs.com. Retrieved 2021-11-02.
  15. ^ "Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. Retrieved 2022-05-05.
  16. ^ Cimpanu, Catalin (26 September 2019). "Cloudflare, Google Chrome, and Firefox add HTTP/3 support". ZDNet. Retrieved 27 September 2019.
  17. ^ "HTTP/3: the past, the present, and the future". The Cloudflare Blog. 2019-09-26. Retrieved 2019-10-30.
  18. ^ "Firefox Nightly supports HTTP 3 - General - Cloudflare Community". 2019-11-19. Retrieved 2020-01-23.
  19. ^ "Overall Operation". RFC 2616. p. 12. sec. 1.4. doi:10.17487/RFC2616. RFC 2616.
  20. ^ "Overall Operation". RFC 1945. pp. 6–8. sec. 1.3. doi:10.17487/RFC1945. RFC 1945.
  21. ^ a b c "Connection Management: Connection". RFC 7230, HTTP/1.1: Message Syntax and Routing. pp. 51–52. sec. 6.1. doi:10.17487/RFC7230. RFC 7230.
  22. ^ "Connection Management: Persistence". RFC 7230, HTTP/1.1: Message Syntax and Routing. pp. 52–53. sec. 6.3. doi:10.17487/RFC7230. RFC 7230.
  23. ^ "Classic HTTP Documents". W3.org. 1998-05-14. Retrieved 2010-08-01.
  24. ^ "HTTP/2 Protocol Overview". RFC 7540, Hypertext Transfer Protocol Version 2 (HTTP/2). p. 5. 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.{{cite web}}: CS1 maint :url-status (링크)
  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. ^ 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". Retrieved 2022-06-06.
  43. ^ a b "Client/Server Messaging". RFC 7230, HTTP/1.1: Message Syntax and Routing. pp. 7–8. sec. 2.1. doi:10.17487/RFC7230. RFC 7230.
  44. ^ "Uniform Resource Identifier: http URI scheme". RFC 7230, HTTP/1.1: Message Syntax and Routing. pp. 17–18. sec. 2.7.1. doi:10.17487/RFC7230. RFC 7230.
  45. ^ "Uniform Resource Identifier: https URI scheme". RFC 7230, HTTP/1.1: Message Syntax and Routing. pp. 18–19. sec. 2.7.2. doi:10.17487/RFC7230. RFC 7230.
  46. ^ a b c Fielding, Roy T.; Reschke, Julian F. (June 2014). Hypertext Transfer Protocol (HTTP/1.1): Authentication. IETF. doi:10.17487/RFC7235. RFC 7235.
  47. ^ 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.
  48. ^ a b "Message format". RFC 7230: HTTP/1.1 Message Syntax and Routing. p. 19. sec. 3. doi:10.17487/RFC7230. RFC 7230.
  49. ^ "Apache Week. HTTP/1.1". 090502 apacheweek.com
  50. ^ 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.
  51. ^ "Method Definitions". RFC 2616. pp. 51–57. sec. 9. doi:10.17487/RFC2616. RFC 2616.
  52. ^ "Message Format: Start Line, Request Line". RFC 7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. pp. 21-22. sec. 3.1.1. doi:10.17487/RFC7230. RFC 7230.
  53. ^ "Request Methods: Overview". RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. pp. 21-22. sec. 4.1. doi:10.17487/RFC7231. RFC 7231.
  54. ^ "Message Format: Header Fields". RFC 7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. pp. 21-22. sec. 3.2. doi:10.17487/RFC7230. RFC 7230.
  55. ^ Jacobs, Ian (2004). "URIs, Addressability, and the use of HTTP GET and POST". Technical Architecture Group finding. W3C. Retrieved 26 September 2010.
  56. ^ "POST". RFC 2616. p. 54. sec. 9.5. doi:10.17487/RFC2616. RFC 2616.
  57. ^ "PUT". RFC 2616. p. 55. sec. 9.6. doi:10.17487/RFC2616. RFC 2616.
  58. ^ "CONNECT". Hypertext Transfer Protocol – HTTP/1.1. IETF. June 1999. p. 57. sec. 9.9. doi:10.17487/RFC2616. RFC 2616.
  59. ^ Khare, Rohit; Lawrence, Scott (May 2000). Upgrading to TLS Within HTTP/1.1. IETF. doi:10.17487/RFC2817. RFC 2817.
  60. ^ "Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections". US-CERT. 2002-05-17. Retrieved 2007-05-10.
  61. ^ Dusseault, Lisa; Snell, James M. (March 2010). PATCH Method for HTTP. IETF. doi:10.17487/RFC5789. RFC 5789.
  62. ^ "Method". RFC 2616. p. 36. sec. 5.1.1. doi:10.17487/RFC2616. RFC 2616.
  63. ^ 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.
  64. ^ 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.
  65. ^ Luotonen, Ari; Franks, John (February 22, 1996). Byte Range Retrieval Extension to HTTP. IETF. I-D draft-ietf-http-range-retrieval-00.
  66. ^ Canavan, John (2001). Fundamentals of Networking Security. Norwood, MA: Artech House. pp. 82–83. ISBN 9781580531764.
  67. ^ Zalewski, Michal. "Browser Security Handbook". Retrieved 30 April 2015.
  68. ^ "Chromium Issue 4527: implement RFC 2817: Upgrading to TLS Within HTTP/1.1". Retrieved 30 April 2015.
  69. ^ "Mozilla Bug 276813 – [RFE] Support RFC 2817 / TLS Upgrade for HTTP 1.1". Retrieved 30 April 2015.
  70. ^ Nottingham, Mark (October 2010). Web Linking. IETF. doi:10.17487/RFC5988. RFC 5988.
  71. ^ "Hypertext Transfer Protocol Bis (httpbis) – Charter". IETF. 2012.

외부 링크