Sign In
Sign In

Network Protocols: What They Are and How They Work

Network Protocols: What They Are and How They Work
Hostman Team
Technical writer
Infrastructure

A network protocol is a set of rules and agreements used to facilitate communication between devices at a specific network layer. Protocols define and regulate how information is exchanged between participants in computer networks. Many protocols are involved in network operation. For example, loading a webpage in a browser is the result of a process governed by several protocols:

  • HTTP: The browser forms a request to the server.
  • DNS: The browser resolves the domain name to an IP address.
  • TCP: A connection is established, and data integrity is ensured.
  • IP: Network addressing is performed.
  • Ethernet: Physical data transmission occurs between devices on the network.

These numerous protocols can be categorized according to the network layers they operate on. The most common network models are the OSI and TCP/IP models. In this article, we will explain these models and describe the most widely used protocols.

Key Terminology

This section introduces essential network-related terms needed for understanding the rest of the article.

Network. A network is a collection of digital devices and systems that are connected to each other (physically or logically) and exchange data. Network elements may include servers, computers, phones, routers, even a smart Wi-Fi-enabled lightbulb—and the list goes on. The size of a network can vary significantly—even two devices connected by a cable form a network. Data transmitted over a network is packaged into packets, which are special blocks of data. Protocols define the rules for creating and handling these packets.

Some communication systems, such as point-to-point telecommunications, do not support packet-based transmission and instead transmit data as a continuous bit stream. Packet-based transmission enables more efficient traffic distribution among network participants.

Network Node. A node is any device that is part of a computer network. Nodes are typically divided into two types:

  • End Nodes. These are devices that send and/or receive data. Simply put, these are sources or destinations of information.
  • Intermediate Nodes. These nodes connect end nodes together.

For example, a smartphone sends a request to a server via Wi-Fi. The smartphone and server are end nodes, while the Wi-Fi router is an intermediate node. Depending on node placement and quantity, a network may be classified as:

  • Global Network. A network that spans the entire globe. The most well-known example is the Internet.
  • Local Network (LAN). A network covering a limited area. For example, your home Wi-Fi connects your phone, computer, and laptop into a local network. The router (an intermediate node) acts as a bridge to the global network. An exception to geographic classification is networks of space-based systems, such as satellites or orbital stations.
  • Distributed Network. A network with geographically distributed nodes.

Network Medium. This refers to the environment in which data transmission occurs. The medium can be cables, wires, air, or optical fiber. If copper wire is used, data is transmitted via electricity; with fiber optics, data is transmitted via light pulses. If no cables are used and data is transmitted wirelessly, radio waves are used.

OSI Model

In the early days of computer networks, no universal model existed to standardize network operation and design. Each company implemented its own approach, often incompatible with others.

This fragmented landscape became problematic—networks, which were supposed to connect computers, instead created barriers due to incompatible architectures. In 1977, the International Organization for Standardization (ISO) took on the task of solving this issue. After seven years of research, the OSI model was introduced in 1984.

OSI stands for Open Systems Interconnection, meaning systems that use publicly available specifications to allow interoperability, regardless of their architecture. (This "openness" should not be confused with Open Source.)

The model consists of seven network layers, each responsible for specific tasks. Let’s look at each:

1. Physical Layer

This layer deals with the physical aspects of data transmission, including transmission methods, medium characteristics, and signal modulation.

2. Data Link Layer

The data link layer operates within a local network. It frames the raw bit stream from the physical layer into recognizable data units (frames), determines start and end points, handles addressing within a local network, detects errors, and ensures data integrity. Standard protocols are Ethernet and PPP.

3. Network Layer

This layer handles communication between different networks. It builds larger networks from smaller subnets and provides global addressing and routing, selecting the optimal path. For example, the IP protocol, which gives each device a unique address, operates at this layer. Key protocols are IP and ICMP.

4. Transport Layer

The transport layer ensures end-to-end communication between processes on different computers. It directs data to the appropriate application using ports. Protocols such as:

  • UDP — Unreliable transmission of datagrams.
  • TCP — Reliable byte-stream transmission.

5. Session Layer

This layer manages communication sessions: establishing, maintaining, and terminating connections, as well as synchronizing data.

6. Presentation Layer

Responsible for translating data formats into forms understandable to both sender and receiver. Examples: text encoding (ASCII, UTF-8), file formats (JPEG, PNG, GIF), encryption and decryption.

7. Application Layer

The user-facing layer where applications operate. Examples include web browsers using HTTP, email clients, and video/audio communication apps.

Some OSI protocols span more than one layer. For instance, Ethernet covers both the physical and data link layers.

When data is sent from one node to another, it passes through each OSI layer from top to bottom. Each layer processes and encapsulates the data before passing it to the next lower layer. This process is called encapsulation.

On the receiving end, the process is reversed: each layer decapsulates and processes the data, from bottom to top, until it reaches the application. This is called decapsulation.

While the OSI model is not used in practical network implementations today, it remains highly valuable for educational purposes, as many network architectures share similar principles.

TCP/IP

While the OSI model was being developed and debated over, others were implementing practical solutions. The most widely adopted was the TCP/IP stack, also known as the DoD model.

According to RFC 1122, the TCP/IP model has four layers:

  1. Application Layer
  2. Transport Layer
  3. Internet Layer (sometimes just called "Network")
  4. Link Layer (also called Network Access or Interface Layer)

Though different in structure, TCP/IP follows the same fundamental principles as OSI. For example:

  • The OSI session, presentation, and application layers are merged into a single application layer in TCP/IP.
  • The OSI physical and data link layers are merged into the link layer in TCP/IP.

Since terminology may vary across sources, we will clarify which model we are referring to throughout this article.

Let’s take a closer look at each layer and the protocols involved, starting from the bottom.

Data Link Layer in TCP/IP

As mentioned earlier, the Data Link Layer in the TCP/IP model combines two layers from the OSI model: the Data Link and Physical layers. The most widely used data link protocol in TCP/IP is Ethernet, so we’ll focus on that.

Ethernet

Let’s forget about IP addresses and network models for a moment. Imagine a local network consisting of 4 computers and a switch. We'll ignore the switch itself; in our example, it's simply a device that connects the computers into a single local network.

40509b52 7906 4baa 8c97 58e17a7b9851

Each computer has its own MAC address. In our simplified example, a MAC address consists of 3 numbers, which is not accurate in reality.

MAC Address

In reality, a MAC address is 48 bits long. It’s a unique identifier assigned to a network device. If two devices have the same MAC address, it can cause network issues.

The first 24 bits of a MAC address are assigned by the IEEE — an organization responsible for developing electronics and telecommunications standards. The device manufacturer assigns the remaining 24 bits.

Now, back to our local network. If one computer wants to send data to another, it needs the recipient's MAC address.

Data in Ethernet networks is transmitted in the form of Ethernet frames. Ethernet is a relatively old protocol, developed in 1973, and has gone through several upgrades and format changes over time.

Here are the components of an Ethernet frame:

  • Preamble indicates the beginning of a frame.
  • Destination MAC address is the recipient’s address.
  • Source MAC address is the sender’s address.
  • Type/Length indicates the network protocol being used, such as IPv4 or IPv6.
  • SNAP/LLC and Data are the payload. Ethernet frames have a minimum size requirement to prevent collisions.
  • FCS (Frame Check Sequence) is a checksum used to detect transmission errors.

ARP

So far, we’ve talked about a simple local network where all nodes share the same data link environment. That’s why this is called the data link layer. However, MAC addressing alone is not enough for modern TCP/IP networks. It works closely with IP addressing, which belongs to the network layer.

We’ll go into more detail on IP in the network layer section. For now, let’s look at how IP addresses interact with MAC addresses. Let’s assign an IP address to each computer:

A2d608a0 062b 43aa A4a3 Fece0cf37348

In everyday life, we rarely interact with MAC addresses directly — computers do that. Instead, we use IP addresses or domain names. The ARP (Address Resolution Protocol) helps map an IP address to its corresponding MAC address.

When a computer wants to send data but doesn’t know the recipient’s MAC address, it broadcasts a message like: "Computer with IP 1.1.1.2, please send your MAC address to the computer with MAC:333."

If a computer with that IP exists on the network, it replies: "1.1.1.2 — that’s me, my MAC is 111."

So far, we've worked within a single network. Now, let’s expand to multiple subnets.

Network Layer Protocols in TCP/IP

Now we add a router to our local network and connect it to another subnet.

4b9809c6 Bba0 495b A601 A76596f596f9

Two networks are connected via the router. This device acts as an intermediate node, allowing communication between different data link environments. In simple terms, it allows a computer from one subnet to send data to a computer in another subnet.

How does a device know it’s sending data outside its own subnet?

Every network has a parameter called a subnet mask. By applying this mask to a node’s IP address, the device can determine the subnet address. This is done using a bitwise AND operation.

You can check the subnet mask in Windows using the ipconfig command: 

Image1

In this example, the mask is 255.255.255.0.

This is a common subnet mask. It means that if the first three octets of two IP addresses match, they are in the same subnet.

