본문 바로가기
프론트엔드/HTTP - 후

An overview of HTTP

by 5ub1n 2024. 10. 13.

HTTP 개요

HTTP는 HTML문서와 같은 리소스를 가져오기 위한 프로토콜이다.

웹에서 일어나는 모든 데이터 교환의 기반이며 클라이언트-서버 프로토콜이다.

요청은 수신자(웹 브라우저)에 의해 시작된다.

완전한 문서는 텍스트, 레이아웃 설명, 이미지, 동영상, 스크립트 등 여러 하위 문서를 가져와서 재구성한다.

클라이언트(웹) - 서버

클라이언트와 서버는 개별로 데이터를 주고 받으면서 통신한다.

일반적으로 웹 브라우저라고 불리는 클라이언트가 보내는 메시지를 '요청'이라고 하고,

서버가 보내는 메시지를 '응답'이라고 한다.

개별로 주고 받으며 통신하는 것은 실시간 오디오 스트리밍과 같은 데이터 스트림과는 반대되는 개념이다.
데이터 스트림은 단방향 통신으로 요청과 응답이 따로 없고 한쪽이 끊임없이 데이터를 수신받는 것이다.
하지만 데이터 스트림은 메시지 기반 통신처럼 양방향 통신(채팅 애플리케이션)도 가능하다.
그저 메시지 기반 통신은 데이터 스트림의 단방향 통신이라는 개념과는 반대인 개념일 뿐이다.
클라이언트와 서버는 메시지 기반 통신, 데이터 스트림 두 개의 방식 모두 지원한다.

 

 

 

1990년대 초에 설계된 HTTP는 시간이 지남에 따라 발전해온 확장 가능한 프로토콜이다.

이것은 TCP를 통해 통신하거나 TLS로 암호화된 TCP 연결을 통해 전송한다.

원칙적으로 신뢰할 만한 어떠한 프로토콜을 사용해도 상관없다.

그리고 확장성이 뛰어나서 단순히 하이퍼텍스트 문서를 가져오는것 뿐만 아니라, 비디오나 동영상도 가져올 수 있다.

반대로 HTML 양식 결과같은 컨텐츠를 서버에 전송할 수도 있다.

또한, HTTP는 필요에 따라 웹페이지를 업데이트 하기 위해 문서의 일부를 가져올 때 사용되기도 한다.

 

HTTP기반 시스템의 구성요소 Components of HTTP-based systems

HTTP는 클라이언트-서버 프로토콜이다.

요청은 한 사용자 에이전트 혹은 이를 대신하는 프록시로부터 전송된다.

대부분의 사용자 에이전트는 웹 브라우저다.

하지만 검색 엔진 인덱스를 채우고 유지하기 위해 웹을 크롤링하는 봇등 무엇이든 사용자 에이전트가 될 수 있다.

 

각각의 요청은 서버로 전송되고 서버는 요청을 처리해서 응답이라는 답변을 제공한다.

클라이언트와 서버 사이에는 프록시라고 통칭되는 엔티티들이 있다.

이 프록시라는 엔티티들은 다양한 작업들을 수행하고 게이트웨이 또는 캐시 등의 역할을 한다.

 

 

클라이언트와 서버 사이의 프록시들

 

실제로 브라우저와 요청을 처리하는 서버 사이에는 라우터, 모뎀 등 더 많은 컴퓨터들이 존재한다.

웹의 계층적 설계 덕분에 많은 컴퓨터들은 네트워크 및 전송 계층에 숨겨져있다.

HTTP는 애플리케이션 계층의 맨 위에 있다.

네트워크 문제를 진단하는 데 중요하지만, 대부분의 기본 계층은 HTTP 설명과 무관하다.

 

클라이언트 : 사용자 에이전트 Client : user-agent

사용자 에이전트는 사용자를 대신하여 작동하는 도구이다.

이 역할은 주로 웹브라우저가 수행한다.

하지만 엔지니어와 웹 개발자가 애플리케이션을 디버깅하기 위해 사용한 프로그램에서도 수행될 수 있다.

 

브라우저는 항상 요청을 시작하는 엔티티다.

서버는 절대 요청을 먼저 시작하는 주체가 아니다.

