TW201608850A - Method for detecting a number of client terminals from the internet request traffics sharing the public IP address and system for detecting the same - Google Patents

Abstract

The present invention is provided a method and a system for detecting the number of client terminals on the private network using the same public IP address from the internet request traffics sharing the public IP address, the method comprising the following steps of: mirroring DNS request message traffic of the client terminals, forwarding the mirrored DNS request message traffic to the push server; extracting a DNS Request message information, wherein the push server parse (Parsing) the mirrored traffic to ensure that the mirrored traffic is a DNS request message, extracting the transaction ID and domain name as information required for generation of a fake DNS response message; generating fake DNS response message and transmitting it to the client terminal, wherein TTL(Time To Live) of its answer field is set to a value designated by the push server; and calculating the number of devices of the client terminal by counting the maximum times of transmissions of DNS request message which is for the same domain with the same ID or the same public IP address of the client terminal during the time period.

Description

Method and system for detecting the number of clients in the Internet requesting public IP address

The present invention relates to a method for detecting the number of clients of an Internet requesting traffic from a public IP address and a public IP sharing state detecting system. More particularly, the present invention relates to a method and system for detecting the number of multiple clients on a private network using the same public IP address to use IP between Internet service users The router detects multiple access users in case the users of the Internet service users pass through an IP router with IP address translation function through multiple terminals (such as NAT or Internet sharing a single public IP beyond the line) The router) is connected to the Internet service network provided by the ISP.

In recent years, in the case of simultaneous connection to a network for a client such as a plurality of PCs, the public IP sharing state often uses Internet services by using an IP router having a single public IP assigned to the Internet service user. The Internet service user is shared among multiple terminals for simultaneous use of Internet services, and in the company or enterprise, NAT (network address translation) is configured in the router for internal network and external A firewall is built between the Internet and private IP is used in the internal network.

On the other hand, an Internet service provider (ISP: Internet Service Provider) has Restricted network resources, such as network devices, network maintenance budgets, and network speeds in the infrastructure of the present invention. If the frequency of use of the NAT or IP router is increased, multiple users are connected for one line that is supplied via the network. As a result of these multiple connections, there has been a tremendous increase in traffic. In this case, there is a public IP line for Internet service with respect to one client (PC or smart device) or with respect to each client (PC or smart device) of a plurality of clients. Ordinary users of multiple public IP lines will encounter relatively large deficiencies.

It is necessary to detect multiple connections via a plurality of client devices (user terminals, user PCs or smart terminals) that exceed the public IP line corresponding to the Internet service subscriber line. For this reason, it is necessary to track the real IP address (private IP address) of the client device connected to the Internet service, but it is not possible to have a real IP address (private IP address) outside the internal network. Because the user's real IP address (that is, the private IP address) should be transferred to the public IP address via a NAT or IP router. Therefore, it is also difficult to detect which private IP address is normally used via a public IP address.

In order to solve this problem, Korean Patent No. 10-0723657 (published May 23, 2007) discloses a technical solution for accurately obtaining each user in a private network by using a specific public Internet IP. Don't use IP privately and use the user's information at the same time. More specifically, the following procedure is recommended.

- Redirect all work phases to connect to the first domain in the private network using a specific public IP (Internet IP) to analyze the TCP/IP packet to the sharer's domain in the request page

- Capture user private IP at the same time

- Build a DB (Library) to see how many users are using the Internet at the same time

- When multiple private IP users selectively access and block to the Internet based on TCP/IP by using the above DB (database) to simultaneously access the Internet via the same specific public IP line (Transmission Control Protocol/Internet) Internet access

However, this technique can be accomplished only by a small program that installs and executes the application on the user's computer. However, if the user can recognize the installation or execution of the applet, the user will delete the applet or stop its execution. Therefore, it cannot be an appropriate final solution.

Meanwhile, in order to solve the deficiencies of the prior art mentioned above, the Korean Patent Application Laid-Open Publication No. 10-2009-0041752 (published Apr. 29, 2009) teaches another prior art. According to another prior art, a technique is used to find the exact number of devices on the user side by accurately detecting an algorithm, and the exact detection algorithm has a private number of users to be detected. A web browser small text file (cookie) generated in a plurality of devices on the client side is used in the network. This prior art also teaches a TCP/IP based technique in which the monitoring server blocks the internet connection of the client device by using a small text file set updated by the time interval under the private network. The District DB Information and Work (JOB) scheduler is selected when a specific public IP private network user attempts to connect an Internet connection that exceeds the allowable number of lines to the Internet connection at the same time.

