Network

HTTP The Definitive Guide - 01. Overview of HTTP

깡구_ 2022. 10. 13. 17:23

title: HTTP The Definitive Guide - 01. Overview of HTTP
date: 2022-10-13
tags:

  • Network
  • HTTP



Introduction

HTTP The Definitive Guide




GDSC에서 해당 서적을 통해 HTTP를 공부하는 스터디에 참가하게 되었다.
HTTP 이전의 내용에 대한 지식도 부족하지만, 이 부분은 개인적으로 공부하며 채울 예정이다.
이번 Chapter는 01장 Overview of HTTP 이다.


Purpose

HTTP에 대한 전반적인 내용을 들여다본다.


Background of HTTP

HyperText System 구축이 진행되면서 HTTP가 만들어졌다.
해당 시스템은 4가지의 요소로 구성되었다.

  • HyperText 문서를 나타내는 텍스트 형식인 HTML (HyperText Markup Language)
  • 이러한 문서들을 교환하기 위한 TCP/IP 기반의 Protocol인 HTTP (HyperText Transfer Protocol)
  • 이러한 문서들을 Client에 그리기 위한 최초의 Web Browser인 WWW (World Wide Web)
  • 이러한 문서들에 접근하기 위한 서버의 최초 버전인 httpd
    초기 HTTP는 HTML의 전송만 가능하였으며, 시간이 지나며 여러 형식의 Resource를 전송할 수 있으며 많은 기능이 발전되었다.

Web Resource

Web Server는 Web Resource를 호스팅하여 유저에게 보여준다.
텍스트나 HTML, MS Word, PDF, Image, Video 등 많은 파일들을 호스팅할 수 있다.
유저에 따라 다른 동작을 하는 동적 Program이나 카메라를 이용한 Video, 주식 거래 등과 같은 동적 파일도 호스팅이 가능하다.


호환되는 파일이 다양하기에 브라우저가 매우 똑똑하거나, 내부적으로 어떤 파일인지 알려주어야한다.
이를 위해 MIME (Multipurpose Internet Mail Extensions) Type이 도입되었다.
HTTP 통신시 MIME Type을 명시하여 수신자가 별도의 처리 없이 명시된 MIME Type에 맞게 처리를 할 수 있다.


URI has URL & URN

흔히 URL이라 사용하는 것은 유저에게 친숙한 방식이지만, 이것이 제일 큰 개념은 아니다.
URI (Uniform Resource Identifier)라는 큰 개념이 존재하며, 이 안에 URL (Uniform Resource Locator)와 URN (Uniform Resource Name)이 존재한다.
URI는 Web Server를 식별하는 유일한 식별자이며, 이 식별자 중 URL과 URN이 존재하는 것이다.


URL은 www.google.com과 같이 일반적으로 사용하는 인터넷 주소이다. 위치를 이용하여 식별한다.
이는 google의 host를 이용하여 Web에 접근하는 것이며, 많은 정보가 생략되었지만 자체적으로 정보를 채운다.
실제 URL은 아래와 같은 형식으로 구성되어 있다.
scheme://user:password@host:port/path?query#fragment

  • scheme은 Protocol이다. Web에서 http 혹은 https를 주로 사용한다.
  • user:password의 경우, 일반적으로 보안의 문제때문에 잘 사용하지 않는다.
  • host는 www.google.com 부분이다. 유저들이 사용하기 편하게 되어있으며, 이는 DNS를 거쳐 IP의 형태로 변환된다.
  • port는 명시하지 않을 경우, 각 Protocol의 고유 Port를 사용한다. HTTP의 경우 80번 Port를 사용한다.
  • path?query 부분은 연결하는 Server에서 접근하고자 하는 대상에 대한 정보이다.
  • #fragment 부분은 대상의 정보 중 특정 정보를 지정하는 것이다.
    URN은 URL이 아닌 불변성을 가지는 식별 방법이며, 잘 사용하지 않는다. 고유한 이름을 이용하여 식별한다. `urn:ietf:rfc:2141` 혹은 `urn:isbn:12345` 와 같이 사용한다.

Transaction

HTTP는 Transaction을 수행하여 Resource를 주고받는다.
송신자는 수신자에게 HTTP Method와 함께 필요한 정보들을 담아 Request를 하며, 수신자는 처리 결과 및 필요한 정보들을 담아 Response한다.


각 Message는 Start Line, Header, Body로 구분할 수 있다.
Start Line에는 Method 및 대상 정보, 그리고 HTTP 버전이 담겨있다.
Header에는 이름이나 값, MIME Type 등에 대한 정보들을 담을 수 있다. 필요한 정보만 담으며, 필요하지 않다면 비어있을 수 있다.
Body에는 전달하고자 하는 Resource가 담긴다. Start Line과 Header의 Resource만 사용할 수도 있으며, Resource가 클 경우 Body를 이용한다고 볼 수 있다.
Body에 Resource를 담을 경우 보안이 조금 좋아지지만, 암호화를 하지 않다면 보안이 낮은건 여전하다.


