0

I am using WireShark and went to google.com. I got 23 TCP streams,23 TCP conversations, 23 handshakes right? I know that the TCP streams end with FIN Flag and that TCP segments are encapsulated in the ip protocol.

My question is what makes a TCP stream to start and to end? Why do we need 23 segments to download a simple website? Which parameters decide when to end and start a stream? Are these parameters related to the protocols above? (maybe they are related with downloading a stream is dedicated to download a pictures from a website)

Please help

Improve this question
2
  • You probably want to read about "HTTP Keep-alive". en.wikipedia.org/wiki/HTTP_persistent_connection
    – Ben Voigt
    Commented Nov 29, 2021 at 22:11
  • google.com is a poor example of a simple website. It looks simple, but there's a lot going on behind the scenes with Javascript/AJAX to provide the search, not to mention user tracking. Most modern websites that aren't simple handwritten HTML with no images are going to result in a lot TCP/IP activity. If you want a simpler protocol to play with, try Gemini.
    – LawrenceC
    Commented Nov 29, 2021 at 22:17

1 Answer 1

Reset to default
2

A TCP stream typically starts when a process calls the operating system's TCP/IP APIs to start a TCP connection. It starts with a "3-way handshake" (3 packets) and typically ends with a "4-way close" (4 packets), and there are usually at least 2 individual TCP segments (packets) in between (like a single-packet request and single-packet response), so typically at least 9 packets per stream.

It sounds like you captured 23 separate TCP streams (so at least 200 segments). That's actually a very small number for a modern website. Loading a typical news site like cnn.com usually involves several hundred HTTP requests across many dozens of TCP streams nowadays, just to load all the separate graphics, JavaScript files, CSS files, ads, trackers, et cetera. And each HTTP response is probably many segments long, so you probably captured thousands of segments.

Edited to add: Your packet count for loading google.com was probably so low because you were probably filtering for TCP, thinking everything would be done in HTTP/1.1 or HTTP/2, whereas Google prefers QUIC (HTTP/3) nowadays, which uses UDP instead of TCP. So if you loaded Google.com from Chrome or another browser that supports QUIC, the only TCP connections you saw were probably just requests to third-party ad servers or something.

Edit2: As for what causes a TCP stream to end, either side can close it nicely or reset it when they're done with it. In the case of HTTP over TCP, the browser might end its side of the stream when its last HTTP request has been sent, and the server might end its side of the stream when the last segment of its last HTTP response has been sent (e.g. when the last bytes of the last requested HTML file or image file or CSS file have been sent).

Improve this answer
2
  • So a TCP stream corresponds to something in the upper protocol, like a unique CSS file, picture or tracker? Is there a mapping relationship with the stream? Who or what decides the lenght of the stream?
    – ilich262
    Commented Nov 29, 2021 at 23:12
  • @ilich262 Each separate file/URL that must be fetched creates a separate HTTP request, but with HTTP/1.1 keepalives, and with the architecture of HTTP/2 and QUIC (HTTP/3), multiple HTTP requests to the same server can be handled in a single TCP stream or UDP flow. But even if all of the resources you need are all on the same server, your browser may still choose to open multiple concurrent connections to the server for performance reasons. The connection is as long as it needs to be to handle all the requests (and matching server responses) that the browser wants to accomplish on that stream.
    – Spiff
    Commented Nov 30, 2021 at 0:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .