... so here is my report addition from the train, after having had to leave a
little early.
Most of the general reporting work has already been done by the workshop's
inofficial correspondent Daniel Stenberg, so I will link to his blog and just
add some comments from my personal notes. I will mostly only comment where I
believe to have anything to add, so not all the points are reflected. Read
Daniel's blog and the slides...
DAY1
----
https://daniel.haxx.se/blog/2024/11/13/the-2024-http-workshop/
Make Cleartext HTTP harder
https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/1.%20Security/cleartext.pdf
I was probably one of those "bringing back the discussion" which Daniel thought
had been left behind, but I find the idea of a "central url registry" simply
evil and with the increasing lock-in of user-agents, this topic felt to me like
dialing up the frog-boiler's temperature another tick.
The valid argument behind the discussion is the need to solve the tls downgrade
issue. HSTS only works after having visited a site at least once, so there is
the "preload list" and sure enough, that doesn't scale. I do not have a solution
to the problem either, but killing clear text http deployments does really not
seem like the right choice to me - even if they are already made less and less
attractive because of reduced support for newer browser features.
HTTP 2/3 abuses
https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/1.%20Security/glitches.pdf
Read the slides! We as Varnish-Cache should really consider Willy's explicit and
implicit advise from his experience and I expect to personally get back to this
relatively soon, because I am getting closer to the H2 re-implementation which I
have on my list for next year...
QUIC pacing
https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/2.%20Performance/quic%20pacing.pdf
Maybe not for our immediate attention, but the insights seem very valuable. In
particular the "send acks in intervals of rtt" advice, and I learned an
interesting detail from side discussions: At least two people from different
teams said that they found SO_TXTIME to be broken on Linux.
Priorities
https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/2.%20Performance/HTTP%20prioritization.pdf
One interesting idea from the discussion: implement one priority as a cache
pre-warm "fetch, but don't send at all". If the client then decides it actually
wants the object, it updates the priority...
DSR
https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/2.%20Performance/QUIC%20cache%20DSR.pdf
Discussing the topic after the workshop, I learned about one use case which was
absolutely not clear to me: At scale, the traffic patterns can be such that it
does not pay off to copy longtail objects to another "neighbor" cache in the
same cluster. So yes, DSR seems to make sense. Though the particular design
presented looked to me like there really should be an easier way...
DAY2
----
https://daniel.haxx.se/blog/2024/11/13/the-2024-workshop-day-two/
CAPSULE
This made me realize again really _how_ many not even particularly new things
there are where we as Varnish-Cache have nothing to offer...
Reverse HTTP
https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/3.%20Semantics/reverse%20HTTP.pdf
This sounds interesting from our perspective, I think. Others already have
non-standardized solutions and workarounds, but the use case really seems
compelling: Instead of connecting to backends, have backends connect to us. An
interesting question is how to signal the need for more capacity, for which the
answer probably is a streams usage in h2/3, but I am not sure if an easy
solution exists for h1.
MoQ
https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/4.%20Evolution/MoQ.pdf
My engineer mind got hooked, even though this topic probably has close to zero
relevance for what I am doing at the moment. Overall impression: The MoQ folks
could probably benefit from learning about some common caching topics...
Multiplexing in the year 2024
https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/4.%20Evolution/multiplexing.pdf
A smart choice of title to maybe not trigger some defensive reflexes, but it was
really about H3 over QUIC-ish over TLS over TCP. I can see how that could be
useful besides maybe reducing the maintenance burden: For clients on
udp-unfriendly networks and for traffic in environments with excellent,
predictable network infrastructure, where all the quic (re)prioritization tricks
are not relevant.
DAY3
----
https://daniel.haxx.se/blog/2024/11/14/workshop-season-six-episode-three/
Do you speak http
https://github.com/HTTPWorkshop/workshop2024/blob/main/talks/5.%20Testing/testing.pdf
Vtest had multiple appearances here and I pushed my neglected vtest-related
tasks further up my list of bad consciousness.
I had to leave during the following break to not risk to miss the one eurostar
train I really had to take to make it home in time for a birthday...
Nils
--
Nils Goroll (he/him)
** * * UPLEX - Nils Goroll Systemoptimierung
Scheffelstraße 32
22301 Hamburg
tel +49 40 28805731
mob +49 170 2723133
fax +49 40 42949753
xmpp://[email protected]/
http://uplex.de/
_______________________________________________
varnish-dev mailing list
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
