Zellio.io

Network Protocol Simulator

Watch a DNS lookup, a TCP handshake, a TLS handshake and a page load, packet by packet.

Processed locally — nothing is uploaded

About Network Protocol Simulator

A simulation, not a measurement: a web page cannot open a raw socket or send a SYN, so the packets here are assembled from the specifications and the timings from the latency you type. What it is faithful about is structure — which flag is set, how sequence numbers advance, who speaks next, and where each round trip goes.

Four exchanges are modelled here, and they are the four that stand between typing an address and seeing a page. A name is turned into an address by walking a hierarchy of servers that each know only who to ask next. A connection is opened with three packets whose numbers matter more than their contents. Keys are agreed in public by two parties who have never met. Then, and only then, does anything resembling a request happen. Each one runs as a sequence of steps you click through, with the packet laid out field by field and a note beside the two or three details that are easy to get wrong.

Latency is the knob that teaches the most. Set the round-trip time to forty milliseconds and the handshake looks trivial; set it to four hundred, which is an ordinary satellite link or a bad mobile connection, and the same sequence becomes most of the page load. That is the actual argument for connection reuse, for keeping third-party domains few, and for the newer protocol version: each of them removes a round trip, and a round trip costs whatever your users' network says it costs rather than whatever your office says.

The transport-layer security exchange has a switch between the two versions still in use, and it is the clearest demonstration on the page. Version 1.3 lets the client guess the key agreement up front, so the exchange finishes in one round trip and the certificate arrives already encrypted. Version 1.2 cannot begin the agreement until the server has spoken, which costs a second round trip on every new connection and puts the certificate, and therefore the identity of the site being visited, in the clear. Flip the switch on the lifecycle view and watch the total move.

The sequence-number arithmetic in the connection simulation is worth a minute of anyone's attention. Numbers count bytes rather than packets, the flags that open and close a connection each consume one even though they carry no data, and an acknowledgement names the next byte expected rather than the last one received. Those three facts explain nearly every confusing capture a person meets early on, including why closing takes four packets when opening took three, and why a socket sits in a waiting state for a minute after everything appears to be finished.

What this cannot do is measure anything. There is no raw socket in a browser, no way to send a packet with chosen flags, and no interface for reading a reply that is not an ordinary HTTP response — those are deliberate limits of the platform, not an omission here. So every number on the page is arithmetic on the values you supply. For real timings use the tools built for it: the browser's own network panel, or a capture tool on a machine you control. Use this to understand what those tools are showing you.

Learn how this works

Understanding Your IP Address & Network BasicsWhat your public IP reveals, how to check it, and what latency means — explained simply, with a free in-browser network tester.6 min read

Frequently asked questions

Are any real packets sent?

None. A web page has no way to open a raw socket, craft a segment with particular flags, or read a reply outside the ordinary request mechanisms — so nothing here touches a network. The addresses are from the ranges reserved for documentation and the host name is a reserved example name, which means even the values on screen point at nobody.

Then how accurate is it?

Accurate about structure, arithmetic about time. The fields, flags, order of messages and state transitions follow the specifications, and the sequence-number arithmetic is computed rather than typed, so it stays consistent when you change the payload sizes. The durations are derived from the latency you enter with a simple model of transfer, which is right for comparing one arrangement against another and wrong for predicting a specific number on a specific network.

Why does closing a connection take four packets?

Because each direction is closed independently. A finish flag says this end has no more to send; it says nothing about receiving, and the other end may keep sending for as long as it likes. So each side sends its own and acknowledges the other's. The half-closed state in between is legitimate, and an application that stops reading as soon as it closes is the usual reason a response arrives truncated.

What is the waiting state at the end for?

Whichever side closes first holds the connection's four-tuple for roughly twice the maximum time a packet can survive in the network. It is there so a straggler from the finished connection cannot arrive at a new one that happens to reuse the same addresses and ports. Thousands of sockets in that state on a busy server is normal, and it is one of the more commonly misdiagnosed graphs in operations.

Does it send anything to a server?

No. Everything runs locally in your browser using standard web APIs — your text, files and inputs are never uploaded to a server, so the tool works even offline once the page has loaded.

Is it free?

Completely. There is no sign-up, no account, no watermark and no usage limit. The tool is supported by unobtrusive ads, not by selling or processing your data.

Pro Tips

  • →Put your real round-trip time in before drawing conclusions: ping a server you use from the network your users are on, and type that number rather than the default.
  • →Switch the security version to the older one on the lifecycle view to see exactly what an out-of-date server configuration costs on every new connection.
  • →Compare the lookup with a warm cache against the cold walk from the root; the gap is why a page that touches six domains can be slow for reasons no profiler attributes to your code.
  • →Follow the byte arithmetic once with a payload size of your own, then look at a real capture. The columns stop being noise once the counting makes sense.
  • →Use the request lifecycle to argue for connection reuse: the repeat request at the end pays none of the setup, and that comparison lands better than a percentage.

Common Use Cases

  • •Teaching someone why a page load is slow in a way that survives their first look at a network panel.
  • •Settling an argument about whether the server or the network is responsible for time to first byte.
  • •Preparing a diagram or a slide with the fields and flags in the right order.
  • •Revising the handshakes before an interview, a certification, or a design review.
  • •Explaining to a stakeholder what a round trip is, and why removing one matters more than it sounds.

How It Compares

A packet capture tool shows you what genuinely happened on a machine you control, which is the right instrument for a real problem and a poor one for learning, since it presents everything at once with no commentary. Diagrams in articles are legible and static: they cannot show you what changes when the latency triples or the protocol version drops. The specifications are complete and unreadable at first meeting. This sits between the three, and is honest that it measures nothing.

Related tools

What Is My IP & Network TesterYour public IP, location, ISP, AS number and connection profile.Subnet CalculatorCalculate network, broadcast, host range and split any CIDR block.MAC Address AnalyzerIdentify the vendor and decode any MAC address — OUI, cast and UAA/LAA.URL Parser & Query InspectorBreak any URL into its parts and inspect every query parameter.