HTTP/Guides/Overview of HTTP

김동현·2026년 3월 22일
Web Technologydocs

mdn 학습 번역 - Web Technology

목록 보기
4/28

HTTP 개요 (Overview of HTTP)

HTTP(HyperText Transfer Protocol)는 HTML 문서와 같은 다양한 리소스를 가져오기 위해 사용하는 프로토콜(규칙)이에요.
웹에서 이루어지는 모든 데이터 교환의 가장 튼튼한 기초가 되죠. HTTP는 클라이언트-서버 프로토콜인데요, 이 말은 데이터 요청(Request)을 받는 쪽이 아니라 보통 웹 브라우저 같은 수신자(클라이언트) 측에서 먼저 요청을 시작한다는 뜻입니다.
우리가 보는 완전한 형태의 웹 문서는 보통 텍스트 콘텐츠, 레이아웃 정보(CSS), 이미지, 비디오, 스크립트(JavaScript) 등 여러 가지 다양한 리소스들이 합쳐져서 만들어집니다.

여러 서버에서 가져온 여러 리소스로 구성된 단일 웹 문서

클라이언트(브라우저)와 서버는 데이터 스트림(연속된 흐름)이 아니라, 개별적인 메시지를 교환하며 소통해요.
클라이언트가 서버로 보내는 메시지를 요청(Requests)이라고 부르고, 서버가 그에 대한 대답으로 보내는 메시지를 응답(Responses)이라고 부릅니다.

응용 계층 프로토콜인 HTTP. TCP(전송 계층)와 IP(네트워크 계층) 위에 있고 표현 계층 아래에 위치함.

1990년대 초에 처음 설계된 HTTP는 시간이 흐르면서 계속 발전해 온 확장 가능한 프로토콜이에요.
HTTP는 애플리케이션(응용) 계층의 프로토콜로, 보통 TCP를 통하거나 암호화된 TLS 연결을 거친 TCP 위에서 전송됩니다. (물론 이론적으로는 신뢰할 수 있는 전송 프로토콜이라면 무엇이든 사용할 수 있어요!)
HTTP는 확장이 아주 유연하기 때문에 단지 하이퍼텍스트(HTML) 문서만 가져오는 게 아니라, 이미지나 비디오를 가져올 때도 쓰이고, HTML 폼(Form) 결과처럼 서버로 우리 데이터를 보낼(Post) 때도 사용됩니다.
또한 웹 페이지 전체를 새로고침 하지 않고 필요한 부분만 업데이트하기 위해 문서의 일부분만 쏙쏙 가져올 때도 HTTP가 쓰인답니다. (이게 바로 우리가 흔히 아는 AJAX 기술의 핵심이죠!)

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

HTTP는 클라이언트-서버 프로토콜이라고 했죠? 요청은 항상 단일 개체인 사용자 에이전트(User-agent)(또는 사용자를 대신하는 프록시)에 의해 전송됩니다.
대부분의 경우 이 사용자 에이전트는 '웹 브라우저'이지만, 때로는 검색 엔진의 인덱스를 채우고 유지하기 위해 웹을 돌아다니며 데이터를 수집하는 크롤러 봇 같은 프로그램이 될 수도 있어요.

각각의 개별 요청은 서버로 전송되고, 서버는 그 요청을 처리한 뒤 응답(Response)이라는 대답을 클라이언트에게 돌려줍니다.
클라이언트와 서버 사이에는 프록시(proxies)라고 불리는 수많은 중간 개체들이 존재해요. 이 프록시들은 게이트웨이나 캐시(caches) 역할을 하면서 아주 다양한 작업들을 수행합니다.

클라이언트에서 보낸 HTTP 요청이 여러 프록시를 거쳐 서버로 전달되고, 응답이 같은 경로를 거쳐 다시 클라이언트로 돌아오는 모습.

실제로는 브라우저와 요청을 처리하는 서버 사이에 더 많은 컴퓨터들(라우터, 모뎀 등)이 존재해요.
하지만 웹의 '계층화된 설계' 덕분에 이런 복잡한 장비들은 네트워크 계층이나 전송 계층 아래로 숨겨져 있죠.
HTTP는 이 구조의 맨 꼭대기인 '애플리케이션 계층'에 위치합니다.
아래 계층들은 네트워크 문제를 진단할 때는 중요하지만, 우리가 HTTP 자체를 이해하고 설명하는 데에는 크게 신경 쓰지 않아도 괜찮답니다.

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

