✅ 클라이언트 서버 구조

  • Request - Response 구조
  • 클라이언트는 서버에 요청을 보내고, 응답을 대기

  • 서버가 요청에 대한 결과를 만들어서 응답

    • 각각 역할을 나뉘었다는 것이 포인트
    • 클라이언트는 UI/UX에 집중하고, 서버는 비즈니스 로직이나, 데이터만 관리
    • 이렇게 독립적으로 분리하면 각각 고도화 진행 가능
    • 또한 문제가 발생하면 각각 독립적으로 처리만 하면 됨

✅ 무상태 프로토콜 = Stateless

  1. 서버가 클라이언트의 상태를 보존 X

    • 상태 유지(stateful)
    • ex) 중간에 다른 점원이 바뀌면 안됨(만약에 바뀌면 상태 정보를 다른 점원에게 미리 알려줘야 함)
    • 상태 유지 X(무상태)
    • ex) 점원이 바뀌어도 정확하게 결과를 얻을 수 있음, 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입 가능, 응답 서버를 쉽게 바뀔 수 있음(무한 서버 증설 가능)
    • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있음
    • 응답 서버를 쉽게 바뀔 수 있음(무한한 서버 증설 가능)
    • 장점: 서버 확장성 높음
    • 단점: 클라이언트가 추가 데이터 전송

Stateless 실무의 한계

  • 모든 것을 무상태로 설계할 수 있는 경우도 있고, 없는 경우도 있음
  • 무상태: ex) 로그인이 필요 없는 단순한 서비스 소개 화면

  • 상태 유지: ex) 로그인

    • 로그인한 사용자의 경우, 로그인 했다는 상태를 서버에 유지
    • 일반적으로 브라우저 쿠키와 서버 세션 등을 이용해서 상태 유지
    • 상태 유지는 최소한만 사용

✅ 비 연결성(connectionless)

특징

  • HTTP는 기본이 연결을 유지 않는 모델
  • 일반적으로 초 단위의 이하의 빠른 속도로 응답
  • 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음 ex) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지 않음
  • 서버 자원을 매우 효율적으로 사용할 수 있음

한계와 극복

  • TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
  • 웹 브라우저로 사이트를 요청하면 HTML 뿐만아니라 JS, CSS 추가 이미지 등 수많은 자원이 함께 다운로드
  • 지금은 HTTP 지속 연결로 문제 해결
  • HTTP/2, HTTP/3에서 더 많은 최적화 ex) UDP

Stateless를 기억하자(서버 개발자들이 어려워하는 업무)

  • 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽 ex) 선착순 이벤트, 명절 KTX 예약, 학과 수업등록