Network Knowledge in Depth: From Layers to HTTPS Encryption, Master Key Interview Skills

In today’s digital age, network knowledge is undoubtedly the key to unlocking the ideal career for operations engineers and programmers. For them, a solid understanding of networking fundamentals has become an essential skill requirement. With this in mind, I have carefully compiled and summarized common interview questions in the field of networking. The questions are explained in a structured manner to help present the key concepts of networking clearly and enable job seekers to confidently stand out in interviews. The following topics will be addressed in detail:

• How is networking layered?

• The reasons and details of the three-way handshake

• The four-way handshake in TCP

• Time_wait and Close_wait states

• Differences and selection between UDP and TCP

• HTTP status codes

• HTTP long connections

• The encryption principles of HTTPS

How is Networking Layered?

The design of network layers aims to improve the manageability and scalability of communication systems. By breaking down complex communication processes into multiple layers, each layer focuses on specific functions and tasks, much like the division of labor in society. Each layer is responsible for solving a particular problem, and they work together to complete the entire data communication process.

Let’s use a specific example to better understand the functionality of network layers. Suppose you are learning a programming technology and want to buy a textbook. This book may be a key resource for your studies, so what you care about first is the content and how to use it, which corresponds to the application layer. The application layer focuses on the needs of the end user, defining the interaction between applications and networks. For example, you need to know the book’s chapters, content depth, etc., and these are handled by the application layer.

Next, you need to get the book from the store or publisher to your home. For this, you’ll need a courier service. To ensure the book is delivered correctly, you need to provide a detailed delivery address and phone number, which corresponds to the transport layer. In networking, the transport layer primarily relies on the TCP protocol to ensure reliable data transfer. TCP uses source and destination port numbers, data acknowledgment mechanisms, retransmission mechanisms, etc., to ensure that each segment of data arrives safely at the destination host. This is like ensuring a courier knows the correct address and phone number to deliver the package.

However, just having an address and phone number is not enough because they only ensure the courier reaches your general area. To ensure the delivery reaches your specific neighborhood, a route plan is needed. This is the responsibility of the network layer, which is in charge of determining the optimal path for data packets from source to destination. In networking, the network layer uses routing protocols (such as RIP, OSPF, BGP, etc.) to select the best path for transmitting data from source devices to target devices through intermediate devices (such as routers). This process is similar to a courier using a map to plan the delivery route.

But the problem is still not solved. After reaching your neighborhood, the courier still needs to find your specific house. The map can only guide the courier to the neighborhood but cannot guide them to your exact address. To find your door, the courier may need to ask the property management or the gatekeeper. This corresponds to the data link layer in networking, which is responsible for transferring data frames within the same network or subnet, ensuring that data reaches another node accurately. The data link layer uses mechanisms like MAC addresses, error detection, and correction to ensure data is transmitted correctly between devices within the same network.

Finally, the courier needs to deliver the book to your doorstep, using physical devices like carts, tablets, and packaging boxes. These physical devices are the work of the physical layer, which is responsible for the actual transmission medium and physical equipment. In networking, the physical layer uses cables, optical fibers, wireless signals, and other media to transmit data in the form of electrical signals, light signals, or wireless signals. This is like the courier using various tools to deliver the book, with the physical layer ensuring data transmission in the physical world.

Through this example, we can see that each layer in the network has its own unique function. The application layer concerns the “how to use” of data, the transport layer ensures data reliability, the network layer plans the path, the data link layer ensures correct transmission within a local network, and the physical layer handles the actual data transmission. This layered design makes network communication more structured and modular, allowing each layer to be optimized and upgraded independently without affecting other layers. Layering improves network efficiency and reliability, making complex network tasks manageable and maintainable.

TCP Three-Way Handshake: Reasons and Details

TCP is a full-duplex communication protocol, meaning both parties can send and receive data simultaneously. To ensure reliable communication, both sides need to continually exchange information to confirm whether they are ready to receive data. This process can be likened to the confirmation messages exchanged between a courier and recipient during the delivery process.

Let’s use the analogy of a courier delivering a package to explain this process:

First: The courier says, “I’m ready to deliver the package. My sequence number is 1.”
Here, the courier informs you that they are ready to start delivery, and they assign a sequence number (1) for this communication.

Second: You reply, “Okay, I’m at home waiting for the package, received sequence number 2. I also have a package to send, with sequence number 100.”
You confirm that you’re ready to receive the package and tell the courier that you also have a new package to send, with sequence number 100. You assign sequence number 2 to confirm your readiness.

