A common mistake I see when people use libcurl is to create a new handle for each request, which pretty much guarantees no connection reuse. Reuse your handles for profit.
Stop Wasting Connections, Use HTTP Keep-Alive
21–30 of 112 posts
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#22Earlier quoted context omitted.
Why does the radio have to be on just because there is an open TCP connection?
Are you asking why the radio has to be on or implying there are other reason that the radio could be on for? If you have a TCP connection open but the radio is off how are you going to receive incoming packets?
If it's a keep alive connection, you can just get the packets when you next turn on the radio. It's not a big deal to get the close right away; not that there's a good way to tell the system that. Anyway, you probably have a tcp connection open for the system push channel; if that requires the radio to stay on, it will be on.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#23too bad 99% of routers drop keepalives
TCP keepalives != HTTP keepalives.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#24Unfortunately most people's primary computing devices are smart phones and smart phone radios cannot keep a TCP connection open, or won't, because of power usage.
Keeping connection open does not require any action. Also radios have nothing to do with connections. Connections are abstractions from a different layer. Radios are shut down much more frequently than you'd think, to save power.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#25Better yet.. switch to http2 (where keep-alive is deprecated): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ke...
Its amazing that not everyone is on http2 yet when its basically free speed.
It's hardly a surprise. It takes time for people to migrate to new protocols. Not everyone can just leave 20 years of engineering effort behind and switch to HTTP2 because it's a bit faster in some situations.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#26Better yet.. switch to http2 (where keep-alive is deprecated): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ke...
of course, because http2 is stateful and whenever the server or client whishes, they can send a close message.
but stateful connection management comes with a cost, especially on tcp.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#27Better yet.. switch to http2 (where keep-alive is deprecated): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ke...
Its amazing that not everyone is on http2 yet when its basically free speed.
I’m not amazed. While many stacks support it, most organizations still have lift on their end to implement this behind the other “priority” customer change requests.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#28Better yet.. switch to http2 (where keep-alive is deprecated): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ke...
Is it easy for Django/Rails/ExpressJS to implement Http2 in their next release?
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#29Be aware of the maximum connection bottlenecks in your stack, especially if you have an interactive app.
I've had apache refuse new requests because old connections were holding slots.
Re: Stop Wasting Connections, Use HTTP Keep-Alive
#30Sure, if Apple have fixed their issues with Keep-Alive for Safari: https://stackoverflow.com/questions/25372318/error-domain-ns...
According to https://tools.ietf.org/html/rfc2068#section-19.7.1.1 HTTP/1.1 defines the "Keep-Alive" header for use with keep-alive parameters but does not actually define any keep-alive parameters. I don't see a definition of this header in any of the RFCs that obsolete this one (just some mentions of issues with persistent connections and HTTP/1.0 servers, and the fact that Keep-Alive is a hop-by-hop header).
MDN's documentation on this header references https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01... for the parameters, but this is an experimental draft that expired in 2012.
Which is to say, I can't really fault Safari for not respecting keep-alive parameters that never made it out of the experimental draft phase.