HTTP는 무엇일까요?

백엔드

HTTP는 무엇일까요?

배게 2022. 8. 21. 04:14

728x90

HTTP 개요

HTTP는 HTML문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다.
HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 구조의 프로토콜이다.

HTTP는 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상으로 무엇이든 사용할 수 있으나 TCP혹은 암호화된 TCP연결인 TLS를 통해 전송된다.

HTTP 특징

1. 클라이언트 서버 구조이다. 클라이언트는 서버에 요청(Request)를 보내고 응답(Response)를 기대한다. 이로 인해 클라이언트와 서버의 관심사를 분리할 수 있고 각각을 따로 개발할 수 있게 된다.

2. 무상태(Stateless) 프로토콜이다.

간단한 예시로 특징을 보기위해 고객과 점원의 예시를 살펴보자.

// Stateful
고객: 이 노트북이 얼마인가요?
점원: 100만원 입니다. (노트북 상태 유지)
  
고객: 2개 구매하겠습니다.
점원: 결제는 신용카드와 현금중에 어떤 걸로 도와드릴까요? (노트북, 2개 상태 유지)
  
고객: 신용카드로 구매하겠습니다.
점원: 200만원 결제되었습니다. 감사합니다. (노트북, 2개, 신용카드 상태 유지)

먼저 Stateful한 프로토콜 예시를 보자.

점원은 계속해서 고객이 요청했던 문맥(상태)을 보존을 하고 있고 알맞게 행동을 한다.

// Stateless
고객: 이 노트북이 얼마인가요?
점원A: 100만원 입니다.
  
고객: 2개 구매하겠습니다.
점원B: 네? 무엇을 2개 구매하시겠어요 ?
  
고객: 신용카드로 구매하겠습니다.
점원C: 네? 무슨 제품을 몇개 신용카드로 구매하시겠어요?

Stateless한 프로토콜 예시를 살펴

보면 점원이 고객이 요청했던 문맥(상태)을 전혀 기억하지 못한다. 또한, 새 요청마다 오로지 요청한 정보에 대한 응답만 한다. 그렇기 때문에 점원은 네?와 같이 전혀 문맥을 파악하지 못하는 상황을 볼 수 있다.

Stateless 한 프로토콜이라면 아래와 같이 매 요청마다 필요한 데이터를 넘겨줘야한다.

// Stateless한 고객과 점원
고객: 이 노트북이 얼마인가요?
점원A: 100만원 입니다.
  
고객: 노트북 2개 구매하겠습니다.
점원B: 노트북 2개는 200만원 입니다. 신용카드, 현금중 어떤 걸로 도와드릴까요?
  
고객: 노트북 2개를 신용카드로 구매하겠습니다.
점원C: 200만원 결제되었습니다. 감사합니다.

이러한 특성 덕분에 중간에 점원이 바뀌어도 상관없이 문맥 전달에 신경을 안써도 된다. 중간에 점원이 바뀌어도 되기 때문에 점원을 늘릴 수 있고 이는 실질적으로 서버를 증설할 수 있다는 것이다. 즉, 스케일 아웃(수평적 확장)에 유리하다.

HTTP는 이러한 특성을 갖고 있다.

부가 설명으로 Stateless의 단점을 얘기하면 다음과 같다.

로그인과 같이 로그인 상태를 유지해야 하는 한계의 상황이 생긴다. 이에 대한 해결책으로 브라우저 쿠키와 서버 세션등을 이용해서 유지한다.
요청할 때마다 자원의 내용을 다 알려줘야 하므로 이 비용이 크다.

3. 비연결성(Connectionless) 프로토콜이다.

HTTP는 클라이언트와 서버의 연결을 유지하지 않는 모델이다.
그렇기 때문에 1시간동안 수천명이 서비스를 사용해도 실제 서버에서 동시에서 처리하는 요청은 수십개 이하로 매우 적다. 즉, 서버의 자원을 매우 효율적으로 사용할 수 있다.
하지만 TCP/IP 연결의 경우 새로 연결을 맺어야 하기 때문에 3 Way Handshake시간이 추가된다.
따라서 웹 브라우저로 사이트를 요청하면 HTML뿐만아니라 자바스크립트, css, 추가 이미지등 자원을 다운받을 때 TCP/IP 연결을 계속 새로 연결하여 다운을 받아야 한다.
지금은 HTTP 지속연결(Persistent Connections)로 문제를 해결했다. (TCP/IP 한번의 연결로 HTML,js, css등을 다 받아 오는 것) 이후 HTTP/2와 HTTP/3에서는 다른 방식으로 문제를 더 개선했다.

