Introduction to Protocols

The NIC is where network communication (all those 1s and 0s) physically enters and exits a machine (network interface card). However, theoretically, network communication enters and exits a system through a software or service. A service is a software that runs in the background and performs one or more system operations without requiring a login.

For example, the Workstation service on Windows client PCs operates in the background and allows access to external network resources.

It is not linked to a particular user login and runs in the background at all times. When you start a Web server, for example, you’re launching a single server service that’s not connected to a certain user login. (In Linux, services are referred to as daemons.)

How does network communication enter and exit a software or service, then?

Assume that a single computer is hosting both a File Transfer Protocol (FTP) server and a Web server, such as FileZilla. How does traffic for the FTP server get to the FTP server and traffic for the Web server get to the Web server if they both have the same IP address?

Consider an apartment building with a mail sorting system in the foyer. Frank Thomas Peterson, the guy in Apartment 21, checks his mail with a key to box 21, while Helen Theresa Thomasina Parker, the lady in Apartment 80, checks her mail with a key to box 80. The mailman delivers both people’s mail to the same building, with the same street address, but divides it depending on the box number indicated on the envelope to ensure that it reaches the intended recipient.

This is similar to having two separate servers with the same IP address. When mail is sent to the guy in Apartment 21, however, it is indicated on the face of the envelope, as is mail addressed to the woman in Apartment 80. Similarly, a port, which is a logical number that represents an endpoint in communication, is used to enter and exit a programme or service.

Getting mail to the apartment complex is similar to getting network traffic to a single computer that runs FileZilla and Apache. Both servers have the same IP address, but they receive and deliver traffic over separate ports. A port is a logical number that represents a communication endpoint. FileZilla uses port 21 as an FTP server, whereas Apache uses port 80 as a Web server.

These logical ports are not to be confused with the physical ports into which we insert connections.

There are source and destination ports in addition to source and destination MAC addresses and source and destination IP addresses. IP addresses can be discovered in Layer 3 transmissions. At Layer 4, port numbers can be found in TCP segments or UDP datagrams.

The destination computer understands which application or service to deliver the data to based on the destination port, just like the mailman knows to place mail for Apartment 21 in the mail box for Apartment 21, and mail for Apartment 80 in the mail box for Apartment 80.

Ports of various types

Ports are classified into three groups:

Ports of Interest

Major protocols and services utilise ports ranging from 0 (which is not used) through 1023. DNS (Domain Name System) servers, for example, listen and transmit on port 53, whereas DHCP (Domain Name Configuration Protocol) servers listen and send on port 67.

Data is delivered to the correct machine via an IP address. The data is routed to the appropriate programme on the computer using a port number.

Ports that have been registered

The Internet Assigned Numbers Authority (IANA) assigns ports from 1024 to 49151 to particular firms who want to utilise a common port for their applications or protocols. If not in use, these ports can be utilised by any system. Ports (including registered ports) are important to a system on a local level. It’s not the same as using a registered IP address, which has a worldwide reach.

Ports that are constantly changing

Client programmes access ports 49152 to 65535 on a need-to-know basis. For instance, your browser could open port 60000 to send a request to a Web server, which will be listening for requests on either port 80, which is unencrypted HTTP, or port 443, which is HTTPS encrypted using Secure Sockets Layer/Transport Layer Security (SSL/TLS).

The Web server’s answer is obtained from port 80 and is destined for the port that your browser opens without encryption. Your browser closes the port it opened when the conversation between your browser and the Web server is complete, but the Web server’s port remains open for future incoming connections. For traffic to and from the same Web site or a different Web site, your browser will open a different port number in that dynamic range.

Commonly Used Ports

The following are the CompTIA Network+ ports that are listed in the objectives.

At https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml, IANA keeps track of port numbers.

Types of Protocol

Each of the protocols discussed before is encapsulated within a Layer 4 protocol, either a TCP segment or a UDP datagram. IP packets contain TCP segments and UDP datagrams at all times. ICMP (Internet Control Message Protocol) messages are also included in IP packets for informative and error reporting purposes.

TCP and UDP are two different protocols.

To encapsulate and transfer data from Layers 5, 6, and 7, all programmes utilise TCP segments or UDP datagrams at Layer 4 of the OSI architecture.

TCP provides a link between the source and destination devices for reliable data transmission and flow control, transmitting data at a pace that is acceptable to both. UDP is a connectionless protocol that does not provide for flow control.

TCP sends all data in a certain order and sequence. TCP ensures that each and every byte transmitted is received in perfect condition and processed in the right sequence. So, in reality, there are three things that are certain in life: death, taxes, and…TCP. UDP does not provide such a guarantee.

TCP segments are acknowledged, letting the sender know that the traffic was received. TCP resends the unacknowledged bytes if an acknowledgement, explicitly identifying byte numbers of the data transmitted, is not received. This is not something that UDP does.

File transfers (FTP), e-mail (IMAP/SMTP), and accessing Web sites (HTTP, SSL/TLS) all require TCP. Accuracy is crucial in these situations. The whole message might be lost or damaged if bytes are lost or corrupted.

For real-time communications, conferencing, and streaming, UDP is utilised. UDP is also used by two key network protocols, DNS and DHCP.

