HTTP / HTTP 1.1 [Network]

이번엔 HTTP 네트워크 프로토콜이다. HTTP는 이미 여러 버전들이 존재하는데, 오늘은 HTTP의 시초격이라고 할 수 있는 HTTP 1.1 버전부터 알아볼 것이다. 잘 따라오라고~~!!

📌 What about HTTP?

'Hyper Text Transport Protocol' , HTTP

 쉽게 말하면 우리가 인터넷 화면에서 보는 html 파일을 실어나르는 통신 프로토콜이다. 즉 웹 브라우저에서 글, 사진, 영상 등을 볼 수 있게 만든 것! 네트워크 장치 간에 정보를 전송하도록 설계된 어플리케이션 계층의 프로토콜이다. HTTP는 Transport Layer의 네트워크 프로토콜 가운데 TCP를 사용하면서 실행된다. 여기서 오해하면 안되는 것이, 초기 HTTP의 탄생 목적은 웹서버에 있는 파일을 그저 웹브라우저에 띄우기 위함이었다. (뭐, 간단한 논문, 글, 기사 정도??)

 하지만 점차 통신의 목적과 방법이 다양해지면서 기존 HTTP의 구조와 통신 방식도 점차 바뀌게 되었고, TCP의 단점을 보완하고자 새로운 7계층 프로토콜(HTTP/2, HTTP/3, QUIC 등) 이 많이 생겨났다. 그럼 본격적으로 HTTP에 대해 알아보자.

 

"HTTP 가 TCP 를 쓴다고?"

 

 놀라지 말자. 일단 HTTP/1.1 버전은 그렇다. 추후 다루게 될 HTTP/2, HTTP/3 과는 약간은 상이한 구조를 띄고 있는데, 초기 버전이라 TCP를 끌어안은 채 동작한다. HTTP 아래 계층 구조를 보면 이해가 쉽다. 

Application Layer(HTTP/1.1) 아래 1~4 계층 구조.

Ref) "HTTP : The Definitive Guide", O'Reilly Media.Inc

 

 따라서 HTTP/1.1는 TCP/IP 통신 프로토콜의 장단점, 특징을 모두 수용한 채 동작한다. TCP에 대해서는 앞선 글에서 다루었으니 4계층에서 동작하는 특징은 간단하게만 언급하고, 추후 이로 인해 발생할 수 있는 문제점에 대해서도 얘기해보겠다.

• Reliable Data Transfer : 신뢰성 있는 데이터 전송
• Connection-Oriented
• 쌍방향적인 Byte Stream 동작
• Flow Control
• Congestion Control

 

그럼 간단한 그림을 통해 HTTP의 동작원리를 알아보자. 

HTTP Request-Response 구조

 

📌  How does it work??

✏️ Request - Response

 HTTP를 통한 일반적인 흐름에는 클라이언트 시스템(ex. 웹 브라우저)에서 서버에 일정 명령을 요청(Request)한 다음 서버에서 응답 메시지(Response)를 보내는 작업이 포함된다.

 

 이게 무슨 말이냐면, 통상 /.../.com라고 하는 인터넷 홈페이지를 접근하고자 할 때 우리는 URL이라는 서버 resource name과 함께 resource Location 을 알아야 한다. 이것도 결국 해당 root 파일이 위치한 '저장소'를 찾기 위함이다. 예를 들어, 아래 인터넷 사이트에 접근하고자 할 때, https: //... /.com/49를 입력하면, 해당 페이지에 접근이 가능하다. 

https://jhklee-coder.tistory.com/49

이모지 [Git/Github]

 

 이 때 동작하는 과정이 바로 ~~ root 디렉토리 아래에 있는, ~~ 디렉토리의 49번째 '파일을 찾는 행위'다. 결국 URL은 파일의 위치를 저장하는 도메인 이름이다.

 그리고 이 도메인 이름에 접근하고자 할 때 HTTP는 Get() 메소드를 통해 서버에 request하고, 서버는 이 요청에 대해 적절한 파일에 접근할 수 있도록 response 한다.

 

✏️ Transactions 

그럼 HTTP 클라이언트와 서버 사이에서 'Request - Response'가 어떻게 이루어지는지 내부 메소드들을 통해 알아보자. 내부 메소드의 역할은 크게 두 가지다. 클라이언트가 서버에게 요구할 때 필요한 명령과, 서버가 그에 맞게 수행해야 할 동작이다. 

• Support Several Request commands
• Ask Server which action to perform

이 동작을 위해 필요한 method 네 가지를 알아보자. 

 

✏️ Methods

1️⃣ Get

Get Request - Response

 

 

내가 얻고자 하는 파일(resource file)을 URL 을 통해 달라고 요청하는 함수.

