文章目录

• ​​前言​​
• ​成为超人的那一刻​

• ​​过程回忆​​
• ​​意义所在​​

• ​​后记​​

前言

技术道路，只要坚持不停联系，总有收获

成长，总是在不停的探索中获得。对于没有天赋的我来说，勤能补拙，才能增长自己的见识，才能提高理解，才能对各种实际应用场景更加明了

成为超人的那一刻

工作之余，腾出时间对技术的探索，显得格外奢侈和宝贵，毕竟忙了一天多少也是会有点累，但是想着能够对技术点的刨根问底，一点一点深入和理解，想到这一点，再累也有了动力。同时也能提高自己的技术和增加经验，说不定就能解决工作上遇到的问题

过程回忆和重现

有一次，完成了图片上传功能，上传了几张很大的图片，大概每张有10MB左右，然后刷新页面，一直在转圈圈，服务器也突然显示重新连接。

第一感觉，哦豁，网站和服务器怎么变慢了！

这个时候，我知道，实际可能会遇到的场景，我遇到了

下面重新当时的场景 

云服务器配置（宽带1Mbps）

• 第一步

准备好3张10MB左右的图片和index.html静态页面，部署到腾讯云windows服务器上的IIS里

访问首页，浏览器打开F12，查看图片加载响应时间

从下图可知，图片每秒加载大概50KB左右，也符合服务器带宽1Mbps

1Mbps=1024Kbps=1024/8KBps=128KB/s（理想加载状态，实际可能要打个5折，60KB/s左右）

• 第二步

同时使用多个不同浏览器打开首页，查看加载情况，从下图可知

第一个请求可以加载出来index.html页面内容

第二、三个请求完全在等待响应状态

index.html为3KB，页面文件是非常小的，影响速度应该是非常快的，也就是这个请求在服务器中处理排队状态，或者通道完全被阻塞了，只有等第一个请求不占用通道或者有空隙通道才会有内容响应回去

 服务器立马失去连接状态，通道被完全请求占用

 关闭请求后，服务器立马恢复连接状态

• 第三步

将改为缩略图，50KB左右大小，几乎是1秒内响应完成，所以当一个请求完成后，再点击第二个请求，第一个请求已经响应完成，不会占用通道，自然第二个请求就很顺畅。

那么，这个时候如果我模拟高并发会如何呢？借助工具请求测试？

 如果第一个请求还是加载大图，那么postman快速请求1000次，第一个请求就等待响应，说明加载图片就完全阻塞带宽通道，其他请求完全进不去

 关闭大图加载页面，此时堆积的请求开始缓存得到响应

逐步加快得到响应，其他排队的已经响应完成

意义所在

通过对上面场景的认知，在技术上就知道应该使用那个方案进行图片的处理

这也就是为什么一定会有原图和对应原图的缩略图的原因，同时也会了解到什么是带宽等知识点

后记

通过这次场景的探索和认知，突然有种进步和提高的感觉，这也许就是技术带来的成就感吧。

仅仅从简单方面进行了描述，深入还会有更多知识点和未理解到位的地方

对于一个1核2GB内存1Mbps带宽的windows服务器，36MB图片请求就基本阻塞其他请求