Understanding TCP/IP, HTTP, and HTTPS in Depth

1. Source Port: The source port number, used when a reply is needed. It can be set to 0.

2. Destination Port: This must be used when delivering the message to the endpoint.

3. Length: The length of the UDP user datagram, minimum is 8 (only header).

4. Checksum: Used to check if the user datagram has errors during transmission; if errors are detected, the message is discarded.

TCP Segment Header Format:

Source and Destination Ports: Each occupies two bytes, containing the source port number and destination port number. Sequence Number: Occupies 4 bytes; used to number the byte stream. For example, if the sequence number is 301, the first byte is numbered 301. If the data length is 100 bytes, the next segment’s sequence number should be 401. Acknowledgment Number: Occupies 4 bytes; the expected sequence number of the next segment to be received. For example, if B correctly receives a segment sent by A with sequence number 501 and a data length of 200 bytes, then B expects the next segment’s sequence number to be 701, and the acknowledgment number in the acknowledgment segment sent by B to A will be 701. Data Offset: Occupies 4 bits; indicates the offset of the data portion from the start of the segment, effectively indicating the length of the header. Acknowledgment (ACK): When ACK=1, the acknowledgment number field is valid; otherwise, it is invalid. TCP stipulates that all transmitted segments must have ACK set to 1 after the connection is established. Synchronization (SYN): Used to synchronize sequence numbers when establishing a connection. When SYN=1 and ACK=0, it indicates a connection request segment. If the other party agrees to establish a connection, the response segment will have SYN=1 and ACK=1. Termination (FIN): Used to release a connection; when FIN=1, it indicates that the sender has finished sending data and requests to release the connection. Window: Occupies 2 bytes; the window value serves as the basis for the receiver to instruct the sender on how to set its sending window. This limitation is necessary because the receiver’s data buffer space is limited. Checksum: Occupies 2 bytes; the checksum field checks both the header and data portions. When calculating the checksum, a 12-byte pseudo-header is added to the front of the TCP segment. Socket: The endpoint of a TCP connection is called a socket or port. The port number combined with the IP address forms the socket.

Interview Soul Searching Questions

TCP’s Three-Way Handshake and Four-Way Termination

1. First Handshake: The client sets the SYN flag to 1, randomly generates a value seq=J, and sends the packet to the server. The client enters the SYN_SENT state, waiting for the server’s confirmation.

2. Second Handshake: Upon receiving the packet, the server recognizes the client’s request to establish a connection with SYN=1. The server sets both the SYN and ACK flags to 1, ack=J+1, randomly generates a value seq=K, and sends the packet back to the client to confirm the connection request. The server enters the SYN_RCVD state.

3. Third Handshake: The client receives the confirmation, checks if ack is J+1 and ACK is 1. If correct, it sets the ACK flag to 1, ack=K+1, and sends the packet to the server. The server checks if ack is K+1 and ACK is 1. If correct, the connection is successfully established, and both the client and server enter the ESTABLISHED state, allowing data transmission to begin.

Why perform a three-way handshake? The third handshake prevents invalid connection requests from reaching the server, which would incorrectly open a connection. If a client’s connection request is delayed in the network, it may take a long time to receive the server’s connection confirmation. After waiting a timeout period, the client will resend the connection request. However, if the delayed request eventually reaches the server without the three-way handshake, the server would open two connections. With the third handshake, the client ignores any connection confirmations from the server for the delayed request, thus preventing the opening of a duplicate connection.

Can it be done with two handshakes? For example, in a phone call scenario: First handshake: A calls B asking, “Can you hear me?” Second handshake: B receives A’s message and replies, “I can hear you, can you hear me?” Third handshake: A responds, “Yes, I am going to send you a message!” Conclusion: After the three-way handshake, both A and B can confirm: I can hear you, and you can hear me. Thus, normal communication can begin. If there were only two handshakes, this confirmation would not be possible.

When data transmission is complete, the connection needs to be terminated with TCP’s four-way termination:

1. The first termination: The client sets seq and ACK, sending a FIN (finish) segment to the server. The client then enters the FIN_WAIT_1 state, indicating that it has no more data to send to the server.

2. The second termination: The server receives the FIN segment sent by the client and responds with an ACK segment.

3. The third termination: The server sends a FIN segment to the client, requesting to close the connection, entering the LAST_ACK state.

4. The fourth termination: The client receives the FIN segment from the server and sends back an ACK segment, then enters the TIME_WAIT state. After receiving the ACK segment from the client, the server closes the connection. At this point, the client waits for 2MSL (the maximum survival time of a segment in the network) and, if no reply is received, concludes that the server has closed the connection properly and can then close its own connection.

Final Complete Process Diagram

Why four-way termination? After the client sends the FIN termination segment, the server enters the CLOSE-WAIT state. This state allows the server to send any data that has not yet been transmitted. Once all data is sent, the server will send a FIN termination segment.

HTTP Persistent Connections

If there are many connections, each requiring three-way handshakes and four-way terminations, performance will clearly suffer. Therefore, HTTP has a mechanism called persistent connections (keepalive connections). It allows the connection to remain open after data transmission, enabling the client to reuse the idle connection for subsequent data requests without needing to perform another handshake.