사용자 에이전트(user-agent)는 사용자를 대신해서 행동하는 모든 도구를 뜻해요.
주로 웹 브라우저가 이 역할을 맡지만, 우리 같은 프론트엔드 개발자나 엔지니어들이 프로그램을 디버깅할 때 쓰는 도구(예: Postman 등)도 사용자 에이전트가 될 수 있습니다.

여기서 중요한 점! 항상 브라우저가 먼저 요청을 시작(Initiate)합니다.
서버가 먼저 우리 브라우저로 뜬금없이 요청을 보내는 일은 없어요. (물론 세월이 흐르면서 서버가 먼저 메시지를 보내는 것처럼 시뮬레이션하는 웹소켓(WebSocket) 같은 기술들이 추가되긴 했지만, 기본 원칙은 그렇습니다.)

웹 페이지를 화면에 띄우기 위해, 브라우저는 가장 먼저 페이지를 구성하는 HTML 문서를 달라는 최초 요청을 보냅니다.
HTML을 받아온 브라우저는 문서를 쓱 읽어(파싱, Parsing) 내려가면서, 그 안에 포함된 실행 스크립트(JS), 예쁘게 꾸며줄 레이아웃 정보(CSS), 그리고 페이지에 포함된 하위 리소스들(주로 이미지나 비디오)에 대한 추가적인 요청들을 서버로 계속 보냅니다.
그다음 웹 브라우저는 이렇게 모아 온 리소스들을 하나로 쫙 조립해서 우리 눈앞에 완성된 웹 페이지를 보여주는 거예요.
이후에도 브라우저에서 실행된 자바스크립트가 나중에 필요한 리소스를 더 가져올 수 있고, 그에 따라 브라우저는 화면을 실시간으로 업데이트합니다.

웹 페이지는 기본적으로 '하이퍼텍스트 문서'예요.
이 말은 화면에 보이는 콘텐츠의 일부가 '링크'라는 뜻이죠. 사용자가 마우스 클릭 등으로 이 링크를 활성화하면 새로운 웹 페이지를 가져오게 되고, 이렇게 사용자는 브라우저(사용자 에이전트)를 조종하며 인터넷 세상을 항해(Navigation)하게 됩니다.
브라우저는 사용자의 이런 조작(클릭 등)을 HTTP 요청으로 번역하고, 서버에서 온 HTTP 응답을 다시 해석해서 사용자에게 깨끗한 화면으로 보여주는 훌륭한 통역사 역할을 하는 거랍니다.

웹 서버 (The Web server)

통신 채널의 반대편 끝에는 클라이언트가 요청한 문서를 제공(Serves)해 주는 웹 서버가 있습니다.
서버는 겉보기에는 마치 한 대의 컴퓨터처럼 보이지만, 실제로는 트래픽 부하를 여러 대가 나눠서 처리하는 서버 무리(로드 밸런싱)일 수도 있고, 캐시 서버, 데이터베이스 서버, 전자상거래 결제 서버 등 여러 소프트웨어가 협력하여 요청받은 문서를 전부 또는 일부분만 그때그때 만들어내는 복잡한 구조일 수도 있어요.

명심하세요. 서버가 반드시 '물리적인 기계 한 대'를 의미하는 건 아니에요. 반대로 강력한 컴퓨터 한 대에 여러 개의 서버 소프트웨어(인스턴스)가 돌아갈 수도 있습니다.
HTTP/1.1 규격과 Host 헤더를 사용하면 여러 웹사이트가 하나의 똑같은 IP 주소를 공유하면서 살아갈 수도 있답니다.

프록시 (Proxies)

웹 브라우저와 웹 서버 사이에는 HTTP 메시지를 중간에서 전달해 주는 수많은 컴퓨터와 장비들이 있어요.
웹 기술의 계층적 구조 덕분에 이들 대부분은 전송, 네트워크, 물리 계층에서 동작하므로 HTTP 계층에서는 투명하게(없는 것처럼) 보입니다. 하지만 성능에는 엄청난 영향을 미치죠.
이 중에서도 '애플리케이션 계층'에서 동작하는 중간 장비들을 보통 프록시(Proxies)라고 부릅니다.

