Message transmission method and device and electronic equipment

Abstract

The invention provides a message transmission method and device and electronic equipment. The method comprises the following steps: in response to a first request message sent by a client and received by a CDN edge node in a content distribution network CDN, acquiring a source internet protocol IP address from a transmission layer where the client is connected with the CDN edge node as a user IP address; obtaining a digital signature result aiming at the IP address of the user; writing a user IP address in a target position of a preset field of the first request message, and writing the digital signature result in the first request message to obtain a second request message; forwarding the second request message to the target object through a content delivery network CDN, so that the target object verifies the reliability of the to-be-verified IP address in the second request message based on a digital signature result in the received second request message; the to-be-verified IP address is the IP address located at the target position in the preset field of the second request message. According to the invention, the accuracy of verifying the reliability of the to-be-transmitted address can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of message transmission, and particularly relates to a message transmission method and device and electronic equipment. BACKGROUND

[0002] In the related art, a client request access source station request message can be forwarded to the source station through a content delivery network (CDN) by a reverse proxy manner, so as to improve user access experience. In addition, the content delivery network CDN usually attempts to pass the source Internet Protocol (IP) address of the client to the source station, so that the source station processes the IP address of the client according to a preset rule, for example, providing different services for users with different IP addresses, or performing user auditing.

[0003] However, in the related art, the upper CDN node needs to ensure the reliability of the user IP address through the whitelist of the lower CDN node. However, in reality, because different manufacturers are involved, the whitelist may not be updated in time, further leading to low accuracy of the analysis result of the source station for the reliability analysis of the user IP address. SUMMARY

[0004] The embodiments of the present application provide a message transmission method, device and electronic equipment, which can improve the accuracy of the target object in verifying the reliability of the to-be-transmitted address.

[0005] The technical scheme of the embodiments of the present application is implemented as follows: in a first aspect, the embodiments of the present application provide a message transmission method, comprising: in response to a CDN edge node in a content delivery network (CDN) receiving a first request message sent by a client, obtaining a source Internet Protocol (IP) address as a user IP address from a transmission layer connected between the client and the CDN edge node; wherein the first request message is used to request a service; obtaining a digital signature result for the user IP address; writing the user IP address at a target position in a specific field of the first request message, and writing the digital signature result in the first request message, to obtain a second request message; forwarding the second request message to a target object through the content delivery network (CDN), so that the target object verifies the reliability of a to-be-verified IP address in the second request message based on the digital signature result in the received second request message; wherein the to-be-verified IP address is an IP address at the target position in the specific field of the second request message.

[0006] In the second aspect, an embodiment of the present application provides a message transmission method, including: in response to the target object receiving a second request message transmitted by the CDN edge node through the content distribution network CDN, obtaining the IP address to be verified and the digital signature result for the user IP address from the second request message; wherein, the IP address to be verified is the IP address located at the target location in the specific field of the second request message; the user IP address is the source Internet Protocol IP address obtained by the CDN edge node from the transport layer connecting the client and the CDN edge node when the CDN edge node receives the first request message sent by the client; the second request message sent by the CDN edge node is obtained after the CDN edge node writes the user IP address at the target location of the specific non-field of the first request message and writes the digital signature result in the first request message; the first request message is used to request business services; based on the digital signature result in the received second request message, a first verification is performed on the reliability of the IP address to be verified.

[0007] In a third aspect, an embodiment of the present application provides a message transmission device, comprising: an acquisition module for obtaining a source Internet Protocol IP address as a user IP address from a transport layer connecting the client and the CDN edge node in response to a first request message sent by a client being received by a CDN edge node in a content delivery network CDN; wherein the first request message is used to request a business service; obtaining a digital signature result for the user IP address; a processing module for writing the user IP address in a target position of a specific field of the first request message, and writing the digital signature result in the first request message to obtain a second request message; a sending module for forwarding the second request message to a target object through the content delivery network CDN, so that the target object verifies the reliability of the IP address to be verified in the second request message based on the digital signature result in the received second request message; wherein the IP address to be verified is the IP address located at the target position in the specific field of the second request message.

[0008] In some embodiments, the target object includes at least one of the following: a source station providing business services; a CDN preset node in a content delivery network CDN, and the CDN preset node is configured to verify the reliability of the IP address to be verified.

[0009] In some embodiments, the acquisition module is used to digitally sign the current first timestamp and user IP address of the CDN edge node to obtain a digital signature result; the processing module is also used to write the first timestamp into the first request message to obtain a second request message.

[0010] In some embodiments, the first request message is used to request a service through a first domain name; the obtaining module is configured to obtain a target certificate address based on the first domain name and a preset path; the target certificate address at least includes a second domain name and the preset path; the first domain name is within a coverage range of the second domain name; a digital signature result for a user IP address is obtained based on a target digital certificate obtained according to the target certificate address; and the processing module is further configured to write the target certificate address in the first request message to obtain a second request message.

[0011] In a fourth aspect, an embodiment of the present application provides a message transmission device, which includes: an obtaining module configured to obtain a to-be-verified IP address and a digital signature result for a user IP address from a second request message received by a target object from a content distribution network (CDN) edge node, in response to the target object receiving the second request message transmitted by the CDN edge node through the CDN; the to-be-verified IP address is an IP address located at a target position in a specific field of the second request message; the user IP address is a source Internet Protocol (IP) address obtained by the CDN edge node from a transmission layer connected with the CDN edge node in a case where the CDN edge node receives a first request message sent by a client; the second request message sent by the CDN edge node is obtained after the CDN edge node writes the user IP address at the target position of the specific field of the first request message and writes the digital signature result in the first request message; the first request message is used to request a service; and a verification module configured to perform a first verification on reliability of the to-be-verified IP address based on the digital signature result in the received second request message.

[0012] In some embodiments, the obtaining module is further configured to obtain at least one of a first time stamp and a target certificate address written by the CDN edge node from the second request message; the target certificate address is used to obtain a target digital certificate matched with the digital signature result; and the verification module is further configured to perform a second verification on reliability of the to-be-verified IP address based on at least one of the first time stamp and the target certificate address, and determine that the to-be-verified IP address passes the second verification, before performing the first verification on reliability of the to-be-verified IP address based on the digital signature result in the received second request message.

[0013] In some embodiments, the verification module is configured to determine that the IP address to be verified fails the first sub-verification of the second verification in a case where a difference between the first timestamp and the second timestamp is greater than a difference threshold; determine that the IP address to be verified passes the first sub-verification in a case where the difference between the first timestamp and the second timestamp is less than or equal to the difference threshold; determine that the IP address to be verified passes the second sub-verification of the second verification in a case where the domain name included in the target certificate address is the preset domain name and the path included in the target certificate address is the preset path; determine that the IP address to be verified fails the second sub-verification in a case where the domain name included in the target certificate address is not the preset domain name and / or the path included in the target certificate address is not the preset path; determine that the IP address to be verified passes the third sub-verification of the second verification in a case where the target digital certificate is successfully obtained based on the target certificate address; determine that the IP address to be verified fails the third sub-verification in a case where the target digital certificate fails to be obtained based on the target certificate address; determine that the IP address to be verified passes the fourth sub-verification of the second verification in a case where the first domain name is within the coverage range of the domain name included in the target certificate address; or determine that the IP address to be verified fails the fourth sub-verification in a case where the first domain name is outside the coverage range of the domain name included in the target certificate address; wherein the first request message is used to request the service from the first domain name; and determine that the IP address to be verified passes the second verification in a case where the IP address to be verified passes all the sub-verifications, and otherwise determine that the IP address to be verified fails the second verification.

[0014] In some embodiments, the target object includes at least one of a CDN preset node in a content distribution network (CDN) and a source station configured to provide a service; the CDN preset node is configured to verify the reliability of the IP address to be verified; the apparatus further includes a sending module configured to send a preset response message to the client for the second request message in a case where the IP address to be verified passes all the verifications; wherein the preset response message is used to provide the service to the client; and in a case where the IP address to be verified fails any verification, according to the service requirement, the second request message is not responded to, or at least one of an error code and an error message is sent to the client.

[0015] In some embodiments, the target object includes a CDN preset node in a content distribution network (CDN), and the CDN preset node is configured to verify the IP address to be verified; the apparatus further includes a processing module and a sending module; the obtaining module is configured to obtain a preset field from the second request message in response to the CDN preset node receiving the second request message; the preset field is configured to list IP addresses of all CDN nodes in the CDN that the second request message passes through; the processing module is configured to replace content of the preset field with the IP address to be verified to obtain a reconstructed preset field in a case where the IP address to be verified passes all verifications; the sending module is configured to send the second request message carrying the reconstructed preset field to the source station; the reconstructed preset field is configured to enable the source station to determine that the IP address to be verified passes the verification; and in a case where the user IP address does not pass any verification, the apparatus rejects the request of the client for the service and sends at least one of an error code and an error message to the client.

[0016] In a fifth aspect, an electronic device is provided, which can be an edge node, a CDN intermediate node, or a source station in embodiments of the present application, and includes:

[0017] a memory configured to store executable instructions;

[0018] a processor configured to execute the executable instructions stored in the memory to implement the message transmission method provided in embodiments of the present application.

[0019] In a sixth aspect, a computer readable storage medium is provided, which stores a computer program or executable instructions, and is configured to cause a processor to execute the message transmission method provided in embodiments of the present application when the computer program or executable instructions are executed.

[0020] In a seventh aspect, a computer program product is provided, which includes a computer program or instructions, and the computer program or instructions are executed by a processor to implement the message transmission method provided in embodiments of the present application.

[0021] Embodiments of the present application have the following beneficial effects:

[0022] In embodiments of the present application, on the one hand, in a case where the client sends a first request message to the CDN edge node, the CDN edge node can obtain a source IP address from a transmission layer to which the client and the CDN edge node are connected as the user IP address, that is, the CDN edge node can obtain the real IP address of the client from the transmission layer as the user IP address. In this way, the CDN edge node will not take the IP address forged by the client as the user IP address, and the reliability of the user IP address obtained by the CDN edge node can be improved.

[0023] On the other hand, the CDN edge node can write the reliable user IP address in the target position of a specific field in the first request message, and write the digital signature result in the first request message to obtain a second request message. The second request message is forwarded to the target object through the content distribution network CDN, so that the target object verifies the reliability of the IP address in the target position (i.e., the to-be-verified IP address) in the specific field of the second request message based on the digital signature result carried in the received second request message. That is, the target object can verify whether the to-be-verified IP address is the same as the reliable user IP address based on the digital signature result, to determine whether the to-be-verified IP address is reliable.

