////
Search

HTTP

HTTP/1.0 HTTP/1.1

HTTP/1.0
•
한 요청 당 하나의 TCP 핸드세이크 발생
•
한 연결 당 하나의 요청 처리하도록
•
RTT가 늘어남
HTTP/1.1
•
keep-alive default
◦
HTTP/1.0에서는 keep-alive가 기본 옵션이 아니었음. 이걸 사용하면 handshake를 반복적으로 하지 않는다.
◦
특정 요청 동안 연결을 유지한다.
◦
time-out / max-request
▪
얼마만큼 유지시킬거냐/몇 개의 리퀘스트
•
서버가 하나의 호스트만 가질 수 있었으나, 여러 개 호스트를 포함하도록 바뀜
•
대역폭 최적화
◦
HTTP/1.0은 안 됬는데 HTTP/1.1은 가능
◦
Range:bytes=500- 라는 헤더를 추가해서 한다.
•
요청 줄이기 위한 기술
◦
이미지 스프라이트 → 여러 개 이미지 묶어서 전송
◦
코드 압축
•
HOL
◦
head of line: 무거운게 앞에 있으면 response time이 느려진다.
◦
HTTP/2에서 해결
HTTP/2.0
•
멀티플렉싱
◦
병렬 요청을 하려면 TCP 요청을 여러 개 해야하는데 멀티플렉싱으로 가능하다.
◦
데이터를 binary frame으로 쪼갠다. 각 frame 별로 streamID, 크기 를 할당
◦
다운로드 받을 때, 병렬적으로 받음.
•
서버 푸시
◦
요청된 html 파일과 함께 다른 객체를 별도로 보낼 수 있음
•
헤더 압축
◦
전달하는건 허프만 알고리즘으로 압축함
◦
중복되는건 안 보냄
HTTP/3
•
UDP 기반으로 돌아감. QUIC이 돌아감
•
1-RTT 만 필요함
HTTPS/TLS
•
대칭
◦
AES
▪
10라운드에 걸쳐 각 라운드마다 스크램블 등의 연산으로 데이터를 암호화한다.
▪
스크램블
•
데이터를 섞고 키를 넣어서 암호문을 만듦. 이 과정을 10번 함
•
비대칭
◦
서로 다른 두 개의 키(공개키, 개인키)
▪
RSA
◦
공개키로 암호화하면 개인키로만 복호화 가능하다.
◦
공개키는 누구나 가질 수 있지만, 개인키는 반드시 비밀로 유지해야함.
•
SSL
•
TLS
◦
Diffie-Hellman 키 교환
▪
서로의 비밀값은 숨긴 채, 공개된 값을 주고 받아 같은 비밀 키를 만들어내는 암호 프로토콜
▪
modular 연산으로 특정 값을 알려면 brute-force를 구하도록 함
•
RSA 약점
1.
서버는 공개키를 클라이언트에게 줍니다.
2.
클라이언트는 세션키(잠시 사용할 대칭키)를 만들어 서버의 공개키로 암호화해서 보냅니다
3.
서버는 자신의 개인키로 이를 풀어 세션키를 알아냅니다.
4.
이제부터 둘은 그 세션키를 이용해 암호화된 통신을 합니다
•
인증서
◦
Domain
◦
서버 공개키
◦
CA
◦
CA의 전자서명
•
서명
◦
인증서를 기반으로 A를 만들고 CA의 전자서명을 기반으로 B를 생성해서 같은지 확인
클라이언트가 ClientHello를 전송하며 지원하는 사이퍼슈트, 랜덤값, ECDHE(Diffie–Hellman 기반) 공개키 등을 보냅니다. 서버는 ServerHello로 응답하며 선택된 사이퍼슈트, 랜덤값, 서버의 ECDHE 공개키를 전송하고, 이어서 Certificate 등의 과정을 통해 서버 인증서와 해당 인증서의 전자서명도 함께 보냄.
클라이언트는 이때 인증서의 서명을 CA의 공개키로 복호화하고, 해시값과 비교하여 인증서의 위조 여부를 확인합니다.
클라이언트와 서버는 ECDHE로 공통의 암호키를 계산하고 이 공통의 암호키를 바탕으로 세션키를 만들고 해당 세션키로 암호화된 Finished 메시지를 교환함. 이후 모든 통신은 이 세션키를 기반으로 한 대칭 암호화 방식으로 보호됩니다