HTTP , HTTPS의 특징과 차이

HTTP 란

HTTP는 서로 다른 클라이언트와 서버 간 통신을 위한 기초적인 통신 규칙 세트 또는 프로토콜이다. 

사용자가 웹 서비스에 접속하면 클라이언트는 80번 포트를 통해 웹 서버에 HTTP 요청을 보내고 응답을 받는다. 이렇게 함으로써 데이터를 일반 텍스트로 교환할 수 있다.

예를 들어, 사용자가 HTTP의 요청 종류인 GET을 보내면 서버는 그에 맞는 응답 및 상태 코드를 보낸다. 상태 코드 예시는 다음과 같다.

200 - OK(정상)
400 - Bad request(잘못된 요청)
404 - Resource not found(리소스를 찾을 수 없음)

 

 

HTTP는 TCP/IP 위에서 작동하는 무상태(stateless) 프로토콜이며 다음과 같은 구조를 가진다.

이미지 출처 : https://mangkyu.tistory.com/98

 

하지만 HTTP는 평문 데이터를 전송하기에 제 3자가 그 데이터를 조회할 수 있다는 보안 이슈가 있다.

 

 

HTTP REQUEST 방식 종류

방식	목적
GET	리소스 조회
POST	요청 데이터 처리
PUT	리소스 대체(덮어 쓰기) , 해당 리소스가 없으면 생성
PATCH	리소스 부분 변경
DELETE	리소스 삭제

 

HTTP 버전 별 차이

HTTP/1.0

기본적으로 연결의 수명이 짧으며 HTTP 요청당 TCP hand-shake가 발생해서 각각 연결을 처리한다.

이로 인해 서버의 오버헤드가 발생하고 *RTT가 늘어나는 문제가 있었다.

 

RTT(Round Trip Time) : 어떤 메세지가 두 장치 사이를 왕복하는 데 걸린 시간

 

HTTP/1.1

1.0 버전의 단점을 보완한 프로토콜이다. 크게 3가지의 개선점이 있다.

 

1. keep alive default

요청할 때마다 TCP 연결을 하는 것이 아닌 keep alive 옵션을 기본 옵션을 함으로써 계속해서 데이터를 받을 수 있다.

 

2. 호스트 헤더

1.1 버전부터 서버는 여러 대의 호스트를 가질 수 있으며 항상 호스트를 헤더에 포함에서 요청을 보내야한다.

 

3. Persistent Connection (대역폭 최적화)

지정한 time out 시간 내에 기존 connection을 재사용할 수 있다. 

기존에는 파일을 다운로드 받다가 끊기면 처음부터 받아야했지만, 1.1 버전부터 이어서 다시 다운로드 받을 수 있다.

 

이외에도 요청을 최소화하기 위한 여러 기술들을 도입했다.

 

1. 이미지 스프라이트

하나의 이미지만 다운받고 여러 개의 이미지를 다운받은 듯한 효과를 낸다.

 

2. 코드 압축

 

3. Base64 인코딩

이미지 파일을 64진법으로 이루어진 문자열로 인코딩해서 이미지 서버에 대한 HTTP 요청을 줄인다.

하지만 파일 크기가 더 커진다는 단점이 있다.

 

 

HTTP/1.1의 문제점 : HOL

그러나 HTTP/1.1 은 HOL(Head Of Line Blocking)이라는 고질적인 문제가 있었다.

HTTP/1.1부터는 여러 요청을 보내고 순서대로 응답을 받는 파이프라이닝이 가능해졌는데 이로 인해 치명적인 문제가 생겼다.

예를 들어 파이프라인으로 인해 1번 요청에 문제가 생기면 그 뒤에 요청이 줄줄이 지연되는 것이다.

RFC 문서 원칙에 따라 요청이 온 순서대로 처리해야 되기 때문에 다음과 같은 문제가 생겼다.

이미지 출처 : https://withbundo.blogspot.com/2021/02/httphol-head-of-line-blocking.html

 

 

 

