131–140 of 142 posts
Earlier quoted context omitted.
I just finished 3 weeks implementing server push for my web app which cuts typical load times in half :-(. I guess I'll have to go back to putting all the images base64 encoded into the html :-(
Depending on how big your pages are and how fast they are generated preload is probably a better alternative. Instead of pushing the images just set headers for the images above the fold: Link: ; rel=preload; as=image The browser will then request the images it doesn't have cached already. The advantage to this method is that the browser can look up the images in its cache first and avoid transferring unnecessary dat…
Earlier quoted context omitted.
> But I do not see support as optional. That's funny, given the HTTP/2 RFC does see the support as optional.
Damn james, killing me. Philosophically, I am highly opposed to the browser opting not do support this. Webdevs have been waiting for half a decade for some way to use PUSH in a reactive manner, as I linked further in this thread, And instead we get this absolute unit of a response. This is just absolutely hogwash james. I can not. Truly epic tragedy that they would do this to the web, to promising technology, after…
Five years ago, we built a company around HTTP/2 server push. Here is what we learned: - The interaction of HTTP/2 push with browser caches were left unspecified for the most part, and browsers implemented different ad-hoc policies. - Safari in particular was pretty bad. - Since HTTP/2 Push worked at a different layer than the rest of a web application, our offering centered around reverse-engineering traffic pattern…
This and so much this. I also worked with HTTP/2 (when it was still a SPDY draft) and came to the same conclusions: TCP peculiarities (most notably congestion control and its dynamic window scaling) mostly eradicate the benefits of HTTP/2. HTTP/1.1 was using 5-6 different TCP connections (which re-use OS level window scaling caches), while HTTP/2 you had to transfer all resources through a single TCP connection. Peop…
Earlier quoted context omitted.
This and so much this. I also worked with HTTP/2 (when it was still a SPDY draft) and came to the same conclusions: TCP peculiarities (most notably congestion control and its dynamic window scaling) mostly eradicate the benefits of HTTP/2. HTTP/1.1 was using 5-6 different TCP connections (which re-use OS level window scaling caches), while HTTP/2 you had to transfer all resources through a single TCP connection. Peop…
Would it be possible to use a patched TCP stack to start up quicker?
See, the problem is, if the initcwnd is set higher on OSes by default, you risk introducing more packet loss, and at the same time reducing everybodys network throughput - if you send more data than the network path to your destination can handle (i.e. full router buffers along the way, more data than client can receive etc.). TCPs congestion control is pretty smart about avoiding congestion or increasing load in already congested networks. So yes, you can set a higher initcwnd, but if everybody was about to increase it by a significant factor, chances are networks become slower for everyone, without anyone benefiting.
Long story short, the limitations of TCP for HTTP are known and the major motivation for QUIC (over UDP), that will allow Browser vendors (Google) and server operators (Google, but also other large players like Facebook etc.) to just "give a shit" about others and put as much pressure on the network as they want in order to bring latency down. Once Chrome rolls out with HTTP/3 support, Google couldn't care less what the linux kernel devs or IEEE network engineers have to say.
Earlier quoted context omitted.
Would it be possible to use a patched TCP stack to start up quicker?
sure, this is basically increasing the initcwnd (the initial number of TCP segments allowed to be sent out before you received an ACK from the other end). Linux supports this through the `ip` command (look for initcwnd). This, however, requires root rights and affects the whole network device. Google submitted a patch to the linux kernel that would have allowed tweaking the initcwn from userspace for individual conne…
(I get that mobile internet requires everyone to cooperate to avoid everyone stepping on each others' toes)
Earlier quoted context omitted.
sure, this is basically increasing the initcwnd (the initial number of TCP segments allowed to be sent out before you received an ACK from the other end). Linux supports this through the `ip` command (look for initcwnd). This, however, requires root rights and affects the whole network device. Google submitted a patch to the linux kernel that would have allowed tweaking the initcwn from userspace for individual conne…
If I use wired internet, shouldn't it be the ISP's responsibility to throttle / apply backpressure? Like if I'm paying for a certain speed why shouldn't I try my best to make use of it from the start? (I get that mobile internet requires everyone to cooperate to avoid everyone stepping on each others' toes)
If a big player like Google or Netflix would decide to, say, double or triple its initcwnd from one day to the other, the result would probably be more congestion (more overloaded nodes in the whole network), higher packet loss, increase of traffic at peering points and the overall throughput to their users would be less than before - at the same time putting more load on the network so that even users not using Netflix or Google would be affected and suffer from lower throughputs.
You can view the whole situation also under aspects of game theory: If in a movie theater at the end of the film everybody got up immediately and ran to the exit door at the same time, the effect would be a clogged door and people would get out of the theater at a slower rate than in the current situation, where people look at the congestion rate and say "naah to many people at the exit, i sit for a while longer". TCP has built-in backoff and there is a wide range of different algorithms that solve this "try to get to the point so I can send as much as possible as quickly as possible, but if packet loss occurs go slower in order not to put even more pressure on the network". Search for TCP Reno, Tahoe, Vegas, Cubic, BIC etc. or look at the Wikipedia page of what is available: https://en.wikipedia.org/wiki/TCP_congestion_control
EDIT: regarding ISP applying backpressure: They do, in fact every router (even the ones in your home) does this automatically: You have a buffer you put packets in scheduled for delivery. If the buffer-file rate exceeds the buffer drain rate (=input data rate is higher than outgoing) the buffer runs full and packets get dropped. But this is not mitigating the problem: Every dropped packet gets retransmitted and will come again a few ms later. So if the sending side wouldn't back off (=throttle down transmission rate) and just retransmit at the same rate as before, the buffer would permanently run full, packet drops would occur again, and your connection will basically fail.
Earlier quoted context omitted.
Damn james, killing me. Philosophically, I am highly opposed to the browser opting not do support this. Webdevs have been waiting for half a decade for some way to use PUSH in a reactive manner, as I linked further in this thread, And instead we get this absolute unit of a response. This is just absolutely hogwash james. I can not. Truly epic tragedy that they would do this to the web, to promising technology, after…
I think you're mistaking that person for someone else
Earlier quoted context omitted.
If I use wired internet, shouldn't it be the ISP's responsibility to throttle / apply backpressure? Like if I'm paying for a certain speed why shouldn't I try my best to make use of it from the start? (I get that mobile internet requires everyone to cooperate to avoid everyone stepping on each others' toes)
Well if a server sends more data to a requesting client that the path to that client can handle (considering current state of congestion along that path) the result is packet loss. That is, data that got send is lost, and the packets need to be re-transmitted. So if in that situation you set your initcwnd too high in an effort to improve speed, you would actually achieve the opposite effect: The data that you send ge…
Earlier quoted context omitted.
I'm going to assume many HTTP libraries and ad-hoc implementations expect one HTTP response for one HTTP request (but still support pipelining) and will break if this underlying assumption changes. In fact, this may even be ratified in the interfaces they provide: think synchronous "give contents of this URL" functions.
That's the most significant criticism of RFC 8297 (the 103 Early Hints response) from my cursory reading of the RFC. It should only be allowed when the client indicates that it can process 1xx responses. All other 1xx responses are like that AFAIK, e.g. 100 Continue is only sent when the client sets the "Expect: 100-continue" header. So a client that doesn't do that doesn't need to care about 100 Continue responses.