Size of data packets sent by TCP and UDP protocols

Source: Internet
Author: User

During UDP programming, the most common question is how many bytes are sent at a time?

Of course, there is no unique answer. The answer is different from the requirements of different systems. Here we only analyze the situation of sending chat messages like ICQ, in other cases, you may be able to get some help:

First, we know that TCP/IP is generally considered as a layer-4 protocol system, including the link layer, network layer, transport layer, and application layer. UDP belong to the transport layer. Let's look at it from the next step:

The length of an Ethernet data frame must be between-bytes, which is determined by the physical characteristics of the Ethernet. this 1500 byte is called the MTU (maximum transmission unit) of the link layer ). however, this does not mean that the link layer length is limited to 1500 bytes. In fact, this MTU refers to the data area of the link layer. it does not include 18 bytes at the beginning and end of the link layer.

Therefore, in fact, this 1500 byte is the length limit of network layer IP datagram. because the IP datagram header is 20 bytes, the IP datagram data zone length is up to 1480 bytes. the 1480 byte is used to store TCP packet segments or UDP datagram from UDP. because the first 8 bytes of the UDP datagram, the maximum length of the UDP datagram data zone is 1472 bytes. this 1472 byte is the number of bytes that we can use. :)

What happens when we send UDP data greater than 1472? This means that the IP datagram is greater than 1500 bytes and greater than MTU. in this case, fragmentation is required for the sender's IP layer ). divides the datagram into several slices so that each segment is smaller than MTU. the receiver's IP layer needs to reorganize the datagram. in this way, we will do more things. More seriously, due to the characteristics of UDP, when a piece of data is lost during transmission, it is easy to receive and cannot reorganize the datagram. the entire UDP datagram is discarded.

