[Kotlin&Spring] 5기 HTTP: Datatracker RFC9110 소개와 주요 용어

HTTP가 만들어진 의도를 알고 싶어서 문서를 보며 나름의 해석을 해보았다

 

 

1. Introduction

1.1 Purpose

HTTP(Hypertext Tranfer Protocol)는 무상태의 가족이며, 보편적인 인터페이스와 확장가능한 의미들, 그리고 네트워크를 베이스로 하는 텍스트 데이터 정보 시스템과의 상호작용을 유연하게 하는, 어플리케이션 수준의 요청과 응답 규약이다

 

HTTP는 제공된 리소스들의 종류에 독립적인 클라이언트에게 표준 인터페이스를 제공함으로써 어떻게 서비스가 구현되었는지에 대한 세부사항들을 숨긴다

이처럼 서버들은 각 클라이언트의 목적을 알 필요가 없다

따라서 요청들은 예정된 일련의 어플리케이션 단계 또는 클라이언트의 특정 종류와 연관되는 것 보다 독립되어있다고 고려된다

이는 보편적 목적의 구현을 많은 다른 맥락에서 효과적으로 사용되게 하며, 상호작용의 복잡성을 감소시키고, 시간에 따라 독립적인 진화를 가능하게 한다

 

HTTP는 또한 중간 매개의 규약으로써 설계되었다

이는 프록시들과 게이트웨이들이 HTTP가 아닌 정보 시스템을 더욱 보편화된 인터페이스로 해석하는 것을 가능하게 한다

 

이 유연성의 결과중 하나는 인터페이스 뒤에서 발생한 것에따라 규약이 결정될 수 없다는 것이다

대신에 HTTP는 소통의 문법, 받은 소통의 의도와 수신자의 예상된 행동을 정의하는데 제한되어 있다

만약 소통이 독립적이라고 고려되면, 성공적인 행동들은 서버에 의해 제공된 관찰 가능한 인터페이스에 응하는 변화를 반영해야 한다

그러나, 다수의 클라이언트들은 평행할 수 있고 아마 의도가 반대되어 행동할 수 있기 때문에 우리는 단순한 하나의 응답의 범위 너머로 그러한 변화들이 관찰가능하도록 요구할 수 없다

 

3.    Terminology and Core Concepts

3.3. Connections, Clients, and Servers

 

HTTP는 신뢰 가능한 수송수단-또는 "연결" 세션 계층-을 통해 운영되는 클라이언트와 서버의 규약이다

 

HTTP의 클라이언트(Client)는 하나 또는 여러 HTTP 요청을 보내는 목적으로 서버로의 연결을 만드는 프로그램이다

HTTP 서버(Server)는 HTTP 응답들을 보냄으로써  HTTP 요청을 서비스하기 위해 연결을 받아들이는 프로그램이다

 

클라이언트와 서버 용어들은 이 프로그램들이 특정한 연결에서 수행하는 역할을 위해서만 언급된다

같은 프로그램은 몇몇의 연결에는 클라이언트로, 다른 연결들에는 서버로써 역할할 수 있다

 

HTTP 는 무상태의 규약으로 정의되는데, 이는 각 요청 메시지의 의미가 독립적으로 이해될 수 있고 요청메세지에 대해 연결과 메세지들 간 관계는 그 메세지들을 해석하는 데에 영향이 없다

예를 들어 CONNECT 요청 또는 업그레이드된 헤더 영역을 가진 요청은 연결의 첫 메세지 뿐 아니라 언제나 발생할 수 있다

많은 구현들은 HTTP 의 무상태 설계에 의해 결정되는데 이는 프록시를 통한 HTTP 연결 또는  복수의 서버를 통한 동적 로딩 균형 요청을 위한 것이다

 

그에 따라, 서버는 연결이 보안되고 그 유저에게 특정되지 않는 한 같은 연결에 대한 두 요청을 절대  같은 유저로부터 왔다고 추정하지 않는다

