HTTP / HTTPS

niireymik·2024년 1월 15일

💡
1990년 웹이 이 세상에 처음 등장했을 때, 웹을 구성하는 요소는 크게 네 가지였다. 웹 페이지를 만드는 컴퓨터 언어인 HTML, 원하는 웹 페이지에 방문할 수 있도록 도와주는 주소 체계인 URL, 그리고 웹 페이지를 주고받는 소프트웨어인 Web browser/server, 그리고 '통신 규칙'이자 오늘의 주제인 HTTP이다. HTTP가 무엇인지, 어떻게 생겼는지부터, 발전 과정, 작동 방식, 그리고 HTTPS의 개념과 사용 이유까지 차근차근 톺아보도록 하자!

📌 HTTP란?

하이퍼텍스트 전송 프로토콜(HyperText Transfer Protocol)의 약자로, 서버와 클라이언트가 인터넷상에서 데이터를 주고받기 위한 프로토콜을 말한다.

(+)
서버-서버, 클라이언트-클라이언트 간의 통신(요청과 응답)도 이루어진다. 서버와 클라이언트 사이에서만 통신이 이루어진다고 단정짓지 않도록 하자.

하이퍼텍스트와 프로토콜?
Hypertext : 참조(하이퍼링크)를 통해 독자가 한 문서에서 다른 문서로 즉시 접근할 수 있는 텍스트이다.
Protocol : 컴퓨터에서 데이터의 교환 방식을 정의하는 규칙 체계이다. 👉 쉽게 말해, 사람들이 말, 글 등으로 서로 소통하듯이 프로그램도 정해둔 규격을 가지고 메시지를 주고받는데, 이때 사용하는 통신 규약이 바로 프로토콜이다 :>

HTTP를 통한 일반적인 흐름에는 클라이언트 시스템에서 서버에 요청한 다음 서버에서 응답 메시지를 보내는 작업이 포함된다.

HTTP의 특징

HTTP 메시지는 HTTP 서버와 HTTP 클라이언트에 의해 해석된다.
TCP / IP를 이용하는 응용 프로토콜이다.
HTTP는 연결 상태를 유지하지 않는 비연결성(Connectionless) 프로토콜이며, 상태정보를 유지하지 않는 Stateless 프로토콜이다. 서버가 응답 후 클라이언트와의 연결을 끊어버려, 요청이 들어오는 클라이언트의 이전 상황을 알 수 없다.
(쇼핑몰에서 물건을 고르고 결제를 하려고 할 때, 무슨 물건을 고른지 몰라 결제를 할 수 없을 수 있다.)
➡️ 이런 Stateless 특징 때문에 정보를 유지하기 위해 쿠키, 세션, 토큰과 같은 기술이 등장했다!🍪
HTTP는 연결을 유지하지 않는 프로토콜이기 때문에 요청/응답 방식으로 동작한다.

📌 HTTP의 역사

HTTP/0.9

: 가장 초기에 WWW(World Wide Web)이 만들어지면서 함께 등장한 HTTP이다. 이는 통신에 필요한 최소한의 기능만 갖추고 있었다. GET /mypage.html 과 같이 데이터를 요청한다는 본문을 보내면

<HTML>
A very simple HTML page
</HTML>

이렇게 결과 자체를 본문에 담아 응답했다. 에러가 발생했을 경우 응답 메시지의 본문에 에러를 적어 보냈다.

HTTP/1.0

: 우리가 익히 알고 있는, 각 잡고 문서화된 형태의 HTTP가 나타났다. 이는 현재 HTTP 프로토콜의 가장 기초가 된다. 아래는 요청의 예시이다.

GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

이에 대한 응답으로 다음과 같은 형태의 메시지를 받을 수 있다.

200 OK
Date: Tue, 15 Nov 1992 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
	<IMG SRC=" /myimage.gif">
</HTML>

이렇게 본문 이외에 텍스트가 추가되었는데, 이것이 HTTP/1.0부터 새롭게 등장한 헤더(Header)이다. 헤더는 해당 메시지의 정보를 담고 있는 역할로, 이만 읽어도 이 메시지의 대략적 의미를 파악할 수 있다. 이를 통해 우리는 메시지가 정상적으로 데이터를 받아 왔는지, 지금 받는 문서의 타입은 어떤지 등을 확인하고 이에 대응할 수 있게 되었다.
❗그러나 놀랍게도, 1.0은 분산된 기능들을 하나로 정리했을 뿐 공식적인 표준은 아니었다.

