[Computer Network] Summary of Basic Knowledge of Computer Network (Autumn Recruitment)

Article directory


foreword

The author of the computer network in the summary of autumn recruiting notes
is written by chatgpt, so there may be some ways out of some answers (the 3.5 version of GPT has some defects), most of the answers have been corrected after I finished writing, and if there are discrepancies, I hope all students pointed out.
Reference Textbook: Computer Network 7th Edition
2023.7.25 First update

computer network notes

This note focuses on the TCP and HTTP protocols

What is the difference between TCP and UDP

insert image description here

TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are two transport layer protocols commonly used in computer networks .

TCP is a connection-oriented protocol that provides reliable data transmission. It ensures the reliable transmission of data by using technologies such as sequence numbers, confirmation numbers, retransmission mechanisms, and congestion control. TCP establishes a connection, transmits data, guarantees the order and integrity of the data, and releases the connection after the transmission is complete. TCP is suitable for applications that require high reliability of data transmission, such as file transmission, email, web browsing, etc.

UDP is a connectionless protocol which provides unreliable data transfer. UDP encapsulates data into datagrams, each datagram is independent, there is no order, and there is no confirmation and retransmission mechanism. UDP does not need to establish a connection and sends data directly. UDP is suitable for applications with high real-time requirements and relatively low data reliability requirements, such as real-time audio and video transmission, online games, etc.

the difference:

  1. Connectivity: TCP is a connection-oriented protocol, and UDP is a connectionless protocol. TCP needs to establish a connection before communicating, while UDP sends data directly.
  2. Reliability: TCP provides reliable data transmission, and UDP does not provide reliability guarantees. TCP uses acknowledgment and retransmission mechanisms to ensure data integrity and reliability, while UDP does not provide these mechanisms.
  3. Sequence: TCP guarantees the order of data transmission, while UDP does not guarantee the order of data. TCP sorts packets to ensure data is received in the order it was sent, while UDP does not sort packets.
  4. Congestion control: TCP has a congestion control mechanism that can adjust the data transmission rate according to network conditions to avoid network congestion. UDP has no congestion control mechanism, and the transmission rate of data packets is determined by the application.
  5. Transmission efficiency: UDP has low transmission overhead and high transmission efficiency, while TCP has a large transmission overhead. TCP needs to establish a connection, maintain state information, and perform error detection. These additional overheads will lead to low transmission efficiency.
  6. Application scenarios: TCP is suitable for applications that require high reliability of data transmission, such as file transfer, email, web browsing, etc. UDP is suitable for applications with high real-time requirements and relatively low data reliability requirements, such as real-time audio and video transmission, online games, etc.
  7. Size limit: TCP has no fixed packet size limit, which can be adjusted according to network conditions and application requirements. The packet size of UDP is limited by the maximum transmission unit (MTU) of the network, usually 1500 bytes.
  8. Number of connections: TCP can support one-to-one, one-to-many, and many-to-one connections, while UDP is usually used for one-to-one or one-to-many simple communications.

You need to choose whether to use TCP or UDP according to the specific application requirements. If the reliability and sequentiality of data transmission is important, you can choose TCP. If real-time and transmission efficiency are more important, you can choose UDP.

What are the upper layer protocols based on the two protocols of TCP and UDP?

The upper layer protocols based on the TCP protocol are:

  1. HTTP (Hypertext Transfer Protocol): Used to transmit hypertext data between web browsers and web servers, it is the most commonly used protocol for web applications.
  2. FTP (File Transfer Protocol): Used to transfer files between a client and a server.
  3. SMTP (Simple Mail Transfer Protocol): Used to transfer email between mail clients and mail servers.
  4. POP3 (Post Office Protocol Version 3): Used to receive e-mail from a mail server.
  5. IMAP (Internet Message Access Protocol): Used to manage email between mail clients and mail servers.

The upper layer protocols based on UDP protocol are:

  1. DNS (Domain Name System): Used to resolve domain names into IP addresses, enabling computers to access Internet resources through domain names.

  2. DHCP (Dynamic Host Configuration Protocol): Used to automatically assign IP addresses and other network configuration information to computers.

  3. TFTP (Trivial File Transfer Protocol): Used to transfer files between client and server, similar to FTP but simpler.

  4. SNMP (Simple Network Management Protocol): Used for management and monitoring between network devices.

  5. RTP (Real-time Transport Protocol): Used to transmit audio and video data in real-time applications.

In which fields are TCP and UDP used more?

Application fields of TCP:

  1. Web browsing: TCP is widely used to transmit HTTP protocol data to ensure reliable transmission of web content.
  2. File Transfer: The reliability and sequential nature of TCP make it the preferred choice for file transfer protocols like FTP and SFTP.
  3. Email: TCP's reliability and connectivity make it the basis for email protocols like SMTP and POP3.
  4. Remote login: TCP is used in remote login protocols such as SSH (Secure Shell) to ensure reliable connection of remote terminals.
  5. Database access: TCP is used for database access protocols, such as MySQL, PostgreSQL, etc., to ensure reliable transmission of data.

Application fields of UDP:

  1. Real-time audio and video transmission: UDP's low latency and high transmission efficiency make it the preferred protocol for real-time audio and video transmission, such as VoIP (Voice over IP) and video conferencing.
  2. Online games: UDP is widely used in online games because it can provide lower latency and faster transmission speed, and is suitable for game scenarios with high real-time requirements.
  3. Real-time data transmission: UDP is suitable for applications that require fast transmission of real-time data, such as sensor data, stock quotes, etc.
  4. DNS resolution: UDP is used in the domain name system (DNS) resolution process to quickly resolve domain names into IP addresses.
  5. Broadcast and multicast: UDP supports broadcast and multicast functions, making it suitable for multipoint communication and streaming media transmission.

What technologies does TCP use to achieve reliable transmission? (How TCP achieves reliable transmission)

Some of the main techniques used by TCP to achieve reliability:

  1. Sequence number and confirmation mechanism: TCP divides data into small data blocks and assigns a unique sequence number to each data block. The receiver confirms the received data by sending an acknowledgment segment. The sender determines which data has been received and which data needs to be retransmitted according to the received confirmation segment.

  2. Timeout retransmission: If the sender does not receive an acknowledgment segment within the specified time, it assumes data loss and resends the data. The timeout period will be dynamically adjusted according to network conditions and congestion levels.

  3. Sliding window: TCP uses a sliding window mechanism to control the rate at which the sender sends data. The sliding window size depends on the receiver's available buffer size and how congested the network is. The sender can only send data within the range of the sliding window, and the receiver updates the position of the sliding window by confirming the segment.

  4. Congestion control: TCP uses congestion control algorithms to avoid network congestion. It monitors network congestion by dynamically adjusting the sending rate, and makes corresponding adjustments based on network feedback.

  5. Reordering and reassembly: TCP can handle the reordering and reassembly of segments in the network. It sorts and reassembles the received message segments according to the sequence number to ensure the correctness of the data.

  6. Parity checksum: When TCP transmits data, it calculates the checksum and appends the checksum to the data segment. When receiving data, the receiver will recalculate the checksum and compare it with the checksum in the message segment to detect whether the data is wrong or damaged.

Talk about timeout retransmission and timeout timer

Timeout retransmission and timeout timer are two important mechanisms in the TCP protocol for reliable data transmission.

Timeout retransmission means that after the sender sends data, if it does not receive an acknowledgment (ACK) message within a certain period of time, it will consider the data lost and trigger a timeout retransmission mechanism. The sender will resend the unacknowledged data to ensure reliable data transmission. The time for overtime retransmission is usually controlled by a timeout timer.

The timeout timer is a timer used by the sender to keep time. When the sender sends data, it starts a timeout timer and sets a timeout period. If the confirmation message is not received within the timeout period, the timeout timer will be triggered, and the sender will consider the data lost and trigger the timeout retransmission mechanism. The time of the timeout timer is usually dynamically adjusted by the congestion control algorithm to adapt to different network environments. (If the network congestion is severe, the sender will set the timeout timer to a shorter time, so as to detect packet loss faster and trigger the timeout retransmission mechanism. Conversely, if the network congestion is low, the sender will timeout The timer time is set longer to avoid unnecessary retransmissions.)

Talk about sliding window control

Sliding window control is a window-based flow control mechanism for reliable data transmission. It controls the transmission of data through the window between sender and receiver.