Third: The courier replies again, “Okay, I’m ready to deliver the package, my sequence number is 2; I confirm that you’re sending a package with sequence number 101.”
At this point, the courier confirms your readiness to send the package and acknowledges the sequence number for the upcoming package (101).

The third confirmation is not redundant. While it may seem like the second confirmation is enough, in reality, the third confirmation is necessary. Without this mechanism, the connection could fail. If one side fails to confirm in time, the other side may incorrectly assume the connection has been dropped and will attempt to reconnect. This wastes server resources, potentially causes connection confusion, and might quickly exhaust the server’s connection port resources, affecting the entire system’s stability and efficiency.

This multi-step confirmation ensures both parties are clear about each other’s state and prevents unnecessary reconnections and resource waste. Therefore, the third confirmation is crucial in maintaining stable and efficient communication.

TCP Four-Way Handshake Process

In TCP, the four-way handshake is the process used to gracefully close a connection. It involves two main messages: FIN and ACK.

FIN (Finish) indicates that the side ending the connection will no longer send data, closing the data transmission channel in that direction.

ACK (Acknowledge) indicates acknowledgment of receiving the other party’s message, signaling that the receiving side has closed that direction’s connection.

Through the four-way handshake, both parties can orderly close the connection and avoid data loss or interruption. Here’s the process:

First handoff:
A sends a FIN message to B, indicating that A has no more data to send and wants to close the data transmission channel with B. A says, “I’m done, that’s it for today.” (A sends FIN)

Second handoff:
B receives A’s FIN and sends an ACK message to confirm it. B says, “Okay, let’s hang up.” (B sends ACK)

Third handoff:
B is also ready to close the connection, so B sends a FIN message to A, indicating no more data to send, preparing to close the connection. B says, “I’m hanging up now.” (B sends FIN)

Fourth handoff:
A receives B’s FIN and sends an ACK message to confirm receipt of B’s connection closure request. A says, “Okay, we’re done.” (A sends ACK)

This process ensures both parties can smoothly disconnect, and only after both sides’ transmission channels are correctly closed, the connection is fully released. Through the four-way handshake, TCP ensures reliable, bidirectional connection termination.

Why does closing a connection require four steps?

This is because TCP does not allow the connection to be half-open with one-way data transmission. In the three-way handshake to establish the connection, the server combines the ACK and SYN messages and sends them to the client. Specifically, the ACK is used to acknowledge the client’s connection request and open the client’s receiving channel, while the SYN is used to open the server’s sending channel. This synchronization of the sending channels between the client and server is completed in the three-way handshake, while the four-way handshake ensures proper termination.

TIME_WAIT and CLOSE_WAIT

In the process of closing a TCP connection, the side that initiates the termination (usually the client, A) and the side that passively terminates the connection (usually the server, B) behave differently and enter different states. When A initiates the termination, it usually means it has no more data to send and is ready to close the connection, while B might still have data to send or may change its mind during the process. TCP introduces necessary mechanisms, with the TIME_WAIT and CLOSE_WAIT states playing crucial roles.

Why must A enter the TIME_WAIT state?

Ensuring the final ACK can be successfully transmitted:
In the closing process of a TCP connection, the side initiating the termination (A) sends a FIN message and waits for B’s ACK confirmation. This is the final step of closing the connection. If B doesn’t receive A’s final acknowledgment (ACK), it may retransmit its FIN message. Therefore, A enters the TIME_WAIT state to ensure it can receive and retransmit the final ACK message to ensure B correctly enters the closed state.

Fault tolerance and retransmission:
TCP is a reliable protocol, assuming packet loss or errors during transmission. If A’s ACK message is not successfully transmitted, B will retransmit its FIN message. If A directly enters the CLOSED state without TIME_WAIT, A might lose the context of the connection and fail to respond correctly to B’s retransmission request, causing connection closure failure. Therefore, by staying in the TIME_WAIT state, A ensures that it can re-send the ACK after receiving B’s FIN message, helping B transition to the CLOSED state properly.

Why does B not enter TIME_WAIT?

During the connection closure, the passive side (B) doesn’t enter TIME_WAIT, but enters CLOSE_WAIT. While B is in CLOSE_WAIT, it indicates that B has received A’s request to close the connection (FIN) and is ready to close its sending channel but is still waiting for A’s final acknowledgment.

Another reason: Avoiding interference from old connections:

The four-tuple (source IP, source port, destination IP, destination port) uniquely identifies a connection. However, network packets may be delayed due to various reasons (like router restarts or link failures). Delayed packets from old connections are called “zombie packets.” If these packets arrive after the connection has been closed and not processed correctly, they could cause errors or issues with the new connection.