(서버에서 시작된 메시지를 시뮬레이션하기 위해 수년간에 걸쳐 몇 가지 메커니즘이 추가되었긴 했다.)

 

웹 페이지를 표시하기 위에 브라우저는 페이지를 나타내는 HTML 문서를 가져올려고 요청을 보낸다.

그 다음 이 파일을 구문 분석하여 실행 스크립트, 표시할 레이아웃 정보(CSS), 페이지에 포함된 여러 하위 리소스(일반적으로 이미지 및 동영상)에 대한 추가 요청을 보낸다.

그러고 나면, 이 리소스를 결합해 완전한 문서인 웹 페이지를 표시한다.

브라우저에서 실행되는 스크립트는 이후에 더 많은 리소스를 가져올 수 있고, 브라우저는 그에 맞게 웹 페이지를 업데이트한다.

 

웹 페이지는 하이퍼텍스트 문서다.

즉, 표시된 콘텐츠 일부분이 링크이며, 일반적으로 마우스클릭으로 활성화하고 새 웹페이지를 가져오면 사용자가 사용자 에이전트에 지시를 내려 웹을 탐색할 수 있다.

브라우저는 이러한 지시를 HTTP 요청으로 변환하고 HTTP 응답을 추가로 해석하여 사용자에게 명확한 응답을 표시해준다.

 

웹 서버 The Web server

통신 채널의 반대편에는 클라이언트의 요구에 따라 문서를 제공해주는 서버가 있다.

서버는 사실상 단일 가상 머신으로 나타난다.

하지만 아마 실제로는 부하 분산을 공유하는 여러 서버들의 모임일 수도 있고, 요구에 따라 문서를 전체적 또는 부분적으로 생성하는 다른 소프트웨어(캐시, 데이터베이스서버, 전자상거래 서버)일 수도 있다.

 

서버는 반드시 단일 머신일 필요는 없다.

동일한 컴퓨터에서 여러 서버 소프트 인스턴스가 호스팅될 수 있다.

HTTP/1.1과 Host 헤더를 사용하면 동일한 IP 주소를 공유할 수 있다.

 

프록시 Proxies

웹 브라우저와 서버 사이에는 수많은 컴퓨터와 시스템들이 HTTP 메시지를 중계한다.

웹 스택의 계층적 구조로 인해, 이들 대부분은 전송, 네트워크 및 물리적 수준에서 작동한다.

그리고 HTTP 계층에서 투명해지고 잠재적으로 성능에 상당한 영향을 미친다.

애플리케이션 계층에서 작동하는 것을 일반적으로 프록시라고 한다.

프록시는 어떤 방식으로든 요청을 변경하지 않고 수신한 요청을 전달하는 투명 프록시일 수도 있고,

서버로 요청을 전달하기 전에 어떤 방식으로든 요청을 변경하는 비투명 프록시일 수도 있다.

 

프록시는 다양한 기능을 수행한다.

 

  • 캐싱(캐시는 브라우저 캐시처럼 공개 또는 비공개일 수 있음)
  • 필터링(안티바이러스 검사, 자녀 보호 기능)
  • 인증(다양한 리소스에 대한 엑세스 허용)
  • 로깅(기록 정보 저장 허용)
  • 로드 밸런싱(여러 서버가 서로 다른 요청을 처리할 수 있도록 허용)

 

HTTP의 기본 측면 Basic aspects of HTTP

HTTP는 간단하다 HTTP is simple

HTTP는 일반적으로 간순하고 사람이 읽을 수 있도록 설계되었다.

하지만 HTTP/2에서 HTTP 메시지를 프레임으로 캡슐화하여 복잡성이 추가되었다.

HTTP 메시지는 사람이 읽고 이해할 수 있어 개발자에게는 좀 더 쉬운 테스트를 제공한다.

초보자에겐 복합성을 줄여준다.

 

확장 가능한 HTTP HTTP is extensible

HTTP/1.0에 도입된 HTTP 헤더는 이 프로토콜을 쉽게 확장하고 쉽게 실험할 수 있게 해준다.

클라이언트와 서버간의 새로운 헤더에 대한 간단한 합의만으로 새로운 기능을 도입할 수 있다.

 

HTTP는 상태가 없지만, 세션이 없는 것은 아니다 HTTP is stateless, but not sessionless