Therefore, in a common LAN environment, it is recommended that UDP data be controlled below 1472 bytes.
When programming the Internet, the MTU may be set to different values on the internet router. if we assume that the MTU is 1500 to send data, and the MTU value of a network passing through is smaller than 1500 bytes, the system will use a series of mechanisms to adjust the MTU value, enable the datagram to reach the destination smoothly, and then perform many unnecessary operations. since the standard MTU value on the internet is 576 bytes, we recommend that you perform UDP programming on the Internet. we recommend that you set the UDP data length to within 548 bytes (576-8-20.

Theoretically, the maximum length of an IP datagram is 65535 bytes, which is limited by the 16-bit total length field of the IP header. Remove the 20-byte IP header and 8-byte UDP header. The maximum length of user data in UDP datagram is 65507 bytes. However, the length provided by most implementations is smaller than the maximum value.

We will encounter two restrictions.

First, applications may be restricted by their program interfaces. The socket API provides a function that can be called by a program to set the length of the receiving and sending cache. For UDP socket, this length is directly related to the maximum UDP datagram length that the application can read and write. Most systems now provide UDP datagram that can read and write more than 8192 bytes by default (this default value is used because 8192 is the default value for NFS to read and write user data ).

The second restriction comes from the TCP/IP kernel implementation. There may be some implementation features (or errors), so that the IP datagram length is less than 65535 bytes.
In SunOS 4.1.3, the maximum IP datagram length of the loopback interface is 32767 bytes. Errors may occur if the value is greater than the value.
However, in the case of BSD/386 to SunOS 4.1.3, sun can receive a maximum IP datagram of 32786 bytes (32758 bytes of user data ).
Use the loopback interface in Solaris 2.2. the maximum length of IP data packets that can be sent and received is 65535 bytes.
From Solaris 2.2 to Aix 3.2.2, the maximum length of IP datagram sent can be 65535 bytes. Obviously, this restriction is related to the implementation of the source and target terminals.

The host must be able to receive IP datagram with a minimum of 576 bytes. In the design of Many UDP applications, the application data is limited to 512 bytes or smaller, so it is smaller than this limit value.

Because the IP address can send or receive data of a specific length, it does not mean that the receiving application can read data of this length. Therefore, the UDP programming interface allows an application to specify the maximum number of bytes returned each time. What happens if the received datagram is longer than the length that the application can process? Unfortunately, the answer to this question depends on the programming interface and implementation.

A typical Berkeley Socket API truncates data packets and discards any redundant data. The time when the application can know is related to the version (4.3bsd Reno and later versions can notify the application datagram to be truncated ).

The socket API (including Solaris 2.x) under svr4 does not intercept the datagram. The excess data is returned in subsequent reads. It does not notify the application to read data from a single UDP datagram multiple times. TLI APIs do not discard data. Instead, it returns a flag indicating that more data can be obtained, and the read operation after the application will return the rest of the datagram. When discussing TCP, we found that it provides continuous byte streams for the application without any information boundaries. TCP transmits data according to the length required by the read operation of the application. Therefore, no data loss occurs in this interface.

 

Certificate ----------------------------------------------------------------------------------------------------------------------------------------------------
**************************************** **************************************** **************************************** ****************************
Size of packets sent by TCP and UDP protocols (Analysis)


The maximum transmission unit of the MTU is closely related to the link layer protocol. Due to the electrical limitations of Ethernet transmission, the structure of the ethernetii frame DMAc + SMAC + Type + Data + CRC, each Ethernet frame has a minimum size of 64 bytes and a maximum size of 1518 bytes. For an Ethernet frame smaller than or greater than this limit, we can regard it as a wrong data frame, generally, Ethernet forwarding devices discard these data frames.

Since the maximum data frame of Ethernet ethernetii is 1518bytes, deplane the frame header of an Ethernet frame (DMAc destination MAC address 48bit = 6 bytes + SMAC source MAC address 48bit = 6 bytes + type domain 2 bytes) 14 bytes and the CRC check at the end of the frame is 4 bytes, so the rest of the places that carry the upper-layer protocol, that is, the maximum data domain can only have bytes, which we call MTU.

The so-called pppoe protocol runs the PPP protocol over Ethernet. Is it strange that the PPP protocol and Ethernet are not both link layer protocols? Why does one link layer go to another link layer? Cannot it be upgraded to a network layer protocol. In fact, this is a misunderstanding: a certain layer of Protocol can only carry a higher layer of protocol.

Why is this strange demand? This is because with broadband access (this type of broadband access is generally cable modem or XDSL or Ethernet access ), due to the lack of authentication and billing mechanisms for Ethernet, traditional carriers use the PPP protocol to authenticate and charge for dial-up and other access services.

Pppoe brings both benefits and some disadvantages, such as resource consumption by secondary encapsulation and reduced transmission efficiency. I will not talk about these disadvantages, the biggest disadvantage is that pppoe makes MTU smaller, and the MTU of Ethernet is 1500, Which is 1492 less than the overhead of the PPP packet header (8 bytes.

The UDP packet size should be 1492-IP header (20)-udp header (8) = 1464 (bytes)
The TCP packet size should be 1492-IP header (20)-TCP Header (20) = 1452 (bytes)

Currently, the MTU of most routing devices is 1500.
My understanding is: if the TCP and UDP packets we define are smaller than 1452,1464, we do not need to subcontract the packets on the IP layer, in this way, errors in IP layer group packets are avoided during transmission. If the UDP protocol is used, if an error occurs in the IP layer group package, the packet will be discarded, and UDP does not guarantee reliable transmission. However, when a group packet error occurs in TCP, the packet will be re-transmitted to ensure reliable transmission. Therefore, when we use socket programming, the package size setting does not have to be smaller than 1400, UDP requires the package to be smaller than 64 K, and TCP is not limited.

Summary:

We set the package size to be different for UDP and TCP Protocols. The key is to view system performance and network performance.

If the network is in a good local area network, the UDP packet is larger to improve the system performance. Otherwise, the packet loss rate is reduced by less than 1464. For TCP, this depends on experience, because TCP packet loss can be automatically re-transmitted, and the system performance is improved. packet forwarding and error restructuring may take time, this reduces the transmission time and system performance. From: http://hi.baidu.com/laoyang1018/blog/item/89d463d98bb8643711df9be8.html

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.