1990년대 팀버너스리가 Web
을 고안했을 때, 웹에는 4가지 핵심 요소가 있었다.
HTTP
World Wide Web
의 기초이며 TCP/IP 기반에서 클라이언트와 서버(호스트)가 서로 통신하는 방법을 표준화하는 애플리케이션 계층 프로토콜 이다.
HTTP
는 콘텐츠가 인터넷을 통해 요청되고 전송되는 방식을 정의한다.웹 브라우저와 웹 서버 사이에는 라우터, 모뎀 등 많은 컴퓨터가 있다.
웹의 계층화로 이것들은 네트워크 및 전송 계층에 숨어 있다.
HTTP
는 애플리케이션 계층 맨 위에 있다.HTTP
는 네트워크에서 중요하지만, 다른 계층들은 대부분 HTTP
와 관련이 없다.HTTP
는 웹에서 클라이언트가 서버에 요청(Request)을 보낸 다음 서버가 응답(Response)하는 것을 포함하는 클라이언트-서버 프로토콜
이다.
클라이언트와 서버 사이에는 서로 다른 작업을 수행하는 Proxy(프록시)
라고 하는 수많은 엔터티가 존재한다.
사용자 에이전트(혹은 프록시)
라는 하나의 엔터티에 의해 전송된다.웹 브라우저(클라이언트) : 사용자가 요청한 정보를 웹 서버에게 요청하고, 응답 정보를 화면에 그려주는 것
웹 서버 : 정보를 응답해주는 것개발자 도구의 Network 탭에서 웹 브라우저, 웹 서버가 어떤 통신을 하고 있는지 확인할 수 있다.
GET
사용으로 액세스 가능POST
, HEAD
메소드 추가
요청/응답 형식 변경
HTTP
헤더가 요청 및 응답 모두에 추가됨이미지, 비디오 파일, 일반 텍스트 또는 기타 콘텐츠 유형과 같은 다른 응답 형식 처리
연결 당 여러 요청 불가
Three-way Handshake
로 느린 시작HTTP
는 stateless
프로토콜PUT
, PATCH
, OPTIONS
, DELETE
추가Connection: close
헤더를 보내
Content-Length
: 응답이 끝나는 위치를 식별하고 다음 응답을 기다리기 시작할 수 있는 헤더
Content-Length
로 지속적인 연결, 파이프라이닝의 이점을 얻을 수 있다.
Q. 그런데 데이터가 동적이고 서버가 미리 콘텐츠 길이를 찾을 수 없으면 어떻게 될까?
Content-Length
를 각 청크에 대해 추가Transfer-Encoding: chunked
Q. 요청이 파이프라인에 멈춰 기다리는 경우(head-of-line blocking
),
어떻게 극복할까?
use of spritesheets
encoded images in CSS
single humungous CSS/Javascript files
domain sharding
...콘텐츠의 저지연 전송
주요 기능
HTTP/2
의 서버 푸시가 실제로 제대로 동작하지 않고, 우선 순위는 때때로 잘못 구현되는 등의 문제들이 있다.
HTTP/3
가 필요할까?
TCP
는HTTP
와 같은 다른 프로토콜에 대한 안정성 및 순서 전달과 같은 중요한 서비스를 제공하는 주요 프로토콜이다.
각 사용자의 대역폭 사용량을 공정하게 제한해 많은 동시 사용자가 인터넷을 계속 사용할 수 있는 이유 중 하나이다.
HTTP(S)
를 사용할 때 HTTP
외에 여러 프로토콜을 동시에 사용하고 있으며, 이 스택의 각 프로토콜에는 고유한 기능과 책임이 있다.
프로토콜의 계층화
는 해당 기능을 쉽게 재사용할 수 있도록 하기 위해 수행된다. 인터넷의 대부분의 애플리케이션은 내부적으로 TCP를 사용하여 모든 데이터가 완전히 전송되도록 하므로
TCP는 인터넷에서 가장 널리 사용되고 배포된 프로토콜 중 하나이다.
실제로
HTTP/3
에 기대하는 주요 기능(더 빠른 연결 설정, 더 적은 HoL 차단, 연결 마이그레이션 등)은 모두QUIC
에서 제공된다.
QUIC
가 필요할까?handshake
로 인한 지연HoL(Head of Line)
- 단일 파일 데이터 TCP 패킷이 손실되면 그 패킷이 복구될 때까지 다른 모든 파일도 지연된다.QUIC
란 무엇일까?QUIC
는 UDP
위에서 실행된다.
UDP는 가능한 가장 기본적인 전송 프로토콜이다. 소위 포트 번호 외에 어떤 기능도 제공하지 않는다. 때문에 TCP가 가진 문제점이 발견되지 않는다.
TCP
를 강력하고, 대중적이지만, 느린 프로토콜로 만드는 기능들을 UDP
로 다시 구현한다.
QUIC
의 특징
흐름 제어
, 정체 제어 메커니즘
을 사용한다. 이러한 기능을 TCP
보다 더 성능이 좋은 방식으로 구현한다.QUIC
의 주요 변경 사항
QUIC
는 TLS(전송 계층 보안 프로토콜)
와 긴밀하게 통합된다.QUIC
는 기존 TLS 1.3 자체를 직접 사용(캡슐화)한다. (서로 분리할 수 없음)QUIC
는 여러 개의 독립적인 바이트 스트림을 지원한다.
QUIC
는 연결 ID를 사용한다.
QUIC
는 프레임을 사용한다.
- 주로 웹 브라우저를 말한다.
- 브라우저는 항상 요청을 시작하는 엔터티이다.
HTTP 요청
으로 변환하고 HTTP 응답
을 추가로 해석해 사용자에게 명확한 응답을 제공한다.script
, css
, resource
들을 추가 요청한다.
- 서버는 클라이언트가 요청한 문서를 제공한다.
- 요청시 문서의 전체 또는 부분을 생성한다.
HTTP/1.1
과Host 헤더
를 사용하면 동일한 IP 주소를 공유할 수 있다.
웹 브라우저와 서버 사이에서 수많은 컴퓨터와 기계가 HTTP 메시지를 중계한다.
애플리케이션 계층에서 작동하는 것을 일반적으로 프록시
라고 하는데,
다음과 같은 기능은 수행한다.
간단하다.
HTTP 메시지를 프레임으로 캡슐화해
HTTP/2에 추가된 복잡성에도 불구하고 간단하고 읽기 쉽게 설계되었다.
개발자에게 더 쉬운 테스트를 제공하고
신규 사용자에게 복잡성을 줄인다.
확장 가능하다.
HTTP/1.0에 도입된 HTTP 헤더를 사용하면
프로토콜을 쉽게 확장할 수 있다.
헤더를 추가하는 기능과 클라이언트-서버 구조를 통해
HTTP는 웹의 확장된 기능과 함께 발전할 수 있다.
HTTP는 stateless지만 sessionless는 아니다.
HTTP는 stateless이다. 연속적인 두 요청 사이에 관계가 없다.
하지만 HTTP 쿠키는 상태 저장 session을 허용하며,
각 HTTP 요청에 대한 세션 생성이 동일한 컨텍스트 또는 동일한 상태를 공유할 수 있다.
HTTP 및 연결
연결은 전송 계층에서 제어되므로 근본적으로 HTTP의 범위를 벗어난다.
HTTP는 기본 전송 프로토콜이 연결 기반일 필요 없다.
HTTP는 연결 기반이며 신뢰할 수 있는 TCP 표준에 의존한다.
클라이언트와 서버가 HTTP 요청/응답을 교환하기 전에
TCP 연결을 설정해야 한다.
HTTP/1.0은 각 HTTP 요청/응답에 별도의 TCP 연결을 생성한다.
(여러 요청이 연속적으로 전송될 때 단일 TCP 연결을 공유하는 것보다 덜 효율적)
더 나은 전송 프로토콜 설계를 위해 Google은 UDP 기반의 QUIC을 실험하고 있다.
캐싱 문서가 캐시되는 방식
동일한 출처의 페이지만 웹 페이지의 모든 정보에 액세스할 수 있다.
인증 페이지는 특정 사용자만 액세스할 수 있다.
WWW-Authenticate
, HTTP 쿠키를 사용하는 특정 세션을 세팅하는 것으로 기본적인 인증을 제공할 수 있다.프록시와 터널링
세션 HTTP 쿠키를 사용하면 요청을 서버 상태와 연결할 수 있다.
클라이언트가 서버(최종 서버 또는 중간 프록시)와 통신하려는 경우 다음 단계를 수행한다.
TCP 연결 열기
HTTP 메시지 보내기
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: kr
서버에서 보낸 응답을 읽는다.
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 come the 29769 bytes of the requested web page)
HTTP/2에서 HTTP 메시지는 이진 구조인 프레임에 포함되어 헤더 압축 및 다중화와 같은 최적화를 허용한다.
이 버전의 HTTP에서 원래 HTTP 메시지의 일부만 전송되더라도 각 메시지의 의미는 변경되지 않고 클라이언트는 원래 HTTP/1.1 요청을 (가상적으로) 재구성하므로 HTTP/1.1 형식의 HTTP/2 메시지를 이해하는 것이 유용하다.
HTTP 메시지에는 요청과 응답의 두 가지 유형이 있으며 각각 고유한 형식이 있다.
HTTP Request
웹 브라우저와 같은 인터넷 통신 플랫폼이 웹사이트를 로드하는데 필요한 정보를 요청하는 방식
HTTP Request
에는 다음이 포함된다.
HTTP 프로토콜의 버전
HTTP Request Header
키-값 쌍에 저장된 텍스트 정보가 포함되어 있으며, 모든 HTTP 요청 및 응답에 포함된다.
클라이언트가 어떤 브라우저를 사용하고 있으며 어떤 데이터가 요청되고 있는지와 같은 핵심 정보를 전달한다.
request line
request headers
공백 라인
Host : 요청하는 웹 서버의 주소
User Agent : 웹 브라우저
Accept-Language : gzip, deflate, br
HTTP Response
웹 클라이언트(브라우저)가 HTTP 요청에 대한 응답으로 인터넷 서버에서 받는 것
이러한 응답은 HTTP 요청에서 요청된 내용을 기반으로 중요한 정보를 전달한다.
HTTP Response
에는 다음이 포함된다.HTTP 프로토콜 버전
HTTP 상태 코드
Fetch API
HTTP 기반으로 가장 많이 사용되는 API는 사용자 에이전트와 서버에 XMLHttpRequest 간의 데이터 교환에 사용할 수 있는 API이다.
server-sent-events
HTTP를 전송 메커니즘으로 사용하여 서버가 클라이언트에 이벤트를 보낼 수 있도록 하는 단방향 서비스
stateless
프로토콜이며, 각 명령이 독립적으로 실행된다.
와 http 이 게시글만 있으면 마스터 가능하군요,,