The principle of sliding window control is as follows:

  1. Send window: The sender maintains a send window, which represents the range of data segments that the sender can send. The size of the sending window depends on the bandwidth and delay of the network, and can be dynamically adjusted according to the condition of the network.
  2. Receive window: The receiver maintains a receive window, which represents the range of data segments that the receiver can receive. The size of the receive window depends on the receiver's processing power and buffer size.
  3. Window sliding: When sending data, the sender divides the data into multiple data segments and sends them to the receiver in sequence. The sender will wait for the receiver to send a confirmation message, confirming that the data has been successfully received. Once the receiver confirms receipt of a data segment, the sender can slide the send window forward, allowing more data to be sent.
  4. Acknowledgment and retransmission: After receiving the data segment, the receiver will send an acknowledgment message to the sender. If the sender does not receive an acknowledgment within a certain period of time, it will consider the data segment lost and retransmit it. The sender can selectively retransmit lost data segments without retransmitting the entire data stream.

The workflow of sliding window control is as follows:

  1. The sender divides the data into multiple data segments and sends them sequentially according to the window size.
  2. After receiving the data segment, the receiver stores it in the receive buffer and sends an acknowledgment message to the sender.
  3. After receiving the confirmation message, the sender slides the sending window forward to allow more data to be sent.
  4. If the sender does not receive an acknowledgment within a certain period of time, it will consider the data segment lost and retransmit it.

Through sliding window control, the sender and receiver can control data transmission according to the size of the window and the speed of sliding. This mechanism can improve the efficiency and reliability of data transmission while adapting to different network environments and conditions.

To sum up, sliding window control controls the transmission of data through the sending window and receiving window. The sender slides the window based on the receiver's acknowledgment, allowing more data to be sent. The receiver confirms the successfully received data according to the size of the receiving window, and sends a confirmation message to the sender. Through this mechanism, sliding window control can improve the efficiency and reliability of data transmission.

The hazards of sliding windows that are too large or too small

Too large or too small a sliding window will adversely affect the efficiency and reliability of data transmission.

  1. Sliding window is too large:
    • Bandwidth waste: If the sliding window is too large, the sender will continuously send a large number of data segments, and the receiver may not be able to process and confirm these data segments in time. This causes buffer overflow on the receiving side, causing data loss and thus wasting network bandwidth.
    • Increased congestion: If the sliding window is too large, the network congestion will increase. When a sender sends a large number of data segments in succession, the network may become congested, leading to increased latency and increased packet loss. This reduces overall transmission efficiency and reliability.
  2. Sliding window is too small:
    • Low transmission efficiency: If the sliding window is too small, the sender can only send a small amount of data segments at a time, and needs to wait for the receiver to send a confirmation message before sending the next batch of data. This will cause the sender to fail to fully utilize the network bandwidth and reduce the efficiency of data transmission.
    • Increased delay: If the sliding window is too small, it will increase the delay of data transmission. The sender needs to wait for the receiver's acknowledgment information, which will increase the waiting time of the sender, thereby prolonging the data transmission time.

Therefore, the size of the sliding window needs to be set reasonably according to the bandwidth, delay and congestion of the network. If the window is too large, it may lead to bandwidth waste and increased congestion; if the window is too small, it may lead to inefficient transmission and increased delay. With an appropriate window size, efficient and reliable data transmission can be achieved.

How does a sliding window achieve flow control?

The following is the basic principle of sliding window to achieve flow control:

  1. The sender maintains the size of the send window: the sender controls the amount of data sent by maintaining a send window. The size of the sending window depends on the bandwidth and delay of the network, and can be dynamically adjusted according to the condition of the network.
  2. The receiver maintains the size of the receiving window: the receiver controls its own processing power and buffer size by maintaining a receiving window. The size of the receive window indicates the amount of data that the receiver can currently receive.
  3. The sender sends data according to the receive window size of the receiver: the sender determines the amount of data that can be sent according to the receive window size of the receiver. The sender can only send data within the sending window, but cannot exceed the size of the receiving window.
  4. The receiver sends window size information to the sender: the receiver will include its receiving window size information in the confirmation message and send it to the sender. In this way, the sender can adjust the size of its sending window according to the size of the receiving window of the receiver.
  5. Dynamically adjust the size of the sending window: the sender dynamically adjusts the size of its sending window according to the receiving window size information sent by the receiver. If the receive window of the receiver becomes larger, the sender can send more data; if the receive window of the receiver becomes smaller, the sender needs to reduce the amount of data sent.

In this way, the sliding window mechanism implements flow control, ensuring that the rate of data transfer between sender and receiver adapts to the conditions of the network. The sender will control the amount of data sent according to the receiving window size of the receiver, so as to avoid sending too much data and causing the receiver to be unable to process it in time, thereby improving the efficiency and reliability of data transmission.

What is TCP's congestion control technology? What are the common congestion control algorithms?

[External link picture transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the picture and upload it directly (img-dO7etMCJ-1690270230621) (C:\Users\93701\AppData\Roaming\Typora\typora-user-images\ image-20230723144208996.png)]

Congestion control is a network traffic management mechanism used to avoid or reduce the occurrence of network congestion in computer networks. Congestion occurs when data traffic in a network exceeds the processing capacity of network links, switches or routers, resulting in degraded network performance, increased latency and even data loss.

The goal of congestion control is to maintain the stability and reliability of the network by limiting the data transmission rate of the sender or adjusting the allocation of network resources to ensure that the traffic in the network will not exceed the capacity of the network.

The congestion window (Congestion Window) is a mechanism used in the TCP protocol to control the amount of data sent by the sender. It is a flow control mechanism introduced to avoid network congestion.

The size of the congestion window indicates how much data the sender can send. Initially, the size of the congestion window is relatively small, and the sender can only send a small amount of data. With the normal operation of the network and the successful transmission of data packets, the congestion window will gradually increase, and the sender can send more data.

The congestion control techniques used by TCP mainly include slow start, congestion avoidance, fast retransmission and fast recovery .

  1. Slow Start: When the TCP connection is first established, the sender sets the initial congestion window to a small value, and then doubles the size of the congestion window every time a round-trip time (RTT) passes to gradually increase the number of senders. The sending rate until reaching the congestion point of the network or the maximum value of the congestion window. (Increase the sending window from small to large, keep trying)

  2. Congestion Avoidance: After the slow start phase ends, the sender will enter the congestion avoidance phase. At this stage, the sender only increases the size of the congestion window by one RTT each time, so as to slowly increase the sending rate to avoid excessive data traffic entering the network. (Instead of the doubling growth of slow start, it belongs to linear growth, "additional increase")

  3. Fast Retransmit: When the sender receives three repeated acknowledgments (ACKs) in a row, it will think that a packet is lost, not due to network congestion . The sender immediately retransmits lost packets without waiting for the timeout timer to fire. (Fast retransmission can increase the throughput of the entire network by about 20%)

  4. Fast Recovery: After fast retransmission, the sender will enter the fast recovery phase. In this phase, the sender halves the congestion window and sets the size of the congestion window to half of what it was before losing packets. Then, the sender continues to gradually increase the size of the congestion window with the congestion avoidance algorithm.

Common congestion control algorithms include:

  • Tahoe algorithm: The earliest TCP congestion control algorithm, only slow start and congestion avoidance phase.

  • Reno algorithm: Based on the Tahoe algorithm, fast recovery and fast retransmission mechanisms are added.

  • New Reno algorithm: The Reno algorithm has been improved, and a more flexible fast recovery and fast retransmission mechanism has been added.

  • Cubic algorithm: based on the square function of the congestion window, it has better network adaptability and fairness.

  • BBR algorithm: Based on the estimation of bandwidth and round-trip time, it can adjust the sending rate more accurately and improve network throughput.

The difference between TCP flow control and congestion control

TCP flow control and congestion control are two different mechanisms in the TCP protocol, and their goals and implementation methods are also different.

Flow control is to ensure that the receiver can process the data from the sender, and prevent the sender from sending too much data so that the receiver cannot process it in time. Flow control is carried out between the sender and the receiver, by the receiver sending window size information to the sender, telling the sender how much space it has available in the receive buffer. The sender controls the rate of sending data according to the window size of the receiver to ensure that the receiver can process the data in time.

Congestion control is a mechanism introduced to avoid network congestion. Congestion control is carried out in the network, and the sending rate of the sender is adjusted by monitoring the congestion degree of the network and the feedback information of the receiver. When the network is congested, congestion control will reduce the sending rate of the sender to reduce the load on the network and prevent further aggravation of congestion. The congestion control algorithm will dynamically adjust the congestion window size of the sender according to the network congestion to achieve reasonable flow control.

