Server internet protocol address determination method and device, equipment, medium and product

Abstract

The embodiment of the invention provides a server internet protocol address determination method and device, equipment, a medium and a product, and relates to the technical field of computer networks. According to the method, the problem of low address determination efficiency in the prior art is effectively solved by introducing a dynamic decision-making mechanism based on multivariable correlation analysis and traffic prediction. According to the method, firstly, key variables having significant influence on the network request quantity are screened out by using correlation coefficients, then the telephone traffic load condition in a future time period is accurately estimated through a prediction model, and finally, intelligent screening of service nodes is realized in combination with user demands and prediction results. The design breaks through the traditional limitation of relying on static address mapping, the returned server address can accurately reflect the network real-time state and the resource bearing capacity by fusing multi-dimensional dynamic factors, and the address determination accuracy and the system response efficiency are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer networks, and in particular to a method and device for determining a server internet protocol address, a medium and product. BACKGROUND

[0002] In the context of the increasing popularity of network applications, users often initiate access requests by memorizing service domain names. The key to supporting this process is the accurate conversion of domain names to server real locations. How to ensure that each access is intelligently directed to the appropriate server directly affects the efficiency of information transmission and the quality of service response. Therefore, accurate determination of server addresses is of great significance.

[0003] In the prior art, the determination of a server internet protocol address usually relies on a hierarchical query mechanism of the domain name system. When a user initiates a request, a resolver will sequentially query authoritative servers such as root domains and top-level domains, and finally obtain the server address corresponding to the domain name. This process mainly returns address determination results based on pre-configured static address mapping relationships.

[0004] However, the prior art has the problem of low efficiency in determining a server internet protocol address. The existing address determination process often relies on limited and lagging system state information, and fails to comprehensively consider various dynamic factors affecting the determination of a server internet protocol address, resulting in addresses that cannot accurately reflect real-time network conditions and resource carrying capacity. SUMMARY

[0005] The embodiments of the present application provide a method and device for determining a server internet protocol address, a medium and product, to solve the problem of low efficiency in determining a server internet protocol address in the prior art.

[0006] In a first aspect, the embodiments of the present application provide a method for determining a server internet protocol address, applied to a resolver of a server internet protocol address determination system, the server internet protocol address determination system further comprising a user end and a plurality of servers, and the method comprising:

[0007] receiving a service domain name and user demand sent by the user end; wherein the user demand is used to represent the demand of the user end for a server;

[0008] performing a cache query according to the service domain name to obtain a query result; wherein the query result comprises a first result, and the first result is used to represent that the resolver does not cache the internet protocol address corresponding to the service domain name, or the internet protocol address has expired;

[0009] In response to the query result being the first result, the correlation coefficient between any two variables from a preset set of variables is calculated, and the two variables corresponding to the correlation coefficients greater than a preset threshold are determined as the first variables; wherein, the set of variables refers to variables that affect traffic volume;

[0010] Obtain the data corresponding to each of the first variables, and input the data corresponding to each of the first variables into a preset traffic volume prediction model to obtain the traffic volume; wherein, the traffic volume is used to represent the number of network requests made by the user terminal in a preset time period in the future;

[0011] The multiple servers are filtered according to the user needs and the call volume to obtain the target server; wherein, the target server refers to the server among the multiple servers that meets the user needs and the call volume;

[0012] The system receives the Internet Protocol address (IPA) sent by the target server and sends the IPA of the target server to the user terminal, which is used to access the website based on the IPA of the target server.

[0013] Secondly, embodiments of this application provide a device for determining a server Internet Protocol (IP) address, a parser applied to a system for determining a server IP address, wherein the system for determining a server IP address further includes a user terminal and multiple servers, and the device includes:

[0014] The first receiving module is used to receive the service domain name and user request sent by the user terminal; wherein, the user request is used to represent the user terminal's request for the server;

[0015] The first query module is used to perform a cache query based on the service domain name to obtain a query result; wherein, the query result includes a first result, which is used to indicate that the resolver has not cached the Internet Protocol address corresponding to the service domain name, or that the Internet Protocol address has expired;

[0016] The first calculation module is used to, in response to the query result being the first result, calculate the correlation coefficient between any two variables among a preset plurality of variables, and determine the two variables corresponding to the correlation coefficients that are greater than a preset coefficient threshold as the first variables; wherein, the plurality of variables refers to variables that affect traffic volume;

[0017] The first acquisition module is used to acquire data corresponding to each of the first variables and input the data corresponding to each of the first variables into a preset traffic volume prediction model to obtain the traffic volume; wherein, the traffic volume is used to represent the number of network requests made by the user terminal in a preset time period in the future;

[0018] The first filtering module is used to filter the plurality of servers according to the user needs and the call volume to obtain a target server; wherein, the target server refers to the server among the plurality of servers that meets the user needs and the call volume;

[0019] The second receiving module is used to receive the Internet Protocol address sent by the target server and send the Internet Protocol address of the target server to the user terminal, which is used to access the website based on the Internet Protocol address of the target server.

[0020] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0021] The memory stores computer-executed instructions;

[0022] When the processor executes the computer execution instructions stored in the memory, it is used to implement the method for determining the server Internet Protocol address as described in any of the first aspects.

[0023] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method for determining the server Internet Protocol address as described in any of the first aspects.

[0024] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, is used to implement the method for determining the server Internet Protocol address as described in any of the first aspects.

[0025] This application provides a method, apparatus, device, medium, and product for determining the Internet Protocol (IP) address of a server. By introducing a dynamic decision-making mechanism based on multivariate correlation analysis and traffic volume prediction, it effectively solves the problem of low efficiency in address determination in existing technologies. The method first uses correlation coefficients to screen out key variables that significantly affect network request volume, then uses a predictive model to accurately predict future traffic load, and finally combines user needs with the prediction results to achieve intelligent selection of service nodes. This design breaks through the limitations of traditional reliance on static address mapping. By integrating multi-dimensional dynamic factors, the returned server address accurately reflects the real-time network status and resource carrying capacity, improving the accuracy of address determination and system response efficiency. Attached Figure Description

[0026] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0027] Figure 1 A schematic diagram illustrating an application scenario for the method for determining the server Internet Protocol address provided in this application embodiment;

[0028] Figure 2 A flowchart illustrating the method for determining the Internet Protocol address of a server provided in this application embodiment. Figure One ;

[0029] Figure 3 A diagram of the TPA-LSTM neural network model provided in the embodiments of this application;

[0030] Figure 4 A flowchart illustrating the method for determining the Internet Protocol address of a server provided in this application embodiment. Figure Two ;

[0031] Figure 5 A flowchart illustrating the method for determining the Internet Protocol address of a server provided in this application embodiment. Figure Three ;

[0032] Figure 6 A flowchart illustrating the method for determining the Internet Protocol address of a server provided in this application embodiment. Figure Four ;

[0033] Figure 7 A schematic diagram of the structure of the device for determining the Internet Protocol address of a server provided in an embodiment of this application;

[0034] Figure 8 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application.

[0035] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0036] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0037] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply difference. It should be noted that in the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner. In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more.

[0038] It should be noted that the phrase "at...time" in the embodiments of this application can refer to the instant at which a certain situation occurs, or to a period of time after the occurrence of a certain situation; the embodiments of this application do not specifically limit this. Furthermore, the method, apparatus, device, medium, and product for determining a server's Internet Protocol address provided in the embodiments of this application are merely examples, and such methods, apparatus, devices, media, and products may include more or less content.

[0039] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0040] The Pearson correlation coefficient is an indicator used to measure the strength of the linear relationship between two continuous variables. Its value ranges from -1 to 1, where 1 indicates a perfect positive correlation (an increase in one variable leads to a linear increase in the other), -1 indicates a perfect negative correlation (an increase in one variable leads to a linear decrease in the other), and 0 indicates no linear relationship between the two variables. It is calculated by dividing the product of the covariance of the two variables by their respective standard deviations.

[0041] Attention mechanisms are a way of mimicking the allocation of human cognitive resources, allowing neural networks to dynamically focus on the parts most relevant to the current task when processing information. It assigns higher attention to key information and suppresses secondary information by calculating importance weights for different parts of the input data. This mechanism enables models to filter valuable content from large amounts of information, effectively improving performance in processing long sequences, complex contexts, and multimodal data.

[0042] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0043] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0044] To clearly understand the technical solution of this application, we will first provide a detailed description of the existing technical solutions. Ensuring that every access is directed to the appropriate server directly affects the efficiency of information transmission and the quality of service. Therefore, accurately determining the server address is of paramount importance.

[0045] In existing technologies, when a user initiates a request, the resolver sequentially queries authoritative servers such as the root domain and top-level domain to obtain the server address corresponding to the domain name. This process primarily relies on pre-configured static address mapping relationships to return the address determination result. Existing technologies often depend on limited and lagging system status information, failing to comprehensively consider the various dynamic factors affecting server Internet Protocol (IP) address determination. This results in the returned address not accurately reflecting real-time network conditions and resource capacity. Therefore, existing technologies suffer from low efficiency in determining server IP addresses.

[0046] Therefore, addressing the low efficiency of server Internet Protocol address determination in existing technologies, this research found that a dynamic decision-making mechanism can be constructed to replace the traditional static address mapping method. This mechanism integrates multi-dimensional dynamic factor analysis affecting traffic volume, future traffic volume prediction, and user demand matching. ① It can collect dynamic indicators related to network performance and server status in real time and use predictive models to estimate network traffic volume or service capacity in the near future. By combining these predictions with specific user requests, a suitable server can be selected from multiple candidate servers. ② A multi-dimensional feature system can be constructed. By analyzing historical request data, hidden correlations between different features and optimal server selection can be mined. When a new request arrives, these correlation rules are used to recommend a suitable server address. ③ A series of address selection strategies can be defined. These strategies can be based on various factors, such as directing requests to the server with the lowest cost, ensuring compliance with data localization regulations, prioritizing green energy data centers, or implementing specific traffic adjustments. When the parser receives a request, it no longer performs fixed-level queries but executes these programmable strategies to select a server address that meets the preset goals.

[0047] Specifically, it can make intelligent decisions based on dynamic network conditions and user needs. By analyzing various variables affecting service quality in real time and using predictive models to estimate future traffic volume trends, it comprehensively considers the user's specific service requirements and proactively selects the optimal target node from multiple servers, ultimately returning its Internet Protocol address. This ensures that the address selection result accurately reflects the real-time network conditions and server capacity, improving the accuracy of address determination.

[0048] This application discloses a method, apparatus, device, medium, and product for determining the Internet Protocol (IP) address of a server. By introducing a dynamic decision-making mechanism based on multivariate correlation analysis and traffic volume prediction, it effectively solves the problem of low address determination efficiency in existing technologies. The method first uses correlation coefficients to screen out key variables that significantly affect network request volume, then uses a prediction model to accurately predict future traffic load, and finally combines user needs with the prediction results to achieve intelligent selection of service nodes. This design breaks through the limitations of traditional reliance on static address mapping. By integrating multi-dimensional dynamic factors, the returned server address accurately reflects the real-time network status and resource carrying capacity, improving the accuracy of address determination and system response efficiency.

[0049] Based on the above-mentioned inventive discovery, the technical solution of this application is proposed.

[0050] The following describes the application scenarios of the method for determining the server Internet Protocol address provided in the embodiments of the present invention. Figure 1This is a schematic diagram illustrating an application scenario for the method of determining the server's Internet Protocol address provided in an embodiment of this application. For example... Figure 1 As shown, this application scenario includes a resolver 101, a client 102, and multiple servers 103. The client 102 sends a service domain name and user requirements to the resolver 101. The resolver 101 performs a cached query based on the service domain name to obtain the query result. Responding to the query result as the first result, the resolver 101 calculates the correlation coefficient between any two variables from a set of preset variables. It then identifies the two variables with correlation coefficients greater than a preset threshold as the first variables. The resolver 101 obtains the data corresponding to each first variable and inputs this data into a preset traffic volume prediction model to obtain the traffic volume. Based on the user requirements and traffic volume, the resolver 101 filters the multiple servers to obtain a target server 1031. The target server 1031 sends its Internet Protocol address (IPA) to the resolver 101, which then sends the IPA of the target server to the client 102.

[0051] The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0052] Figure 2 A flowchart illustrating the method for determining the Internet Protocol address of a server provided in this application embodiment. Figure One .like Figure 2 As shown, in this embodiment, the execution entity of this invention is a parser. Therefore, the method for determining the server's Internet Protocol address provided in this embodiment includes the following steps:

[0053] S201, Receive the service domain name and user request sent by the user terminal; wherein, the user request is used to represent the user terminal's requirements for the server.

[0054] Specifically, the client application can encapsulate the service domain name and the user's specific requirements for the server, such as response speed and service type, into request information, which is then transmitted over the network to the resolver. The resolver receives the request information through a preset communication interface and extracts the service domain name and user requirements. This step provides basic information for the subsequent address determination process, allowing the resolver to clearly understand the service object that the user needs to access and the user's specific requirements for the server. This provides a basis for subsequent operations such as cache lookup, variable analysis, and server filtering, ensuring that the final determined server address matches the user's actual needs.

[0055] The service domain name can be entered by the user in the browser. After the user enters the service domain name, such as www.example.com and presses Enter, the system will send a query request to the Domain Name System Resolver (DNS).

[0056] User requirements refer to the quantitative indicators and parameters that users pre-set to screen servers based on their own access experience and service reliability requirements. These include three key thresholds: first, the distance threshold, which is the maximum network distance between the user and the server that the user can accept; second, the health threshold, which is the minimum operational health standard that the user requires the server to meet; and third, the load threshold, which is the maximum current load level of the server that the user can accept.

[0057] S202. Perform a cache query based on the service domain name to obtain the query result; wherein, the query result includes a first result, which indicates that the resolver has not cached the Internet Protocol address corresponding to the service domain name, or that the Internet Protocol address has expired.

[0058] Specifically, the resolver can search its own preset cache space to see if the corresponding Internet Protocol address is stored based on the received service domain name. At the same time, it checks the validity status of the address. If a corresponding address that has not expired exists, a corresponding query result is generated. If no address is stored or the address has expired, a first result is generated. This step is used to prioritize the use of cached information to quickly respond to requests, reduce unnecessary subsequent processing steps, improve address determination efficiency, and trigger subsequent dynamic analysis mechanisms when the cache is invalid to ensure the accuracy of address determination.

[0059] S203. In response to the query result being the first result, calculate the correlation coefficient between any two variables among a set of preset variables, and determine the two variables corresponding to the correlation coefficients that are greater than the preset coefficient threshold as the first variables; where the set of variables refers to variables that affect the traffic volume.

[0060] Specifically, after the parser confirms that the query result is the first result, it first retrieves multiple preset variables that have an impact on call volume and their basic information. Then, it analyzes the degree of correlation between any two variables through a preset calculation method to obtain the correlation coefficient. Subsequently, it compares the obtained correlation coefficient with a preset coefficient threshold and determines the two corresponding variables with a correlation coefficient greater than the threshold as the first variable. This step is used to screen out key variables that have a significant effect on subsequent call volume prediction from the variables that affect call volume, eliminate the interference of weakly correlated or irrelevant variables, provide accurate and effective input basis for subsequent call volume prediction models, and ensure the reliability of call volume prediction results.

[0061] The pre-defined variables refer to dynamic variables that are potentially correlated with call volume, selected based on historical data analysis of call volume fluctuation patterns. These include, but are not limited to, time-dimensional variables, network status-dimensional variables, server-related variables, and user attribute-dimensional variables. The selection of these pre-defined variables is based on the core principle of "potentially having a significant impact on call volume," perfectly aligning with the logic of analyzing "variables affecting call volume" using Pearson correlation coefficients later in the text. Calculating the correlation coefficient between any two pre-defined variables is precisely to further filter out the first variable from the aforementioned multi-dimensional variables, indicating a stronger correlation with call volume—that is, a correlation coefficient greater than the pre-defined threshold. This avoids ambiguity in variable definitions that could lead to a disconnect from the subsequent Pearson correlation coefficient analysis, ensuring the continuity and consistency of the entire variable selection and call volume prediction process. This provides a clear and analytically tailored variable foundation for accurate future call volume prediction.

[0062] S204. Obtain the data corresponding to each first variable, and input the data corresponding to each first variable into the preset traffic volume prediction model to obtain the traffic volume; wherein, the traffic volume is used to represent the number of network requests made by the user terminal in a preset time period in the future.

[0063] Specifically, the parser can retrieve valid data corresponding to each first variable from a preset data source, such as a database storing real-time operating information and historical data of each first variable, or a related network status acquisition module or server monitoring unit. At the same time, the retrieved data is checked for integrity to eliminate abnormal information. Then, the checked data of each first variable is organized according to a preset format specification. The organized data is then input into a traffic prediction model that has been trained and optimized using historical traffic data. The model processes the input data according to its built-in analysis logic and finally generates the corresponding traffic volume. This step is used to accurately obtain valid data of key variables and use professional models to calculate the network request volume of users in the future. This provides a core reference for selecting servers based on user needs and ensures that the selected servers can effectively bear the future network load.

[0064] The call volume prediction model can be a deep learning network prediction model, which consists of two parts: Pearson correlation analysis is mainly responsible for selecting appropriate input variables, and the TPA-LSTM neural network model is mainly responsible for call volume prediction.

[0065] The Pearson correlation coefficient primarily explains the correlation between two features; its absolute value determines the strength of the correlation between the two features. The formula for calculating the Pearson correlation coefficient between two features can be expressed as:

[0066]

[0067] in, Let X be the correlation coefficient, Y be the features, and E be the expected value of the calculated value.

