HTTP

오민영·2021년 7월 8일

HTTP Protocol

목록 보기

7/7

HTTP(Hyper Text Transform Protocol)은 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜(통신 규약)이다.

프로토콜?
무전기는 전파를 이용해서 음성 데이터 등을 주고받을 수 있는 기기이다. 전이중통신인 전화기와 달리, 무전기는 반이중통신을 기반으로 한다. 이 때문에 혼선을 사전에 방지하기 위해 무전 교신시에 메시지 전달을 끝마친 후에 '이상' 과 같이 응답하는 규칙을 사용한다.
이와 마찬가지로 컴퓨터 네트워크 통신을 위해서 사전에 제정된 약속, 즉 규칙이 존재하며, 이를 "프로토콜" 이라고 부른다.

웹 에서는 브라우저와 서버간에 데이터를 주고받기 위한 방식으로 HTTP 프로토콜을 사용하고 있으며, FT개발자라면 필수적으로 알아야하는 지식이다.

(클라이언트 - 서버) 프로토콜?

보통 웹 브라우저인 수신자 측에 의해 요청이 초기화 되는 프로토콜을 의미한다.
하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등을 불러온(fetched) 하위 문서들로 재구성된다.

클라이언트와 서버들은 개별적인 메세지 교환에 의해 통신을 한다. 보통 브라우저인 클라이언트에 의해 전송되는 메세지를 요청(Request)라고 부르며, 그에 대해 서버에서 응답으로 전송되는 메시지를 응답(Response)라고 한다.

HTTP 기반 시스템의 구성 요소

HTTP는 (클라이언트 - 서버) 사이의 존재하는 프로토콜이다.

요청(request)은 하나의 개체인 사용자 에이전트(프록시)에 의해 전송된다. 대부분의 경우, 사용자 에이전트는 브라우저이지만 무엇이든 될 수 있다. (웹을 돌아다니는 로봇도 될 수 있음)

이렇게 각각의 요청은(Request)들은 서버로 보내지며, 서버는 요청을 처리하고 Response라고 불리는 응답을 제공한다. 이 요청(Request)과 응답(Response) 사이에는 여러 개체들이 있는데, 다양한 작업을 수행하는 Gateway 또는 Cache 역할을 하는 Proxy 등이 있다.

즉, 클라이언트(브라우저)와 서버 사이에는 다양하고 많은 컴퓨터 종류가 존재한다.(라우터, 모뎀 등)

클라이언트(User Agent)

요청(Request)을 보내는 쪽을 의미하고, 일반적으로 웹 관점에서 브라우저를 의미한다. 브라우저는 항상 요청(Request)을 보내는 객체로, 결코! 서버가 될 수 없다.

사용자 에이전트는 사용자를 대신하여 동작하는 모든 도구로, 이 역할은 주로 브라우저에 의해 수행된다. (엔지니어와 자신들의 애플리케이션을 디버그하는 웹 개발자들이 사용하는 프로그램(VsCode, IntelliJ...)은 예외)

웹 페이지를 표시하기 위해, 브라우저는 페이지의 HTML 문서를 가져오기 위한 요청을 전송한 뒤, 파일을 분석하여 실행해야 할 Script, 그리고 페이지 내 포함된 하위 리소스들(이미지 / 비디오)를 잘 표시하기 위한 레이아웃 정보(CSS)에 대응하는 추가적인 요청들을 가져온다. 그런 뒤에 브라우저는 완전한 문서인 웹페이지를 표시하기 위해 그 리소스들을 혼합한다. 브라우저에 의해 실행된 스크립트는 이후 단계에서 좀 더 많은 리소스들을 가져올 수 있으며, 브라우저는 그에따라 웹 페이지를 갱신하게 된다.

웹 페이지는 하이퍼텍스트 문서로, 표시된 텍스트의 일부는 사용자가 사용자 에이전트를 제어하고 웹을 돌아다닐 수 있도록 새로운 웹 페이지를 가져오기 위해 실행(보통 마우스 클릭에 의해)될 수 있는 링크임을 뜻합니다. 브라우저는 HTTP 요청 내에서 이런 지시 사항들을 변환하고 HTTP 응답을 해석하여 사용자에게 명확한 응답을 표시한다.

웹 서버

요청을 받아 응답(Response)하는 쪽을 의미하며, 일반적으로 데이터를 보내주는 원격지의 컴퓨터를 의미한다.

