My terminal emulator program telnets to 192.168.1.120:8 to send commands to an instrument, and it sends replies back that show up in the terminal window.
I think the instrument responds to these replies because they are in packets addressed to 192.168.1.120 and it knows packets that specify port 8 contain ASCII for commands to be followed. Right?
But when my computer sees packets addressed to 192.168.1.100, its own address, how does it know to write the corresponding letters in the terminal window? Is the instrument sending them to a specific port, perhaps port 23 for telnet?
The instrument happens to have its own web server with configuration pages, and I happen to have one of those open in IE while this is going on, and of course the instrument is sending some packets for this purpose too. Do they control the web page display because they are sent to port 80?
Even more complicated - my computer also has other IE windows open at the time. Supposing that they are filled with content that came in to 192.168.1.100:80, how does the content wind up in the correct IE window?
This is what the TCP in TCP/IP does. Each IP packet contains a segment of an overall TCP data stream which the application creates. Each of these segments is addressed with both a destination and source port, as well as a sequence number, and an acknowledgement number. The ports and sequence numbers are used to ensure that all of the segments can be reassembled in the right order (without any missing or duplicated).
The TCP algorithm is a little more complicated than that, but suffice to say, when TCP/IP data arrives, the TCP driver uses the port and sequence information to figure out which application stream it goes to, and where in the stream it belongs (TCP tries to be robust against mis-ordered segments). It can also request missing or corrupted segments be resent. This TCP stream is associated with an application process which either initiated the communication (like IE would do), or has been listening for incoming requests (like a web server would do).
You are thinking at too low a level about how the data is managed. There are a couple of extra layers between what you see from the vantage point of your user level programs and what is actually sent on the network.
Most programs need a reliable end to end connection, and this is provided by a intermediate protocol, in this case TCP - Transmission Control Protocol. It job is to initiate a connection, and manage that connection, ensuring that your program (in this case Telnet) sees a connection that does not drop data, and does not scramble the order of data. In doing so it establishes a virtual circuit, a middle layer of communuication between your computer and your instrument over which your communications flows. The raw data you type doesn’t simply get injected to a port on the other end, it is handled by TCP. The virtual circuit handles such mundane issues as the identity of the end points, sequencing of data, repeating lost packets, assembling packets together to create the transmitted data, and also handles setup and teardown of the sessions. The flowing packets contain such useful information as packet sequence numbers (to ensure ordering and used to trigger resending of lost packets) and also contain the originating address and port number of the packets. A circuit can be set-up on any port numbers. Part of the initial dialog between the ends can be to agree to move the virtual circuit for a particular connection to a pair of dynamically allocated ports. The standard port for Telnet (23) is where you go to initiate the conversation, not where the conversation ultimately takes place. Telnet’s internal protocol is sufficiently general, and useful that it turns out that you can use it to talk to many services. Thus it is possible to use a telnet client to connect to ports that offer services other than Telnet initiation, such as web servers on port 80, mail servers etc, and if you know the protocol and commands, carry on a conversation. Useful for debugging, and a long time ago, for spoofing mail.
Your web browser won’t be listening on port 80, that is where servers live, not browsers. Your browser will be listening on dynamically allocated ports for traffic addressed to them from servers that are on port 80 on their respective machines. These dynamically allocated ports will only be in use for the time needed to effect the web transaction needed.
As ed pointed out, there’s a source port involved as well as a destination port.
Destination ports are normally “well-known” port numbers in the range below 1024; for example, Web servers generally reside at port 80. But source ports are just picked more or less randomly; the instrument knows which port to send its return packets to because that information is present in the header of every packet which it receives.
Thanks - this is fascinating. Ed, I also peeked at the link, and want to look more closely later.
Am I asking questions about just ordinary “TCP”? There’s a “7 layer model” or something like that I have heard of - is that about this? I guess I’d like to know what topic to go look up, or buy a book about, if I wanted a better general appreciation of this.
The full 7 layer OSI model is a way of categorizing how various protocols relate to each other. There’s quite a lot of them, and most of them are obscure (I used to have this poster which was kind of fun - each of those nodes is a different protocol).
However, nearly everything today is probably TCP/IP over ethernet, which covers layers 2-4: ethernet, IP, and TCP. Depending on what you’re doing, there are other common protocols that run “on top of” these: SSL, HTTP, SSH, FTP, telnet, etc.
Generally though, in my experience most people start by learning about IP networks and routing concepts, and then TCP and reliable communication. From there, the “higher” protocols are (I think) easier to understand. HTTP, for example, is a fairly simple plain text based protocol that is made possible because TCP is there to provide a seamless channel for text data. All the pain of routing and segmenting is hidden in the lower layers.
If you’re adventurous, look into downloading Wireshark (it’s free), which can be used to capture “raw” data off your network connection, which you can then inspect. It does a pretty reasonable job breaking captured data into different protocols, so you can poke around and see how things work.
It makes a lot more sense to learn the TCP/IP model, which is four layers, but the whole concept of ‘layering’ can be misleading depending on what you’re looking at. It’s useful enough for the simple stuff we’re talking about, though.
The OSI model is a relic of technology that, by and large, never got off the ground. Don’t bother with it too much.
The one valuable idea in the OSI model is that each layer can simply assume the layer(s) beneath it “just work”. I can design an application layer component without the slightest interest in how the physical layer or IP layer works. Or even caring whether IP is even anywhere in the stack.
For a lot of historical reasons, in current networking technology the layers above & below IP mostly just work, at least for ordinary folks in ordinary situations. Whereas IP is the layer is where all the configuration challenges arise. So as a result, self taught IT folks (e.g. our noble OP) often think of IP as the whole networking shebang.
I’m not really IT folk. It is much more pitiable than this. I am a user, one who grew up hearing that computers were going to free us from detailed and repetitive work, and that you carefully tell the computer the computer exactly what you want it to do by writing a program ; this is how you use computers. I still have not unlearned this terrible thing.
Well, I’m IT at my house, I guess. At work I’m mostly just exta work for real IT folks. In fact, if they heard anybody had the idea that I actually WAS an IT sort, home grown or otherwise, they’d probably send out some kind of warning to “All”.
Seriously, the idea of making large numbers of Windows boxes do what large numbers of people think they are supposed to do gives me shivers.
About IP: I didn’t think IP was the whole shebang. I knew that TCP and ethernet and telnet and ftp and html were all parts of the whole shebang and imagined it contained others too. I thought it was a layered arrangement and thought maybe that OSI picture did describe the whole shebang, which is what my second posting was asking. Now I gather that the answer is sort of a “yes”, the 7 layer model does describe the whole shebang, or at least is supposed to, though in practice the four layer TCP/IP model is closer to the truth and is simpler. Is that about right?
All that being said, the wisdom I’m getting here is just the sort of thing I was looking for - thanks!
The OSI model persists in making distinctions without a difference. The biggest example of this is the distinction between the top two layers, Application and Presentation. I’ve never heard a cogent explanation of why there’s two layers there, or why networking software programmers (the ones the model is supposedly for) should care if there were twenty layers up above the highest networking layer.
Another example of distinction (largely) without a difference is in the bottom two, the Physical and the Link layers. This is actually really easy to explain: The Physical layer is the hardware that moves individual bits from one machine to another. Phone lines and radio waves (for Wi-Fi and cell phones) and so on and so forth. The Link layer is the very lowest-level protocol, the language used to ensure efficient communications within a LAN. Examples are Ethernet and PPP and Wi-Fi.
The problem with insisting that the Physical and Link layers are separate is that they’re really joined at the hip in 99% of cases. There’s nobody, but nobody, running the Wi-Fi Link layer protocol over Cat6e (Ethernet) cables. Similarly, nobody runs raw PPP over Cat6e: If they need PPP over Cat6e, they encapsulate it into Ethernet frames and run PPPoE (PPP over Ethernet). There is effectively no separation between the layers. It’s misleading to say there is.
My caveat is that the Internet design people (the IETF (Internet Engineering Task Force)) don’t like to think in layers all the time. In fact, they’ve even put out an RFC (standards document) that has a section called Layering Considered Harmful. So don’t take layers too much to heart, or you’ll get confused when you try to figure out where ARP fits and nobody deserves that.
But people run Ethernet over coax. (Not too common anymore, admittedly, but this was its original incarnation.) People run FibreChannel over copper twisted-pair.
The case of tunneled protocols is more complex, of course. Depending on your perspective, you could consider the emulated serial line provided by PPP to be the physical and link layers, or you could consider the tunneled protocol as a whole in which case the Ethernet network would be the link layer. Add a VPN or SSH tunnel and you’ve got layers within layers.
That’s kinda the whole point, though. The layered architecture ensures that a higher level protocol doesn’t have to know what’s on its adjacent levels, as long as the right interface is there.
