The size of the packet sent by the TCP and UDP protocols

Reproduced from: http://blog.chinaunix.net/uid-20180960-id-2998594.html, thank the author.

When it comes to UDP programming, the easiest question we can think about is how many bytes are sent at a time?

Of course, this does not have the only answer, compared to different systems, different requirements, the answer is not the same, here just like the ICQ type of sending chat messages to analyze, for other cases, may also get a little help:
First, we know that TCP/IP is often considered a four-layer protocol system, including link layer, network layer, Transport layer, application layer. UDP belongs to transport layer, below we from down to the previous step to see:
The length of the Ethernet (Ethernet) data frame must be between 46-1500 bytes, which is determined by the physical characteristics of the Ethernet. This 1500 byte is called the MTU of the link layer (the Maximum transmission unit). But this does not mean that the length of the link layer is limited to 1500 bytes, In fact, this MTU refers to the data area of the link layer. Does not include the link layer header and the trailing 18 bytes. So, in fact, this 1500 byte is the length limit of the network layer IP datagram. Because the header of the IP datagram is 20 bytes, Therefore, the data of the IP datagram has a maximum of 1480 bytes. And this 1480 byte is used to put TCP packets or UDP transmitted UDP datagram. And because the first 8 bytes of the UDP datagram, Therefore, the maximum data area length for a UDP datagram is 1472 bytes. This 1472 byte is the number of bytes we can use. :)
What happens when we send more UDP data than 1472? This means that the IP datagram is larger than 1500 bytes, which is greater than the MTU. This time the sender IP layer needs to be fragmented (fragmentation). Divide the datagram into pieces so that each piece is smaller than the MTU. The receiver IP layer needs to be reorganized for the datagram. So there's a lot more to be done, What's more, because of the characteristics of UDP, when a piece of data transmission is lost, the reception is not able to reorganize the datagram. Causes the entire UDP datagram to be discarded.
Therefore, in a normal LAN environment, I recommend that the UDP data control under 1472 bytes is good.
Internet programming is different because routers on the Internet may set the MTU to a different value. If we assume that the MTU is sending data to 1500来, and that the MTU value of a network passing through is less than 1500 bytes, then the system will use a series of mechanisms to adjust the MTU value , so that the datagram can get to the destination smoothly, so there are many unnecessary actions. Because the standard MTU value on the Internet is 576 bytes, I recommend that you make UDP programming on the Internet. It is best to have UDP data-length controls within 548 bytes (576-8-20).

In theory, the maximum length of an IP datagram is 65535 bytes, which is limited by the IP header 16-bit total Length field. Remove the 20-byte IP header and the 8-byte UDP header, and the maximum length of user data in the UDP datagram is 65507 bytes. However, most implementations provide a smaller length than this maximum value.
We will encounter two limiting factors. First, the application may be limited by its program interface. The socket API provides a function that the application can call to set the length of the receive and send caches. For UDP sockets, this length is directly related to the length of the maximum UDP datagram that the application can read and write. Most systems now default to read and write UDP datagrams that are larger than 8192 bytes (using this default value because 8192 is the default for NFS read and write user data).
The second limitation is the kernel implementation from TCP/IP. There may be some implementation features (or errors) that make the IP datagram length less than 65535 bytes.
The maximum IP datagram length using the loopback interface under SunOS 4.1.3 is 32767 bytes. A value larger than it will go wrong.
However, from bsd/386 to SunOS 4.1.3, Sun can receive a maximum IP datagram length of 32786 bytes (that is, 32758 bytes of user data).
With the loopback interface under Solaris 2.2, the maximum IP datagram length is 65535 bytes.
The maximum IP datagram length that is sent from Solaris 2.2 to Aix 3.2.2 can be 65535 bytes. Obviously, this limitation is related to the implementation of the source and destination ends.
The host must be able to receive an IP datagram with a minimum of 576 bytes. In the design of many UDP applications, the application data is limited to 512 bytes or less, so it is less than this limit value.
Because IP can send or receive datagrams of a specific length does not mean that the receiving application can read data of that length. Therefore, the UDP programming interface allows the application to specify the maximum number of bytes to return each time. What happens if you receive a datagram that is longer than the length your application can handle. Unfortunately, the answer to this question depends on the programming interface and implementation.
A typical version of the Berkeley socket API truncates datagrams and discards any excess data. When the application knows, it is related to the version (4.3BSD Reno and later versions can notify the application that the datagram is truncated).
The socket API under SVR4 (including Solaris 2.x) does not truncate datagrams. The partial data is returned in subsequent reads. It also does not notify the application to read from a single UDP datagram multiple times. The TLI API does not discard data. Instead, it returns a flag indicating that more data can be obtained, and the subsequent read of the application returns the remainder of the datagram. When we discuss TCP, we find that it provides a continuous stream of bytes to the application without any information boundaries. TCP transmits data at the length required by the application read operation, so there is no data loss under this interface.