HTTP/2.0

 

바이너리 포맷 계층

더 작은 프레임으로 메세지를 전송하기 위해 어플리케이션과 통신 계층 사이에 바이너리 포맷 계층을 추가하였다. 

 

 

멀티 플렉싱

단일 TCP 연결에서 스트림을 통해 여러 HTTP 요청과 응답을 비동기적으로 받을 수 있다.

기존에는 다중 TCP 연결을 통해서만 병렬 요청이 가능했지만 HTTP/2.0 부터는 리소스를 작은 프레임으로 나누고 스트림으로 프레임을 병렬적으로 전달한다. 이를 통해 HTTP/1.1의 문제인 HOL을 해결할 수 있다.

 

또한 각각의 프레임은 스트림 id가 있기 때문에 응답 순서와 상관없이 데이터를 조립할 수 있다.

 

 

서버 푸시

클라이언트의 별도 요청이 없더라도 서버가 필요할 것 같은 데이터를 미리 응답에 같이 보낼 수 있다.

 

헤더 압축

무거운 헤더를 최소화하기 위해 중복된 헤더는 한번만 보내고 중복되지 않은 값은 *허프만 인코딩을 통해 압축시킨다.

 

허프만 인코딩: 문자열을 문자 단위로 쪼개서 빈도가 높은 정보는 적은 비트수를 사용하고, 빈도가 낮은 정보는 비트수를 많이 사용한다.

 

우선 순위

서버에서 원하는 순서대로 우선순위를 정해서 리소스를 전달할 수 있다.

 

HTTP/3.0

TCP 연결로 인한 오버헤드 및 RTT 시간 증가의 문제점을 해결한 버전이다.

이 버전부터 UDP 프로토콜 기반의 QUIC(Quick UDP Internet Connections)로 동작하며 이전 버전들의 장점, 특징들은 대부분 가지고 있다.

 

또한 QUIC는 TLS로 암호화 통신을 구축할 때 hand shake를 통해 서버와의 연결까지 진행함으로써 1-RTT만에 연결을 수립할 수 있다.

기존 UDP는 데이터의 무결성을 보장하지 못하는 프로토콜이었지만, QUIC는 에러를 검출하고 수정할 수 있는 순방향 오류 제어 메커니즘을 가지고 있다.

 

HTTPS와의 차이점

HTTP의 보안적인 한계를 SSL/TLS를 사용함으로써 해결한 것이 HTTPS이다.

SSL은 서버와 클라이언트 사이에 암호화 된 연결을 만들어주고 데이터들이 도난되는 것을 방지한다.

 

SSL 인증서는 클라이언트와 서버 간 주고받는 데이터들을 암호화한다. 그렇기 때문에 데이터가 탈취된다 하더라도 암호화 된 상태이기 때문에 제 3자는 알 수 없다.

또한 SSL 외에도 TLS 프로토콜을 통해서도 데이터 무결성을 제공함으로써 보안을 강화한다.

 

HTTPS는 보안 상의 이점도 있지만 구글이 안전하다고 신뢰하는 사이트라는 반증이기 때문에 검색엔진 최적화(SEO)측면에서도 많은 이점을 얻을 수 있다.

 

HTTPS의 동작 방식

HTTPS의 가장 큰 특징은 암호화를 한다는 점인데 암호화 방식은 크게 두가지로 분류된다.

암호화를 통해 의도된 송수신자를 제외하고는 데이터 유출을 방지하고 데이터의 무결성을 보장한다.

 

대칭키 암호화

클라이언트와 서버가 동일한 키를 하나만 사용해서 암호화한다.

키가 노출될 위험이 있지만 연산 속도가 빠르다는 장점이 있다.

ex)

Plaintext + key = ciphertext: hello + 2jd8932kd8 = X5xJCSycg14=

Ciphertext + key = plaintext: X5xJCSycg14= + 2jd8932kd8 = hello

