Similarities and differences between TCP, UDP and RTP (RTCP)

Original address: http://www.cnblogs.com/imystr/p/4026639.html

OSI Seven layer model
Layer-Functional TCP/IP protocol family in OSI
Application-layer file transfer, email, file service, virtual terminal tftp,http,snmp,ftp,smtp,dns,telnet
Presentation layer data format, code conversion, data encryption No protocol
Session layer release or establish contact with other contacts no agreement
The Transport layer provides end-to-end interface tcp,udp (RTP)
Network layer selects routing Ip,icmp,rip,ospf,bgp,igmp for packets
The data link layer transmits the frame with the address and the error detection function SLIP,CSLIP,PPP,ARP,RARP,MTU
The physical layer transmits data on the physical media as binary data iso2110,ieee802,ieee802.2

*************************************************************************************************************** *********************

TCP/IP five-layer Model protocol

Application Layer
Transport layer: Four-layer switch, also has a router that works on the four level

Network layer: Router, three layer switch

Data Link layer: Network Bridge (now rarely used), Ethernet switch (two-tier switch), Nic (in fact, the network card is half the work in the physical layer, half of the work in the Data link layer)

Physical layer: Repeater, hub, and we usually say twisted pair also work on the physical layer

*************************************************************************************************************** ***********************

An analysis of RTP protocol

1, RTP overview

1.1. What is RTP?

The RTP full name is the real-time transport Protocol (Real-time transport protocol). It is a standard proposed by the IETF, and the corresponding RFC document is RFC3550 (RFC1889 is its outdated version). RFC3550 not only defines RTP, but also defines the associated protocol RTCP (real-time transport control Protocol, the Real-time Transport protocol). RTP is used to provide end-to-end real-time transmission services for many multimedia data which require real-time transmission in voice, image, facsimile and so on IP network. RTP provides time information and stream synchronization for real-time transmission on the upper end of the Internet, but does not guarantee service quality and service quality is provided by RTCP.

Application environment of 1.2. RTP

RTP is used to transmit real-time data in a unicast or multicast network. They are typically used in a number of situations.

(1) Simple multicast audio conferencing. Voice communication is implemented through a multicast address and a pair of ports. One for audio data (RTP) and another for control packs (RTCP).

(2) Audio and video conferencing. If both audio and video conferencing are used in a single meeting, the two media will be routed in different RTP sessions, each using a different transport address (IP address + port). If a user uses two sessions at the same time, each session corresponds to a RTCP package that uses the canonical name CNAME (Canonical name). Attendees can obtain the associated audio and video based on the CNAME in the RTCP package, and then synchronize audio and video according to the timing information in the RTCP package (Network Time Protocol).

(3) Translators and mixers. Both the translator and the mixer are RTP-level relay systems. The translator has a firewall between the user areas that cannot be reached directly through IP multicast, such as between the sender and the receiver. When attendees receive a different audio encoding format, such as having an attendee connect to a high-speed meeting via a low-speed link, the mixer is used. Before entering the network where the audio data format needs to change, the mixer reconstructs the audio packets from one source or multiple sources, merges the reconstructed audio, and encodes the new RTP packet with another audio encoding. All packets coming out of a mixer are identified by using a mixer as their sync source (SSRC, see RTP encapsulation) and can be identified by contributing to the source list (the  table, see RTP encapsulation).

1.3. Streaming media

Streaming media refers to the continuous-time base media using streaming transmission technology on the Internet. Currently there are two main ways to transmit audio and video on the Internet: downloading and streaming.

Download, the user needs to download the entire media file to local before the media file can be played. In the video broadcast and other applications, due to the generation of the entire media file to wait for the end of the live broadcast, that is, the user at least after the live broadcast to see the live program, so the download method can not be achieved live.

Streaming transmission is the key technology to realize streaming media. Use streaming to view streaming media programs while downloading. Because the Internet is based on packet transmission, packets received at the receiving end tend to have delays and chaos (streaming traffic is built on UDP). To achieve streaming, you start by reducing the latency and recovery packet timing. On the sender side, the transmission data is often preprocessed (reduced quality and efficient compression) to reduce latency. In order to restore the timing, the receiving buffer is used and the playback buffer is used to realize the smooth playback of the media.

