What is HTTP/2?#

HTTP/2 is a replacement for how HTTP is expressed “on the wire.” It is not a ground-up rewrite of the protocol; HTTP methods, status codes and semantics are the same, and it should be possible to use the same APIs as HTTP/1.x (possibly with some small additions) to represent the protocol.

The focus of the protocol is on performance; specifically, end-user perceived latency, network and server resource usage. One major goal is to allow the use of a single connection from browsers to a Web site.

The basis of the work was SPDY, but HTTP/2 has evolved to take the community’s input into account, incorporating several improvements in the process.

Snippet from Akamai

HTTP/2 attempts to solve many of the shortcomings and inflexibilities of HTTP/1.1.

Its many benefits include:

• Multiplexing and concurrency: Several requests can be sent in rapid succession on the same TCP connection, and responses can be received out of order – eliminating the need for multiple connections between the client and the server
• Stream dependencies: the client can indicate to the server which of the resources are more important
  than the others
• Header compression: HTTP header size is drastically reduced
• Server push: The server can send resources the client has not yet requested

You will not need to change your websites or applications to ensure they continue to work properly. Not only will your application code and HTTP APIs continue to work uninterrupted, but your application will also likely perform better and consume fewer resources on both client and server.

As it becomes more prevalent, organizations looking to benefit from the performance and security features of HTTP/2 should start thinking about how they are invested to fully capitalize on these new capabilities. Such considerations include:

• Encrypting: Applications running over HTTP/2 are likely to experience improvements in performance over secure connections. This is an important consideration for companies contemplating the move to TLS.
• Optimizing the TCP layer: Applications should be designed with a TCP layer implemented to account for the switch from multiple TCP connections to a single long-lived one, especially when adjusting the congestion window in response to packet loss.
• Undoing HTTP/1.1 best practices: Many “best practices” associated with applications delivered over HTTP/1.1 (such as domain sharding, image spriting, resource in-lining and concatenation) are not only unnecessary when delivering over HTTP/2, and in some cases may actually cause sub-optimizations.
• Deciding what and when to push: Applications designed to take advantage of the new server push capabilities in HTTP/2 must be carefully designed to balance performance and utility.

Preparation

mkdir /root/rpmbuild
cd /root/rpmbuild
yum -y install rpm-build
mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
echo ‘%_topdir %(echo $HOME)/rpmbuild’ > ~/.rpmmacros

OpenSSL Dependency

yum -y install perl-WWW-Curl
#apr depend
yum -y install lksctp-tools-devel

Apache Dependency

yum -y install xmlto lua-devel ea-apr-devel ea-apr-util-devel
yum -y install createrepo
mkdir /root/repo

nano /etc/yum.repos.d/local.repo

name=CentOS-$releasever – local packages baseurl=file:///root/repo enabled=1 gpgcheck=0 protect=1 cost=20 priority=1

Misc Dependencies

cd /root/rpmbuild
mkdir poop
git clone https://github.com/Cacasapo/ea-apache2-http2.git poop
mv -n poop/SOURCES/find.pl /usr/lib64/perl5
\cp -R poop/SPECS/* SPECS/
\cp -R poop/SOURCES/* SOURCES/
rm -fr poop

OpenSSL

rpmbuild -ba SPECS/openssl.spec
\cp RPMS/x86_64/openssl-parallel* ../repo
createrepo /root/repo
yum clean expire-cache
yum -y install openssl-parallel

Do NGHTTP/2

rpmbuild -ba SPECS/nghttp2.spec
\cp RPMS/x86_64/libng* ../repo
\cp RPMS/x86_64/nghttp* ../repo
createrepo /root/repo
yum clean expire-cache
yum -y install libnghttp2-devel

Do Apache

rpmbuild -ba SPECS/ea-apache24.spec
\cp RPMS/x86_64/ea-apache24* ../repo
createrepo /root/repo
yum clean expire-cache
yum -y install ea-apache24