HTTP and HTTPS

What is HTTP?

The Hypertext Transfer Protocol is a stateless, application-layer protocol based on request and response, commonly transmitting data over TCP/IP. It is the most widely used network protocol on the Internet, and all WWW files must comply with this standard. The initial design of HTTP was to provide a method for publishing and receiving HTML pages.

Characteristics of HTTP:

1. Stateless: The protocol does not store state for the client and has no “memory” for processing actions, such as requiring repeated logins when accessing a website.

2. Connectionless: Prior to HTTP/1.1, due to its stateless nature, each request required a new TCP connection established through three-way handshakes and four-way terminations. For example, if a client requests the same resource multiple times in a short period, the server cannot distinguish whether it has already responded to the user’s request, necessitating a new response each time, wasting time and bandwidth.

3. Based on request and response: The basic characteristic is that the client initiates the request, and the server responds.

4. Simple, fast, and flexible.

5. Communication uses plaintext; requests and responses do not confirm the identity of the communicating parties, making it impossible to protect data integrity.

Components of an HTTP Message:

1. Request Line: Includes request method, URL, and protocol/version.

2. Request Header

3. Request Body

4. Status Line

5. Response Header

6. Response Body

Disadvantages of HTTP

1. Communication uses plaintext (unencrypted), content may be intercepted.

2. Does not verify the identity of the communicating parties, which may lead to impersonation.

3. Cannot prove the integrity of messages, so they may have been tampered with.

What is HTTPS?

HTTPS is an HTTP channel aimed at security; simply put, it is the secure version of HTTP, which adds an SSL layer. The security foundation of HTTPS is SSL, so the details of encryption require SSL. The main functions of the HTTPS protocol can be divided into two: one is to establish a secure information channel to ensure the security of data transmission; the other is to verify the authenticity of the website.

HTTPS is not a new protocol at the application layer; it simply replaces the HTTP communication interface with SSL (Secure Socket Layer) and TLS (Transport Layer Security) protocols. Typically, HTTP communicates directly with TCP. When using SSL, it evolves to first communicate with SSL, then with TCP. In simpler terms, HTTPS is HTTP wrapped in the SSL protocol.

HTTPS Communication Process:

1. The client accesses the web server using an HTTPS URL, requesting to establish an SSL connection.

2. Upon receiving the client’s request, the web server sends the website’s certificate information (which includes the public key) to the client.

3. The client’s browser and the web server begin negotiating the security level of the SSL connection, which is the level of information encryption.

4. The client’s browser establishes a session key based on the agreed security level, encrypts it with the website’s public key, and sends it to the website.

5. The web server uses its private key to decrypt the session key.

6. The web server uses the session key to encrypt communication with the client.

Why is HTTPS Secure?

1. SSL provides not only encryption processing but uses a method called certificates for verification. Certificates are issued by trusted third-party organizations to prove the existence of the server and client. Moreover, forging a certificate is technically very difficult. Therefore, as long as the authenticity of the certificate held by the communicating party (server or client) can be confirmed.

Encryption Methods

Symmetric Encryption: The method of encryption and decryption using the same key is called shared key encryption (Common key crypto system), also known as symmetric key encryption.

Symmetric encryption methods have lower efficiency and slower encryption speeds. Additionally, symmetric encryption has security risks; the symmetric encryption key must be transmitted to the other party for decryption, and if the key is intercepted during transmission, it defeats the purpose of encryption, making it unsafe to rely solely on symmetric encryption.

Asymmetric Encryption: Public key encryption uses a pair of asymmetric keys. One is called the private key, and the other is called the public key. As the names imply, the private key must not be known to anyone, while the public key can be freely distributed. In public key encryption, the sender encrypts the message using the recipient’s public key, and the recipient decrypts it using their private key.

However, is asymmetric encryption completely secure? It is not, due to the possibility of an intermediary forging the public and private keys. If someone intercepts the public key during transmission and replaces it with their own forged public key, the recipient will not receive the true public key. When the recipient encrypts a file using the forged public key and sends it back, the interceptor can decrypt the file using their private key.

Hybrid Encryption Mechanism (combining symmetric and asymmetric encryption methods) is exactly what it sounds like: a combination of symmetric and asymmetric encryption.

How to prove the authenticity of the public key itself? Because during the transmission of the public key, it is possible that the true public key has been replaced by an attacker. To solve this issue, in addition to CA certification certificates, the server sends the CA certificate to the client for public key encrypted communication. Upon receiving the certificate, the client can use the public key of the digital certificate authority to verify the digital signature on the certificate. Once verified, the client can confirm two things: first, that the public key of the server is a valid digital certificate issued by a trusted authority; second, that the server’s public key is trustworthy.

Thus, how the public key is handed over to the client is crucial. Therefore, most browser developers embed the public keys of commonly used certification authorities in their software versions to ensure that the public key is the one used by the certification authority, avoiding the risk of public key forgery and ensuring security.

Highly recommend a high-quality content sharing architecture + algorithms. If you haven’t followed yet, please do so by long-pressing to subscribe:

Long press to subscribe for more exciting content ▼

If you found this helpful, please give it a thumbs up. Thank you sincerely.