--------------------------------------------------------------------------------------------------------------- -------------------------------------
*************************************************************************************************************** *************************************
The size of the packet sent by the TCP and UDP Protocol (analysis)
MTU Maximum Transmission unit, the largest transmission unit is actually closely related to the link layer protocol, the structure of the ethernetii frame DMAC+SMAC+TYPE+DATA+CRC due to the electrical limitations of Ethernet transmission, Each Ethernet frame has a minimum size of 64bytes maximum can not exceed 1518bytes, for less than or greater than the limit of the Ethernet frame can be regarded as the wrong data frame, the general Ethernet forwarding device will discard these data frames.


Since the Ethernet ethernetii maximum data frame is 1518Bytes, the frame header of the Ethernet frame is planed (Dmac destination MAC address 48bit=6bytes+smac source MAC address 48bit=6bytes+ Type field 2bytes) 14Bytes and frame tail CRC checksum part 4Bytes so the rest of the upper layer protocol is the data domain the largest can only have 1500Bytes this value we call it the MTU.

PPPoE so-called PPPoE is running on the Ethernet PPP protocol, it is strange that the PPP protocol and Ethernet are not all link layer protocol. How does a link layer go up to another link layer, or upgrade to a network layer protocol? In fact, this is a misunderstanding: is a layer of protocol can only carry a more layer of protocol.

Why is this strange demand? This is because with the broadband access (the broadband access is generally cable modem or xDSL or Ethernet access), because the Ethernet lack of authentication billing mechanism and traditional operators through the PPP protocol to the Dial-up and other access services authentication billing.

PPPoE brings advantages, but also brings some disadvantages, such as: two times the package consumes resources, reduce the transmission efficiency, and so on, these disadvantages I do not say, the biggest disadvantage is that PPPoE caused the MTU to become smaller Ethernet MTU is 1500, minus the overhead of the packet tail of the PPP (8Bytes), It becomes 1492.

UDP packet size should be 1492-IP-UDP header (8) = 1464 (BYTES)
The TCP packet size should be 1492-IP header (+)-TCP header (+) = 1452 (BYTES)

Most routing devices currently have an MTU of 1500
My understanding of the above is: if we define TCP and UDP packets less than 1452,1464, then our package at the IP layer will not be sub-packet, so that the transfer process will avoid the IP layer package errors. If the UDP protocol is used, if an error occurs in the IP layer packet, the packet is discarded and UDP is not guaranteed to transmit reliably. However, when TCP has a packet error, the packet is re-transmitted and guaranteed to be transmitted reliably. Therefore, when we use the socket programming, the package size setting is not necessarily less than the 1400,UDP protocol requires that the packet is less than 64k,tcp not qualified.




Summarize:

We set the size of the packet for the UDP and TCP protocol is different, the key is to look at the system performance and network performance, the network is a good state of the LAN, then the UDP packet large points, improve the performance of the system. Not good, the score is less than 1464, this can reduce the packet loss rate. For TCP, this relies on experience, because TCP drops can be automatically re-transmitted, divided into large, system performance improved, subcontracting and error reorganization may be time-consuming, so that the transmission time is extended, smaller, the system is reduced.