[0024] Here, if the to-be-verified IP address carried in the second request message changes during the transmission through the CDN and becomes unreliable, that is, if the to-be-verified IP address carried in the second request message is different from the user IP address initially written in the first request message, the target object can still verify the unreliable to-be-verified IP address based on the digital signature result for the user IP address. At this time, the target object will not take the unreliable to-be-verified IP address as the user IP address, and will not provide normal service to the client based on the unreliable to-be-verified IP address, so as to improve the security and accuracy of the service provided by the target object. BRIEF DESCRIPTION OF DRAWINGS

[0025] Figure 1 is a structural schematic diagram of a system architecture of a message transmission method provided by an embodiment of the present application;

[0026] Figure 2 is a structural schematic diagram of an electronic device provided by an embodiment of the present application Figure 1 ;

[0027] Figure 3 is a structural schematic diagram of an electronic device provided by an embodiment of the present application Figure 2 ;

[0028] Figure 4 is a structural schematic diagram of an electronic device provided by an embodiment of the present application Figure 3 ;

[0029] Figure 4 is a structural schematic diagram of an electronic device provided by an embodiment of the present application Figure 6 ;

[0030] Figure 1 is a structural schematic diagram of an electronic device provided by an embodiment of the present application Figure 7 .

[0031] Figure 2 is a structural schematic diagram of an electronic device provided by an embodiment of the present application Figure 8 .

[0032] Figure 3 is a flowchart of a message transmission method provided by an embodiment of the present application Figure 9 .

[0033] Figure 4 is a flowchart of a message transmission method provided by an embodiment of the present application Figure 1 . DETAILED DESCRIPTION

[0034] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the drawings, and the described embodiments should not be regarded as limiting the present application, and all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0035] In the following description, “some embodiments” are described, which describe a subset of all possible embodiments, but it can be understood that “some embodiments” can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict.

[0036] If similar descriptions of “first\second” appear in the application file, the following description is added, in the following description, the terms “first\second\third” referred to only distinguish similar objects, and do not represent a specific order of the objects, and it can be understood that “first\second\third” can be interchanged in a specific order or sequence as allowed, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0037] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application, and are not intended to limit the present application.

[0038] In the related art, the Hyper Text Transfer Protocol (HTTP) message generated by a client at a network layer can be forwarded to a source station providing a service through a Content Delivery Network (CDN).

[0039] In some embodiments, the client can write the user IP address (i.e., the IP address of the client) in a target position of a specific field of a request header of the HTTP message, and forward the HTTP message to the origin server through a content distribution network (CDN). In the process of forwarding the HTTP message by a CDN node in the content distribution network (CDN), the CDN node can also add the IP address of the CDN node in other positions within the specific field of the HTTP message. After receiving the HTTP message forwarded by the content distribution network (CDN), the origin server can directly verify the IP address in the target position within the specific field of the HTTP message as a reliable user IP address (i.e., the real IP address of the client) to determine the reliability of the client, so as to determine whether to provide service to the client. Exemplarily, the specific field can be an X-Forwarded-For field or other similar fields (such as X-Real-IP) of the HTTP message, the target position can be the beginning of the specific field, and the other position can be the end of the specific field.

[0040] However, the client has the ability to forge IP addresses at the network layer, at which time the client can write the user IP address forged by the client (i.e., the IP address of the client forged by the client, rather than the real IP address of the client) in the target position of the specific field of the HTTP message at the network layer. Even if the IP address to be verified in the HTTP message received by the origin server does not change in the transmission process, it is still not a reliable user IP address, but a user IP address forged by the client.

[0041] That is, the origin server mentioned above verifies the IP address in the target position of the specific field of the HTTP message as a reliable user IP address, which can be understood as that the origin server mistakenly verifies the user IP address forged by the client as a reliable user IP address. At this time, even if the verification result of the origin server on the user IP address forged by the client is passed, it does not mean that the client is reliable; even if the verification result of the origin server on the user IP address forged by the client is failed, it does not mean that the client is unreliable. That is, the origin server is difficult to verify the reliability of the client, so as to safely provide service to the reliable client.

[0042] In some scenarios, if the origin server provides service to the unreliable client, the client can directly scan the IP address of the origin server, and the client can directly send a request containing a forged IP address to the origin server without passing through the content distribution network (CDN), which causes a security risk of the origin server.

[0043] To reduce the situation that the content distribution network (CDN) forwards the user IP address forged by the client to the source station, on one hand, the header used by the CDN node can be different. For example, the header of the CDN edge node can adopt the X-Real-IP field and be used to indicate discarding the user IP address written by the client. For example, the CDN edge node discards any X-Real-IP field (including the X-Real-IP field in the HTTP message sent by the client) existing before. At this time, although the client can carry the forged user IP address in the HTTP message when making a normal request, the forged user IP address will be discarded by the CDN edge node.

[0044] On the other hand, the CDN nodes in the content distribution network (CDN) can all be provided with a preset white list. In the process of forwarding the HTTP message by the CDN nodes in the content distribution network (CDN), the CDN nodes can also add the IP address of the CDN node in other positions of the specific field to indicate the node link of the CDN node passed by the HTTP message. In the case that the current CDN node receives the HTTP message and any IP address in the specific field in the HTTP message is outside the preset white list, the specific field in the HTTP message or the IP address in the specific field outside the preset white list can be discarded. In the case that the current CDN node receives the HTTP message and the IP address of the specific field in the HTTP message is inside the preset white list, the current CDN node further parses the IP address to be verified (such as the first IP address in the X-Forwarded-For field or other similar fields) in the HTTP message, and adds the IP address of the current CDN node in other positions (such as the tail of the X-Forwarded-For field or other similar fields) of the specific field after the parsing is completed to obtain a reconstructed HTTP message. The current CDN node continues to forward the reconstructed HTTP message to the upper CDN node until the HTTP message is forwarded to the source station through the content distribution network (CDN).

[0045] Here, the reliability of the IP address in the preset field in the HTTP message can be verified by the preset white list.

[0046] However, the preset white list set in the related art is not necessarily accurate.

[0047] Exemplarily, due to the rapid change of modern network, for a large-scale content distribution network (CDN), not only frequent adjustment of the machine room and / or IP address can exist, but also challenges such as non-IP dependent services such as elastic containers are faced. At this time, it is difficult to update the preset white list in real time to adapt to the change of the IP address.

[0048] Exemplarily, the manufacturers to which different CDN nodes in a content distribution network (CDN) belong can be different, causing it difficult to synchronize the preset white list updates between CDN nodes managed by different manufacturers, resulting in different preset white lists used by different CDN nodes, and thus the same IP address can have different checking results in different CDN nodes.

[0049] Exemplarily, the IP address changes frequently, and some operation and maintenance personnel can directly write an inappropriate large network segment in the preset white list, causing the client-forged user IP address carried in the HTTP message to be treated as the real user IP address of the client, resulting in the risk that the preset white list cannot accurately identify the client-forged user IP address.

[0050] Here, in the case that the preset white list set in the CDN node can be inaccurate, if there are multiple CDN nodes cascaded in the content distribution network (CDN), the CDN node in the later stage can mistakenly discard the specific field of the HTTP message delivered by the CDN node in the previous stage or the to-be-checked IP address located at the target position in the specific field, causing the to-be-checked IP address located at the target position in the HTTP message to change. For example, the CDN node in the later stage can discard the to-be-checked IP address located at the target position in the specific field, at this time, the IP address originally located at the target position is regarded as a new to-be-checked IP address located at the target position, causing the to-be-checked IP address located at the target position in the specific field to change. Or, the CDN node in the later stage can discard the entire specific field in the HTTP message delivered by the CDN node in the previous stage, and regenerate the specific field and write the IP address of the CDN node in the previous stage to the target position of the specific field, causing the to-be-checked IP address located at the target position in the specific field to change to the IP address of the CDN node in the previous stage. In this way, after the source station receives the HTTP message forwarded by the content distribution network, the to-be-checked IP address located at the target position in the preset field of the HTTP message received by the source station is different from the to-be-checked IP address located at the target position in the preset field of the HTTP message initially sent by the CDN edge node.

[0051] At this time, the source station checks the to-be-checked IP address located at the target position in the specific field of the HTTP message as the user IP address, which can be understood as that the source station checks the erroneous to-be-checked IP address delivered by the content distribution network (CDN) as the user IP address, causing the source station also unable to determine whether the client is reliable based on the checking result of the to-be-checked IP address of the HTTP message.

[0052] In conclusion, in the related art, the client has the opportunity to forge its own IP address, and due to cross-vendor communication, it is sometimes difficult to synchronize the accurate preset white list in the CDN node and the source station, resulting in the source station possibly verifying the wrong to-be-verified IP address or misverifying the forged user IP address as the real user IP address.

[0053] To solve the above problems, the embodiments of the present application provide a message transmission method, device and electronic equipment, which replace the method of delivering the to-be-verified IP address based on the preset white list and verifying the to-be-verified IP address in the related art.

[0054] In the embodiments of the present application, on the one hand, in the case that the client sends a first request message to the CDN edge node, the CDN edge node can obtain the real source IP address as the reliable user IP address from the transport layer which does not have the ability to forge the IP address. In this way, the situation of delivering the IP address forged by the client to the target object is reduced, and the probability of delivering the reliable user IP address to the target object is improved.

[0055] On the other hand, the CDN edge node can obtain the digital signature result for the reliable user IP address, and write the reliable user IP address at the target position of the specific field of the first request message, and write the digital signature result in the first request message to obtain a second request message. In this way, in the process of forwarding the second request message to the target object through the content distribution network CDN, even if the to-be-verified IP address located at the target position in the specific field of the second request message changes, the target object can still accurately verify the to-be-verified IP address based on the digital signature result received in the second request message, so as to verify that the to-be-verified IP address is unreliable.

[0056] In this way, based on the verification result of the target object on the reliability of the to-be-verified IP address, the target object will not take the to-be-verified IP address delivered incorrectly or the forged user IP address as the reliable user IP address, and will not provide the business service to the client based on the unreliable IP address other than the reliable user IP address, so as to improve the security and accuracy of the business service provided by the target object.

[0057] Referring to Figure 1 , Figure 1 is a schematic diagram of the architecture of a system 100 for a message transmission method provided by the embodiments of the present application. To implement the message transmission method of the embodiments of the present application, the client 400-1 and the client 400-2 Figure 2Only two clients are shown, but this does not limit the number of clients included in the system of the message transmission method of the embodiments of the present application) through the preset network 300. The preset network 300 can be a content distribution network (CDN). Through the preset network 300, the first request message sent by the client 400 can be converted into a second request message, and the second request message can be forwarded to a target object. The target object can be a CDN preset node in the preset network 300, or the target object can be a source station 200 connected by the preset network 300.

