[네트워크] Stateless & Connectionless: 서버는 왜 Stateless? HTTP/1.1부터 왜 Persistent Connection?

반응형

🌏 Stateless & Connectionless

✅ Stateless

• 서버가 클라이언트의 상태 정보를 유지하지 않는 특성
• 각 요청은 독립적인 트랜잭션으로 취급, 이전 요청의 맥락을 알지 못함
• 클라이언트가 매 요청마다 필요한 모든 정보를 담아서 전달해야 함
• HTTP 기본 동작이 Stateless하기 때문에 세션(Session)이나 JWT를 통해 상태 유지를 별도로 구현
• 장점
  • 서버 확장성 향상, 부하 분산 용이
  • 장애 복구 및 로드 밸런싱에 유리
• 단점
  • 같은 클라이언트라 하더라도 요청마다 인증 정보나 세션 토큰 등을 포함해야 함
  • 상태를 유지하려면 별도의 저장소(Redis, DB 등)에 위임 필요

Q. HTTP는 왜 Stateless라고 하나요?

HTTP는 각 요청을 독립적으로 처리하고, 서버가 클라이언트의 이전 상태를 기억하지 않기 때문에 Stateless라고 합니다. 그래서 클라이언트는 매 요청마다 인증 정보나 필요한 데이터를 함께 전달해야 합니다.

Q. REST 아키텍처 원칙에서 Stateless가 왜 중요한가요?

서버가 상태를 기억하지 않으면 어떤 서버가 요청을 받아도 같은 결과를 줄 수 있습니다. 그래서 서버 확장성과 로드 밸런싱에 유리하고, 장애 복구도 간단해집니다. 이게 REST의 핵심 원칙 중 하나입니다.

만약에 서버가 상태를 저장하면 같은 클라이언트 요청이 항상 같은 서버로 가야 해서 Sticky Session 문제가 생깁니다. 확장성이 떨어지고 장애 복구도 어려워집니다.

✅ Connectionless

• 클라이언트와 서버가 연결 상태를 유지하지 않는 특성
• 요청을 보낸 후 응답을 받으면 연결을 끊음
• 요청과 응답이 끝날 때마다 새로운 연결이 생성되고 종료됨
• 장점
  • 불필요한 연결 유지 비용 절감
  • 다수의 클라이언트를 동시에 처리하기 유리
• 단점
  • 연결 재사용 불가, 매번 핸드셰이크 비용 발생
  • 실시간 통신에는 비효율적
• 예시
  • UDP는 대표적인 Connectionless 프로토콜
  • TCP는 Connection-oriented라 대비됨
  • HTTP/1.0은 Connectionless 기반이었으나, HTTP/1.1부터는 Keep-Alive로 연결 유지 가능

Q. Connectionless인 HTTP/1.0이 왜 HTTP/1.1부터 Persistent Connection으로 바뀌었나요?

HTTP/1.0은 요청마다 TCP 연결을 새로 열고 닫아야 해서 오버헤드가 컸습니다. 그래서 HTTP/1.1부터는 Keep-Alive를 기본으로 해서 연결을 재사용하도록 바꿨고, 덕분에 성능이 크게 개선됐습니다.

• 장점
  • TCP Handshake 비용 감소
    • 매번 3-way handshake를 하지 않아도 되므로 지연 시간 줄어듦
  • 네트워크 자원 절약
    • 연결 생성/종료에 필요한 CPU, 메모리, 포트 소모 줄어듦
  • 성능 향상
    • 하나의 연결에서 여러 리소스(HTML, CSS, JS, 이미지 등)를 순차적으로 빠르게 가져올 수 있음
• 단점
  • 연결을 오래 유지하면 서버 리소스를 계속 점유 → 동시 접속자 많을 때 부하 가능
  • 유휴 연결을 끊지 않으면 리소스 낭비 → Keep-Alive: timeout=5, max=100 같은 식으로 제한 설정 가능

 

 

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!