By using the receive buffer, you can cache the packets received and then reorder the ordered packets based on the packet's encapsulation information (such as the package sequence number and timestamp), and finally put the reordered packets into play buffer.

Why do I need to play the buffer? It is easy to think that, because the network can not be ideal, and the packet ordering needs to be processed, we get sorted packets of time interval is unequal. If you do not play the buffer, then the show will be very card, which is called delay jitter. On the contrary, using playback buffer, when starting playback, it takes dozens of seconds to fill in the playback buffer (for example, PPLive), which can effectively eliminate the delay jitter, so as to realize the smooth playback of streaming media without too much loss of real-time performance.

Up to now, there are three major streaming video formats used on the Internet: the RealNetworks Company's RealMedia, Apple's QuickTime, and Microsoft's Advanced streaming Format (ASF).

When it comes to receiving buffers, the package information (packet number and time stamp, etc.) of streaming media packets will be reflected in the RTP package later. In addition, RealMedia these streaming media formats are only different codecs, but for RTP, they are to be encapsulated the transfer of streaming media data without any difference.

2, RTP detailed

2.1. RTP protocol Hierarchy

2.1.1. The child layer of the Transport layer

RTP (Real-time Transfer Protocol), as the name suggests it is used to provide real-time transmission, and thus can be considered as a layer of transport layers. Figure 1 shows a typical protocol architecture in streaming media applications. Figure 2 shows the relationship between the RTP protocol and other protocols.

Figure 1 Streaming Media architecture

Fig. 2 Relationship between RTP protocol and other protocols

RTP, TCP and UDP all belong to transport layer protocol; RTP can also be considered between the application layer and the Transport layer

As can be seen from the diagram, RTP is divided into the transport layer, which is based on UDP. As with the UDP protocol, RTP has a fixed encapsulation form in order to realize its real-time transmission function. RTP is used to provide time information and stream synchronization for end-to-end real-time transmission, but does not guarantee quality of service. The quality of service is provided by RTCP.

2.1.2. Part of the application layer

Many people also classify RTP as part of the application layer, which is from the perspective of the application developer. TCP/IP in the operating system and other protocol stacks provide the most commonly used services, and the implementation of RTP still depends on the developers themselves. So from the development point of view, the implementation of RTP and Application layer protocol is not different, so RTP can be regarded as application layer protocol.

RTP implementation in the delivery of RTP data, you need to encapsulate the data into a RTP package, and in the received RTP packet, the data need to be extracted from the RTP package.

2.2. RTP Encapsulation

The encapsulation of a protocol is designed to meet the functional requirements of the Protocol. From the previous functional requirements, it can be inferred that the RTP package should have synchronization source and time stamp fields, but a more complete package is what it looks like. Take a look at Figure 3.

Fig. 3 RTP Header Format

Version number (V): 2 bits, used to mark the use of RTP version.

Padding bit (P): 1 bits, if the position is bit, then the tail of the RTP package contains additional padding bytes.

Extension bit (X): 1 bits, if the position is a bit, the RTP fixed head is followed by an extended head.

The counter (CC): 4 bits containing the number of the regulatory commission followed by a fixed head.

Tag bit (M): 1 bits, the interpretation of this bit is assumed by the configuration document (profile).

Load Type (PT): 7 bits, identifies the type of RTP payload.

Serial Number (SN): 16 bits, the sender after each send a RTP packet will increase the value of the domain 1, the receiver can be detected by the domain packet loss and recovery package sequence. The initial value of the serial number is random.

Timestamp: 32 bits that record the sampling time of the first byte of the data in the packet. At the beginning of a session, the timestamp is initialized to an initial value. Even when there is no signal to send, the timestamp value will increase over time (time goes by). Timestamps are essential for removing jitter and implementing synchronization.