[0058] In some embodiments, the preset network 300 can include a CDN edge node, and the first request message sent by the client 400 can be converted into a second request message by the CDN edge node, and the CDN edge node is directly connected with the source station 200. At this time, the CDN edge node can directly send the second request message of any of the present disclosure to the source station 200. Alternatively, the preset network 300 can include at least two cascaded CDN nodes, and the CDN edge node in the at least two cascaded CDN nodes is connected with the source station 200 through a CDN CDN intermediate node. At this time, the CDN edge node can send the second request message of any of the present disclosure to the CDN node of the upper level, and the CDN intermediate node in the at least two cascaded CDN nodes can sequentially transmit the second request message to the source station.

[0059] In an implementation, a user can send a first request message to a CDN edge node in the preset network 300 through any of the client 400-1 and the client 400-2. Accordingly, the CDN edge node in the preset network 300 can obtain a source Internet Protocol (IP) address as a user IP address from a transmission layer to which the client is connected with the CDN edge node in response to receiving the first request message; wherein the first request message is used to request a service. Then, the CDN edge node obtains a digital signature result for the user IP address; writes the user IP address in a target position of a preset field of the first request message, and writes the digital signature result in the first request message to obtain a second request message; the CDN edge node forwards the second request message to a target object through a content distribution network (CDN) so that the target object checks the reliability of a to-be-checked IP address in the second request message based on the digital signature result in the received second request message; wherein the to-be-checked IP address is an IP address in the target position in the specific field of the second request message. Accordingly, the target object obtains the to-be-checked IP address and the digital signature result for the user IP address from the second request message after receiving the second request message, and checks the reliability of the to-be-checked IP address based on the digital signature result in the second request message.

[0060] In some embodiments, the source station 200 can be a standalone physical server, a server cluster or a distributed system composed of multiple physical servers, a cloud server providing cloud services, cloud database, cloud computing, cloud function, cloud storage, network service, cloud communication, middleware service, domain name service, security service, and basic cloud computing services such as big data and artificial intelligence platform. The client can be a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart watch, and other electronic devices with a display screen, but is not limited thereto.

[0061] Figure 2 FIG. 5 is a structural schematic diagram of an electronic device 500 provided by an embodiment of the present application. The electronic device 500 can be a client, a CDN edge node, a CDN preset node, or a source station.

[0062] Figure 2 The electronic device 500 shown includes at least one processor 510, a memory 550, at least one network interface 520, and a user interface 530. The various components in the electronic device 500 are coupled together by a bus system 540. It can be understood that the bus system 540 is used to realize the connection and communication between the components. In addition to including a data bus, the bus system 540 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, all the buses are marked as the bus system 540 in Figure 3 .

[0063] The processor 510 can be an integrated circuit chip with signal processing capability, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc., wherein the general-purpose processor can be a microprocessor or any conventional processor.

[0064] The user interface 530 includes one or more output devices 531 that enable the presentation of media content, including one or more speakers and / or one or more visual display screens. The user interface 530 also includes one or more input devices 532, including user interface components that facilitate user input, such as a keyboard, a mouse, a microphone, a touch screen display, a camera, other input buttons and controls.

[0065] The memory 550 can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. The memory 550 optionally includes one or more storage devices physically located in proximity to the processor 510.

[0066] The memory 550 includes volatile memory or nonvolatile memory, and can include both volatile and nonvolatile memory. The nonvolatile memory can be read only memory (ROM), and the volatile memory can be random access memory (RAM). The memory 550 described in the embodiments of the present application is intended to include any suitable type of memory.

[0067] In some embodiments, the memory 550 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, which are exemplarily illustrated below.

[0068] Exemplarily, the memory 550 can include an operating system 551, a network communication module 552, and an input processing module 553. Among them, the operating system 551 includes a system program for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks; the network communication module 552 is used to reach other computing devices via one or more (wired or wireless) network interfaces 420, and exemplary network interfaces 420 include Bluetooth, wireless compatibility certification (WiFi), and universal serial bus (USB), etc.; the input processing module 553 is used to detect and translate one or more user inputs or interactions from one or more input devices 532.

[0069] In some embodiments, referring to Figure 2 In the case of the electronic device 500 being a client, the memory 550 in the electronic device 500 can further include a presentation module 554 for enabling presentation of messages (e.g., user interfaces for operating peripheral devices and displaying content and messages) via one or more output devices 531 (e.g., display screens, speakers, etc.) associated with the user interface 530.

[0070] In some embodiments, the message transmission apparatus provided by the embodiments of the present application can be implemented in a software manner, which can be in the form of software such as programs and plug-ins. Referring to Figure 4 The message transmission apparatus provided by the embodiments of the present application can include software modules arranged in the memory 550 of the electronic device 500. Therefore, any combination or further splitting can be made according to the implemented functions. The functions of each module will be further described below.

[0071] Exemplarily, referring to Figure 5, the electronic device 500 can be an edge node, the memory 550 includes a message transmission apparatus 555, which can include an acquisition module 5551, a processing module 5552, and a sending module 5553. By way of example, see Figure 6 , the electronic device 500 can be a source station or a CDN preset node in the preset network 300 for checking a user IP address, at this time, the memory 550 includes a message transmission apparatus 556, which can include an acquisition module 5561 and a checking module 5562.

[0072] In some other embodiments, the message transmission apparatus provided by the embodiments of the present application can be implemented in a hardware manner. By way of example, the message transmission apparatus provided by the embodiments of the present application can be a processor in the form of a hardware decoding processor, which is programmed to execute the message transmission method provided by the embodiments of the present application. For example, the processor in the form of a hardware decoding processor can use one or more application specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0073] In some other embodiments, the message transmission apparatus 555 provided by the embodiments of the present application can be implemented in a hardware manner. By way of example, the message transmission apparatus 555 provided by the embodiments of the present application can be a processor in the form of a hardware decoding processor, which is programmed to execute the message transmission method provided by the embodiments of the present application. For example, the processor in the form of a hardware decoding processor can use one or more application specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0074] The message transmission method provided by the embodiments of the present application will be described below in conjunction with exemplary applications and implementations of a terminal provided by the embodiments of the present application.

[0075] SeeFigure 6 , Figure 1 is a flowchart of a message transmission method provided by an embodiment of the present application Figure 6 The message transmission method provided by the present application will be described below in conjunction with the steps shown in Figure 6

[0076] It should be noted that Figure 7 The execution subject of the flowchart shown can be a CDN edge node in a CDN node. The CDN edge node can be directly connected with a client. That is, the edge node can be used to provide an entrance of a content distribution network CDN for the client. The connection of the CDN edge node with the client can mean that the CDN edge node and the client establish a four-layer (i.e., a transport layer) connection. The transport layer is the fourth layer in the Open Systems Interconnection (OSI) seven-layer model.

[0077] It should be noted that the user IP addresses in the following text are source Internet Protocol IP addresses obtained by a CDN edge node from a transport layer to which a client is connected, and are different from the user IP addresses written in a first request message by the client in the above text.

[0078] In step 1001, in response to a CDN edge node in a content distribution network CDN receiving a first request message sent by a client, a source Internet Protocol IP address is obtained from a transport layer to which the client is connected as a user IP address; wherein the first request message is used to request a service.

[0079] Exemplarily, before the client sends the first request message to the CDN edge node, the client can send a preset message to the CDN edge node based on the transport layer to which the CDN edge node is connected. The CDN edge node can obtain a source Internet Protocol IP address from the preset message as a user IP address. The preset message is a message transmitted based on a transport layer protocol. For example, the transport layer protocol can be a Transmission Control Protocol (TCP) protocol, and the message can be a TCP message. The CDN edge node can obtain an Internet Protocol IP address of the client from the TCP message as a user IP address.

[0080] ​In some embodiments, the first request message can be used to request the source station to provide a service to the client. Here, the source station can be understood as a service server. The service requested by the first request message includes, but is not limited to, at least one of the following: a data query service, an online payment service, an order submission service, and a social service. It should be noted that the service requested by the first request message is exemplarily described herein, and the service requested by the first request message in the embodiments of the present application is not limited thereto. The client can send the first request message for requesting the corresponding service according to the specific service requirement.

[0081] In step 1002, a digital signature result for the user IP address is obtained.

[0082] Exemplarily, the CDN edge node digitally signs at least the user IP address to obtain the digital signature result for the user IP address. It can be understood that the CDN edge node can digitally sign the user IP address alone to obtain the digital signature result for the user IP address. Alternatively, the CDN edge node can digitally sign the user IP address and other information together to obtain the digital signature result for the user IP address.

[0083] In step 1003, the CDN edge node writes the user IP address in a target position of a specific field in the first request message, and writes the digital signature result in the first request message to obtain a second request message.

[0084] In some embodiments, the user IP address can be digitally signed based on a target digital certificate to obtain the digital signature result. The length of the digital signature result obtained based on the target digital certificate is less than a first length threshold. Exemplarily, the target digital certificate can be an elliptic curve certificate. The digital signature algorithm of the elliptic curve certificate can be an elliptic curve digital signature algorithm (ECDSA), an Edwards-curve digital signature algorithm (EdDSA), or an SM2 digital signature algorithm. Here, the length of the digital signature result obtained by digitally signing the user IP address is short, and the short digital signature result can be written in the first request message to obtain the second request message. In this way, the transmission speed of the second request message carrying the digital signature result can be improved.

[0085] In some embodiments, the CDN edge node writes the user IP address and the digital signature result in the request header of the first request message to obtain the second request message.

[0086] In some embodiments, the CDN edge node can determine the target digital certificate based on a type of the first request message; and the CDN edge node can digitally sign the user IP address based on the target digital certificate to obtain a digital signature result. Exemplarily, the type of the first request message can indicate a length of a request header of the first request message. The lengths of the request headers of different types of the first request message are different. The target digital certificate can be obtained based on the length of the request header of the first request message. The length of the digital signature result obtained after the digital signature based on the target digital certificate is positively correlated with the length of the request header of the first request message.

[0087] For example, in a case where the first request message is an HTTP type message and the length of the request header of the first request message is less than a second length threshold, the target digital certificate can be an elliptic curve certificate. The length of the digital signature result obtained after the digital signature based on the elliptic curve certificate is less than a first length threshold. The first length threshold is less than the second length threshold.

[0088] Through the above-mentioned manner of obtaining the target digital certificate, the length of the digital signature result obtained after the digital signature based on the target digital certificate can be flexibly controlled, and the case that the second request message is difficult to carry the digital signature result due to the length of the digital signature result being too long can be reduced, and the reliability of carrying the digital signature result in the request header of the second request message can be improved.

