웹의 핵심 기술 HTTP 프로토콜

개념

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

버전

• 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 Connection)을 지원하였으나, HTTP/1.1부터 Keep-Alive는 명세에서 빠지고 기본으로 지속 연결이 활성화 되어 있다.
  • 모든 요청이 끝나면 "Connection: close" 헤더를 통해 연결 종료를 알린다.
  • 또한, 기존이 "GET, POST, HEAD" 3가지 뿐이었던 메서드가 "OPTIONS, PUT, DELETE" 등 많은 메서드가 추가되었다.
• HTTP/2.0
  • HTTP의 성능 문제는 여전히 문젯거리로 존재하였다.
  • 특히 요즘 웹의 경우 하나의 웹 페이지를 보기 위해서 수십개의 요청을 보내야 정상적으로 페이지를 볼 수 있다.
  • 그리하여 이런 문제를 해결할 수 있는 HTTP/2.0이 등장하였다.
  • HTTP/2.0은 성능 향상에 초점을 둔 프로토콜로 멀티플렉싱 스트림, 헤더 압축, 서버 푸시 등의 기능이 추가되었다.
• 2015년 HTTP/2.0을 공식 발표하였다. 아직 대부분 HTTP/1.1을 사용중이며, Google 계열 사이트는 HTTP/2.0을 지원하고 있으며, 점차 HTTP/2.0을 지원하는 추세이다. 그러나 국내 사이트들은 아직 HTTP/1.1만 지원하고 있다.(Google에서 3.0을 개발하고 있다는 얘기가 있는 것 같기도 하고~...아닌 것 같기도 하고~...)

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

• OSI 계층 모델은 각 기능별 모듈화 된 기능을 계층별로 총 7계층으로 구성되어 있다.
• 그러나 이는 교육에 대한 적합한 모델로 실제 TCP/IP 계층 모델을 표준으로 하고 있다.
• 웹에서 사용되는 HTTP, HTTPS 프로토콜은 응용 계층에 해당된다.

OSI 계층 모델	TCP/IP 계층 모델	계층별 프로토콜
응용 계층 Application Layer	응용 계층 Application Layer	HTTP, HTTPS, SMTP, FTP, TELNET, SSH, DNS
표현 계층 Presentation Layer
세션 계층 Session Layer
전송 계층 Transport Layer	전송 계층 Transport Layer	TCP, UDP
네트워크 계층 Network Layer	인터넷 계층 Internet Layer	IP, ICMP, ARP
데이터링크 계층 Data-Link Layer	네트워크 액세스 계층 Network Access Layer	MAC
물리 계층 Pysical Layer

 

TCP/IP 통신에 대한 이해

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

통신 방식에 대한 간단한 설명

1. 처음에 최초에는 3-way hand shake를 진행하게 된다.
2. 이것은 서로가 3번의 통신을 주고 받는 것을 의미한다.
3. 이 3-way handshake는 TCP 프로토콜에 의해서 이루어지는 연결 방식이다.
4. 그래서 TCP는 3-way hand shake 때문에 종단 간의 신뢰성 있는 정보 전송을 제공해 줄 수 있는 프로토콜이라고 하는 것이다.
5. 그리하여 3-way hand shake이 진행이 되고 이후에 서로 통신이 본격적인 HTTP 전송 및 데이터가 전송이 되는 것이다.
6. 먼저 3-way hand shake를 진행한 다음, 그 다음에 이 데이터를 주고 받게 된다.
7. 우선 여기서는 IP와 PORT가 있어야 하는데, 간단하게 예시를 들어 설명해 보겠다.
8. 만약 주소가 "경기도 고양시 일산동구 네모네모로 77 네카라쿠배아파트 123동 456호"라고 한다면, 여기서 IP는 "경기도 고양시 일산동구 네모네모로 77 네카라쿠배아파트 123동"이 되고 PORT는 "456호"는 의미한다고 보면 된다.
9. 위의 이 개념으로 본다면 먼저 웹 브라우저에서 최초의 통신을 하게 된다.
10. 그리고 url창을 통해 www.naver.com 을 치면 통신을 하기 위해 임의의 포트를 할당하게 된다.
11. 그 다음 이제 목적지 IP가 세팅이 되며,  목적지 PORT도 세팅이 된다. 보통 이 경우에는 기본적으로 80포트가 세팅된다.
12. 이렇게 되면 출발지의 IP와 PORT,  목적지의 IP와 PORT가 세팅이 되고 이렇게 되어야만 요청과 응답을 받을 수 있다.
13. 그렇게 하여 IP를 통해 최종 서버까지 찾아 들어가고 서비스 중인 80포트를 통해서 데이터를 받게 되고 어플리케이션 단에서 처리할 수 있다.
14. 그리고 다시 응답을 전송해주게 된다. 이렇게 통신 원리가 이루어진다고 보면 되겠다.

