网站服务器

[更新20200218：这是之前写的，纯粹是好玩，但后来做活动买了个一年99元的腾讯云，最近我在腾讯云上通过LNMP环境搭建了个基于wrodpress的个人博客网站 https://www.cnblogs.com/wangyi0419/p/12327215.html ] 出于个人兴趣，想搭建一个自己的网站玩玩。 先在华为云买个云服务器，由于是第一次玩，先买个windows server 2019版的，2核4G，以后弄熟了再上手linux吧。、 经过重置密码，设置安全组等简单配置后登录服务器主机： 然后就是安装配置一下Web服务器IIS： 添加角色 一路下一步，选择IIS 然后选择个ftp，下一步安装即可。 然后在windows管理工具里面可以看到刚安装的IIS： 打开后会看到有个默认的站点： 看他的工作目录在C盘下的inetpub/wwwroot 至此，访问云服务器的公网ip就可以打开这里面的index.html页面了。 可以自己在自己的电脑把页面写好push到github上，再用云主机去下载。 来源： https://www.cnblogs.com/wangyi0419/p/11531828.html

　　上篇文章我简要的介绍了下网站静态化的演进过程，有朋友可能认为这些知识有点过于稀松平常了，而且网站静态化的技术基点也不是那么高深和难以理解，因此它和时下日新月异的web前端技术相比，就显得不伦不类了。其实当我打算写本系列的之前我个人觉得web前端有一个点是很多人都知道重要，但是有常常低估它作用的，那就是web前端和web服务端如何融合的这个点上，这个点再加上我们要做出一个规模庞大，高并发，快速响应的网站时候它对于web前端的架构技术的演进起到了一个不可忽视的作用。 　　网站的web前端要实现高效，第一个要解决的短板就是网络的延迟性对网站的加载效率的影响，当然很多人会说网速快不快这是网络运营商的问题，不是网站的问题，但是大家肯定也见过就算我们用上了千兆宽带也会有些网站加载速度慢的让人无法忍受，网站本身的确是没法控制网络速度的能力，但是如果我们不降低网络对页面加载效率的影响，其他任何优化网站的手段也就无从谈起，原因就是网络效率对于网页加载效率的影响是起到大头作用的，只有这个大头被解决了，那么解决其他的小头才能发挥作用。 　　回到上文讲到的网站静态化的关键点动静分离，解决这个关键点的本质就是为了降低网速对网站加载效率的影响，但是我们在处理动静分离问题时候采取的策略不同会对我们整个网站架构产生重大影响，特别是将网页做好动静拆分后，静态的资源尽力向浏览器端推移

　　前文里我讲到了网站静态化的关键点是动静分离， 动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来，动静资源做好了拆分以后，我们就可以根据静态资源的特点将其做缓存操作，这就是网站静态化处理的核心思路 。由此可见，网站静态化处理的核心就是 动静分离和缓存 两大方面，上篇我简单讲述了动静整合的基础知识，本篇将会讲述两大核心之一的动静分离策略，只有把动静分离策略做好了，缓存才能发挥出它应有的效果。 　　下面我们要讨论下动静分离的策略了，一个页面什么内容是动态的，什么内容是静态的，这个我们到底该如何来区分了？这个问题学问非常大，我们的标准不同，最后拆分出来的动静资源就会存在很大的不同。在本系列开篇里，我提到了什么样的页面是静态页面，什么样的页面是动态页面，我是以一个url的角度定义的，每个独立的页面都会有一个url，这个url就好比这个页面的门牌号，我们每次访问这个url时候如果得到的响应页面都是一样的那么我们就认为该页面是静态页面，如果访问某个url，我们访问的时间不同，最后展示的页面也不一样那么这个页面就是动态页面，动态页面就是我们要进行动静分离的载体了，我们可以看到我的定义其实是和时间相关的，也就是说访问时间不同，得到的结果会不一致，所以我们可以根据时间这个维度分析页面里那些内容是静态的，那些是动态，但是这个划分在实际情况里就会变得非常复杂

原文：http://lusongsong.com/reed/350.html 再好的网站，如果打开速度慢，10个人会有9个人选择离开，我归纳了大约9大影响网站打开速度的因素，但网站页面显示的速度取决于众多的因素，包括 服务器性能、网络传输质量、网站的带宽、DNS解析、网页内容包括涉及到的JS代码、图片和视频的大小等等各种因素，如有不全，欢迎跟帖补充和指正。 （再好的网站，如果打开速度慢，10个人会有9个人选择离开） 1：网络最小带宽 这是最主要的因素，在慢的网站放在好的带宽下访问速度一样快（就是多花钱），网络的带宽包括对网站所在服务器带宽和用户端两个位置，对接点指的是出口端与入口端(如电信对网通的对接点)，另一个就是用户本身的最小带宽，如果用户办的是512K宽带咱就爱莫能助了。 2：DNS解析时间 DNS解析 包括往返解析的次数及每次解析所花费的时间，它们两者的积就是DNS解析所消耗的时间，因此，很多人忽视了DNS的问题，其实，DNS对网站解析速度也是非常重要的，如Google近期推出的 Page Speed Service 和国内的DNSPOD等免费给域名做DNS加速的，大家可以一试。 3：机器的配置 包括服务器端与客户机端的硬件配置程度，同样的网络环境下，双核的服务器的运算能力肯定要强一些，毫无疑问的，同样的网络环境下，你用一台赛扬的机器和奔四双核处理器的电脑，打开同样的网页

目录 访问流程简述 DNS域名解析 建立tcp三次握手 客户端发出http请求 服务端发出http响应 tcp四次挥手断开连接 网站集群内部请求分析 ~~~~~~~~ 因为想要面对一个新的开始，一个人必须有梦想、有希望、有对未来的憧憬。如果没有这些，就不叫新的开始，而叫逃亡。 ​​​​ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ————玛丽亚·杜埃尼亚斯 我们经常使用浏览器上网查询资源，看到网页从空白到丰满，这可能是一瞬间，也有可能要几秒钟或者直接弹出错误等。那么这背后的工作流程究竟是怎样的呢？接下来以访问www.baidu.com为例，进行一个流程的分析。 访问流程简述 当用户在浏览器地址中输入www.baidu.com时，需要经历如下几个流程：DNS域名解析——>建立tcp三次握手——>客户端发出http请求——>服务端发出http响应——>tcp四次挥手断开连接 DNS域名解析 DNS被称为域名解析系统，主要作用就是负责将域名解析为对应的IP地址（当然还有反向解析，即将ip解析为域名，一般很少用）。比如解析一下百度 在DNS解析中分为两种查找方式： 递归查询和迭代查询 递归查询：由DNS客户端发起，一级一级的向上提交查询申请

大型网站的特点 以用户为中心，用户多，分布广泛 流量大，并发高，数据量大 安全环境恶劣，容易受到网络攻击 需求多，频繁发布 系统从小到大，渐进发展 大型网站的架构目标 高性能：提供快速访问体验（响应时间短，兵法处理能力强，吞吐量高） 高可用：网站服务一直可以正常访问（负载均衡，冗余备份） 可伸缩：可通过增加或减少服务器来提高或降低处理能力 扩展性：方便的通过新增/移除方式，增加/减少新的功能/模块 安全性：提供网站安全访问和数据加密，安全存储等策略 大型网站的架构演变历程 1.所有的应用服务器，数据库和文件都在同一台服务器上。 .在网站刚刚开始的时候，并没有很多的访问量，所以只需要一台服务器就足够了，这时候的网站架构如下图所示： 2.进行数据和应用的分离 随着网站的业务发展，增加的访问导致性能降低，增加的数据导致存储空间不足，这时候就需要进行数据和应用的分离： 分离后的服务器： 应用服务器：需要处理大量的业务逻辑，所以需要更强大的CPU； 文件服务器：要存储更多的静态文件，所以需要更大的硬盘； 数据库服务器：需要快速磁盘检索和数据缓存，所以需要更快的硬盘和更大的内存； 应用和数据的分离，提高了网站的并发处理能力和数据存储空间，使网站的性能得以改善。 3.使用缓存改善网站性能 网站的数据访问满足二八定律，即80%的业务访问集中在20%的数据上，例如微博热搜

一直呼 花2块钱体验了一把被科技虐的感觉，原理就像你在电影或新闻里看到的黑客攻击服务器一样，利用多次拨号形成拨号轰炸，一直占你的线路；多短信形成短信轰炸进行骚扰。 一直呼 过程 买体验卷，输入号码，一键点击开始进程，刚开始有点延迟，我还以为这个网站是假的，随后... 验证码铺天盖地而来 ，WTF它hack了那么多服务器？ 最后体验卷还送你一个验证码接收电话 后记 没试电话轰炸，这威力也够了。卡拉什尼科夫说过，武器没有罪，有罪的是使用武器的人。不知道这网站还能存活多久，但愿长久吧，给网络空间留点自由的土壤。 来源： https://www.cnblogs.com/lyzz1314/p/12328116.html

千万级的注册用户，千万级的帖子，nTB级的附件，还有巨大的日访问量，大型网站采用什么系统架构保证性能和稳定性？ 首先讨论一下大型网站需要注意和考虑的问题。 数据库海量数据处理 ：负载量不大的情况下select、delete和update是响应很迅速的，最多加几个索引就可以搞定，但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下，更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。 高并发死锁 ：平时我们感觉不到，但数据库死锁在高并发的情况下的出现的概率是非常高的。 文件存储的问题 ：大型网站有海量图片数据、视频数据、文件数据等等，他们如何存储并被有效索引？高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者海南的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。 接下来讨论大型网站的底层系统架构，来有效的解决上述问题。 毋庸置疑，对于规模稍大的网站来说，其背后必然是一个服务器集群来提供网站服务，例如，2004年eBay的服务器有2400台，估计现在更多。当然，数据库也必然要和应用服务分开，有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。 下面

千万级的注册用户，千万级的帖子，nTB级的附件，还有巨大的日访问量，大型网站采用什么系统架构保证性能和稳定性？ 首先讨论一下大型网站需要注意和考虑的问题。 数据库海量数据处理 ：负载量不大的情况下select、delete和update是响应很迅速的，最多加几个索引就可以搞定，但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下，更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。 高并发死锁 ：平时我们感觉不到，但数据库死锁在高并发的情况下的出现的概率是非常高的。 文件存储的问题 ：大型网站有海量图片数据、视频数据、文件数据等等，他们如何存储并被有效索引？高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者海南的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。 接下来讨论大型网站的底层系统架构，来有效的解决上述问题。 毋庸置疑，对于规模稍大的网站来说，其背后必然是一个服务器集群来提供网站服务，例如，2004年eBay的服务器有2400台，估计现在更多。当然，数据库也必然要和应用服务分开，有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。 下面

千万级的注册用户，千万级的帖子，nTB级的附件，还有巨大的日访问量，大型网站采用什么系统架构保证性能和稳定性？ 首先讨论一下大型网站需要注意和考虑的问题。 数据库海量数据处理 ：负载量不大的情况下select、delete和update是响应很迅速的，最多加几个索引就可以搞定，但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下，更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。 高并发死锁 ：平时我们感觉不到，但数据库死锁在高并发的情况下的出现的概率是非常高的。 文件存储的问题 ：大型网站有海量图片数据、视频数据、文件数据等等，他们如何存储并被有效索引？高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者海南的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。 接下来讨论大型网站的底层系统架构，来有效的解决上述问题。 毋庸置疑，对于规模稍大的网站来说，其背后必然是一个服务器集群来提供网站服务，例如，2004年eBay的服务器有2400台，估计现在更多。当然，数据库也必然要和应用服务分开，有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。 下面