애플리케이션 계층(Application Layer) - HTTP/1.0에서 HTTPS까지

안녕하세요 동쪽별입니다. 이번에는 정~말 중요한 HTTP를 들고 왔어요 😆

지난 포스트 웹 브라우저가 메시지를 만든다 글에서 HTTP에 대해 자세히 다루지 않았기에, 이번 글에서 알아보려해요.

 

목차 

• HTTP?
• HTTP/1.0
• HTTP/1.1
• HTTP/2
• HTTP/3
• HTTPS

 

---

 

HTTP?

HTTP(HyperText Transfer Protocol)은 웹 상에서 서버-클라이언트 모델을 따라 데이터를 주고받기 위한 프로토콜입니다.

• 주로 HTML 문서를 주고받는데 쓰입니다.
• TCP와 UDP를 사용하며, 80번 포트를 사용합니다.

HTTP는 중요한 두가지 특징이 있습니다.

• 비연결(Connectionless)
  • 클라이언트가 요청을 서버에 보내고, 서버가 적절한 응답을 클라이언트에 보내면 바로 연결이 끊깁니다.
• 무상태(Stateless)
  • 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않습니다.

 

그럼 1.0 버전부터 3 버전까지 알아봅시다!

 

---

 

HTTP/1.0

HTTP/1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되었습니다.

이는 RTT 증가를 불러오게 되었습니다.

 

 

RTT란 Round Trip Time의 줄임말로 패킷이 목적지에 도달한 후 다시 출발지로 돌아오기까지 걸리는 시간, 즉 패킷 왕복 시간을 의미합니다. 

HTTP/1.0의 한 연결당 하나의 요청 처리는 서버로부터 파일을 가져올 때마다 TCP의 3-way hanshake를 계속해셔 열어야 하기 때문에 RTT가 증가되는 것입니다.

TCP 통신을 위한 네트워크 연결은 3-way handshake 라는 방식으로 연결됩니다. 서로의 통신을 위한 포트를 확인하고 연결하기 위하여 3번의 요청/응답 후에 연결이 되는 것을 말합니다. (위 이미지처럼) 이 과정에서 가장 많은 시간이 소요되어 UDP 방식보다 속도가 느려지는 주요 원인으로 지목됩니다.

이를 해결하기 위한 방법으로는 다음과 같습니다.

• 이미지 스플리팅
  • 웹페이지를 구성하는 다양한 이미지 파일의 요청 횟수를 줄이기 위해, 이미지들을 하나의 큰 이미지로 만든 다음 CSS에서 해당 이미지의 좌표 값을 지정해 표시하는 방법입니다.
• 코드 압축
  • 코드를 압축해서 개행 문자, 빈칸을 없애 코드의 크기를 최소화하는 방법입니다.
• 이미지 Base64 인코딩 (Data URI Scheme)
  • 이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법입니다.
  • 하지만 Base64 문자열로 변환할 경우 37% 정도 크기가 더 커지는 단점이 있습니다.

 

---

 

HTTP/1.1

매번 TCP 연결을 하는 것이 아니라, 한번 TCP 초기화를 한 이후에 keep-alive 라는 옵션으로 여러 개의 파일을 송수신할 수 있게 바뀌었습니다.

 

 

즉, 한번 TCP 3-way handshake가 발생하면 그 다음부터 발생하지 않는 것입니다.

하지만 문서 안에 포함된 다수의 리소스(이미지, css, script 등)을 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어진다는 단점이 여전히 존재합니다. 

동시 전송이 불가능하고, 요청과 응답이 순차적으로 이루어지기 때문이죠. 

왜? 한 연결당 하나의 요청을 처리하도록 설계되었으니까요!

 

HOL Blocking

• Head Of Line Blocking의 줄임말입니다.
• 네트워크에서 같은 큐에 있는 패킷이 이전 패킷에 의해 지연될 때 발생하는 성능 저하 현상입니다.
• 예를 들어 이미지와 css, xml 등을 다운로드 받을 때, 이미지가 느리게 받아진다면 그 뒤에 있는 것들이 대기하게 되며 다운로드가 지연되는 상태가 되는 것입니다.

 

이러한 HOL Blocking 문제 뿐 아니라 아래 단점 또한 존재합니다.

 

무거운 헤더 구조

• HTTP/1.1의 헤더에는 쿠키 등 많은 메타데이터가 들어있고 압축이 되지 않아 무겁습니다.
• 또한 매 요청마다 중복된 헤더 값을 전송하게 됩니다.

 

---

 

HTTP/2

HTTP/2는 SPDY 프로토콜에서 파생되어 HTTP/1.1보다 지연 시간을 줄이고 응답 시간을 더 빠르게 합니다.

 

 

SPDY

• 처리량 관점이 아닌 지연 시간 관점에서 HTTP를 고속화한 프로토콜입니다.
• 기존 HTTP를 대치한 것이 아닌, HTTP를 재정의하는 형태입니다.
• 멀티 플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위 처리를 지원하는 프로토콜입니다.

 

멀티플렉싱