[0068] The degree of correlation between two features is related to the absolute value of the correlation coefficient. The larger the absolute value, the stronger the correlation. If the value is greater than 0, it indicates that the two variables are positively correlated; if it is less than 0, it indicates that they are negatively correlated; if it is zero, it indicates that the two variables are unrelated. The correlation coefficient can be represented as follows:

[0069] Table 1. Correlation Coefficient Level Table

[0070]

[0071] TPA-LSTM (Temporal Pattern Attention LSTM) is a time series forecasting model that is mainly used to solve multivariate time series forecasting problems. It introduces an attention mechanism to capture the relationship between variables over time, rather than simply using the historical information of all variables.

[0072] Figure 3 This is a diagram of the TPA-LSTM neural network model provided in the embodiments of this application. Figure 3 In the middle, h t Let H represent the hidden states of a Recurrent Neural Network (RNN) at time step t. It has k one-dimensional Convolutional Neural Network (CNN) filters of length w, represented by rectangles of different colors. Each filter convolves m hidden state features to obtain a matrix H. C It contains m rows and k columns. Then, the scoring function compares the current hidden state h. t To calculate H for each row C The weights are then normalized, and H is assigned a weight. C The rows are summed according to their respective weights to generate V. t Finally, V t h t And perform matrix multiplication to generate This is used to establish the final predicted value.

[0073] Temporal pattern detection uses CNNs, applying CNN filters to the row vectors of variable features, for example, with k filters C. i ∈R 1×T T is the maximum length; if not specified, let T = w. The convolution operation yields H. C ∈R n×k Hi，jC The convolution value between the i-th row vector and the j-th filter is represented by the following formula:

[0074]

[0075] in, This represents the convolution value obtained by performing a convolution operation between the eigenvector of the i-th variable and the convolution filter of the j-th variable. The superscript c indicates "convolution", and w is the length of the convolution filter. For the index of the summation operation, This indicates the position of the eigenvector of the i-th variable. The element value at that position, This represents the element value of the j-th convolutional filter at position T, where T is the time length.

[0076] The formula for calculating the scoring function is:

[0077]

[0078] in, Let i be the feature vector obtained by the convolution operation. This is the weight matrix. This is the hidden state vector.

[0079] Note the weights:

[0080]

[0081] in, To be mindful of the weights, use a sigmoid activation function instead of softmax.

[0082] H C row vectors are used Weighting yields the context vector. , The calculation formula is:

[0083]

[0084] Then and Combining these, we obtain the final prediction formula:

[0085]

[0086] in, For call volume forecast results, It is used for The weight matrix for linear transformation. For the hidden state vector, Used for The weight matrix for linear transformation.

[0087] Recurrent Neural Networks:

[0088] Given an information sequence {x1, x2, ..., xt}, where RNNs typically define a recursive function F to calculate the feature matrix at each time step t. , The formula is:

[0089]

[0090] in, Let F be the hidden state vector, and F be the recursive function. For time step The hidden state vector at time, The input vector at time step t,

[0091] The implementation of the recursive function F is determined by the type of RNN unit used. LSTM is widely used, and it has a recurrent function, which can be expressed as:

[0092]

[0093] in, This represents the cell state at time step t. For time step The cell state. This formula is the loop function form of LSTM (different from ordinary RNN), except for the hidden state. It also introduced cell state. It achieves precise control over long-term memory through complex gating logic.

[0094] Complex gating logic can be represented as:

[0095]

[0096] in, It is the output of the input gate at time step t. It is the input vector The weight matrix of the input gate, The hidden state of the previous moment The weight matrix to the input gate, For time step The hidden state vector. This formula controls how much of the current input can enter the cell state. The sigmoid activation function makes the output between 0 and 1, achieving the gating on / off effect.

[0097]

[0098] in, It is the output of the forget gate at time step t. It is the input vector The weight matrix of the forget gate, The hidden state of the previous moment The weight matrix to the input gate. This formula controls how much information in the cell state is forgotten, and also uses a sigmoid function to achieve 0-1 gating.

[0099]

[0100] in, It is the output of the output gate at time step t. It is the input vector The weight matrix of the output gate, The hidden state of the previous moment The weight matrix to the output gate. This formula controls how much information from the cell state can be output to the hidden state; it's the switch for the LSTM output.

[0101]

[0102] in, This represents the cell state at time step t. For time step The state of cells, The output of the input gate at time step t. For input vectors Weight matrix to candidate cell state Hidden state in the previous moment The weight matrix for candidate cell states. This formula is the core of LSTM's long-term memory; the first part filters cell states from the previous time step using a forgetting gate. The latter part filters the current candidate cell states through an input gate, and the two are added together to obtain the cell state at the current time step.

[0103]

[0104] in, For the hidden state vector, It is the output of the output gate at time step t. Let be the cell state at time step t. This formula filters the cell states through an output gate to obtain the hidden state at the current time step. This serves as the final output of the LSTM.

[0105] In methods for determining the Internet Protocol address of a server, if it is necessary to predict future traffic volume to optimize server selection, an LSTM model can be used to process the time series data of traffic volume. Cell state, as the core mechanism of LSTM to capture long-term dependencies, can effectively learn the historical trends and periodicity of traffic volume, improve prediction accuracy, and accurate traffic volume prediction can help adjust the thresholds such as distance, health, and load of server selection, thereby accurately determining the Internet Protocol address of the target server and achieving optimized allocation of service resources.

[0106] Loss function:

[0107] During model training, the Adaptive Moment Estimation (Adam) optimization algorithm is used to update the weight and bias matrices of neurons to find the minimum value of the loss function, which is expressed as the mean squared error function:

[0108]

[0109] Where Floss represents the mean squared error loss function, and n is the number of samples. Let i be the actual value of the i-th sample. Let be the predicted value for the i-th sample.

[0110] S205. Based on user needs and call volume, filter multiple servers to obtain the target server; where the target server refers to the server among multiple servers that meets user needs and call volume.

[0111] Specifically, the parser first breaks down user needs into specific evaluation dimensions, such as requirements for service response speed, the type of service required, and server resource configuration requirements. Then, it obtains the current operating status information of multiple servers, including current load, remaining available resources, and historical performance in handling similar requests. Subsequently, combined with predicted traffic volume, it evaluates each server in the future preset time period to determine whether it can both meet the various dimensions of user needs and stably handle the network requests corresponding to that traffic volume. Servers that simultaneously meet both conditions are selected to determine the target server. This step ensures that the final selected server matches the user's actual usage needs, preventing access problems caused by unsuitable service capabilities, and effectively handles future network request loads, avoiding service interruptions due to exceeding the server's capacity limit. This provides a guarantee for subsequent users to obtain accurate addresses and access the system smoothly.

[0112] S206. Receive the Internet Protocol address sent by the target server and send the Internet Protocol address of the target server to the user terminal, which is used by the user terminal to access the website based on the Internet Protocol address of the target server.

[0113] Specifically, the resolver can receive the Internet Protocol address (IPA) sent by the target server through a pre-established dedicated communication link or interface. During the reception process, the address is simultaneously validated for format and validity. Once the address is confirmed to be correct and usable for access, it is sent back to the user through the communication channel corresponding to the initial request sent by the user. A simple address availability message can also be attached. This step is used to accurately transmit the target server address, which has been selected through multiple rounds of screening and meets both user needs and call volume capacity, to the user. This provides the correct connection direction for the user to subsequently initiate website access, completing the closed loop of the entire server IPA address determination process. This ensures that users can access the required services smoothly and stably, avoiding access failures or poor user experience due to incorrect or inappropriate addresses.

[0114] This embodiment provides a method for determining the Internet Protocol (IP) address of a server. By introducing a dynamic decision-making mechanism based on multivariate correlation analysis and traffic volume prediction, it effectively solves the problem of low efficiency in address determination in existing technologies. This method first uses correlation coefficients to screen out key variables that significantly affect network request volume, then uses a predictive model to accurately estimate the traffic load in future time periods, and finally combines user needs with the prediction results to achieve intelligent selection of service nodes. This design breaks through the limitations of traditional reliance on static address mapping. By integrating multi-dimensional dynamic factors, the returned server address can accurately reflect the real-time network status and resource carrying capacity, improving the accuracy of address determination and system response efficiency.

[0115] In one possible design, S205 filters multiple servers based on user demand and call volume to obtain the target server, including:

[0116] S2051. Iteratively filter multiple servers to obtain multiple authoritative servers; where multiple authoritative servers refer to the servers that resolve the service domain name and provide the resolution results among multiple servers.

