101–110 of 164 posts
TL;DR: TCP and DNS, which is what you would expect. If you want light-speed internet, send UDP packets with a laser.
Earlier quoted context omitted.
> which you should for many reasons but chiefly performance and security. Why would you use nginx for security? I see over 100 CVEs for nginx. This isn't exactly unexpected. Nginx is an incredibly complicated piece of software written for performance in C. That's basically the trifecta of security badness. If you want security, why not use a (possibly slower) simpler product written in a safer language?
Ah, the old concept of binary security - either you want it or not. It doesn't work like that, security is one need to be balanced against others. Also, lots of CVEs indicate only one thing: that lots of people are checking it.
Doesn't it also mean they're finding lots of problems with it?
If the 3x slowdown from the infrastructure were eliminated, each round-trip-time being 3x faster would affect all the protocols above, and we could immediately cut the latency inflation from ~37x to around 10x, without any protocol modifications. The page this article is published on makes 87 separate network requests to 19 different domains. Even with a great deal of the content cached, it takes 7 seconds to reload…
As much as ads are annoying, this has nothing to do with the article. One man's bloat is another man's content. No need for this nag to be top comment on HN for an article about why data isn't moving at the speed of light.
Their page has a high number of requests primarily because they do not bundle their javascript, CSS, or icons.
I see 95 requests that I see without adblocking, and about 20 of those requests are javascript coming out of their own WordPress instance. They're using 2 different full icon libraries and adding at least 5 more icons not contained in either.
Since the OP compared Internet latencies to the speed of light in glass...look up 802.1CM/IEEE1904.3 or "CPRI over Ethernet"/"Radio over Ethernet"! Those describe techniques for conveying LTE baseband signals (digital I/Q-samples) over Ethernet -- so the radios can live far away from the equipment that speaks the physical / MAC / radio-resource-control layers of LTE. There are strict latency/jitter requirements invol…
If you are interested in bufferbloat and TCP, Google's BBR is a really interesting attempt at solving part of the problem. See http://queue.acm.org/detail.cfm?id=3022184 BBR is a sender-only modification to TCP that basically solves the problem of large buffers.
If the 3x slowdown from the infrastructure were eliminated, each round-trip-time being 3x faster would affect all the protocols above, and we could immediately cut the latency inflation from ~37x to around 10x, without any protocol modifications. The page this article is published on makes 87 separate network requests to 19 different domains. Even with a great deal of the content cached, it takes 7 seconds to reload…
If the 3x slowdown from the infrastructure were eliminated, each round-trip-time being 3x faster would affect all the protocols above, and we could immediately cut the latency inflation from ~37x to around 10x, without any protocol modifications. The page this article is published on makes 87 separate network requests to 19 different domains. Even with a great deal of the content cached, it takes 7 seconds to reload…
As much as ads are annoying, this has nothing to do with the article. One man's bloat is another man's content. No need for this nag to be top comment on HN for an article about why data isn't moving at the speed of light.
"Slow" internet is not so bad (especially when it is not really THAT slow). Limitations in connectivity force designers and developers (therefore large companies) to optimise things and save resources. Internet speed growth rate could be 5% (compounding) would be enough in order to provide a friendly environment for new frameworks, technologies in the field of network and web to benefit all.
If you're thinking, "it's fast enough!" -- remember that a system's performance determines what you're able to build on top of it. If GPU designers had said "it's fast enough" ten years ago, for example, modern neural-net AI may never have happened. It's easy to imagine doing the same things faster, but it's harder to picture the new things that a lower-latency Internet would make possible.
I don't think anyone that has ever used Skype, VoIP, Facetime, etc has thought "this is fast enough".
Earlier quoted context omitted.
As much as ads are annoying, this has nothing to do with the article. One man's bloat is another man's content. No need for this nag to be top comment on HN for an article about why data isn't moving at the speed of light.
They don't need to cut advertisements. Certainly, they could have as many as 10 advertisements, and only make requests to two domains---the ad network, and their own domain. Their page has a high number of requests primarily because they do not bundle their javascript, CSS, or icons. I see 95 requests that I see without adblocking, and about 20 of those requests are javascript coming out of their own WordPress instan…
Think about it. If you include a gigantic library in a compiled language, but only use 3 of its features, the rest of the library doesn't make it into your final program. Only those three features that you used do, because that's the linker's job. It takes only the features of a given library that are actually used for space efficiency reasons, and removed anything unneeded.
This is possible for JavaScript, but common language usage patterns work against this goal. If you're going to use a clientside library that's fine, but you should ship only the small fraction of it that your code actually calls into, not the entire honking library, 90% of which goes untouched by the client for every user.
Point here is, I agree with you, but this is a difficult problem to solve. You're asking a large number of frankly inexperienced programmers to deviate heavily from most JavaScript tutorials, and worse, most example code included in the documentation of most large frameworks.