Mdn web docs - HTTP를 통해 학습한 내용을 정리한 글입니다.
개요
HTTP(하이퍼텍스트 전송 프로토콜)은 HTML과 같은 하이퍼미디어 문서를 전송하기 위한 애플리케이션 계층 프로토콜이다. 클라이언트의 요청에 따라 통신하는 클라이언트-서버 모델을 따르며, 이전 요청의 세션 상태를 유지하지 않는 Stateless 프로토콜이다.
* 애플리케이션 계층 통신 네트워크에서 호스트가 사용하는 트로토콜과 인터페이스 방법을 지정하는 추상화 계층
* 프로토콜 컴퓨터 내부 혹은 컴퓨터 간 데이터의 교환 방식을 정의하는 규칙 체계 집합
* Stateless 동일한 연결 상에서 발생한 두 개의 요청 사이에 연결고리가 없음을 말한다. 쿠키를 통해 동일한 상태를 공유하는 세션을 생성한할 수 있다.
프록시
브라우저(클라이언트)와 서버 통신 간 여러 계층을 거치며 데이터를 전달되는데, 이 중 애플리케이션 계층에서 동작하는 것들을 프록시라고 부른다. 프록시는 캐싱, 필터링, 로드 밸런싱(여러 서버들이 서로 다른 요청을 처리하도록 허용), 인증(리소스에 대한 접근 제어), 로깅(이력 정보를 저장) 등의 다양한 기능을 수행할 수 있다.
연결
연결은 근본적으로 HTTP 영역 밖인 전송 계층에서 제어된다. 따라서 근본적인 전송 프로토콜을 요구하진 않지만, 신뢰가능하거나 손실이 없는 연결을 요구한다. 일반적인 전송 프로토콜 TCP / UDP 중 신뢰할 수 있는 TCP 표준에 의존한다.
통신 구조
- 클라이언트가 요청을 보내거나 응답을 받을 수 있는 TCP 연결을 연다.
- HTTP 메시지를 요청(GET)한다. HTTP/2 이후로는 프레임 속으로 캡슐화되어 전송되기 때문에 직접 읽는 것이 불가능하다. 그러나 기본적인 구조는 이전과 동일하다.
- 서버에 의해 전송된 응답을 읽어 들인다.
- 연결을 닫거나 다른 요청을 위해 재사용한다.
파이프라인이 활성화되면, 첫 번째 응답을 완전히 수신되지 않아도 여러 요청을 보낼 수 있다.
*HTTP 메시지 서버와 클라이언트 간 데이터가 교환되는 방식으로, 요청(Request)과 응답(Response) 두 자기 타입이 존재한다. ASCII로 인코딩된 텍스트로 구성된다.
흐름
HTTP/0.9
극히 단순한 HTTP의 초기 버전이다. 단일 라인으로 구성되는 요청이 GET 메서드로만 이루어졌으며, 파일 내용 자체를 응답받기 때문에 해석이 가능했다. 헤더 또한 존재하지 않았다. 이는 HTML 파일이 아닌 다른 유형의 문서는 전송될 수 없음을 의미한다.
GET /mypage.html
HTTP/1.0
이전 버젼에 비해 브라우저와 서버 모두 융통성을 가지도록 확장되었다. 각 요청 사이에 버전 정보가 첨부되었으며, 상태 코드를 통해 요청에 대한 성공 / 실패 여부를 확인할 수 있었다. 또한 헤더 개념이 도입되어 메타데이터 전송을 허용함으로써 프로토콜을 극도로 유연하고 확장 가능하게 만들어주었다.
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
<IMG SRC="/myimage.gif">
</HTML>
HTTP/1.1 - 표준 프로토콜
이전 버전의 모호한 부분을 명확하게 하고 많은 개선 사항을 도입하였다. 커넥션을 재사용할 수 있게 되어 자원을 절약하게 하였고, 파이프라이닝을 추가하여 첫 번째 요청에 대한 응답이 완전히 전송되기 전에 두 번째 요청을 가능케 하여 지연율을 낮추었다. Host 헤더가 추가되어 동일 IP주소에 대한 도메인을 호스트가 가능하게 되었다.
RESTful API
REST란 효율적, 안정적이며 확장 가능한 분산시스템을 가져올 수 있는 소프트웨어 아키텍쳐 디자인 제약의 집합이다. 그리고 그 제약들을 준수했을 때를 RESTful하다고 일컫는다. 이를 통해 브라우저나 서버의 갱신없이 데이터 탐색과 수정을 허용하는 API 제공이 가능해졌다. 그 중 서버 전송 이벤트가 웹소켓과 같은 API는 새로운 HTTP 헤더로 표준화되었다.
서버 전송 이벤트
전통적으로 웹페이지는 클라이언트-서버 통신을 따르지만, 서버 전송 이벤트는 웹페이지의 요청 없이 서버가 새로운 데이터를 보낼 수 있다. 이렇게 보내진 메시지는 웹페이지 내에서 DOM 이벤트 + 데이터로 다루게 된다.
웹 소캣
브라우저와 서버 간 인터랙티브 통신 세션을 설정할 수 있게 하는 기술이다. 웹 소켓 API를 통해 서버로 메시지를 보내고, 응답을 받기 위해 서버를 폴링하지 않고도 이벤트 중심 응답을 받을 수 있다.
HTTP/2
교환되는 데이터의 양과 크기가 증가함에 따라, 데이터를 이진화 및 최적화하여 전송하게 되었다. 또한 연속된 요청 사이의 유사한 내용들로 존재하는 헤더들을 압축시키고, 서버 푸쉬를 통하여 서버로 하여금 사전에 필요한 데이터를 채워넣도록 허용하였다.
외에도 허프만 코딩을 통한 데이터 압축, 데이터를 쪼개어 병렬 스트림으로 보냄으로써 패킷 지연 (HOL Blocking)을 방지할 수 있게 되었다.
연결 관리
Shorted-lived Connection
HTTP는 클라이언트와 서버 사이의 커넥션을 제공하는 TCP를 전송프로토콜로 이용한다. 초기 HTTP는 단일 모델을 제공했으며, 요청이 필요할 때마다 새로운 커넥션을 생성한 후 응답이 도착하면 연결을 닫는 단기 형태로 유지되었다.TCP 핸드셰이크는 지속적으로 연결되었을 때 효율적으로 작동하는데, 이러한 특징을 이용하지 않는 단기 커넥션 방식은 성능 상의 제약을 발생시키기 때문에, 비효율적인 모델 구조였음이 자명하다.
Keep-alive Connection
이전의 단점을 보완하여, HTTP/1.1에서는 일정 기간 연결을 열어놓고 여러 요청에 재사용하는 영속적인 커넥션 모델을 채택하였다. 이는 새로운 연결 간 발생하는 비용을 아끼고, TCP의 성능 향상 조건을 만족시킨다. 또한 해당 모델을 활용하여 파이프라이닝을 구현할 수 있다.이는 같은 연결에서 응답을 기다리지 않고 연속적으로 요청을 보내는 것으로, 지연을 회피하고자 사용된다. 그러나 실제로는 프록시와 서버들이 갖고 있는 제한 사항 때문에 범용적으로 활성화되지 못했다.
➡️ HTTP 접근 제어(CORS)부터 계속됩니다...
