这种情况下导致fastcgi进程被挂起，如果fastcgi服务队这个挂起处理不是很好的话，就可能提示“504 Gateway Time-out”错误。
情况一解决办法：
默认的fastcgi进程响应的缓冲区是8K，我们可以设置大一点，在nginx.conf里，加入：fastcgi_buffers 8 128k
这表示设置fastcgi缓冲区为8块128k大小的空间。
情况一解决办法（改进）：
在上述方法修改后，如果还是出现问题，我们可以继续修改nginx的超时参数，将参数调大一点，如设置为60秒：
send_timeout 60
经过这两个参数的调整，结果没有再提示“504 Gateway Time-out”错误，说明效果还是挺不错的，问题基本解决。
情况二：PHP环境的配置问题
这里我们需要对php-fpm和nginx进行配置修改。因为这种情况下，也会出现“504 Gateway Time-out”错误提示。
情况二解决办法（ php-fpm配置修改）：
将max_children由之前的10改为30，这样操作是为了保证有充足的php-cgi进程可以被使用。
将request_terminate_timeout由之前的0秒改成60秒，这样使php-cgi进程处理脚本的超时时间提高到60秒，可以防止进程被挂起以提高利用效率。
情况二解决办法（nginx配置修改）：
为了减少fastcgi的请求次数，尽量维持buffers不变，我们要更改nginx的几个配置项，如下：
将fastcgi_buffers由4 64k改为2 256k
将fastcgi_buffer_size 由64k改为128k
将fastcgi_busy_buffers_size由128k改为256k
将fastcgi_temp_file_write_size由128k改成256k。
情况二解决办法修改完，我们需要重新加载php-fpm和nginx的配置，然后再进行测试。之后就没有发现“504 Gateway Time-out”错误，效果也还是不错的！
文件都传完了才执行refresh，那不是就直接获取到最后100%的文件了，前面就没有执行。放到文件上传外面，并且你的处理文件不能使用session之类会导致程序被挂起执行的代码，要不也会没有效果。
asp.net/asp网站浏览器打开一个长时间运行的页面同时打开其他页面为什么被挂起
1、 域名解析
2、 根据IP建立TCP连接（三次握手）
3、 发送HTTP请求
4、 服务器处理请求并返回HTTP报文
5、 浏览器解析并渲染页面
6、 连接结束，关闭TCP连接（四次挥手）
当输入一个域名的时候，我们首先要做的就是 将域名转化成IP地址 。前端的静态资源等，都是存储在服务器上。在计算机网络中，我们不能通过域名直接访问，只能通过IP地址访问到具体的主机。
1、首先 浏览器会查询自身的缓存 中，有没有此条域名的解析，如果有的话，就返回这个解析后的地址。
2、如果浏览器自身的缓存中，没有找到与此条域名对应的IP地址，那么就会去 操作系统中的缓存 中查找是否有这条域名的解析。
3、如果在操作系统中也没有找到的话，那么就需要通过 DNS(域名系统) 帮助我们解析。
4、DNS域名解析过程（详细看参考链接）
浏览器与远程web服务器通过TCP三次握手协商来建立一个TCP/IP连接。该握手首先由客户端尝试建立起通信，而后服务器应答并接受客户端的请求，最后由客户端发出该请求已经被接受的报文。
一旦TCP/IP连接建立，浏览器会通过该连接向远程服务器发送HTTP请求。
当浏览器再次访问某个url时，会先获取资源的header信息， 判断是否命中强缓存 ：
1、如命中，直接从缓存获取资源，包括响应的header信息（ 请求不会和服务器通信 ），也就是强缓存
2、如未命中强缓存，浏览器发送请求到服务器，该请求会携带第一次请求返回的有关缓存的header信息，由服务器根据请求种的相关header信息来 对比结果是否协商缓存命中
1）若命中，服务器 返回新的响应header信息，更新缓存中对应的header信息，但并不返回资源内容 ，它会告诉浏览器可以直接从缓存获取
2）否则，返回最新的资源内容
Expires ：Expires 的值是一个 绝对时间的GMT格式的时间字符串（如Thu, 02 Sep 2021 11:03:45 GMT） ，在浏览器发起请求的时候，会根据系统时间和 Expires 的值进行比较，如果发送请求的时间在expires之前，那么本地缓存始终有效，否则就会发送请求到服务端来获取资源。
注：这个字段会导致一个问题，要是系统时间与服务器时间不一致的时候，就可能出现假性失效，或者出现缓存已经失效了，但是并未去请求最新资源
Cache-control ：HTTP/1.1 中新增的属性，属性值具有以下几个：
pragma ：不使用强缓存，需要验证缓存是否新鲜。（HTTP/1.1 之前版本的历史遗留字段，仅作为与 HTTP/1.0 的向后兼容而定义）
协商缓存都是由浏览器和服务器协商，来确定是否缓存，主要通过两组header字段，两组字段都是 成对出现 的，即第一次请求的响应头上带某个字段（Last-Modified 或 Etag），则后续请求会带上对应的请求字段（if-modified-since或者if-none-match），若响应头没有，则请求头也不会有对应的字段
①、解析 HTML，生成 DOM 树（浏览器不能直接理解和使用HTML，需要将HTML转换为浏览器能够理解的结构）
②、解析 CSS，生成 CSS 规则树
③、合并 CSS 和 DOM 树，生成render树
④、计算渲染树的布局（Layout/reflow），即各元素尺寸、位置的计算
⑤、绘制 render 树（paint），绘制页面像素信息
⑥、浏览器将各层信息发送给GPU,GPU将各层合成，显示在屏幕
注 ：
1 、render树的节点并不等同的dom树的节点，因为有些节点的display为none，那么在生成render树的时候，就不会将其加入到render树中
2 、 当我们浏览器获得HTML文件后，会自上而下的加载，并在加载过程中进行解析和渲染。
3 、 如果在加载过程中遇到外部CSS文件和图片，浏览器会另外发送一个请求，去获取CSS文件和相应的图片，这个请求是异步的，并不会影响HTML文件的加载。 不会阻塞DOM树的解析，会阻塞DOM树的渲染和后面js语句的执行 ，当计算样式的时候需要等待css文件的资源进行层叠样式，资源阻塞了，会进行等待，直到网络超时，network报出错误，渲染进程继续层叠样式计算。为了避免让用户看到长时间的白屏时间，应该提高css的加载速度：
4 、如果遇到Javascript文件，HTML文件会挂起渲染的进程，等待JavaScript文件加载完毕后，再继续进行渲染。因为JavaScript可能会修改DOM，导致后续HTML资源白白加载，所以HTML必须等待JavaScript文件加载完毕后，再继续渲染，这也就是为什么JavaScript文件在写在底部body标签前的原因
5 、 每个页面至少需要一次回流，就是在页面第一次加载的时候。
1.第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
2.第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
3.第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
4.第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1， Server进入CLOSED状态，完成四次挥手。
参考： 前端进阶必看——详细版输入URL到界面展示的过程
简述浏览器渲染机制
