HTTP 이해 - 이슈칼럼

쉬운 목차

HTTP 개요

HTTP(HyperText Transfer Protocol)는 HTML 문서와 같은 하이퍼텍스트 리소스를 검색할 수 있게 해주는 프로토콜입니다.

웹에서 모든 데이터 교환의 기초이며 클라이언트-서버 프로토콜이기도 합니다.

클라이언트-서버 프로토콜은 수신 측에서 요청이 시작되는 프로토콜입니다.

전체 문서는 텍스트, 레이아웃 설명, 이미지, 비디오 및 스크립트와 같은 가져온 부분 문서에서 재구성됩니다.

HTTP는 애플리케이션 계층 프로토콜이며 TCP 또는 암호화된 TCP인 TLS를 통해 전송됩니다.

HTTP 흐름

클라이언트가 서버와 통신을 원할 때 다음 단계를 수행합니다.

'추천 관련글,

1. TCP 연결을 엽니다.

TCP 연결은 요청(또는 여러 요청)을 보내거나 응답을 받는 데 사용됩니다.

클라이언트는 새 연결을 열거나 기존 연결을 재사용하거나 서버에 대한 여러 TCP 연결을 열 수 있습니다.

2. HTTP 메시지를 보냅니다.

HTTP 메시지(HTTP/2 이전)는 사람이 읽을 수 있습니다.

HTTP/2에서는 이러한 간단한 메시지가 프레임에 캡슐화되어 직접 읽을 수 없지만 원칙은 동일합니다.

3. 서버에서 보낸 응답 읽기

4. 연결을 닫거나 다른 요청에 다시 사용하십시오.

HTTP 파이프라이닝이 활성화되면 첫 번째 응답이 완전히 수신될 때까지 기다리지 않고 여러 요청을 보낼 수 있습니다.

HTTP 파이프라이닝은 이전 소프트웨어와 최신 버전이 공존하는 기존 네트워크에서 어려운 것으로 입증되었으며 프레임 내에서 보다 강력한 다중 요청을 보내는 HTTP/2로 대체되고 있습니다.

HTTP 메시지

HTTP 메시지의 두 가지 유형인 요청과 응답은 각각 고유한 형식을 가집니다.

문의

– HTTP 메서드: 클라이언트가 수행하려는 작업을 정의하는 GET 또는 POST와 같은 동사 또는 OPTIONS 또는 HEAD와 같은 명사. 일반적으로 ‘GET’은 리소스를 검색하는 데 사용되며 ‘POST’는 HTML 양식 데이터를 제출하는 데 사용됩니다.

– 경로: 프로토콜, 도메인 또는 TCP 포트 요소가 제거된 리소스의 URL입니다.

– 프로토콜 버전: HTTP 프로토콜 버전

– 헤더: 서버에 대한 추가 정보를 제공하는 헤더입니다.

메서드에 대해 전송되는 리소스를 포함하는 응답 본문과 유사합니다.

B. 포스트.

답변

– 프로토콜 버전: HTTP 프로토콜 버전

– 상태 코드: 요청의 성공 또는 실패, 상태 코드. 상태 코드를 보면 이유를 알 수 있습니다.

– 상태 메시지: 상태 코드에 대한 간략한 설명이 포함된 상태 메시지입니다.

– 헤더: 요청 헤더 및 선택적으로 가져온 리소스와 유사한 HTTP 헤더를 포함하는 본문입니다.

HTTP 개발

HTTP/0.9 – 단일 회선 프로토콜

초기 버전의 HTTP에는 버전 번호가 없었습니다.

HTTP/0.9는 이후 버전과 구별하기 위해 나중에 0.9로 명명되었습니다.

HTTP/0.9는 매우 간단합니다.

요청은 한 줄로 구성되며 가능한 방법은 리소스에 대한 경로인 ‘GET’입니다.

그것은 독특했습니다.

GET /mypage.html

대답도 매우 간단합니다.

파일 콘텐츠 자체로만 구성됩니다.

<HTML>
A very simple HTML page
</HTML>

이후 개발과 달리 HTTP 헤더가 없었습니다.

즉, HTML 파일만 전송할 수 있었고 다른 문서 유형은 전송할 수 없었습니다.

