HTTP(Hypertext Transfer Protocol)

클라이언트와 서버간의 소통 방법은 무엇이 있을까?

글 전체 참조
MDN - HTTP
HTTP 완벽 가이드
[10분 테코톡] 🧃쿨라임의 HTTP/1.1, HTTP/2, 그리고 QUIC

개요

클라이언트와 서버

HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다. HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 하다. HTTP 클라이언트의 요청과 HTTP 서버의 응답은 www의 기본 요소다.클라이언트-서버 프로토콜은 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미한다. 하나의 완전한 문서는 텍스트, 레이아웃, 설명, 이미지, 비디오, 스크립트 등 불러온 하위 문서들로 제구성된다.

리소스

웹 서버는 리소스를 관리하고 제공한다. 그림, 워드파일, HTML, Javscript 등 어떤 종류의 콘텐츠도 리소스가 될 수 있다.

미디어 타입

인터넷은 수천가지 데이터 타입을 다루기 때문에 HTTP는 웹에서 전송되는 객체 각각에 MIME(Multipurpose Internet Mail Extensions) 타입이라는 데이터 포멧 라벨을 붙인다. 웹 서버는 모든 HTTP 객체 데이터에 MIME 타입을 붙인다. 웹 브라우저는 서버로부터 HTTP 객체를 돌려받을 때, 다룰 수 있는 객체인지를 MIME로 판단한다.

1Content-type: image/jpeg(MIME Type)
2Content-length : 123124

MIME 타입은 사선으로 구분된 주 타입과 부 타입으로 이루어진 문자열 라벨이다. 위에서 image/jpeg처럼...

URI

웹 서버 리소스는 각자 이름을 가지고 있다. 클라이언트는 관심 있는 리소스를 지목할 수 있다. 서버 리소스 이름은 통합 자원 식별자로 불린다.(Uniform Resource Identifier - URI)

URI는 URL과 URN으로 나뉜다. 통합 자원 지시자(uniform resource locator, URL)는 리소스 식별자의 가장 흔한 형태다. URL은 특정 서버의 한 리소스에 대한 구체적인 위치를 서술한다. ㄷ리소스가 정확하게 어디있고 어떻게 접근할 수 있는지 분명히 알려준다.

URL

URL은 세부분으로 이루어진 표준 포맷을 따른다.

1// 예제이고 없는 주소다.
2https://photos.google.com/photo/AF1Q3pMu7tPf11taDupnO3ygBakMPRgqtfpAQZcnlbV6
3
41. 스킴(scheme) 보통 HTTP 프로토콜dlek.
5https://
6
72. 서버의 인터넷 주소 제공 photos.google.com으로 이동해라
8photos.google.com
9
103. 웹의 리소스를 가리킨다. /photo/AF1Q3pMu7tPf11taDupnO3ygBakMPRgqtfpAQZcnlbV6라고 불리우는 리소스를 가져와라
11/photo/AF1Q3pMu7tPf11taDupnO3ygBakMPRgqtfpAQZcnlbV6

URN

유니폼 리소스 이름(uniform resource name, URN)은 콘텐츠를 이루는 한 리소스에 대해, 그 리소스의 위치에 영향을 받지 않는 유일무이한 이름 역할을 한다. 아직 실험적이다.

트랜잭션

HTTP 트랜잭션 요청 명령과 응답 결과로 구성된다. 이 상호작용은 HTTP 메시지라고 불리는 정형화된 데이터 덩어리를 이용해 이루어진다.

TCP 커넥션

HTTP는 애플리케이션 계측의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상으로는 무엇이든 사용할 수 있으나 TCP 혹은 TLS를 통해 전송된다.

TCP는 오류 없는 데이터 전송, 순서에 맞는 전달, 조각나지 않은 데잍터 스트림을 제공한다. TCP/IP는 각 네트워크와 하드웨어의 특성을 숨기고 어떤 종류의 컴퓨터나 네트워크든 서로 신뢰성 있는 의사소통을 하게 해준다. 일단 TCP 커넥션이 맺어지면 클라이언트와 서버 컴퓨터 간에 교환되는 메시지가 없어지거나, 소산되거나, 순서가 뒤바뀌어 수신되는 일은 결코 없다.

