애플리케이션 계층 - HTTP

기운찬곰·2020년 10월 9일

Computer Science

목록 보기

24/27

🚀 웹과 HTTP

웹의 애플리케이션 계층 프로토콜인 HTTP(HyperText Transfer Protocol) 는 웹의 중심입니다.

HTTP는 W3 상에서 정보를 주고받을 수 있는 프로토콜입니다. 주로 HTML 문서를 주고받는 데에 쓰입니다. 주로 TCP를 사용하고 HTTP/3 부터는 UDP를 사용하며, 80번 포트를 사용합니다.

HTTP는 클라이언트와 서버 사이에 이루어지는 요청/응답(request/response) 프로토콜입니다. 예를 들면, 클라이언트인 웹 브라우저가 HTTP를 통하여 서버로부터 웹페이지(HTML)나 그림 정보를 요청하면, 서버는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 됩니다.

연결과정

3방향 핸드셰이크
1. HTTP 클라이언트는 HTTP기본 포트 80번을 통해 www.velog.io 서버로 TCP연결을 시도한다.
2. HTTP 서버는 연결을 수락한다.
3. HTTP클라이언트는 HTTP 요청메시지를 TCP소켓을 통해 서버로 보낸다.

이후과정
4. HTTP 서버는 연결 소켓을 통하여 요청 메시지를 받는다. 저장장치로부터 html, 자바스크립트, css 파일 등을 추출하여 응답 메시지에 그 객체를 캡슐화하여 보낸다.
5. HTTP 서버는 TCP에게 TCP연결을 끊으라고 한다. (클라이언트가 응답메시지를 올바르게 받을때까지)
6. 응답메시지를 받으면 연결이 중단된다.

하지만 HTTP 1.1 부터는 keep-alive가 가능해짐에 따라 지속연결이 가능해집니다. 즉, TCP 연결을 그대로 유지하고 이후 요청과 응답을 같은 연결을 통해 보낼 수 있습니다. 이후 일정 시간이 지나면 연결을 닫습니다.

HTTP 메시지 포맷

요청 메시지

메시지가 일반 ASCII 텍스트로 쓰여 있어 사람들이 읽을 수 있다.
각 줄은 CR과 LF로 구별된다. 마지막 줄에는 추가 CR과 LF를 따른다.
요청메시지의 첫 줄은 요청라인이라 부르고, 이 후 줄들은 헤더라인이라고 부른다.

요청라인은 3개의 필드, 즉 메소드필드, URL필드, HTTP버전 필드를 갖는다.
헤더라인은 Host(객체가 존재하는 호스트를 명시), Connetion, User-agent(사용자 에이전트, 즉 서버에게 요청을 하는 브라우저 타입), Accept-Language(요청바디의 언어형식), Accept(클라이언트가 인식할 수 있는 데이터 종류, 타입을 지정. 일반적으로 text/html)
요청바디에는 post방식으로 요청할때 들어가는 공간이다.

응답 메시지

상태라인 : 3개의 필드, 버전필드, 상태코드, 해당 상태 메시지를 갖는다.
헤더라인 : Date(HTTP응답이 서버에 의해 생성되고 보낸 날짜와 시간을 의미한다 = 응답메시지를 보낸시간). server(메시지가 아파치 웹 서버에 의해 만들어졌음을 나타낸다). Last-modified(객체가 생성되거나 마지막으로 수정된 시간과 날짜를 나타낸다). connection-length(송신되는 객체의 바이트 수). content-type(개체 몸체 내부에 객체의 타입을 나타낸다)

🪁 HTTP 버전 변화

문서화된 최초의 HTTP 버전은 1991년 HTTP 버전 0.9입니다.

1996년 버전 1.0, 그리고 1999년 1.1이 각각 발표되었습니다. 그리고 한참 후인 2015년 HTTP/2가 발표되었습니다.

HTTP/3는 HTTP 프로토콜의 3번째 메이저 업데이트 버전입니다. 2020 년 10 월 현재 인터넷 초안입니다. W3Techs에 따르면 상위 1000 만 웹 사이트 중 7.3 %가 HTTP / 3를 지원합니다.

1. HTTP/0.9

버전번호가 따로 없음
단일 라인으로 구성되며 get 메소드가 유일
Header 따위는 없었고 오직 HTML 파일만 전송
상태확인 코드도 존재하지 않았음

2. HTTP/1.0

요청에 버전 정보가 붙어서 붙어서 전송되기 시작
응답 시작 부분에 상태 코드가 추가됨
모든 요청과 응답에 헤더 개념이 추가됨

문제점 : HTTP/1.0 에서는 클라이언트와 서버 간의 요청/응답 교환을 위해서 하나의 TCP 연결이 새로 만들어 지는데, 요청을 보내기 전에 TCP와 TLS 핸드쉐이크가 완료되어야 하므로 모든 요청에 대해서 지연 패널티가 발생하게 됩니다.

3. HTTP/1.1

1.0이 발표될 당시에 다양한 표준화가 진행되고 있었고, 1.0 발표가 된지 몇달 지나지 않아 HTTP의 첫번째 표준버전인 1.1이 발표되었습니다.

