3. HTTP란 무엇이며 어떻게 진화되었는가? - 1

원문 : kamranahmed.info/blog/2016/08/13/http-in-depth/

Journey to HTTP/2 – Kamran Ahmed

HTTP는 모든 웹 개발자가 알아야 할 프로토콜로, 웹 전체를 작동시키고, 그것이 당신이 더 나은 응용 프로그램을 개발하는 데 확실히 도움이 되리라는 것을 알고 있다.

 

HTTP는 무엇인가?

먼저 HTTP란 무엇인가? HTTP는 클라이언트와 서버가 서로 통신하는 방법을 표준화하는 TCP/IP 기반 애플리케이션 계층 통신 프로토콜이다. HTTP는 인터넷을 통해 콘텐츠가 요청되고 전송되는 방식을 규정한다. 애플리케이션 계층 프로토콜에 따르면, 그것은 호스트(클라이언트와 서버)가 어떻게 통신하고 그 자체가 클라이언트와 서버 사이의 요청과 응답을 얻기 위해 TCP/IP에 의존하는 방식을 표준화하는 추상화 계층일 뿐이다. 기본적으로 TCP 포트 80이 사용되지만 다른 포트도 사용할 수 있다. 그러나 HTTPS는 포트 443을 사용한다.

 

HTTP/0.9 - One Liner(1991)

HTTP의 첫 번째 문서 버전은 1991년에 발표된 HTTP/0.9이다. 그것은 ”GET”이라는 싱글 메소드를 가진 가장 간단한 프로토콜이었다. 만약 클라이언트가 서버의 일부 웹페이지에 접속해야 한다면, 아래와 같이 간단한 요청을 했을 것이다.

 

GET /index.html

 

그리고 서버로부터의 응답은 다음과 같다.

(response body)
(connection closed)

즉, 서버는 요청을 받고, 응답하는 HTML로 회신하고, 콘텐츠가 전송되는 즉시 연결이 종료된다.

 

HTTP/0.9의 특징

ㆍNo header

ㆍGET 은 유일하게 허용된 메소드

ㆍ응답은 HTML이어야 함

 

 

HTTP/1.0 - 1996

1996년에 HTTP의 다음 버전 즉, HTTP/1.0은 원래 버전보다 훨씬 개선된 버전으로 진화했다.

 

HTML 응답만을 위해 설계된 HTTP/0.9와는 달리, HTTP/1.0은 이제 이미지, 비디오 파일, 일반 텍스트 또는 다른 컨텐츠 유형과 같은 다른 응답 형식을 처리할 수 있다. 더 많은 방법(즉, POST 및 HEAD), 요청/응답 형식 변경, 요청 및 응답 모두에 HTTP 헤더 추가, 응답을 식별하기 위한 상태 코드 추가, 문자 집합 지원 도입, 다중 파트 유형, 권한 부여, 캐싱, 콘텐츠 인코딩 등이 추가되었다.

 

샘플 HTTP/1.0 요청 및 응답 방법은 다음과 같다.

GET / HTTP/1.0
Host: kamranahmed.info
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

 

보시다시피 request와 함께 client도 개인정보, 필수응답 유형 등을 보내왔다. HTTP/0.9를 사용하는 동안에는 header가 없어서 이러한 정보를 보낼 수 없었다.

 

위의 요청에 대한 응답 예제는 아래와 같을 수 있다.

HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84

(response body)
(connection closed)

 

응답 초기에는 HTTP/1.0(HTTP 다음에 버전 번호가 표시됨)이 있고, 그 다음에 reason phrase(또는 상태 코드에 대한 설명, 만약 당신이 원한다면)가 뒤따른다.

 

이 새로운 버전에서 요청 및 응답 헤더는 여전히 ASCII 인코딩된 상태로 유지되지만, 응답 본문은 이미지, 비디오, HTML, 일반 텍스트 또는 기타 콘텐츠 유형일 수 있다. 그래서, 이제 그 서버는 클라이언트에 어떤 콘텐츠 유형도 보낼 수 있게 되었다.

 

HTTP/1.0의 주요 단점 중 하나는 연결당 여러 개의 요청을 가질 수 없다는 것이었습니다. 즉, 클라이언트가 서버로부터 무언가가 필요할 때마다, 새로운 TCP 연결을 열어야 하며, 그 단일 요청이 이루어진 후에는 연결이 종료된다. 그리고 어떤 다음 요건에 대해서도, 그것은 새로운 연결고리에 있어야 할 것이다. 왜 나쁜가? 10개의 이미지, 5개의 스타일 시트, 5개의 자바스크립트 파일이 있는 웹 페이지를 방문한다고 가정해 봅시다. 그 웹페이지에 대한 요청이 있을 때 총 20개의 항목을 가져와야 한다. 서버는 요청이 완료되는 대로 연결을 종료하기 때문에, 20개의 연결이 별도로, 연속적으로 이루어질 것이다. 이 많은 수의 연결은 three-way handshake로 인해 새로운 TCP 연결을 요구하는 경우 상당한 성능 저하를 초래하고 slow-start 때문에 심각한 성능 저하를 초래한다.

 

Three-way Handshake

Three-way Handshake는 모든 TCP 연결이 클라이언트와 서버가 응용 프로그램 데이터를 공유하기 전에 일련의 패킷을 공유하는 것으로 시작하는 것이다.

 

SYN - client가 임의의 번호를 선택한 후 x라 하고, 서버로 보낸다.

SYN ACK - 서버가 임의의 번호(y)로 구성된 ACK 패킷을 클라이언트로 회신하여 요청을 승인함. 여기서 x는 클라이언트가 보낸 번호다.

 

ACK - 클라이언트에서 서버로부터 수신한 수 y를 증가시키고, y+1과 함께 ACK 패킷을 다시 전송

 

Three-way handshake

 

Three-way Handshake가 완료되면 클라이언트와 서버 간의 데이터 공유가 시작될 수 있다. 클라이언트가 마지막 ACK 패킷을 전송하는 즉시 응용 프로그램 데이터 전송을 시작할 수 있지만, 서버는 요청을 이행하기 위해 ACK 패킷이 수신될 때까지 기다려야 한다는 점에 유의해야 한다.

 

그러나 HTTP/1.0의 일부 구현에서는 서버에 "서버야, 이 연결을 닫지마! 그러면 다시 연결해야 해"라는 새로운 헤더를 도입하여 이 문제를 해결하려고 시도했다. 하지만 여전히, 그것은 널리 사용되지 않았고 그 문제는 여전히 지속하였다.

 

HTTP는 연결이 없는 것 외에도 상태 비저장 프로토콜이다. 즉, 서버는 클라이언트에 대한 정보를 유지하지 않기 때문에 각각의 요청은 서버가 이전 요청과 아무런 관련 없이 스스로 요청을 이행하는 데 필요한 정보를 가져야 한다. 그래서 이것은 화재에 연료를 더하는 겁니다. 즉, 클라이언트가 열어야 하는 많은 연결을 제외하고, 그것은 또한 대역폭 사용을 증가시키는 와이어에 대한 중복 데이터를 보내야 하는 겁니다.