[Invention goal]: Technical problems of prior art

However, according to one of the prior art methods for detecting and blocking an IP router or for detecting and blocking one of the IP routers, the system is using a small text file stored in a specific area of the user's computer for detection. A heavy user of an IP router with an IP address sharing function. These small text files will be provided for a standard HTTP protocol extension to be operated by a web browser (ie, application level) to give continuity to the client side, followed by a known location on one of the user's computer hard drives. These small text files are stored in the middle, and most computer users also know how to delete small text files.

If a small text file is stored in one batch, due to one of the problems of reduced internet speed, the web browser provides the ability to delete small text files by default after a predetermined period of time.

However, when you re-operate the web browser during the internet connection, delete the small When a text file is generated to generate web traffic with one of the new small text files, the blocking system from one terminal (one computer) is mistakenly considered to have the same public IP according to the prior art blocking system described above. Another web page of another terminal (another computer; another small text file) of the address (ie, another service via the same IP router).

And this can cause a problem for ordinary users of traffic blocking errors, which greatly damages the security of the services provided by the Internet Service Provider (ISP).

In addition, this small text file has a problem in that when used with several types of browsers in a single device (for example, Microsoft Internet Explorer, Google Chrome, Firefox, Opera, Safari, etc.), the same terminal can be Different browsers recognize different terminals, which are because the files must be individually controlled by the type of web browser features. As a result of this confusion, it can cause problems for a general user who mistakes a terminal for a plurality of terminals for a traffic blocking error.

In order to solve this problem and to overcome the dependency by the web browser, Korean Patent No. 10-108791 (published on Nov. 29, 2011) proposes a method which, in addition to the step of confirming the number of devices using a small text file, further includes A step for checking a flashing small text file that was generated in a particular location in the terminal in the past.

However, in this method, it is difficult to continuously maintain the location of the flash small text file storage, and when the manufacturer of the web browser newly generates or updates a browser, the location and storage of a flash small text file storage can be changed. One of the flashing small text files calls the program. Moreover, if this change occurs, it is possible to generate a new flash small text file by the failure of calling the flash small text file that has been stored by the first web browser in the case of using the second web browser. As a result of generating a new flash small text file, it can cause problems for a normal user who mistakes a terminal for a plurality of terminals for a traffic blocking error.

Therefore, in order to maintain the security of the services provided by the Internet Service Provider (ISP), The system for this method places a burden on performing changes to the continuous monitoring management feature relative to the location of the flashing small text file store and its calling program according to the type of web browser.

[Summary of the Invention]: Technical Solution

