http란

김병민·2022년 6월 5일

TIL

목록 보기

40/68

http ( HyperText Transfer Protocol )

http는 hyperText 데이터를 빠르게 교환하기 위한 애플리케이션 레이어 프로토콜의 일종으로, 서버와 클라이언트의 사이에서 어떻게 메시지를 교환할지를 정해 놓은 규칙이다. 해당 포스트에서는 http가 어떻게 구성되었으며 어떻게 변화해가고 있는 지에 대해 알아보도록 하겠다.

애플리케이션 레이어란?
네트워크에서 클라이언트가 사용하는 통신 프로토콜 및 인터페이스를 지정하는 추상화 계층

http의 구성

http를 크게 구분하면 Request와 Response로 구성되어있다고 볼 수 있다. 말 그대로 Request는 클라이언트가 서버에 요청을 보낼 때, Response는 클라이언트의 요청에 따른 응답이라고 볼 수 있다.

Request Format

클라이언트가 보낸 메시지 형식

요청 라인
HTTP Method, file(?) 요청 데이터,Protocol Version
요청 헤더
host: 클라이언트가 요청한 도메인 정도
Accept: 데이터 형식
User-Agent: 사용자가 사용한 브라우저 정보
Cookie: 클라이언트에게 저장되는 key 데이터
공백 라인 : header와 body의 구분선
요청 바디 : 클라이언트가 서버에 실제 요청한, 보내는 내용

Response Format

서버가 보낸 메시지 형식

상태 라인
Protocol Version, Response Status code
응답 헤더
Date: 날짜
Server: 서버 종류
Last-Modified: 마지막 접근 날짜
Content_Type : 응답 데이터 타입
공백 라인 : header와 body의 구분선
응답 바디 : 요청에 맞는 응답 데이터

특징

단순함
HTTP 메세지를 프레임별로 캡슐화하여 간결함을 유지하였으며 HTTP 메세지들은 사람이 읽고 이해할 수 있어, 테스트하기 쉽고 진입장벽이 낮다.
확장성
HTTP header는 확장하고 실허뫄기 쉽게 만들어졌습니다. 클라이언트와 서바가 새로운 헤더의 시맨틱에 대해 간단한 합의만 한다면, 언제든지 새로운 기능을 추가 가능합니다.
무상태성 ( Stateless )
HTTP는 상태를 저장하지 않습니다. 동일한 연결 상에서 연속하여 전달된 두 개의 요청 사이에는 연결고리가 없습니다. 즉 서버가 클라이언트의 상태를 보존하지 않습니다. 하지만 HTTP 쿠키는 상태가 있는 세션을 만들도록 해줍니다.

쿠키
쿠키
=> 클라이언트에 저장되는 키와 값이 들어있는 작은 데이터
=> 쿠키의 유효시간 내 브라우저가 종료되어도 인증이 유지됨
=> Response header에 set-Cookie 속성을 사용하여 쿠키를 만들 수 있다.

세션
=> 쿠키를 기반으로 하고 있지만, 쿠키와 달리 서버 측에서 관리
=> 서버는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태 유지
=> 세션 정보를 서버에 두어 보안이 좋지만, 서버 메모리를 많이 차지하게 됨

비연결성
HTTP는 기본이 연결을 유지하지 않음. 하지만 별도의 옵션을 두며 일정기간동안 유지할 수 있다. 비연결성을 유지하지 않는 이유는 지속적으로 리소스를 차지하기 때문

HTTP 변화

http 0.9 one-line-protocol

htpp 초기 버전에는 버전 번호가 존재하지 않았다. 그렇기에 매우 단순한 구조를 갖게된다.

//req
GET /mypage.html

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

위는 http 0.9 버전의 모습입니다. 메소드는 GET이 유일했습니다.

http 1.0

간단해도 너무 간단한 0.9버전을 진화시킨 1.0이 나왔습니다. 헤더를 추가하여 http의 확장성을 넓혔습니다. 여기서부터 우리가 흔히 보는 http형식을 보입니다.

