HTTP 프로토콜 발전

신복호·2020년 9월 5일

HTTP

목록 보기

1/1

HTTP 프로토콜이란?

HTTP(HyperText Transfer Protocol, 문화어: 초본문전송규약, 하이퍼본문전송규약)는 W3 상에서 정보를 주고받을 수 있는 프로토콜이다. 주로 HTML 문서를 주고받는 데에 쓰인다. 주로 TCP를 사용하고 HTTP/3 부터는 UDP를 사용하며, 80번 포트를 사용한다. 1996년 버전 1.0, 그리고 1999년 1.1이 각각 발표되었다.

출처 : https://ko.wikipedia.org/wiki/HTTP

즉 인터넷에서 데이터를 주고 받을수 있는(HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는) 프로토콜입니다.

HTTP 동작 방식

참조: https://joshua1988.github.io/web-development/http-part1/

HTTP는 서버 사이에서 이루어지는 요청/응답(request/response) 프로토콜입니다.

HTTP 특징

Request-Response
상태가 없는 Stateless 프로토콜
Connetionless

Request - Response

한 컴퓨터 (클라이언트) 에서 데이터를 요청을 보내면 다른 컴퓨터(서버) 에서는 그 요청에 따른 응답을 보내는 형식

Stateless (무상태 프로토콜)

어떠한 이전 요청과도 무관한 각각의 요청을 독립적인 트랜젝션으로 취급하는 통신 프로토콜

Connectionless(비연결성)

클라이언트와 서버가 한번 연결을 맺은 후. 클라리언트의 요청에 대해 서버가 응답을 마치면 맺엇던 연결을 끊어 버리는 성질

HTTP 발전 방식

HTTP 용어 등장

1965년 제너두 프로젝트에서 테디 넬슨이 만듬

HTTP 0.9 - 원라인 프로토콜

본래 HTTP 초기버전에는 번호가 없었으나 차후 버전과 구별하기 위해 0.9로 불림
요청 : 요청된 방법 + 해당 경로
Method : GET
응답 직후 종료
HTTP Header x -> HyperText 이외에 다른 파일 전송 x
상태 / 오류코드 / 버전 x

HTTP 0.9 예시

request : GET /user.html
response :
```
 <HTML>
 	Simple Page    
 </HTML>
```

HTTP 1.0 - 확장

1996년 등장
HTTP 버전 정보가 각 요청 사이내로 전송 가능
상태 코드 도 응답의 시작부분에 붙어 전송 시작
-> 브라우저 요청에 대한 성공/실패 여부 확인
요청에 따른 결과에 대한 동작(로컬 캐시 갱신/사용) 기능
HTTP 헤더 개념 등장
-> 메타데이터 전송을 허용 (프로토콜의 유연성 / 확장 가능성 높임)
-> 평이한 HTML 이외에 다른 문서들 또한 전송이 가능해짐(Content-Type)
연결 방법 : GET , HEAD, POST
단순한 동작이 반복되면서 통신부하 문제 발생

HTTP 1.0 예시

Request
Get /myPage.html HTTP/1.0
User-Agent : NCSA_Mosaic / 2.0 (Windows 3.1)
Response
-> HTTP/1.0 200 OK
Content-Type: text/html
Content-Length: 137582
Expires: Thu, 01 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 1 May 1996 12:45:26 GMT
Server: Apache 0.84

Resource

<HTML> 
	A page with an image 
	<IMG SRC="/myimage.gif">
</HTML>

HTTP 1.1 - 표준 프로토콜

1997년 1월 등장
Connction 재사용이 가능 -> Keep-alive 기능
pipelining의 등장으로 인해 Multiple Request가 처리 가능
-> 첫번째 요청에 대한 응답이 완전히 전송되기 전에 두번째 요청을 가능하게 함
Proxy Server , 간접 접근 지역
Caching -> 전송 및 접근 시간 절약
단일 IP로 Multiple Web Site 사용 가능
-> 자원 소모를 줄임

Keep-alive 및 Pipelining

