본문 바로가기
Computer-Sience/Network

[Network] HTTP(Hypertext Transfer Protocol)

by dev_ss 2023. 2. 7.

HTTP는 www(world wide web) 상에서 정보를 교환할 수 있도록 내재된 프로토콜이다.

OSI 7 계층의 Application Layer에 속하여 있다.

 

포트는 기본적으로 80번을 사용하고, 주로 HTML 문서를 주고받는데 이용되며,

TCP를 주로 사용하되 HTTP/3 부터 UDP를 이용한다.

 

HTTP는 사용되는 주체에 따라 클라이언트(사용자), 서버로 나뉘어서 구분할 수 있으며,

Request(요청)과 Response(응답)에 따라 주체 간의 상호 작용을 통하여 자료를 송/수신한다.

 

이를 기반으로 URL에 자원의 위치를 명시하고 HTTP Method(POST/GET 등)을 이용하여 해당 위치의 자원과 상호작용하는 것이 REST(Representational state transfer)이다.

 


HTTP는 여러 버전을 두고 현재까지도 개발되고 있으며 다음의 순으로 역사에 대하여 확인할 수 있다.

 

HTTP/0.9 :

초기의 HTTP는 버전 번호가 존재하지 않았으나 이후 개발이 되면서 HTTP에 버전을 명시하였고

그와 구분하기 위하여 초기 단계의 HTTP에는 0.9라는 버전을 지정받게 되었다.

 

특징 : 

매우 단순하다는 특징을 가지고 있으며, 요청은 단일 라인으로 구성되어 있고

Request(요청)은 GET을 통한 리소스 요청이 유일했다.

 

HTTP에 헤더가 존재하지 않았으며, 이는 HTML 파일만 전송될 수 있다는 것이었다.

게다가 상태/오류를 나타내는 코드도 없었으며, 문제가 발생하면 해당 HTML 파일을

문제 해결을 위해 특정 인원에게 문제에 대한 설명과 함께 전송이 되는 것이 전부였다.

 

HTTP/1.0 :

HTTP의 1.0 버전은 이전 버전과 비교하여 브라우저 및 서버가 조금 더 융통성을 가지게 되었고 빠르게 확장되었다.

 

다음은 HTTP/1.0 버전에서 추가된 기능들이다.

  • 각 요청에 버전 정보가 추가되어 전송
  • 상태 코드(status code)도 응답(Response)의 시작 부분에 첨부되어 전송되어 해당 결과에 따른 동작이 가능하게 되었음
  • HTTP의 헤더가 요청과 응답을 위하여 도입되었으며, META data 전송을 허용하고 프로토콜 유연성 및 확장성을 증진
  • 새로운 HTTP 헤더로 HTML 파일 외의 다른 문서들도 전송이 가능하였음(Content-Type을 이용하여 가능)

 

HTTP/1.1 (표준 프로토콜) :

HTTP/1.1 버전은 HTTP/1.0 버전이 출시된 지 얼마 지나지 않아 1997년 초에 공개되었다.

HTTP/1.1 버전은 모호함을 명확하게 하고 많은 개선을 시행하였다.

 

다음은 HTTP/1.1 버전의 개선 사항들이다.

  • 커넥션을 재사용되게하여, 탐색된 원본 문서 내에 내장된 리소스들을 디스플레이하기 위하여 사용된 커넥션을 재사용하여 시간을 절약
  • 파이프라이닝을 추가하여 처음 요청에 대한 응답이 완전히 전송되기 전에 다음 요청을 전송 가능케 하였고, 커뮤니케이션 레이턴시를 낮춤
  • 청크 된 응답(Chunked Message) 지원
  • 추가적 캐시 제어 메커니즘 도입
  • 언어, 인코딩 또는 타입을 포함한 콘텐츠 협상이 도입 -> 서버/클라이언트 간 적합한 콘텐츠 협의 가능
  • Host 헤더로 동일 IP 주소에 다른 도메인을 Host할 수 있게 되었고 이가 서버 코로케이션을 가능하게 함