몇몇의 표준적이지 않는 HTTP 확장자들은 이 요구를 위반한 것으로 유명하고 보안문제와 상호운용 문제로 이어졌다

 

3.4. Messages

 

HTTP 는 연결을 통해 메세지들을 교환하기 위한 무상태의 요청, 응답 규약이다

전송자와 수신자라는 용어들은 주어진 메세지들을 보내거나 받는 것의 각각의 구현체를 의미한다

 

클라이언트는 서버로의 요청을 메소드와 요청 타겟을 담은 요청 메세지의 형식으로 보낸다

요청은 요청 수정자, 클라이언트 정보, 그리고 대표하는 메타데이터, 메소드와 일치하는 프로세스를 의도 하는 내용, 내용을 보낼 때 정보를 교환할 트레일러 필드들을 위한 헤더 필드를 포함해야 한다

 

서버는 하나 또는 그 이상의 응답 메시지를 보냄으로써 클라이언트의 요청에 응답하는데 각각의 응답메세지는 상태 코드를 갖는다

응답은 또한 서버 정보, 리소스 메타데이터, 대표 메타데이터, 상태 코드와 일치하는 해석될 내용, 그리고 내용을 보낼 때 수집될 정보를 소통하기 위한 트레일러 필드들을 위한 헤더 필드를 포함해야한다

 

3.5. User Agents

 

유저 에이전트는 요청을 시작하는  다양한 클라이언트 프로그램들을 의미한다

 

가장 친숙한 형태의 유저 에이전트는 보편적 목적의 웹 브라우저이이다

하지만 이것은 구현체의 아주 작은 퍼센트 일 뿐이다

다른 흔한 유저 에이전트들은 spider(웹 크롤러)들, command-line tool들, 전광판들, 가전 기계들, 척도들, 전구들,  펌웨어 업데이트 스크립트들, 모바일 앱들, 그리고 다양한 형태와 크기의 소통 기계들을 포함한다

 

유저 에이전트가 되는 것은 요청 시점에 소프트웨어 에이전트와 직접적으로 소통하는 인간 유저가 있다는 것을 내포하고 있지 않다

많은 경우에 유저 에이전트는 백그라운드에서 실행하거나 후의 예상을 위해 그 결과를 저장(또는 흥미롭거나 오류가 있을 수 있는 결과의 일부만 저장)하기 위해 설치되거나 구성된다

예로 크롤러들은 관습적으로 시작 URI를 제공받고 텍스트 그래프로 웹을 크롤링할때 특정 행동을 따르도록 구성되어있다

 

많은 유저 에이전트들은 그들의 유저에게 상호적인 제안을 할 수 없고, 안 하도록 선택한다

또는 보안이나 사생활 우려에 대한 적절한 경고를 제공할 수 없고 안 하도록 선택한다

몇몇 이런 특정 요구들이 유저에게 에러를 보고한 경우에 오류 콘솔이나 로그 파일에서 관찰 가능한 것만이 그러한 보고에 알맞았다

이와 같이, 실행 전 유저에 의해 확인된 자동화된 행동의 요구들은 발전된 구성 선택, 실행 시점 선택지들, 또는 안전하지 않은 행동들을 간단히 피함을 통해 볼 수 있고, 확인은 만약 유저가 그 선택을 이미 했다면 어떠한 특정 유저 인터페이스 또는 평범한 프로세스의 방해를 내포하지 않는다

 

 

 

언어의 장벽이 있어 읽는 데 어려움이 있었지만 문서 내용이 생각보다 이해하기 쉽게 설명이 되어있었다

다음에는 request/response message 구성 부분을 자세히 읽어보고 싶다

배우면 배울수록 내가 많이 부족함을 느낀다

배운지 얼마 안 되었으니 좌절하지 말고 앞으로 배울게 많아 기쁘다고 생각하자 ~

화이팅 ~ !!

 

https://datatracker.ietf.org/doc/rfc9110/

RFC 9110: HTTP Semantics