연결 관리 방식

• 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부터는 명세에서 빠지고 지속 연결을 기본으로 한다.
• 즉, Kepp-Alive 사용 없이 모든 연결을 지속 연결로 한다.
• 종종 HTTP/1.1부터 Keep-Alive를 지원한다고 하는데 그것을 잘못된 내용이고 HTTP/1.0+에서부터 지원하게 된 것이며, HTTP/1.1에서 Keep-Alive는 기본 사양이다.

연결 관리 방식 - 비 지속 연결(Non-Persistent Connection)

• 비 지속 연결은 초기 HTTP에서 사용하던 방식으로 HTTP/1.0까지 사용되었다.
• 초기의 웹은 단순히 문서를 전달하는 방식으로 지속 연결이 필요하지 않았다.
• 때문에 한번의 요청과 응답 과정을 거치면 바로 연결을 끊어버렸다.
• 오늘 날의 웹 문서의 경우 인터페이스를 구성하기 위해 많은 리소스가 필요한데 리소스 요청 시마다 3-way hand shake를 수행해야 하기 때문에 오늘날의 웹과 부적합한 연결 방식이다.

연결 관리 방식 - 지속 연결(Persistent Connection)

• 웹의 기술 흐름에 맞게 HTTP/1.0+에서 Keep-Alive연결을 지원한다.
• 헤더에 "Connection: Keep-Alive"란 것이 명시가 되어 있으면, 지속 연결을 사용한다는 것이다.
• HTTP/1.1부터는 "Connection: Keep-Alive" 헤더 필요 없이 기본으로 지속 연결을 사용한다는 것이다.
• 단 한번의 3-way handshake 과정으로 여러 번의 요청과 응답 과정을 거치며, 비 지속 연결에 비해 시간이 단축된다는 것을 알 수 있다.

HTTP 메세지 - 메세지 구조

• 웹 브라우저가 요청할 때 보내는 메세지를 요청 메세지(Request Message)라고 부른다.
• 웹 서버가 HTTP 요청 메세지를 받고 응답할 때 보내는 메세지를 응답 메세지(Response Message)라고 부른다.
• 메세지 구조는 시작줄, 메세지 헤더, 메세지 바디로 나뉜다.
• 각 행은 개행문자(\r\n)를 기준으로 분류를 한다.

HTTP 메세지 - 개행문자

• 개행 문자는 텍스트의 한 줄이 끝남을 표시하는 문자 또는 문자열이다.
• 새 줄 문자 혹은 줄 바꿈 문자라고도 한다.
• OS 혹은 프로토콜마다 개행문자의 ASCII 값이 다른데 HTTP와 같은 인터넷 프로토콜의 경우 ASCII의 CR+LF를 개행 문자로 사용하도록 규정하고 있다.
• CR은 캐리지 리턴(Carriage Return)으로 문자는 "\r", Hex 값으로는 "0x0D"으로 표현된다.
• LF는 라인 피드(Line Feed)로 문자는 "\n", Hex값으로는 "0x0A"로 표현된다.
• HTTP 통신 상에서 이러한 개행 문자로 라인을 구부한여 데이터 식별을 하게 된다.
• 메세지 헤더는 꼭 한개일 필요는 없고 여러 개가 들어올 수 있다.
• 만약 개행문자가 두개가 연속으로 들어오는 경우에는 그 시점으로 뒤에 문자열은 메세지 바디라고 보면 된다.

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