Sync source Identifier (SSRC): 32 bits, the sync source is the source of the RTP packet stream. You cannot have two identical SSRC values in the same RTP session. The identifier is a randomly selected RFC1889 recommendation of the MD5 stochastic algorithm.

Contribution source list (regulatory list): The 0~15 item, each 32 bits, is used to flag the source of all RTP packages that contribute to a new package generated by a RTP mixer. The mixer inserts these contributing SSRC identifiers into the table. SSRC identifiers are listed so that the receiver can correctly identify both sides of the conversation.

Encapsulation of 2.3. RTCP

RTP requires RTCP to provide assurance for its quality of service, so here's a brief introduction to RTCP's knowledge.

The main functions of RTCP are: quality of service monitoring and feedback, synchronization between media, and identification of members in a multicast group. During the RTP session, the participants periodically transmit RTCP packets. The RTCP package contains statistics such as the number of packets sent and the number of packets lost, so that each participant can use the information to dynamically change the transmission rate and even change the payload type. RTP and RTCP are used in conjunction with effective feedback and minimal overhead to optimize transmission efficiency, and are therefore particularly suitable for the transmission of real-time data on the Web.

As you can see from Figure 1, RTCP is also transmitted using UDP, but RTCP encapsulates only some control information, so the packets are very short, so you can encapsulate multiple RTCP packets in a single UDP packet. The following five groups of RTCP are

Table 1 RTCP 5 Types of grouping

The encapsulation of the five groupings is similar, and the following only describes the SR type, while the other types refer to RFC3550.

The sending End reports group SR (Sender Report) is used to enable the sender to report to all the receiving end in multicast mode. The main contents of the SR packet are: The time stamp of the latest RTP grouping in the SSRC,RTP stream of the corresponding RTP stream and the number of packets included in the NTP,RTP stream, and the number of bytes in the RTP stream. The encapsulation of the SR package is shown in Figure 3.

Fig. 3 The format of RTCP head

Version (V): Same RTP header field.

Padding (P): Same RTP header field.

Receive report Counter (RC): 5 bits, the number of receive report blocks in the SR package, can be zero.

Package Type (PT): 8 bits, SR package is 200.

Length field: 16 bits, which store the SR package with a total length of 32 bits minus one.

Sync Source (SSRC): The synchronization source identifier for the SR packet sender. The same as the SSRC in the RTP package.

The absolute time value of the NTP Timestamp (Network Times Protocol) SR packet when it is sent. The role of NTP is to synchronize different RTP media streams.

RTP Timestamp: Corresponding to the NTP timestamp, has the same unit and random initial value as the RTP timestamp in the RTP packet.

Sender ' s packet count: The total number of RTP packets sent by the sender from the beginning of the packet to the time the SR package was generated. When SSRC changes, this field is zeroed.

Sender ' s octet count: The total number of bytes (excluding headers and fills) sent by the sender for the period from which the packet was sent to the SR package. When the sender changes its ssrc, the field needs to be zeroed.

SSRC identifier of the synchronization source N: The report block contains statistics for packets received from the source.

Loss rate (fraction Lost): Indicates the loss rate of RTP packets from the sync source N (ssrc_n) since the last SR or RR Packet was issued.

Cumulative number of packets lost: The total number of RTP packets passed from the Ssrc_n from the beginning of the Ssrc_n packet to the outgoing Sr.

Extended Maximum serial number received: The largest serial number in RTP packets received from Ssrc_n,

Receive Jitter (Interarrival jitter): Statistical variance estimation for RTP packet acceptance time

Last SR,LSR: The middle 32 bits of the NTP timestamp in the most recent SR package received from Ssrc_n. If the SR package is not currently received, the domain is cleared zero.

Latency since the last SR (Delay since last SR,DLSR): The delay in receiving the SR packet from Ssrc_n to send this report.

2.4. RTP Session Process

