웹의 핵심 기술 HTTP 프로토콜

HTTP 프로토콜 개념

팀 버너스 리 박사에 의해 개발된 HTTP(HyperText Transfer Protocol)는 하이퍼텍스트 문서를 전송하기 위해 사용되는 프로토콜, 즉 통신 규약으로 웹의 핵심 기술이다. 하이퍼텍스트 문서는 HTML 파일이다.

그림1 - HTTP 통신

HTTP 버전

HTTP 버전은 다음과 같다.

 

HTTP/0.9

최초로 웹이 만들어 졌을 때 오직 HTML을 받아 오기위해 만들어 졌다.

그래서 버전 번호도 없고 명세서도 없으며, 정식 사양이 아니었다.

이후 HTTP/1.0부터 정식 사양으로 되면서 이전이랑 의미로 HTTP/0.9라는 버전이 붙여졌다. 

HTTP/0.9는 GET메소드만 지원하며, 특별한 기능은 없다.

HTTP/0.9에서 HTTP/1.0으로 빠르게 대체되었다.

 

 

HTTP/1.0

HTTP의 정식 사양으로 처음으로 널리 사용하기 시작한 버전으로 RFC1945가 발행되었다. 

HTTP/1.0부터 POST, HEAD 메소드,  헤더를 지원하며, 요청의 결과를 알 수 있는 상태코드가 추가되었다.

HTML 파일들 외 다른 파일들도 전송이 가능하게 되었다. 허나 각 요청마다 새로운 연결을 맺고 끊고 다시 새로운 연결을 맺는 비효율적인 비 연결지향(Connectionless)방식으로 성능이 떨어진다.

 

 

HTTP/1.0+

HTTP/1.0은 비효율적인 연결에 대한 문제가 있었다.

HTTP/1.0+에서는 "Keep-Alive 커넥션"을 지원함으로써 여러 번 커넥션을 맺는 설계상의 문제를 해결하였다.

 

 

HTTP/1.1

HTTP/1.1은 현재 가장 많이 사용되고 있는 버전으로 HTTP의 설계상 문제들을 해결하고 성능을 최적화하였다.

HTTP/1.0+에서는 Keep-Alive 커넥션을 통해 지속 연결(Persistence Conneciton)을 지원하였으나, HTTP/1.1부터 Keep-Alive는 명세에서 빠지고 기본으로 지속 연결이 활성화 되어 있다. 모든 요청이 끝나면 "Conneciton:close" 헤더를 통해 연결 종료를 알린다. 또한, 기존이 "GET, POST, HEAD" 3가지 뿐이었던 메소드가 "OPTIONS, PUT, DELETE" 등 많은 메소드가 추가되었다.

 

HTTP/2.0

HTTP의 성능 문제는 여전히 존재하였으며, 특히 요즘 웹의 경우 하나의 웹 페이지를 보기 위해서 수십개의 요청을 보내야 정상적으로 페이지를 볼 수 있다. 때문에 이런 문제를 해결할 수 있는 HTTP/2.0이 등장하였다. HTTP/2.0은 성능 향상에 초점을 둔 프로토콜로 멀티플렉싱 스트림, 헤더 압축, 서버 푸시 등의 기능이 추가되었다.

 

 

 

OSI 7 Layer에서 바라 본 HTTP 프로토콜

OSI 계층 모델은 각 기능별 모듈화 된 기능을 계층별로 총 7계층으로 구성되어 있다.

그러나 이는 교육에 대한 적합한 모델로 실제 TCP/IP 계층 모델을 표준으로 하고 있다.

웹에서 사용되는 HTTP, HTTPS 프로토콜은 응용 계층에 해당 된다.

그림2 - OSI 7 Layer, TCP/IP 계층

 

 

 

TCP/IP 통신에 대한 이해

