CS/네트워크

HTTP Re

한번은하자 2024. 6. 14. 18:33

1) HTTP/1.0

- HTTP/1.0은 기본적으로 한 연결당 하나의 요청을 처리하도록 설계되었습니다.

 

문제점

 - 서버로부터 파일을 가져올 때마다 TCP의 3-way-handshake를 계속해서 열어야 한다.

이는 RTT증가를 불러오게 됐습니다.

 

HTTP 1.0에서의 RTT 증가를 해결하기 위한 방법

- 이미지 스플리팅 : 많은 이미지를 다운로드 받게 되면 과부하가 걸리기 때문에 많은 이미지가 합쳐 있는

  하나의 이미지를 다운로드 받고, 이를 기반으로 background-image의 position을 이용하여 이미지를

  표기하는 방법이다.

- 코드 압축 : 코드를 압축해서 개행 문자, 빈 칸을 없애서 코드의 크기를 최소화하는 방법이다.

- 이미지 Base64Encoding : 이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법

HTTP 1.0

2) HTTP/1.1

 - 매번 TCP연결을 하는 것이 아니라 한 번 TCP 초기화를 한 이후에 keep-alive라는 옵션으로 여러 개의 파일을

   송수신할 수 있도록 바꾼 것이다.1.0버전에서는 있긴 했지만 표준화되어 있지 않았다.

문제점

- HOL Blocking(Head Of Line Blocking) : 네트워크에서 같은 큐에 있는 패킷이 그 첫 번째 패킷에 의해 지연될 때

  발생하는 성능 저하 현상을 말한다.

HTTP 1.1

 

3) HTTP/2

- 멀티플렉싱, 헤더 압축, 서버 푸시를 지원하는 프로토콜이다.

 

1) 멀티플렉싱 : 여러 개의 스트림을 사용하여 송수신한다는 것이다. 이를 통해 특정 스트림의 패킷이

    손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작할 수 있다.

   → 각각의 패킷을 쪼갠 후에 병렬적으로 보낸 후에 다시 합치는 구조이다.

 

2) 헤더 압축 : HTTP/1.X 에서는 헤더가 커서 문제가 발생했다. 이를 해결하기 위해서 허프만 코딩이 

    사용된다. 이는 빈도가 낮은 정보는 비트 수를 높게 표현하고 빈도가 높은 수는 비트 수를 낮게 표현해서

    전체 비트양을 줄이는 원리다.

 

3) 서버 푸시 : HTTP/1.1에서는 클라이언트가 서버에 요청을 해야 파일을 다운로드받을 수 있었다면

    HTTP/2는 클라이언트 요청없이 서버가 바로 리소스를 푸시할 수 있다.

    → html에는 css나 js파일이 포함되기 마련인데 html을 읽으면서 그 안에 들어 있던 css 파일을 서버에서

        푸시하여 클라이언트에 먼저 줄 수 있다.

 

4) HTTP/3

- TCP 위에서 돌아가는 HTTP/2와는 달리 QUIC이라는 계층 위에서 돌아가면, TCP 기반이 아닌 UDP 기반으로

  돌아간다. 즉 클라이언트가 서버에 어떤 신호를 한 버 주고, 서버도 거기에 응답하기만 하면 바로 본 통신을

  시작할 수 있다.