HTTP는 무엇일까요?

SG Jang·2021년 2월 1일

인터넷(Internet)

목록 보기

2/2

이번 시간에는 "HTTP는 무엇일까요?"에 대해 다뤄보겠습니다.

HTTP란?

HTTP란 HyperText Transfer Protocol의 약자로, 글자 그대로 직역해보려고 한다.
나무위키를 찾아보면 HyperText는 "기존의 책과 같은 선형적인 텍스트가 아니라, 월드 와이드 웹(WWW)에서 사용되는 하이퍼링크와 하이퍼텍스트를 통해서 이어지는 비선형적인 텍스트가 신개념이라는 의미에서 만들어진 용어이다. 굳이 번역하자면, 초월문서라고 할 수 있겠다."라고 적혀있다.
비선형적인텍스트? 초월문서? 다소 생소하고 낮선 용어로 이루어져 있다.
우리는 글을 읽을때 책의 목차를 보고 '순차적'으로 원하는 내용을 찾는다.
그렇다면 아래 링크를 클릭해보자.
>>여기<<
위 링크를 눌러보면 알겠지만 하이퍼텍스트는 책과 다르게 원하는 정보에 '비순차적', '비선형적'으로 접근할 수 있다. 즉, 하이퍼텍스트는 컴퓨터화면이나 전자기기에서 볼 수 있는 텍스트(데이터)이며, 다른 텍스트와 연결될 수 있는 주소를 참조하고 있다. 여기에 덧붙여서 Transfer는 전송이고, Protocol은 통신규약의 의미를 갖는다.
이를 종합해보면 HTTP는
= HyperText Transfer Protocol
= 초월문서를 전송하는 통신규약
= 컴퓨터화면이나 전자기기에서 볼 수 있는 텍스트(데이터)를 주고 받는 통신규약
= 다른텍스트와 연결될 수 있는 주소를 참조하고 화면이나 전자기기에서 볼 수 있는 텍스트(데이터)를 주고 받는 통신규약으로 이해할 수 있다.

그러면 이러한 통신규약은 어떻게 사용되는걸까?
사용자가 할 줄 아는 것은 주소창에 "www.naver.com"과 같은 URI를 입력하는 것이 전부이다.
이때 사용자가 브라우저 주소창에 URI를 입력하면 그 데이터를 요청하고 보여주는 것은 브라우저이며, 데이터를 요청받아 응답해주는 것은 웹 서버의 역할이다.
HTTP는 바로 그 브라우저(클라이언트)와 서버 간의 규칙을 의미한다. 이때 클라이언트가 웹서버로 데이터를 요청하는 것을 HTTP Request라 하고, 웹서버가 클라이언트에게 데이터로 응답하는 것을 HTTP Response라고 한다.

TCP/IP 4계층에서 동작하는 HTTP

HTTP에 대해 공부하고자 여러 정보를 찾아본 사람들은 HTTP는 TCP/IP에 기반한다는 말을 들어본 적이 있을 것이다. TCP/IP는 무엇일까? 단순하게 얘기해보자면 OSI 7계층이 시스템 들의 연결이라면, TCP/IP 4계층은 웹서비스에 좀 더 집중한 모델이라고 생각하면 된다.
(TCP/IP 4계층과 OSI 7계층을 비교한 글)

각 계층에 대해 설명하자면 이렇다.

응용계층(Application): OSI 7계층의 세션 계층, 표현 계층, 응용 계층에 해당한다. 응용프로그램들이 네트워크서비스, 메일서비스,웹서비스 등을 할 수 있도록 표준적인 인터페이스를 제공한다.
주요프로토콜: HTTP, FTP, SSH
전송계층(Transport): OSI 7계층의 전송 계층에 해당한다. 네트워크 양단의 송수신 호스트 사이에서 신뢰성 있는 전송기능을 제공하고, 시스템의 논리주소와 포트를 가지고 있어서 각 상위 계층의 프로세스를 연결해서 통신한다. 정확한 패킷의 전송을 보장하는 TCP와 정확한 전송을 보장하지 않는 UDP 프로토콜을 이용하며, 데이터의 정확한 전송보다 빠른 속도의 전송이 필요한 멀티미디어 통신에서 UDP를 사용하면 TCP보다 유용하다.
주요프로토콜: TCP, UDP
인터넷계층(Internet): OSI 7계층의 네트워크 계층에 해당한다. 상위 트랜스포트 계층으로부터 받은 데이터에 IP패킷 헤더를 붙여 IP패킷을 만들고 이를 전송하는 기능과 라우팅 기능을 담당한다.
주요프로토콜: IP, ARP, RARP
네트워크접근계층(Network Access): OSI 7계층의 물리계층과 데이터 링크 계층에 해당한다. OS의 네트워크 카드와 디바이스 드라이버 등과 같이 하드웨어적인 요소와 관련되 는 모든 것을 지원하는 계층으로 물리적인 주소로 MAC을 사용한다.
주요프로토콜: Ethernet