[0089] In some embodiments, the target digital certificate is a certificate trusted by the target object. Here, the type of the target digital certificate is not limited, for example, the target digital certificate can be a certificate based on the Hypertext Transfer Protocol Secure (HTTPS), or a self-signed certificate.

[0090] The following can refer to a specific field as a first field. The first field can be a field set based on a standard protocol, for example, the first field can be an X-Forwarded-For field, or the first field can be a self-defined field, for example, the first field can be a self-defined X-Real-IP field.

[0091] In some embodiments, the digital signature result can be written in a position other than the target position in the first field. Or, the digital signature result can be written in a second field different from the first field in the first request message. Exemplarily, the CDN edge node can write the user IP address in the target position of the first field of the first request message, and write the digital signature result in the second field. The second field can be a self-defined field.

[0092] In some embodiments, in response to the first field being initially carried in the received first request message, the CDN edge node can discard the first field initially carried in the received first request message, and re-write the first field in the first request message, the re-written first field containing the user IP address obtained by the CDN edge node from the transport layer through which the client is connected to the CDN edge node. Alternatively, the CDN edge node can replace the content in the first field initially carried in the first request message with the user IP address obtained by the CDN edge node from the transport layer through which the client is connected to the CDN edge node.

[0093] By way of example, the first field can be an X-Real-IP field, in response to the X-Real-IP field being initially carried in the received first request message, the CDN edge node can discard the X-Real-IP field initially carried in the received first request message, and regenerate the X-Real-IP field based on the user IP address obtained by the CDN edge node from the transport layer through which the client is connected to the CDN edge node, to write the newly generated X-Real-IP field into the request header of the first request message to obtain a second request message. Alternatively, the CDN edge node can not delete the X-Real-IP field initially carried in the first request message, and the CDN edge node can directly replace the content of the X-Real-IP field carried in the first request message with the user IP address obtained by the CDN edge node from the transport layer through which the client is connected to the CDN edge node.

[0094] By the above-described manner of writing the user IP address obtained by the CDN edge node from the transport layer through which the client is connected to the CDN edge node in the first field, the situation of passing a client-forged IP address to the target object can be reduced, thereby improving the authenticity of the user IP address passed to the upper CDN node or the source station.

[0095] At step 1004, the second request message is forwarded to the target object through the content distribution network CDN, so that the target object checks the reliability of the to-be-checked IP address in the second request message based on the digital signature result in the received second request message; wherein the to-be-checked IP address is an IP address located at a target position in a specific field of the second request message.

[0096] In some embodiments, the target object includes at least one of the following: a source station providing a service; a CDN preset node in the content distribution network CDN, the CDN preset node being configured to check the reliability of the to-be-checked IP address.

[0097] It should be noted that the CDN edge node can send the second request message to the upper CDN node, so that the upper node forwards the second request message carrying the IP address to be verified and the digital signature result until the source station or the CDN preset node receives the second request message, and the source station or the CDN preset node verifies the reliability of the IP address to be verified based on the digital signature result in the received second request message. The CDN preset node here can be understood as a CDN intermediate node in at least two cascaded CDN nodes, which is specially used for verifying the user IP address. The CDN preset node is used to verify the reliability of the IP address to be verified on behalf of the source station under the entrustment of the source station.

[0098] It should be noted that in the case of verifying the user IP address by the CDN preset node on behalf of the source station, it is not necessary to specially set a related mechanism for verifying the user IP address based on the digital signature result in the source station, and the source station also does not need to consume computing resources to verify whether the user IP address is reliable based on the digital signature result, thereby reducing the waste of computing resources of the source station.

[0099] In the embodiments of the present application, the CDN edge node in the content distribution network CDN can obtain the IP address from the transmission layer in which the client is connected to the CDN edge node as a reliable user IP address. Moreover, the CDN edge node can digitally sign the reliable user IP address to obtain a digital signature result, and forward a second request message carrying the IP address to be verified and the digital signature result to a target object through the content distribution network CDN, so that the target object accurately analyzes whether the IP address to be verified is a reliable user IP address based on the digital signature result in the received second request message. In this way, in the case that an error or fake IP address to be verified is delivered to the target object, the target object can still verify the error or fake IP address to be verified based on the digital signature result, and will not provide normal service based on the error or fake IP address to be verified, thereby improving the security and accuracy of providing service to the client.

[0100] In some embodiments, the CDN edge node digitally signs at least the user IP address to obtain a digital signature result, including: the CDN edge node digitally signs at least one of the first timestamp and the node information, and the user IP address to obtain a digital signature result.

[0101] In some embodiments, the CDN edge node can digitally sign the user IP address, the first timestamp, and the node information of the CDN edge node to obtain a digital signature result. The CDN edge node can write the user IP address, the first timestamp, the node information of the CDN edge node, and the digital signature result in a request header of the first request message. In this way, the determination of whether the user IP address is reliable can be assisted based on the auxiliary message of multiple dimensions, and the accuracy of determining whether the user IP address is reliable can be improved.

[0102] In some embodiments, the CDN edge node obtains the digital signature result for the user IP address by digitally signing the first timestamp currently of the CDN edge node and the user IP address to obtain the digital signature result.

[0103] In some embodiments, the first timestamp currently of the CDN edge node is also written in the first request message to obtain the second request message. For example, the first timestamp currently of the CDN edge node is also written in the request header of the first request message to obtain the second request message.

[0104] In some embodiments, in response to the CDN edge node receiving the first request message, the CDN edge node acquires the first timestamp currently of the CDN edge node. It should be noted that the first timestamp here can be used to indicate the timestamp corresponding to the time of receiving the first request message. Alternatively, in response to the CDN edge node obtaining the user IP address, the CDN edge node acquires the first timestamp currently of the CDN edge node. It should be noted that the first timestamp here can be used to indicate the timestamp corresponding to the time of acquiring the source Internet Protocol (IP) address from the transport layer in which the client is connected to the CDN edge node.

[0105] It should be noted that the first timestamp can be a millisecond-level timestamp. For example, the first timestamp can be “1718350318523”.

[0106] In some embodiments, the CDN edge node obtains the digital signature result for the user IP address by digitally signing the node information of the CDN edge node and the user IP address to obtain the digital signature result.

[0107] In some embodiments, the node information of the CDN edge node is also written in the first request message to obtain the second request message. For example, the node information of the CDN edge node is written in the request header of the first request message to obtain the second request message.

[0108] In some embodiments, the node information of the CDN edge node can include at least one of the following: a manufacturer to which the CDN edge node belongs, a service type of the CDN edge node, and a node identifier of the CDN edge node.

[0109] In some embodiments, the CDN edge node can write a third field containing the first timestamp and / or a fourth field containing the node information of the CDN edge node in a request header of the first request message. The fields in the request header can include a field name and a field value. The field value of the third field can be used to indicate the value of the first timestamp, and the field value of the fourth field can indicate the specific node information.

[0110] For example, the third field can be "X-Real-time: 1718350318523". Wherein, "X-Real-time" can be the field name of the third field, and "1718350318523" can be the value of the first timestamp.

[0111] For example, the fourth field can be "X-Real-Ext: sina cdn 001". Wherein, "X-Real-Ext" can be the field name of the fourth field, "sina" can be the manufacturer of the CDN edge node, "cdn" can indicate that the CDN edge node is a CDN node, and "001" can be the node identifier of the CDN edge node.

[0112] In the embodiments of the present application, the CDN edge node can also write the current first timestamp of the CDN edge node in the first request message to obtain a second request message. By forwarding the second request message to the target object through the content distribution network CDN, the target object can use the first timestamp carried in the received second request message to assist in determining whether the to-be-verified IP address carried in the second request message is reliable, so that the to-be-verified IP address that passes the verification is used as a reliable user IP address, and the client is provided with service, so as to improve the security of providing service to the client.

[0113] In some embodiments, the CDN edge node can convert the digital signature result from the first format to a second format to obtain a digital signature result in the second format, write the user IP address and the digital signature result in the second format in the first request message to obtain a second request message. The digital signature result in the second format has a smaller data size than the digital signature result in the first format. For example, the digital signature result can be Base64 encoded (a binary data encoding method that converts every 6-bit binary data into one printable character) to obtain the digital signature result in the second format. It can be understood that the digital signature result before Base64 encoding has the first format, and the first format can be a binary format. The digital signature result after Base64 encoding has the second format, and the second format can be a character format. Here, by converting the format of the digital signature result, the data size of the digital signature result can be reduced, and the reliability of the second request message carrying the digital signature result can be improved.

[0114] For example, the CDN edge node can write a first field in the request header of the first request message, the first field containing the user IP address, and the first field can be "X-Real-IP: 192.0.2.33". The CDN edge node can write a third field in the request header of the first request message, the third field containing the first timestamp, and the third field can be "X-Real-time: 1718350318523". The CDN edge node can write a fourth field in the request header of the first request message, the fourth field containing the node information of the CDN edge node, and the fourth field can be "X-Real-Ext: sina cdn 001". The user IP address, the first timestamp, and the node information of the CDN edge node can be digitally signed to obtain a digital signature result. A second field can be written in the request header of the first request message, the second field containing the Base64 encoded digital signature result, and the second field can be:

[0115] "X-Real-Sign: RrGnD2UGRy37r8jtVnFeCc2+g5gMgsxMGTsmcNfUn3WIcvA2cV3hwsVnffmAxKGueTMo7OG3sOGT5fePR9JmosO67nlmDCLh".

[0116] In the embodiments of the present application, the first timestamp and the user IP address can be digitally signed, so that the target object receiving the second request message can accurately verify whether the first timestamp and the to-be-verified IP address are tampered in the transmission process based on the digital signature result in the second request message. In this way, the target object can provide service to the client based on the reliable to-be-verified IP address verified, thereby improving the security of providing service to the client.

[0117] In some embodiments, the CDN edge node can also write the IP address of the CDN edge node in a preset field of the first request message. The preset field is used to list the IP addresses of all CDN nodes through which the second request message passes. The preset field can be a field agreed in advance between each CDN node and the source station based on a standard protocol. For example, the preset field can be an X-Forwarded-For field.

[0118] It should be noted that the preset field can be different from the first field. For example, the first field can be an X-Real-IP field, and the preset field can be an X-Forwarded-For field. Alternatively, the preset field can be the same as the first field. For example, the preset field and the first field can both be X-Forwarded-For fields.

[0119] In some embodiments, the CDN edge node can write the IP address of the CDN edge node in the preset field of the first request message, except for the target location.

