HTTP(Hypertext Transfer Protocol)
- HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜(컴퓨터 내부에서, 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계).
- 웹에서 이루어지는 모든 데이터 교환의 기초
- 클라이언트-서버 프로토콜: (보통 웹브라우저인) 수신자 측에 의해 요청이 초기화되는 프로토콜
client와 server가 서로 어떻게 커뮤니케이션하는지를 표준화한 TCP/IP 기반의 *어플리케이션 계층 커뮤니케이션 프로토콜이다.content가 어떻게 요청되고, 어떻게 인터넷을 통해 전송되는지를 정의한다.
- *어플리케이션 계층 프로토콜(application layer protocol): hosts(client와 server)가 어떻게 커뮤니케이션하는지를 표준화한 추상화된 계층이며, TCP/IP가 client와 server사이에 요청과 응답을 주고 받는 것에 의존한다.
HTTP 기반 시스템의 구성요소
각가의 개별적인 요청들은 서버로 전송되고, 서버는 전달받은 요청을 처리하여 response
라고 불리는 응답을 제공한다. 그리고 이 요청과 응답
사이에는 다양한 작업을 수행하는 게이트웨이, 캐시 역할을 하는 프록시 등의 여러 개체들이 존재한다. 라우터, 모뎀 등의 개체도 존재하는데 웹은 계층적으로 설계되어 있기 때문에 이들은 네트워크과 전송 계층 내로 숨겨지고, HTTP는 어플리케이션 계층의 최상위에 있다.
클라이언트: 사용자 에이전트
사용자를 대신하여 동작하는 모든 도구, 주로 브라우저에 의해 수행된다. 브라우저는 항상 요청을 보내는 개체이며, 결코 서버가 될 수 없다.
브라우저가 *웹 페이지를 표시하기 위해서는 페이지의 *HTML 문서를 가져오기 위한 요청을 전송한 뒤, 파일을 구문 분석하여 실행해야 할 스크립트와 하위 리소스들(보통 이미지와 비디오)을 잘 표시하기 위한 레이아웃 정보(CSS)에 대응하는 추가적인 요청들을 가져온다. 그리고, 하나의 완전한 문서인 웹페이지를 표시하기 위해 리소스들을 혼합한다. 즉, 하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 불러온(fetched) 하위 문서들로 재구성된다.
- *웹페이지: 하이퍼텍스트 문서. HTML 언어로 쓰여진 browser(브라우저)를 통해 보여지는 단순한 문서이다. 위에서 설명한 것처럼 웹 페이지는 다양한 다른 종류의 자원을 포함할 수 있다.
- *HTML(*HyperText Markup Language)</u>: 웹을 이루는 가장 기초적인 구성 요소로 웹 콘텐츠의 의미와 구조를 정의할 때 사용하고 웹 브라우저에 표시되는 글, 이미지 등의 다양한 컨텐츠를 표시하기 위해
마크업
을 사용한다. 마크업은 \, \처럼 다양한 요소를 사용한다. - *하이퍼텍스트:웹 페이지를 다른 페이지로 연결하는 링크로 웹의 근본적인 속성이다.
웹 서버
통신 채널의 반대편에 존재하는 클라이언트에 의한 요청에 대한 문서를 제공하는 서버.
프록시
웹 브라우저와 서버 사이에서는 수많은 컴퓨터와 머신이 HTTP 메시지를 이어 받고 전달하는데,여러 계층으로 이루어진 웹 스택 구조에서 이러한 컴퓨터/머신들은 대부분은 전송, 네트워크 혹은 물리 계층에서 동작하며, 성능에 상당히 큰 영향을 주지만 HTTP 계층에서는 이들이 어떻게 동작하는지 눈에 보이지 않는다. 이러한 컴퓨터/머신 중에서도 애플리케이션 계층에서 동작하는 것들을 일반적으로 프록시라고 부른다. 프록시는 눈에 보이거나 그렇지 않을 수도 있으며(프록시를 통해 요청이 변경되거나 변경되지 않는 경우를 말함) 다양한 기능들을 수행할 수 있다
- 캐싱 (캐시는 공개 또는 비공개가 될 수 있다 (예: 브라우저 캐시))
- 필터링 (바이러스 백신 스캔, 유해 컨텐츠 차단(자녀 보호) 기능)
- 로드 밸런싱 (여러 서버들이 서로 다른 요청을 처리하도록 허용)
- 인증 (다양한 리소스에 대한 접근 제어)
- 로깅 (이력 정보를 저장)
HTTP의 기초
간단하다
: HTTP/2가 다소 더 복잡해졌지만 여전히 HTTP 메세지를 프레임별로 캡슐화하여 간결함을 유지하고 있고, 사람이 읽을 수 있도록 간단하게 고안되어 있다.확장가능하다
: HTTP/1.0에서 소개된, *HTTP 헤더는 HTTP를 확장하고 실험하기 쉽게 만들어주었기 때문에, 클라이언트와 서버가 새로운 헤더의 시맨틱에 대해 간단한 합의만 한다면, 언제든지 새로운 기능을 추가할 수 있다.stateless, but not sessionless
: 상태를 저장하지 않는다. 동일한 연결 상에서 연속하여 전달된 두 개의 요청 사이에는 연결고리가 없다. HTTP의 핵심은 상태가 없는 것이지만 HTTP 쿠키는 상태가 있는 세션을 만들도록 해준다. 헤더 확장성을 사용하여, 동일한 컨텍스트 또는 동일한 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 HTTP 쿠키가 추가된다.HTTP와 connections
: 연결(connection)은 전송 계층에서 제어되므로 근본적으로 HTTP 영역 밖이다. HTTP는 연결될 수 있도록 하는 근본적인 전송 프로토콜을 요구하지 않는다. 다만 그저 신뢰할 수 있거나 메시지 손실이 없는(최소한의 오류는 표시) 연결을 요구할 뿐이다. HTTP는 연결이 필수는 아니지만 연결 기반인 TCP 표준에 의존한다.
클라이언트와 서버가 HTTP를 요청/응답으로 교환하기 전에 여러 왕복이 필요한 프로세스인 TCP 연결을 설정해야 하고, 기본적인 TCP 연결은 Connection 헤더를 사용해 부분적으로 제어할 수 있다.
- *HTTP 헤더: 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해준다. HTTP 헤더는 대소문자를 구분하지 않는 이름과 콜론 ‘:’ 다음에 오는 값(줄 바꿈 없이)으로 이루어져있다. 값 앞에 붙은 빈 문자열은 무시된다.
HTTP로 제어할 수 있는 것
- 캐시
HTTP로 문서가 캐시되는 방식을 제어할 수 있다. 서버는 캐시 대상과 기간을 프록시와 클라이언트에 지시할 수 있고 클라이언트는 저장된 문서를 무시하라고 중간 캐시 프록시에게 지시할 수 있다. - origin 제약사항을 완화하기
스누핑과 다른 프라이버시 침해를 막기 위해, 브라우저는 웹 사이트 간의 엄격한 분리를 강제힌다. 동일한 origin으로부터 온 페이지만이 웹 페이지의 전체 정보에 접근할 수 있다. 그런 제약 사항은 서버에 부담이 되지만, HTTP 헤더를 통해 그것을 완화시킬 수 있다. 그런 덕분에 문서는 다른 도메인으로부터 전달된 정보를 패치워크할 수 있다(그렇게 하려면 어떤 경우에 보안과 관련된 사항이 있을 수도 있다). - 인증
어떤 페이지들은 보호되어 오로지 특정 사용자만이 그것에 접근할 수도 있다. 기본 인증은 HTTP를 통해 WWW-Authenticate 또는 유사한 헤더를 사용해 제공되거나, HTTP 쿠키를 사용해 특정 세션을 설정하여 이루어질 수도 있다. - 프록시와 터널링
서버 혹은 클라이언트 혹은 그 둘 모두는 종종 인트라넷에 위치하며 다른 개체들에게 그들의 실제 주소를 숨기기도 한다. HTTP 요청은 네트워크 장벅을 가로지르기 위해 프록시를 통해 나가게 된다. 모든 프록시가 HTTP 프록시는 아니다. 예를 들면 SOCKS 프로토콜은 좀 더 저수준에서 동작한다. FTP와 같은 다른 프로토콜도 이 프록시를 통해 처리될 수 있다. - 세션
쿠키 사용은 서버 상태를 요청과 연결하도록 해준다. 이것은 HTTP가 기본적으로 상태없는 프로토콜임에도 세션을 만들어주는 계기가 된다. 이것은 e-커머스 쇼핑 바구니를 위해서 유용할 뿐만 아니라 사용자 구성을 허용하는 모든 사이트에 대해서 유용하다.
HTTP의 흐름
TCP 연결을 연다
: 요청을 보내거나(혹은 여러개의 요청) 응답을 받는데 사용되고, 클라이언트는 새 연결을 열거나, 기존 연결을 재사용하거나, 서버에 대한 여러 TCP 연결을 열 수 있다.HTTP 메시지를 전송
: HTTP 메시지(HTTP/2 이전의)는 인간이 읽을 수 있다. HTTP/2에서는 이런 간단한 메시지가 프레임 속으로 캡슐화되어, 직접 읽는게 불가능하지만 원칙은 동일하다.
1 | GET / HTTP/1.1 |
서버에 의해 전송된 응답 읽어들이기
:
1 | HTTP/1.1 200 OK |
연결을 닫거나 다른 요청들을 위해 재사용하기
HTTP 메세지
- HTTP/1.1과 초기 HTTP 메시지: 사람이 읽을 수 있다.
- HTTP/2: 이 메시지들은 새로운 이진 구조인 프레임 안으로 임베드되어, 헤더의 압축과 다중화와 같은 최적화를 가능케 한다.
- HTTP 메시지의 두 가지 타입인
요청(requests)과 응답(responses)
은 각자의 형식을 가지고 있다.
요청
의 구성요소
HTTP 메서드
: 보통 클라이언트가 수행하고자 하는 동작을 정의한 GET, POST 같은 동사나 OPTIONS나 HEAD와 같은 명사. 일반적으로, 클라이언트는 리소스를 가져오거나(GET을 사용하여) HTML 폼의 데이터를 전송(POST를 사용하여)하려고 하지만, 다른 경우에는 다른 동작이 요구될 수도 있다.가져오려는 리소스의 경로
: 예를 들면 프로토콜 (http://), 도메인 (developer.mozilla.org), 또는 TCP 포트 (80)인 요소들을 제거한 리소스의 URL.HTTP 프로토콜의 버전
서버에 대한 추가 정보를 전달하는 선택적 헤더들
응답의 본문과 유사한 본문
: POST와 같은 몇 가지 메서드를 위한, 전송된 리소스를 포함
응답
의 구성요소
- HTTP 프로토콜의 버전.
- 요청의 성공 여부와, 그 이유를 나타내는 상태 코드.
- 아무런 영향력이 없는, 상태 코드의 짧은 설명을 나타내는 상태 메시지.
- 요청 헤더와 비슷한, HTTP 헤더들.
- 선택 사항으로, 가져온 리소스가 포함되는 본문.
HTTP 기반 API
HTTP 기반으로 가장 일반적으로 사용된 API는 user agent와 서버간에 데이터를 교환하는데 사용될 수 있는 *XMLHttpRequest API이다. 최신 *Fetch API는 보다 강력하고 유연한 기능을 제공합니다.
- *XMLHttpRequest(XHR) API: XHR객체는 서버와 상호작용하기 위해 사용되며, 전체 페이지의 새로고침없이도 URL 로부터 데이터를 받아올 수 있다. 이는 웹 페이지가 사용자가 하고 있는 것을 방해하지 않으면서 페이지의 일부만 업데이트할 수 있도록 해준다. XMLHttpRequest 는 AJAX 프로그래밍에 주로 사용된다. 또한 XML만 받아올 수 있을 것 같아 보이지만, 모든 종류의 데이터를 받아오는데 사용할 수 있다. 또한 HTTP 이외의 프로토콜도 지원한다(file 과 ftp 포함). 이 XHR
- * Fetch API: 네트워크 통신을 포함한 리소스 취득을 위한 인터페이스가 정의되어 있다. XMLHttpRequest와 같은 비슷한 API가 존재하지만, Fetch API는 좀더 강력하고 유연한 조작이 가능하다.
References
HTML: Hypertext Markup Language
웹페이지, 웹사이트, 웹서버 그리고 검색엔진의 차이는 무엇일까요?
프로토콜
Journey to HTTP/2
HTTP 개요
HTTP 헤더
XMLHttpRequest
Fetch API