HTTP 메시지

HTTP로 클라이언트와 서버가 통신하고자할 때, 클라이언트가 TCP연결을 새로 열거나 기존 연결을 재사용하여 서버에 대한 TCP연결을 열고 HTTP메시지를 전송하고 응답을 받고 TCP연결을 끊거나 재사용하는 흐름으로 이루어진다.
HTTP메시지는 두가지 타입인 요청(requests)과 응답(response)이라는 형식을 가지고 있다.
HTTP/1.1와 초기 HTTP 메시지는 사람이 읽을 수 있다.
HTTP/2에서 이 메시지들은 새로운 이진 구조 프레임안으로 임베디드되어 헤더의 압축과 다중화와 같은 최적화가 가능하게 됐다.

요청(requests)

HTTP 요청의 예시

요청은 다음의 요소들로 구성된다.

HTTP 메서드일반적으로 클라이언트는 리소스를 가져오거나(GET) HTML 폼의 데이터를 전송(POST)하려고 하지만, 다른 경우에는 다른 동작이 요구될 수 있다.
보통 클라이언트가 수행하고자 하는 동작을 정의한 GET, POST 같은 동사나 OPTIONS나 HEAD와 같은 명사이다.
가져오려는 리소스의 경로
예를 들면 프로토콜(http://), 도메인 (위 사진에서는 developer.mozilla.org), 또는 TCP 포트 (위 사진에서는 default port인 80)인 요소들을 제거한 리소스의 URL
HTTP 프로토콜의 버전
서버에 대한 추가 정보를 전달하는 선택적 헤더들
POST와 같은 몇 가지 메서드를 위한, 전송된 리소스를 포함하는 응답의 Body와 유사한 본문

응답(responses)

HTTP 응답의 예시

응답은 다음의 요소들로 구성된다.

HTTP 프로토콜의 버전
요청의 성공 여부와, 그 이유를 나타내는 상태 코드
상태 코드의 짧은 설명을 나타내는 메시지 (아무런 영향력이 없다.)
요청 헤더와 같은 HTTP 헤더들
선택 사항으로 요청한 리소스가 포함되는 본문

HTTP란?

HyperText Transfer Protocol의 두문자어로 인터넷에서 데이터를 주고받을 수 있는 프로토콜이다. 초기에는 HTML과 같은 하이퍼텍스트를 주로 전송했지만, 최근에는 Plain text, JSON, XML 등 다양한 형태의 정보도 전송하는 애플리케이션 레이어 프로토콜이다.

*하이퍼 텍스트: 참조(하이퍼링크)를 통해 한 문서에서 다른 문서로 즉시 접근할 수 있는 텍스트이다. 기존의 문서가 순차적이면서 서열형 구조라면, 하이퍼텍스트는 링크에 따라 그 차례가 바뀌는 임의적이면서 나열형인 구조를 가진다.

*어플리케이션 레이어 프로토콜 : 컴퓨터 네트워크에서 인터넷 프로토콜 컴퓨터 네트워크를 통하는 프로세스 간 통신 접속을 위해 설계되어 통신 프로토콜과 방식을 위해 보유된 추상 계층이다.

HTTP 특징

클라이언트 - 서버 구조

클라이언트는 UI/UX에 집중하고 서버에서 비즈니스 로직과 데이터를 처리하는 등 서버와 클라이언트의 역할을 분리한 클라이언트-서버 구조이다.

🧐 클라이언트-서버 구조란?
클라이언트는 유저와 상호작용을 담당하고, 서버는 리소스요청과 응답에 대한 처리를 하도록 역할이 분리되어 있는 구조이다. HTTP프로토콜을 통해 서버-클라이언트 간 request와 response를 주고 받는다.

-클라이언트
서버와 연결된 모든 단말기와 웹에 접근하는 단말기 내 소프트웨어를 지칭하는 것으로 보통은 브라우저를 나타낸다. 사용자의 입력을 처리하여 서버에 요청을 보내는 역할을 한다.

-서버
클라이언트의 요청을 받아 처리하고 클라이언트에게 응답을 보낸다. 어떠한 형태로든 클라이언트의 요청을 받아 응답을 제공하면 서버가 될 수 있다.

TCP/IP 기반

브라우저가 웹 서버와 통신하기 위해 사용하는 주요 프로토콜로 TCP/IP기반으로 서버와 클라이언트의 요청과 응답을 전송한다.

🧐 TCP/IP 프로토콜이란?
전송 제어 프로토콜인 TCP와 인터넷 프로토콜인 IP의 합성어로 인터넷 동작의 중심이 되는 통신규약이다.

-TCP 역할: 데이터 흐름 관리, 데이터 전달 보증
-IP 역할 : 패킷 목적지 주소 지정, 경로 제어, 비신뢰성, 비연결형

IP는 기본 데이터 단위인 데이터그램이 목적지에 성공적으로 도달되는 것을 보장하지 않는 비신뢰성의 특징과 전달되는 데이터그램의 상태정보를 유지하지 않으며 각 데이터그램이 독립적으로 처리되는 비연결형의 특징을 갖는다. 따라서 전송 제어 프로토콜인 TCP와 함께 사용한다.
즉, TCP/IP를 기반으로 한다는 것을 IP주소 지정과 TCP의 안정적인 전송 특성을 활용해 논리적 연결을 수행하며 순서대로, 신뢰할 수 있는 데이텉 교환이 이루어진다는 것이다.

비연결성(Connectionless)

연결 상태를 유지하지 않는 비연결성 프로토콜(Connectionless)이다.

🧐 비연결성이란?
클라이언트와 서버가 한 번 연결을 맺고 클라이언트 요청에 대해 서버가 응답을 마치면 연결을 끊어버리는 성질이다.

연결을 유지하면 리소스가 계속 사용되고, 부족해지면 다른 사용자가 이용하지 못하기 때문에 더 많은 연결을 위해 비연결 지향으로 설계되었다. 하지만, 서버가 클라이언트를 기억하고 있지 않아 동일한 클라이언트의 모든 요청에 대해 매번 새로운 연결 시도/해제의 과정을 거쳐야 해 3 way handske의 시간이 추가되어 오버헤드가 발생한다는 단점이 있다.
HTTP 1.0부터는 keep-alive 헤더를 통해 연결을 유지할 수 있다. (HTTP 1.1붙터 별도 명시가 없으면 모든 연결이 지속연결로 간주) 자원 하나를 요청했을 때 이와 묶여 있는 모든 자원을 요청하기 위해 연결을 유지한 상태로 연결 횟수가 줄어들어 효율적인 처리가 가능하다.

무상태성(Stateless)

각각의 요청을 독립적인 트랜잭션으로 취급하는 무상태 프로토콜(Stateless)이다.

🧐 무상태란?
비연결성을 가지기 때문에 서버는 클라이언트를 식별할 수 없어 매번 새로운 인증을 해야 한다. 이러한 번거로움을 해결하는 대표적인 방법은 아래와 같다.

-쿠키/세션 기반 인증
브라우저가 서버와 연결이 되면 서버는 해당 클라이언트에 대한 유일한 값인 세션 ID를 부여하고 세션 스토리지에 저장한다. HTTP헤더에 실어 클라이언트에게 보내면 브라우저는 세션 ID를 포함하는 쿠키를 저장하고 있고, 이후 요청 시 헤더의 쿠키에 세션 ID를 담아서 전송한다. 서버는 클라이언트의 요청의 쿠키 내 세션 ID와 세션 스토리지에 담긴 세션 ID를 대조해 인증 여부를 판단한다.
즉, 세션은 서버에서 가지고 있는 정보이고 쿠키는 서버에서 발급된 세션을 열기 위한 키 값인 세션ID를 보관하는 곳이다.

-토큰 기반 인증
토큰은 인증을 위해 사용되는 암호화된 문자열이다. 서버는 토큰을 생성해서 클라이언트로 보내고, 클라이언트는 HTTP 헤더에 실어 서버에 전송하며 유효성을 검사한다. 토큰을 사용하면 서버나 세션에 의존하지 않고 클라이언트측에서 들어오는 요청만으로 작업을 처리하기 때문에 상태를 유지하지 않으므로 Stateless한 구조를 갖는다. 토큰은 제한된 수명을 가지고 만료되면 새로 생성되어야 한다.

HTTP 메시지 구조

요청(Request) 메시지 구조

요청문(요청 메서드, URL, HTTP 버전)
헤더: 요청에 대한 추가적인 정보로 Key/Value 형식으로 나타냄
바디: 실질적인 데이터

GET https://plustory.tistory.com HTTP/1.1

User-Agent: Mozilla/5.0 ...

Upgrade-Insecure-Requests: 1 ...

응답(Response) 메시지 구조

상태문(HTTP 버전, 상태코드, 상태이름)
헤더: 응답에 대한 추가적인 정보로 key/Value 형식으로 나타냄
바디: 실질적인 데이터, HTML이 담겨있는 경우 브라우저가 화면에 렌더링 함

HTTP/1.1 200 OK

Connection: keep-alive
Content-Encoding: gzip
Content-Length: 22222
Content-Type: text/html; charset=utf-8charset=utf-88

<!DOCTYPE html><html lang="ko"><head>...

HTTP 요청 메서드

GET:자료 요청
POST: 자료 생성
PUT: 자료 수정
DELETE: 자료 삭제

HTTP 응답 상태 코드

100~109 : 메시지 정보
200~206 : 요청 성공
300~305 : 리다이렉션
400~415 : 클라이언트 에러
500~505 : 서버 에러

Hypertext Transfer Protocol

HTTP는 웹 서버와 브라우저 사이에 정보를 송수신하는데 사용하는 클라이언트와 서버 프로토콜이다.

1989년 영국의 컴퓨터 과학자인 팀 버너스 리(Tim Berners-Lee)가 월드 와이드 웹(World Wide Web)을 고안하면서 설계한 프로토콜이다.
주로 HTML 문서를 주고 받는데 사용한다.

HTML(HyperText Markup Language) : 웹을 이루는 구성 요소이다.
웹 페이지가 어떤 구조로 이루어져 있는지 브라우저가 알 수 있도록 하는 마크업 언어!! ❌프로그래밍 언어 아님❌
- HyperText : 웹 페이지를 다른 페이지로 연경하는 링크이다.
- Markup Language: 태그 같은 수많은 요소를 사용 <h1>이런 태그</h1>하는 언어

Protocol : 규칙이다. 특정 기기 간에 데이터를 주고받기 위해 정의되었다.
“나는 이렇게 줄게! 넌 저렇게 받아! 난 너가 준거 요렇게 받을게!

✅ HTTP는 client-server 모델을 따르는 protocol이다.

client-server protocol

클라이언트(client) : 요청을 보내는 쪽 (일반적으로 웹 브라우저)
엔지니어들과 자신들의 어플리케이션을 디버그하는 웹 개발자들이 사용하는 프로그램들은 예외
서버(server) : 요청을 받는 쪽 (일반적으로 데이터를 보내는 원격지 컴퓨터)
요청(request) : 클라이언트에 의해 전송되는 메시지
응답(response) : 서버가 요청에 대해 전송하는 메시지

1. 웹 브라우저(Client)가 HTTP(규칙)를 통해 웹 서버(Server)로부터 웹 페이지나 이미지 정보를 요청한다.

2. 웹 서버(Server)는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 된다.

예를 들면 'http://www.tta.or.kr'과 같이 'http://'로 시작되는 URL을 지정한다.
여기에 있는 데이터를 HTTP(규칙)를 사용하여 서버에서 클라이언트로 전송한다.

HTTP 프로토콜로 데이터를 주고받기 위해서는 아래와 같이 요청(Request)을 보내고 응답(Response)을 받아야 한다.

URL이란?

protocol : 규약 http, ftp, telnet

host : 웹 서버의 위치

IP 주소 : 도메인 아니면 Ip 주소를 쓴다. ex) 127.0.0.1

