안녕하세요 RyuWoong 입니다.
이번에 다뤄볼 이야기는 HTTP에 관한 이야기 입니다.
우연히 접한 이야기였는데, 흥미로워서 포스팅하게 됐습니다.
HTTP 단순하게 프로토콜인줄 알았는데 버전도 있고 버전에서 어떤변화가 있는지 함께 알아볼까요?
HTTP
HTTP는 Hyper Text Transfer Protocol의 약자로 HTML문서와 같은 리소스를 가져올 수 있도록 해주는 프로토콜이자 웹에서 이루어지는 데이터 교환의 기초입니다. 아주 과거에 웹사이트는 순수하게 Text로 이루어진 방식이였다고 합니다. Hyper Text라는 것이 등장하고, 이때 우리가 아는 웹사이트의 시초가 되었습니다. 사이트 내에서 '클릭'을 해 다른 페이지로 이동하는 지금은 별거 아닌 기술 같지만, 이 시절엔 엄청난 혁신이였죠. 닷컴버블 시절에 '.com' 도메인을 가진 웹사이트만 있어도 투자를 받을 수 있었다라는 소리도 있으니까요. 아무튼, HTTP를 이용하여 우리는 인터넷에서 데이터를 주고 받을 수 있게 되었습니다.
0.9
HTTP의 초기 버전을 의미하며, 차후에 현재버전과 구분하기위해 0.9라는 버전명이 붙었습니다. 요청은 단일라인으로 구성되며, 메서드는 GET만 가능했습니다. 또 HTTP 헤더가 없었는데 이는 HTML 파일만 전송될 수 있으며 다른 유형의 문서는 전송될 수 없음을 의미합니다. 상태 혹은 오류 코드도 없었습니다. 문제가 발생한 경우, 특정 HTML 파일이 사람이 처리할 수 있도록, 해당 파일 내부에 문제에 대한 설명과 함께 되돌려 보내졌었다고 합니다.
GET /mypage.html
<HTML>
A very simple HTML page
</HTML>
1.0
초기버전은 매우 간단하고 제한적이였습니다. 따라서 융통성을 가질 수 있도록 확장한 버전입니다.
- 버전 정보가 각 요청 사이내로 전송되기 시작. ( GET /mypage.html HTTP/1.0 )
- 상태 코드 라인 또한 응답의 시작 부분에 붙어 전송되어, 브라우저가 요청에 대한 성공과 실패를 알 수 있고 그 결과에 대한 동작(특정 방법으로 그것의 로컬 캐시를 갱신하거나 사용하는 것과 같은)을 할 수 있음.
- HTTP 헤더 개념은 요청과 응답 모두를 위해 도입되어, 메타데이터 전송을 허용하고 프로토콜을 극도로 유연하고 확장 가능하도록 만듬.
- 새로운 HTTP 헤더의 도움으로, 평이한 HTML 파일들 외에 다른 문서들을 전송하는 기능이 추가되었습니다. ( Content-Type )
Front End 개발자나 Back End 개발자라면, Network 부분을 살펴보다보면 본 것 같은 개념들이 쏙쏙 들어와 있죠?
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>
초기에 단순 했던 용청과 응답이 이제 좀 더 우리에게 친숙한 모습으로 봐뀌었습니다.
하지만 아직 공식적인 표준이 아니였습니다.
1.1
1.0이 공개된지 몇 달 뒤 1.1 버전이 공개되었습니다. HTTP의 첫번째 표준으로 모호함을 명확하게 하고 많은 개선 사항들을 도입했습니다.
특히 영속적인 Connection과 Pipelining이라는 것이 도입된 것이 큰 차이점입니다.
영속적인 Connection.
기존 1.0 버전에서는 이미지 좌측에 보이는 것처럼 Connection이 연결되고 1개 요청 전송 후 닫히는 것을 반복하는걸 볼 수 있습니다. 단기 Connection이라고 하는데 요청이 3번 들어간다면, 3번의 연결과 닫힘이 반복되어야 하기에 응답속도가 길어질 수 밖에 없었습니다. 이러한 문제를 가운데 이미지처럼 개선 하고자 했습니다. 영속적인 Connection이라고 합니다. 얼마간 연결을 열어놓고 여러 요청에 재사용함으로써, 새로운 TCP 핸드셰이크를 하는 비용을 아끼고, TCP의 성능 향상 기능을 활용할 수 있습니다. 열어 놓는 시간은 Keep-Alive 헤더로 컨트롤 할 수 있습니다.
Pipelining.
그리고 이미지 우측처럼 Pipelining이 도입 되었습니다. HTTP는 기본적으로 요청을 순차적으로 처리합니다. 따라서 네트워크 지연과 대역폭 제한에 걸려 다음 요청을 보내는 데까지 상당한 딜레이가 발생할 수 있습니다. 커넥션 지연을 회피하기 위해 파이프라이닝이라는 기술이 도입 되었습니다. 같은 영속적인 Connection을 통해서, 응답을 기다리지 않고 요청을 연속적으로 보내는 기능입니다.
Host Header.
동일 IP 주소에 다른 도메인 호스트가 가능해졌습니다. 이 덕분에 가상호스팅이 가능해졌습니다.
이로서 한 대의 서버에 여러 어플리케이션을 운영할 수 도 있는 것이죠!
문제점.
HOL(Head Of Line)Blocking.
첫번째로 처리해야하는 요청에서 딜레이가 발생하면 두 ~ 세번째 요청이 먼저 완료 되었어도 첫번째 요청이 끝나기 전까지 기다려야하는 병목이 생깁니다. 이를 HOL Blocking이라고 합니다.
무거운 Header 구조.
Header는 점점 비대해지고, 댜앙한 값들이 추가되었습니다. 따라서 전송 되는 데이터에 비해 Header가 더 큰 경우도 생겼습니다.
2.0
1.1 에서 부족한 것을 개선하고 성능향상에 초점을 두었습니다.
Multiplexed Streams
한 커넥션으로 동시에 여러 개의 메세지를 주고 받을 있으며, 응답은 순서에 상관없이 stream으로 주고 받습니다.
Stream Prioritization
요청 리소스간 의존관계를 설정 합니다.
Server Push
HTML문서상에 필요한 리소스를 클라이언트 요청없이 보내줄 수 있스빈다.
Header Compression
Header 정보를 HPACK 압축 방식을 이용하여 압축하여 전송합니다.
문제점.
TCP 위에서 동작하기 때문에 TCP 통신으로 생기는 Latency는 해결하기 어렵다. 따라서 UDP로 통신하는 3.0이 등장하게 되었다.
참조.
'Programming > Web' 카테고리의 다른 글
Web Performance .03 중요 렌더링 과정 (0) | 2023.04.02 |
---|---|
Web Perfomance .02 브라우저가 웹페이지를 보여주기까지. (0) | 2023.03.26 |
Web Perfomance .01 Latency (0) | 2023.03.24 |
Web Performance .00 시작하기 전에 (0) | 2023.03.23 |
웹표준과 웹접근성 (Web Standards & Web Accessibility) (0) | 2023.03.11 |
삽질의 기록과 일상을 남기는 블로그입니다. 주로 React Native를 다룹니다.
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!