HTTP 클라이언트가 서버에 메시지 전송이 가능하게 되기 전에 IP 주소와 포트번호를 사용해서 클라이언트와 서버 사이에 TCP/IP 커넥션을 맺어야한다. TCP는 서버 컴퓨터에 대한 IP주소와 그 서버에서 실행중인 프로그램이 사용하는 포트번호가 필요하다. URL을 이용해서 서버의 IP 주소와 포트 번호를 알아낸다.

서버가 사용자에게 리소스를 보여주는 순서

웹 브라우저는 a. 서버의 URL에서 호스트 명을 추출한다. b. 서버의 호스트 명을 IP로 변환한다. c. URL에서 포트 번호가 있다면 추출한다. d. 웹 서버와 TCP 커넥션을 맺는다. e. 서버에 HTTP 요청을 보낸다.
서버는 웹브라우저에 HTTP 응답을 돌려준다.
커넥션이 닫히면, 웹브라우저는 문서를 보여준다.

HTTP 기반 시스템의 구성요소

HTTP 요청은 하나의 개체, 사용자 에이전트에 의해 전송된다. 대부분의 사용자 에이전트는 브라우저지만, 무엇이든 될 수 있다. 서버는 request(요청)을 처리하고 response(응답)을 제공한다. 요청과 응답 사이에는 다양한 작업을 수행하는 게이트웨이 또는 캐시 역할을 하는 프록시 등이 있다. HTTP는 애플리케이션 계층의 최상위에 있다.

웹 페이지를 표시하기 위해

브라우저는 페이지의 HTML 문서를 가져오기 위한 요청을 전송
파일을 구문 분석하여 실행해야 할 스크립트 그리고 페이지 내 포함된 하위 리소스, CSS에 대응하는 추가적인 요청들을 가져온다.
브라우저는 불러온 리소스를 혼합한다.
브라우저에 의해 실행된 스크립트는 이후 단계에서 조금 더 많은 리소스를 가져올 수 있다.
브라우저는 그에 따라 웹 페이지를 갱신하게 된다.

웹 페이지는 하이퍼텍스트 문서이다. 사용자가 에이전트를 제어하고 웹을 돌아다닐 수 있도록 새로운 웹 페이지를 가져오기 위해 실행될 수 있는 링크를 뜻한다. 브라우저는 HTTP 요청 내에서 이런 지시 사항들을 변환하고 HTTP 응답을 해석하여 사용자에게 명확한 응답을 표시한다.

웹 서버

웹 서버는 클라이언트의 요청에 대한 문서를 제공하는 서버가 존재한다. 서버는 논리적으로 단일 기계다.

서버가 반드시 단일 머신일 필요는 없지만, 여러 개의 서버를 동일한 머신 위에서 호스팅 할 수 있다. HTTP/1.1과 Host 헤더를 이용하여 동일한 IP 주소를 공유할 수도 있다.

프록시

웹 브라우저와 서버 사이에는 수많은 컴퓨터와 머신이 HTTP 메시지를 이어 받고 전달한다. 프락시는 클라이언트와 서버 사이에 위치한 HTTP 중계자이다. 주로 보안을 위해 사용된다. 또한 요청과 응답을 필터링한다.

프록시의 기능

캐싱
필터링
로드 밸런싱
인증
로깅

캐시

웹캐시와 캐시 프락시는 자신을 거쳐 가는 문서들 중 자주 찾는 것의 사본을 저장해 두는, 특별한 종류의 HTTP 프락시 서버다.

게이트웨이

게이트 웨이는 다른 서버들의 중개자로 동작하는 특별한 서버다. 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용된다. 게이트 웨이는 스스로가 리소스를 가지고 있는 진짜 서버인 것처럼 요청을 다룬다.

터널

두 커넷션 사이에서 날(raw) 데이터를 열어보지 않고 그대로 전달해주는 HTTP 애플리케이션이다. HTTP 터널은 HTTP가 아닌 데이터를 하나 이상의 HTTP 연결을 통해 그대로 전송하기 위해 사용한다. 대표적 예로, 암호화된 SSL 트래픽을 HTTP 커넥션으로 전송하여 웹 트래픽만 허용하는 사내 방화벽을 통과하게 할 수 있다.

에이전트

사용자를 위해 HTTP 요청을 만들어주는 클라이언트 프로그램이다. 대표적인 에이전트로 웹 브라우저가 있다. 그밖에 웹 로봇처럼 자동화된 에이전트도 있다.

URL과 리소스

HTTP 완벽 가이드 - 2장
Identifying resources on the Web

