ABOUT ME

    -

    Today
    -
    Yesterday
    -
    Total
    -
    • HTTP가 뭐예요? (HTTP의 진화 과정)
      HTTP 2022. 10. 4. 09:00
      반응형

      • HTTP의 역사

      HTTP Evolution


      HTTP (Hyper-Text Transfer Protocol) 은 W3에 내재된 통신 규약으로 인터넷을 통해 웹 브라우저와 서버 간 데이터를 인코딩하고 전송하기 위한 프로토콜입니다.

      해당 게시물에서는 HTTP의 역사와 흐름에 대해 알아보도록 하겠습니다.

      1989년 CERN (유럽 입자 물리학 연구소) 팀 버러스 리 박사는 연구소 간 지식 공유를 위해 Hyper-Text 시스템을 제안하였고 그 과정에서 HTML, HTTP, W3, Httpd의 초기 버전이 탄생하였습니다.


      HTTP/0.9
      1991년 CERN 내부적으로 사용하던 HTTP를 최초로 외부에 선보입니다.

      개발 당시에는 버전 정보를 따로 부여하지 않았으나, 이후 프로토콜이 발전함에 따라 전/후를 구분하기 위해 0.9라는 버전을 붙이게 되었습니다.

      1.0이 아닌 0.9를 붙인 이유는 해당 버전은 후에 나온 정식 사양인 1.0의 이전이라는 의미로 0.9를 붙이게 되었습니다.

      해당 버전에서의 HTTP는 GET 요청만 가지고 있었지만 Stateless, Request-response 통신 등의 개념을 갖추었습니다.

      HTTP/0.9의 특징은 아래와 같습니다.

      1. Request - Response 구조
      2. TCP/IP를 통해 실행되는 ASCII 프로토콜
      3. HTML (Hyper-Text Mark-up Language)을 전송하도록 설계
      4. 서버와 클라이언트 간의 연결은 모든 요청 후에 닫힌다



      HTTP/1.0 (Header의 사용)
      Mosaic 브라우저와 Netscape Navigator 1.0이 출시되면서 인터넷 시장 날이 갈수록 커지게 되었습니다.

      동시에 W3C가 설립되며 HTML의 발전이 이루어졌고 HTTP 프로토콜 개선이 필요하게 되어 HTTP-WG라는 단체가 설립되었습니다.

      1994 ~ 1995년 인터넷 붐이 오면서 1996년 HTTP-WG는 늘어나는 요구에 따라 HTTP/1.0을 만들어 RFC1945를 발표합니다. 

      GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
  <IMG SRC="/myimage.gif">
</HTML>

      HTTP/1.0의 특징은 아래와 같습니다.

      1. 버전 정보가 전송되기 시작했다.
      2. 상태 코드 라인이 응답의 시작 부분에 붙어 전송되어 브라우저가 요청에 대한 성공과 실패를 알 수 있게 되었다.
      3. Header의 개념이 도입되어 요청과 응답 모두에 메타데이터를 전송하고 프로토콜을 유연하고 확장 가능하도록 만들었다.
      4. Header의 도입으로 Content-Type을 지정하여 HTML 외의 데이터를 전송할 수 있게 되었다.



      HTTP/1.1 (커넥션 유지)
      1997년 초창기 버전의 HTTP/1.1 이 발표되었으며 지속적인 개선과 업데이트가 표준에 통합되어 RFC2616으로 출시되었습니다.

      HTTP/1.1은 이전 버전에서 발견된 많은 모호성을 해결하고 여러 가지 중요한 성능 최적화를 도입하여 빠르게 표준으로 자리 잡았습니다.

      이후 RFC7230를 시작으로 지금까지 꾸준히 업데이트되고 있습니다.

      RFC문서에 대한 추가적인 정보는 해당 링크를 참고해보시기 바랍니다.

      GET /static/img/header-background.png HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache

(image content of 3077 bytes)

      HTTP/1.1의 특징은 아래와 같습니다.

      • 커넥션 유지 (Persistent connection)

      HTTP/1.0의 multiple connections와 HTTP/1.1의 Persistent connection 비교

      HTTP를 통해 데이터를 전달할 때 우리는 TCP의 3-Way Handshake & 4-Way Handshake를 이용합니다.

      이전 버전에서는 Client와 Server 간의 요청의 3-Way handshake(SYN, SYN+ACK, ACK)로 이루어져 10개의 오브젝트를 가진 웹페이지를 호출한다면 서버와 클라이언트 간에 10번에 TCP 연결과 끊는 과정을 반복해야 합니다.

      HTTP/1.1는 이를 보완하고자 Persistent connection을 기본적으로 지원하며 필요 없을 경우 Connection header를 통해 조절할 수 있습니다.

      Keep-Alive를 사용함으로써 우리는 TCP 연결을 최소화할 수 있으며 이는 리소스를 절약하고 Network latency를 줄일 수 있게 되었습니다.

      • 파이프라이닝 (PIpelining)

      No pipelining과 with pipeling 비교

      HTTP/1.1 에서는 서버와 클라이언트 간의 통신 효율성을 개선하기 위해 HTTP Pipelining이 등장했습니다.

      기존의 다수의 요청들이 각각의 서버 소켓에 입력된 후 요청에 대한 응답을 순차적으로 기다리는 문제를 해결하기 위해 다수의 요청을 하나의 TCP/IP Packet으로 묶어 요청합니다.

      파이프라인이 적용되면 한 개의 연결로 다수의 응답과 요청을 처리할 수 있고, Network latency를 효과적으로 줄일 수 있게 됩니다.

      하지만 여전히 응답의 처리는 순차적으로 진행되며 결론적으로 후순위의 응답은 지연될 수밖에 없습니다.

      • 호스트 헤더 (Host header)

      HTTP/1.0에서는 한 개의 IP에 하나의 도메인을 운영할 수 없었지만 HTTP/1.1부터는 호스트 헤더의 추가로 Virtual hosting이 가능해졌습니다.

      • 진화된 인증 절차 (Improved authentication procedure)

      HTTP/1.1 에서는 2가지 헤더가 추가되어 인증 절차가 강화되었습니다.

      1. proxy-authentication
      2. proxy-authorization



      HTTP/2.0 (멀티 플렉싱)
      2009년 Google에서 개발한 비표준 개방형 네트워크 프로토콜인 SPDY을 기반으로 HTTP/2.0에 대한 개발이 이루어졌습니다.

      HTTP/1.1은 기본적으로 연결 당 하나의 요청/응답을 처리하기 때문에 동시 전송 문제와 다수의 리소스를 처리하기에 속도와 성능 이슈를 가지고 있습니다.

      HTTP/2.0은 이런 점을 개선하고자 등장했으며 아래와 같은 특징을 가지고 있습니다.

      • Muliplexed stream

      HTTP/2.0의 Stream을 통한 데이터 전송

      HTTP/1.x가 가진 문제점 중, 네트워크에서 대기열에 Head의 지연에 따른 성능 저하 현상 HOL(Head Of Line) Blocking을 해결했습니다.

      • Server push

      HTTP/2.0 Server push

      클라이언트가 요청하지 않은 JS, CSS, Font, Image 등과 같이 필요하게 될 특정 파일들을 서버에서 단일 HTTP 요청 시 응답과 함께 전송할 수 있게 되었습니다.

      • HTTP Header compression

      HTTP/2.0의 Header compression

      HTTP/1.x 에서는 Header가 Plain text로 이루어져 그 크기가 점점 커졌지만 HTTP/2.0 에서는 이전 Header와 중복되는 필드는 재전송하지 않으며 HPACK라는 압축 방식을 통해 데이터 전송 효율을 높였습니다.

      • Stream priority

      HTTP/2.0 우선순위 지정 트리

      HTTP/2.0 에서는 HTTP 메시지를 개별 프레임으로 분할할 수 있고 여러 스트림 프레임을 다중화할 수 있게 되면서, 이에 '우선순위 지정 트리'를 통해 우선순위를 지정할 수 있도록 하였습니다.

      서버에서는 우선순위 지정 트리를 분석하여 우선순위가 높은 응답을 클라이언트에 우선적으로 전달될 수 있도록 대역폭을 조절하게 됩니다.


      HTTP/3.0 (UDP로의 전환 + QUIC ptorocol)

      HTTP/3.0의 QUIC와 기존 모델 비교


      지난 HTTP/2.0에서 HTTP의 HOL blocking 문제는 해결하였지만 TCP를 기반으로 하고 있다 보니 TCP HOL blocking의 문제는 영원한 숙제였습니다.

      HTTP/2.0에서는 하나의 연결 안에서 여러 개의 스트림이 전송되는데 하나의 패킷이 손상되거나 유실되면 재요청까지 TCP 연결이 중단되게 됩니다.

      HTTP/3.0은 UDP를 사용하면서도 프로토콜의 신뢰성을 유지하기 위해 QUIC 프로토콜을 만들었습니다.

      신뢰성이 보장되지 않는 UDP에 새로운 전송계층을 추가함으로써 각각의 스트림을 식별자를 통해 독립적으로 움직이게 만들었으며, 그 결과 패킷 손상이 발생해도 해당 스트림만 멈추게 됩니다.

      또한 QUIC 프로토콜은 0-RTT, 1-RTT Handshake를 제공함으로써 3-way handshake로 발생되는 시간을 줄여줍니다.

      여기까지 HTTP의 진화 과정에 대해 알아보았습니다.






      구독과 좋아요 그리고 생산적인 댓글은 언제나 환영입니다.

      반응형
      저작자표시 비영리

      'HTTP' 카테고리의 다른 글

      HTTP가 뭐예요? (HTTP Request methods와 Response status code)  (0) 2022.10.10
      HTTP가 뭐예요? (REST)  (2) 2022.10.08
      HTTP가 뭐예요? (HTTP의 특징과 구조)  (2) 2022.10.07

      관련글 관련글 더보기

      댓글

    Designed by Tistory.

    티스토리툴바