HTTP는 기본적으로 Stateless하다. 즉, 이전 요청과 다음 요청 사이에 연결 정보나 상태를 유지하지 않는다. 이를 보완하기 위해 사용하는 것이 바로 쿠키(cookie)이다.
| 헤더 | 설명 |
|---|---|
Set-Cookie | 서버가 쿠키를 클라이언트에 설정할 때 사용 |
Expires | 쿠키의 유효 만료 시간 지정 (절대 시간) |
Max-Age | 쿠키의 유효 기간 (초 단위) |
Secure | HTTPS 요청에만 쿠키 전송 |
HttpOnly | JavaScript에서 접근 불가 (XSS 방지 목적) |
웹 페이지에 포함된 이미지, CSS, JS 파일은 자주 변하지 않으며 용량도 크다. 매 요청마다 다운로드하면 속도와 리소스 낭비가 크다. 이를 해결하는 기술이 바로 HTTP 캐시이다.
If-Modified-Since 헤더| 서버 상황 | 응답 코드 | 설명 |
|---|---|---|
| 변경됨 | 200 OK | 최신 자원 반환 |
| 변경 안 됨 | 304 Not Modified | 캐시된 자원 사용 가능 |
| 삭제됨 | 404 Not Found | 자원이 존재하지 않음 |
Etag과 If-None-Match 헤더Etag: 자원의 버전을 식별하는 엔티티 태그If-None-Match로 현재 Etag를 전송하여, 서버에 변경 여부를 확인결과는 위와 동일하게 200 / 304 / 404 코드로 판단된다.
📌 결론: 캐시는 단순 저장이 아닌, 서버의 상태를 고려하여 효율적으로 자원을 관리하는 시스템이다.
같은 자원을 여러 표현 방식으로 제공할 수 있다. 예를 들어, 텍스트 파일은 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을 더 선호한다는 의미
HTTP는 내용을 암호화하지 않는다. 민감한 정보가 그대로 노출될 수 있다. 이를 막기 위해 사용하는 것이 HTTPS이며, SSL/TLS 프로토콜을 기반으로 한다.
TLS 통신에서 사용되는 대칭키 또는 비대칭키 암호화 방식은 아래와 같은 흐름으로 동작한다.
👉 키가 같으면 대칭키 방식, 다르면 비대칭키 방식이다.
TLS는 클라이언트와 서버 간의 비밀키 공유, 인증서 검증, 암호화 방식 협상을 포함한다.

ClientHello (key_share 포함)ServerHello (key_share 포함), EncryptedExtensions, Certificate, CertificateVerify, FinishedFinished✔ 이 후부터는 서로 동일한 키로 암호화된 데이터 송수신 가능
크롬에서 확인:
🔒 사이트 정보보기 -> 이 연결은 안전합니다 → 인증서 유효함 → 인증서 뷰어

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

클라이언트와 서버 사이에 위치한 중간 대리 서버로, 클라이언트 요청을 받아 대신 서버에 요청을 전달하고 응답을 받아 다시 클라이언트에 전달
📌 클라이언트 입장에서 직접 오리진 서버에 접근하지 않고, 대신 요청을 수행하는 심부름꾼 같은 존재이다.
- 클라이언트가 오리진 서버에 직접 요청하는 대신, 리버스 프록시 서버가 먼저 요청을 받아 오리진 서버로 전달
📌 리버스 프록시는 서버 진영의 문지기 또는 경비 역할을 한다.
고가용성은 시스템이 장시간 중단되지 않고 동작할 수 있는 능력이다.
가용성 = 업타임 / (업타임 + 다운타임)
- 업타임(uptime): 정상 작동 시간
- 다운타임(downtime): 장애로 인해 시스템이 멈춘 시간

다수의 서버가 동일한 서비스를 제공할 때, 클라이언트 요청을 고르게 분산시켜주는 장치가 로드 밸런서(load balancer)이다.
| 알고리즘 | 설명 |
|---|---|
| 라운드 로빈 | 순서대로 하나씩 서버에 분배 |
| 최소 연결 | 현재 연결 수가 가장 적은 서버에 전달 |
| 가중치 기반 | 성능 좋은 서버에 더 많은 요청을 분산 |
📌 로드 밸런싱은 서버 과부하 방지, 서비스 안정성 향상을 목적으로 한다.
트래픽이 급증할 경우, 서버 용량을 확장하여 시스템을 유지해야 한다. 이를 스케일링이라 한다.
✅ 장점: 구성 간단
❌ 단점: 비용 증가, 한계 존재
✅ 장점: 유연한 확장
❌ 단점: 시스템 설계 복잡
${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 서버이다.
이 두 개는 데이터 흐름의 방향을 기준으로 한다.
✅ 정리: "업스트림은 데이터를 보내는 방향", 다운스트림은 그걸 받는 쪽
이 둘은 요청/응답이 어느 시스템 안으로 들어오느냐, 나가느냐를 기준으로 한다.
✅ 정리: "인바운드는 들어오는 것", 아웃바운드는 나가는 것"
Ref. 📗《이것이 취업을 위한 컴퓨터 과학이다 with CS 기술 면접》, 강민철