1.The difference between get and post
In a conventional sense, the get parameter is in the url and the post parameter is in the body.
Security: Relatively speaking, post is safer than get
Length limit: There is no length limit for post requests, and there is a length limit for get requests (the URL itself has a length limit)
Cache line: get requests can be cached, post requests cannot be cached
Under ordinary browsers, get will send one data packet, and post will send two data packets.
2. The difference between cookies, tokens and sessions
cookie
Cookies are not very secure. Others can analyze cookies stored locally and spoof cookies. Sessions should be used for security reasons.
HTTP is a stateless protocol. The server has no way to know the identity of the visitor just from the network connection. To solve this problem, Cookie was born.
Cookies are actually small pieces of text information. The client requests the server. If the server needs to record the user status, it uses response to issue a cookie to the client browser.
The client browser will save the cookie. When the browser requests the website again, the browser submits the requested URL together with the cookie to the server. The server checks this cookie to identify the user's status. The server can also modify the contents of the cookie as needed.
session
The session will be saved on the server for a certain period of time. When visits increase, it will take up more performance of your server. In order to reduce server performance, cookies should be used.
Closing the browser does not close the session. It has an expiration date. After the expiration, the server considers that the client has stopped active and deletes the session to save space.
Token
As an identity authentication token, the security is better than the session, because each request is signed and it can prevent monitoring and replay attacks.
Oauth token provides authentication and authorization. Authentication is for users and authorization is for apps.
Token generation generally uses uuid to ensure uniqueness. When a user logs in, a unique token is generated for the user, and the storage is generally stored in the database. The token expiration time is to store the token twice in the cookie or session, and maintain the token expiration time based on the expiration time of the cookie and session.
3.The difference between cookie and session
The cookie data is stored on the client's browser, and the session data is stored on the server.
Cookies are not very secure. Others can analyze the COOKIE stored locally and conduct COOKIE deception. Sessions should be used for security reasons.
The session will be saved on the server for a certain period of time. When access increases, it will take up more of your server's performance. In order to reduce server performance, COOKIE should be used.
The data saved by a single cookie cannot exceed 4K, and many browsers limit a site to save up to 20 cookies.
4.TCP’s three-way handshake and four-way wave
Three-way handshake: When establishing a TCP connection, the client and server need to send a total of 3 packets to confirm the establishment of the connection.
First handshake: When establishing a connection, the client sends a SYN packet to the server and enters the SYN_SENT state, waiting for confirmation by the server.
Second handshake: When the server receives the client's request, it will give a confirmation message ACK to the client and send a SYN packet at the same time. At this time, the server enters the SYN_RECV state.
Third handshake: After receiving the ACK+SYN packet from the server, the client sends ACK to the server. After the sending is completed, the client and the server enter the ESTABLISHED (TCP connection successful) state and complete the three-way handshake.
Wave four times: When disconnecting a TCP connection, the client and server need to send a total of four packets to confirm.
The first wave: the client sends a FIN to close the data transmission from the client to the server, and the client enters the FIN_WAIT_1 state.
The second wave: After receiving the FIN, the server sends an ACK to the client. The confirmation sequence number is the received sequence number + 1 (the same as SYN, one FIN occupies one sequence number), and the server enters the CLOSE_WAIT state.
The third wave: the server sends a FIN to close the data transmission from the server to the client, and the server enters the LAST_ACK state.
The fourth wave: After the client receives the FIN, the client enters the TIME_WAIT state, and then sends an AKC to the server. The confirmation sequence number is the received sequence number + 1. The server enters the CLOSED state and completes four waves.
Why do we need three handshakes, but not two?
The third handshake is to prevent: If the client does not receive the confirmation message returned by the server, it will abandon the connection and restart a connection request. But the problem is: the server does not know that the client has not received it, so he will Two connections are received, wasting connection overhead. If this happens every time, multiple connections will be wasted.
Why is it a three-way handshake to establish a connection and a four-way wave to close a connection?
This is because in the LISTEN state, after receiving the SYN message for establishing a connection request, the server puts ACK and SYN in one message and sends it to the client. When closing the connection, when receiving the other party's FIN message, it only means that the other party no longer sends data but can still receive data. Not all data may be sent to the other party, so one can close immediately or send some data. After the data is sent to the other party, a FIN message is sent to the other party to express agreement to close the connection now. Therefore, one's own ACK and FIN are generally sent separately.
5. Status code returned by interface request
1xx - Indicates that the request has been accepted and needs to continue processing. This type of response is a temporary response, containing only a status line and some optional response header information, and ending with a blank line:
100 （继续）初始的请求已经接受， 请求者应当继续提出请求。
101 （切换协议） 请求者已要求服务器切换协议，服务器听从客户的请求已确认并准备切换。2xx - Indicates that the request was successfully received, understood, and accepted by the server:
200 （请求成功），服务器成功返回请求的数据。
201 （已创建） 请求成功并且服务器创建了新的资源。
202 （已接受） 服务器已接受请求，但尚未处理。
203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
204 （无内容） 服务器成功处理了请求，但没有返回任何内容。
205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。
206 （部分内容） 服务器成功处理了部分 GET 请求。3xx - Indicates that further action is required to complete the request. Typically, these status codes are used for redirects:
300 （多种选择） 针对请求，服务器可执行多种操作。
301 （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。4xx - These status codes indicate that something might have gone wrong with the request, preventing the server from processing it:
400 （错误请求） 服务器不理解请求的语法。
401 （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403 （禁止） 服务器拒绝请求。
404 （未找到） 服务器找不到请求的网页。
405 （方法禁用） 禁用请求中指定的方法。
406 （不接受） 无法使用请求的内容特性响应请求的网页。
407 （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408 （请求超时） 服务器等候请求时发生超时。
409 （冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410 （已删除） 如果请求的资源已永久删除，服务器就会返回此响应。
411 （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
412 （未满足前提条件）服务器未满足请求者在请求中设置的其中一个前提条件。
413 （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
415 （不支持的媒体类型） 请求的格式不受请求页面的支持。
416 （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 （未满足期望值） 服务器未满足”期望”请求标头字段的要求。5xx - Indicates that the server was unable to complete an apparently valid request. This type of status code represents that an error or abnormal state occurred while the server was processing the request:
500 （服务器内部错误） 服务器遇到错误，无法完成请求。**
501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。6. Enter the URL to the page loading process
1. Enter the URL in the browser's address bar and press Enter.
2. The browser searches for the DNS cache record of the current URL.
3. DNS resolves the IP corresponding to the URL.
4. Establish a TCP connection based on IP (three-way handshake).
5. HTTP initiates a request.
6. The server processes the request and the browser receives the HTTP response.
7. Render the page and build the DOM tree.
8. Close the TCP connection (wave four times).