URL은 브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리킨다.

1URL
2http://www.example.com/image/Ai9ef88FNeifhv09a9dlaiwifA
3
41. 스킴 (어떻게)
5http://
62. 호스트(어디에)
7www.example.com
83. 경로(무엇을)
9/image/Ai9ef88FNeifhv09a9dlaiwifA

URL은 HTTP 프로토콜이 아닌 다른 가용한 프로토콜을 사용할 수도 있다. mailto, ftp, rtsp 등...

URL 문법

1<스킴>://<사용자 이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프레그먼트>

스킴(Scheme or Protocol)

Scheme

스킴은 주어진 리소스에 어떻게 접근하는지 알려주는 중요한 정보다. 웹 브라우저가(또는 어플리케이션)어떤 프로토콜을 사용하여 리소스를 요청해야하는지 알려준다.

사용자 이름과 비밀번호

URL에서 사용자 이름과 비밀번호를 요구하기도 한다. 나는 이런 종류의 url을 몽고db에서 봤다. '@'문자는 URL로부터 사용자 이름과 비밀번호 컴포넌트를 분리한다. 입력하지 않을 경우 기본 사용자 이름과 비밀번호 값을 넣는다.

1ex) mongodb+srv://<cluster name>:<password>@cluster1.bfdgj.mongodb.net/myFirstDatabase?retryWrites=true&w=majority

호스트와 포트

호스트(Authority) 컴포넌트는 접근하려고 하는 리소스를 가지고 있는 인터넷상의 호스트 장비를 가리킨다. 호스트 명이나 IP주소로 제공한다.

포트 컴포넌트는 서버가 열어놓은 네트워크 포트를 가리킨다. 내부적으로 TCP 프로토콜을 사용하는 HTTP는 기본 포트로 80을 HTTPS는 443을 사용한다. 보통 생략한다.

경로 (path)

리소스가 서버의 어디에 있는지 알려준다. 유닉스 파일 시스템의 파일 경로와 유사하다. HTTP URL에서 경로 컴포넌트는 '/'문자를 기준으로 경로 조각으로 나뉜다. 각 경로 조각은 자체만의 파라미터 컴포넌트를 가질 수 있다.

파라미터(paramiter)

URL을 사용하는 애플리케이션이 리소스에 접근하기 위해서는 프로토콜 파라미터가 필요하다. 파라미터 컴포넌트는, 애플리케이션이 서버에 정확한 요철을 하기 위해 필요한 입력 파라미터를 받는데 사용한다.

이름/값 쌍의 리스트로 URL 나머지 부분들로부터 ';'로 구분하여 URL에 기술한다.

1/weekly;sale=false/main;graphics=ture

MDN 예제에는 포함되어있지 않다. 파라키터를 쿼리 파라미터만 소개하고있다.

질의(쿼리 - query)

데이터베이스 같은 서비스들은 요청받을 리소스 형식의 범위를 좁히기 위해서 질문이나 질의를 받을 수 있다. ?의 우측에 있는 값들이 쿼리 파라미터다. &로 나뉜 이름=값 쌍 형식의 질의 문자열로 구성된다.

1/store?item=24251&name=automobile&color=blue

프레그먼트

HTML 같은 리소스 형식들은 본래의 수준보다 더 작게 나뉠수 있다. 예를 들어 절(paragraph)이 포함된 용량이 큰 한 개의 텍스트 문서의 경우, 그 리소스에 대한 URL은 텍스트 문서 전체를 가리키겠지만, 이상적으로는 리소스 안에 있는 특정 절을 가리킬 수 있어야한다. 리소스의 특정 부분을 가리킬 수 있도록, URL은 리소스 내의 조각을 가리킬 수 있는 프래그먼트 컴포넌트를 제공한다. 일반적으로 HTTP 서버는 객체의 일부가 아닌 전체만 다루기 때문에, 클라이언트는 서버에 프래그먼트를 전달하지 않는다. 브라우저가 서버로부터 전체 리소스를 내려 받은 후, 프래그먼트를 사용하여 당신이 보고자 하는 리소스의 일부를 보여준다.

1&color=blue#automobile

단축 URL

상대 URL

URL은 상대와 절대로 나뉜다. 지금까지 공부한 것은 절대 URL이었다. 상대 URL은 모든 정보를 담고 있지 않다. 상대 URL로 리소스에 접근하는데 필요한 모든 정보를 얻기 위해서, base(기저)라고 하는 다른 URL을 사용해야한다.

