OKHTTP on Android does not negotiate SPDY against nginx endpoints?

[mejofi]

We are running into an issue where OKHTTP on Android does not negotiate SPDY against nginx endpoints we have control over, and falls back to HTTP/1.1 instead. This seems to happen for all versions we have active;

• nginx 1.6.2, the stock package on Debian Jessie
• nginx 1.8.0, from the Dotdeb repository, also on Debian Jessie

When tested against CloudFlare, OKHTTP negotiates SPDY/3.1. Our own endpoints do SPDY/3.1 in Chrome and Firefox without any problems, and AFNetworking in the iOS app hums along happily on SPDY as well, it's purely the Android app where we are seeing this behaviour.

Possibly related to #1895?

[jurenovic]

This behaviour was discovered using stock Nexus 5, Android version 6.0, Build number MRA58K with OkHttp version 2.5 and stock Nexus 5, Android version 5.1.1, Build number LMY48M with OkHttp version 2.5

[swankjesse]

Is your server running ALPN or NPN?

[swankjesse]

It's unlikely we’ll fix this. I’m hoping to delete SPDY support entirely in a future release. HTTP/2 is the future.

[mejofi]

NPN, AFAICT. ALPN does not appear in nginx until the version that includes the HTTP/2 module, which only became available three weeks or so ago; https://www.nginx.com/blog/nginx-1-9-5/

It will take a good while before it becomes widely available in mainstream distributions, and the 1.8 branch is still supported. Given that upgrading to HTTP/2 doesn't just require updating the nginx binary, but also the OpenSSL version it's built against, I'd say it's a bit too early to drop support for SPDY at this time?

[swankjesse]

You probably don't want NGINX 1.9.5 due to this bug:
http://hg.nginx.org/nginx/rev/0e37389c0bd5

[mejofi]

Reiterate my point about it being too early to drop SPDY support :-)

[swankjesse]

Unfortunately we had a lot of problem with NPN on various Android devices, and testing 'em is particularly painful. If you want to bring it back in a branch, the original rollback is here:
#1201

[mufumbo]

oh man, this is painful. very slow connections using okhttp and https on cloudflare, since it has to re negotiate the handshake everytime. I'm getting 500ms latency for every request, opposed to 100ms with http or spdy

[swankjesse]

@mufumbo that's unexpected. It should reuse the connection. If it isn't, please provide a test case in a new issue report!

[mufumbo]

@swankjesse sorry I don't know how to submit a test case. Can you try to make OkHttp to call this: https://api.craftlog.com/api/health/latency/ping.json

That host is behind cloudflare. We use cloudflare mainly for easy SSL negotiation, but if it doesn't work properly with okhttp we probably need to figure out another solution, since it's really bad to re-negotiate SSL at every request.

Also, the latency to download this file is almost half if we create a fake "trust all" sslSocketFactory. This is probably the right behavior anyways.

[yschimke]

With OkHttp 3.9 that URL works from both desktop and Android. I get a successful HTTP/2 response. Can you use the latest OkHttp and use HTTP/2 instead of SPDY?

[mufumbo]

@yschimke we're on "com.squareup.okhttp3:okhttp:3.9.0"..

The app works very well. That's not the problem. I want to have a highly optimized connection that is reused and we don't want HTTPS negotiation to happen in every https request.

I wonder if more people have tried optimizing against cloudflare SSL stack.
I'm having trouble believing okhttp3 is reusing the HTTPS connections if every connection takes 200ms to be made. This is just the connection time without counting TTFB.

[yschimke]

OK, my own testing suggests that HTTP/2 is used, and we successfully re-use an existing connection the second time.

Try implement an event listener to confirm that it is connecting (or secure connecting) multiple times https://github.com/square/okhttp/wiki/Events