• [목차]

[Answer]

Stateless 무상태성

• stateless란?

  • 서버가 클라이언트를 식별할 수 없음.
  • 서버가 클라이언트의 상태, 주고받은 통신 기록을 기억하지 않음.

  ex) stateless로 인해 서버가 사용자의 state를 까먹는 예시

  1. 쇼핑몰에 접속
  2. 로그인
  3. 상품 클릭 -> 상세화면으로 이동
  4. 로그인
  5. 주문
  6. 로그인
  7. ....

• 대응방법 상태를 기억하기 위해 쿠키, 세션을 사용할 수 있다.

  • 쿠키 클라이언트의 브라우져 단에 데이터(쿠키)를 저장. 클라이언트는 매 통신마다 HTTP 헤더에 cookie를 실어보냄으로써 서버에 자신임을 알림 ⇒ 쿠키는 브라우져단에 저장되기 때문에 보안 별로임
  • 세션 쿠키와 달리 서버 단에 데이터(세션)를 저장 ⇒ 세션도 중간에 탈취 당할 수 있어 보안 별로임 ⇒ 서버에서 세션 데이터를 저장하므로, 서버 자원이 부담됨
  • 토큰 기반 JWT, OAuth 보호할 데이터를 토큰으로 치환하여 원본 데이터 대신 토큰을 사용하는 기술. ⇒ 토큰은 탈취 당하더라도 원본 데이터에 대한 내용을 알 수 없으므로 보안 좋음

Connectionless 비연결성

• Connectoinless란?

  • 클라이언트와 서버가 req-res 한 번 주고받으면 TCP 연결을 끊음
  • 동일한 사용자와 통신을 하더라도 매번 TCP 연결 (3way handshake - 4way handshake) 과정을 거치는 것임
  • 서버는 여러 클라이언트와 통신하고 있음~!

  

• 장점

  • 왜 연결을 매번 끊을까?? → 서버는 다수의 클라이언트와 통신해야 하기 때문에, 여러 연결을 계속 유지하려면 서버의 리소스가 너무 많이 소모됨! 따라서 그냥 연결 끊어버리고 연결유지를 위한 리소스를 줄이는 대신 더 많은 클라이언트와 연결하려고 비연결성 채택!

• 단점

  • 매번 TCP 연결 (3way handshake - 4way handshake) 과정을 거쳐야 하므로 서버의 자원이 많이 소모된다.

• 대응방법 TCP연결을 오래 유지하기 위해 keep alive, pipelining를 이용할 수 있다. 단, 이러한 방법 역시 연결 유지를 위한 자원을 소모하기 때문에 성능향상이 미미하고, 프록시버그가 발생할 가능성이 있어서 최고의 방법은 아님! 그냥 그떄그때 서비스와 트래픽 상황에 따라 적절히 연결 지속방법을 정하는 것이 좋음

1. keep alive 지속연결 TCP 연결을 매 req-res마다 끊지 않고, 서버와 클라이언트 간에 일정 시간 동안 패킷 교환이 없을 때 비로소 연결을 끊기를 시도

1. pipelining : req에 대한 res가 오지 않았어도 새로운 req를 보낼 수 있는 방법