• 하나의 연결로 동시에 여러개의 메시지를 주고받을 수 있으며, 순서에 상관없이 스트림으로 주고 받습니다.
  • 스트림(Stream)? 시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름입니다. 
  • 메시지를 독립된 프레임으로 조각내어 서로 송수신한 이후 다시 조립하며 데이터를 주고 받는 원리를 말합니다.
• 이를 통해 특정 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미칩니다.

• 따라서 단일 연결을 사용하여 병렬로 여러 요청을 받을 수 있고, 응답을 줄 수 있습니다.
• 이렇게 되면 HTTP/1.1에서 발생하는 문제인 HOL Blocking 문제를 해결할 수 있는 것입니다.

 

헤더 압축

• 허프만 코딩 압축 알고리즘을 사용하여 HAPCK 압축 형식을 가짐으로, HTTP/1.1의 무거운 헤더 문제를 해결합니다.
  • 허프만 코딩? 문자열을 문자 단위로 쪼개어 빈도수를 세고, 빈도가 높은 정보는 적은 비트 수를 사용하여 표현하며, 빈도가 낮은 정보는 비트 수를 많이 사용하여 표현하는 것을 말합니다.
  • 이를 통해 전체 데이터의 표현에 필요한 비트양을 줄입니다.

 

서버 푸시

• HTTP/1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운로드 받을 수 있었다면, HTTP/2는 클라이언트 요청없이 서버가 바로 리소스를 푸시할 수 있습니다.

• HTML에는 CSS나 JavaScript 파일이 포함되기 마련인데, HTML을 읽으면서 그 안에 들어있던 CSS 파일을 서버에서 푸시하여 클라이언트에 먼저 줄 수 있는 것입니다.

 

스트림 우선순위

• 클라이언트가 요청한 HTML 문서 안에 CSS 파일 1개와 Image 파일 2개가 존재하고, 이를 클라이언트가 각각 요청한 후 Image 파일보다 CSS 파일의 수신이 늦어지는 경우 브라우저의 렌더링이 늦어지는 문제가 발생할 수 있습니다.
• HTTP/2의 경우 리소스간의 의존관계(우선순위)를 설정하여 이러한 문제를 해결합니다.

 

---

 

HTTP/3

TCP 위에서 돌아가는 HTTP/2와 달리 QUIC 이라는 계층 위에서 돌아가며, TCP 기반이 아닌 UDP 기반으로 돌아갑니다.

• QUIC? Quck UDP Internet Connection의 약자로, 말 그대로 UDP를 사용하여 인터넷 연결을 하는 프로토콜입니다.
• QUIC을 이용한 HTTP/3은 새로운 연결의 handshake로 인한 지연 시간이 감소됩니다.

• QUIC은 첫 연결 설정에 1-RTT만 소요됩니다.
  • 클라이언트가 서버에 어떤 신호를 한번 주고, 서버도 거기에 응답하기만 하면 바로 통신 시작이 가능합니다.
• QUIC은 순방향 오류 수정 메커니즘(FEC, Forward Error Correction)으로 신뢰성을 확보합니다.
  • 이는 전송한 패킷이 손실되었다면 수신측에서 에러를 검출하고 수정하는 방식입니다.
  • 열악한 네트워크 환경에서도 낮은 패킷 손실률을 자랑합니다.

 

---

 

HTTPS

HyperText Transfer Protocol over Secure Socket Layer의 약자입니다.

HTTP over TLS, HTTP over SSL, HTTP Secure 등으로도 불립니다.

이름에서 알 수 있듯이 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전의 프로토콜입니다.

• HTTPS의 기본 TCP/IP 포트로 443번을 사용합니다.
• HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신, 웹 상에서 정보를 암호화하는 TLS(SSL) 프로토콜을 통해 세션 데이터를 암호화합니다.
  • TLS(Transport Layer Security) 프로토콜은 SSL(Secure Socket Layer) 프로토콜에서 발전한 것입니다.
  • 두 프로토콜의 주요 목표는 기밀성(사생활 보호), 데이터 무결성, ID 및 디지털 인증서를 사용한 인증을 제공하는 것입니다.

 

이처럼 HTTPS는 데이터의 적절한 보호를 보장합니다.

보호의 수준은 웹 브라우저에서의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 달려있습니다.

금융 정보나 메일 등 중요한 정보를 주고받는 것은 HTTPS!

아무나 보아도 상관없는 페이지는 HTTP를 사용합니다!

 

HTTPS가 필요한 이유에 대해서 더 자세히 설명하겠습니다.

웹 브라우저가 서버에 HTTP를 통해 웹 페이지나 이미지 정보를 요청하면 서버는 이 요청에 응답하여 요구하는 정보를 제공하겠죠?

웹 페이지(HTML)은 텍스트이고, HTTP를 통해 이러한 텍스트 정보를 교환하는 것인데..

이때 주고받는 텍스트 정보에 주민등록번호나 비밀번호와 같이 민감한 정보가 포함되어있다면..?

네트워크 상에서 제 3자가 중간에 정보를 가로챌 수 있는 보안상 큰 문제가 발생합니다.