상대 URL은 URL을 짧게 표기하는 방식히다. 상대 URL 문법에 따르면 HTML 작성자가 URL에 스킴과 호스트 그리고 다른 컴포넌트들을 모두 입력하지 않아도 된다.

상대 URL은 프래그먼트이거나 URL이다. 상대 URL을 사용하면 리소스 집합을 쉽게 변경할 수 있다. 그리고 문서 집합의 위치를 변경하더라고, 새로운 베이스 URL에 의해서 해석될 것이다.

안전하지 않은 문자

안전한 전송이란, 정보가 유실될 위험 없이 URL을 전송할 수 있다는 것을 의미한다.

사람들이 URL에 이진 데이터나 일반적으로 안전한 알파벳 외의 문자도 포함하려고 할 때가 있다는 것을 알게 되었다. 그래서 이스케이프라는 기능을 추가하여, 안전하지 않은 문자를 안전한 문자로 인코딩 할 수 있게 하였다.

URL 문자 집합

역사적으로 많은 컴퓨터 애플리케이션이 US-ASCII 문자 집합을 사용한다. 이것은 만들어 진지 오래된 문자 집합이라 유럽 언어, 비 라틴계 언어에 존재하는 변형된 문자들까지 지원하지 않는다. 또한 URL이 특정 이진 데이터를 포함해야하는 경우도 있다. 그래서 URL은 이스케이프 문자열을 써서 특정 문자나 데이터를 인코딩 할 수 있게 하였다.

인코딩 체계

안전하지 않은 문자들을 표현하기 위해 %기호로 시작해 ASCII 코드로 표현되는 두개의 16진수 숫자로 이루어진 '이스케이프'문자로 바꾼다.

문자 제한

URL에서 특별한 의미로 예약되어있는 문자들을 사용할 경우 반드시 인코딩을 거쳐야한다.

1%, /, ., .., #, ?, ;, : 등등

마무리

URL은 파일 위치가 바뀌면 더이상 파일을 찾을 수 없다는 단점이 있다. 그래서 한계를 극복하기 위해서 URN 방식이 고안되었다.(그러나 아직 사용되고 있지 않다.)

URN이 왜 URL을 대체하지 않는 것인지 찾아봤지만 이유를 찾을 수는 없었다. Uniform Resource Name

HTTP 메시지

참고 MDN - HTTP
HTTP 완벽 가이드 - 3장

서버와 클라이언트 간에 데이터가 교환되는 방식이다. HTTP/1.1에서는 클라이언트와 서버 사이의 연결을 통해 공개적으로 전달하였다.(사람이 읽을 수 있다) HTTP/2에서는 최적화와 성능 향상을 위해 HTTP 프레임으로 나누어진다. HTTP 메시지를 개발자가 손수 작성하는 경우는 드물다. 소프트웨어, 브라우저, 프록시 또는 웹 서버가 그 일을 한다. HTTP 메시지는 설정 파일, API, 다른 인터페이스를 통해 제공된다.

HTTP 메시지는 개발자 도구(크롬 기준)의 네트워크에서 볼 수 있다.

request는 클라이언트(브라우저)에 의해 전송되는 메시지다. responses는 전송된 메시지에 대해서 서버에서 응답으로 전송되는 메시지다. 괄호 안 글씨는 설명을 위해 내가 넣은 것이고 메시지에 포함되지 않는다. HTTP 메시지의 시작 줄과 HTTP 헤더를 묶어서 요청 헤드라고 부르고, HTTP 메시지의 페이로드는 본문이라고 한다.

메시지 흐름

메시지는 원 서버 방향을 인바운드로 하여 송신된다. 모든 처리 후, 메시지가 사용자 에이전트로 돌아오는 것은 아웃 바운드라고 부른다.

HTTP는 요청, 응답에 관계 없이 모든 메시지는 다운스트림으로 흐른다.

HTTP requests

1GET(method) /(path) HTTP/1.1(version of the protocol) [start-line]
2Host: example.com                                     [Headers]
3Accept-Language: en
4                                                      [empty line]

start line

1GET / HTTP1.1

method
- GET, PUT, POST 또는 명사 HEAD, OPTIONS, TRACE, DELETE를 통해 서버가 수행해야 할 동작을 나타낸다.
- POST와 PUT은 메시지 본문이 있고 나머지는 없다.
- 메서드는 확장 메서드가 존재한다.(위에서 언급한 GET, POST 등보다 더 많을 수 있다.)

