웹서버

웹서버는 대답하는 프로그램입니다

장비 랙과 클라우드 상표를 걷어 내면, 웹서버는 한 가지 일을 되풀이하는 프로그램 하나입니다. 누가 연결하기를 기다렸다가, 무엇을 달라는지 읽고, 글을 돌려주고, 다시 기다립니다.

"서버"라는 낱말은 두 가지를 가리키고 사람들이 늘 섞어 씁니다. 데이터센터에 놓인 기계도 서버고, 포트에서 귀를 기울이는 프로그램도 서버입니다. 여기서 말하는 것은 프로그램 쪽이고, 그것은 지금 앞에 있는 노트북에서도 똑같이 잘 돕니다.

손님 한 명, 네 걸음

1. 귀 기울이기프로그램이 포트 하나를 차지하고 기다립니다 — 예제에서는 8084 입니다. 포트는 기계에 번호가 붙은 문이라, 두 프로그램이 같은 문을 잡을 수는 없습니다.
2. 요청 읽기브라우저가 연결해 몇 줄의 글을 보냅니다. 첫 줄에 어떤 방법으로 어떤 경로를 원하는지가 담깁니다. 예를 들면 경로 / 를 GET 해 달라는 식입니다.
3. 판단하기무엇을 보낼지 정합니다. 디스크에서 파일을 읽거나, 코드를 돌리거나, 데이터베이스에 묻습니다. 예제는 늘 같은 파일만 보내기 때문에 20줄에 들어갑니다.
4. 응답하고 끊기상태 줄과 몇 개의 헤더, 빈 줄 하나, 그리고 내용을 적어 보낸 뒤 연결을 끊고 다음 손님을 위해 처음으로 돌아갑니다.

쉘 스크립트 한 장으로 만드는 웹서버

아래가 bash 로 쓴 완전한 웹서버입니다. 포트를 열고, 요청 줄을 읽고, 기록을 남기고, index.html 을 제대로 된 HTTP 응답으로 돌려줍니다. 스무 줄, 라이브러리 없음, 그리고 브라우저는 차이를 알아채지 못합니다.

무거운 일은 두 명령이 맡습니다. netcat(nc) 이 네트워크를 말하고, mkfifo 가 이름 있는 파이프를 만들어 우리가 쓴 답을 nc 가 붙들고 있는 연결로 되돌려 보냅니다.

#!/bin/bash

PORT=8084
PIPE=simple-web-server-pipe

rm -f "$PIPE"
mkfifo "$PIPE"

response() {
    read -r method path _
    echo "[$(date)] $method $path" >&2
    index=$(cat index.html)
    printf 'HTTP/1.1 200 OK\r\nContent-Type: text/html; charset=utf-8\r\nConnection: close\r\n\r\n%s' \
      "$index"
}

while true; do
    response < "$PIPE" | nc -l "$PORT" > "$PIPE"
done

한 줄씩 뜯어보기

1. PORT=8084귀를 기울일 포트입니다. 1024 보다 큰 번호는 관리자 권한 없이 쓸 수 있고, 8084 는 이미 쓰고 있는 것과 부딪힐 일이 적습니다.
2. PIPE=simple-web-server-pipe파이프 파일의 이름입니다. 폴더에 보통 파일처럼 나타나지만 안에 저장되는 것은 없습니다 — 두 명령 사이로 자료를 지나가게 할 뿐입니다.
3. mkfifo "$PIPE"이름 있는 파이프(FIFO)를 만듭니다. 바로 윗줄이 지난번에 남은 것을 지우는 이유는, mkfifo 가 이미 있는 파일 위에 덮어쓰기를 거부하기 때문입니다.
4. read -r method path _요청의 첫 줄을 읽어 방법 · 경로 · 나머지로 나눕니다. 그 뒤에 오는 브라우저의 헤더들은 이 서버가 그냥 흘려보냅니다.
5. echo "[$(date)] $method $path" >&2기록을 한 줄 남깁니다. 표준 오류로 방향을 돌린 덕분에 이 글이 브라우저로 가지 않고 터미널에만 나타납니다.
6. index=$(cat index.html)지금 폴더의 index.html 을 읽어 변수에 담습니다. 서버를 그 파일이 있는 폴더에서 실행해야 하는 이유가 이것입니다.
7. printf 'HTTP/1.1 200 OK\r\n…'응답을 씁니다. 상태 줄, 내용의 종류, 여기서 연결을 끝낸다는 헤더, 그리고 빈 줄과 페이지. 헤더와 내용을 가르는 것이 그 빈 줄이고, HTTP 는 모든 줄 끝에 캐리지리턴과 줄바꿈을 함께 요구합니다.
8. response < "$PIPE" | nc -l "$PORT" > "$PIPE"이것이 동작하게 만드는 요령입니다. nc 는 파이프에서 우리 응답을 읽고, 브라우저의 요청을 그 파이프에 다시 써 넣습니다. 두 쪽이 서로에게 먹이를 주는 셈입니다.
9. while true; do … done반복문입니다. nc 는 연결 하나를 처리하면 끝나 버리므로, 이 줄이 없으면 서버는 손님 한 명만 받고 멈춥니다.

