HTTP 헤더

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가지를 수행하게 된다.

1. Client와 Server가 서로 사용할 TLS 버전을 지정한다.
2. Client와 Server가 서로 사용할 암호화 방식을 결정한다.
3. Client와 Server는 서로를 검증한다.
4. TLS Handshake가 완료된 이후에 Session Key를 생성한다(=Session ID).

 

https://velog.io/@uoayop/HTTP

HTTP : HTTP 1.0과 1.1 / 헤더 / keep-alive

https://velog.io/@cjllee/HTTP1.0%EA%B3%BC-HTTP1.1%EC%9D%98-%EC%B0%A8%EC%9D%B4-keep-alive-HOL

HTTP/1.0과 HTTP/1.1의 차이, 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

HTTPS와 TLS 핸드셰이크

https://velog.io/@seyoung755/TLS-handshake%EA%B0%80-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EA%B3%BC%EC%A0%95

TLS handshake가 일어나는 과정