6. Reactor - part 1

[gaepury]

Backpressure in WebFlux

Backpressure mechanism in Spring Web-Flux

https://stackoverflow.com/questions/52244808/backpressure-mechanism-in-spring-web-flux

• 네트워크단에서는 backpressure가 의도처럼 정상적으로 되지 않는다.

Spring WebFlux Flux behavior with non streaming application/json

https://stackoverflow.com/questions/54680001/spring-webflux-flux-behavior-with-non-streaming-application-json

Differences between gRPC and RSocket

https://medium.com/netifi/differences-between-grpc-and-rsocket-e736c954e60

• gRPC is at OSI layer 7 — an RPC layer built on top of HTTP/2. RSocket is an OSI layer 5/6 that models Reactive Streams semantics over a network.

[gaepury]

HTTP2 도메인 샤딩

https://wonism.github.io/domain-sharding/ 도메인 샤딩은 정적파일(이미지, CSS, JS 등)의 로딩 속도를 개선하는 방법으로, 여러개의 서브도메인을 생성하여 정적파일을 병렬로 가져온다.

도메인 샤딩의 등장 배경은 HTTP/1.x에서 도메인 당 동시 요청 갯수의 제한때문이다. (대부분의 모던 브라우저는 6~8개, IE 하위 버전은 2개까지 동시 요청을 할 수 있다.(하단의 표 참고) 이러한 제한은 웹서버에 과부하가 걸리지 않도록 IETF(Internet Engineering Task Force)에 의해 HTTP/1.1 사양으로 정의되었다.)

동시 요청을 함으로써 웹 페이지 로딩 속도가 무조건 빨라질 것 같지만 그렇지 않다. 각 하위 도메인에 DNS 조회를 함으로써 꽤 많은 시간과 CPU, 전력을 소모하기 때문이다.(“김기정, 이성원. 웹 성능을 향상시키기 위한 DNS Resolution 감소 방안에 대한 연구”에 따르면, 3G환경에서는 평균 361ms, 4G환경에서는 평균 176ms의 왕복 지연시간이 발생한다고 한다.) 따라서, 도메인 샤딩은 동시 요청에 대한 완벽한 솔루션이라고 볼 수 없다.(도메인 샤딩 대신 HTTP/2로 전환하는 것이 좋다. HTTP/2 설정 방법은 링크를 참고한다.)

추가로, 많은 모바일 브라우저가 HTTP 파이프라이닝을 구현하고 있다. 따라서, 도메인 샤딩은 더 이상 동시 요청에 대한 좋은 솔루션이 아니다.