[HTTP 완벽 가이드] HTTP 웹의 기초

은승균·2022년 7월 4일
0

HTTP 완벽 가이드

목록 보기
1/1

대학 동기들과 2022/07/06 부터 HTTP 스터디를 진행하기로 하였다.
스터디를 위한 교재는 'HTTP 완벽 가이드', 일명 다람쥐 책이다.

7,8월 두 달간 최대한 빠르게 1회독을 해보는 것을 목표로 진행한다.

1부인 <HTTP 웹의 기초> 파트에서는 4개의 장에 걸쳐 HTTP의 핵심 기술과 웹의 기초에 대해 다룬다.

1. HTTP 개관
HTTP에 대해 개략적으로 살펴본다.
2. URL과 리소스
통합 자원 지시자(Uniform Resource Locator,URL)의 포맷과 URL이 가리키는 리소스의 다양한 형식에 대해 상세히 다룬다. 더 진화한 지시자 URN에 대해서도 다룬다.
3. HTTP 메시지
HTTP 메시지가 어떻게 웹 콘텐츠를 전송하는지 다룬다.
4. 커넥션 관리
HTTP 커넥션 관리에 대한 오해와 잘못 작성된 규칙 및 동작들을 설명한다.

HTTP 웹의 기초

HTTP는 왜 중요한가?

WWW(월드 와이드 웹)을 지탱하는 가장 중요한 기술 두 가지는 HTMLHTTP라고 할 수 있다. 둘 중 하나라도 빠지게 된다면 웹은 성립하지 않는다. 즉, 이 둘만 있다면 어떻게는 웹이 구성된다는 소리이다.
지난 25년간 HTTP가 사용되어 왔으며, 여러 웹 개발을 위한 프레임워크들이 유행에 따라 바뀌어 왔지만,HTTP를 이용해 서버, 캐시, 프락시 등 모든 웹의 구성 요소들이 소통한다는 점은 변하지 않는다.

HTTP, Hypertext Transfer Protocol

HTTP는 웹(WWW)에서 사용되는 통신 프로토콜이다. 주로 웹 브라우저웹 서버 사이에서의 쌍방향 통신에 사용된다.
HTTP는 신뢰성 있는 데이터 전송 프로토콜(TCP)을 사용하기 때문에 온전하고, 순서가 제대로 된 패킷을 전송 받을 것을 보장한다.

웹 클라이언트와 웹 서버

클라이언트(웹브라우저)는 HTTP 객체(index.html)를 요청하면 서버에서는 요청받은 객체를 찾아 HTTP 응답으로 보내준다.

리소스

웹 서버는 웹 리소스를 관리하고 제공한다. 웹 리소스는 HTML파일, 사진, 동영상 파일 등의 정적 파일일 수도 있고, 요청에 따라 다른 데이터를 보내주는 동적 컨테츠일 수도 있다. 즉, 어떤 종류의 콘텐츠 소스도 리소스가 될 수 있다.

  • 스프레스 시트 파일
  • 지역 공공 도서관 서가 탐색 웹 게이트웨이
  • 인터넷 검색엔진
    ...

    미디어 타입 MIME

    원래 전자메일 시스템에서 수 천가지 데이터에 대한 타입 문제를 해결하기 위해서 설계된 미디어 타입이다. HTTP에서도 멀티미디어 콘텐츠를 기술하고 라벨을 붙이기 위해 MIME(Multipurpose Internet Mail Extension)을 채택하였다.
    모든 HTTP 객체 데이터에 MIME 타입을 붙인다. MIME 타입은 / 로 주타입/부타입 으로 이루어진 문자열 라벨이다.
    예시
    - HTML 문서: text/html
    - plain ASCILL 텍스트 문서: text/plain
    - JPEG: image/jpeg
    - GIF: image/gif
    - 애플 퀵타임 동영상: video/quicktime
    - MS 파워포인트 ppt: application/vnd.ms-powerpoint
    위와 같이 많은 MIME 타입이 존재한다.

    URI

    웹 서버의 리소스는 각자 이름을 가지고 있으며, 클라이언트는 리소스를 지목할 수 있다. 이러한 이름은 URI(Uniform Resource Identifier, 통합 자원 식별자)라고 한다. 인터넷 상의 우편물 주소 같은 것이다. 리소스를 고유하게 식별하고 위치를 지정할 수 있다.
    URL(Uniform Resource Locator)
    통합 자원 지시자, 리소스 식별자의 가장 흔한 형태이다.
    프로토콜, 서버 리소스를 명시한다.
    URL 표준 포맷

    http://www.joes-hardware.com/specials/saw-blade.gif
    - URL의 첫 번째 부분은 Scheme(스킴) 이라고 부른다. 리소스에 접근하기 위해 사용되는 프로토콜을 서술한다. http, https 등
    - 두 번째 부분은 인터넷 주소를 제공한다. www.joes-hardware.com 부분
    - 마지막은 웹 서버의 리소스를 카리킨다. /specials/saw-blade.gif

URN(Uniform Resource Name)

