COMPARISON BETWEEN HTTP AND HTTPS PERFORMANCE [601930]

COMPARISON BETWEEN HTTP AND HTTPS PERFORMANCE
A performance analysis of HTTP and HTTPS

Cristian Udrescu
University POLITEHNICA of Bucharest
Bucharest, Romania
[anonimizat]

Abstract — the increased concern for security in web
application s and privacy of user information has led to
increasing adoption of the HTTPS protocol over HTTP. The
benefits given by the encrypted communication offered by
HTTPS comes with a few costs determined by the overhead
introduced in terms of infrastructure, latency and data usage.
Additionally any services between the server and client such as
proxies and caches become ineffective due to the opaqueness of
the communication.
This paper addresses the performance o verhead added by the
HTTPS protocol over HTTP by measuring the average loading
time for a large data set in different formats in a web application
deployed on different servers .

Keywords — network protocols, HTTPS performance, TLS,
SSL

I. INTRODUCTION

The HyperText Transfer Protocol (HTTP) was
introduced in 1997 when the Internet and web
applications were still in an early stage and most websites
consisted of static content displ ayed in a browser. Since
then, t he Internet has changed significantly becoming the
primary infrastructure for communication, commerce,
education and information storage and access. Enabling
users to easily communicate sensitive information online
was a necessary condition for its growth.
The core protocols of World Wide Web, namely
HTTP and HTML were not designed with security in
mind. As a result, a series of new technologies have been
gradually introduced to the basic web stack.
HTTPS is the dominant protocol used to secure web
traffic and consists of layering HTTP traffic over the
SSL/TLS encrypted transport protocols.
While originally developed for websites that required
data confidentiality or authentication between server and
client, like online -banking systems or e -commerce
services, the increased concern for users’ privacy has led
to the adoption of HTTPS by the lar ge majority of
websites, such as Gmail, Facebook or YouTube. Google announced its intention to implement HTTPS
for all the services it provides (Fig 1) .

Figure 1. Adoption of HTTPS in Google services

According to [1] more than 50 % of the web traffic
today is secured through HTTPS and this number is
increasing. However, security comes at a cost and HTTPS
makes no exception.
While encryption provides a clear benefit to the user
in terms of confidentiality and authentication it could
have implications that are harder to assess. Middleware
services aiming to reduce the amount of traffic, compress
content before transmission or filter
inappropriate/undesired content to protect users suddenly
become ineffective in the presence of encryption.
In this article we aim to determine the performance
overhead added by this prot ocol when compared to
HTTP. We will analyze how TLS impacts latency and
data-consumption. HTTPS requires an additional
handshake between the client and the server and adds
computational cost for encryption operations. Our goal is
to determine how significant this costs are for a web
application. In the following paragraphs we will do an
overview of the HTTPS protocol, present the testing
mechanism we developed and the p erformance difference
that we noticed.
II. RELATED WORK
Security of the web communication has been the
subject of a lot of research and HTTPS in particular has
received a lot of academic attention. However most
papers have focused on the implementation details or the
potential vulnerabilities of the protocol and how they can
be avoided.

In [2 ] the authors do an analysis of the underlying
model of the HTTPS protocol and its certificate and go
through the security challenges the protocol has faced
since its crea tion and the enhancements done to overcome
this issues.
Another research done in [3 ] focuses on HTTPS
hijacking attacks and proposes three different measures to
defend against it, which are static ARP table, enhanced
certificate system and two -way authenti cation.
The article [4 ] researches HTTPS vulnerability
against SSL -MITM (SSL Man in the Middle) attacks and
suggests a few methodologies to prevent the decoding of
confidential data.
We have found only 2 articles whose main subject is
similar to our paper tackling the costs introduced by
HTTPS and the performance overhead it brings when
compared to HTTP.
The first article “A comparison o f HTTP and HTTPS
performance” [5 ] was published in 1998 by Arthur
Goldberg, Robert Buff and Andrew Schmitt and
compares th e performance of encrypted and un -encrypted
web communications.
The authors have compared the average and median
response time for the same application serving static
HTML documents on two popular web servers at that
time, Netscape Enterprise Server 3.5.1 and Microsoft IIS
4.0 and concluded that encryption increases this time by
at most 22%.
The second article “The cost of the S in HTTPS” [6],
published in 2014, takes a more complete view of the
overhead introduced by HTTPS analyzing the adoption
rate of H TTPS over the last 3 years and the costs of
webpage load time, data usage, battery life of devices and
loss of value -added services.
In order to quantify the HTTPS page load time
overhead the authors measured the load time for the top
500 Alexa sites 20 times, first using HTTP and then
HTTPS. The pages were downloaded using the
PhantomJS headless browser running on a Linux PC
connected to a 3G USB modem and via fiber.
The results show that using HTTPS significantly
increases load time. For a 3G connection the extra latency
is larger than 500 ms for about 90% of websites resulting
in an inflation factor larger than 1.5x. On fiber the ext ra
latency is smaller but still significant resulting in a 1.3x
increase. An important factor of the load overhead is the
time required to establish a connection and the increased
time per handshake caused primarily by TLS negotiation
overhead.
HTTPS also impacts the volume of data usage due to
the size of TLS handshake and the inability to use network
caches or compression proxies. The impact of TLS handshake is determined by the
size of data transferred through the connection , the more
data transferred t he lower the negotiation cost .
Measurements done by the authors , show that the average
TLS negotiation overhead amounts to 5% of the total
volume of data.
In regard to the second cause of increased data usage
the article concluded that m ost users are unlik ely to notice
significant jumps in data usage due to loss of
compression, but ISPs stand to see a large increase in
upstream traffic due to loss of caching.
The effect on battery life has been tested on a mobile
device with a power meter that samples the c urrent drawn
by the phone while loading a webpage 50 times over
HTTP and HTTPS using Chrome for Android. The
conclusion of this test was that HTTPS cryptographic
operation have almost no impact on energy costs.
The loss of value -added services , such as dee p packet
inspection, simple URL filtering, content prioritization or
blocking tracking cookies, is difficult to quantify but has
an impact on the performance of web applications.
Each of the papers mentioned above analyzes the
performance difference betwee n HTTPS and HTTP and
provides benchmarked results to support the conclusion
that HTTPS adds an overhead in page loading time that
can be critical especially in mobile networks .
While the articles above conducted their tests by
measuring the load time of a webpage, this paper focuses
on measuring the overhead added by HTTPS to the
response time of REST services using different response
formats such as JSON, XML or OCTET_STREAM.
III. PROTOCOL OVERVIEW

