RTSP and HTTP protocol

Live from the RTSP protocol (Transport Media stream) to the HTTP TS (ts shard after TS partition encoder, HTML file) (Apple's live streaming scenario) conversion effort.

HTTP Live Streaming (abbreviated as HLS) is an HTTP-based streaming network Transfer protocol proposed by Apple. is part of Apple's QuickTime X and iphone software system. It works by dividing the entire stream into small HTTP-based files to download, one at a time. When media streaming is playing, clients can choose to download the same resources at different rates from many different alternative sources, allowing streaming media sessions to accommodate different data rates. When you start a streaming session, the client downloads a extended m3u (m3u8) playlist file that contains metadata to find the available media streams.
HLS only requests basic HTTP messages, and unlike real-time Transport Protocol (RTP), HLS can pass through any firewall or proxy server that allows HTTP data to pass through. It is also easy to use a content distribution network to transfer media streams.
Apple introduced the HLS protocol as an Internet draft (progressive submission), which was submitted to the IETF as an informal standard in the first phase. However, even if Apple occasionally submits some minor updates, the IETF has no further action on setting this standard.

First, RTSP
1. Introduction
Real time Streaming protocol live streaming protocol, is the application layer protocol, control the transmission of real-time data. It provides a scalable framework that enables the ability to control on-demand transmission of real-time data. However, RTSP itself does not send continuous media stream, only serves as the network remote control of multimedia server.
2, the characteristics of the agreement
? Extensibility: It's easy to add new methods and parameters.
? Easy to parse: can be parsed by a standard HTTP or MIME parser.
? Security: Use the Web security mechanism, or you can use the transport layer or the network layer Security mechanism.
? Independent transfer:You can use Unreliable Datagram Protocol (UDP), Reliable Datagram Protocol (RDP), or you can use a reliable streaming protocol if you want to achieve application-level reliability.
? Multi-server support
? Recording Device control: The protocol controls the recording and playback devices.
? Flow control and meeting start separation
? Suitable for professional applications: Supports frame-level accuracy and allows remote digital editing.
? Indicates a description of neutrality
? Agent-to-firewall-friendly: can be handled by the application layer and the Transport layer firewall.
?http friendly: Many definition grammars are similar to http/1.1
? Transport coordination
? Performance coordination
3. Message Format
The RTSP message consists of a client-to-server request and a server-to-client response.
Rtsp-message = Request | Response; rtsp/1.0 messages
Both request and response (Response) messages use the message format specified in the Entity Transport Section in RFC822. Both messages can include a starting line, one or more header fields (headers), a line representing the empty line at the end of the header field (that is, a row with no content before CRLF), and a message body (message-body).
Generic-message = Start-line
*message-header
CRLF
[Message-body]
Tart-line = Request-line | Status-line
For robustness reasons, the server should ignore any empty rows that are received when the request is expected to be received. In other words, if the server is reading the protocol stream, the CRLF character should be ignored if the CRLF is first received at the beginning of a message.
The RTSP header domain includes the main header, the request header, the response header, and the entity header, all in accordance with the common format definition given by RFC822. Each header field consists of a first name followed by a colon, a single space (SP), a character, and a field value. Domain names are case-sensitive.
Rtsp-header = field-name ":" [Field-value] CRLF
Field-name = Token
Field-value = * (Field-content | LWS)
Field-content = <the OCTETs make up the Field-value
and consisting of either *text or combinations
of tokens, tspecials, and quoted-string>
The order in which the header fields are received is not important, but it is good practice to send the main header first, then the request header or the response header, and finally the entity header. Multiple RTSP header fields with the same domain name can be represented in a message when and only if all domain values of the header field are represented by a comma-delimited column (that is, # (value)). It must be possible to add the concurrent domain values to the first value without changing the message syntax, separating them with commas, and eventually combining multiple header fields into the domain name: domain value pair.
The message body of the RTSP message is used to carry the subject of the request or response. The message body and entity body are different only when using transfer encoding (transfer-encoding).
Message-body = Entity-body
When a message contains a message body, the length of the message body is determined by the following rules (high and low order of precedence):
? Any response message does not contain a message body (such as 1xx,204 and 304 responses), and no matter whether the Entity header field exists in the message ends with a blank line in the first line after the message header field.
? If the content Length header field exists, its value in bytes is the length of the message body. If the Content header field does not exist, the value is assumed to be zero.
? When the server shuts down the connection. (Closing the connection does not indicate the end of the request body, which may cause the server to fail to respond.)
Although the description length is dynamically generated, the return length of the representation description can be obtained, so that the server can always determine the description length without using the block transfer encoding method. As long as there is an entity subject, there must be content-length items that ensure that reasonable operations can be made even if no definite length is given.
4. RTSP connection mode
RTSP requests can support several different ways of transmitting:
? A persistent transport connection for multiple request/response transmissions.
? Each request/response transmits a connection.
? No connection mode
The transport connection type is defined by the RTSP URI. For the \ "Rtsp\" scenario, a persistent connection is required, while the \ "rtspu\" scenario calls RTSP request send without establishing a connection.
Unlike HTTP, RTSP allows media servers to send requests to media users. However, this is only supported when the connection is persistent, or the media server does not have a reliable way to reach the user, which is the only way to request a firewall from the media server to the user.

Second, HTTP
1. Introduction
HTTP Hypertext Transfer Protocol is a distributed, collaborative, hypermedia Information System Application layer protocol. HTTP follows the request/answer (Response) model and is a non-connected stateless protocol that when a client makes a request to the server and then the Web server returns a response (Response), the connection is closed and the connection information is not maintained on the server side.
2, the characteristics of the agreement
? Support Customer service/server mode
? Simple and fast: When a customer requests a service from the server, it simply transmits the request method and path.
? Flexible: HTTP allows the transfer of any type of data object. The type being transmitted is marked by Content-type.
? No connection: The meaning of no connection is to limit the processing of only one request per connection. When the server finishes processing the customer's request and receives the customer's answer, the connection is disconnected. In this way, the transmission time can be saved.
? Stateless: Stateless means that the protocol has no memory capacity for transactional processing. A lack of state means that if the previous information is required for subsequent processing, it must be re-routed, which may cause the amount of data to be transferred per connection to increase. On the other hand, it responds faster when the server does not need the previous information.
3. HTTP URL description
HTTP is often based on TCP connection, the HTTP1.1 version of a continuous connection mechanism, the vast majority of web development, are built on the HTTP protocol on the Web application.
The format of the HTTP URL is as follows:
http://host[":" Port][abs_path]
HTTP means to locate network resources through the HTTP protocol, the host represents a legitimate Internet host domain name or IP address; port specifies a port number, or null specifies the URI of the requested resource using the default port 80;abs_path, if no abs_ is given in the URL Path, it must be given as a "/" when it is a request URI, which is usually done automatically by the working browser.
Input: www.guet.edu.cn
Browser automatically converted to: http://www.guet.edu.cn/
4. HTTP Message Header Description
HTTP messages consist of client-to-server requests and server-to-client responses. Both the request message and the response message are from the start line (for the request message, the start line is the request line, for the response message, the start line is the status line), the message header (optional), the empty line (only the CRLF line), and the message body (optional) is composed.
The HTTP message header includes the normal header, the request header, the response header, and the entity header.
Each header field consists of a name + ":" + a Space + value, and the name of the message header field is case-insensitive.
5. HTTP request Description
The HTTP request consists of three parts, namely the request line, the message header, and the request body.
The request line begins with a method symbol, separated by a space, followed by the requested URI and version of the Protocol, in the following format:
Method Request-uri http-version CRLF
Where method represents the request approach, Request-uri is a Uniform Resource identifier, http-version represents the requested HTTP protocol version, CRLF represents a carriage return and a newline (except for the end of CRLF, a separate CR or LF character is not allowed).
There are several ways to request a method (all uppercase), and each method is interpreted as follows:
Get request gets the resource identified by the Request-uri
Post appends new data to the resource identified by Request-uri
HEAD request Gets the response message header for the resource identified by Request-uri
PUT Request server stores a resource and uses Request-uri as its identity
Delete Request server deletes the resource identified by the Request-uri
TRACE requests the server to echo received request information, primarily for testing or diagnostics
CONNECT reserved for future use
Options request the performance of the query server, or query for resource-related choices and requirements
6. HTTP Response Description
After receiving and interpreting the request message, the server returns an HTTP response message. Also consists of three parts: the status line, the message header, and the response body.
The status line format is as follows:
Http-version Status-code reason-phrase CRLF
Where http-version represents the version of the server HTTP protocol, Status-code represents the response status code sent back by the server, and Reason-phrase represents a textual description of the status code.
The status code consists of three digits, the first number defines the category of the response, and there are five possible values:
1XX: Indication information--Indicates that the request has been received and continues processing
2XX: Success-Indicates that the request has been successfully received, understood, accepted
3XX: Redirect--further action is required to complete the request
4XX: Client Error--Request syntax error or request not implemented
5XX: Server-side error-the server failed to implement a legitimate request
Common status codes, status descriptions, and descriptions:
$ OK//client request succeeded
Bad Request//client requests have syntax errors and cannot be understood by the server
401 Unauthorized//request unauthorized, this status code must be used with the Www-authenticate header field
403 Forbidden//server receives request, but refuses to provide service
404 Not Found//request resource not present, eg: Wrong URL entered
Internal Server error//server unexpected errors
503 Server Unavailable//server is currently unable to process client requests and may return to normal after some time
The response body is the resource content returned by the server.

Three, RTSP and HTTP differences
1, the same point
? Both RTSP and HTTP are applied at the application layer.
? In theory, RTSP, HTTP can do live and on-demand, but generally do live with RTSP, do on-demand http.
? RTSP is similar in syntax and operation to HTTP. Are all TCP-based links
2, different points
? RTSP introduces a number of new methods and has different protocol identifiers.
? The RTSP server needs to maintain a state in most cases by default, but HTTP is a stateless protocol .
? both RTSP clients and servers can make requests.
? RTSP data is transmitted by another protocol (except for one exception).
? RTSP uses ISO 10646 (UTF-8) instead of ISO 8859-1 to match the internationalization of the current HTML.
? RTSP contains an absolute URI when using a URI request. The HTTP1 only contains the absolute path in the request, placing the hostname in a separate header domain.
2. HTTP is essentially an asymmetric protocol in which the client requests and the server responds, whereas RTSP is symmetric and the server and the client can send and respond to requests.
The difference and connection between RTSP and HTTP
(1) Contact: Both use plain text to send messages, and the RTSP protocol syntax is similar to HTTP. RTSP was initially designed to be compatible with parsing code using previously written HTTP protocols.
(2) Difference: RTSP is stateful, different is the RTSP command need to know now is in a state, that is, RTSP command always in order to send, a command always before another command to send. RTSP does not break the connection, no matter what state it is in. , and HTTP does not save the state, and the protocol disconnects when a command is sent, and there is no dependency between the commands. The RTSP protocol uses port 554, and HTTP uses 80 ports.

RTSP and HTTP protocol