➡️ Response : 서버는 request 받은 파일이 해당 위치 디렉토리에 있는지 확인한다. (요청에 대해 아무런 문제가 없다는 정보를 제공한다면, 200을 화면에 보여주는데, 우리는 이 Status 정보도 추가로 얻을 수 있다.

➡️ Status Code (상태 정보)

• 404 (Not Found. -> 파일이 없어요 ㅠㅠ)
• 200 (OK -> 파일이 있으니 해당 디렉토리로 이동시켜서 파일 보내드릴게요!!)
• 302 (Redirect. -> 해당 파일이 다른 위치로 이동되었거나, 삭제되었어요 ㅠ Go someplace else to get the resource)

 

2️⃣ Put

Put Request  - Response

Ref) "HTTP : The Definitive Guide", O'Reilly Media.Inc

 

웹페이지에서 파일을 업로드하는 등의 행동. 브라우저(클라이언트) 서버로 파일을 put request 로 밀어넣는 과정.  

➡️ Response : 서버는 request 받은 파일이 해당 위치 디렉토리에 저장하고, 잘 저장되었다는 메시지와 함깨 저장된 정보(ex. 파일)에 대한 Status를 보여준다.

 

3️⃣ Post

Post Request - Response

서버로 정보를 입력시킬 때 꼭 파일만 가능할까? 그렇지 않다. 혹은 서버 to 브라우저에서 파일이 아닌 걸 보내고 싶을 수 있다. 서버의 입력박스(ex. 프롬프트)에 숫자를 입력하면, 서버에서 돌려주는 형태다. 혹은 새로운 resource 파일이나 정보를 생성(등록)하고자 할 때도 사용한다. 

 

4️⃣ Delete

(그림 생략)

 

말 그대로 서버에 있는 파일, 정보, resource 를 삭제하고자 할 때 delete 함수와 함께 파일 URL을 입력해서 사용한다. 

 

이외에도 Head(), Trace(), Options() 등의 메소드들이 있으나, 위 핵심 4가지 메소드들을 아는 것이 우선이다. 해당 메소드들이 추후 등장할 웹서버-브라우저 프레임워크 주요 철학의 핵심 키워드가 되기 때문이다. (나중에 등장할 예정)

 

📁 Cf)

HLS (HTTP Live Streaming)

HTTP의 초기 목적은 파일을 웹서버에서 클라이언트 브라우저로 띄우기 위함이었다. 그러면 움직이는 영상은 어떻게 보낼 수 있을까? 생각해보면, 파일은 말 그대로 '정적인 상태'의 글이다. 하지만 동영상은 계속 움직이는 객체(혹은 물체)들로 이루어져있지 않은가. 그럼 HTTP 는 유튜브 영상 정보는 다루지 못하는 걸까?? 

 

그렇지 않다. 유튜브도 HTTP 를 사용한다. 다만 그 방식이 정적인 파일들을 보낼 때와 약간 다르다. How?? 바로 HLS (HTTP Live Streaming) 라는 방식을 써서 동작한다. 녹화된 영상을 잘게 쪼개서 많은 양의 파일들로 구성하는 방식이다. 그리고 이 잘게 쪼개진 파일을 전송받고자 끊임없이 request - response를 한다. 조금 시간이 흐르면 또 파일이 오고, 또 요청하고, 또 기다리는 이런 형태를 띄는 것!

 결국, 광고를 통해 미리 버퍼에 파일을 다운로드 받아둘 수 있는 시간을 벌어두고, 다운로드 된 크기가 얼마 이상이 될 때까지 기다리면서 HTTP는 영상도 성공적으로 웹브라우저, 웹클라이언트 환경에 사용할 수 있게 되었다.  

 

• 144p 의 해상도를 가진 파일: request - response 보냄.
• 네트워크와 컴퓨터 성능이 이를 견딜 수 있는 수준이네? 화면에서도 깔끔하게 보여지고 하니, 그러면 해상도를 올리고 이미지, 영상 파일의 수준을 높여서 보내주자. 
• 240p / 480p / 720p / 1080p : 동일

 

HLS (HTTP Live Streaming) / ref) https://velog.io/HTTP-라이브-스트리밍/HLS

Fig. 3 - Segments generation and Target Duration / ref) https://www.theoplayer.com/blog/http-live-streaming

 

앞서 언급했다시피, HTTP/1.1은 TCP 통신 프로토콜을 끌어안은 채 동작한다고 했다. 그러면 TCP의 단점인 slow-start 문제와 congestion-control 간 쌓일 수 있는 지연 문제를 어떻게 해결했을까?

 구글은 영상 streaming을 위해 기발한 해결책을 내세웠으니, 바로 '광고'와 버퍼다. 물론 광고는 사업적 이익을 위함이기도 하다. 하지만 영상의 무수히 많이 나뉘어진 파일을 불러올 때 HTTP 아래 통신 계층은 정보를 주고 받으면서 에러 및 지연을 발생시킨다. 결국 영상을 보여주기 전 광고를 통해 필요한 만큼의 지연 시간을 확보하고, 버퍼에 충분히 정보를 쌓으면서 Streaming 이 가능하다.

 

(이 TCP 통신 프로토콜을 활용한 기술은 추후 'QUIC'으로 대체됨! 나중에 자세히 다룰 예정.)

 

오늘은 여기서 끝!! 다음에 계속..