[0120] In some embodiments, in response to any CDN intermediate node in the at least two cascaded CDN nodes receiving the second request message, the IP address of the CDN intermediate node can be written in the preset field of the second request message to obtain a reconstructed second request message. The CDN intermediate node can send the reconstructed second request message to the upper CDN node or the source station. In this way, the IP addresses of each CDN node through which the second request message passes can be added one by one in the preset field.

[0121] In some embodiments, the CDN edge node digitally signs the user IP address based on the target digital certificate obtained according to the target certificate address to obtain a digital signature result. The CDN edge node also writes the target certificate address in the first request message to obtain the second request message.

[0122] In some embodiments, the target certificate address can include at least a second domain name and a preset path. The second domain name can be a domain name agreed in advance by the CDN edge node and the target object. The preset path can be a path agreed in advance by the CDN edge node and the target object. The CDN preset node can be an intermediate CDN node in the cascade of at least two CDN nodes for checking the user IP address. The CDN preset node can be any CDN preset node of the present disclosure, which will not be repeated here.

[0123] For example, the target certificate address can be "http: / / example.com / cdn / cert1.pem". The target certificate address can include the second domain name "example.com" and the preset path "cdn". The "example.com" can be a domain name agreed in advance by the CDN edge node and the target object, and the "cdn" can be a path agreed in advance by the CDN edge node and the target object.

[0124] In some embodiments, a fifth field containing the target certificate address can also be written in the first request message to obtain the second request message. For example, the fifth field containing the target certificate address can also be written in the request header of the first request message to obtain the second request message.

[0125] For example, the fifth field can be "X-Real-Cert: http: / / example.com / cdn / cert1.pem".

[0126] The field name of the fifth field can be "X-Real-Cert", and the field value of the fifth field can be "http: / / example.com / cdn / cert1.pem".

[0127] In some embodiments, the target certificate address can be determined from at least two candidate certificate addresses. The domain name contained in the candidate address can be a domain name agreed in advance by the CDN edge node and the target object. The path contained in the candidate address can be a path agreed in advance by the CDN edge node and the target object. Different candidate certificate addresses correspond to different digital certificates. Moreover, all the candidate certificate addresses are located in the domain name and the path agreed in advance.

[0128] In some embodiments, a new target digital certificate can be created based on the first period. Moreover, the target certificate address of the created target digital certificate can contain a domain name that is pre-agreed between the CDN edge node and the target object, and the target certificate address of the created target digital certificate can contain a path that is pre-agreed between the CDN edge node and the target object. For example, the first period can be 1 minute. In this way, the target digital certificate can be updated based on the first period, so that the digital certificate used for digital signature can be dynamically changed, and the reliability of the digital signature can be improved.

[0129] For example, the target certificate address of the target digital certificate created at the first time based on the first period can be "http: / / example.com / cdn / cert1.pem". The target certificate address of the target digital certificate created at the second time based on the first period can be "http: / / example.com / cdn / cert2.pem".

[0130] In some embodiments, the target digital certificate used for digital signature can be updated based on the second period. For example, the newly created target digital certificate can be used as the target digital certificate for digital signature. Moreover, the first period and the second period can be asynchronous. In this way, a new target digital certificate can be created in advance to preheat the target digital certificate, and after the CDN edge node receives the first request message sent by the client and obtains the user IP address, the CDN edge node can quickly use the newly created target digital certificate to obtain the digital signature result for the user IP address.

[0131] In the embodiments of the present application, the target digital certificate used for digital signature can be written in the request header of the first request message to obtain the second request message. Here, in the case that the target object in the cascaded at least two CDN nodes receives the second request message, the target object can quickly obtain the target digital certificate based on the target certificate address carried in the second request message, so as to quickly verify whether the user IP address carried in the second request message is reliable based on the target digital certificate and the digital signature result carried in the second request message, and the speed of verifying whether the user IP address is reliable can be improved.

[0132] In some embodiments, the first request message is used to request to access the source station through the first domain name, and the method further includes:

[0133] Based on the first domain name and the preset path, a target certificate address is obtained; the target certificate address at least contains a second domain name and a preset path; the first domain name is within the coverage range of the second domain name.

[0134] In the embodiments of the present application, since the first domain name used for requesting access to the source station is within the coverage of the second domain name corresponding to the target digital certificate used for digital signature, the security of the target digital certificate used for digital signature under the second domain name can be improved, thereby improving the reliability of the verification of the user IP address based on the digital signature result.

[0135] In some embodiments, in response to the CDN intermediate node in the cascaded at least two CDN nodes receiving the second request message, if the digital signature result is carried in the second request message, and the second request message is used for the target object to verify the reliability of the user IP address in the received second request message, the CDN intermediate node can not perform other processing on the second request message, and the CDN intermediate node can directly forward the received second request message to the upper CDN node or the source station. That is, in the CDN intermediate node in the cascaded at least two CDN nodes, the step of performing digital signature on the user IP address to obtain the digital signature result by the CDN edge node of any one of the present disclosure can be skipped.

[0136] Exemplarily, the CDN intermediate node can skip the specific steps performed by the CDN edge node, including the steps of obtaining the IP address from the transmission layer connected by the CDN node and the client as the user IP address, obtaining the digital signature result for the user IP address, writing the user IP address obtained by the CDN node at the target position of the specific field in the request message received by the CDN node, and writing at least one of the digital signature result, the timestamp, the node information and the target certificate address in the request message received by the CDN node.

[0137] In some embodiments, in response to the CDN intermediate node in the cascaded at least two CDN nodes receiving the second request message, if the digital signature result is carried in the second request message, and the second request message is used for the target object to verify the reliability of the user IP address in the second request message, the IP address of the CDN intermediate node can be added to the preset field of the second request message, and no other processing is performed on the second request message to obtain the reconstructed second request message. The CDN intermediate node can send the reconstructed second request message to the upper CDN node or the source station.

[0138] Here, in the CDN intermediate node in the cascaded at least two CDN nodes, in addition to adding the IP address of the CDN intermediate node in the preset field, no additional processing is performed (i.e., the user IP address is not digitally signed to obtain the digital signature result, and the newly obtained digital signature result is not re-written in the second request message).

[0139] In some embodiments, at least one CDN intermediate node in the at least two CDN nodes in the cascade can belong to a different vendor than the CDN edge node. And / or, at least two CDN intermediate nodes can belong to different vendors. For example, the CDN edge node can belong to vendor A, and the CDN intermediate nodes can belong to vendor B. At this time, because the CDN nodes belong to different vendors, the standards adopted by the vendors for configuring the white list message or the request header of the request message of the CDN nodes are different, which causes some of the request messages transmitted by different vendors to be discarded or modified, resulting in a change in the IP address to be verified transmitted by the CDN edge node to the source station through the CDN intermediate nodes in the content distribution network CDN. Based on this, the message transmission method in the embodiments of the present application can be applied to provide reliable user IP addresses as reliable IP addresses to be verified for the client to provide service.

[0140] Referring to Figure 7 , Figure 2 is a flowchart of the message transmission method provided by the embodiments of the present application Figure 7 The message transmission method provided by the present application will be described below in conjunction with the steps shown in Figure 7

[0141] It should be noted that Figure 8 The execution subject of the flowchart shown can be a target object. The target object includes at least one of the following: a source station providing a service; and a CDN preset node in a content distribution network CDN, the CDN preset node being configured to verify the reliability of an IP address to be verified in a second request message received. The CDN preset node can be a CDN intermediate node in the content distribution network CDN, and the preset node is configured to verify a user IP address.

[0142] In step 2001, in response to the target object receiving a second request message transmitted by a CDN edge node through a content distribution network CDN, a digital signature result of an IP address to be verified and a user IP address are obtained from the second request message.

[0143] The IP address to be verified is an IP address located at a target position in a specific field of the second request message. The user IP address is a source Internet Protocol (IP) address obtained from a transmission layer connected to the CDN edge node by the client in a case where the CDN edge node receives a first request message sent by the client. The second request message sent by the CDN edge node is obtained after the CDN edge node writes the user IP address at the target position of the specific field of the first request message and writes the digital signature result in the first request message. The first request message is used to request a service.

[0144] ​In some embodiments, the source station in the target object has the ability to provide service for the client, and the CDN preset node in the target object does not have the ability to provide service for the client. The second request message can be used for the client to request the source station to provide service. At this time, in response to the CDN preset node receiving the second request message, and the CDN preset node being configured to check the to-be-checked IP address, if the user IP address passes the check, the CDN preset node does not provide service for the client. The CDN preset node transmits the to-be-checked IP address that passes the check to the source station, so that the source station takes the to-be-checked IP address that passes the check as a reliable user IP address, and provides service for the client based on the to-be-checked IP address that passes the check.

[0145] Alternatively, the CDN preset node and the source station can both have the ability to provide service for the client. The second request message can be used for the client to request at least one of the CDN preset node and the source station to provide service. At least one of the CDN preset node and the source station can respond to receiving the second request message, check the received to-be-checked IP address, and provide service for the client if the received to-be-checked IP address passes the check. It should be noted that in the case of including the CDN preset node in the content distribution network CDN, if the CDN preset node has already been used to provide service for the client, the second request message can not be forwarded to the source station. In the case of not including the CDN node in the content distribution network, the second request message needs to be sent to the source station, so that the source station provides service for the client.

[0146] In step 2002, the target object performs first checking on the reliability of the to-be-checked IP address based on the digital signature result in the received second request message.

[0147] In some embodiments, the target object can decrypt the digital signature result in the received second request message based on the target digital certificate to obtain a first digest message; and the target object can calculate the to-be-checked IP address based on a hash algorithm to obtain a second digest message. The target object can perform first checking on the reliability of the to-be-checked IP address by comparing the first digest message and the second digest message. In the case that the first digest message and the second digest message are different, the target object determines that the to-be-checked IP address does not pass the first checking. In the case that the first digest message and the second digest message are the same, the target object determines that the to-be-checked IP address passes the first checking.

[0148] In some embodiments, the target object can pre-store the target digital certificate. Alternatively, the target object receives a target certificate address in the second request message, and the target object can obtain the target digital certificate based on the target certificate address.

[0149] In some embodiments, in a case where the target object comprises a CDN preset node, the CDN preset node can write a check result of checking the reliability of the IP address to be checked into the second request message to obtain a reconstructed second request message. The CDN preset node can send the reconstructed second request message to the source station. The source station can obtain the check result for the user IP address from the received second request message, and determine whether the user IP address passes the check based on the check result. The check result at least indicates whether the IP address to be checked in the second request message in the CDN preset node passes the first check.

[0150] It should be noted that the CDN preset node can be a front node of the source station, i.e., the CDN preset node can be a CDN node directly connected to the source station. The CDN preset node can directly send the check result of checking the user IP address to the source station. Here, there is no need to use other CDN nodes to forward the check result obtained in the CDN preset node to the source station, thereby improving the consistency between the check result received by the source station and the check result sent by the CDN preset node.