프록시는 받은 요청을 토씨 하나 안 틀리고 그대로 전달하는 '투명한(transparent)' 프록시일 수도 있고, 서버로 넘기기 전에 요청의 내용 일부를 입맛대로 수정하는 '비투명한(non-transparent)' 프록시일 수도 있어요.
이 프록시들은 정말 다양한 일들을 대신해 줍니다.

  • 캐싱 (Caching): 브라우저 캐시처럼 프록시도 데이터를 임시로 저장해 둬서 서버까지 안 가도 빠르게 응답하게 해줘요. (공개 캐시, 비공개 캐시가 있음)
  • 필터링 (Filtering): 이상한 바이러스가 없는지 스캔하거나, 유해 사이트를 차단(자녀 보호 기능)합니다.
  • 로드 밸런싱 (Load balancing): 사용자 접속이 폭주할 때 여러 대의 서버가 요청을 골고루 나눠서 처리할 수 있게 분배해 줘요.
  • 인증 (Authentication): 아무나 리소스에 접근하지 못하도록 권한을 확인합니다.
  • 로깅 (Logging): 누가 언제 접속했는지 등의 역사적인 정보를 기록해 둡니다.

HTTP의 기본 특징들 (Basic aspects of HTTP)

HTTP는 간단해요 (HTTP is simple)

HTTP는 기본적으로 사람이 읽고 이해하기 쉽게(human-readable) 설계되었어요.
HTTP/2 버전에 오면서 성능을 위해 HTTP 메시지를 보이지 않는 '프레임' 안으로 캡슐화하는 복잡성이 추가되긴 했지만, 그 본질은 변하지 않았습니다.
개발자들이 주고받는 메시지를 눈으로 직접 읽고 이해할 수 있기 때문에 디버깅하고 테스트하기가 훨씬 수월하고, 이제 막 웹 개발을 시작하는 초보자들의 진입 장벽도 훅 낮춰준답니다.

HTTP는 확장 가능해요 (HTTP is extensible)

HTTP/1.0부터 도입된 HTTP 헤더(Headers) 덕분에 이 프로토콜은 기능을 확장하고 실험하기가 너무나도 쉽습니다.
심지어 클라이언트와 서버가 서로 "우리 앞으로 이 새로운 헤더 이름 써서 통신하자!"라고 합의만 한다면, 이 세상에 없던 새로운 기능도 얼마든지 뚝딱 만들어낼 수 있어요.

HTTP는 상태가 없지만(stateless), 세션이 없는 건 아니에요 (HTTP is stateless, but not sessionless)

HTTP는 기본적으로 무상태(Stateless)입니다.
이게 무슨 말이냐면, 방금 전에 한 요청과 지금 하는 요청 사이에 아무런 연결고리나 기억이 없다는 뜻이에요. 서버는 클라이언트가 과거에 누군지 기억하지 못합니다.
이 특징 때문에 쇼핑몰에서 장바구니에 물건을 담고 다음 페이지로 넘어가는 것처럼 여러 페이지에 걸쳐 일관성 있는 상호작용이 필요할 때 큰 문제가 될 수 있죠. (페이지를 이동할 때마다 장바구니가 텅텅 비어버릴 테니까요!)

하지만 HTTP 핵심 자체는 상태가 없더라도, 우리는 HTTP 쿠키(Cookies)라는 마법을 사용해 '상태가 있는 세션(stateful sessions)'을 만들 수 있습니다.
앞서 말한 뛰어난 '헤더 확장성'을 이용해서 HTTP 흐름에 쿠키를 살짝 끼워 넣는 거예요. 이렇게 하면 각각의 독립적인 HTTP 요청들이 서로 같은 맥락(컨텍스트)이나 상태를 공유하는 하나의 '세션'으로 묶이게 됩니다.

💡 강사의 실무 TIP!
이 "Stateless" 개념은 프론트엔드 면접에서 아주 사랑받는 단골 질문입니다! HTTP가 기억상실증에 걸렸기 때문에, 우리는 사용자가 로그인했다는 사실을 서버에 계속 알려주기 위해 매 요청마다 Cookie나 JWT(JSON Web Token) 같은 신분증을 헤더에 담아서 보내야 한다는 사실을 꼭 명심하세요.

HTTP와 연결 (HTTP and connections)

