UDP (User Datagram Protocol)

UDP (User Datagram Protocol) is an alternative communications protocol to Transmission Control Protocol (TCP) used primarily for establishing low-latency and loss-tolerating connections between applications on the internet.

Both UDP and TCP run on top of the Internet Protocol (IP) and are sometimes referred to as UDP/IP or TCP/IP. But there are important differences between the two.

Where UDP enables process-to-process communication, TCP supports host-to-host communication. TCP sends individual packets and is considered a reliable transport medium; UDP sends messages, called datagrams, and is considered a best-effort mode of communications.

In addition, where TCP provides error and flow control, no such mechanisms are supported in UDP. UDP is considered a connectionless protocol because it doesn’t require a virtual circuit to be established before any data transfer occurs.

UDP provides two services not provided by the IP layer. It provides port numbers to help distinguish different user requests and, optionally, a checksum capability to verify that the data arrived intact.

TCP has emerged as the dominant protocol used for the bulk of internet connectivity due to its ability to break large data sets into individual packets, check for and resend lost packets, and reassemble packets in the correct sequence. But these additional services come at a cost in terms of additional data overhead and delays called latency.

In contrast, UDP just sends the packets, which means that it has much lower bandwidth overhead and latency. With UDP, packets may take different paths between sender and receiver and, as a result, some packets may be lost or received out of order.

User datagram protocol features

The user datagram protocol has attributes that make it advantageous for use with applications that can tolerate lost data.

  • It allows packets to be dropped and received in a different order than they were transmitted, making it suitable for real-time applications where latency might be a concern.
  • It can be used for transaction-based protocols, such as DNS or Network Time Protocol (NTP).
  • It can be used where a large number of clients are connected and where real-time error correction isn’t necessary, such as gaming, voice or video conferencing and streaming media.

UDP header composition

UDP uses headers as part of packaging message data to transfer over network connections. UDP headers contain a set of parameters called fields defined by the technical specifications of the protocol.

The User Datagram Protocol header has four fields, each of which is 2 bytes. They are:

  • source port number, which is the number of the sender;
  • destination port number, the port the datagram is addressed to;
  • length, the length in bytes of the UDP header and any encapsulated data; and
  • checksum, which is used in error checking. Its use is required in IPv6 and optional in IPv4.

How UDP works

UDP uses the Internet Protocol to get a datagram (data unit) from one computer to another. UDP works by encapsulating data in a UDP packet and adding its own header information to the packet. This data consists of the source and destination ports to communicate on, the packet length and a checksum. After UDP packets are encapsulated in an Internet Protocol packet, they’re sent off to their destinations.

Unlike TCP, UDP doesn’t guarantee that the packets will get to the right destinations. That means that UDP doesn’t connect to the receiving computer directly as TCP does. Rather, it sends the data out and relies on the devices in between the sending and receiving computers to get the data where it’s supposed to go correctly.

Most applications that use UDP just wait for any replies that are expected as a result of packets sent via UDP. If an application doesn’t receive a reply within a certain timeframe, the application sends the packet again or it stops trying.

UDP uses a simple transmission model that doesn’t include implicit handshaking dialogues to provide reliability, ordering or data integrity. Consequently, UDP’s service is unreliable and packets may arrive out of order, appear to have duplicates or disappear without warning.

Although this transmission method doesn’t guarantee that the data being sent will ever even reach its destination, it does have a very low overhead and it’s popular for services that don’t absolutely have to work the first time.

Applications of UDP

UDP can be used in applications that require lossless data transmission when the application is configured to manage the process of retransmitting lost packets and correctly arranging received packets. This approach can help to improve the data transfer rate of large files compared to TCP.

In the Open Systems Interconnection (OSI) communication model, UDP, like TCP, is in Layer 4, the transport layer. UDP works in conjunction with higher level protocols to help manage data transmission services, including Trivial File Transfer Protocol (TFTP), Real Time Streaming Protocol (RTSP), Simple Network Protocol (SNP) and domain name system (DNS) lookups.

UDP is an ideal protocol for network applications in which perceived latency is critical, such as in gaming and voice and video communications, which can suffer some data loss without adversely affecting perceived quality. In some cases, forward error correction techniques are used to improve audio and video quality in spite of some loss.

UDP can also be used for applications that depend on the reliable exchange of information but should have their own methods to answer packets. These services are advantageous because they’re not bound to fixed patterns to guarantee the completeness and correctness of the data packets sent. Users can decide how and when to respond to information that’s not correct or sorted.

UDP can also be used for multicasting because it supports packet switching. In addition, UDP is used for some routing update protocols, such as the Routing Information Protocol (RIP). UDP can be used in applications where speed rather than reliability is critical. For instance, it might be prudent to use UDP in an application sending data from a fast acquisition where it’s OK to lose some data points.

TCP vs. UDP

TCP and UDP are part of the TCP/IP protocol suite, which includes a number of protocols for carrying out network communications.