HTTP/1.1

: 1.0과 큰 맥락은 동일하나, 일부 모호했던 기능들이 개선되며 진정한 표준으로 자리매김한 버전이다.

당시 1.0 버전에서는 모든 요청마다 새로운 연결을 맺어야 했다. 연결을 하고, 요청과 응답을 한 번씩 주고받고 나면 그 연결을 끊고 다시 새 연결을 하는 식이었다. 문제는, 동일한 컴퓨터 사이에서 여러 개의 콘텐츠를 요청할 때에도 매번 새 연결을 맺어야 했다는 것! 특히 한 번 연결을 할 때마다 TCP에선 3-way handshake가 이루어지니 속도가 눈에 띄게 느려졌다.

TCP : (IP가 정한 주소로 보내는 데에 집중한 규약이라면) 데이터가 정확하게 들어왔는지에 집중하는 규약, 즉 안정적인 데이터 전송[신뢰적인 전송]을 담당하는 프로토콜이 Trandsmission Control Protocol이다.
3-way handshake : 직역하면 '세 방법의 악수'인데, 세 번의 핑퐁을 거쳐 데이터를 보내는 쪽과 받는 쪽 둘 다 준비가 되었는지 확인하는 방식이다. [연결해도 될까요? - 네! 저도 연결해도 될까요? - 네 좋아요!]

이러한 문제점을 해결하기 위해 탄생한 HTTP/1.1에서는 아래와 같은 방법을 통해 효과적으로 통신 속도를 개선하게 된다.

persist connections : 한 번 TCP 연결을 맺으면 끊지 않고 계속 유지할 수 있게 한 것
pipelining : (이전 요청에 대한 응답이 도착해야만 다음 요청을 보낼 수 있어야 했던 1.0과 다르게) 이전 응답과 상관없이 한 번에 여러 개의 요청을 보낼 수 있게 해 통신 속도를 더욱 높인 것

SPDY(스피디)

: Google에서 발표한 새 프로토콜이다. 이름에서 유추할 수 있듯, HTTP/1.1의 성능 제한을 해결하고 웹 페이지의 로드 지연 시간을 줄이기 위해 만들어졌다. 이 SPDY의 발표를 흥미롭게 본 HTTP 관계자(HTTP Working Group)는 SPDY를 기반으로 새 HTTP 버전을 만들어보지 않겠냐는 제안을 했다. 이는 성사되었고, 다음의 HTTP/2가 탄생한다.

HTTP/2

: SPDY를 기반으로 HTTP/1.1에서 '성능, 속도'를 개선한 HTTP이다. 이 버전에는 다음과 같은 기능들이 추가되었다.

이전의 요청에 대한 응답을 대기하지 않고도 뒤의 응답을 먼저 받을 수 있음
한 번의 요청만으로도 여러 개의 응답을 받을 수 있음(Multiplexed Streams)
클라이언트가 요청하지 않아도 서버에서 미리 필요한 리소스들을 푸시함 (Server Push)

이를 가능케 한 HTTP/2의 핵심이 바로 바이너리 프레이밍(binary framing)이다. (우리가 읽을 수 있는 텍스트 형식이었던 HTTP 메시지를 더 작은 단위로 쪼개 바이너리 형태로 캡슐화한 것. 같은 메시지라도 더 작게 쪼개서 효율적으로 전달할 수 있게 한다!)

HTTP/3

: HTTP/2의 고질적인 문제(오래된 프로토콜인 TCP 위에서 동작하고 있었음)를 해결한 프로토콜 : QUIC을 사용한 차세대 프로토콜이다. TCP의 한계를 극복하도록 만든 프로토콜인 QUIC은 TCP가 아닌 UDP 위에서 동작한다.

UDP란?
UDP는 비연결형 서비스로서, 연결을 설정하고 해제하는 과정이 존재하지 않는다. 서로 다른 경로로 독립적으로 처리하고 패킷에 순서를 부여해 재조립한다. TCP보다 속도가 빠르며 네트워크 부하가 적다는 장점이 있지만 신뢰성 있는 데이터의 전송을 보장하지는 못한다. 따라서 신뢰성보다는 연속성이 중요한 서비스(Ex. 실시간 서비스(streaming))에 자주 사용된다.
👉 다시 말해, 데이터가 잘못 갔는지 확인하는 작업은 생략하고 계속해서 보낸다. 이로써 연속성에 초점을 맞춘 것이 UDP이다. 영상 스트리밍처럼 신뢰성보다 연속성이 중요한 부분에서 (TCP 위에서 동작하는 HTTP/2보다는) UDP 위에서 동작하는 HTTP/3가 사용된다.

