진행 순서
- 클라이언트) 요청
- dispatcher-servlet) 요청 받음
- dispatcher-servlet) Handler Mapping을 함 URL 매핑 정보를 바탕으로 어떤 Controller가 이 요청을 처리할지 찾음
해당 컨트롤러의 클래스를 찾아함
Component Scan과 같은 방법을 사용하여 bin으로 등록된 Controller를 찾음
- dispatcher-servlet) 해당 Controller의 실행을 담당할 Handler Adapter를 선택
선택된 컨트롤러의 빈 객체가 IoC 컨테이너에서 관리
어댑터 인터페이스를 통해 어댑터 패턴을 적용하여 Controller의 구현 방식에 상관없이 요청 위임 가능
- Handler Adapter) Controller의 method 호출 method의 파라미터에는 요청 정보가 주입되어 사용 가능
Controller의 method) 비즈니스 로직을 수행하고 모델(Model)과 뷰(View)를 반환
- Handler Adapter) View Resolver를 호출 View Resolver) 뷰의 이름을 실제 뷰 객체로 변환 View Resolver) 뷰의 이름을 기반으로 실제 사용될 뷰 객체를 찾아줌 View Rendering) 실제 뷰 객체에게 모델 데이터를 전달하고, 뷰는 이 데이터를 사용하여 최종적인 응답 내용을 생성 View Rendering) 응답을 dispatcher-servlet에게 반환
- dispatcher-servlet) 클라이언트(브라우저)에게 전송
- dispatcher-servlet은 Tomcat이 new해서 메모리에 띄워줌
스프링에서 dispatcher 클래스를 구현해놨음
- 특정 URL 요청 → 무조건 dispatcher-servlet
→ 받은 URL을 파싱 → 어떤 컨트롤러로 보낼지 결정 : IF가 아닌 reflection으로 작동함
- 푸쉬 서버
클라이언트가 요청하지 않아도 응답 받음
- 폴링(Polling)
: 클라이언트가 주기적으로 서버에게 데이터를 요청하는 방식
단점) 과부화
시간 측정도 어려움/반응이 달라지니까
.png?table=block&id=449ba54a-94ed-4f0b-970d-8d59899aa7f7&cache=v2)
.png?table=block&id=bd3dcb31-7b2f-4145-affb-93a7612be05e&cache=v2)
내부적으로 F5를 계속 요청
단점) 과부화
시간 측정도 어려움/반응이 달라지니까
반응이 늦어도 되는 것도 있음
ex) 아이유 사진 → 이소룡 사진으로 변경되는 단순한거면 100초에 한번 해도 나쁘지 않음
웹을 키고 가만히 있는데 변경이 일어남 : 크게 문제 없으면 괜찮음
실시간으로 해야되는 민감한 것들은 초를 줄여야함→폴링을 못씀
다시 전이중으로 바꿔야 함
단점) 웹 서버가 감당을 못함/폴링보다 부화가 더 큼
조금 부화를 줄일 수 있는 방식이 있음
- 서버 샌드 이벤트 : SSE(서버-센트 이벤트, Server-Sent Events)
리쿼스트 선을 끈고 리스판스 선만 유지시킴
정보가 바뀌면 BW로 쓰는것
클라이언트가 브라우저를 종료해야 선이 다 끈김
리쿼스트를 새로 요청하면 유지하던 리스판스 선이 끈기고 새로 만들어짐
.png?table=block&id=29cd9211-148c-4116-a469-a2ae1a5ef3f9&cache=v2)
- WebFlux : 끝이 있는 스트림
한번에 못주고 여러번에 걸쳐서 받아서 선이 끈김
ex) 차트를 요청했는데 차트가 계속 변동이 되니까 계속 받는 선만 유지되고 있음
.png?table=block&id=a4917dc4-d85e-47f5-80e8-7ba5fdc23e57&cache=v2)
.png?table=block&id=2aec91f6-82cd-49f1-a947-134c166b47b9&cache=v2)
Share article
