Jetty supports both a client and a server implementation for the SPDY protocol, beginning with versions 7.6.2 and 8.1.2.
http://www.chromium.org/spdy/spdy-protocol
direct usage:
- SPDY Client - SPDY Server
remap in/out of the box:
- SPDY Client - SPDY PROXY - HTTP Server
- HTTP Client - SPDY PROXY - SPDY Server
SPDY proxy
- Jetty
- Nginx
https://wiki.eclipse.org/Jetty/Feature/SPDY
but only DPSYProxyEngine supported now, https://bugs.eclipse.org/bugs/show_bug.cgi?id=396606
spdy-jetty-http also provides a fully functional SPDY proxy server out of the box. Jetty's SPDY proxy is capable to receive SPDY (currently v2/v3) and HTTP requests and proxy those requests to other SPDY servers. It will if necessary translate the incoming protocol to a protocol the target host understands. The translation to the target server protocol is done by an implementation of the ProxyEngine class. Right now we only provide a SPDYProxyEngine implementation which can talk spdy/2 and spdy/3. We're planning to support other protocols soon out of the box. As always contributions are welcome.
but, fixed in jetty9(JDK7/8)
Status: CLOSED FIXED
Reported: 2012-12-14 07:27 EST by Thomas Becker CLA Friend
Modified: 2013-02-13 11:42 EST (History)
spdy-jetty-http provides a fully functional SPDY proxy server out of the box. Jetty's SPDY proxy can receive SPDY (currently v2/v3) and HTTP requests, and proxy those requests to other SPDY servers. If necessary, an implementation of the Proxy Engine class translates the incoming protocol to a protocol the target host understands. Currently we provide a SPDYProxyEngine that can talk SPDY v2 and SPDY v3. We plan to support other protocols soon. As always, contributions are welcome.
An Example Configuration for a SPDY to HTTP Proxy, http://www.eclipse.org/jetty/documentation/9.1.3.v20140225/spdy-configuring-proxy.html
spdy-jetty-http provides full proxy functionality as described above. Here's another example configuration for a SPDY to HTTP proxy. This proxy accepts SPDY requests and proxies them to an HTTP server.
This is a very common use case, for example to terminate SPDY on a frontend server when you need to talk plain HTTP to your backend, because either your network hardware needs to inspect HTTP content or your backend is unable to talk SPDY. You have the performance advantages of SPDY over the slow internet with high latencies, and you talk HTTP to your backend as needed.
http://nginx.org/en/docs/http/ngx_http_spdy_module.html
http://www.nginxtips.com/how-to-install-and-configure-spdy-on-nginx/
./configure --with-http_spdy_module --with-http_ssl_module --with-pcre=~/pcre-8.36 --with-openssl=~/openssl-1.0.1j/worker_processes 1;
error_log /home/houkun/error.log;
pid /home/houkun/nginx.pid;
events {
worker_connections 1024;
}
http {
server {
listen 4433 ssl spdy;
server_name localhost;
ssl_certificate /home/houkun/stunnel.pem;
ssl_certificate_key /home/houkun/stunnel.pem;
location / {
proxy_pass http://10.2.14.243:8080;
}
}
}
curl "https://10.189.226.27/router/rest?app_key=4272&format=json&id=1&method=taobao.time.get&partner_id=sdk-bash×tamp=1419301233&v=2.0&sign=95DDD0F9DAB08ECD5F50DD2660828049"
chrome://net-internals/#spdyOkHttp An HTTP & SPDY client for Android and Java applications http://square.github.io/okhttp/
You can try out OkHttp without rewriting your network code. The okhttp-urlconnection module implements the familiar java.net.HttpURLConnection API and the okhttp-apache module implements the Apache HttpClient API.
OkHttp supports Android 2.3 and above. For Java, the minimum requirement is 1.7.
http://www.eclipse.org/jetty/documentation/current/spdy.html
Jetty's SPDY modules Jetty supports both a client and a server implementation for the SPDY protocol, beginning with versions 7.6.2 and 8.1.2. As Jetty 7 and 8 are now in maintenance-only mode, we recommend using Jetty 9 if you intend to use SPDY. Not all features described here exist in 7/8. To provide the best support possible for SPDY, the Jetty project also provides an implementation for NPN. Both the SPDY and the NPN implementations require OpenJDK 1.7 or greater.
SPDY_SESSION_UPDATE_RECV_WINDOW after SPDY_SESSION_RECV_DATA
https://www.belshe.com/2012/03/29/comments-on-microsofts-spdy-proposal/
c) Removal of Flow Control The Microsoft proposal is quick to dismiss SPDY’s per-stream flow control as though it is already handled at the TCP layer. However, this is incorrect. TCP handles flow control for the TCP stream. Because SPDY introduces multiple concurrent flows, a new layer of flow control is necessary. Imagine you were sending 10 streams to a server, and one of those streams stalled out (for whatever reason). Without flow control, you either have to terminate all the streams, buffer unbounded amounts of memory, or stall all the streams. None of these are good outcomes, and TCP’s flow control is not the same as SPDY’s flow control.
This may be an example of where SPDY’s implementation experience trumps any amount of protocol theory. For those who remember, earlier drafts of SPDY didn’t have flow control. We were aware of it long ago, but until we fully implemented SPDY, we didn’t know how badly it was needed nor how to do it in a performant and simple manner. I can’t emphasize enough with protocols how important it is to actually implement your proposals. If you don’t implement them, you don’t really know if it works.
http://chimera.labs.oreilly.com/books/1230000000545/ch12.html
Does the preceding list remind you of TCP flow control? It should; the mechanism is effectively identical—see “Flow Control”. However, because TCP flow control cannot differentiate among the many streams within a single HTTP 2.0 connection, it is insufficient on its own. Hence the reason for HTTP 2.0 flow control.
The HTTP 2.0 standard does not specify any specific algorithm, values, or when the WINDOW_UPDATE frames should be sent: the implementers are able to select their own algorithm to match their use case and deliver the best performance.
https://github.com/square/okhttp/wiki/Building