그림으로 배우는 Http&Network Basic 정리 - 5장. HTTP와 연계하는 웹 서버

이 시리즈는 그림으로 배우는 Http&Network Basic을 읽고 스터디 하면서 정리한 내용입니다.
추가적으로 포함되어 있는 내용은 GPT 를 이용하여서 정리한 내용으로 참고해주시면 감사하겠습니다.

 

5.1. 1대로 멀티 도메인을 가능하게 하는 가상 호스트 (Virtual Hosting)

🔹 하나의 서버에서 여러 개의 웹사이트 또는 서비스를 호스팅하는 기술을 의미
웹 서버는 기본적으로 하나의 IP 주소와 포트를 사용해 웹사이트를 서비스합니다. 하지만 하나의 서버에서 여러 개의 웹사이트를 운영하려면 방법이 필요합니다. 가상 호스팅은 이런 상황에서 사용되며, 크게 두 가지 방식이 있습니다.
 

1️⃣ IP 기반 가상 호스팅

• 각 웹사이트가 서로 다른 IP 주소를 사용.
• 같은 서버에 여러 개의 IP를 설정하여, IP마다 다른 웹사이트를 서비스함.
• 일반적으로 SSL 인증서가 필요한 환경에서 사용됨
  => 과거(구형 시스템): SNI를 지원하지 않는 환경에서 HTTPS를 적용할때
  => 현재(특정 상황): 기업 정책상 각 도메인마다 개별적인 SSL 인증서를 적용해야할때(ex. 은행, 정부기관, 대기업)

#Ngnix에서 IP 기반 가상 호스팅
server {
    listen 192.168.1.10:80;
    server_name example1.com;
    root /var/www/example1;
}

server {
    listen 192.168.1.11:80;
    server_name example2.com;
    root /var/www/example2;
}

#Apahce에서 IP 기반 가상 호스팅

<VirtualHost 192.168.1.10:80>
    ServerName example1.com
    DocumentRoot /var/www/example1
</VirtualHost>

<VirtualHost 192.168.1.11:80>
    ServerName example2.com
    DocumentRoot /var/www/example2
</VirtualHost>

 
🔹 장점:

• SSL 인증서를 각각 적용할 수 있음.
• IP마다 분리된 환경으로 설정 가능.
• 특정 사이트 트래픽이 많아도 다른 사이트에 영향을 덜 줌.

🔹 단점:

• IP 주소가 필요하므로 비용이 추가됨.
• IPv4 주소가 한정되어 있어 확장성에 제약이 있음.

 

2️⃣ 도메인 기반 가상 호스팅 (일반적으로 가장 많이 사용됨)

• 같은 IP 주소를 사용하지만, 도메인 이름에 따라 다른 웹사이트를 서비스.
• 웹 서버가 Host 헤더를 보고 클라이언트가 요청한 도메인에 맞는 웹사이트를 제공.
• 가장 일반적인 방식이며, 대부분의 웹 서버(Apache, Nginx 등)에서 사용됨

#Ngnix에서 이름 기반 가상 호스팅 설정
server {
    listen 80;
    server_name example1.com;
    root /var/www/example1;
}

server {
    listen 80;
    server_name example2.com;
    root /var/www/example2;
}

#Apahce에서 이름 기반 호스팅 설정
<VirtualHost *:80>
    ServerName example1.com
    DocumentRoot /var/www/example1
</VirtualHost>

<VirtualHost *:80>
    ServerName example2.com
    DocumentRoot /var/www/example2
</VirtualHost>

 
🔹 장점:

• 하나의 IP로 여러 개의 도메인을 운영할 수 있어 비용 절감.
• 설정이 간단하고 확장성이 좋음.

🔹 단점:

• HTTPS에서는 SSL/TLS 핸드셰이크가 먼저 실행되므로, Host 헤더를 읽기 전에 암호화과 진행되기 때문에 어려웠지만, 최근에는 SNI(Server Name Indication) 기술로 해결됨.
  [참고] SNI : 요청하는 도메인 정보를 미리 서버에 전달하는 기술
• 특정 사이트가 높은 트래픽을 유발하면 같은 서버의 다른 사이트 성능에 영향을 줄 수 있음.

💡 즉, 요즘은 대부분 "도메인 기반 가상 호스팅(SNI 적용)"이 기본이고, 특별한 경우(IP 제한, 레거시 시스템)만 "IP 기반 가상 호스팅"을 사용함! 🚀

---

 

5.2. 통신을 중계하는 프로그램 : 프록시, 게이트웨이, 터널

1️⃣ 프록시(Proxy) - 요청을 대신 보내는 중개자

• 클라이언트와 서버 사이에서 중개 역할을 하는 서버 또는 소프트웨어
• 보통 애플리케이션 계층(L7)에서 동작.
• 요청을 캐싱하거나, 보안을 강화하는 역할을 수행.

