辞职在家,理理东西,理什么了,就cdn吧
对于CDN,汉语为内容分发网络,即Content Distribute Network,其用途为将资源内容,.从服务器传递到用户端,认识之前,应该要先说说互联网了吧,互联网我的理解是以tcp/ip为基础的狭义网络和由www构成的万维网构成,tcp/ip 用于计算机之间的互联,用于将各种信息以极低的成本进行传递,也就是自来水中的管道了,而以www组成的万维网,应该就是我们日常生活中,所见到的b/s了,也就是应用层http了,而http和tcp的差别在于,http是建立在tcp之上,是应用交互协议,http好比孩子,而tcp好比父亲,像后面的多媒体分发网络,其协议也是基于tcp/ip
而在传统的bs应用中,我所知道的哈,会经历以下几个瓶颈
1. 服务器的宽带,宽带决定了该服务器的 访问速度和并发访问量,用户越多,出口带宽要求就越大,如果不够,将会导致性能瓶颈
2. 服务器本身的处理能力,在以前,能充分利用多核,个人觉得是件不简单的事情,现在也觉得也是件不简单的事情,怎么说呢,我所遇到的和见到的,主程根据业务设计时,锁很频繁,各个环节之间,扣得很厉害,对于常驻式线程池,多线程争取同一份资源时,会有等待,也就导致了,该线程处于阻塞中,如果其他与该资源无关的任务到达,是不能及时处理了,这也就导致了延迟,而这个延迟在很大程度上是由设计者决定的.有时候在想,如果通过一个任务到来,一个就开启一个线程处理这样能力用多核,但是线程的开启并非想象中的那么轻量,有时候在想,如果在开始时,一次向开启两千或者更多的线程组成常驻式线程池,进行处理任务,可以在一定程度上避免上面的问题,但是还是有几率出现(思考中,好像不能避免上面的状况),而且线程越多,cpu调度压力就越大,在很大程度上,也是损失了性能,而在综合考虑下,驻留式处理池是最好的,意思是任务到来,会先去驻留式池子中看看,有没有还没退出的线程,如果有,则通过制定的queue 发布任务,然后处理,如果没有则新开启,也是上面这个原因,所以我选择了协程,作为任务处理器单元,因为协程的开启很轻量,但不是越多越好,因为协程越多,调度的压力就越大,所造成的延迟也就上来了,因此这也是我为什么决定去做go的原因,也是通过了前面的思想,实现了驻留式的协程池
3. 用户的接入宽带.
4. 如果是微服务,还得看看要经历哪些结点,经历的结点越多也就越慢了
理解的CDN工作过程,从承载的内容来看,主要有静态网页,动态网页,下载型文件和应用协议, CDN会极大地简化网站的维护工作,只需要将内容通过指定的工具注入到CDN系统,CDN系统会自然的将内容和部署到各个物理位置的服务器进行全网分发,而至于其分发策略,我实现的是Kademlia协议
传统的bs应用中,用户通过浏览器发送请求到服务器,服务器根据相应的指定做出相应的反映,其过程,我所知道的哈,应该是这样
1. 用于输入网站域名,按下 enter
2. 浏览器首先向本地DNS服务器请求对该域名的解析,其实就是看看host文件中有没有指定的域名,如果有就直接对该地址建立连接发起请求,当然也有缓存的,如果缓存中找得到,就忽略了上面的步骤了
3. 如果本地DNS没有找到该域名,则会向指定的在全网中去查找这个域名
4. 如果找到会返回相应的IP
5. 得到IP后,浏览器向服务器发起请求
6. 服务器将处理结果返回给浏览器
而加入CDN后,其实对于使用者而言,我觉得没什么区别,最简单的CDN网络有一个DNS服务器和几台缓存服务器就可以了,其流程,我理解的是这样的
1. 当浏览器请求一个URL资源内容的时候,首先,会由网站的DNS来进行域名解析,该DNS服务器中会有一条CNAME记录,意思是将域名解析交给CDN DNS总服务器
2. CDN的DNS服务器将全局CDN负载均衡设备的IP作为域名解析的结果返回给浏览器
3. 当拿到全局负载设备IP后,用户向该IP发送URL请求
4. 全局服务器收到请求后,根据IP算距离,选择距离最小的一台服务器为用户服务,且将这个最短距离的内容服务器的IP返回给用于
5. 用户向这个有服务能力,且距离最短的 发起内容请求
总上所述,使用CDN服务的网站,只需要将域名解析权交给CDN,将所需的内容发布到所有的CDN内容服务器上,就可以实现内容加速了,综合说法就是,选择最优设备为用户提供服务,如果某个内容被很多用户所需要,它被缓存到距离用户最近的结点中