결론

HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이자, 클라이언트-서버 모델의 프로토콜
HTTPS는 HTTP 통신의 보안을 강화한 버전.(SSL/TLS 프로토콜이 추가된 HTTP)

HTTP

HTTP란?

출처: Mozila - HTTP란?

HTTP란 HTML(HyperText Mark-up Language) 문서와 같은 리소스들을 가져올 수 있도록 프로토콜(규약, 약속)이에요. 웹에서 이루어지는 모든 데이터 교환의 기초가 되고, 클라이언트-서버 모델의 포로토콜이죠.

우리가 보는 웹은 이런식으로 구성되어 있어요.

구성 요소

클라이언트(대게 브라우저)가 서버로 전송하는 메시지를 요청(request)이라 부르고, 서버에서 응답되는 메시지를 응답(response)라고 불러요.
확장 가능한 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 무엇이든 사용할 수 있어요.
request는 하나의 개체(브라우저, 프록시, 웹 크롤링 봇 등..)에 의해 서버에 전송돼요. 각각 개별 요청들은 서버로 보내지고, 서버는 요청을 처리해 reponse를 클라이언트에 제공해요.

• 실제로는 브라우저와 요청을 처리하는 서버 사이에 많은 머신(라우터, 모뎀 등)이 있지만, 웹의 계층적 설계로 이들은 고려하지 않아 HTTP 명세와는 관련이 없어요.
• 웹의 계층적 설계에 대해 자세히 알고싶다면, 클릭해보세요.

요런 식으로 웹은 계층적으로 분리돼요.

위 그림으로 웹의 계층과 HTTP 메시지 전송의 관계를 알 수 있어요.

브라우저에서 F12를 누르면 볼 수 있는 개발자 도구에 HTTP 명세가 담겨있어요.

특징

1. 간단해요. HTTP 메시지는 프레임 별로 캡슐화되기 때문에, 간결해요. 초기 HTTP 메시지는 사람이 읽고 이해할 정도예요.
2. 확장 가능해요. 서버-클라이언트가 새롭게 헤더의 semantic(의미)에 대해 합의한다면, 언제든 새로운 기능을 추가할 수 있어요.
3. 상태는 없지만(Stateless), 세션은 있어요. 하지만 HTTP 쿠키로 상태가 있는 세션을 만들도록 해줘요.

HTTP와 연결 계층의 관계
HTTP는 전송 계층에서 신뢰할 수 있거나, 메시지 손실이 없는 연결(connection)을 요구해요. 그래서 TCP는 신뢰할 수 있지만, UDP는 신뢰할 수 없어요. 그러므로 HTTP는 TCP 표준 프로토콜에 의존해요.
그래서 클라이언트와 서버가 HTTP 요청/응답을 교환하기 전, 여러 왕복이 필요한 프로세스인 TCP 연결을 설정해요. (HandShake)
이런 과정을 실시간 통신에서 비효율적이기 때문에, HTTP/1.1 버전에서 파이프라이닝 개념과 지속적 연결의 개념을 도입했어요. HTTP/2는 단일 연결 상에서 메시지를 다중 전송(Multiplexing)할 수 있게 됐어요.

핸드셰이크의 과정이에요.

동작 원리

클라이언트는 웹 페이지를 표시하기 위해
1. 브라우저는 페이지의 HTML 문서를 가져오기 위한 요청을 서버로 전송한 뒤
2. 파일 구문 분석으로 실행해야 할 스크립트, 페이지 내 하위 리소스(이미지, 비디오 등)를 표시하기 위한 레이아웃 정보(CSS) 등 추가 요청을 가져와요.
3. 브라우저는 완전한 문서인 웹 페이지를 표시하기 위해 리소스들을 혼합해요.

출처

클라이언트는 항상 요청을 보내는 객채예요.
서버는 통신 채널 반대편 클라이언트에 의한 요청에 대한 문서를 제공해요.
서버는 논리적으로는 단일 기계예요. 그렇지만 반드시 단일 머신일 필요는 없어요. 여러 개의 서버를 동일한 머신 위에서 호스팅 할 수는 있어요. HTTP/1.1과 Host 헤더를 이용하여, 동일한 IP 주소를 공유할 수도 있어요.

주 기능

