An overview of HTTP == '원본'

번역기를 사용했고 불필요하다고 생각되거나 해석이 어색한 부분은 수정했습니다.

저를 포함한 모든 백엔드 개발자 분들에게 도움이 됐으면 좋겠습니다.

HTTP 개요

HTTP는 리소스를 가져오기 위한 프로토콜 입니다. 이는 웹에서 이뤄지는 모든 데이터 통신의 기초이며 '클라이언트-서버' 프로토콜입니다. 이는 요청이 일반적으로 웹 브라우저에 의해 시작됨을 의미합니다.

웹 페이지는 다양한 리소스로 구성되어있습니다. 클라이언트와 서버는 메시지로 통신합니다. 일반적으로 웹 브라우저와 같은 '클라이언트'가 보내는 메시지를 '요청'이라고 하고 '서버'가 보내는 메시지를 '응답'이라고 합니다.

HTTP는 애플리케이션 계층 프로토콜입니다. 1990년대 초에 설계된 HTTP는 확장 가능한 프로토콜입니다. TCP 또는 TLS(Transport Layer Security)로 암호화된 TCP 연결을 통해 전송되는 애플리케이션 계층 프로토콜입니다. 확장성으로 인해 하이퍼텍스트 문서뿐만 아니라 이미지 및 비디오를 가져오거나 HTML과 같이 서버에 콘텐츠를 가져오는데 사용됩니다.

HTTP 시스템의 구성 요소

HTTP는 클라이언트-서버 프로토콜입니다. 요청은 사용자 에이전트(또는 이를 대신하는 프록시)라는 하나의 엔티티에 의해 전송됩니다. 대부분의 경우 사용자 에이전트는 웹 브라우저이지만 웹을 크롤링하는 프로그램과 같이 무엇이든 될 수 있습니다.

각 요청은 서버로 보내지고 서버는 이를 처리하고 응답합니다. 클라이언트와 서버 사이에는 게이트웨이 또는 캐시 역할을 하는 프록시라고 하는 수많은 엔티티가 있습니다.

실제로 브라우저와 서버 사이에는 라우터, 모뎀 등 많은 컴퓨터가 있습니다. 그것들은 계층화된 웹 덕분에 네트워크 및 전송 계층에 숨겨져 있습니다. HTTP는 애플리케이션 계층에서 맨 위에 있습니다. 그렇기 때문에 다른 계층은 대부분 HTTP와 관련이 없습니다.

클라이언트: 사용자 에이전트

사용자 에이전트는 사용자를 대신하여 작동하는 모든 도구입니다. 이 역할은 주로 웹 브라우저가 수행하지만 엔지니어와 웹 개발자가 애플리케이션을 디버그하는 데 사용하는 프로그램에서도 수행할 수 있습니다.

브라우저는 항상 요청을 시작하는 엔티티입니다. 그것은 결코 서버가 아닙니다.

웹 페이지를 표시하기 위해 브라우저는 페이지를 나타내는 HTML 문서를 요청합니다. 그런 다음 이 파일을 분석하여 실행 스크립트, 표시할 레이아웃 정보(CSS) 및 페이지에 포함된 하위 리소스(일반적으로 이미지 및 비디오)를 추가적으로 요청합니다. 그런 다음 웹 브라우저는 이러한 리소스를 결합하여 완전한 웹 페이지를 사용자에게 제공합니다. 브라우저에서 실행되는 스크립트는 이후 단계에서 더 많은 리소스를 가져올 수 있으며 브라우저는 그에 따라 웹 페이지를 업데이트합니다.

웹 페이지는 하이퍼텍스트 문서입니다. 즉, 표시된 콘텐츠의 일부가 링크로 활성화되어(일반적으로 마우스 클릭으로) 새 웹 페이지를 가져와 사용자가 웹을 탐색할 수 있습니다. 브라우저는 이러한 지시를 HTTP 요청으로 변환하고 HTTP 응답을 추가로 해석하여 사용자에게 제공합니다.

웹 서버

통신 채널의 반대편에는 클라이언트가 요청한대로 페이지를 제공하는 서버가 있습니다. 서버는 반드시 하나일 필요는 없으며 여러 서버 인스턴스가 동일한 시스템에서 호스팅 될 수 있습니다.

프록시

웹 브라우저와 서버 사이에서 수많은 컴퓨터가 HTTP 메시지를 중계합니다. 애플리케이션 계층에서 작동하는 것을 일반적으로 '프록시' 라고 합니다. 프록시는 어떤 식으로든 받은 요청을 그대로 전달하거나 특수한 기능을 수행할 수 있습니다. 프록시는 다음과 같은 다양한 기능을 수행할 수 있습니다.

