After reading the RFC document for protocols such as HTTP __http

Previously for HTTP and FTP also have some understanding, read the English version of the RFC document, although very painful, but the feeling is different.

The control and descriptive information expressed by 1,http are included in the initial line and header of HTTP. The use of BNF allows you to clearly comb through all the classes in the start line and header. It is also possible to understand what each type of meta information contains. This abstract method is not only more rigorous when the HTTP protocol is defined, but is very easy to implement when implementing the HTTP parser (browser) by referencing BNF code. This also reminds us that we can draw a similar approach when writing related system design solutions. After all, the use of words to express the design of the problem is omitted, the formulation is not clear enough, different people understand differences and so on. (We'll see that there are similar methods in FTP, state diagrams). HTTP is designed to be a very easy to extend protocol, so the protocol is loosely structured. The header field can add the required header name and the specified value. Although some headers are not included in the RFC standard, they may become the standard for convention moralize (although this poses a challenge to the security of HTTP), it can be seen that good design is considered to be extensible at the outset, This is also the reason that HTTP can exist for a long time and develop continuously.

2,FTP adopts the mode of control and data separation to realize the transmission of files. First of all, this design idea is very common in the design of the program itself. FTP in the form of COMMAND + response code to control the function of file transfer, several commands + different types of response code will lead to different results, the combination of a variety of ways, but the FTP RFC document gives these combinations of the state diagram. Six types of state diagrams cover all possible scenarios for FTP. We mentioned earlier that the BNF representation of HTTP is good for writing programs, and the state diagram here also gives a guideline for writing complete FTP software. Of course, the state diagram can also see that some commands are sequential, but most commands do not have this requirement.

3,RTSP can be said that the basic reuse of the design idea of HTTP, from the request and response message composition can be clearly seen. But it also borrowed from the relevant good ideas in FTP. such as the separation of data and control, RTSP data transmission is by RTP/RTCP and other protocols to achieve. In HTTP, the request response pattern is based on the CS mode, where the client initiates the request and the server responds. FTP has changed, first in the FTP architecture exists in this client to control the communication between the two servers. Two-server communications, and in Port mode in FTP (data connections are initiated by the server), are very different from HTTP. As for the RTSP request is two-way.

In general, all three protocols are text-based application layer protocols, and text-based protocols can be easily added when certain attributes, methods, or commands are required. Relative to the transport layer and the network layer (although also has the extension), the fixed position expression meaning is certain, the text-based protocol is more flexible and changeable. Of course, the most basic principle of layering is also embodied in http,ftp and RTSP, that is, application layer protocols should minimize the coupling between them and the lower layers. Although common HTTP is based on the TCP protocol, HTTP does not care about how the entire HTTP message is used at the transport level.

The above is to read a few RFCs after the personal point of opinion, there is the wrong place, also please correct and spit groove.