Server Push and its benefit
Server Push는 client가 필요로 하는 data를 미리 전부 보내는 용도로 사용될 수 있는 HTTP/2 기능이다.
page-load time을 줄일 수 있고, redirect 시 추가 통신 없이 바로 해당 page를 load할 수 있는 instant redirect 등에 활용이 될 수 있다.
예를 들어 client가 server에 /document를 요청했다고 해보자. server push를 지원하지 않는 server에서 /document.html로의 redirect를 제공했다고 해보자. 그러면 client는 그것에 대한 요청을 할거고, 그러면 server이 관련 resource들을 제공할 것이다. 이 때 page를 구성하는 추가 자원들이 있을 수 있는데 (사진, css 등) 그것들을 또 client가 요청하고, server이 관련 resource를 또 제공할 것이다. 이처럼 반복적인 요청과 응답이 많이 발생하게 된다.
그런데 server push가 있는 경우 /document에 대한 요청을 했을 때 동시에 redirect, 그 page에서 필요로 하는 resource까지 한번에 보냄으로서 여러번의 request가 발생하는 것을 방지할 수 있다. 이것이 server push의 이점이다.
But there are some cost...
저런 기능이 protocol 상에 있는 것은 좋은데, 문제는 server이 무슨 기준으로 미리 보낼 resource를 정하냐에 대해 왈가왈부가 많았다.
Akamai라는 미국의 기업같은 경우 기계학습(Machine Learning)을 통해 미리 보낼 resource들을 정하도록 했었다. 또 javax.servlet을 위한, 미리 보낼 resource를 학습하는 오픈소스 코드도 존재하긴 했다.
하지만 유명한 웹 서버들은 위 문제 때문에 server push 기능 자체를 미구현했다. server push가 HTTP/2를 사용하는 server에서 꼭 구현해야하는 기능은 아니었기 때문이다.
실제로 크롬 사용자들이 server에 HTTP/2로 연결을 할 때 server push를 활용한 connection은 0.05% 밖에 안되었다고 한다. 그리고 결국 크로뮴 및 크롬에서 2022년에 이에 관한 지원을 완전히 끊어버렸다. HTTP/3에서 지원하는 기능임에도 불구하고 말이다.
Why is that a problem?
이 글을 읽는 분들은 server이 무슨 resource를 보낼지를 왜 고민하고 있는지 의문을 가질 수 있다. 그냥 연관된 resource들을 매번 전부 다 client에게 보내면 되지 않냐고 생각할 수 있다.
하지만 이게 사실 생각보다 진~짜 복잡한 technique이다. 고려해야 할 요소가 꽤 많고, 애초에 유명 브라우저들끼리도 (크롬, 사파리, 파이어폭스, 엣지) 이를 통일성있게 구현하질 못했다. 자세하게 알고 싶으면 이 링크 참고
가장 간단하게 생각할 수 있는 문제점은, client에서 본인이 계속 재사용할 목적으로 특정 resource들을 cache에 저장했을 수 있고, 무작정 위에 제시한것처럼 많은 resource들을 client에게 제공하면 client가 cache에서 자주 사용하던 resource들을 날려버릴 수도 있다. 이러면 본인이 push로 보내는 정보를 client가 자주 사용한다는, 아니 애초에 사용한다는 보장도 없으면서 자주 사용하는 정보에 대해 server에 다시 request를 보내는 불상사를 만들 수 있다. 이러면 client 입장에서는 server push로 인해 인터넷 속도가 더 많이 느려지는 것처럼 체감할 수 있다.
Suggested Solution : digest-based caching using cache digest
사실 방금 말한 cache 관련 문제점을 해결하기 위해 digest-base caching이라는 기술이 등장하긴 했다.
간단히 설명하자면 user이 특정 URL request를 어떤 cache server에 했을 때, 해당 server이 그 request에 해당하는 response 제공이 불가능한 경우 peering하는 다른 cache server의 'cache digest'를 모은다. 각 cache digest에는 그 cache server이 원하는 request에 대한 resource를 가지고 있는지에 대한 정보를 가지고 있다. resource를 가진 cache server을 발견하면, 가장 가까운 cache server에 해당 resource를 요청하면 된다.
이것이 앞에 말한 문제점을 어느정도 해결해주는 이유는 server push로 인해 자주 참조하던 resource가 날라가더라도 다른 cache server에 있으면 거기서 resource를 가져오면 되기 때문이다. 어느정도 penalty 완충을 하는 것이라고 볼 수 있고, 사실 server push를 안 쓴다 하더라도 꽤 좋아보이는 technology이지요.
But failed...
그러나 2016년에 등장했음에도 불구하고 아무 브라우저도 이를 사용하지 않는다.
첫번째 이유는 보안 문제. digest cache의 작동 방식 때문에 이 기술 자체가 super cookie로서 악용이 될 수 있기 때문이다.
일반적인 cookie는 web server에서 사용자의 허락을 받고 server이 사용자를 인지하는데 사용되는 수단이다. 그런데 super cookie의 경우 사용자 본인이 모르는 사이에 server이 사용자를 인지하는데 사용될 수 있는 것들을 말한다.
보통 cached된 data들이 supercookie에 많이 사용되는데, A라는 user이 X라는 data를 요청했다고 해보자. 이때 X가 cache에 저장될텐데, 그러면 malicious agent가 cached된 data에 identifier을 encode하고 tracking을 시작, 만약 cached된 X가 다른 사이트에서도 활용된 경우 tracker로 거기에 이용되는것을 파악해 user이 어떤 다양한 사이트들을 사용하는지를 추적하는게 가능해진다. 이는 광고에 악용이 될 수 있음.
사실 이걸 막기 위해 브라우저들은 각 website들에 대해 따로 cache를 만들어서 운용하고 있다. 예를들어 A가 X라는 data를 W1이라는 곳에서 load를 하면 W1에 대한 cache에다가 이를 저장한다. 이후 W2에서 같은 data를 요청할 경우 W1 cache측에 있는 X를 사용하지 않고, W2를 운용하는 server에서 X를 또 받아 W2에 대한 cache에 저장하는 것이다. 이러면 cached된 data에 tracking을 하더라도 다른 website를 어디를 사용하는지를 파악하는 것이 불가능하다.
digest-based caching이 supercookie로 악용이 될 수 있는 이유는 정확히는 cache server끼리 공유되는 cache digest가 악용될 위험이 있다.
user1이 W1에 X라는 data를 요청했고, 이게 cache에 저장되었다고 해보자. 자 이제 정보 유출에 매우 민감한 user2라는 사람이 W1에서 cookie도 사용하지 못하도록 막고 W1에 X라는 data를 요청했다고 해보자. 만약 user2 측의 cache가 user1의 cache를 peering하고 있다면 X라는 data가 user2의 cache에 전달되고 그걸 user2가 사용할 것이다. 이 때 user1에 cache되었던 data가 tracking되고 있을 경우 user2 몰래 user2가 W1에 방문했다는 것을 파악하는 것이 가능하다... 이게 문제점 1.
두번째 이유는 (FireFox같은 경우) 그냥 얻는 성능적 이득에 비해 구현이 너무 어려워서인 것으로 보인다.
Technology itself have quite a merit but...
일단 현재는 사용하지 않는 쪽으로 귀결되고 있는 분위기다.
참고자료
Chrome to remove HTTP/2 Push - Ctrl.blog
Browsers are rushing to stop shadowy supercookies that spy on your activity - FastCompany