• 캐싱(캐시는 브라우저 캐시와 같이 공개 또는 비공개일 수 있음)
• 필터링(예: 바이러스 백신 검사 또는 자녀 보호 기능)
• 로드 밸런싱(여러 서버가 서로 다른 요청을 처리할 수 있도록 허용)
• 인증(다른 리소스에 대한 액세스를 제어하기 위해)
• 로깅(로그 정보 저장)

HTTP는 간단하다

HTTP는 일반적으로 사람이 읽을 수 있도록 설계되었습니다. HTTP 메시지는 사람이 읽고 이해할 수 있으므로 개발자에게는 더 쉬운 테스트 환경을 제공하고 신규 사용자에게는 복잡성을 줄입니다.

HTTP는 확장 가능합니다.

HTTP/1.0에 도입된 HTTP 헤더를 사용하면 이 프로토콜을 쉽게 확장하고 실험할 수 있습니다. 새로운 기능은 클라이언트와 서버 간의 간단한 합의에 의해 추가될 수도 있습니다.

HTTP는 stateless이지만 sessionless는 아닙니다.

HTTP는 'stateless' 입니다. 모든 요청이 독립적입니다. HTTP 자체의 핵심은 stateless지만 HTTP 쿠키는 세션을 사용합니다. 헤더 확장성을 이용하여 HTTP 쿠키를 추가하여 각 HTTP 요청에 동일한 컨텍스트를 제공할 수 있습니다(예: 로그인).

HTTP와 연결

연결은 전송 계층에서 제어되므로 근본적으로 HTTP의 범위를 벗어납니다. HTTP는 연결지향적일 필요가 없습니다. 대신 신뢰할 수 있거나 메시지가 손실되지 않아야 합니다(최소한 이러한 경우 오류가 표시됨). 인터넷에서 가장 일반적인 두 가지 전송 프로토콜 중에서 TCP는 신뢰할 수 있고 UDP는 그렇지 않습니다. 따라서 HTTP는 TCP에 의존합니다.

클라이언트와 서버가 HTTP 요청/응답을 교환하기 전에 TCP 연결을 설정해야 하며 이 프로세스는 여러 번 반복해야 합니다. HTTP/1.0의 기본 동작은 각 HTTP 요청/응답에 대해 별도의 TCP 연결을 하는 것입니다. 이것은 여러 요청을 연속적으로 받을 수 없어 효율적이지 못합니다.

이 결함을 보완하기 위해 HTTP/1.1은 파이프라이닝 및 영구적인 연결을 도입했습니다. TCP 연결은 헤더를 사용하여 부분적으로 제어할 수 있습니다. HTTP/2는 한 단계 더 나아가 단일 연결을 통해 메시지를 다중화하여 연결을 효율적으로 유지하도록 돕습니다.

HTTP로 제어할 수 있는 것

HTTP의 이러한 확장 가능한 특성은 시간이 지남에 따라 웹의 더 많은 제어와 기능을 제공했습니다.

다음은 HTTP로 제어할 수 있는 일반적인 기능 목록입니다.

• 캐싱: 문서가 캐시되는 방식은 HTTP로 제어할 수 있습니다. 서버는 캐시할 대상과 기간을 프록시와 클라이언트에 지시할 수 있습니다. 클라이언트는 저장된 문서를 무시하도록 중간 캐시 프록시에 지시할 수 있습니다.
• 원본 제약 완화(Relaxing the origin constraint): 스누핑 및 기타 개인 정보 침해를 방지하기 위해 웹 브라우저는 웹 사이트 간에 엄격한 분리를 시행합니다. 동일한 출처의 페이지만 웹 페이지의 모든 정보에 액세스할 수 있습니다(*). 이러한 제약이 서버에 부담이 되지만 HTTP 헤더는 서버 측에서 이러한 엄격한 분리를 완화하여 페이지가 다른 도메인에서 가져온 데이터로 재구성될 수 있습니다.(**)
• 인증: 일부 페이지는 특정 사용자만 액세스할 수 있도록 보호될 수 있습니다. 인증은 WWW-Authenticate나 비슷한 헤더를 사용하는 HTTP나 HTTP 쿠키를 사용하여 특정 세션을 설정함으로써 제공받을 수 있다.
• 프록시 및 터널링: 서버 또는 클라이언트는 종종 인트라넷에 위치하며 실제 IP 주소를 숨깁니다. 그런 다음 HTTP 요청은 프록시를 통해 네트워크로 넘어갑니다.
• 세션: HTTP 쿠키를 사용하면 요청을 서버 세션과 연결할 수 있습니다. 이것은 기본 HTTP가 비연결 프로토콜임에도 불구하고 세션을 생성합니다.

(*) - 'Relaxing the origin constraint'를 이해하기 전에 'The Same Origin Policy'를 이해하면 좋습니다. 'The Same Origin Policy'
(**) - 'naver.com'안에서 'www.naver.com'와 'comic.naver.com'이 같은 리소스를 공유하는 것.

HTTP 흐름

클라이언트가 서버와 통신하려는 경우 다음 단계를 수행합니다.

