The difference between HTTP2 and 1.1

What are the advantages of HTTP 2.0 over HTTP 1.1?

HTTP1.1 head-of-line blocking problem

The server must respond in the order in which the requests are received, why

Because there is no specific field in the traditional 1.1 to distinguish which request belongs to, it can only be returned in the physical order of the request.

The idea of HTTP2 to solve the head-of-line blocking problem is to define an additional frame structure field so that the sender can reorder according to the flow id after receiving the response. Responses don't have to be in physical request order, do they?

As you said, HTTP/2 solves the head-of-line blocking problem by introducing the concept of "streams". Each stream has a unique identifier (stream ID), which enables multiple requests and responses to proceed in parallel on the same TCP connection without interfering with each other. That way, if one stream's response is delayed, it doesn't block the processing of other streams.

Specifically, the "frame" structure in HTTP/2 allows multiple types of information to be exchanged on a single TCP connection. The "flow ID" field identifies which flow the frame belongs to. When the client receives responses, it can order or process the responses based on the stream ID, rather than relying on the physical order in which they were sent. This allows the server to send a response as soon as it is ready, without waiting for responses from other requests .

In summary, the design of HTTP/2 allows for higher parallelism and efficiency, avoiding the head-of-line blocking problem in HTTP/1.1.

HTTP2's idea of solving the head-of-line blocking problem is applied in other places (actually it is a multiplexing mechanism)

The idea of HTTP/2 to solve the head-of-line blocking problem is based on the concepts of multiplexing and frames, which indeed provides inspiration for other technical fields. The rationale behind this is to allow multiple independent interactions to take place in parallel on the same connection, each with its unique identifier allowing it to be properly identified and processed as it is sent and received.

This idea also has applications in the following areas:

Other protocols of computer networks : For example, in some modern transport layer protocols such as QUIC, a stream-like concept is also used, allowing multiple independent data streams to be processed in parallel on a single connection.
Database management : When dealing with multiple concurrent transactions, some databases use identifiers to distinguish and process each transaction correctly, ensuring the independence and integrity of each transaction.
Computer Operating System : In operating system multitasking, each task or process has its unique identifier that allows them to run in parallel in a system, and the operating system manages and schedules these tasks correctly.
Message Queuing and Stream Processing : When dealing with large numbers of concurrent messages, message queuing systems like Kafka use partitions or other identifiers to process messages in parallel, ensuring correct and efficient processing of messages.
Grid Computing and Parallel Computing : When dealing with distributed tasks, each task may have its unique identifier, allowing them to run in parallel on multiple nodes while the system is able to properly collect and combine the results.

This idea of breaking down a large task or request into smaller chunks that can be processed independently, and assigning each chunk a unique identifier, has applications in many areas of computer science and engineering.