1.1. GET

서버에게 리소스를 달라고 요청하기 위해서 쓰인다.
1.2. HEAD

정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만 돌려준다. 엔터티 본문은 결코 반환되지 않는다.
1.3 PUT

서버에 문서를 쓴다. 사용자가 PUT을 이용해 웹페이지를 만들고 웹 서버에 직접 게시할 수 있게 해준다. PUT의 의미는 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하는 것이다. PUT은 콘텐츠를 변경하기 때문에 수행 전에 사용자 비밀번호를 요구할 것이다.
1.4 POST

서버에 입력 데이터를 전송하기 위해 설계되었다. HTML 폼을 지원한다. 입력된 폼 값을 모아 서버로 전송한다.
1.5 TRACE

TRACE는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다. TRACE 요청은 목적지 서버에서 '루프백' 진단을 시작한다. 요청 전송 마지막 단계에서 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE응답을 되돌려준다. TRACE는 주로 진단을 위해 사용된다. 요청이 의도한 요청/응답 연쇄를 거쳐가는지 검사할 수 있다. 또한 프록시나 다른 어플리케이션들이 요청에 어떤 영향을 미치는지 확인해보고자 할 때 좋은 도구다. 대부분의 HTTP 애플리케이션은 TRACE 요청을 구별하는 메커니즘을 제공하지 않는다. 어떻게 이 요청을 처리할 것인지는 일반적으로 중간 애플리케이션이 결정을 내린다.
1.6 OPTIONS

OPTIONS는 웹 서버에게 여러가지 종류의 지원 범위에 대해 물어본다. 여러 리소스에 실제로 접근하지 않고 그것에 어떻게 접근하는 것이 최선인지 확인할수 있다.
1.7 DELETE

DELETE 메서드는 리소스를 삭제한다. 그러나 클라이언트는 삭제가 수행되는 것을 보장하지 못한다. 왜냐하면 클라이언트에게 알리지 않고 무시하는 것을 허용하기 때문이다.
1.8 확장 메서드

HTTP는 필요에 따라 확장 가능하도록 설계되어있다.

path
- 주로 URL, 프로토콜, 포트, 도메인의 절대 경로로 나타낼 수 있다.
- 포맷에는 origin, absolute, authority, asterisk형식이 있다.
version of the protocol
- 마지막에는 HTTP 버전이 들어간다.
- HTTP/2.22는 HTTP/2.3 보다 크다. (숫자 22가 3보다 크다. 숫자는 반드시 따로따로 비교해야한다.)

MDN HTTP headers

헤더에는 요청이 들어간다. 대소문자 구분이 없는 문자열 다음에 ":"이 붙고, 그 뒤에 오는 값은 헤더에 따라 다르다. 헤더는 값까지 포함해서 한 줄로 구성되지만 꽤 길어질 수 있다. 헤더 마지막은 빈 줄(CRLF)이 출력된다.

General, Request, Entity, 확장 헤더로 나뉜다.
General : 요청과 응답 양쪽에 모두 나타날 수 있음
Request : 요청에 대한 부가 정보 제공. 서버에게 클라이언트가 받고자 하는 데이터의 타입이 무엇인지 등의 부가 정보를 제공한다. 예: 어떤 미디어 타입도 다 받아들이겠다.