1. TCP 연결: TCP 연결은 하나 이상의 요청을 보내고 응답을 받는 데 사용됩니다. 클라이언트는 새 연결을 열거나 기존 연결을 재사용하거나 서버에 대한 여러 TCP 연결을 열 수 있습니다.

2. HTTP 메시지 보내기: HTTP 메시지(HTTP/2 이전 버전)는 사람이 읽을 수 있습니다. HTTP/2를 사용하면 이러한 간단한 메시지가 캡슐화되어 직접 읽을 수 없지만 구조는 동일하게 유지됩니다.
   GET / HTTP/1.1
   Host: developer.mozilla.org
   Accept-Language: fr

3. 다음과 같이 서버에서 보낸 응답을 읽습니다.
   HTTP/1.1 200 OK
   Date: Sat, 09 Oct 2010 14:28:02 GMT
   Server: Apache
   Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
   ETag: "51142bc1-7449-479b075b2891b"
   Accept-Ranges: bytes
   Content-Length: 29769
   Content-Type: text/html

4. 추가 요청을 위해 연결을 닫거나 재사용합니다.

HTTP 파이프라이닝이 활성화되면 첫 번째 응답이 완전히 수신될 때까지 기다리지 않고 여러 요청을 보낼 수 있습니다. HTTP 파이프라이닝은 HTTP/2에서 보다 강력한 멀티플렉싱 요청으로 대체되었습니다.

HTTP 메시지

HTTP/1.1 및 이전 버전에 정의된 HTTP 메시지는 사람이 읽을 수 있습니다. HTTP/2에서 이러한 메시지는 이진 구조인 프레임에 포함되어 헤더 압축 및 다중화와 같은 최적화를 허용합니다. HTTP/2 메세지를 전송하더라도 가상으로 HTTP/1.1로 재구성합니다. 따라서 HTTP/1.1 형식의 HTTP/2 메시지를 읽을 수 있습니다.

HTTP 메시지에는 요청/응답이 있으며 각각 고유한 형식이 있습니다.

요청은 다음과 같이 구성됩니다.

Method: HTTP 메소드(일반적으로 'GET'이나 'POST'같은 동사 혹은 'OPTIONS'나 'HEAD'같은 명사) 클라이언트가 원하는 작업을 정의한다.
일반적으로 클라이언트는 리소스를 가져오거나('GET') 데이터를 전달하기 원하지만('POST') 다른 메소드를 사용하여 다른 작업을 할 수도 있습니다.

Path: 가져올 리소스의 경로입니다. 프로토콜(http://), 도메인(developer.mozilla.org) 그리고 포트번호(80)가 제거된 URL입니다.

Version of the protocol: HTTP 프로토콜의 버전입니다.

Headers: 서버에 대한 추가 정보를 전달하는 헤더 입니다.

Body: 서버에게 건내줄 리소스입니다.

응답은 다음과 같이 구성됩니다.

Version of the protocol: 서버가 사용하는 HTTP 프로토콜의 버전입니다.

Status code: 요청의 성공 여부와 이유를 나타내는 상태 코드 입니다.

Status message: 상태 코드에 대한 짧은 설명입니다.

Headers: 요청 헤더와 같은 HTTP 헤더입니다.

Body: 선택적으로 요청한 리소스가 포함된 본문입니다.

HTTP 기반 API

HTTP 기반으로 가장 많이 사용되는 API는 사용자 에이전트와 서버 간의 데이터 교환에 사용할 수 있는 'XMLHttpRequest' API 입니다. 최신 Fetch API은 더 강력하고 유연한 기능과 함께 동일한 기능을 제공합니다.

또 다른 API인 server-sent events는 서버가 HTTP를 전송 메커니즘을 사용하여 클라이언트에 이벤트를 전송할 수 있는 단방향 서비스입니다. 클라이언트는 EventSource 인터페이스를 사용하여 연결하고 이벤트 핸들러를 확립합니다. 클라이언트 브라우저는 HTTP 스트림에 도착한 메시지를 적절한 이벤트 객체로 자동 변환하여 이벤트 유형에 등록된 이벤트 핸들러에 전달하거나 유형이 정해지지않은 경우 'onmessage' 이벤트 핸들러로 전달합니다.

결론

HTTP는 사용하기 쉬운 확장 가능한 프로토콜입니다. 헤더를 추가하는 기능과 결합된 클라이언트-서버 구조를 통해 HTTP는 웹의 확장된 기능과 함께 발전할 수 있습니다.

HTTP/2는 성능을 향상시키기 위해 HTTP 메시지를 프레임에 포함함으로써 약간의 복잡성이 추가되었지만 메시지의 기본 구조는 HTTP/1.0 이후로 동일하게 유지되었습니다. 세션 흐름은 단순하게 유지되어 간단한 HTTP 메시지를 모니링하거나 디버깅 할 수 있습니다.