[Web/Network] HTTP 기본 개념 및 HTTP1.0, HTTP1.1, HTTP2.0 특징

HTTP(HyperText Transfer Protocol)이란?

- 웹상에서 클라이언트와 서버 간 통신을 위한 프로토콜

 

---

HTTP 클라이언트 서버 구조

• Request & Response 구조
• 클라이언트는 서버에 요청을 보내고, 응답을 대기
• 서버가 요청에 대한 결과를 만들어서 응답

HTTP 특징

• Stateless(무상태) - 서버가 클라이언트의 상태를 보존 X
  • 장점 : 서버 확장성이 높음 (응답 서버를 바꿀 수 있고 무한한 서버 증설 가능)
  • 단점: 클라이언트가 추가 데이터 전송
  • 상태 유지는 쿠키나 세션 사용
• connectionless(비연결성) - 응답 뒤 클라이언트 서버 간 연결 해제
  • 장점 : 서버 자원을 매우 효율적으로 사용할 수 있고 응답시간빠름
  • 단점 : 새로 연결해야하기 때문에 3way handshake 시간 추가
  • persistent connections로 문제 해결

 

HTTP 역사

• HTTP/0.9 → Get메서드만 지원, HTTP 헤더 X / 응답도 html 파일자체만 보내줌
• HTTP/1.0 → 메서드와 헤더 추가
  • 요청헤더 : 버전이 생김.
  • 응답헤더 : 상태코드와 content-type이 생겨 html 파일 외 다른 타입의 파일도 전송
  • 단기커넥션 : connection 하나당 1 Request & 1 response 처리 가능 → 매번 새로운 연결로 선능 저하 및 서버 부하 비용 증가
  • keep-alive connection 도입으로 지속 커넥션을 만들었지만 해당 기능을 지원안하는 서버가 존재
• HTTP/1.1 → 가장 많이 사용 
  • Persistent connection : 기능 내제, 지정한 timeout 동안 연속적인 요청 사이에 커넥션을 닫지 않음
  • pipelining 도입 : 하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방식
  • Head Of Line Blocking : 우선순위로 들어온 요청의 응답 시간이 길어지면 후 순위에 있는 요청의 응답 시간도 길어짐
  • head구조의 중복
• HTTP/2 → 성능 개선 및 확장
  • 메시지 전송 방식의 변화 : 바이너리 프레이밍 계층 사용
  • 파싱, 전송속도 증가 & 오류 발생 가능성 저하
  • 멀티플렉싱
  • HPACK 압축 : 헤더 중복값 개선
• HTTP/3 → TCP 대신에 UDP 사용(Quic을 바탕으로 만듦)

 

---

keep-alive 커넥션

• 지정한 timeout동안 연결을 끊지 않는 것.
• HTTP 1.0에서는 persistent connection을 원하고 지원하는 클라이언트는 서버에 connection : keep-alive를 요청헤더에 추가한다.
• 엔티티 헤더에 content-length 값을 정확히 명시해야 트랜잭션이 끝나는 시간에 기존 메시지의 끝과 새 메시지의 시작을 알 수 있다.
• 옵션 : keep-alive 헤더는 요청일 뿐이기 때문에 언제든지 서버나 클라이언트 측에서 끊을 수 있고 timeout(얼마나 유지할건지), max(몇개의 트랜잭션까지 유지할건지) 파라미터를 정할 수 있다.

 

---

 

persistent connection (지속적 커넥션)

• HTTP 1.1에서는 기본적으로 persistent connection을 지원하기 때문에 필요없을 경우 요청헤더에 connection: close를 추가한다.
• connection: close 포함 시 클라이언트는 해당 커넥션에 추가 요청을 보낼 수 없다.
• 커넥션에 있는 모든 메시지가 자신의 길이 정보를 정확히 알아야 한다. (content-length)
• HTTP/1.1 프락시는 클라이언트와 서버 각각에 대해 별도의 지속 커넥션을 맺고 관리한다.
• 장점 : 서버의 단일 시간 내의 TCP 연결 수를적게 해 서버의 CPU나 메모리 자원을 절약할 수 있고네트워크 혼잡이나 지연의 수를 줄일 수 있다. 또한, 여러 개의 HTTP 요청과 응답을 병렬적으로 동시에 처리하기 위한 pipeline을 위해서 꼭 필요하다.
• 단점 : 연결 된 클라이언트의 수가 계속 증가하게 되면 서버의 자원이 고갈되어 더 많은 클라이언트의 접속에 대처가 불가능 하다. 따라서 클라이언트의 접속이 가장 많은 메인 페이지 URL같은 경우 고려할 점이 많다.
• HTTP1.0에는 connection: keep-alive를 넣어야 가능하고 HTTP1.1부터는 기본으로 내장되어있음

 

 

---

pipelining

