Hacker News new | past | comments | ask | show | jobs | submit login

"If the clients use HTTP/2, data transfer decreases further, as response headers are compressed."

But CPU usage is increased for decompression and CPU is the only real bottleneck.

Just because you don't pay for the compression electricity doesn't mean you get away with it.

This ties back to my previous comment on the User-Agent subject yesterday, remove all headers except "Host" from all HTTP traffic is the solution.

HTTPS is a complete waste of energy. Security should not be overarching, it should be precision.

WebSockets are also bad, since they don't work well with memory latency. Use "Transfer-Encoding: chunked" on a separate pull connection instead.




> HTTPS is a complete waste of energy. Security should not be overarching, it should be precision.

A harmless meme in the US might get you executed in North Korea. Optimizing for energy usage (which is already pretty minor on modern hardware for HTTPS these days) over security is odd.


Electric use for the client on compressed vs not compressed isn't as clear cut as more/less cpu. You also need to consider the reduction in use of the network interface, since the data size will be smaller. Overall latency could improve as well if the compressed form is meaningfully smaller (depending on the tcp congestion window, just one packet smaller can mean a whole roundtrip time)


No, that's not how it works, you cannot upgrade the routers in real-time without complexity and additional cost. So the cost for transfer is fixed with more latency. But if you subtract bad protocol design and the latency added by the compression/decompression I'm pretty sure you end up with the same deal just more complexity that costs even if you don't see the costs.

Just like wind-power actually competes with nuclear because it take 30 days to wind down a nuclear power plant.

Also data can be compressed with more efficient hardware on the backbone without you having to deal with it.

The biggest cost of the internet is idle things and synchronized CPUs, async. never made it unfortunately.


HTTP/2 isn't used on the backend AFAIK, so the CPU usage isn't a concern I terms of increase load on e.g.e EC2


Still there is going to be energy lost for very little in return. We need to go the other direction; less machines, less IP addresses, less energy, less complexity, less code, etc.

The only thing we need more of is cores and we can't have that because memory is too slow.


I think this post shows that indeed small things adds up. Energy might rise by using HTTP/2, but that's not the concerns of OP, they want to reduce their cost, not their energy footprint.


I think you are going to have a rough time if you separate energy and money like that. The only reason the dollar is worth anything is because of coal, oil, gas and nuclear.

What do you think happens to the value of the dollar when the physical supply of energy becomes unstable in the coming years?

Money is energy because debt needs energy to either have been spent in the past or energy being promised to be spent in the future.

The proportion between these is what makes debt money trustworthy or not. When the states around the world privatizes houses that is old energy (so far since the energy to heat the house is marginal compared to building it), but when the stock market goes up that is a promise for new energy.

Globally all money for old energy is saturated (negative interest rates) and now all liquidity is being injected into the stock market that promises that the future will be rich with energy.

The stock market (and all companies) is a promise to spend energy we don't have.

The only energy that is added to earth is sunlight, the only way to capture that energy are trees and plants.

All jobs are now meaningless because of the energy that we are wasting. And people now depend on wasting energy to have a job.

Do you see why energy is more important than money?


I did not say energy is more important than money.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: