HTTP Semantics (RFC 9110) 정리(1)

인터넷 서핑을 하다가 http에 대해 설명하는 rfc 문서를 발견했다.
여태 rfc가 대충 영어로 된 문서다 이정도는 알고 있었는데 한번도 제대로 읽어본적은 없었다.
어떤 내용일까 궁금해서 살짝 훑어봤는데 잘 정리되어있고 내용도 좋아서 힘들게 번역하면서 읽어보았다.

원문 -> RFC 9110

RFC란?

미국의 국제 인터넷 표준화기구에서 관리하는 네트워크 등의 인터넷 관련 기술, 연구 결과 등을 정리한 문서이다. 거의 모든 인터넷 표준는 RFC로 문서화되어있고 절차에 따라 등록하면 문서에 번호를 붙여 부른다.

참고 : Comments란-RFC의-역사-RFC-종류-RFC-표준화-절차

HTTP Semantics, RFC 9110

https://www.rfc-editor.org/rfc/rfc9110.html

1. 소개

1.1 목적

stateless이고, 어플리케이션 레벨의 request/response 구조의 프로토콜이다.
generic하고 확장 가능하고 네트워크 기반의 hypertext information systems와 유연하게 상호작용하기 위해 자체 설명 가능한 메세지를 사용한다.

1.2 역사와 진화

HTTP/0.9

1990년에 도입되어 world wide web의 주요 정보 전달 프로토콜이었다.
단일 메서드 GET을 이용해 대기 시간이 짧은 요청을 위한 메커니즘을 가졌었다.

HTTP/1.0

header 개념 추가
상태코드를 response에 추가

HTTP/1.1

기존 구문과 호환성을 유지하며 프로토콜의 기능을 개선하고 확장성 및 상호 운용성을 향상시키도록 설계됨
1995년에 도입되고 1997년에 표준 트랙에 게시됨. 1999년과 2014년에 개정됨
길이 기반 데이터 구분자, 캐시 제어, 연결 지속 (지정 시간동안 커넥션을 닫지 않음)

HTTP/2

효율적인 필드 압축, 서버 푸시 (단일 요청에 여러응답)
1.1 버전 확장

HTTP/3

QUIC를 사용해 동시 메세지에 더 큰 독립성 제공
QUIC → 구글에서 개발한 UDP 기반의 전송 프로토콜
이전 버전들은 TCP를 사용하고 있었음

참고 : velog - HTTP (1) - version 별 특징 (0.9 / 1.0 / 2.0 / 3.0)

3. 용어 및 핵심 개념

3.1 자원(resources)

HTTP 요청의 대상을 자원이라고 함.
HTTP는 리소스의 특성을 제한하지 않음. 리소는 대부분 URI에 의해 식별됨

HTTP의 설계 목표중 하나는 요청 구문으로부터 자원 식별을 분리하는것이고, 이것은 요청 method 및 request header으로 요청 구문을 표현함으로써 해결가능하다.

3.2 표현 (representations)

자원의 과거, 현재 또는 원하는 상태를 반영하기 위한 정보 (?)
표현은 표현 메타데이터 세트와 표현 데이터 스트림으로 구성됨 (표현 헤더 + 표현 데이터)

HTTP는 리소스 자체를 전송하긴 하지만 균일한 인터페이스 뒤에 정보를 은닉할 수 있다. (information hiding → 암호화)

3.3 연결, 클라이언트 및 서버

HTTP는 신뢰가능한 전송 계층 또는 세션 계층 연결을 통해 작동하는 클라이언트/서버 프로토콜이다.
HTTP 클라이언트 → HTTP 요청을 전송하기 위해 서버에 대한 연결을 설정하는 프로그램이다.
HTTP 서버 → HTTP 요청을 처리하고 HTTP 응답을 전송하기 위해 연결을 수락하는 프로그램이다.
동일한 프로그램이 일부 연결에서는 클라이언트로 작동하고 다른 연결에서는 서버로 작동할 수 있다.

HTTP는 연결과 메세지간의 관계가 메세지 해석에 영향을 미치지 않는 stateless protocol이다.

3.4 메세지

HTTP는 연결을 통해 메세지를 교환하기 위한 프로토콜이다.
메세지는 보내거나 받는 모든 메세지를 뜻한다.

요청 메세지는 표현 메타데이터를 위한 헤더 필드, 처리할 컨텐츠, 요청 수정자, 전송 중에 수집된 정보를 전달하기 위한 트레일러 필드가 포함될 수 있다.
응답 메세지는 상태 코드를 포함하고 하나 이상일 수 있다. 서버 정보, 리소스 메타데이터, 상태 코드에 따라 해석될 컨텐츠, 컨텐츠를 보내는 동안 수집된 정보를 전달하기 위한 트레일러 필드가 포함될 수 있다.

3.5 사용자 에이전트 (UA, User Agent)
요청을 시작하는 클라이언트 프로그램이다.
웹사이트가 가장 친숙하지만 극히 일부이다. 사용자 에이전트에는 가전 제품, 저울, 전구, 모바일 앱 등 다양한 통신 장치가 포함된다.

3.6 origin 서버

주어진 대상 리소스에 대해 응답을 할 수 있는 프로그램을 뜻함.

3.7 중개자 (Intermediaries)

HTTP를 사용할때 연결 체인을 사용할 수 있다.
HTTP 중개자에는 프록시, 게이트웨이, 터널로 세가지 형태가 있다.

---

> > > UA =========== A =========== B =========== C =========== O < <

사용자 에이전트와 오리진 서버 사이에 3개의 중개자(A,B,C)가 있다.
채널을 이용하는 요청 또는 연결은 4개의 개별 연결을 통과한다.
HTTP 통신 옵션은 가장 가까운 연결에만 적용될 수 있고, 체인의 엔드포인트에만 적용될 수도 있고 모든 연결에 적용될 수도 있다. 각 참가자는 여러 개의 연결에 동시로 참여할 수 있다.

인바운드 → 오리진 서버를 향한 것
아웃바인드 → 사용자 에이전트를 향한 것

프록시

특정 유형의 절대 URI 요청을 수신하고 HTTP 인터페이스로 변환해 요청을 만족시키려고 클라이언트가 선택하는 메세지 전달 에이전트이다.
보안 서비스, 공유 캐싱을 위해 사용한다.

게이트웨이 (리버스 프록시)

아웃바운드 연결에 대한 오리진 서버 역할을 하지만
수신된 요청을 변환해 다른 서버로 인바운드를 전달함

레거시 또는 신뢰할 수 없는 서비스를 캡슐화 하거나 accelerator 캐싱으로 서버 성능 개선, 여러 시스템에 걸친 HTTP 서비스 분할, 로드 밸런싱을 할때 사용함

터널

메세지를 변경하지 않고 두 연결 사이에서 전달자 역할을 한다. 터널이 활성화되면 터널은 HTTP 통신의 당사자로 간주되지 않는다.

3.8 캐시
동일한 요청에 대한 응답 시간과 네트워크 대역폭 소비를 줄이기 위해 사용한다.
모든 클라이언트나 서버는 캐시를 사용할 수 있지만 터널 역할을 수행하는 동안에는 캐시를 사용할 수 없다.

캐시는 연결 체인의 참가자 중 하나가 해당 요청에 적용 가능한 캐시된 응답을 가진 경우 요청/응답 체인이 단축될 수 있다.

             > >
       UA =========== A =========== B - - - - - - C - - - - - - O
               < <

B가 해당 요청에 대한 캐시된 응답을 가지고 있어 요청이 Origin 서버까지 가지 않고 바로 UA로 간다.