To sum up, flow control is the control to ensure that the receiver can process data, and congestion control is the control to avoid network congestion. Flow control is done between sender and receiver while congestion control is done in the network. Both are to ensure the reliable transmission of data and the optimization of network performance, but their goals and implementation methods are different.

Talk about the working principle of TCP connection establishment

TCP (Transmission Control Protocol) is a connection-oriented and reliable transport layer protocol, which plays an important role in network communication. Here is a brief introduction to how TCP works:

  1. Establish a connection: Before TCP communication, the client and server need to establish a connection through a three-way handshake. First, the client sends a SYN (synchronization) message to the server, and the server replies a SYN+ACK (synchronization + confirmation) message to the client after receiving it, and finally, the client replies an ACK (confirmation) message to the server . In this way, the connection is established. (three-way handshake)
  2. Data transfer: Once the connection is established, the client and server can start transferring data. TCP uses a sliding window mechanism for flow control and congestion control. The sender divides the data into small pieces called TCP segments and sends them to the receiver. The receiver will confirm the received data, and the sender can adjust the sending rate according to the receiver's confirmation information.
  3. Confirmation and retransmission: After receiving the data, the receiver will send a confirmation message to the sender, indicating that it has been successfully received. If the sender does not receive the confirmation message within a certain period of time, it will consider the data lost and retransmit it. The receiver can use the sequence number to check for missing data segments and discard them to avoid repeated processing.
  4. Close the connection: When the data transmission is completed or the connection needs to be terminated, the connection can be closed by a four-way handshake. First, one party sends a FIN (end) message to the other party, and the other party replies with an ACK message for confirmation after receiving it. Then, the other party sends a FIN message to the first party, and the first party replies with an ACK message to indicate confirmation after receiving it. Finally, the connection is closed. (waves four times)

The working principle of TCP ensures the reliable transmission and sequentiality of data, and also has flow control and congestion control mechanisms to meet the transmission requirements in different network environments. This makes TCP one of the most widely used transport protocols on the Internet.

Focus on TCP's three-way handshake and four-way wave process

When a TCP connection is established, a three-way handshake is required; when the connection is closed, four handshakes are required. Next, I will focus on explaining the process of TCP's three-way handshake and four-way handshake.

  1. Three-way Handshake:

    a. Step 1: The client sends a SYN (synchronization) message to the server, which contains an initial sequence number (seq) . This SYN message is equivalent to the signal that the client initiates a connection request, indicating that the client wants to establish a connection with the server.

    b. Step 2: After receiving the SYN message, the server will reply with a SYN+ACK (synchronization + confirmation) message, which contains the confirmation number (ack) and the server's initial sequence number (seq).

    c. Step 3: After receiving the SYN+ACK message from the server, the client will send an ACK (confirmation) message, which contains the confirmation number (ack), indicating that the connection has been established.

    In this way, through the three-way handshake, both the client and the server confirm each other's sending and receiving capability and initial serial number, and a two-way reliable connection is established.

  2. Four-way Handshake: a. Step 1: When the client wants to close the connection, it will send a FIN (end) message to the server. b. Step 2: After receiving the FIN message, the server will send an ACK message as confirmation. c. Step 3: The server sends a FIN message to the client, indicating that the server also closes the connection. d. Step 4: After receiving the FIN message from the server, the client sends an ACK message as confirmation.

    In this way, by waving four times, both parties confirm the closing intention of the other party and complete the closing process of the connection.

During the three-way handshake and four-way handshake, each step requires both parties to send and receive confirmation information to ensure the reliability and sequence of the connection. The exchange of messages and confirmation numbers in these processes is to ensure that both parties can correctly understand each other's status and intentions, so as to ensure that the establishment and closure of the connection is reliable. (The two pictures below are very important, and the state inside is also important)

[External link picture transfer failed, the source site may have an anti-theft link mechanism, it is recommended to save the picture and upload it directly (img-Z1iG7e2e-1690270230621) (C:\Users\93701\AppData\Roaming\Typora\typora-user-images\ image-20230723112552073.png)]

The lowercase ack is the sequence number, and the uppercase ACK is the flag.

SYN=1 indicates that a Synchronous Sequence Number (SYN) flag is set to 1.

The handshake process in the figure is usually as follows:

  1. The client sends a TCP packet to the server with the SYN flag set to 1 and the ACK (acknowledgment) flag set to 0. At the same time, the client generates a random sequence number, say x.

  2. After the server receives the SYN=1 data packet, it will respond to the client with a data packet, in which both the SYN and ACK flags are set to 1. The server also generates a random sequence number, say y, and sets the confirmation number to x+1.

  3. After receiving the server's SYN=1 and ACK=1 data packets, the client sends a confirmation data packet to the server, in which the SYN flag is 0, the ACK flag is 1, and the confirmation number is set to y+1. The sequence number should still be x+1 (in the second handshake, the server's confirmation number is x+1, indicating that the sequence number of the next byte it expects to receive is x+1)


[External link picture transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the picture and upload it directly (img-baVz2K76-1690270230621) (C:\Users\93701\AppData\Roaming\Typora\typora-user-images\ image-20230723121127429.png)]

Four hand waving refers to the process in which the communication between the two parties ends when the TCP connection is closed. The following is the four-wave process and the changes in related fields:

  1. First wave:
    • The active closing party (Client) sends a message segment with the FIN flag set to 1 to the passive closing party (Server). FIN=1
    • The sequence number in the message segment indicates the sequence number of the last byte sent by the active closing party. seq=u
  2. Second wave:
    • After receiving the message segment of the first hand wave, the passive closing party sends a message segment with the ACK flag bit set to 1 to the active closing party, indicating that the closing request has been received. ACK=1
    • The acknowledgment number in the message segment indicates the sequence number of the next byte that the passive closing party expects to receive. ack=u+1,seq=v
  3. Third wave:
    • The passive closing party sends a message segment with the FIN flag set to 1 to the active closing party, indicating that it is also ready to close the connection. FIN=1,ACK=1 ack=u+1
    • The sequence number in the message segment indicates the sequence number of the last byte sent by the passive closing party. seq=w ( the reason why it is different from the second seq=v is because the server may have been sending data, but the client side stopped sending data )
  4. Fourth wave:
    • After the active closing party receives the message segment waving for the third time, it sends a message segment with the ACK flag set to 1 to the passive closing party, indicating that the closing request has been received. ACK=1
    • The acknowledgment number in the segment indicates the sequence number of the next byte that the active close party expects to receive. ack=w+1,seq=u+1

Talk about the state transition process of TCP's three-way handshake and four-way wave (what are the states)

Three-way handshake process: (For details, please refer to the figure below)

[External link image transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the image and upload it directly (img-uMoc55wm-1690270230622) (C:\Users\93701\AppData\Roaming\Typora\typora-user-images\ image-20230723112552073.png)]

  1. Initial state: the client end is in the CLOSED state, and the server end is in the LISTEN state.

  2. First handshake: Client sends a message segment with the SYN flag set to 1 to the Server, and selects an initial sequence number (ISN) at the same time.

    • The client state changes to SYN_SENT, waiting for the server's confirmation.
  3. The second handshake: After receiving the SYN message segment from the Client, the Server sends a message segment with the ACK flag bit of 1 to the Client, and also sends a message segment with the SYN flag bit of 1 to the Client to confirm receipt of the Client SYN, and choose an initial sequence number of your own.

    • The server status changes to SYN_RCVD.
  4. The third handshake: After receiving the SYN/ACK segment from the Server, the Client sends a segment with the ACK flag set to 1 to the Server to confirm receipt of the SYN/ACK from the Server.

    • Client status changes to ESTABLISHED.
  5. After receiving the ACK segment from the Client, the Server also enters the ESTABLISHED state.

    • The server status changes to ESTABLISHED.

The process of waving four times: (For details, please refer to the figure below)