상태 또는 오류 코드가 없었습니다.

문제가 있는 경우 해당 파일의 문제에 대한 설명과 함께 사람이 처리할 수 있도록 특정 HTML 파일이 다시 전송되었습니다.

HTTP/1.0 – 확장성 부여

HTTP/0.9는 매우 제한적이었고 브라우저와 서버 모두에 약간의 유연성을 제공하기 위해 빠르게 확장되었습니다.

각 요청에 버전 정보를 추가했습니다.

(HTTP/1.0 그만큼 받다 라인에 첨부된 형식으로)
브라우저가 요청의 성공 또는 실패 여부를 알고 결과에 따라 조치를 취할 수 있도록 응답 시작 부분에 상태 코드 라인도 전송됩니다.
HTTP 헤더의 개념은 요청 및 응답에 도입되어 메타 데이터 전송을 허용하고 프로토콜을 유연하고 확장 가능하게 만듭니다.
새로운 HTTP 헤더(콘텐츠 유형 추가)를 사용하여 순수 HTML 파일 이외의 문서를 전송하는 기능을 추가했습니다.

다음은 몇 가지 일반적인 질문과 답변입니다.

GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
  <IMG SRC="http://catdog6210.myimage.gif">
</HTML>

다음은 두 번째 연결에서 이미지를 다운로드하기 위한 요청 및 응답입니다.

GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)

이러한 새로운 기능은 1991년부터 1995년까지 시행착오 방식을 사용하여 개발되었습니다.

서버와 브라우저에 기능을 추가한 후 상황을 관찰했습니다.

1996년 11월 일반 진료를 설명하는 정보 문서 RFC 1945이것이 HTTP/1.0의 정의이며 공식 표준이 아니라는 점은 주목할 만합니다.

HTTP/1.1 – 표준 프로토콜

1995년부터 다양한 HTTP/1.0 구현이 작업 중이었고 이듬해 HTTP/1.0 문서가 게시될 때까지 표준화가 진행되었습니다.

HTTP의 첫 번째 표준 버전인 HTTP/1.1은 HTTP/1.0이 출시된 지 불과 몇 달 후인 1997년 초에 출시되었습니다.

HTTP/1.1은 모호성을 명확히 하고 많은 개선 사항을 도입했습니다.

HTTP 연결 재사용을 허용하여 크롤링된 단일 소스 문서에 포함된 리소스를 표시하는 데 사용되는 연결을 다시 열어 시간을 절약합니다.

TCP 연결이 이미 열려 있으면 다른 핸드셰이크를 거치지 않고 요청에 직접 응답합니다.

첫 번째 요청에 대한 응답이 완전히 전송되기 전에 두 번째 요청을 보낼 수 있도록 파이프라인을 추가하여 통신 대기 시간을 줄였습니다.

HTTP 1.1 “Keep Alive(파이프라이닝)” / HTTP 1.1 “Keep Alive(Multiple)”

– 파이프라이닝: 클라이언트가 요청에 대한 응답을 기다린 후 새로운 요청을 보내는 대신 즉시 여러 요청을 보냅니다.

– 다중: 클라이언트는 많은 수의 개체를 검색하기 위해 여러 TCP 연결을 만들 수 있습니다.

– HOLB: 이 문제는 파이프라이닝을 통해 연결을 통해 여러 요청을 보낼 수 있지만 다음 응답은 첫 번째 응답이 처리될 때까지 대기하기 때문에 발생합니다.

분할 응답도 지원됩니다.
추가 캐시 제어 메커니즘이 도입되었습니다.
클라이언트와 서버가 가장 적합한 콘텐츠를 제공할 수 있도록 언어, 인코딩 또는 유형을 포함한 콘텐츠 협상이 도입됩니다.
주인 헤더 덕분에 동일한 IP 주소에서 다른 도메인을 호스트할 수 있는 기능을 통해 서버 코로케이션이 가능합니다.

다음은 단일 연결을 통한 전체 요청 흐름의 예입니다.

GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(content)


GET /static/img/header-background.png HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache

(image content of 3077 bytes)

1997년 1월 HTTP/1.1 RFC 2068에서 처음 공개되었습니다.

