HTTP/1.0과 HTTP/1.1의 차이 keep-alive, HOL
HTTP/1.0
HTTP/1.0은 수명이 짧은 연결
HTTP요청은 자체 요청에서 완료되며, 각 HTTP 요청당 TCP 핸드셰이크가 발생되며 기본적으로 한 연결당 하나의 요청을 처리하도록 설계됨.
문제점: 한번 연결할 때마다 TCP연결-> RTT가 증가
HTTP/1.1
HTTP/1.1은 HTTP/1.0의 단점을 보완한 프로토콜.
1.keep-alive default
매번 데이터를 요청할 때마다 TCP 연결을 하는게 아닌 한번 해놓고 계속해서 데이터를 받을 수 있게 됨
- 기본옵션으로 keep-alive 옵션을 하며 가능해짐
2. 호스트 헤더
서버는 여러개의 호스트를 가질 수 있으며, 이런 유연성을 위해 HTTP/1.1은 헤더에 특정 호스트를 포함할 수 있게 변경되다.
항상 호스트를 포함해서 요청하도록 바뀜
3. 대역폭 최적
HTTP/1.0의 경우 어떠한 파일을 다운로드 받다가 연결이 끊기면 재다운로드는 불가능했는데. /1.1의 경우 다시 다운로드 받을 수 있게 됨
ex. HTTP/1.0에서는 10KB 파일 다운로드 시 5KB까지만 받고 다시 다운로드를 받는게 불가.
HTTP/1.1에서는 Range:bytes=5000- 라는 헤더를 추가 -> 다운로드 재개 요청 가능
요청을 줄이기 위한 기술
HTTP/1.1로 발전했음에도, 서버요청할 때마다 RTT는 계속해서 증가.
요청을 줄이기 위한 여러가지 기술: 이미지스프라이트(image sprite), 코드압축, Base64 인코딩 기술
HTTP 버전이 올라간 뒤에도 이 기술들 같이 씀
- 이미지 스프라이트
- 수많은 이미지를 하나의 이미지로 만들어 하나의 이미지만 다운
- 이를 통해 수많은 이미지를 다운받는 듯한 효과를 냄
- 코드압축
- 코드를 압축해서 서빙
- 이미지 Base64 인코딩
- 이미지 파일을 64진법으로 이루어진 문자열로 인코딩 -> 이미지 서버에 대한 HTTP 요청을 할 필요가 없이 만드는 것
- 단점: 파일크기 37% 증가
HTTP/1.1의 고질적인 문제 : HOL
HOL(Head Of Line Blocking)
네트워크에서 같은 큐에 있는 패킷이 그 첫번째 패킷에 의해 지연될 때 발생하는 성능저하현상
HTTP/2와 HTTP/3의 차이
HTTP/2
바이너리 포맷 계층
애플리케이션 계층과 전송 계층 사이에 바이너리 포맷 계층을 추가.
HTTP 1.0: 일반 텍스트 메시지를 전송하고 줄바꿈으로 데이터 분할
HTTP 2.0: 0과 1로 이루어진 바이너리 데이터로 변경, 더 작은 메시지가 캡슐화 되어서 프레임으로 전송됨
멀티플렉싱
단일 TCP연결의 여러 스트림에서 여러 HTTP 요청과 응답을 비동기적으로 보낼 수 있음. (HOL 해결)
HTTP1.1에서 병렬요청: 다중TCP연결을 통해서 요청. 일반적으로 TCP 연결 하나 당 병렬요청 불가
HTTP/2.0: 리소스를 작은 프레임으로 나누고, 이를 프레임을 스트림으로 전달
- 각각의 프레임은 스트림ID, 해당 청크의 크기를 나타내는 프레임이 추가됨
-> 때문에 작게 나눠서 다운로드 되어도 응답데이터에서 올바른 순서로 재조립할 수 있게 됨
서버푸시
서버가 클라이언트에 리소스를 푸시할 수 있다.
요청된 html파일과 함께 다른 개체를 별도로 전송 가능!
헤더압축
HTTP/1.1: 무거운 헤더를 허프만 인코딩 압축 방법 등으로 압축
HTTP/2.0: 똑같은 서버에서 2개의 이미지를 준다고 했을 때, 중복되는 헤더는 제외하고 전송.
해당 공통 필드로 헤더를 재구성 -> 중복되지 않은 헤더값은 허프만 인코딩 압축 방법으로 압축해 전송
우선순위
서버에서 원하는 순서대로 우선순위를 정해 리소스를 전달할 수 있음.
HTTP/3
HTTP/2의 초기 연결에 대한 RTT로 인한 지연시간이라는 문제점을 해결한 버전
- QUIC(Quick UDP Internet Connections)이라는 계층 위에서 돌아감
- TCP 기반이 아닌 UDP 기반으로 돌아감
- HTTP/2에서 장점이었던 멀티플렉싱 등을 가지고 있으며 초기연결설정시 지연시간 감소
TCP의 경우 3 - RTT가 필요했다면 QUIC은 1 - RTT만 필요하다는 장점
- HTTP/2나 HTTP/3 은 HTTPS 위에서 돌아가는데, TLS로 암호화통신을 구축할 때의 핸드쉐이크를 사용.
- 1 - RTT만에 연결 성립
순방향 오류 수정 메커니즘(FEC, Forward Error Correction)
- 전송된 패킷이 손실되었을 때, 수신측에서 에러를 검출하고 수정하는 방식
- 열악한 네트워크 환경에서도 낮은 패킷손실률
HTTPS와 TLS 암호화
암호화는 승인된 당사자만 정보를 이해할 수 있도록 데이터를 “스크램블”한 방법
복호화 시 송신자와 수신자가 서로 동의한 “키”가 필요
스크램블
무작위로 개별 데이터 비트를 섞는 것.
비트가 높아질수록 스크램블을 많이 하고, 복잡해짐
대칭 암호화
키를 하나만 사용하는 암호화 방법
비대칭 암호화
공개키 암호화.
두 개의 다른 키(공개키, 개인키)로 데이터를 암호화/서명
키 중 공개키를 누구나 사용할 수 있도록 함
공개키로 암호화된 데이터는 개인키로만 복호화 가능
TLS는 부분적으로 비대칭 암호화를 사용한다.
비대칭암호화로 인증 -> 대칭 암호화로 보안적 통신 시작
TLS 핸드쉐이크 과정에서, 첫 인증 시 비대칭 암호화 -> 클라이언트/서버는 세션키를 기반으로, 대칭 암호화된 통신 진행
암호화의 필요성
통신을 하이제킹해 읽을 수 없음 (의도한 송수신자 제외)
민감한 데이터 유출 방지, 데이터 무결성 보장
HTTPS와 TLS 핸드쉐이크
Client와 Server가 주고 받을 데이터를 암호화 및 복호화를 할 수 있는 대칭키를 얻고자 함
서로 데이터를 암호화할 수 있는 대칭키를 얻기 위해서 TLS Handshake 과정을 필요함
이 과정 속에서는 총 4가지를 수행하게 된다.
- Client와 Server가 서로 사용할 TLS 버전을 지정한다.
- Client와 Server가 서로 사용할 암호화 방식을 결정한다.
- Client와 Server는 서로를 검증한다.
- TLS Handshake가 완료된 이후에 Session Key를 생성한다(=Session ID).
https://velog.io/@cjllee/HTTP1.0%EA%B3%BC-HTTP1.1%EC%9D%98-%EC%B0%A8%EC%9D%B4-keep-alive-HOL
https://velog.io/@cjllee/HTTPS%EC%99%80-TLS-%ED%95%B8%EB%93%9C%EC%85%B0%EC%9D%B4%ED%81%AC-c5e533bo