[0117] Specifically, the resolver can first set filtering conditions related to the resolution of the service domain name, such as whether the server has the authority to resolve the service domain name and whether it stores the resolution records for the service domain name. Then, it can perform an initial screening of multiple servers according to the preset filtering logic, excluding servers that obviously do not meet the basic resolution conditions. After that, it can perform multiple rounds of verification on the remaining servers, such as checking the validity of their resolution qualifications and the success rate of resolving the service domain name in history, gradually narrowing down the scope. Finally, the remaining servers are the multiple authoritative servers. This step is used to accurately select servers from many servers that are capable of resolving the current service domain name and providing results, reducing the number of candidates in subsequent screenings, improving screening efficiency, and ensuring that subsequent screening based on user needs and traffic volume is carried out on servers with core resolution capabilities, laying the foundation for the accurate determination of the target server.

[0118] S2052. Based on user needs and call volume, iteratively filter multiple authoritative servers to obtain the target server.

[0119] Specifically, the resolver can first refine user needs into specific screening criteria, such as service response speed requirements and the types of resources required. Combined with the predicted traffic volume, the load standards that the server needs to handle are set. Then, multiple authoritative servers are screened in the first round to exclude servers that obviously do not meet the user's core needs or cannot handle basic traffic volume. After that, for the remaining servers, their stability in meeting user needs under different load scenarios is further verified. For example, their response performance when handling similar traffic volumes in the past is checked, and whether the resource reserves are sufficient. After multiple rounds of progressively strict screening, the target server that meets all the conditions is finally determined. This step is used to accurately find servers among authoritative servers with domain name resolution capabilities that not only meet the user's actual needs but can also stably handle future network request loads, ensuring that the screening results are more targeted and reliable.

[0120] The technical effect of this solution in this embodiment is that, by establishing a hierarchical filtering mechanism, precise load control is achieved while ensuring the correctness of service domain name resolution. This method first iteratively filters and identifies server clusters capable of providing authoritative resolution results. Then, based on user needs and predicted traffic volume, it performs a secondary optimization and filtering of this cluster. This approach inherits the hierarchical verification reliability of traditional domain name systems while incorporating dynamic load factors, ultimately ensuring that the returned server addresses possess both resolution authority and service capacity adaptability.

[0121] In one possible design, the service domain name includes the hostname, main domain, and top-level domain. S2051 iteratively filters multiple servers to obtain multiple authoritative servers, including:

[0122] S20511. Filter multiple servers based on the top-level domain to obtain multiple first servers; where multiple first servers refer to servers that match the top-level domain among multiple servers.

[0123] Specifically, the resolver can first extract the top-level domain from the service domain, and then set matching rules based on the top-level domain. For example, it can check whether the server stores the associated record of the top-level domain, or whether the top-level domain is included in its own identification information. Then, it can compare multiple servers one by one according to the rules, and filter out the servers that meet the matching conditions as multiple first servers. This step is used to lock in the candidate objects corresponding to the top-level domain in the service domain from many servers in the initial stage of iterative filtering, narrowing the scope of subsequent filtering, providing a basis for further filtering based on the main domain and hostname, ensuring that the filtering process gradually focuses and improving the overall filtering efficiency.

[0124] In this context, "multiple first-level servers" specifically refers to those servers configured to manage and resolve top-level domains, such as ".com" or ".net". "Matching with the top-level domain" means that these servers are authorized within the global domain name system to provide authoritative responses to all domain query requests under that top-level domain. This filtering step aims to identify the key server nodes that hold a top-level domain management position within the domain name hierarchy from a vast number of servers, laying the foundation for subsequent hierarchical resolution.

[0125] S20512. Filter multiple first servers based on the main domain name to obtain multiple second servers; where multiple second servers refer to servers among multiple first servers that match the main domain name.

[0126] Specifically, the resolver can extract the main domain from the service domain, and then formulate matching criteria based on the main domain. For example, it can check whether multiple first servers have the resolution qualifications for the main domain and whether they store the associated resolution information of the main domain. Then, it compares the multiple first servers one by one according to the criteria, and selects the servers that meet the main domain matching conditions as multiple second servers. This step is used to further narrow down the candidate range based on hostname filtering, so that the filtering objects are more focused on the servers corresponding to the main domain in the service domain. This provides a more accurate candidate group for the final filtering based on the top-level domain, ensuring that the iterative filtering process is progressive and improving the accuracy and efficiency of authoritative server filtering.

[0127] In this context, "multiple secondary servers" refers to servers further identified from the selected primary servers, authorized to manage and resolve specific main domain names, such as "example.com". "Matching with the main domain" means that these servers are formally appointed as authoritative data sources for that main domain at the Domain Name System (DNS) level, capable of providing final, authoritative resolution results for queries on themselves and their subdomains (hostnames). This step precisely narrows the resolution target from a broad range of top-level domains to a set of servers with direct jurisdiction over the main domain, thus completing a crucial preparation before obtaining the final IP address.

[0128] S20513. Filter multiple secondary servers based on hostname to obtain multiple authoritative servers; where multiple authoritative servers refer to servers among multiple secondary servers that match the hostname.

[0129] Specifically, the resolver can extract the hostname from the service domain name, and then set matching conditions based on the hostname. For example, it can check whether multiple secondary servers have the resolution permissions for the hostname, whether they store the associated resolution records for the hostname, etc. Then, it compares the multiple secondary servers one by one according to the conditions, and selects the servers that meet the hostname matching requirements as multiple authoritative servers. This step is used to complete the final focusing based on the hostname and main domain name filtering, ensuring that the selected authoritative servers match the hostname of the service domain name and have the ability to fully resolve the entire service domain name. This provides accurate and qualified candidates for subsequent selection of target servers based on user needs and traffic volume, ensuring the accuracy and effectiveness of the resolution process.

[0130] For example, a local Domain Name System (DNS) resolver can look up the authoritative DNS server responsible for example.com based on the DNS hierarchy: root → .com → example.com.

[0131] In this context, "authoritative servers" refers to the servers ultimately confirmed from among the multiple secondary servers responsible for the primary domain name to provide direct and authoritative resolution for the complete hostname, such as "www.example.com". "Matching the hostname" means that these servers contain resource records, such as IP addresses, corresponding to that specific hostname in their stored domain name resolution records. These servers are the ultimate authoritative data source capable of responding to hostname query requests, and the Internet Protocol addresses they return will be directly used by users to access the website.

[0132] The technical effect of this solution in this embodiment is that by constructing a hierarchical domain name matching mechanism, the traditional domain name system architecture is organically integrated into the dynamic address decision-making process. This method filters according to the hierarchical structure of hostname, main domain, and top-level domain, ensuring that the final set of authoritative servers conforms to the Internet domain name resolution specifications, and laying an accurate and reliable candidate foundation for subsequent intelligent filtering based on real-time load.

[0133] In one possible design, user requirements include distance threshold, health threshold, and load threshold. S2052, based on user requirements and call volume, iteratively filters multiple authoritative servers to obtain target servers, including:

[0134] S20521. Obtain the address of the user terminal, and filter multiple authoritative servers based on the address of the user terminal to obtain multiple third-party servers; wherein, multiple third-party servers refer to servers among multiple authoritative servers whose distance from the address of the user terminal is less than a distance threshold.

[0135] Specifically, the parser can extract the user's address from the request information sent by the user, or obtain the address through communication with the user. Then, it combines the address information of multiple authoritative servers to calculate the distance between each authoritative server and the user's address. The calculated distance is then compared with the distance threshold in the user's requirements. Authoritative servers with a distance less than the threshold are designated as multiple third servers. This step is used to prioritize authoritative servers that are closer to the user, reducing access delays that may be caused by excessive distance. This lays the foundation for subsequent selection of target servers that meet user requirements and can respond efficiently, thus improving the smoothness of user access.

[0136] S20522. Obtain the health status of multiple third servers, and filter the multiple third servers according to the health status of multiple third servers to obtain multiple fourth servers; wherein, multiple fourth servers refer to servers among multiple third servers whose health status is greater than the health status threshold.

[0137] Specifically, the parser can establish connections with multiple third-party servers through a preset status query mechanism to obtain the health information of each server. This information can cover the operating status of hardware devices, the stability of software services, the frequency of recent failures, etc. Then, the health of each third-party server is compared with the health threshold in the user's requirements. Third-party servers whose health exceeds the threshold are designated as multiple fourth servers. This step is used to ensure that the selected servers are in good operating condition, avoid service interruptions or abnormal responses due to poor server health, provide stable and reliable candidates for further screening, and ensure the continuity of the user's access process.

[0138] S20523. Obtain the load of multiple fourth servers, and filter the multiple fourth servers according to the load of multiple fourth servers to obtain multiple fifth servers; wherein, multiple fifth servers refer to servers among multiple fourth servers whose load is less than the load threshold.

[0139] Specifically, the parser can obtain the current load information of each server through a real-time status interaction mechanism with multiple fourth servers. This information may include the number of network requests being processed, resource usage, etc. Then, the load of each fourth server is compared with the load threshold in the user's requirements. Fourth servers with loads below the threshold are selected as multiple fifth servers. This step is used to ensure that the current workload of the selected servers is within a reasonable range and that there are sufficient resource reserves to handle subsequent requests, avoiding service performance degradation due to excessive load. This provides stable candidate servers for subsequent selection of target servers based on traffic volume processing limits.

