HTTP란?

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

클라이언트-서버 프로토콜: 수신자 측에 의해 요청이 초기화되는 프로토콜

하나의 완전한 문서는 이것저것 Fetch한 하위 문서들로 재구성된다.

클라와 서버는 개별적인 메세지 교환에 의해 통신한다. 보통 브라우저인 클라이언트에 의해 전송되는 메세지를 **요청(request)** 이라 하고 서버에서 받는 메세지를 **응답(response)** 이라고 한다.

HTTP는 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이면 이론상 무엇이든 사용할 수 있다. TCP 혹은 암호화된 TCP 연결인 TLS를 통해 전송된다.

TCP(Transport Control Protocol) 전송 제어 프로토콜, 두 개의 호스트를 연결하고 데이터 스트림을 교환하게 해주는 중요 네트워크 프로토콜

TLS(Transport Layer Security) 전송 계층 보안, 애플리케이션들이 네트워크 상에서 안전하게 통신하기 위해 사용된 프로토콜. 이메일, 웹 브라우징, 메시징, 다른 프로토콜들의 감청을 통한 정보의 변형을 방지한다. SSL(Secure Sockets Layer)으로도 알려져 있음. 최신 브라우저들은 유효한 디지털 인증서를 제공하도록 요구하는 TLS 프로토콜을 지원하고 있다.

이를 통해 오늘날 우리가 이런저런 인터넷에서 여러 정보를 교환할 수 있는 것이다.

HTTP 기반 시스템의 구성 요소

HTTP는 클라이언트-서버 프로토콜로 요청은 하나의 개체, 사용자 에이전트에 의해 전송된다. 사용자 에이전트는 브라우저지만 로봇이든 무엇이든 될 수 있다. 각각의 요청은 서버로 보내지고 response를 받는 과정에서 게이트웨이 또는 캐시 역할을 하는 프록시가 중간에 걸쳐 있다.

실제로 브라우저와 서버 사이에는 인터넷에서 설명했듯 모뎀이나 라우터와 같은 컴퓨터들이 존재하지만 웹의 계층적인 설계로 네트워크와 전송 계층 내로 숨겨진다. 여기서 HTTP는 애플리케이션 계층의 최상위에 있다.

HTTP의 기초적인 측면

간단하다

사람이 읽을 수 있고 간단하여 사람이 읽고 이해가 가능하다.

확장 가능하다

HTTP헤더는 HTTP를 확장하고 실험하기 쉽게 만들어주어 계속해서 가능 추가가 가능하다.

상태가 없지만 세션이 있다

상태를 저장하지 않지만 HTTP 쿠키를 통해 상태가 있는 세션을 만들도록 해준다. 헤더 확장성을 사용하여 동일한 컨텍스트 또는 동일한 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 HTTP 쿠키가 추가된다.

HTTP 쿠키 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각. 브라우저는 쿠키를 저장해 놓았다가 동일한 서버에 재요청시 저장된 데이터를 함께 전송한다. 두 요청이 동일한 브라우저에서 들어왔는지 아닌지를 판단할 때 주로 사용한다 사용자의 로그인 상태 유지에서 사용되는 편

연결

연결은 전송 계층이므로 HTTP 영역의 밖이다. 근본적인 전송 프로토콜을 요구하지 않지만 신뢰할 수 있거나 메세지 손실이 없는 연결을 요구한다. 즉 연결이 필수는 아니지만 연결 기반인 TCP 표준에 의존한다.

HTTP로 클라이언트/서버가 요청/응답으로 교환하기 전 TCP 연결 설정이 필요하다. HTTP/1.0은 각 요청/응답에 대해 별도 TCP 연결을 열어야 했지만 이 경우 연속적인 요청이 있을 경우 비효율적이게 된다.

이에 HTTP/1.1은 파이프라이닝 개념과 지속적인 연결의 개념을 도입하여 Connection 헤더를 사용해 부분적으로 제어할 수 있다.

HTTP/2는 연결을 지속되고 효율적으로 유지하는데 도움이 되도록 단일 연결 상에서 메세지를 다중전송할 수 있도록 발전했다.

현재는 더 나은 전송 프로토콜을 설계하는 중이다.

HTTP로 제어할 수 있는 것

캐시

문서가 캐시되는 방식을 제어할 수 있다. 서버는 캐시 대상과 기간을 프록시와 클라이언트에 지시할 수 있고 클라이언트는 저장된 문서를 무시하라고 중간 캐시 프록시에게 지시할 수 있다.

Origin 제약사항 완화

스누핑과 다른 프라이버시 침해를 막기 위해, 브라우저는 웹 사이트 간의 엄격한 분리를 강제한다. 동일한 origin으로부터 온 페이지만이 웹 페이지의 전체 정보에 접근할 수 있다. 그런 제약 사항은 서버에 부담이 되지만, HTTP 헤더를 통해 그것을 완화시킬 수 있다. 그런 덕분에 문서는 다른 도메인으로부터 전달된 정보를 패치워크할 수 있다.

스누핑 : 네트워크 상에 떠도는 중요 정보를 몰래 흭득하는 행위

인증

어떤 페이지들은 보호되어 오로지 특정 사용자만이 그것에 접근할 수도 있다. 기본 인증은 HTTP를 통해 WWW-Authenticate (en-US) 또는 유사한 헤더를 사용해 제공되거나, HTTP 쿠키를 사용해 특정 세션을 설정하여 이루어질 수도 있습니다.

프록시와 터널링

