[CS 스터디] 네트워크 정리3

오리구이·2025년 3월 26일

📡응용계층 - HTTP의 응용


🍪 쿠키: Stateless HTTP

HTTP는 기본적으로 Stateless하다. 즉, 이전 요청과 다음 요청 사이에 연결 정보나 상태를 유지하지 않는다. 이를 보완하기 위해 사용하는 것이 바로 쿠키(cookie)이다.

  • 쿠키는 <이름, 값> 쌍으로 이루어진 데이터이며, 서버가 클라이언트에 전송하여 브라우저에 저장한다.
  • 이후 같은 서버에 요청할 때 브라우저는 해당 쿠키를 요청 헤더에 포함시켜 전송한다.

쿠키 관련 주요 헤더

헤더설명
Set-Cookie서버가 쿠키를 클라이언트에 설정할 때 사용
Expires쿠키의 유효 만료 시간 지정 (절대 시간)
Max-Age쿠키의 유효 기간 (초 단위)
SecureHTTPS 요청에만 쿠키 전송
HttpOnlyJavaScript에서 접근 불가 (XSS 방지 목적)

웹 스토리지 (Web Storage)

  • 로컬 스토리지 (Local Storage): 브라우저를 꺼도 유지되는 영구 저장소
  • 세션 스토리지 (Session Storage): 브라우저가 열려 있는 동안만 유지되는 임시 저장소

📦 HTTP 캐시

웹 페이지에 포함된 이미지, CSS, JS 파일은 자주 변하지 않으며 용량도 크다. 매 요청마다 다운로드하면 속도와 리소스 낭비가 크다. 이를 해결하는 기술이 바로 HTTP 캐시이다.

캐시의 핵심 개념

  • Expires: 이 날짜 이전까지는 캐시된 자원을 그대로 사용해도 됨
  • 신선도(freshness): 캐시된 데이터가 서버의 최신 데이터와 유사한 정도
  • 유효 기간이 만료된 경우, 서버에 원본 자원이 변경되었는지 질의 후 판단

조건부 요청

🔖 If-Modified-Since 헤더

  • 클라이언트가 가진 데이터의 최종 수정 시간을 서버에 전송
  • 서버는 이 시간 이후로 자원이 수정되었는지 확인
서버 상황응답 코드설명
변경됨200 OK최신 자원 반환
변경 안 됨304 Not Modified캐시된 자원 사용 가능
삭제됨404 Not Found자원이 존재하지 않음

🔖 EtagIf-None-Match 헤더

  • Etag: 자원의 버전을 식별하는 엔티티 태그
  • 클라이언트가 If-None-Match로 현재 Etag를 전송하여, 서버에 변경 여부를 확인

결과는 위와 동일하게 200 / 304 / 404 코드로 판단된다.

📌 결론: 캐시는 단순 저장이 아닌, 서버의 상태를 고려하여 효율적으로 자원을 관리하는 시스템이다.


🌍 콘텐츠 협상(Content Negotiation)

같은 자원을 여러 표현 방식으로 제공할 수 있다. 예를 들어, 텍스트 파일은 XML, JSON, HTML 등 다양한 포맷으로 표현할 수 있다. 이 중 클라이언트에게 적합한 형식을 제공하는 것이 콘텐츠 협상이다.

📑 주요 헤더

헤더설명
Accept선호하는 미디어 타입 (ex. application/json)
Accept-Language선호하는 언어 (ex. ko-KR)
Accept-Encoding선호하는 인코딩
q품질 인자. 0~1 사이의 값으로 우선순위 표시. 높을수록 선호함

예시:

GET /api/data HTTP/1.1
Host: example.com
Accept: application/json;q=1.0, text/html;q=0.8, application/xml;q=0.6
Accept-Language: ko-KR;q=1.0, en-US;q=0.8, ja-JP;q=0.5
Accept-Encoding: gzip;q=1.0, deflate;q=0.8, br;q=0.5
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

👉 클라이언트는 JSON, 한국어, gzip을 더 선호한다는 의미


🔒 HTTPS와 TLS/SSL

HTTP는 내용을 암호화하지 않는다. 민감한 정보가 그대로 노출될 수 있다. 이를 막기 위해 사용하는 것이 HTTPS이며, SSL/TLS 프로토콜을 기반으로 한다.

