Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.
Sign up to join this community
If we have a common protocol port on both ends.. say source point is 443 and destination port is 80 (hypothetical situation, I know this combination of ports probably makes no sense).. how do we determine the protocol of the packet in its entirety?
Just like wireshark tells us the protocol, how would we determine the protocol of the packet? Do we use the source or destination port for this?
You seem to have it backwards. Some transport protocols, e.g. TCP and UDP, use addresses that are better knows as ports. Other transport protocols use other or no addressing. Both TCP and UDP use the same number range for their ports, but they are not the same ports. For example, TCP port 12345 is not UDP port 12345. You cannot, given only a port number, know which protocol is meant.
The Protocol number field in the IPv4 packet header, or the Next Header field for the IPv6 packet header (same as the IPv4 Protocol number), will tell you which protocol is being used, and it may be a protocol other than TCP or UDP. IANA maintains the Protocol Numbers page that explains which protocol number is which protocol.
Look at this from a perspective of the layers in the network stack. Each lower layer encapsulates the datagram of the higher layer as the payload of its datagram. There will be a field in the header of the protocol at a layer that tells it to which process it should send its payload.
Data-Link Layer:
For example, ethernet can carry many different protocols as a payload, and it doesn't know or care about the protocols, so how does it give the IPv4 packet in the payload to the IPv4 process and not the IPX, IPv6, etc. process? The ethernet header has the Ether Type field and if the field contains 0x0800, then it sends the frame payload to the process registered for that number (IPv4), or if the number is 0x86DD, then it sends the frame payload to the process for that number (IPv6). IANA maintains the IEEE 802 Numbers with the Ether Type for the IEEE protocols (ethernet, Wi-Fi, token ring, etc.).
Network Layer:
As I explained in the first part of the answer, IPv4 and IPv6 use the protocol numbers maintained by IANA to determine the process to which they should send the packet payload.
Transport Layer:
TCP and UDP use addressing commonly called ports. Applications register with TCP or UDP for a port number for the protocol (TCP or UDP) that the application wants to use. Any UDP datagram or TCP segment coming in will have the destination port number to which the protocol will look to see which process has registered with it for that port number, and it will pass the payload to that process, or drop it if no process is registered for that port number.
There are services that have registered with IANA (see Service Name and Transport Protocol Port Number Registry for well-known port numbers. Unfortunately, that does not keep an application from using a port number that is well-known for a service to be used as a different service if the port has not been claimed. For example, a web server normally registers with TCP for port 80 for HTTP and port 443 for HTTPS. If a host is not running a web server that has registered those ports, any application is free to request use of those ports. Sometimes people will register SSH with port 80 because a firewall has blocked port 22 (well-known port for SSH), but the firewall allows port 80 traffic. Some people, for various reasons, will set up a web server on a different port than the well-known HTTP port. That forces anyone trying to browse that web server to explicitly enumerate the port number in a URI.
+1 to Ron’s answer. “Protocol” has a very precise meaning to network engineers because that’s a specific field in the TCP/IP network stack.
More generally, software engineers refer to a “protocol” as a set of rules for communication.
Usually, the destination port in the direction the socket was initiated, in combination with the IP protocol (tcp or udp), determines how the data is interpreted (there are 256 protocol numbers, tcp and udp are two of the most common and have the “port” concept).
So if a tcp socket had source port 443 and destination port 80, interpreting the data as http would be most likely to be successful.
Of course, the response traffic would be source port 80 and destination port 443. But I said “direction the socket was initiated”.
As Ron said, there is nothing preventing a process from listening to tcp/80 and interpreting incoming data as DNS or NFS or whatever.
