KR101109563B1 - Apparatus and method for guranteeing internet service - Google Patents

Abstract

An apparatus and method for guaranteeing Internet service are disclosed. An Internet service guarantee apparatus for providing a service according to a standby priority only to a normal user to guarantee normal Internet service includes a reverse turing test verification unit, a user standby manager, and a service provider.
The inverse Turing test verifier transmits inverse Turing test information to a user who has established a TCP connection, and when a normal response to the inverse Turing test information is received from the user, transmits an authentication cookie for authenticating the user as a normal user to the user. The user standby management unit sets the standby priority of the normal user by using the authentication cookie when the normal user is under service load of the server, and the service provider sets the service according to the standby priority when the normal user re-requests the service. to provide.
As a result, a normal Internet service can be guaranteed not only when a Bot-based distributed denial of service (DDoS) attack that mimics a normal user but also when a flash crowd occurs by a normal user.

Description

Apparatus and method for guranteeing internet service}

The present invention relates to an apparatus and a method for guaranteeing an Internet service, and more particularly, to an apparatus and a method for guaranteeing normal Internet service by providing a service according to a standby priority only to a normal user.

Today, all businesses depend on the Internet and networks to do business, and business environments demand high levels of reliability, reliability, and high performance from the Internet and networks. In particular, Internet service, which is used by most companies such as internet portals, internet shopping malls, internet banking, internet bidding and purchasing systems, and internet reception, is absolutely dependent on the Internet. Providing stable Internet service is directly related to the business activities of the company. It is becoming.

The biggest obstacles to such stable Internet services can be divided into distributed denial of service (DDoS) attacks and flash crowds where normal users are concentrated on specific sites.

DDoS attacks by Bot are used by numerous PCs infected with Bot, which are infected by Bot through various paths such as malicious attachments of emails, file downloads, web surfing, and worms. It will execute any command such as DDoS, spamming, keyboard logging, etc. From the 1990s to the 77 DDoS turbulence of 2009, distributed denial of service (DDoS) attacks are the most serious threats after malicious code among cyber threat types.

To reduce the damage caused by these attacks, various security vendors have released various DDoS attack defense devices (Anti-DDoS solutions) to protect the service from many kinds of distributed denial of service (DDoS) attacks. (DDoS) attacks are application-level attacks that mimic normal users who can bypass the defense mechanisms of existing Anti-DDoS devices, making them impossible to detect and defend.

In other words, the recent DDoS attack by Bot effectively depletes the server's CPU and memory by technically impossible to distinguish from normal users, so even the existing Anti-DDoS solution cannot be defended. Normal Internet service becomes very difficult.

In addition, the existing DDoS attack defense devices are devices for defending against distributed denial of service (DDoS) attacks, so when a user experiences a crowd of traffic crowds (Flash Crowd), it cannot provide any service protection.

When such a flash crowd occurs, it is very difficult for even normal users to receive Internet service, which means that if more users are gathered in less time than the maximum users predicted at the time of site construction, network bandwidth and server CPU , Memory is due to lack of capacity.

Internet services such as Internet shopping malls, Internet banking, Internet bidding and purchasing systems, and Internet receptions, which are used by most companies today, not only lead to direct economic losses, such as lower sales, if long-term failures or delays occur. There is no choice but to suffer enormous damage such as loss of reputation and customer churn.

There is a network device such as Quality of Service (QoS) for efficiently allocating network bandwidth in order to efficiently guarantee such important Internet services, but it is a device that adjusts the network bandwidth usage by service, and it can be used for DDoS attacks or normal users. It is difficult to have an effect when a flash crowd occurs.

In conclusion, as described above, efforts for protecting and guaranteeing Internet services have been continued. However, in the case of recent Bot-based distributed denial of service (DDoS) attacks or flash crowds of normal users, no concrete and clear solutions have yet been proposed. It is not.

The present invention has been made to solve such a conventional problem, and aims to guarantee normal Internet service when Bot-based distributed denial-of-service (DDoS) attacks occur by authenticating normal users.

In addition, an object of the present invention is to ensure a normal Internet service even in the event of a flash crowd by a normal user.

Internet service guarantee apparatus according to the present invention for solving the above-described control includes a reverse turing test verification unit, a user standby management unit, and a service providing unit.

The inverse Turing test verifier transmits inverse Turing test information to a user who has established a TCP connection, and when a normal response to the inverse Turing test information is received from the user, transmits an authentication cookie for authenticating the user as a normal user to the user. The user standby management unit sets the standby priority of the normal user by using the authentication cookie when the normal user is under service load of the server, and the service provider sets the service according to the standby priority when the normal user re-requests the service. to provide.