HTTPS 구성 요소

  • HTTPS = HTTP + TLS
  • 통신 과정 요약:
    1. TCP 3-way 핸드셰이크
    2. TLS 핸드셰이크 (암호화 통신 준비)
    3. 실제 HTTP 메시지 송수신

🔐 암호화 알고리즘의 동작 방식

TLS 통신에서 사용되는 대칭키 또는 비대칭키 암호화 방식은 아래와 같은 흐름으로 동작한다.

🔐 암호화

  • 입력: 평문 + 키
  • 출력: 암호문

🔓 복호화

  • 입력: 암호문 + 키
  • 출력: 평문

👉 키가 같으면 대칭키 방식, 다르면 비대칭키 방식이다.


🤝 TLS 1.3 핸드셰이크 흐름

TLS는 클라이언트와 서버 간의 비밀키 공유, 인증서 검증, 암호화 방식 협상을 포함한다.

📶 핸드셰이크 순서

  1. 클라이언트 → 서버: ClientHello (key_share 포함)
  2. 서버 → 클라이언트: ServerHello (key_share 포함), EncryptedExtensions, Certificate, CertificateVerify, Finished
  3. 클라이언트 → 서버: Finished

✔ 이 후부터는 서로 동일한 키로 암호화된 데이터 송수신 가능


🛡 인증서와 보안

  • 서버는 공인된 인증기관(CA)에서 발급받은 인증서를 전송한다
  • 클라이언트는 이를 통해 서버의 신뢰성 확인

크롬에서 확인:

🔒 사이트 정보보기 -> 이 연결은 안전합니다 → 인증서 유효함 → 인증서 뷰어


🏗 프록시와 안정적인 트래픽

웹 시스템은 단순히 서버 하나로 구성되지 않는다. 수많은 사용자의 요청을 안정적으로 처리하고, 갑작스러운 부하에도 견딜 수 있어야 한다. 이를 위해 사용하는 대표적인 구조가 프록시, 로드 밸런싱, 스케일링, 고가용성 설계이다.


🧭 오리진 서버와 프록시 서버

🖥 오리진 서버(Origin Server)

오리진 서버는 자원의 최초 생성지이며, 클라이언트 요청에 대한 최종 응답을 보장할 수 있는 서버

🔁 포워드 프록시 (Forward Proxy)

클라이언트와 서버 사이에 위치한 중간 대리 서버로, 클라이언트 요청을 받아 대신 서버에 요청을 전달하고 응답을 받아 다시 클라이언트에 전달

✅ 주요 기능

  • 캐시 저장으로 응답 속도 향상
  • 클라이언트의 IP 차단 우회
  • 접근 제어, 익명성 보장

📌 클라이언트 입장에서 직접 오리진 서버에 접근하지 않고, 대신 요청을 수행하는 심부름꾼 같은 존재이다.

🛡 리버스 프록시 (Reverse Proxy, 게이트웨이)

  • 클라이언트가 오리진 서버에 직접 요청하는 대신, 리버스 프록시 서버가 먼저 요청을 받아 오리진 서버로 전달

✅ 주요 기능

  • 클라이언트는 오리진 서버를 직접 알 필요 없음
  • 오리진 서버를 숨길 수 있어 보안상 유리
  • 부하 분산, SSL 종료, 캐시 제공 등에 활용

📌 리버스 프록시는 서버 진영의 문지기 또는 경비 역할을 한다.


🔄 고가용성(High Availability)

고가용성은 시스템이 장시간 중단되지 않고 동작할 수 있는 능력이다.

📊 가용성

가용성 = 업타임 / (업타임 + 다운타임)

  • 업타임(uptime): 정상 작동 시간
  • 다운타임(downtime): 장애로 인해 시스템이 멈춘 시간

고가용성 구현 요소

  • 결함 감내(Fault Tolerance): 일부 컴포넌트가 장애를 일으켜도 전체 시스템은 작동 가능해야 한다.
  • 다중화(Redundancy): 핵심 구성 요소를 복수로 구성

대표적인 기술

  • 하트비트(Heartbeat): 서버 간 생존 여부를 신호로 주고받는 시스템
  • 헬스 체크(Health Check): 서버 상태를 주기적으로 검사

