HTTP

1.0과 1.1 차이

HTTP/1.0

• 수명이 짧은 연결이라고 함
• HTTP 요청은 자체 요청에서 완료 됨
• 각 HTTP 요청당 TCP 핸드셰이크 발생
  • 기본적으로 한 연결당 하나의 요청 처리하도록 설계
• 한번 연결 때마다 TCP연결 계속해야되니 RTT 가 늘어나는 문제점 존재
• 파일 하나 하나마다 연결시킴

RTT(round trip time:왕복 지연 시간)는 신호를 전송하고 해당 신호의 수신학인에 걸린 시간을 더한 값이자 어떤 메시지가 두 장치 사이를 왕복하는데 걸린 시간

HTTP/1.1

• 1.0 단점 보완한 프로토콜. 크게 3가지 차이

1. keep-alive default

• 매번 요청마다 TCP 연결하는게 아닌 한번 해놓고 계속해서 데이터를 받을 수 있게 만듬. 이는 keep alive 옵션을 기본옵션으로 하면서 가능해짐
  • 1.0 에서는 실험적 기능이었음

2. 호스트 헤더(?)

• 1.0은 서버가 하나의 호스트만 가진다고 가정하기에 헤더에 호스트를 포함 안했음
  • 그래서 1.0은 하나의 IP에 하나의 호스트만 가질 수 있음
• 그러나 사실 서버는 여러개의 호스트 가질 수 있으며 이런 유연성 위해 1.1은 헤더에 특정 호스트를 포함할 수 있게 변경
• 항상 호스트를 포함해서 요청하도록 바뀜
• 203.123.45.67 주소에 www.apple.com, www.google.com, blog.naver.com 모두 함께 사용가능하게 된 것임. HTTP 1.1 이후 부터.

3. 대역폭 최적화

• 1.0 경우 어떤 파일 다운받다가 끊기면 다시 다운받는게 불가
  • 예를 들어 10KB 파일 다운로드 받을 때 절반만 받고 다시 이어서 다운 불가
• 1.1 에서는 Range:bytes=5000- 라는 헤더 추가해서 다운로드 재개 요청 가능

1.1의 고질적 문제 HOL

• 무거운 헤더를 가지는 문제점 존재
• HOL(Head Of Line Blocking)
• 네트워크에서 같은 큐에 있는 패킷이 그 첫 피캣에 의해 지연될 때 발생하는 성능 저하 현상

2.0과 3.0의 차이

2.0

• 구글은 1.1 한계극복위해 SPDY 프로토콜 개발
• 이후, 15년 SPDY 기반으로 하는 HTTP/2 개발

바이너리 포맷 계층

• 애플리케이션 계층과 전송계층 사이에 바이너리 포맷 계층 추가
• 1.0 은 일반 텍스트 메시지를 전송하고 이를 줄바꿈으로 데이터를 나눔
• 2.0 은 0과 1로 이루어진 바이너리 데이터로 변경. 더 작은 메시지가 프레임으로 캡슐화되어 전송됨

[참고] h2와 h2c HTTP/2는 TLS를 선택적으로 쓸 수 있습니다. 즉, TLS가 없는 HTTP/2도 있습니다.

h2c는 TLS를 사용하지 않고 TCP 연결 위에서 직접 HTTP/2를 사용하는 것을 의미합니다.개발 환경에서의 디버깅이나 로컬 테스트를 위해 암호화된 연결을 설정할 필요가 없으므로 개발자들이 편리하게 테스트를 할 수 있다는 장점, 암호화와 관련된 오버헤드가 없다는 장점이 있습니다.

h2는 tls가 장착된 http2를 부르며 브라우저에서는 HTTPS가 없는 HTTP2는 지원하지 않기 때문에 브라우저에서는 h2c가 아니라 h2만 허용됩니다.

멀티플렉싱

• 단일 TCP 연결의 여러 스트림에서 여러 HTTP 요청과 응답을 비동기적으로 보낼 수 있음
  • 이를 통해 HOL 해결
• 1.1 에서는 병렬요청을 하려면 다중 TCP 연결 통해서 하고 일반적으로는 TCP 연결하나당 병렬요청은 불가했음
• 이를 2.0에서는 리소스를 작은 프레임으로 나누고 이를 스트림으로 프레임을 전달
  • 각각 프레임은 스트림ID, 해당 청크 크기나타내는 프레임이 추가되었때문에 작게 나누어 다운로드 되더라도 결과적으로 응답데이터에서는 올바른 순서로 재조립 할 수 있음

서버푸시

• 서버가 리소스를 클라에 푸시 가능
• 요청된 HTML 파일과 함께 다른 개체를 별도로 보낼 수 있음
  • 만약, 요청한 html에 css가 포함되어 있다면 별도 요청 없이 css같이 보낼 수 있음

헤더압축

• 1.1 에서는 무거운 헤더 있었지만 이를 허프만 인코딩 압축 방법 등으로 압축 시킴
  • 똑같은 서버에서 2개의 이미지 준다고 했을 때, 중복되는 헤더는 제외한체 보내고 해당 공통 필드로 헤더를 재구성하며 중복되지 않은 헤더값은 허프만 인코딩 압축 방법으로 압축해 전송함

우선순위

• 서버에서 원하는 순서대로 우선순위 정해 리소스 전달 가능

3.0

• 2는 여전히 TCP 쓰기에 초기 연결에 대한 RTT로 인한 지연시간이라는 문제점 존재했고 3.0은 이를 해결한 버전
• QUIC(Quick UDP Internet Connections)라는 계층 위에서 돌아가며, TCP 기반아닌 UDP 기반임
• 2.0에서 장점이었던 멀티플렉싱 등 가지고 있으며 초기 연결 설정시 지연시간 감소라는 대표적 특성 가지고 있음
• TCP 경우 3 - RTT 필요했다면, QUIC는 1 - RTT 만 필요하다는 장점있음
• 2, 3은 HTTPS 위에서 돌아가는데 TLS로 암호화 통신 구축할 때의 핸드셰이크를 활용
  • 이를 기반으로 1 - RTT 만에 연결 성립을 할 수 있는것
• 전송된 패킷이 손실되었다면 수신측에서 에러르 검출하고 수정하는 방식
• 열악한 네트워크 환경에서도 낮은 패킷손실률 자랑하는 순방향 오류 수정 메커니즘(FEC, Forward Error Correction)이란 특징 가짐