Stateless와 Connectionless

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

Stateless

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

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 지속 연결) 이용

• HTTP/2, HTTP/3에서 더욱 최적화

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 옵션 지정