캐시: HTTP로 문서가 캐시되는 것을 제어
origin 제약사항 완화: 브라우저는 스누핑과 프라이버시 침해 방지를 위해, 웹 사이트간의 엄격한 분리를 강제합니다. 동일한 origin으로부터 온 페이지만이 웹 페이지의 전체 정보에 접근할 수 있습니다. HTTP는 헤더를 통해 이러한 제약사항을 완화시킬 수 있습니다.
인증: 페이지를 보호하여 특정 사용자만이 접근할 수 있게 해줍니다. Auth 혹은 HTTP 쿠키를 사용해 특정 세션을 설정하여 만들 수 있습니다.
프록시와 터널링: 서버 혹은 클라이언트는 인트라넷에서 프록시를 통해 다른 개체들에게 실제 주소를 숨길 수 있습니다. (모든 프록시가 HTTP 프록시는 아닙니다. SOCKS 프로토콜, FTP 등이 있습니다.)
세션: 쿠키 사용은 서버 상태를 요청과 연결하도록 해줍니다. 이를 통해 HTTP가 기본적으로 STATEless 프로토콜임에도 세션을 만들어주는 이유입니다.

HTTP 흐름

1. TCP 연결을 엽니다. TCP connection은 요청(단일 혹은 복수의)을 보내거나, 응답을 받는 데 사용합니다. 클라이언트는 새 연결을 열거나, 기존 연결을 재사용하거나, 서버에 대한 여러 TCP 연결을 열 수 있습니다.
2. HTTP 메시지를 전송합니다. 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

4. 연결을 닫거나, 다른 요청을 위해 재사용합니다.

HTTP 메시지

HTTP/1.1과 초기 메시지는 사람이 읽을 수 있었어요. 그러나 HTTP/2 이후 메시지들은 프레임 안으로 임베드되어, 헤더의 압축, 다중화 등 같은 최적화를 가능하게 됐어요.
HTTP 메시지의 두가지 타입인 request와 response는 각자의 형식을 가지고 있습니다.

요청(Resquest)

Method: 클라이언트가 수행하고자 하는 동작을 정의한 GET, POST와 같은 동사나, OPTION, HEAD와 같은 명사입니다. 일반적으로는 클라이언트는 리소스를 가져오거나(GET), HTML form의 데이터를 전송(POST)하는 등의 요청 목적입니다.
Path: 가져오려는 리소스의 경로입니다. 예를 들면 프로토콜(http://), 도메인(developer.mozilla.org), TCP 포트(80)인 리소스 URL입니다.
Headers: 서버에 대한 추가 정보를 전달하는 선택전 헤더들입니다.

응답

Status Code: 요청의 성공 여부와 그 이유를 나타내는 코드입니다.
Status Message: 상태 코드에 대한 짧은 설명입니다.
Headers: 요청 헤더와 비슷한 HTTP 헤더들입니다.

• 선택 사항으로 가져온 리소스가 포함된 본문

HTTP 기반 API
가장 일반적인 API는 user agent와 서버간 데이터 교환에 유용한 XMLHttpRequest API입니다.
최신 Fetch API는 보다 강력하고 유연합니다.
또다른 API인 서버-전송 이벤트는 서버가 전송 메커니즘으로 HTTP를 사용하여, 클라이언트로 이벤트를 보낼 수 있도록 하는 단방향 서비스입니다.(SSE 방식으로 웹 페이지의 요청 없이도 서버가 새로운 데이터를 보내는 것이 가능합니다.)

HTTP 기반 API에서, 클라이언트는 EventSource 인터페이스를 사용하여 연결 맺고, 이벤트 핸들러를 설정합니다.
브라우저는 HTTP 스트림으로 도착한 메시지를 적절한 Event 객체로 자동 변환합니다. 해당 이벤트 Type에 등록된 이벤트 핸들러로 전달하거나, 이벤트가 등록되지 않은 경우 onMessage 이벤트 핸들러로 전달합니다.

HTTPS

차이점

출처: HTTPS의 차이

HTTP 통신은 클라이언트(브라우저)와 서버가 데이터를 일반 텍스트로 교환합니다. 이를 제 3자라 가로챌 수 있기 때문에, 보안을 강화하기 위해 HTTPS(HTTP Secure)로 확장됐습니다.
HTTPS에서는 브라우저와 서버가 데이터를 전송하기 전에 암호화된 연결을 생성합니다. HTTPS는 모든 요청 및 응답을 SSL(Secure Socket Layer) 및 TLS(Transport Layer Security) 프로토콜에 따라 암호화합니다.

HTTPS의 동작원리