[Lecture 21] HTTP

#개요

이번 포스트에서는 현대 웹 기반 애플리케이션뿐만 아니라 전 세계 웹의 기본 프로토콜인 Hypertext Transfer Protocol HTTP에 대해 알아보자. 

 

HTTP란 인터넷에서 하이퍼텍스트(hypertext) 문서를 교환하기 위하여 사용되는 통신규약이다. 하이퍼텍스트는 문서 중간중간에 특정 키워드를 두고 문자나 그림을 상호 유기적으로 결합하여 연결시킴으로써, 서로 다른 문서라 할지라도 하나의 문서인 것처럼 보이면서 참조하기 쉽도록 하는 방식을 의미한다.

 

http는 1989년 팀 버너스 리(Tim Berners Lee)에 의하여 처음 설계되어 인터넷을 통한 월드 와이드 웹(World-Wide Web) 기반에서 전 세계적인 정보공유를 이루는데 큰 역할을 하였다. http의 첫번째 버전은 인터넷을 통하여 가공되지 않은 데이터를 전송하기 위한 단순한 프로토콜이었으나, 데이터에 대한 전송과 요구·응답에 대한 수정 등 가공된 정보를 포함하는 프로토콜로 개선되었다. 1991년에 처음으로 HTTP 0.9가 나왔고, 각각 1996, 1997에 HTTP/1.0과 HTTP/1.1이 나왔다. HTTP/2.0(2015, RFC 7540)과 HTTP/3.0은 주로 시맨틱을 보존하는 전송/보안 향상 기능이다.

 

인터넷 주소를 지정할 때 'http://www....'와 같이 하는 것은 www로 시작되는 인터넷 주소에서 하이퍼텍스트 문서의 교환을 http 통신규약으로 처리하라는 뜻이다.

하이퍼링크로 연결된 문서

#HTTP 기본 개념

• 사용자 에이전트가 서버에서 임의의 오브젝트를 요청하는 요청/응답 프로토콜
  • 매우 간단한 syntax, 요청 및 응답은 유사한 형식을 사용한다
• 요청: 균일한 리소스 로케이터에서 파생된 경로로 표시된 임의 개체/리소스 또는 URL을 요청한다
  • 요청 유형(“methods” GET, POST, PUT, DELETE, HEAD, OPTIONS, PATCH 등등)
• 응답: 일부 메타데이터와 함께 개체(옥텟/바이트로 구성됨)를 반환한다.
  • HTML, 텍스트, 이미지, 비디오, 오디오등등
  • 해석할 메타데이터(콘텐츠 유형 + 인코딩)
  • 또한 더 큰 개체의 스트리밍도 지원

# URL(Uniform Resource Locators)

• 일반적인 체계: http, https, file
• 기본 포트는 체계에 따라 다름
• 쿼리 문자열은 key=value pairs의 시퀀스이다

#HTTP Transaction 예시 1

//https://html.duckduckgo.com/html?q=http

GET /html?q=http HTTP/1.1 	<- method path?query version
Host: duckduckgo.com 		<- domain (in case of virtual hosts)
User-Agent: curl/7.58.0 	<- User agent is curl
Accept: */* 			<- Accept any content type

HTTP/1.1 200 OK 					<- HTTP version + status + message
Server: nginx 						<- various headers
Date: Sun, 26 Apr 2020 01:02:56 GMT
Content-Type: text/html; charset=UTF-8 			<- body is utf8-encoded HTML
Transfer-Encoding: chunked 				<- body will be sent in chunks
Expires: Sun, 26 Apr 2020 01:02:57 GMT
Cache-Control: max-age=1
X-DuckDuckGo-Locale: en_US

 

#HTTP Transaction 예시 2

//http://optiplex:10000/api/login

POST /api/login HTTP/1.1
Host: optiplex:10000
User-Agent: curl/7.58.0
Accept: */*
Content-Type: application/json 		<- request body type
Content-Length: 45 			<- request body length

{"username":"user0","password":"thepassword"}

HTTP/1.1 200 OK
Server: Personal-Server
Set-Cookie: auth_token=eyJhbGc ... 81Phms; Path=/
Content-Type: application/json
Content-Length: 49

{"exp":1588010897,"iat":1587924497,"sub":"user0"}

#HTTP Transaction 예시 3

//http://optiplex:10000/private/secret.txt