하지만 http 1.0은 하나의 요청과 응답에 각 각 연결을 해야했습니다.

TCP handshake가 이루어지고 응답요청이 이루어지고 TCP가 끊어집니다 그리고 다음 요청은 다시 이 과정을 반복하죠. 자 여기서 문제가 생깁니다. 이러한 과정을 계속해서 반복한다면 매번 새로운 연결로 인해 성능이 저하될 것이며 서버 부하는 심해질 것입니다.

http 1.1

이러한 문제를 해결하기 위해 나온 것이 http 1.1입니다.
http 1.1은 Persistent Connection기능을 추가합니다.

Persistent Connection은 지정한 시간동안 연결을 끊지않고 계속해서 유지하여 TCP를 유지하는 것입니다.

또한 PipeLining이라는 기술을 도입합니다.

PipeLining은 첫번째 요청에 대한 응답이 완전히 전송되기 이전에 두번째 요청 전송을 가능케 하여, 요청,응답의 레이턴시를 줄이는 것입니다.

레이턴시
자극과 반응 사이의 시간

하지만 Pipeling은 치명적인 문제점이 도출되었습니다.

head of line blocking

첫번째 요청의 응답시간이 길어질 수록 두번째 세번째 요청도 길어지는 문제점입니다.

연속된 요청의 헤더 중복
연속된 요청의 헤더가 동일할 지라도 헤더를 계속해서 중복으로 보내어 주고받는 데이터가 무거워지는 문제점이다.

http 2.0 - 더 나은 성능을 위한 프로토콜

기존 http 1.x 버전의 성능 향상에 초점을 맞춰 나온 것이 http 2.0 프로토콜이다.
http 2.0은 표준의 대체가 아닌 확장을 의미한다.

특징

http 1.x 는 텍스트 프로토콜이었더라면,2.0은 이진 프로토콜, 바이너리 프로토콜로 변화했습니다.
=> 파싱, 전송 속도를 향상, 오류 발생 가능성을 낮췄습니다.
Multiplexed Streams
=> 하나의 Connection으로 동시에 여러 개의 메세지를 주고받게되었습니다. 또한, 응답은 요청 순서에 상관없이 Stream으로 받기 때문에 head of line blocking도 발생하지 않습니다.
Stream Prioritization
=> 리소스간 우선 순위 설정 가능
Server Push
=> 클라이언트가 요청하지 않은 내용도 서버에서 넣어보 보내줄 수 있다. 예를 들어 특정 요청이 이후에 다른 요청이 필요하다는 것을 서버가 안다면 특정 요청 이후 요청을 할 필요없이 서버가 클라이언트에 보내주는 것
Header Compression
=> 헤더의 크기를 줄여 페이지 로드 시간 감소 ( 중복 헤더 검출 후 압축 )

http 3.0 over QUIC

UDP를 바탕으로 구글에서 만든 QUIC를 활용한 3.0 버전

QUIC
범용 목적의 전송 계층 통신 프로토콜로 구글의 짐 로스킨드가 처음 설계하였다.
TCP는 UDP에 비해 신뢰성이 높지만 지연을 줄이기가 힘든 구조였기에 상대적으로 UDP에 비해 느렸다. 그래서 구글은 데이터 전송에만 집중된 설계인 UDP에 원하는 기능을 구현하여 TCP의 지연을 줄이면서 신뢰성을 확보한 QUIC를 구현했다.

기존은 TCP handShake가 없이 연결과 동시에 데이터를 전송하기에 TCP에 비해 빠르다는 장점이 있다.
Connection UUID라는 고유한 식별자로 서버와 연결하기에 커넥션 재수립을 할 필요가 없다.
TSL 기본 적용을 통해 IP Spoofing / Replay Attack 방지가 되고 보안성이 향상
독립 스트림 사용하여 향상된 멀티 플렉싱이 가능하다