Theory
네트워크
Stateless & Connectionless

Stateless와 Connectionless


무상태(Stateless)와 비연결성(Connectionless)은 HTTP의 특징 중 하나이다.


Stateless


* stateful : 서버가 클라이언트의 이전 상태를 보존 (상태유지)             
* stateless : 서버가 클라이언트의 이전 상태를 보존하지 않음 (무상태)
    * stateless의 예시 : HTTP
    * stateful의 예시 : TCP

Stateful의 문제점

  • 해당 서버가 멈추거나 사용이 불가시, 다른 서버 사용이 어려움
    • 새로운 서버에는 이전 서버의 데이터가 존재하지 않음
  • 한 서버가 처리할 수 있는 능력보다 많은 요청 발생 시 처리 한계
  • Scale-in을 하는 경우 하나의 서버에 트래픽이 몰리거나 기존의 트래픽의 데이터가 유실 될 수 있다.

개념

  • 클라이언트 서버 사이에 상태를 유지하지 않음
  • 서버는 단순히 요청에 대한 응답을 보내며, 상태 관리는 클라이언트에게 책임
  • 통신에 필요한 모든 상태 정보들은 클라이언트에서 가지고 있다가 서버와 통신할때 데이터를 실어 보냄

특징

  • 동일한 요청이라도 매번 각 요청은 독립적
    • HTTP에서 stateless하다는 건 서버입장에서 클라이언트의 상태가 없다는 의미
  • 요청에 대한 응답을 처리하게 되면 연결이 끊어져(Connectionless) 이전 정보나 현재 통신 상태가 남아있지 않음(Stateless)
  • 서버는 단순히 응답만 진행하므로 상태 유지에 대한 부하가 줄어듦

장점

  • 높은 서버 확장성(Scale Out)
    • 어떤 서버가 클라이언트 요청에 응답해도 상관 없음
    • 서버 증설하여 문제가 생길 경우 다른 서버로 확장 가능
    • 대용량 트래픽 발생 시 서버 확장을 통한 대처 수월함

단점

  • 클라이언트가 추가 데이터를 매번 전송해야함
    • ex) 로그인 상태를 유지해야하는 서비스의 경우 Token을 항상 Header에 유지해줘야 함.
  • 빈번한 커넥션으로 인한 리소스 비용 발생

토큰

  • 수행 내용

    1. 클라이언트가 서버 접속 시 서버에서 해당 클라이언트에게 인증의 의미로 토큰 부여
    2. 토큰을 발급받은 클라이언트는 또 다시 서버에 요청을 보낼 때 요청 헤더에 토큰을 심어 보냄
    3. 서버는 받은 토큰을 제공한 토큰과 일치여부를 체크하여 인증 과정 처리

  • 특징

    • 토큰은 세션과 달리 서버가 아닌 클라이언트에 저장
      • 세션을 관리하던 서버의 부담을 덜 수 있음
    • 상태를 유지하지 않으므로 Stateless 함

  • 단점

    • 쿠키 세션과 달리 토큰 자체의 데이터 길이가 길어, 인증 요청이 많아질수록 네트워크 부하 심해질 수 있음
    • payload자체는 암호화되지 않기에 중요한 정보는 담을 수 없음
    • 토큰 탈취 시 대처 어려움
      • 사용 기간 제한을 설정하여 극복


Connectionless

배경

  • TCP/IP의 경우 기본적으로 연결을 종료하지 않으면 연결 유지
  • 사용하지 않는 연결들은 서버의 자원낭비로 이어짐
  • 이때문에 HTTP의 초기모델은 각 클라이언트가 서버에 요청을 하고 응답을 받으면 바로 TCP/IP 연결을 끊음 (Connectionless)

개념

  • TCP/IP 커넥션 연결을 지속하지 않는다

장점

  • 서버 자원의 효율적 사용
    • 연결을 유지할 경우, 서버는 요청•응답이 끝난 관계여도 서버 자원 지속적 소모
    • 같은 시간 대용량 트래픽 발생하는 일이 흔하지 않음
      • 실제로 수천명이 하나의 서비스를 사용하더라도 동시 처리 요청은 수십개 이하로 매우작음
      • 초단위의 빠른 속도로 요청•응답이 이루어짐

같은 시간 대용량 트래픽 발생 시, 대기열 서버 등을 이용


한계

  • TCP/IP 연결을 새로 맺어야함
  • 웹 브라우저로 사이트 요청 시, 수많은 자원 함께 다운로드

두 경우 모두 3way-handshake 시간이 걸림


한계 극복


Persistent Connections (HTTP 지속 연결)

  • 등장배경

    • Connectionless는 불필요하게 많은 3way-handshake의 횟수를 줄이기 위해 등장

  • 개념

    • 서버와 클라이언트 중 하나가 명시적으로 connection을 close하거나 정책적으로 close 될 때까지 계속 connection을 유지하는 경우
    • 요청•응답과정이 HTML 한페이지를 다 받을때 까지 지속된 이후 종료

  • 장점

    • 네트워크 혼잡 감소
      • TCP connection request 수가 줄어듦
    • 네트워크 비용 감소
      • 한 개의 connection으로 클라이언트 요청을 serving
    • 지연시간 감소
      • 3wy-handshake를 맺으며 필요한 round-trip이 줄어듦

  • 특징

    • 기본적으로 웹 서버에서 Persistent Connections 적용해줌
    • 연결 지속시간은 서버쪽에서 설정 가능 (요즘은 따로 설정해줄 필요X)
    • 기본적으로 비연결성이지만, 성능 최적화를 위해 약간의 연결을 유지하는(연결성) 특성을 가짐

keep alive

개념

  • HTTP와 TCP에서 Persistent Connections을 유지하기 위해 제공되는 옵션
  • 클라이언트의 요청 처리 후 연결을 바로 끊지 않고 일정 시간 대기하는 시간
  • 하나의 연결을 여러번 재사용하여 응답과 요청 수행 가능

HTTP keep-alive 옵션

  • 사용
    • HTTP/1.0+
      • HTTP/1.0+ 부터 keep alive 옵션 추가
      • HTTP 요청 헤더에 Connection: keep-alive 포함
    • HTTP/1.1
      • 기본적으로 모든 connection이 keep-alive 상태로, 하나의 TCP연결 위에서 이뤄짐
      • HTTP/1.0과의 호환성을 위해 Connection: keep-alive request를 받으면 keep-alive를 사용해 response 보냄

TCP keep alive

  • 사용이유
    • 유령세션 구분
      • 유령세션: 연결된 두 호스트 중 한쪽 호스트 연결이 끊어져있는데도 연결이 된 줄 알고 계속 살아있는 세션
    • 네트워크 비활성화로 인한 연결 해제 방지
  • 사용
    • TCP연결 종료 시 4way-handshake로 종료되는 것은 이상적인 상황
    • keep-alive는 일정시간 간격으로 payload가 없는 데이터를 전송해 커넥션 생존유무 확인
      • 살아있을 경우(ack 수신) 설정된 시간만큼 TCP세션 연장
      • 죽어있을 경우(ack 수신X) TCP세션 종료
    • setsockopt() 를 통해 소켓에 keep-alive 옵션 지정

Multiplexing & Demultiplexing