Ali encountered multiplexing mechanism scenario questions during the interview (the IO multiplexing here is similar to the field of adding stream id in HTTP2.0, and the solution mentioned by the interviewer is a solution when resources are sufficient solution, similar to HTTP1.1's solution to establish multiple TCP connections)

Background: The schema instance is reversely synchronized to the schema definition table, which involves the synchronization of 6 tables, and there may be more subsequent tables

## 2.6 同步过程你是如何保证数据的一致性的

答：我这个同步的过程是六张实例表同步到对应的六张定义表中（其实它们都在一张表，只不过存在架构定义和架构实例字段以表示区别）；我当时没有保证他的一致性，但是我现在想到的一个解决方案是将其加入到消息队列中，消息队列定期消费，如果消息队列本身是raft集群部署，本身可以保证一致性的。

### 2.6.1 你整个消息队列的消息体是什么？包含哪些核心数据

答：比如说序列号，消息体中应该还包含我定义的那些模板，比如说表名，表类结构，需要同步的字段啊

### 2.6.2 你们那边应该是有节点实例id吧，如果一个节点多次发生了变更，你投放到消息队列，实际消费的时候，会不会出现乱序的问题？

答：有可能啊，那就开六个队列吧，每一个队列单线程消费

### 2.6.3 从A同步到B，比如是从淘宝的买家数据到卖家的同步，是不是不能用你的单队列单线程的模式去走？因为这样会限制消费速率，遇到这种场景，如何去设计他呢？避免乱序。

答：可以借鉴tcp的序列号机制，给每一个队列都加上两个字段，一个是表名，一个是序列号，不同表名下的序列号空间隔离，这样接收端收到消息后可以依据这个序列号空间的连续性进行重排序。

### 2.6.4 你这里有一个问题，如果发送端节点实例变化频繁，发送和接收的地方是不知道的，所以你这个方案是不太行的

针对感知变更号的优化方案：

答：我在消息体上再加一个字段，表示变更的版本，这样接收端收到发送端的消息时，会比较发送端发送的版本和自己期望的版本是否一致，一致则加入到那个版本的缓冲区中，不一致则放入到其他版本的缓冲区中，延迟到接收到期望的变更号

面试官的方案（他说我的方案是一种思路，但是比较复杂）：\
可以采用多节点方案，比如针对同一个节点的版本的变更号的消息统一经由一个消息队列节点发送，通过节点隔离实现变更号隔离。

我：你这种方案更我前面说的按照表拆分队列有什么不同呢？

面试官：你的这种方式拆分的节点数和表的数量相同，但是我说的这种相当于按照"节点+变更号"的方式拆分节点，每一个消息队列节点负责某一个节点实例id（这个实例id是逻辑id，用于解耦合）的某一个版本，拆分的粒度更细，整个的吞吐量会大很多，比如说一个同步六张表，每张表有10个变更号，按照你的方案最多拆分成6个队列，但是按照我的方案可以拆分成60个队列。

HTTP2的Multiplexing

What is HTTP2 Multiplexing, what is its function, and what is its mechanism

In HTTP/1.1, each HTTP request requires an independent TCP connection, which makes it necessary to open multiple TCP connections to send multiple requests at the same time. But in HTTP/2, multiplexing (Multiplexing) technology was introduced, allowing multiple HTTP requests to be sent and responses received simultaneously on a single TCP connection.

Pipelining and Multiplexing in HTTP

Pipelining and Multiplexing are two different technologies in the HTTP protocol, both of which aim to improve the efficiency of network transmission.

Pipelining: Introduced in HTTP/1.1, it allows a client to send multiple requests consecutively in a persistent connection without waiting for each response. However, HTTP/1.1 stipulates that the response must be returned in the order of the request, which leads to the "head of line blocking" problem, that is, if the processing of a request takes a long time, subsequent responses will also be blocked.

Multiplexing (multiplexing): Introduced in HTTP/2, it allows the client and server to process multiple requests and responses simultaneously in a persistent connection. Multiplexing works by splitting each request and response into multiple frames, which can be sent mixed within a connection and reassembled at the receiving end. Multiplexing is more efficient because there is no head-of-line blocking problem.

The multiplexing (Multiplexing) mechanism of HTTP/2 guarantees the order of requests and responses by introducing the concept of "Stream".

In HTTP/2, each request-response pair is considered an independent stream. Each stream has a unique identifier called "Stream ID". Streams can be sent in parallel because each frame is marked as belonging to a certain stream via the stream ID in the frame's header.

Here's how ordering is guaranteed:

Order of frames : Although frames from multiple streams can be mixed and sent on a connection, the order of frames within a single stream is fixed. For example, the sending order of frame 1, frame 2, and frame 3 of stream A will not be disturbed.
Stream ID : Each stream has a unique stream ID, which allows the receiver to correctly associate the frame with the corresponding request or response based on the stream ID.
Flow control : HTTP/2 also introduces a flow control mechanism that allows the receiving end to control the rate at which it receives data, which further ensures the orderly reception and processing of data.

In summary, multiplexing allows multiple requests and responses to be sent in parallel on a connection, but the order of the frames within each stream remains consistent. The receiving end reassembles each stream based on the frame's stream ID and sequence, thus ensuring correct and sequential processing of requests and responses.

Why is the browser allowed to establish multiple tcp connections with the server? Isn't there pipeline technology?

Although both the pipelining technology in HTTP/1.1 and the Multiplexing technology in HTTP/2 can process multiple HTTP requests in one TCP connection, due to the head-of-line blocking problem, the pipelining technology is not used much in practice. Therefore, HTTP/1.1 clients usually establish multiple TCP connections to the same server to process multiple HTTP requests in parallel. In HTTP/2, due to the introduction of Multiplexing technology, one TCP connection can process multiple requests in parallel, so it is generally no longer necessary to establish multiple connections.

If multiple tcp connections are allowed, how does the receiving end distinguish and reassemble multiple message segments received at the same time according to the rules?

The TCP protocol guarantees the order and integrity of the data of each connection. In the TCP protocol, each data segment has a sequence number, and the receiving end can reassemble the data according to this sequence number. Therefore, even if there are multiple TCP connections, the receiving end can correctly process the data of each connection. This is due to the fact that each TCP connection has its own sequence number space and acknowledgment mechanism, so although these connections may exist concurrently, they are completely independent.

1 Question: Each TCP connection has an independent serial number space and confirmation mechanism to ensure that the receiver can reassemble correctly even if multiple TCP connections are established. Tell me about this mechanism?

In the TCP protocol, each TCP connection is defined as a four-tuple: source IP address, source port, destination IP address, destination port. This quadruple uniquely identifies a TCP connection , which is also the guarantee of an independent serial number space. Each TCP connection has its own independent serial number space, which is guaranteed by the TCP protocol. Sequence numbers are used to identify the order of data bytes sent in a TCP connection.

When establishing a new TCP connection, both the sender and receiver exchange their Initial Sequence Numbers (ISNs) during a handshake. After that, each byte sent by the sender will have a sequence number, which is the ISN of the byte plus its offset in the sent data stream. The receiver can judge the order of the received data bytes and whether there is any data loss according to the sequence number.

In addition, TCP also uses an acknowledgment mechanism to confirm the receipt of data. When the receiver receives the data, it sends an acknowledgment (ACK), which is the sequence number of the next byte the receiver expects to receive. If the sender does not receive an acknowledgment from the receiver, it resends the data.

Therefore, through the independent sequence number space and confirmation mechanism, even if there are multiple TCP connections, the receiver can correctly receive and reassemble the data of each connection.

2 Establishing multiple TCP connections will occupy multiple ports, right?

Yes, each new TCP connection requires a new port. But it should be noted that usually, the client (that is, the party that initiates the connection) will use a new port, while the server (the party that receives the connection) will usually use a fixed, known port (such as HTTP The default port is 80 for HTTPS and 443 for HTTPS). The operating system automatically selects an unused ephemeral port for the client.

3 The TCP quadruple source IP address, source port, destination IP address, and destination port here uniquely identify the space of each TCP serial number, right?

Yes, the TCP quadruple (source IP address, source port, destination IP address, destination port) does uniquely identify a TCP connection. Sequence numbers are used internally within each TCP connection to ensure the correct order and integrity of data within the connection. This means that each TCP connection has its own independent sequence number space and will not conflict with other TCP connections. This is because each TCP connection is independent and its state (including sequence numbers) does not affect other connections.

4 So even if multiple TCP connections are established, the destination port remains unchanged, but the source port changes, which uniquely identifies the namespace?

Yes, your understanding is correct. Even if the destination port (usually the server port) of multiple TCP connections is the same, as long as the source port (usually the client port) or source IP address is different, this is enough to uniquely identify a TCP connection at the network level. That's why we can open multiple connections to the same port on the same server from the same device (same IP) at the same time (such as multiple tabs of a browser connected to the same website).

5 Under the condition that "even if multiple TCP connections are established, the destination port remains unchanged, but the source port changes, which uniquely identifies the namespace", the destination ports are all the same, so multiplexing and Divide it, right?

Yes, your understanding is correct. We call it multiplexing and demultiplexing because the same port on the server side can serve multiple connections from different clients (multiplexing, service refers to sending or responding data), and can also be based on the unique identification of each connection (source IP and source port) to correctly transfer the received data to the corresponding connection/process (demultiplexing) .

multiplexing and demultiplexing

Multiplexing: It means that at the sending end of the network, a higher layer protocol can send data to different receiving ends through the same lower layer service interface. For example, your computer (as a client) can send data to different ports of the server through the same network layer interface (that is, the same IP address and port), or to different servers. We call this process reuse.

Demultiplexing: Correspondingly, at the receiving end of the network, the lower layer protocol can distribute the received data to different service interfaces of the higher layer according to certain rules (such as target IP and port). For example, the server can distribute the received data to different applications according to the source IP and source port information of the data. We call this process splitting.

The following is the detailed address: "Computer Network" knowledge summary-3. Multiplexing and demultiplexing

Talk about the Multiplexing implementation mechanism of HTTP/2 in detail

Multiplexing implementation mechanism of HTTP/2: In HTTP/2, all communication is completed on a TCP connection, which can carry any number of bidirectional data streams. Each data stream has a unique integer ID. The request and response of the data flow are composed of HTTP frames, which can be interleaved in the TCP connection, and then reassembled according to the data flow ID at the receiving end.

More specifically, HTTP/2 defines the following types of frames: HEADERS and DATA are used for metadata and bodies of requests and responses; SETTINGS, PING, and GOAWAY are used for connection management; PUSH_PROMISE is used for server push, etc.

Since HTTP/2 frames can be interleaved in a TCP connection, it can solve the head-of-line blocking problem of HTTP/1.x and make the utilization of the connection higher.
Because the traditional pipeline technology requires the previous packets to arrive at the receiving end completely and correctly, if the sending end mixes and sends a plurality of segmented segments and combines them with other application segments out of order, and then sends them to the receiving end , after receiving the first frame, the receiving end will wait for the rest of the frame to arrive, and will unblock after receiving all of them.

Does the "frame" mentioned here refer to the frame of the data link layer?

The "frame" in HTTP/2 is a concept at the application layer, it is not a frame at the data link layer. In HTTP/2, a "frame" represents the smallest unit in HTTP/2 communication. Each frame includes a frame header and a frame body, where the frame header contains the type, flag, length, and identification of the data stream of the frame. symbol.

Is multiplexing here the same concept as I/O multiplexing at the TCP layer?

Multiplexing of HTTP/2 and I/O multiplexing of TCP layer are not the same concept. Multiplexing of HTTP/2 means that multiple requests and responses can be processed in parallel in one TCP connection. The I/O multiplexing of the TCP layer means that in the underlying operating system, a single thread can be used to monitor and operate multiple I/O streams at the same time, such as select, poll, epoll, etc.

What is the difference between Multiplexing here and Linux epoll, select and other multiplexing mechanisms?

The main difference between HTTP/2 Multiplexing and Linux epoll, select and other multiplexing mechanisms is that they work at different levels:

Multiplexing of HTTP/2 works at the application layer. It is part of the HTTP/2 protocol and is mainly used to process multiple HTTP requests and responses in parallel in one TCP connection.

epoll, select, etc. work at the operating system layer. They are interfaces provided by the operating system and are mainly used to simultaneously process multiple network connections or other I/O operations in one thread.

In addition, multiplexing mechanisms such as epoll and select are event-driven. When an I/O stream is ready (for example, there is data to read), the corresponding event will be triggered. The multiplexing of HTTP/2 is data-driven. When a new frame is sent to the TCP connection, the frame will be processed immediately.

Here HTTP Multiplexing and TCP layer I/O multiplexing should have a similar principle, right?

The core concept of multiplexing of HTTP/2 and I/O multiplexing of TCP layer is to process multiple data streams or operations through a single connection or resource, so in this sense, their principles are similar. However, as I mentioned in my previous answer, they work at different levels and with different mechanisms.

Multiplexing divides each request and response into multiple frames. These frames can be mixed and sent in one connection. It can be understood that the data frames requested by A and some data frames requested by B are mixed in one TCP segment and then sent to On the receiving side, does the application layer on the receiving side reorganize according to the way of delimiter, length, socket and other fields?

In general your understanding is correct, but the details need some tweaking. In HTTP/2, a request or response frame is not mixed in a TCP segment, but is sent as an independent frame in a TCP connection (HTTP request) . The header of each frame has a stream ID, which is used to indicate which request or response the frame belongs to. The receiver's application layer can reassemble the received frame into a complete request or response based on this stream ID. So instead of reassembly based on delimiter, length, socket, etc. fields, reassembly is done based on the stream ID of each frame.

HTTPS和HTTP

HTTPS interaction process

Approximate interaction process:

Yes, HTTPS is based on the HTTP protocol, but a security layer of SSL/TLS is added between HTTP and TCP. This security layer provides data encryption services for the HTTP protocol to protect data from being stolen or tampered with during transmission, as well as server authentication to protect users from being directed to fake servers.

In actual use, the workflow of the HTTPS protocol can be roughly divided into two steps:

Handshake phase: An SSL/TLS session is established between the client and server. During this process, server authentication will be performed (through the server's SSL/TLS certificate), and the two parties will also negotiate a set of encryption parameters (such as which encryption algorithm to use, what the key is, etc.). Once this session is established, encrypted services can be provided.
Data transmission phase: The client and server use the HTTP protocol for data transmission, but before the data is sent out, the data will be encrypted with the encryption parameters negotiated in the handshake phase, and the receiver will decrypt the data after receiving it.

Therefore, it can be said that HTTPS is based on HTTP, but with the addition of data encryption and server authentication, which provides higher security.

For more detailed interaction, please refer to the following: HTTPS interaction process

How to deal with packet replay attacks against the SSL layer?

The above operations seem to have fulfilled the three basic requirements for secure communication, but the data integrity of the message flow during the entire session has not been fully guaranteed. Although the message integrity of a single record can be guaranteed by MAC, However, if an intruder maliciously swaps the order of two SSL records, or deliberately replays the same SSL record multiple times, this will cause the receiver to receive an incorrect final message, which is a "packet replay attack". .

Does the packet replay attack target the ssl layer? Because there is a serial number and confirmation number field in the tcp layer, it can filter out duplicate tcp message segments, but it cannot filter out different tcp message segments, but the tcp message segment replayed by the ssl certificate is correct

Yes, you understand correctly. Packet replay attacks are aimed at the application layer, especially those protocols that use encryption and authentication mechanisms (such as SSL or TLS). Since SSL/TLS is above the TCP layer, they usually do not deal with TCP-level issues, such as data retransmission or packet loss, which are usually handled by TCP itself. Therefore, SSL/TLS needs to deal with some security issues that TCP cannot handle, including packet replay attacks.

At the TCP level, sequence numbers and confirmation numbers can indeed filter out duplicate TCP segments, and can also prevent data rearrangement to a certain extent. However, this does not prevent packet replay attacks at the SSL/TLS level. why? Because an attacker may intercept and store a complete SSL/TLS session, and then replay the session at a later time. Although these packets appear to be new at the TCP level (because they have new TCP sequence numbers), at the SSL/TLS level they are actually old packets, thus potentially leading to packet replay attacks.
Therefore, SSL/TLS must implement some defensive measures at the protocol level to prevent such attacks, such as by including an implicit sequence number in each record and taking this sequence number into account when calculating the MAC, so as to ensure that the packet sequence and completeness.

What is the common solution in the industry?

A common practice in the industry is to consider such attack scenarios during protocol design, and then provide corresponding protection measures. For example, the SSL/TLS protocol prevents replay attacks by introducing a sequence number in the MAC calculation (even if this sequence number is not visible in the sent message, that is, "implicit"). In addition, for some key operations (such as payment operations), the business system will also design some anti-replay mechanisms, such as including a , or a random number (nonce) that can only be used once wait.

Talk about the specific C/S interaction process of using serial numbers to prevent replay attacks

The specific C/S interaction process may vary due to specific protocols and application scenarios. But for the SSL/TLS protocol, it will establish a shared key between the two parties during the handshake phase, and then the two parties can start to exchange data securely. In this process, in order to prevent replay attacks, the sender on each side will maintain a sequence number for each record it sends, and use this sequence number when calculating the MAC value. When the receiving end receives a record, it will use the same method to calculate the MAC value, if the calculated MAC value matches the MAC value in the record, then the record will be accepted. Otherwise, if the MAC values do not match, the record is rejected as it may be a replayed record.

Replay will cause this MAC mismatch, why

In SSL/TLS, every time a new record is sent, the sender will automatically increment the sequence number (this feature is very important, in fact, it is very similar to TCP's reflushing mechanism). This sequence number is included in the calculation of the MAC (Message Authentication Code). MAC is obtained by performing specific algorithm operations on data such as shared keys, serial numbers, and message content. This MAC will be sent to the receiving end together.

After receiving the message, the receiving end will use the same key and the serial number maintained by itself to perform the same algorithm operation to obtain a new MAC. Then the receiving end will compare whether the newly calculated MAC is consistent with the received MAC.

If the message at the sending end is replayed maliciously, the MAC in the replayed message is calculated at the time of the original sending, and the sequence number at that time is outdated. After receiving the replay message, the receiving end will use the current (increased) sequence number for MAC calculation, and the obtained MAC value is inconsistent with the MAC in the received message, so the receiving end can recognize that this is A replayed message and refused to receive it.

In other words, the auto-increment mechanism of the serial number and the use of the serial number in MAC calculation jointly prevent replay attacks, which is why replay will cause MAC mismatches.

Using HTTPS communication, every time the receiving end receives a request, it will verify the validity of SSL. During the verification process, the MAC verification mechanism is used, and then it can be deduplicated by the way?

When using HTTPS communication, the receiving end will verify the integrity and authenticity of each SSL/TLS record, and MAC will be used in this process. In the process of receiving and sending each record, a serial number will be maintained, and this serial number will be included in the calculation process of MAC, so by verifying the legality of the MAC value, the protection against replay attacks can be realized.

Let me talk about the encryption and decryption process of MAC. Is the generation and verification process of MAC different when using symmetric keys and asymmetric keys?

MAC (Message Authentication Code) is a value calculated using the shared secret and the message content. Its main function is to verify the integrity and authenticity of the message, and it does not involve the process of data encryption. In SSL/TLS communication, the use of MAC is not affected by symmetric encryption or asymmetric encryption, and the process of generation and verification is the same.

When generating MAC, there will be a pre-shared key first, and this key is known between the two communicating parties. Then the message content (including information such as serial number, message length, etc.) and the pre-shared key are input to a specific hash function (such as HMAC-SHA256), and the output hash value is MAC.
When verifying the MAC, the receiver inputs the same pre-shared key and received message content into the same hash function to calculate a new MAC. Then compare whether the newly calculated MAC is consistent with the received MAC. If they match, the message was sent by the intended sender and was not modified in transit. If not, the message may have been tampered with, or not sent by the intended sender.

It should be noted that the MAC mechanism can guarantee the integrity and authenticity of the message, but it cannot guarantee the confidentiality of the message. That is to say, the message itself is not encrypted. To ensure the confidentiality of the message, other encryption is required Techniques such as symmetric encryption or asymmetric encryption.

Including a timestamp in the request, why can it prevent ssl anti-replay attacks, because it can filter out too old HTTPS requests based on the timestamp?

Timestamps are often used as a way to prevent replay attacks. After receiving the request, the server will check whether the timestamp in the request is within a reasonable time window (for example, the past 5 minutes). If the request's timestamp is too old, the server can assume it's a replayed request and reject it. This requires the system time of the client and server to be consistent, or at least not too different.

Using the "a random number that can only be used once" strategy, do you have to require both parties to store this random number and mark whether it expires? (In fact, the same is true for serial numbers, both parties need to maintain a list of serial numbers that were successfully used last time)

For the strategy of "a random number that can only be used once", the server usually needs to maintain a list of all random numbers and whether they have been used. When the server receives a request, it will check whether the random number is in the list, if not, it means that this is a new request, accept processing. If it is in the list and not used, it is also processed and marked as used. If it is in the list and already used, then deny the request.

The relationship between MAC and JWT, JWT will use MAC

The full name of MAC is Message Authentication Code. For JWT, you can refer to this article: Want to fully understand JWT? One article is enough
The relationship between JWT (JSON Web Token) and MAC is that the signature part of JWT can be generated using HMAC (a key-based hash algorithm, which is a type of MAC). This signature guarantees the integrity of the JWT and verifies the sender of the message.

The protocol involved in entering a URL on the website

process

dns+arp+ip+tcp+http+ssl+websocket

Do you have to use the dns protocol?

Not necessarily, if the url is accessed directly using ip+port number, there will be no dns, if there is only a domain name, the dns protocol needs to be resolved to the dns protocol

The difference between mac and ip

MAC address: Physical address, used for communication between network devices in the same LAN. It is globally unique, assigned by the network equipment manufacturer at the time of production, and is usually hard-coded into the network interface card (NIC) hardware.
IP address: Logical address, used to uniquely identify a network interface on the network. IP addresses may be assigned statically or dynamically obtained from a DHCP server. The same network device may have different IP addresses in different network environments.

What kind of message is arp and what is used to realize it? Do you know?

ARP (Address Resolution Protocol) is a resolution protocol that can resolve an IP address into a corresponding MAC address. When a device needs to send data to another device on the network, it will first use the ARP protocol to find the MAC address of the target device. Both ARP requests and responses are encapsulated in Ethernet frames for transmission.

After arriving at the host, how do I know whether you are dealing with https or http

This is usually distinguished by the port used. By default, HTTP uses port 80 and HTTPS uses port 443. Of course, these ports are configurable, and you don't have to use the default ports. (I answered the establishment process of https)
Isn’t https built on top of http, the port of http is 80, and the port of https is 443, can the port number be changed after http is established?
HTTPS is indeed built on top of HTTP, but the port numbers they use are different. The default port number for HTTP is 80, and the default port number for HTTPS is 443. This is due to the fact that HTTP and HTTPS are actually two different protocols, although their content and format are very similar. When we say that HTTP is upgraded to HTTPS, it actually means that an encryption layer of SSL/TLS is added on the basis of HTTP, so that data transmission is more secure. As for whether the port number can be changed after the HTTP connection is established, generally speaking, this is not possible. The port number is determined when the TCP connection is established. Once the TCP connection is established, the port number cannot be changed. If you need to change the port number, you must disconnect the existing TCP connection, and then re-establish a new TCP connection.

Is the first request to establish ssl initiated by the client or the server?

In the SSL/TLS protocol, the establishment of a connection is generally initiated by the client. The client will first send a "ClientHello" message to the server, indicating that it wishes to establish an SSL/TLS connection. The server then responds with a "ServerHello" message, along with the server's certificate and a "ServerHelloDone" message. The subsequent handshake process will also involve steps such as key exchange and handshake completion.
Why is it initiated by the client, because does the client know that it has to use the https protocol from the beginning?
Usually, the client knows whether to use HTTPS or not. For example, when you enter a URL in your browser, you specify whether to use http:// or https://. If you specify https://, then the browser knows that HTTPS is required and starts the SSL/TLS handshake immediately after the TCP connection is established. This handshake process is initiated by the client, because in the SSL/TLS protocol, the client is responsible for providing the choice of encryption parameters and starting the handshake process.

What's inside a digital certificate?

A digital certificate usually contains the following information:
The public key of the certificate owner
The information of the certificate owner (including name, email address, authority to use the certificate, etc.) The information
of the certification authority (CA) that issued the certificate
The validity period of
the certificate Certification authority Digital signature on the above information

How does the client verify whether the certificate is valid?

Verify whether the certificate is issued by the superior CA. When verifying the certificate, the browser will call the certificate manager interface of the system to verify all the certificates in the certificate path level by level. Only all the certificates in the path are trusted. , the result of the entire verification is trusted.

After the client receives the server's certificate, it will do the following checks to verify the validity of the certificate:

Verify the signature of the certificate: The client will use the public key of the certificate authority to verify the signature of the certificate to confirm that the content of the certificate has not been tampered with.
Verify the validity period of the certificate: The certificate has a validity period. If the current date is not within the validity period of the certificate, the certificate is invalid.
Verify the certificate's issuing authority: The client checks that the certificate's issuing authority is trusted, usually by checking the list of trusted CAs in the operating system or browser.

Verify the signature of the certificate: The client will use the public key of the certificate authority to verify the signature of the certificate to confirm that the content of the certificate has not been tampered with. Can you watch and talk about the process?
For the signature verification process of a digital certificate, the following is a possible simplified description:

After the client receives the server's digital certificate, it first obtains the public key of the certificate authority (CA) from the certificate.
The client uses the CA's public key to decrypt the digital signature in the certificate and obtain a digest value.
The client also hashes everything in the certificate except the digital signature to get another digest value.
The client compares the two digest values, and if they are the same, the content of the certificate has not been tampered with and the certificate is valid. If they are different, then the contents of the certificate may have been tampered with and the certificate is invalid.

The key to this process is that only a real CA can generate a digital signature that can be correctly decrypted by its public key, so in this way you can verify whether the certificate is issued by a real CA and whether the content of the certificate has been tampered with Pass.

What are the advantages of udp, and which scenarios do they correspond to?

UDP (User Datagram Protocol) is a connectionless protocol. Its main advantages include:
Simple: UDP does not need to establish and disconnect connections, and does not need complex error checking and recovery, which makes the implementation of UDP relatively simple.
Efficient: Since UDP does not require connection management and error recovery, it is more efficient than TCP.
UDP is often used in scenarios where reliable transport is not required, or where error recovery can be handled at the application layer. For example: video streaming, real-time gaming, VoIP, etc.

How much data can a udp package hold?

UDP datagrams are limited in size. Its header occupies 8 bytes, including source port, destination port, length and checksum. The length field of a UDP datagram is 16 bits, so the maximum size of a UDP datagram is 2^16 - 1 = 65535 bytes. Subtract the 8-byte header, and the minimum size of the IP header (20 bytes), and you're left with a maximum payload of 65507 bytes.

When forwarding, can the package with the maximum number of bytes supported be forwarded at one time?

In fact, although the theoretical maximum size of a UDP datagram is 65535 bytes, it is often subject to various restrictions in actual networks. For example, the IP protocol stipulates that if the size of a data packet exceeds the MTU (Maximum Transmission Unit), then the data packet needs to be fragmented and then reassembled at the receiving end. Generally speaking, the MTU of Ethernet is 1500 bytes, so in the Ethernet environment, if the size of a UDP datagram exceeds this value, it may need to be fragmented. However, UDP is a connectionless protocol, it does not have a retransmission mechanism like TCP, so if a fragment of a UDP datagram is lost, the entire datagram will be discarded. Therefore, in practical applications, we usually try to avoid sending too large UDP datagrams to avoid fragmentation and possible data loss.

Yes, in order to avoid fragmentation and possible data loss caused by oversized UDP datagrams, in general, the application layer needs to be responsible for controlling the size of each UDP datagram (and can also be responsible for its reliability) . This is because UDP itself is a simple, connectionless protocol that does not provide any mechanisms for congestion control, flow control, or error recovery. Therefore, for these problems, it usually needs to be dealt with at the application layer.

In some applications that require real-time data transmission, such as video conferencing or online games, UDP is a very commonly used protocol. In these applications, some strategies are usually used to avoid sending too large UDP datagrams. For example, the size of each video frame can be controlled by adjusting video encoding parameters, or only a part of the video frame is included in each UDP datagram, so as to ensure that the size of each UDP datagram will not exceed the MTU . Of course, this may increase the complexity of programming, because data fragmentation and assembly need to be processed, but in this way, data packet fragmentation at the network layer can be avoided, thereby improving the efficiency and stability of data transmission.

How does http cross domains?

How HTTP crosses domains: In HTTP, cross domains are restricted by the same-origin policy of the browser. But there are some common ways to cross-domain:

JSONP (JSON with Padding): Only GET requests can be made.
CORS (Cross-Origin Resource Sharing): The server sets the response header Access-Control-Allow-Origin to allow the source to access, and can also set the allowed methods and headers through Access-Control-Allow-Methods, Access-Control-Allow-Headers, etc. .
Use proxy: For example, set Nginx to perform reverse proxy (at this time, the proxy server must be of the same origin as the client, and then the proxy server is set to complete the cross-domain request), or set HTTP proxy in Node.js.
Use Websockets for communication.
Bypass browsers using inter-server communication or storage sharing.

websocket

The relationship between websocket and http

The relationship between WebSocket and HTTP:

Both WebSocket and HTTP are communication protocols, and they are both based on the TCP/IP protocol. WebSocket is an independent protocol built on top of TCP. Both HTTP and WebSocket can use URL Scheme to define the address, HTTP uses http or https, and WebSocket uses ws or wss (corresponding to the encrypted connection of HTTP and HTTPS).

Is websocket built on top of http?

Whether WebSocket is built on top of HTTP:

WebSocket is not built on top of HTTP, it is an independent protocol. But the WebSocket handshake uses the HTTP protocol, which is for compatibility with the existing HTTP infrastructure.

The relationship between websocket and publish-subscribe mechanism

The relationship between WebSocket and publish-subscribe mode:

WebSocket is a full-duplex communication protocol that allows the server to actively push information to the client, and the client can also actively send information to the server, which makes it a good choice for implementing the publish-subscribe model. When using WebSocket for real-time communication, it is often designed in conjunction with the publish-subscribe model.

The establishment process of websocket

The establishment process of WebSocket:
- The client negotiates with the WebSocket server to establish a connection through an HTTP request. This process is often called a "handshake". If the server accepts the connection request, it sends back a successful HTTP response, and the HTTP connection is upgraded to a WebSocket connection.
- During the handshake, the client will send an HTTP request to the server, which contains an Upgrade: websocket header, indicating an attempt to upgrade the connection to WebSocket.
- After the server receives this request and agrees to the connection, it will return an HTTP response containing the Upgrade: websocket header. In this way, the handshake process is completed, and the communication between the client and the server is switched to the WebSocket protocol.

These are the basic contents of the WebSocket protocol. In practical applications, you may also need to conduct more in-depth understanding and research according to your needs and environment.

TCP connection and release

Regarding the connection and release of tcp, it is recommended to read this article Theoretical classic: Detailed explanation of the 3-way handshake and 4-way handshake process of the TCP protocol , with a detailed process

Why do you need a three-way handshake, can't you do it twice?

Imagine that if you use two handshakes, the following situation will occur:

If the client sends a connection request, but does not receive an acknowledgment due to the loss of the connection request message, the client retransmits the connection request again. A confirmation was later received and the connection was established. After the data transmission is completed, the connection is released, and the client sends two connection request segments, the first one is lost, and the second one reaches the server, but the first lost segment is only in some The network node stays for a long time, and it is delayed until a certain time after the connection is released to reach the server. At this time, the server mistakenly believes that the client sends a new connection request, so it sends a confirmation message segment to the client, agreeing To establish a connection, a three-way handshake is not used. As long as the server sends a confirmation, a new connection is established. At this time, the client ignores the confirmation sent by the server and does not send data. The server waits for the client to send data, wasting resources. .

Why does the client have to wait for 2MSL to release the client's resources after the fourth wave?

1. Why does the TCP disconnect need to wave four times?

TCP is a reliable two-way communication protocol, so each direction must be closed separately. The process takes four steps to ensure that both parties can close their connections. The first two waves are used to close the connection of the initial sender, and the last two waves are used to close the connection of the other party . That is to say, sending "FIN" just means that the sender no longer sends data, but can still receive data ; after receiving the other party's "FIN" flag, it means that the other party will no longer send data, and the connection can be completely closed.

2. When the last wave of TCP disconnection, why both the client and the server wait for 2MSL? (The interviewer may ask why the client enters the time_wait state after sending the last ACK to the server)

The client needs to wait for 2MSL (Maximum Segment Lifetime) after sending the last ACK packet. There are two main reasons for this:

Make sure the last ACK reaches the server. If the ACK is lost, the server will resend the FIN packet, and the client sends the ACK again.
Avoid "old duplicate packets" staying in the network for too long. In the 2MSL time after the TCP connection is closed, the connection with the same source ip address, destination ip address, source port, and destination port is not allowed to be established. This is mainly to prevent the delayed data packets of the old connection from being mistaken in the new connection. considered to be valid data. **If the client is asked to wait for 2MSL time, then

As an example:

Suppose you have a TCP connection between a client and a server with a source address and port of C1:1234 and a destination address and port of S1:80. In this connection, you send a data packet P, but due to network delay, P stays in the network for a long time and does not reach the server immediately. Then you close the connection.

Now, you want to open a new connection between the same client and server, still using C1:1234 and S1:80. If you open a new connection immediately after closing the old connection, the data packet P stuck in the network may reach the server and be mistaken by the server as valid data in the new connection, which will cause data confusion and errors.

In order to prevent this situation, TCP stipulates that within 2MSL time after closing the connection, no connection with the same source address, destination address, source port, and destination port is allowed to be established. In this way, the data packet P staying in the network has enough time to disappear in the network without affecting new connections.

So 2MSL is something both server and client need to wait for?

Yes, 2MSL (Maximum Segment
Lifetime, Maximum Segment Lifetime) is the time that a TCP connection needs to pass before it is completely closed. This period of time applies to both the client and the server. This is because the TCP connection is full-duplex, that is, both the client and the server can send and receive data. Therefore, whether it is a client or a server, it is necessary to ensure that the last data packet (or confirmation packet) it sends can reach the opposite end, and it needs to wait for enough time so that all data packets stranded in the network have a chance to reach the opposite end or be discarded. In this way, when a new connection is established on the same port and address, it will not be affected by these "old" packets.

3. What is the MSL?

The specific value of MSL varies depending on the system and network environment, but the common value is 2 minutes. This value is long enough to ensure that all packets of the TCP segment in the network no longer exist. However, this value is not fixed in the actual network environment and can be set according to the actual network environment and requirements.

4. If the client's ACK is lost, the server has a timeout mechanism, which must be less than the MSL time, so the FIN will be retransmitted within this time. What if the retransmitted FIN is lost again?

If the FIN resent by the server has been lost, according to the design of TCP, the server will try to resend a certain number of times or wait for a period of time. If it still does not receive the ACK from the client, the server will assume that the client has received the FIN and treat the connection as is off. While there may be some resources that are not reclaimed immediately, this process is usually automatic and requires no additional intervention. In fact, because of the reliability of the network, the situation that FIN packets are always lost rarely happens in reality.

5. Between the server's second wave and the third wave, can the server still transmit other data to the client?

Yes, after the server receives the FIN message from the client and replies with the ACK message, the server can continue to send data to the client during the period until it sends its own FIN message. This is because TCP is full-duplex. Sending a FIN message at one end means "I have no data to send to you", and it does not affect the sending of data at the other end.

DDOS/DOS/SYN flood attack

some differences between the three

1 Why is DDOS called so? Isn’t it the client’s refusal to make a third response?
2 What’s the difference with DOS
3 What’s the difference with SYN attack

DDoS (Distributed Denial of Service, Distributed Denial of Service) attack is so called because it usually involves the use of many decentralized systems (such as infected computers or other network equipment) to launch a large-scale attack, so that the target The system cannot provide normal service. DDoS attack does not just refer to the refusal to make the third tcp response, it is a general term for a type of attack, including SYN flood attack, UDP flood attack, ICMP flood attack, etc.
The main difference between a DOS (Denial of Service) attack and a DDoS attack lies in the initiator of the attack. DOS attacks are usually launched by a single source, while DDoS attacks are launched by multiple sources (distributed in different network locations). Due to the dispersion and scale of DDoS attacks, it is more difficult to defend against than DOS attacks.
SYN flood attack is a specific DoS/DDoS attack method, which uses the three-way handshake mechanism of TCP. In a SYN flood attack, the attacker will send a large number of SYN requests to the server, but will not confirm the server's SYN+ACK response (that is, not send the third handshake), resulting in a large number of half-open connections occupying server resources, causing Normal users cannot connect to the server. Therefore, SYN flood attack can be regarded as a special DoS/DDoS attack.

Common defense methods against SYN attacks are as follows:

Shorten the timeout (SYN Timeout) time
, increase the maximum number of semi-connections,
filter gateway protection
SYN cookies technology

Explain some of the above preventive methods

Shorten the timeout (SYN Timeout): In this method, the server will shorten the timeout period waiting for the client to complete the TCP three-way handshake. If within this shortened time, the client does not send the third handshake (ie ACK), the server will close the half-open connection and release resources. In this way, the server can process those incomplete connections faster, so that there are more resources to process new connection requests.
Increase the maximum number of half-open connections: The server can defend against SYN flood attacks by increasing the maximum number of half-open connections it allows. This can increase the server's ability to handle a large number of half-open connections. However, this method cannot completely solve the problem, because the attacker may exceed the maximum number of half-open connections of the server by continuously increasing the number of SYN requests.
Filtering gateway protection: Deploying a filtering gateway at the boundary of the network (such as a firewall or router) can help defend against SYN flood attacks. This device can analyze the traffic entering the network, identify possible SYN flood attacks, and prevent these attack traffic from entering the internal network.
SYN cookies technology: SYN cookies are a very effective technology to defend against SYN flood attacks. In a server using SYN cookies technology, when a SYN request is received, the server does not immediately allocate resources to create a half-open connection (a half-open connection is also resource-intensive) , but calculates a cookie (an encrypted hash value), And send this cookie back to the client as the Initial Sequence Number (ISN) in the SYN+ACK response. If the client is legitimate and really wants to establish a connection, then in the third handshake, it will send an ACK whose acknowledgment number is the previous ISN plus one. At this time, after the server receives the ACK, it can verify whether the ACK is legal through the cookie. If it is legal, the connection is established, otherwise it is ignored. In this way, for legal connection requests, resources are only allocated when the connection is actually established, but for SYN requests caused by attacks, the server does not allocate resources, thus effectively defending against SYN flood attacks.

SYN cookies are designed to defend against SYN flood attacks. In this attack, the attacker sends a large number of SYN requests in an attempt to exhaust server resources, but they do not complete the TCP three-way handshake and therefore never send an ACK response.

The core idea of SYN cookies technology is that the server does not fully trust the client before actually allocating resources. In order to confirm the real intention of the client, the server sends an encrypted hash value (cookie) as the initial sequence number (ISN). Legitimate clients will respond with an ACK based on this ISN.

After the server here receives the ACK, how to verify whether the ACK is legal through the cookie

The rationale behind the SYN cookie technique is to verify the legitimacy of the client without fully establishing the connection. The specific workflow is as follows:

Generate Cookie : When the server receives a SYN request, it will not immediately allocate memory or other resources for the connection, but will be based on the client's IP address, port number, its own IP address and port number, and a key, through A hash function generates a cookie. This cookie is then sent to the client as an Initial Sequence Number (ISN).
Client response : If the client is legal, it will add one to the ISN value and send it to the server as the confirmation number of the ACK response.
Verify Cookie : When the server receives the ACK, it recalculates the cookie again according to the previous algorithm, and then checks whether this recalculated value matches the acknowledgment number returned by the client (specifically, whether it is higher than the acknowledgment number returned by the client) number one less). If it matches, the SYN request is valid and the server will fully establish the connection.

The key to this mechanism is that the cookie generation algorithm is pseudo-random, but predictable in a short period of time. Therefore, only a legal client that knows the correct ISN may return the correct ACK confirmation number. In this way, the server can effectively filter out malicious SYN requests before resource allocation, thereby avoiding excessive consumption of resources.

It should be noted that because SYN cookies technology does not really allocate resources for the connection during the initial handshake phase, some TCP characteristics (such as the maximum segment size) may not be handled normally when using this technology. This is a small drawback of this defense mechanism.

Only a legal client that knows the correct ISN may return the correct ACK confirmation number. Don’t a large number of forged clients know the ISN number? Why?

Yes, you pointed out an important point. In a SYN flood attack, the attacker sends a large number of SYN requests, but most of the time these requests come from fake IP addresses. This means that the attacker may not actually receive the SYN+ACK response, because the response will be sent to the fake IP address instead of the attacker's real address. Therefore, an attacker usually cannot see the correct ISN (because it is included in the SYN+ACK response).

Consider the following steps:

The attacker sends a SYN request from a spoofed IP address.
The server receives the SYN request and calculates the cookie, which is then sent as the ISN in the SYN+ACK response to the forged IP address.
Since the IP address is spoofed, the attacker may never see this SYN+ACK response and thus the correct ISN.

If the attacker doesn't know the correct ISN, then they won't be able to send a matching ACK to pass the server's cookie verification.

Note, however, that this strategy may not be very effective against source-true SYN flood attacks, since the attacker can see the SYN+ACK response and send the correct ACK. However, in practice, most SYN flood attacks use forged IP addresses because it makes it more difficult to track down the attacker.

What resources on the server side are mainly consumed by SYN Flood?

When suffering from a SYN flood attack, the attacker sends a large number of SYN requests with forged source addresses in order to exhaust the relevant resources of the server, so that legitimate users cannot establish connections with the server. The main affected resources include:

Half-open queue : When the server receives a SYN request, it creates an entry in a queue called half-open to track the connection. This queue has a size limit. When suffering from a SYN flood attack, this queue will be filled quickly, making legitimate connection requests unable to be tracked.
Memory : Each entry in the semi-join queue requires some memory to store information about the connection. A large number of forged SYN requests will cause the server to allocate a large amount of memory for these forged connections.
CPU : Both processing forged SYN requests and sending SYN-ACK responses require CPU resources. This increases the CPU load on the server when subjected to a large number of forged SYN requests.
Bandwidth : An attacker sending a large number of SYN requests consumes network bandwidth. In addition, the server consumes additional bandwidth in responding to these requests. In some cases, this can cause network congestion.
File Descriptor : Each new connection request requires a file descriptor. In UNIX and Linux systems, each process has a maximum file descriptor limit. When these descriptors are exhausted, the server may not be able to handle new connections or perform other file, socket related operations.
Other system resources : In addition, some other system resources may also be affected, such as ARP cache, routing table, etc.

In order to defend against SYN flood attacks, various strategies can be adopted, the most famous of which is the SYN cookies technology. This technique allows the server to handle SYN requests without preallocating large resources.

Summary of SYN Mechanism

This is actually a sniffing mechanism, very similar to DCL, three-stage distributed transactions, and hashcode+equals to judge whether objects are equal; they all perform detection work by sending some pre-check requests/commands in advance, and general detection work will not Let the server or cpu consume too many resources

Why there is no SYN attack without SSL layer

Answer: SSL/TLS is a protocol applied on top of a transport layer (such as TCP) to provide encryption and authentication for communications between the application layer and the transport layer. A SYN attack is an attack against the transport layer (especially TCP). The attacker consumes server resources by sending a large number of SYN packets but never completing the three-way handshake process.

When starting an SSL/TLS session, the TCP connection has been established and the three-way handshake has been completed. Therefore, SSL/TLS itself is not affected by SYN attacks. However, it can be subject to other types of attacks, such as SSL handshake flood attacks, in which an attacker tries to consume a server's computing resources with a large number of SSL/TLS handshakes .

Among them, the attacker tries to use a large number of SSL/TLS handshakes to consume the computing resources of the server. The handshake here refers to ssl replay attacks.

When I refer to an attacker trying to consume a server's computing resources with numerous SSL/TLS handshakes, I'm not referring to replay attacks. What I mean is that the attacker tries to establish a large number of new SSL/TLS connections to the server, which triggers a large number of encrypted handshakes. The public key encryption and digital certificate verification involved in the SSL/TLS handshake are computationally intensive operations. A large number of such handshakes will occupy a large amount of server resources, which may cause legitimate user requests to not be processed. This attack is known as "SSL handshake flood attack".

The SSL attack shows that the attacker is using real IP addresses, right?

When performing an SSL/TLS attack, attackers do often use real IP addresses, as they complete the handshake with the server. But that doesn't mean they can't use fake or bogus IP addresses. Using real IP addresses does make attacks easier to track and locate, but attackers may use botnets or other methods to hide their true location. In cybersecurity, few things are certain, and attackers often use a variety of tricks and tactics to achieve their goals.

SYN can only stop the flood attacks of the tcp layer and the application layer. Does the IP layer and the data link layer have such attacks? Are the measures taken similar to this one?

Why No SSL Layer No SYN Attack
SSL/TLS is a protocol applied on top of a transport layer (eg TCP) that provides encryption and authentication for communication between the application layer and the transport layer. A SYN attack is an attack against the transport layer (especially TCP). The attacker consumes server resources by sending a large number of SYN packets but never completing the three-way handshake process.

When starting an SSL/TLS session, the TCP connection has been established and the three-way handshake has been completed. Therefore, SSL/TLS itself is not affected by SYN attacks. However, it can be subject to other types of attacks, such as SSL handshake flood attacks, in which an attacker tries to consume a server's computing resources with a large number of SSL/TLS handshakes.

IP layer, data link layer attack
IP layer attack:

ICMP Flood (Ping Flood): The attacker sends a large number of ICMP Echo (ping) requests to the target, making it respond continuously.
IP Fragmentation Attack: The attacker sends a large number of fragmented packets to the target, causing it to expend resources trying to reassemble these packets.
Data link layer attack:
MAC Flooding: An attacker tries to fill up the MAC address table of the switch, causing normal traffic to fail.
ARP Spoofing: An attacker sends forged ARP messages to a LAN with the purpose of redirecting certain traffic from its normal path to the attacker.

For these attacks, responses vary on a case-by-case basis. Generally speaking, you can use firewalls, intrusion detection systems, traffic restrictions, filtering and other means to prevent them. For data link layer attacks, network devices usually have built-in security mechanisms and strategies to resist.

SYN injection attack

A TCP sequence number prediction attack (sometimes also called a SYN injection attack) is a relatively complex attack that requires an in-depth understanding of the TCP protocol. The following is the basic flow of the attack:

Monitor target connections : First, an attacker needs to listen or observe a TCP connection between two targets. Attackers usually target a pair of machines that are communicating, such as a user and a web server.
Capture SYN and SYN-ACK : When a new TCP connection starts, there is a three-way handshake. During this process, the client sends a SYN packet, and the server replies with a SYN-ACK packet. The attacker captures both packets to obtain their sequence numbers.
Predicting Sequence Numbers : Based on the captured sequence numbers, the attacker tries to predict the sequence numbers of subsequent packets. This requires knowledge of TCP implementation specific details and behavior.
Sending forged packets : Once an attacker has determined the predicted sequence numbers, they can create forged TCP packets. These packets will look like they come from a legitimate client or server because they use predicted sequence numbers.
Connection Hijacking : Since forged packets look like legitimate packets, they may be received and processed, causing legitimate packets to be replaced by forged ones.
Preventing legitimate packets from reaching the target : To ensure that forged packets are accepted and processed, the attacker may also need to ensure that legitimate packets do not reach the target. This can be accomplished through a DoS attack or other methods, with the goal of having forged packets arrive before or in place of legitimate packets.

It should be noted that this attack relies on being able to predict or determine the TCP sequence number, which is a security risk in the design of TCP. To alleviate this problem, many modern TCP implementations employ randomized sequence numbers, making this attack more difficult.

Replay attack?

Replay Attack , also known as regeneration attack or repeat play attack, refers to the attacker resending or repeatedly sending valid data transmission, thereby deceiving the computer system to perform unauthorized operations. This type of attack mainly occurs during authentication, where an attacker attempts to deceive a system or network by capturing, copying, and resending valid user authentication information such as passwords, tokens, or keys.

Here are some simple examples of replay attacks:

Attacks in wireless networks : If an attacker can capture the authentication handshake of other devices in a wireless network, they can use this handshake again later to gain access to the network, even if the original device is disconnected.
Online Payments : An attacker intercepts a user's online payment transaction and resends the same transaction shortly afterwards, causing the user to be billed multiple times.
Login Credentials : An attacker captures a user's login token or password and uses it to gain access to the system again.

To defend against replay attacks, the following strategies are usually used:

Timestamp : Add a timestamp to each request, and verify this timestamp on the server side to ensure that the request is new and within a specific time window.
Sequence Number : Similar to a timestamp, each message is given a unique, incrementing sequence number and validated on the server side.
One-time tokens : Use a mechanism, such as HOTP or TOTP, to generate one-time, short-lived credentials or tokens to ensure that each login request is unique.
Encryption and integrity checking : Use appropriate encryption and/or HMAC to ensure the confidentiality and integrity of data so that even if an attacker intercepts the data, it cannot easily replay it.

In general, a replay attack is a threat that involves resending valid data, but can be mitigated and protected by a variety of strategies.

Do you think HTTPS can prevent replay attacks? Why yes, HTTP?

HTTPS is mainly based on the SSL/TLS protocol, which includes a series of mechanisms designed to prevent replay attacks. Here's why HTTPS prevents replay attacks, and why HTTP doesn't:

Protection against HTTPS and replay attacks :
- Random Number : During the TLS handshake, both the client and the server generate a random number. These random numbers are used to establish session keys. Even if an attacker intercepts the handshake data and tries to replay it, they cannot correctly establish the session key due to the nonce.
- Session Recovery and Session ID : If the client and server decide to reuse the previous session parameters, they will use a session ID for session recovery. If an attacker attempts to replay using an intercepted session ID, they will fail because the session parameters associated with that ID have expired or are invalid on the server.
- Sequence Number : In TLS, each record has a sequence number. If the server receives a sequence number that has already been seen, it rejects the record, thus preventing replay attacks.
HTTP and replay attacks :
- No built-in protection : HTTP is a clear-text protocol, which provides no built-in protection against data integrity, confidentiality, or replay attacks. Therefore, if an attacker intercepts an HTTP request, they can simply resend it again for a replay attack.
- Does not use nonces or sequence numbers : Unlike HTTPS, HTTP does not include nonces or sequence numbers in requests, which means replay attacks are easier.

To sum up, HTTPS provides multiple mechanisms to prevent replay attacks, while HTTP itself has no such protection. This is one of the reasons why many websites and applications choose to use HTTPS instead of HTTP, because it provides additional security for data transmission.

Can't the hacker directly use the captured symmetric key to complete the replay?

You raise a great question. Indeed, if a hacker manages to capture the symmetric key, then they can decrypt the captured data, but simply having the symmetric key does not directly allow them to successfully perform a replay attack for the following reasons:

Short-lived session keys : The symmetric keys (session keys) used in TLS/SSL usually only exist for the duration of a session. Every handshake generates a new session key. So, even if an attacker obtains the key, it's only valid for that particular session. If an attacker wants to perform a replay attack in a new session, they need to obtain the key for the new session.
Sequence numbers and timeliness : As mentioned earlier, every record in TLS has a sequence number. The server keeps track of these sequence numbers to detect replay attacks. Even if an attacker has the symmetric key and tries to replay a record, the server will reject the record because of the sequence number.
Integrity checking : TLS is more than just encryption, it also provides data integrity checking. Each message is accompanied by a checksum (like HMAC). An attacker cannot modify these messages without being detected.
PFS (Perfect Forward Secrecy) : Many modern TLS configurations use perfect forward secrecy. This means that even if the long-lived private key (or other session's keys) is compromised, it will not compromise the security of other sessions. Each session has a unique key that is not dependent on other sessions.

Of course, this is theoretically possible if an attacker captures the key during a session and immediately tries to replay it, but they only have a short window of time to do so, and it requires a fairly high position and capability on the network. Also, modern security configurations and measures (like the aforementioned PFS) make this type of attack very difficult in practice.

Overall, just having a symmetric key is not enough for a successful replay attack, but it certainly increases the attacker's capabilities, which also emphasizes the importance of key management and protection.

XSS, CSRF, SQL injection and other security issues

XSS（Cross-Site Scripting）：

It is an injection attack in which the attacker injects malicious scripts on the target website, and these scripts are executed when other users visit the website.
Defense methods: filter user input, escape output, use Content Security Policy (CSP).

CSRF（Cross-Site Request Forgery）：

The attacker tricks the victim's browser into sending a request to the target website (given that the victim is logged in), so that the attacker can fake the user's behavior.
Defense method: use anti-CSRF tokens to ensure that only real users can perform sensitive operations.

SQL injection:

An attacker inserts SQL code into an application's input field. If the application does not handle the input properly, then this code may be executed by the database server.
Defense method: Use parameterized queries to avoid directly splicing SQL statements.

Deep Thinking about Computer Networks Part 2