For example:

  • IP 1.1.1.2 and 1.1.1.3 are in the same subnet.
  • IP 1.1.2.2 is in a different subnet.

When a device detects that the recipient is in another subnet, it sends data to the default gateway, which is the router’s IP address.

Let’s simulate a situation:

A device with MAC 111 wants to send data to the IP 1.1.2.3. The sender realizes this is a different subnet and sends the data to the default gateway. First, it uses ARP to get the MAC address of the gateway, then sends the packet.

The router receives the packet, sees that the destination IP is different, and forwards the data. In the second subnet, it again uses ARP to find the MAC address of the target device and finally delivers the data.

IP Protocol

The IP (Internet Protocol) was introduced in the 1980s to connect computer networks. Today, there are two versions:

  • IPv4 – uses 32-bit addressing. The number of available IP addresses is limited.
  • IPv6 – uses 128-bit addressing and was introduced to solve IPv4 address exhaustion. In IPv6, ARP is not used.

Both protocols serve the same function. IPv6 was meant to replace IPv4, but because of technologies like NAT, IPv4 is still widely used. In this guide, we’ll focus on IPv4.

An IP packet consists of the following fields:

  • Version – IPv4 or IPv6.
  • IHL (Internet Header Length) – indicates the size of the header.
  • Type of Service – used for QoS (Quality of Service).
  • Total Length – includes header and data.
  • Identification – groups fragmented packets together.
  • Flags – indicate if a packet is fragmented.
  • Fragment Offset – position of the fragment.
  • Time to Live (TTL) – limits the number of hops.
  • Protocol – defines the transport protocol (e.g., TCP, UDP).
  • Header Checksum – verifies the header’s integrity.
  • Source IP Address
  • Destination IP Address
  • Options – additional parameters for special use.
  • Data – the actual payload.

Transport Layer Protocols

The most common transport layer protocols in TCP/IP are UDP and TCP. They deliver data to specific applications identified by port numbers. Let’s start with UDP — it’s simpler than TCP.

UDP

A UDP datagram contains:

  • Source port
  • Destination port
  • Length
  • Checksum
  • Payload (from the higher layer)

UDP’s role is to handle ports and verify frames. However, it does not guarantee delivery. If some data is lost or corrupted, UDP will not request a retransmission — unlike TCP.

TCP

TCP packets are called segments. A TCP segment includes:

  • Source and destination ports
  • Sequence number
  • Acknowledgment number (used for confirming receipt)
  • Header length
  • Reserved flags
  • Control flags (for establishing or ending connections)
  • Window size (how many segments should be acknowledged)
  • Checksum
  • Urgent pointer
  • Options
  • Data (from the higher layer)

TCP guarantees reliable data transmission. A connection is established between endpoints before sending data. If delivery cannot be guaranteed, the connection is terminated. TCP handles packet loss, ensures order, and reassembles fragmented data.

Application Layer Protocols

In both the TCP/IP model and the OSI model, the top layer is the application layer.

Here are some widely used application protocols:

  • DNS (Domain Name System) – resolves domain names to IP addresses.
  • HTTP – transfers hypertext over the web, allowing communication between browsers and web servers.
  • HTTPS – does the same as HTTP, but with encryption for secure communication.

DNS servers use UDP, which is faster but less reliable. In contrast, protocols like FTP and HTTP rely on TCP, which provides reliable delivery.

Other popular application protocols include:

  • FTP (File Transfer Protocol) – for managing file transfers.
  • POP3 (Post Office Protocol version 3) – used by email clients to retrieve messages.
  • IMAP (Internet Message Access Protocol) – allows access to emails over the internet.

Conclusion

This guide covered the most commonly used protocols in computer networks. These protocols form the backbone of most real-world network communications. In total, there are around 7,000 protocols, many of which are used for more specialized tasks.

Infrastructure

Similar

Infrastructure

IaaS vs PaaS vs SaaS: Cloud Computing Service Models

The term “cloud” has become an integral part of modern business practices. Most new projects and startups are launched using cloud-based solutions. They simplify the protection of commercial and personal data, reduce the costs of deploying IT infrastructure, and lower the risks of server breaches aimed at stealing databases or financial information. Many established companies are also considering moving to cloud services as a way to optimize operations. What Is a Cloud Service The weakest link in IT services is often the administrator who maintains the server and software. By default, an organization must either keep such a specialist on staff or hire one through an outsourcing contract. This option is not always cost-effective, especially for small companies or those going through financial difficulties. However, it is also impossible to do without technical experts, since their absence increases the risks of downtime and profit loss. A completely different situation arises when a company rents a SaaS platform: The client does not need to buy expensive servers. The provider handles updates and software patches. The system can be scaled up or down in just a few minutes. The number of workstations in a cloud-based application can be changed simply by paying for additional accounts or switching to another plan. Similarly, it is just as easy to remove unnecessary accounts and revert to the previous setup. Cloud services are usually provided on a prepaid basis, allowing users to pause or cancel their subscriptions for specific periods, for instance, during a slow season or for a few months or a quarter. When compared to other industries, cloud systems can be likened to taxi services. When a customer orders transportation, they pay only for the distance or time traveled, without bearing any expenses for vehicle maintenance, driver salaries, insurance, or spare parts. If they owned a vehicle instead, they would have to buy it and handle repairs, fueling, and maintenance. Benefits of Cloud Infrastructure To the benefits listed above, we can add at least a dozen more. For example, local IT systems can be migrated to the cloud with relative ease; often, a single software reconfiguration is enough. Office or industrial networking equipment usually continues to function almost unchanged. This means that business owners can avoid costly software purchases and data transfer services. Other key advantages of SaaS solutions include: A significant reduction in the workload of the company’s IT department, which can make it possible to reduce staff or lower outsourcing costs. Cloud hosting alleviates internal network strain and prevents router overloads during peak reporting periods. Businesses no longer need to buy backup, mirroring, or other systems designed to protect against hardware failures. Scalability is so high that connecting a few new workstations in an existing office or setting up a brand-new office for ten employees presents no difficulty at all. For business owners, several points stand out as particularly important. There are no capital expenditures for equipment purchases, and resources are saved on maintenance and staff. Rapid deployment of workstations makes it easier to open new offices. For startups, it is also possible to rent only the resources required for testing a business plan before committing to long-term investment. Cloud Service Models Cloud computing continues to be a rapidly developing technology, partly because there are multiple ways to use it. The SaaS model is only one option, albeit the most common. There are four deployment models for cloud technologies: private cloud, public cloud, hybrid cloud, and community cloud. Each offers a different set of features and capabilities. Even more interesting is the division by service delivery models: SaaS (Software as a Service) PaaS (Platform as a Service) IaaS (Infrastructure as a Service) A broader term, XaaS (Anything as a Service), emphasizes that users do not purchase hardware but rent it, or in some cases, pay only for software licenses. All services are delivered virtually and provide only the final result: for example, access to a CRM, a warehouse database, or remote storage. IaaS: Infrastructure as a Service Let’s begin with IaaS. Every organization’s infrastructure differs slightly from others, depending not only on the system administrator but mostly on the tasks performed by the network hardware. The IaaS model enables the creation of various configurations based on virtual servers. Providers offering such services typically operate under the public cloud model. IaaS addresses the following business needs: Migrating IT infrastructure to the cloud. Quickly launching startups and digital products. Creating a backup environment in case of a local server crash. Expanding existing infrastructure during business scaling. Handling peak loads, for example, during sales or marketing campaigns. Some companies maintain their own servers for central operations while renting additional capacity for remote branches as needed. This significantly speeds up deployment and saves the valuable time that would otherwise be spent purchasing, setting up, and later upgrading hardware to keep up with growing demands. Virtual resources make it possible to correct configuration mistakes almost instantly and without major financial losses. Common examples of IaaS include Microsoft Azure, Amazon EC2, Hostman, Cisco Metacloud, Google Compute Engine (GCE), and other public clouds such as Elastic Cloud. Even large enterprises use these services, since renting resources as needed is often more cost-efficient than maintaining proprietary hardware. Renting also removes concerns about equipment failures or insufficient performance. PaaS: Platform as a Service Next, PaaS provides “platform as a service,” primarily designed for developers and software testers because it automates routine processes and manages large datasets. A PaaS package often includes development tools, testing environments, and data storage for code and applications. PaaS platforms solve the following tasks: Shortening development cycles and reducing administrative costs. Processing Big Data, both historical and real-time. Implementing machine learning, for example, image recognition systems. The PaaS model is suitable for both small mobile applications and large enterprise services. Users can focus on the development process and access ready-to-use development tools out of the box. Time-to-market is greatly improved, regardless of project complexity. Developers can also install additional tools alongside built-in ones. Examples of PaaS systems include the Containerum Managed Kubernetes Service (a container-based development platform), Azure Stack App Service, and database-as-a-service offerings. Provider pricing is often affordable even for individual developers who need limited resources. Large corporations also use PaaS to build mobile apps for their services, such as delivery platforms and product aggregators. SaaS: Software as a Service SaaS solutions are widely familiar: Google Docs, Microsoft 365, and Trello are common examples. Each of these products simplifies collaboration, especially for remote work, and offers flexible pricing options. They are fully ready-to-use, subscription-based services with pricing determined by the number of active users. In short, a SaaS platform provides: Office software for employees. Cloud-based tools for freelancers and small business owners. Affordable access to otherwise expensive applications. For example, Adobe offers Photoshop, Illustrator, InDesign, Premiere Pro, and XD through Creative Cloud, and Autodesk provides several products via the cloud. This approach gives users access to high-performance computing resources without the need for costly local hardware. Beyond flagship products, countless simpler SaaS applications exist, including CRM systems, accounting tools, warehouse databases, website builders, and cloud storage such as Google Drive and OneDrive. Users are now so accustomed to these services that they rarely think of them as cloud-based; an internet outage is usually the only reminder that applications are running on remote servers. Quick Comparison of IaaS, PaaS, and SaaS Even with clear definitions, businesses often struggle to choose the right model. Renting a few CRM seats in AmoCRM is one thing; replacing a local server with a virtual machine and migrating CRM databases, inventory systems, and vast document libraries is another. A practical approach is to start by listing the hardware involved (CPU, RAM, storage, etc.), then select the operating system best suited to your goals. When renting virtual hardware, there is no need to purchase OS or RDP licenses separately, since these are included with access to the virtual machine’s specifications. Next, calculate the cost of deploying an in-house server room versus renting cloud capacity in a data center, factoring in software, user count, and storage needs. This provides an objective comparison of profitability. Choosing between IaaS, PaaS, and SaaS is not difficult; each has its ideal user: developers typically prefer PaaS, system administrators rely on IaaS, and end users benefit most from SaaS. Model Typical User Service Provided Area of Responsibility Level of Customization IaaS IT departments, software developers Virtual servers, cloud storage Server availability Minimal restrictions on supported OS and applications PaaS Application developers Platform for running software, cloud storage Platform performance and reliability High level of application customization SaaS End users Ready-to-use software application Application performance and uptime Minimal user customization Clouds are used for video surveillance storage, virtual PBXs, webinar and video conferencing platforms, and electronic document management. Virtual machines frequently host corporate websites or SMTP servers. These functions are often combined with CRM systems, accounting tools, and other business applications, turning the cloud into a universal platform. Choosing a Cloud Deployment Model Migrating to cloud services often stems from limited in-house expertise and the need for full business process automation. If the company employs an experienced IT professional, such questions may not even arise, because that person can handle OS installation, configuration, backup, and maintenance. It is worth asking the following questions: Is the organization large, medium, or small? Does it already have its own IT infrastructure? Has it purchased equipment for an on-premises server room? Does it have qualified engineers and administrators on staff? The answers will clarify whether cloud services are necessary or if existing resources suffice. Choosing a specific cloud model is rarely a problem. For example, with Hostman’s cloud services, users do not need to understand the internal workings of the cloud; the provider’s support team will handle the setup free of charge. Cloud Provider Pricing Models Another important issue is cost: how much will it cost to rent a SaaS application or other cloud service? If the provider frequently increases prices, cloud migration may become unprofitable. It is therefore essential to assess the company’s resource consumption patterns. The most popular pricing schemes are: Pay as You Go: customers pay only for the resources they actually use. Reservation Pool: the provider reserves a fixed amount of capacity after payment. The first model gives clients access to resources as long as they are available; during peak demand, processing speed may temporarily decrease. The second model guarantees consistent resource availability, regardless of load. Each option has its pros and cons, and customers can switch between them easily. Conclusion The popularity of cloud services is easy to explain. They provide automation opportunities even for small businesses and independent professionals. The speed of deployment and scaling, along with the flexibility of configuration, make virtual machines far more versatile than local setups. For this reason, cloud computing will continue to evolve, gradually shifting more and more company resources into remote data centers.
10 October 2025 · 10 min to read
Infrastructure

Data Processing Unit (DPU): Meaning & How It Works

A DPU is a special type of processor designed for data processing. The abbreviation stands for Data Processing Unit. Technologically, it is a kind of smart network interface card. Its main purpose is to offload the central processing unit (CPU) by taking over part of its workload. To understand why DPUs are important and what potential this technology holds, we need to go back several decades. A Bit of History In the 1990s, the Intel x86 processor, combined with software, provided companies with unprecedented computing power. Client-server computing began to develop, followed by multi-tier architectures and then distributed computing. Organizations deployed application servers, databases, and specialized software, all running on numerous x86 servers. In the early 2000s, hypervisors became widespread. Now, multiple virtual machines could be launched on a single powerful server. Hardware resources were no longer wasted and began to be used efficiently. Thanks to hypervisors, hardware became programmable. Administrators could now write code to automatically detect and initiate virtual machines, forming the foundation of today’s cloud computing paradigm. The next step was network and storage virtualization. As a result, a powerful CPU became the foundation for emulating virtually everything: virtual processors, network cards, and storage interfaces. The downside of this evolution was that pressure on the CPU increased significantly. It became responsible for everything, from running the operating system and applications to managing network traffic, storage I/O operations, security, and more. All system components began competing for CPU resources. The CPU’s functions went far beyond its original purpose. At this point, two major trends emerged: The appearance of specialized hardware for artificial intelligence (AI). The evolution of programmable hardware. CPU, GPU, and DPU AI workloads require parallelism, which cannot be achieved with a general-purpose CPU. Thus, graphics processing units (GPUs) became the driving force behind AI development. Originally designed to accelerate graphics rendering, GPUs evolved into coprocessors for executing complex mathematical operations in parallel. NVIDIA quickly seized this opportunity and released GPUs specifically designed for AI training and inference workloads. GPUs were the first step toward offloading the CPU. They took over mathematical computations. After that, the market saw the emergence of other programmable chips. These microchips are known as application-specific integrated circuits (ASICs) and field-programmable gate arrays (FPGAs), which can be programmed for specific tasks, such as optimizing network traffic or accelerating storage I/O operations. Companies like Broadcom, Intel, and NVIDIA began producing processors that were installed on network cards and other devices. Thanks to GPUs and programmable controllers, the excessive load on the CPU started to decrease. Network functions, storage, and data processing were delegated to specialized hardware. That’s the simplest explanation of what a coprocessor is: a device that shares the CPU’s workload, allowing hardware resources to be used to their full potential. The secret to success is simple: each component does what it does best. Understanding the Architecture Before discussing DPUs, we should first understand what an ASIC processor is and how it relates to network interface cards. Standard and Specialized Network Cards A network card is a device that allows a computer to communicate with other devices on a network. They are also referred to by the abbreviation NIC (Network Interface Controller). At the core of every NIC is an ASIC designed to perform Ethernet controller functions. However, these microchips can also be assigned other roles. The key point is that a standard NIC’s functionality cannot be changed after manufacturing; it performs only the tasks it was designed for. In contrast, SmartNICs have no such limitations. They allow users to upload additional software, making it possible to expand or modify the functionality of the ASIC, without even needing to know how the processor itself is structured. To enable such flexibility, SmartNICs include enhanced computing power and extra memory. These resources can be added in different ways: by integrating multi-core ARM processors, specialized network processors, or FPGAs. DPU Characteristics Data Processing Units are an extension of SmartNICs. Network cards are enhanced with support for NVMe or NVMe over Fabrics (NVMe-oF). A device equipped with an ARM NVMe processor can easily handle input/output operations, offloading the central processor. It’s a simple yet elegant solution that frees up valuable CPU resources. A DPU includes programmable interfaces for both networking and storage. Thanks to this, applications and workloads can access more of the CPU’s performance, which is no longer burdened with routine network and data management tasks. Market Solutions One of the best-known solutions is NVIDIA® BlueField, a DPU line first introduced in 2019, with the third generation announced in 2021. NVIDIA BlueField DPU is designed to create secure, high-speed infrastructure capable of supporting workloads in any environment. Its main advantages include: Zero-trust architecture, ensuring strong security within data centers. Low latency with direct data access. Data transfer speeds up to 400 Gbit/s. SDKs that help developers build high-performance, software-defined, cloud-optimized services accelerated by DPUs using standard APIs. Another company in this space is Pensando, which develops the Distributed Services Card, a data-processing card featuring a DPU. It includes additional ARM cores and hardware accelerators for specific tasks such as encryption and disk I/O processing. Google and Amazon are also developing their own ASIC-based projects: Google TPU (Tensor Processing Unit): a processor designed for machine learning, optimized to run advanced ML models in Google Cloud AI services. AWS Graviton: an ARM-based chip designed to provide the best performance-to-cost ratio for cloud workloads running in Amazon EC2. What’s Next? It is quite possible that the DPU will become the third essential component of future data center servers, alongside the CPU (central processing unit) and GPU (graphics processing unit). This is due to its ability to handle networking and storage tasks. The architecture may look like this: CPU: used for general-purpose computing. GPU: used for accelerating AI applications. DPU: used for processing and transferring data. It appears that DPUs have a promising future, largely driven by the ever-growing volume of data. Coprocessors can breathe new life into existing servers by reducing CPU load and taking over routine operations. This eliminates the need to look for other optimization methods (such as tweaking NVIDIA RAID functions) to boost performance. Estimates suggest that currently, around 30% of CPU workload is consumed by networking functions. Transferring these tasks to a DPU provides additional computing power to the CPU. This can also extend the lifespan of servers by several months or even years, depending on how much CPU capacity was previously dedicated to networking. By adding a DPU to servers, clients can ensure that CPUs are fully utilized for application workloads, rather than being bogged down by routine network and storage access operations. And this looks like a logical continuation of the process that began over 30 years ago, when organizations started building high-performance systems based on a single central processor.
09 October 2025 · 6 min to read
Infrastructure

