instructions

The purpose of this article is to introduce the basic data transfer and interaction flow, which is to write something about the HTTP protocol. And this article is mainly due to the recent and long time many people have asked questions about this area (maybe the question is not the question, but the main root cause is still this area), so I want to write this article is to do a popular science, so that when you write back-end programs, There are no data transfer problems and you don’t know how to solve bugs.

This article I think is a basic article, originally wanted to take a lofty name, but I thought about it, still so called, convenient for beginners or is to write a period of time with the server interaction program to understand. Of course, the whole article is just based on the summary of my development experience in these years. It is inevitable that there will be some expressions or misunderstanding of the bottom layer. If there is any mistake, please kindly point it out.

The HTTP protocol

Before I begin, I’d like to make a few remarks about the HTTP protocol, which I’ll focus on in the following articles. About this part, I posted the baidu Encyclopedia article, I think the explanation is quite comprehensive. (Don’t worry about subsidizing wiki links here)

Baike.baidu.com/item/http/2…

HTTP is divided into data request (send) phase and data response phase. Data content formats in the data request stage mainly include:

Request line – General information Header – Request Header – Entity Header – Message body

The content formats of the data response stage mainly include:

Status line – General message Header – Response Header – Entity Header – Message body

The body of the message we see

What non-developers see is the body of the message that responds to the data. This may not be correct, but it should be the body that the browser parses.

<html>
....
</html>Copy the code

The content of the.

As a developer, open the debugging tool in Chrome browser, we can see the request header and response header, and the data will return the corresponding response status according to the error or corresponding success (such as the common 200,404,500,502, etc.).

The data type

There are thousands of data types, and I think anyone who writes a program should be aware of the basic data types. There are usually integers, floating point, characters, strings, arrays, etc. (not to mention that the underlying underlying data is binary representation, which can be spent a lot of time in depth and understanding).

From these basic data types come various data types, and then there are image data types, text data types, streaming media data types, and so on.

When we write web programs, we often encounter HTML, JSON, images, audio, video, and other types of data, which can be categorized as string data. Speaking of which, I think we should introduce a “reference” thing, that is, what types of data are described primarily with respect to different reference points.

HTML to the browser, is the type of HTML, which can be interpreted to render a beautiful interface, of course, it is also possible to render a poor interface. To a back-end program, such as PHP or Java, HTML is nothing more than a bunch of strings that can represent meaning (the document that the browser renders). Similarly, JSON is nothing more than a bunch of strings that make sense to a back-end program, whereas in JavaScript, JSON represents a data object.

The purpose of this data format and data format reference is that when we write programs, we should think about different data for different programs meaning is not the same, so our data processing thinking is not the same, otherwise it will be the same thinking to think, so can not think of the problem is difficult.

Of course, there are some common data types, such as images and streaming media data, which are treated in almost the same way.

Asynchronous data interaction

What we usually know about asynchrony is AJAX, but AJAX here might be part of asynchrony, so let’s start with AJAX.

AJAX is a mode of data interaction that still follows the HTTP protocol itself, but it’s usually up to us to trigger the browser to implicitly request and process data in the background using the programming interface.

Typically, we enter a URL, the browser makes a request for that URL, and we see a web page. But in fact, if we just do this step, without asynchrony, we would not be able to see the full web page, which means there would be no interactive animations and beautiful styles. Why is that?

We usually define some external CSS styles and external JS programs in a page. This is actually dependent on the browser when doing HTML parsing, encounter external CSS style introduction or JS introduction, will take the initiative in the background to initiate a resource request, but this request is invisible to us. Of course, this is not to say that the request is invisible and asynchronous, but because the load with the HTML resource itself is not synchronous, but asynchronous until the HTML data is loaded.

The asynchronous interaction itself is based on HTTP, and when we write AJAX, we actually take over the browser’s processing of the interactive data from another point of view, that is, we do not follow the browser’s own behavior rules, such as when we transfer json data, We need to process the JSON returned by the server and parse it into node data for the browser to display. Similarly, taking over the management of AJAX data ourselves adds a lot of flexibility to the data processing.

Asynchronous is only a partial description of AJAX. Why? Since asynchrony and asynchrony programs, many advanced languages now have asynchrony features, of course, can also be implemented manually, on the program asynchrony this piece I will not do more here, on the program asynchrony is another topic.

About cookies and sessions

I’m also going to talk about cookies and sessions separately, without going into too much detail, but just like the whole article, I’m going to focus on the basics.

We write front-end programs to know that cookie has scope and storage time, cookie scope is for security, prevent cross-domain use, and storage expiration time also has this role. The purpose of using cookie itself is actually to cache some short data, and the browser itself has good support for cookie, each time the data request, the cookie set by the user will be brought to the cookie header, the server program through the request header parsing cookie header, The cookie value of the client can also be obtained.

Similarly, the cookie set by the server will be added to the response header. When the browser finds a cookie in the response header, it will store the cookie locally in the browser and carry the cookie with each subsequent request. This is how the server sets cookies.

The above basic knowledge theory provides the support for session. First of all, LET me talk about what is session. The Chinese translation of session means the meaning of session. Generally, the most basic understanding is that “session is used for user login”. It’s basically true that sessions are generally used to store user login status, but it’s not entirely true. I’m going to talk about the session implementation mechanism, and then I think it’s clear that sessions can be extended to some of the functions.

Session and cookie are interdependent. First, when a user opens a website, the server will generate a session_ID and then put the session_ID in the response header to inform the browser to store it. Then the browser will carry the session_id cookie value every time the request, the server obtains the session_id to check again, can hold the call. Of course, this only means to keep the user online, but it has nothing to do with the user’s login. Therefore, when the user logs in, the user information will be associated with session_ID, indicating that the login is successful, and our back-end service will check whether there is the associated user information and inform the user whether he is logged in. That’s how user login works.

These are briefly discussed above, mainly my personal experience and understanding of server-side data interaction.