As a result, a normal Internet service can be guaranteed not only when a Bot-based distributed denial of service (DDoS) attack that mimics a normal user but also when a flash crowd occurs by a normal user.

In addition, the inverse Turing test verifier may use a CAPTCHA as the inverse Turing test information.

In addition, the Internet service guarantee apparatus according to the present invention transmits a SYN cookie specifying the initial sequence number to the user, and further comprises a SYN cookie verification unit for establishing a TCP connection when the response from the user and the 'initial sequence number + 1' match This can prevent DoS attacks using SYN floods from Bot.

In addition, the SYN cookie verification unit may be configured to asynchronously perform the normal user terminal authentication of the reverse Turing test verification unit, or to provide the service of the service provider unit asynchronously, so that the Internet service guarantee apparatus performs a TCP connection after transmitting one data to the user. It releases and receives the response on the new connection, preventing the Bot impersonating the normal user from connecting to the server.

In addition, the Internet service guarantee apparatus according to the present invention periodically requests a service to the server, and compares the response time measured for the requested service with a preset response time, the service load measurement unit for measuring the service load of the server further In this case, it is possible to authenticate a normal user to provide a service only when the service of the server is under load.

In addition, an invention embodying the apparatus in the form of a method is disclosed.

According to the present invention, normal Internet services can be guaranteed when Bot-based distributed denial of service (DDoS) attacks occur by authenticating normal users by using a Reverse Turing Test (RTT) technique.

In addition, even when a traffic crowd (Flash Crowd) occurs by a normal user, the priority is given to the user according to the access order, and when the user reconnects, the service is provided according to the priority of the user, thereby ensuring normal Internet service. .

Figure 1 is a block diagram schematically showing an embodiment of the configuration of the Internet service guarantee apparatus according to the present invention.
2 shows a flow of data for normal user authentication.
3 illustrates one embodiment of a captcha.
4 is a diagram illustrating a data flow for user waiting management.
5 is a flowchart schematically illustrating an embodiment of a method for guaranteeing Internet service according to the present invention.
6 is a flowchart detailing the TCP connection establishment and normal user authentication steps.
Fig. 7A is a diagram showing the flow of data in TCP connection # 1.
FIG. 7B is a diagram showing the flow of data in TCP connection # 2. FIG.
FIG. 7C is a diagram showing the flow of data in TCP connection # 3. FIG.

Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings. In order to more clearly understand the present invention, the same reference numerals are used for the same components in different drawings.

1 is a block diagram schematically showing an embodiment of the configuration of the Internet service guarantee apparatus 100 according to the present invention, Figure 2 is a diagram showing the flow of data for the normal user 220 authentication.

Referring to FIG. 1 and FIG. 2, the apparatus 100 for guaranteeing Internet service 100 includes a service load measuring unit 110, a SYN cookie verification unit 120, and an inverse Turing test verification unit 130. ), A service provider 140, and a user standby manager 150.

The service load measuring unit 110 measures whether traffic for providing a service from the server 300 is in a normal state (service normal state) or a congestion state (service load state), and periodically services the server 300. Request, and by comparing the response time measured for the requested service with a preset response time, it is possible to determine whether the service load of the server 300 (1 in Fig. 2).

In this case, the preset response time refers to the normal response time during normal service and the load response time under load, which are inputted from an administrator.

When the service load measuring unit 110 determines that the service is in a load state (2 in FIG. 2), in order to remove the connection attempt by the Bot 210, the user 200 that is attempting to connect is the normal user 220. Perform normal user authentication to authenticate.

Normal user authentication may be performed through the SYN cookie verification unit 120 and the inverse Turing test verification unit 130.

The SYN cookie verification unit 120 responds to the request of the user 200 on behalf of the server 300.

When the SYN cookie verification unit 120 receives a SYN packet for requesting access to the server 300 from the user 200 through the user terminal (3 in FIG. 2), the SYN cookie verification unit 120 uses the received SYN packet. A SYN + ACK packet containing a SYN cookie that is a uniquely generated ISN (TCP Initial Sequence Number) by encrypting the number, the server IP address and port number, the current time, and calculating the hash value. Send to user 200.

(In the embodiment of the present invention, data transmission and reception between the user 200 and the Internet service guarantee device 100 is performed through the user terminal.)

