HTTP

27 posts
Caddy: 인증서를 신경 쓰지 않아도 되는 웹 서버

Caddy: 인증서를 신경 쓰지 않아도 되는 웹 서버

사이드 프로젝트를 서버에 처음 올려본 사람이라면 비슷한 밤을 보냈을 겁니다. 앱은 이미 3000번 포트에서 잘 돌아갑니다. 정작 반나절이 날아가는 쪽은 그걸 바깥에서 접속하게 만드는 일이죠. Nginx 설정 파일에서 server 블록과 location 블록의 중괄호를 세어 보고, Let's Encrypt 인증서를 받으려고 certbot을 깔고, 갱신이 제대로 도는지 확인하려고 cron 로그를 뒤지는 식입니다. 서비스 로직은 한 줄도 건드리지 않았는데 말이죠. 😅 Caddy는 바로 이 지점을 겨냥한 웹 서버입니다. Go로 작성된 오

Cache-Control 헤더 정리: max-age부터 stale-while-revalidate까지

Cache-Control 헤더 정리: max-age부터 stale-while-revalidate까지

웹 페이지를 두 번째 열 때 첫 번째보다 훨씬 빨리 그려지는 경험을 한 번쯤 해보셨을 겁니다. 어딘가에서 그 자원을 미리 들고 있다가 다시 꺼내준 결과인데, 이 "미리 들고 있다"가 곧 캐시이고요. 브라우저, 회사 프록시, CDN, 원본 서버 앞 모두 캐시가 자리할 수 있어 한 자원이 여러 곳에 사본을 가질 수 있는 셈입니다. 문제는 이렇게 흩어진 캐시들이 서로 다른 규칙으로 동작하면 곤란하다는 점입니다. 한 캐시는 1시간을 보관하고 다른 캐시는 영원히 보관하는 식이면 운영자가 원하는 정책을 만들 수가 없죠. 그래서 HTTP는 모든

프록시 서버와 리버스 프록시

프록시 서버와 리버스 프록시

로컬에서 혼자 웹 앱을 개발하던 사람이 회사 운영 환경을 처음 만지면 꼭 듣게 되는 말이 있어요. "앞단에 nginx를 둘 거예요"라든지, "프록시 통해서 바깥으로 나가야 해요" 같은 문장인데요. 두 쪽 다 "프록시"라는 단어가 들어가는데, 가리키는 대상이 아예 반대입니다. 앞의 것은 리버스 프록시, 뒤의 것은 포워드 프록시예요. 이 글에서는 두 프록시가 어떻게 다른지, 왜 같은 이름을 쓰면서 역할은 서로 반대인지, 실무에서 어디에 어떻게 배치되는지를 차근차근 풀어보려 합니다. 프록시가 대체 뭐였죠? 프록시(proxy)라는 단어는

헷갈리는 HTTP 헤더 총정리: Host, Origin, Referer

헷갈리는 HTTP 헤더 총정리: Host, Origin, Referer

웹 개발을 하다 보면 브라우저 개발자 도구에서 HTTP 요청 헤더를 뜯어볼 일이 종종 있잖아요? 그때 Host, Origin, Referer... 이 세 녀석이 나란히 있는 걸 보면 "이거 다 비슷한 거 아닌가?" 싶을 때가 있는데요. 헤더 자체가 처음이라면 HTTP 메시지가 어떻게 생겼는지부터 보고 오시면 흐름이 더 잘 잡힙니다. 셋 다 URL이나 도메인 정보를 담고 있으니까 대충 같은 역할처럼 보이거든요. 그런데 막상 CORS 문제를 디버깅하거나 보안 설정을 건드려야 할 때 이 헤더들의 차이를 정확히 모르면 삽질을 피할 수가 없

로드 밸런서 정리: 부하 분산 알고리즘부터 운영 포인트까지

로드 밸런서 정리: 부하 분산 알고리즘부터 운영 포인트까지

처음 웹 서버를 돌릴 때는 한 대만 잘 띄워 두면 충분합니다. 그런데 사용자가 늘고 트래픽이 점점 무거워지면, 어느 순간 한 대로는 감당이 안 되는 시점이 옵니다. 사양을 키우는 방법(스케일 업)도 있지만, 한 대를 더 띄워서 일을 나누어 시키는 방법(스케일 아웃)이 더 자연스러운 선택일 때가 많은데요. 이 분산을 책임지는 도구가 로드 밸런서입니다. 이름 그대로 트래픽이라는 부하를 여러 서버에 나눠 주는 장치인데, 막상 들여다보면 "어떤 기준으로 나누느냐", "어느 계층에서 동작하느냐", "한 대가 죽으면 어떻게 알아채느냐"처럼 결

HTTPS란 무엇인가: TLS와 인증서로 HTTP를 보호하는 원리

HTTPS란 무엇인가: TLS와 인증서로 HTTP를 보호하는 원리

브라우저 주소창에 작은 자물쇠 아이콘이 켜져 있으면 우리는 별다른 의심 없이 정보를 입력합니다. 비밀번호를 치고, 카드 번호를 넣고, 메시지를 보내는데요. 이 자물쇠 한 칸이 사실은 HTTP 위에 한 겹의 보호막을 덧씌운 결과인 셈입니다. HTTPS는 이름에서도 짐작되듯 HTTP에 보안(Secure)을 보탠 형태입니다. 정확히 말하면 HTTP를 TLS라는 암호 통신 위에서 흘려보내는 구조인데요. 이번 글에서는 평문 HTTP가 왜 위험한지, TLS가 그 위에 무엇을 더하는지, 그리고 우리가 평소에 보는 인증서와 자물쇠가 어떻게 신뢰를

요청과 응답으로 알아보는 HTTP와 버전 이야기

요청과 응답으로 알아보는 HTTP와 버전 이야기

웹 페이지 하나를 여는 일을 한 줄로 요약하면 "브라우저가 서버한테 뭔가 달라고 부탁하고, 서버가 그걸 보내준다"입니다. 이 단순한 부탁을 둘 사이에서 약속된 모양으로 주고받게 만든 것이 HTTP입니다. 이름이 길어 보이지만 풀어보면 HyperText Transfer Protocol, "문서를 주고받기 위한 약속" 정도로 옮길 수 있죠. 그런데 한 가지 호기심이 생깁니다. 이렇게 단순한 약속이 오랫동안 살아남으면서, 뒷자리 숫자만 1.0에서 1.1, 2, 3까지 바뀌어 왔다는 점이죠. 같은 이름을 달고도 토대를 TCP에서 UDP로

Discord