Service Level Agreement (SLA): Meaning, Metrics, Examples

An SLA is an agreement that defines the level of service a company provides to its customers. This term is usually used in IT and telecommunications.  Unlike standard service contracts, a Service Level Agreement provides a very detailed description of service quality, operating modes, response times to incidents, and other parameters. Main Characteristics of an SLA A Service Level Agreement usually has the following characteristics: Maximum possible transparency of all processes and interactions between the service provider and the client. When drafting the contract, vague wording that could be interpreted ambiguously in one direction or another is avoided. Clearly defined rights and obligations understood by all participants in the agreement. For example, a provider commits to ensuring 99.9% service availability and to pay compensation if a lower figure is recorded, while the client has the right to request that compensation. Expectation management. For instance, a client might expect 24/7, ultra-fast support even for minor issues, while the provider cannot offer such a service. In this case, the client should either lower their expectations or sign a contract with another provider. A third option is also possible: the provider may raise the service level if it benefits their business processes. The agreement specifies the timeframes for fixing issues and solving other problems. It also describes possible compensations that the client may receive if the company fails to meet the declared metrics. An SLA does not always need to be a large document. The main thing is that it clearly describes the core parameters of the service in understandable terms. For example, the AWS S3 SLA is only one page long. It lists monthly uptime percentages and the amount of compensation the client receives if the service fails to meet those thresholds. What is Usually Included in an SLA The example above from Amazon Web Services is not a standard; it is just one possible format tailored to a specific service. An IT SLA often includes the following sections: The procedure for using the service. Responsibilities of both parties, including tools for mutual monitoring of performance. Specific steps for troubleshooting and restoring functionality. The agreement may also specify its term. In some cases, the parties describe in detail the procedure for adding new requirements for functionality or service availability. When describing service quality, its parameters are also disclosed. These typically include: Service availability. Response time to a problem. Time to fix incidents. The SLA may also specify a metric for operating hours. When describing payment procedures, it may indicate the billing model (e.g., pay-as-you-go, fixed rate, etc.). If penalties are provided, the SLA will specify the situations in which the provider must pay them. If the client is entitled to compensation, the SLA also describes the relevant situations and payment procedures. Key SLA Parameters SLA parameters are metrics that can be measured. The agreement should not contain vague phrases like “issues will be resolved quickly, before you even notice.” Such wording is unclear and prevents all participants from organizing proper workflows. For example, the support schedule metric should clearly define when and for which groups of users technical support is available. Suppose a company divides its clients into several groups: Group 1: 24/7 phone and chat support. Group 2: phone and chat support only on weekdays. Group 3: chat-only support on weekdays. Metrics are necessary so that all participants understand which services they receive, when, and in what scope. From this, several key characteristics follow: Metrics must always be publicly available. Their descriptions must be unambiguous for all parties. Clients must be notified in advance about metric changes. When defining metrics, it’s important not to set overly strict requirements, as this significantly increases costs. For instance, suppose a typical specialist can resolve a problem in 4 hours, while a higher-level expert can do it in 2 hours. Writing “2 hours” as the SLA metric is not ideal, as it would immediately make the expert’s work more expensive. If you specify “1 hour,” costs rise further due to the increased risk of penalties for non-compliance. Other important metrics can include response time to a client request. The values may differ depending on the client’s status and problem criticality. For example, a company providing IT outsourcing services might have: Premium clients: response within 15 minutes. Basic clients: response within 24 hours. All of this must be clearly reflected in the SLA. In addition to response time, there’s also incident resolution time. The logic for this parameter is similar: even if a client is important, requests are prioritized based on criticality. For example: If a client’s local office network stops working and all processes halt, that issue must be prioritized. The SLA may state that local network troubleshooting should take no more than 5 hours. If the same client needs to add a few new devices to an already working network, the resolution time may be several hours or even days. The combination of response time and resolution time forms downtime. These and other parameters must be described in the SLA and accepted by all parties before cooperation begins. This approach reduces conflicts; everyone understands what to expect from each other. Service Availability For providers, one of the most important SLA parameters is service availability. It is usually measured in days, hours, or minutes over an agreed period. For example, a provider guarantees that a cloud computing service will be available 99.99% of the time during a year. At first glance, the difference between SLA 99 and SLA 100 may seem small. But in absolute terms, it’s significant. At 99%, you agree that servers may be down up to 4 days per year. At 100%, downtime should be zero—something no company can guarantee. That’s why SLAs are usually written with “nines”: e.g., 99.9%, 99.99%, etc. For example, Hostman.com guarantees 99.98% uptime, meaning total annual downtime will not exceed 1 hour 45 minutes. Some providers promise “five nines”: 99.999% uptime, or less than 15 minutes of downtime per year. But this is not always the best option. Two points to consider: The higher the SLA percentage, the higher the cost. Not every client needs such a high level. In most cases, 99.982% uptime (or slightly higher) is sufficient. It’s important to check not only the number of nines but also the time unit used for measurement. By default, SLA indicators are calculated annually. For example, 99.95% availability equals no more than 4.5 hours of downtime per year. If the contract doesn’t explicitly say that the time unit is “per year,” be sure to clarify, as some providers disguise monthly values as annual. Another key concept is aggregate availability, which equals the lowest of all measured values. Benefits of an SLA Signing and adhering to an SLA benefits both parties. For the company, it defines obligations and protects against unreasonable client demands, such as urgently fixing a minor issue in the middle of the night. Other benefits include: The provider can use the SLA to organize both external and internal processes, such as introducing different support levels depending on service criticality and client importance. Clients gain clarity about what services they can expect, in what timeframes, and in what order, helping them plan their core operations. SLA vs. SLO: What’s the Difference An SLA can also be viewed as an indicator of user satisfaction, ranging from 0% to 100%. Absolute satisfaction (100%) is impossible, just as it’s impossible to guarantee 100% uptime. Therefore, when choosing metrics, one should be realistic and select achievable values. For example, if your team doesn’t provide 24/7 support, you shouldn’t promise it. When the team expands, you can update the SLA and delight clients by offering round-the-clock assistance. To monitor service levels internally, another system is used: SLO (Service Level Objective). These are the target values the provider aims to achieve. Example: Current capabilities are handling 50 tickets per business day, working 9:00 to 18:00, five days a week. These metrics are fixed in the SLA and shown to clients. Meanwhile, the SLO document sets internal goals, for example, increasing the number of handled tickets to 75 per day or switching to 24/7 support. This directly affects the company’s future service level. How to Create a Proper SLA Start with a descriptive section, which usually includes: A glossary System description Participant roles (users, support specialists) Boundaries of operation: geography, time, functionality The next section describes the services provided, giving the client a full understanding of what they can expect when signing with the provider. Then comes the main section, describing the service level. It should include metrics that reflect quality and are easily measurable, as well as metric values that are specific numbers guiding all participants. You can end the SLA with references to other documents that regulate service processes. At all stages of preparing an SLA, remember: it is a regulatory document. Its main goal is control. The more control over the process, the better the SLA. If there is no control, such an agreement is meaningless. Checklist: What to Consider When Preparing an SLA If you are not signing but drafting an SLA to offer clients, pay attention to the following points: Users. In large systems, divide users into groups and manage them separately. This helps allocate resources efficiently and avoid overload from different client types. Services. Consider the criticality of each service for each client group. Example: You provide a CRM to trading companies. If they can’t use it, they lose money and complain, meaning it’s a high-criticality service. Printer replacement or user account creation can wait until tomorrow. Service quality parameters. They must align with business goals and client needs. A typical example is incident resolution times, e.g., 24/7 support versus 9 a.m. to 5 p.m. on weekdays only. An SLA is a document that must be announced to all users whenever it is introduced or updated, regardless of privilege level or service criticality. SLA is a management tool that constantly evolves. You may find that current quality parameters harm business processes or no longer meet client expectations. In that case, management should decide to optimize processes or improve services. The main goal of SLA indicators is not to attract users but to ensure open dialogue with them. Every participant accepts the agreement and commits to following it. Violation of an SLA is grounds to claim compensation and terminate cooperation.
09 October 2025 · 9 min to read

Do you have questions,
comments, or concerns?

Our professionals are available to assist you at any moment,
whether you need help or are just unsure of where to start.
Email us
Hostman's Support