🔹 정방향  프록시 (Forward Proxy)

• 사용자가 인터넷에 직접 접근하지 않고, 프록시 서버를 거쳐 요청을 보냄
• 클라이언트 ➡️ 프록시 서버 ➡️ 웹 서버
• 주로 접근 제어, 캐싱, 익명화 기능을 수행( 일부 VPN 서비스 기능) 
• 예: 회사 내부망에서 외부 사이트 접근 시 프록시 서버를 거치는 경우. 특정 국가에서 차단된 사이트 접속, 네트워크 트래픽 제어 및 로깅

🔹 역방향  프록시 (Reverse Proxy)

• 사용자가 특정 서버에 직접 접근하지 못하도록 하고, 대신 리버스 프록시 서버의 요청을 받아 전달.
• 역방향 프록시를 통과하는 과정에서 IP가 변경될 수 있음. (예: 원래 서버 IP 대신 프록시 서버 IP가 노출됨)
• 그렇기에, 사용자가 역방향 프록시를 거쳤는지 확인하는 방법 중 하나로 쿠키를 활용할 수 있다. 프록시 서버가 특정 쿠기를 심어두면, 이후 요청에서 이를 확인할 수있는데 해당 방법을 통해 프록시가 지났다는 것을 인지할 수 있다.
• 클라이언트 ➡️ 역방향 프록시 ➡️ 백엔드 서버
• 주로 로드 밸런싱, 보안, 캐싱, SSL 처리를 수행.
• 예: Nginx를 이용하여 대규모 웹사이트에서 부하 분산 적용, 서버의 실제 IP 주소 숨기기

🔹 투명  프록시 (Transparent Proxy)

• 사용자가 인지하지 못한 상태에서 트래픽을 중계하는 프록시
• 클라이언트 ➡️ (모르는 사이) 프록시 서버 ➡️ 목적지 서버
• 알테온
• 주로 네트워크 관리자가 특정 트래픽을 감시하거나 차단할 때 사용.
• 기업 및 학교에서 인터넷 사용 감시, 공공 Wi-Fi에서 특정 웹사이트 차단, 중국의 ‘만리방화벽(Great Firewall)’으로 ISP에서 카카오톡, 유튜브, 페이스북, 구글 차단 기능

🔹 SOCKS  프록시 (SOCKS5)

• HTTP뿐만 아니라 FTP, P2P, 게임 등 다양한 프로토콜을 지원하는 고급 프록시.
• 클라이언트 ➡️ (SOCKS 프록시 서버) ➡️ 카카오톡 
• SOCK5 프록시는 특정 트래픽만 우회하며, 암호화하지 않기때문에 ISP가 감시가 가능하다. 그렇기에 암호화 기술을 함께 쓴다.
• ISP가 차단한 IP나 도메인을 직접 접속하지 않고, SOCKS 프록시를 경유하면 차단을 우회 가능

 

> 알고싶은 점1 . 정방향 프록시와 VPN 터널링의 차이

VPN : 원격 사용자가 공용 네트워크(예: 인터넷)를 통해 암호화된 터널을 만들고, 기업 내부망이나 특정 네트워크에 안전하게 접속할 수 있도록 하는 기술

• 클라이언트 ➡️ ( 암호화된 VPN 터널 ) ➡️ VPN 서버 ➡️ 인터넷 서버 

🔹 정방향 프록시와 VPN 터널링 유사점

• 직접 인터넷에 연결하는 것이 아니라, 중간에 VPN 서버나 프록시 서버를 거쳐 데이터를 주고받는 방식이다.
• IP 주소를 숨겨 인터넷 사용자의 위치를 감추거나 특정 지역에서 차단된 사이트에 접속하는 것이 가능하다.
• 중간 서버를 거치면서 네트워크 홉이 늘어나기 때문에 속도가 느려질 수 있다.

---

🔹 정방향 프록시와 VPN 터널링 차이점

• 즉, 프록시는 ISP보다 아래(L7, 애플리케이션 레벨)에서 트래픽을 처리하기 때문에 특정 트래픽(ex. 웹트래픽)을 우회하지만, ISP보다 아래에서 작동하기 때문에 ISP는 사용자의 트래픽을 감시할 수 있다.
• VPN은 ISP보다 위(L3, 네트워크 레벨)에서 모든 트래픽을 암호화하여 ISP조차 어떤 데이터를 주고받는지 알 수 없다.

👉 즉, 프록시는 ISP보다 낮은 위치에서 작동하며 웹사이트 차단을 우회하는 역할이지만, VPN은 ISP보다 높은 위치에서 네트워크 전체를 암호화하여 트래픽 감시를 차단할 수 있다! 🚀

