2

There's something I don't understand about TCP/IP stack : ports. There's an IP to identify a machine and port for a specific process on that machine. For me ports have to do with application layer ; there are some ports for some process (80 for HTTP, 25 for SMTP etc...). Ports have nothing to do with TCP layer (transport). Ports should be implemented at a higher level (application layer). So why do you say "TCP port" and not "application port" ?

Thanks

AntonBoarf
  • 1,239
  • 15
  • 31
  • Because FTP , SSH, POP, SMTP, HTTP are not 'applications' – Kahn Kah Oct 12 '18 at 08:52
  • Yeah there are not applications but protocols that are part of "application layer". So ports should be part of this "application layer" and not the layer below ("transport layer" like TCP, UDP) – AntonBoarf Oct 12 '18 at 08:54
  • The OSI model does not apply to TCP/IP, which has its own, prior model. The OSI model only applies to the defunct OSI protocol suite. – user207421 Feb 07 '19 at 23:27
  • @AntonBoarf You are mistaken. Ports are an ineradicable part of TCP and UDP. The rest of your comment is a complete *non sequitur.* Both are transport layer protocols. The fact that application protocols use them doesn't change that. – user207421 Apr 13 '20 at 03:10

1 Answers1

5

TCP or UDP ports are defined in either layer 4 of the OSI model or layer 3 of the TCP/IP model, both are defined as the 'transport' layer.

OSI layer 5 'session layer' uses the ports defined in layer 4 to create sockets and sessions between communicating devices/programs/etc.

Reminder about OSI model:

It is a conceptual model. That means it describes an idealized, abstract, theoretical group of networking functions. It does not describe anything that someone actually built (at least nothing that is in use today).

It is not the only model. There are other models, most notably the TCP/IP protocol suite (RFC-1122 and RFC-1123), which is much closer to what is currently in use.

The most important things to understand about the OSI (or any other) model are:

  • We can divide up the protocols into layers
  • Layers provide encapsulation
  • Layers provide abstraction
  • Layers decouple functions from others

Dividing the protocols into layers allows us to talk about their different aspects separately. It makes the protocols easier to understand and easier to troubleshoot. We can isolate specific functions easily, and group them with similar functions of other protocols.

Each “function” (broadly speaking) encapsulates the layer(s) above it. The network layer encapsulates the layers above it. The data link layer encapsulates the network layer, and so on.

Layers abstract the layers below it. Your web browser doesn’t need to know whether you’re using TCP/IP or something else at at the network layer (as if there were something else). To your browser, the lower layers just provide a stream of data. How that stream manages to show up is hidden from the browser. TCP/IP doesn’t know (or care) if you’re using Ethernet, a cable modem, a T1 line, or satellite. It just processes packets. Imagine how hard it would be to design an application that would have to deal with all of that. The layers abstract lower layers so software design and operation becomes much simpler.

Kahn Kah
  • 1,389
  • 7
  • 24
  • 49
  • In fact the OSI model was specifically designed only to describe the defunct OSI protocol suite. It was never intended to model the whole world of networking, and it is most unfortunate that the tertiary education sector has never caught on either that or to its rather speedy demise. – user207421 Apr 13 '20 at 03:12