사전 오리진 서버
개념

오리진 서버

gabury1

요청받은 내용을 직접 만들어서 내주는 쪽입니다. 중간에 다른 서버가 몇 겹 끼어 있어도 답이 실제로 만들어지는 자리는 여기입니다. 웹사이트만 여기 해당하는 것은 아닙니다.

상세

안내 창구에 앉은 사람에게 영업시간을 물으면 그 자리에서 답이 나옵니다. 같은 사람에게 어려운 것을 물으면 그는 안쪽에 물어보러 갑니다. 답을 내주는 쪽이 누구인지는 앉은 곳이 아니라 무엇을 물었는지가 정합니다.

HTTP(HyperText Transfer Protocol) 의 의미를 정하는 RFC(Request for Comments) 9110 은 오리진 서버를 이렇게 정의합니다. 주어진 대상 자원에 대해 권위 있는 응답을 만들어 낼 수 있는 프로그램입니다.

이 정의에서 걸리는 말이 둘입니다. 하나는 프로그램입니다. 기계 한 대나 회사에 붙는 이름이 아닙니다. 다른 하나는 대상 자원입니다. 어느 자원을 기준으로 삼느냐에 따라 누가 오리진 서버인지가 정해집니다.

가장 익숙한 형태는 큰 공개 웹사이트입니다. RFC 9110 은 그 익숙함을 경계합니다. 사용자 에이전트를 브라우저와 같은 것으로 놓기 쉬운 것처럼, 오리진 서버도 다 비슷하게 생겼다고 오해하기 쉽다는 것입니다. 흔한 오리진 서버에는 홈 오토메이션 장치, 설정 가능한 네트워킹 부품, 사무기기, 자율 로봇, 뉴스 피드, 교통 카메라, 실시간 광고 선택기, 주문형 비디오 플랫폼도 들어갑니다.

배경

RFC 9110 은 대부분의 HTTP 통신이 URI(Uniform Resource Identifier) 로 지목된 자원의 표현을 가져오는 요청이라고 적습니다. 그리고 가장 단순한 경우를 사용자 에이전트와 오리진 서버 사이의 양방향 연결 하나로 그립니다. 이때는 따로 이름이 필요 없습니다. 말을 주고받는 상대가 곧 답을 만드는 쪽입니다.

그런데 HTTP 는 연결의 사슬을 거쳐 요청을 처리하는 중개자를 허용합니다. 흔한 중개자의 형태는 프록시, 게이트웨이, 터널 셋입니다. 사슬이 끼는 순간 둘이 갈라집니다. 지금 연결을 맺고 있는 상대와, 그 답을 실제로 만들어 낸 쪽입니다. 캐시에 든 응답이 아직 신선하면 캐시는 오리진 서버에 연락하지 않고 뒤따르는 요청을 처리할 수 있습니다. 그러면 상대는 오리진 서버가 아닙니다.

게다가 하나의 중개자가 요청의 성격에 따라 오리진 서버, 프록시, 게이트웨이, 터널로 행동을 바꾸기도 합니다. 그래서 필요한 것은 기계나 회사를 가리키는 이름이 아니라 역할을 가리키는 이름이었습니다. 권위 있는 응답을 만들어 내는 쪽, 그 역할에 붙은 이름이 오리진 서버입니다.

flowchart TD
    UA["사용자 에이전트"] -->|요청| M["중개자"]
    M -->|요청| O["오리진 서버"]
    O -->|응답| M
    M -->|응답| UA

예시

HTTP 캐시 명세

RFC 9111 은 응답의 신선도 수명을 오리진 서버가 그 응답을 만든 시점부터 만료 시점까지의 길이라고 적습니다. 응답의 나이는 오리진 서버가 그것을 만들거나 오리진 서버와 성공적으로 검증한 뒤 흐른 시간입니다. 응답이 신선하면 캐시는 오리진 서버에 연락하지 않고 뒤따르는 요청을 처리할 수 있습니다. 신선도를 정하는 주된 방법은 오리진 서버가 앞날의 만료 시각을 명시하는 것입니다. 그 자리가 Expires 헤더 필드나 max-age 응답 지시자입니다.

Cloudflare 프록시 상태

DNS(Domain Name System) 레코드마다 프록시를 켜고 끕니다. 공식 문서의 예시 표에서 blog 레코드는 프록시가 켜진 Proxied 상태이고, shop 레코드는 꺼진 DNS only 상태입니다.

Type  Name  Content     Proxy status  TTL
A     blog  192.0.2.1   Proxied       Auto
A     shop  192.0.2.2   DNS only      Auto

