Stateless vs Stateful

	Stateless	Stateful
state?	상태; 과거의 동작(데이터 송수신 및 처리) 결과로, 서버의 현재 상태에 따라 클라로부터의 요구(request)마다 취하는 응답(response)이 달라질 수 있음 연결 지속성이 가장 큰 이슈 (+) 상태 정보를 사용하면 현재의 상태에 따라 약속된 명령에 대해 신속히 응답할 수 있으며, 클라와 주고받을 메세지의 크기도 줄일 수 있음 (+) 상태 정보는 과거의 정보이므로 클라가 이전에 보낸 메세지에서 오류가 발생했다면, 틀린 상태로 가 있을 수 있음
정의	- 단방향 통신 - 통신의 동작 상태를 정의하지 않고 항상 클라로부터의 독립적인 request에 의해 서비스를 제공하는 서버	- 양방향 통신 - 서버가 클라와의 통신 상태(state)를 계속 추적하며 상태 정보를 서비스 제공에 이용하는 서버
Protocol
차이점	- 클라로부터 새로 도착한 명령문(request)에만 의존하여 서비스 제공 - 틀린 상태 정보를 사용할 가능성을 없앰으로써 서버가 안정적으로 동작한다는 장점 - 클라가 서버로 보내는 request는 서버가  동작하기에 필요한 모든 정보를 가지고 있어야 하므로 메세지의 길이가 stateful 서버보다 길어질 수 있음(요청 헤더가 큼 > DB관련 오버헤드로 느림) - 서버의 현재 상태에 따라 요청에 대한 응답이 달라질 수 있음 - 연속된 상태정보를 저장하지 않기 때문에 application 구현 상에서 상태정보를 저장해야함 - 서버의 수평확장과 로드밸런싱이 용이 - 상대적으로 적은 메모리를 사용함	- 현재의 상태 정보가 잘못되어 있거나 request에서 비트 오류가 발생하는 경우, 오동작을 할 가능성이 높다는 단점(오동작을 최소화하는 범위에서 상태 정보를 적절히 이용하는 프밍 기술이 필요) - 네트웍 또는 서버가 reset되었을 때 모든 상태 정보도 reset되어야 하고 모든 동작이 reset된다는 단점 - 요청 헤더가 작고 메모리에 데이터로 대부분 처리가 가능해 빠름 - 서버의 수평 확장과 로드밸런싱이 어려움 - 상대적으로 많은 메모리를 사용함 - 재접속에 대한 오버헤드가 큼
언제 사용?	- 인터넷 환경은 패킷의 복사, 분실, 오류, 지연, 순서 바뀜 등이 발생할 가능성이 크므로 안정적이지 않음 ∴stateless 사용이 유리 - 모바일 게임에서는 연결을 유지하는게 어렵기 때문에 stateless 많이 사용	- 네트웍이 안정적인 (즉, 오류 및 순서 바뀜이 적은) 경우 유리함 - 전통적으로 게임 서버는 stateful로 구현되긴 함
참고	http://cafe.daum.net/_c21_/bbs_search_read?grpid=SD4r&fldid=jTs&datanum=10