domain name : host name의 일부분, 보통 도메인으로 불림 ex) example.com, kr, net

port : USB 포트를 생각해보자. 연결되는 gate로 컴퓨터와 다른 컴퓨터와 서로 연결되는 통로

표준 HTTP 포트 80, HTTPS는 443이다. 표준 포트를 사용할 경우 보통 생략한다.

resource path : 파일 위치다. 자원에 대해 웹서버에서 추상화한 경로다. 없으면 표시되지 않는다.

매개변수(query or parameter) : 웹 서버에서 보내는 추가 파라메터

fragment identifier : 부분 식별자

HTTP 프로토콜의 특징

1. HTTP 프로토콜은 stateless한 프로토콜이다. 상태가 없지만 세션은 있다.

상태가 없다 : 상태를 저장하지 않는다. 데이터를 주고 받기 위한 각각의 데이터 요청이 서로 독립적으로 관리가 된다.
서버는 세션같이 별도 추가 정보를 관리하지 않아도 된다. (다수의 요청 처리 및 서버의 부하를 줄일 수 있는 성능상의 이점)

2. 일반적으로 네트워크 프로토콜은 TCP/IP 프로토콜 위에서 동작한다. HTTP 기본 포트는 80번이다.

프록시(Proxy)란 무엇인가?