HTTP/2 – 더 나은 성능을 위한 프로토콜

오늘날의 웹사이트는 매우 복잡해지고 있습니다.

시각 효과와 상호작용성을 추가하기 위한 스크립트의 양과 크기가 증가하고 있습니다.

요청이 많을수록 더 많은 데이터가 전송됩니다.

HTTP/1.1 연결에서는 요청을 순서대로 보내야 합니다.

이론적으로 여러 개의 병렬 연결이 가능하더라도(일반적으로 5~8개) 많은 양의 오버헤드와 복잡성이 여전히 남아 있습니다.

예를 들어 HTTP 파이프라이닝은 배포의 악몽이 되었습니다.

2010년 상반기에 Google은 실험적인 SPDY 프로토콜을 구현하여 클라이언트와 서버 간의 데이터 교환을 위한 대체 방법을 시연했습니다.

브라우저와 서버 측 모두에서 많은 관심을 불러일으켰습니다.

HTTP/2 프로토콜의 기반이 된 SPDY는 응답성을 높이고 전송된 데이터 중복 문제를 해결할 수 있는 능력을 입증했습니다.

HTTP/2 프로토콜에는 HTTP/1.1 버전과 몇 가지 근본적인 차이점이 있습니다.

텍스트 로그가 아닌 바이너리 로그입니다.

더 이상 읽을 수 없고 수동 작업을 생성할 수 없습니다.

이러한 단점을 보완하기 위해 새로운 최적화 기술을 구현할 수 있습니다.
동일한 연결을 통해 병렬 요청을 처리할 수 있도록 허용하는 멀티플렉싱 프로토콜로, 순서를 제거하고 HTTP/1.x 프로토콜의 제한을 방지합니다.
연속 요청 사이에 매우 유사한 콘텐츠가 있는 헤더를 압축하여 전송된 데이터의 명백한 중복과 이러한 데이터로 인한 불필요한 오버헤드를 제거합니다.
서버가 서버 푸시라는 메커니즘을 통해 필요한 데이터로 클라이언트 캐시를 미리 채울 수 있습니다.

HTTP/2는 2015년 5월에 공식적으로 표준화되었으며 큰 성공을 거두었습니다.

2016년 6월 전체 웹사이트의 8.7%(하나)이미 사용 중이며 전체 요청의 68%를 차지합니다.

(2) 이상을 나타냅니다.

전송 오버헤드를 줄임으로써 많은 비용을 절약하는 인터넷의 트래픽이 많은 웹사이트는 이 프로토콜을 빠르게 채택합니다.

HTTP/2는 웹 사이트와 애플리케이션에서 채택할 필요가 없었기 때문에 이러한 빠른 채택이 가능했습니다.

HTTP/1.1 또는 HTTP/2 사용에 대해 걱정할 필요가 없습니다.

최신 브라우저와 통신하는 최신 서버는 프로토콜을 사용하기에 충분합니다.

HTTP/2 채택을 촉진하는 데는 다소 제한된 행위자 집합만 필요하며 브라우저 및 서버 버전이 변경됨에 따라 웹 개발자는 약정 없이도 HTTP/2 사용이 자연스럽게 증가할 수 있습니다.

차세대 – HTTP/2로의 진화

HTTP 2.0은 HTTP 1.1 프로토콜을 계승했으며 동일한 API를 유지하면서 성능 향상에 중점을 두었습니다.

일반 텍스트를 사용하고 새 줄로 구분되는 기존 HTTP/1.x 프로토콜과 달리 2.0은 이진 형식으로 인코딩된 메시지와 프레임으로 구성됩니다.

스트림: 설정된 연결 내에서 전송되는 양방향 바이트 흐름으로, 하나 이상의 메시지가 가능합니다.
메시지: 논리적 요청 또는 응답 메시지와 관련된 전체 프레임 시퀀스입니다.
프레임: Http/2.0에서 가장 작은 통신 단위로 각 최소 단위에는 프라임 헤더가 포함됩니다.

이 프라임 헤더는 적어도 프레임이 속한 스트림을 식별합니다.

헤더 타입 프레임과 데이터 타입 프레임이 존재합니다.