Fakultät Informatik Institut für Rechnernetze Thesis [Diplomarbeit] HTTP/2 - POSSIBILITIES FOR AND EXTENSIONS TO THE PROXY PATTERN Timo Lutz Matriculation number: 3444118 Supervised by: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill and: Dr. Ing. Tenshi Hara Submitted on 31th March 2017 i ABSTRACT HTTP/2 is the next evolutionary step of the Internet’s most used and adopted protocol. It accommodates the changed demands of on the one hand yearly growing content in number of resources and size and on the other hand altered way of accessing this content: In 2015, for the first time in the history of the internet, more traffic was generated from mobile devices than from stationary ones and this trend is expected to last. Moreover has the bandwidth available to each user grown exponentially while the latency, mostly depending on the distance to span, only improved marginally. In order to resolve this issue, a paradigm shift from simplicity towards performance has been put into effect by using a binary framing layer instead of being a pure text based protocol as its predecessor HTTP 1.1. The effects of this combined with header compression and a new set of features like Server Push shall be evaluated in general and with respect to the proxy pattern using the example of the SANE proxy at the Technische Universität Dresden. CONTENTS 1 Introduction 11 1.1 Objective ......................................... 13 1.2 Motivation ......................................... 13 1.3 Structure ......................................... 14 2 Preliminaries 15 2.1 TCP basics ........................................ 17 2.2 TLS basics ......................................... 18 2.3 Evolution of HTTP .................................... 19 2.3.1 Commonalities among all revisions ....................... 19 2.3.2 History of HTTP ................................. 19 2.3.3 Shortcomings of HTTP 1.1 ............................ 22 2.3.4 SPDY ....................................... 23 2.4 HTTP/2 .......................................... 23 2.4.1 Preserving downward compatibility ...................... 24 2.4.2 Advancement of HTTP/2 ............................. 24 2.4.3 HTTP/2 compared to HTTP 1.1 ......................... 28 2.5 The proxy pattern ..................................... 29 2.6 SANE ........................................... 29 3 Related Work 31 3.1 HTTP/2 in a nutshell ................................... 33 3.2 Quantifiable Aspects ................................... 33 3.2.1 Current adoption across the Web ........................ 33 3.2.2 Performance ................................... 34 3.2.3 Energy Efficiency ................................. 35 3.3 Server Push ........................................ 37 3.4 SANE and HTTP/2 .................................... 37 3.5 Summary ......................................... 38 4 Concept 39 4.1 SANE basics and principles ............................... 41 4.1.1 Architecture configurations ........................... 41 4.1.2 SANE method range ............................... 42 4.1.3 SANE: An application layer proxy ........................ 43 4.2 Expected impact of improvements on the SANE ................... 43 4.2.1 Implicit improvements .............................. 43 4.2.2 Link-type independent improvements ..................... 44 4.2.3 Link-type specific improvements ........................ 46 4.3 Classification and Realization of HTTP/2 advancements ................ 46 4.3.1 Link-type independent improvements ..................... 46 4.3.2 Cross propagation/runtime dependent features ................ 47 4.3.3 C − P link features for load control ....................... 48 4.3.4 P − S link features for load control ....................... 50 4.4 Evaluation criteria ..................................... 51 4.4.1 General criteria .................................. 51 4.4.2 Advancement specific criteria .......................... 52 4.5 Conclusion and further proceeding ........................... 53 5 Proof of Concept 55 5.1 Feasibility ......................................... 57 5.1.1 Client-Proxy (C − P) link ............................. 57 5.1.2 Proxy-Server (P − S) link ............................ 57 5.2 Functional demonstration ................................ 58 5.2.1 C − P Stream Reset ............................... 59 5.2.2 C − P Server Push ................................ 60 5.2.3 P − S Stream Reset ............................... 61 5.2.4 P − S Server Push ................................ 62 5.2.5 C − P − S Stream Reset ............................. 64 5.2.6 C − P − S Server Push ............................. 66 5.3 C − P Server Push Implementation ........................... 68 5.3.1 GET instead of POST .............................. 68 5.3.2 Parameters in the header ............................ 68 5.3.3 SANE control flow ................................ 69 5.3.4 Modifications for Server Push .......................... 69 5.3.5 Detailed implementation ............................ 72 5.3.6 Proof of functional capability .......................... 74 5.4 Remarks to upcoming implementations for SANE ................... 76 5.4.1 C − P Stream Reset ............................... 77 5.4.2 P − S Multiplexing ............................... 77 5.4.3 Employing FastCGI ................................ 77 5.5 Summary ......................................... 78 6 Evaluation 79 6.1 General performance assessment ........................... 81 6.2 Advancement specific assessment ........................... 83 6.2.1 Stream Reset ................................... 83 6.2.2 Server Push .................................... 84 6.3 Additional aspects .................................... 87 6.3.1 Automated Smart Multiplexing ......................... 88 6.3.2 Parallel execution of libcurl requests ...................... 89 6.3.3 External script processing ............................ 90 6.4 Summary ......................................... 91 7 Conclusion 93 7.1 Summary ......................................... 95 7.1.1 Concept ...................................... 95 7.1.2 Proof of Concept ................................. 96 7.1.3 Evaluation ..................................... 96 7.2 Perspective and future work ............................... 97 7.2.1 In General ..................................... 97 7.2.2 For the SANE ................................... 98 A Code snippets 99 B Test setup 109 C Communication protocols 111 D Copyright permissions 165 E Index 167 F Declaration of Authorship 175 1 INTRODUCTION Dimidium facti, qui coepit, habet: sapere aude, incipe. Horaz Since the introduction of the Hypertext Transfer Protocol the Internet or better the Web underwent many changes: Was the first version only intended to serve hypertext as the name suggests, it nowadays is used to transport a great variety of file types a thousandfold in size. As the usage pattern changed, the protocol, aside from smaller optimizations, remained the same. To better cope with the changed demands, a new version of this jack of all trades protocol has been launched in 2015: HTTP2.0 or HTTP/2 or just H2. The increase of the major version and the abandonment of a minor version reflects the extensive changes made under the hood, as will be examined carefully in the course of this thesis. 1.1 OBJECTIVE The objectives of the work at hand are, firstly, to systematically evaluate the impact of the improvements on client-server architecture in HTTP/2 in a general way. Secondly, to relate these improvements to the proxy pattern and, in case they turn out advantageous, implement them with special consideration of end-to-end architectures and possibly pre-existing solutions. The outcome of the conducted improvements will finally be measured on the basis of previously defined evaluation criteria. 1.2 MOTIVATION Since the introduction of HTTP1.1 in the year 1991, the Web underwent massive changes, although with the increase in size of websites also the bandwidth increased to a comparable extent. Alongside sheer bandwidth, the second factor significant for the experienced speed only improved marginally: Latency, which is mainly a function of the peers’ distance, as the time a packet needs to travel a certain distance is delimited by the speed of light and the wire’s refractive index respectively. As those last two factors can be considered constant for the case at hand, other ways of reducing the load time have to be found, as latency influences the necessary time to load data on multiple ways: Due to the increased complexity of web sites and -applications, the amount of requests to download an average website also increased, leading to a lower perceived speed, as the individual latencies add up with every additional round-trip needed until the whole website has arrived at their particular destination. Moreover, is the latency of a connection also determining the maximum data rate as a factor in the Bandwidth-Delay Product. As an application layer protocol HTTP/2 has in fact minimal impact on this issue of lower layers, but bears functionality to send data earlier and more efficiently, combine certain steps to require less round-trips or to recognize whether something has to be sent at all. "No bit is faster than a bit not sent." [Gri13a] The effect of the Bandwith-Delay product becomes even stronger in mobile networks, where the transmission of packets naturally takes even more time. This issue will be examined more detailed in 2.4.3. With HTTP/2, the subject of this work, most improvements concern an overall faster perceived