When an application establishes a RTP session, the application determines a pair of destination transport addresses. Destination transport address consists of a network address and a pair of ports, with two ports: one to the RTP packet, one to RTCP packet, so that the RTP/RTCP data can be sent correctly. RTP data is sent to even UDP ports, and the corresponding control signal RTCP the data to the adjacent odd UDP port (even UDP port +1), which constitutes a UDP port pair. RTP is sent as follows, and the reception process is reversed.

1 The RTP protocol receives the stream media information stream (such as H.263) from the upper layer, encapsulates the RTP data packet, RTCP receives the control information from the upper layer and encapsulates it into the RTCP control package.

2 RTP to the RTP packet to the UDP port pair in the even port, rtcp the RTCP control packet to the UDP port pair in the receive port.

Second, TCP protocol analysis

1. Introduction to TCP protocol

TCP, full name transfer Control Protocol, is known as Transmission Control Protocol, which works on the OSI Transport layer, providing reliable connection-oriented transport services.

The main task of TCP is to establish a connection and then receive data from the application-tier program and transfer it. TCP uses the virtual Circuit connection method to work, before sending the data it needs to establish a connection between the sender and the receiver, the data is sent out, the sender waits for the receiver to give a confirmation reply, otherwise the sender will think this data is lost, and resend this data.

2, TCP header

The TCP header length is a minimum of 20 bytes, and its header structure is shown in the following figure (Figure 1);

Bit 0 bit 15 bit 16 bit 31

Source Ports (16)

Destination Port (16)

Serial Number (32)

Confirmation Number (32)

TCP Offset (4)

Reservations (6)

Signs (6)

Windows (16)

checksums (16)

Emergency (16)

Options (0 or 32)

Data (variable)

(Figure 1 TCP header structure)

SOURCE port: Port specified for Send port

Destination port: Specifies the port number of the accepted port

Ordinal: Indicates the position of the segment in the sequence of segments that are about to be transmitted

Confirmation Number: Specify that the serial number of the segment is successfully received, and that the serial number contains the next serial number expected to be received at the end of the sending confirmation

TCP Offset: Specifies the length of the segment header. The length of the Chito depends on the options set in the Segment Header option field

Reserved: A reserved field was specified for future use

Logo: SYN, ACK, PSH, RST, URG, FIN

SYN: Indicates synchronization

ACK: Indicates confirmation

PSH: means to send data to the receiving process as soon as possible

RST: Indicates a reset connection

URG: Indicates an emergency pointer

FIN: Indicates that the sender completes sending data

window: Specifies instructions about the size of the next paragraph that can be transmitted by the sender

Checksum: Checksum contains TCP segment headers and data portions to verify the reliability of segment headers and data parts

Emergency: The specified paragraph contains emergency information, only if the U R G flag is placed 1 o'clock the emergency pointer is valid

Options: Specifies the recognized segment size, timestamp, the end of the option field, and the boundary options that specify the option field

3, TCP working principle

TCP connection establishment: TCP's connection establishment process is also called TCP three times handshake. First, the sending host initiates a synchronous (SYN) request to the receiving host, and the receiving host replies a synchronous/acknowledgment (Syn/ack) response to the sending host after receiving the request, and the sending host sends a confirmation (ACK) to the receiving host after receiving the packet. TCP connections are successfully established at this time;

TCP connection shutdown: After the sender host and the destination host establish a TCP connection and complete the data transfer, a packet that will end the tag of 1 is sent to close the TCP connection while releasing the buffer space occupied by the connection; TCP Reset: TCP allows for a sudden disconnect during transmission, This is known as a TCP reset;

TCP Data Sorting and acknowledgement: TCP is a reliable transmission protocol, which uses serial numbers and acknowledgement numbers to track the reception of data in the process of transmission;

TCP retransmission: In the TCP transmission process, if in the retransmission timeout time does not receive the receiving host to a certain packet confirmation reply, the sender host thinks this packet is lost, and sends this data packet again to the receiver, this is called the TCP retransmission;

TCP delay Acknowledgement: TCP does not always acknowledge data immediately after it is received, allowing the host to send its own acknowledgement to each other while receiving the data.

TCP Data Protection (checksum): TCP is a reliable transport protocol that provides checksum computation to achieve data integrity during transmission.

