터미널에서 키를 누르면 → 서버가 그 명령을 전달하고 → iPhone / iPad의 웹앱이 그 키를 받아 실제 동작하는 구조를 구현했는데
결과적으로는 Polling방식으로 구현을 했고
문득
WebSocket 방식으로 했으면 어떨까? 생각이 들더군요
이런 방식 구현할때 어떤게 좋을지
선배님들 생각은 어떠시나요?!
터미널에서 키를 누르면 → 서버가 그 명령을 전달하고 → iPhone / iPad의 웹앱이 그 키를 받아 실제 동작하는 구조를 구현했는데
결과적으로는 Polling방식으로 구현을 했고
문득
WebSocket 방식으로 했으면 어떨까? 생각이 들더군요
이런 방식 구현할때 어떤게 좋을지
선배님들 생각은 어떠시나요?!
하지만, 앱의 시작부터 끝까지 Polling한다면, 배터리와 쓸데없는 네트워크 비용이 발생하니 WebSocket이 낫겠죠.
단방향이면 저도 SSE 추천합니다.
폴링은 이 부분이 다음 요청에 그냥 딸려와서 공짜로 풀리는 면이 있더군요. 키 입력이 딱 한 번만 실행돼야 하는 성격이라면 그 기준으로 골라도 될 것 같습니다.
WebSocket은 RFC 6455에 그런 게 없습니다. 닫히면 닫힌 걸로 끝이고, 밀린 걸 어디서부터 다시 줄지는 애플리케이션이 직접 얹어야 합니다. 순번을 한쪽이 들고 있어야 하는 부담은 WebSocket 쪽이 더 큽니다.
고르실 때 기준이 하나 있는데, 그 키 명령이 두 번 실행돼도 괜찮은 종류인가요, 아니면 정확히 한 번이어야 하나요? 두 번 와도 되면 재연결 후 그냥 다시 밀어도 되고, 한 번이어야 하면 순번이 필수가 됩니다.
200ms 로 도는 GET 이라 하나 걸리는 건 캐시입니다. RFC 9111 은 명시적인 만료 헤더가 없어도 캐시가 휴리스틱으로 신선도를 매길 수 있게 두고 있고, 4.2.2 에서 쿼리 문자열이 붙은 URI 는 휴리스틱 대상에서 빼라던 옛 규정을 걷어내면서 막고 싶으면 서버가 직접 no-cache 를 보내라고 적어놨습니다. 중간에 프록시나 CDN 이 끼면 지난 응답이 그대로 돌아올 수 있습니다.
그리고 정확히 한 번이어야 한다면 자리가 하나 더 남습니다. 그 마지막 ID 를 언제 올리시나요? 키를 실행한 다음에 올리면 그 사이에 탭이 죽었을 때 다시 받아 또 실행하고, 먼저 올리면 실행 전에 죽었을 때 그 키가 통째로 사라집니다.