The SYN cookie verification unit 120 receives an ACK packet and a service request packet corresponding to the SYN + ACK packet from the user 200 receiving the SYN + ACK packet, and the ACK number is the SYN cookie verification unit 120. It is preferable to be a number obtained by adding 1 to the ISN number (SYN cookie value) transmitted by the user (that is, the ACK number from the user 200 = ISN + 1).

The SYN cookie verification unit 120 verifies whether the ACK packet received from the user 200 matches the ISN + 1 sent to the user 200, and establishes a TCP connection if it matches. You can stop the attack.

In addition, when the SYN cookie verification unit 120 transmits data to the user 200 by the inversion Turing test verification unit 130 and the service provider 140 when the TCP connection is established, the SYN cookie verification unit 120 simultaneously transmits a TCP reset packet together with the data. To terminate the TCP connection. Thereafter, the transmission of other data is transmitted after a new TCP connection is established. In this case, the TCP connection is terminated by simultaneously transmitting a TCP reset packet together with the data transmission.

When the TCP connection with the user 200 is established, the inverse Turing test verification unit 130 receives a normal response to the inverse Turing test from the user 200 (5 in FIG. 2). The user 220 authenticates (⑥ in FIG. 2) and transmits an authentication cookie to the normal user 220 (⑦ in FIG. 2).

In the embodiment of the present invention as a reverse Turing Test (RTT) to distinguish between the normal user 220 and the Bot 210, one type of the Reverse Turing Test (CAPTCHA, Completely Automated Public Turing test to tell Computers and Humans Apart, but other types of inverse Turing tests can be used.

At this time, the captcha is a method used to distinguish whether a user is a real human or a computer program, and as shown in FIG. How to ask.

3 is a diagram illustrating one embodiment of a CAPTCHA, where the normal CAPTCHA response to CAPTCHA is "smwm".

Looking at the function of the inverse Turing test verification unit 130 in more detail, when the user 200 requesting the service is a TCP connection is established, the inversion Turing test verification unit 130 transmits the CAPTCHA to the user 200 (FIG. 2). ④).

Then, the CAPTCHA response received from the user 200 is verified (⑤ in FIG. 2), and if the CAPTCHA response is correct (the normal CAPTCHA response), the corresponding user 200 is authenticated as the normal user 220 (FIG. 2). (6) transmits an authentication cookie (eg, an encrypted HTTP cookie) to the normal user 220 (⑦ of FIG. 2).

As such, when data (captcha or authentication cookie) is transmitted from the inverse Turing test verification unit 130 to the user 200 (or the normal user 220), as described above, the data from the SYN cookie verification unit 120 Send TCP reset packet at the same time and terminate the TCP connection.

That is, CAPTCHA is sent over TCP connection # 1 and authentication cookie is sent over TCP connection # 2.

Due to the normal user authentication scheme of the asynchronous connection and inverse Turing test verification unit 130 of the SYN cookie verification unit 120, Bot 210 impersonates the normal user 220 to access the server 300 You can stop it.

When the service provider 140 receives the service request packet together with the authentication cookie from the normal user 200 (⑧ in FIG. 2), the service provider packet 140 receives the service request packet received when the service user is not in the service load state by the normal user 220. It transmits to the server 300, and provides the service received from the server 300 to the normal user 200 (9 to 9 in Fig. 2).

Even in this case, when the data (service) is transmitted to the normal user 220, the SYN cookie verification unit 120 delivers the TCP reset packet with the data at the same time to terminate the corresponding TCP connection, the service is TCP connection # 3 Is sent through.

4 is a diagram illustrating a data flow for user waiting management.

Referring to FIG. 4, when the server 300 is in a service load state due to the normal user 220 (② of FIG. 4), the user standby manager 150 may request a service request of the normal user 220 (access order). According to the priority setting, if the normal user 220 re-requests the service after the expected waiting time, it may be to provide the service according to the standby priority.

Looking at the function of the user standby management unit 150 in more detail, the user standby management unit 150 is a server (300) in the service load state due to the normal user 220 (2 in Fig. 4), the normal user 220 When the service request packet is transmitted together with the authentication cookie (3 in FIG. 4), the waiting priority may be set by inserting an authentication cookie into the access waiting list for each access time of the normal user 220 (4 in FIG. 4).

When the standby priority of the corresponding normal user 220 is set, the user waiting manager 150 transmits the waiting information that calculates the number of target persons and the expected waiting time to the corresponding normal user and makes a waiting request (⑤ in FIG. 4). .

After the expected waiting time, when the normal user 220 accesses the user waiting manager 150 to transmit the authentication cookie and resend the service request packet (⑥ in FIG. 4), the server 300 is not in a service load state. Alternatively, the service is provided when the normal user 220 having a higher priority than the normal user 220 is not in the waiting list (⑤ to ⑦ of FIG. 4).

As a result, even when the traffic is overwhelmed by normal users, the Internet service is not paralyzed, but a fair first come, first serve (FCFS) type of service can be received, and inappropriate connection attempts can be reduced.

5 is a flowchart schematically illustrating an embodiment of a method for guaranteeing Internet service according to the present invention.

In the following description, when the server 300 is an Internet server, the service provision from the user 200 may be provided as a URL, and the service provided when the server 300 is a server other than the Internet server corresponds to the server. Information can be provided.

The apparatus 100 for guaranteeing service of the present invention periodically requests a service from the server 300 and compares the response time measured for the requested service with a preset response time to measure whether the server 300 has a service load. (S100).

When the service is not in a load state (normal state), the Internet service guarantee device 100 connects with the user 200 according to the server 300 connection request and the service request from the user 200, and the server 300. After requesting the corresponding service, the service provided from the server 300 is again provided to the corresponding user 200 and the TCP connection is released (S200).

When the service is under load, the Internet service guarantee device 100 establishes a TCP connection with the user 200 and authenticates whether the user 200 is a normal user 220 (S300).

FIG. 6 is a flowchart illustrating a TCP connection establishment and normal user authentication step S300 in detail, and FIGS. 7A to 7C illustrate the flow of data for each TCP connection. I will explain by reference.

When the service is under load, the Internet service guarantee device 100 receives a SYN packet from the user 200 requesting access to the server 300 through TCP connection # 1, and the IYN of the user 200 is included in the SYN packet. This includes (S310, Fig. 7- (a) -①).

The Internet service guarantee apparatus 100 encrypts a user IP address and a port number, a server IP address and a port number, a current time by using the received SYN packet, and calculates a hash value to generate a uniquely generated ISN (TCP). An SYN + ACK packet including a SYN cookie, which is an initial sequence number and a TCP initial sequence number, is transmitted to the corresponding user 200 (S312, FIG. 7 (a) -②).

The Internet service guarantee device 100 receives an ACK packet corresponding to the SYN + ACK packet transmitted from the user 200 and an HTTP GET requesting service (S314, FIG. 7- (a) -③④). The number is preferably a number obtained by adding 1 to the ISN number (SYN cookie value) transmitted by the Internet service guarantee apparatus 100 (that is, the ACK number from the user 200 = ISN + 1).

The Internet service guarantee device 100 verifies whether the ACK packet received from the user 200 matches the ISN + 1 sent to the user 200 (S316), and stops the TCP connection if it does not match (S316). S318), by establishing a TCP connection in case of a match, it is possible to prevent DoS attacks using the SYN flood (S320).

The Internet service guarantee device 100 checks whether the user 200 in which the TCP connection is established is a normal user 220 (S330), and the user 200 requests the service (sends a service request packet) along with an authentication cookie. When transmitting the user 200 is recognized as a normal user 220 proceeds to step S400, if the user 200 does not transmit an authentication cookie, the user 200 is authenticated as a normal user 220 If it is determined that the user 200 is not, the user 200 checks whether the Bot 210 or the normal user 220.

In order to check whether the user 200 is the Bot 210 or the normal user 220, the Internet service guarantee apparatus 100 checks whether a CAPTCHA response is received from the user 200 (S340), and the CAPTCHA response. Is not received, a SYN + ACK packet including the SYN cookie + 1 of the Internet service guarantee apparatus 100, HTTP 200 indicating that the service request was successfully performed, and CAPTCHA are sent simultaneously, and a TCP reset packet is simultaneously sent. After the transmission releases TCP connection # 1, the process returns to step S310 again. (S342, Fig. 7- (a) -⑤⑥).

Still, when the service is under load, the Internet service guarantee apparatus 100 receives a SYN packet (ISN of the user 200) requesting access to the server 300 from the user 200 receiving the CAPTCHA through the TCP connection # 1. This is included) is received via a new TCP connection # 2 (S310, Fig. 7- (b) -①).

The Internet service guarantee apparatus 100 encrypts a user IP address and a port number, a server IP address and a port number, a current time by using the received SYN packet, and calculates a hash value to generate a uniquely generated ISN (TCP). An SYN + ACK packet including a SYN cookie, which is an initial sequence number and a TCP initial sequence number, is transmitted to the corresponding user 200 (S312, FIG. 7- (b) -②).

