This paper is participating in theNetwork protocols must be known and must be known”Essay campaign

Interviewer: Why don’t we talk about HTTP today?

Candidate: Well, the HTTP “protocol” is a communication format for clients and servers to “interact.

Candidate: An “agreement” is really just an agreed “format” that both parties can understand

Candidate: Interactions are really just “requests” and “responses”

Interviewer: Do you know the differences between different versions of HTTP?

Candidate: HTTP1.0 defaults to short connections, requiring a new connection each time you interact with the server

Candidate: The main feature of HTTP1.1 is the “default persistent connection”. As long as the client server is not disconnected from the TCP connection, the connection remains open and can send multiple HTTP requests.

Candidate: Chunked transfer-coding is next. The body of the entity is transferred in chunks using the chunking transport encoding using HTTP headers

Candidates: HTTP/2 no longer transmits as text, uses “binary framing layer”, “compresses” headers, supports “flow control”, and most importantly HTTP/2 is “multiplexed” (sending multiple request and response messages “in parallel” over a single TCP connection)

Interviewer: Um, excuse me. I know HTTP1.1 has a pipelining theory, but it’s off by default. Pipelining this is very similar to HTTP/2’s “multiplexing”. What’s the difference?

Candidate: The pipelining proposed by HTTP1.1 can only be “serial” (a response must be fully returned before the next request can begin transmission)

Candidate: HTTP/2 multiplexing takes advantage of a “frame-split” data stream, which breaks the HTTP protocol into “undependent” frames (each frame is sent “sequentially” and then reassembled as it is received), thereby “out-of-order” sending to avoid “some degree” of queue blocking

Candidate: However, whether HTTP1.1 or HTTP/2, the “processing order” of the response should always be the same as the order of the request. If the response to a request is slow, there will still be a blocking problem.

Candidate: This is limited to HTTP’s underlying transport protocol TCP, which does not completely solve the problem of “header blocking”

Interviewer: Oh, ok.

Candidates: The main difference between HTTP/3 and previous versions is that both http1. x and HTTP/2 are TCP at the bottom, while HTTP/3 is UDP at the bottom. Use HTTP/3 to reduce RTT “round trip latency” (TCP three-way handshake, TLS handshake)

Interviewer: Do you understand the HTTPS process?

Candidate: Well, HTTPS, as I understand it, is the “secure” HTTP protocol (encrypted over the client-server transport link)

Candidate: HTTPS has to solve the problem of authentication first

Candidate: The client needs to know exactly if the server is “real,” so there is a role in HTTPS: CA.

Candidate: Before using HTTPS, the server needs to apply for a digital certificate from the CA. A digital certificate contains information about the certificate owner, certificate validity period, and server public key

Candidate: THE CA also has its own public and private key, and encrypts the digital certificate with its own “private key” before issuing it

Candidate: When the client requests the server, the server returns the certificate to the client. The client decrypts the certificate using the CA’s public key (the client has a public key because the CA is a public trust authority and is built into the browser or operating system). At this point, the client will determine whether the certificate is trusted/tampered with.

Candidates: Private key encryption, public key decryption we call “digital signature” (this way to see if it has been tampered with)

Candidate: At this point, the problem of “authentication” is solved, at least the client can be assured that it is communicating with a “real server.”

Candidate: Once the “authentication” problem is solved, the “confidentiality” problem should be solved so that the communication content between the client and the server is not leaked to the third party during transmission

Candidate: After obtaining the digital certificate from the CA, the client can obtain the public key of the server

Candidate: The client generates a Key as the “symmetric encryption” secret Key and passes it to the server using the “public Key encryption” of the server

Candidate: The server decrypts the client’s data with its own “private key” to obtain a symmetric encrypted secret key

Candidate: Then clients and servers can happily send and receive messages using “symmetrically encrypted secret keys.

Interviewer: I see

Follow my wechat official account [Java3y] to talk about something different!

Online Interviewers + Write Java projects from scratchContinuous high intensity update! O star,

Original is not easy!! Three times!!