Argthtjtr

As far as I know as of 2018 some of the 65535 available ports has at least one of what's called a "port proto"; I know 2 such protocols; TCP and UDP, while TCP is the mainly used one.

If I'm not wrong these ports are part of the operating system and not motherboard of the computer ports and I ask myself, if for example, one installs Ubuntu-WSL on Windows 10, or even an entire OS on VirtualBox like a VirtualBox-Ubuntu, do the WSL or this Ubuntu has extra 65535 available ports of their own?

_{Notes: Some call these protocols "protos" in short (as in Ansible YAML syntax).}

You're on the right track - port in this sense does not mean a physical piece of hardware you plug something into - it's a name given to a certain part of the TCP and UDP networking protocols. To avoid confusion with hardware ports you can use the terms TCP port or UDP port (UDP has ports too).

Most of computer networking is about sharing a single communications medium. The original Ethernet networks were physically connected by a single wire, and wireless still works on a similar principle - all wireless devices on a certain channel have to share the same air.

But you also might want to have multiple programs use a communications medium as well. For example, you might want to run a web browser (HTTP port 80) and an email client at the same (SMTP port 25).

The notion of TCP or UDP ports allow multiple programs on a system to use the same medium.

• A program wanting to talk asks TCP to provide it a free port number




• A program wanting to receive connections tells TCP what port number it will use




• TCP breaks up communication into segments. It includes the port number with the segment.




• So you can then have multiple programs on the same system sending and receiving data and the port numbers is how it separates the data from the single stream sent over the wire or communications medium.




• Because of this you don't need a separate NIC for each program you want to talk over a network.

Ports are associated with processes, so they are a "per-system" resource. You can't have 2 processes listening or receiving on the same port at the same time - but you can have 2 processes with different source ports talking to the same destination port - which is a process that's listening on a given other port.

Proto being short for protocol is something specific to ufw, and other programs.

Network ports aren’t hardware, they’re just software labels to let the network stack direct network traffic to the appropriate application. Any operating system running its own network stack (and therefore with its own IP address) will have its own network ports, regardless of whether it’s running in a VM or not.

Ports (eg 1-65535) and protocols (including tcp, udp, icmp and some other obscure ones) are defined in Internet standards and implemented by the OS as a network stack. (In fact there can be multiple stacks, for example different stacks for ipv4 and ipv6)

In the case of multiple OS's / virtualization, it's possible for each OS to use it's own stack - as long as the stack has access to the underlying interface. +In the case if virtualise systems the VM need a virtual or actual interface - often a network card or virtual network card which is bridged or routed by the host software. In the case of a bridged interface the IP stack on the OS is ignored as bridging takes place at a lower level, while in the case if a routed config the packets are processed by the host as well)

A motherboard's ports are physical receptacles for physical cables for I/O.

A TCP or UDP port number is just an ID number that acts as a metaphorical receptacle that one of many flows of data packets can be sent to. Each process (app) on your system that wants to receive TCP packets from the network has to request use of a port number from the OS, and from then on if the OS receives a packet addressed to that port number, it passes that packet data along to the process that owns that port number.

Networking is designed as a stack of independent layers, which a different protocol for each layer. Each layer's protocol puts its own header on the front of each packet, and each layer's header has some kind of numeric ID field (often 16-bit unsigned integers) that lets the receiving end know what the next-layer protocol is, so that the packets can be passed to the right code to handle that next protocol.

Traditional "Ethernet-II" style Ethernet headers have an "EtherType" field that says what the next protocol is. EtherType 0x0800 means this Ethernet frame contains an IP datagram.

IP headers have a "Protocol" field that says what transport-layer protocol needs to handle the contents of this IP datagram. A value of 6 means TCP, and a value of 17 means UDP.

TCP and UDP happen to both use the same model of port numbers. They both have a UInt16 source port and UInt16 destination port. TCP and UDP port numbers are flexible and can be mapped to different protocols. But there are some strong conventions, so traffic to or from TCP port 80 is highly likely to be HTTP (or some other protocol trying to disguise itself as HTTP to try to get through proxies and firewalls).

I think you must have had some exposure to some software that conflates IP protocol numbers with TCP/UDP port numbers. Although IP protocol numbers serve a similar purpose at the IP layer as TCP/UDP port numbers serve at the transport layer, they are still separate concepts at different layers and should not be conflated.