We have mentioned previously that HTTPS is simply
HTTP with a SSL/TLS encryption layer on top of it.
HTTP is a stateless protocol that allows
communication between a server and a client via a
request/response pair. Its definition presumes an
underlying and reliable transport layer protocol, and
Transmission Control Protocol (TCP) is commonly used.
However HTTP can be adapted to use unreliable
protocols such as the User Datagram Protocol (UDP).
An HTTP client, for example a browser, initiates a
request by establishing a Transmission Control Protocol
(TCP) connection to a particular port on a server
(typica lly 80 or 8080). The HTTP request can be
structured in request method (GET, POST, PUT,
DELETE etc.), request headers and request body. Upon
receiving the request the server sends back a status such
as "HTTP/1.1 200 OK" and a message of its own. Details

of the protocol architecture are outside the scope of this
paper and can be found in [7].
Through HTTPS the servers and clients speak exactly
the same, but over a secure SSL connection that encrypts
and decrypts their requests and responses. The SSL layer
has 2 purposes:
 verify the identity of the server the client is
talking to
 ensure that only the server and the client can
read the messages they exchange
A SSL connection between a client and server is set
up by a handshake which is structured into 3 main phases:
1. “Hello”: The handshake begins with the client
sending a ClientHello message. This contains all the
information the server needs in order to connect to the
client via SSL, including the various cipher suites and
maximum SSL version that it supports. The server
responds with a ServerHello, which contains similar
information required by the client, including a
decision based on the client’s preferences about
which cipher suite and version of SSL will be used.
2. Certificate Exchange : Now that contact has been
established, the server has to prove its identity to the
client. This is achieved using its SSL certificate,
which is a very tiny bit like its passport. An SSL
certificate contains various pieces of data, including
the name of the owner, the property (eg. domain) it is
attached to, the certificate’s public key, the digital
signature and information about the certificate’s
validity dates. The client checks that it either
implicitly trusts the certificate, or that it is verified
and trusted by one of several Certificate Authorities
(CAs) that it also implicitly trusts.
3. Key Exchange : The encryption of the actual message
data exchanged by the client and server will be done
using a symmetric algorithm, the exact nature of
which was already agreed during the Hello phase. A
symmetric algorithm uses a single key for both
encryptio n and decryption, in contrast to asymmetric
algorithms that require a public/private key pair. Both
parties need to agree on this single, symmetric key, a
process that is accomplished securely using
asymmetric encryption and the server’s public/private
keys.
After the handshake is established the client and
server can begin communicating through messages. Even
if the message is intercepted the data would not be
accessible to the attacker as it can only be deciphered by
the server or the client who know the key [8]. IV. EXPERIMENT AL METHODOLOGY
In order to evaluate the cost of server encryption and
client decryption we measured the average response time
for several rest services.
We developed a web application that exposes 3 REST
services [9] to get data in 3 different formats: JSON, XML
and OCTET_STREAM. The data used for the
measurement consists of an array of 10000 objects with
the followin g structure :
The application was developed in Java using the
Spring MVC framework , version 4.2 [10]. To measure the
response time and extract graphical results we used
Apache JMeter version 3.1 [11].
We packaged the application in a war file and
deployed it on two of the most commonly used
application servers that are currently available free of
charge: Tomcat version 7.0.64 and J Boss version 7.0.1.
We configured the servers to run bot h on HTTP and
HTTPS and using JMeter we sent 10 requests to each of
the rest services described above and measured the
average response time.
By doing so we determined the performance overhead
of HTTPS on REST services using different response
formats and different application servers.

