-
HTTP를 이해하기 위해서 TCP/IP 전송 프로토콜에 대해 알아보자
-
HTTP (Hypertext Transfer Protocol)
- 웹상에서 클라이언트와 서버 간 통신을 위한 프로토콜 -
HTTP를 이용한 데이터 전달은 TCP 세션 기반에서 이루어짐
- Application 층에 존재
📌 HTTP/1.0
HTML 문서만 날리는 HTTP/0.9와 다르게 다양한 파일(css, image 등)을 받을 수 있도록 설계됨
-
매번 새로운 연결로 성능 저하
- 하나의 데이터를 받을 때 마다 서버 측에서 연결을 끊음
- 요청 컨텐츠마다 TCP 세션을 맺어야 함 -
서버 부하 비용 상승
- RTT(Round Trip Time) 증가 : 패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간이며 패킷 왕복 시간 -
HTTP 1.0 환경에서는 하나의 IP에 여러 개의 도메인을 운영할 수 없음
-
HTTP 1.0은 기본적으로 Connection 당 하나의 요청을 처리할 수 있음
- 그렇기 때문에 동시 전송은 불가능하고 하나의 요청에 대한 응답이 온 후 다음 요청을 처리하게 되는데,
- 수 많은 멀티미디어 리소스들이 있는 상황에서 이러한 특징은 Network Latency를 발생시킨다.
HTTP/1.0에서 RTT 감소를 위해 이미지 스플리팅, 코드 압축, base64인코딩 등 시행
📌 HTTP/1.1
💡 HTTP 1.0과 1.1의 차이는 "TCP 세션을 지속적으로 유지할 수 있는가?"의 차이를 두며 (Persistent Connection는 HTTP 1.0에서도 지원하였지만 표준화되지 않았다고 함), HTTP 1.1이 가지는 특징으로는 다음과 같다.
- HTTP/1.1의 특징
- Persistent Connection
- 지정한 timeout 동안 커넥션을 닫지 않는 방식
- Persistent 기능을 이용하여 한 개의 TCP 세션을 통해 여러 개의 컨텐츠 요청이 가능- 요청 컨텐츠마다 TCP 세션을 맺어야하는 HTTP 1.0에 반해 HTTP 1.1은 TCP 세션 처리 부하를 줄일 수 있고, 그만큼 클라이언트 응답속도가 개선된다.
- Pipelining
- 하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방식 (TCP 안에 두 개 이상의 HTTP 요청을 담음)
- 위 그림과 같이 HTTP 1.1은 동시에 요청을 보내고 이에 대한 각각의 응답을 받아 처리한다.
-> 이는 응답 속도를 높이고 페이지 뷰의 속도를 빠르게 한다
- Host Header
- HTTP 1.0 환경에서는 하나의 IP에 여러 개의 도메인을 운영할 수 없음에 반해, HTTP 1.1에서 Host 헤더의 추가를 통해 버츄얼 호스팅이 가능하다
- Imporved Authentication Procedure (강력한 인증 절차)
- HTTP 1.1 에서는 2개의 헤더(proxy-authentication,
proxy-authorization)가 추가되었다.
- 실제 서버에서 클라이언트 인증을 요구하는 www-authentication 헤더는 HTTP 1.0에서부터 지원이 됐으나, 클라이언트와 서버 사이에 프록시가 위치하는 경우 프록시가 사용자의 인증을 요구할 수 있는 방법이 없었음
- 참고자료 : 인증 관련 헤더 내용
- HTTP/1.1의 단점
- HTTP Pipelining
- HTTP 1.0의 Network Latency를 개선하기 위해 파이프라이닝이 도입되었지만,
- 이는 정확히 구현하기 힘들 뿐더러, HOL Blocking이 발생한다.
- HOL(Head of Line) Blocking
- 어떤 요청에 병목이 생겨서 전체 latency가 증가하는 것
- TCP를 사용하는 통신에서 패킷은 무조건 정확한 순서대로 처리되어야 한다. 수신 측은 송신 측과 주고 받은 시퀀스 번호를 참고하여 패킷을 재조립해야 하기 때문이다.
- 따라서, 중간에 패킷이 손실될 경우 완전한 데이터로 재조립하기 어렵기 때문에 송신 측은 해당 패킷이 제대로 전달되지 않았을 경우 재전송 해야 한다.
- 서버는 TCP에서 요청을 받은 순서대로 응답을 해야하므로, 앞선 요청에 의해 뒤의 요청이 지연된다.
- 무거운 Header
- Client-Server 간 수 많은 http 요청이 발생할 것이고, header의 정보는 대부분 동일하다.
- 하지만 HTTP 1.1에서는 헤더를 중복해서 보낼 뿐만 아니라 cookie 정보 역시 매 요청마다 헤더에 포함되어 전송된다.
- 즉, 불필요한 데이터를 주고 받는데 네트워크 자원이 소비되는 문제가 발생한다
💡 이러한 문제들은 HTTP/2.0 버전에서 개선이 된다.
📌 HTTP/2.0
- HTTP는 1996년에 1.0 버전이 처음 release 되고 1999년에 1.1버전이 등장하였다.
- 시간이 지나면서 웹에서 담아야 할 정보가 늘어나고 수 많은 멀티미디어 리소스들과 비동기 요청들이 발생함에 따라,
- 2015년에 기존 HTTP/1.X 버전의 성능 향상에 초점을 맞춘 HTTP 2.0이 등장하였다. (구글의 SPDY 기반)
- HTTP 2.0은 새로운 기능 확장이 아닌 기존 HTTP가 가지고 있던 문제점과 성능을 개선시킨 버전이다.
- HTTP/2.0의 특징
- HTTP 메시지 전송 방식의 변화
- 바이너리 프레이밍(binary framing) 계층 사용
-> 파싱, 전송 속도 ⬆️, 오류 발생 가능성 ⬇️
- 바이너리 프레이밍(binary framing) 계층 사용
- Request and response multiplexing (I/O Multiplexing)
- HTTP 1.1의 HTTP Pipelining의 개선안으로 하나의 Connection을 통해 동시에 여러 개의 메세지를 주고 받을 수 있음
- 또한, 응답은 요청 순서에 상관없이 Stream으로 받기 때문에 HOL(Head Of Line) Blocking 문제도 해결
- 즉 여러 개의 스트림을 사용하여 송수신한다는 것. 이를 통해 특정 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작할 수 있음
- Stream Prioritization
- 리소스간 우선 순위를 설정 가능
- 응답에 대한 우선순위를 정해 우선순위가 높을수록 응답을 빨리 함
- Server Push
- 클라이언트가 요청하기 전에 HTTP/2 호환 서버가 리소스를 HTTP/2 호환 클라이언트에 보낼 수 있음
- 서버 푸시는 클라이언트가 리소스가 필요할지 알기도 전에 미리 리소스를 로드하여 대기 시간을 줄이는 것을 목표로 하는 성능 기술
- 즉, 서버가 클라이언트의 요청없이 응답을 보내는 방법으로 클라이언트의 요청을 최소화하여 서버가 리소스를 보내주는 방식
- Header Compression
- HTTP 1.1의 경우 이전 요청과 중복되는 Header도 똑같이 전송하느라 네트워크 자원을 불필요하게 낭비하였음
- HTTP 2.0의 경우, 헤더의 크기를 줄여 페이지 로드 시간 감소
- Header Table과 Huffman Encoding을 사용하는 HPACK 압축방식으로 이를 개선하였음
- 클라이언트와 서버는 각각 Header Table을 관리하고 이전 요청과 동일한 필드는 table의 index만 보내고, 변경되는 값은 Huffman Encoding 후 보냄으로서 Header의 크기를 경량화
⚡ 그러나, TCP의 Head of Line Blocking 문제는 여전히 존재
📌HTTP/3.0
- 2020년 등장하였으며, TCP 위에서 돌아가는 이전 버전과 달리 HTTP3는 QUIC이라는 계층 위에서 돌아가며, TCP 기반이 아닌 UDP 기반으로 돌아간다.
- http/3.0에서는 무조건 https를 사용한다.
- 네이버는 HTTP3와 HTTP2를 혼용하여 컨텐츠를 서빙하며, 구글은 HTTP3로만 서빙
- HTTP/2.0 에서 장점이었던 멀티플렉싱을 가지고 있으며, "초기 연결 설정 시 지연 시간 감소"라는 대표적 특성이 있음
📌 QUIC (Quick UDP Internet Connections)
-
전송 계층 프로토콜 (2013년에 구글에서 공개)
-
순방향 오류 수정 메커니즘(FEC, Forward Error Correction) 적용
- 전송한 패킷이 손실되었다면 수신 측에서 에러를 검출하고 수정하는 방식이며 열악한 네트워크 환경에서도 낮은 패킷 손실률을 자랑 -
TCP가 아닌 UDP를 선택한 이유?
- TCP 헤더는 신뢰성을 확보하지만 지연을 줄이기 힘든 구조
- UDP는 데이터 전송에 집중한 설계로 별도의 기능이 없음- 따라서, 원하는 기능의 구현이 가능하며, TCP의 Latency를 줄이면서 TCP만큼 신뢰성 확보 가능
- Youtube의 라이브 스트리밍, 동영상 서비스
-
헤더 압축 또한 HPACK이 아닌 QPACK을 사용
- QUIC의 장점
-
전송 속도 향상
- 첫 연결 설정에서 필요한 정보와 함께 데이터를 전송
-> 연결 성공 시 설정을 캐싱하여 다음 연결 때 바로 성립 가능 -
Connection UUID라는 고유한 식별자로 서버와 연결
- 커넥션 수립 필요가 없음 -
TLS (전송 계층 보안, Transport Layer Security) 기본 적용
-
IP Spoofing / Replay Attack을 방지하여 보안성을 향상
- Spoofing?
- 스푸핑의 사전적 의미는 '속이다'이다. 네트워크에서 스푸핑 대상은 MAC 주소, IP주소, 포트 등 네트워크 통신과 관련된 모든 것이 될 수 있고, 스푸핑은 속임을 이용한 공격을 총칭한다.
- 근거리 통신망(LAN) 하에서 주소 결정 프로토콜(ARP) 메시지를 이용하여 상대방의 데이터 패킷을 중간에서 가로채는 중간자 공격 기법이다.
- Spoofing?
-
독립 스트림을 이용하여 향상된 멀티플렉스 기능을 제공
REF
