TIL 52 | HTTP Version & HTTPS

임종성·2021년 10월 17일

TIL

목록 보기

20/22

HTTP(Hyper Text Transfer Protocol)란 클라이언트와 서버 사이에 이루어지는 요청과 응답에 대한 통신규약(Protocol)입니다. HTTP의 특징은 무엇이고, 어떻게 발전해왔는지 알아보겠습니다.

HTTP & HTTPS

HTTP

HTTP(Hyper Text Transfer Protocol)는 인터넷 웹에서 클라이언트와 서버간 요청(Request)와 응답(Response)으로 정보를 주고 받을 수 있는 통신규약(Protocol)입니다.

주로 HTML 문서를 주고받는데 쓰입니다.
HyperText라는 텍스트를 주고받기에 네트워크에서 전송신호를 Intercept하면 원치 않는 데이터 유출이 발생합니다.
TCP, UDP를 사용하며 80번 포트를 사용합니다.
비연결 지향(Connectionless)
- 클라이언트가 request를 서버에 보내고, 서버가 클라이언트에 요청에 맞는 response를 보내면 바로 연결을 끊습니다.
상태정보 유지 안 함(Stateless)
- 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않습니다.

HTTPS

HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer)는 HTTP의 보안 취약점을 해결하기 위해 강화된 버젼의 프로토콜입니다.

HTTPS 프로토콜의 특징

HTTPS의 기본 TCP/IP 포트로 443번 포트를 샤용합니다.
기본 골격과 사용목적은 HTTP와 거의 동일하지만 소켓 통신에서 일반 텍스트를 사용하지 않고 TLS나 SSL 프로토콜을 통해 정보를 암호화합니다.

쉽게 말해 클라이언트와 서버 사이의 모든 통신 내용을 암호화하여 보안을 강화합니다.

HTTPS 프로토콜의 원리

암호화, 복호화시킬 수 있는 서로 다른 키(공개키, 개인키)를 사용하여 암호화합니다.
- 공개키: 모두에게 공개하여 공개키 저장소에 등록합니다.
- 개인키(비공개키): 개인이 소유하고 있는 비공개키입니다.
공개키로 암호화하면 개인키로만 복호화할 수 있고, 개인키로 암호화하면 공개키로만 복호화할 수 있습니다.
클라이언트(공개키) - 서버(개인키)
- 클라이언트가 데이터를 공개키로 암호화하면 개인키를 가지고 있는 서버만 복호화하여 데이터를 얻을 수 있습니다.
- 서버가 데이터를 제공하면 공개키를 가지고 있는 클라이언트 모두가 데이터를 얻을 수 있습니다.

HTTPS의 장점과 단점

HTTPS의 장점
- HTTP에 비해 보안이 강화된 만큼 안전합니다.
HTTP의 단점
- 보안기능이 추가된 만큼 HTTP보다 처리 속도가 느립니다.
- 보안을 위해 인증서를 발급하고 유지하기 위한 추가 비용이 발생합니다.
- 암호화하는 과정이 웹 서버에 부하를 줍니다.

따라서 금융정보, 개인정보와 같이 보안에 민감한 데이터를 주고받는다면 HTTPS 프로토콜을 사용하고, 단순한 정보 조회와 같이 보안에 문제 없는 데이터를 주고받는다면 HTTP 프로토콜을 사용하는 것이 합당합니다.

HTTP 1.0/1.1/2.0/3.0

HTTP 1.0

단순히 open/operation/close 방식을 취하고 있는 단순한 구조입니다.
TCP Connection당 하나의 URL만 fetch합니다.
매번 request/response가 끝나면 연결이 끊기므로 필요할 때마다 다시 연결해야하는 단점이 있어 속도가 현저히 느립니다.
URL의 크기가 작고 한번에 가져올 수 있는 데이터의 양이 제한되어 있습니다.
반복되는 disconnect로 서버에 계속 접속하면 과부하가 걸리고 성능이 떨어집니다.