[0140] S20524. Obtain the traffic volume processing limits of multiple fifth servers, and filter the multiple fifth servers according to the traffic volume processing limits and traffic volume to obtain the target server; wherein, each traffic volume processing limit is used to represent the maximum number of network requests processed by each fifth server per unit time.

[0141] Specifically, the parser can obtain the traffic handling limit of each fifth server by interacting with multiple fifth servers. This limit reflects the maximum number of network requests that each server can handle per unit time. Then, the traffic handling limit of each fifth server is compared with the previously predicted traffic volume, and the fifth servers with a traffic handling limit not less than the traffic volume are selected as target servers. This step is used to ensure that the finally selected servers have sufficient processing capacity to cope with the network request volume in the future preset time period. It is the final check based on distance, health, and load screening, avoiding the inability of the server to handle the predicted traffic volume due to insufficient server processing capacity, thereby ensuring the stability and smoothness of user access.

[0142] The technical effect of this solution in this embodiment is that it achieves precise optimization of server selection by constructing a multi-dimensional dynamic filtering mechanism. This method uses multiple thresholds, such as user distance, server health, real-time load, and call volume processing capacity, to progressively filter candidate servers, ultimately identifying the optimal target server that meets both user performance requirements and can handle expected future traffic, thus improving the rationality of service allocation and system stability.

[0143] In one possible design, S206, sending the target server's Internet Protocol address to the user terminal includes:

[0144] S2061. Based on the Internet Protocol address of the target server, send a simulated user access command to the target server.

[0145] Specifically, the parser can generate simulated instructions similar to real user access operations by referring to the typical access behavior characteristics of the user terminal. These instructions may include connection requests, basic data exchanges, etc. Then, based on the Internet Protocol address of the target server, the simulated user access instructions are sent to the target server through a pre-established communication path. This step is used to verify in advance whether the target server can receive and respond to the access request normally, and to check the situation where the address is valid but the server cannot provide services normally, so as to provide reliability support for sending the address to the user terminal in the future.

[0146] S2062. Receive the simulated access result sent by the target server; wherein, the simulated access result includes successful simulated access.

[0147] Specifically, after sending a simulated access command, the parser can maintain a communication link with the target server in a ready-to-receive state. When the target server processes the simulated command and returns a result, the parser receives the corresponding simulated access result through this communication link and identifies whether it contains information indicating a successful simulated access. This step is used to confirm that the target server can indeed respond to the access request normally, verify its actual service capabilities, and provide a reliable basis for subsequently sending the address to the user, thus avoiding user access failure due to the server being able to respond even though the address is valid.

[0148] Among them, simulated access instructions can refer to HTTP request instructions that simulate the regular website access behavior of users. The composition of these instructions must closely match the actual access scenario of users and include core elements consistent with real website access: such as specifying the service port corresponding to the Internet Protocol address of the target server, carrying request headers that conform to the HTTP specification, and initiating access requests for the server's default homepage or preset basic resources. The instruction format is consistent with the HTTP request format of users initiating website access through a browser, ensuring that simulated access behavior can truly reflect the interaction logic of users' actual access.

[0149] The criteria for determining "successful simulated access" must match the aforementioned command type, specifically including three core conditions: First, the simulated access command can successfully establish a TCP connection with the target server without connection timeouts, connection rejections, or other exceptions; second, the server returns a response conforming to the HTTP protocol specification, and the response status code is a 2xx class; third, parsing the server's returned response data allows the acquisition of the preset basic valid content. Only when all three conditions are met simultaneously can it be determined as "successful simulated access."

[0150] S2063. In response to the simulation access result being successful, the Internet Protocol address of the target server is sent to the user terminal.

[0151] Specifically, after confirming that the simulated access result is successful, the parser can first perform a final simple validity check on the Internet Protocol address of the target server to ensure that there are no temporary anomalies in the address. Then, it selects the same communication channel as when the user initially sent the address query request and transmits the Internet Protocol address to the user. This step is used to complete the final reliability check before delivering the address to the user, ensuring that the address obtained by the user can be used directly for smooth access and avoiding access failures caused by temporary server failures after the initial screening. At the same time, matching the original communication channel ensures the stability of data transmission, and finally completes the closed loop of the entire address determination and delivery process.

[0152] The technical effect of this solution in this embodiment is that it improves the reliability of address resolution results by introducing a service availability pre-verification mechanism. Before returning the server address to the user, this method sends a simulated access command to the target server to verify connectivity, ensuring that only available addresses that can successfully respond are delivered to the user. This pre-verification step avoids access failures caused by momentary server malfunctions or network outages from the source, improving the end-user's access success experience.

[0153] Figure 4 A flowchart illustrating the method for determining the Internet Protocol address of a server provided in this application embodiment. Figure Two In this embodiment, in Figure 2 Based on the provided embodiments, the method for determining the server's Internet Protocol address is further explained. The method for determining the server's Internet Protocol address includes:

[0154] S401, Receive the service domain name and user request sent by the user terminal; wherein, the user request is used to represent the user terminal's requirements for the server.

[0155] S402. Perform a cache query based on the service domain name to obtain the query result; wherein, the query result includes a first result, which indicates that the resolver has not cached the Internet Protocol address corresponding to the service domain name, or that the Internet Protocol address has expired.

[0156] S401-S402 are similar to S201-S202, and will not be described again in this embodiment.

[0157] S403. In response to the query result being the second result, an address query is performed based on the service domain name to obtain the Internet Protocol address corresponding to the service domain name; wherein, the second result is used to indicate that the resolver has cached the Internet Protocol address corresponding to the service domain name, and the Internet Protocol address has not expired.

[0158] Specifically, after confirming that the query result is the second result, the resolver can directly retrieve the stored and valid Internet Protocol address from its own cache space based on the service domain name, without performing additional variable analysis or server filtering operations. This step is used to quickly complete the query process by leveraging the existing valid address in the cache, saving the subsequent complex dynamic analysis process, greatly shortening the address determination time, ensuring that the user can quickly obtain an available address and initiate access, and improving the response efficiency and user experience of the entire system.

[0159] S404. Send the Internet Protocol address corresponding to the service domain name to the user terminal, which is used to access the website based on the Internet Protocol address corresponding to the service domain name.

[0160] Specifically, the resolver can first perform a simple verification of the Internet Protocol address (IPA) corresponding to the service domain name obtained from the cache to confirm that it is still valid and has no risk of transmission anomalies. Then, through the same communication channel used when the user initially sent the service domain name and user request, the IPA is transmitted to the user. This step is used to quickly deliver the confirmed valid address to the user, allowing the user to directly obtain the address required for access and initiate website access without going through complex processes such as subsequent variable analysis and traffic prediction. This completes the closed loop of the entire address determination process and minimizes the time from when the user initiates a request to when they can access the website normally, effectively improving system response speed and user experience.

[0161] For example, the resolver can be a local DNS resolver. The local DNS resolver can check its own cache. If there is a cached access to the domain name and the Time To Live (TTL) has not expired, it can directly return the cached IP address and the process ends. If there is no cached access to the domain name or the TTL has expired, it needs to query the authoritative DNS server of the domain name and perform a recursive query.

[0162] S405. In response to the query result being the first result, calculate the correlation coefficient between any two variables among a set of preset variables, and determine the two variables corresponding to the correlation coefficients that are greater than the preset coefficient threshold as the first variables; where the set of variables refers to variables that affect the traffic volume.

[0163] S406. Obtain the data corresponding to each first variable, and input the data corresponding to each first variable into the preset traffic volume prediction model to obtain the traffic volume; wherein, the traffic volume is used to represent the number of network requests made by the user terminal in a preset time period in the future.

[0164] S407. Based on user needs and call volume, filter multiple servers to obtain the target server; where the target server refers to the server among multiple servers that meets user needs and call volume.

[0165] S408: Receive the Internet Protocol address sent by the target server and send the target server's Internet Protocol address to the user terminal, which uses the target server's Internet Protocol address to access the website.

[0166] S405-S408 are similar to S203-S206, and will not be described again in this embodiment.

[0167] The technical effect of this solution in this embodiment is that it improves the overall efficiency of the address resolution system by establishing a fast response mechanism in cache hit scenarios. When the resolver detects a valid cache record, it directly returns the cached address result, avoiding the repeated execution of complex traffic prediction and server filtering processes. This dual-path processing mechanism reduces the response latency of regular requests while ensuring the accuracy of dynamic decision-making, achieving a balance between system resource optimization and user experience improvement.

[0168] Figure 5 A flowchart illustrating the method for determining the Internet Protocol address of a server provided in this application embodiment. Figure Three In this embodiment, in Figure 2 Based on the provided embodiments, the method for determining the server's Internet Protocol address is further explained. The method for determining the server's Internet Protocol address includes:

[0169] S501, Receive the service domain name and user request sent by the user terminal; wherein, the user request is used to represent the user terminal's requirements for the server.