우리는 인터넷을 이용하여 TCP/IP 기반의 통신을 하며, 대부분의 네트워크 통신은 TCP/IP기반 통신을 근간으로 한다. 이때 통신을 하기 위한 중요한 정보가 있는데 IP와 port가 있다. IP를 통해 물리적 호스트 대상을 찾으며, port를 통해 논리적 대상을 찾는다.

그림3 - 브라우저와 서버의 통신

통신 순서

1. 3-way handshake

2. 데이터 전송 및 수신

 

 

연결 관리 방식

HTTP 프로토콜의 연결 관리 방식은 크게 두 가지로 나뉜다.

- 비 지속 연결(Non-Persistent Connection)

- 지속 연결(Persistent Connection)

 

HTTP 버전에 따라 사용 되는 연결 방식이 다른데, HTTP/0.9, HTTP/1.0까지는 비 지속 연결이다.

HTTP/1.0+, HTTP/1.1, HTTP/2.0은 지속 연결이다. HTTP/1.0+에서 Keep-Alive 커넥션을 통해 지속 연결을 지원하며, HTTP/1.1부터는 명세에서 빠지고 지속 연결을 기본으로 한다. 즉, Keep-Alive 사용없이 모든 연결을 지속 연결로 한다.

그림4 - HTTP 연결 관리 방식

 

비 지속 연결(Non-Persistent Connection)

비 지속 연결은 초기 HTTP에서 사용하던 방식으로 HTTP/1.0까지 사용되었다.

초기의 웹은 단순히 문서를 전달하는 방식으로 지속 연결이 필요하지 않았다.

때문에 한번의 요청과 응답 과정을 거치면 바로 연결을 끊어버렸다.

오늘날의 웹 문서의 경우 인터페이스를 구성하기 위해 많은 리소스가 필요한데 리소스 요청 시 마다 3-way handshake를 수행해야 하기 때문에 오늘날의 웹과 부적합한 연결 방식이다.

그림5 - 비 지속 연결

 

 

지속 연결(Persisten Connection)

웹의 기술 흐름에 맞게 HTTP/1.0+에서 Keep-Alive 연결을 지원한다.

헤더에 "Connection: Keep-Alive" 문구가 명시가 되어 있으면, 지속 연결을 사용한다는 것이다.

HTTP/1.1부터는 "Connection: Keep-Alive" 헤더 필요 없이 기본으로 지속 연결을 하게 된다.

단 한번의 3-Way Handshake 과정으로 여러 번의 요청과 응답 과정을 거치며, 비 지속 연결에 비해 시간이 확연히 단축된다는 것을 알 수 있다.

그림6 - 지속 연결

 

 

 

HTTP 메시지 - 메시지 구조

HTTP 메시지로 웹 브라우저가 요청할 때 보내는 메시지를 요청 메시지(Request Message)라고 한다.

웹 서버가 HTTP 요청 메시지를 받고 응답할 때 보내는 메시지를 응답 메시지(Response Message)라고 한다.

메시지 구조는 시작줄, 메시지 헤더, 메시지 바디로 나뉜다.

각 행은 개행 문자(\r\n)을 기준으로 분류 한다.

그림7 - HTTP 메시지 구조

 

요청 메시지 시작줄 → 무엇을 요청하는지

응답 메시지 시작줄 → 요청에 대한 결과값

 

요청 메시지 헤더 → 요청의 상세 속성 정보(Host, Content Type, Cookie 등)

응답 메시지 헤더 → 응답의 상세 속성 정보

 

요청 메시지 바디 → 데이터를 실어서 전송(POST 메소드)

응답 메시지 바디 → 요청한 데이터를 실어서 응답

 

 

HTTP 메시지 - 개행 문자

개행 문자는 텍스트의 한 줄이 끝남을 표시하는 문자 또는 문자열이다.

새 줄 문자 혹은 줄 바꿈 문자라고도 한다.

OS 혹은 프로토콜마다 개행 문자의 ASCII 값이 다른데 HTTP 와 같은 인터넷 프로토콜의 경우 ASCII의 CR + LF를 개행 문자로 사용하도록 규정하고 있다.