즉! 중간에서 정보를 볼 수 없도록 주고받는 정보를 암호화하는 방법인 HTTPS를 사용하는 것입니다.

 

HTTPS의 원리

암호화, 복호화시킬 수 있느 키가 서로 동일한 암호화 방법을 대칭키 암호화라 합니다.

반대로 암호화, 복호화시킬 수 있는 서로 다른키(공개키, 개인키)를 이용한 암호화 방법을 비대칭키 암호화라 합니다.

• 공개키(Public Key): 공개키 저장소에 등록하여 모두에게 공개합니다.
• 개인키(Private Key): 개인에게만 공개합니다. 클라이언트-서버 구조에서는 서버가 가지고 있습니다.

 

대칭키는 비대칭키 암호화 방식에 비해 속도가 빠르다는 장점이 있지만, 키를 교환해야한다는 문제 (키 배송 문제)가 발생합니다.

키를 교환하는 중 키가 탈취될 수 있는 문제도 있고, 사람이 증가할수록 전부 따로 키 교환을 해야하기 때문에 관리해야 할 키가 방대하게 많아집니다.

 

비대칭키는 대칭키 암호화 방식에 비해 키 분배가 필요없고, 개인키를 가지고있는 수신자만이 암호화된 데이터를 복호화할 수 있으므로 일종의 인증기능도 제공합니다.

하지만 대칭키 암호화 방식에 비해 속도가 느립니다.

 

HTTPS는 대칭키 암호화와 비대칭키 암호화를 모두 사용하여 빠른 연산 속도와 안정성을 모두 얻습니다!

• HTTPS 연결 과정(handshaking)에서는 먼저 서버와 클라이언트 간에 세션 키를 교환합니다.
  • 여기서 세션키는 주고받는 데이터를 암호화하기 위해 사용되는 대칭키입니다.
  • 이를 통해 빠른 연산 속도로 데이터를 교환할 수 있습니다.
• 문제는 이 세션키를 '클라이언트와 서버가 어떻게 교환할 것인가' 인데, 이 과정에서 비대칭키가 사용됩니다.

 

→ 즉, 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키가 사용되는 것이고, 이후 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용되는 것입니다.

 

1. 클라이언트(브라우저)가 서버로 최초 연결 시도를 합니다.
2. 서버는 공개키(엄밀히는 인증서)를 브라우저에게 넘겨줍니다.
3. 브라우저는 인증서의 유효성을 검사하고 세션키를 발급합니다.
4. 브라우저는 세션키를 보관하며 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송합니다.
5. 서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻습니다.
6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암/복호화를 진행합니다.

 

그럼 이러한 비대칭키는 어떻게 발급할까요?

 

서버는 클라이언트와 세션키를 공유하기 위한 공개키를 생성해야 하는데, 일반적으로 인증된 기관(CA, Certificate Authority)에 공개키를 전송하여 인증서를 발급받습니다.

1. A기업은 HTTP 기반의 애플리케이션에 HTTPS를 적용하기 위해 공개키/개인키를 발급합니다.
2. CA 기업에게 돈을 지불하고, 공개키를 저장하는 인증서의 발급을 요청합니다.
3. CA 기업은 CA 기업의 이름, 서버의 공개키, 서버의 정보 등을 기반으로 인증서를 생성하고, CA 기업의 개인키로 암호화하여 A 기업에게 이를 제공합니다.
4. A기업은 클라이언트에게 암호화된 인증서를 제공합니다.
5. 브라우저는 CA기업의 공개키를 미리 다운받아 갖고 있어, 암호화된 인증서를 복호화합니다.
6. 암호화된 인증서를 복호화하여 얻은 A기업의 공개키로 세션키를 공유합니다.

 

HTTPS의 장단점

HTTP는 암호화가 추가되지 않았기 때문에 보안에 취약한 반면, HTTPS는 안전하게 데이터를 주고받을 수 있습니다.

하지만 HTTPS를 이용하면 암호화/복호화 과정이 필요하기 때문에 HTTP보다 속도가 느립니다. (오늘날에는 거의 차이를 못 느낄 정도라 합니다)

또한 HTTPS는 인증서를 발급하고 유지하기 위한 추가 비용이 발생합니다.

 

따라서,

개인 정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를 이용!

노출이 되어도 괜찮은 단순한 정보 조회 등 만을 처리한다면 HTTP를 이용!

 

 

.

.

.

 

 

더 자세히 파고들면 HTTP 관련 많은 내용이 있지만..!

최대한 중요한 내용들을 하나의 글에 담으려 노력했습니다.

저 같은 프론트엔드 개발자에게 HTTP는 꼭 알아야 하는 필수 개념입니다.

HTTP, HTTPS! 꼭 알아둡시다. (기술 면접에서 단골 질문이래요 🤭)

 

 

※ 참조

HTTP/1.1 VS HTTP/2

HTTP/3는 왜 UDP를 선택한 것일까?

[Web] HTTP와 HTTPS의 개념 및 차이점

[Network] TCP / UDP의 개념과 특징, 차이점

대칭키 vs 공개키(비대칭키) 암호화 차이