HTTP Method & Status Code

주로 사용하는 Method는 다음과 같다.

  • GET - 특정 대상의 정보 혹은 Resource를 요청한다.
  • POST - GET과 유사하지만 Resource를 새로 생성할 때 사용한다. 동일한 Resource를 전송하더라도 새로운 Resource를 계속하여 생성한다. 멱등하지 않다.
  • PUT - 데이터를 수신자의 Resource에 생성 혹은 업데이트할 때 사용한다. 동일한 Resource를 전송하면 동일한 Resource에 대한 처리를 반복한다. 멱등하다.
  • DELETE - 특정 대상의 정보 혹은 Resource를 삭제한다.
    이 외에도 Method가 다양하며, Chapter 03에서 자세히 다룬다.
    Status Code는 Method의 결과를 나타낸다. 동일하게 많은 Status가 존재하며, 주로 볼 수 있는 Status Code는 다음과 같다. 200 - 처리가 무사히 끝난 것이다. 가장 보고 싶은 Status Code이다. 301 || 302 - Redirection에 대한 Status Code이다. 404 - 해당 정보 혹은 Resource를 찾을 수 없다. 유명한 `404 Not Found`가 이것이다. Status Code는 훨씬 더 많으며, 이 또한 Chapter 03에서 자세히 다룬다.

Connection

HTTP는 TCP/IP를 기반으로 한 Application Layer Protocol이다.
TCP의 아래 특성때문에 TCP를 이용한다.

  • Resource 전달시 순서를 보장
  • 패킷의 손실 발생시 재전송
  • 문서를 잘게 나누어 전송하기에 어떠한 크기의 파일도 전송 가능
    이 때문에 HTTP를 사용하더라도 Connection 생성까지는 TCP 방식으로 이루어지며, 실제 Resource 교환시 HTTP Method를 사용한다.


HTTP Versions