-> 만약 데이터를 전송하는 과정에서 key를 탈취당하면 제 3자가 데이터를 볼 수 있다.

 

비대칭키 암호화

두 개의 다른 키로 데이터를 암호화하거나 복호화하고 공개키는 누구나 사용할 수 있다.

예를 들어 공개키로 암호화된 데이터는 개인키로만 복호화가 가능하다.

암호화를 개인키로 할것인지 공개키로 할 것인지에 따라 얻는 효과가 달라진다.

 

공개키 암호화: 개인키로만 복호화할 수 있으므로 해당 데이터는 자신만 확인 가능하다.

대칭키 암호화 방식은 데이터 전송 과정에서 키가 탈취될 위험이 있었지만 공개키 암호화 방식은 공개키가 탈취되도 상관이 없다.

수신측에서는 공개키로 암호화 한 다음에 다시 개인키로 복호화해서 데이터를 확인할 수 있다.

제3자는 개인키를 가지고 있지 않기 때문에 공개키로 암호화된 데이터를 탈취하더라도 데이터를 확인할 수 없다.

 

개인키 암호화: 모두에게 공개된 공개키로 복호화하므로 인증된 정보임을 신뢰할 수 있다.

A는 원본 데이터와 개인키로 암호화된 데이터를 전송한다. 그러면 B에서는 공개키를 통해 암호화된 데이터를 복호화하고 해당 데이터가 원본 데이터와 일치하면 신뢰할 수 있는 정보임을 인증할 수 있다.

하지만 공개키로 복호화를 하였을 때 원본 데이터와 다르다면 해당 데이터는 A가 아닌 제3자가 암호화한 데이터이므로 신뢰할 수 없다.

 

TLS Hand Shaking

SSL은 SSL 1.0 부터 시작해서 명칭이 바뀌어 TLS 1.3 버전에 이르렀다.

TLS는 전송 계층에서 제 3자가 메세지를 도청하거나 변조하지 못하게 보안을 제공하는 프로토콜이다.

 

이 과정에서 비대칭키 암호화와 대칭키 암호화를 모두 사용하여서 빠른 연산 속도와 안정성을 제공한다.

먼저 처음 연결이 진행될때는 안전한 연결을 위해 속도가 다소 느린 비대칭키 암호화를 사용하고, 이후에는 빠른 통신을 위해서 대칭키를 사용한다.

 

 

Client : Client Hello

패킷에 TLS Version, Client가 지원하는 암호화 방식(사이퍼슈트), Client Random Data(클라이언트에서 생성한 난수로 대칭키를 만들 때 사용), 임시 *DH변수, SNI(서버명) 를 담아서 보낸다.

 

DH 매개변수 : DH는 Die-Hellman을 의미하며 Die-Hellman 알고리즘은 서로 공개값 공유,비밀값과 혼합, 혼합값과 공유, 각자의 비밀값과 혼합해서 공통의 암호키를 만드는 알고리즘이다. 모든 TLS 통신이 DH 매개변수를 사용하지는 않음

 

Server Hello, EncryptedExtensions, Certificate, CertificateVerify

서버는 클라이언트로부터 받은 옵션을 확인하고 공개키가 포함된 인증서와, 서버랜덤값, DH 매개변수를 브라우저에 보낸다.

 

Client : Client Key Exchange

클라이언트가 서버로부터 받은 DH매개변수(혹은 공개키)를 이용하여 세션키를 생성한다.

이렇게 생성된 세션키를 다시 공개키로 암호화해서 서버에 보내면, 서버는 개인키로 복호화를 할 수 있다.

 

Server & Client : Finished

클라이언트와 서버의 세션키를 기반으로한 대칭 암호화된 통신이 시작된다.

 

만약 세션키가 생성된 이후 다시 그 사이트에 방문한다면, 미리 만들어놓은 세션키로 통신하기 때문에 인증에 드는 비용은 없다.