[WEB] HTTP 프로토콜

0. 웹 통신과 프로토콜(Protocol)

• '웹 통신'이란 인터넷상의 웹 공간에서의 통신을 말한다.

• ' 프로토콜(Protocol)'이란 '통신 규약'이라고도 하며, 컴퓨터나 원거리 통신 장비 사이에서 메시지를 주고받는 양식과 규칙의 체계를 아우르는 말이다.

• 참고) 클라이언트-서버 프로토콜(모델)이란 서비스 제공자와 요청자로 구분되는 네트워크 모델이다. 서비스 제공자의 역할을 하는 측은 서버, 요청자의 역할을 하는 측은 클라이언트라고 한다. 이때 클라이언트는 Data Presentation을 위한 최소한의 자원을 가지는 것이 일반적이다.

1. HTTP란 무엇인가?

HTTP(Hyper Text Transmit Protocol)는 인터넷 상에서 HTML 문서나 동영상과 같은 리소스(Resource)를 주고받기 위한 프로토콜이다. 기본 포트 번호는 80번이다.
애플리케이션 층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상으로는 무엇이든 사용할 수 있으나 TCP 혹은 암호화된 TCP 연결인 TLS를 통해 전송된다.

HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 하다.
보통 브라우저인 클라이언트에 의해 전송되는 메시지를 요청(request)이라고 부르며, 그에 대해 서버에서 응답으로 전송되는 메시지를 응답(response)이라고 부른다.

클라이언트는 URI를 이용해서 서버에 접속하고, 데이터를 요청하게 된다. 서버는 클라이언트의 요청을 받아, 해석하고 응답한다. 이 때, 응답이 오기 전까지 클라이언트는 대기한다.

2. HTTP의 특징

HTTP는 Connectless 방식으로 작동한다. 서버에 연결하고, 요청해서 응답을 받으면 연결을 끊어버린다. 기본적으로 자원 하나에 대해서 하나의 연결을 만든다.

• 장점 : 불특정 다수를 대상으로 하는 서비스에 적합한 방식이다. 수 십만 명이 웹 서비스를 사용하더라도 접속 유지는 최소한으로 할 수 있기 때문에, 더 많은 유저의 요청을 처리할 수 있다. (서버 확장성이 높음, 서버의 부하를 최대한 줄일 수도 있음)

• 단점 : 연결을 끊어버리기 때문에, 클라이언트의 이전 상태를 알 수 없다. 이러한 HTTP의 특징을 Stateless라고 한다. 클라이언트의 이전 상태 정보를 알 수 없게 되면, 웹 서비스를 하는데 당장에 문제가 생긴다. 클라이언트가 과거에 로그인을 성공하더라도 로그 정보를 유지할 수가 없다. 이러한 단점을 해결하기 위해 Cookie와 Session이 등장했다.
  

3. HTTP 기반 시스템의 구성 요소

HTTP는 클라이언트-서버 프로토콜이다. 요청은 하나의 개체, 사용자 에이전트(User-Agent, 또는 그것을 대신하는 프록시)에 의해 전송된다. 대부분의 경우 에이전트는 웹 브라우저이다.

각각의 개별적인 요청들은 서버로 보내지며, 서버는 요청을 처리하고 응답을 보낸다. 이 요청과 응답 사이에는 여러 개체들이 있는데, 예를 들면 다양한 작업을 수행하는 게이트웨이(Gateway) 또는 캐시(Cache) 역할을 하는 프록시(Proxy) 등이 있다.

• 클라이언트(Client) : 사용자 에이전트(User-Agent)
  주로 브라우저에 해당하며 요청을 보내는 개체이다. 브라우저는 HTTP 요청하고 응답을 해석하여 사용자에게 명확한 응답을 표시해 준다.

• 웹 서버(Server)
  서버는 사실상 논리적으로 단일 기계지만, 여러 개의 서버를 동일한 머신 위에서 호스팅 할 수는 있다. HTTP/1.1과 Host 헤더를 이용하여, 동일한 IP 주소를 공유할 수도 있다.