According to an aspect of the present invention for solving the problem with respect to the prior art described above, a client for using the same public IP address on an Internet requesting traffic detection private network from a shared public IP address is provided. A method of quantity, the method comprising the steps of: (I) transmitting a DNS request message to a DNS (domain name system; when the user operates a web browser and requests a connection to a website on the Internet; The domain or host name is interpreted as an IP address server consisting of a plurality of digits on the network to identify the IP address of a website domain (eg, www.naver.com) to be accessed by the client. (II-1) Mirroring the DNS request message of the client, wherein one of the mirror copying devices provided in the backbone network of the ISP (Internet Service Provider) copies the DNS request generated by the client Message service, and the mirrored copy of the DNS request message service is forwarded to the push server; (II-2) extracts a DNS request message information, wherein the push server parses the mirrored copy of the message to ensure The mirrored copy of the service is a DNS request. And extract the transaction ID and domain name as the information needed to generate a fake DNS response message; (III) generate a fake DNS response message and transmit it to the client, where the push server confirms that the extracted domain is The in-monitoring domain monitored by the push server converts the domain name into the domain IP only in the case of the monitored domain, generates a fake DNS response message and transmits the fake DNS response message to the user. End, wherein the fake DNS response message includes an extracted transaction ID and a converted domain IP, and wherein the TTL (residence time) of the response field is set to a value specified by the push server (for example, 2 hours) (IV-1) transmitting the DNS history information from the push server to the analysis server, wherein the DNS history information includes the response time for transmitting the fake DNS response message to the client, the domain requested by the client, and the client. Public IP address or ID; (IV-2) storing the IP address of the specific domain to the core of the operating system, wherein when the user receives a fake DNS response message, the client connects to the specific website domain and stores it as the push server. The IP address obtained by interpreting the results of the DNS of the particular domain in the core of the operating system during the specified time period to prevent the UE from generating DNS requests for a particular domain during the time period specified by the push server a message; (V) storing the DNS history information received by the analysis server from the push server to a first DB server, wherein the DNS history information includes a response time for transmitting the fake DNS response message to the client, by the client Requesting the public domain IP address or ID of the domain and the client; and (VI) calculating the number of devices on the client side, wherein the analysis server is stored by the push server by using a first DB server DNS history information and the specified number of times (TTL value; for example, 2 hours) is used to count the maximum number of transmissions of DNS request messages for the same domain with the same ID of the client or the same public IP address. IP road The number of devices on the client side of the combination is used to use the same public IP address.

More specifically, if the IP address as the result of the DNS interpretation of the specified domain is stored in the core of the operating system, the client connects to the specified domain by using an IP address stored in the core of the operating system. And a DNS request message for re-connection of the specified domain is no longer generated by the UE.

A client device may not send a DNS request message multiple times during a time period (TTL value) specified by the push server for the same domain. Therefore, if the maximum number of transmissions of DNS request messages for the same domain with the same ID of the client or the same public IP address during the period specified by the push server (TTL value; for example, 2 hours) Counting, the analysis server can calculate the number of devices requesting the client to connect to the specified domain of the same public IP address during the time period.

However, in the step of transmitting the DNS history information from the push server to the analysis server, the push server transmits the DNS history information to the analysis server, the DNS history information packet. The response time for transmitting the fake DNS response message to the client, the domain IP address requested by the client, and the public IP address or ID of the client. At this time, if the push server attempts to transmit the ID of the client terminal instead of the public IP address to the analysis server, it is possible to provide an instant user IP allocation history from a second DB server. The second DB server provides functionality that is different from the first DB server described above, which can be a physical integration configuration of the first DB server. Alternatively, the second DB server can be configured in isolation from the first DB server entity.

In addition, the present invention also provides a public IP shared state detection system in one of the other types of diagrams.

[Advantageous effects of the present invention]

According to the present invention, it is possible to detect a more accurate over-utilization state from the UE to access the Internet using the same public IP via an IP router. More specifically, unlike the small text file according to the prior art, the user in the step of detecting cannot easily remove the DNS analysis result stored for use in the time period set forth in the core phase of the operating system. Therefore, if it is excessively estimated to be larger than the real number of the client by the elimination of the small text file according to the prior art, it is possible to prevent the occurrence of a line failure with respect to the internet connection.

In addition, the above prior art is used as a detector flash sharing object ("flash shared object", referred to as a flash small text file) for further recommendation to solve the dependency problem of a web browser having a typical small text file. The system operator should continuously monitor whether the storage location of the flash shared object is maintained relative to the traffic on each web browser of various web browsers. However, according to the present invention, if the operating system has no change, it can be maintained by how various web browsers store the fake DNS response message in the core of the operating system. Therefore, the operation of the detection system is excessively used with respect to the IP router, according to The detection method or system of the present invention provides an impact to reduce the chance of false detection and reduce operating costs.

100‧‧‧IP router

200‧‧‧ Public IP shared status detection system

210‧‧‧Mirror copying device

220‧‧‧Pushing server

230‧‧‧Analysis server

240‧‧‧First DB server

300‧‧‧Internet

310‧‧‧DNS server

1 is a schematic diagram illustrating an exemplary embodiment of a detection system for use with the present invention; and FIG. 2a is a diagram illustrating steps performed in accordance with an exemplary embodiment of the present invention for detecting A general flow diagram of the number of clients on the private network using the same public IP address, and Figure 2b is a specific flow diagram illustrating the steps of generating and transmitting a fake DNS response message executed by the push server; Figure 3 is an illustration Generating a first execution state of the DNS request message in the UE to connect to a schematic state diagram of the specific domain; FIG. 4 is a view illustrating the mirror copy DNS request message of the client and will be mirrored after the state of FIG. Schematic diagram of the execution status of the replicated DNS request message traffic to the push server; Figure 5 is a schematic diagram illustrating the execution status of the mirrored copy of the DNS request message and the extracted DNS request message information. FIG. 6 is a screen capture image illustrating an exemplary embodiment of a DNS request message service; FIG. 7 is a main execution step illustrating a push server generating a fake DNS response message and transmitting it to the execution state of the client. Schematic state diagram; Figure 8a is a screen capture image illustrating an exemplary embodiment of a fake DNS response message made from extracted DNS request message information; and Figure 8b shows the answer field more accurately The TTL (residence time) has been set to 2 hours; Figure 9 is a schematic diagram illustrating the procedure by which the push server transmits DNS history information to the analysis server and the analysis server stores it in the first DB (database) server. FIG. 10a is a schematic state diagram illustrating an exemplary embodiment of a program for computing the number of devices using a client terminal of the same public IP address by utilizing DNS history information stored in the first DB server; 10b is a schematic state diagram illustrating an exemplary embodiment added by an additional program providing an instant user IP allocation history; FIG. 11 is a schematic state diagram illustrating the following procedure: when the client receives a fake DNS response message, the client Storing an IP address obtained by interpreting the DNS of the particular domain into the core of the operating system during the time period specified by the push server to prohibit the client from being during the time period specified by the push server Generate DNS request messages for specific domains Interest, and the client connects to a specific website domain.

In the following, an exemplary embodiment of the present invention provided to detect the number of clients in a private network using the same public IP address will be described with reference to the accompanying drawings.

Referring to the basic construction and flowchart of FIG. 1, FIG. 2a, FIG. 2b and FIG. 3 to FIG. 11, an exemplary embodiment of the disclosed IP shared state detection system according to the present invention will be described.

As shown in FIG. 1, an exemplary embodiment of a disclosed IP shared state detection system (200) according to the present invention includes a mirror copying device (210), a push server (220), an analysis server (230), and a A DB server (240) and an additional second DB server (see Figure 10b). More specifically, the above components work as follows.

The image replication device (210) is a device that is located in a backbone network of an Internet service provider (ISP; Internet Service Provider) and is provided for use in DNS request message services (see figure) 3) From the client side image copy (see Figure 4) to the DNS server to obtain the IP address of the specific domain, the client is the user end of the ISP user (PC-1, PC-2, smart phone-1 , Smart TV-1), wherein the specific domain is the target website domain (for example, www.naver.com) of the Internet (300) requested by the client to operate the web browser.