TCP/IP 4계층에 대해 알아봤으나 아직 HTTP가 TCP/IP에 기반하여 동작하는 과정은 감이 안올거라 생각한다. 이제 사용자가 URI를 입력하여 클라이언트와 서버사이에서 어떠한 일련의 과정을 거치는지 설명하고자 한다.

(HTTP Request가 이뤄지는 일련의 과정)
1. 사용자가 브라우저(클라이언트) 주소창에 URI를 입력하여 데이터를 요청하면 ISP(인터넷서비스제공업체)의 DNS 해석기로 IP주소를 반환받아 이 IP주소를 웹브라우저(클라이언트)에게 반환한다.

2. 응용계층에서 HTTP 메시지를 작성합니다.
3. 전송계층에서 HTTP 메시지를 패킷으로 분해합니다.
4. 인터넷계층에서 전송위치를 확인하고
5. 네트워크접근계층에서 네트워크를 통하여 전송합니다.
6. 그 이후는 위 과정의 역순으로 진행하여 처리한다.

(HTTP Response는 위 과정의 반대라고 생각하면 된다.)

HTTP통신의 특성

비연결성(Connectionless)
비연결성은 클라이언트와 서버가 한 번 연결을 맺은 후, 클라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어 버리는 성질을 말합니다. 이러한 연결 방식은 클라이언트가 요청을 보내는 경우에만 서버가 응답하는 단방향적 통신으로 서버가 클라이언트로 요청을 보낼수는 없다.
좀 더 이해를 돕기위해 설명하자면, 지금 당신이 읽고 있는 이 글은 링크를 클릭하는 순간 클라이언트와 서버가 연결을 맺고 내용을 주고받은뒤 바로 연결이 종료된다. 즉, 당신이 보고있는 이 페이지는 이미 연결이 종료된 페이지를 보고있는 것이다. 만약 새로고침을 한다면 다시 한번 클라이언트와 서버가 연결되고 연결이 끊긴 페이지를 보게될 것이다.
이러한 HTTP통신은 필요한 경우에만 서버로 접근하는 콘텐츠 위주의 데이터를 사용할 때 용이하며, 실시간으로 연결이 유지되는 Socket통신과 대조된다.
- 장점
  HTTP 프로토콜은 왜 한 번 맺은 연결을 끊어버리는걸까? HTTP는 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되었습니다. 만약 서버에서 다수의 클라이언트와 연결을 계속 유지해야 한다면, 이에 따른 많은 리소스가 발생하게 됩니다. 따라서 연결을 유지하기 위한 리소스를 줄이면 더 많은 연결을 할 수 있으므로 비연결적인 특징을 갖습니다.
- 단점
  서버는 클라이언트를 기억하고 있지 않으므로 동일한 클라이언트의 모든 요청에 대해, 매번 새로운 연결을 시도/해제의 과정을 거쳐야하므로 연결/해제에 대한 오버헤드가 발생한다는 단점이 있습니다.
- KeppAlive
  단점에 대한 해결책으로 오버헤드를 줄이기 위해 HTTP의 KeepAlive 속성을 사용할 수 있습니다. KeepAlive는 지정된 시간동안 서버와 클라이언트 사이에서 패킷 교환이 없을 경우, 상대방의 안부를 묻기위해 패킷을 주기적으로 보내는것을 말합니다. 이 때 패킷에 반응이 없으면 접속을 끊게 됩니다. 주기적으로 클라이언트의 상태를 체크한다는 것으로 미루어보아 KeepAlive 역시 완벽한 해결책은 아닙니다. KeepAlive 속성이 On 상태라해도, 서버가 바쁜 환경에서는 프로세스 수가 기하급수적으로 늘어나기 때문에 KeepAlive로 상태를 유지하기 위한 메모리를 많이 사용하게 되므로 주의해야 합니다.