To prevent this, TCP introduces the TIME_WAIT state. While in TIME_WAIT, A ensures that all zombie packets from the network disappear. This delay is usually sufficient to clear old packets from the network, ensuring they don’t interfere with new connections.

If A stays in TIME_WAIT for 2 * MSL, any packets from old connections will be discarded, and a new connection will be handled independently.

Differences Between UDP and TCP

TCP and UDP are two common network communication protocols that operate differently and are suitable for different use cases. You can compare the characteristics and usage scenarios of these two protocols based on the following aspects.

1. Reliability

TCP (Transmission Control Protocol) is a reliable protocol, meaning it ensures correct data transmission through acknowledgment mechanisms (like the three-way handshake to establish the connection and the four-way handshake to close the connection) and retransmission mechanisms (re-sending data if lost). For example, TCP is like communicating over the phone where both parties receive immediate feedback to ensure every message is received and acknowledged.

UDP (User Datagram Protocol), on the other hand, is unreliable and doesn’t guarantee the order, integrity, or timeliness of data. Once a packet is sent, the sender cannot confirm whether it was received by the recipient. UDP is like sending a letter without knowing if the recipient received it or when.

2. Connection Method

TCP is a connection-oriented protocol, using a one-to-one connection. Both parties must establish a connection before starting data transmission. This means TCP needs to negotiate the connection beforehand and manage the state.

UDP is a connectionless protocol, supporting one-to-one or one-to-many communication modes without the need to establish a connection beforehand or maintain state.

3. Data Transmission Method

TCP is a byte-stream protocol. Although the application layer usually interacts with TCP using data blocks, TCP views the data as a continuous stream of bytes, without boundaries. Therefore, the data sent to TCP can be of any size, and TCP automatically splits it into segments suitable for network transmission.

UDP is a message-oriented protocol. Each message passed to UDP maintains its boundary, and UDP doesn’t split or merge data packets. It sends each data packet as is.

4. Header Size

TCP’s header is typically between 20-50 bytes as it carries more control information (such as sequence numbers, acknowledgment numbers, window size, etc.).

UDP’s header is much simpler, fixed at 8 bytes, containing only basic information like source and destination ports, length, and checksum.

5. Use Cases

TCP is suitable for applications requiring reliable transmission, such as file transfers (FTP), web browsing (HTTP/HTTPS), and email (SMTP/IMAP). These applications demand accuracy and ordered delivery, so TCP guarantees reliability.

UDP is ideal for applications that require real-time data delivery and can tolerate some data loss, such as VoIP, online gaming, live streaming, and DNS queries. UDP’s low latency and minimal protocol overhead make it highly efficient for these scenarios.

6. Enhanced Reliability with UDP: QUIC Protocol

In some UDP-based protocols, developers add mechanisms to simulate TCP’s reliability. One such protocol is QUIC, developed by Google. QUIC uses UDP with enhanced reliability features to provide secure and efficient connections.

Summary

By comparing TCP and UDP, we can see that TCP is better suited for applications requiring guaranteed reliability, while UDP is ideal for scenarios with high speed and real-time data needs where some packet loss is acceptable. In certain scenarios, protocols like QUIC combine the best of both, offering reliable connections built on UDP.

HTTP Status Codes

Below is a table displaying common HTTP status codes and their descriptions:

Status Code	Description	Explanation
200	OK	Request succeeded and the server returned data
201	Created	Request succeeded and the server created a new resource
204	No Content	Request succeeded but no content returned
301	Moved Permanently	Permanent redirect, resource moved to a new location
302	Found	Temporary redirect, resource temporarily moved
304	Not Modified	Resource not modified, client can use cached version
400	Bad Request	Invalid request, server can’t understand the request
401	Unauthorized	Unauthorized, missing authentication
403	Forbidden	Forbidden access, server understands the request but refuses to process it
404	Not Found	Resource not found, server can’t find the requested resource
405	Method Not Allowed	Request method not allowed, e.g., using GET to submit data
408	Request Timeout	Request timed out, server didn’t receive a complete request
409	Conflict	Request conflict, e.g., resource state conflicts with request
410	Gone	Resource permanently gone and no longer available
500	Internal Server Error	Server error, unable to process request
502	Bad Gateway	Gateway error, server acting as a gateway could not get a valid response
503	Service Unavailable	Service unavailable, server overloaded or under maintenance
504	Gateway Timeout	Gateway timeout, server acting as a gateway could not get a timely response