직접 띄워 보기

스크립트를 server.sh 로 저장하고 옆에 index.html 을 두고 실행합니다. 그 터미널은 켜 둔 채로, 두 번째 터미널에서 요청을 보내 보세요.

# 1. create an index.html in the same folder
echo '<h1>Hello</h1>' > index.html

# 2. save the script above as server.sh and start it
bash server.sh

# 3. open it in a browser (or check from a second terminal)
open http://localhost:8084
curl http://localhost:8084

브라우저를 새로고침하면서 첫 터미널을 보세요. 요청 하나마다 기록이 한 줄씩 쌓입니다. Control-C 로 멈추고, 파이프 파일이 남아 있으면 지웁니다. 리눅스의 nc 는 포트 앞에 -p 를 더 붙여야 할 수 있고, macOS 에 기본으로 들어 있는 판은 적힌 그대로 동작합니다.

선을 타고 실제로 오가는 것

연결을 열어 보면 여러분이 손으로 칠 수도 있었을 평범한 글자가 흐릅니다. 쉘 웹서버가 가능한 이유가 이것이고, 웹에서 생긴 문제를 짐작이 아니라 읽어서 풀 수 있는 이유도 이것입니다.

브라우저가 보내는 요청

GET / HTTP/1.1
Host: localhost:8084
User-Agent: Mozilla/5.0
Accept: text/html

• 첫 줄이 우리 서버가 읽는 유일한 부분입니다. 방법(GET 은 가져오기, POST 는 보내기), 경로, 그리고 프로토콜 판입니다.
• Host 는 어느 사이트를 원하는지 말합니다. 서버 하나가 한 주소에서 수백 개 도메인을 품을 수 있고, 그것을 구별하는 것이 이 헤더입니다.
• 나머지는 브라우저의 자기소개입니다. 자신이 어떤 프로그램인지, 어떤 형식을 읽을 수 있는지, 어떤 언어를 좋아하는지. 서버는 쓸 수도 있고 무시할 수도 있습니다.

서버가 보내는 응답

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Connection: close

<h1>Hello</h1>

• 상태 줄입니다. 프로토콜 판과, 일이 어떻게 됐는지 알리는 숫자. 200 은 요청이 잘 됐다는 뜻입니다.
• Content-Type 은 뒤따라올 것을 어떻게 읽어야 하는지 알려 줍니다. HTML 을 엉뚱한 종류로 보내면 브라우저가 태그를 페이지가 아니라 글자 그대로 보여 줍니다.
• charset 부분은 실제로는 선택이 아닙니다. 이것이 없으면 한글은 깨진 글자로 도착하기 쉽습니다.
• 그리고 빈 줄 하나. 그 뒤는 전부 내용입니다. 헤더와 페이지를 가르는 경계는 오직 그 빈 줄뿐입니다.

알아 둘 만한 상태 코드

이 서버가 못 하는 일

예제는 정직한 교재이고 형편없는 서비스입니다. 어디서 모자란지 정확히 아는 것이 곧 진짜 서버가 대신 풀어 주는 문제를 아는 것입니다.