무상태(Stateless)
Connectionless로 인해 서버는 클라이언트를 식별할 수가 없는데, 이를 Stateless라고 합니다. 클라이언트의 상태를 모른다는 것은 아래 과정에서 로그인마다 새로운 인증을 거쳐야하는 번거로움이 생긴다.
[쇼핑몰에 접속 -> 로그인 -> 상품 클릭 -> 상세화면으로 이동 -> 로그인 -> 주문 -> 로그인 -> ....]
- 상태를 기억하는 방법(쿠키)
  서비스를 운영하려면 서버가 클라이언트를 기억해야 할 경우가 많이 있는데, 클라이언트를 기억할 수 있는 방법은 없을까요? HTTP는 이러한 문제점을 해결하기 위해 브라우저 단에서 쿠키라는 것을 저장하여 서버가 클라이언트를 식별할 수 있도록 한다. (HTTP 헤더: set-cookie)
- 상태를 기억하는 방법(세션)
  쿠키는 사용자 정보가 브라우저에 저장되기 때문에 공격자로부터 위변조의 가능성이 높아 보안에 취약합니다. 이와 달리 세션은 브라우저가 아닌 서버단에서 사용자 정보를 저장하는 구조입니다. 따라서 쿠키보다는 안전하다고 할 수 있습니다. 그런데 세션 정보도 중간에 탈취 당할 수 있기 때문에 보안에 완벽하다고 할 수 없습니다. 또한 세션을 사용하면 서버에 사용자 정보를 저장하므로, 서버의 메모리를 차지하게 되고, 만약 동시 접속자 수가 많은 서비스일 경우에는 서버 과부화의 원인이 됩니다.
- 상태를 기억하는 방법(토큰을 사용하는 OAuth, JWT)
  쿠키와 세션의 문제점들을 보완하기 위해 토큰(Token)기반의 인증 방식이 도입되었습니다. 토큰 기반의 인증 방식의 핵심은 보호할 데이터를 토큰으로 치환하여 원본 데이터 대신 토큰을 사용하는 기술입니다. 그래서 중간에 공격자로부터 토큰이 탈취당하더라도 데이터에 대한 정보를 알 수 없으므로, 보안성이 높은 기술이라 할 수 있다. 대표적으로는 OAuth와 JWT이 있습니다. 그런데 꼭 토큰 기반의 인증이 좋은것은 아니므로 서비스에 따라 기술의 특징을 잘 이해하여 쿠키, 세션, OAuth, JWT 등을 상황에 맞게 적절히 사용하는 것이 좋다.

HTTP메시지 구조

명령프롬프트에서 curl -v URI를 입력하면 HTTP의 자세한 동작과정을 알 수 있다. 우리가 자주 사용하는 "www.naver.com"라는 URI주소를 활용하여 HTTP메시지에 대해 공부해보자.

HTTP메시지에서 HTTP Request와 HTTP Response의 구조는 서로 닮았으며, 그 구조는 다음과 같다.
HTTP메시지 = 헤드(head) [시작줄(start-line) + HTTP헤더] + 빈줄(blank line) + 본문(body) [HTTP메시지의 페이로드]

시작줄: 실행되어야 할 요청, 또는 요청 수행에 대한 성공 또는 실패가 기록되며 항상 한 줄로 끝난다.
HTTP헤더: 요청에 대한 설명, 메시지 본문에 대한 설명
빈줄: 요청에 대한 모든 메타 정보가 전송되었음을 알림
요청과 관련된 내용(HTML 폼 콘텐츠 등)이 옵션으로 들어가거나, 응답과 관련된 문서(document)가 들어갑니다. 본문의 존재 유무 및 크기는 첫 줄과 HTTP 헤더에 명시됩니다.

