0. 하지만 역부족...
이로써 HTTP 통신이 많이 발전했다 싶었지만, 아직 해결하지 못한 문제가 있었다.
그것은 바로,
서버는 왜 요청이 없으면 응답을 못해?
였다.
AJAX가 HTML의 문제를 해결해주긴 했지만 어디까지나 일부 랜더링 문제이고, 결국 HTTP 자체를 벗어날 순 없었다.
다시말해 "양방향 통신이 불가능"했다.
그래서 급한 불을 끄기 위해, 3가지 편법으로 어떻게든 "양방향 같은 통신"을 구현해냈다.
1. 폴링(Polling)
아주 무식한(?) 방법이다.
클라이언트가 원하는 요청이 아니어도, 일정 주기마다 지속적으로 요청을 보낸다.
그러면 서버는 응답을 보낼 것이고, 이것은 마치 "요청이 없는데도 응답을 보낸 것처럼" 보일 것이다.
2. 롱 폴링(Long Polling)
폴링 방식은 무조건 요청을 보내기 때문에, 트래픽이 심하게 과부화 걸린다.
따라서 좀 더 효율적인 텀(term)을 두고 폴링을 수행할 필요가 있었는데, 그것이 바로 롱 폴링이다.
이 방식은 클라이언트가 요청을 하면, 서버는 연결을 유지하고 있다가 이벤트가 발생할 때 응답을 돌려주는 방식이다.
폴링에 비해 효율적이긴 하지만, 이벤트가 한번 일어나면 트래픽이 치솟는다는 것이 단점.
3. 스트리밍(Streaming)
롱 폴링에서 한발 더 나아간 방법이다.
롱 폴링도 이벤트가 일어나는 족족 요청을 보내므로 폴링과 다를 것이 없다.
따라서 스트리밍은 이벤트를 받고서 응답을 하지만, 연결을 완료하고 끝맺지는 않는다. 즉, 연결을 계속 물고 있는 것이다.
클라이언트는 응답받기 위해 일일히 요청할 필요는 없지만,
연결을 계속 유지시킨다는 건 보안적으로나 효율성으로나 좋지 않다는게 단점.
연결은 필요없을 땐 끊어지는 게 맞기 때문이다.
4. 결론
이렇게 어떻게 해봐도 효율성이 나쁜 것이 사실이다.
그래서 이런 방법을 딛고 나타난 것이 바로 WebSocket!
다음 편에서는 WebSocket에 대해 알아보도록 하겠다.