• 한 번에 한 명입니다. nc 는 연결 하나만 다루므로, 그것이 바쁜 동안 나머지는 모두 기다립니다.
• 경로를 무시합니다. 무엇을 달라고 하든 index.html 만 돌아옵니다 — 길 안내도 없고 두 번째 페이지도 없습니다.
• 전부 HTML 로 보냅니다. 그림도 스타일 파일도 내려받기도 저마다의 내용 종류가 필요한데, 이 서버는 딱 하나만 압니다.
• HTTPS 가 없습니다. 모든 것이 맨몸으로 지나가므로, 중간의 어떤 네트워크든 읽거나 바꿔치기할 수 있습니다.
• 안전장치가 전혀 없습니다. 요청 크기를 재지 않고, 시간 제한도 없으며, 함부로 확장하면 남이 정한 파일 경로를 그대로 읽어 버립니다.

Caddy — 읽을 수 있는 채로 남은 진짜 웹서버

Caddy 는 실행 파일 하나로 된 현대적인 웹서버입니다. 쉘 예제 바로 다음에 배울 값어치가 있는 이유는, 읽을 수 있는 몇 줄이면 돌아간다는 느낌을 그대로 유지하면서 쉘 판이 못 하던 것을 전부 해결하기 때문입니다.

가장 내세우는 기능은 자동 HTTPS 입니다. 진짜 도메인 이름만 주면 인증서를 받아 오고, 설치하고, 만료 전에 갱신하고, http 손님을 https 로 넘겨 줍니다. 다른 서버에서는 몇 달마다 되풀이하는 잡일입니다.

설치하기

# macOS
brew install caddy

# Ubuntu / Debian
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
sudo apt update && sudo apt install caddy

# Docker alone is enough
docker run -p 8080:80 -v "$PWD":/usr/share/caddy caddy

명령 한 줄로 폴더 내놓기

설정 파일이 필요 없습니다. index.html 이 있는 폴더로 가서 한 줄만 치면 됩니다 — 같은 네트워크의 누군가에게 페이지를 보여 주는 가장 빠른 방법입니다.

# serve this folder's index.html on port 8080
caddy file-server --listen :8080

# add a directory listing for folders without an index.html
caddy file-server --listen :8080 --browse

Caddyfile

오래 둘 것이라면 Caddyfile 을 씁니다. 그냥 글자 파일이고, 사이트 하나가 네 줄로 끝납니다.

example.com {
	root * /var/www/html
	file_server
	encode gzip zstd
}