The Internet service guarantee device 100 receives an ACK packet corresponding to the transmitted SYN + ACK packet from the user 200 who transmits the SYN + ACK packet (S314, Figs. 7 (b) -③).

The Internet service guarantee device 100 verifies whether the ACK packet received from the user 200 matches the ISN + 1 sent to the user 200 (S316), and stops the TCP connection if it does not match (S316). S318), by establishing a TCP connection in case of a match, it is possible to prevent DoS attacks using the SYN flood (S320).

At the same time, an HTTP 200 packet indicating that the CAPTCHA request from the Internet service guarantee apparatus 100 was successfully performed and a CAPTCHA response to the CAPTCHA received through the TCP connection # 1 are received (FIG. 7- (b) -④).

The Internet service guarantee apparatus 100 checks whether the user 200 in which the TCP connection is established is a normal user 220 (S330). When the user 200 requests a service and transmits an authentication cookie, the corresponding user 200 ) Is recognized as the normal user 220 and proceeds to step S400, if the user 200 does not transmit the authentication cookie, it is determined that the user 200 is not authenticated as the normal user 220, the corresponding user ( It is checked whether the 200 is the Bot 210 or the normal user 220.

In order to confirm whether the user 200 is the Bot 210 or the normal user 220, the Internet service guarantee apparatus 100 checks whether a CAPTCHA response is received from the user 200 (S340).

As described above, since the Internet service guarantee apparatus 100 receives the CAPTCHA response from the corresponding user 200 through the TCP connection # 2, it checks whether the received CAPTCHA response is a normal CAPTCHA response (S350).

If the received CAPTCHA response is not a normal CAPTCHA response (ie, a response different from 'smwm' which is a normal CAPTCHA response in the CAPTCHA image of FIG. 3), the user 200 is recognized as a Bot 210 and the TCP connection is established. To release (S352).

If the received CAPTCHA response is a normal CAPTCHA response, the corresponding user 200 is authenticated as a normal user 220, and an HTTP 301 packet and an authentication cookie (eg, indicating that the resource requested to the normal user 220 has been moved to another address). Encrypted HTTP cookie), and simultaneously sends a TCP reset packet to release TCP connection # 2, and returns to step S310 again. (S354, Fig. 7- (b) -⑤⑥).

Still, when the service is under load, the Internet service guarantee apparatus 100 may request a connection to the server 300 from the user 200 that receives the authentication cookie through the TCP connection # 2 (the ISN of the user 200). This is included) is received via a new TCP connection # 3 (S310, Fig. 7- (c) -①).

The Internet service guarantee apparatus 100 encrypts a user IP address and a port number, a server IP address and a port number, a current time by using the received SYN packet, and calculates a hash value to generate a uniquely generated ISN (TCP). An SYN + ACK packet including a SYN cookie, which is an initial sequence number and a TCP initial sequence number, is transmitted to the corresponding user 200 (S312, FIG. 7- (c) -②).

The Internet service guarantee device 100 receives an ACK packet corresponding to the transmitted SYN + ACK packet from the user 200 who transmits the SYN + ACK packet (S314).

The Internet service guarantee device 100 verifies whether the ACK packet received from the user 200 matches the ISN + 1 sent to the user 200 (S316), and stops the TCP connection if it does not match (S316). S318), by establishing a TCP connection in case of a match, it is possible to prevent DoS attacks using the SYN flood (S320).

At the same time, the user 200 receives an HTTP GET packet requesting the service and an authentication cookie transmitted to the user 200 through the TCP connection # 2 (FIG. 7- (c) -③).

The Internet service guarantee device 100 checks whether the user 200 in which the TCP connection is established is a normal user 220 as an authentication cookie (S330). As described above, the user 200 detects the TCP connection # 3. Since the service is requested and the authentication cookie is transmitted, the corresponding user 200 is recognized as a normal user 220.

Since the Internet service guarantee device 100 connects to the server 300 only to the authenticated normal user 220 through the TCP connection # 1 to # 3, the service due to the Bot 210 or the unauthenticated user 200. The load condition can be solved.

However, even in this case, since the service load state due to the normal user 220 may occur, the Internet service guarantee device 100 checks whether the service load state due to the normal user 220 is once again (S400).

If the service load is not in the service state, the normal user 220 requests the service requested by the server 300, provides the service provided from the server 300 to the normal user 220, and then establishes a TCP connection # 3. Release (S200).

