Analyzing FastestWebsiteEver

Checking https://github.com/diracdeltas/FastestWebsiteEver was on my TODO list. Let’s see some details in Wireshark and review some TCP/IP details.

Captura de pantalla 2017-09-30 a las 3.19.38.png

You can check http://packet.city/ if you want to avoid setting up the service yourself.

So you open Wireshark and you start capturing. Visit http://packet.city and you can use a Wireshark filter for the resolved IP for packet.city.

Captura de pantalla 2017-09-30 a las 2.11.30.png

The project states that it is “the greatest website to ever fit in a single TCP packet”.

Is it true? Let’see what it needs: I can see 9 packets and some details.

First 3 packets (handshake)

Captura de pantalla 2017-09-30 a las 3.03.49.png

Like any normal TCP connection we start with a 3-way handshake:

  • First, my laptop sends a SYN packet with an Initial Sequence Number which can be seen 0 in Wireshark but that’s actually a relative over a random. This is my laptop requesting proof that its message can get through.

Captura de pantalla 2017-09-30 a las 2.28.14.png

  • The server needs to send an ACK packet (to prove SYN received) and its own SYN (to prove it can reach the client). We can see it’s actually done in the same sent packet: SYN-ACK

Captura de pantalla 2017-09-30 a las 2.30.49.png

  • My laptop receives the SYN-ACK: as its an ACK it knows it can send a packet to the server and as its a SYN it knows that the server needs an ACK, so it sends such ACK.

Captura de pantalla 2017-09-30 a las 2.35.54

  • Once the server receives that ACK handshake has finished and the channel is considered feasible. However it might have been like, but this is the minimum to start trying to communicate.

Packet #4 (GET)

We’ve finished with the 3 first packets. The fourth one is the GET request.

Captura de pantalla 2017-09-30 a las 2.41.10

Captura de pantalla 2017-09-30 a las 2.48.50.png

Notice that Push flag is enabled (PSH) and also ACK as with any exchanged packet during the communication.

In HyperText Transport Protocol we can see the sent HTTP request:

Captura de pantalla 2017-09-30 a las 2.52.48

#5 and #6 packets

Captura de pantalla 2017-09-30 a las 3.04.41.png

Packet #5 is an ACK:

Captura de pantalla 2017-09-30 a las 3.00.10

Next packet is the HTTP GET response:

Captura de pantalla 2017-09-30 a las 3.02.55.png

I guess this is what the project describes as “send response immediately after TCP session init”

I think PSH is enabled because Nagle’s algorithm is disabled as the project describes too.

In Hypertext Transfer Protocol section we can see DEFLATE compression is being used, again exactly as described in README.

Captura de pantalla 2017-09-30 a las 3.13.12.png

See that Response is “200 k” instead of “200 OK”: 1 byte saved there.

Content encoded is 1163 bytes (1547 bytes decoded), far from needing fragmentation:

The maximum would be 1460 bytes for content and 40 bytes for IP and TCP headers.

In this case, the frame is 1292 bytes, TCP segment length is 1226 bytes and HTTP Content-Length is 1163 bytes, in detail:

ethernet_frame

  • Frame header (14 bytes): 7 bytes for preamble, 1 byte for SFD, 12 bytes for source and destination MACs and 2 bytes for packet type (IP) –> 22 bytes (14 ignoring preamble and SFD)

Captura de pantalla 2017-09-30 a las 9.49.08.png

  • IP header (20 bytes): 1 byte for ip.version (4), 1 byte for ip.dsfield, 2 bytes for ip.len (Length), 2 bytes for ip.id (ID), 1 byte for ip.flags (0x02, ip.flags.df (Don’t Fragment  )is set), 2 bytes for ip.frag_offset (Fragment Offset), 1 byte for ip.ttl (TTL), 1 byte for ip.proto (Protocol), 2 bytes for ip.checksum (Header checksum) and 8 bytes for ip.src and ip.dst.

TCP-Header.png

  • TCP header (32 bytes): 4 bytes for tcp.srcport and tcp.dstport, 4 bytes for tcp.seq (Sequence Number), 4 bytes for tcp.ack (Ack Number), 2 bytes for tcp.flags, 2 bytes for tcp.window_size_value, 2 bytes for tcp.checksum, 2 bytes for tcp.urgent_pointer, 12 bytes for tcp.options

Captura de pantalla 2017-09-30 a las 10.17.44.png

  • HTTP (1226 bytes): 15 bytes for “HTTP/1.1 200 k\n”, 21 bytes for http.content_length_header, 26 bytes for http.content_encoding_header, 1 byte of “\n” and 1163 bytes for Content (encoded)

About the HTTP response content, it’s easier seeing the source code in the browser, there you’ll see:

Captura de pantalla 2017-09-30 a las 3.16.04.png

 

Last 3 packets

Finally last 3 packets. Server resets the connection with RST packet. I guess they could use FIN but RST is quicker. More about FIN vs RST.

Captura de pantalla 2017-09-30 a las 3.21.41.png

That’s all 🙂

 

 

Advertisements

Published by

Ivan Mosquera Paulo

Software Engineer

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s