📌 HTTP의 동작 방식 : 요청(Request)과 응답(Response)

HTTP는 서버/클라이언트 모델을 따른다.

서버 : 어떠한 자료에 대한 접근을 관리하는 네트워크 상의 시스템(요청에 대한 응답을 보내준다.)
클라이언트 : 그 자료에 접근할 수 있는 프로그램(Ex. 웹 브라우저, 핸드폰 어플리케이션 등)

: 클라이언트 즉, 사용자가 브라우저를 통해서 어떠한 서비스 url을 통하거나 다른 것을 통해서 요청(request)을 하면 서버에서는 해당 요청사항에 맞는 결과를 찾아서 사용자에게 응답(response)하는 형태로 동작한다.

💡 (+) 웹 브라우저에 웹 페이지가 표시되는 과정
1. 사용자가 www.naver.com 와 같은 URL을 웹 브라우저에 입력한다.
2. DNS 조회를 통하여 www.naver.com을 ip로 변환한다.
3. TCP의 3way-handshaking 연결 방식으로 웹 서버에 연결하고 http는 80, https는 443포트를 이용한다.
4. http 프로토콜을 이용하여 웹 서버에 요청(Request)한다.
5. 관련 기능에 따라 WAS와 상호 연동하며 필요한 경우 DB의 정보를 이용한다.
6. 웹 서버는 최종 정보를 웹 브라우저에 응답(Response)하고 웹 브라우저는 전송 받은 내용을 표시한다.
7. TCP의 4way-handshaking 연결 종료 방식으로 웹서버와 연결을 종료한다.

용어 설명

DNS 조회 : DNS(Domain Name System : 인터넷에서 도메인 이름과 IP 주소 간의 대응을 제공하는 시스템)를 사용하여 특정 도메인의 IP 주소나 기타 관련된 정보를 검색하는 프로세스. 사용자가 웹 브라우저나 다른 네트워크 응용 프로그램에서 도메인 이름(Ex. www.example.com)을 입력하면, 해당 도메인 이름에 대한 IP 주소를 찾아서 컴퓨터가 서버와 통신할 수 있도록 한다.
WAS : Web Application Server의 약자로, 웹 애플리케이션을 실행하기 위한 서버이다. 정적인 웹 페이지뿐만 아니라 동적인 콘텐츠를 생성하고 처리하는 데 사용된다.
TCP의 4way-handshaking 연결 종료 방식 : [ (Client)데이터 그만 보낼래. -> (Server)알겠어! -> (S)나도 데이터 그만 보낼래. -> (C)알겠어! ]

💡 대화에서도 서론-본론-결론처럼 일련의 구조가 있듯, HTTP 메시지 또한 일정한 포맷이 존재한다. 이러한 포맷은 누가 누구에게 보내는지에 따라, 즉 요청인지 응답인지에 따라 조금 다른 형식을 띤다. 아래에서 자세히 살펴보자.

HTTP 요청(Request)

: 웹 브라우저와 같은 인터넷 통신 플랫폼에서 웹 사이트를 로드하는 데 필요한 정보를 요청하는 방법

✅ HTTP 요청의 구조

요청 라인(메서드/경로/버전) + 요청 헤더 + 공백 라인 + 요청 메시지 본문

메서드(Method) : 첫 줄에는 클라이언트가 무엇을, 어떻게 처리하고자 한다는 정보가 담겨 있는데, 이때 메서드는 '어떻게', 즉 처리 방식에 해당한다.
- GET : 존재하는 자원에 대한 요청
- POST : 새로운 자원을 생성
- PUT : 존재하는 자원에 대한 변경
- DELETE : 존재하는 자원에 대한 삭제
경로(URL) : 메서드가 '어떻게'에 해당한다면 경로는 '무엇을'에 해당한다. 주로 가져오려는 리소스의 경로를 표시하며 형태는 https://www.google.com/ 처럼 완전한 형식, index.html 처럼 상대적인 형식 등 메서드의 유형에 따라 다양한 포맷이 있다.
프로토콜 버전(Version of the protocol) : HTTP 프로토콜의 버전을 표시한다. 현재는 1.1버전과 보안성을 강화한 2버전이 주를 이루고 있다.
헤더(Headers) : 서버에 대한 추가 정보를 전달한다. 주로 호스트의 정보나 접속하고 있는 사용자의 정보, 그리고 열려고 하는 페이지의 정보 등을 확인할 수 있다. 다음은 그 예시들이다.
- User-Agent : 웹 브라우저의 다른 표현. 요청하는 웹 브라우저의 정보 및 운영체제를 표시한다.
- Accept-encoding : 클라이언트가 이해할 수 있는 압축 방식을 표시한다. 이를 표기해 서버에 전송하면, 서버는 필요한 경우 해당 압축 방식으로 리소스를 압축하여 반환해 준다.
공백 라인(Empty Line) : 헤더와 본문을 구분하는 역할을 한다.
본문(Request Message Body) : 메시지의 가장 마지막에 들어가는 컨텐츠로, 다른 컨텐츠와 달리 선택적인 요소이다. GET, HEAD, DELETE, OPTIONS처럼 리소스를 가져오는 요청은 보통 본문이 필요가 없기 때문이다. POST처럼 서버에 새로운 자원을 추가해야 하는 경우에 그 정보를 본문에 작성하여 전달한다.