Three, UDP protocol analysis

1. Introduction to UDP

The UDP protocol is the abbreviation of the English userdatagramprotocol, the User Datagram protocol, which is mainly used to support network applications that need to transfer data between computers. The UDP protocol is needed for the network applications of many client/server modes including the network video conferencing system. The UDP protocol has been in use for many years since its inception, although its initial brilliance has been overshadowed by similar protocols, but even today, UDP is a very practical and feasible network transport protocol.
Like our well-known TCP (Transmission Control Protocol) protocols, the UDP protocol is directly at the top of the IP (Internet Protocol) protocol. According to the OSI (Open Systems Interconnection) Reference model, both UDP and TCP belong to the Transport layer protocol.
The main function of UDP protocol is to compress the network data traffic into the form of datagram. A typical datagram is a transmission unit of binary data. The first 8 bytes of each datagram are used to contain header information, and the remaining bytes are used to contain the specific transmitted data.
2, UDP protocol structure
The UDP header consists of 4 domains, each of which occupies 2 bytes, as follows:
Source port number, destination port number, datagram length, and checksum value.
The UDP protocol uses the port number to retain its own data transmission channel for different applications. This mechanism is used by UDP and TCP protocols to support the simultaneous sending and receiving of data for multiple applications at the same time. The data sender (either the client or the server side) sends the UDP datagram through the source port, while the data receiver receives the data through the destination port. Some network applications can only use static ports that are reserved or registered in advance, while others may use dynamic ports that are not registered. Because the UDP header uses two bytes to store the port number, the valid range for the port number is from 0 to 65535. In general, port numbers greater than 49151 represent dynamic ports.
The length of the datagram refers to the total number of bytes, including the header and data portions. Because the length of the header is fixed, the field is used primarily to compute the variable-length data portion (also called the data payload). The maximum length of datagrams varies according to the operating environment. In theory, the maximum length of a datagram containing a header is 65535 bytes. However, some practical applications tend to limit the size of datagrams, sometimes down to 8192 bytes.
The UDP protocol uses the checksum value in the header to secure the data. The checksum is first computed by a special algorithm on the sender of the data, which needs to be recalculated after being passed to the receiving party. If a datagram is tampered with by a third party during transmission or is damaged due to line noise, the sending and receiving checksum calculation values will not match, and the UDP protocol can detect errors. This is different from the TCP protocol, which requires that a checksum value be required.

Comparison of four or three protocols

RTP is located above UDP, UDP is not as reliable as TCP, and can not guarantee the service quality of real-time services, it needs RTCP real-time monitoring data transmission and quality of service, but because the transmission delay of UDP is lower than TCP, can match with video and audio well. Therefore, in practical applications, RTP/RTCP/UDP is used for audio/video media, while TCP is used for data and control signaling transmission.

The main difference between UDP and TCP is that the two differ in how to achieve reliable transmission of information. The TCP protocol includes a special delivery guarantee mechanism, and when the data receiver receives the message from the sender, it automatically sends a confirmation message to the sender, and the sender will wait until the confirmation message is received before it continues to transmit other information.

So TCP will have more than UDP time to establish the connection. TCP has higher security and reliability relative to UDP. TCP protocol transmission size is not limited, once the connection is established, the two sides can be in a certain format to transmit a large number of data, and UDP is an unreliable protocol, the size is limited, each time can not exceed 64K.

In contrast to the TCP protocol, another difference in UDP protocol is how to receive multiple datagrams of the process. Unlike TCP,UDP, it does not guarantee the order in which data is sent and received.

The performance comparison of the three is shown in table 1.

Table 13 Performance Comparison of protocols

Agreement name

Complexity

Connection built

Immediately

Reliability

Ensure the order in which datagrams are sent and accepted

Real-time performance

Applicable scope

Whether to support multicast

Rtp/rtcp

Low

Less

Low

Whether

Is

Real-time Audio viewing

Frequency Media transmission

Support

Tcp

High

Many

High

Is