통신 채널의 반대편에는 클라이언트에 의한 요청(Request)에 대한 문서를 제공(Response)하는 서버가 존재한다.

Proxy

클라이언트와 서버간의 응답, 요청을 하게 되는데 중계 역할을 하는 서버를 말한다.
트랙픽 부하, 캐쉬 , 보안 여러 가지 목적에 따라 프록시 서버를 사용하게 된다.

클라이언트에서 프록시 서버로 데이터 전송
프록시 서버에서 다시 웹 서버로 웹 요청(Request)
웹 서버에서 프록시 서버로 웹 응답(Response)
프록시 서버에서 클라이언트로 데이터 전송

여러 계층으로 이루어진 웹 스택 구조에서 이러한 컴퓨터 / 머신 대부분은 전송(Response), 네트워크 혹은 물리 계층에서 동작하며, 성능에 상당히 큰 영향을 주지만 HTTP 계층에서는 이들이 어떻게 동작하는지 눈에 보이지 않는다. 이러한 컴퓨터 / 머신 중에서 애플리케이션 계층에서 동작하는 것들을 일반적으로 Proxy라고 부른다.

프록시는 눈에 보이거나, 그렇지 않을수도 있고 다양한 기능을 수행할 수 있다.

Caching (캐시는 공개 / 비공개 일 수 있다.)
필터링 (바이러스 백신 스캔, 유해 컨텐츠 차단(자녀보호) 기능)
로드 밸런싱 (여러 서버들이 서로 다른 요청을 처리하도록 허용)
인증 (다양한 리소스에 대한 접근 제어)
로깅 (이력 정보를 저장)

HTTP 기초적인 측면

HTTP는 간단하다.

HTTP는 사람이 읽을 수 있으며, 간단하게 고안되었다.
HTTP 메시지들은 사람이 읽고 이해할 수 있어, 테스트하기 쉽다.

HTTP는 확장 가능하다.

HTTP 헤더는 HTTP를 확장하고 실험하기 쉽게 만들어주었다.
클라이언트와 서버가 새로운 헤더의 시멘틱에 대해 간단한 합의만 한다면, 새로운 기능을 추가할 수 있다.

HTTP는 상태가 없지만, 세션은 있다.

HTTP 프로토콜은 상태를 저장하지 않는다.(Stateless) 즉, 상태가 없는 프로토콜이다.
상태가 없다는 말은, 데이터를 주고 받기 위한 각각의 데이터 요청이, 서로 독립적으로 관리가 된다.
즉, 이전 데이터 요청과 다음 데이터 요청이 서로 관련이 없다.
HTTP의 핵심은 상태가 없는 것이지만 HTTP 쿠키는 상태가 있는 세션을 만들도록 해준다.

HTTP와 연결

연결은 전송 계층(Request)에서 제어되므로 근본적으로 HTTP 영역 밖이다.
HTTP는 연결될 수 있도록 하는 근본적인 전송 프로토콜을 요구하지 않는다. 다만 신뢰할 수 있거나, 메시지 손실이 없는 연결을 요구할 뿐이다.
인터넷 상의 가장 일반적인 두 개의 전송 프로토콜 중에서 TCP는 신뢰할 수 있으며, UDP는 그렇지 않다.
HTTP는 연결이 필수는 아니지만 연결 기반은 TCP 표준에 의존한다.
클라이언트와 서버가 HTTP를 요청/응답으로 교환하기 전에 여러 왕복이 필요한 프로세스인 TCP 연결을 설정해야 합니다.

HTTP로 제어할 수 있는 기능 목록

HTTP의 확장 가능한 특성은 수년간에 걸쳐 웹의 점점 더 많은 기능들을 제어하고 허용해 왔다. (캐시 혹은 인증 메서드는 HTTP에 초기부터 제어해왔던 기능이다)

Cache

HTTP로 문서가 캐시되는 방식을 제어할 수 있다.
서버는 캐시 대상과 기간을 Proxy와 클라이언트에 지시할 수 있고, 클라이언트는 저장된 문서를 무시하라고 중간 캐시 프록시에게 지시할 수 잇다.

Origin 제약사항 완화하기