The push server (220) is a device provided for performing the following operations: profiling (see FIG. 5) mirrored copy of the message to ensure that the mirrored copy of the message is a DNS request message; extracting as a generating fake DNS The transaction ID and domain name of the information required to respond to the message (see Figure 6); confirm that the extracted domain is the monitored monitored domain; convert the domain name to the domain only if the domain is being monitored IP; generates a fake DNS response message including the extracted transaction ID and the translated domain IP (see FIG. 8a); and transmits the generated fake DNS response message to the client (see FIG. 7), where (false DNS response message) The TTL (residence time) of the reply field is set to the value specified by the push server (for example, 2 hours; see Figure 8b). In addition, the push server (220) transmits the DNS history information to the analysis server (230) (refer to FIG. 9), wherein the DNS history information includes a response time for transmitting the fake DNS response message to the user terminal, The public IP address or ID of the domain and client requested by the client.

And, the analysis server (230) is a device provided for performing the following operations: including a response time for transmitting the fake DNS response message to the client, a public domain IP address requested by the client, and a public IP address of the client. The DNS history information of the address or ID is stored to the first DB server (240); and is specified by counting by the push server (220) by utilizing the DNS history information stored in the first DB server (240) The number of devices for calculating the number of UEs combined via the IP router (100) for the maximum number of transmissions of the DNS request message with the same ID of the client or the same domain of the same public IP during the period (TTL value; for example, 2 hours) To use the same public IP address.