현재 Web에서는 HTTPS를 주로 사용한다. HTTP에 TLS를 사용하여 암호화된 연결을 하는 방식이다.
본 서적에서는 HTTP를 주로 다루며, HTTPS와 TLS, DES, AES 등은 따로 찾아보도록 한다.
HTTP의 버전은 다양하다.

  • HTTP 0.9 - HTTP의 초기 버전이라고 볼 수 있다. Legacy Client와만 통신이 가능하며, GET Method만 존재한다. Header 및 MIME Type도 지원하지 않기에 HTML 파일만 전송 가능하였다.
  • HTTP 1.0 - 보급된 최초의 버전이다. Header와 MIME Type을 지원하여 다양한 Resource 전송이 가능하다. Method도 다수 추가가 되었으며, Method 처리 결과도 알 수 있었다.
    • Connection 하나에 Request와 Response를 하나만 처리할 수 있어 비효율적이다.
  • HTTP 1.0+ - 가상 Hosting, Proxy Connection, Keep-Alive라는 기법이 도입되었다. Keep-Alive는 하나의 Connection에서 여러 Request 처리를 하는 기법으로, 해당 버전을 지원하지 않는 Proxy가 있을 경우 Blind Relays 라는 문제가 발생하였다. 정식 버전으로는 사용되지 않아 +가 붙었다.
  • HTTP 1.1 - Persistent Connection 기법이 도입되었다. Keep-Alive 기법보다 발전된 기법으로, Connection을 Close하지 않고 유지하여 사용한다. OS에서의 Locality처럼 Site Locality라는 개념이 존재한다. Connection을 맺고 끊는 처리가 줄어들어 이전보다 빠른 시간안에 Resource 전송이 가능하였다.
    • PipeLining 이라는 기법도 추가되었다. Response를 기다리지 않고 순차적인 Request를 연속적으로 보내는 것이다. 이 덕분에 하나의 Connection에서 여러 Request를 처리할 수 있다.
    • 다만 Head Of Line (HOL) Blocking, Round Trip Time (RTT), 무거운 Header 문제가 발생한다.
    • HOL Blocking은 Queue의 가장 앞에 있는 Packet으로 인하여 지연이 되어 성능이 저하된다.
    • RTT의 경우 TCP Connection이기에 Handshake가 계속하여 발생하고, 이로 인해 불필요하게 RTT가 증가하고 Network Latency로 인하여 성능이 저하된다.
    • Header에 많은 정보들이 저장되며, 한 Web에서 여러 HTTP 요청이 발생하면 중복된 Header를 전송하며 Cookie 정보도 포함될 수 있다. 이로 인하여 Header가 매우 방대해지는 문제가 발생한다.
    • Parallel Connection 이라는 기법도 존재하였는데, 이 기법은 매번 Connection을 구성하여 더 많은 시간과 Bandwidth를 소모한다. TCL Slow Start로 인한 성능 저하 문제도 발생하며, 이 Connection을 맺는 개수에 제한이 있다.
    • 두 Connection 기법 모두 장단점이 존재하며, 적절하게 함께 사용하는 것이 가장 효과적이다.
  • HTTP 2.0 - 현재 가장 널리 쓰이는 버전이다. SPDY의 개선 사항을 적용하여 기능 개선 및 성능 향상에 초점을 두었다.
    • 압축 방식이 변경되었다. 1.1에서는 본문만 압축이 되었고, 중복된 Header 문제로 인하여 전송하는 메세지의 크기가 크다. Request를 Frame이라는 최소 전송 단위로 나누어 Binary로 전송한다. 이 경우 Header도 압축이 가능하며, Binary 방식이기에 파싱 및 전송 속도가 빠르고 오류 발생 가능성이 낮아진다.
    • Multiplexed Stream - 하나의 Connection에서 여러 메세지를 보내며, Response 순서에 상관없이 stream으로 전달된다. 여러 Stream이 존재할 수 있기에 Multiplexing이 가능하며, 각 요청에 대한 Response또한 가능하다. Response 순서에 얽매이지 않아 HOL Blocking 문제가 해결된다.
    • Stream Prioritization - Stream의 우선순위를 설정하여 렌더링에 필요한 Stream을 먼저 받을 수 있다.
    • Server Push - Request하지 않은 Resource를 받을 수 있다. HTML에 렌더링에 필요한 여러 Resource가 존재할 경우 다시 Request를 해야 하는데, 이를 같이 보내주어 불필요한 Request를 줄인다.
    • Header Compression - 위에서 설명한 압축 방식과는 약간 다르다. Header의 중복값을 Static / Dynamic Header Table 개념을 사용하여 중복 Header의 Index를 보내주며, 중복되지 않은 Header의 경우 Huffman Encoding 방식으로 압축한다.
    • Stream의 도입으로 문제가 많이 해결되었으나, TCP 방식을 사용하기에 Handshake의 RTT와 HOL Blocking은 여전히 존재한다.
  • HTTP 3.0 - 구글에서 개발한 Quick UDP Internet Connection (QUIC) Protocol을 사용한다. QUIC는 TCP의 Handshake를 최적화 하는 것에 초점을 두고 개발되었다.
    • 기존의 TCP Stream은 하나의 Chain으로 연결되었으나, 이를 개선하여 각 Stream마다 개별 Chain을 가짐으로써 HOL Blocking을 해결한다.
    • 패킷 손실에 대한 빠른 대응 - TCP에서 패킷 손실을 감지할 때 과거의 응답 시간을 토대로 Timeout을 동적으로 계산하며, 이 때문에 패킷 손실 감지에 시간이 걸린다. 각 Header에 별도의 패킷 공간을 부여하며, 패킷 고유의 번호를 이용하여 패킷 손실 감지에 걸리는 시간을 단축한다.
    • IP와 무관하게 연결 유지 - TCP는 송신자의 IP가 변경되면 다시 Connection을 설정하여야 하며, 이 과정에서 Latency가 발생한다. 송신자의 IP와는 무관한 Connection ID를 도입하여, IP가 변경되더라도 해당 Connection ID를 이용하여 연결을 유지하여 Latency를 줄인다.
      HTTP 2.0과 3.0은 서적이 출판된 이후에 나온 내용들로, 따로 찾으며 정리하였다.

Architectural Components of Web

Web Browser와 Web Server를 기반으로 내용을 확인하였으나, 이 외에도 Web과 통신하기 위한 많은 Application이 존재한다.

  • Proxy & Cache - Client와 Server의 중간에 위치한 Cache 및 보안의 역할이라고 볼 수 있다. 낮은 Bandwidth로 여러 통신이 이루어질 때 많은 Latency가 발생하며, Proxy를 이용하여 Cache에 존재하며 최신 버전의 페이지라면 빠르게 통신할 수 있다. 또한 Proxy 자체의 IP가 있기에 외부에서는 Client의 IP를 알 수 없으며, 바이러스가 포함된 무언가가 들어온다면 이를 막아주기도 한다. 현재 Cache의 경우 Content Delivery Network (CDN)이 이 역할을 한다.
  • Gateway - 서로 다른 Protocol을 사용해야할 때 사용된다. HTTP Client와 FTP Server가 통신할 때, Client -> Gateway로 HTTP Request를 보내면 Gateway는 Server에 FTP Protocol로 통신한다. 반대의 경우는 FTP로 넘어오고, Gateway는 HTTP로 통신한다.
  • Tunnel - 두 Connection 사이에 raw Data를 조회하지 않고 그대로 전달하는 Application이다.
  • Agent - User 대신 HTTP Request를 만들어주는 Application이다. 대표적으로 Web Browser가 있다.

Conclusion

전체적인 내용을 보는 1장인데, 궁금한 점이 계속 생기다보니 양이 방대해졌다.
최대한 간략하게 적어놨으며, 대부분의 내용은 서적에서 자세히 다룰 것이다.
HTTP 2.0과 3.0의 경우 서적에 없을 가능성이 높으며, 이 부분은 따로 찾아봐야 한다.

저작자표시 비영리 변경금지 (새창열림)