[External link picture transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the picture and upload it directly (img-CaRvbyiU-1690270230622) (C:\Users\93701\AppData\Roaming\Typora\typora-user-images\ image-20230723121127429.png)]

  1. Initial state: Both Client and Server are in ESTABLISHED state.
  2. First wave: Client sends a message segment with the FIN flag set to 1 to the Server, indicating that it has no data to send, but it can still receive data.
    • The client state changes to FIN_WAIT_1.
  3. The second wave: After receiving the FIN segment from the Client, the Server sends a segment with the ACK flag set to 1 to the Client to confirm receipt of the FIN from the Client.
    • The server status changes to CLOSE_WAIT, and the client status changes to FIN_WAIT_2.
  4. The third wave: the server sends a message segment with the FIN flag set to 1 to the client, indicating that it has no data to send.
    • The server status changes to LAST_ACK.
  5. Fourth waving: After receiving the FIN segment from the Server, the Client sends a segment with the ACK flag set to 1 to the Server to confirm receipt of the FIN from the Server.
    • The client state changes to TIME_WAIT, and enters the CLOSED state after waiting for twice the longest segment life (MSL).
  6. After receiving the ACK segment from the client, the server also enters the CLOSED state.
    • The server status changes to CLOSED.

When it comes to the state of the TCP connection, there are some common states:

  1. CLOSED: The initial state or the state in which the connection has been closed. In this state, the TCP connection has not been established or has been closed.
  2. LISTEN (listening): The server is waiting for the state of the client to connect. In this state, the server is listening on the specified port and is ready to accept connection requests from clients.
  3. SYN_SENT (synchronously sent): The client waits for the server's confirmation after sending the SYN segment. In this state, the client has sent a connection request and is waiting for a response from the server.
  4. SYN_RECEIVED (synchronously received): The status of the server sending its own SYN message segment after receiving the client's SYN message segment. In this state, the server has received the client's connection request and sent its own connection confirmation.
  5. ESTABLISHED (established): The connection has been established, and both parties can perform data transmission. In this state, the connection between the client and the server has been successfully established, and data transmission can be performed.
  6. FIN_WAIT_1 (termination wait 1): The client waits for the server's confirmation after sending the FIN segment. In this state, the client has sent a connection termination request and is waiting for an acknowledgment from the server.
  7. CLOSE_WAIT (close wait): The server waits to close the connection after receiving the FIN segment from the client. In this state, the server has received the client's connection termination request and is waiting to close the connection.
  8. FIN_WAIT_2 (termination wait 2): The client waits for the server to send a FIN segment. In this state, the client has received the connection termination request from the server, and is waiting for the server to send its own connection termination request.
  9. LAST_ACK (final confirmation): The server waits for the client's confirmation after sending the FIN segment. In this state, the server has sent a connection termination request and is waiting for an acknowledgment from the client.
  10. TIME_WAIT (time wait): The connection has been closed, and it enters the CLOSED state after waiting for a period of time. In this state, the client waits for a period of time to ensure that all segments have been received before entering the CLOSED state.

What is MSL? TIME_WAIT Why wait for 2MSL time here?

MSL (Maximum Segment Lifetime) refers to the longest segment lifetime in the TCP protocol. It represents the maximum survival time of a TCP segment in the network.

In the TCP protocol, each message segment is divided into multiple smaller data packets for transmission. These data packets are passed through various network devices and links in the network. Due to factors such as delay, congestion, and router failure in the network, the transmission of message segments may encounter some problems, such as loss, repetition, or out-of-sequence. In order to ensure that the message segment can be normally transmitted and received correctly in the network, the TCP protocol stipulates a concept of the longest message segment life (MSL). MSL indicates the maximum lifetime of a packet in the network. After this time, the packet will be discarded. The specific value of MSL is determined according to the characteristics and configuration of the network, usually between a few minutes and tens of minutes. The waiting time of 2MSL in the TCP protocol is to ensure that all delayed segments are discarded during this period and to avoid interference with subsequent connections.

Why wait for 2MSL time?

There are several reasons for choosing to wait 2 times the MSL:

  1. Ensure that all delayed segments in the network are discarded: Waiting for 2 times the MSL can be more conservative in ensuring that all delayed segments in the network have disappeared. This avoids any possible confusion and errors. (The old connection request segment will not appear in the next new connection)
  2. Avoid confusion between new connections and old connections: If you only wait for 1 times the MSL time, there may still be some delayed segments in the network during this time. If it restarts and establishes a new connection with the same IP address and port number during this period, these delayed segments may be wrongly assigned to the new connection, resulting in data confusion and errors. Waiting for 2 times the MSL ensures that all segments of the old connection are discarded before the new connection is established.
  3. Compatible with different devices and implementations in the network: Different network devices and TCP implementations may have different processing methods for the survival time of the message segment. Some devices may drop segments sooner, while others may retain segments longer. The time to wait for 2x the MSL better accommodates differences between devices and implementations, ensuring reliable and correct connections.
  4. Unreliable network situation : If the host closes the connection immediately after waiting for 1 times the MSL, then during this period, if the retransmission data on the server side is delayed or lost in the network , the host will not be able to receive the retransmission data ( FIN+ACK segment), which may lead to data loss or error. Waiting for 2 times the MSL can provide a longer receiving window to ensure that the host can receive the timeout retransmission data from the server . This can increase the reliability of the connection and avoid data loss or error.

What does it mean that each byte of the byte stream established by TCP must be numbered in sequence? (The role of the serial number) (The method of keeping the byte stream in order)

The TCP protocol uses serial numbers to number byte streams to ensure the orderly transmission and reliability of data.

After the TCP connection is established, the sender divides the data to be sent into multiple data segments (the data segment is the TCP segment), and assigns a sequence number to each data segment. The sequence number is a 32-bit integer used to identify the position of the data segment in the byte stream. Each data segment has a starting sequence number, which indicates the position of the first byte in the data segment in the entire byte stream. Subsequent data segments increment sequence numbers in turn.

for example:

Suppose the sender wants to send a data stream containing 100 bytes.

The sender divides the data stream into data segments, which are numbered sequentially. Suppose the size of each data segment is 10 bytes, then there will be 10 data segments.

The starting sequence number of the first data segment is 1, indicating the position of the first byte in the entire byte stream. The starting sequence number of the second data segment is 11, the starting sequence number of the third data segment is 21, and so on.

When the sender sends data, each data segment will have a sequence number. The receiver confirms the received data segment according to the sequence number, and notifies the sender of the sequence number of the next expected received data segment.

Assuming that the receiver has successfully received the data segment with the sequence number 1 and the data segment with the sequence number 11, the receiver will send an acknowledgment message with the confirmation number 21 to the sender, indicating the next data segment expected to be received. The starting sequence number is 21.

If the sender finds that the data segment with the sequence number 21 is lost when sending the data segment, it will retransmit according to the received confirmation number to ensure reliable data transmission.

What is the confirmation number in TCP? what's the effect?

The confirmation number serves two purposes:

  1. Indicates a data segment that has been successfully received: the acknowledgment number indicates the sequence number of the last byte of a data segment that has been successfully received by the receiver. Through the confirmation number, the sender can know which data has been correctly received by the receiver. (For example, if the confirmation number is N, it means that all the data up to N-1 have been received correctly)
  2. Indicates the sequence number of the next data segment expected to be received: the value of the acknowledgment number is usually the sequence number of the last byte of the received data segment plus 1 . After receiving the confirmation message, the sender can determine the sequence number of the next data segment to be sent according to the confirmation number. ( The initial serial number of the data segment sent by the sender is 1001, and the length is 200 bytes. The receiver successfully receives the data segment and hopes to receive the next data segment with the serial number 1201. In this case, the receiver sends the data segment to the sender The ACK packet sent should contain an acknowledgment number of 1201. )

What does the header of a TCP segment contain?

[External link image transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the image and upload it directly (img-uopPAgt4-1690270230622) (C:\Users\93701\AppData\Roaming\Typora\typora-user-images\ image-20230723114411399.png)]

The header of a TCP segment contains the following fields:

  1. Source Port Number (Source Port): 16-bit field, indicating the port number of the sender.
  2. Destination Port (Destination Port): 16-bit field, indicating the port number of the receiver.
  3. Sequence Number: A 32-bit field used to number the bytes sent to ensure the orderly transmission of data.
  4. Acknowledgment Number: 32-bit field, only valid when the ACK flag is 1, indicating the sequence number of the next byte expected to be received.
  5. Data Offset (Data Offset): 4-bit field, indicating the length of the TCP header, in units of 4 bytes. The maximum value is 15, so the maximum length of the TCP header is 60 bytes.
  6. Reserved: 6-bit field, reserved for future use, currently set to 0.
  7. Control bit (Flags): There are 6 flag bits in total, namely: URG (urgent pointer valid bit), ACK (acknowledgment number valid bit), PSH (the receiver should hand over the data to the application layer as soon as possible), RST (reset connection bit), SYN (synchronization sequence number bit) and FIN (end connection bit).
  8. Window Size (Window Size): 16-bit field, indicating the receiving window size of the sender, used for flow control.
  9. Checksum (Checksum): 16-bit field, used to detect whether there is an error in the TCP header and data.
  10. Urgent Pointer (Urgent Pointer): 16-bit field, only valid when the URG flag is 1, indicating the byte offset of urgent data.
  11. Options (Options): A variable-length field used to extend TCP functions, such as selection confirmation, timestamp, etc.
  12. Padding: used to ensure that the length of the TCP header is a multiple of 4 bytes.