Keep-Alive
: 기존 1개의 요청/응답의 프로세스를 처리 하면 Connectionless 특성으로 인해 Connection이 close됩니다. 그에 따라서 요청/응답을 다시 요청 해야 하는데 요청/응답을 하기 전 클라이언트와 서버간의 연결을 위한 작업이 필요합니다. 그에 따라서 데이터를 주고 받는 시간이외에 나머지 추가 인증 시간이 누적되어서 Network Latency 가 증가합니다. 이를 개선 하기 위해 Keep-Alive라는 개념을 도입하여 Connection을 유지해 인증시간에 따른 레이턴시를 감소 시킵니다.
Pipelining
: 하나의 Connection으로 다수의 Request / Response를 처리할수 있게끔 하는 기능으로서 Network Latency가 줄일수 있다.
-> 완전한 멀티플렉싱이 아닌 응답처리를 미루는 방식으로 앞선 응답이 오지 않을 경우 HOL Blocking 발생

Proxy Server

proxy : 같은 프로토콜을 사용하는 둘 이상의 어플리케이션을 연결하는 용도
보안 개선
성능 개선 / 비용 절약
트래픽 개선 및 사용자 접근 차단 기능

Caching

브라우져가 웹 페이지 구성요소를 PC의 hard disk에 저장했다가 같은 요소가 다시 불릴 때 서버에 요청하지 않고 저장된 것을 보여주는 것
-> cache는 client와 svr 사이에 위치하여 기능을 수행함으로써 데이터의 전송을 줄여 양측의 부하를 줄이고, 보다 빨리 리소스를 얻을 수 있도록 한다.

출처: https://jaweb.tistory.com/entry/HTTP-Http-11-Cache-Header-에-대한-정리 [잡다구리 파크]

HTTP 1.1의 문제

HOL (Head Of Line) Bloking - 특정 응답의 지연
- HTTP의 HOL Blocking 문제 : 순차적으로 데이터를 요청하고 응답을 받는 작업 진행중 먼저 받은 요청이 끝나지 않으면 뒤의 요청이 아무리 빨리 끝나도 대기해야하는 현상
RTT(Round Trip time)의 증가

요청별로 connection을 만들게 되고 TCP상에서 동작하는 HTTP의 특성상 3-way Handshake 가 반복적으로 일어나고 또한 불필요한 RTT증가와 네트워크 지연을 초래하여 성능을 저하
-> 3-way Handshake : 전송 제어 프로토콜(TCP)에서 통신을 하는 장치간 서로 연결이 잘 되어있는지 확인하는 과정,방법
무거운 Header 구조
- header에는 많은 메타 정보를 저장
- 매 요청시마다 중복된 Header값을 전송하게 되며 또한 domain에 설정된 Cookle 정보도 매 요청시마다 Header에 포함
- 이로 인해 전송하려는 데이터 보다 헤더 값이 더 큰 경우 발생

HTTP 1.1 개선

Image Spriting

여러개의 이미지를 하나의 이미지로 합쳐서 관리하는 이미지 (사용시 좌표범위로 구분하여 사용)

Domain Sharding

리소스를 여러 개의 도메인으로 나누어 저장하여, 페이지 로딩 시간을 빠르게 하는 방법

각 브라우저 당 최대 Connection 수가 한정이 되있기 때문에 각 도메인을 나눔으로서 페이지 로딩 시간을 개선

Minify CSS/Javascript

CSS 및 JAVASCRIPT를 압축해서 전달

Data URI Scheme

data: 스킴이 접두어로 붙은 URL은 컨텐츠 작성자가 작은 파일을 문서 내에 인라인으로 임베드해서 데이터를 전송

HTTP 2.0 등장

SDPY(구글 제안프로토콜) 기반으로 2015년 IETF에 의해 HTTP 2.0 등장

HTTP 2.0 특징

Binary Framework

Binary Framwork
- 기존 plane 텍스트가 아닌 Binary 프레임으로 구성
- 파싱이 더 빠르고, 오류 발생 가능성이 낮음
Frame
- HTTP 2.0 에서의 통신의 최소 단위
- 최소의 하나의 프레임 헤더
- 바이너리로 인코딩 작업
Message
- 다수의 프레임
- 요청/응답의 단위
Streams
- 구성된 연결 내에서 전달되는 바이트의 양방향 흐름, 하나 이상의 메시지가 전달 가능하다
참조 : https://velog.io/@taesunny/HTTP2HTTP-2.0-%EC%A0%95%EB%A6%AC