If the normal user 220 is in the service load state, the normal user 220 may reconnect (the standby priority is set) or the first connection (the standby priority is not set). Check (S500).

Even in a service load state caused by the normal user 220, when there is no waiter having a higher priority than the normal user 220 reconnected, the service is provided from the server 300 and provided to the normal user 220. After that, the TCP connection # 3 is released (S200).

If the normal user 220 first accesses the service priorities and the standby priority is not set, the standby priority is set (S600).

In this case, the Internet service guarantee apparatus 100 may set the priority of the authentication by inserting an authentication cookie into the access waiting list for each access time of the normal user 220. When the waiting priority is set, the number of subjects to be processed and the expected waiting The waiting information is calculated by transmitting the waiting information to the corresponding normal user and ends (S610).

After the expected waiting time, the normal user 220 having the standby priority set again reconnects to the Internet service guarantee device 100 using the authentication cookie, and passes through steps S100 to S510, and the server 300 is not in a service load state or the normal user. When the normal user 220 having a higher standby priority than the 220 is not in the standby list, the Internet service guarantee device 100 releases the TCP connection after providing the service to the normal user 220 (S200). .

The invention can also be embodied as computer readable code on a computer readable recording medium. A computer-readable recording medium includes all kinds of recording apparatuses in which data that can be read by a computer system is stored. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage, and the like, and may also be implemented in the form of a carrier wave (for example, transmission over the Internet). Include. In addition, the computer-readable recording medium may be distributed over network-connected computer systems so that computer readable codes can be stored and executed in a distributed manner.

So far I looked at the center of the preferred embodiment for the present invention. Those skilled in the art will appreciate that the present invention can be implemented in a modified form without departing from the essential features of the present invention. Therefore, the disclosed embodiments should be considered in descriptive sense only and not for purposes of limitation. The scope of the present invention is shown in the claims rather than the foregoing description, and all differences within the scope will be construed as being included in the present invention.

100 Internet Service Guarantee
110 Service load measurement unit
120 SYN Cookie Verifier
130 Reverse Turing Test Verification Unit
140 Service Provider
150 User Waiting Management
200 users
210 Bot
220 normal users
300 servers

Claims (11)

Inverted Turing test information is transmitted to a user who has established a TCP connection, and when a normal response to the Inverted Turing test information is received from the user, an inverted Turing test that transmits an authentication cookie for authenticating the user as a normal user. Verification unit;
A user standby manager configured to set a standby priority of the normal user by using the authentication cookie when the normal user is in a service load state of the server;
A service provider for providing a service according to the standby priority when the normal user re-requests a service; And
A service load measuring unit configured to periodically request a service from the server and compare the response time measured with respect to the requested service with a preset response time to determine whether the server has a service load; Internet service guarantee device comprising a. The method of claim 1,
The inverse Turing test verification unit,
And a captcha (CAPTCHA) as the inverse Turing test information. The method of claim 1,
A SYN cookie verification unit which transmits a SYN cookie specifying an initial sequence number to the user and establishes a TCP connection when the response from the user and the initial sequence number + 1 match; Internet service guarantee device further comprising. The method of claim 3, wherein
The SYN cookie verification unit,
And asynchronously performing normal user terminal authentication of the inverse Turing test verification unit or providing a service of the service provider unit asynchronously. delete Internet service guarantee device,
(b) sending inverse Turing test information to a user who has established a TCP connection;
(c) if a normal response to the reverse Turing test information is received from the user, transmitting an authentication cookie to the user authenticating the user as a normal user;
(d) setting a standby priority of the normal user using the authentication cookie when the normal user is under a service load of a server;
(e) if the normal user re-requests a service, providing a service according to the standby priority; And
(f) periodically requesting a service from the server, and comparing the response time measured for the requested service with a preset response time to determine whether the server has a service load; Internet service guarantee method comprising a. The method of claim 6,
In the step (b),
And captcha (CAPTCHA) as the inverse Turing test information. The method of claim 6,
Before step (b),
(a) transmitting a SYN cookie specifying an initial sequence number to the user and establishing a TCP connection when the response from the user and the initial sequence number + 1 match; Internet service guarantee method comprising a further. The method of claim 8,
In step (a),
And (b) between the steps (b) and (c) or between the steps (d) and (e). delete A recording medium which can read the Internet service guarantee method according to any one of claims 6 to 9, and which is recorded by an executable program code.

Images