[0151] In some embodiments, in response to the IP address of the CDN preset node being within the preset whitelist set by the source station, the source station can determine whether the user IP address passes the check based on the check result sent by the CDN preset node. Alternatively, in response to the IP address of the CDN preset node being outside the preset whitelist set by the source station, the source station can discard the check result sent by the CDN preset node. The check result can comprise a first check result or a second check result, the first check result indicating that the user IP address does not pass the check, and the second check result indicating that the user IP address passes the check.

[0152] It should be noted that since the front node of the source station has entered the intranet of the source station, the source station can accurately set the preset whitelist for the IP address and accurately determine the environment variable of the IP address (i.e., the IP address changes). Based on this, in a case where the CDN preset node is a front node of the source station, if the IP address of the CDN preset node is within the preset whitelist set by the source station, the source station can trust the check result determined by the CDN preset node for checking the IP address to be checked, and the source station can trust the IP address to be checked sent by the CDN preset node to the source station.

[0153] In the embodiments of the present application, the target object can verify the reliability of the IP address to be verified based on the digital signature result in the received second request message, so as to accurately determine whether the IP address to be verified is changed in the process of being transmitted from the CDN edge node to the target object. In this way, in the case that the IP address to be verified in the second request message received by the target object is changed compared with the IP address to be verified in the second request message initially generated by the CDN edge node, the target object can still accurately identify that the changed IP address to be verified is unreliable through the digital signature result in the received second request message, reduce the case of false response to the unreliable IP address to be verified, and improve the security of response to the IP address to be verified.

[0154] In some embodiments, the method further comprises:

[0155] At least one of the first timestamp and the target certificate address written by the CDN edge node is also obtained from the second request message; wherein the target certificate address is used to obtain a target digital certificate matched with the digital signature result;

[0156] Before the first verification of the reliability of the IP address to be verified based on the digital signature result in the received second request message, the second verification of the reliability of the IP address to be verified is performed based on at least one of the first timestamp and the target certificate address, and it is determined that the IP address to be verified passes the second verification.

[0157] It should be noted that before the first verification of the reliability of the IP address to be verified based on the digital signature result in the received second request message, the condition of determining that the IP address to be verified passes the second verification needs to be met. In the case that the condition of determining that the IP address to be verified passes the second verification is not met, the operation of performing the first verification of the reliability of the IP address to be verified based on the digital signature result in the received second request message is not triggered.

[0158] In some embodiments, in the case that the CDN preset node determines that the IP address to be verified does not pass the second verification, the CDN preset node can send the first verification result of any one of the present disclosure to the source station; wherein the first verification result is used to indicate that the IP address to be verified does not pass the verification.

[0159] It should be noted that the target certificate address can be used to obtain the target digital certificate, and the target digital certificate can be used to decrypt the digital signature result to obtain the first digest message of any one of the present disclosure.

[0160] In some embodiments, the target object obtains the digital signature result for the signature object and the to-be-verified object from the second request message; the signature object includes the user IP address and at least one of the first timestamp and the node information of the CDN edge node; the to-be-verified object includes at least one of the to-be-verified IP address, the to-be-verified timestamp and the to-be-verified node information; the to-be-verified IP address is the IP address at the target position in the preset field of the second request message; the to-be-verified timestamp is the timestamp in the third field of the second request message; and the to-be-verified node information is the timestamp in the fourth field of the second request message. The target object performs the first verification on the to-be-verified object based on the digital signature result in the second request message. It should be noted that the first verification on the to-be-verified object based on the digital signature result can be understood as verifying whether the to-be-verified object and the signature object are consistent based on the digital signature result. For example, verifying whether the to-be-verified IP address is consistent with the user IP address based on the digital signature result.

[0161] In some embodiments, the target object decrypts the digital signature result based on the target digital certificate in the received second request message to obtain a first digest message; and the target object can calculate the signature object of the digital signature result based on a hash algorithm to obtain a second digest message. In the case that the first digest information and the second digest information are the same, it is determined that all objects of the to-be-verified object pass the first verification. At this time, the to-be-verified IP address in the to-be-verified object passes the first verification. Or, in the case that the first digest information and the second digest information are different, it is determined that all objects of the to-be-verified object do not pass the first verification. At this time, the to-be-verified IP address in the to-be-verified object does not pass the first verification.

[0162] In some embodiments, in the case that the to-be-verified timestamp passes the first verification, the to-be-verified timestamp is determined as the first timestamp, and the reliability of the to-be-verified address is secondly verified based on at least one of the first timestamp and the target certificate address.

[0163] It should be noted that due to external attacks or different standard fields in the request header configured by different CDN nodes, the to-be-verified object carried in the second request message received by the CDN preset node or the source station may be different from the signature object in the second request message initially sent by the CDN edge node. Based on this, in the embodiments of the present application, whether the to-be-verified object changes can be verified based on the digital signature result for the signature object, so as to accurately determine whether the to-be-verified IP address in the to-be-verified object passes the first verification.

[0164] In the embodiments of the present application, the first check on the to-be-verified IP address can be performed based on at least one of the target certificate address and the first timestamp, and when it is determined that the to-be-verified IP address passes the first check, an operation of performing the second check on the reliability of the to-be-verified IP address based on the digital signature result in the second request message is triggered. In this way, the reliability of the to-be-verified IP address can be accurately determined based on multiple verifications on the reliability of the to-be-verified IP address.

[0165] In some embodiments, the second check includes at least one sub-check; and the check on the reliability of the to-be-verified IP address based on at least one of the first timestamp and the target certificate address includes at least one of the following:

[0166] In a case where the difference between the first timestamp and the current second timestamp is greater than the difference threshold, it is determined that the to-be-verified IP address does not pass the first sub-check in the second check; and in a case where the difference between the first timestamp and the second timestamp is less than or equal to the difference threshold, it is determined that the to-be-verified IP address passes the first sub-check.

[0167] In a case where the domain name included in the target certificate address is a preset domain name and the path included in the target certificate address is a preset path, it is determined that the to-be-verified IP address passes the second sub-check in the second check; and in a case where the domain name included in the target certificate address is not a preset domain name and / or the path included in the target certificate address is not a preset path, it is determined that the to-be-verified IP address does not pass the second sub-check.

[0168] In a case where the target digital certificate is successfully acquired based on the target certificate address, it is determined that the to-be-verified IP address passes the third sub-check in the second check; and in a case where the target digital certificate fails to be acquired based on the target certificate address, it is determined that the to-be-verified IP address does not pass the third sub-check.

[0169] In a case where the first domain name is within the coverage range of the domain name included in the target certificate address, it is determined that the to-be-verified IP address passes the fourth sub-check in the second check; or in a case where the first domain name is outside the coverage range of the domain name included in the target certificate address, it is determined that the to-be-verified IP address does not pass the fourth sub-check; wherein the first request message is used to request a service through the first domain name.

[0170] In a case where the to-be-verified IP address passes all the sub-checks, it is determined that the to-be-verified IP address passes the second check, otherwise it is determined that the to-be-verified IP address does not pass the second check.

[0171] In some embodiments, the target object can acquire the current second timestamp in response to receiving the second request message sent by the content distribution network (CDN). Alternatively, the target object can acquire the current second timestamp in response to acquiring the first timestamp from the received second request message.

[0172] In some embodiments, the first request message is used to request a service, and the second request message has the same function as the first request message, i.e., the second request message is also used to request the service. The target object determines the service type of the service requested by the client based on the received second request message, and determines the difference threshold value based on the service type of the service requested by the client. There can be a corresponding relationship between the service type and the difference threshold value. In the case where the difference between the first timestamp and the current second timestamp is greater than the difference threshold value, it is determined that the IP address to be verified fails the first sub-verification; in the case where the difference between the first timestamp and the second timestamp is less than or equal to the difference threshold value, it is determined that the IP address to be verified passes the first sub-verification.

[0173] In the embodiments of the present application, the timeliness of the second request message can be determined by judging the size relationship between the difference between the first timestamp and the second timestamp and the difference threshold value, so that in the case where the timeliness of the second request message is low, it is determined that the IP address to be verified fails the first sub-verification, i.e., the IP address to be verified is unreliable. In the case where the timeliness of the second request message is high, it is determined that the IP address to be verified passes the first sub-verification. In this way, the target object can adapt to the timeliness of the second request message and perform the first sub-verification on the reliability of the IP address to be verified of the target object.

[0174] In the embodiments of the present application, the reliability of the target certificate address can also be verified from multiple dimensions. In the case where the target certificate address is reliable, the IP address to be verified is further verified based on the target digital certificate obtained from the reliable target certificate address and the digital signature result carried in the second request message, to ensure the accuracy of the verification result obtained after verifying the IP address to be verified based on the digital signature result.

[0175] In some embodiments, after receiving the second request message, the target object can perform the following steps 1 to 5 in sequence:

[0176] Step 1, determining whether the difference between the first timestamp and the second timestamp is greater than the difference threshold value, to perform the first sub-verification on the IP address to be verified.

[0177] Step 2, determining whether the domain name contained in the target certificate address is a preset domain name and whether the path contained in the target certificate address is a preset path, to perform the second sub-verification on the IP address to be verified.

[0178] Step 3, obtaining the target digital certificate based on the target certificate address, to perform the third sub-verification on the reliability of the IP address to be verified.

[0179] Step 4, in the case that the second request message is used to request to access the source station through the first domain name, determining whether the first domain name is within the coverage of the domain name indicated by the target certificate address, to perform a fourth sub-check on the reliability of the IP address to be checked.

[0180] Step 5, performing a first check on the reliability of the IP address to be checked based on the digital signature result in the second request message.

[0181] It should be noted that the IP address to be checked can be determined to pass the second check in the case that the IP address to be checked passes all sub-checks. In the case that the IP address to be checked fails any sub-check, the IP address to be checked is determined to fail the second check.

[0182] In some embodiments, in response to the CDN preset node determining that the IP address to be checked fails at least one of the sub-checks in the first check and the second check, the CDN preset node sends a first check result to the source station; wherein the first check result indicates that the IP address to be checked fails the check. Alternatively, in response to the CDN preset node determining that the IP address to be checked passes all sub-checks in the first check and the second check, the CDN preset node sends a second check result to the source station; wherein the second check result is used to indicate that the IP address to be checked passes all checks.

[0183] In some embodiments, the method further comprises:

[0184] In the case that the IP address to be checked passes all checks, a preset response message to the second request message is sent to the client; wherein the preset response message is used to provide service to the client;