Stream Prioritization

리소스간의 우선순위를 설정하여 랜더링이 늦어질때 발생할수 있는 문제를 해결한다.

Multiplexing 개선

하나의 TCP connection내에서 다수의 Stream을 생성
하나의 요청이 지연되면 나머지 응답이 늦어지는 Pipelining과 달리 각각의 request/response을 독립적으로 처리
-> 다수의 request/response를 동시에 처리 가능

Header Compression

Header 정보를 압축하기 위해 Header table 과 Huffman Encoding 기법을 이용
-> 반복적으로 사용되는 헤더를 헤더 테이블내의 인덱스로 표기
-> 헤더 크기를 약 80퍼센트 정도 줄임

Server Push

클라이언트가 요청하지 않아도 필요가 예상되는 리소스를 서버가 미리 전송
-> HTTP 1.1에서는 클라이언트가 HTML 문서를 요청했고 해당 HTML에 여러개의 리소스가 있는 경우 해석하면서 필요한 리소스를 재요청 하는 방식이며 반면 HTTP/2에서는 Server Push 기법을 통해서 클라이언트가 요청하지 않아도 리소스를 push 해주는 방식

HTTP 2.0 한계

HTTP 2.0가 HTTP 1.1에 비해 많은 기능들이 개선되었으나 HTTP2.0 또한 TCP통신을 이용하기 때문에 HTTP 1.1에 문제점에서 발생했던 문제들이 여전하게 발생하고 있습니다.

3-way Handshak 문제
HOL (Head Of Line) Bloking

HTTP 3.0

HTTP 2.0이 2015년도에 등장하였습니다. 그런데도 불구하고 약 4년만에 HTTP3.0이 등장하였습니다. 무엇이 바뀐것일까?

The differences are in the mapping of these semantics to underlying transports. Both HTTP/1.1 and HTTP/2 use TCP as their transport. HTTP/3 uses QUIC , a transport layer network protocol developed initially by Google where user space congestion control is used over the User Datagram Protocol (UDP). The switch to QUIC aims to fix a major problem of HTTP/2 called "head-of-line blocking": because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recovery

참조 : https://en.wikipedia.org/wiki/HTTP/3

가장 눈에 띄는 것은 기존 HTTP의 통신 방식인 TCP 에서 QUIC로 바뀐것이다.
그렇다면 QUIC란 무엇일까?

QUIC 프로토콜

QUIC (Quick UDP Internet Connection) :
구글에서 2013년 6월에서 공개한 프로토콜으로서 UDP를 채택한 프로토콜입니다.

QUIC 장점

연결 설정 시 레이턴시 감소
- TCP 통신을 사용하지 않으므로 통신을 시작시 번가로운 3-WAY-HANDSHAKE 과정을 거치지 않아도 된다.
- 클라이언트가 서버에 신호를 한번 주고 서버가 거기에 따른 응답만 하면 바로 통신 가능
흐름 제어의 속도 개선
- TCP/QUIC 둘다 통신과정에서 발생한 에러를 ARQ 방식을통해 에러를 복구하는 방식
  - TCP: Stop and Wiat ARQ (수신측에서 적절한 답변을 안주면 레이턴시 발생)
  - QUIC : 에러를 정정할수 있는 이레이저 코드를 같이 전송
    ※ 이레이저 코드 : 데이터 원본을 nn개로 나눈후 그 데이터를 가지고 kk의 패러티를 생성해서 최대 kk개가 손실이 되더라도 nn개의 데이터만 있으면 전체 제이터를 복구 가능
클라이언트의 IP가 바뀌어도 연결이 유지됨
- TCP는 소스의 IP주소와 포트, 연결대상 IP주소와 포트로 연결 식별
- QUIC는 Connection ID를 사용하여 서버와 연결 생성
  참조 : http://m.blog.daum.net/dosman1/2251

참조

신복호

한참 열정이 가득한 백엔드 개발자입니다.