[0170] S502. Perform a cache query based on the service domain name to obtain the query result; wherein, the query result includes a first result, which indicates that the resolver has not cached the Internet Protocol address corresponding to the service domain name, or that the Internet Protocol address has expired.

[0171] S503. In response to the query result being the first result, calculate the correlation coefficient between any two variables among a preset set of multiple variables, and determine the two variables corresponding to the correlation coefficients that are greater than the preset coefficient threshold as the first variables; where multiple variables refer to variables that affect traffic volume.

[0172] S504. Obtain the data corresponding to each first variable, and input the data corresponding to each first variable into the preset traffic volume prediction model to obtain the traffic volume; wherein, the traffic volume is used to represent the number of network requests made by the user terminal in a preset time period in the future.

[0173] S505. Based on user needs and call volume, filter multiple servers to obtain the target server; where the target server refers to the server among multiple servers that meets user needs and call volume.

[0174] S506. Receive the Internet Protocol address sent by the target server and send the target server's Internet Protocol address to the user terminal, which uses the target server's Internet Protocol address to access the website.

[0175] S501-S506 are similar to S201-S206, and will not be described again in this embodiment.

[0176] S507. Receive the Time to Live (TTL) sent by the target server and store the Internet Protocol address and TTL sent by the target server; wherein, the TTL is used to represent the validity period of the Internet Protocol address sent by the target server on the resolver.

[0177] Specifically, the resolver can receive the Time-to-Live (TTL) sent by the target server through a pre-agreed communication interface. It then associates the TTL with the corresponding Internet Protocol address of the target server, marking the time points at which both were received, and stores them together in the resolver's dedicated cache space. This step provides cache support for subsequent address queries for the same service domain name. When a request for the same service domain name is received again, the stored address can be directly retrieved, and its validity can be determined based on the TTL, eliminating the need to repeatedly perform complex processes such as variable analysis and traffic prediction. Furthermore, the TTL controls the cache's validity period, preventing the use of expired addresses and ensuring the efficiency and accuracy of subsequent address queries.

[0178] S508. In response to the deadline of the future preset time period, the call volume prediction model is updated according to the call volume to obtain the updated call volume prediction model.

[0179] Specifically, after the end time of a pre-set future time period, the parser first collects the actual call volume data that occurred during that time period, compares and analyzes it with the call volume predicted by the model, calculates the degree of deviation between the two, and then uses this actual call volume data as new training basis to adjust the parameter settings or calculation logic in the call volume prediction model, such as correcting the model's judgment weights on the degree of influence of each variable, thereby obtaining an updated call volume prediction model. This step is used to enable the call volume prediction model to continuously optimize according to the actual network request situation, adapt to the dynamic changes in network status, improve the accuracy of subsequent call volume prediction, provide a more reliable reference for subsequent server selection, and ensure the continuous and efficient operation of the entire address determination method.

[0180] The technical advantages of this solution in this embodiment are: by introducing dynamic lifetime management and a self-updating mechanism for the prediction model, the continuous optimization capability of the address determination system is effectively improved. This method synchronously caches the validity period of the target address when returning it, ensuring the timeliness of the resolution results and avoiding the risk of misjudgment caused by cache expiration. Simultaneously, the system can automatically update the prediction model based on actual call volume data after each prediction cycle, enabling subsequent decisions to continuously adapt to changes in the network environment, thus achieving self-evolution and long-term stability of the system performance.

[0181] In one possible design, S508 updates the traffic volume prediction model based on traffic volume to obtain an updated traffic volume prediction model, including:

[0182] S5081, Obtain the actual network request volume within a future preset time period.

[0183] Specifically, the parser can interact with the target server or a monitoring system that records network requests to collect the actual number of user-end network requests generated within a preset time period in the future. These numbers can cover information such as the number of requests at each moment in that time period and the total number of cumulative requests. This step is used to obtain real network request data, which provides a basis for subsequent comparison of predicted traffic volume with the actual situation and calculation of the deviation between the two. This provides an accurate basis for updating the traffic volume prediction model and ensures that the model can be optimized to fit the actual network conditions.

[0184] S5082. Calculate the network request volume deviation based on the call volume and the actual network request volume.

[0185] Specifically, the parser can first determine the previously predicted traffic volume and the actual network request volume collected within a preset future time period. Then, it can perform calculations on these two sets of data using preset methods, such as calculating the difference between the two or the deviation ratio based on the actual value, to obtain the network request volume deviation. This step is used to quantify the difference between the prediction result and the actual situation, providing a clear reference indicator for adjusting the traffic volume prediction model based on this difference. This ensures that the model update can accurately optimize the deviation, thereby improving the model's future prediction accuracy.

[0186] S5083. Based on the network request volume deviation, update the traffic volume prediction model to obtain the updated traffic volume prediction model.

[0187] Specifically, the parser first analyzes the specific circumstances of the network request volume deviation, including the magnitude of the deviation and possible causes, such as the overestimation or underestimation of the influence of certain variables. Then, based on the preset model adjustment rules, it modifies the parameter settings in the traffic volume prediction model according to the degree of deviation, such as adjusting the influence weight of each variable in the model calculation or optimizing the model's calculation logic, so that the model's prediction results are closer to the actual situation, thereby obtaining an updated traffic volume prediction model. This step is used to eliminate or reduce prediction deviation by specifically correcting the model, improve the model's accuracy in predicting future network request volume, provide a more reliable basis for subsequent server selection based on traffic volume, and ensure that the entire address determination process can continuously adapt to changes in network conditions.

[0188] The technical effect of this solution in this embodiment is that by establishing a feedback correction mechanism based on prediction deviation, the accuracy and adaptability of the traffic volume prediction model are improved. This method calculates the specific deviation value by comparing the predicted traffic volume with the actual network request volume, and uses this deviation as a basis for targeted optimization of the model. This allows the prediction model to continuously learn from historical errors and adjust its parameters, thereby narrowing the gap between the predicted value and the actual value, ensuring that the system maintains high-precision decision-making capabilities when facing dynamically changing network environments.

[0189] Figure 6 A flowchart illustrating the method for determining the Internet Protocol address of a server provided in this application embodiment. Figure Four In this embodiment, in Figure 2 Based on the provided embodiments, the method for determining the server's Internet Protocol address is further explained. The method for determining the server's Internet Protocol address includes:

[0190] S601. Obtain the address of the user terminal, and filter multiple authoritative servers based on the address of the user terminal to obtain multiple third-party servers; wherein, multiple third-party servers refer to servers among multiple authoritative servers whose distance from the address of the user terminal is less than a distance threshold.

[0191] S602. Obtain the health status of multiple third servers, and filter the multiple third servers according to the health status of multiple third servers to obtain multiple fourth servers; wherein, multiple fourth servers refer to servers among multiple third servers whose health status is greater than the health status threshold.

[0192] S603. Obtain the load of multiple fourth servers, and filter the multiple fourth servers according to the load of multiple fourth servers to obtain multiple fifth servers; wherein, multiple fifth servers refer to servers among multiple fourth servers whose load is less than the load threshold.

[0193] S604. Obtain the traffic processing limits of multiple fifth servers, and filter the multiple fifth servers according to the traffic processing limits and traffic volume to obtain the target server; wherein, each traffic processing limit is used to represent the maximum number of network requests processed by each fifth server per unit time.

[0194] S601-S604 are similar to S20521-S20524, and will not be described again in this embodiment.

[0195] S605, Obtain historical concurrent call volume; where historical concurrent call volume is the network request volume within a preset time period in the past.

[0196] Specifically, the parser can extract the network request volume within a past preset time period corresponding to the current future preset time period from a dedicated system that stores historical network request data. This data can cover information such as the total number of requests in the past time period and the distribution of requests in each time period. This step is used to provide historical reference data for the current traffic volume, so that the fluctuation range and direction of the traffic volume can be determined by comparing the two, and provide a basis for judging whether it is necessary to adjust the distance, health and load-related thresholds.

[0197] S606. Determine the fluctuation range and direction based on call volume and historical call volume for the same period.

[0198] Specifically, the parser can compare and analyze the current call volume with the extracted historical call volume for the same period. By using a preset analysis method, the degree of difference between the two can be determined, thereby determining the fluctuation range. At the same time, it can be determined whether the current call volume is higher or lower than the historical call volume for the same period, thereby determining the direction of fluctuation. This step is used to quantify the change in the current call volume compared with the historical period, providing specific fluctuation characteristics as a basis for subsequent judgment on whether the fluctuation is significant enough to require adjustment of distance, health, and load-related thresholds, ensuring that the threshold adjustment can fit the actual call volume change trend.

[0199] S607. In response to a fluctuation amplitude exceeding a preset fluctuation amplitude threshold, adjust the distance threshold, health threshold, and load threshold according to the fluctuation amplitude and direction to obtain the adjusted distance threshold, adjusted health threshold, and adjusted load threshold.