콘텐츠를 이루는 한 리소스에 대해, 그 리소스의 영향 받지 않는 유일무이한 이름 역할으 한다. URN은 독립적이기 때문에 리소스를 여기저기 옮겨도 영향 받지 않는다. 리소스 이름을 변하기 않게 유지하는 한 여러 종류의 네트워크 접속 프로토콜로 접근해도 문제가 없다.
예를 들어, urn:ietf:rfc:2141 이라는 URN은 'RFC2141' 문서가 어디에 있든 해당 문서를 지칭하는데 사용될 수 있다.

아직 실험 단계이며 널리 채택되지 않았다. URN의 효율적인 동작을 위해서는 URN은 리소스 위치 분석을 위한 인프라 자원이 필요한데 없다.

트랜잭션

요청명령요청결과로 이루어져 있다.
HTTP 메시지라고 불리는 정형화된 데이터 덩어리를 이용해 상호작용이 이루어진다.

구성요소

메소드

HTTP메서드설명
GET서버에서 클라이언트로 지정한 리소스를 보내라.
PUT클라이언트에서 서버로 보낸 데이터를 지정한 이름의 리소스로 저장하라.
DELETE지정한 리소스를 서버에서 삭제하라.
POST클라이언트 데이터를 서버 게이트웨이 애플리케이션으로 보내라.
HEAD지정한 리소스에 대한 응답에서, HTTP 헤더 부분만 보내라

상태코드

HTTP상태코드설명
200좋다. 문서가 바르게 반환되었다.
302다시 보내라. 다른 곳에 가서 리소스를 가져와라.
404없음. 리소스를 찾을 수 없다.

모든 HTTP응답 메시지는 상태코드와 함께 반환된다. 또한 코드에 텍스트로 된 '사유 구절(reason phrase)'도 함께 보낸다. 하지만 사유 구절은 단순히 설명만을 위한 것이다. 즉, 응답 처리에는 상태코드가 사용된다. 상태 코드가 같으면 같은 처리를 한다.

HTTP 메시지

메시지는 요청 메시지응답 메시지로 이루어진다. 사람이 읽을 수 있는 일반 텍스트로 이루어져 있으며, 세부분으로 이루어진다.

시작줄
메시지의 첫 줄.
요청 - 무엇을 해야 하는지

  • 메소드
  • 리소스
  • 프로토콜 버전

응답 - 무슨 일이 일어났는지

  • 프로토콜 버전
  • 상태코드, 사유 구절

헤더
시작 줄 다음으로 오는 0개 이상의 헤더 필드
이름 : 값 으로 구성된다.

본문
어떤 종류의 데이터든 들어갈 수 있다. 시작줄과 헤더와는 달리 텍스트 뿐만 아니라 임의의 이진 데이터(이미지, 비디오, 오디오 트랙 등)를 포함할 수 있다.

TCP 커넥션

HTTP는 네트워크 계층 중 애플리케이션 계층의 프로토콜이다. 즉, 애플리케이션 단의 역할이 아닌 네트워크의 핵심적인 동작 부분에 대해서는 하위 계층의 프로토콜에게 맡긴다. 해당 프로토콜은 TCP/IP 프로토콜이다. 처음 소개에서 설명한 것 처럼 TCP 프로토콜은 신뢰성 있는 연결을 보장하는 프로토콜이며, 다음과 같은 것들을 보장한다.

  • 오류 없는 데이터 전송
  • 순서에 맞는 전달(데이터는 언제나 보낸 순서대로 도착한다)
  • 조각나지 않는 데이터 스트림(언제든 어떤 크기로든 보낼 수 있다)

TCP/IP 프로토콜은 패킷 교환 네트워크 프로토콜의 집합니다. 네트워크와 하드웨어의 특성을 숨기고, 어떤 종류의 컴퓨터나 네트워크든 서로 신뢰성 있는 의사소통을 하게 해주는 역할을 한다.

실제 연결 부분은 더 하위 계층이 담당한다.
계층적으로 구성되어 각 계층은 다른 계층을 신경쓰지 않아도 된다.

애플리케이션 계층 (HTTP)
전송 계층 (TCP) - 포트 번호(각 프로그램 별로 사용 중)로 식별
네트워크 계층 (IP) - IP 주소로 식별
링크 계층 - MAC 주소로 식별
물리 계층

각 계층을 통해 연결을 할 때 IP주소와 포트번호로 연결을 하게 된다. 하지만 이런 IP주소와 포트번호를 어떻게 알 수 있을까?
바로 URL을 이용하여 알아낼 수 있다.

URL은 IP주소+포트 번호 또는 도메인 이름 또는 호스트 명으로 이루어 진다. DNS를 통해서 호스트명으로부터 IP를 알 수 있다.