(+) URL이란?

Uniform Resource Locater
: 웹상에서 자원들의 위치를 나타낸 것, 특정 웹 서버의 특정 파일에 접근하기 위한 경로 혹은 주소
접근 프로토콜://IP주소or도메인 이름/문서 경로/문서이름
Ex) http://www.codecode.co.kr/does/index.html

물리적인 서버를 찾기 위해서 반드시 필요한 것은 IP주소나 도메인 주소! 물리적인 컴퓨터를 찾은 후에 해당 컴퓨터 안에 등장하는 소프트웨어 서버를 찾기 위해서는 포트 값이 필요하다.

IP는 집 주소와 같다. 하나의 컴퓨터에는 IP가 하나 존재하며, 집 안에 여러 개의 방이 존재하는 것처럼 컴퓨터에 존재하는 방을 각각 포트라고 한다. 포트 번호(0보다 큰 숫자 값)는 고유하다.
(+) http 서버는 기본 포트 값이 80번이다.

(+) URI는 식별자, URL은 식별자+위치를 나타낸다. URI가 더 포괄적인 개념이다.

HTTP 응답(Response)

: 웹 클라이언트(종종 브라우저)에서 HTTP 요청에 대한 응답으로 인터넷 서버로부터 수신하는 응답

✅ HTTP 응답의 구조

응답 라인(버전/상태코드/상태메시지) + 응답 헤더 + 공백 라인 + 응답 메시지 본문

프로토콜 버전(Version of the protocol) : 요청 메시지와 동일하며 HTTP 프로토콜의 버전을 나타낸다.
상태 코드(Status code) : 상태 코드는 클라이언트 요청의 성공 여부를 숫자로 나타낸 것이며 상태 메시지는 상태 코드를 이해하기 쉽게 영어로 풀어쓴 메시지이다. 상태 코드와 상태 메시지는 100번대부터 500번대까지 존재한다. 클라이언트가 웹 페이지를 요청한 후 가장 일반적으로 표시되는 응답의 상태 코드는 '200 OK'로, 요청을 제대로 수행했음을 나타낸다.

1xx : 조건부 응답 - 요청을 받았으며 작업을 계속합니다.
2xx : 성공 - 정상적으로 요청을 수행했습니다.
3xx : 리다이렉션 완료 - 클라이언트가 요청을 마치기 위해 추가 동작을 취해야 합니다.
4xx : 클라이언트의 요청에 오류가 있습니다.
5xx : 서버가 요청을 수행하지 못했습니다.
헤더(Headers) : 요청 헤더와 유사한 형식으로 추가 정보를 전달한다.
- content-type : 전달한 리소스의 타입. text/html이라면 텍스트 중에서도 HTML 타입이라는 뜻이다.
- content-encoding : 컨텐츠가 압축된 방식을 표시한다.
본문(Body) : 가져온 리소스가 표시된다. 만약 리소스 유형이 HTML이라면, 형태의 HTML 코드가 나타나고, 유형이 이미지 또는 동영상이면 그에 맞는 코드가 표시된다.

📌 HTTPS란?

HTTP는 정보를 텍스트로 주고받기 때문에 네트워크에서 전송 신호를 인터셉트하는 경우 원하지 않는 데이터 유출이 발생할 수 있다. 이러한 보안 취약점을 해결하기 위한 프로토콜이 HTTP에 S(Secure)를 추가한 HTTPS이다. HTTPS는 기본 골격이나 사용 목적 등은 HTTP와 거의 동일하지만, HTTPS를 사용하면 서버와 클라이언트 사이의 모든 통신 내용이 암호화된다는 것이 가장 큰 차이점이다.

