[FE면접준비] HTTP 총 정리 및 특징, HTTP1.1 VS HTTP2.0

HTTP

• HTTP (Hypertext Transfer Protocal)은 인터넷 상에서 데이터를 주고 받기 위한 클라이언트/서버 모델을 따르는 프로토콜

• WWW (world wide web)에서 하이퍼텍스트 문서를 교환하기 위해 사용되는 통신규약

• TCP/IP 프로토콜 위에서 동작한다. 포트 80번을 사용하여 통신한다

• HTML 문서, 이미지, 동영상, 오디오, 텍스트 문서 등 의 모든 종류의 데이터를 전송한다

• 하이퍼텍스트 기반으로 데이터 전송 = 링크 기반으로 데이터에 접속하겠다

• 첫 표준은 HTTP/1.1이며 이후로 HTTP/2, HTTP/3이 등장했다.

클라이언트/서버 모델

• 클라이언트
  • 클라이언트 소프트웨어(ie,crome같은 브라우저)가 설치된 컴퓨터를 이용해서 서버에 요청한다. URI를 통해 서버에 접속하고 데이터를 요청한다.
• 서버
  • 클라이언트 요청을 받아 해석하고 응답하는 소프트웨어(Apache, nginx, IIS, lighttpd)가 설치된 컴퓨터
  • 웹서버는 표준 포트인 80번 포트로 서비스 한다

HTTP/1.1

비연결지향(connectionless)

• 클라이언트가 서버에 리소스 요청한 후 응답 받으면 연결을 끊어버리는 특징이다.
• 서버에 부담을 주지 않도록 클라이언트 요청을 처리하면 연결을 끊어 서버의 부담을 줄인다. 하지만 리소스를 요청할 때마다 새롭게 연결해야 되므로 오버헤드 비용이 발생한다. (RTT 증가, 네트워크 성능 저하)
• 오버 헤드 해결 방법:
  • 요청 헤더 connection:keep-alive 속성으로 지속적 연결 상태(persistent connection)을 유지한다.
    요청을 할 때마다 연결하지 않고 기존의 연결을 재사용하는 방식으로 HTTP/1.1부터는 지속적 연결 상태가 기본이고 해제하기 위해서는 명시적으로 요청 헤더를 수정해야 한다.
  • 파이프라이닝: http/1.1의 connection 당 하나의 요청 처리를 개선하는 방법 중 파이프라이닝이 존재한다.  connection을 통해 다수개의 파일을 요청/응답 받는 기법

무상태성 (stateless)

• 각각의 요청은 독립적이라고 여겨지는 특성으로 서버는 클라이언트의 상태를 유지하지 않는다.

• 요청이 처리되면 연결이 끊어지기 때문에 클라이언트의 이전 상태를 알 수 없다. connectless로부터 파생되는 특징이다.

• 클라이언트가 과거에 로그인을 해도 로그 정보를 유지할 수 없다. 웹 서비스를 하기위해서 쿠키나 세션 또는 토큰 방식의 OAuth 및 JWT가 사용된다.

• 동시 전송이 불가능하고 요청과 응답이 순차적으로 이루어진다. HTTP문서 안 다수의 리소스를 처리하려면 Latency(대기시간)이 길어진다

HTTP/1.1 단점

• HOL (Head of Line) blocking: 특정 응답의 지연
  • http/1.1의 connection 당 하나의 요청 처리를 개선하는 방법 중 파이프라이닝이 존재
  • connection을 통해 다수개의 파일을 요청/응답 받는 기법

하나의 TCP 연결에서 3개의 이미지 (a.png, b.png, c.png)를 요청한 경우 첫 번째 이미지를 요청하고 응답이 지연되면 2, 3번째 이미지는 대기하게 되는데 이런 현상을 HTTP의 HOB (head of line blocking)이라고 부른다. 파이프라이닝의 큰 문제점 중 하나.

 

• RTT (round trip time) 증가
  • 하나의 connection에 하나의 요청을 처리하면서 매 요청별로 connection이 연결되기 때문에 TCP 상에서 동작하는 HTTP 특성상 3- way handshake가 반복적으로 일어나 불필요한 RTT 증가와 네트워크 지연을 일으켜 성능을 저하시킨다 
• 무거운 header 구조 (ex. 쿠키)
  • 헤더에 많은 메타 정보를 저장한다
  • 매 요청시마다 중복된 header값을 전송하게 되며 해당 domain에 설정된 cookie 정보도 매 요청시 마다 헤더에 포함되어 전송된다
  • 전송하는 값보다 헤더 값이 더 큰 경우도 있다.

HTTP/1.1 단점 해결 방법

1. Image spriting 이미지 스프라이트 (여러 개의 이미지를 하나의 이미지로 합쳐서 관리하는 이미지)

• 이미지 파일 요청 횟수를 줄이기 위해 여러 아이콘을 하나의 큰 이미지를 만든다음 css에서 해당 이미지 좌표값을 지정해 표시한다. 
• ex) 이미지 하나를 가지고 여러 아이콘을 만드는 방법 (각도, 방향 조절)

2. Domain Sharing

• 최신 브라우저들은 http/1.1 단점을 극복하기 위해 다수의 connection을 생성해서 병렬로 요청을 보내기도 한다. 
• 브라우저 별로 domain 당 connection 개수 제한이 존재해서 근본 해결책은 아니다. 

3. Minify css/ javascript: 코드 축소시킴, 스크립트, 스타일 시트를 html문서 하단, 상단에 각각 위치시킴 

4. SPDY 등장 

• 근본적으로 문제 해결 X
• 구글은 Latency 관점에서 http고속화한 스피디라는새 프로토콜을 구현했다.
• HTTP 통한 전송을 재정의하여 구현

HTTP/2.0 특징

• Multiplexed Streams
  • 한 커넥션으로 동시에 여러 개의 메세지 주고 받음. 응답 순서에 상관없이 stream으로 주고 받음
  • http/1.1의 connection keep-alive, pipelining 개선시킴 
• Stream Prioritization
  • 요청한 리소스간 우선 순위를 설정하여 의존성 있는 파일의 수신이 늦어지는 경우 브라우저 렌더링이 늦어지는 문제 해결 
• Server Push
  • 서버는 클라이언트가 요청하지 않은 리소스 보내줄 수 있음
  • http/1.1에서 클라이언트는 요청한 html문서 수신 후 해석하면서 필요한 리소스를 재 요청하는데, http/2에서는 server push  기법을 이용해서 요청하지 않은 리소스를 push하여 클라이언트의 추가적인 요청을 최소화하여 성능 향상을 시킨다
  • push_promise라고 부른다

• header compression
  • header 정보를 압축하기 위해 header table과 huffman encoding 기법을 사용하는데 이를 hpack 압축방식이라 한다
  • 클라이언트가 여러 번 요청을 보낼 때 http/1.1은 헤더에 중복 값이 존재해도 그대로 중복 전송한다. http/2에서는 static/dynamic 테이블 개념을 이용해 중복 header를  검출하고 중복된 헤더는 index값만 전송하고 나머지는 huffman encoding으로 인코딩하여 전송한다.

 

 

출처

HTTP/1.1 VS HTTP/2

baeharam/Must-Know-About-Frontend

HTTP 프로토콜이란?