HTTP를 이용해 리소스를 받는 과정을 정리하면 다음과 같다.

  1. 웹 브라우저는 서버의 URL에서 호스트 명을 추출한다.
  2. 웹 브라우저는 서버의 호스트 명을 IP로 변환(DNS를 통해)한다.
  3. 웹 브라우저는 URL에서 포트번호(있다면, 기본 80)를 추출한다.
  4. 웹 브라우저는 웹 서버와 TCP 커넥션을 맺는다.
  5. 웹 브라우저는 서버에 HTTP 응답을 보낸다.
  6. 서버는 웹 브라우저에 HTTP 응답을 돌려보낸다.
  7. 커넥션이 닫히면, 웹 브라우저는 문서를 보여준다.

HTTP 요청을 보낼 때 TCP 연결을 맺으며, 클라이언트에서 응답을 받으면 TCP 커넥션을 끊는다는 것을 알 수 있다. 여기서 HTTP의 무상태성이라는 특징을 알 수 있다.

HTTP 프로토콜 버전

HTTP 프로토콜은 계속해서 발전해 왔으며 수 많은 버전이 만들어졌다. 이 중에서 현재 주로 쓰이고 있는 버전은 HTTP/1.1HTTP/2.0 이다. 이 책에서는 주로 1.1 버전에 대해서 다루고 있는 것 같다.

HTTP/1.1 버전은 이전의 HTTP 프로토콜의 구조적 결함 교정, 성능 최적화, 잘 못된 기능 제거가 이루어진 버전이다.

HTTP/2.0 버전은 1.1 버전까지의 성능 문제를 개선하기 위해 구글의 SPDY 프로토콜을 기반으로 설계된 버전이다. 주요 특징은 다음과 같다.

  • Multiplexed Streams(1개의 커넥션으로 여러 메시지 주고 받을 수 있다.)
  • Stream Prioritization: 리소스 간의 의존관계에 따른 우선순위 설정
  • Header Compression: 헤더 정보를 HPACK 방식으로 압축

HTTP/1.1의 문제점은 다음과 같다.

  • 1개의 커넥션 당 1 개의 요청을 처리한다.
  • HOL(Head Of Line) 블로킹이 발생할 수 있다.
    같은 큐에 있는 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 문제를 말한다.
  • RTT(Round Trip Time)이 증가한다.
    여러 요청을 동시에 보내지 못하기 때문에 3-way-handshake를 매번 다시 해야한다. 이는 RTT를 증가시키는 요인이 된다.
  • 헤더가 무겁다.
    매번 서버 도메인에 관련된 쿠키 정보가 포함되어 보내지는데, 같은 정보를 반복적으로 실어 보내는 것은 비효율 적인다.

웹의 구성요소

인터넷과 상호작용 할 수 있는 웹 애플리케이션의 종류는 다음과 같다.

프락시
클라이언트와 서버 사이에 위치한 HTTP 중개자이다. 웹 보안, 애플리케이션 통합, 성능 최적화를 위한 중요한 구성요소이다.
주로 보안을 위해 사용되며, 모든 트래픽 흐름 속에서 신뢰할만한 중개자 역할을 한다.
중개를 하며 요청과 응답을 필터링하는 역할을 한다.

6장에서 계속

캐시
많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고
자주 사용하는 문서의 사본을 저장해 두는 특별한 종류의 HTTP 프락시 서버이다.
멀리 떨어진 웹 서버보다 근처의 캐시에서 문서를 다운 받을 수 있다.

7장에서 계속

게이트웨이
다른 애플리케이션과 연결된 중개자로 동작하는 특별한 웹서버이다. 주로 HTTP 트래픽을 다른 프로토콜로 변환하기 위해 사용된다.
게이트웨이는 언제나 자신이 리소스를 가지고 있는 진짜 서버인 것 처럼 요청을 다룬다. 이 말은 클라이언트는 게이트웨이와 통신하는지에 대한 여부를 알지 못한다는 뜻이다.

HTTP <--HTTP프로토콜--> HTTP/FTP 게이트웨이 <--FTP프로토콜--> FTP서버

터널
단순히 HTTP 통신을 전달하기만 하는 특별한 프락시
터널은 두 커넥션 사이에서 RAW 데이터를 열어보지 않고 그대로 전달해주는 HTTP 애플리케이션이다. 주로 비HTTP 데이터를 하나 이상의 HTTP 연결을 통해 그대로 전송해주기 위해 사용된다.

클라이언트 => SSL --터널시작-- HTTP with RAW SSL -- HTTP 커넥션 -- HTTP with RAW SSL -- 80번 포트 / 터널 끝 --> SSL / SSL커넥션 --> SSL --> 서버 443포트

에이전트
사용자 에이전트는 자동화된 HTTP 요청을 만드는 준지능적(semi-intelligent) 웹클라이언트 프로그램이다. 웹 요청을 만드는 애플리케이션은 뭐든 HTTP 에이전트이다. 지금까지는 웹 브라우저 하나만 봤지만, HTTP 트랜잭션을 일으키고 컨텐츠를 받아오는 자동화된 사용자 에이전트도 있다. 이러한 '스파이더'나 '웹로봇'과 같은 이름을 가지고 있다.

profile
3대 500을 향해서

0개의 댓글