'S'를 추가했다는 것은 곧, HTTP가 TCP와 직접적으로 통신하는 방식이 아니라, 보안 계층(SSL 또는 TLS) 위에 HTTP 프로토콜을 얹어 보안된 HTTP 통신을 함을 말한다.

SSL과 TLS?
SSL과 TLS는 데이터를 암호화하는 통신 프로토콜이다. (TLS가 SSL의 후속 버전이지만, SSL이 일반적으로 더 많이 사용되는 용어이다.)

HTTP와 HTTPS의 차이

HTTP는 보안에 취약한 반면, HTTPS는 안전하게 데이터를 주고받을 수 있다.
HTTPS는 암호화/복호화 과정이 필요하기에 속도가 느리다.
HTTPS는 인증서를 발급 및 유지하기 위한 비용이 발생한다.

➡️ 개인 정보와 같은 민감한 데이터를 주고받아야 한다면 HTTPS를 이용해야 하지만, 노출이 되어도 괜찮은 단순한 정보 조회 등 만을 처리하고 있다면 HTTP를 이용하는 것이 좋겠다!

HTTPS의 암호화 방식

HTTP는 비대칭키[공개키] 암호화 방식과 대칭키 암호화 방식을 함께 사용한다. 공개키 방식으로 key를 전달하고, 서로 공유된 키[대칭키]를 가지고 통신한다.

🔑 대칭키 암호화 방식이란?

동일한 키로 암호화, 복호화가 가능한 방식이다.

대칭키가 매번 랜덤으로 생성되면 누출되어도 다음에 사용할 때는 다른 키가 사용되기 때문에 안전하다.

(공개키 방식보다) 빠르게 통신할 수 있다.

🔑 비대칭키[공개키] 암호화 방식이란?

암호화와 복호화에 사용되는 키가 서로 다른 방식이다.
- A키로 암호화를 하면 B키로 복호화를 할 수 있다.
- B키로 암호화를 하면 A키로 복호화를 할 수 있다.

둘 중 하나를 개인키(Private Key)라 부르며, 이는 자신만 가지고 있고 공개되지 않는다.

나머지 하나를 공개키(Public Key)라고 부르며 타인에게 제공한다. 공개키는 유출이 되어도 비공개키를 모르면 복호화 할 수 없기 때문에 안전하다.
(비대칭키의 두 키가 개인키, 공개키이기에 비대칭키 암호화 방식을 '공개키' 암호화 방식이라고도 한다.)

HTTPS의 동작 과정

동작 과정은 두 갈래로 나누어서 살펴보자. 이는 HTTPS의 주된 기능인 다음의 두 가지를 기준으로 한다.

1. 내가 사이트에 보내는 정보들을 제3자가 못 보게 한다.
2. 접속한 사이트가 믿을 만한 곳인지를 알려준다.

✅ 첫 번째는 비교적 간결하다. 위에서 설명한 것처럼, 대칭키 암호화 방식과 비대칭키 암호화 방식을 함께 사용한다.

비대칭키 암호화 방식을 통해 서버와 클라이언트가 '키'를 공유한다.
공유한 키를 대칭키로 둬 대칭키 암호화 방식으로 데이터를 주고받는다.

✅ 비교적 복잡한 두 번째 기능은 차근차근 살펴보자.
접속한 사이트가 믿을 만한 곳인지는, 신뢰할 수 있는 제3자인 인증기관(CA : Certificate Authority)을 통해 확인할 수 있다. 그 일련의 과정은 다음과 같다.

서버는 CA로부터 인증서를 요청한다.
CA는 (서버가 안전하다고 판단되면) 자신의 개인키로 암호화한 '인증서'를 서버에게 제공한다.
클라이언트가 서버에 접속하면, 서버는 CA로부터 받은 인증서를 클라이언트에게 전송한다.
클라이언트는 CA의 공개키로 인증서를 복호화 한다.
(CA의 공개키로 복호화 가능함은 인증서가 CA의 개인키로 암호화되었음을 나타낸다. 즉, CA의 공개키로 인증서를 확인함으로써 "이 서버는 인증 기관이 인증해 준 신뢰할 수 있는 서버다!"라고 판단할 수 있다.)
인증서가 제대로 복호화 되었다면 신뢰할 수 있다고 판단해 서버에 접속한다.