컴퓨터 간의 연결은 전송 계층에서 관리하므로, 사실 HTTP의 관할 밖이에요.
HTTP는 밑바탕에 깔린 전송 프로토콜이 반드시 연결 지향적일 필요는 없다고 말하지만, 단 하나의 조건, '신뢰성(Reliable)'은 꼭 요구합니다. 메시지가 중간에 유실되어서는 안 된다는 거죠. (최소한 유실되면 에러라도 띄워줘야 해요.)
인터넷에서 가장 많이 쓰이는 두 전송 프로토콜 중 TCP는 신뢰성이 높고 UDP는 그렇지 않아요. 그래서 HTTP는 기본적으로 연결 지향적인 TCP 표준에 의존하고 있습니다.

클라이언트와 서버가 HTTP 요청/응답을 한 세트 주고받으려면, 먼저 서로 인사를 나누고 TCP 연결을 맺어야 해요. 이 과정에는 네트워크를 여러 번 왔다 갔다 해야 하는 시간(Round-trips)이 소요됩니다.
초창기 HTTP/1.0 시절에는 요청을 보낼 때마다 매번 새로운 TCP 연결을 맺고 끊는 걸 반복했어요. 이건 짧은 시간 안에 여러 개의 요청을 다다닥 보낼 때 효율이 엄청나게 떨어지는 방식이었죠.

이 단점을 고치기 위해 HTTP/1.1에서는 파이프라이닝(Pipelining, 구현이 꽤 어려웠음)과 지속 연결(persistent connections)이라는 개념을 도입했습니다. Connection 헤더를 사용해서 TCP 연결을 안 끊고 살려둔 채로 재사용할 수 있게 된 거죠.
거기서 한 발 더 나아가 HTTP/2는 단일 연결 위에서 여러 메시지를 동시에 섞어 보내는 멀티플렉싱(Multiplexing) 기술을 통해 연결을 항상 따뜻하게 유지하고 훨씬 더 효율적으로 통신할 수 있게 만들었습니다.

지금도 HTTP에 더 찰떡같이 맞는 전송 프로토콜을 만들기 위한 실험은 계속되고 있어요.
예를 들어 구글은 빠르지만 신뢰성이 부족했던 UDP를 기반으로 신뢰성과 효율성을 모두 잡은 QUIC이라는 프로토콜을 열심히 실험하고 도입하고 있답니다.

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

시간이 지나면서 HTTP의 확장 가능한 특성 덕분에 웹을 훨씬 더 강력하게 제어할 수 있게 되었어요.
초창기 HTTP 시절부터 캐시나 인증 같은 기능들은 기본적으로 처리하고 있었죠. 반대로 보안을 위해 출처를 엄격하게 제한하는 규칙을 완화해 주는 기능(CORS)은 2010년대에 들어서야 새롭게 추가되기도 했습니다.

HTTP를 이용해 우리가 제어할 수 있는 대표적인 기능들은 다음과 같아요.

  • 캐싱(Caching):
    문서가 캐시에 어떻게 저장될지를 HTTP로 섬세하게 컨트롤할 수 있어요. 서버는 프록시나 클라이언트에게 "이 파일은 이만큼의 기간 동안만 캐시에 저장해!"라고 지시할 수 있고, 클라이언트는 반대로 "나 저장된 캐시 안 쓸 거니까 최신 데이터로 당장 가져와!"라고 중간 프록시에게 요구할 수도 있습니다.
  • 동일 출처 제약 완화(Relaxing the origin constraint - CORS):
    웹 브라우저는 해커가 우리 정보를 훔쳐 가는 걸 막기 위해 다른 웹사이트 간의 접근을 엄격하게 차단합니다. 오직 같은 출처(Same origin)에서 온 페이지들끼리만 모든 정보를 자유롭게 열어볼 수 있죠. 하지만 때로는 다른 도메인의 데이터를 합쳐서 화면을 그려야 할 때가 있잖아요? 이때 서버 측에서 HTTP 헤더를 세팅해 주면 이 엄격한 보안 규칙을 살짝 느슨하게 풀어서 데이터를 안전하게 가져올 수 있게 해줍니다.
  • 인증(Authentication):
    어떤 웹 페이지들은 관리자나 특정 사용자만 볼 수 있도록 보호되어야 하죠. HTTP는 WWW-Authenticate 같은 헤더를 사용한 기본 인증 방식이나, HTTP 쿠키를 통해 특정 세션을 설정하는 방식으로 인증을 처리할 수 있게 도와줍니다.
  • 프록시와 터널링(Proxy and tunneling):
    서버나 클라이언트가 사내망(인트라넷) 깊숙이 숨어있어서 진짜 IP 주소를 외부로 감춰야 할 때가 있어요. 이때 HTTP 요청은 프록시를 통과해 이 네트워크 장벽을 넘어갑니다. (모든 프록시가 HTTP 프록시는 아니에요. SOCKS 같은 프로토콜은 더 낮은 계층에서 작동하고, FTP 같은 다른 프로토콜도 프록시를 거칠 수 있습니다.)
  • 세션(Sessions):
    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>… (여기서부터 사용자가 요청한 29769 바이트짜리 진짜 HTML 웹 페이지 내용이 쭉 나옵니다)

  4. 연결 닫기 또는 재사용: 통신이 끝났으니 연결을 닫거나, 나중에 올 다음 요청을 위해 연결을 끊지 않고 잠시 대기시킵니다.