⚖️ 로드 밸런싱 (Load Balancing)

다수의 서버가 동일한 서비스를 제공할 때, 클라이언트 요청을 고르게 분산시켜주는 장치가 로드 밸런서(load balancer)이다.

주요 알고리즘

알고리즘설명
라운드 로빈순서대로 하나씩 서버에 분배
최소 연결현재 연결 수가 가장 적은 서버에 전달
가중치 기반성능 좋은 서버에 더 많은 요청을 분산

📌 로드 밸런싱은 서버 과부하 방지, 서비스 안정성 향상을 목적으로 한다.


📈 스케일링 (Scaling)

트래픽이 급증할 경우, 서버 용량을 확장하여 시스템을 유지해야 한다. 이를 스케일링이라 한다.

스케일 업(Scale Up)

  • 하나의 서버를 더 좋은 사양으로 교체
  • 수직 확장(vertical scaling)

✅ 장점: 구성 간단

❌ 단점: 비용 증가, 한계 존재

스케일 아웃(Scale Out)

  • 서버 수를 늘려서 처리 능력 향상
  • 수평 확장(horizontal scaling)

✅ 장점: 유연한 확장

❌ 단점: 시스템 설계 복잡

🔁 오토 스케일링 (Auto Scaling)

  • 실시간 트래픽 변화에 따라 자동으로 서버 수를 늘리거나 줄이는 기능
  • 예: 티켓팅 시스템, 수강 신청처럼 순간적으로 트래픽이 몰리는 상황

🧰 Nginx로 알아보는 로드 밸런싱 실전

📂 Nginx 설정 파일 구조

${nginx}/nginx.conf          # 메인 설정 파일
${nginx}/conf.d/*.conf       # 웹 서버 관련 하위 설정
${nginx}/log/nginx/          # 접근/오류 로그 저장 경로

🔧 주요 설정 예시

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        listen 80;
        server_name localhost;

        location / {
            proxy_pass http://backend;
        }
    }
}
  • listen 80: 80 포트에서 요청 대기
  • location /: 루트 경로 요청 시 처리
  • proxy_pass http://backend;: 요청을 backend 서버 그룹으로 전달

📌 Nginx는 단순 웹 서버를 넘어 리버스 프록시, 로드 밸런서 역할까지 수행할 수 있는 범용 HTTP 서버이다.


🔁 업스트림(Upstream) / 다운스트림(Downstream)

이 두 개는 데이터 흐름의 방향을 기준으로 한다.

📤 업스트림 (Upstream)

  • 요청을 보내는 쪽, 또는 상위 시스템
  • 예: 클라이언트 → 서버일 때, 클라이언트가 업스트림
  • 예: 서비스 A → 서비스 B → DB 구조에서 A는 B의 업스트림
  • 🔄 위로 흐른다 생각하면 이해 쉬움 (하류 → 상류)

📥 다운스트림 (Downstream)

  • 요청을 받는 쪽, 또는 하위 시스템
  • 예: 클라이언트 → 서버일 때, 서버가 다운스트림
  • 예: A → B → DB 구조에서 DB는 A의 다운스트림

✅ 정리: "업스트림은 데이터를 보내는 방향", 다운스트림은 그걸 받는 쪽


🔃 인바운드(Inbound) / 아웃바운드(Outbound)

이 둘은 요청/응답이 어느 시스템 안으로 들어오느냐, 나가느냐를 기준으로 한다.

🔽 인바운드 (Inbound)

  • 외부 → 내부로 들어오는 트래픽
  • 예: 외부 클라이언트가 내 API 서버로 요청 보냄 → 인바운드 요청
  • 예: 방화벽 입장에서 외부에서 들어오는 요청

🔼 아웃바운드 (Outbound)

  • 내부 → 외부로 나가는 트래픽
  • 예: 내 서버가 외부 API 호출 → 아웃바운드 요청
  • 예: 방화벽 입장에서 내부에서 외부로 나가는 요청

✅ 정리: "인바운드는 들어오는 것", 아웃바운드는 나가는 것"


Ref. 📗《이것이 취업을 위한 컴퓨터 과학이다 with CS 기술 면접》, 강민철

0개의 댓글