Talk about the FIN flag ACK flag SYN flag

FIN (Finish) flag: used to indicate that the sender has finished sending data and requests to close the connection. When one party of a TCP connection sends a segment with the FIN flag set to 1, it means that the party no longer sends data, but can still receive data.

ACK (Acknowledgment) flag: used to indicate that the acknowledgment number (acknowledgment number) field in the message segment is valid. When the ACK flag is set to 1, the acknowledgment number field is considered valid. During the establishment and closing of the TCP connection, the ACK flag is used to confirm the reception of the message segment sent by the other party.

SYN (Synchronize) flag: Used for synchronization during the establishment of a TCP connection. When one party of a TCP connection sends a message segment with the SYN flag set to 1, it means that the party requests to establish a connection and specifies the initial sequence number (sequence number).

The size of the flag bit is one bit (bit), that is, only one binary bit is occupied

What is SACK?

SACK refers to Selective Acknowledgment (selective acknowledgment), which is an optional extension for the TCP protocol. SACK allows the receiver to report missing data segments to the sender, thereby improving the reliability and performance of TCP.

In the traditional TCP protocol, when the receiver receives out-of-order data segments, it can only send a cumulative acknowledgment to the sender, telling the sender which data segment it has received, and expecting the sender to retransmit the data segment all data after that. There is a problem with this method, that is, if multiple data segments are lost, the sender needs to retransmit the entire lost window, resulting in a waste of network resources and an increase in delay.

SACK solves this problem by introducing a selective confirmation mechanism. The receiver can report to the sender the specific range of missing data segments, not just the last received data segment. This way, the sender can retransmit only the missing data segments without retransmitting the entire window.

SACK works as follows:

  1. After receiving the out-of-order data segment, the receiver will record the range of the lost data segment.
  2. The receiver includes the SACK option in the acknowledgment message, indicating the range of data segments lost by the sender.
  3. After receiving the SACK option, the sender can selectively retransmit according to the range of lost data segments.

By using SACK, TCP can handle lost data segments more efficiently, reduce unnecessary retransmissions, and improve the throughput and performance of the network. SACK is an optional TCP extension that needs to be supported by both the sender and receiver to take effect.

What is TCP keepalive?

Keepalive is a network protocol or mechanism for detecting and maintaining the liveness of network connections. It confirms whether the other party is still active by periodically sending small probe packets, so as to avoid the connection being closed due to no data transmission for a long time. (That is to say, the server can use this to determine whether the client is disconnected and connected)

In the TCP protocol, Keepalive is implemented by periodically sending Keepalive detection packets on idle connections. When the TCP connection is idle, that is, when there is no data transmission, the Keepalive mechanism will periodically send detection packets to the other party. If the other party does not respond within a certain period of time, the connection will be considered invalid and the connection will be closed. This can avoid long-term invalid connection due to network failure or abnormal exit of the other party.

The use of keepalives can improve the reliability and stability of network connections. It can be used to detect the availability of the connection, prevent the connection from being closed due to too long idle time, and detect network failure or abnormal exit of the other party.

It should be noted that the Keepalive mechanism needs to be configured and enabled in the operating system or application. Different operating systems and applications may have different keepalive parameters and default settings, which can be configured and adjusted according to specific needs.

What does the heartbeat mechanism mean?

Heartbeat (heartbeat) is a mechanism for keeping alive connections, similar to keepalive. It confirms the liveness of communicating parties by periodically sending small probe messages.

Heartbeat is usually implemented at the application layer to detect and maintain connections between applications. It can be a mechanism to periodically send messages or signals to ensure that the communicating parties are still alive. Usually, an application periodically sends a heartbeat message to another application. If no heartbeat message is received within a period of time, it will be considered that the connection has been disconnected or the other party is no longer active.

The Heartbeat mechanism is very common in distributed systems and is used to monitor and manage the connection status between nodes. It can be used to detect node failures or abnormalities, and take corresponding measures, such as reassigning tasks, reconnecting, etc. Heartbeat can also be used to coordinate various nodes in a distributed system to ensure synchronization and consistency between nodes.

The frequency and specific implementation of Heartbeat can be configured and adjusted according to the needs of the application. Usually, the frequency of the heartbeat message should be determined according to the network delay, connection stability and real-time requirements of the application. A lower heartbeat frequency can reduce network bandwidth usage, but may cause delays in connection status detection. A higher heartbeat frequency can detect connection state changes faster, but will increase the consumption of network bandwidth.

What are TCP's delayed ACK and cumulative acknowledgment? what scene to use

Delayed ACK (Delayed ACK) and Cumulative Acknowledgment (Cumulative Acknowledgment) are concepts related to data acknowledgment in the TCP protocol.

Delayed ACK means that the TCP receiver does not send an acknowledgment (ACK) message immediately after receiving the data, but waits for a period of time, hoping to send an ACK at one time to confirm multiple data packets. This reduces the number of ACK messages, thus saving network bandwidth. The default time to delay ACK is usually 200 milliseconds.

Cumulative acknowledgment means that when the TCP receiver sends an ACK message, it confirms a series of data packets received continuously, rather than confirming each data packet one by one. For example, if the receiver has received packets 1, 2, 3, 4, it can just send an ACK message to acknowledge receipt of these four packets. This can reduce the number of ACK messages and improve the efficiency of network transmission.

The use of delayed ACK and cumulative acknowledgment can effectively reduce the number of ACK messages in the network, thereby reducing network delay and bandwidth consumption. However, delayed ACKs and cumulative acknowledgments may also cause a certain delay, because the receiver needs to wait for a certain period of time or a certain number of packets before sending the acknowledgment message. In some specific application scenarios, such as real-time communication or high-speed data transmission, it may be necessary to adjust the parameters of delayed ACK and cumulative acknowledgment to balance delay and bandwidth requirements.

It should be noted that delayed ACK and cumulative acknowledgment are an optimization mechanism in the TCP protocol and are not required to be used. Whether to use delayed ACK and cumulative response, as well as parameter settings, depends on the specific network environment and application requirements.

What is the TCP data sticky packet problem?

The TCP data sticking problem refers to the phenomenon that when using the TCP protocol for data transmission, the data sent by the sender is glued together by the receiver, resulting in the phenomenon that the receiver cannot correctly parse and process the data.

TCP is a connection-oriented reliable transmission protocol, which divides data into individual data packets for transmission. However, due to the uncertainty of network transmission, the receiver may not be able to receive according to the boundary of the data packet sent by the sender, resulting in multiple data packets being glued together to form a larger data block, which is the TCP data sticky packet problem .

There are many reasons why TCP data sticky packets can occur, including network delay, congestion, bandwidth limitation, etc. When the receiver receives the data blocks glued together, it needs to be processed to correctly parse out the boundary and content of each data packet.

Is there a solution to the TCP data sticky packet problem?

In order to solve the problem of TCP data sticky packets, the following methods can usually be adopted:

  1. Message fixed length: the sender fixes the length of each data packet, and the receiver splits it according to the fixed length.
  2. Special character separation: The sender adds special characters between data packets as separators, and the receiver splits them according to the special characters.
  3. Message header identification: The sender adds identification information to the header of each data packet, including the length of the data packet, and the receiver splits it according to the identification information.
  4. Use message boundaries: The sender adds a message boundary identifier at the end of each data packet, and the receiver splits it according to the message boundaries.

According to specific application scenarios and requirements, it is very important to choose a suitable solution to deal with the problem of TCP data sticking.

Talk about the Http protocol

HTTP (Hypertext Transfer Protocol) is a protocol for transferring data between web browsers and web servers. It is a stateless, application-layer protocol based on a client-server model.