However, the self-pushing server (220) to the analysis server (230) transmits a response time including transmitting the fake DNS response message to the client, a public domain IP address or ID of the domain requested by the client and the client. DNS history information, if the push server (220) attempts to transmit the client ID instead of the public IP address to the analysis server (230), it is possible to provide instant user IP allocation from the second DB server. history. The second DB server provides functionality that is distinct from the first DB server (240) described above, which can be a physical integration configuration of the first DB server (240). Alternatively, the second DB server can be configured in isolation from the first DB server (240) entity.

According to the present invention, if the IP address as the result of the DNS interpretation of the specified domain is stored in the core of the operating system, the client connects to the specified domain by using the IP address stored in the core of the operating system, and Then, the UE generates a DNS request message for specifying reconnection of the domain.

Therefore, a client device may not transmit a DNS request message multiple times during a time period (TTL value) specified by the push server (220) for the same domain (eg, www.naver.com). Therefore, if the count is used during the time period specified by the push server (220) (TTL value; for example, 2 hours), the transmission of the DNS request message for the same domain having the same ID of the client or the same public IP address is transmitted. The maximum number of times, the analysis server (230) can calculate the request to the time The number of devices that connect to the client of the specified domain of the same public IP address during the segment. If the results of these analyses are updated over a period of time, it is possible to identify the minimum number of clients on the private network (the number of clients simultaneously connected via the IP router) to connect to the same public IP via the IP router (100).

With regard to the inventive method, as illustrated by the flow chart shown in Figures 2a, 2b and the schematic state diagrams shown in Figures 3 to 11 drawn with reference to Figure 1 of the basic construction diagram, it is provided in accordance with the present invention. An exemplary embodiment of a method for detecting the number of clients from an Internet requesting a public IP address, the method comprising the steps of:

(I) Step (S100): When the client operates the web browser and requests a connection to a website on the Internet, the DNS request message is transmitted to the DNS server (310) (the domain name system; The host name is interpreted as an IP address consisting of a plurality of digits on the network) to identify the website domain to be accessed by the client (PC, smart phone, tablet PC, smart TV, etc.) (eg, Www.naver.com) IP address; (see arrow 1 and arrow 2 in Figure 3)

(II-1) Step (S200): Mirroring the DNS request message of the client, wherein the mirror copying device (210) provided in the backbone network of the ISP (Internet Service Provider) is mirrored by the user The generated DNS request message service and forwards the mirrored copy of the DNS request message to the push server (220); (see arrow 3 in FIG. 4)

(II-2) Step (S300): Extracting DNS request message information, wherein the push server (220) parses (S310) the mirrored copy of the DNS request message service (see FIG. 6) to ensure (S320) mirrored copy The service is a DNS request message, and extracts (S330) the transaction ID and the domain name as the information required to generate the fake DNS response message; (see arrow 4 in FIG. 5)

(III) Step (S400): generating a fake DNS response message and transmitting it to the client, wherein the push server (220) confirms (S410 in FIG. 2b) the extracted domain is the push server (220) Monitoring the monitored domain (in the design, the system pre-selects a certain number of domains, such as frequently accessed Internet portals), and only the domain name in the case of monitoring the domain The conversion (S420 in Figure 2b) is referred to as the domain IP, and a false DNS response message (see Figure 8a and Figure 8b) is generated (S430 in Figure 2b), and the fake DNS response message is transmitted (S440 in Figure 2b). To the user end, wherein the fake DNS response message includes the extracted transaction ID and the converted domain IP, and wherein the TTL (residence time) of the reply field is set to a value specified by the push server (220) (for example, 2) Hour); (see arrow 5 in Figure 7)

(IV-1) Step (S500): transmitting the DNS history information from the push server (220) to the analysis server (230), wherein the DNS history information includes a response time for transmitting the fake DNS response message to the user end, The public IP address or ID of the domain and client requested by the client; (see arrow 6 in Figure 9)