HTTP Request
시작줄(start-line): GET / HTTP/1.1
(HTTP메소드/ 요청타겟(주로 URI)/HTTP버전)
두번째로 오는 요청 타겟은 주로 URL, 또는 프로토콜, 포트, 도메인의 절대 경로로 나타낼 수도 있으며 이들은 요청 컨텍스트에 의해 특정지어 집니다. 요청 타겟 포맷은 HTTP 메소드에 따라 달라집니다. 포맷에는 다음과 같은 것들이 있습니다.
1. origin 형식: 끝에 '?'와 쿼리 문자열이 붙는 절대 경로입니다. 이는 가장 일반적인 형식이며, GET, POST, HEAD, OPTIONS 메서드와 함께 사용합니다.
POST / HTTP 1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0
2. absolute 형식: 완전한 URL 형식입니다. 프록시에 연결하는 경우 대부분 GET과 함께 사용됩니다.
GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
3. authority 형식: 도메인 이름 및 옵션 포트(':'가 앞에 붙습니다)로 이루어진 URL의 authority component 입니다. HTTP 터널을 구축하는 경우에만 CONNECT와 함께 사용할 수 있습니다.
CONNECT developer.mozilla.org:80 HTTP/1.1
4. asterisk 형식: OPTIONS와 함께 별표('*') 하나로 간단하게 서버 전체를 나타냅니다.
OPTIONS * HTTP/1.1
HTTP헤더:
Host: www.naver.com
User-Agent: curl/7.55.1
Accept: */*
요청에 들어가는 HTTP 헤더는 HTTP 헤더의 기본 구조를 따릅니다. 대소문자 구분없는 문자열 다음에 콜론(':')이 붙으며, 그 뒤에 오는 값은 헤더에 따라 달라집니다. 헤더는 값까지 포함해 한 줄로 구성되지만 꽤 길어질 수 있습니다. 다양한 종류의 요청 헤더가 있는데, 이들은 다음과 같이 몇몇 그룹으로 나눌 수 있습니다.
1. General 헤더: Via와 같은 헤더는 메시지 전체에 적용됩니다.
2. Request 헤더: User-Agent, Accept-Type와 같은 헤더는 요청의 내용을 좀 더 구체화 시키고(Accept-Language), 컨텍스를 제공하기도 하며(Referer), 조건에 따른 제약 사항을 가하기도 하면서(If-None) 요청 내용을 수정합니다.
3. Entity 헤더: Content-Length와 같은 헤더는 요청 본문에 적용됩니다. 당연히 요청 내에 본문이 없는 경우 entity 헤더는 전송되지 않습니다.
빈줄
요청에 대한 모든 메타 정보가 전송되었음을 알림

본문
본문은 요청의 마지막 부분에 들어갑니다. 모든 요청에 본문이 들어가지는 않습니다. GET, HEAD, DELETE , OPTIONS처럼 리소스를 가져오는 요청은 보통 본문이 필요가 없습니다. 일부 요청은 업데이트를 하기 위해 서버에 데이터를 전송합니다. 보통 (HTML 폼 데이터를 포함하는) POST 요청일 경우에 그렇습니다. 본문은 두가지 종류로 나뉩니다.

단일-리소스 본문(single-resource bodies): 헤더 두 개(Content-Type와 Content-Length)로 정의된 단일 파일로 구성됩니다.

다중-리소스 본문(multiple-resource bodies): 멀티파트 본문으로 구성되는 다중 리소스 본문에서는 파트마다 다른 정보를 지니게 됩니다. 보통 HTML 폼과 관련이 있습니다.

HTTP Response
시작줄(status-line): HTTP/1.1 302 Moved Temporarily
(프로토콜버전(보통 HTTP/1.1)/ 상태코드 상태텍스트)

상태코드: 요청의 성공 여부를 나타냅니다. 200, 404 혹은 302입니다.

상태텍스트: 짧고 간결하게 상태 코드에 대한 설명을 글로 나타내어 사람들이 HTTP 메시지를 이해할 때 도움이 됩니다.
HTTP헤더:
HTTP/1.1 302 Moved Temporarily
Server: NWS
Date: Tue, 02 Feb 2021 03:34:17 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Location: https://www.naver.com/
Vary: Accept-Encoding,User-Agent
응답에 들어가는 HTTP 헤더는 다른 헤더와 동일한 구조를 따릅니다. 대소문자를 구분하지 않는 문자열 다음에 콜론(':')이 오며, 그 뒤에 오는 값은 구조가 헤더에 따라 달라집니다. 헤더는 값을 포함해 전체를 한 줄로 표시합니다. 다양한 종류의 응답 헤더가 있는데, 이들은 다음과 같이 몇몇 그룹으로 나눌 수 있습니다.
1. General 헤더: Via와 같은 헤더는 메시지 전체에 적용됩니다.
2. Response 헤더: Vary와 Accept-Ranges와 같은 헤더는 상태 줄에 미처 들어가지 못했던 서버에 대한 추가 정보를 제공합니다.
3. Entity 헤더: Content-Length와 같은 헤더는 요청 본문에 적용됩니다. 당연히 요청 내에 본문이 없는 경우 entity 헤더는 전송되지 않습니다.
빈줄
요청에 대한 모든 메타 정보가 전송되었음을 알림

본문
본문은 응답의 마지막 부분에 들어갑니다. 모든 응답에 본문이 들어가지는 않습니다. 201, 204과 같은 상태 코드를 가진 응답에는 보통 본문이 없습니다. 본문은 세가지 종류로 나뉩니다.
1. 이미 길이가 알려진 단일 파일로 구성된 단일-리소스 본문: 헤더 두개(Content-Type와 Content-Length)로 정의 합니다.
2. 길이를 모르는 단일 파일로 구성된 단일-리소스 본문: Transfer-Encoding가 chunked로 설정되어 있으며, 파일은 청크로 나뉘어 인코딩 되어 있습니다.
3. 서로 다른 정보를 담고 있는 멀티파트로 이루어진 다중 리소스 본문: 이 경우는 상대적으로 위의 두 경우에 비해 보기 힘듭니다.

HTTP Method

HTTP메소드는 서버가 수행해야 할 동작을 나타낸다.

GET
GET 메서드는 특정 리소스의 표시를 요청합니다. GET을 사용하는 요청은 오직 데이터를 받기만 합니다.
HEAD
HEAD 메서드는 GET 메서드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않습니다.
POST
POST 메서드는 특정 리소스에 엔티티를 제출할 때 쓰입니다. 이는 종종 서버의 상태의 변화나 부작용을 일으킵니다.
PUT
PUT 메서드는 목적 리소스 모든 현재 표시를 요청 payload로 바꿉니다.
DELETE
DELETE 메서드는 특정 리소스를 삭제합니다.
CONNECT
CONNECT 메서드는 목적 리소스로 식별되는 서버로의 터널을 맺습니다.
OPTIONS
OPTIONS 메서드는 목적 리소스의 통신을 설정하는 데 쓰입니다.
TRACE
TRACE 메서드는 목적 리소스의 경로를 따라 메시지 loop-back 테스트를 합니다.
PATCH
PATCH 메서드는 리소스의 부분만을 수정하는 데 쓰입니다.

HTTP 응답코드

웹 서비스를 개발하면서 자주 접하게 되는 응답코드를 모아보았다.

100대 코드: 정보전달
200대 코드: 성공응답
- 200: OK, 정상
- 204: No Content, 보통 특정내용을 삭제시 해당 응답코드를 응답합니다.
- 206: Range, 헤더를 지정한 요청을 응답할 때 사용합니다.
300대 코드: Redirection, request완료를 위해 추가 동작이 필요합니다
- 301: Moved Permanently, 영구적으로 URI 변경을 의미
- 302: Found, 일시적인 URI 이동을 의미
- 304: Not Modified, 변경 없음
- 307: Temporary Redirect, 임시적인 redirect
400대 코드: 클라이언트의 에러
- 400: Bad Request, 잘못된 요청
- 403: Forbidden, 접근권한없음
- 404: Not Found, 요청 내용이 없거나 찾을 수 없음
- 408: Request Timeout, 요청 타임아웃
500번대 코드: 서버의 에러
- 500: Internal Server Error, 서버에러, 로직에러 발생시 자주 등장합니다.
  503: Service Unavailable, 서버 한계 초과등 오류

HTTPS는 무엇일까?

우리는 오늘 HTTP에 대해 공부하였다. 그런데 사실 주소창을 사용해본 사용자라면 HTTP보다는 HTTPS가 좀 더 익숙할 것이다.

HTTPS는 HyperText Transfer Protocol Secure의 약자로 HTTP의 확장 버전이다. ‘Secure’이란 말에서 유추할 수 있듯 HTTP를 통한 데이터의 보안을 위한 조치가 추가되었고, 이때 사용되는 것이 SSL(Secure Sockets Layer)프로토콜이다. HTTP와 HTTPS의 차이점은 SSL을 사용해 데이터를 한쪽에서 다른 한 쪽으로 안전하게 보낼 수 있는지 여부이다.

위 그림에서 확인할 수 있듯, HTTP를 통해 주고받는 데이터는 평문(plain text)으로 되어있어서 중간에서 데이터를 탈취하는 누구라도 쉽게 알아볼 수 있다.
반면 HTTPS는 웹서버와 브라우저간 데이터를 암호화된 상태(encrypted text)로 주고받기 때문에 비밀번호 등 민감한 정보들이 탈취되어 악용되는 것을 방지하고, 누군가 끼어들어 데이터를 가져가도 쓸 도리가 없다.
크롬브라우저는 사용자가 HTTPS가 아닌 HTTP로 접속하면 '안전하지 않음'이라는 문구로 사용자에게 경고메시지를 노출하고 있다.

참고자료

SG Jang

이전 포스트