HTTP는 상태가 없다 : 동일한 연결상에서 두 요청이 연속으로 수행되는 동안 두 요청 사이에는 아무런 연결고리가 없다.

이는 이커머스 장바구니를 사용하는 등 특정 페이지와 일관성 있게 상호 작용하려는 사용자에게 문제가 될 수 있다.

HTTP의 핵심은 상태가 없는것이지만, 쿠키를 사용하면 상태를 유지할 수 있다.

헤더 확장을 통해 워크플로우에 HTTP 쿠키가 추가되고 각 HTTP 요청마다 세션을 생성하여 동일한 컨텍스트 또는 동일한 상태를 공유할 수 있게 된다.

 

HTTP와 연결들 HTTP and connections

연결은 전송 계층에서 제어되기 때문에 기본적으로 HTTP의 범위를 벗어난다.

HTTP에서는 연결 기반의 기본 전송 프로토콜을 요구하지 않는다.

오직 신뢰할 수 있거나 메세지를 잃어버리지 않게만 요구한다. 

(적어도 메시지를 잃어버리는 경우만큼은 오류를 표시해준다.)

인터넷에서 가장 널리 사용되는 두 가지 전송 프로토콜 중 TCP는 신뢰할 수 있지만, UDP는 그렇지 않다.

그러므로 HTTP는 TCP(연결 기반) 표준에 의존한다.

 

클라이언트와 서버가 HTTP 요청/응답 한 쌍을 서로 교환하기 전에 TCP 연결을 설정해야 한다.

이 TCP 연결을 설정하는 프로세스는 여러번의 라운드 트립(여러번의 왕복)이 필요하다.

HTTP/1.0의 기본 동작은 각 HTTP 요청/응답 한 쌍마다 별도의 TCP 연결을 여는 것이다.

이는 여러 요청이 연속적으로 전송될 때, 단일 TCP 연결을 공유하는 것보다 덜 효율적이다.

 

이 결함을 완화하기 위해 HTTP/1.1에서는 구현하기 어려웠던 파이프라이닝과 지속적인 연결을 도입했다.

지속적인 연결은 Connection 헤더를 사용하여 기본 TCP 연결을 부분적으로 제어할 수 있다.

HTTP/2는 한 걸음 더 나아가 단일 연결을 통해 메세지를 다중화하여 연결을 따듯하고 효율적으로 유지할 수 있도록 도와주었다.

 

HTTP에 더 적합하고 더 나은 전송 프로토콜을 설계하기 위한 실험이 진행중이다.

예를 들어, Google은 더욱 신뢰성 있고 효율적인 전송 프로토콜을 제공하기 위해 UDP를 기반으로 하는 QUIC를 실험하고 있다.

 

 HTTP로 제어할 수 있는 것 What can be controlled by HTTP 

시간이 지남에 따라 HTTP의 확장성 덕분에 웹을 더 많이 제어할 수 있고 더 많은 기능을 수행할 수 있게 되었다.

캐시 및 인증 메서드는 HTTP 역사 초기에 처리된 기능이다.

반면에 출처 제약 조건을 완화하는 기능은 2010년대에 추가되었다.

 

아래는 HTTP로 제어할 수 있는 일반적인 기능들이다.

 

  • 캐싱 : 문서가 캐시되는 것을 HTTP로 제어할 수 있다.
    서버는 프록시와 클라이언트에게 무엇을 캐시하고 얼마나 오래 캐시할 것인지 지시할 수 있다.
    클라이언트는 중간 캐시 프록시에게 그 프록시에 저장된 문서를 무시하도록 지시할 수 있다.
  • 출처 제한 완화 : 스누핑 및 기타 개인정보 침해를 방지하기 위해 웹 브라우저는 웹사이트들을 엄격하게 분리한다.
    오직 똑같은 출처(같은 도메인)의 페이지만이 웹페이지의 모든 정보들을 엑세스할 수 있다.
    이러한 제약 조건은 서버에 부담이 되지만, HTTP 헤더가 서버측의 엄격한 분리를 완화하여 문서가 다른 도메인들로부터 가져온 정보의 조합이 될 수 있게 한다.엄격하게 분리하는 것에 관해 보안과 관련된 이유가 있을 수도 있다.