(IV-2) Step (SC500): The IP address of the specific domain is stored in the core of the operating system, wherein when the user receives the fake DNS response message, the client connects to the specific website domain (see Figure 11). Arrow 6'), and stored as a result of DNS of a particular domain in the core of the interpretation operating system (see arrow 6" in Figure 11) during the time period (TTL value) specified by the push server IP address to prevent the UE from generating a DNS request message for a specific domain during the time period (TTL value) specified by the push server; (V) step (S600): via the analysis server (230) The DNS history information received by the push server (220) is stored in the first DB server (240), wherein the DNS history information includes a response time for transmitting the fake DNS response message to the client, and a domain requested by the client ( Www.naver.com) and the public IP address (Ip-Addr1) or ID (USER-1) of the client; (see arrow 7 in Figure 9); and (VI) step (S700): calculate the user side The number of devices, wherein the analysis server (230) is configured by utilizing a DNS stored in a first DB server (240) by the push server (220) Historical information and specified period (TTL value; for example, 2 hours) during the maximum number of transmissions of DNS request messages for the same domain with the same ID of the client or the same public IP address is counted and calculated via the IP router The number of devices combined to use the same public IP address (see arrow 8-1 in Figure 10a and arrow 8-2 in Figure 10b). Further, as a specific step of constructing the step of extracting the DNS request message information (S300), the step of ensuring that the mirrored copy of the message is a DNS request message (S320) includes: confirming the format of the DNS request message; and verifying the DNS The field value of the request message (for example, the response value of the flag field = 0, the job code value of the flag field = 0, the value of the question field = 1, the type value of the query field = 1, the query field The rating value = 1).

In addition, in the case where the IP address as the result of the DNS interpretation of the specified domain is stored in the core of the operating system, the UE connects to the specified domain by using the IP address stored in the core of the operating system, and Then, the UE generates a DNS request message for specifying reconnection of the domain.

Therefore, a client device may not transmit a DNS request message multiple times during a time period (TTL value) specified by the push server (220) for the same domain (www.naver.com). Therefore, if the time period is counted as shown in Figures 10a and 10b for the period specified by the push server (220) (TTL value; for example, 2 hours) for the same ID with the client or the same public IP The maximum number of times the DNS request message of the same domain of the address is transmitted, the analysis server (230) can calculate the request to the client of the connection of the specified domain sharing the same public IP address (IP-Addr1) during the time period. The number of devices.

Meanwhile, in the step of transmitting the DNS history information to the analysis server (S500), when the push server (220) includes the response time for transmitting the fake DNS response message to the client, the domain requested by the client and When the DNS history information of the public IP address or ID of the client is sent to the analysis server (230), the instant user IP allocation history may be provided from the second DB server for using the ID of the user terminal instead of the user. The IP address of the terminal is transmitted to the analysis server (230) as shown in Figure 10b.

Although the technical spirit of the present invention has been described with reference to the accompanying drawings, the description of the DNS request message and the fake response message such as illustrated in FIG. 6, FIG. 8a and FIG. 8b does not limit the present invention, but merely explains the preferred embodiment of the present invention. example. In addition, those skilled in the art will understand that they can Various changes and modifications may be made without departing from the spirit and scope of the invention as defined by the scope of the claims.

100‧‧‧IP router

200‧‧‧ Public IP shared status detection system

210‧‧‧Mirror copying device

220‧‧‧Pushing server

230‧‧‧Analysis server

240‧‧‧First DB server

300‧‧‧Internet

310‧‧‧DNS server

Claims (5)