[0200] Specifically, after determining that the fluctuation amplitude is greater than a preset fluctuation amplitude threshold, the parser first judges whether the current call volume is increasing or decreasing compared to the same period in history based on the direction of the fluctuation. Then, it formulates adjustment rules based on the magnitude of the fluctuation amplitude: if the call volume is increasing, the distance threshold can be appropriately relaxed to include more candidate servers, the health threshold can be increased to ensure that the server is more stable, and the load threshold can be reduced to reserve more processing space; if the call volume is decreasing, the distance threshold can be tightened to prioritize closer servers, the health threshold can be appropriately reduced to increase the number of candidates, and the load threshold can be increased to make fuller use of server resources. The larger the fluctuation amplitude, the greater the adjustment of the thresholds. This results in three adjusted thresholds. This step is used to dynamically adapt the key thresholds for screening servers to significant fluctuations in call volume, ensuring that the subsequently screened servers can better match the actual situation of the current network requests, improving the flexibility and targeting of server screening, and ensuring the stable operation of the service.

[0201] The technical effect of this solution in this embodiment is that by introducing historical call volume as a reference benchmark, it is possible to accurately identify the fluctuation range and direction of the current call volume compared with the same period in the past. When the fluctuation range exceeds the preset threshold, the core threshold of server screening is dynamically adjusted, which makes the subsequent server screening process more in line with the actual call volume change requirements and improves the flexibility and adaptability of server screening.

[0202] This application also provides a system for determining the Internet Protocol (IP) address of a server. The system includes a resolver, a client, and multiple servers, including a target server.

[0203] The resolver receives the service domain name and user request sent by the user client. It performs a cached query based on the service domain name to obtain the query result. When the query result is the first result, it obtains information from multiple servers and iteratively filters the multiple servers based on the user request and predicted traffic volume to obtain the target server. It receives the Internet Protocol address (IPA) sent by the target server and sends it to the user client. It also receives the time-to-live (TTL) sent by the target server and stores the corresponding IPA and TTL. When the deadline of a preset future time period is reached, it updates the traffic volume prediction model based on the actual traffic volume. In response to the query result being the second result, it retrieves the IPA corresponding to the service domain name from the cache and sends it to the user client. Before sending the IPA to the user client, it sends a simulated access command to the target server, receives the simulated access result, and sends the address when the result is successful.

[0204] The user terminal sends the service domain name and user request to the resolver, receives the Internet Protocol address corresponding to the target server or service domain name sent by the resolver, and accesses the website according to the Internet Protocol address to obtain the required network service.

[0205] The target server is used to send its own Internet Protocol address and Time to Live (TTL) to the resolver, receive simulated access instructions sent by the resolver and return simulated access results, and also serve as the final node for user access, providing service support for user website access.

[0206] Figure 7 A schematic diagram of the structure of the device for determining the Internet Protocol address of a server provided in an embodiment of this application. Figure 7 As shown, the device for determining the Internet Protocol address of the server includes:

[0207] The first receiving module 701 is used to receive the service domain name and user request sent by the user terminal; wherein, the user request is used to represent the user terminal's requirements for the server.

[0208] The first query module 702 is used to perform a cache query based on the service domain name and obtain the query result; wherein, the query result includes a first result, which is used to indicate that the resolver has not cached the Internet Protocol address corresponding to the service domain name, or that the Internet Protocol address has expired.

[0209] The first calculation module 703 is used to calculate the correlation coefficient between any two variables among a preset set of multiple variables in response to the query result being the first result, and to determine the two variables corresponding to the correlation coefficients that are greater than the preset coefficient threshold as the first variables; wherein, the multiple variables refer to variables that affect the traffic volume.

[0210] The first acquisition module 704 is used to acquire the data corresponding to each first variable and input the data corresponding to each first variable into a preset traffic volume prediction model to obtain the traffic volume; wherein, the traffic volume is used to represent the number of network requests made by the user terminal in a preset time period in the future.

[0211] The first filtering module 705 is used to filter multiple servers based on user needs and call volume to obtain target servers; where the target server refers to the server among the multiple servers that meets the user needs and call volume.

[0212] The second receiving module 706 is used to receive the Internet Protocol address sent by the target server and send the Internet Protocol address of the target server to the user terminal, which is used to access the website based on the Internet Protocol address of the target server.

[0213] In one possible design, the device for determining the server's Internet Protocol address also includes:

[0214] The second query module is used to perform an address query based on the service domain name in response to the query result being the second result, and obtain the Internet Protocol address corresponding to the service domain name; wherein, the second result is used to indicate that the resolver has cached the Internet Protocol address corresponding to the service domain name, and the Internet Protocol address has not expired.

[0215] The first sending module is used to send the Internet Protocol address corresponding to the service domain name to the user terminal, which then uses the Internet Protocol address corresponding to the service domain name to access the website.

[0216] In one possible design, the first screening module 705 includes:

[0217] The first filtering unit is used to iteratively filter multiple servers to obtain multiple authoritative servers; among them, multiple authoritative servers refer to the servers that resolve the service domain name and provide the resolution results.

[0218] The second filtering unit is used to iteratively filter multiple authoritative servers based on user needs and call volume to obtain the target server.

[0219] In one possible design, the service domain name includes the hostname, the main domain, and the top-level domain. The first filtering unit includes:

[0220] The first filtering component is used to filter multiple servers based on the top-level domain name to obtain multiple first servers; where multiple first servers refer to servers that match the top-level domain name among multiple servers.

[0221] The second filtering component is used to filter multiple first servers based on the main domain name to obtain multiple second servers; where multiple second servers refer to servers among multiple first servers that match the main domain name.

[0222] The third filtering component is used to filter multiple secondary servers based on their hostnames to obtain multiple authoritative servers; where multiple authoritative servers refer to the servers among the multiple secondary servers that match the hostname.

[0223] In one possible design, user requirements include distance threshold, health threshold, and load threshold; the second filtering unit includes:

[0224] The fourth filtering component is used to obtain the user's address and filter multiple authoritative servers based on the user's address to obtain multiple third servers; where multiple third servers refer to servers among multiple authoritative servers whose distance from the user's address is less than a distance threshold.

[0225] The fifth filtering component is used to obtain the health status of multiple third servers and filter them based on their health status to obtain multiple fourth servers; where multiple fourth servers refer to servers among the multiple third servers whose health status is greater than the health status threshold.

[0226] The sixth filtering component is used to obtain the load of multiple fourth servers and filter them according to the load of multiple fourth servers to obtain multiple fifth servers; wherein, multiple fifth servers refer to servers among multiple fourth servers whose load is less than the load threshold.

[0227] The seventh filtering component is used to obtain the traffic processing limits of multiple fifth servers, and to filter the multiple fifth servers according to the traffic processing limits and traffic volume to obtain the target server; wherein, each traffic processing limit is used to represent the maximum number of network requests that each fifth server can process per unit time.

[0228] In one possible design, the device for determining the server's Internet Protocol address also includes:

[0229] The storage module is used to receive the Time-to-Live (TTL) sent by the target server and store the Internet Protocol (IP) address and TTL sent by the target server; wherein, the TTL is used to represent the validity period of the IP address sent by the target server on the resolver.

[0230] The update module is used to update the traffic volume prediction model based on the traffic volume in response to the deadline of a preset future time period, so as to obtain the updated traffic volume prediction model.

[0231] In one possible design, the update module includes:

[0232] The acquisition unit is used to acquire the actual number of network requests within a preset future time period.

[0233] The calculation unit is used to calculate the network request volume deviation based on the call volume and the actual network request volume.

[0234] The update unit is used to update the traffic volume prediction model based on the network request volume deviation, so as to obtain the updated traffic volume prediction model.

[0235] In one possible design, the second receiving module 706 includes:

[0236] The first sending unit is used to send a simulated user access instruction to the target server based on the target server's Internet Protocol address.

[0237] The receiving unit is used to receive the simulated access result sent by the target server; wherein the simulated access result includes a successful simulated access.

[0238] The second sending unit is used to send the Internet Protocol address of the target server to the user terminal in response to the simulation access result being successful.

[0239] The device for determining the server's Internet Protocol address provided in this embodiment can execute... Figure 2 , Figure 4 , Figure 5 , Figure 6 and Figure 7 The technical solution of an embodiment of a method for determining the Internet Protocol address of a server, as shown, has the same implementation principle and technical effects as... Figure 2 , Figure 4 , Figure 5 , Figure 6 and Figure 7 The embodiment of the method for determining the Internet Protocol address of a server shown is similar and will not be described in detail here.

[0240] Figure 8 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application. Figure 8 As shown, the electronic device 80 includes at least one processor 801 and a memory 802. The electronic device 80 also includes a communication component 803. The processor 801, memory 802, and communication component 803 are connected via a bus 804.

[0241] In a specific implementation, at least one processor 801 executes computer execution instructions stored in memory 802, causing at least one processor 801 to implement a method for determining a server Internet Protocol address as described in the above embodiment.