• HTTP1.1은 지속커넥션을 통해 파이프라이닝이 가능하다.
• 하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방법.
• 서버 간 요청의 응답속도를 개선시키기 위해 적용
• HTTP 클라이언트는 커넥션이 지속 커넥션인지 확인한 후 파이프라이닝을 이어서는 안된다.
• HTTP 응답은 요청 순서와 같에 와야한다.
• 하나의 사용자 클라이언트는 서버의 과부하 방지를 위해 넉넉잡아 두개의 커넥션을 연결한다.
• POST 요청같이 반복해서 보낼 경우 문제가 생기는 요청은 파이프라인을 통해 보내면 안된다. (에러 발생 시 파이프라인을 통한 요청 중 어떤 것들이 서버에서 처리됐는지 클라이언트가 알 방법X)
• 실제로 멀티플렉싱을 제공하는 것이 아닌 응답처리를 미루는 방식으로 각 응답의 처리는 순차적으로 처리되며, 앞에 있는 트랜잭션의 처리가 오래걸릴 경우 후순위에 있는 트랜잭션의 응답은 지연될 수 밖에 없다 이러한 문제를 Head OF Line Blocking이라 부른다. HTTP2에서는 멀티플렉싱 알고리즘으로 대체되었다.
•  

---

 

HTTP1.1에서 제공하는 persistent connection과 pipelining

 

---

HTTP 1.1의 문제 1 Head Of Line Blocking

• HTTP1.0의 커넥션마다 request를 날리는 구조에서 HTTP1.1의 지속커넥션과 파이프라인 도입으로 처리 시간을 효율적으로 줄였지만 보낸 요청 순서대로 응답을 받아야하는 부분에서 문제가 생겼다.
• 우선순위에 있는 요청의 응답속도가 늦어지면 후순위에있는 요청의 응답속도가 늦어진다.

HTTP 1.1의 문제2 Header 구조의 중복

• 지속 커넥션에서 주고받는 데이터가 중복된 헤더를 가지는 경우가 많아 메모리 자원을 낭비함.

 

---

HTTP2

HTTP 메시지 전송 방식의 변화

• • 기존 HTTP는 플레인텍스트로 구성되어 있지만 HTTP2부터 데이터를 전송할 때 바이너리로 인코딩하여 전송한다.
  • 바이너리 포맷의 데이터를 사용하게 되어, 데이터를 프레임 단위로 나눠 관리/전송할 수 있음.
  • 파싱, 전송속도 증가 오류 발생 가능성이 줄어듬
•  

• 

  • 프레임이란 HTTP2통신에서 데이터를 주고받을 수 있는 가장 작은 단위이고 헤더 프레임과 데이터 프레임으로 구성된다.
  • 요청과 응답의 단위이다.
  • 메시지는 다수의 프레임으로 구성되어 있다.
  • stream이랑 클라이언트와 서버 사이에 맺어진 연결을 통해 양방향으로 데이터를 주고 받는 한 개 이상의 메시지를 의미한다.
  • Frame > Message > Stream (프레임이 여러 개 모여 메시지가 되고 메시지가 여러 개 모여 스트림이 된다)

 

멀티플렉싱

• HTTP1은 요청과 응답이 메시지라는 단위로 구분되어 있었지만 HTTP2부터는 Stream을 통해 요청과 응답이 묶일 수 있어 다수 개의 요청을 병렬적으로 처리가 가능해졌다. 따라서 응답 프레임들은 요청 순서에 상관없이 먼저 완료된 순서대로 클라이언트에 전달이 가능하다.
• Head Of Line Blocking 해결

 

(옵션)

• Stream Prioritization : 리소스간 우선 순위를 설정 가능

• Server Push : 클라이언트가 요청하지 않아도 서버에서 알아서 데이터 전송 가능 (html 전송시 js와 css 동시에보냄)
  • HTML 태그 데이터를 내려줄 때 브라우저는 태그를 파싱해서, 또 요청을 날려야하는 리소스들이 뭔지 파악한 후 css/ 자바스크립트 / 이미지 등을 요청해서 받아온다.
  • server push가 필요할 떄 : 캐싱되지 않은 리소스를 받아올 떄, 페이지에서 필요한 리소스가 서버에 있을때 유용
  • server push가 필요없을 떄 : 캐싱되어서 재사용되는 리소스를push할때, CDN처럼 다른 서버에서 내려주는 리소스 떄문에 Blocking이 걸릴 때

 

• • header을 header Table로 관리한다. 이전 리퀘스트에서 중복으로 선언된 데이터는 인덱스값만 전송해서, 전송해야하는 데이터 양을 최소화한다.
  • 새롭게 추가되거나 변경된 헤더는 Huffman 인코딩이 되어 전송된다.
  • HPACK 압축방식Header Compression : 헤더의 크기를 줄여 페이지 로드 시간 감소

 

---

TCP 자체의 Head of Line Blocking이 존재하기 때문에 HTTP2의 한계가 있음

QUIC 이란?

• 전송 계층 프로토콜(TCP/UDP같은것)
• Google에서 만듦
• UDP 기반 -> TCP는 신뢰성을 확보하지만 지연을 줄이기 힘들고 UDP는 데이터 전송에 집중했기 때문에 원하는 기능을 구현할 수 있어 UDP를 채택
• 장점 : 전송 속도 향상 , 첫 연결 설정에서 필요한 정보와 함께 데이터를 전송 → 연결 성공 시 설정을 캐싱하여 다음 연결 때 바로 사용 가능
• Connection UUID라는 고유한 식별자로 서버와 연결해 커넥션 재수립이 필요X
• TLS 기본 적용과 IP Spoofing/ REplaty Attack 방지로 보안성 향상
• 독립 스트림 → 향상된 멀티플렉싱 기능 (HTTP2이 멀티플렉싱을 적용해도 TCP 자체로 Head Of Line Blocking이 존재함)keep-alive 커넥션