• 프록시(Proxy)
  웹 브라우저와 서버 사이에서 HTTP 메시지를 이어 받고 전달하는 애플리케이션 계층에서 동작하는 것들을 일반적으로 프록시(Proxy)라고 부른다. 프록시는 다양한 기능들을 수행할 수 있다.

  • 캐싱 (ex: 브라우저 캐시)
  • 필터링 (바이러스 백신 스캔, 유해 컨텐츠 차단 기능)
  • 로드 밸런싱 (여러 서버들이 서로 다른 요청을 처리하도록 허용)
  • 인증 (다양한 리소스에 대한 접근 제어)
  • 로깅 (이력 정보를 저장)

4. URI (Uniform Resource Identifier)

HTTP 요청 대상을 흔히 "리소스(Resource, 자원이라고도 함)"라고 부르는데, 각 리소스는 HTTP 전체에서 사용되는 URI에 의해 식별된다. 웹에서 리소스에 대한 식별과 위치는 대부분 단일 URL(Uniform Resource Locator, URI의 한 종류)로 제공된다.

URI의 가장 일반적인 형식은 웹 주소라고 불리는 URL인데, 구조는 아래와 같다.

URI의 종류 중 하나인 URN은 개별적인 네임스페이스 내에서 이름에 의해 리소스를 식별한다.

5. HTTP Request Method (HTTP 요청 메서드)

메서드는 요청의 종류를 서버에게 알려주기 위해서 사용한다.

• GET : 특정한 리소스를 가져오도록 요청하기 위해 사용한다. 데이터를 가져올 때만 사용해야 한다.
• POST : 서버로 데이터를 전송하기 위해 사용한다. 서버에 변경사항을 만든다고 보면 된다.
• PUT : 요청 페이로드(Payload)를 사용해 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체한다.
• DELETE : 지정한 리소스를 삭제하기 위해서 사용한다.
• HEAD : (HTTP) 헤더 정보만 요청한다. 해당 자원이 존재하는지 혹은 서버에 문제가 없는지를 확인하기 위해서 사용한다.
• OPTIONS : 웹 서버가 지원하는 메서드의 종류를 요청한다.

보통 웹 서비스들은 GET과 POST만을 이용해서 개발한다. DELETE나 PUT 등이 필요한 요청에도 GET과 POST를 사용하는데, 예를 들어 게시판에서 특정 레코드를 삭제할 때도 GET으로 표현한다.

5. HTTP Status Code (HTTP 상태 코드)

앞에서 살펴본 URI와 요청 메서드가 클라이언트에서 설정해야 할 정보라면 HTTP 상태 코드는 서버에서 설정해주는 응답(Response) 정보이다. 대략적인 상태 코드만 살펴보자.

① 2xx: Success 성공
서버가 요청을 받고 성공적으로 처리되었음을 나타낸다.

② 3xx: Redirection 리다이렉션
대부분 클라이언트가 이전 주소로 데이터를 요청하여 서버에서 새 URL로 리다이렉트를 유도하는 경우를 나타낸다.

③ 4xx: Client Error 클라이언트 오류
대부분 서버가 해결할 수 없는 클라이언트의 코드가 잘못된 경우다. 유효하지 않은 자원을 요청했거나 요청이나 권한이 잘못된 경우 발생한다. 가장 익숙한 코드로는 '404 Not Found'가 있다.

④ 5xx: Server Error 서버 오류
서버가 클라이언트의 요청을 처리하지 못했을 때 발생한다.

6. HTTP의 전체적인 흐름

클라이언트가 서버와 통신하고자 할 때, 다음 단계의 과정과 같이 수행하게 된다.

1. TCP 연결을 열어 요청과 응답을 받을 수 있게 만든다. 클라이언트는 새 연결을 열거나, 기존 연결을 재사용하거나, 서버에 대한 여러 TCP 연결을 열 수 있다.

2. 클라이언트 측에서 HTTP 요청 메시지(Request Message)를 전송한다. HTTP 메시지(HTTP/2 이전의)는 읽을 수 있고, HTTP/2에서는 이런 간단한 메시지가 프레임 속으로 캡슐화되어, 직업 읽는 게 불가능하지만 원칙은 동일하다.

   GET / HTTP/1.1
   Host: developer.mozilla.org
   Accept-Language: fr

