HTTP는 애플리케이션 계층에 존재하며, 웹 서비스 통신에 사용
HTTP/1.0 부터 시작해 발전하여 현재는 HTTP/3이다.
1. HTTP/1.0
HTTP/1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계
👉 RTT 증가 야기
서버로부터 파일을 가져올 때마다 TCP의 `3-Way Handshake`를 계속 열어야 하기 때문에 RTT가 증가함
RTT (Round Trip Time): 패킷이 목적지에 도달하여 다시 출발지로 돌아오는 시간
RTT 증가를 해결하기 위한 방법
연결할 때마다 RTT가 증가하니, 서버에 부담 多, 사용자 응답 시간 長
👉 이미지 스플리팅, 코드 압축, 이미지 Base64 인코딩 사용
이미지 스플리팅
- 많은 이미지를 다운로드 받으면 과부하가 걸리기 때문에, 합쳐 있는 하나의 이미지를 다운로드 받음
- 이를 기반으로 background-image의 position을 이용하여 이미지 표기
#icons>li>a {
backgound-img: url("icons.png")
}
#icons>li:nth-child(1)>a {
backgound-position: 2px -8px;
}
#icons>li:nth-child(2)>a {
backgound-position: -29px -8px;
}하나의 icons.png를 기반으로 background - position 을 활용해 2개의 이미지 설정
코드 압축
코드를 압축해서 개행 문자, 빈칸을 제거 → 코드 크기 최소화
이미지 Base64 인코딩
- 이미지 파일을 64진법으로 이루어진 문자열로 인코딩
- 서버와의 연결을 열고 이미지에 대해 서버에 HTTP 요청을 할 필요가 없음!
- 크기가 37% 더 커지는 단점 존재
❓ 인코딩
정보의 형태나 형식을 표준화, 보안, 처리 속도 향상, 저장 공간 절약 등을 위해 다른 형태나 형식으로 변환하는 처리 방식
2. HTTP/1.1
- HTTP/1.0에서 발전함.
- 매번 TCP 연결을 하는 것이 아닌,
한 번 TCP 초기화를 한 이후에 `keep-alive` 옵션으로 여러 개의 파일을 송수신할 수 있도록 변경됨 - 헤더에는 쿠키 등 많은 메타데이터들 들어 있고 압축이 되지 않아 무거움
📌 HTTP/1.0 에서도 keep-alive가 있었으나, 표준화가 되어있지 않았음!
HTTP,1.1은 한 번 3-Way Handshake가 발생하면, 그 다음부터는 발생하지 않음
하지만, 문서 안에 포함된 다수의 리소스(이미지, 동영상, .css, .js)를 처리 시 요청할 리소스 개수 ∝ 대기 시간
TCP Teardown = TCP 4-way Handshake (연결 종료)
HOL Blocking (Head Of Line Blocking)
HOL Blocking은 네트워크에서 같은 큐에 있는 패킷이 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상
- HTTP/1.1은 기본적으로 하나의 TCP 연결에서 한 번에 하나의 요청/응답만 처리할 수 있는 구조
- = A 요청을 보낸 후, 서버의 응답이 오기 전까지는 다음 요청을 보낼 수 없음
👉 이로 이해 앞의 요청이 느리면 뒤의 요청이 대기해야 하는 HOL Blocking 현상 발생
3. HTTP/2
HTTP/2는 SPDY 프로토콜에서 파생된 HTTP/1.x 보다 지연 시간을 줄이고 응답 시간을 더 빠르게 함
멀티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위 처리 지원
멀티 플렉싱
하나의 TCP 연결을 여러 스트림으로 나누고, 동시에 요청과 응답을 주고받을 수 있게 하는 기능
- 여러 개의 스트림을 사용하여 송수신하는 것
- 특정 스트림의 패킷이 손실되더라도 해당 스트림에만 영향을 미치고 나머지 스트림에는 영향X
❓ 스트림
데이터를 한꺼번에 모두 다 받는 것이 아니라, 조금씩 순차적으로 받으며 처리할 수 있게 되는 방식
하나의 연결 내의 여러 스트림이 담겨 있는 모습
병렬적인 스트림들을 통해 데이터를 서빙하고, 스트림 내의 데이터도 쪼개져 있음.
애플리케이션에서 받아온 메시지를 독립된 프레임으로 조각내어 서로 송수신한 이후 다시 조립하며 데이터를 주고 받음
👉 HTTP 레벨에서의 HOL Blocking 해결
❓ 스트림 데이터, 스트림 헤더
스트림 데이터: 실제 콘텐츠나 정보가 담긴 부분 (전송되는 데이터의 본문)
스트림 헤더: 데이터가 무엇인지, 어떻게 처리해야 하는지 설명해 주는 메타 정보
TCP 레벨의 HOL Blocking은 여전히 존재
TCP의 전송 방식은 순서 보장 & 신뢰성 보장, 다음 두 가지는 엄격히 지킴
- 데이터는 순서대로 도착해야 한다.
- 데이터가 손실되면 재전송한다.
HTTP/2에서 A, B, C, D 총 4개의 프레임을 보냈다고 가정,
프레임 B가 네트워크 문제로 손실되고 나머지가 정상 도착한 경우?
- TCP는 C, D를 받았다고 하더라도 HTTP/2 (애플리케이션)에 넘기지 않음
- B가 재전송되어 도착할 때까지 C, D는 기다림 = HOL Blocking
| 계층 | HOL Blocking 해소 여부 | 설명 |
| HTTP/2 (애플리케이션) | ✅ 해소됨 | 멀티플렉싱으로 여러 요청 동시 처리 |
| TCP (전송 계층) | ❌ 여전히 존재 | 하나의 패킷 손실로 전체 지연 발생 가능 |
HTTP 레벨의 HOL Blocking은 해결됐지만, TCP 레벨의 HOL Blocking은 여전히 존재
→ HTTP/2의 구조적 한계
헤더 압축
HTTP/1.x에는 헤더의 크기가 큰 문제가 있었음
HTTP/2는 허프만 코딩 압축 알고리즘을 사용하는 `HAPCK` 압축 형식을 가짐
허프만 코딩 (Huffman Coding)
문자열을 문자 단위로 쪼개 빈도수를 셈
빈도가 높은 정보는 적은 비트수를 사용하여 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용하여 표현
= 전체 데이터 표현에 필요한 비트양을 줄이는 원리
서버 푸시
HTTP/1.1 에선 클라이언트가 서버에 요청을 해야 파일을 다운로드 받을 수 있었음
HTTP/2에선 클라이언트 요청 없이 서버가 바로 리소스 푸시 가능
html에는 css나 js 파일이 포함되기 마련
html을 읽으면서 그 안에 들어 있던 css 파일을 서버에 푸시하여 클라이언트에 먼저 줄 수 있음
4. HTTP/3
- HTTP/3은 HTTP/1.1 & HTTP/2와 함께 World Wide Web에서 정보를 교환하는 데 사용되는 세 번째 버전
- TCP 위에서 돌아가는 HTTP/2와 달리, `QUICK`이라는 계층에서 돌아가며 이는 UDP 기반임
- 멀티플렉싱을 가지고 있으며, 초기 연결 설정 시 지연 시간이 감소되는 장점
초기 연결 시 지연 시간 감소
QUICK은 UDP를 사용하므로 통신 시작시 TCP의 3-Way Handshake 과정을 거치지 않아도 됨
QUICK은 첫 연결 설정에 `1-RTT`만 소요됨.
👉 클라이언트가 서버에 어떤 신호를 한 번 주고 서버도 응답하기만 하면 바로 본 통신을 시작할 수 있음
📌 참고
QUICK은 순방향 오류 수정 메커니즘 (FEC, Foward Error Correction)이 적용됨
전송한 패킷이 손실된 경우, 수신 측에서 에러를 검출하고 수정
= 열악한 네트워크 환경에서도 낮은 패킷 손실률을 보임
5. HTTPS
HTTP/2,3은 HTTPS 위에서 동작
HTTPS는 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 `SSL/TLS` 계층을 넣은 신뢰할 수 있는 HTTPS 요청을 말함
👉 이를 통해 통신을 암호화 함
HTTPS를 구축하는 방법은 아래와 같이 크게 세 가지로 나뉨
- 직접 CA에서 구매한 인증키를 기반으로 HTTPS 서비스 구축
- 서버 앞단에 HTTPS를 제공하는 로드밸런서 사용
- 서버 앞단에 HTTPS를 제공하는 CDN 사용
SSL/TLS
SSL (Secure Soket Layer)은 SSL 1.0 부터 시작하여 SSL 2.0, SSL3.0, TLS 1.0, TLS 1.3까지 버전이 올라감
TLS(Transport Layer Security Protocol)로 명칭이 변경되었으나, 통칭하여 SSL/TLS로 부름
- SSL/TLS는 전송 계층에서 보안을 제공하는 프로토콜
- 제 3자가 메시지를 도청하거나 변조하지 못하도록 함
| 항목 | SSL | TLS |
| 정식 명칭 | Secure Sockets Layer | Transport Layer Security |
| 개발 주체 | Netscape | IETF(인터넷 표준화 기구) |
| 버전 | SSL 2.0, 3.0 (현재 모두 폐기됨) | TLS 1.0, 1.1, 1.2, 1.3 |
| 보안성 | 취약점 존재, 더 이상 사용되지 않음 | 최신 버전은 보안이 강화됨 |
| 호환성 | 과거 시스템과 호환 | SSL과의 하위 호환 제공 (초기 TLS) |
| 사용 여부 | 더 이상 사용하지 않음 | 현재 대부분의 웹에서 사용 중 |
SSL/TLS를 통해 공격자가 서버인 척하면서 사용자 정보를 가로채는 네트워크상의 `인터셉터` 방지 가능
- SSL/TLS는 보안 세션을 기반으로 데이터를 암호화
- 보안 세션 만들기 👉 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘 사용됨
보안 세션
보안이 시작되고 끝나는 동안 유지되는 세션
SSL/TLS는 핸드셰이크를 통해 보안 세션을 생성, 이를 기반으로 상태 정보 등을 공유
📌 세션
운영체제가 어떠한 사용자로부터 자신의 자산 사용을 허락하는 일정 기간
사용자는 일정 시간 동안 응용 프로그램 & 자원 사용 가능
클라이언트와 서버가 키를 공유하고, 이를 기반으로 인증, 인증 확인 등의 작업이 발생
= 단 한 번의 1-RTT가 생긴 후 데이터를 송수신
- 클라이언트에서 `사이퍼 슈트(cypher shites)`를 서버에 전달
- 서버는 사이퍼 슈트의 암호화 알고리즘 리스트를 제공할 수 있는지 확인
- 제공할 수 있다면 클라이언트로 인증서를 보내는 인증 메커니즘 시작
- 이후 해싱 알고리즘 등으로 암호화된 데이터 송수신 시작
📌 TLS 1.3은 사용자가 이전에 방문한 사이트를 재방문하는 경우, 위 통신을 하지 않아도 됨 (= 0-RTT)
사이퍼 슈트
프로토콜, AEAD 사이퍼 모드, 해싱 알고리즘이 나열된 규약으로 다섯 개가 있음
- TLS_AES_128_GCM_SHA256
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_CCM_SHA256
- TLS_AES_128_CCM_8_SHA256
EX) TLS_AES_128_GCM_SHA256
- TLS = 프로토콜
- AES_128_GCM: AEAD 사이퍼 모드
- SHA256: 해싱 알고리즘
❓ AEAD 사이퍼 모드
AEAD(Authenticated Encryption with Associated Data)는 데이터 암호화 알고리즘을 의미
EX) AES_128_GCM
128비트의 키를 사용하는 표준 블록 암호화 기술 + 병렬 계산에 용이한 알고리즘 GCM이 결합된 알고리즘
1) 인증 메커니즘
인증 메커니즘은 `CA` (Certificate Authorities)에서 발급한 인증서를 기반으로 이루어짐
CA에서 발급한 인증서는 안전한 연결을 시작하는 데 있어 필요한 `공개키`를 클라이언트에 제공하고,
사용자가 접속한 서버가 신뢰할 수 있는 서버임을 보장
CA는 아무 기업이나 할 수 있는 것이 아니며, 신뢰성이 엄격히 공인된 기업들만 참여 가능
Ex) Comodo, GoDaddy, GlobalSign, 아마존 등
CA 발급 과정
서비스가 CA 인증서를 발급받으려면 `사이트 정보`와 `공개키`를 CA에 제출해야 함
이후 CA는 공개키를 해시한 값인 지문(finger print)을 사용하는 CA의 비밀키 등을 기반으로 CA 인증서 발급
❓ 개인키, 공개키
개인키 (비밀키): 개인이 소유하고 있는 키, 반드시 자신만이 소유해야 하는 키
공개키: 공개된 키
인증서를 사용하는 이유
인증서는 서버가 진짜 신뢰할 수 있는 주체인지 클라이언트에게 증명하기 위한 수단임
인증서의 역할
- 서버의 공개키와 도메인이 진짜인지 검증
- 공개키가 제 3자 (인증기관, CA)에 의해 발급되었는지 확인
- 중간자 공격 방지
인증서에 들어있는 것
- 서버의 도메인 정보
- 서버의 공개키
- 인증기관의 전자 서명
- 유효기간 등 메타 정보
브라우저는 내장된 신뢰된 루트 CA 목록을 가지고, 서버 인증서의 서명 검증
📌 정리
인증서 없이는 누가 공개키를 보냈는지 알 수 없어서, 신뢰할 수 없는 암호화가 됨
∴ SSL/TLS 핸드셰이크 (= HTTPS 핸드셰이크)에서 인증서를 먼저 보내는 것
2) 암호화 알고리즘
공개키는 보안을 위해, 대칭키는 속도를 위해 사용됩니다.
HTTPS에서는 처음에 공개키로 대칭키를 안전하게 주고받고, 이후는 대칭키로 빠르게 암호화합니다.
| 항목 | 공개키 암호화 | 대칭키 암호화 |
| 키 사용 방식 | 공개키로 암호화, 개인키로 복호화 | 같은 키로 암호화와 복호화 |
| 속도 | 느림 | 빠름 |
| 사용 시점 | 초기 핸드셰이크에서만 사용 (대칭키 전달용) | 이후 실제 데이터 전송에 사용 |
| 예시 알고리즘 | RSA, ECDHE | AES, ChaCha20 |
- 공개키 암호화: 디피-헬만키 교환 암호화 알고리즘 (Diffie-Hellman key exchange)
g, x, p를 안다면 y를 구하기 쉽다. 하지만, g, y, p만 아는 경우 x는 구하기 어렵다는 원리에 기반한 알고리즘
- 처음 공개 값 공유
- 각자 비밀 값과 혼합 후 공유
- 각자의 비밀 값과 혼합
- 공통 암호키 생성 (= PSK (Pre-Shared Key))
PSK가 생성된다면, 악의적인 공격자가 개인키 또는 공개키를 가지고도 PSK가 없기 때문에 아무것도 못 함
- 대칭키 암호화: AES (Advanced Encryption Standard)
가장 널리 사용되는 대칭키 블록 암호화 알고리즘
| 항목 | 내용 |
| 이름 | Advanced Encryption Standard (고급 암호화 표준) |
| 대체한 것 | 과거 DES(Data Encryption Standard)를 대체 |
| 암호 방식 | 대칭키 암호화 – 암호화와 복호화에 같은 키 사용 |
| 블록 크기 | 128비트 고정 |
| 키 길이 | 128, 192, 256비트 중 하나 선택 |
| 라운드 수 | 키 길이에 따라 10, 12, 14 라운드 |
| 사용처 | HTTPS, VPN, 파일 암호화, 하드디스크 암호화 등 |
3) 해싱 알고리즘
해싱 알고리즘은 데이터를 추정하기 힘들도록 더 작고, 섞여 있는 조각으로 만드는 알고리즘
SSL/TLS는 SHA-256, SHA-384알고리즘을 사용함.
SHA-256 알고리즘
해시 함수의 결괏값이 256비트인 알고리즘
해싱을 해야 할 메시지에 1을 추가하는 등의 전처리를 하고, 전처리된 메시지를 기반으로 해시 반환
비트 코인을 비롯한 많은 블록체인 시스템에서도 사용됨
| 원문 | SHA -256 알고리즘 사용 |
| Hello World! | 7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069 |
❓ 해시, 해싱, 해시 함수
- 해시: 다양한 길이를 가진 데이터를 고정된 길이를 가진 데이터로 매핑한 값
- 해싱: 임의의 데이터를 해시로 바꿔주는 일, 해시 함수가 담당
- 해시 함수: 임의의 데이터를 해시로 바꿔주는 함수
HTTP의 무상태 (Stateless) 특성
HTTP는 무상태(stateless) 프로토콜
서버는 클라이언트의 이전 요청이나 상태를 "기억하지 않는다" 는 의미
왜 Stateless인가?
HTTP는 원래 간단한 요청-응답 구조를 위해 설계된 프로토콜임
클라이언트가 요청을 보내면 서버는 응답하고, 그걸로 끝.
- 서버는 "누가", "무엇을 요청했는지" 상태 정보를 유지하지 않는다.
- 매 요청은 독립적이며, 이전 요청과 관계X
EX) 사용자가 로그인 후 상품 페이지를 열람해도, HTTP 자체만으로는 로그인 상태인지 알 수 없음
| 장점 | 단점 |
| 서버 확장성: 상태를 기억하지 않기 때문에 서버 부담이 줄어듦 | 클라이언트 상태(예: 로그인, 장바구니 등)를 따로 관리해야 함 |
| 구현 단순함: 각 요청은 독립적으로 처리됨 | 쿠키, 세션, 토큰 등의 기술이 함께 사용됨 |
즉, HTTP는 Stateless하므로, 사용자의 상태는 기본적으로 서버가 기억하지 않음
따라서 실무에서는 상태를 유지하기 위한 보완 기법(쿠키, 세션, 토큰 등)이 필수