1.WEB与网络
Web 使用一种名为 HTTP的协议作为规范,完成从客户端到服务器端等一系列运作流程。而协议是指规则的约定。可以说,Web 是建立在 HTTP 协议上通信的。HTTP协议是Hyper Text Transfer Protocol(超文本传输协议)的缩写,是用于从万维网(WWW:World Wide Web )服务器传输超文本到本地浏览器的传送协议。HTTP基于TCP/IP通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)。
各种协议与 HTTP 协议的关系:
2.使用 Cookie 的状态管理
HTTP 是一种不保存状态,即无状态(stateless)协议。HTTP怎么样保持状态:可以通过cookie保持数据。Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。
Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息,通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时,客户端会自动在请求报文中加入 Cookie 值后发送出去。服务器端发现客户端发送过来的 Cookie 后,会去检查究竟是从哪一个客户端发来的连接请求,然后对比服务器上的记录,最后得到之前的状态信息。
Cookie与Session的作用和区别
Cookie一般为小型的文本文件,是一些网站为了记录用户身份会把经过加密的数据存储在用户终端机器上,随客户端暂时或永久保存。
Session即会话控制,Session对象会存储一些由特定用户在会话过程中需要用到的配置信息。
Cookie与Session的最大区别是前者的数据存储在在浏览器端,而后者的数据则存储在服务器端。 相对Cookie来说,Session更加高效、安全。
Cookie与Session的优缺点
优点 | 缺点 | |
cookie | 极高的扩展性和可用性: 通过良好的编程,控制保存在cookie中的session对象的大小; 通过加密和安全传输技术(SSL),减少cookie被破解的可能性; 只在cookie中存放不敏感数据,即使被盗也不会有重大损失; 控制cookie的生命期,使之不会永远有效。偷盗者很可能拿到一个过期的cookie。 | Cookie数量和长度的限制。每个domain最多只能有20条cookie,每个cookie长度不能超过4KB,否则会被截掉; 安全性问题。如果cookie被人拦截了,那人就可以取得所有的session信息。即使加密也与事无补,因为拦截者并不需要知道cookie的意义,他只要原样转发cookie就可以达到目的了; 有些状态不可能保存在客户端。例如,为了防止重复提交表单,我们需要在服务器端保存一个计数器。如果我们把这个计数器保存在客户端,那么它起不到任何作用。 |
session | 如果要在诸多Web页间传递一个变量,那么用Session变量要比通过QueryString传递变量可使问题简化; 要使WEb站点具有用户化,可以考虑使用Session变量。你的站点的每位访问者都有用户化的经验,基于此,随着LDAP和诸如MS Site ; Server等的使用,已不必再将所有用户化过程置入Session变量了,而这个用户化是取决于用户喜好的; 你可以在任何想要使用的时候直接使用session变量,而不必事先声明它,这种方式接近于在VB中变量的使用。使用完毕后,也不必考虑将其释放,因为它将自动释放。 | Session变量和cookies是同一类型的。如果某用户将浏览器设置为不兼容任何cookie,那么该用户就无法使用这个Session变量; 当一个用户访问某页面时,每个Session变量的运行环境便自动生成,这些Session变量可在用户离开该页面后仍保留20分钟!(事实上,这些变量一直可保留至“timeout”。“timeout”的时间长短由Web服务器管理员设定。一些站点上的变量仅维持了3分钟,一些则为10分钟,还有一些则保留至默认值20分钟。)所以,如果在Session中置入了较大的对象(如ADO recordsets,connections, 等等),那就有麻烦了!随着站点访问量的增大,服务器将会因此而无法正常运行; 因为创建Session变量有很大的随意性,可随时调用,不需要开发者做精确地处理,所以,过度使用session变量将会导致代码不可读而且不好维护。 |
3.HTTP协议的请求与响应
左图请求,右图响应
请求报文:
- 方法,POST、GET等等
- url——输入的网址
- 版本——http版本
常见的方法:
- GET——从服务器获取资源。返回什么,由服务器决定。
- POST——他需要主动告知服务器一些信息,而不是获取。告知服务器的信息一般会放在正文里。正文可以有各种形式,常见的是JSON。
- PUT——向指定资源位置上传最新内容。与POST的区别之处在于,POST常用于创建资源,PUT通常用于修改资源。
- DELETE——删除资源。
- HEAD——获得报文首部,HEAD 方法和 GET 方法一样,只是不返回报文主体部分。用于确认URL的有效性及资源更新的日期时间等。
请求行下面就是首部字段。首部是key value(首部字段名: 字段值),通过冒号分隔。这里往往用于保存一些重要的字段。
一般有 4 种首部,分别是:通用首部、请求首部和实体首部。其他,可能包含 HTTP 的 RFC 里未定义的首部(Cookie 等)。
通用首部
Cache-Control 控制缓存的行为
Connection 逐跳首部、连接的管理
Date 创建报文的日期时间
Pragma 报文指令
Trailer 报文末端的首部一览
Transfer-Encoding 指定报文主体的传输编码方式
Upgrade 升级为其他协议
Via 代理服务器的相关信息
Warning 错误通知
请求首部
Accept 用户代理可处理的媒体类型
Accept-Charset 优先的字符集
Accept-Encoding 优先的内容编码
Accept-Language 优先的语言(自然语言)
Authorization Web认证信息
Expect 期待服务器的特定行为
From 用户的电子邮箱地址
Host 请求资源所在服务器
If-Match 比较实体标记(ETag)
If-Modified-Since 比较资源的更新时间
If-None-Match 比较实体标记(与 If-Match 相反)
If-Range 资源未更新时发送实体 Byte 的范围请求
If-Unmodified-Since 比较资源的更新时间(与If-Modified-Since相反)
Max-Forwards 最大传输逐跳数
Proxy-Authorization 代理服务器要求客户端的认证信息
Range 实体的字节范围请求
Referer 对请求中 URI 的原始获取方
TE 传输编码的优先级
User-Agent HTTP 客户端程序的信息
实体首部:
Allow 资源可支持的HTTP方法
Content-Encoding 实体主体适用的编码方式
Content-Language 实体主体的自然语言
Content-Length 实体主体的大小(单位:字节)
Content-Location 替代对应资源的URI
Content-MD5 实体主体的报文摘要
Content-Range 实体主体的位置范围
Content-Type 实体主体的媒体类型
Expires 实体主体过期的日期时间
Last-Modified 资源的最后修改日期时间
③实体(body)
报文主体
响应
响应报文基本上由协议版本、状态码(表示请求成功或失败的数字代码)、用以解释状态码的原因短语、可选的响应首部字段以及实体主体构成。
状态行
包括HTTP协议的版本、状态码、状态文本。例如:HTTP/1.1 403 Forbidden
常见状态码:
- 100~199:表示服务器成功接收部分请求,要求客户端继续提交其余请求才能完成整个处理过程。
- 200~299:表示服务器成功接收请求并已完成整个处理过程。常用200(OK 请求成功)。
- 300~399:为完成请求,客户需进一步细化请求。例如:请求的资源已经移动一个新地址、常用302(所请求的页面已经临时转移至新的url)、307和304(使用缓存资源)。
- 400~499:客户端的请求有错误,常用404(服务器无法找到被请求的页面)、403(服务器拒绝访问,权限不够)。
- 500~599:服务器端出现错误,常用500(请求未完成。服务器遇到不可预知的情况)。
首部(headers)
一般有 4 种首部,分别是:通用首部、响应首部和实体首部。其他,可能包含 HTTP 的 RFC 里未定义的首部(Cookie 等)。
响应首部
Accept-Ranges 是否接受字节范围请求
Age 推算资源创建经过时间
ETag 资源的匹配信息
Location 令客户端重定向至指定URI
Proxy-Authenticate 代理服务器对客户端的认证信息
Retry-After 对再次发起请求的时机要求
Server HTTP服务器的安装信息
Vary 代理服务器缓存的管理信息
WWW-Authenticate 服务器对客户端的认证信息
实体(body)
不是所有的响应都有body,具有状态码的响应,通常不会有body。