Following are some key features of the HTTP protocol:

  1. Stateless : HTTP is stateless, which means that the server does not remember previous requests. Each request is independent, and the server does not keep state information about the client. In order to deal with the state, you can use the session (Session) or use the cookie to track the state of the client.
  2. Request-response model : HTTP is based on a request-response model. The client sends an HTTP request to the server, the server processes the request and returns an HTTP response to the client. Both requests and responses consist of a start line, header fields and an optional message body.
  3. URL (Uniform Resource Locator) : HTTP uses URLs to specify resources to be accessed. A URL consists of a protocol type (for example http://), hostname, port number, path, and optional query parameters.
  4. Request methods : HTTP defines several request methods, the most common being GET and POST. The GET method is used to request resources, while the POST method is used to submit data to the server. Other common request methods include PUT (update resource), DELETE (delete resource), etc.
  5. Status code : The HTTP response contains a status code, which is used to indicate the processing result of the request. Common status codes include 200 (success), 404 (not found), 500 (internal server error), etc.
  6. Header fields : HTTP requests and responses contain some header fields that are used to convey additional information about the request or response. For example, Content-Typeheader fields are used to specify the content type of the response, and User-Agentheader fields are used to identify the client sending the request.
  7. Persistent connection : HTTP/1.1 introduces a persistent connection (Keep-Alive), which allows multiple HTTP requests and responses to be sent on a single TCP connection to reduce the overhead of connection establishment and closure.

The HTTP protocol is the basis of web application communication, which defines the communication rules between the client and the server. Through HTTP, the client can request resources from the server, and the server can return the resources to the client. This simple and flexible protocol made possible the development of the Web and the popularization of the Internet.

What are the request methods of the Http protocol?

The HTTP protocol defines a variety of request methods, each with a different purpose and semantics. The following are common request methods in the HTTP protocol:

  1. GET : Used to request data for a specified resource. GET requests are idempotent, that is, sending the same GET request multiple times should return the same result.
  2. POST : Used to submit data to the server, usually to create new resources or submit form data. POST requests are not idempotent, that is, sending the same POST request multiple times may result in different results.
  3. PUT : Used to upload or update the content of the specified resource to the server. PUT requests are typically used to update an existing resource, or to create a new resource if the resource does not exist.
  4. DELETE : Used to delete the specified resource.
  5. HEAD : Similar to a GET request, but only returns the response header, not the response body. It is mainly used to obtain the metadata of the resource, such as the size and type of the resource.
  6. OPTIONS : Used to obtain information such as request methods supported by the server, response header fields, etc.
  7. PATCH : Used to make partial updates to resources. Unlike PUT requests, PATCH requests only need to pass the part of the data that needs to be updated, not the entire resource.
  8. TRACE : Used to echo request information on the request-response link, mainly for testing or diagnosis.

In addition to the common request methods mentioned above, the HTTP protocol also allows the extension of custom request methods. But in practical applications, the commonly used request methods are GET, POST, PUT, and DELETE.

The most used are get and post

What are the common status codes of the Http protocol?

The HTTP protocol defines a set of status codes to indicate the processing result of the request. Each status code has a specific meaning and is used to indicate conditions such as request success, redirection, client error, or server error. The following are common status codes in the HTTP protocol:

  1. 1xx (informational status codes) : Indicates that the request has been received, is being processed, or requires further action.

    • 100 Continue: The server has received the initial part of the request, and the client should continue sending the remainder.
    • 101 Switching Protocols: The server has understood the request and will switch to a new protocol.
  2. 2xx (success status code) : Indicates that the request was successfully processed.

    • 200 OK: The request is successful and the requested data is returned.
    • 201 Created: The request was successfully processed and a new resource was created.
    • 204 No Content: The request was successful, but the response contained no content.
  3. 3xx (redirection status code) : Indicates that further action is required to complete the request.

    • 301 Moved Permanently: The requested resource has been permanently moved to a new location.
    • 302 Found: The requested resource was temporarily moved to a new location.
    • 304 Not Modified: The requested resource has not been modified, and the cached version can be used.
  4. 4xx (client error status code) : Indicates that the request contains errors or cannot be completed.

    • 400 Bad Request: The request was invalid and could not be understood by the server.
    • 401 Unauthorized: The request requires authentication.
    • 403 Forbidden: The server denies the request to access the resource.
    • 404 Not Found: The requested resource does not exist.
  5. 5xx (Server Error Status Code) : Indicates that an error occurred while the server was processing the request.

    • 500 Internal Server Error: The server encountered an unexpected error.

    • 502 Bad Gateway: The server, acting as a gateway or proxy, received an invalid response from an upstream server.

    • 503 Service Unavailable: The server is currently unable to process the request, possibly due to overload or maintenance.

Talk about the process of the Get request method

When a client sends a GET request, the following is the general process:

  1. Client builds a GET request: The client creates an HTTP request, including the request line, request header, and optional request body. The request line contains the request method (GET), the requested URL, and the protocol version.
  2. The client sends a GET request: the client sends the constructed GET request to the target server. The request contains the URL of the resource to be obtained and other related information.
  3. The server receives the GET request: After the target server receives the GET request, it starts processing the request.
  4. The server processes the GET request: the server finds and obtains the corresponding resource according to the URL and other information in the request. Typically, a server fetches the content of a resource from a file system, database, or other data source.
  5. The server generates a response: The server generates an HTTP response based on the obtained resource content. A response consists of a response line, response headers, and a response body. The response line contains the protocol version, status code and status message.
  6. Server sends response: The server sends the generated HTTP response back to the client.
  7. Client Receives Response: The client receives the response sent by the server.
  8. Client processing response: The client processes the response content according to the status code and other relevant information in the response. The processing method can be displaying the response content, parsing the response header, performing other operations, etc.
  9. The client displays the response result: the client displays the response result to the user, such as displaying the webpage content in the browser.

Talk about the components of the Get request message and the components of the response message

When a client sends a GET request, the request message consists of the following components:

  1. Request line : contains request method, requested URL and protocol version.
    • For example: GET /api/users HTTP/1.1
  2. Request header : Contains additional information about the request, expressed in the form of key-value pairs.
    • For example:
      • Host: example.com
      • User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
      • Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8
  3. Empty line : used to separate request header and request body.
  4. Request body : GET requests usually do not have a request body, because it is mainly used to obtain resources, not to send data.

Here is a complete example of a sample GET request message:

GET /api/users?name=John&age=25 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: application/json
Authorization: Bearer abc123

The meaning of each line is as follows:

  1. GET /api/users?name=John&age=25 HTTP/1.1: Request line, including HTTP method (GET), request path (/api/users), query parameters (name=John&age=25), and HTTP protocol version (HTTP/1.1).

  2. Host: example.com: The request header field specifies the target host (example.com) of the request.

  3. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36: The request header field, which contains the information of the user agent (browser) that sent the request.

  4. Accept: application/json: The request header field specifies the response content type (application/json) that the client can accept.

  5. Authorization: Bearer abc123: Request header field for authentication, where Bearer is the authentication scheme and abc123 is the authentication token.

  6. A blank line indicates the end of the request headers, followed by no request body.


A response message consists of three main parts: the response line, response headers, and response body.

  1. Response line: The response line contains the HTTP protocol version number, status code, and status message. Its format is usually HTTP/1.1 200 OK, where it HTTP/1.1indicates the protocol version, 200indicates the status code, and OKindicates the status message.
  2. Response header: The response header contains meta information related to the response. It contains a series of key-value pairs, each key-value pair consists of a field name and a field value. Common response header fields include Content-Type(specify the content type of the response body), Content-Length(specify the length of the response body), Date(specify the date and time of the response), etc.
  3. Response body: The response body contains the actual data returned by the server. It can be data in various formats such as HTML, JSON, XML, etc., depending on the processing logic of the server and the needs of the client.

The following is an example of a corresponding response message, including the components of the response line, response headers, and response body:

HTTP/1.1 200 OK

Content-Type: application/json

Content-Length: 120

Date: Mon, 25 Jul 2023 06:46:32 GMT

{

“id”: 1,

“name”: “John”,

“age”: 25,

“email”: “[email protected]

}

Parsed as follows:

  1. HTTP/1.1 200 OK: Response line, indicating that the server successfully processed the request and returned a 200 status code (OK).
  2. Content-Type: application/json: The response header field, specifying that the content type of the response body is application/json.
  3. Content-Length: 120: Response header field, specifying that the length of the response body is 120 bytes.
  4. Date: Mon, 25 Jul 2023 06:46:32 GMT: The response header field specifies the date and time of the response.
  5. Empty line: indicates the end of the response header.
  6. Response body: contains the data returned by the server, here is an object in JSON format, including attributes such as id, name, age, and email.

What are the Content-Types?

Content-Type is one of the HTTP header fields used to indicate the media type of the sent or received entity body. The following are some common Content-Type types:

  1. text/plain: plain text type.
  2. text/html: HTML document type.
  3. text/css: CSS style sheet type.
  4. application/json: JSON data type.
  5. application/xml: XML data type.
  6. application/pdf: PDF document type.
  7. image/jpeg: JPEG image type.
  8. image/png: PNG image type.
  9. audio/mpeg: MPEG audio type.
  10. video/mp4: MP4 video type.

In addition to the above types, there are many other Content-Type types used to represent different media types and data formats. The appropriate Content-Type type can be selected according to actual needs.

Talk about the process of the Post request method

When using the POST request method, the request sent by the client to the server will contain a request body, which contains the data to be transmitted to the server. The following is the general process of the POST request method:

  1. The client establishes a connection with the server: the client establishes a connection with the server by establishing a TCP connection or using other protocols.
  2. Build request message: The client builds an HTTP request message, which includes request line, request header and request body. The request method is POST and the URL of the request target is specified in the request line. The request header can contain some additional information, such as Content-Type, Content-Length, etc. The request body contains the data to be transmitted to the server.
  3. Send request message: The client sends the constructed request message to the server. The request message will be transmitted to the server side through the network.
  4. The server receives the request message: the server receives the request message sent by the client.
  5. Processing request: The server performs corresponding processing according to the received request message. This may involve authenticating the user, processing request data, executing appropriate business logic, etc.
  6. Return Response: The server generates an HTTP response message, which includes the response line, response headers, and response body. The response line specifies the HTTP protocol version number, status code, and status message. Response headers contain meta information related to the response. The response body contains the data returned by the server.
  7. Receive response: The client receives the response message returned by the server.
  8. Processing response: The client performs corresponding processing according to the received response message. This may include parsing data in the response body, processing meta information in response headers, error handling based on status codes, etc.

The POST request method is suitable for scenarios where data needs to be submitted to the server, such as submitting form data, uploading files, and so on. Compared with the GET request method, the POST request method is more suitable for transmitting large amounts of data or sensitive data, because the POST request includes the data in the request body instead of being visible in the URL.

Talk about the components of the Post request message and the components of the response message

When sending a message using a POST request, the message usually consists of a request line, request headers, and a request body. Here is an example of a POST request showing the components of the message:

POST /api/login HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 43

{
  "username": "exampleuser",
  "password": "secretpassword"
}
  • Request line: The request line of the POST request specifies that the request method is POST, the request target is /api/login, and the HTTP protocol version used is HTTP/1.1.
  • Request Header: The request header contains some additional information. In this example, Hostthe header specifies the hostname of the server, Content-Typethe header specifies that the data type of the request body is JSON, and Content-Lengththe header specifies that the length of the request body is 43 bytes.
  • Request body: The request body contains the data to be transmitted to the server. In this example, the request body is a JSON object containing username and password.

Please note that this is just an example, and the actual POST request message can be customized according to specific needs and scenarios.

When a message is sent using a POST request, the server returns a response message. The following is an example of a response message:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 26

{
  "message": "Login successful"
}
  • Response line: The response line specifies the HTTP protocol version and status code. In this example, the status code in the response line is 200, indicating that the request was successful.

  • Response header: The response header contains some additional information. In this example, Content-Typethe header specifies that the data type of the response body is JSON, and Content-Lengththe header specifies that the length of the response body is 26 bytes.

  • Response body: The response body contains the data returned by the server. In this example, the response body is a JSON object containing a messagefield named Login successful.

What is the difference between GET and POST request methods?

GET and POST are two common request methods in the HTTP protocol. They have some differences in usage and characteristics:

  1. Where the data is transferred: GET requests append the data in the query parameters of the URL, while POST requests include the data in the request body.
  2. Data length limit: Since the GET request appends data in the URL, the data length is limited by the URL length limit. The POST request contains the data in the request body, there is no clear length limit, and a large amount of data can be transmitted.
  3. Data security: The data of the GET request will be displayed in the URL, so it is not suitable to use the GET request for sensitive information, because the URL may be saved in the browser history, server logs, etc. POST requests include data in the request body and will not be exposed in the URL, which is relatively safer.
  4. Data caching: GET requests can be cached by the browser, so for the same request, the browser may get the response directly from the cache without sending the request to the server. POST requests will not be cached and will be sent to the server every time.
  5. Idempotency: GET requests are idempotent, that is, multiple identical GET requests will not have side effects on the server. The POST request is not idempotent, and multiple identical POST requests may produce different results to the server.
  6. Usage scenario: GET requests are suitable for operations such as obtaining resources and querying data, while POST requests are suitable for operations such as submitting data and modifying data.

To sum up, GET requests are suitable for obtaining data, for operations without side effects, and for scenarios that do not require high data security. POST requests are suitable for submitting data, for operations with side effects, and for scenarios with high data security requirements.

What is a URL and what are its components?

A URL (Uniform Resource Locator) is a string of characters used to identify and locate a resource on the Internet. A URL usually consists of the following components:

  1. Protocol (Protocol): The first part of the URL is the protocol, which specifies the protocol used for communication between the client and the server, such as HTTP, HTTPS, FTP, etc. Agreements usually ://end with .

  2. Domain name (Domain): The domain name is the main part of the URL, which specifies the name or IP address of the server to be accessed. A domain name can be a full hostname (such as www.example.com) or an IP address (such as 192.168.0.1).

  3. Port: Port is optional and specifies the specific port number on the server that is listening. If no port is specified, the default port number is used. The default port number of the common HTTP protocol is 80, and the default port number of HTTPS is 443.

  4. Path (Path): The path specifies the specific location of the resource on the server. It /starts with a slash and can contain multiple path segments, separated by slashes. For example, it means accessing resources under a directory /products/123on the server .products123

  5. Query Parameters (Query Parameters): Query parameters are used to pass additional data to the server. They start with a question ?mark and multiple parameters are &separated. Each parameter consists of a parameter name and a parameter value, which =are connected by an equal sign. For example, ?page=1&limit=10the requested page number is 1, and 10 pieces of data are displayed on each page.

  6. Anchor (Fragment): An anchor is an optional part of a URL that specifies a specific location within a page. It #starts with a pound sign followed by the anchor name. For example, it means that the page is scrolled to the element #section1whose ID is .section1

    Here's an example URL, - to better understand the components of a URL:

    https://www.example.com:8080/products/123?category=electronics&sort=price#reviews
    

    In this example, the components of the URL are as follows:

    • protocol:https://
    • domain name:www.example.com
    • port::8080
    • path:/products/123
    • Query parameters:?category=electronics&sort=price
    • anchor point:#reviews

    This URL represents a www.example.comserver located on the host machine accessed using the HTTPS protocol. The port number the server listens on is 8080. The path is , indicating that the resources under the directory /products/123on the server are to be accessed . There are two parameters in the query parameters, the value of is and the value of is . Finally, the anchor point is , indicating that the page is scrolled to the element whose ID is .products123categoryelectronicssortprice#reviewsreviews

What is the difference between the URL of the Get method and the Post method?

When using the GET method, query parameters are appended directly to the end of the URL. Here is an example URL using the GET method:

Example URL for a GET request:

https://www.example.com/api/products?id=123&category=electronics

In the example above, the query parameters id=123and category=electronicsare appended directly at the end of the URL to request product data with a specific ID and category from the server.

When using the POST method, the data will be placed in the request body instead of directly attached to the URL. Here is an example URL using the POST method:

Example URL for a POST request:

https://www.example.com/api/products

The difference between HTTP and HTTPS

HTTP (Hypertext Transfer Protocol) and HTTPS (Hypertext Transfer Protocol Secure) are protocols for transferring data between a client and a server. The main differences between them are as follows:

  1. safety:
    • HTTP: Data is in plain text during transmission and is not encrypted. Therefore, there are security risks in the HTTP protocol, for example, hackers can intercept and steal transmitted data.
    • HTTPS: Data is encrypted by SSL/TLS during transmission to ensure data security and integrity. HTTPS uses public key encryption and private key decryption to prevent data from being stolen or tampered with.
  2. port:
    • HTTP: Port number 80 is used by default.
    • HTTPS: Port number 443 is used by default.
  3. Certificate:
    • HTTP: Certificates are not required.
    • HTTPS: An SSL certificate is required to verify the identity of the server. SSL certificates are issued by a trusted third party to establish a secure connection.
  4. SEO (Search Engine Optimization):
    • HTTP: Search engines do not give special preference to ranking HTTP websites.
    • HTTPS: Search engines tend to rank websites that use HTTPS higher because HTTPS provides better security and user privacy protection.

To sum up, HTTP is an unencrypted protocol, while HTTPS provides higher security and data protection by using SSL/TLS to encrypt data transmission. It is recommended to use HTTPS when transmitting sensitive information, making online payments, or when user privacy needs to be protected.

Talk about the reasons for the emergence of NAT technology What is the technology provided by NAT

NAT (Network Address Translation, Network Address Translation) technology was created to solve the problem of insufficient IPv4 addresses. In the early development of the Internet, IPv4 address resources were limited and could not meet the connection needs of a large number of devices. NAT technology realizes the function of multiple devices sharing a public IP address by performing address translation between the private network and the public network.
NAT technology provides the following functions:

IP address translation: NAT uses private IP addresses for devices in private networks to communicate, and when communicating with public networks, NAT converts private IP addresses to public IP addresses to enable communication with public networks.

Port translation: NAT can also translate the port numbers used by devices in the private network to port numbers in the public network. In this way, even if multiple devices use the same private IP address, they can be distinguished by different port numbers, so that multiple devices can share a public IP address.

Address mapping: NAT technology can also implement the address mapping function, mapping public IP addresses to specific devices in the private network. In this way, the external network can access the devices in the private network by accessing the public IP address to realize functions such as remote access and port forwarding.

What is a dynamic IP address?

A dynamic IP address refers to a temporary IP address assigned to a device in the network. Compared with the static IP address, the dynamic IP address is temporary, and a new IP address will be obtained every time the device is connected to the network.
The allocation of dynamic IP addresses is usually managed by a DHCP (Dynamic Host Configuration Protocol, Dynamic Host Configuration Protocol) server. When a device connects to the network, it sends a DHCP request asking for an available IP address. The DHCP server will select an available IP address from an address pool to assign to the device, and send the assigned IP address and other network configuration information to the device. When a device finishes using an IP address, it releases it back to the DHCP server so that other devices can use it again.
The advantage of dynamic IP addresses is that they make more efficient use of IP address resources. Since the dynamic IP address is temporary, when the device is no longer in use, it can be released back to the address pool for use by other devices, thereby reducing the waste of IP addresses. In addition, the process of assigning dynamic IP addresses is simpler and more automated, reducing the workload of network administrators.
However, dynamic IP addresses also have some limitations. Since the IP address is temporary, the device will get a new IP address each time it connects to the network, which may cause configuration problems for some network applications or services. For devices that require remote access or require a fixed IP address, a static IP address may be more suitable.

Dynamic IP addresses can occur in both public and private networks.
In a public network, a dynamic IP address is a temporary IP address assigned to a user by an Internet Service Provider (ISP). When a user connects to the Internet, the ISP will assign it an available dynamic IP address. In this way, users can communicate with the Internet through this dynamic IP address.
In a private network, a dynamic IP address is a temporary IP address assigned to a device by the local network's DHCP server. When the device is connected to the private network, the DHCP server will assign it an available dynamic IP address. In this way, devices can communicate in the private network and exchange data with other devices.

What is the difference between port translation and port mapping?

Both port mapping and port conversion are functions used to enable public network users to access private network devices or services.
Port mapping refers to mapping a specific port of a public network IP address to a specific port of a private network device. In this way, when a public network user sends a request to the public network IP address and mapped port, the router will forward these requests to the corresponding port on the corresponding private network device.
Port translation (also known as NAT translation) is a broader concept that includes port mapping. Port translation refers to a conversion process within the private network, which converts the private network user's request from one port to another port, and forwards it to other devices in the private network. In this way, the communication between internal devices of the private network can be realized, and at the same time, the function of public network users to access private network devices can be realized.
Therefore, port mapping is a form of port translation, which is used for public network users to access private network devices or services. The port conversion may also include port forwarding between private network users , so as to realize communication between devices inside the private network.

Example of port translation:
Imagine you have a home network with three devices connected to the same router: device A, device B, and device C. Your home network uses a public IP address.
Device A is running a web server listening on port 80. Assume that both device B and device C want to access this web server on device A through the Internet.
Since your home network only has one public IP address, neither device B nor device C can access the web server on device A directly over the Internet.
At this point, you can configure port translation on the router. You can specify an external port (e.g. 8080) and map it to port 80 of device A.
Now, when device B or device C accesses the router's public IP address and mapped port (e.g. http://your_public_ip:8080) over the Internet, the router will forward these requests to the web server on device A.
In this way, device B and device C can access the web server on device A through the Internet without directly connecting to device A.
Port mapping example:
Suppose you have a home network with a camera device, and you want to be able to access this camera through the public Internet. First, you need to configure port forwarding on the router.

Find the IP address of your webcam device, such as 192.168.1.101.

Log in to your router's admin interface and find the port forwarding settings in options such as network settings or port forwarding.

Create a new port mapping rule. Enter the following information:

Public Port: Select an unoccupied public port number, such as 8080.

Internal IP address: Enter the IP address of the camera device, which is 192.168.1.101.

Internal port: Enter the port number that the camera device monitors, such as 80.

Protocol: Choose TCP or UDP, according to the requirements of the camera device.

Save and apply this port mapping rule.

Now, when you access your router's public IP address on the public Internet and specify port number 8080, the router will forward this request to the camera device's IP address 192.168.1.101 on port 80. This way, you can access your webcam device over the public internet.

What are DHCP server and gateway?

DHCP server and gateway play different roles in the network, and they have the following differences:

Function: A DHCP server is responsible for dynamically assigning IP addresses and other network configuration information to devices connected to the network. It receives the device's DHCP request and selects an available IP address from the pre-configured IP address pool to assign to the device. The gateway is the exit point in the network, which connects the communication between the local area network (LAN) and the external network (such as the Internet), and is responsible for the transmission of data packets from one network to another.

Working method: The DHCP server communicates with the device through the DHCP protocol, receives and processes the DHCP request of the device, and sends the assigned IP address and other configuration information back to the device. Its job is to automatically assign IP addresses and configuration information to devices when they join the network. The gateway transmits data packets from the source network to the target network according to the routing table and forwarding rules of the network layer.

Address assignment: The DHCP server is responsible for dynamically assigning IP addresses, providing temporary and variable IP addresses for devices connected to the network. This allows the device to automatically obtain an available IP address without manual configuration. A gateway, on the other hand, usually has a static IP address, and it is an exit point in the network , which is used to transfer data packets from one network to another.

Scope of action: The scope of action of a DHCP server is devices within a local area network (LAN), which provides IP addresses and other configuration information for devices connected to the LAN. The scope of the gateway is the entire network, which connects the LAN and the external network, and is responsible for transmitting data packets from the LAN to the external network, or from the external network to the LAN.

To summarize, a DHCP server is responsible for dynamically assigning IP addresses and other network configuration information to devices, while a gateway is an exit point in a network, responsible for transferring data packets from one network to another. They differ in function, mode of operation, address assignment and scope of action.

A DHCP server is usually placed on a router or network device. A router acts as a gateway in a private network, connecting communications between a local area network (LAN) and an external network such as the Internet.

What are the exit points in the network? Is 192.168.0.1 the exit point

An exit point in a network refers to the egress of network communication, and may also be called a default gateway or gateway. It is the switching point that connects a local area network (LAN) or private network with external networks such as the Internet.
The exit point is usually a network device such as a router or firewall. It has two or more network interfaces, one connected to the local area network and one or more connected to the external network. The egress point transmits the data in the local area network to the external network, or transmits the data in the external network to the local area network by forwarding the data packets.
192.168.0.1 is a common private IP address that is often used as the IP address of the default gateway or exit point. The default gateway means that when the device sends a data packet, if the target IP address is not in the same subnet, it will send the data packet to the default gateway, and the default gateway is responsible for forwarding the data packet to the external network.
Therefore, 192.168.0.1 can be an exit point in a network, acting as a default gateway, responsible for transmitting packets from the LAN to the external network, or from the external network to the LAN. However, it should be noted that the actual exit point IP address may be different, depending on the configuration of the network and the settings of the device.

Guess you like

Origin blog.csdn.net/weixin_46274756/article/details/131919152