웹 브라우저와 서버 사이에 수많은 컴퓨터와 머신이 HTTP 메시지를 이어 받고 전달하는데 그 중 애플리케이션 계층에서 동작하는 것이다.
서버 대신 클라이언트의 요청을 중계 받는다.
프록시는 주로 보안을 위해 사용된다. 즉, 모든 웹 트래픽 흐름 속에서 신뢰할 만한 중개자 역할을 한다.
게이트웨이? 프록시? 차이점..
프록시 서버는 컨텐트 캐시, 보안, 필터링 등의 역할을 하는 중개자라면 게이트웨이는 서로 다른 네트워크 통신에서 서로 다른 프로토콜을 호환가능하게 하는 특별한 서버라고 볼 수 있을 것 같다.
- 요청과 응답 사이에는 여러 개체들이 있다. 게이트 웨이 또는 캐시 역할을 하는 프록시 등

Application Layer protocol

응용 계층(Application Layer)은 [OSI 7계층]에서 7계층을 담당하는 녀석으로 HTTP가 속해 있다.

실제로 브라우저와 요청을 처리하는 서버 사이에 좀 더 많은 컴퓨터들이 존재한다. (라우터, 모뎀 등)
웹의 계층적 설계 덕분에 이들은 네트워크와 전송 계층 내로 숨겨지고 HTTP는 애플리케이션 계층의 최상위에 있다.