만약 HTTP 파이프라이닝 기능이 켜져 있다면, 클라이언트는 첫 번째 응답이 채 도착하기도 전에 기다리지 않고 여러 개의 요청을 와다다다 보낼 수 있어요. 하지만 파이프라이닝은 구형 소프트웨어와 최신 소프트웨어가 섞여 있는 현실의 네트워크 환경에서 오류 없이 구현하기가 너무 까다로웠습니다. 그래서 결국 HTTP/2에서는 프레임 안에서 안전하게 여러 메시지를 동시에 주고받는 더 강력한 '멀티플렉싱(multiplexing)' 기술로 대체되었죠.

HTTP 메시지 (HTTP Messages)

HTTP/1.1과 그 이전 버전의 HTTP 메시지들은 사람이 직접 눈으로 읽을 수 있는 텍스트로 되어 있어요.
HTTP/2에서는 메시지가 프레임(frame)이라는 바이너리(이진) 구조 속에 쏙 들어가게 되는데, 이 덕분에 헤더 데이터를 압축하고 여러 통신을 동시에 하는(멀티플렉싱) 등 엄청난 성능 최적화가 가능해졌죠.
HTTP/2에서는 원본 HTTP 메시지가 조각조각 나뉘어 전송되더라도, 각 메시지가 담고 있는 '의미(Semantics)' 자체는 하나도 변하지 않기 때문에 클라이언트가 알아서 원래의 HTTP/1.1 요청처럼 완벽하게 재조립해 냅니다.
따라서, 최신 HTTP/2 통신을 이해하기 위해서라도 기본이 되는 HTTP/1.1 포맷의 메시지 구조를 이해하는 것은 여전히 무척 중요해요.

HTTP 메시지에는 요청(Requests)과 응답(Responses) 두 가지 종류가 있고, 각각 생김새(포맷)가 다릅니다.

요청 (Requests)

HTTP 요청 메시지의 구조를 살펴볼까요?

헤더가 포함된 HTTP GET 요청 개요