> 알고싶은 점2. 역방향 프록시와 API 게이트웨이의 차이

🔹 역방향 프록시와 API 게이트웨이의 공통점

• 클라이언트 요청을 받아 백엔드 서버로 전달
• 보안 강화, 트래픽 관리, 로드밸런싱 가능하다.

🔹 API 게이트웨이 로드 밸런싱

-- API 게이트웨이 로드밸런싱 : API 레벨에서 트래픽을 분배하는 것
클라이언트 → (API 게이트웨이) → /users 요청 → 사용자 서비스
                        → /orders 요청 → 주문 서비스
                        → /payments 요청 → 결제 서비스
                        

-- 역방향 프록시 로드밸런싱 : 서버 단위로 트래픽을 여러 노드에 분배
사용자 → (Cloudflare) → 웹 서버 1 (80% 트래픽)
               → 웹 서버 2 (20% 트래픽)

 

 

	API 게이트웨이	역방향 프록시
주요 역할	API 요청 관리 및 보안	웹사이트 보호 및 부하 분산
처리 대상	REST API, GraphQL, gRPC 등	HTTP(S) 웹 트래픽
보안 기능	API 인증, API Rate Limiting	SSL/TLS, WAF, DDoS 방어
적용 환경	마이크로서비스, API 서버	웹사이트, CDN, 부하 분산 서버
대표 서비스	AWS API Gateway, Kong, Apigee	Nginx, HAProxy, Cloudflare

👉 API 게이트웨이는 API 요청을 통제하고 관리하는 데 최적화, 역방향 프록시는 웹사이트 보호 및 성능 최적화에 최적! 🚀

 

---

 

2️⃣ 게이트웨이(Gateway) - 서로 다른 네트워크 연결

게이트웨이는 단순한 네트워크 장비뿐만 아니라 다양한 환경에서 데이터 변환, 보안, 최적화 등의 역할을 수행하는 중요한 개념입니다. ( 좀 큰 개념.. - 종류가 여러가지이다,, 🫠 ) 

주로, OSI 7계층 모델에서 주로 네트워크 계층(3계층) 이상에서 동작한다.

어디에서 사용되는지에 따라 기능이 다를 수 있지만, 기본적으로는 서로 다른 시스템 간의 연결을 중계하는 장치 또는 소프트웨어라고 이해하면 됩니다.

 

🔹게이트웨이의 역할

1. 프로토콜 변환
   • HTTP ↔ HTTPS, FTP, WebSockets 등 서로 다른 프로토콜 간 변환 역할을 함
   • 예: 클라이언트가 HTTP 요청을 보내면, 게이트웨이가 이를 FTP 요청으로 변환하여 파일 서버와 통신
2. 백엔드 서비스 통합
   • 여러 개의 내부 서비스(API, DB, 외부 시스템)의 단일 진입점을 제공하여 클라이언트에게 통합된 응답 제공
   • 예: API Gateway가 여러 개의 마이크로서비스 요청을 하나로 모아서 클라이언트에 응답
3. 보안 및 인증
   • 인증, 권한 부여, 트래픽 필터링 등의 역할 수행
   • 예: SSL/TLS 종단점으로 작동해 HTTPS 트래픽을 복호화하고 내부 서버는 HTTP로 통신
4. 부하 분산 및 캐싱
   • 백엔드 서버 부하를 줄이기 위해 요청을 적절히 분산하거나 캐싱하여 성능을 개선
   • 예: 클라이언트가 자주 요청하는 데이터(이미지, JSON 응답)를 캐싱하여 빠르게 응답
5. 방화벽 및 트래픽 관리
   • 특정 IP 차단, 속도 제한(Throttle), DDoS 방어 등 네트워크 보호 기능 수행
   • 예: AWS API Gateway에서 요청 속도를 제한하여 악의적인 요청을 방어

👉 게이트웨이는 " 변환 & 표준화 ", 프록시는 익명화, 캐싱을 위한 "중간 대리인" 느낌 🚀

 

---

3️⃣ 터널(Tunnel) - 보안 채널(SSL, HTTPS, VPN 등) 제공

터널링(Tunneling)은 네트워크 통신에서 데이터를 특정 프로토콜을 이용해 다른 네트워크 프로토콜 내에 캡슐화(Encapsulation)하여 전송하는 기법을 의미한다. 이렇게 하면 방화벽을 우회하거나 보안이 강화된 네트워크 연결을 유지할 수 있습니다.

 

🔹터널링의 기본 원리

• 원래 통신하려는 프로토콜(A)을 지원하지 않는 네트워크에서, 다른 프로토콜(B) 안에 A를 감싸서 전달한 후, 목적지에서 원래 프로토콜(A)로 복원하는 방식입니다.
• 보통 VPN, SSH, IPSec 등의 보안 프로토콜이 사용됩니다.

