Difference between TCP and UDP protocols. TCP and UDP protocols
User Datagram Protocol (UDP)(User Datagram Protocol) is a TCP/IP protocol defined in RFC 768, "User Datagram Protocol (UDP)". UDP is used instead of TCP for fast and unreliable data transport between TCP/IP hosts.
UDP protocol provides a connectionless service, so UDP does not guarantee delivery or sequencing for any datagram. A host that needs reliable communication must use either the TCP protocol or a program that will keep track of the sequence of datagrams and acknowledge the receipt of each packet.
Time-sensitive applications often use UDP (video data), as it is preferable to drop packets rather than wait for delayed packets, which may not be possible in real-time systems. Also, the loss of one or more frames when transmitting video data via UDP is not so critical, in contrast to the transmission of binary files, where the loss of one packet can lead to distortion of the entire file. Another advantage of the UDP protocol is that the length of the UDP header is 4 bytes, while that of the TCP protocol is 20 bytes.
UDP messages are encapsulated and sent as IP datagrams.
UDP header
The figure shows the fields present in the UDP header.
- Sender port - this field specifies the port number of the sender. This value is supposed to specify the port to which the response will be sent if necessary. Otherwise, the value should be 0. If the source host is a client, then the port number will most likely be ephemeral. If the source is a server, then its port will be one of the "well-known".
- Destination Port - This field is required and contains the destination port. Similar to the source port, if the client is the destination host, then the port number is ephemeral, otherwise (the server is the destination) it is a "well-known port".
- Datagram length - a field that specifies the length of the entire datagram (header and data) in bytes. The minimum length is equal to the header length - 8 bytes. Theoretically, the maximum field size is 65535 bytes for a UDP datagram (8 bytes for header and 65527 for data). The actual data length limit when using IPv4 is 65507 (in addition to the 8 bytes per UDP header, another 20 bytes per IP header are required).
- Checksum - The checksum field is used to check the header and data for errors. If the amount is not generated by the transmitter, then the field is filled with zeros.
Consider the heading structure UDP using the Wireshark network analyzer:
UDP ports
Since several programs can be running on the same computer, a unique identifier for each program or port number is used to deliver a UDP packet to a specific program.
Port number is a conditional 16-bit number from 1 to 65535 indicating which program the packet is intended for.
UDP ports provide the ability to send and receive UDP messages. The UDP port functions as a single message queue to receive all datagrams destined for the program specified by the protocol port number. This means that UDP programs can receive more than one message at a time.
All UDP port numbers less than 1024 are reserved and registered with the Internet Assigned Numbers Authority (IANA).
The UDP and TCP port numbers do not overlap.
Each UDP port is identified by a reserved or known port number. The following table shows a partial list of known UDP port numbers that are used by standard UDP programs.
UDP uses a simple transmission model, with no implicit handshakes, to ensure reliability, ordering, or data integrity. Thus, UDP provides an unreliable service, and datagrams can arrive out of order, be duplicated, or disappear without a trace. UDP implies that error checking and remediation are either not necessary or must be performed by the application. Time-sensitive applications often use UDP, as it is preferable to drop packets rather than wait for delayed packets, which may not be possible in real-time systems. If it is necessary to correct errors at the network interface layer, the application can use TCP or SCTP, which are designed for this purpose.
The nature of UDP as a stateless protocol is also useful for servers responding to small queries from a huge number of clients, such as DNS and streaming media applications like IPTV, Voice over IP, IP tunneling protocols, and many online games.
Service ports
UDP provides no message delivery guarantees for the upper layer protocol and does not store the state of sent messages. For this reason, UDP is sometimes referred to as the Unreliable Datagram Protocol.
Before calculating the checksum, the UDP message is padded with zero bits at the end to a length that is a multiple of 16 bits (the pseudo-header and padding zero bits are not sent with the message). Checksum field in UDP header during checksum calculation sent messages are taken to be null.
To calculate the checksum, the pseudo-header and the UDP message are split into words (1 word = 2 bytes (octets) = 16 bits). Then the bitwise one's complement of the sum of all words with the bit's complement is calculated. The result is written to the corresponding field in the UDP header.
A checksum value of zero is reserved, meaning that the datagram has no checksum. If the calculated checksum is equal to zero, the field is filled with binary ones.
Upon receipt of the message, the recipient calculates the checksum again (already taking into account the checksum field), and if the result is a binary number of sixteen ones (that is, 0xffff), then the checksum is considered to have converged. If the sum does not add up (the data was corrupted in transit), the datagram is destroyed.
Checksum calculation example
For example, let's calculate the checksum of several 16-bit words: 0x398a, 0xf802, 0x14b2, 0xc281 . Find their sum with bitwise complement.
0x398a + 0xf802 = 0x1318c → 0x318d
0x318d + 0x14b2 = 0x0463f → 0x463f
0x463f + 0xc281 = 0x108c0 → 0x08c1
Now we find the bitwise addition to the unit of the result obtained:
0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73e or else 0xffff − 0x08c1 = 0xf73e . This is the desired checksum.
When calculating the checksum, a pseudo-header is again used, imitating a real IPv6 header:
| bits | 0 – 7 | 8 – 15 | 16 – 23 | 24 – 31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Source address | |||||||||||||||||||||||||||||||
| 32 | ||||||||||||||||||||||||||||||||
| 64 | ||||||||||||||||||||||||||||||||
| 96 | ||||||||||||||||||||||||||||||||
| 128 | Address of the recipient | |||||||||||||||||||||||||||||||
| 160 | ||||||||||||||||||||||||||||||||
| 192 | ||||||||||||||||||||||||||||||||
| 224 | ||||||||||||||||||||||||||||||||
| 256 | UDP Length | |||||||||||||||||||||||||||||||
| 288 | Zeros | Next title | ||||||||||||||||||||||||||||||
| 320 | Source port | Destination Port | ||||||||||||||||||||||||||||||
| 352 | Length | Check sum | ||||||||||||||||||||||||||||||
| 384+ | Data |
|||||||||||||||||||||||||||||||
The source address is the same as in the IPv6 header. Recipient address - final recipient; if the IPv6 packet does not contain a Routing header, then this will be the destination address from the IPv6 header, otherwise, on the starting node, this will be the address of the last element of the routing header, and on the destination node, the destination address from IPv6- header. The "Next Header" value is equal to the protocol value - 17 for UDP. UDP Length - The length of the UDP header and data.
Reliability and congestion solutions
Due to the lack of robustness, UDP applications must be prepared for some losses, errors, and duplication. Some of them (for example, TFTP) can add rudimentary application-layer reliability mechanisms as needed.
But more often such mechanisms are not used by UDP applications and even interfere with them. Streaming media, real-time multiplayer games, and VoIP are examples of applications that often use the UDP protocol. In these particular applications, packet loss is usually not a big problem. If an application needs a high level of reliability, then another protocol (TCP) or erasure codes can be used.
A more serious potential problem is that, unlike TCP, UDP-based applications do not necessarily have good congestion control and avoidance mechanisms. Congestion-sensitive UDP applications that consume a significant amount of available bandwidth can compromise Internet stability.
Network mechanisms were designed to minimize the possible effects of congestion under uncontrolled, high-speed loads. Network elements such as routers using packet queuing and flushing techniques are often the only tool available to slow down excess UDP traffic. DCCP (Datagram Congestion Control Protocol) is designed as a partial solution to this potential problem by adding mechanisms to the end host to track congestion for high-speed UDP streams like streaming media.
Applications
Numerous key Internet applications use UDP, including DNS (where queries must be fast and consist of only one query followed by a single response packet), Simple Network Management Protocol (SNMP), Routing Information Protocol (RIP), Dynamic Host Configuration (DHCP).
Voice and video traffic is usually transmitted using UDP. Real-time video and audio streaming protocols are designed to handle random packet loss so that the quality is only marginally degraded instead of long delays when the lost packets are retransmitted. Because both TCP and UDP operate on the same network, many companies have noticed that the recent increase in UDP traffic due to these real-time applications is hindering the performance of TCP applications like database systems or accounting. Because both business and real-time applications are important to companies, developing quality solutions to a problem is seen by some as a top priority.
Comparison of UDP and TCP
TCP is a connection-oriented protocol, which means that a "handshake" is required to establish a connection between two hosts. Once a connection is established, users can send data in both directions.
- Reliability- TCP manages acknowledgment, retransmission, and timeout of messages. Multiple attempts are made to deliver the message. If it gets lost along the way, the server will re-request the lost part. In TCP, there is no missing data, nor (in the case of multiple timeouts) dropped connections.
- orderliness- if two messages are sent consecutively, the first message will reach the receiving application first. If the data chunks arrive in the wrong order, TCP sends out-of-order data to the buffer until all of the data can be ordered and passed to the application.
- heaviness- TCP needs three packets to establish a socket connection before sending data. TCP monitors reliability and congestion.
- Threading- data is read as a stream of bytes, no special notation for message boundaries or segments is transmitted.
UDP is a simpler, connectionless, message-based protocol. These types of protocols do not establish a dedicated connection between two hosts. Communication is achieved by passing information in one direction from source to destination without checking the readiness or state of the destination. However, the main advantage of UDP over TCP is in Voice over Internet Protocol (Voice over IP, VoIP) applications, where any "handshake" would interfere with good voice communication. In VoIP, it is assumed that end users will provide any necessary real-time acknowledgment that a message has been received.
- Unreliable- when a message is sent, it is not known whether it will reach its destination - it may get lost along the way. There are no such concepts as acknowledgment, retransmission, timeout.
- disorder- if two messages are sent to the same recipient, then the order of their achievement of the goal cannot be predicted.
- lightness- no ordering of messages, no connection tracking, etc. This is a small transport layer developed on IP.
- datagrams- Packets are sent individually and checked for integrity only if they have arrived. Packets have defined boundaries that are respected upon receipt, i.e. a read operation on the receiving socket will return the message as it was originally sent.
- No overload control- UDP itself does not avoid congestion. It is possible for high bandwidth applications to cause congestion collapse unless they implement application layer controls.
Links to RFCs
- RFC 768 - User Datagram Protocol
- RFC 2460 - Internet Protocol Specification Version 6 (IPv6)
- RFC 2675 - IPv6 Jumbograms
- RFC 4113 - Management Information Base for the UDP
- RFC 5405 - Unicast UDP Usage Guidelines for Application Designers
see also
Links
- Kurose, J. F.; Ross, K. W. (2010). Computer Networking: A Top-Down Approach (5th ed.). Boston, MA: Pearson Education. ISBN 978-0-13-136548-3.
- Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
- [email protected]"UDP Protocol Overview". ipv6.com. Retrieved 17 August 2011.
- Clark, M.P. (2003). Data Networks IP and the Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd.
- Postel, J. (August 1980). RFC 768: User Datagram Protocol. Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc768
- Deering S. & Hinden R. (December 1998). RFC 2460: Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc2460
- "The impact of UDP on Data Applications". networkperformancedaily.com. Retrieved 17 August 2011.
- D. Comer. Internetworking using TCP/IP. Chapter 11
| Basic TCP / IP Protocols by OSI Model Layers (List of TCP and UDP Ports) | |
|---|---|
| Physical | |
| ducted | |
At the link and network layer protocols TCP/IP packet, which deal with the basic mechanism for transferring blocks of data between countries and between networks, are the foundations TCP/IP. They use the protocol stack, but they are not used directly in applications that run on the protocol. TCP/IP. In this article, we will look at two protocols that are used by applications: User Datagram Protocol (UDP) and Transmission Control Protocol (TCP).
User datagram protocol
The User Datagram Protocol is a very simple protocol. Like IP, it is a reliable protocol without connections. You don't need to connect to the host to communicate with it using UDP, and there is no mechanism to ensure the data being transferred.
Block of data transmitted using UDP called a datagram. UDP adds four 16-bit header fields (8 bytes) to the transmitted data. These fields are the length field, the checksum field, and the source and destination port number. A "port", in this context, is a software port, not a hardware port.
The concept of a port number is common to both UDP and TCP. Port numbers determine which protocol module is sending (or receiving) data. Most protocols have standard ports that are commonly used for this. For example, the Telnet protocol typically uses port 23. Simple Mail Transfer Protocol (SMTP) uses port 25. The use of standard port numbers allows clients to communicate with the server without having to first determine which port to use.
Port and protocol number in header field IP overlap to some extent, although the protocol fields are not available to higher level protocols. IP uses the protocol field to determine where the data should be transferred to UDP or TCP modules. UDP or TCP use the port number to determine which application layer protocol should receive data.
Despite, UDP is not reliable, it is still a suitable choice for many applications. It is used by real-time applications such as streaming audio and video, where if data is lost, it is better to do without it than to send it again in order. It is also used by protocols such as the Simple Network Management Protocol (SNMP).
Broadcast
UDP suitable for broadcasting as it does not require an open connection. The purpose of a broadcast message is determined by the sender, to the destination IP address specified. UDP datagrams with the destination IP address are all binary 255.255.255.255) and will be received by every host on the local network. Note the word local: datagrams with this address will not be accepted by the router to the Internet.
Transmissions can be directed to specific networks. UDP datagrams with the host and subnet parts of the IP address set as binary are broadcast to all hosts on all subnets of the network that matches the pure part of the IP address. If only the receiving end (in other words, all bits that are zero in the subnet mask) is set to binary, then broadcasting is restricted to all hosts on the subnet that matches the rest of the address.
Multicast is used to send data to a group of hosts that have expressed a desire to receive it. multicast UDP The datagram has a destination address in which the first four bits, 1110, are given addresses in the range 224.xxx to 239.xxx The remaining bits of the address are used to designate a multicast group. It's more like a radio or TV channel. So, for example, 224.0.1.1 is used for the NTP protocol. If TCP/IP applications want to receive a multicast message, they must join the appropriate multicast group, which it does by passing the group's address up the protocol stack.
Broadcasts, in fact, filter the transmission. Multicaster does not consider individual messages for each host that joins a group. Instead, the messages are broadcast, and the drivers on each host decide whether to ignore them or push the contents to the protocol stack.
This means that multicast messages must be broadcast all over the Internet, since multicaster does not know which hosts want to receive messages. Fortunately, this is not necessary. IP uses a protocol called Internet Group Management Protocol (IGMP) to tell routers which hosts want to receive multicast group messages, so messages are only sent where they are needed.
Transmission Control Protocol
The Transmission Control Protocol is a transport layer protocol used by most Internet applications such as Telnet, FTP, and HTTP. It is a connection-oriented protocol. This means that two computers - one client, another server - must establish a connection between them before data can be transferred between them.
TCP provides reliability. Application that uses TCP knows that it is sending data received at the other end, and that it has received it correctly. TCP uses checksums on both headers and data. When receiving data, TCP sends an acknowledgment back to the sender. If the sender does not receive confirmation within a certain period of time, the data is resent.
TCP includes mechanisms to ensure that data arrives in the reverse order in which it was sent. It also implements flow control so that the sender cannot overwhelm the data receiver.
TCP transmits data using IP in blocks called segments. The length of the segment is determined by the protocol. In addition to the IP header, each segment consists of a 20 bytes header. header TCP starts with a 16-bit source and destination port number field. Like UDP, these fields define the application level, which is aimed at receiving data. The IP address and port number taken together uniquely identify the services running on the host and the pair known as the socket.
Next in the header is a 32-bit sequence number. This number specifies the position in the data stream that should occupy the first data byte in the segment. Serial number TCP allows you to keep the data stream in the correct order, although the segments can be obtained from the sequence.
The next field is a 32-bit field that is used to signal back to the sender that the data was received correctly. If ACK is the flag, which it usually is, then this field contains the position of the next data byte that the sender of the segment expects to receive.
V TCP there is no need for each data segment to be recognized. The value in the confirmation field is interpreted as "all data received so far OK". This saves bandwidth when all data is sent in one direction, reducing the need for segment recognition. If data is sent in both directions at the same time, as in full duplex communication, there is no cost associated with marks, since a one-way data segment may contain an acknowledgment for data sent the other way.
Next in the header is a 16-bit field containing the header length and flags. TCP headers can contain additional fields, so the length can vary from 20 to 60 bytes. Flags: URG, ACK (which we already mentioned), PSH, RST, SYN and FIN. Later, we will look at some other flags.
The header contains a field called the window size, which gives the number of bytes that the receiver can receive. There is also a 16-bit checksum covering both header and data. Finally (before the additional data) there is a field called "urgency pointer". When the URG flag is set, this value is interpreted as a sequence number offset. It defines the start of the data in the stream that needs to be processed urgently. This data is often referred to as "out-of-band" data. An example of its use is when the user presses the break key to abort exiting a program during a Telnet session.
TCP and UDP protocols
TCP- Transmission Control Protocol
Connection-oriented communication can use reliable communication, in which the Layer 4 protocol sends acknowledgments of data receipt and requests retransmission if data is not received or corrupted. The TCP protocol uses just such a reliable connection. TCP is used in application protocols such as HTTP, FTP, SMTP, and Telnet.
The TCP protocol requires that a connection be opened before a message can be sent. The server application must perform the so-called passive open to create a connection on a known port number, and instead of sending a call to the network, the server goes to wait for incoming requests. The client application must active opening (active open) by sending the server application a sync sequence number (SYN) that identifies the connection. The client application can use a dynamic port number as the local port.
The server must send an acknowledgment (ACK) to the client along with a sequence number (SYN) of the server. In turn, the client responds with an ACK, and the connection is established.
After that, the process of sending and receiving messages can begin. When a message is received, an ACK message is always sent in response. If the timeout expires before the sender receives the ACK, the message is queued for retransmission.
The TCP header fields are listed in the following table:
| Field | Length | Description |
|---|---|---|
| Source port | 2 bytes | Source port number |
| Port of destination | 2 bytes | Destination port number |
| Serial number | 4 bytes | The sequence number is generated by the source and used by the destination to reorder packets to create the original message and send an acknowledgment to the source. |
| Confirmation number | 4 bytes | If the ACK bit of the Control field is set, this field contains the next expected sequence number. |
| Data offset | 4 bits | Information about the beginning of the data packet. |
| Reserve | 6 bits | Reserved for future use. |
| Control | 6 bits | The control bits contain flags that indicate whether the acknowledgment (ACK), Urgent Pointer (URG) fields are correct, whether the connection should be reset (RST), whether a sync sequence number (SYN) has been sent, etc. |
| Window size | 2 bytes | This field specifies the size of the receive buffer. Using acknowledgment messages, the recipient can inform the sender of the maximum amount of data that the sender can send. |
| Check sum | 2 bytes | Header and data checksum; it determines if the packet has been corrupted. |
| Urgency pointer | 2 bytes | In this field, the target device receives information about the urgency of the data. |
| Options | variable | Optional values that are specified if necessary. |
| Addition | variable | So many zeros are added to the padding field so that the header ends on a 32-bit boundary. |
TCP is a complex, time-consuming protocol due to its connection mechanism, but it takes care of guaranteed packet delivery without having to include this functionality in the application protocol.
The TCP protocol has a built-in reliable delivery capability. If the message is not sent correctly, we will receive an error message. The TCP protocol is defined in RFC 793.
UDP - User Datagram Protocol
Unlike TCP, UDP is a very fast protocol because it defines the most minimal mechanism needed to transfer data. Of course, it has some drawbacks. Messages arrive in any order, and the one sent first may be received last. Delivery of UDP messages is by no means guaranteed, the message may get lost, and two copies of the same message may be received. The latter case occurs when two different routes are used to send messages to the same address.
UDP does not require a connection to be opened, and data can be sent as soon as it is prepared. UDP does not send acknowledgment messages, so data can be received or lost. If reliable data transmission is required when using UDP, it should be implemented in a higher layer protocol.
So what are the advantages of UDP, why might such an unreliable protocol be needed? To understand the reason for using UDP, one must distinguish between unicast, broadcast, and multicast.
Unicast message is sent from one node to only one other node. This is also called point-to-point communication. The TCP protocol only supports unidirectional communication. If a server needs to communicate with multiple clients using TCP, each client must establish a connection because messages can only be sent to single nodes.
Broadcast transmission (broadcast) means that the message is sent to all nodes in the network. Group mailing (multicast) is an intermediate mechanism: messages are sent to selected groups of nodes.
UDP can be used for unidirectional communications when fast transmission is required, such as for media delivery, but the main advantages of UDP are in broadcast and multicast.