If every byte delivered on a VoIP conversation via the Internet had to be recognised, there may be issues with missing messages or even acknowledgements. TCP on the source would assume the message was not received by the destination and would resent it. As a result, when the destination hears “Hello,” it responds to the source. Let’s pretend the acknowledgement was misplaced. The destination would hear the source’s subsequent remarks from the voice call, “How are you doing today?” but the source would respond with “Hello” once more. That would be a really aggravating phone call! You’d be bringing the past back into the present discourse!

As you might expect, all music and video transmitted in real time and streaming over the Internet in UDP datagrams must still be organised in order to be processed correctly. UDP’s ordering is handled via the Real-Time Streaming Protocol (RTSP), which is implemented at Layer 7.

Using RTSP just for the ordering of UDP datagrams has a much lower overhead than using TCP. If TCP is utilised, a connection must be created and maintained, flow control must be implemented, and acknowledgements must be delivered. Due to these and other circumstances, communication would be slowed. We don’t care if bytes are lost using UDP. They’re simply a blip on the screen. It’s possible that we won’t even notice. We may perceive a little reduction in image or sound quality, but rather than slowing down the entire connection to compensate for the additional cost that TCP demands, we simply accept it.

TCP has a lot more overhead than UDP and is designed to be slower in order to achieve greater accuracy and integrity. UDP has no overhead and is faster, with an emphasis on efficiency.

The TCP header has numerous fields with latency-adding functions, but the UDP header simply has a few fields with no extra cost.

The source and destination ports are the first two elements of the TCP header, identifying the application or service from which the message originated and to which it is being sent on the destination. The Sequence Number and Acknowledgement Number fields come next.

We need to look at the flags section following the Data Offset field, which represents the size of the TCP header, and the Reserved field, which is just three 0 bits, to see how these fields are used. The TCP header contains flags that indicate particular control information delivered to and from the linked computers. These flags could be raised or lowered, just like a mailbox flag. TCP flags, on the other hand, are not red. A single bit is used to represent them. Setting a flag to a value of 1 is the same as turning it on. Setting a bit to a value of 0 indicates turning a flag off. The TCP header has nine flags (six standard ones and three specialty ones).

The source (client) turns on the SYN (Synchronization) flag by inserting a 1 in that bit location, and creates a pseudo-random sequence number that it inserts in the Sequence Number field in the first phase of the three-way handshake. For this example, let’s suppose it’s 9. The source encapsulates the TCP header in an IP packet, encapsulates the packet in a frame, and transmits the frame to the default gateway, presuming remote communication.

Starting a connection-oriented session

Step two of the TCP three-way handshake occurs when the TCP segment arrives at the destination, with the destination (server) replying “Roger that!” by sending its own TCP header. The destination then activates the ACK (Acknowledgment) flag and increments the sequence number transmitted by the source by one in the Acknowledgement Number field in step two. Because the initial sequence number of the source is 9, the destination enters 10 (9 + 1) in the Acknowledgement Number field. Both the sequence number and the acknowledgment number are 4-byte values in reality.

The destination also raises the SYN flag and generates its own pseudo-randomly generated sequence number, say 2017, which it inserts in the Sequence Number field in the same TCP packet. “Can I talk to you as well?” says the destination. The source receives this TCP segment.

In step three, the source replies by sending another TCP segment with the ACK flag enabled, increasing the sequence number transmitted by the destination by one in the Acknowledgement Number field to 2018, in our example.

The two systems are now linked together. There was no data in the TCP segments in the first three stages. The TCP header included just control messages. Actual data is now wrapped inside TCP headers by either station, whether it’s HTTP, SSL/TLS, SSH, FTP, or anything else. In reality, the acknowledgements now increase the number of the last byte transmitted by one, and the sequence numbers now move up by the amount of the data sent. Every item of information transmitted is recognised. If not, it will be resent. That’s how TCP delivers on its promise of assured data delivery!

If your client receives no response from your DNS server when attempting to resolve a name to an IP address or from your DHCP server when attempting to get or renew an IP address lease, your client will simply ask again. There’s no reason to spend more money on overhead.

There are just four fields in the UDP header: Source Port, Destination Port, Length, and Checksum (for error checking).

IP

At Layer 3, the Internet Protocol wraps all communications in a packet. The IP addresses in the IP header part of the packet are used to deliver packets from source to destination. The upper-layer headers and data are included in the data section.

The IP header has a lot of data, some of which we’ll look at in a later domain.

To send control information to IP, tools like ping and tracert (on Windows)/traceroute (on non-Windows) employ the ICMP Internet Control Message Protocol. Ping delivers ICMP echo request packets to a specified location. If the destination receives such messages, it responds to the source with ICMP echo reply messages. This indicates that the source can communicate with the destination. If no ICMP echo answers are received, it implies that either the source cannot reach the destination or the destination’s replies cannot reach the source.

Informational messages, such as ICMP echo reply messages, are wrapped directly inside IP headers, whereas error messages, such as destination unreachable messages, are created for a variety of reasons (for example, when the router does not have a route for the target network).

Every ICMP header begins with the same three fields—Type, Code, and Checksum—and then varies depending on the circumstances.