UDP characteristics:

  • is a connectionless protocol
  • is used for VoIP, video streaming, gaming and live broadcasts
  • it’s faster and needs fewer resources
  • the packets don’t necessarily arrive in order
  • it allows missing packets. The sender is unable to know whether a packet has been received
  • better suited for applications that need fast, efficient transmission, such as games.

TCP characteristics:

  • is a connection-oriented protocol
  • it’s the most widely used protocol on the Internet
  • it guarantees that no packets are missing and all the data that’s sent makes it to the intended recipient
  • sends packets in order so they can be stitched back together easily.
  • it’s slower and requires more resources
  • has a bigger header than UDP
  • best suited for apps that need high reliability, and transmission time is relatively less critical.

Server Message Block Protocol (SMB protocol)

The Server Message Block Protocol (SMB protocol) is a client-server communication protocol used for sharing access to files, printers, serial ports and other resources on a network. It can also carry transaction protocols for interprocess communication.

Created by IBM in the 1980s, the SMB protocol has since spawned multiple variants or implementations, also known as dialects, to meet evolving network requirements over the years.

How does the SMB protocol work?

The SMB protocol enables an application — or the user of an application — to access files on a remote server, as well as other resources, including printers, mail slots and named pipes. Thus, a client application can open, read, move, create and update files on the remote server. It can also communicate with any server program that is set up to receive an SMB client request.

The SMB protocol is known as a response-request protocol, meaning that it transmits multiple messages between the client and server to establish a connection.

An early dialect of the SMB protocol, Common Internet File System (CIFS), gained notoriety as a chatty protocol that bogged down wide area network (WAN) performance due to the combined burdens of and CIFS’ numerous acknowledgments. The next dialect, SMB 2.0, improved the protocol’s efficiency by drastically reducing its hundreds of commands and subcommands down to just 19.

The SMB protocol operates in Layer 7, also known as the application layer, and can be used over TCP/IP on port 445 for transport. Early dialects of the SMB protocol use the application programming interface (API) NetBIOS over TCP/IP, or legacy protocols such as the Internetwork Packet Exchange or NetBEUI. Today, communication with devices that do not support SMB directly over TCP/IP requires the use of NetBIOS over a transport protocol, such as TCP/IP.

Microsoft Windows operating systems since Windows 95 have included client and server SMB protocol support. Samba, an open source server that supports the SMB protocol, was released for Unix systems.

A client and server may implement different variations of SMB, which they negotiate before starting a session.

SMB protocol dialects

Variants of the SMB protocol have improved the original implementation’s capabilities, scalability, security and efficiency. Here is a brief overview of the SMB protocol’s notable dialects:

  • SMB 1.0 (1984): Created by IBM for file sharing in DOS. Introduced opportunistic locking (OpLock) as a client-side caching mechanism designed to reduce network traffic. Microsoft would later include the SMB protocol in its LAN Manager product.
  • CIFS (1996): Microsoft-developed SMB dialect that debuted in Windows 95. Added support for larger file sizes, transport directly over TCP/IP, and symbolic links and hard links.
  • SMB 2.0 (2006): Released with Windows Vista and Windows Server 2008. Reduced chattiness to improve performance, enhanced scalability and resiliency, and added support for WAN acceleration.
  • SMB 2.1 (2010): Introduced with Windows Server 2008 R2 and Windows 7. The client oplock leasing model replaced OpLock to enhance caching and improve performance. Other updates included large maximum transmission unit (MTU) support and improved energy efficiency, which enabled clients with open files from an SMB server to enter sleep mode.
  • SMB 3.0 (2012): Debuted in Windows 8 and Windows Server 2012. Added several significant upgrades to improve availability, performance, backup, security and management. Noteworthy new features included SMB Multichannel, SMB Direct, transparent failover of client access, Remote VSS support, SMB Encryption and more.
  • SMB 3.02 (2014): Introduced in Windows 8.1 and Windows Server 2012 R2. Included performance updates and the ability to completely disable CIFS/SMB 1.0 support, including removal of the related binaries.
  • SMB 3.1.1 (2015): Released with Windows 10 and Windows Server 2016. Added support for advanced encryption, preauthentication integrity to prevent man-in-the-middle attacks and cluster dialect fencing, among other updates.

In 2017, the WannaCry and Petya ransomware attacks exploited a vulnerability in SMB 1.0 to load malware on vulnerable clients and propagate it across networks. Microsoft subsequently released a patch, but experts have advised users and administrators to take the additional step of disabling SMB 1.0/CIFS on all systems.

CIFS vs. SMB

As noted in the list above, CIFS is an early dialect of the SMB protocol developed by Microsoft. Although the terms are sometimes used interchangeably, CIFS only refers to a single implementation of SMB. Most modern systems use more recent dialects of the SMB protocol.

Samba vs. SMB

Released in 1992, Samba is an open source implementation of the SMB protocol for Unix systems and Linux distributions. It supports file sharing and print services, authentication and authorization, name resolution, and service announcements between Linux/Unix servers and Windows clients.

 

source: https://searchnetworking.techtarget.com/definition/Server-Message-Block-Protocol