GET /private/secret.txt HTTP/1.1
Host: optiplex:10000
User-Agent: curl/7.58.0
Accept: */*
Cookie: auth_token=eyJhb .... fv24M9Ijl1ePpM81Phms

HTTP/1.1 200 OK
Server: Personal-Server
Content-Length: 12
Content-Type: text/plain
Secret File.

#HTTP Transaction 예시 4

//http://optiplex:10000/private/secret.txt

GET /private/secret.txt HTTP/1.1
Host: optiplex:10000
User-Agent: curl/7.58.0
Accept: */*

HTTP/1.1 403 Permission Denied
Server: Personal-Server
Content-Length: 18
Permission denied.

HTTP는 상태 비저장 (Stateless) 프로토콜이다. 서버는 프로토콜의 일부로 요청 간 상태를 유지하지 않는다. 클라이언트는 서버가 이전 상호 작용 또는 진행 중인 세션의 일부로 인식할 수 있는 정보를 제공해야 한다. 일반적으로 쿠키 또는 베어러(bearer) 토큰이 사용된다.

#HTTP Request Methods

 

GET:  Request transfer of target resource in the selected representation
HEAD: Like GET, except only metadata, no body
POST: Process data sent in the request, possibly creating a new resource
PUT: Update target resource
DELETE: Delete target resource
CONNECT: Create a tunnel to the target resource
OPTIONS: Inquire about server options or policies
TRACE, PATCH ...

#HTTP Response Status Codes

200 OK: Success
301 Moved Permanently: Follow directions in Location:
304 Not Modified: Resource hasn’t changed, use the cached copy
400 Bad Request: Client sends ill-formed request
401 Unauthorized: Unauthenticated
403 Forbidden: Authenticated, but unauthorized
404 Not Found: Resource doesn’t exist
418 I’m a Teapot: Attempt to brew coffee in a teapot [1]
500 Internal Server Error: Something went wrong that shouldn’t have
502 Bad Gateway: Can’t connect to upstream

#HTTP와 Transport Layer

• 일반적인 웹 페이지를 가져오는 것은 자바스크립트, 스타일시트, 글꼴, 이미지 등을 검색하기 위해 여러 HTTP 트랜잭션을 서로 다른 서버로 가져오는 것을 포함한다
• 2022년을 기준으로 HTTP는 TCP를 통해 직접 또는 간접적으로 실행되는 경우가 가장 많다.
• 따라서 전송 계층 속성은 HTTP 성능에 강력한 영향을 미친다

#HTTP 1.0

먼저 클라이언트가 웹 브라우저를 이용해 서버에 연결을 요청하면, 연결 요청을 받은 서버는 그 클라이언트에 대해 서비스를 준비한다. 서버가 준비 상태가 되면(①) 클라이언트는 읽고자 하는 문서를 서버에 요청한다(②). 그러면 서버는 웹 문서 중 클라이언트가 요청한 문서를 클라이언트에 전송하고(③) 연결을 끊는다(④). 아래 그림의 위쪽 부분에서 보여준 기본 연결 기능은 HTTP의 버전에 관계없이 동일하다.

하지만 HTTP 0.9는 하나의 웹 페이지 안에서도 텍스트와 그림마다 Connect 과정을 반복해서 거쳐야 했기 때문에 무척 비효율적이었고 오래 사용되지 못했다. 하지만 1.0 버전부터는 한 번의 Connect 후에 Request와 Response를 반복할 수 있게 되었다. 현재 인터넷에서 사용되는 대부분의 HTTP가 이런 방식의 1.0과 1.1 버전이다.

출처: https://terms.naver.com/entry.naver?docId=3431903&cid=58437&categoryId=58437

HTTP 1.0 버전의 연결

• HTTP 1.0이 요청한 각 리소스에 대해 새 TCP 연결을 만든다
• 요청은 handshake의 세 번째 lef와 함께 전송될 수 있다
• 필요한 시간: 2 × RTT + Tt 여기서 RTT는 작은 패킷의 왕복 시간이고 Tt는 객체의 전송 시간이다
• 비효율적이다, 특히 소규모 리소스(대역폭 대비) 및 높은 전파 지연(예: WAN) 연결의 경우

HTTP 1.0

#HTTP 1.1 - Persistent Connections

• 여러 전송에 대해 하나의 연결을 재사용한다
• 각 서버에 몇 개의 연결을 설정해야 할까?
  • 서버는 이 숫자가 낮기를 원한다(오버로드 방지). 네트워크또한 이 수치가 낮기를 원한다(공정성, 혼잡 제어)
• 어떤 요청을 어떤 연결을 통해 언제 보내야 할까?
  • 클라이언트는 서버가 가장 빨리 제공하는 연결을 사용하려고 한다

HTTP 1.1

#HTTP 1.1 Pipelining