커넥션의 재사용 가능(기존 연결에 대해서 handshake 생략가능)
파이프라이닝 추가, 이전 요청에 대한 응답이 완전히 전송되기 전에 다음 전송을 가능헤 하여, - 커뮤니케이션 레이턴시를 낮춤
청크된 응답 지원(응답 조각)
캐시 제어 메커니즘
언어, 인코딩 타입등을 포함한 컨텐츠 전송
동일 IP 주소에 다른 도메인을 호스트하는 기능 가능 (HOST header)

HTTP/1.1을 통해 많은 개선사항이 있었고, 그 중 keep-alive 헤더 등의 역할은 클라이언트와 서버간의 연결 비용을 줄이는데 큰 역할을 하였습니다.

클라이언트 요청 예

GET /restapi/v1.0 HTTP/1.1
Accept: application/json
Authorization: Bearer UExBMDFUMDRQV1MwMnzpdvtYYNWMSJ7CL8h0zM6q6a9ntw

서버 응답 예

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close 
-
<html>
<head>
  <title>An Example Page</title>
</head>
<body>
  Hello World, this is a very simple HTML document.
</body>
</html>

한계점 : 하지만, 웹이 발전함에 따라 브라우저가 웹페이지를 가져오고 렌더링 할 때 필요한 리소스의 가짓수(CSS, JavaScript, 이미지, html)등이 크게 증가함에 따라 점점 더 많은 동시성을 요구하게 되었고, 그 결과 단일 컨텐츠 조회에 대해서 여러개의 TCP 연결을 병렬 수행하는 것이 필요하게 되었고, 결국 이러한 각각의 TCP 스트림들은 다시 연결비용의 증가를 초래하게 되었습니다.

4. HTTP/2

HTTP/2의 등장은 이를 해결할 해결책으로 "streams"라는 개념을 도입하였습니다. 이것은 서로 다른 HTTP 연결들을 하나의 TCP 스트림으로 다중화하여 추상화 할 수 있는 개념으로, 브라우저에서 보다 효율적으로 TCP연결을 재사용 할 수 있도록 지원하는 개념입니다.

한계점 : 하지만 이러한 노력에도 피해갈 수 없는 문제인 HOLB라는 걸림돌이 있었습니다. HOLB(Head of line Blocking) 은 TCP 패킷이 네트워크 경로에서 손실되면 스트림에 공백이 생겨, 손실 된 바이트 다음에 오는 올바른 바이트들도 재전송으로 인해 전달이 되지 않아 발생하는 불필요한 지연을 말한다. 프로토콜이 TCP를 사용한는 한 피해갈 수 없는 문제인 것입니다.

특히, HTTP/2의 경우에는 여러개의 HTTP 스트림을 하나의 TCP 커넥션으로 처리하기 때문에 더 크게 영향을 받게 됩니다.

5. HTTP/3

HTTP/3는 매우매우매우 이례적으로 기반 프로토콜을 UDP를 사용합니다. 정확하게는 UDP를 기반으로 하는 QUIC를 사용합니다. UDP를 사용하지만 그렇다고 기존의 신뢰성 있는 통신이라는 타이틀을 포기한 것은 아닙니다.

HTTP/3의 장점을 설명하기 위해서는 기존의 TCP를 포기하고 QUIC를 채택하면서 얻게 된 장점을 설명해야한다.

암호화가 프로토콜의 일부기능으로 포함되어 있다. 이런 결합은 암호화와 인증이 기본으로 제공되고 연결을 더 빨리 만들 수 있게 합니다.
QUIC는 네이티브 멀티플렉싱을 제공하기 때문에 손실 된 패킷은 데이터가 손실 된 스트림에만 영향을 미칩니다. 그래서 HOLB를 피해갈 수 있습니다.

따라서 이러한 QUIC를 이용하는 HTTP/3는 새로운 연결에 대해서 핸드세이크로 인한 지연, 패킷 손실이 다른 스트림에 미치는 영향, 패킷 손실로 인한 지연으로부터 자유로울 수 있다.

그냥 HTTP/2를 수정하면 되지 않았을까?

HTTP/2의 일부 기능들은 QUIC 위에서도 별도의 변환 없이 그대로 적용할 수 있지만, 몇몇 기능들은 그렇지 않다. 대표적으로 예를 들자면, HPACK 이라는 HTTP/2에서 사용하던 헤더 압축 체계는 응답의 전달순서에 따라 크게 좌우되는데, QUIC는 스트림간의 순서를 보장하지 않기 때문에 사용할 수 없다.

현 진행상황

빠른 콘텐츠 전달이 생명인 CDN들은앞 다투어 서비스들을 적용하고 있고, 당연히 해당 CDN을 이용하는 서비스 제공자들은 HTTP/3를 지원한다. 구글에서 제공하는 상당수의 컨텐츠들(유튜브 포함), 페이스북 등이 지원하도록 구성되었고, 클라이언트는 크롬, 엣지 브라우저, curl 등이 이미 지원하고 있다.