B/S架构带来的两个好处:
客户端使用同一的浏览器,不仅仅浏览器具有统一性,而且,浏览器的交互特性使得用户使用非常简单,且用户行为的可继承性非常强
服务端基于同一的HTTP,使用统一的HTTP为服务上简化了开发模式。
1.1 B/S架构概述
传统的大多数C/S架构采用的是长连接的交互模式,而HTTP采用的是无状态短连接的方式,通常情况下,一次请求就完成一次数据交互,然后这次通信就断开了。
B/S架构图如下图所示:
过程如下
一个URL回车,会发生很多的操作。首先进行DNS解析成IP地址,然后根据IP地址找到对应的服务器,发送一个get请求,服务器返回默认的数据资源给访问的用户。过程中服务器可能很多台,业务可能很复杂, 然后具体哪一台服务器返回数据,以及静态资源的存放获取等,每一个细节都会影响这一个过程是否能够成功。
不管网络架构如何变化,始终有一个固定不变的原则需要遵守
互联网上所有的资源都要用一个URL来表示。
必须基于HTTP与服务端进行交互
数据展示必须在浏览器上运行
1.2 如何发起一个请求
既复杂又简单
不借助浏览器具有两层含义:
能不能自己组装一个HTTP的数据包
处理浏览器还有哪些方式也能简单的发起一个请求
发起一个HTTP请求,类似于完成一次Socket链接
开源工具包HttpClient可以模拟发送get和post请求,具体使用,请自行搜索。
如下是一段简单的示例代码
另外 在linux平台可以使用CRUL 命令进行操作。
如下是使用示意图:
也可以查看Http头信息,添加-I参数
也可以添加-HI选项
因为缺少cookie信息,所以返回302状态码,添加cookie信息如下所示:
1.3 HTTP解析
HttpHeader控制着互联网成千上万的用户的数据的传输。最关键的是,他控制着用户浏览器的渲染行为和服务器的执行逻辑。
常见的HTTP请求头
常见的HTTP响应头
常见的HTTP状态码
可以通过firefox的firebug和HttpFox或者Chrome的开发工具或者IE的测试工具进行查看具体的Http头信息
1.3.1 查看Http信息的工具
firebug如下图所示:
HttpFox如下图所示:
chrome自带的调试工具如下图所示:
1.3.2 浏览器的缓存机制
既复杂又简单
刷新页面就是重新请求页面。此时会在Http响应头信息中添加一些额外的信息
正常返回数据如下图所示:
刷新页面返回的数据如下图所示:
增加了两个头信息,如截图所示。
1.Cache-Control/Prama
用于指定所有的缓存机制在整个请求/响应链中必须服从的命令。具体说明如下图所示:
Cache-Control被支持的比较好,优先级也比较高。
Pragma和上面作用类似最常用的也就是Pragma:no-cache和Cache-Control:no-cache
2. Expires
使用格式
超过这个时间,缓存的内容也将失效。
3.Last-Modified/Etag
一般用于表示服务器上的资源的最后修改时间
Etag类似于Last-Modified。作用是让服务端给每个页面分配唯一的一个编号,然后通过 这个编号来区分这个页面是否是最新的。
1.4 DNS域名解析
将DNS域名解析成IP地址
1.4.1 DNS域名解析的过程
如下图所示:
第一步,浏览器会检查缓存中有没有这个域名对应的解析过的IP地址,不仅有时间限制,还有大小限制
第二步,如果用户浏览器没有缓存,浏览器会查找操作系统中是否有这个域名解析对应的DNS解析的结果。
前两步都是在本机完成
第三步,如何,怎么知道域名服务器?我们自己的网络配置都会有一个DNS服务器地址,将这个域名发送给LDNS,也就是本地区的域名服务器。通常不会很远。window下通过ipconfig进行查看,linux下通过cat /etc/resolv.conf查看DNS server
这个专门的域名解析服务器性能一般很好。当然缓存失效是通过时间进行控制的。大约80%的域名解析在此阶段完成。
第四步,如果LDNS仍然没有命中,就直接到RootServer域名服务器中请求解析
第五步,根域名服务器返回给本地域名服务器一个所查询域的主域名服务器(gTLDServer是国际顶级域名服务器,只有13台左右)
第六步,本地域名服务器,再向上一步的gTLDserver发送请求
第七步,接收请求的gTLD服务器查找并返回域名对应的NameServer域名服务器的地址,这个NameServer通常就是你注册的域名服务器的地址
第八步,NameServer域名服务器会查询存储的域名和Ip映射关系表
第九步,返回对应的Ip地址和TTL值 LDNS会缓存这两个值
第十步,把解析的结果返回给用户,根据TTL值,缓存对应的解析的DNS到本地系统缓存中,解析过程结束。
当然也不只是十步,大体上过程如上所示。
1.4.2 跟踪域名解析的过程
linux和window是下都可以通过nslookup命令查看解析的结果。如下图所示:
linux下可以通过dig命令进行查看,具体可以自行进行查看
1.4.3 清除缓存的域名
DNS解析的结果存放地方主要有两个。一个是LDNS,一个是用户的本地机器。都可以通过设置TTL值和本地缓存大小进行控制。
windows下通过ipconfig/flushdns来刷新缓存
linux下通过/etc/inti.d/nscd restart来清除缓存
java的缓存策略有两种:一种是正确解析的结果进行缓存,一种是失败的解析结果进行缓存。两个配置项可以通过networkaddress.cache.ttl和networdaddress.cache.negative.ttl进行设置,默认值,-1(永不失效)和0(缓存10秒),也可以通过添加参数-Dsun.net.inetaddr.ttl=xxx进行控制如果使用的是InetAddress进行域名解析,一定要使用单例模式,否则性能会变差。
1.4.4 几种域名的解析方式
A记录:用来指定域名对应的IP地址
MX记录: Mail Excharge 可以将某个域名的邮件服务器指向自己的Mail Server
CNAME记录:Canonical Name 别名解析,就是可以为一个域名设置一个或者多个别名
NS记录:为某个域名指定DNS解析服务器,也就是这个域名指定的IP地址的DNS服务器去解析。
TXT记录:为某个主机名或者域名设置说明。
1.5 CDN 工作原理
CDN Content Delivery Network 内容分布网络
一种先进的流量分配网络。
目的通过现有的Internet中增加一层新的网络架构,将网站的内容发布到最接近用户的网络“边缘”,提高用户访问网站的响应速度
CDN= MIRROR+Cache+GSLB(整体负载均衡)
目前以静态数据为主
实现的几个目标:
可扩展:性能扩展性和成本扩展性
安全性
可靠性、响应和执行
1.5.1 CDN技术架构
如下图所示:
一个用户访问某个静态资源,这个静态文件的域名假如是cnd.taobao.com,那么首先向LDNS发起请求,一般经过迭代解析后回到这个域名的注册服务器去解析,这时这个DNS解析服务器通常会把它重新cname到另外一个域名,而这个最终的域名指向CDN全局中的DNS负载均衡服务器,再由这个GTM来最终分配那个地方的访问用户,返回给里这个用户最近的CDN节点。
1.5.2 负载均衡
对工作任务进行平均、分摊到多个操作单元上进行,共同完成工作任务,避免软硬件出现单点故障,解决网络拥堵问题,实现地理无关性,为用户提供一致的访问质量。
三种负载均衡的架构:链路负载均衡,集群负载均衡,和操作系统负载均衡。
链路负载均衡:通过DNS解析成不同的IP,然后用户根据这个IP来访问不同的目标服务器。如下图所示:
优点是:用户会直接访问目标服务器,而不需要经过其他代理服务器。
缺点:由于用户本地和LDNS都存在缓存,一旦某个WebServer宕机,那么就很难及时更新用户的解析结构。
集群负载均衡:
一般分为软件负载和硬件负载
硬件负载:优点是性能好,缺点是价格昂贵
软件负载:特点是成本低,直接使用廉价的PC就可以搭建。缺点是一般一次访问要经过多个代理服务器,会增加网络负担。
硬件负载如下图所示:
软件负载:
操作系统负载
利用操作系统级别的软中断或者硬件中段来达到负载均衡。
1.5.3 CDN动态加速
是一种优化技术
技术原理是CND的DNS域名解析中通过动态的链路探测来寻找回源最好的一条路径,从而加速用户访问的效率。
如下图所示:
本章内容知识点如上所示,我们下篇博文再见。