서버에서 다양한 정책과 보안 규칙을 적용하여 웹사이트의 리소스를 암격하게 관리하고 분리하는 것과 제한을 풀기 위해 서버에서 HTTP 헤더를 통해 제한을 일부 완화해주는 것은 서로 다른 개념이다.
평소에는 보안때문에 서버측에서 웹사이트를 엄격하게 관리하지만 간혹가다 제한을 완화해야 할 특정한 상황이 오면 HTTP 헤더를 사용한다.

출처 제한 완화 ( Relaxing the origin constraint ) 는 A 웹사이트에서 가져온 정보를 B 웹사이트에서도 사용할 수 있게 보안 규칙을 완화해주는 것이다.
이렇게 하면 다른 웹사이트들끼리 자유롭게 정보를 주고 받을 수 있다.
예를들어 여러 웹사이트들의 서비스를 조합하거나, 다양한 소스에서 정보를 모아 사용할 수 있다.
또한, 자세한 기능과 상호작용을 가능하게 하여 사용자에게 더 다양하고 풍부한 경험을 제공할 수 있게 해준다.

 

  • 인증 : 일부 페이지들은 특정 사용자만 접근할 수 있도록 보호될 수 있다.
    기본 인증은 HTTP를 통해 제공될 수 있는데, WWW-Authenticate 및 유사한 헤더를 사용하거나 HTTP 쿠키를 이용하여 특정 세션을 설정하는 방식으로 제공될 수 있다.
WWW-Authenticate 헤더는 웹 서버가 → 클라이언트에게 "이 요청을 수락하려면 인증이 필요하다"라고 알리는 역할을 한다.
클라이언트는 이 헤더를 받으면 서버에서 제공한 특정 방식으로 자신을 인증해야 한다.

간단한 예시 

1. Basic Authentication
서버가 클라이언트에게 아래와 같이 말한다고 가정한다.
WWW-Authenticate: Basic realm="My Website"
"내 웹사이트에 접속하려면 기본 인증이 필요하다" 라고 서버가 말한다.
클라이언트는 사용자 이름과 비밀번호를 Base64로 인코딩하여 서버에 보내야 한다.

2. Digest Authentication
서버가 클라이언트에게 아래와 같이 말한다고 가정한다.
WWW-Authenticate: Digest realm="My Website", qop="auth", nonce="123456", opaque="789012"
"내 웹사이트에 접속하려면 암호화되나 방식으로 정보를 보내야 한다" 라고 서버가 말한다.
클라이언트는 암호화된 정보를 생성하여 서버에 전달해야 한다.

3. Bearer Token Authentication (OAuth 2.0)
서버가 클라이언트에게 아래와 같이 말한다고 가정한다.
 
WWW-Authenticate: Bearer realm="My API", error="invalid_token", error_description="The access token expired"
"내 API에 접속하려면 토큰을 제대로 포함시켜야 한다"라고 서버가 말한다.
클라이언트는 발급받은 토큰을 요청에 포함시켜야 한다.

요약하면, WWW-Authenticate 헤더는 서버가 클라이언트에게 어떤 방식으로 인증을 해야 하는지 알려주는 표지판이라고 생각하면 된다.

HTTP 쿠키 (웹 쿠키, 브라우저 쿠키) 는 서버가 사용자의 웹 브라우저에 보내는 작은 데이터 조각이다.
브라우저는 쿠키를 저장했다가 나중에 요청할 때 동일한 서버로 다시 보낼 수 있다.
일반적으로 HTTP 쿠키는 두 요청이 동일한 브라우저에서 오는지 확인하는 데 사용된다.(예: 사용자 로그인 유지)

 

  • 프록시 및 터널링 : 서버나 클라이언트는 종종 인트라넷에 위치하여 다른 컴퓨터로부터 실제 IP 주소를 숨긴다.
    그런 다음 HTTP 요청들은 프록시를 통해 인트라넷의 네트워크 방화벽을 통과한다.
    그렇다고 해서 모든 프록시가 HTTP의 프록시인건 아니다.
    예를 들어, SOCKS 프로토콜은 더 낮은 수준에서 작동한다.
    FTP와 같은 다른 프로토콜에서도 이러한 프록시에 의해 처리될 수 있다.