스니핑(네트워크 트래픽을 도청하는 과정)이나 다른 프라이버시 침해를 막기 위해, 브라우저는 웹 사이트 간에 엄격한 분리를 절대적으로 중요시한다. 동일한 origin으로부터 온 웹 페이지 만이 전체 정보에 접근할 수 있다. 이런 제약 사항은 서버에 부담이 되지만, HTTP 헤더를 통해 부담을 완화시킬 수 있다.

인증

어떤 페이지들은 보호되어 오로지 특정 사용자만 접근하도록 설정할 수 있다.
기본 인증은 HTTP를 통해 WWW-Authenticate 또는 유사한 헤더를 사용해 제공하거나, HTTP 쿠키를 사용해 특정 세션 ID를 설정해서 이루어 질수도 있다.

프록시와 터널링

서버 혹은 클라이언트 모두 종종 인트라넷에 위치해서 다른 개체들에게 그들의 실제 주소를 숨기곤 한다.

세션

쿠키의 사용은 서버 상태를 요청과 연결하도록 해준다. (세션 ID?)

HTTP 흐름

클라이언트가 서버와 통신하려고 할 때, 최종 도착지가 서버든 / 프록시든 아래 관계를 반드시 거치게 된다!

TCP(Transmission Control Protocol)
데이터가 의도된 목적지까지 닿을 수 잇도록 보장해주는 통신 프로토콜.
최상위 계층인 TCP는 많은 양의 데이터를 가져와서 패킷(데이터를 일정한 크기로 자른 단위)으로 컴파일 한다음, 동료 TCP 계층에서 수신하도록 전송하여 패킷을 유용한 정보 / 데이터로 바꾸는 역할을 한다.

IP(Internet Protocol)
데이터가 의도된 목적지까지 닿을 수 잇도록 보장해주는 통신 프로토콜.
인터넷에서 컴퓨터의 위치를 찾아 데이터를 전송하기 위해 지켜야할 규약으로 각각의 컴퓨터에 특별한 주소를 부여하는 것!

TCP를 연다.

클라이언트는 새 연결을 열거나 기존 연결을 재사용해서, 서버에 대한 여러 TCP 연결을 할 수 있다.

HTTP 메세지를 전송한다.

HTTP는 사람이 읽을 수 있다.
HTTP/2 버전에는 간단한 메세지가 프레임 속으로 캡슐화되어 직접 읽기는 불가는 하지만, 원칙은 동일하다.

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

서버에 의해 전송받은 응답(Resoponse)을 읽어들인다.

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html

<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)

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

HTTP 메세지

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

요청(Request)

URL을 이용하면 서버에 특정 데이터를 요청할 수 있다.

HTTP 요청 메서드(HTTP Request Method)

GET: 존재하는 자원에 대한 요청
POST: 새로운 자원을 생성
PUT: 존재하는 자원에 대한 변경
DELETE: 존재하는 자원에 대한 삭제
- 위와 같이, 데이터에 대한 조회, 생성, 변경, 삭제 동작을 HTTP 메서드로 정의할 수 있다.
HEAD: 서버의 헤더 정보를 획득
OPTIONS: 서버 옵션들을 확인하기 위한 요청 (CORS에서 사용)

HTTP 요청의 예

HTTP 메서드: 수행하고자 하는 동작 (GET, POST, HEAD ...)
가져오려는 리소스의 경로(PATH)
- https://`(프로토콜)`developer.mozilla.org`(도메인) 요소를 제외한 리소스의 URL
HTTP 프로토콜 버전 (HTTP/1.1)
서버에 대한 추가 정보를 전달하는 선택적 헤더들

응답(Response)

앞에서 URL과 요청 메서드가 클라이언트에서 설정해야 할 정보라면
HTTP 상태 코드(HTTP Status Code)는 서버에서 설정해주는 응답(Response)정보이다.
이 상태 코드로 에러 처리를 할 수 있다!

2xx : 성공
- 200번대 상태 코드는 대부분 성공을 의미한다.
3XX : 리다이렉션
- 300번대의 상태 코트는 대부분 클라이언트가 이전 주소로 데이터를 요청하여 서버에서 새 URL로 리다이렉트를 유도하는 경우이다.
4xx : 클라이언트 에러
- 400번대 상태 코드는 대부분 클라이언트의 코드가 잘못된 경우이다.
- 유효하지 않은 자원을 요청했거나 요청이나 권한이 잘못된 경우 발생한다.
5xx : 서버 에러
- 500번대 상태 코드는 서버 쪽에서 오류가 난 경우이다.