CR = Carriage Return = \r (문자) = 0x0D (Hex)

LF = Line Feed = \n (문자) = 0x0A (Hex)

 

HTTP 통신 상에서 이러한 개행 문자로 라인을 구분하여 데이터 식별을 하게 된다.

개행 문자를 두 번 사용하여 메시지 헤더의 끝을 알린다. = \r\n\r\n = 한 줄 띄기

그림8 - HTTP 메시지 개행 문자

 

 

 

 

HTTP 메시지 - 요청 메시지(Request Message)

메시지 시작줄 = 요청 라인으로 메소드, 요청 URL, 버전을 포함

메시지 헤더 = 요청의 속성, 추가 정보들을 포함

메시지 바디 = 엔티티 바디가 들어감, 메시지의 데이터가 들어가는 부분으로 데이터 전송을 목적으로 설계됨.

 

엔티티 바디는 메소드에 따라 존재 유/무가 결정된다. → GET or POST

그림9 - HTTP 요청 메시지 구조

 

 

HTTP 메시지 - 응답 메시지(Response Message)

메시지의 시작줄 = 상태 라인으로 버전, 상태 코드, 응답 문구를 포함

메시지 헤더 = 응답의 속성, 추가 정보들이 포함

메시지 바디 = 엔티티 바디가 들어감, 메시지의 데이터가 들어가는 부분으로 데이터 전송을 목적으로 설계됨.

 

엔티티 바디는 메소드에 따라 존재 유/무가 결정된다. → GET or POST

그림10 - HTTP 응답 메시지 구조

 

 

 

HTTP 메소드 - GET/POST 메소드

HTTP 메소드에는 여러가지가 있으나, GET/POST 메소드가 일반적으로 웹 통신 시 가장 많이 사용된다.

GET/POST 메소드는 클라이언트에서 서버에 데이터를 전달할 때 사용되는 방식으로 GET/POST 메소드 별로 차이가 있다.

 

GET 방식: URL에 데이터를 실어서 전송한다. → 자원을 요청

POST 방식: 메시지 바디에 데이터를 실어서 전송한다. → 서버에 데이터 전달, Action

POST 방식은 Content-Type 헤더가 없으면 메시지 바디값을 해석 할 수 없다.

그림11 - GET/POST 메소드 차이

 

 

 

 

HTTP 상태코드

클라이언트가 요청을 할 경우 서버는 요청에 대한 상세 결과를 알려준다 = 상태 코드(Status Code)

상태 코드는 3자리 숫자로 구성되어 있으며, 뒤에 응답 문구가 붙는다. 응답 문구는 상태 코드에 대한 설명이다.

그림12 - HTTP 상태 코드

 

 

HTTP 상태코드 - 상태코드의 에러 페이지에 다른 웹 서버 식별

상태 코드에 따라 출력되는 에러 페이지는 서버 별로 다르기 때문에 이를 통해 사용되는 웹 서버 혹은 WAS를 식별 할 수 있다. 

그림13 - 웹 서버 별로 다른 에러 페이지

 

 

 

HTTP 메시지 헤더

메시지 헤더는 메시지를 구성하는 요소로 클라이언트와 서버가 무엇을 할지 결정하고 처리하기 위한 정보들이 들어있으며, 요청 메시지와 응답 메시지에는 반드시 메시지 헤더가 포함이 되어 있다.

헤더의 종류에는 크게 5가지로 분류가 되며, 확장 헤더는 HTTP 명세에는 추가되지 않은 비 표준 헤더이다.

HTTP/1.1에 정의되어 있는 헤더는 총 47가지이다.

그림14 - 메시지 헤더 종류

 

 

 

 

 

 

 

 

 

 

 

참고

https://www.inflearn.com/course/%EC%9B%B9-%EA%B8%B0%EC%88%A0-%EA%B8%B0%EC%B4%88