HTTP: 하이퍼텍스트 전송 프로토콜 (HTTP: Hypertext Transfer Protocol)
HTTP는 HTML과 같은 하이퍼미디어 문서를 전송하기 위한 애플리케이션 계층(application-layer) 프로토콜이에요. 원래는 웹 브라우저와 웹 서버 간의 통신을 위해 설계되었지만, 지금은 기계 간 통신(machine-to-machine), API에 대한 프로그래밍 방식의 접근 등 다양한 목적으로도 널리 쓰이고 있답니다.
HTTP는 전형적인 클라이언트-서버 모델(client-server model)을 따르고 있어요. 클라이언트가 연결을 열고 요청(request)을 보낸 다음, 서버로부터 응답(response)을 받을 때까지 기다리는 방식이죠.
또한 HTTP는 상태가 없는 프로토콜(stateless protocol)이에요. 즉, 서버가 두 요청 사이에 어떤 세션 데이터도 유지하지 않고 기억하지도 않는다는 뜻이죠. 하지만 나중에 쿠키(cookies)라는 기능이 추가되면서 일부 클라이언트-서버 상호작용에서는 상태를 유지하는 것처럼 만들 수 있게 되었어요.
가이드 (Guides)
HTTP는 리소스나 URI(Uniform Resource Identifiers), 기본적인 메시지 구조, 클라이언트-서버 통신 모델 같은 개념들에 기반을 둔 확장 가능한 프로토콜이에요. 이러한 기본 개념 위에, 지난 수년 동안 새로운 HTTP 메서드나 헤더 등 여러 확장 기능들이 개발되어 기능이 추가되고 의미론적으로도 계속 업데이트되어 왔어요.
HTTP 가이드는 전반적인 개요부터 시작해서 특정한 사용 사례에 맞춘 심화 주제 순서대로 나열되어 있어요. 초보자분들은 더 집중적인 문서를 살펴보기 전에 반드시 기초적인 가이드부터 시작하시는 걸 권장해요.
HTTP 개요 (Overview of HTTP)
: HTTP의 기본 기능, HTTP로 할 수 있는 일, 웹 아키텍처에서의 본래 사용 목적, 그리고 프로토콜 스택 내에서의 위치에 대해 설명해요.
HTTP의 진화 (Evolution of HTTP)
: HTTP는 1990년대 초반에 만들어져 여러 번 확장되었어요. 이 문서는 그 역사를 살펴보고, HTTP/0.9, HTTP/1.0, HTTP/1.1부터 HTTP/2와 HTTP/3까지, 그리고 수년에 걸쳐 도입된 새로운 기술들을 설명해 줘요.
전형적인 HTTP 세션 (A typical HTTP session)
: 연결을 설정하고, 요청을 보내고, 응답을 받기까지의 HTTP 세션 흐름을 설명합니다.
HTTP 메시지 (HTTP messages)
: 요청(request)과 응답(response)으로 전송되는 HTTP 메시지들은 정해진 구조를 가지고 있어요. 이 문서에서는 그 전반적인 구조와 목적, 그리고 다양한 메시지 유형에 대해 설명해요.
💡 강사의 팁: HTTP 메시지는 크게
Start line(시작 줄),Headers(헤더),Body(본문)세 부분으로 나뉩니다. 우리가 프론트에서 POST 요청으로 보내는 JSON 데이터는 바로 저Body부분에 담겨서 날아가게 되죠!
MIME 타입 (MIME types)
: HTTP/1.0부터는 다양한 타입의 콘텐츠를 전송할 수 있게 되었어요. 이 문서에서는 Content-Type 헤더와 MIME 표준을 사용해서 이를 어떻게 구현하는지 설명해요. 웹 개발자들이 자주 사용하는 타입의 간략한 목록은 흔히 사용되는 MIME 타입 (Common MIME types)에서 확인할 수 있어요.
HTTP의 압축 (Compression in HTTP)
: 브라우저와 서버는 전송해야 할 데이터의 양을 줄여서 전송 속도와 대역폭 활용도를 높이기 위해, 네트워크로 메시지를 보내기 전에 미리 메시지를 압축한답니다.
HTTP 캐싱 (HTTP caching)
: 캐싱(Caching)은 웹에서 빠르고 쾌적한 사용자 경험을 제공하고 리소스를 효율적으로 사용하기 위해 정말 중요한 메커니즘이에요. 이 문서는 다양한 캐싱 방법과 HTTP 헤더를 이용해 캐시를 제어하는 방법을 설명해요.
💡 강사의 팁: 요즘 SWR이나 React Query(TanStack Query) 같은 라이브러리를 많이 사용하시죠? 이런 상태 관리 도구들이 프론트엔드 레벨에서 캐싱을 도와준다면, HTTP 캐싱은 브라우저와 서버 사이의 통신 레벨에서 일어나는 근본적인 캐싱 전략입니다. 두 가지를 함께 잘 활용하면 정말 엄청난 성능 최적화를 이뤄낼 수 있어요!
HTTP 인증 (HTTP authentication)
: 인증(Authentication)은 클라이언트가 서버에 요청을 보낼 때 자신의 신원을 증명하는 방법이에요. 인가된(authorized) 사용자나 시스템만 특정 리소스에 접근할 수 있도록 보장해 줍니다.
HTTP 쿠키 사용하기 (Using HTTP cookies)
: HTTP는 무상태(stateless) 프로토콜이지만, 서버는 응답과 함께 Set-Cookie 헤더를 보낼 수 있어요. 그러면 클라이언트는 이후 서버에 요청을 보낼 때마다 Cookie 요청 헤더 형태로 그 쿠키 값을 다시 돌려보내죠. 이 기능을 통해 적은 양의 데이터를 저장하고 교환할 수 있어서, 결과적으로 일부 클라이언트-서버 상호작용에 상태(state)를 더해준답니다.
HTTP의 리다이렉션 (Redirections in HTTP)
: URL 리다이렉션(또는 URL 포워딩)은 페이지나 폼, 전체 웹사이트나 웹 애플리케이션에 하나 이상의 URL 주소를 부여하는 기술이에요. HTTP는 이 작업을 위해 'HTTP 리다이렉트'라는 특별한 종류의 응답을 가지고 있어요.
HTTP 조건부 요청 (HTTP conditional requests)
: 조건부 요청에서는 요청에 포함된 검사기(validator)의 값에 따라 요청의 결과가 달라져요. 이 방법은 캐싱(caching)에서 매우 중요하게 사용되며, 다운로드를 일시 정지했다가 이어받거나, 서버의 문서를 수정할 때 업데이트 내역이 손실되는 것을 방지하는 등 다양한 곳에 쓰입니다.
HTTP 범위 요청 (HTTP range requests)
: 범위 요청은 서버에게 전체 리소스 대신 파일의 특정 부분(들)만 클라이언트에게 돌려달라고 요청하는 기능이에요. 큰 파일의 일부분만 필요하다는 걸 알 때나, 사용자가 다운로드를 일시 정지하고 다시 시작할 수 있게 해주는 애플리케이션에서 매우 유용하죠.
콘텐츠 협상 (Content negotiation)
: HTTP는 브라우저가 자신이 선호하는 포맷, 언어, 또는 인코딩을 서버에 알릴 수 있도록 Accept로 시작하는 일련의 메시지 헤더들을 정의해 놓았어요. 이 문서는 이러한 선호도 알림이 어떻게 이루어지는지, 서버는 어떻게 반응해야 하는지, 그리고 서버가 요청에 대해 가장 적절한 응답을 어떻게 선택하는지 설명합니다.
HTTP/1.x의 연결 관리 (Connection management in HTTP/1.x)
: HTTP/1.1은 지속 연결(persistent connections)과 파이프라이닝(pipelining)을 지원하는 첫 번째 HTTP 버전이었어요. 이 문서에서는 각 방식의 장단점을 포함해 두 가지 개념을 모두 설명해요.
프로토콜 업그레이드 메커니즘 (Protocol upgrade mechanism)
: HTTP/1.1은 Upgrade 헤더를 사용해서 이미 설정된 연결을 다른 프로토콜로 업그레이드하는 메커니즘을 제공해요. 클라이언트는 연결을 HTTP/1.1에서 HTTP/2로 업그레이드하거나, HTTP(S) 연결을 웹소켓(WebSocket) (ws / wss)으로 업그레이드할 수 있답니다.
프록시 서버와 터널링 (Proxy servers and tunneling)
: 프록시는 사용자의 로컬 컴퓨터에 있을 수도 있고, 사용자 컴퓨터와 인터넷상의 목적지 서버 사이 그 어디든 있을 수 있어요. 이 페이지에서는 프록시에 대한 몇 가지 기본 개념을 설명하고 몇 가지 설정 옵션을 소개합니다.
HTTP 클라이언트 힌트 (HTTP Client hints)
: 클라이언트 힌트는 서버가 클라이언트의 기기, 네트워크, 사용자, 그리고 사용자 에이전트 특정 설정에 대한 정보를 선제적으로 요청할 수 있게 해주는 응답 헤더들의 모음이에요. 그러면 서버는 클라이언트가 제공하기로 선택한 정보를 바탕으로 어떤 리소스를 보내야 할지 결정할 수 있죠.
네트워크 에러 로깅 (Network Error Logging) (실험적 기능)
: 네트워크 에러 로깅은 NEL HTTP 응답 헤더를 통해 설정할 수 있는 메커니즘이에요. 이 실험적인 헤더를 사용하면, 웹사이트나 애플리케이션이 이 기능을 지원하는 브라우저로부터 실패한(혹은 심지어 성공한) 네트워크 가져오기 작업에 대한 리포트를 받을 수 있도록 설정할 수 있어요.
사용자 에이전트(User-Agent)를 이용한 브라우저 감지 (Browser detection using the user agent)
: 사용자 에이전트 정보를 엿보고 브라우저를 알아내는 것은 아주 드문 예외 상황을 제외하면 별로 좋은 방법이 아니에요. 하지만 어쩔 수 없이 필요한 상황(edge cases)이 있죠. 이 문서는 꼭 이 방법을 써야 할 때 어떻게 하면 최대한 올바르게 할 수 있는지 안내해주며, 특히 이 방식을 선택하기 전에 고려해야 할 사항들을 강조하고 있어요.
보안 및 개인정보 보호 (Security and privacy)
권한 정책 (Permissions Policy)
: 권한 정책은 웹 개발자가 웹사이트에서 사용할 수 있는 기능과 사용할 수 없는 기능을 명시적으로 선언할 수 있는 메커니즘을 제공해요. 사이트의 코드가 어떤 API에 접근할 수 있는지 제한하거나 특정 기능에 대한 브라우저의 기본 동작을 수정하는 "정책(policies)" 세트를 정의할 수 있어요.
교차 출처 리소스 공유 (CORS, Cross-Origin Resource Sharing)
: 교차 출처(Cross-site) HTTP 요청은 요청을 보내는 쪽과 다른 도메인에 있는 리소스를 요청하는 것을 말해요. 오늘날 웹 페이지들은 이런 교차 출처 리소스를 아주 흔하게 불러옵니다. 예를 들어, '도메인 A'(http://domaina.example/)의 페이지가 img 요소를 통해 '도메인 B'(http://domainb.foo/image.jpg)에 있는 이미지를 요청하는 식이죠. CORS는 웹 개발자들이 이러한 교차 출처 요청에 사이트가 어떻게 반응할지를 제어할 수 있게 해 줍니다.
💡 강사의 팁: 실무나 사이드 프로젝트를 진행하면서 API를 연동할 때 붉은색 글씨로 콘솔에
CORS error가 뜨는 걸 정말 자주 보게 될 거예요. 프론트엔드와 백엔드의 도메인이나 포트(예: localhost:3000과 localhost:8080)가 달라서 브라우저가 보안상 막아버리는 현상인데, 이 문서를 통해 원리와 해결법(주로 백엔드에서 헤더 설정 등)을 알아두면 큰 도움이 됩니다!
콘텐츠 보안 정책 (CSP, Content Security Policy)
: CSP는 웹사이트 관리자가 Content-Security-Policy 응답 헤더를 사용해서, 특정 페이지에서 클라이언트가 로드하도록 허용된 리소스가 무엇인지 제어할 수 있게 해 줘요. 이 CSP 가이드는 크로스 사이트 스크립팅(XSS)이나 데이터 주입 공격 같은 특정 유형의 공격을 감지하고 완화하는 데 도움을 주는 전반적인 콘텐츠 보안 정책 메커니즘을 설명합니다.
교차 출처 리소스 정책 (CORP, Cross-Origin Resource Policy)
: CORP는 웹사이트와 애플리케이션이 다른 출처에서 오는 특정한 요청(예를 들어 <script>나 <img> 요소로 발행된 요청)으로부터 스스로를 보호하도록 설정하여 투기적 실행 부채널 공격(speculative side-channel attacks)을 완화할 수 있게 해 줍니다.
Mozilla 웹 보안 가이드라인 (Mozilla web security guidelines)
: 안전한 웹 애플리케이션을 만들고자 하는 운영 팀에게 도움이 되는 보안 팁 모음이에요.
관련 리소스 (Related resources)
URIs
: 통합 자원 식별자(URIs, Uniform Resource Identifiers)는 웹 상의 리소스를 설명하고 그 위치를 찾아내는 데 사용되며, HTTP 요청에 있어서 필수적인 요소예요.
Ogg 미디어를 위한 서버 설정 (Configuring servers for Ogg media)
: 이 가이드는 웹 서버가 Ogg 미디어 파일을 올바르게 서비스하기 위해 필요할 수 있는 몇 가지 서버 설정 변경 사항을 다루고 있어요. 서버가 인식하도록 미리 설정되어 있지 않은 다른 미디어 타입을 마주쳤을 때도 이 정보가 유용할 수 있답니다.
도구 및 리소스 (Tools & resources)
HTTP를 이해하고 디버깅하는 데 유용한 도구와 리소스들이에요.
Firefox 개발자 도구 (Firefox Developer Tools)
: 네트워크 모니터 (Network monitor)
💡 강사의 팁: 브라우저 개발자 도구(F12)의 'Network' 탭과 친해지는 것은 프론트엔드 개발자의 필수 소양입니다! 내가 어떤 API를 호출했는지, 응답은 200 OK로 잘 왔는지, 페이로드(Payload)에는 어떤 값을 실어 보냈는지를 여기서 모두 확인할 수 있으니까요.
HTTP Observatory
: 개발자, 시스템 관리자, 보안 전문가가 사이트를 안전하고 확실하게 설정할 수 있도록 돕기 위해 만들어진 프로젝트예요.
RedBot
: 캐시 관련 헤더들을 점검해 주는 도구입니다.
nghttp2
: C 언어로 작성된 HTTP/2 클라이언트, 서버 및 프록시 구현체로, 부하 테스트와 벤치마킹 도구, 그리고 HPACK 인코더 및 디코더를 포함하고 있어요.
curl
: URL 구문으로 명시된 데이터를 전송하기 위한 명령줄(command-line) 도구예요. 수많은 프로토콜 중에서도 HTTP, HTTPS, WS, WSS 등을 지원하죠.
브라우저는 어떻게 동작하는가 (How Browsers Work 2011)
: 브라우저의 내부 동작 원리와 HTTP 프로토콜을 통한 요청 흐름에 대해 매우 포괄적이고 상세하게 다룬 아티클이에요. 꼭 한 번 읽어보시길 권합니다!
참조 (Reference)
HTTP 참조 (HTTP reference) 문서에는 헤더, 요청 메서드, 상태 응답에 대한 상세한 정보가 담겨 있으며, 관련된 명세 및 표준 문서들의 목록도 제공하고 있어요.
HTTP 헤더 (HTTP headers)
: 메시지 헤더는 리소스나 HTTP 메시지에 대한 메타데이터(metadata)를 전송하고, 클라이언트나 서버의 동작을 설명하는 데 사용돼요.
HTTP 요청 메서드 (HTTP request methods)
: 요청 메서드는 요청의 목적과 그 요청이 성공했을 때 기대되는 결과를 나타내요. 가장 흔히 쓰이는 메서드는 데이터를 가져오는 데 쓰이는 GET과 데이터를 서버로 전송하는 데 쓰이는 POST지만, 다른 목적을 가진 다양한 메서드들도 존재합니다.
HTTP 응답 상태 코드 (HTTP response status codes)
: 응답 상태 코드는 특정 HTTP 요청이 어떻게 처리되었는지 결과를 알려줘요. 응답은 정보성(1xx), 성공(2xx), 리다이렉션(3xx), 클라이언트 에러(4xx), 그리고 서버 에러(5xx) 이렇게 5가지 클래스로 나뉩니다.
HTTP 리소스 및 명세 (HTTP resources and specifications)
: 이 페이지는 1990년대 초반 HTTP가 처음 명세화된 이후의 관련 리소스 목록을 제공해요.
다음의 하위 섹션들도 꼭 살펴볼 만합니다:
CSP 지시어 (CSP directives)
: Content-Security-Policy (CSP) 응답 헤더를 통해 웹사이트 관리자는 해당 페이지에 대해 사용자 에이전트(브라우저)가 로드하도록 허용할 리소스를 구체적으로 지정할 수 있어요. 이 섹션은 CSP 헤더에서 사용할 수 있는 지시어 목록을 나열하고 있으며, 각 지시어가 어떻게 동작하고 어떻게 사용하는지에 대한 개별 문서 페이지를 제공합니다.
권한 정책 지시어 (Permissions-Policy directives)
: Permissions-Policy 응답 헤더는 문서 내에서, 또는 그 문서 안의 특정 <iframe> 요소 안에서 브라우저의 특정 기능 사용을 허용하거나 거부할 수 있는 메커니즘을 제공해요. 이 섹션은 이 헤더에서 사용할 수 있는 지시어 목록과 각각의 사용 방법을 설명하는 개별 문서를 나열합니다.
