How to quickly get started with VUE3.0: Get started with learning.
This is the first article in the Nodejs series. When I read tutorials before, many of them started with the IO, buffer, path, event, fs, process, and node event loop mechanisms. . These are indeed the development dependencies that node development mainly relies on. But I am quite anxious. From the time I learned about node, it means that node can do the backend, but the first half of these courses are talking about the capabilities it has, that is, how to interact with it in the end. Introduction to the module of client communication.
I feel very uncomfortable, so when I write my own summary, I must write the module that communicates between the server and the client first to feel comfortable. Even if the knowledge points of the event module and fs module are involved in the process, you can Put it aside for now and just understand how net module implements communication as a whole.
If you want to learn the communication module, you have to understand the network communication model. If you want to remember the network communication model, you have to practice it. To assist memory. This is the focus of the interview. There is a lot of content in this area. I want to have an in-depth understanding of it, and it also requires systematic study. Here is just a brief mention.
Send this old picture:
For our front-end, we need to remember the system results of the TCP/IP protocol suite.
Application layer: http (port 80), FTP (21), SMTP (sending mail), POP (receiving mail), DNS
Transport layer: TCP/UDP
Internet layer: IP, ICMP (a subsidiary protocol of the IP layer)
Data link layer: PPP, SLIP
Physical layer: The network has twisted pair, coaxial cable, optical fiber and other transmission methods, following the ISO2110 specification
from ICMP to this It can be known from the protocols attached to the IP protocol that there is no need to worry too much about the layering of network protocols. ICMP obviously needs the IP protocol as a basis, but it is also planned as a network layer. Our correct understanding of the OSI model, I think, should be It is more meaningful to use the OSI model to analyze problems than to use the so-called layering of protocols.
The TCP/IP protocol suite does not just refer to the TCP and IP protocols, but because these two protocols are too out of the circle, TCP is used /IP collectively refers to the collection of protocols related to the Internet. Another way to say it is as a collective name for the protocol family used in the process of using the TCP/IP protocol.
The transmission flow of the client and server is as follows
If the roles become发送者and接受者, the transmission flow is as follows:
It can be seen that during the transmission process, starting from the sending end, the required header information will be added without passing through a layer of protocol. Layers of checks and layers of coding. Then when it comes to the receiving end, it will work on the contrary. Each layer passes through Strip off the corresponding headers. Just wait until the final HTTP data is obtained.
.The above picture is from "Illustrated HTTP"
The above is the general network protocol model.
Question: Why do books and many places merge the OSI system results into TCP/IP? After the five-layer protocol, will the name of the network layer become the Internet layer?
First handshake: The client sends the SYN flag (sequence number is J) to the server, and enters the SYN_SENT state (waiting for confirmation from the server).
Second handshake: The server receives SYN J from the client, and the server will confirm The data packet has been received and sent the ACK flag bit (sequence number is J + 1) and SYN flag bit (sequence number is K), and then enters the SYN_REVD state (request acceptance and waiting for client confirmation state)
third handshake: client enters After the connection is established, the ACK flag bit (K+ 1) is sent to the server to confirm that the client has received the established connection. After the server receives the ACK flag, the server enters the connection established state.
connection.J and K are both used to establish who is the
In the request. There is no difference in the structure of SYN and ACK, but the objects sent are different.
net模块is the specific implementation of the above TCP connection.
First of all, it is still recommended to go directly to the official documentation to learn the API. The content of the Chinese documentation is not It will be the latest version.
When I study, I try to read English documents when I have time. I have been insisting on this for half a year. I couldn't stand it at the beginning, but now I can hold back the discomfort and read it. For half a year The progress over time is obvious. And this kind of discomfort is a good thing. It means that this is not your comfort zone. After all, the courage to cross your comfort zone is the source of progress
. Next, let’s get to the point. Since you want to learn communication, Then we need two objects to simulate the client and server. Create two files, client.js and service.js respectively. Create through the command line:
touch client.js && touch service.js
introduces the net module , and let the server enter the LISTENT state, configure the port number and HOST address (manually skip the DNS resolution process), and wait for the client's call
const net = require("net");
const post = 3306;
const host = "127.0.0.1";
const server = net.createServer();
server.listen(post, host); At this time, the server corresponds to the server LISTEN status in the TCP connection.
Then it listens to some necessary events, which are the hooks provided by the server. (Belongs to event-related knowledge)
server.on("listening", ( ) => {
console.log("The server can be connected");
});
server.on("connection", (socket) => {
console.log("A client is visiting");
});
server.on("close", () => {
console.log("The server is shut down");
});
server.on("error", (error) => {
console.log("The server has an error: ", error); // error has error information}); The above string of codes involves,
listening : an event triggered after listening to the portconnection : an event triggered when a client visitsclose : Triggered by server shutdownerror : Triggered by server errorRegarding close , we need to pay attention to the fact that the background brother usually directly
ps Kill -9 pid
is performed by killing the thread.
In the connection dog, the formal parameter is the socket name. Its Chinese translation is a nested word, which is encapsulated into a stream by node. It can be roughly understood as It is the data sent by the client. This is because the data itself has its own method. I process socket in connection
server.on("connection", (socket) => {
console.log("A client is visiting");
socket.on("data", (data) => {
console.log(data); //Data sent by the client});
}); stream will be introduced in future articles.
Since the server can accept the data sent by the client, it can naturally reply to the client. Write in socket.on (of course it can also be written outside):
socket.write ("I have received your server, client"); At this time, if the client has completed receiving the data and then closed the connection. We can also monitor it through socket.on('close') hook :
socket.on("close", () => {
console.log("The client shut down the other end of the stream");
}); Put the summary of socket events in client.js . At this time, all the contents of service.js are as follows:
const net = require("net");
const post = 3306;
const host = "127.0.0.1";
const server = net.createServer();
server.listen(post, host);
server.on("listening", () => {
console.log("The server can be connected");
});
server.on("connection", (socket) => {
console.log("A client is visiting");
socket.on("data", (data) => {
console.log(data); //The data sent by the client socket.write("I have received it from your server, client");
});
socket.on("close", () => {
console.log("The client shut down the other end of the stream");
server.close(); // The client no longer needs the data, so let’s close the server});
});
server.on("close", () => {
console.log("The server is shut down");
});
server.on("error", (error) => {
console.log("The server has an error: ", error); // error has error information}); client part is much simpler.
const net = require("net");
const post = 3306;
const host = "127.0.0.1";
const socket = net.connect(post, host);
socket.on("connect", () => {
console.log("Already connected to the server");
});
socket.write("Server, here I come");
socket.on("data", (data) => {
console.log(data.toString());
socket.end();
});
socket.on("close", () => {
console.log("The connection has been closed");
}); Summary of socket events
connect : Successful connection with the server triggersdata : Receives the parameters sent by the serverend : After the data is received, it can triggerclose : The socket close triggersservice.js and client.js frameworks have been written. Run them after opening two terminals:
node service.js node client.js
can check the printed results by itself.
The entire TCP connection framework has been basically completed. Of course, the actual production is far more than that. It also needs to deal with sticky packets, unpacking/packaging, heartbeat packets, etc.
This article is reproduced from: https://juejin.cn/post/7084618854801866765
Author: I am Little Orange