V. EXPERIMENT AL RESULTS

The experiment described above was run on a
machine with a 1.7 GHz Intel i5 processor, 16 GB of ram
and Windows 8.1 as operating system. Both the server and
the JMeter client were running on the same machine.
The results obtained for HTTP and HTTPS for the 3
response formats using Tomcat as the application server
are described in the following graph s:

Fig.1. HTT P Response T ime
User : {
int id; Date dateOfBirth;
int age; String email;
String firstName ; String lastName;
String password;
}

Fig.2. HTT PS Response T ime

Both figures show that the response time depends on
the metadata added by the format in which the data is
represented. The XML response time is the highest with
an average of 110 ms for HTTP and 490 ms for HTTPS,
JSON follows with 56 ms for HTTP and 400 ms f or
HTTPS and OCTET_STREAM is the fastest re sponse
time format with 11 ms for HTTP and 129 ms for HTTPS.
We made the same measurements on a JBoss
application server with similar results. The average
response times are detailed in the following table:

Tomcat JBoss
HTTP HTTPS HTTP HTTPS
XML 110ms 483ms 73ms 543ms
JSON 56ms 400ms 29ms 372ms
OCTET_STREAM 11ms 129ms 10ms 119ms
Table 1. Response T ime Results

We noticed a small improvement in response time
when the application was running on the JBoss
applica tion server but the difference is not significant. We
can safely conclude that the application server chosen for
the application has negligible effect on the performance
of HTTP and HTTPS.

Fig.3. HTTP/ HTT PS Response T ime

In figure 3 w e can see the graphical representation
generated in JMeter of both HTTP and HTTPS response
times for 10 consecutive runs for each of the response
formats .
It is important to note that our measurements showed
an average of 60 ms time required for establishing the connection when the requests were made using the
HTTPS protocol.
The final results show that HTTPS significantly
increases the load time for a REST service in a web
appli cation. Depending on the format of the response
which determines the size of the data returned , the
increase in response time is about 4.3x for XML, 7.1x for
JSON and 10x for OCTET_STREAM.
VI. CONCLUSION

Motivated by the necessity of assuring a secure
communication mechanism of user private data HTTPS
continues to be adopted by most of the web applications
at a very high rate. However the security improvement it
introduces comes with a noticeable cost in performance.
A large number of the web applications developed
today use the REST architecture to bring data on demand
and display content to users dynamically .
Motivated by this trend in develop ment we have run
a series o f measurements to determine what is the impact
of using HTTPS instead of HTTP for REST service s.
Our results show that the difference in response time
is significant and can affect the user experience for a web
application .
We hope that the work we have done in this paper can
serve as a starting point for introducing new performance
improvements to the HTTPS protocol as well as help
developers of web applications to carefully decide which
protocol is most suitable to be used.
VII. REFERENCES
[1] Kranch, Michael, and Joseph Bonneau. "Upgrading HTTPS in Mid -Air."
(2015).
[2] Clark, Jeremy, and Paul C. van Oorschot. "SoK: SSL and HTTPS:
Revisiting past challenges and evaluating certificate trust model
enhancements." Security and Privacy (SP), 2013 IEEE Symposium on .
IEEE, 2013.
[3] Cheng, Kefei, Meng Gao, and Ruijie Guo. "Analysis and research on
HTTPS hijacking attacks." Networks Security Wireless Communications
and Trusted Computing (NSWCTC), 2010 Second International
Conference on . Vol. 2. IEEE, 2010.
[4] Chomsiri, Thawatchai. "HTTPS Hacking protection." Advanced
Information Networking and Applications Workshops, 2007, AINAW'07.
21st International Conference on . Vol. 1. IEEE, 2007.
[5] Goldberg, Arthur, Robert Buff, and Andrew Schmitt. "A comparison of
HTTP and HTTPS performance ." Computer Measurement Group,
CMG98 (1998).
[6] Naylor, David, et al. "The cost of the s in https." Proceedings of the
10th ACM International on Conference on emerging Networking
Experiments and Technologies . ACM, 2014.
[7] Fielding, Roy, et al. Hypertext transfer protocol –HTTP/1. 1. No. RFC
2616. 1999 .
[8] Durumeric, Zakir, et al. "Analysis of the HTTPS certificate
ecosystem." Proceedings of the 2013 conference on Internet
measurement conferenc e. ACM, 2013 .
[9] Battle, Robert, and Edward Benson. "Bridging the semantic Web and
Web 2.0 with representational state transfer (REST)." Web Semantics:
Science, Services and Agents on the World Wide We b 6.1 (2008): 61 -69.

[10] Johnson, Rod, et al. "The spring framework –reference
documentation." Interfac e 21 (2004) .
[11] Halili, Emily H. Apache JMeter: A practical beginner's guide to
automated testing and performance measurement for your website s.
Packt Publishing Ltd, 2008 .