1. example.com {사이트 주소입니다. 여기에 진짜 도메인을 적으면 Caddy 가 HTTPS 인증서를 알아서 마련하고, localhost 를 적으면 로컬 작업용으로 평범한 http 를 내놓습니다.
2. root * /var/www/html파일이 디스크의 어디에 있는지입니다. 별표는 이 사이트의 모든 경로에 적용한다는 뜻입니다.
3. file_server그 파일들을 실제로 내놓으라는 줄입니다. 이 줄이 없으면 Caddy 는 요청에 아무것도 주지 않습니다.
4. encode gzip zstd보내기 전에 응답을 압축합니다. 한 낱말인데, 느린 회선에서 페이지가 눈에 띄게 빨리 도착합니다.

리버스 프록시 — 요청을 넘겨주기

대부분의 사이트는 디스크의 파일이 아니라 어느 로컬 포트에서 귀를 기울이는 응용 프로그램입니다. 리버스 프록시는 바깥의 요청을 받아 그 프로그램에 건네고 답을 되돌려 주는 서버입니다. 한 줄이면 됩니다.

sonub.com {
	reverse_proxy sonub-web:3000
}

dl.sonub.com {
	root * /srv/files
	file_server browse
}

기계 한 대가 여러 사이트를 품는 방법도 이것입니다. 443 포트는 한 프로그램만 가질 수 있으므로 Caddy 가 그것을 쥐고, 손님이 어느 도메인을 찾았는지 읽어 각각 다른 프로그램으로 넘깁니다.

알아야 할 명령들

Docker: 상자에 담은 Caddy 로 진짜 사이트를 인터넷에

도커(Docker)는 프로그램과 그 프로그램이 도는 데 필요한 모든 것 — 라이브러리, 설정, 작은 운영체제까지 — 를 도커 이미지 하나에 담고, 그 이미지를 컨테이너로 실행합니다. 컨테이너는 내 노트북에서도 빌린 서버에서도 똑같이 움직이므로 "제 컴퓨터에서는 되는데요"라는 오래된 핑계가 사라집니다.

Caddy 는 이미 파일 하나인데 굳이 왜 도커를 쓸까요? 진짜 서버에서는 곧 여러 가지가 함께 돌기 때문입니다 — 사이트, 앱, 데이터베이스. 도커는 그 하나하나에 자기 상자를 주고, 같은 몇 가지 명령으로 켜고 끄고 새로 바꾸고 지웁니다. 서버에 다른 것을 설치하지 않고 이웃도 건드리지 않습니다.

먼저 알아 둘 낱말 네 개

1. 이미지프로그램과 그것에 필요한 모든 것을 얼려 둔 꾸러미입니다. 내려받거나(caddy:2) Dockerfile 이라는 조리법 파일로 직접 만듭니다. 실행하는 동안 바뀌지 않습니다.
2. 컨테이너실행 중인 이미지입니다. 이미지 하나로 컨테이너를 여러 개 띄울 수 있고, 컨테이너를 지워도 이미지는 그대로입니다 — 다음에 켜면 새것으로 시작합니다.
3. 포트 연결컨테이너에는 바깥에서 보이지 않는 자기만의 포트가 있습니다. -p 8080:80 은 내 컴퓨터의 8080 포트를 컨테이너 안의 80 포트에 이어서 브라우저가 닿을 수 있게 합니다.
4. 볼륨컨테이너가 자기 안에 쓴 파일은 컨테이너를 지우면 함께 사라집니다. 볼륨이나 컨테이너에 연결한 내 폴더는 남는 저장소입니다 — 페이지, 설정, Caddy 의 인증서가 거기에 삽니다.

도커 설치

Mac 이나 Windows PC 에서는 docker.com 에서 Docker Desktop 을 설치하고 한 번 실행해 둡니다. 그러면 터미널에서 docker 명령이 됩니다. 리눅스 서버에서는 도커의 공식 스크립트가 한 줄로 모두 설치합니다. 다음으로 넘어가기 전에 확인 명령 두 개가 모두 답해야 합니다.

# macOS · Windows: install Docker Desktop from docker.com and start it once

# Ubuntu / Debian server: Docker's official install script
curl -fsSL https://get.docker.com | sh

# check that both commands answer
docker --version
docker compose version

명령 한 줄로 Caddy 띄우기

index.html 이 있는 폴더로 가서 아래 한 줄을 실행합니다. 처음에는 도커가 Caddy 이미지를 내려받고, 그다음부터는 1초쯤이면 켜집니다. http://localhost:8080 을 열면 내 페이지가 보입니다.

# serve this folder at http://localhost:8080 (Control-C stops it)
docker run --rm -p 8080:80 -v "$PWD":/usr/share/caddy caddy:2

1. docker run이미지로 컨테이너를 만들고 실행합니다.
2. --rm멈추자마자 컨테이너를 지웁니다. 멈춘 컨테이너가 쌓이지 않게 하려는 것입니다. 이미지는 남으므로 다음 실행도 똑같이 빠릅니다.
3. -p 8080:80내 컴퓨터의 8080 포트를 Caddy 가 기다리는 컨테이너 안의 80 포트에 잇습니다. 왼쪽 숫자는 마음대로 고르고, 오른쪽 숫자는 이미지가 정해 둔 값입니다.
4. -v "$PWD":/usr/share/caddy지금 폴더($PWD)를 컨테이너 안의 /usr/share/caddy 로 보이게 합니다 — 공식 이미지가 기본으로 내놓는 폴더입니다. 여기서 파일을 고치면 다음 새로 고침에 바로 보입니다.
5. caddy:2실행할 이미지 — 공식 Caddy 이미지의 2.x 버전입니다. :2 꼬리표를 빼면 도커는 latest 를 가져오는데, 어느 날 큰 버전이 바뀌어 발밑이 흔들릴 수 있습니다.

Control-C 로 멈춥니다. 잠깐 보기에는 그만이지만 명령이 길고, 터미널을 닫는 순간 잊힙니다. 오래 둘 것은 파일에 적어 둡니다 — 그것이 다음 프로젝트입니다.

자주 쓰는 명령