3. 서버에서 클라이언트의 요청에 응답하여 HTTP 응답 메시지(Response Message)를 전송한다.

4. 클라이언트는 서버에 의해 전송된 응답을 읽어 들인다.

5. 연결을 닫거나 다른 요청들을 위해 재사용한다.

6. HTTP Message (HTTP 메시지)

HTTP/1.1과 초기 HTTP 메시지는 사람이 읽을 수 있으나, HTTP/2부터는 이 메시지들이 새로운 이진 구조인 프레임 안으로 임베드(embedded)되어 헤더의 압축과 다중화와 같은 최적화를 가능케 한다. 본래의 HTTP 메시지의 일부분만이 이 버전의 HTTP 내에서 전송된다고 할지라도, 각 메시지의 의미들은 변하지 않으며 클라이언트는 본래의 HTTP/1.1 요청을 가상으로 재구성한다. 그러므로 HTTP/1.1 포맷 내에서 HTTP/2를 이해하는 것이 여전히 유용하다고 볼 수 있다.

HTTP 메시지의 두 가지 타입인 요청(Request)과 응답(Response)은 각자만의 형식을 가지고 있다.

1) HTTP 메시지의 전체적인 구조

/* rfc7230 공식스펙 */
const HTTP-Message  =  start-line      // 시작 라인 
			* (header-field CRLF)      // 헤더 라인
			CRLF					   // 공백 라인
       		[ message-body]            // 메시지 바디 (Entity 본문)

✔️ HTTP 메시지 구조 : 시작 라인, 헤더, 공백 라인(필수), 메시지 바디

• 시작 라인 (Start-line) : 메시지의 종류에 따라 요청 라인 (Request-line)과 응답 라인 (Response-line)으로 나뉜다.

• 헤더 라인 (Header-line) : HTTP 전송에 필요한 모든 부가 정보가 포함된다.
  (예를 들면 Content-type, Content-Length, ...)
  필요 시 임의의 헤더도 추가할 수 있다.

• 공백 라인 (CRLF) : 말 그대로 공백인 라인.

• 메시지 바디 (Entity 본문) : 실제 전송할 데이터. HTML, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터가 전송 가능하다.

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

✔️ HTTP Method : HTTP 메서드는 보통 클라이언트가 수행하고자 하는 동작을 정의한 GET, POST, OPTIONS, HEAD를 지칭한다. 일반적으로, 클라이언트는 리소스를 가져오거나(GET 사용) HTML 폼의 데이터를 전송(POST 사용)하곤 하지만, 다른 경우에는 다른 동작이 요구될 수 있다.

✔️ Path : 가져오려는 리소스의 경로.

✔️ Version of the Protocol : HTTP 프로토콜의 버전.

✔️ Headers : 서버에 대한 추가 정보를 전달하는 선택적 헤더들.

✔️ etc : POST와 같은 몇 가지 메서드를 위한, 전송된 리소스를 포함하는 응답의 본문.

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

✔️ Version of the Protocol : HTTP 프로토콜의 버전.

✔️ Status Code : 요청의 성공 여부와, 그 이유를 나타내는 상태 코드.

✔️ Status Message : 아무런 영향력이 없는, 상태 코드의 짧은 설명을 나타내는 상태 메시지.

✔️ Headers : 요청 헤더와 비슷한, HTTP 헤더들.

✔️ etc : 선택 사항으로, 가져온 리소스가 포함되는 본문.

Link

https://developer.mozilla.org/ko/docs/Web/HTTP,
https://developer.mozilla.org/ko/docs/Web/HTTP/Overview#http%EC%9D%98_%EA%B8%B0%EC%B4%88%EC%A0%81%EC%9D%B8_%EC%B8%A1%EB%A9%B4,
https://www.joinc.co.kr/w/Site/Network_Programing/AdvancedComm/HTTP,
https://velog.io/@dnjscksdn98/HTTP-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC,
https://joshua1988.github.io/web-development/http-part1/,
https://velog.io/@dnr6054/web-technologies-and-http,
https://velog.io/@gparkkii/HTTPMessage,
https://velog.io/@sujeong/2-%EC%9B%B9%EC%9D%98-%EB%8F%99%EC%9E%91-HTTP-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EC%9D%B4%ED%95%B4,