- HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X
- HTTP/1.0 1996년: 메서드, 헤더 추가
- HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
- RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)
- HTTP/2 2015년: 성능 개선
- HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선
- Persisted connection 연결 상태 유지
- 커넥션 재사용 가능 → 시간 절약
- Keep-Alive : 연결 유지 시간 제한
- Pipelining → 여러 요청 동시에 가능
- 클라이언트 측에서 여러 요청을 순차적으로 보내면 서버는 받은 순서에 따라 응답 제공
- Chunked Transfer encoding 청크 전송 인코딩
- 스트리밍 데이터 전송 방식
- 본문: chunk size+내용+chunk size+내용 형식
- Transfer-Encoding: chunked
- Cache-Control 캐시 제어
- Content negotiation 도입
- Host Header
- 동일 IP에 여러 도메인 호스트 가능
- Host: 요청한 호스트 정보(도메인)
- 요청에서 사용
- 필수
- 하나의 서버가 여러 도메인을 처리해야 할 때
- 하나의 IP 주소에 여러 도메인이 적용되어 있을 때
```http
GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com
```
HTTP, 암호화되지 않은 텍스트 통신 -> 내용 가로채거나 사용자 정보 탈취 가능 - HTTP + 신뢰성/무결성 = HTTPS
- 인증서를 이용한 비대칭 키 암호화 방식
- SSL(Secure Socket Layer)/TLS(Transport Layer Security)프로토콜로 통신 내용 암호화
대칭키 : 빠른 대신 서로간의 공통적으로 알고 있는 키 공유 -> 외부로의 노출 발생 비대칭키 : 서로 다른 키를 갖고 있어 암복호화 진행 => 처음 대칭키를 교환할때만 비대칭 암호키를 사용하자(TLS)
- 보안 목표
- Confidentiality 기밀성
- 우리만 읽을 수 있다 -> 대칭키 암호화 알고리즘(DES, 3DES, RC4 등)
- Integrity 무결성
- 변경되지 않았다 -> MAC(Message Authentication Code, 메시지 인증 코드)기법으로 위, 변조 여부 확인(HMAC-md5, HMAC-SHA-1)
- Authenticity 인증
- 받은게 목적한 상대방이 맞다(상호 인증) -> 연결 초기 설정에서 인증서 주고 받아 신뢰성 확인(RSA, DSS, X.509), 공개 키
- Confidentiality 기밀성
- TLS Handshake(TCP Handshake 후 연결)
- Client Hello: 클라이언트가 서버로 Hello 메시지를 전송하면서 핸드셰이크를 개시. 이 메시지에는 클라이언트가 지원하는 TLS 버전, 지원되는 암호 제품군, 그리고 클라이언트 무작위라고 하는 무작위 바이트 문자열이 포함됨
- Server Hello: Client Hello 메시지에 대한 응답으로 서버가 서버의 TLS(SSL) 인증서, 서버에서 선택한 암호 제품군, 그리고 서버에서 생성한 또 다른 무작위 바이트 문자열인 서버 무작위를 포함하는 메시지를 전송
- 인증: 클라이언트가 서버의 SSL 인증서를 인증서 발행 기관을 통해 검증 -> 서버가 인증서에 명시된 서버가 맞는지 확인
- 예비 마스터 암호: 클라이언트가 예비 마스터 암호라고 하는 무작위 바이트 문자열을 하나 더 전송, 예비 마스터 암호는 공개 키로 암호화, 서버가 개인 키로만 해독가능
- 개인 키 사용: 서버가 예비 마스터 암호를 해독
- 세션 키 생성: 클라이언트과 서버 모두 클라이언트 무작위, 서버 무작위, 예비 마스터 암호를 이용해 세션 키를 생성 -> 모두 같은 결과
- 클라이언트 준비 완료: 클라이언트가 세션 키로 암호화된 완료메시지를 전송
- 서버 준비 완료: 서버가 세션 키로 암호화된 완료메시지를 전송
- 안전한 대칭 암호화 성공: 핸드셰이크가 완료, 세션 키를 이용해 통신이 계속 진행
- Header 중복 전송
- HOLB(Head-of-Line Blocking) : 서버가 항상 요청받은 순서대로 응답으로 지연 -> 기존 HTTP/1.1에서는 TCP 병렬연결(max 6)으로 처리
- 요청 별 우선순위 지정 불가
- 클라이언트 기반 통신, 서버-> 클라이언트 전송 불가
- SPDY Protocol - 웹 페이지 로드 대기 시간 감소
- Binary Protocol 이진 프로토콜 <-> HTTP/1.1 텍스트 기반 프로토콜(읽기는 편한데 데이터 커짐)
- multiplexing 응답 다중화 : 하나의 TCP연결에 여러 요청 동시 처리 가능
- stream : 요청과 응답이 양방향으로 오가는 논리적 연결 단위, TCP연결에서 여러 개의 스트림 동시 존재 가능
- message : 하나의 요청과 응답 구성 단위
- frame : 메시지 구성 최소 단위, 잘게 쪼개어 전송되어 수신측에서 다시 조립(작은 사각형)
- HPACK 헤더 필드 압축
- Huffman Coding 허프만 코딩 기법 : 달라진 부분만 다시 전송
- 서버 푸시 기능 : 서버가 클라인언트가 요청하지 않은 리소스 미리 클라이언트에게 보냄
- 스트림별 우선순위 지정 기능 : 정수와 트리 구조로 구현
- 프로토콜 자체의 흐름 제어 기능
- TCP에서는 근본적으로 HOLB해결 불가
- TCP 신뢰성 지향 -> 데이터 손실 발생시 재전송 수행 -> 패킷 정확한 순서로 처리위해 재전송 대기 발생
- TCP 혼잡 제어 수행 -> 전송 속도를 낮은 상태에서 천천히 높이는 방식으로 속도 제어 : 네트워크 상황 좋을 땐 불필요한 지연 발생
- 프로토콜 자체의 불필요한 헤더 고칠 수 없음
- QUIC Protocol : TCP 신뢰성 보장 기능 UDP 기반 구현 => UDP 기반 프로토콜
- TLS 포함 -> HTTPS 강제 사용
- 0-RTT : 연결 정보 캐싱하여 재사용
- 최초 연결 1-RTT -> 시간 절약, 이후 캐싱정보로 0-RTT
- 최초 연결 1-RTT -> 시간 절약, 이후 캐싱정보로 0-RTT
- 연결 다중화 지원
- 각 스트림 독립적으로 동작
- 각 스트림 독립적으로 동작
- 연결 별 고유 UUID(Connection ID)로 각 연결 식별
- IP로 연결할 땐 환경 변하면 주소 변경 되어 연결 재수립 필요했음
- TCP: HTTP/1.1, HTTP/2
- UDP: HTTP/3
- Client-Server 구조
- Reqest-Response 구조
- Stateless Protocol:무상태 프로토콜 지향
- 서버가 클라이언트의 상태 보존X
- 장점 : 서버 확장성이 높음(스케일 아웃)
- 단점 : 클라이언트가 추가로 데이터를 전송
Stateful vs Stateless
- Stateful : 중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 함 => 항상 같은 서버 유지(최소한만 사용하여 개발하기)
- Stateless : 서버에 상태를 중복으로 계속 알려줌 => 아무 서버나 호출해도 됨
- Connectionless : 비연결성
- TCP/IP 연결 유지 -> 서버 자원 소모
- Connectionless 응답 후 TCP/IP 연결 종료 => 최소한의 자원 소모
- TCP/IP 연결 반복 -> 3way handshake 시간 추가
- HTTP Persistent Connections(지속 연결)지원, ver2-3에서 최적화
- HTTP 메시지
- HTTP 메시지에 거의 모든 것 전송
start-line - request-line/status-line
- HTTP 메시지에 거의 모든 것 전송
- 단순함, 확장가능