Extension of thinking about alert in JavaScript scripts

The question about alert in JavaScript scripts I mentioned in [Thinking About alert in JavaScript scripts] has also been answered by everyone. In fact, from a certain point of view, this is not worth mentioning. However, I have raised this question again. My goal is not to get the result of this question: alert in JavaScript scripts will definitely put pressure on the server or not.
I hope that more people can understand how to guess, analyze, solve, and solve problems through analysis of problems. Obtain the result from the actual data. Some of my friends gave answers in [Thinking About alert in JavaScript scripts], but these answers are somewhat lacking. For example, some people may not understand Http details when they reply to this question. But there is no key to explaining this answer: Why isn't it putting pressure on the browser. Here I will analyze this issue again, and I hope to provide you with a method to analyze the problem.
For [alert problems in JavaScript scripts] I analyzed them through hypothetical methods. First, I assume that alert will cause pressure, then I should speculate on the reasons why alert may cause pressure on different occasions. For example, alert may keep the communication between the server and IE, until alert is disabled. The assumption for this reason is to monitor the connection of the server, and its connection will remain. If this is not the case, the original assumptions are not true.
[Alert Issues in JavaScript scripts] There are several controversial points:
1: Is html displayed after it is completely transmitted to the customer segment?
2: Is JavaScript executed after html is fully displayed?
3: If JavaScript can be executed without being fully displayed in html, will alert be waiting for the communication between the browser and the server? ([Alert problems in JavaScript scripts] In alert state, the browser will be in the waiting state, which means that the current thread of the browser is in the waiting state)
First, let's assume that html is displayed only after it is completely transmitted to the customer segment. This will happen when we open a webpage: if we open a large webpage (with a large index and large images), it will be blank when we open it, after a while, the screen will suddenly appear. When it is blank, the browser requests data with the server. Because of the large data size, the request takes a long time. As html data is not transmitted completely during this period, the browser will not display html information, so it will be blank.
I made a test sample for this:

Private void Page_Load (object sender, System. EventArgs e)
{
For (int I = 0; I <50; I ++)
{
This. Page. Response. Write ("<table> <tr> <td> ");
Using (FileStream fs = File. OpenRead (@ "D: \ Inetpub \ wwwroot \ Test \ 123.bmp "))
{
Byte [] B = new byte [1024];
While (fs. Read (B, 0, B. Length)> 0)
{
This. Page. Response. Write (B );
}
}
This. Page. Response. Write ("</table> </tr> </td> ");
}
}

I directly write a large file into the webpage. A file is a relatively large image: the data sent to the customer segment exceeds 100 MB after more than 2 MB of reading and writing through 50 cycles, in this way, the browser processing will be slow. The test result shows that the browser displays the received content gradually. It is different from the Expected One-time display.
The reason for this display is that the browser displays the received data every time it receives a complete Table, not all data is displayed once after it is received. This kind of appearance may often occur when you visit websites with many images. After opening a webpage, you can only display a part of it for a long time.
This shows 1: whether html is displayed after being completely transmitted to the customer segment.
For the second question, I assume that the JavaScript script can be executed only after the Html display is complete. For the design test method, I simply add the following rationale before the loop operation begins:
This. Page. Response. Write ("<SCRIPT> alert (\" ee \ "); </SCRIPT> ");
If the JavaScript script can only be executed after the Html display is complete, the alert dialog box will not pop up until all the information is fully displayed. However, the test result is that the script is executed before the page content is displayed.
Next, the webpage will continue to be displayed.
The original cause of this phenomenon is that the browser displays some relatively complete data (such as a Table. If a script is executed during the display process.
This shows 2: JavaScript scripts can be executed during Html display.
Since 1 and 2 are not true, we can infer 3. If both 1 and 2 are true, the browser is disconnected from the server because the script is executed after Html is sent, after the server sends the data requested by the browser, the connection to the client is disconnected.) then, execute alert to keep the current thread of the browser in a waiting state without affecting the server)
The test results of 1 and 2 make the answer of 3 uncertain. The reason for the stress on the server is that alert puts the browser in a waiting state, and the communication with the server may not be terminated yet, therefore, the client and the server will be connected for a long time, resulting in pressure. If the reason is true, then the monitoring server will find that IIS is always active.
Through software testing, we first remove [enable HTTP activation] from the site attribute settings in IIS. Then, the software can monitor the number of IIS connections.
The test result is that IIS is not activated until alert is disabled, which means IIS does not maintain the communication protocol with the client.
The original reason for this phenomenon is: due to the characteristics of the communication protocol, because the network communication protocol is a bottom-up service feature, the HTTP protocol also communicates through the TCP/IP protocol in the network. Due to the service characteristics of the communication protocol, even if the browser is in the waiting state, this does not affect the underlying TCP communication. Because the TCP Service goes from bottom to top, the upper-layer invocation does not care too much about the lower-layer operation status.
Now, this question is clearly explained, hoping to help everyone.