• 요청 메세지의 시작줄은 요청 라인으로 메서드, 요청 URL, 버전이 들어가며, 메세지 헤더는 요청의 속성과 추가 정보들이 포함되어 있다.
• 메세지 바디 부분은 엔티티 바디가 들어가며, 메세지의 데이터가 들어가는 부분으로 데이터 수송을 목적으로 설계하였다.
• 여기서 엔티티 바디는 메서드에 따라 존재 유/무가 결정되는 선택적인 부분이다.

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

• 응답 메세지의 시작줄은 상태 라인으로 버전, 상태코드, 응답 문구가 들어가며, 메세지 헤더는 응답의 속성과 추가 정보들이 포함되어 있다.
• 메세지 바디 부분은 엔티티 바디가 들어가며, 메세지의 데이터가 들어가는 부분으로 데이터 수송을 목적으로 설계하였다.
• 여기서 엔티티 바디는 메서드에 따라 존재 유/무가 결정되는 선택적인 부분이다.

HTTP 메서드 - GET/POST 메서드

• HTTP 메서드에는 여러가지가 있으나, GET/POST 메서드가 일반적으로 웹 통신시 가장 많이 사용되는 메서드이다.
• GET/POST 메서드는 클라이언트에서 서버에 데이터를 전달할 때 사용되는 방식으로 GET/POST 메서드 별로 차이가 있다.

HTTP 상태 코드

• 클라이언트가 요청을 할 경우 서버는 요청에 대한 상세 결과를 알려 주는데 그것이 상태 코드(Status Code)이다
• 상태 코드는 3자리 숫자로 구성되어 있으며, 뒤에 응답 문구가 붙는다.
• 응답 문구는 상태 코드에 대한 설명이다.
• 상태코드는 외울 필요까지는 없지만, 자주 반환되는 몇개만 알고 있으면 된다.

분류		전체 범위	정의된 범위
1XX	정보	100 ~ 199	100 ~ 101
2XX	성공	200 ~ 299	200 ~ 206
3XX	리다이렉션	300 ~ 399	300 ~ 305
4XX	클라이언트 에러	400 ~ 499	400 ~ 415
5XX	서버 에러	500 ~ 599	500 ~ 505

**전체 범위 내에서 정의된 범위만 사용이 되며, HTTP 버전이 업그레이드 됨에 따라 정의될 코드가 늘어날 예정이다.

코드	응답 문구	내용
200	OK	정상적으로 처리 됨
302	Found	다른 페이지로 이동
304	Not Modified	수정되지 않음
400	Bad Request	클라이언트 요청 에러
403	Forbidden	접근 권한 없음
404	Not Found	존재하지 않음
500	Internal Server Error	서버 측 에러

 

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

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

HTTP 메세지 헤더

• 메세지 헤더는 메세지를 구성하는 요소로 클라이언트와 서버가 무엇을 알지 결정하고 처리하기 위한 정보들이 들어 있다.
• 요청 메세지와 응답 메세지에는 반드시 메세지 헤더가 포함이 되어 있다.
• 헤더의 종류에는 크게 5가지로 분류가 되며, 확장 헤더는 HTTP 명세에는 추가되지 않은 비 표준 헤더이다.
• HTTP/1.1 에 정의되어 있는 헤더는 총 47가지이다.

종류

일반 헤더(General Header)

요청 헤더(Request Header)

응답 헤더(Response Header)

엔티티 헤더(Entity Header)

확장 헤더(Extension Header)