Gitsunmin

TIL

TIL
(=Today I Learned)

Basic

HTTP는 확장 가능한 *프로토콜로 리소스 및 URI(Uniform Resource Identifier), 간단한 메시지 구조, 클라이언트-서버 통신 흐름과 같은 개념에 의존합니다. 이러한 기본 개념을 토대로, 새로운 HTTP 메서드나 헤더의 생성을 통해 새로운 기능과 새로운 의미를 더하는 수많은 확장들이 수년간 생겨났습니다.

  • *프로토콜은 컴퓨터 내부에서, 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계입니다. 기기 간 통신은 교환되는 데이터의 형식에 대해 상호 합의를 요구합니다. 이런 형식을 정의하는 규칙의 집합을 프로토콜이라고 합니다.

HTTP 개요

HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜입니다. HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, *클라이언트-서버 프로토콜이기도 합니다.

  • *클라이언트: 특정 자원을 요청하는 쪽. (웹 브라우저, 스마트폰, 태블릿, 데스크톱 애플리케이션 등)
  • *서버: 클라이언트의 요청에 응답으로 자원을 제공하는 쪽. (웹 서버, 데이터베이스 서버, 애플리케이션 서버 등)
  • *클라이언트-서버 프로토콜이란 (보통 웹브라우저인) 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미합니다. 하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 불러온(fetched) 하위 문서들로 재구성됩니다.

1990년대 초에 설계된 HTTP는 거듭하여 진화해온 확장 가능한 프로토콜입니다. HTTP는 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상으로는 무엇이든 사용할 수 있으나 *TCP 혹은 암호화된 TCP 연결인 *TLS를 통해 전송됩니다. HTTP의 확장성 덕분에, 오늘날 하이퍼텍스트 문서 뿐만 아니라 이미지와 비디오 혹은 HTML 폼 결과와 같은 내용을 서버로 포스트(POST)하기 위해서도 사용됩니다. HTTP는 또한 필요할 때마다 웹 페이지를 갱신하기 위해 문서의 일부를 가져오는데 사용될 수도 있습니다.

  • TCP: Transmission Control Protocol. 인터넷 상에서 데이터를 메세지의 형태로 보내기 위해 IP와 함께 사용하는 프로토콜입니다. TCP는 IP와 함께 TCP/IP의 기본 프로토콜로서, IP가 데이터의 배달을 처리한다면 TCP는 패킷의 추적 및 전송을 담당합니다.
  • TLS: Transport Layer Security. 네트워크 통신에서 주고받는 데이터를 암호화하는 목적으로 설계된 암호화 프로토콜입니다.

HTTP의 기본

우리가 사용하는 인터넷 브라우저는 HTTP를 통해 서버로부터 웹 페이지를 가져옵니다. 브라우저는 사용자가 요청한 페이지의 주소를 입력받아, 서버에게 해당 페이지를 가져오라고 요청합니다. 서버는 요청받은 페이지를 찾아서 브라우저에게 보내줍니다. 이때 서버는 요청받은 페이지를 찾지 못했을 수도 있습니다. 이럴 경우 서버는 사용자에게 404 Not Found라는 메시지를 보내줍니다.

이러한 일련의 과정은 위에서 설명하였듯이 HTTP 프로토콜을 통해 이루어집니다.

HTTP에서 제어할 수 있는 것

HTTP의 확장 가능한 특성은 수년 간에 걸쳐 웹의 점점 더 많은 기능들을 제어하도록 허용되어 왔습니다. 캐시 혹은 인증 메서드는 HTTP에 초기부터 제어해왔던 기능이며, 반면에 origin 제약사항을 완화시키는 조치는 2010년에 들어서 추가되었습니다.