[0185] In the case that the IP address to be checked fails any check, at least one of an error code and an error message is sent to the client according to service requirements, or no response is made to the second request message.

[0186] It should be noted that the IP address to be checked passing all checks can be understood as: the IP address to be checked passing the first check and the second check. The IP address to be checked passing the second check can be understood as the IP address to be checked passing all sub-checks in the second check.

[0187] The IP address to be checked failing any check can be understood as: the IP address to be checked failing any check in the first check and the second check. The IP address to be checked failing the second check can be understood as the IP address to be checked failing any sub-check in the second check.

[0188] It should be noted that the not responding to the second request message can mean that the preset response message is not sent to the client, and the error code and the error message are not sent to the client. In this way, the situation that the client attacks the source station through the interaction between the client and the source station can be reduced, and the security of the source station can be improved.

[0189] It should be noted that at least one of the not responding to the second request message or the sending the error code and the error message to the client can be understood as rejecting the request of the client for the service.

[0190] In some embodiments, the service demand can be determined based on the service requested by the client. There can be a corresponding relationship between the service demand and the service requested by the client.

[0191] In some embodiments, the error message can be a description message for the error code. For example, the error code can be “404”, and the description message for the error code “404” can be “invalid request”, which is used to indicate that the request of the client for the service is invalid.

[0192] In some embodiments, a record log can be generated in the process of performing the related processing operation on the second request message. In response to receiving again the request message for indicating that the client requests the service, the request message can be further processed based on the related processing operation in the record log generated in the history. The related processing operation herein includes any one of the following: sending the preset response message to the client; sending at least one of the error code and the error message to the client; and not responding to the second request message.

[0193] For example, in response to the related processing operation in the record log generated in the history being at least one of the sending the error code and the error message to the client, if the request message for indicating that the client requests the service is received again within a short time, the same operation as the related processing operation recorded in the record log can be performed, that is, at least one of the error code and the error message is directly sent to the client. In this way, the request of the client can be quickly further processed based on the record log generated in the history.

[0194] In some embodiments, the target object includes a CDN preset node in a content distribution network (CDN), and the CDN preset node is configured to verify the IP address to be verified. The method further includes:

[0195] In response to the CDN preset node receiving the second request message, a preset field is obtained from the second request message. The preset field is used to list the IP addresses of all CDN nodes in the content distribution network (CDN) passed through one by one.

[0196] In a case where the IP address to be checked passes all the checks, the content of the preset field is replaced by the IP address to be checked, to obtain a reconstructed preset field;

[0197] The second request message carrying the reconstructed preset field is sent to the source station; the reconstructed preset field is used for the source station to determine that the IP address to be checked passes the check;

[0198] In a case where the IP address to be checked fails any check, the request of the client for the service is rejected, and at least one of an error code and an error message is sent to the client.

[0199] In some embodiments, in a case where the IP address to be checked fails any check, the CDN preset node adds a first check result of the IP address to be checked in the received second request message, and the first check result is used to indicate that the IP address to be checked fails the check.

[0200] In some embodiments, in a case where the IP address to be checked passes the check, the CDN preset node replaces the content of the preset field in the received second request message by the IP address to be checked, to obtain a reconstructed preset field; the CDN preset node sends the second request message carrying the reconstructed preset field and a second check result to the source station; the second check result is used to indicate that the IP address to be checked in the preset field passes the check.

[0201] In some embodiments, in a case where the IP address of the CDN preset node is in a preset whitelist set by the source station, the source station can trust the first check result or the second check result carried in the second request message sent by the CDN preset node. In a case where the IP address of the CDN preset node is not in the preset whitelist set by the source station, the source station can perform the second check and the first check on the IP address to be checked in the second request message in sequence.

[0202] In the embodiments of the present application, the CDN preset node checks the IP address to be checked under the entrustment of the source station. On the one hand, if the IP address to be checked passes all the checks, the content in the preset field can be directly replaced by the IP address to be checked, and the source station does not need to analyze the IP address of the passed CDN node, and can directly trust the IP address to be checked in the preset field, thereby improving the efficiency of the source station in determining the correct IP address to be checked. On the other hand, if the IP address to be checked does not pass any check, the source station does not need to perform related processing operations on the service request of the client, but the CDN preset node can directly replace the source station to reject the service request of the client or send at least one of the error message and the error code to the client, so as to replace the source station to perform related processing operations. In this way, the source station can reduce the steps of processing the request of the client, and release the processing resources of the source station.

[0203] In order to better illustrate the message transmission method in the embodiments of the present application, please refer to Figure 8 , Figure 3 is a flowchart of the message transmission method performed in the system 100 Figure 9 . The method includes steps 3001 to 3008, wherein,

[0204] In step 3001, the client 400 sends a first request message to the CDN edge node 300-1.

[0205] In step 3002, the CDN edge node 300-1 obtains an IP address from the transmission layer connected to the CDN edge node 300-1 as the user IP address.

[0206] In step 3003, the CDN edge node 300-1 obtains the digital signature result for the user IP address.

[0207] In step 3004, the CDN edge node 300-1 writes the IP address to be checked in the target position of the specific field of the first request message, and writes the digital signature result in the first request message, to obtain a second request message.

[0208] In step 3005, the CDN edge node 300-1 sends the second request message to the CDN preset node 300-2 through the content distribution network CDN.

[0209] It should be noted that the CDN preset node 300-2 is the upper-level CDN node of the CDN edge node 300-1. At this time, the CDN edge node 300-1 directly sends the second request message to the CDN preset node 300-2. Alternatively, the CDN edge node 300-1 is a first-level CDN node, and the CDN preset node 300-2 can be an M-th level CDN node. The CDN edge node can send the second request message to the CDN preset node 300-2 through the second-level CDN node to the M-1-th level CDN node.

[0210] In step 3006, the CDN preset node 300-2 obtains the IP address to be verified and the digital signature result for the user IP address from the received second request message, and performs a first verification on the reliability of the IP address to be verified based on the digital signature result in the second request message.

[0211] The IP address to be verified is the IP address located at the target location in the preset field of the second request message.

[0212] In step 3007, when the IP address to be verified passes all checks, the CDN preset node 300-2 replaces the content of the preset field in the second request message with the IP address to be verified, and obtains a reconstructed preset field.

[0213] In step 3008 , the CDN preset node 300 - 2 sends a second request message carrying the reconstructed preset field to the origin station 200 .

[0214] See Figure 9 , Figure 4 Schematic diagram of the process of executing the message transmission method in system 100 Figure 4 The method includes steps 4001 to 4006, wherein:

[0215] In step 4001, the client 400 sends a first request message to the CDN edge node 300-1.

[0216] In step 4002, the CDN edge node 300-1 obtains an IP address from the transport layer connecting the client 400 and the CDN edge node as the user IP address.

[0217] In step 4003, the CDN edge node 300-1 obtains a digital signature result for the user IP address.

[0218] In step 4004, the CDN edge node 300-1 writes the IP address to be verified into the target location of the preset field of the first request message, and writes the digital signature result into the first request message to obtain a second request message.

[0219] In step 4005, the CDN edge node 300-1 sends a second request message to the source station 200 through the content distribution network CDN.

[0220] In step 4006, the source station 200 obtains the IP address to be verified and the digital signature result for the IP address to be verified from the received second request message, and performs first verification on the reliability of the IP address to be verified based on the digital signature result in the received second request message.

[0221] In order to better understand the technical solutions in the embodiments of the present application, the present application exemplarily provides a message transmission method, comprising steps 51 to 55:

[0222] Step 51, creating a digital certificate. Existing https certificate can be used, or other certificates, or even self-signed certificates. As long as the source station needs to trust the certificate, and the domain name of the certificate can cover the domain name of the request, it is OK.

[0223] Step 52, when the request received by the CDN node already contains X-Real-IP, skip this step; otherwise, for requests that need to pass the real user IP address, the following content needs to be written in the http header:

[0224] 1), on the CDN edge node that establishes a four-layer connection with the client directly, when forwarding the request to the upper level or the source station, write the special user IP field (i.e. the specific field in the present application) such as “X-Real-IP: 192.0.2.33” in the constructed new request, and the IP comes from the IP address in the transmission layer between the user and the server;

[0225] 2), write the timestamp field, such as “X-Real-time: 1718350318523” (this example is a millisecond timestamp).

[0226] 3), write the target certificate address. For each different certificate, use a different address, but all are located in the preset domain name and path. For example, “X-Real-Cert: http: / / example.com / cdn / cert1.pem”.

[0227] 4), write the node information of the CDN node, such as “X-Real-Ext: sina cdn 001”.

[0228] 5), use the certificate to sign the aforementioned user IP address, timestamp, and node information, and write the digital signature result after base64, as shown below:

[0229] X-Real-Sign: RrGnD2UGRy37r8jtVnFeCc2+g5gMgsxMGTsmcNfUn3WIcvA2cV3hwsVnffmAxKGueTMo7OG3sOGT5fePR9JmosO67nlmDCLh.

[0230] Step 53, when the source station (final service server) or the front-end agent of the source station receives the request, the following operations are performed; if any item fails, the result is marked as "failure", i.e. the user IP address is unreliable:

[0231] 1) Verify the timestamp, if the timestamp exceeds the preset threshold;

[0232] 2) Determine that the download path of the certificate is within the pre-agreed domain name and path;

[0233] 3) Obtain and verify the certificate (cacheable);

[0234] 4) Verify the domain name of the certificate, match the domain name of the request;

[0235] 5) Verify the IP, time and related information through the aforementioned certificate;

[0236] The final service can refuse unreliable requests from the user IP address according to its own characteristics; or return a normal request in the case of knowing that the user IP address is unreliable.

[0237] Step 54, when the request received in step 53 is processed by the front-end agent, the reliable user IP address can replace the previously commonly used fields, such as replacing the X-Forwarded-For field or environment variables, and passing them to the source station. In this case, the source station trusts the IP address given by this agent through the preset solution (IP white list, environment variable, etc.). Since it has entered the business party's intranet here, the business party can conveniently set IP and strategy, and there is no problem of IP change being difficult to collect.

[0238] Step 55, when updating the related certificate:

[0239] 1) Sign and deploy a new certificate first, which needs to be located within the pre-agreed domain name and path, such as http: / / example.com / cdn / cert2.pem.

[0240] 2) (Optional) Sign individual requests with the new certificate, request the backend at a certain frequency (such as 1 per minute) to preheat the backend certificate cache

[0241] 3) After a period of time, switch the signing certificate to use the new certificate for signing.

