서론
- 그동안 웹개발 공부를 하면서 HTTP에 대한 기초지식이 부족하다는 것을 깨달았다. MDN에서 HTTP
기초 공부를 하면서 정리한 것을 블로그에 적고자 한다.
developer.mozilla.org/ko/docs/Web/HTTP/Overview
HTTP 개요 - HTTP | MDN
HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜입니다. HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 합니다. 클라이언트-서버
developer.mozilla.org
HTTP 개요
- HTTP는 HTML과 같은 하이퍼미디어 문서 전송을 위한 애플리케이션 레이어 프로토콜이다.
- 웹 브라우저와 웹 서버간의 커뮤니케이션을 위해 사용되며
- HTTP는 무상태 프로토콜을 지닌다. (서버가 두 요청간에 데이터(상태)도 유지 하지 않음을 의미)
- 'HTTP'는 웹에서 이루어지는 모든 데이터 교환의 기초가 되며, 하나의 완전한 문서는
텍스트, 레이아웃, 설명, 이미지, 스크립트 등 불러온(fetched) 하위 문서들로 재구성된다.
- 클라이언트와 서버들은 데이터 스트림과 대조적으로 개별적인 메시지 교환에 의해 통신되고,
브라우저는 메시지를 request하고, 서버는 요청받은 메시지에 대한 결과를 response한다.
- HTTP는 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상 무엇이든
사용할 수 있으나 TCP 혹은 TCP 연결인 TLS(Transport Layer Security, 전송 계층 보안, 이전의 SSL)
를 통해 전송된다.
HTTP 기반 시스템의 구성 요소
- 요청은 하나의 개체, 사용자 에이전트(또는 프록시)에 의해 전송된다.
- 기본적으로 사용자 에이전트는 브라우저지만, 무엇이든 될 수 있다. (예를들어 검색 봇)
- 각각의 개별적인 요청들은 서버로 보내지고, 서버는 요청을 처리하고 응답을 제공한다.
- 요청과 응답 사이에 여러 개체들이 있는데, 다양한 작업을 수행하는 게이트웨이 또는 캐시역할을
하는 프록시 등이 있다.
- 실제 브라우저와 서버 사이에는 더 많은 구성 요소(하드웨어, 라우터, 모뎀 등)이 존재하지만 웹의
계층적인 설계 덕분에 이들은 네트워크와 전송 계층 내로 숨겨진다.
- HTTP는 그 중 애플리케이션 계층의 최상층에 존재하여 동작한다.
클라이언트: 사용자 에이전트
- 사용자 에이전트 : 사용자를 대신하여 동작을 처리하는 도구(주로 브라우저)
- 웹 페이지 표시를 위해 브라우저는 페이지의 HTML 문서를 가져오기 위한 요청 전송 뒤
파일을 구문 분석하여 실행해야 할 스크립트, 페이지 내 포함된 하위 요소들(이미지, 비디오 등)을
잘 표시하기 위한 레이아웃 정보(CSS)에 대응하는 추가적인 요청들을 가져온다.
- 브라우저는 완전한 문서인 웹 페이지 표시를 위해 리소스들을 혼합하고, 브라우저에 의해 실행된
스크립트는 이후 단계에서 좀 더 많은 리소스들을 가져올 수 있고, 브라우저는 그에 따라 웹 페이지
를 갱신한다.
- 웹 페이지는 하이퍼텍스트 문서로, 표시된 텍스트의 일부는 사용자가 에이전트를 제어하고 웹을
돌아다닐 수 있도록 새로운 웹 페이지를 가져오기 위해 실행될 수 있는 링크임을 뜻한다.
- 브라우저는 HTTP 요청 내에서 이런 지시 사항들을 변환하고, HTTP 응답을 해석하여 사용자에게
명확한 응답을 표시한다.
웹 서버
- 클라이언트에 요청에 대한 문서 혹은 리소스를 제공하는 서버
- 서버는 사실상 논리적으로 단일 기계를 의미한다. 이는 로드(로드 밸런싱) 혹은 그때 그때 다른
컴퓨터(캐시, DB서버, e-커머스 서버 등)들의 정보를 얻고 완전하게 혹은 부분적으로 문서를 생성
하는 소프트웨어의 복잡한 파트를 공유하는 서버들의 집합일 수 있다.
- 서버는 반드시 단일 머신일 필요 없지만, 여러 개의 서버를 동일한 머신 위에서 호스팅 가능
- HTTP/1.1과 host 헤더를 이용하여 동일한 IP 주소를 공유할 수도 있다.
프록시
- 웹 브라우저와 서버 사이에서 많은 컴퓨터들이 HTTP 메시지를 이어 받고 전달한다.
- 여러 계층으로 이루어진 웹 스택 구조에서 컴퓨터들은 대부분은 전송,네트워크 혹은 물리
계층에서 동작하며 성능에 큰 영향을 주지만 HTTP 계층에서는 이들이 어떻게 동작하는지 눈에
보이지 않는다.
- 이러한 컴퓨터 중에서 애플리케이션 계층에서 동작하는 것들은 주로 '프록시'라고 한다.
- 프록시는 다양한 기능을 수행 가능하다.
- 캐싱 (캐시는 공개 또는 비공개 (예: 브라우저 캐시))
- 필터링 (바이러스 백신 스캔, 유해 컨텐츠 차단)
- 로드 밸런싱 (여러 서버들이 서로 다른 요청을 처리하도록 허용)
- 로깅 (이력 정보를 저장)
HTTP 특징
- 간단함
- HTTP는 사람이 읽을 수 있도록 간단하게 고안되었다.
- HTTP/2가 다소 복잡해졌지만 HTTP 메시지를 바이너리 기반 프레임별로 캡슐화하여 간결함
을 유지하였다.
- 간단하기에 테스트하기가 쉽고, 초심자의 진입장벽이 낮다.
- 확장 가능한 HTTP
- HTTP/1.0에서 소개된 HTTP헤더는 HTTP를 확장하고 실험하기 쉽게 만들어 주었다.
- 클라이언트와 서버가 새로운 헤더의 시맨틱(의미)에 대해 간단한 합의만 한다면 언제든지 새로운
기능을 추가 가능하다.
- HTTP는 상태가 없지만, 세션은 있다.
- HTTP는 상태를 저장하지 않는다. 동일한 연결 상에서 연속하여 전달된 두 개의 요청사이에
연결고리가 없는 것.
- e-커머스 쇼핑 바구니처럼, 일관된 방식으로 상호작용하길 원할 때 문제가 되지만, HTTP의 핵심은
상태가 존재하지 않아도 HTTP 쿠키가 상태가 있는 세션을 만들도록 도와준다.
- 헤더 확장성을 사용하여 동일한 컨텍스트 또는 동일한 상태를 공유하기 위해 요청들에 세션을
만들도록 HTTP 쿠키가 추가된다.
- HTTP와 연결
- 연결은 전송 계층에서 제어되므로, 근본적으로 HTTP 영역 밖이지만, 연결가능하도록 하는 근본적인
전송 프로토콜을 요구하지 않는다.
- 그저 신뢰할 수 있거나 메시지 손실이 없는(최소한의 오류는 표시, TCP 표준에 의존) 연결을 요구할 뿐이다.
- HTTP/1.0의 기본 동작은 각 요청/응답에 대해 별도의 TCP 연결을 하는 것이고, 이 동작은 여러 요청을
계속해서 보내는 경우에는 단일 TCP 연결을 공유하는 것보다 비효율적이지만
- 이러한 결함 개선을 위해 HTTP/1.0은 파이프라이닝 개념과 지속적인 연결의 개념을 도입했다.
- 기본적으로 TCP 연결은 Connection 헤더를 사용해 부분적으로 제어가 가능하다.
- HTTP/2는 연결을 좀 더 지속되고 효율적으로 유지하는데 도움이 되도록, 단일 연결 상에서 메시지를
다중 전송(multiplex)하여 한 걸음 진보 하였다.
HTTP로 제어 가능한 것
- 캐시 혹은 인증 메소드는 HTTP 초기부터 제어 해왔던 기능이며, origin 제약사항을 완화시키는 조치는
2010년에 들어서 추가되었다.
- HTTP를 사용하여 제어 가능한 일반적인 기능 목록
- 캐시
- HTTP로 문서가 캐시되는 방식을 제어 가능하다. 서버는 캐시 대상과 기간을 프록시와 클라이언트에
지시 가능하고, 클라이언트는 저장된 문서를 무시하라고 중간 캐시 프록시에게 지시 가능하다.
- origin 제약사항 완화
- 스누핑과 다른 프라이버시 침해를 막기 위해 브라우저는 웹 사이트간의 분리를 강제한다.
- 동일한 origin으로부터 온 페이지만이 웹 페이지의 전체 정보에 접근 가능하다.
- 앞의 제약사항은 서버에 부담이 되지만, HTTP 헤더를 통해 그것을 완화 가능하고, 덕분에 문서는
다른 도메인으로부터 전달된 정보를 패치워크 가능하다.
- 인증
- 어떤 페이지들은 보호되어 오로지 특정 사용자만이 그것에 접근 가능하다.
- 기본 인증은 HTTP를 통해 WWW-Authenticate 또는 유사한 헤더를 사용해 제공되거나, HTTP 쿠키를
사용해 특정 세션을 설정하여 이루어질 수 있다.
- 프록시와 터널링
- 서버 혹은 클라이언트 혹은 서버-클라이언트는 종종 인트라넷에 위치하며 다른 개체들에게 그들의
실제 주소를 숨기기도 한다.
- HTTP 요청은 네트워크의 장벽을 가로지르기 위해 프록시를 통해 나가게 된다.
- 하지만 모든 프록시가 HTTP 프록시라는 것은 아니다.
- 예로, SOCKS 프로토콜은 좀 더 저수준에서 동작하고, FTP와 같은 다른 프로토콜도 이 프록시를 통해 처리
- 세션
- 쿠키 사용은 서버 상태를 요청과 연결하도록 도와준다.
- HTTP가 기본적으로 상태 없는 프로토콜임에도 세션을 만들어주는 계기가 된다.
HTTP 흐름
- 클라이언트가 서버와 통신하고자 할 때, 최종 서버든, 중간 프록시든 다음 단계와 같은 과정을 수행한다.
1. TCP 연결을 연다. TCP 연결은 요청을 보내거나 혹은 여러개의 요청을 보낼 때 응답을 받는데 사용된다.
클라이언트는 새 연결을 열거나, 기존 연결을 재사용하거나, 서버에 대한 여러 TCP 연결을 열 수 있다.
2. HTTP 메시지를 전송. HTTP 메시지(HTTP/2 이전의)는 인간이 읽을 수 있고 HTTP/2에서는 이런 간단한
메시지가 프레임 속으로 캡슐화되어 직접 읽는게 불가능하지만 원칙은 동일하다.
GET / HTTP/1.1
Host: developer.mozilla.org Accept-Language: fr3. 서버에 의해 전송된 응답을 읽어들인다.
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)4. 연결을 닫거나 다른 요청들을 위해 재사용된다.
- 파이프라이닝이 활성화되면, 첫 번째 응답을 완전히 수신할 때까지 기다리지 않고 여러 요청을 보낼 수 있다.
- HTTP 파이프라이닝은 오래된 소프트웨어와 최신 버전이 공존하고 있는 기존의 네트워크 상에서 구현하기
어려운게 입증되었으며, 프레임안에서 보다 활발한 다중 요청을 보내는 HTTP/2로 교체되고 있다.
HTTP 메시지
- HTTP/1.1와 초기 HTTP 메시지는 사람이 읽을 수 있다. HTTP/2에서는 메시지들을 새로운 이진 구조인
프레임 안으로 임베드하여, 헤더의 압축과 다중화와 같은 최적화를 가능케 한다.
- 본래 HTTP 메시지의 일부분만이 이 버전의 HTTP 내에서 전송된다고 할지라도, 각 메시지의 의미들은
변화하지 않고 본래의 HTTP/1.1 요청을(가상으로) 재구성한다.
- HTTP/1.1 포맷 내에서 HTTP/2를 이해하는 것은 여전히 유용하다.
- HTTP 메시지의 두 가지 타입인 요청과 응답은 각자의 특성있는 형식을 가지고 있다.
- HTTP 요청의 예
GET / HTTP/1.1 ← 요청라인[Method(요청 방식) / URL(요청 URI) / Version(HTTP 버전)]
Accept: text/html, application/json, image/zip, */*
Accept-Language: ko
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Edge/15.15063
Accept-Encoding: gzip, deflate
Host: 192.168.211.55
Connection: Keep-Alive
Cache-Control: no-cache
- 요청은 다음의 요소들[요청라인][HTTP 헤더][공백][HTTP 바디]로 구성된다.
- 헤더와 메시지 바디 사이에 공백이 존재하고, 이 공백으로 헤더와 바디를 구분한다.
- 요청라인 이후, HTTP 헤더 정보들이 포함되고, 요청 라인과 헤더 정보 다음엔 메시지 바디가 위치
- 바디부분에 웹서버로 전달하고자 하는 사용자 데이터가 흔히 포함되고, 로그인 창에 아이디와 패스워드
를 입력하도록 전달할 때 이 바디 부분에 입력데이터를 포함하여 전송
- 요청라인
- HTTP 메서드 :
- 보통 클라이언트가 수행하고자 하는 동작을 정의한 GET, POST 같은 동사나 OPTINOS나 HEAD와
같은 명사
- 일반적으로 클라이언트 리소스를 가져오거나 HTML 폼의 데이터를 전송하려고 하지만 다른 경우
에는 다른 동작이 요구 될 수 있다.
- 가져오려는 리소스의 경로 :
- 예를 들면 프로토콜(HTTP://), 도메인(developer.mozilla.org), 또는 TCP 포트(80) 요소들을 제거한
리소스의 URL
- HTTP 프로토콜의 버전
- 서버에 대한 추가적인 정보를 전달하는 선택적 헤더들
- POST와 같은 몇 가지 메서드를 위한 전송된 리소스를 포함하는 응답의 본문과 유사한 본문
- HTTP 헤더
- HTTP는 클라이언트와 서버가 요청 또는 응답으로 부가적인 정보를 전송할 수 있도록 해준다.
- 헤더는 대소문자를 구분하지 않는 이름과 콜론':' 다음에 오는 값(줄 바꿈 없이)으로 이루어져 있다.
- 다른 것들은 IANA 레지스트리에 나열되어 있으며, 원본 컨텐츠는 RFC 4228에서 정의되었다.
- 헤더는 컨텍스트에 따라 그룹핑 될 수 있다.
- General header : 요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와 관련이
없는 데이터
- Request header : 패치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더
- Response header : 위치 또는 서버 자체에 대한 정보(이름, 버전등)와 같이 응답에 대한 부가적인
정보를 갖는 헤더
- Entity header : 컨텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 헤더
- 헤더는 또한 프록시의 처리 방법에 따라 그룹핑할 수도 있다.
- 종단간 헤더
- 반드시 메시지의 최종 수신자에게 전송되어야 한다. 요청에 대해서는 서버, 응답에 대해서는
클라이언트
- 중간 프록시는 반드시 종간 간 헤더가 수정되지 않은 상태로 재전송해야하며 캐시는 이를 반드시
저장해야 한다.
- 홉간 헤더
- 단일 전송-레벨 연결에서만 의미가 있으며 프록시에의해 재전송되거나 캐시되어서는 안된다.
- 이러한 헤더들은 다음과 같다. (Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization,
TE, Trailer, Transfer-Encoding, Upgrade)
- 홉간 헤더는 Connecction 일반 헤더를 사용해 설정될 수도 있다.
- HTTP 응답의 예
HTTP/1.1 200 OK
Date: Fri, 14 Jul 2018 05:24:24 GMT
Server: Apache/2.4.25 (Ubuntu)
Set-Cookie: PHPSESSID=6oufjf43migs432fsfmipodm1; path=/
Expires: Thu, 19 Nov 1981 09:42:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 3132
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitonal//EN” http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
<!--
Modified from the Debian original for Ubuntu
→
…
- HTTP 응답 [상태라인][헤더][공백][바디]
- 상태 라인은 다음 항목으로 구성된다 : HTTP 버전, 상태 코드, 응답 이유
- HTTP 프로토콜의 버전
- 요청의 성공 여부와, 그 이유를 나타내는 상태 코드
- 아무런 영향력이 없는 상태 코드와 짧은 설명을 나타내는 상태 메시지
- 요청 헤더와 비슷한 HTTP 헤더들
- 선택 사항으로 가져온 리소스가 포함되는 본문
HTTP 기반 API
- USER-AGENT와 서버간에 데이터를 교환하는데 사용 가능한 XMLHttpRequest API
최신 Fetch API는 보다 강력하고 유연한 기능을 제공
- 또 다른 API인 서버-전송 이벤트는 서버가 전송 메커니즘으로 HTTP를 사용하여 클라이언트로 이벤트를
보낼 수 있도록하는 단방향 서비스
- 클라이언트 EventSource 인터페이스를 사용하여 연결을 맺고 이벤트 핸들러를 설정
- 클라이언트 브라우저는 HTTP 스트림으로 도착한 메시지를 적절한 Event 객체로 자동 변환하여, 알려진
경우 해당 이벤트타입에 대해 등록된 이벤트 핸들러로 전달하거나 또는 특정 유형의 이벤트가 설정되지
않은 경우에는 onmessage이벤트 핸들러로 전달
'WEB > HTTP' 카테고리의 다른 글
| [HTTP] MIME 타입(개요,문법,웹 개발자들을 위한 MIME 타입) (0) | 2020.12.15 |
|---|