HTTP는 또한 새로운 기능을 추가하기 위해 확장되었습니다. 예를 들어, HTTP/1.1은 *쿠키와 *범용 리소스 식별자(URI)를 도입했으며, HTTP/2는 *서버 푸시와 *헤더 압축을 도입했습니다. 이러한 확장들은 HTTP의 기본적인 특성을 확장하거나, 더 나은 성능을 위해 새로운 기능을 추가하는 데 사용됩니다.

  • *쿠키: 서버가 클라이언트의 요청에 대해 HTTP 헤더에 Set-Cookie를 통해 쿠키를 설정하면, 클라이언트는 이후 요청 시 HTTP 헤더에 Cookie를 포함하여 서버에게 쿠키를 전송합니다. 이를 통해 서버는 클라이언트를 식별하고, 클라이언트의 상태를 유지할 수 있습니다.
  • *범용 리소스 식별자(URI): 인터넷에 있는 자원을 나타내는 유일한 주소입니다. URI는 URL과 URN으로 나뉩니다. URL은 리소스의 위치를 나타내고, URN은 리소스의 이름을 나타냅니다.
  • *서버 푸시: 서버가 클라이언트의 요청에 대해 필요한 리소스를 클라이언트에게 미리 전송하는 기능입니다. 이를 통해 클라이언트는 서버로부터 리소스를 요청하지 않아도 되므로, 페이지 로딩 시간을 단축할 수 있습니다.
  • *헤더 압축: HTTP/2에서 도입된 기능으로, 헤더를 압축하여 전송함으로써 네트워크 대역폭을 절약할 수 있습니다.
  • *HTTP/1.1, HTTP/2: HTTP의 버전을 나타냅니다. HTTP/1.1은 1997년에 표준으로 제정되었으며, HTTP/2는 2015년에 표준으로 제정되었습니다.
  • *HTTP 헤더: HTTP 요청이나 응답에 대한 부가적인 정보를 담고 있는 헤더입니다. 헤더는 키-값 쌍으로 이루어져 있으며, 헤더의 종류에 따라 요청 헤더와 응답 헤더로 나뉩니다.

HTTP에서는 아래와 같은 기능을 제어할 수 있습니다.

  • 캐시: HTTP로 문서가 캐시되는 방식을 제어할 수 있습니다. 서버는 캐시 대상과 기간을 프록시와 클라이언트에 지시할 수 있고 클라이언트는 저장된 문서를 무시하라고 중간 캐시 프록시에게 지시할 수 있습니다.
  • origin 제약사항을 완화하기: *스누핑과 다른 프라이버시 침해를 막기 위해, 브라우저는 웹 사이트 간의 엄격한 분리를 강제합니다. 동일한 origin으로부터 온 페이지만이 웹 페이지의 전체 정보에 접근할 수 있죠. 그런 제약 사항은 서버에 부담이 되지만, HTTP 헤더를 통해 그것을 완화시킬 수 있습니다. 그런 덕분에 문서는 다른 도메인으로부터 전달된 정보를 패치워크할 수 있습니다(그렇게 하려면 어떤 경우에 보안과 관련된 사항이 있을 수도 있습니다).
  • 인증: 어떤 페이지들은 보호되어 오로지 특정 사용자만이 그것에 접근할 수도 있습니다. 기본 인증은 HTTP를 통해 WWW-Authenticate (en-US) 또는 유사한 헤더를 사용해 제공되거나, HTTP 쿠키를 사용해 특정 세션을 설정하여 이루어질 수도 있습니다.
  • 프록시와 터널링: 서버 혹은 클라이언트 혹은 그 둘 모두는 종종 인트라넷에 위치하며 다른 개체들에게 그들의 실제 주소를 숨기기도 합니다. HTTP 요청은 네트워크 장벽을 가로지르기 위해 프록시를 통해 나가게 되죠. 모든 프록시가 HTTP 프록시는 아닙니다. 예를 들면 SOCKS 프로토콜은 좀 더 저수준에서 동작합니다. FTP와 같은 다른 프로토콜도 이 프록시를 통해 처리될 수 있습니다.
  • 세션: 쿠키 사용은 서버 상태를 요청과 연결하도록 해줍니다. 이것은 HTTP가 기본적으로 상태없는 프로토콜임에도 세션을 만들어주는 계기가 됩니다. 이것은 e-커머스 쇼핑 바구니를 위해서 유용할 뿐만 아니라 사용자 구성을 허용하는 모든 사이트에 대해서 유용합니다.