A method for detecting the number of clients of an Internet requesting traffic from a public IP address according to the present invention, the method comprising the following steps: (I) step (S100): when the clients operate a webpage When the browser requests a connection to one of the websites on the Internet (300), the DNS request message is transmitted to the DNS server (310) (the domain name system; it interprets the domain or host name into a network An IP address consisting of a plurality of digits on the road) to identify a website domain to be accessed by such clients (PC, smart phone, tablet PC, smart TV, etc.) (eg, www.naver. Com) of the IP addresses; (II-1) step (S200): mirroring the DNS request message services of the clients, which are provided in the backbone network of the ISP (Internet Service Provider) One of the mirror copying devices (210) mirrors the DNS request message service generated by the clients, and forwards the mirrored copy of the DNS request message to the push server (220); (II- 2) Step (S300): Extracting a DNS request message information, wherein the push server (220) parses (S310) the mirrored copy DNS request message service to ensure (S320) the mirrored copy of the message as a DNS request message, and extract (S330) the transaction ID and the domain name as the information required to generate a fake DNS response message; (III) Step (S400): generating a fake DNS response message and transmitting it to the client, wherein the push server (220) confirms (S410) that the extracted domain is monitored by the push server (220) The monitored medium domain converts (S420) the domain name into the domain IP only in the case of monitoring the domain, and generates (S430) a fake DNS response message, and transmits the fake DNS response message (S440) to The user terminal, wherein the fake DNS response message includes an extracted transaction ID and a converted domain IP, and wherein a TTL (residence time) of the response field is set to be specified by the push server (220) value; (IV-1) Step (S500): transmitting the DNS history information from the push server (220) to the analysis server (230), wherein the DNS history information includes a response time for transmitting the fake DNS response message to the client, The domain requested by the client and the public IP address or ID of the client; (IV-2) step (SC500): storing the IP address of the specific domain into the core of the operating system, where When the client receives a fake DNS response message, the client connects to the specific website domain and stores the specific one in the core of the operating system during the time period (TTL value) specified by the push server. The IP address obtained as a result of the DNS of the domain, in order to prevent the client from generating a DNS request message for the particular domain during the time period (TTL value) specified by the push server; (V) step (S600): storing the DNS history information received from the push server (220) via the analysis server (230) to a first DB server (240), wherein the DNS history information includes transmitting the fake DNS response message to The response time of the client, the domain requested by the client, and the public IP of the client Address or ID; and (VI) step (S700): calculating the number of devices of the client, wherein the analysis server (230) is utilized by the push server (220) by utilizing a first DB servo The maximum number of transmissions of DNS request messages for the same domain with the same ID or the same public IP address of the client during the specified period (TTL value) during the DNS history information stored in the device (240) is counted. The number of devices of the client that is combined via the IP router to use the same public IP address is calculated. The method of claim 1, as a specific step of constructing the step (S300) of extracting a DNS request message information, wherein the step (S320) of ensuring that the mirrored copy of the message is a DNS request message comprises: Confirm the format of the DNS request message; and verify the field value of the DNS request message. The method of transmitting the DNS history information to the analysis server as in the method of claim 1. (S500), when the push server (220) includes a response time for transmitting the fake DNS response message to the client, a domain requested by the client, and a public IP address or ID of the client. When the DNS history information is sent to the analysis server (230), an instant user IP allocation history is provided from a second DB server for transmitting the ID of the client to the analysis server (230). An apparatus for disclosing an IP shared state detection system (200), the apparatus comprising: a mirror copying device (210) located in a backbone network of an internet service provider and provided for use in The DNS request message is copied from the client image to the DNS server to obtain the IP address of the specific domain. The client is the client of one of the ISPs (PC-1, PC-2, and smart phone-1). Smart TV-1), wherein the specific domain is a target website domain (eg, www.naver.com) of the Internet (300) requested by operating a web browser in the client; Pushing server (220), which is provided for performing the following operations: parsing the mirrored copy of the message to ensure that the mirrored copy of the message is a DNS request message; extracting as a false DNS response message The transaction ID and domain name of the required information; confirm that the extracted domain is the monitored monitoring domain; convert the domain name to the domain IP only in the case of monitoring the domain; generate an extraction a transaction ID and a fake DNS response message for the converted domain IP; and the generation The fake DNS response message is transmitted to the client, wherein the TTL (residence time) of the reply field of the fake DNS response message is set to a preset value, and wherein the push server (220) transmits the DNS history information to the analysis server. (230), wherein the DNS history information includes a response time for transmitting the fake DNS response message to the client, a domain requested by the client, and a public IP address or ID of the client; and an analysis server ( 230), which is provided for performing the following operations: including a response time for transmitting a fake DNS response message to the client, a domain requested by the client, and a public IP address or ID of the client. Historical information stored to first The DB server (240); and by using during a period (TTL value) specified by the push server (220) by utilizing DNS history information stored in a first DB server (240) The number of devices having the same ID of the same user or the same domain of the same public IP for the transmission of the DNS request message is counted to calculate the number of devices of the client that are combined via the IP router (100) to use the same public IP address. For the device of claim 4, if the push server (220) attempts to transmit the ID of the client instead of the public IP address to the analysis server (230), the device further includes a second DB server. The real-time user IP allocation history is provided from the second DB server.