1Accept: */*

Response : 클라이언트에게 정보를 제공하기 위한 헤더

1Server : Tiki-Hut/1.0

Entity : 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술
확장 : 명세에 정의되지 않은 새로운 헤더

body

본문은 요청의 마지막 부분에 들어간다. GET, HEAD, DELETE, OPTIONS처럼 리소스를 가져오는 요청은 본문이 필요 없다. POST와 같이 일부 요청은 업데이트를 위해 서버에 데이터를 전송한다.

단일 리소스 본문, 다중 리소스 본문으로 나뉜다.

HTTP responses

1HTTP/1.1(Version of the protocol) 200(Status code) OK(Status message)  [start-line]
2Date: Sat, 09 Oct 2010 14:28:02 GMT                        [Headers]
3Server: Apache
4Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
5Etags: "51142bc1-7449-479b075b2891b"
6Accept-Ranges: bytes
7Content-Length: 29769
8Content-Type: text/html
9                                                          [empty line]

status line

시작줄을 상태 줄이라고 부른다.

프로토콜 버전
- 보통 HTTP/1.1
status code

HTTP response status codes
- 요청의 성공 여부
- 보통 많이 썼던거 200(OK),201(Created) 302(Found), 404(Not Found)
  
  전체 범위 정의된 범위 분류
  100-199 100-101 정보
  200-199 200-206 성공
  300-199 300-305 리다이렉션
  400-199 400-415 클라이언트 에러
  500-199 500-505 서버 에러

전체 범위	정의된 범위	분류
100-199	100-101	정보
200-199	200-206	성공
300-199	300-305	리다이렉션
400-199	400-415	클라이언트 에러
500-199	500-505	서버 에러

2.1 100-199 : 정보성 상태코드
- 클라이언트와 100 Continue 클라이언트가 엔터티를 서버에 보내려고 하기 전 100 Continue 응답을 기다리겠다면 Expect 요청 헤더를 보낼필요가 있다. 100-continue는 서버가 다루기 어렵거나 사용할 수 없는 큰 엔터티를 서버에게 보내지 않으려는 목적으로 사용해야한다.
- 서버와 100 Continue 서버가 Expect : 100-continue 헤더가 포함된 요청을 받는다면 응답 혹은 에러 코드로 답해야한다.
- 프락시와 100 Continue 클라이언트로부터 100-continue 응답을 의도한 요청을 받은 프락시가 해야할 일이 있다. next-hop 서버가 HTTP/1.1을 따르거나 어떤 버전을 따르는지 모른다면, Expect 헤더를 포함시켜서 요청을 다음으로 전달해야한다. 만약 next-hop이 HTTP/1.1 이전 버전을 따른다면 417 에러로 응답해야한다. 만약 이전 버전을 따르는 클라이언트를 대신해서 Expect:100-countinue를 포함시키기로 결정했다면 100 Countinue 응답을 클라이언트에게 보내면 안된다.
더 간략하게 이해해보기 100 Continue
Expect

상태 텍스트
- OK, Not Found 등
- 사유 구절은 상태 코드와 일대일로 대응된다.

Headers

General, Response, Entity로 나뉜다.(위에서 설명)

body

201, 204와 같은 상태 코드를 가진 응답에는 보통 본문이 없다. 본문은 세가지 종류로 나뉜다.

길이가 알려진 단일 파일로 구성된 단일-리소스 본문
길이를 모르는 단일 파일로 구성된 단일-리소스 분문
서로 다른 정보를 담고 있는 멀티파트로 이루어진 다중 리소스 본문

HTTP/2 프레임

HTTP/1.x 메시지는 성능상의 결함을 몇가지 가지고 있다.

본문은 압축이 되지만 헤더는 압축이 되지 않는다.
연속된 메시지들은 비슷한 헤더 구조를 띄기 마련인데, 그럼에도 불구하고 메시지마다 반복되어 전송된다.
다중 전송이 불가능하다. 서버 하나에 연결을 여러개 열어야한다.

HTTP/2에서는 추가적인 단계가 생겼다. HTTP/1.x 메시지를 프레임으로 나누어 스트림에 끼어 넣는다. 데이터와 헤더 프레임이 분리 되어 헤더를 압축할 수 있다. 스트림 여러개를 하나로 묶을 수 있다. 그래서 TCP 연결이 조금 더 효율적이다.

커넥션 관리

클라이언트가 서버와 통신하고자 할때

TCP 연결을 연다. TCP 연결은 요청을 보내거나 응답을 받는데 사용된다.
HTTP 메시지를 전송한다.

1GET / HTTP/1.1
2Host: example.com
3Accept-Language: en

서버에 의해 전송된 응답을 읽어들인다.

1HTTP/1.1 200 OK
2Date: Sat, 09 Oct 2010 14:28:02 GMT
3Server: Apache
4Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
5Etags: "51142bc1-7449-479b075b2891b"
6Accept-Ranges: bytes
7Content-Length: 29769
8Content-Type: text/html
9
10<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)

연결을 닫거나 다른 요청들을 위해 재사용한다.

HTTP 기반 API

일반적으로 사용된 API는 XMLHttpRequest와 fetch가 있다. 서버-전송 이벤트는 서버가 전송 메커니즘으로 HTTP를 사용하여, 클라이언트로 이벤트를 보낼 수 있도록 하는 단방향 서비스다.