HTTP 1.1

Persistent Connection(Keep-alive)

연결을 지속하여 클라이언트와 서버 통신이 이루어집니다.
HTTP 1.0은 요청마다 TCP 연결을 3-way handshake 방식으로 맺어야 했습니다.(1 GET 1 Connection)
이와 다르게 HTTP 1.1은 Persistent 기능을 이용해 한 개의 TCP 세션을 통해 여러 요청이 가능합니다.
따라서 서버가 세션 처리 부하를 줄일 수 있고 그만큼 클라이언트의 응답 속도가 개선됩니다.

Pipelining

HTTP 1.0에서는 Request와 Response는 순차적으로 이루어졌습니다.
이를 해결하기 위해 여러 요청에 대한 응답을 뒤로 미루는 방법을 사용합니다.
따라서 하나의 Connection 요청으로 다수의 Request, Response를 처리하고 클라이언트-서버 간 요청과 응답 효율성을 개선했습니다.
그러나 응답이 순차적으로 이루어지므로 결국 후순위 응답은 미루어질 수 밖에 없습니다.

Header에는 많은 메타정보가 저장되어 있습니다.
다수의 HTTP Request에 대해 매 요청시마다 중복된 Header값을 전송합니다.
Domain에 설정된 Cookie정보도 헤더에 포함되어 전송 값보다 헤더 값이 큰 경우가 많습니다.

HTTP 2.0

Multiplexed Stream

하나의 Connection으로 동시에 여러 메시지를 주고 받을 수 있으며, 응답은 순서에 상관없이 Stream으로 주고 받습니다.
HTTP 1.1의 Connection Keep-alive, Pipelining의 개선이라 볼 수 있습니다.
Stream Prioritization
- 리소스간의 의존관계(우선순위)를 설정하여 요청/응답의 효율을 개선했습니다.
Header Compression
- HTTP 1.1에서 Header는 여러 요청에 대해 중복된 값과 쿠키정보를 담아 불필요하게 무거웠습니다.
- HTTP 2.0은 Header 정보를 압축하기 위해 HPACK 압축방식을 사용합니다.
- Header에 중복 값이 존재하는 경우 중복 Header를 검출하여 Index만 전송하고 나머지 Header 정보는 Huffman Encoding 기법으로 인코딩합니다.

HTTP 3.0

HTTP 2.0은 여전히 TCP를 이용하기 때문에 Handshake의 RTT(Round Trip Time)로 인한 Latency(지연시간), TCP의 HOLB 문제가 발생합니다. 따라서 이러한 문제를 해결하기 위해 QUIC을 사용하는 HTTP 3.0으로 발전했습니다.

QUIC(Quick UDP Internet Connection)

HTTP 2.0에서 TCP + TLS에 해당하며, 보안 및 향상된 기능을 제공하는 UDP 기반 전송계층 프로토콜입니다.
RTT 감소로 인한 지연시간 단축
- UDP의 사용으로 TCP의 3-way Handshke 과정을 거치지 않습니다.
- 연결 설정에 필요한 정보와 함께 데이터도 보내 첫 연결 설정에 1 RTT, 다음 연결은 0 RTT로 통신이 가능합니다.
Header에 별도 패킷 번호 공간을 부여해 패킷의 고유 번호를 가지고 있습니다,.
- 이를 통해 패킷 손실 감지와 패킷에 대한 흐름 제어를 효율적으로 할 수 있습니다.
클라이언트의 IP가 바뀌어도 연결이 유지됩니다.
- TCP는 IP와 포트로 연결을 식별하기에 IP가 바뀌면 연결이 끊깁니다.
- 반면 QUIC은 IP와 무관한 Connection ID를 이용해 서버와 연결을 생성합니다.
- 따라서 클라이언트 IP가 바뀌더라도 기존 연결을 유지할 수 있습니다.