서버/클라이언트 혹은 그 둘 다 종종 인트라넷에 위치하며 다른 개체들에게 그들의 실제 주소를 숨기기도 한다. HTTP 요청은 네트워크 장벽을 가로지르기 위해 프록시를 통해 나가게 된다. 하지만 모든 프록시가 HTTP 프록시는 아니다.

프록시(Proxy) 와 프록시 서버 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터 시스템이나 응용 프로그램을 가리킴. 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 행위 자체를 프록시라고 하며, 그 중계 기능을 하는 것을 프록시 서버라고 부른다

세션

쿠키 사용을 통해 서버 상태를 요청과 연결시킨다. stateless한 프로토콜임에도 세션을 만들어주는 계기가 된다. 브라우저의 이커머스 웹같은 곳에서도 장바구니에 담은 후 나갔다 들어와도 유지시켜주는 그런 기능을 할 수 있다.

HTTP 흐름

클라이언트가 서버와 통신할 때, 중간프록시가 하는 다음의 과정은 아래와 같다.

1. TCP 연결 열기

TCP(Transport Control Protocol) 연결은 요청을 보내거나 응답을 받는데 사용된다.

2. 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
<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)

4. 연결을 닫거나 다른 요청을 위한 재사용

HTTP 파이프라이닝이 활성화되면 첫번째 응답을 완전히 수신할 때까지 기다리지 않고 여러 요청을 보낼 수 있다.

HTTP 파이프라이닝 여러 요청으로 웹 성능을 개선하는 방법. 단일 TCP 연결을 통해 여러 HTTP 요청을 보내는 기술 HTTP/1.1 클라이언트의 경우 다수의 HTTP 요청을 하나의 TCP/IP Packet으로 연속적으로 Packing해서 요청을 보낸다. HTTP/2에서는 이미 다중화를 통합하고 있으므로 파이프라이닝 없이 HTTP/2의 속도를 개선했다.

HTTP 메세지

HTTP/1.1과 초기 HTTP는 사람이 읽을 수 있지만 HTTP/2는 새로운 이진 구조인 프레임 안으로 임베드되어 읽을 수 없다. 하지만 위에서 말했듯 메세지의 원칙은 동일하며, 각 메세지의 의미들 또한 변화하지 않았다. 따라서 HTTP/1.1의 포맷을 이해한다면 HTTP/2 또한 이해할 수 있다.

요청

### Method HTTP 메서드로 클라이언트가 수행하고자 하는 동작을 정의한다(GET, POST 등).

Path

가져오려는 리소스의 경로. 프로토콜(http://), 도메인, TCP 포트인 요소들을 제거한 리소스의 URL

Version of the Protocol

HTTP 프로토콜의 버전

서버에 대한 추가적인 정보를 전달

응답

### Version of the Protocol HTTP 프로토콜의 버전

Status Code

요청의 성공 여부와 그 이유를 코드를 통해 나타낸다.(200, 404등)

Satus message

상태 코드의 짧은 설명 200 - 성공, 404 - Not Found 등

Headers

요청과 마찬가지로 서버에 대한 추가적인 정보를 담는다

HTTP 기반 API

HTTP 기반으로 가장 일반적으로 사용된 API는 XMLHttpRequest API이다. 최신 Fetch API는 이보다 강력하고 유연한 기능을 지닌다.

다른 API로 서버-전송 이벤트와 Websocket API 등이 있다.

XMLHttpRequest 서버와 상호작용할 때 사용하는 객체(XHR)로 페이지의 새로고침 없이 URL에서 데이터를 가져올 수 있다. AJAX 프로그래밍에 많이 사용된다.

Fetch API 네트워크 통신을 포함한 리소스 취득을 위한 인터페이스를 제공한다. Request와 Response, 기타 네트워크 요청에 관련된 것들을 사용하고, CORS와 HTTP Origin 헤더 행동 등 관련한 개념도 포함하고 있다.

서버-전송 이벤트(Server-sent events) 원래는 새로운 데이터를 받기 위해 서버로 요청을 보내야 했지만 Server-sent Events 방식은 웹페이지의 요청 없이도 언제는지 서버가 새로운 데이터를 보낼 수 있다. 이렇게 보내진 메세지는 웹페이지에서 Events(DOM에서 발생하는 이벤트)와 데이터로 다룰 수 있다. 이벤트 데이터나 메세지 데이터를 서버에서 가져오는 통신에 유리하다

WebSocket API 사용자의 브라우저와 서버 사이의 인터액티브 통신 세션을 설정할 수 있게 해준다. 서버를 풀링하지 않고도 이벤트 중심 응답을 받는 것이 가능하다. 완전한 양방향 통신의 경우에는 Server-sent Event보다 WebSocket API가 유리하다.

🐢꾸준함의 미학

탐색기

HTTP란?

HTTP란?

HTTP 기반 시스템의 구성 요소

HTTP의 기초적인 측면

간단하다

확장 가능하다

상태가 없지만 세션이 있다

연결

HTTP로 제어할 수 있는 것

캐시

Origin 제약사항 완화

인증

프록시와 터널링

세션

HTTP 흐름

1. TCP 연결 열기

2. HTTP 메세지 전송

3. 서버에 의해 전송된 응답 읽기

4. 연결을 닫거나 다른 요청을 위한 재사용

HTTP 메세지

요청

Path

Version of the Protocol

Header

응답

Status Code

Satus message

Headers

HTTP 기반 API

그래프 뷰

목차

백링크