Optimizing Web Performance

performance of web applications n.w
1 / 12
Embed
Share

Discover the process of how web browsers handle clicking on links, servers' role in receiving and responding to requests, and modern web optimization techniques like reducing space and requests, utilizing caching, and more.

  • Web performance
  • Optimization
  • Caching
  • HTTP requests
  • Server response

Uploaded on | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. PERFORMANCE OF WEB APPLICATIONS Software Performance Engineering 1

  2. The Interview Question What happens when I click on a link in a browser? Browser formulates an HTTP Request: GET /hello.htm HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) Host: www.rit.edu Accept-Language: en-us Accept-Encoding: gzip, deflate Connection: Keep-Alive Browser packs up the HTTP Request and determines where to send it First looks up the host name via DNS to get the IP address Breaks the HTTP Req string into packets Browser sends packets over the TCP protocol to the host The host computer has a program called a Web Server running constantly that s listening for packets e.g. Apache HTTPD, nginx Listens on various ports, usually 80 and 443 2

  3. The Interview Question (2) Server receives the packets Only once the all packets are received (TCP is lossless after all) HTTP request string is re-assembled, and parsed Server will route the request and send back a response Routes to static files or to a dynamic web application, HTTP Response will have headers, a body of typically HTML Browser receives the HTTP Response, and then parses it As it parses, it finds more HTTP requests to make! e.g. CSS, JS, images, fonts, etc Makes those requests while painting what it has thus far Executes any JS as directed Server receives requests for those assets and sends them back HTTP is stateless , meaning the second set of HTTP requests are not aware that they were part of the original request It s up to the application to maintain state (e.g. logins) 3

  4. How the Web is Optimized Today Reducing space Reducing requests: Caching Reducing requests: Avoiding page refreshes HTTP/2 (many more but that s enough for today) 4

  5. Reducing Space Code minification and asset packing e.g. WebPack, Grunt/Gulp, Uglifier, many others Converts human-readable code into compressed code HTTP request/response compression via gzip is typical Image compression Usage of SVG vs. PNG vs. JPG SVG can be smaller, but is a logical series of instructions so it could be slow, could be fast PNG is lossless raster, but potentially large JPG is lossy raster 5

  6. Caching to Reduce Requests Cache all assets. If you got the CSS file before, why request it again? Work from the cached version Caching can be done at the browser, server, or Content Delivery Network level. HTTP headers can define periods of time for caching Fingerprinting Busting the cache is a problem. Browsers often hold onto cached assets EVEN on a clean refresh CDNs don t know when to update a file either Instead, the name of a file has its SHA-256 signature appended to the name That way if the content changes, the filename changes! 6

  7. Other Request Reductions Increase asynchronous features AJAX requests: using XmlHttpRequest WebSockets: bidirectional, real-time access to a server Single Page Applications Don t treat a website like a series of pages Treat it like a desktop application Highly interactive sites that progressively change without user interruption 7

  8. Performance of HTTP/2 The world has been using HTTP 1.1 for a long time, and HTTP/2 has been (slowly) rolling out Binary format instead of textual format More compact storage Fewer packets to go over TCP Response Multiplexing One request can lead to many responses over a constant stream No need to concatenate all resources into a single bundle Server pushes HTTP/2 enables embedding resources into a single push without doing it yourself Early Hints Instead of waiting for the browser to parse the big response, the server can send back a quick, small hint that new resources need to be downloaded. Good for third-party integrations (e.g. ads) Domain sharding Allow for putting resources on separate servers under the same host In HTTP 1.1, you d put your resources on different subdomains e.g. assets.company.com or images.company.com . 8

  9. Denial of Service & Web A denial of service vulnerability is any reproducible performance degradation that compromises the availability of the system e.g. resource exhaustion, deadlocks, infinite loops DoS attacks for the web Overwhelm TCP networking protocols e.g. SYN-flood Overwhelm HTTP networking protocols e.g. Slowloris Overwhelm RAM and HDD e.g. Compression Bombs see SWEN-331 Overwhelm DBMS e.g. triggering slow queries, exploiting DB indexes, exploiting sorting algorithms Note: DDOS vs. DoS A DoS is not necessarily distributed! Not everything is a flood! 9

  10. SYN Floods The TCP three-way handshake: Client to server: SYN Server to client: SYN-ACK Client to server: ACK What if an evil client sends SYN and walks away? what if thousands of computers do this at once? Memory fills up, processor fills up, server locks up Countermeasures Shrinking default timeouts Looking for floods of traffic 10

  11. Slowloris Basic idea: start a connection with the web server, then never finish it Keep sending headers every few seconds to keep the connection alive Once server closes the connection, start a new one If the server uses threads, you can overwhelm its thread pool Low bandwidth Only one Python script from one machine making periodic requests will lock up the server A non-ddos DoS Easy to fix with proper configuration, but See code: https://github.com/gkbrk/slowloris/blob/master/slowloris.py 11

  12. Web DoS: Slowloris Download a portable version of XAMPP. https://www.apachefriends.org/ Get the zip version so you don t have to install it https://sourceforge.net/projects/xampp/files/XAMPP%20 Windows/7.3.4/ Unzip it and run setup-xampp.bat (Should be no need to run as admin) Get a slowloris exploit: https://github.com/gkbrk/slowloris/ You can install via pip, or just copy-paste the Python script Now research and attempt the following fixes to slowloris Using mod_reqtimeout: https://www.acunetix.com/blog/articles/slow-http-dos- attacks-mitigate-apache-http-server/ Using another technique from your research 12

More Related Content