HTTP 요청 메소드(Http Request Methods)

URL을 통해 서버에 특정 데이터를 요청할 수 있다.

요청하는 데이터에 특정 동작을 수행해야 할 때 Http Request Methods를 사용한다.

GET : 존재하는 자원에 대한 요청

POST : 새로운 자원을 생성

PUT : 존재하는 자원에 대한 변경

DELETE : 존재하는 자원에 대한 삭제

기타 요청 메소드 HEAD, OPTIONS(CORS에서 사용) 등이 있다.

HEAD

요청에 대해 body 없이 응답 헤더만 제공한다.

GET, HEAD를 제공하는 api에 GET과 HEAD를 각각 요청해보면 GET은 응답 body가 있고, HEAD는 응답 body가 없다. 응답 header는 동일하다.

데이터 양이 줄어들기 때문에 빠르게 서버의 상태를 조회할 수 있다.

응답 헤더의 Content-Length 또한 동일하기 때문에 resource 양에 대한 조회만 할 때에는 HEAD method가 유용할 수 있다.

OPTIONS

해당 end point가 지원하는 method가 무엇인지 알아볼 때에 사용하는 method

어떤 method를 지원하는지 응답 헤더 Allow로 제공

options로만 요청해보면 어떤 method를 지원하는지 노출되기 때문에 보안 취약성을 가진다.

HTTP 상태 코드(HTTP Status Code)

서버에서 설정해주는 응답(Response) 정보이다.

이 상태 코드로 에러 처리를 할 수 있다.

2XX 성공을 의미함

200 : GET 요청에 대한 성공
204 : No Content 성공하긴 했는데 응답 본문에 대한 데이터가 없음
205 : Reset Content 성공했으나 클라이언트의 화면을 새로고침하도록 권고함
206 : Partial Content 성공했으나 일부 범위의 데이터만 반환함

3XX 리다이렉션

클라이언트가 이전 주소로 데이터를 요청함 서버에서 새 URL로 리다이렉트를 유도하는 경우

301 : Moved Permanently 요청한 자원이 새 URL에 존재함
303 : See Other 요청한 자원이 임시 주소에 존재함
304 : Not Modified 요청한 자원이 변경되지 않아서 클라이언트에서 캐싱된 자원을 사용하도록 권고함
-ETag와 같은 정보를 활용하여 변경 여부를 확인함

4XX 클라이언트 에러

클라이언트의 코드가 잘못됐거나 유효하지 않은 자원을 요청했거나 권한이 잘못된 경우

400 : Bad Request 잘못된 요청
401 : Unauthorized 권한 없음 Authorization 헤더가 잘못된 경우
402 : 이 응답 코드는 나중에 사용될 것을 대비해 예약됨. 지금은 사용되고 있지 않음.
403 : Forbidden 서버에서 해당 자원에 대해 접근 금지
404 : Not Found 요청한 자원이 서버에 없음
405 : Method Not Allowed 지원하지 않는 요청을 하였을 때 사용

5XX 서버 에러

서버쪽에서 오류가 난 경우

501 : Not Implemented 요청 동작에 대해 서버가 수행할 수 없음
503 : Service Unavailable 서버가 과부하 또는 유지 보수로 내려간 경우

저작자표시