Comparison of the above four methods: 1 Development is simple. Because HTTP connections need to be established regularly to obtain progress information, the number of connection requests will increase. In addition, in the case of low speed, various bugs often appear, and the difference of network environment makes it difficult to choose that cycle. 2. Development is complicated. Comet itself needs the support of the server, so TOMCAT should choose at least 6.0, otherwise the pressure of connecting to the server for a long time will be unbearable. However, the performance is still good, because only two HTTP link requests are actually initiated at one upload, which is much less than AJAX. Another advantage is that COMET will enable the server to report the progress to the client, so the client's progress bar is relatively accurate. At present, the solution is the best. Although the development needs to involve the development of FLASH, JAVASCRIPT and JAVA, the amount of code is small, so the complexity is relatively moderate. However, FLASH also has several problems: first, the compatibility of browser FLASH version; Second, FLASH reflects the progress bar by getting the progress of sending data, so although it doesn't need the code of the server-side development progress part, the progress display is not very accurate, and it is often very fast at first and then slower and slower. 4, stop it, development is definitely the most troublesome, but the progress bar effect is definitely the best, but it is still painful for every browser to have a plug-in. To sum up, I hope it will help everyone. It's actually very troublesome. I have tried it before, and there will be the following problems: First, the server must choose a server that supports HTTP long connections, otherwise the thread limitation of the operating system will lead to less concurrency. Second, unless you use the comet's progress method, you have to change the progress of the cycle to the comet's way, which is very depressing. COMET wants the server to send the progress information back to the client in JAVASCRIPT, so it needs to convert the structure into JAVASCRIPT calls. Third, different browsers handle JAVASCRIPT in different ways. The result of my experiment is that IE will execute a certain amount of JAVASCRIPT after receiving it, so although I call the flush method on the server side every time, it still takes some time to respond on the interface. Moreover, this period of time is not easy to control, because the uploaded files are different in size, which leads to the different amount of JAVASCRIPT distributed, so it is basically difficult to achieve the effect of FLASH. In fact, if you have decided to use flash, you don't need to modify the code on the server side, because whether the progress information server sends it or not will not affect the execution of the code. Anyway, FLASH itself has provided progress instructions. So, to put it simply, if you want to upload in FLASH, you just need to make a FLASH client, and you don't need to change the server. By the way, there is another situation that needs to change the server side, that is, multiple files uploaded by FLASH are multi-threaded, so if multiple files are uploaded at one time, the server side needs to be changed. It is necessary to modify the database after uploading all threads.