[0242] The following continues to illustrate an exemplary structure of the embodiment of the message transmission device provided by the present application as a software module. In some embodiments, as shown in Figure 5 The electronic device 500 can be a CDN edge node, and the software module stored in the message transmission device 555 of the memory 550 can include: an obtaining module 5551, configured to obtain a source Internet Protocol (IP) address as a user IP address from a transmission layer connected with the CDN edge node in response to the CDN edge node receiving a first request message sent by a client in a content distribution network (CDN), wherein the first request message is used to request a service; obtain a digital signature result for the user IP address; a processing module 5552, configured to write the user IP address in a target position of a specific field of the first request message, and write the digital signature result in the first request message to obtain a second request message; and a sending module 5553, configured to forward the second request message to a target object through the CDN, so that the target object checks the reliability of a to-be-checked IP address in the second request message based on the digital signature result in the received second request message, wherein the to-be-checked IP address is an IP address in the target position of the specific field of the second request message.

[0243] In some embodiments, as shown in ​ The electronic device 500 can be a target object, and the software module stored in the message transmission device 556 of the memory 550 can include: an obtaining module 5561, configured to obtain a to-be-checked IP address and a digital signature result for a user IP address from a second request message in response to the target object receiving the second request message transmitted by a CDN edge node through a CDN, wherein the to-be-checked IP address is an IP address in a target position of a specific field of the second request message, and the user IP address is a source Internet Protocol (IP) address obtained from a transmission layer connected with the CDN edge node by the CDN edge node in a case where the CDN edge node receives a first request message sent by a client, the second request message sent by the CDN edge node is obtained after the CDN edge node writes the user IP address in the target position of the specific field of the first request message and writes the digital signature result in the first request message, and the first request message is used to request a service; and a checking module 5562, configured to perform a first check on the reliability of the to-be-checked IP address based on the digital signature result in the received second request message.

[0244] The embodiment of the present application provides a computer program product, which comprises a computer program or executable instruction stored in a computer readable storage medium. The processor of a computer device reads the computer program or executable instruction from the computer readable storage medium, and the processor executes the computer program or executable instruction, so that the computer device executes the message transmission method provided by the embodiment of the present application.

[0245] The embodiment of the present application provides a computer readable storage medium, which stores a computer program or executable instruction. When the computer program or executable instruction is executed by a processor, the processor executes the message transmission method provided by the embodiment of the present application.

[0246] In some embodiments, the computer readable storage medium can be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disc, or CD-ROM; or various devices comprising one or any combination of the above memories.

[0247] In some embodiments, the executable instruction can be in the form of a program, software, software module, script or code, written in any form of programming language (including a compiled or interpreted language, or a declarative or procedural language), and can be deployed in any form, including being deployed as an independent program or as a module, component, subroutine or other unit suitable for use in a computing environment.

[0248] As an example, the executable instruction can but not necessarily correspond to a file in a file system, can be stored in a part of a file storing other programs or data, for example, stored in one or more scripts in a Hyper Text Markup Language (HTML) document, stored in a single file dedicated to the program in question, or stored in multiple cooperative files (for example, files storing one or more modules, subroutines or code parts).

[0249] As an example, the executable instruction can be deployed to execute on one computing device, or on multiple computing devices located at one place, or on multiple computing devices distributed at multiple places and interconnected through a communication network.

[0250] The above is only an embodiment of the present application, and is not used to limit the protection scope of the present application. Any modification, equivalent replacement and improvement made within the spirit and scope of the present application shall be included in the protection scope of the present application.

Claims

1. A message transmission method, characterized by, The method comprises: obtaining a source Internet Protocol (IP) address as a user IP address from a transport layer to which a client is connected, in response to a CDN edge node in a content distribution network (CDN) receiving a first request message sent by the client, wherein the first request message is used to request a service; obtaining a digital signature result for the user IP address; writing the user IP address at a target position of a specific field in the first request message, and writing the digital signature result in the first request message to obtain a second request message; forwarding the second request message to a target object through the content distribution network (CDN), so that the target object checks the reliability of a to-be-checked IP address in the second request message based on the digital signature result in the received second request message, wherein the to-be-checked IP address is an IP address at the target position in the specific field of the second request message.

2. The message transmission method according to claim 1, characterized in that, The target object comprises at least one of: a source station that provides a service; a CDN preset node in the content distribution network (CDN), which is configured to check the reliability of the to-be-checked IP address.

3. The message transmission method of claim 1, wherein, The method further comprises: writing the first timestamp in the first request message to obtain the second request message. The first request message is used to request a service through a first domain name. The method further comprises:

4. The message transmission method according to any one of claims 1 to 3, characterized in that, obtaining a target certificate address based on the first domain name and a preset path, wherein the target certificate address at least contains a second domain name and the preset path, and the first domain name is within the coverage of the second domain name; obtaining a digital signature result for the user IP address based on a target digital certificate obtained according to the target certificate address; The method further comprises: writing the target certificate address in the first request message to obtain the second request message. The method comprises: ​ 5. A message transmission method characterized by, ​ In response to the target object receiving a second request message transmitted by a CDN edge node through a content distribution network (CDN), obtaining a to-be-verified IP address and a digital signature result for a user IP address from the second request message; wherein the to-be-verified IP address is an IP address located at a target position in a specific field of the second request message; the user IP address is a source Internet Protocol (IP) address obtained by the CDN edge node from a transmission layer connected with the CDN edge node in a case where the CDN edge node receives a first request message sent by a client; the second request message sent by the CDN edge node is obtained after the CDN edge node writes the user IP address at the target position of the specific field of the first request message and writes the digital signature result in the first request message; and the first request message is used to request a service. Performing a first verification on the reliability of the to-be-verified IP address based on the digital signature result in the received second request message.

6. The message transmission method according to claim 5, characterized by, The method further comprises: Further obtaining at least one of a first timestamp and a target certificate address written by the CDN edge node from the second request message; wherein the target certificate address is used to obtain a target digital certificate matching the digital signature result. Before the first verification on the reliability of the to-be-verified IP address based on the digital signature result in the received second request message, performing a second verification on the reliability of the to-be-verified IP address based on at least one of the first timestamp and the target certificate address, and determining whether the to-be-verified IP address passes the second verification.

7. The message transmission method according to claim 6, characterized in that, The second verification comprises at least one sub-verification; and the second verification on the reliability of the to-be-verified IP address based on at least one of the first timestamp and the target certificate address comprises at least one of the following: In a case where a difference between the first timestamp and a current second timestamp is greater than a difference threshold, determining that the to-be-verified IP address fails a first sub-verification of the second verification; and in a case where the difference between the first timestamp and the second timestamp is less than or equal to the difference threshold, determining that the to-be-verified IP address passes the first sub-verification; In a case where a domain name contained in the target certificate address is a preset domain name and a path contained in the target certificate address is a preset path, determining that the to-be-verified IP address passes a second sub-verification of the second verification; and in a case where the domain name contained in the target certificate address is not the preset domain name and / or the path contained in the target certificate address is not the preset path, determining that the to-be-verified IP address fails the second sub-verification; In a case where a target digital certificate is successfully obtained based on the target certificate address, determining that the to-be-verified IP address passes a third sub-verification of the second verification; and in a case where the target digital certificate fails to be obtained based on the target certificate address, determining that the to-be-verified IP address fails the third sub-verification. determining that the IP address to be verified passes the fourth sub-check of the second check in a case that the first domain name is within a coverage of domain names contained in the target certificate address, or determining that the IP address to be verified fails the fourth sub-check of the second check in a case that the first domain name is outside the coverage of domain names contained in the target certificate address; wherein the first request message is used to request a service from the first domain name; determining that the IP address to be verified passes the second check in a case that the IP address to be verified passes all sub-checks, or determining that the IP address to be verified fails the second check in a case that the IP address to be verified fails any sub-check.

8. The message transmission method according to any one of claims 5 to 7, characterized in that, The target object includes at least one of a CDN preset node in the content distribution network (CDN) and a source station for providing a service. The CDN preset node is configured to verify the reliability of the IP address to be verified. The method further includes: sending a preset response message for the second request message to the client in a case that the IP address to be verified passes all checks, wherein the preset response message is used to provide a service for the client; in a case that the IP address to be verified fails any check, not responding to the second request message according to a service requirement, or sending at least one of an error code and an error message to the client.

9. The message transmission method according to any one of claims 5 to 7, characterized in that, The target object includes a CDN preset node in the content distribution network (CDN), and the CDN preset node is configured to verify the IP address to be verified. The method further includes: obtaining a preset field from the second request message in response to the CDN preset node receiving the second request message, wherein the preset field is used to list IP addresses of all CDN nodes in the content distribution network (CDN) one by one; replacing content of the preset field with the IP address to be verified to obtain a reconstructed preset field in a case that the IP address to be verified passes all checks; sending the second request message carrying the reconstructed preset field to a source station, wherein the reconstructed preset field is used for the source station to determine that the IP address to be verified passes the verification; in a case that the IP address to be verified fails any check, rejecting a request of the client for a service, and sending at least one of an error code and an error message to the client.

10. A message transmission apparatus characterized by comprising: includes: The acquisition module is configured to obtain a source Internet Protocol (IP) address as a user IP address from a transmission layer in which a client and a CDN edge node are connected in response to the CDN edge node receiving a first request message sent by the client, wherein the first request message is used to request a service, and obtain a digital signature result for the user IP address. The processing module is configured to write the user IP address at a target position of a specific field in the first request message, and write the digital signature result in the first request message to obtain a second request message. The sending module is configured to forward the second request message to a target object through the content distribution network (CDN) so that the target object checks the reliability of an IP address to be checked in the second request message based on the digital signature result in the received second request message, wherein the IP address to be checked is an IP address located at the target position in the specific field of the second request message.

11. A message transmission apparatus characterized by comprising: The method comprises: The obtaining module is configured to, in response to the target object receiving a second request message transmitted by a CDN edge node through a content distribution network (CDN), obtain an IP address to be checked and a digital signature result for a user IP address from the second request message, wherein the IP address to be checked is an IP address located at a target position in a specific field of the second request message, the user IP address is a source Internet Protocol (IP) address obtained by the CDN edge node from a transmission layer connected with the CDN edge node in a case where the CDN edge node receives a first request message sent by a client, the second request message sent by the CDN edge node is obtained after the CDN edge node writes the user IP address at the target position of the specific field of the first request message and writes the digital signature result in the first request message, and the first request message is used to request a service; The checking module is configured to perform a first check on the reliability of the IP address to be checked based on the digital signature result in the received second request message.

12. An electronic device, comprising: The electronic device comprises: a memory configured to store executable instructions; a processor configured to execute the executable instructions or computer programs stored in the memory, and realize the method in any one of claims 1 to 4 or 5 to 9.

Images