✽ Chunked Message: 큰 메세지를 분할하여 보내는 방식

 Server Co-location : 직접 서버를 관리하는 것이 아닌 IDC 시설의 공간을 임대하여 위탁 관리를 맡기는 서비스

 

HTTP/2 :

십수년을 지나면서, 웹 페이지는 복잡해지고 스크립트의 양 또한 점점 늘어갔다.

더 많은 데이터들이 요청되고 응답되며 이에 따라 HTTP/1.1 버전에서는 올바른 순서대로 전송되는 요청을 요구했다.

그에 따라 병렬 커넥션이라는 개념이 있었지만 복잡함과 그에 따른 많은 오버헤드 때문에 도입이 어려웠다.

 

2010년 전반기에 Google은 SPDY(스피디 - Google이 만든 조어) 프로토콜을 구현하여,

클라이언트와 서버 간의 데이터 교환을 대체할 수단을 개발하였다.

새로운 프로토콜은 응답성 증가 능력을 입증하고, 전송된 데이터 중복의 문제를 해결하며

HTTP/2의 프로토콜의 기초로써 기여하였다.

 

다음은 HTTP/2과 HTTP/1.1 버전의 차이점을 나타낸 것이다.

  • HTTP/2 프로토콜은 이진 프로토콜이며, 더 이상 읽을 수 없고 수작업을 만들어 낼 수 없으나 최적화 기술 구현이 가능하게 되었다.
  • 병렬 요청이 동일한 커넥션 상에서 다루어질 수 있는 다중화 프로토콜이며, 순서를 제거해 주고 HTTP/1.1의 제약사항을 막는다.
  • 전송된 데이터의 중복과 해당 데이터로 인한 불필요한 오버헤드를 제거하며, 연속된 요청 사이의 유사한 내용의 헤더를 압축시킨다.
  • 서버가 사전에 클라이언트 캐시를 Server Push라는 매커니즘에 의해 필요하게 될 데이터로 채워 넣도록 허용한다.

✽ Server Push : 클라이언트가 리소스를 요청하기 전에 서버가 클라이언트에 미리 리소스를 보내는 것

 

2015년에 공식 표준화된 HTTP/2는 큰 성공을 거두었고 그 다음 해에 새로운 확장을 도입하였다.

  • Alt-Svc를 지원하여 신분 증명의 개념과 자원의 위치를 분리
  • Client Hints를 도입하여 사용자 요구사항이나 서버의 하드웨어 제약사항 정보를 미리 교환
  • Cookie 내 보안 관련 접두사 도입은 보안 쿠키가 변경되지 않는다는 것을 보장

 

HTTP/3 (HTTP over QUIC) :

HTTP/2가 도입된지 얼마 지나지 않았지만 벌써 HTTP/3의 개발이 이루어지고 있다.

HTTP의 다음 버전인 HTTP/3는 전송 계층 부분에서 TCP/TLS 대신 QUIC을 사용한다는 특수성을 가지고 있다.

벌써 일부 웹사이트에서는 지원을 하고 있고 브라우저에 따라 추가 설정을 통하여 활성화를 시킬 수 있다.

 

다음은 HTTP/3의 개선 사항을 나타낸 것이다.

  • QUIC 기반의 Zero RTT(Round Trip Time)
  • 패킷 손실에 대한 대응이 빠르다.
  • 사용자 IP가 변경이 되어도 연결이 유지

✽ Zero RTT : 전송 계층과 암호화된 Hand-Shake를 하나로 통합하여 시간을 단축

 

위와 같은 사항들은 일반적인 웹 브라우저 사용 시 큰 차이점을 느끼지 못할 수 있으나 동영상 스트리밍과 같은 분야에서는 확연한 차이점을 느낄 수 있다.


<출처 : https://blog.cloudflare.com/ko-kr/even-faster-connection-establishment-with-quic-0-rtt-resumption-ko-kr/>

[기존의 TCP/TLS 방식의 HTTP]


<출처 : https://blog.cloudflare.com/ko-kr/even-faster-connection-establishment-with-quic-0-rtt-resumption-ko-kr/>

[QUIC 방식의 HTTP]

 

같은 Zero RTT라도 왕복 시간을 줄인 것을 확인할 수 있다.

반응형