프록시가 켜진 blog.example.com 질의에는 원래 값인 192.0.2.1 대신 Cloudflare 애니캐스트 IP(Internet Protocol) 주소가 돌아갑니다. 프록시가 꺼진 shop.example.com 질의에는 실제 오리진 IP 주소인 192.0.2.2 가 그대로 돌아갑니다. 그러면 레코드를 조회하는 누구에게나 오리진 IP 주소가 드러납니다. 표적 공격에 대한 보호 계층 하나가 사라집니다. 프록시가 켜진 상태를 이 문서는 orange-clouded 라고 부릅니다. 그 상태에서 Cloudflare 는 웹사이트나 애플리케이션을 호스팅하는 서버, 곧 오리진 서버를 DDoS(Distributed Denial of Service, 분산 서비스 거부) 공격으로부터 보호할 수 있다고 적습니다.

nginx 리버스 프록시

ngx_http_proxy_module 은 요청을 다른 서버로 넘깁니다. 최소 형태는 한 줄입니다.

location / {
    proxy_pass http://localhost:8000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

넘길 곳이 여러 대면 ngx_http_upstream_module 로 묶습니다. 묶음에 이름을 붙입니다. proxy_pass 가 그 이름을 가리킵니다.

upstream backend {
    server backend1.example.com weight=5;
    server backend2.example.com:8080;
    server backup1.example.com:8080 backup;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

nginx 설정은 넘겨받는 쪽을 upstream 이라는 이름으로 가리킵니다.

MDN 의 관리형 캐시

MDN(Mozilla Developer Network) 은 관리형 캐시를 서비스 개발자가 오리진 서버의 부담을 덜고 콘텐츠를 효율적으로 전달하려고 명시적으로 배치하는 캐시라고 적습니다. 그 예로 리버스 프록시, CDN(Content Delivery Network), 그리고 Cache API(Application Programming Interface) 와 함께 쓰는 서비스 워커를 듭니다.

경계

리버스 프록시도 오리진 서버인가. 바깥쪽 연결에 대해서는 맞습니다. RFC 9110 은 게이트웨이를 이렇게 정의합니다. 바깥쪽 연결에 대해서는 오리진 서버 노릇을 합니다. 다만 받은 요청은 번역해 안쪽의 다른 서버로 넘깁니다. 그리고 게이트웨이의 다른 이름이 리버스 프록시라고 적습니다. 오리진 서버에 걸리는 HTTP 요구사항은 게이트웨이의 바깥쪽 통신에도 전부 걸립니다. 그러니 요청을 보낸 쪽에서 보면 게이트웨이는 오리진 서버입니다.

안쪽을 향할 때는 아닙니다. 제삼자의 HTTP 서버와 상호운용하려는 게이트웨이는 안쪽 연결에서 사용자 에이전트에 걸리는 요구사항을 따라야 합니다. 그 자리에서 게이트웨이는 오리진 서버가 아니라 요청을 보내는 쪽입니다.

이름이 겹쳐 헷갈리는 다른 말도 있습니다. RFC 9110 이 정의하는 「origin」은 URI 의 스킴, 호스트, 포트를 정규화해 묶은 세 값입니다. https://example.com/happy.js 의 origin 은 { "https", "example.com", "443" } 입니다. 포트를 항상 적은 정규화된 URI 접두사 https://example.com:443 으로도 적을 수 있습니다. 스킴, 호스트, 포트 중 하나라도 다르면 서로 다른 origin 입니다. 이쪽은 이름공간을 가르는 값의 묶음이지 프로그램이 아닙니다. 오리진 서버와 같은 말이 아니라서 이 표제어에 들어가지 않습니다. HTML(HyperText Markup Language) 과 관련 웹 프로토콜에서 쓰는 origin 은 이 명세의 범위 밖입니다. RFC 6454 가 따로 다룹니다.

관련 항목

요청 사슬에 관여하는 역할

사용자 에이전트 · 브라우저 · 중개자 · 프록시 · 게이트웨이 · 리버스 프록시 · 터널

오리진 서버가 속하는 상위 프로토콜과 자원 식별자

HTTP · URI

오리진 서버 앞단에 놓이는 CDN 기술·설정

CDN · 애니캐스트 · 로드 밸런싱 · nginx · Cloudflare · DNS · 레코드 · IP 주소 · DDoS

캐시가 신선도를 판정하는 규칙

신선도 · 나이 · 검증 · 무효화 · Cache-Control · Expires · max-age · Age 헤더

오리진 서버 부담을 더는 캐시 구현

캐시 · 관리형 캐시 · 서비스 워커 · API

오리진 서버를 다루는 표준·참고 문서

RFC 9110 · RFC 9111 · MDN

이름이 겹치는 헷갈리는 이웃

origin · 정규화 · HTML · RFC 6454

다른 이름: origin server