HTTP Long Connections

When you download a large file from a cloud storage service, you usually only need to establish a single HTTP connection. This can be understood through three key aspects: HTTP long connections, chunked transfer, and file compression.

1. HTTP Long Connections (Keep-Alive)

HTTP’s Keep-Alive feature (also called HTTP long connections) allows multiple HTTP requests and responses to be sent over a single TCP connection. Unlike traditional short connections (where each request requires a new TCP connection), long connections reduce the overhead of frequently establishing and closing TCP connections, improving efficiency. Long connections allow the client and server to exchange data over the same connection, avoiding the need to establish a new connection for each request.

When downloading a file from cloud storage, typically, only one connection is needed. The server and client can transfer multiple chunks of data over this connection, significantly reducing the overhead of creating and releasing connections.

2. Chunked Transfer Encoding

For large files, HTTP supports chunked transfer encoding. In this mode, the body of the response is not sent all at once, but rather in smaller chunks (chunks). The server includes Transfer-Encoding: chunked in the response header to indicate that the body is split into chunks.

The advantage of chunked transfer is that it allows the server to begin sending data before the entire file is ready, improving responsiveness. The client can start receiving and processing data without waiting for the entire file to finish downloading.

3. File Compression

HTTP also supports compression to reduce the size of the transmitted data. In the request and response headers, the client can indicate supported compression formats, such as gzip, deflate, or br, using the Accept-Encoding field. The server selects an appropriate compression algorithm and sends the compressed content to the client with the Content-Encoding header.

Compression is particularly useful for text-based data such as HTML

, CSS, and JavaScript. For multimedia files like images, audio, and video that are already compressed, further compression typically won’t help and could even increase the file size.

When you download a large file, only one HTTP connection is usually needed. The process may use an HTTP long connection to reduce connection overhead, chunked transfer to break the file into segments, and compression to minimize data transfer size. However, compression has little effect on highly compressed multimedia files.

HTTPS Encryption

Initially, understanding encryption methods might involve hearing signals like beeps from various encryption machines. Everyone has a password book to encrypt and decrypt information. However, as communication complexity increased and attackers advanced, simple encryption methods exposed many problems. Therefore, encryption technology has evolved in several stages, each addressing security, integrity, and identity verification issues.

First round: Symmetric Encryption

The earliest form of encryption was symmetric encryption, like using the same password book to encrypt and decrypt messages between headquarters and operatives. Both parties used the same key. This method seemed simple but had a major flaw: if the password book was stolen, anyone could easily decrypt the messages.

Second round: Asymmetric Encryption

After realizing the flaws in symmetric encryption, both sides quickly adopted asymmetric encryption. In this method, both parties have a pair of keys, a public key and a private key. The sender uses the receiver’s public key to encrypt the message, which can only be decrypted with the receiver’s private key. This way, even if the enemy intercepts the encrypted message, it remains unreadable without the private key.

Additionally, asymmetric encryption can be used for identity verification. For example, both parties can exchange keys to ensure that only they can securely exchange information.

Third round: Symmetric + Asymmetric Encryption

However, while asymmetric encryption is secure, it is slower, especially for large files. To improve efficiency, both sides decided to combine symmetric and asymmetric encryption: asymmetric encryption is used to exchange the symmetric key, and once the key is shared, the communication can use symmetric encryption for faster operations.

Fourth round: Digital Signatures & Identity Verification

Next, both sides need to verify each other’s identity. Just exchanging keys and encrypting messages is not enough to prove the message truly came from the other side. To prevent impersonation, both sides decide to use digital signatures to verify the message’s source.

They obtain a digital certificate from a trusted authority. The certificate contains the sender’s identity and the authority’s public key. If an attacker tries to impersonate the sender, they would have to break the certificate, which is highly difficult because of complex encryption algorithms and certificate validation mechanisms.

Fifth round: Integrity Verification

Lastly, both sides need to ensure that the message has not been tampered with or lost during transmission. Attackers could delete or modify parts of the message, disrupting its integrity. To solve this, both sides add security tags to each message.

Hashing algorithms (Hash) are commonly used to verify message integrity. Every message has a hash value appended, which represents its unique identity. If the message is modified during transmission, the hash value will change, and the receiver can check the integrity by comparing the received hash with the original.

The overall encryption process used by HTTPS follows these principles. HTTPS uses a combination of symmetric and asymmetric encryption to ensure data security, digital certificates to verify identities, and hash algorithms to guarantee data integrity. Through these encryption techniques, HTTPS ensures security, identity verification, and message integrity.
```