The TCP Handshake Process

Last Updated on December 22, 2015

Internet traffic starts with a basic tuple: protocol, host and port. The browser provides three functions, render, computation and IO (a messaging layer that allows these origins to communicate.) Through IO layer, the browser then tries to resolve the requested resources.

Render API includes: HTML, CSS, MathML, ARIA, WebGL, <video>, <canvas>, and images (jpg, png, gif.)

IO API: XHR, DOM Storage, IndexedDB, Cookies, FileReader, Browser Cache, App Cache

Once a connection is made, the TCP Slow-Start process begins, wherein the server sends bytes in a very small amount to make sure it is getting a response.

  1. DNS lookup, finds server – approx. 200ms
  2. Ask server for file. Server acknowledges – approx. 200ms
  3. TCP Slow-Start begins, you ask server for 4 packets it responds accordingly
  4. Next you request 8 packets, if all is well, it sends them.
  5. This ramping up process repeats increasing the size of the data chunks sent – the increments of data size are as follows: 5.7kb, 11.4kb, 22.8kb, 45.6kb, 85kb
  6. A fast connection will take about 800ms to complete up to this point, plus the DNS lookup and initial handshake, we’re looking at 1200ms.

Most of the HTTP data flows consist of small bursty data transfers whereas TCP is optimized for long lived connections and bulk data transfers. Network roundtrip time is limiting factor in TCP throughput and performance in most cases. Consequently, latency is is the performance bottleneck for HTTP and most of the web.
High Performance Browser Networking: What Every Web Developer Should Know

Test your website