WEB架构发展
1.单机架构，所有应用内程序都在本机运行，所有的数据也都保存在本机上。表示层，应用层喝数据层位于统一主机上
2.工作站/服务器架构（W/S）在服务器上保存数据，在工作站上处理数据。数据层位于服务器端，应用层和表示层位于工作站。
3.客户端/服务器架构（C/S）客户机想服务器发出之灵，服务器上存储喝处理数据，服务器完成数据处理将结果返回客户机进行二次处理。数据层和应用位于服务器，表示层位于客户端。
4.浏览器/服务器架构（B/S）雾浮起处理数据并生成页面，客户级上浏览请求页面和显示页面
5.客户端/应用服务器/数据服务器（C/S/S）在客户端和和服务器之间加入中间层，即应用服务器。
6.Web浏览器/Web服务器/数据库服务器（B/S/S）由Web浏览器、Web服务器、中间件、数据库服务器组成，各组成部分之间物理上通过intranet或Internet相链接，软件上遵守HTTP协议，浏览器通过发送请求和服务器端建立链接，从而实现整个Internet为背景的数据存储和访问。中间件是一个用API定义的软件层，是具有清大通信能力和良好可扩展性的分布式软件管理框架
7.四层体系结构，包括WEB浏览器、WEB服务器、应用服务器、数据库服务器
从单机结构到四层结构或者多层结构，技术方面也从最初的浏览器展示，服务端控制，经历前端组件化、后端为主
MVC时代、Ajax带来的SPA时代（Single Page Application 单页免应用）、前后端分离、前端为主的MV*时代。
随着WEB架构的不断发展API重要性逐渐提现出来，目前API 接口层已经在软件开发过程中被独立出来
OSI七层协议
应用层 文件传输，电子邮件，文件服务，虚拟终端 TFTP，HTTP，SNMP，FTP，SMTP，DNS，Telnet
表示层 数据格式化，代码转换，数据加密 没有协议
会话层 解除或建立与别的接点的联系 没有协议
传输层 提供端对端的接口 TCP，UDP
网络层 为数据包选择路由 IP，ICMP，RIP，OSPF，BGP，IGMP
数据链路层 传输有地址的帧以及错误检测功能 SLIP，CSLIP，PPP，ARP，RARP，MTU
物理层 以二进制数据形式在物理媒体上传输数据 ISO2110，IEEE802，IEEE802.2
应用层
传输层
网络层
数据链路层
物理层
HTML是一种用来定义网页的文本，超文本标记语言
HTTP是在网络上传输HTML的协议，用于浏览器和服务器的通信
当网络通信时采用TCP协议时，在真正的读写操作之前，客户端与服务器端之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时可以释放这个连接。连接的建立依靠“三次握手”，而释放则需要“四次握手”，所以每个连接的建立都是需要资源消耗和时间消耗的。
工作流程
1、客户端与服务器建立连接；
2、建立连接后，客户端发送一个请求给服务器；
3、服务器接到请求后，给予相应的响应信息；
4、客户端接收服务器所返回的信息通过浏览器显示，然后断开连接。
URL：（Uniform Resource Locator）统一资源定位符，对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示，是互联网上标准资源的地址。
HTTP使用统一资源标识符（URI）来传输数据和建立连接。URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息。
以下面这个URL为例：
http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
1.协议部分：代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等。在"HTTP"后面的“//”为分隔符
2.域名部分：“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用
3.端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口80/tcp
4.虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”
5.文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名
6.锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分（可以理解为定位）
7.参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。
域名解析
第一步：浏览器会检查缓存中有没有这个域名对应的解析过的IP地址，如果有，这个解析过程就结束了，直接拿到IP进行访问。这个浏览器缓存域名是有限制的，除了缓存大小有限制，缓存的时间也有限制，通常情况下由TTL属性来设置。
第二步：如果用户浏览器缓存中没有，浏览器会查找操作系统中是否有这个域名对应的DNS解析结果。windows中c:/windows/system32/drivers/etc/hosts文件设置，linux中/etc/hosts文件中设置。当解析到这个配置文件中的某个域名时，操作系统会在缓存中缓存这个解析结果。（修改文件后不立即生效的原因）
第三步：在网络配置中都会有“DNS服务器地址”这一项，当前面两步都不能解析时，操作系统会把这个域名发送给设置的DNS服务器（简称LDNS）-local缩写，一般是本地区的域名服务器也可以是自己设置的域名服务器地址，如果命中，那解析就此结束并返回IP并标记为非权威服务器的应答。如是学校的互联网，那么你的DNS服务器肯定在你的学校，如果你是一个小区接入互联网，那这个DNS就是提供给你接入互联网的应用供应商，即电信或联通。windows中能用ipconfig查看DNS服务器地址，linux中cat /etc/resolv.conf查看DNS Server。
第四步：如果LDNS没有命中，LDNS就会向Root Server域名服务器请求解析。LDNS会从配置文件里面读取13个根域名服务器的地址（这些地址是不变的，直接在BIND的配置文件中），然后像其中一台发起请求。
第五步:根服务器拿到这个请求后，知道他是com.这个顶级域名下的，所以就会返回com.域中的NS记录，一般来说是13台主机名和IP（主域名服务器地址即gTLD-国际顶级域名服务器地址），返回给本地域名服务器即LDNS，
第六步：LDNS再向上一步返回的其中一台gTLD服务器发送请求。com.域的服务器（gTLD）发现你这请求是baidu.com这个域的，一查发现了这个域的NS（一般就是你注册的域名服务器），那就返回给你，你再去查。
第七步：LDNS接受gTLD返回的域服务器地址（即域名服务提供商的域服务器）并向其中一台再次发起请求，在baidu.com的域下面查了下有www的这台主机，就把这个IP返回给你了。
第八步：LDNS接受返回的IP和TLL值
第九步：LDNS缓存这个域名和IP的对应关系，缓存时间有TLL控制
第十步：LDNS把解析的结果返回给用户，用户根据TLL值缓存在本地系统缓存中，域名解析结束。
返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性
2、HEAD
向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。
3、GET
向特定的资源发出请求。它本质就是发送一个请求来取得服务器上的某一资源。资源通过一组HTTP头和呈现数据（如HTML文本，或者图片或者视频等）返回给客户端。GET请求中，永远不会包含呈现数据。
4、POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 Loadrunner中对应POST请求函数：web_submit_data,web_submit_form
5、PUT
向指定资源位置上传其最新内容
6、DELETE
请求服务器删除Request-URL所标识的资源
7、TRACE
回显服务器收到的请求，主要用于测试或诊断
8、CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
状态码
状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：
1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操作
4xx：客户端错误--请求有语法错误或请求无法实现
5xx：服务器端错误--服务器未能实现合法的请求
常见状态代码、状态描述、说明：
200 OK //客户端请求成功
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized // 请求未经授权， 这个状态代码必须和WWW-Authenticate 报头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable // 服务器当前不能处理客户端的请求， 一段时间后，可能恢复正常
request
User_agent:发出请求的用户信息,客户端操作系统和浏览器的名称和版本
Accept:浏览器端可以接收的媒体类型
Accept-Language:浏览器申明主机接收的语言
Accept-Encoding:浏览器申明接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法
Referer:提供request的上下文信息的服务器，告诉服务器我是从哪个链接过来的
Cookie：最重要的header,将cookie值发送给http服务器
Connection:
keep-alive当一个网页打开完成后，客户端和服务器之间用于传输http数据的tcp链接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的链接
Close代表一个request完成后，客户端和服务器之间用于传输http数据的tcp链接会关闭，当客户端再次发送request，需要重新建立tcp链接
Cache-Control:Public 可以被任何缓存所缓存（）
Cache-Control:Private 内容只缓存到私有缓存中
Cache-Control:no-cache 所有内容都不会被缓存
max-age>0 时 直接从游览器缓存中 提取 max-age<=0 时 向server 发送http 请求确认 ,该资源是否有修改 ，有的话 返回200 ,无的话 返回304.
X-Forwarded-For:client1, proxy1, proxy2, proxy3
Content-Type:web服务器告诉浏览器自己响应的对象的类型和字符集。
Date:生成消息的具体时间和日期。
Server:指明http服务器的软件信息。
Tracecode:跟踪代码
Transfer-encoding:传输编码，chunked便士输出的内容长度不能确定。
X-powered-by:表示网站用什么技术开发的。
Expires:浏览器会在指定过期时间内使用本地缓存
Last-modified:指示资源的最后修改日期和时间
Content-length:实体正文长度
session
session的中文翻译是“会话”，当用户打开某个web应用时，便与web服务器产生一次session。服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。
cookie
cookie是保存在本地终端的数据。cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。
cookie的组成有：名称(key)、值(value)、有效域(domain)、路径(域的路径，一般设置为全局:"\")、失效时间、安全标志(指定后，cookie只有在使用SSL连接时才发送到服务器(https))。下面是一个简单的js使用cookie的例子:
用户登录时产生cookie:
document.cookie = "id="+result.data['id']+"; path=/";
document.cookie = "name="+result.data['name']+"; path=/";
document.cookie = "avatar="+result.data['avatar']+"; path=/";
使用到cookie时做如下解析：
var cookie = document.cookie;var cookieArr = cookie.split(";");var user_info = {};for(var i = 0; i < cookieArr.length; i++) {
user_info[cookieArr[i].split("=")[0]] = cookieArr[i].split("=")[1];
}
$('#user_name').text(user_info[' name']);
$('#user_avatar').attr("src", user_info[' avatar']);
$('#user_id').val(user_info[' id']);
token
token的意思是“令牌”，是用户身份的验证方式，最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token，避免多次查库
cookie 和session的区别
1、cookie数据存放在客户的浏览器上，session数据放在服务器上。
2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用COOKIE。
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
5、所以个人建议：
将登陆信息等重要信息存放为SESSION
其他信息如果需要保留，可以放在COOKIE中
token 和session 的区别
session 和 oauth token并不矛盾，作为身份认证 token安全性比session好，因为每个请求都有签名还能防止监听以及重放攻击，而session就必须靠链路层来保障通讯安全了。如上所说，如果你需要实现有状态的会话，仍然可以增加session来在服务器端保存一些状态
App通常用restful api跟server打交道。Rest是stateless的，也就是app不需要像browser那样用cookie来保存session,因此用session token来标示自己就够了，session/state由api server的逻辑处理。 如果你的后端不是stateless的rest api, 那么你可能需要在app里保存session.可以在app里嵌入webkit,用一个隐藏的browser来管理cookie session.
Session 是一种HTTP存储机制，目的是为无状态的HTTP提供的持久机制。所谓Session 认证只是简单的把User 信息存储到Session 里，因为SID 的不可预测性，暂且认为是安全的。这是一种认证手段。 而Token ，如果指的是OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对App 。其目的是让 某App有权利访问 某用户 的信息。这里的 Token是唯一的。不可以转移到其它 App上，也不可以转到其它 用户 上。 转过来说Session 。Session只提供一种简单的认证，即有此 SID，即认为有此 User的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方App。 所以简单来说，如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。如果永远只是自己的网站，自己的 App，用什么就无所谓了。
token就是令牌，比如你授权（登录）一个程序时，他就是个依据，判断你是否已经授权该软件；cookie就是写在客户端的一个txt文件，里面包括你登录信息之类的，这样你下次在登录某个网站，就会自动调用cookie自动登录用户名；session和cookie差不多，只是session是写在服务器端的文件，也需要在客户端写入cookie文件，但是文件里是你的浏览器编号.Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端。
Web缓存一般分为浏览器缓存、代理服务器缓存以及网关缓存，本文主要讲的是 浏览器缓存，其它两种缓存大家自行去了解下。
Web 缓存游走于服务器和客户端之间。这个服务器可能是源服务器（资源所驻留的服务器），数量可能是1个或多个；这个客户端也可能是1个或多个。Web 缓存就在服务器-客户端之间搞监控，监控请求，并且把请求输出的内容（例如html页面、 图片和文件）（统称为副本）另存一份；然后，如果下一个请求是相同的 URL，则直接请求保存的副本，而不是再次麻烦源服务器。
使用缓存的2个主要原因：
- 降低延迟：缓存离客户端更近，因此，从缓存请求内容比从源服务器所用时间更少，呈现速度更快，网站就显得更灵敏。
- 降低网络传输：副本被重复使用，大大降低了用户的带宽使用，其实也是一种变相的省钱（如果流量要付费的话），同时保证了带宽请求在一个低水平上，更容易维护了。
试想现在的大型网站，随便一个页面都是一两百个请求，每天 pv 都是亿级别，如果没有缓存，用户体验会急剧下降（表现在等待请求的时间上）、同时服务器压力和网络带宽都面临严重的考验。
http下加入ssl层，https的安全基础是ssl(secure socket layer)