인터넷의 서로 다른 여러 네트워크를 탐색할 때, 프록시 서버와 HTTP 터널은 월드 와이즈 웹의 콘텐츠에 쉽게 접근할 수 있도록 도와준다.
프록시는 사용자의 로컬 컴퓨터 또는 사용자의 컴퓨터와 인터넷상의 대상 서버 사이의 어느 곳이든 위치해 있을 수 있다.

 

  • 세션 : HTTP 쿠키를 사용하면 서버 상태와 요청을 연결할 수 있다.
    이렇게 하면 상태를 저장하지 않는 HTTP에서도 세션이 생성된다.
    이것은 전자상거래 쇼핑 장바구니뿐만아니라, 사용자가 출력 구성할 수 있는 어떠한 사이트에서도 매우 유용하다.

 

HTTP 흐름 HTTP flow

클라이언트가 서버(최종 서버 혹은 중간 프록시)와 통신을 하는 경우, 다음 단계들을 수행한다.

  1.  TCP 연결 열기 : TCP 연결은 하나 이상의 요청을 보내고 답변을 받는 데 사용된다.
    클라이언트는 새 연결을 열거나, 기존의 연결을 재사용하거나, 서버로 여러 TCP 연결을 열 수 있다.
  2. HTTP 메시지 보내기 : HTTP/2 이전의 HTTP 메시지들은 사람이 읽을 수 있다.
    HTTP/2에서는 이러한 간단한 메시지들을 프레임으로 캡슐화하여 직접 읽을 수 없지만, 원칙은 동일하다.
    예를 들어 : 
    GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr
  3. 다음과 같이 서버에서 보낸 응답을 읽는다.
    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)
  4. 추가 요청을 위해 연결을 재사용하거나 닫는다.

HTTP 파이프라이닝이 활성화되면 첫번째 요청이 완전히 수신되길 기다리지 않고 여러 요청을 전송할 수 있다.

HTTP 파이프라이닝은 최신 버전과 공존하는 오래된 소프트웨어 조각이 있는 네트워크에서는 구현하기 어려운걸로 입증되었다.

HTTP 파이프라이닝은 HTTP/2의 프레임안에서 더 견고한 멀티플렉싱 요청으로 대체되었다.

 

HTTP 메시지 HTTP Messages

HTTP/1.1 및 그 이전 버전에서는 HTTP 메시지들을 사람이 읽을 수 있었다.

HTTP/2에서는 이러한 메시지들이 2진 구조인 프레임에 내장되어 있어 헤더 압축 및 멀티플렉싱과 같은 최적화가 가능해졌다.

이 버전의 HTTP에서는 원본 HTTP 메시지의 일부만 전송되더라도 각 메시지의 의미는 변하지 않으며, 클라이언트는 원본 HTTP/1.1 요청을 (가상으로) 재구성한다.

따라서 HTTP/1.1 형식으로 HTTP/2 메시지를 이해하는 것이 유용할 것이다.

클라이언트가 HTTP/2로부터 받은 메시지를 HTTP/1.1 요청으로 재구성하는 이유는 기존의 HTTP/1.1 인프라(네트워크 상의 다양한 장치 및 서버)와의 호환성을 유지하기 위해서이다.

 

HTTP 메시지에는 요청과 응답이라는 두 가지 유형이 있으며, 각각 고유한 형식이 있다.

 

요청 Requests

HTTP 요청 예시 :