• 알려진 대로 다음 리소스에 대한 요청을 전송하면 이론적으로 서버가 리소스를 연속으로 전송할 수 있다
• HOL(Head of Line) 차단으로 이어짐: 리소스 2를 보낼 준비가 될 때까지 리소스 3을 보낼 수 없다
• 또한 서버는 거의 항상 여러 연결을 병렬로 처리할 수 있지만 동일한 연결에서 리소스를 병렬로 가져오기 위해 구현되지 않는다
• 결과: 클라이언트가 여러 연결을 사용하고 파이프라인을 사용하지 않는다
  • RFC 2616: 서버당 2개
  • RFC 7230: 클라이언트는 "여러 연결을 열 때 보수적이어야 한다."

HTTP 1.1 with pipelining

#HTTP 2.0

웹이 복잡한 응용 개발을 위한 플랫폼 기술로 발전하면서 요구되는 성능 최적화에 목적을 두고 개발되었다. 바이너리 기반의 프레이밍 전송 계층(binary framing layer), 서버 푸시, 헤더 압축, 요청 및 응답 다중화, 전송 계층 보안(TLS: Transport Layer Security) 프로파일 등 새로운 기술이 추가되어 빠른 성능과 보안이 강화되었다.

웹 페이지 로딩 시간을 50% 줄이는 것을 목표로 구글(Google)사에서 2009년 개발한 개방형 전송 규약인 스피디(SPDY, SPeeDY로 발음)를 토대로 인터넷 엔지니어링 태스크 포스(IETF)에서 표준으로 개발하였다(2015년 IETF RFC 7540).

기존 HTTP 1.1 버전에서 새로 추가된 사항은 다음과 같다. HTTP 메시지를 바이너리 형식으로 캡슐화하여 프레임 단위로 전송함으로써 요청 및 응답 메시지 전송 효율성을 높인 바이너리 프레이밍 계층(binary framing layer), 다수의 요청/응답을 동시 처리하는 요청 및 응답 다중화(request/response multiplexing), 반복 사용되는 헤더 정보의 전송을 최소화한 헤더 압축(header compression), 클라이언트가 요청하지 않아도 필요가 예상되는 리소스를 서버가 미리 전송하는 서버 푸시(server push), 연결 초기에 서버 지원 프로토콜 리스트를 제공하는 프로토콜 교섭(Protocol Negotiation) 등이다. 2015년 말부터 인터넷 익스플로러 11, 크롬(Chrome), 오페라(Opera), 사파리(Safari), 에지 브라우저(Edge browser) 등 주요 브라우저에 적용되었다. (출처: 네이버 지식백과)

• 더 이상 선착순이 아니다. 클라이언트가 전송 순서 기본 설정을 지정할 수 있다
• 서버는 객체를 임의의 순서로 다시 보낼 수 있으며, 실제로는 프레임(부품)으로 분할하여 혼합하여 다시 조립할 수 있다
• 서버 푸시: 서버가 개체를 요청하기 전에 개체를 보낼 수 있게 하는 것 (하지만, 2022 년 부터 크롬에서 지원 중지함 https://developer.chrome.com/blog/removing-push/) 
• Header compression: 더 이상 ASCII가 아님
• 목표: 클라이언트가 여러 연결을 열도록 incentive 감소
  • 그러나 기본 TCP 전송에서 패킷 손실이 발생하면 연결이 일시적으로 지연될 수 있다

HTTP 2.0

#TLS - Transport Layer Security

• 최근 몇 년 동안 보안 전송을 통해 https - HTTP를 사용하는 것이 대부분이다 (예: RFC 7258)
  • 모든 TLS 프로토콜 제품군을 사용할 수 있다
  • HTTP 계층에 대해 완전히 투명
  • 일반적으로 인증서 및 공개 키 인프라를 통해 암호화 및 서버 인증을 제공한다
• 성능 측면에서 적절한 TLS 프로토콜이 협상되는 TCP 핸드셰이크에 이어 TLS 핸드셰이크가 추가되었다

HTTP over TLS

#HTTP/3 over QUIC: Quick UDP Internet Connections

• QUIC: Google의 제안:https://www.chromium.org/quic/
• HTTP/3은 QUIC를 사용한다.
• TCP 대신 UDP를 사용하여 패킷 손실 시 전체 스트림 차단 방지
  • 스트림 단위로 안정성 재구현
  • 정체 제어 재구현
  • 연결 설정 핸드셰이크 및 암호화 핸드셰이크 결합(암호화 상태를 재사용할 수 있는 경우 0 RTT)
  • 오류 수정 및 연결 마이그레이션 전달
• 모바일 비디오에서 이미 널리 사용되고 있다

QUIC 로고