요청 메시지는 다음과 같은 요소들로 이루어져 있어요.

  • HTTP 메서드 (Method): 클라이언트가 서버에게 "어떤 행동을 해줘!"라고 지시하는 동사 같은 녀석이에요. 데이터를 가져오고 싶을 땐 GET, 데이터를 생성해 달라고 보낼 땐 POST를 주로 씁니다. OPTIONS나 HEAD처럼 상황에 맞게 다른 메서드들을 사용하기도 해요. 주로 리소스를 요청(GET)하거나 HTML 폼(Form)에 적은 값을 서버로 보낼 때(POST) 사용하죠.
  • 리소스의 경로 (Path): 가져오고 싶은 데이터의 주소예요. 전체 URL에서 굳이 안 써도 뻔한 정보들, 예를 들면 프로토콜(http://), 도메인(여기서는 developer.mozilla.org), TCP 포트 번호(80) 등을 뺀 핵심 경로만 적습니다.
  • HTTP 프로토콜 버전: HTTP/1.1처럼 현재 사용 중인 버전을 명시합니다.
  • 헤더 (Headers): (선택 사항) 서버에게 추가적인 정보를 알려주기 위한 부가적인 데이터들이에요.
  • 본문 (Body): (선택 사항) GET 요청에는 보통 없지만, POST 메서드처럼 서버로 내 데이터를 밀어 넣을 때 그 전송할 데이터가 담기는 공간입니다.

응답 (Responses)

이번엔 서버가 보내는 HTTP 응답 메시지의 구조입니다.

응답 헤더가 포함된 GET 요청에 대한 '200 OK' HTTP 응답의 개요

응답 메시지는 다음과 같은 요소들로 이루어져 있어요.

  • HTTP 프로토콜 버전: 서버가 사용한 HTTP 버전을 알려줘요.
  • 상태 코드 (Status code): 요청이 성공했는지(200), 실패했는지(404), 혹은 왜 실패했는지를 3자리 숫자로 명확하게 알려주는 아주 중요한 코드예요.
  • 상태 메시지 (Status message): 상태 코드를 짧은 글로 설명해 주는 텍스트예요. (예: OK, Not Found)
  • HTTP 헤더 (Headers): 요청 메시지의 헤더와 마찬가지로, 서버가 클라이언트에게 전달하는 각종 부가 정보들이 담겨있습니다.
  • 본문 (Body): (선택 사항) 우리가 애타게 요청했던 문서나 데이터의 실제 내용이 담겨서 오는 공간이에요.

💡 강사의 실무 TIP!
크롬이나 엣지 브라우저에서 F12를 누르고 [네트워크(Network)] 탭을 열어보세요. 새로고침을 해보면 수많은 요청과 응답 메시지들이 오가는 걸 눈으로 직접 확인할 수 있습니다. 내가 보낸 데이터가 Payload에 잘 담겼는지, 서버가 200 OK를 줬는지 아니면 500 에러를 냈는지 확인하는 게 프론트엔드 디버깅의 첫걸음입니다!

HTTP 기반 API들 (APIs based on HTTP)

우리가 자바스크립트를 사용해서 웹 화면에서 동적으로 HTTP 요청을 보낼 때 가장 많이, 그리고 흔하게 사용하는 API가 바로 Fetch API예요. (과거에 쓰이던 좀 복잡하고 오래된 XMLHttpRequest API를 요즘 스타일로 세련되게 대체한 녀석이죠!)

또 다른 재밌는 API로는 서버 전송 이벤트 (server-sent events)가 있습니다. 이건 HTTP를 전송 수단으로 사용해서, 서버가 클라이언트 쪽으로 일방적으로 계속 이벤트를 밀어 넣어주는(단방향 서비스) 기술이에요.
클라이언트 측에서 EventSource 인터페이스를 써서 연결을 열고 이벤트 리스너를 달아두면 끝입니다. 그럼 브라우저가 알아서 HTTP 스트림을 타고 넘어오는 메시지들을 Event 객체로 예쁘게 변환해 줘요. 메시지의 type을 안다면 그에 맞는 이벤트 핸들러로, 특별한 타입이 없다면 기본 onmessage 핸들러로 데이터를 깔끔하게 전달해 줍니다.

마무리하며 (Conclusion)

HTTP는 정말 쓰기 쉬우면서도, 무한하게 확장할 수 있는 매력적인 프로토콜이에요.
가장 기본적인 '클라이언트-서버 구조'에 '헤더'라는 마음대로 추가할 수 있는 유연성을 곁들인 덕분에, HTTP는 웹 기술이 발전하고 요구사항이 복잡해지는 와중에도 뒤처지지 않고 훌륭하게 진화해 올 수 있었습니다.

HTTP/2가 도입되면서 성능을 쥐어짜 내기 위해 메시지를 프레임 안에 가두는 약간의 복잡성이 추가되긴 했지만요, 메시지의 뼈대와 기본 구조 자체는 HTTP/1.0 시절부터 뚝심 있게 그대로 유지되고 있어요.
가장 기본적인 통신 흐름의 원리는 전혀 변하지 않았기 때문에, 프론트엔드 개발자라면 언제든지 HTTP 네트워크 모니터(개발자 도구) 같은 툴을 열어서 통신 과정을 쉽게 들여다보고 버그를 잡아낼 수 있습니다.

profile
김동현
프론트에_가까운_풀스택_개발자
이전 포스트

HTTP: Hypertext Transfer Protocol

다음 포스트

HTTP/Guides/Evolution of HTTP

0개의 댓글