기본적인 HTTP 요청

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

 

  • HTTP 메서드(Method, 일반적으로 GET, POST와 같은 동사 혹은 OPTION, HEAD와 같은 명사)는 클라이언트가 수행하고자 하는 작업을 정의한다.
    다른 경우에는 더 많은 작업이 필요할 수 있지만, 일반적으로 클라이언트는 리소스를 가져오거나(GET 사용) HTTP 양식의 값을 게시(POST 사용)할려고 한다.
  • 가져올 리소스의 경로(Path)는 문맥에서 명확한 요소로부터 제거된 리소스의 URL이다. 예를 들어, 프로토콜(http://), 도메인(여기서는 developer.mozilla.org) 또는 TCP 포트(여기서는 80, 브라우저는 기본적으로 80번 포트를 사용)를 제외한 부분이다.
  • HTTP 프로토콜의 버전(Version of the protocol)이다.
  • 서버에 대한 추가 정보를 전달하는 선택적 헤더(Headers)다.
  • POST와 같은 몇 가지 메서드를 위한 본문(body)으로, 전송된 리소스를 포함하는 응답과 유사하다.
예를 들어, 웹 애플리케이션에서 사용자가 회원 가입 양식을 작성하고 제출하는 경우, 사용자는 이 양식을 작성하고 "가입" 버튼을 클릭하면 클라이언트는 서버에 POST 요청을 보낸다.
이 POST 요청의 본문에는 사용자가 입력한 이름, 이메일, 비밀번호 등의 정보가 포함된다.
이 정보들은 사용자가 제출한 리소스라고 볼 수 있다.
서버가 POST 요청을 받으면 사용자가 제출한 정보를 처리하고, 회원 가입 과정을 완료한다.
이후 서버는 회원 가입이 성공적으로 완료했음을 나타내는 응답을 클라이언트에게 보낸다.
이 응답의 본문에는 일반적으로 회원 가입이 성공적으로 완료되었다는 메시지나 사용자의 고유 ID와 같은 추가 정보가 포함될 수 있다.
따라서 POST 요청과 이에 대한 응답은 서로 유사한 형태의 본문을 가질 수 있다.
POST 요청의 본문은 클라이언트가 서버로 전송하는 리소스(회원 가입 양식의 정보 : 이름, 이메일, 비밀번호 등)를 포함하고, 그에 대한 응답의 본문은 서버가 클라이언트에게 반환하는 데이터나 메시지를 포함한다.

 

응답 Responses

응답 예시 :

HTTP 응답 이미지

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

 

  • 사용하는 HTTP 프로토콜의 버전(Version of the protocol)
  • 응답이 성공했는지 아닌지, 그리고 그 이유를 나타내는 상태 코드(Status code)다.
  • 상태 코드의 비공식적인 짧은 설명인 상태 메시지(Status message)다.
  • 요청에 대한 헤더와 비슷한 HTTP 헤더(Headers)다.
  • 선택 사항으로, 가져온 소스를 포함하는 본문이다.

 

HTTP 기반 API APIs based on HTTP

자바 스크립트에서 HTTP 요청만드는데 사용할 수 있는 Fetch API는 가장 흔하게 사용되는 HTTP 기반 API이다.

Fetch API는 XMLHttpRequest를 대체한다.

 

또 다른 API인 서버 전송 이벤트는 HTTP를 전송 메커니즘으로 사용하여 서버가 클라이언트에 이벤트를 보낼 수 있게 하는 단방향 서비스다.

클라이언트는 EventSource 인터페이스를 사용하여 연결을 열고 이벤트 핸들러를 설정한다.

클라이언트 브라우저는 HTTP 스트림에 도착하는 메시지를 적절한 이벤트 객체로 자동 변환한다.그런 다음 이미 알려진 이벤트 유형이 등록된 이벤트 핸들러에 전달하거나, 혹은 설정되지 않은 특정 유형의 이벤트 핸들러일 경우 onmessage 이벤트 핸들러로 전달한다.

 

결론 Conclusion

HTTP는 사용하기 쉬운 확장 가능한 프로토콜이다.

클라이언트-서버 구조와 헤더 추가 기능이 결합되면 웹의 확장된 기능과 함께 HTTP가 발전할 수 있다.

 

HTTP/2는 성능을 향상시키기 위해 프레임에 HTTP 메시지를 삽입하여 약간의 복잡성을 추가했지만, 메시지의 기초 구조는 HTTP/1.0 이후 동일하게 유지되었다.

세션 흐름(클라이언트-서버 간의 통신 구조)은 단순하게 유지되어, 간단한 HTTP 메시지 모니터로 조사하고 디버깅 할 수 있다.

 

 

An overview of HTTP - HTTP | MDN

HTTP is a protocol for fetching resources such as HTML documents. It is the foundation of any data exchange on the Web and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser. A complete document is

developer.mozilla.org

 

'프론트엔드 > HTTP - 후' 카테고리의 다른 글

HTTP caching  (0) 2024.12.01
Compression in HTTP  (0) 2024.10.13
MIME types (IANA media types)  (0) 2024.10.13
HTTP Messages  (0) 2024.10.13
A typical HTTP session  (0) 2024.10.13

관련글

티스토리툴바