🔵 쿠키와 세션
HTTP는 기본적으로 무상태성(stateless) 이기 때문에
서버는 사용자가 누구인지, 이전에 어떤 요청을 보냈는지 기억하지 못합니다.
이 한계를 해결하기 위해 등장한 기술이 바로 쿠키와 세션입니다.
< 쿠키(Cookie) >
쿠키는 웹 브라우저에 저장되는 작은 데이터로,
서버가 클라이언트를 식별하거나 설정값을 유지하기 위해 사용합니다.
주요 특징
- 서버가 생성 → 클라이언트(브라우저)에 저장
- 요청마다 자동으로 서버에 전송됨
- 로그인 유지·사용자 설정·광고 트래킹 등에 많이 사용
- 만료 시간/도메인/경로 설정 가능
장점
- 구현이 단순하고 빠름
- 별도 서버 자원 사용 X
- 상태 유지 기능을 최소 비용으로 제공
한계
- 클라이언트 저장 방식이라 보안 취약
(탈취·변조 가능 → Secure, HttpOnly, SameSite 필요)
- 브라우저별로 저장되기에 환경이 달라지면 일관성 유지 어려움
- 저장 가능한 용량이 매우 작음(브라우저별 약 4KB 수준)
쿠키의 이러한 한계 때문에 민감한 정보나 인증 정보를 직접 저장하는 것은 위험하며,
대부분은 세션 ID 같은 최소한의 식별자만 저장하는 방식으로 사용됩니다.
< 세션 >
세션은 서버에서 사용자 상태를 관리하는 방식입니다.
사용자가 로그인하면 서버는 세션을 만들고
그 세션을 가리키는 세션 ID만을 쿠키로 클라이언트에 전달합니다.
동작 구조
- 사용자가 로그인
- 서버가 세션 저장소에 사용자 정보를 저장
- 세션 ID를 쿠키에 담아 사용자에게 전달
- 이후 요청마다 세션 ID를 이용해 서버가 해당 사용자를 식별
장점
- 사용자 정보가 서버에 있어 보안성이 높다
- 세션 무효화가 즉각 가능(로그아웃, 세션 삭제)
단점
- 서버 메모리를 사용 → 동접 많으면 부담
- 서버가 여러 대일 경우 세션 공유 문제가 발생 → Redis 같은 세션 스토리지 필요
- 확장성이 낮아지기 쉽다
세션은 보안면에서 쿠키보다 강하지만 규모가 커질수록 비용이 증가하고
인프라 구성이 복잡해진다는 단점이 있습니다.
🔵 JWT 토큰
JWT는 서버가 인증 상태를 저장하지 않는
무상태 인증 방식입니다.
사용자 정보가 세션처럼 서버에 저장되는 것이 아니라,
토큰 자체에 포함되어 클라이언트가 직접 가지고 다닌다는 점이 가장 큰 특징입니다.
JWT는 크게 Header, Payload, Signature 세 부분으로 이루어져 있습니다.
- Header에는 토큰이 어떤 알고리즘으로 서명되었는지 등
토큰의 기본 정보가 들어 있습니다. - Payload에는 사용자 ID, 권한, 만료시간 같은
인증에 필요한 실제 사용자 정보(Claim)가 담겨 있습니다.
이 정보 덕분에 서버는 별도의 세션 저장 없이도 사용자를 식별할 수 있습니다. - Signature는 토큰이 위조되지 않았음을 확인하기 위한
서명값입니다.
서버는 이 서명을 검증하는 것만으로 토큰의 신뢰성을 판단합니다.
이 구조 덕분에 서버 확장이 잦거나 여러 대인 환경에서
상태 공유 없이 인증을 처리할 수 있다는 장점이 있습니다.
하지만 JWT는 세션 ID보다 크기가 큽니다.
이를 해결하기 위해 필요한 Claim만 넣고 최소한으로 유지하거나,
Access Token은 짧게 가져가고
Refresh Token으로 재발급하는 방식을 활용합니다.
🔵 JWT 토큰과 세션의 차이
세션과 JWT의 큰 차이는 인증 상태를 어디에 저장하느냐입니다.
세션은 서버가 사용자 상태를 저장하는 Stateful 방식이라,
클라이언트는 단순히 세션 ID만 보내고 실제 인증 정보는 서버에 보관됩니다.
이 구조 덕분에 서버가 세션을 삭제하는 것만으로 즉시 무효화가 가능하고,
민감한 정보도 클라이언트에 노출되지 않아 보안적으로 유리합니다.
다만 서버가 상태를 들고 있어야 하기 때문에
여러 대의 서버로 확장할 때는 세션 공유나 외부 저장소가 필요합니다.
반면 JWT는 인증 정보를 토큰 안에 담아 클라이언트가 직접 보관하는 Stateless 방식입니다.
서버는 토큰의 서명만 검증하면 되므로 서버 간 상태 공유가 필요 없고,
분산 환경이나 모바일·SPA 같은 구조에서 확장성이 뛰어납니다.
하지만 토큰 자체가 크고 모든 요청마다 전송되며,
또 서버가 상태를 저장하지 않기 때문에
발급된 토큰을 즉시 무효화하기 어려운 구조적 단점이 있어
일반적으로 Access Token과 Refresh Token을 함께 사용하는 방식으로 보완합니다.
🔵 리프레시 토큰이 등장한 이유
JWT는 한 번 발급된 Access Token을 서버가 임의로 즉시 무효화할 수 없는 구조적 한계가 있습니다.
Access Token은 유효기간(exp) 기반으로만 판단되기 때문에,
탈취되면 만료되기 전까지 악용될 위험이 존재합니다.
이 한계를 보완하기 위해 Access Token + Refresh Token 구조가 사용됩니다.
Refresh Token은 서버가 저장하거나 관리할 수 있기 때문에
유출이 발생하면 서버 측에서 즉시 폐기하거나 차단할 수 있으며,
만료된 Access Token을 안전하게 재발급하는 역할을 합니다.
따라서 짧은 만료시간의 Access Token과
장기 보관되는 Refresh Token 조합을 사용함으로써
보안성과 사용자 경험을 확보할 수 있습니다.
만약 Access Token이 탈취되더라도
짧은 만료 시간을 통해 피해를 최소화할 수 있고,
Refresh Token은 서버가 가진 저장소(예: DB·Redis)에서 관리되므로
유출 시 즉시 폐기하거나 재발급을 중단할 수 있습니다.
또한 Refresh Token을 이용한 재사용 감지(Reuse Detection) 기법을 적용하면
Refresh Token이 복제되어 두 번 사용되는 패턴을 탐지하여
계정 탈취나 토큰 복제 공격을 빠르게 차단할 수 있습니다.
🔵 리프레시 토큰의 도입으로 JWT 토큰이 상태를 갖게 되면, 세션과의 차이
리프레시 토큰을 도입하면 서버가 리프레시 토큰을 저장하거나 검증해야 하므로
JWT 인증도 일부 상태(State)를 갖게 됩니다.
그러나 이는 세션 방식과는 성격이 다릅니다.
✅ 1) 저장하는 “상태”의 범위
세션(Session)
- 서버가 사용자 상태(로그인 정보, 권한, 세션 데이터 전부)를 저장합니다.
JWT + 리프레시 토큰
- 서버는 사용자 전체 상태를 저장하지 않고,
리프레시 토큰 자체만 저장하거나
블랙리스트·화이트리스트 형태로 토큰 유효성만 관리합니다.
✅ 2) 인증의 중심
세션(Session)
인증의 중심은 서버 저장소에 있는 세션 데이터입니다.
서버가 기억하는 정보가 곧 인증의 근거입니다.
JWT 인증
인증의 중심은 클라이언트가 가진 액세스 토큰 자체이며,
서버는 서명 검증만으로 사용자를 식별합니다.
리프레시 토큰은 “추가 발급 관리” 용도일 뿐 인증의 중심이 아닙니다.
✅ 3) 확장성(Scalability) 측면
세션(Session)
전체 사용자 상태를 서버가 저장하므로
서버가 늘어날수록 세션 공유 문제가 발생합니다.
JWT + 리프레시 토큰
서버가 관리하는 정보가 제한적이기 때문에
여전히 수평 확장에 유리한 구조를 유지합니다.
✅ 4) 무효화 방식
세션(Session)
서버에서 세션 데이터를 삭제하면 즉시 무효화됩니다.
JWT
액세스 토큰은 여전히 무효화하기 어렵고
리프레시 토큰만 서버에서 제거하여
추가 토큰 발급을 차단하는 방식으로 무효화를 처리합니다.
🔵 SOP와 CORS
✅ 1) SOP(Same-Origin Policy)
SOP는 브라우저가 보안 강화를 위해 적용하는 기본 정책으로
같은 출처(origin) 에서만 리소스를 자유롭게 요청할 수 있도록 제한합니다.
출처는 아래 3가지 조합으로 결정됩니다.
- 프로토콜 (http/https)
- 도메인
- 포트
이 3가지 중 하나라도 다르면 다른 출처로 간주되며,
브라우저는 민감한 리소스 접근을 차단합니다.
✅ 2) CORS(Cross-Origin Resource Sharing)
CORS는 브라우저의 SOP 정책 때문에 기본적으로 차단되는
‘교차 출처 요청’을 예외적으로 허용하기 위한 표준 규약입니다.
서버가 응답 헤더를 통해 “이 출처의 요청은 허용해도 된다”라고
명시적으로 선언함으로써 브라우저가 요청을 허용할지 결정합니다.
서버는 응답 헤더로 아래와 같은 정보를 설정하여 허용 여부를 결정합니다.
- Access-Control-Allow-Origin
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
- Access-Control-Allow-Credentials
브라우저는 이 값을 검사하여
서버가 허용한 요청만 교차 출처 요청으로 인정합니다.
CORS는 SOP를 우회하는 것이 아니라,
SOP 위에서 “서버가 허용한 요청만 예외적으로 열어주는 방식”입니다.
🔵 REST / Restful API
REST는 리소스를 URI로 표현하고,
GET·POST·PUT·DELETE 같은 HTTP 메서드로 그 리소스를 다루는 방식입니다.
그리고 이 규칙을 지켜 만든 API를 RESTful API라고 합니다.
✅ REST 핵심 개념
- 리소스(Resource) 중심 설계
- 고유한 URI로 리소스 식별
- HTTP 메서드 활용 (GET, POST, PUT, DELETE 등)
- 무상태성(Stateless)
- 일관된 응답 구조
✅ RESTful API 특징
- 리소스는 명사로 표현합니다. (/users, /orders/1)
- 행동은 HTTP 메서드로 표현합니다.
GET: 조회
POST: 생성
PUT/PATCH: 수정
DELETE: 삭제
- 상태를 서버에 저장하지 않습니다.
- API가 일관되고 직관적이며 확장성이 높습니다.
🔵 REST 제약 조건
✅ 1) 클라이언트-서버(Client-Server)
클라이언트와 서버의 역할을 명확히 분리합니다.
클라이언트는 UI·사용자 경험을 담당하고,
서버는 데이터 처리와 저장을 담당합니다.
역할 분리를 통해 유지보수성과 확장성이 증가합니다.
✅ 2) 무상태성(Stateless)
서버는 각 요청을 독립적으로 처리하며
이전 요청의 상태를 저장하지 않습니다.
요청에는 서버가 처리하는 데 필요한 모든 정보가 포함되어야 합니다.
✅ 3) 캐시 가능(Cacheable)
응답은 캐싱이 가능한지 여부를 명시해야 합니다.
캐시는 네트워크 트래픽을 줄이고 성능을 크게 높입니다.
HTTP의 Cache-Control, ETag가 대표적입니다.
✅ 4) 계층화 시스템(Layered System)
클라이언트가 서버와 직접 통신한다고 느끼게 하지만,
실제로는 프록시·캐시·로드밸런서 같은 중간 계층을 자유롭게 둘 수 있도록 하는 제약 조건입니다.
✅ 5) 일관된 인터페이스(Uniform Interface)
REST의 핵심 제약 조건입니다.
서버의 리소스를 일관된 방식으로 식별하고 조작할 수 있어야 합니다.
주요 요소는 다음과 같습니다.
- 리소스는 URI로 식별합니다.
- 리소스 조작은 HTTP 메서드로 표현합니다.
- 표현(Representation)을 통해 리소스를 주고받습니다.
🔵 URL, URI, URN 차이
1) URI(Uniform Resource Identifier)
“이 리소스가 무엇인지 식별할 수 있는 문자열”이 URI입니다.
URL과 URN을 모두 포함하는 상위 개념입니다.
2) URL(Uniform Resource Locator)
URL은 리소스의 위치(어디에 있는가)를 나타내는 URI의 한 종류입니다.
프로토콜, 도메인, 경로 등이 포함됩니다.
(예시)
https://example.com/users/1
“리소스의 주소(위치)를 알려주는 URI”가 URL입니다.
3) URN(Uniform Resource Name)
URN은 리소스의 이름을 나타내는 URI의 한 종류로,
위치와 관계없이 리소스를 고유하게 식별합니다.
변하지 않는 고유한 이름을 부여하는 방식입니다.
(예시)
urn:isbn:9783161484100
🔵 XSS 공격 / 방어하는 방법
XSS(Cross-Site Scripting) 공격은
공격자가 웹 페이지에 악성 스크립트(JavaScript 등)를 주입하여
사용자의 브라우저에서 실행되도록 만드는 공격입니다.
이를 통해 공격자는
- 쿠키 탈취
- 세션 하이재킹
- 악성 요청 유도
- 화면 변조
등 다양한 공격을 수행할 수 있습니다.
XSS 공격 유형
1) 저장형(Stored XSS)
공격자가 주입한 악성 스크립트가 서버 또는 DB에 저장된 뒤,
해당 데이터를 조회하는 모든 사용자 브라우저에서 자동으로 실행되는 공격입니다.
2) 반사형(Reflected XSS)
URL 파라미터 등에 주입된 스크립트가 서버 응답에 즉시 반영되어 실행되는 공격으로
사용자가 악성 링크를 한 번만 클릭해도 피싱·쿠키 탈취 등이 즉시 발생할 수 있어 위험합니다
3) DOM 기반 XSS
서버 응답 자체는 안전하지만
클라이언트 측 JavaScript가 사용자 입력을 DOM에 삽입하는 과정에서
필터링 없이 처리되어 브라우저 내에서 스크립트가 실행되는 공격
XSS 방어 방법
1) 출력 시 이스케이프(Escape) 처리
HTML에 값을 출력할 때 < > " ' & 같은 문자를
<, > 등으로 HTML 이스케이프합니다.
악성 스크립트를 “코드”가 아니라 “글자”로 바꿔 버려서
브라우저가 실행할 수 없도록 만드는 방식입니다.
2) 입력 값 검증(Input Validation)
사용자가 입력한 값 중에서 <script>나 onclick 같은 위험한 코드 조각이 들어 있다면
그 부분을 미리 걸러내거나 삭제해서 악성 스크립트가 실행되지 않도록 막는 방식입니다.
3) Content Security Policy(CSP) 적용
CSP는 브라우저에게 ‘어디서 온 스크립트만 실행해라’라고 지정하는 보안 규칙입니다.
허용되지 않은 외부 스크립트나 인라인 스크립트는 아예 실행되지 않기 때문에
XSS가 성공하더라도 실제 실행을 크게 막을 수 있는 강력한 방어 방법입니다.
4) HttpOnly 쿠키 사용
HttpOnly 옵션을 주면 쿠키를 JavaScript로 읽을 수 없게 만들어
XSS가 발생하더라도 공격자가 쿠키를 훔치지 못하게 막는 방식입니다.
5) 라이브러리/프레임워크의 기본 방어 기능 사용
React나 Vue, Spring 같은 최신 프레임워크는
기본적으로 위험한 입력을 자동으로 이스케이프해 XSS를 막아줍니다.
이런 내장된 보안 기능을 활용하면 개발자가 실수로 취약점을 만들 가능성을 크게 줄일 수 있습니다.
🔵 CSRF 공격 / 방어하는 방법
CSRF는 브라우저가 인증 정보를 자동으로 전송한다는 특징을 악용해,
사용자가 의도하지 않은 요청을 공격자가 대신 보내도록 만드는 공격입니다.
결과적으로 인증된 사용자의 권한으로
송금, 설정 변경 같은 민감한 동작이 실행될 수 있습니다.
발생 원인은 크게 두 가지입니다.
1) 쿠키 기반 인증에서, 외부 사이트의 요청도 쿠키가 자동 전송되는 점
2) 요청이 실제 사용자가 의도한 것인지 추가 검증이 부족한 점
이를 방어하기 위한 전략은 다음과 같습니다.
CSRF Token 사용
서버가 매 요청마다 예측 불가능한 토큰을 요구해 공격자가 위조 요청을 보내지 못하도록 함
Synchronizer Token, Double Submit Cookie 방식 등 존재
SameSite 쿠키 옵션 설정
SameSite=Lax 또는 Strict로 설정해 외부 사이트에서 발생한 요청에는 쿠키가 전송되지 않도록 제한
Referer / Origin 검사
요청의 출처가 동일한 도메인인지 확인하여 외부에서 온 요청 차단
민감 동작은 GET 금지
GET 요청은 브라우저/링크/이미지 요청만으로도 실행될 수 있으므로
중요한 동작은 반드시 POST, PUT 등을 사용해 의도를 명확히 해야 함
🔵 SQL Injection 공격 / 방어하는 방법
SQL Injection은 사용자가 입력한 값이 그대로 SQL문에 삽입되어 실행되는 취약점을 악용한 공격입니다.
공격자는 입력 필드나 URL 파라미터에 SQL 구문을 주입하여
데이터 조회, 수정, 삭제, 관리자 로그인 우회 등 다양한 공격을 수행할 수 있습니다.
예를 들어, 로그인 쿼리에
' OR '1'='1
같은 값을 주입하면 WHERE 조건이 항상 참이 되어 인증을 우회할 수 있습니다.
본질적으로 문자열 기반 SQL 조립 과정에서 입력값이 코드로 실행되는 것이 문제의 핵심입니다.
SQL Injection 방어 방법
1) Prepared Statement(Prepared Query) 사용
SQL 구문과 입력 값을 명확히 분리하여 처리합니다.
플레이스홀더(?, :id 등)를 사용하면
입력값이 SQL로 실행되지 않고 단순한 데이터로 취급됩니다.
가장 확실하고 권장되는 방어법입니다.
2) ORM 사용 시 바인딩 처리 활용
JPA, Hibernate, MyBatis, Sequelize 등 ORM/프레임워크는
기본적으로 Prepared Statement 기반의 파라미터 바인딩을 제공하므로
직접 문자열로 쿼리를 조립할 때 발생하는 SQL Injection을 효과적으로 방지합니다.
3) 입력 값 검증(Input Validation)
숫자만 허용되는 필드라면 숫자만 허용하는 등
입력값의 형식을 사전에 강제하여 위험한 데이터가 SQL까지 도달하지 않도록 합니다.
바운더리 차단 방식으로 안전성을 추가하는 접근입니다.
4) 최소 권한 원칙 적용
서비스 계정에 불필요한 권한(UPDATE, DELETE, DROP 등)을 부여하면
Injection 성공 시 피해가 치명적입니다.
역할에 맞게 최소 권한만 부여하면 공격이 성공하더라도 피해 범위를 줄일 수 있습니다.
5) 에러 메시지 노출 제한
DB 에러를 그대로 반환하면 테이블 구조나 컬럼 정보가 노출될 수 있어
추가 공격에 이용될 수 있습니다.
서버에서 커스텀 에러로 포장해 응답하도록 구성합니다.
🔵 웹 캐시
웹 캐시는 네트워크 성능을 개선하고 서버 부하를 줄이기 위해
데이터를 저장해 두었다가 재사용하는 구조이며
크게 세 가지 계층에서 작동합니다.
1) 브라우저 캐시(Client Cache)
사용자 브라우저가 이미지, CSS, JavaScript 같은 정적 리소스를 저장해 두는 방식입니다.
다음 요청 시 서버까지 가지 않고 로컬에서 바로 제공되기 때문에
가장 빠른 캐시 형태이며 네트워크 비용을 아낄 수 있습니다.
Cache-Control, Expires, ETag 같은 HTTP 헤더로 캐싱 정책을 제어합니다.
2) 프록시 캐시(중간 캐시)
클라이언트와 서버 사이의 프록시 서버 또는 CDN이 캐싱을 수행합니다.
여러 사용자가 동일한 데이터를 요청할 때 중간 캐시가 응답을 제공하므로
원본 서버의 트래픽과 부하를 크게 줄일 수 있습니다.
3) 서버 캐시(Application Cache)
애플리케이션 내부에서 데이터를 캐싱하는 방식입니다.
주로 DB 조회 결과나 비용이 큰 연산 결과를 저장해두고 빠르게 제공하기 위해 사용합니다.
Redis, Memcached 같은 인메모리 캐시가 대표적입니다.
캐시 제어를 위한 주요 헤더
✔ Cache-Control
캐싱 가능 여부, 유효 시간, 재검증 방식을 정의합니다.
예: Cache-Control: max-age=3600, public
✔ ETag
ETag는 리소스를 나타내는 고유한 해시값 또는 식별자입니다.
클라이언트가 다음 요청 시 If-None-Match와 함께 보내면
서버는 ETag 비교만으로 변경 여부를 판단할 수 있습니다.
- 변경 없음 → 304 Not Modified (바디 없이 캐시 재사용)
- 변경됨 → 새 리소스 + 새 ETag 반환
✔ Last-Modified / If-Modified-Since
리소스가 마지막으로 수정된 시점을 나타내며,
클라이언트는 이를 If-Modified-Since로 다시 보냅니다.
- 변경 없음 → 304 Not Modified
- 변경됨 → 새 리소스와 새 수정 시각 전달
🔵 프록시 서버
프록시 서버는 초기 인터넷 구조가 가진 여러 한계를 해결하기 위해 등장했습니다.
초기 웹은 클라이언트가 서버에 직접 연결되는 단순한 구조였는데,
이 방식에서는 보안 취약성, 서버 과부하, 네트워크 비용 증가 같은 문제가 빠르게 드러났습니다.
첫 번째로, 보안 문제가 컸습니다.
클라이언트와 서버가 직접 통신하면 서로의 실제 IP가 그대로 노출되기 때문에
공격 대상이 쉽게 식별되고, 악성 요청을 걸러낼 방법도 부족했습니다.
이 때문에 중간에서 요청을 대신 받아 주고 필터링할 수 있는 계층이 필요했고
프록시가 보안 게이트웨이 역할을 하게 되었습니다.
두 번째로, 서버 부하와 트래픽 비용을 줄이기 위해 필요했습니다.
웹 트래픽이 급증하면서 동일한 정적 리소스를 반복해서 내려주는 것이 큰 부담이 되었고,
이를 해결하기 위해 “한 번 받은 데이터를 저장해 여러 사용자에게 제공하는 캐싱 프록시”가 등장했습니다.
이 구조는 원본 서버의 부하를 크게 줄이고 응답 속도도 개선했습니다.
세 번째로, 조직·기업 환경에서 접근 제어를 하기 위해 도입되었습니다.
특정 사이트 차단, 내부망 보호, 사용자 트래픽 관리 같은 정책을 적용하려면
네트워크 중간에 제어 지점이 필요했고 프록시가 자연스럽게 이 역할을 맡았습니다.
마지막으로, 서비스 규모가 커지면서 로드밸런싱이라는 개념이 등장했고
리버스 프록시 형태로 요청을 여러 서버에 분산하는 구조가 발전했습니다.
오늘날의 Nginx, HAProxy, Envoy 같은 로드밸런서들이
모두 이 프록시 개념에서 출발한 기술입니다.
🔵 포워드 프록시
포워드 프록시는 클라이언트 앞단에서 동작하는 프록시 서버로,
클라이언트가 서버와 직접 통신하지 않고
프록시가 대신 요청을 전달하는 구조입니다.
포워드 프록시의 핵심 목적은 클라이언트 정보 보호와 접근 제어입니다.
프록시가 외부와 통신하기 때문에 클라이언트의 실제 IP가 노출되지 않아 보안이 강화되고,
조직에서는 특정 사이트 차단·업무용 트래픽 정책 적용 같은 네트워크 관리가 가능합니다.
또한 자주 요청되는 리소스는 프록시가 캐싱하여
원본 서버를 거치지 않고 빠르게 응답할 수 있어 성능 향상에 효과가 있습니다.
대표적인 예로 회사 내부망에서 외부 인터넷에 접속할 때 쓰는
‘사내 프록시 서버’가 포워드 프록시에 해당합니다.
🔵 리버스 프록시
리버스 프록시는 서버 앞단에서 동작하여
클라이언트 요청을 여러 내부 서버로 대신 전달하고,
그 결과를 다시 클라이언트에게 응답해 주는 구조입니다.
클라이언트가 실제 내부 서버와 직접 통신하면
서버 IP·구조가 노출되고 공격 표면이 넓어지는 문제가 있었고,
또한 단일 서버가 처리할 수 있는 트래픽에 한계가 있었기 때문에
중간에서 요청을 분산해 줄 계층이 필요했습니다.
리버스 프록시는 이러한 문제를 해결합니다.
클라이언트는 항상 리버스 프록시와만 통신하므로
내부 서버의 위치, 개수, 구조가 외부에 노출되지 않아 보안이 강화됩니다.
또한 리버스 프록시는 로드 밸런싱을 수행하여
요청을 여러 서버로 효율적으로 분산시키고 과부하를 방지합니다.
정적 파일 캐싱, 압축, SSL 종료(SSL termination) 같은 기능을 통해
전체 응답 성능도 크게 향상시킵니다.
대표적으로 Nginx, Apache, HAProxy, Envoy 등이
리버스 프록시 역할을 수행하는 대표적인 소프트웨어입니다.
🔵 커넥션 타임아웃과 리드 타임아웃
커넥션 타임아웃과 리드 타임아웃은 네트워크 통신 과정에서
어디까지 기다릴 것인가를 구분해서 설정하는 개념입니다.
먼저 커넥션 타임아웃은
클라이언트가 서버와 연결 자체를 맺는 과정을
얼마나 기다릴지를 의미합니다.
예를 들어 서버가 죽어 있거나 네트워크가 끊겨 있어
소켓 연결이 성립되지 않는 상황에서
정해진 시간 동안 연결이 안 되면 커넥션 타임아웃이 발생합니다.
반면 리드 타임아웃은
연결이 이미 성공한 이후,
서버가 응답 데이터를 보내기까지 기다리는 시간입니다.
요청은 정상적으로 전달되었지만
서버 처리 시간이 너무 오래 걸리거나
응답이 오지 않을 때 리드 타임아웃이 발생합니다.
정리하면
커넥션 타임아웃은 “연결될 때까지 기다리는 시간”,
리드 타임아웃은 “응답이 올 때까지 기다리는 시간”을 의미하며
두 타임아웃을 적절히 설정하는 것이
시스템 안정성과 사용자 경험을 위해 매우 중요합니다.
'Programming > 컴퓨터 네트워크' 카테고리의 다른 글
| 🔵 네트워크 레이어, IP 프로토콜 (0) | 2025.12.17 |
|---|---|
| 🔵 UDP & TCP (1) | 2025.12.11 |
| 🔵 HTTP/1.1 vs HTTP/2 vs HTTP3 차이 (0) | 2025.11.25 |
| 🔵 HTTP 🟢 HTTPS 🔴 DNS (0) | 2025.11.25 |
| 🔵 TCP/IP & OSI 7 Layer (0) | 2025.11.20 |
