Hello everyone, I am Chen Haha, and I have been drifting north for five years. Friends who know me know that I was born in a non-major class, renounced halfway through, and the university is also very poor! Come to Beidiao with this background, you don’t know what you will experience 🙃🙃.
I can’t agree. I believe everyone is like me
都有一个大厂梦. As a senior Java player, I know the importance of interviews. Next, I’m going to spend 100 days, based on the high-frequency interview questions in Java post interviews,
每日3题and take you in the form of Go through the popular interview questions and the appropriate answers. Of course, I won't go too deep, because I'm afraid I can't remember! !
因此，不足的地方希望各位在评论区补充疑惑、见解以及面试中遇到的奇葩问法, I hope these 100 days will allow us to fly over qualitatively and rush into the big factory together! ! , Let us learn together (juan)! ! !
Coordinates: Mount Putuo
- Interview Question 1: Tell me about the three-way handshake and four waved hands of a TCP connection
- Seriously answer:
- In-depth inquiry:
- Follow-up 1: Why is there a three-way handshake when connecting, but a four-way handshake when closing?
- Follow-up 2: What if the connection has been established but the client suddenly fails?
- Interview question 2: What are the common HTTP status codes?
- Seriously answer:
- Interview Question 3: Let me talk about the difference between GET and POST requests.
- Seriously answer:
- In-depth inquiry:
- Follow-up 1: Does the Get request have a request body? If so, can the parameters be placed in it like a Post request?
- Follow-up 2: What about the length limitation of the parameters in the URL you just mentioned in Get and Post?
- Follow-up 3: So do you know the difference between the data packets sent by Get and Post requests?
- Daily summary
This column Java developers Kong high-frequency face questions from each of the following major technology
Linux操作技巧and so on.
Interview Question 1: Tell me about the three-way handshake and four waved hands of a TCP connection
First of all, the essence of the three-way handshake is to confirm the two parties (Client side, Server side)
The three-way handshake actually means: when a TCP connection is established, the client and the server need to send a total of 3 packets. These three request packets are used to confirm whether the receiving and sending capabilities of both parties (Client and Server) are normal. At the same time, specify Your own initialization sequence number prepares for the subsequent reliable transmission. Essentially, it connects to the designated port of the server, establishes a TCP connection, synchronizes the serial number and confirmation number of the two parties, and exchanges TCP window size information.
Note: At the beginning, the client was in the Closed state, and the server was in the Listen state.
Introduction to the three-way handshake (connection) process in vernacular:
My girlfriend and I raised a carrier pigeon to spread the letter. Today I want to try if it works. If it doesn’t work, I’m going to have a barbecue at night.
第一次握手: I tie the letter (the first letter) to the pigeon’s legs and send it to my girlfriend. If my girlfriend receives it, it is confirmed that my sending ability and her receiving ability are okay;
第二次握手: Then my girlfriend replied to me (the second letter). If I receive it, it means that my receiving ability and her sending ability are okay;
第三次握手: However, at this time, my girlfriend does not know whether her ability to send mail and my ability to receive mail is normal; therefore, I will send him a (third letter) explaining that after receiving it, I finally decided to eat grilled fish at night.
- Homing pigeon: Damn it, it's really tiring, you guys are all fake phones.
Three-way handshake theoretical process:
第一次握手: The client sets the flag bit SYN to 1, randomly generates a value seq=J, and sends the data packet to the server. The client enters the SYN_SENT state and waits for the server to confirm.
第二次握手: After the server receives the data packet, the flag bit SYN=1 knows that the client requests to establish a connection. The server side sets the flag bits SYN and ACK to 1, ack=J+1, randomly generates a value seq=K, and sets The data packet is sent to the client to confirm the connection request, and the server enters the SYN_RCVD state.
第三次握手: After receiving the confirmation, the client checks whether ack is J+1 and ACK is 1, if it is correct, set the flag ACK to 1, ack=K+1, and send the data packet to the server, the server Check whether ack is K+1 and ACK is 1. If it is correct, the connection is established successfully, the client and server enter the ESTABLISHED state, complete the three-way handshake, and then the client and server can begin to transmit data.
Wave four times:
The TCP connection is terminated with four waves of hands, which means that when a TCP connection is disconnected, the client and the server need to send a total of 4 packets to confirm the disconnection. In socket programming, this process is triggered by either the client or the server executing close.
Since the TCP connection is full-duplex, each direction must be closed separately. This principle is that when one party completes the data sending task, it sends a FIN to terminate the connection in this direction. Receiving a FIN only means There is no data flow in this direction, that is, no more data will be received, but data can still be sent on this TCP connection until FIN is also sent in this direction. The party that shuts down first will execute the active shut down, and the other party will execute the passive shut down.
Four waved theoretical process
- The end of the connection can be the client or the server.
第一次挥手: The client sends a FIN=M to close the data transmission from the client to the server, and the client enters the FIN_WAIT_1 state. It means "my client has no data to send to you", but if you have data on the server side that has not been sent, you don't have to close the connection in a hurry, you can continue to send data.
第二次挥手: After receiving the FIN, the server first sends ack=M+1 to tell the client that I have received your request, but I am not ready yet, please continue to wait for my message. At this time, the client enters the FIN_WAIT_2 state and continues to wait for the FIN message from the server.
第三次挥手: When the server side determines that the data has been sent, it sends a FIN=N message to the client, telling the client, OK, I have finished sending the data here, and I’m ready to close the connection. The server enters the LAST_ACK state.
第四次挥手: After the client receives the FIN=N message, it knows that it can close the connection, but he still doesn’t believe in the network, because the server does not know to close it, so it enters the TIME_WAIT state after sending ack=N+1. If the server does not Retransmission is possible after receiving ACK. After the server receives the ACK, it knows that it can disconnect. After the client has waited for 2MSL and still does not receive a reply, it proves that the server has been shut down normally. Well, my client can also close the connection. Finally completed the four-way handshake.
Follow-up 1: Why is there a three-way handshake when connecting, but a four-way handshake when closing?
Because when the Server side receives the SYN connection request message from the Client side, it can send a SYN+ACK message directly. The ACK message is used for reply, and the SYN message is used for synchronization. However, when the connection is closed, when the server receives a FIN message, it may not immediately close the SOCKET, so it can only reply with an ACK message and tell the client, "I received the FIN message you sent." Only after all the messages on my Server side have been sent, I can send FIN messages, so I cannot send them together. Therefore, a four-step handshake is required.
Follow-up 2: What if the connection has been established but the client suddenly fails?
TCP also has a keep-alive timer. Obviously, if the client fails, the server cannot wait forever, and resources are wasted. The server resets this timer every time it receives a request from the client. The time is usually set to 2 hours. If it has not received any data from the client for two hours, the server will send a probe segment, and then every 75 Sent once every second.
If there is no response after sending 10 probe messages, the server considers the client to be faulty, and then closes the connection.
Interview question 2: What are the common HTTP status codes?
The HTTP status code indicates the returned result of the client's HTTP request, identifies whether the server is processing normally, and indicates an error in the request.
Type of status code:
|status code||the reason|
|1XX||Informational (informative status code) The accepted request is being processed|
|2XX||Success (success status code) The request is processed normally|
|3XX||Redirection (redirection status code) requires additional actions to complete the request|
|4XX||Client Error (client error status code) The server could not process the request|
|5XX||Server Error (server error status code) server processing request error|
|status code||the reason|
|2XX||Success (this series indicates that the request was processed normally)|
|200||OK, it means that the request from the client is processed correctly on the server|
|204||No content, indicating that the request is successful, but the response message does not contain the body of the entity|
|206||Partial Content, the scope request was successful|
|status code||the reason|
|3XX||Redirection (indicating that the browser needs to perform special processing)|
|301||moved permanently, a permanent redirect, indicating that the resource has been assigned a new URL|
|302||found, temporary redirection, indicating that the resource is temporarily assigned a new URL|
|303||see other, indicating that another URL exists for the resource, and the GET method should be used to obtain the resource|
|304||not modified, indicating that the server allows access to the resource, but the request does not meet the conditions (not related to redirection)|
|307||Temporary redirect, temporary redirect, and 302 have a similar meaning, but the client is expected to keep the request method unchanged and send a request to the new address|
|status code||the reason|
|400||bad request, there is a syntax error in the request message|
|401||unauthorized, indicating that the request sent needs to have authentication information authenticated by HTTP|
|403||forbidden, which means that access to the requested resource is denied by the server, and a description of the reason can be returned in the entity body|
|404||not found, indicating that the requested resource was not found on the server|
|status code||the reason|
|500||internal sever error, indicating that an error occurred on the server side while executing the request|
|501||Not Implemented, which means that the server does not support a function required by the current request|
|503||service unavailable, indicating that the server is temporarily overloaded or is shutting down for maintenance and cannot process the request|
Interview Question 3: Let me talk about the difference between GET and POST requests.
- The parameters transmitted in the URL for GET requests are limited in length, while POST does not.
- GET is less secure than POST, because the parameters are directly exposed on the URL, so it cannot be used to transmit sensitive information. The POST data will not be displayed in the URL. It is placed in the Request body.
- For the data type of the parameter, GET only accepts ASCII characters, while POST has no restrictions.
- GET request parameters will be completely retained in the browser history; on the contrary, POST request parameters will not be retained by the browser.
- GET requests can only be url-encoded (application/x-www-form-urlencoded), while POST supports multiple encoding methods.
- GET requests will be actively cached by the browser, while POST will not, unless manually set.
- GET is harmless when the browser rolls back, while POST will submit the request again.
Follow-up 1: Does the Get request have a request body? If so, can the parameters be placed in it like a Post request?
Actually, there is no difference between GET and POST in essence, and both are two methods of sending requests in the HTTP protocol. And HTTP is a TCP/IP-based protocol on how data communicates in the World Wide Web.
World Wide Web: WWW for short, short for World Wide Web, also known as Web, 3W, etc.
The bottom layer of HTTP is TCP/IP. So the bottom layer of GET and POST is also TCP/IP, that is,
- For example:
TCP is like a car. We use TCP to transport data. It is very reliable and there is never a phenomenon of missing or missing pieces.
But if there are all cars that look exactly the same on the road, the world looks like a mess. The cars delivering urgent items may be blocked on the road by cars full of cargo in front, and the entire transportation system will definitely be paralyzed.
In order to prevent this from happening, the traffic rule HTTP was born. HTTP sets several service categories for automobile transportation, including GET, POST, PUT, etc.,
HTTP stipulates that when a GET request is executed, a GET label must be attached to the car (set method to GET), and the transmitted data must be placed on the roof of the car (in the url) to facilitate recording.
If it is a POST request, a POST label must be affixed to the car and the goods should be placed in the carriage (in the request body).
Of course, you can also secretly hide some goods in the compartment when using GET, but this is not shameful; you can also put some data on the roof of the car during POST, which will make people feel silly.
HTTP is just a code of conduct, and GET and POST are essentially TCP links, and there is no difference. However, due to HTTP regulations and browser/server restrictions, they show some differences in the application process.
Follow-up 2: What about the length limitation of the parameters in the URL you just mentioned in Get and Post?
In fact, there is another important role in the Web: transportation companies.
The client side (initiating http request) and server side (receiving http request) of different browsers are different transportation companies.
Although in theory, you can pile up unlimited goods on the roof of the car (infinitely add parameters in the url). But the transportation company is not stupid. Loading and unloading also have a lot of cost. They will limit the single transportation volume to control the risk. The large amount of data is a great burden on the browser and the server.
The unwritten regulations in the industry are:
The excess part will not be processed. If you use the GET service and hide the data secretly in the request body, the processing methods of different servers are also different. Some servers will help you unload and read the data, and some servers will ignore it.
Therefore, although GET can carry request body, there is no guarantee that it will be received.
I dealt with a bug before, and the user responded that the query did not respond. After checking the log, my colleague found that several parameters were undefined. It was strange. Finally, it turned out that the first query parameter of the Get request was too long, which caused the URL to follow. Part of the server was unable to receive, and later changed the request to post and put the parameters after the request body.
Follow-up 3: So do you know the difference between the data packets sent by Get and Post requests?
Well, it's like this, one TCP data packet is generated for GET request; two TCP data packets are generated for POST request.
- GET: The browser will send the http header and data together, and the server will respond with 200 (return data);
- POST: The browser sends the header first, the server responds with 100 continue, the browser sends data again, and the server responds with 200 OK (return data).
It's like GET only needs one car to deliver the goods, while POST has to run two times. The first one is to say hello to the server, "Old iron, I will deliver a batch of goods later, you are ready Receive it," and then go back and deliver the goods.
Because POST requires two steps, theoretically it consumes a little more time. It seems that GET is more effective than POST. But it wasn't. Later it turned out to be a pit. in my opinion:
- Both GET and POST have their own semantics and cannot be mixed casually.
- According to research, when the network environment is good, the difference between the time to send a packet and the time to send two packets can basically be ignored. In the case of a poor network environment, two-packet TCP has great advantages in verifying the integrity of the data packet.
- Not all browsers will send the packet twice in POST, Firefox will only send it once. I tested it with the Chrome browser last year and found that it was only sent once, so I think the poor performance of Get and POST can be ignored.
Today we reviewed the
网络编程类three frequently tested questions in interviews . Do you know it well?
对了，如果你的朋友也在准备面试，请将这个系列扔给他，如果他认真对待，肯定会感谢你的！！Okay, let’s stop here today
记得在评论区留言：打卡。, to encourage students who have lost their studies .