🔹 터널링의 주요 목적

• 보안 강화: 데이터를 암호화하여 안전하게 전송 가능
• 방화벽 우회: 특정 네트워크에서 차단된 프로토콜을 다른 프로토콜을 이용해 전송 가능
• 비공개 통신: IP를 숨기거나 사설 네트워크를 연결 가능
• 기존 네트워크의 확장: 사설망을 인터넷을 통해 연결하여 내부 네트워크처럼 사용 가능 (예: VPN)

🔹터널링 방식

1. GRE (Generic Routing Encapsulation)
   • IP 패킷을 다른 IP 패킷 안에 캡슐화하는 방식
   • 암호화 기능이 없지만, 다양한 프로토콜을 터널링할 수 있음
2. IPSec (Internet Protocol Security)
   • IP 패킷을 암호화하여 안전하게 전송
   • 주로 VPN에서 사용됨
3. SSH 터널링 (Secure Shell Tunneling)
   • SSH를 이용하여 TCP 포트 포워딩 수행
   • 원격 서버와 보안 연결을 설정할 때 사용됨
4. SSL/TLS 터널링
   • HTTPS를 이용해 데이터를 암호화하여 보안 연결을 제공
   • 웹 기반 VPN(예: OpenVPN)에서 많이 사용됨
5. L2TP (Layer 2 Tunneling Protocol)
   • PPP 패킷을 캡슐화하여 터널링
   • IPSec과 함께 사용하면 보안성이 강화됨

---

 

5.3. 리소스를 보관하는 캐시

1️⃣ 5.3.1. 캐시의 유효기간 (Expiration)

캐시는 최신 데이터를 반영해야 하는 문제 때문에, 일정 시간이 지나면 삭제되거나 갱신되도록 설정할 수 있다.
이런 유효기간 설정을 "캐시 만료(Cache Expiration)" 또는 캐시 무효화(Cache Invalidation)라고 한다.

• TTL (Time-To-Live): 특정 시간이 지나면 자동으로 캐시 삭제됨.
• ETag (Entity Tag): 서버에서 데이터가 변경되었는지 확인하는 방법.
• Last-Modified / If-Modified-Since: 마지막으로 변경된 시간을 비교하여 캐시 유지 여부 결정.

2️⃣ 클라이언트 캐시 vs 서버 캐시

캐시는 저장 위치에 따라 클라이언트와 서버에서 관리됩니다.

① 클라이언트 측 캐시 (Client-side Cache)

👉 사용자의 웹 브라우저나 로컬 저장소에서 캐시를 저장하는 방식.

• 어디에 저장되나?
  • 웹 브라우저 (Chrome, Firefox, Edge 등)
  • 모바일 앱 (앱 내부 캐시)
  • OS 레벨 (DNS 캐시 등)
• 웹에서 사용하는 캐시 종류
  • 브라우저 캐시: HTML, CSS, JS, 이미지 등을 로컬에 저장하여 빠르게 로딩.
  • DNS 캐시: 방문한 웹사이트의 IP 주소를 저장하여 DNS 조회 시간을 줄임.
  • Service Worker Cache: 오프라인 상태에서도 웹사이트를 사용할 수 있도록 특정 데이터를 저장.
• 캐시 만료 방법
  • Cache-Control 헤더를 설정 (max-age=3600 → 1시간 후 만료)
  • Expires 헤더로 만료 날짜 지정
  • 사용자가 직접 브라우저 캐시 삭제 가능 (Ctrl + Shift + R 강제 새로고침)

✅ 예제 (Cache-Control 헤더)

http

복사편집

Cache-Control: max-age=3600, must-revalidate

(1시간 동안 캐시 유지, 만료되면 서버에서 확인)

---

② 서버 측 캐시 (Server-side Cache)

👉 서버에서 데이터를 빠르게 제공하기 위해 캐싱하는 방식.

• 어디에 저장되나?
  • CDN 캐시 (Cloudflare, Akamai 등): 전 세계 여러 서버에 데이터를 캐싱하여 빠르게 로드.
  • Database 캐시 (Redis, Memcached): 자주 조회되는 데이터베이스 결과를 저장하여 빠르게 응답.
  • Application Cache (Spring, Django, Express 등): API 응답 결과를 메모리에 저장.
• 캐시 만료 방법
  • TTL 설정 (SET key value EX 3600 → 1시간 후 만료)
  • 데이터 변경 시 캐시 자동 삭제
  • 서버 재시작 시 캐시 초기화

✅ 예제 (Redis에서 TTL 설정)

sh

복사편집

SET user:123 "John Doe" EX 3600

(1시간 후 user:123 캐시 자동 삭제)