[0242] The specific implementation process of processor 801 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0243] In the above embodiments, it should be understood that the processor 801 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0244] The memory 802 may include high-speed RAM memory, and may also include non-volatile memory (NVM), such as at least one disk storage.

[0245] Bus 804 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Bus 804 can be divided into address bus, data bus, control bus, etc. For ease of illustration, the bus 804 in the accompanying drawings of this application is not limited to only one bus or one type of bus.

[0246] The above description of the functions implemented by electronic devices and main control devices has introduced the solutions provided by the embodiments of the present invention. It is understood that, in order to implement the above functions, the electronic device or main control device includes hardware structures and / or software modules corresponding to the execution of each function. By combining the units and algorithm steps of the various examples described in the embodiments of the present invention, the embodiments of the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the technical solutions of the embodiments of the present invention.

[0247] This application also provides a computer-readable storage medium storing computer-executable instructions. When executed by a processor, these instructions are used to implement a method for determining a server Internet Protocol (IP) address as described in the above embodiments. In the specific implementation of the aforementioned method for determining a server IP address, each module can be implemented as a processor.

[0248] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0249] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in application-specific integrated circuits (ASICs). Alternatively, the processor and the readable storage medium can exist as discrete components in an electronic device or a host device.

[0250] This application also provides a computer program product, including a computer program, which, when executed by a processor, is used to implement a method for determining a server Internet Protocol address as described in the above embodiments.

[0251] The computer program is stored in a readable storage medium, and at least one processor can read the computer program from the readable storage medium and execute the computer program to perform the scheme provided in any of the above embodiments.

[0252] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disk, or optical disk.

[0253] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it is readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. The above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for determining the Internet Protocol address of a server, characterized in that, A resolver applied to a system for determining the Internet Protocol (IP) address of a server, the system further comprising a user terminal and multiple servers, the method comprising: Receive the service domain name and user request sent by the user terminal; wherein, the user request is used to represent the user terminal's requirements for the server; A cache query is performed based on the service domain name to obtain the query result; wherein, the query result includes a first result, which indicates that the resolver has not cached the Internet Protocol address corresponding to the service domain name, or that the Internet Protocol address has expired; In response to the query result being the first result, the correlation coefficient between any two variables from a preset set of variables is calculated, and the two variables corresponding to the correlation coefficients greater than a preset threshold are determined as the first variables; wherein, the set of variables refers to variables that affect traffic volume; Obtain the data corresponding to each of the first variables, and input the data corresponding to each of the first variables into a preset traffic volume prediction model to obtain the traffic volume; wherein, the traffic volume is used to represent the number of network requests made by the user terminal in a preset time period in the future; The multiple servers are filtered according to the user needs and the call volume to obtain the target server; wherein, the target server refers to the server among the multiple servers that meets the user needs and the call volume; The system receives the Internet Protocol address (IPA) sent by the target server and sends the IPA of the target server to the user terminal, which is used to access the website based on the IPA of the target server.

2. The method for determining the Internet Protocol address of a server according to claim 1, characterized in that, The query result also includes a second result. After obtaining the query result by performing a cached query based on the service domain name, the query further includes: In response to the query result being the second result, an address query is performed based on the service domain name to obtain the Internet Protocol address corresponding to the service domain name; wherein, the second result is used to indicate that the resolver has cached the Internet Protocol address corresponding to the service domain name, and the Internet Protocol address has not expired; The Internet Protocol address corresponding to the service domain name is sent to the user terminal, which is used to access the website based on the Internet Protocol address corresponding to the service domain name.

3. The method for determining the Internet Protocol address of a server according to claim 1, characterized in that, The step of filtering the multiple servers based on the user demand and the call volume to obtain the target server includes: The multiple servers are iteratively filtered to obtain multiple authoritative servers; wherein, the multiple authoritative servers refer to the servers among the multiple servers that resolve the service domain name and provide the resolution results; The target server is obtained by iteratively filtering the multiple authoritative servers based on the user needs and the call volume.

4. The method for determining the Internet Protocol address of a server according to claim 3, characterized in that, The service domain name includes a hostname, a main domain name, and a top-level domain name. The iterative filtering of the multiple servers yields multiple authoritative servers, including: The multiple servers are filtered based on the top-level domain to obtain multiple first servers; wherein, the multiple first servers refer to the servers among the multiple servers that match the top-level domain; Based on the main domain name, the plurality of first servers are filtered to obtain a plurality of second servers; wherein, the plurality of second servers refer to the servers among the plurality of first servers that match the main domain name; The plurality of second servers are filtered based on the hostname to obtain the plurality of authoritative servers; wherein, the plurality of authoritative servers refer to the servers among the plurality of second servers that match the hostname.

5. The method for determining the Internet Protocol address of a server according to claim 3, characterized in that, The user requirements include distance threshold, health threshold, and load threshold. The step of iteratively filtering the multiple authoritative servers based on the user requirements and the call volume to obtain the target server includes: The address of the user terminal is obtained, and the multiple authoritative servers are filtered according to the address of the user terminal to obtain multiple third servers; wherein, the multiple third servers refer to the servers among the multiple authoritative servers whose distance from the address of the user terminal is less than the distance threshold. The health status of the plurality of third servers is obtained, and the plurality of third servers are filtered according to the health status to obtain a plurality of fourth servers; wherein, the plurality of fourth servers refer to the servers among the plurality of third servers whose health status is greater than the health status threshold. The load of the plurality of fourth servers is obtained, and the plurality of fourth servers are filtered according to the load of the plurality of fourth servers to obtain a plurality of fifth servers; wherein, the plurality of fifth servers refer to the servers among the plurality of fourth servers whose load is less than the load threshold. Obtain the traffic volume processing limits of the plurality of fifth servers, and filter the plurality of fifth servers according to the traffic volume and the traffic volume to obtain the target server; wherein, each of the traffic volume processing limits is used to represent the maximum number of network requests that each fifth server can process per unit time.

6. The method for determining the Internet Protocol address of a server according to claim 1, characterized in that, After receiving the Internet Protocol address sent by the target server and sending the Internet Protocol address of the target server to the user terminal, the method further includes: The resolver receives the time to live (TTL) sent by the target server and stores the Internet Protocol address (IPA) sent by the target server and the TTL; wherein the TTL represents the validity period of the IPA sent by the target server on the resolver. In response to the arrival of the deadline of the preset future time period, the call volume prediction model is updated according to the call volume to obtain the updated call volume prediction model.

7. The method for determining the Internet Protocol address of a server according to claim 6, characterized in that, The step of updating the call volume prediction model based on the call volume to obtain the updated call volume prediction model includes: Obtain the actual network request volume within the preset future time period; Calculate the network request volume deviation based on the traffic volume and the actual network request volume; Based on the network request volume deviation, the traffic volume prediction model is updated to obtain the updated traffic volume prediction model.

8. The method for determining the Internet Protocol address of a server according to claim 1, characterized in that, Sending the Internet Protocol address of the target server to the user terminal includes: Based on the Internet Protocol address of the target server, send a simulated user access command to the target server; Receive the simulated access result sent by the target server; wherein the simulated access result includes a successful simulated access; In response to the simulated access result being successful, the Internet Protocol address of the target server is sent to the user terminal.

9. A device for determining the Internet Protocol address of a server, characterized in that, A resolver for a system for determining the Internet Protocol (IP) address of a server, the system further comprising a user terminal and multiple servers, the apparatus comprising: The first receiving module is used to receive the service domain name and user request sent by the user terminal; wherein, the user request is used to represent the user terminal's request for the server; The first query module is used to perform a cache query based on the service domain name to obtain a query result; wherein, the query result includes a first result, which is used to indicate that the resolver has not cached the Internet Protocol address corresponding to the service domain name, or that the Internet Protocol address has expired; The first calculation module is used to, in response to the query result being the first result, calculate the correlation coefficient between any two variables among a preset plurality of variables, and determine the two variables corresponding to the correlation coefficients that are greater than a preset coefficient threshold as the first variables; wherein, the plurality of variables refers to variables that affect traffic volume; The first acquisition module is used to acquire data corresponding to each of the first variables and input the data corresponding to each of the first variables into a preset traffic volume prediction model to obtain the traffic volume; wherein, the traffic volume is used to represent the number of network requests made by the user terminal in a preset time period in the future; The first filtering module is used to filter the plurality of servers according to the user needs and the call volume to obtain a target server; wherein, the target server refers to the server among the plurality of servers that meets the user needs and the call volume; The second receiving module is used to receive the Internet Protocol address sent by the target server and send the Internet Protocol address of the target server to the user terminal, which is used to access the website based on the Internet Protocol address of the target server.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; When the processor executes the computer execution instructions stored in the memory, it is used to implement the method for determining the server Internet Protocol address as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method for determining the server Internet Protocol address as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, is used to implement the method for determining the server Internet Protocol address as described in any one of claims 1 to 8.

Images