五、协议：HTTP
1. HTTP(Hyper Text Transfer Protocol:超文本传送协议)
WWW服务器和本地浏览器之间传输超文本的传送协议，运行在应用层，默认端口号：80
1) 请求-响应构成 ——方法、状态码、属性
2) 不记录状态 ——session、cookie
3) 运行在TCP（传输层）之上的应用层 ——Tcp/Ip、ARP、DNS、路由选择
4) 通信使用明文（不加密），内容可能会被窃听 ——HTTPS
5) 不验证通信方的身份，有可能遭遇伪装 ——HTTPS
6) 无法证明报文的完整性，有可能遭遇篡改 ——HTTPS
7) 一个连接上只可发送一个请求 ——SPDY
8) 请求只能从客户端开始.客户端不可以接收除响应以外的指令 ——Comet、SPDY、WebSocket
9) 请求/响应首部未经压缩就发送.首部信息越多延迟越大 ——SPDY、WebSocket
10) 发送冗长的首部.每次互相发送相同的首部造成的浪费较多 ——SPDY、WebSocket
11) 可任意选择数据压缩格式.非强制压缩发送 ——SPDY
12) 发展历程：
连接-请求-响应-断开（每一次http通信就要断开一次tcp连接）（通信量开销大）
——>持久连接（即Connection:keep-alive一次连接，多次请求，直到任意一方明确提示断开连接）（减少了tcp连接的重复建立和断开所造成的额外开销）
——>管线化(pipelining)（并行请求）
DNS(Domain name resolution,域名解析协议):在应用层,提供通过域名查找IP地址,或逆向从IP地址反查域名的服务
ARP(Address Resolution Protocol,地址解析协议):在数据链路层，根据通信方的IP地址反查出对应的MAC地址
路由选择机制:在网络层，
1.1. HTTP请求
请求方法+URI（host+端口号+url）+协议版本
请求头（header）
（空行）
请求主体（body）
1.1.1. 请求方法
请求方法需要大写
1.1.1.1. GET获取资源
例：
GET /index.html HTTP/1.1
Host:www.hackr.jp
响应：index.html的页面资源
1.1.1.2. POST传输实体主体
例：
POST /submit.cgi HTTP/1.1
Host:www.hackr.jp
Content-Length:1560(1560字节的数据)
响应：返回submit.cgi接收数据的处理结果
注：GET和POST方法的区别：
1) GET提交的数据会放在URL之后，以问号（？）分割URL和传输数据，参数之间以&连接，POST方法是把提交的数据放在HTTP包的Body中；
2) GET提交的数据大小有限制（因为浏览器对URL的长度有限制），而POST方法提交的数据大小没有限制。
3) GET方式需要使用Repuest. QueryString来取得变量的值，而POST方法通过Request.Form来获取变量的值；
4) GET方法提交数据会带来安全问题，用户名和密码等参数会出现在URL上，如果页面可以被缓存或者其他人访问这台机器，就可以从历史记录获得该用户的账号和密码。
1.1.1.3. PUT传输文件
注：由于PUT方法本身不带验证机制，任何人都可以上传文件，存在安全问题，因此一般不使用，若配合web应用程序的验证机制，或架构设置采用REST（Representational State Transfer，表征状态转移）标准，才可能使用
例：
PUT /example.html HTTP/1.1
Host:www.hackr.jp
Content-Type:text/html
Content-Length:1560(1560字节的数据)
响应：返回状态码（服务器处理结果）
1.1.1.4. HEAD获得报文首部
和GET相同，只是不返回报文主体部分，用于确认URI的有效性及资源更新的日期时间等
例：
HEAD /index.html HTTP/1.1
Host:www.hackr.jp
响应：返回index.html有关的响应首部
1.1.1.5. DELETE删除文件
与PUT相反，删除请求URI指定的资源
与PUT相同，不安全，所以不常用
例：
DELETE /example.html HTTP/1.1
Host:www.hackr.jp
响应：返回删除处理的状态码
1.1.1.6. OPTIONS询问支持的方法
查询针对请求URI指定的资源支持的方法
例：
OPTIONS * HTTP/1.1
Host:www.hackr.jp
响应：HTTP/1.1 200 OK
Allow:GET,POST,HEAD,OPTIONS（返回服务器支持的方法）
1.1.1.7. TRACE追踪路径
让web服务器端将之前的请求通信返回给客户端
发送请求时，在Max-Forwards首部填入数值，每经过一个服务器端就将该数值减1，直接 减到0时，则停止传输，最后接收到请求的服务器端则返回状态码200 OK的响应
通过此方法，客户端可以查询发送出去的请求是怎样被加工修改/篡改的
缺点：容易引发XST（Cross-Site Tracing,跨站追踪）攻击
例：
TRACE / HTTP/1.1
Host: hackr.jp
Max-Forwards:2
响应：HTTP/1.1 200 OK
Content-Type:message/http
Content-Length:1024
TRACE / HTTP/1.1
Host:hackr.jp
Max-Forwards:2(返回响应包含请求内容)
1.1.1.8. CONNECT要求隧道协议连接代理
例：
CONNECT proxy.hackr.jp:8080 HTTP/1.1
Host:proxy.hackr.jp
响应：HTTP/1.1 200 OK（之后进入网络隧道）
1.2. HTTP响应
协议版本+响应状态码+状态说明
响应头（header）
（空行）
响应主体（body）
1.2.1. 1XX状态码：信息提示
1.2.1.1. 100 Continue
服务器仅接收到部分请求，但是一旦服务器并没有拒绝该请求，客户端应该继续发送其余的请求。
1.2.1.2. 101 Switching Protocols
服务器转换协议：服务器将遵从客户的请求转换到另外一种协议。
1.2.2. 2XX成功
1.2.2.1. 200 OK
请求成功（其后是对GET和POST请求的应答文档）。
1.2.2.2. 201 Created
请求被创建完成，同时新的资源被创建。
1.2.2.3. 202 Accepted
供处理的请求已被接受，但是处理未完成。
1.2.2.4. 203 Non-authoritative Information
文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝。
1.2.2.5. 204 No Content
没有新文档。浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的。
1.2.2.6. 205 Reset Content
没有新文档。但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容。
1.2.2.7. 206 Partial Content
客户发送了一个带有Range头的GET请求，服务器完成了它。
一般头部会带有Range属性
视频网站的边看边下载就是使用206状态码来实现断点续传的。
1.2.3. 3XX重定向
1.2.3.1. 300 Multiple Choices
多重选择。链接列表。用户可以选择某链接到达目的地。最多允许五个地址。
1.2.3.2. 301 Moved Permanently
永久性重定向：所请求的页面已经转移至新的url。
1.2.3.3. 302 Found
临时性重定向：所请求的页面已经临时转移至新的url。
1.2.3.4. 303 See Other
所请求的页面可在别的url下被找到。
和302功能相同，但303会明确表示客户端应当采用GET方法获取资源
1.2.3.5. 304 Not Modified
未按预期修改文档。客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since：（日期）表示客户只想比指定日期更新的文档）。如果指定日期之后文件没有更新，则服务器告诉客户，原来缓冲的文档还可以继续使用。
1.2.3.6. 305 Use Proxy
客户请求的文档应该通过Location头所指明的代理服务器提取。
1.2.3.7. 307 Temporary Redirect
被请求的页面已经临时移至新的url。
与301、302功能相同，但301、302会自动将POST方法改成GET方法，并删除请求报文内的主体，之后请求会自动再次发送，但307，会遵照标准，不会从POST变成GET
1.2.4. 4XX客户端错误
1.2.4.1. 400 Bad Request
服务器未能理解请求。请求报文中存在语法错误，当错误发生时，需修改请求的内容后再次发送请求，浏览器会像对待200 OK一样对待该状态码。
1.2.4.2. 401 Unauthorized
被请求的页面需要有通过HTTP认证（BASIC认证、DIGEST认证）的认证信息（用户名和密码）。
返回401的响应必须包含一个适用于被请求资源的www-Authenticate首部用来质询用户信息。浏览器初次接收到401时，会弹出认证用的对话窗口。
1.2.4.3. 403 Forbidden
请求资源访问被服务器拒绝了。如：未获得文件系统的访问授权，访问权限出现问题。
1.2.4.4. 404 Not Found
服务器无法找到被请求的页面。也可以在服务器端拒绝请求且不想说明理由时使用。
1.2.5. 5XX服务器错误
1.2.5.1. 500 Internal Server Error
请求未完成。服务器遇到不可预知的情况。服务器在执行请求时发生了错误，也可能是web应用存在的bug或某些临时的故障。
1.2.5.2. 502 Bad Gateway
请求未完成。服务器从上游服务器收到一个无效的响应。
1.2.5.3. 503 Service Unavailable
请求未完成。服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入Retry-After首部字段再返回给客户端。
1.3. HTTP属性
1.3.1. Header属性
1.3.1.1. Accept
客户端可接受的媒体类型
Accept：text/html代表浏览器可以接受服务器返回html
通配符*：代表任意类型，如Accept:text/html,*/*,q=0.8(q=0.8为权重比值，1最大，优先级高)
Accept-Encoding：浏览器支持的压缩类型，如Accept-Encoding:gzip,deflate
Accept-Language：浏览器声明自己接受的语言，如Accept-Language:en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4,zh-TW;q=0.2
1.3.1.2. User-Agent
浏览器告诉服务器，客户端使用的操作系统及版本、CPU类型、浏览器及版本、浏览器渲染引擎、浏览器语言、浏览器插件等
1.3.1.3. Referer
让服务器判断来源页面，即用户是从哪个页面来的，有时被用作防盗链，即下载时判断来源地址是不是在网站域名之内，否则就不能下载或显示。
1.3.1.4. Connection
:Keep-Alive 默认开户，保持连接特性，不会永久保持连接，有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间
1.3.1.5. Host
是Header必需的，指定被请求的主机和端口号，从URL中提取
1.3.1.6. Tansfer-Encoding
规定了传输报文主体时采用的编码方式（仅对分块传输编码有效）
1.3.1.7. Upgrade
用于检测HTTP协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来指定一个完全不同的通信协议。
例：
GET /index.htm HTTP/1.1
Upgrade:TLS/1.0
Connection:Upgrade
响应：服务器可响应101 Switching Protocols，提示切换协议成功
1.3.1.8. Via
为了追踪客户端与服务器之间的请求和响应报文的传输路径，还可避免请求回环的发生
报文经过代理或网关时，会先在首部字段Via中附加该服务器的信息，然后再进行转发
经常会和TRACE方法一起使用
1.3.1.9. Warning
从HTTP1.0的Retry-After演变而来，通常会告知用户一些与缓存相关的问题的警告
1.3.1.10. Authorization
用来告知服务器，用户代理的认证信息（证书值），通常，想要通过服务器认证的用户代理会在接收到返回的401状态码响应后，把Authorization加入请求中，共用缓存在接收到含有Authorization的请求时操作会略有差异
1.3.1.11. Expect
告知服务器，期望出现的某种特定行为
例：Expect:100-continue 告知服务器期望等待状态码100
1.3.1.12. From
告知服务器使用用户代理的用户的电子邮件地址
1.3.1.13. If-Match
条件请求，如果符合条件，才执行请求
通常带Etag的值
1.3.1.14. If-Range
告知服务器，若指定的If-Range字段值（Etag值或时间）和请求资源的Etag值或时间相一致时，则作为范围请求处理，反之，则返回全体资源
通常会带Range后面带范围
相当于If-Match+Range的组合
1.3.1.15. If-Unmodified-Since
与If-Modified-Since的作用相反，告知服务器，指定的请求资源只有在字段值内指定的日期之后，未发生更新的情况下，才能处理请求。
1.3.1.16. Max-Forwards
在后面赋值，每经过一台服务器数值减1，当收到值为0时则不再转发，而是直接返回响应
1.3.1.17. Proxy-Authorization
接收到从代理服务器发来的认证质询时，客户端会发送包含首部字段Proxy-Authorization的请求，以告知服务器认证所需要的信息。
1.3.1.18. Range
用于只需获取部分资源的范围请求，告知服务器资源的指定范围
例：
Range:bytes=5001-10000 请求获取从第5001字节到第10000字节的资源
接收到带Range字段请求的服务器，会在处理请求之后返回状态码206 Partial Content的响应，无法处理该范围请求时，则会返回状态码200 OK的响应及全部资源
1.3.1.19. TE
Transfer Encoding告知服务器客户端能够处理响应的传输编码方式及相对优先级，和首部字段Accept-Encoding功能相像，但是用于传输编码
例：
TE：gzip,deflate;q=0.5
TE除指定传输编码外，还可以指定伴随trailer字段的分块传输编码的方式
例：
TE：trailers
以下为响应首部字段
1.3.1.20. Accept-Ranges
告知客户端是否能处理范围请求，以指定获取服务器端某个部分的资源，可指定的值有两种：bytes和none
例：
Accept-Ranges:bytes (当不能处理范围请求时，值为none)
1.3.1.21. Age
告知客户端，源服务器在多久前创建了响应，字段值单位为秒，若创建该响应的服务器是缓存服务器，则指缓存后的响应再次发起认证到认证完成的时间值，代理创建响应时必须加上首部字段Age
例：
Age:600 这个缓存向源服务器确认过，现在已经过去了10分钟
1.3.1.22. Location
后面带地址URI，可以将响应接收方引导到某个与请求URI位置不同的资源，一般会配上3XX重定向的响应状态码，提供重定向的URI，几乎的有浏览器在接收到包含首部字段Location的响应后，都会强制性地尝试对已提示的重定向资源的访问
1.3.1.23. Proxy-Authenticate
会把代理服务器所要求的认证信息发送给客户端，与客户端和服务器之间的HTTP访问认证的行为相似，不同之处在于其认证行为是在客户端与代理之间进行的，而客户端与服务器之间进行认证时，首部字段WWW-Authorization有相同的作用
1.3.1.24. Retry-After
告知客户端应该在多久之后再次发送请求，主要配合状态码503 Server Unavaliable响应或者3XX Redierct响应一起使用
例：
Retry-After:120（单位为秒，也可以带具体时间）
1.3.1.25. Server
告知客户端当前服务器上安装的HTTP服务器应用程序的信息，可能包含服务器上的软件应用名称、版本号和安装时启用的可选项
例：
Server:Apache/2.2.17 (Unix) PHP/5.2.5
1.3.1.26. Vary
可对缓存进行控制，当代理服务器接收到带有Vary字段指定获取资源的请求时，如果使用的Accept-Language字段的值相同，那么就直接从缓存返回响应，反之，则需要先从源服务器端获取资源后才能作为响应返回（即使对相同资源发起请求，如果Vary指定的首部字段不同，也必须从源服务器重新获取资源）
例：
Vary:Accept-Language 表示代理服务器只能对持相同自然语言（Accept-Language）的请求返回缓存
1.3.1.27. WWW-Authenticate
用于HTTP访问认证，会告知客户端适用于访问请求URI所指定资源的认证方案（Basic或Digest）和带参数提示的质询，一般和状态码401 Unauthorized响应一起使用
例：
WWW-Authenticate:Basic realm=”Usagidesign Auth” (realm字段的字符串是为了辨别请求URI指定资源所受到的保护策略)
1.3.1.28. Allow
通知客户端能够支持Request-URI指定资源的所有HTTP方法，当服务器接收到不支持的HTTP方法时，会以状态码405 Method Not Allowed作为响应返回，同时把所有能支持的HTTP方法写入首部字段Allow后返回
例：
Allow:GET,HEAD
1.3.1.29. Content
Content-Encoding:gzip 告知客户端服务器对实体的主体部分选用的编码方式（内容编码是指在不丢失实体信息的前提下所进行的压缩）
Content-Language:zh-CN 告知客户端，实体主体使用的自然语言（指中文或英文等语言）
Content-Length:15000 实体主体的大小（单位是字节）
Content-Location:具体URI 给出与报文主体部分相对应的URI，和Location不同， 该字段表明的是报文主体返回资源对应的URI
Content-MD5：经过MD5计算后的值 客户端会对接收的报文主体执行相同的MD5算法，然后与首部字段Content-MD5的字段值比较，用于检查报文主体在传输过程中是否保持完整以及确认传输到达
Content-Range:5000-10000/10000 表示当前发送部分及整个实体大小,针对范围请求，返回响应时使用，能告知客户端作为响应返回的实体的哪个部分符合范围请求，单位为字节
Content-Type:text/html;charset=UTF-8 说明实体主体内对象的媒体类型，和首部字段Accept一样
1.3.1.30. X-Frame-Options
用于控制网站内容在其他web网站的Frame标签内的显示问题，主要目的是为了防止点击劫持（clickjacking）攻击
例：
X-Frame-Options:DENY 拒绝，还有一个值SAMEORIGIN，仅同源域名下的页面匹配时许可，比如，当指定http://hackr.jp/sample.html页面为SAMEORIGIN时，那么 hackr.jp上所有页面的frame都被允许可加载该页面，而example.com等其他域名的页面就不行了
目前主流的浏览器都已经支持，能在所有的web服务器端预先设定好X-Frame-Options字段值是最理想的状态
1.3.1.31. X-XSS-Protection
针对跨站脚本攻击（XSS）的一种对策，用于控制浏览器XSS防护机制的开关
可指定的值为0（将XSS过滤设置为无效状态）和1（将XSS过滤设置为有效状态）
1.3.1.32. DNT
Do Not Track，意为拒绝个人信息被收集，是拒绝被精准广告追踪的一种方法，由于该属性具备有效性，所以web服务器需要对DNT做对应的支持
值为0（同意被追踪）和1（拒绝被追踪）
例：
DNT：1
1.3.1.33. P3P
通过利用P3P（The Platform for Privacy Preferences,在线隐私偏好平台）技术，可以让web网站上的个人隐私变成一种仅供程序可理解的形式，以达到保护用户隐私的目的
进行设置需按以下步骤进行：
创建P3P隐私——创建P3P隐私对照文件后，保存命名在/w3c/p3p.xml——从P3P隐私中新建Compact policies后，输出到HTTP响应中
1.3.2. 与缓存有关的属性
1.3.2.1. Cache-Control
:no-cache不使用缓存，提醒浏览器要从服务器提取文档进行验证
Pragma:no-cache，也是不使用缓存，不过是HTTP1.0的标准，Cache-Control:no-cache是HTTP1.1的标准
:public响应被缓存，并且在多用户间共享
:private只能作为私有缓存，不能在用户之间共享
:no-store绝对禁止缓存（用于机密、敏感文件）
:max-age=60 60s之后缓存过期（相对时间）
1.3.2.2. If-Modified-Since
后面带时间，表示缓存文件的最后修改时间。
用于跟服务器更新时间做对比，如果在此时间之后文件没有更新，则会返回304状态码，告知客户端，可直接使用缓存。
1.3.2.3. If-None-Match
如果不匹配，后面带缓存文件的Etag值，与If-Match作用相反
1.3.2.4. Date
值为时间，表示当前响应发送的时间
1.3.2.5. Last-Modified
值为时间，表示服务器端文件的最后修改时间
1.3.2.6. Etag
服务器端文件的Etag值
Etag：实体标签，是根据实体内容生成的一段hash字符串（类似于MD5或者SHA1之后的结果），可以标识资源的状态，当资源发生改变时，Etag也随之变化。由web服务端产生，然后发给客户端。
Etag主要为了解决一些Last-Modified无法解决的问题
1) 某些服务器不能精确得到文件的最后修改时间，这样就无法通过最后修改时间来判断文件是否更新了；
2) 某些文件的修改非常频繁，在以秒为单位以下的时间内进行修改，而Last-Modified只能精确到秒；
3) 一些文件的最后修改时间改变了，但是内容并未改变，不希望客户端认为这个文件修改了。
Etag：分强Etag(不论实体发生多么细微的变化都会改变其值)和弱Etag(只用于提示资源是否相同，只有资源发生了根本改变，产生差异时才会改变Etag值，会在字段值最开始处附加W/)
例：
Etag:W/”usage-1234”
1.3.3. Cookie属性
1.3.3.1. Set-Cookie
客户端第1次请求时，服务器生成，并在响应中发送给客户端
1.3.3.2. Cookie
客户端第2次及以后的请求时，放在请求中
1.3.3.3. Expires过期属性
一个时间，代表过期时间（绝对时间），过了这个时间，该cookie就失效了，如果不指定，则表示关闭浏览器/页面的时候，此cookie就被浏览器删除了。
1.3.3.4. Path路径属性
表示Cookie所属的路径，asp.net默认为“/”，就是根目录。
1.3.3.5. HttpOnly安全属性
将cookie设置为HttpOnly后，通过JavaScript脚本将无法读取到Cookie信息，能有效的防止XSS攻击。一般，跟登录有关的Cookie必须设置为HttpOnly。
例：
Set-Cookie:name=value; HttpOnly
设置该属性后，使用JavaScript的document.cookie就无法读取附加HttpOnly属性后的cookie的内容了，因此无法在XSS中利用JavaScript劫持cookie了。
1.3.3.6. Domain属性
通过该属性指定的域名可做到与结尾匹配一致，比如当指定example.com后，除example.com以外，www.example.com或www2.example.com等都可以发送Cookie，因此，除了针对具体指定的多个域名发送Cookie之外，不指定domain属性更安全
1.3.3.7. Secure属性
用于限制web页面仅在HTTPS安全连接时，才可以发送Cookie
例：
Set-Cookie:name=value; secure
1.4. SESSION和COOKIE
由于http的无状态，才设计出了session和cookie机制
1.4.1. Session
HTTP的无状态，通过SESSIONID来区分用户，存储在服务器端
客户端的Session信息是存储在Cookie中的，如果客户端完全禁用掉了Cookie功能，他也就不能享受到了Session提供的功能了
Session可以用Cookie来实现，也可以用URL回写的机制来实现。
用Cookie来实现的Session可以认为是对Cookie更高级的应用。
在计算机中，尤其是在网络应用中，称为“会话控制”。Session对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的Web页之间跳转时，存储在Session对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当用户请求来自应用程序的 Web页时，如果该用户还没有会话，则Web服务器将自动创建一个 Session对象。当会话过期或被放弃后，服务器将终止该会话。Session 对象最常见的一个用法就是存储用户的首选项。例如，如果用户指明不喜欢查看图形，就可以将该信息存储在Session对象中。有关使用Session 对象的详细信息，请参阅“ASP应用程序”部分的“管理会话”。注意会话状态仅在支持cookie的浏览器中保留。
session的工作原理：
（1）当一个session第一次被启用时，一个独一的标识被存储于本地的cookie中。
（2）首先使用session_start()函数，PHP从session仓库中加载已经存储的session变量。
（3）当执行PHP脚本时，通过使用session_register()函数注册session变量。
（4）当PHP脚本执行结束时，未被销毁的session变量会被自动保存在本地一定路径下的session库中，这个路径可以通过php.ini文件中的session.save_path指定，下次浏览网页时可以加载使用。
持久性方法的限制：
随着越来越多用户登录，Session所需要的服务器内存量也会不断增加。
访问Web应用程序的每个用户都生成一个单独的Session对象。每个Session对象的持续时间是用户访问的时间加上不活动的时间。
如果每个Session中保持许多对象，并且许多用户同时使用Web应用程序（创建许多Session），则用于 Session持久性的服务器内存量可能会很大，从而影响了可伸缩性。
1.4.2. Cookie
HTTP的无状态，通过COOKIE（会包含SESSIONID等信息）来记录用户（认证）状态，发送请求时，由服务器生成并在响应中发送给客户端（set-cookie=），由客户端存储在本地，在下次请求时，带到请求的header中（cookie=），服务器便可以通过cookie来区分用户和对应的用户状态
分会话Cookie(临时cookie，记录了用户访问站点时的设置和偏好，关闭浏览器，会话cookie就被删除了)和持久Cookie(存储在硬盘上，不管浏览器退出或者计算机重启，都会继续存在，持久cookie有过期时间)
保存在硬盘上，IE和Firefox存Cookie的地方不一样，不同的操作系统也可能不一样。
Windows7、IE8，存放路径为
C:\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files
注：缓存文件和cookie文件是存在一起的，也可以通过打开IE-Tools-Internet Options-Genernal Tab-Browsing history-Setting-View files
1.4.3. Session和cookie的区别
1）Cookie将状态保存在客户端，Session将状态保存在服务器端；
2）Cookies是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器。Cookie最早在RFC2109中实现，后续RFC2965做了增强。网络服务器用HTTP头向客户端发送cookies，在客户终端，浏览器解析这些cookies并将它们保存为一个本地文件，它会自动将同一服务器的任何请求缚上这些cookies。Session并没有在HTTP的协议中定义；
3）Session是针对每一个用户的，变量的值保存在服务器上，用一个sessionID来区分是哪个用户session变量,这个值是通过用户的浏览器在访问的时候返回给服务器，当客户禁用cookie时，这个值也可能设置为由get来返回给服务器；
4）就安全性来说：Session比cookie安全,当你访问一个使用session 的站点，同时在自己机子上建立一个cookie，建议在服务器端的SESSION机制更安全些.因为它不会任意读取客户存储的信息。
session是存储在服务器端的会话，相对安全，并且不像Cookie那样有存储长度限制。
由于Session是以文本文件形式存储在服务器端的，所以不怕客户端修改Session内容。实际上在服务器端的Session文件，PHP自动修改session文件的权限，只保留了系统读和写权限，而且不能通过ftp修改，所以安全得多。
对于Cookie来说，假设要验证用户是否登陆，就必须在Cookie中保存用户名和密码(可能是md5加密后字符串)，并在每次请求页面的时候进行验证。如果用户名和密码存储在数据库，每次都要执行一次数据库查询，给数据库造成多余的负担。因为并不能只做一次验证。为什么呢? 因为客户端Cookie中的信息是有可能被修改的。假如你存储$admin变量来表示用户是否登陆，$admin为true的时候表示登陆，为false的时候表示未登录，在第一次通过验证后将$admin等于true存储在Cookie，下次就不用验证了是错的，假如有人伪造一个值为true的$admin变量， 非常的不安全。
而Session就不同了，Session是存储在服务器端的，远程用户没办法修改session文件的内容，因此可以单纯存储一个$admin变量来判断是否登陆，首次验证通过后设置$admin值为true，以后判断该值是否为true，假如不是，转入登陆界面，这样就可以减少很多数据库操作了。而且可以减少每次为了验证Cookie而传递密码的不安全性了(session验证只需要传递一次，假如你没有使用SSL安全协议的话)。即使密码进行了md5加密，也是很容易被截获的。
当然使用session还有很多优点，比如控制容易，可以按照用户自定义存储等(存储于数据库)。
session在php.ini一般不需要设置，因为并不是每个人都有修改PHP.ini的权限，默认session 的存放路径是服务器的系统临时文件夹，可以自定义存放在自己的文件夹里。
2. HTTPS
由于http的不安全性，令数据存在窃听、篡改、伪装等攻击的可能，于是产生了HTTPS
HTTPS=HTTP+SSL(或TLS)(SSL运行在会话层)，默认端口号：443
HTTPS=HTTP+加密+认证+完整性保护
2.1. 通信加密
通信加密：HTTP通过和SSL(Secure Socket Layer,安全套接层)或TLS(Transport Layer Security,安全传输层协议)的组合使用，加密HTTP的通信内容
2.2. 内容加密
对HTTP报文进行加密处理后再发送请求，但不同于SSL或TLS将整个通信线路加密，所以仍有被篡改的可能
2.3. MD5、SHA-1、数字签名
常用的MD5(由单向函数生成的散列值)、SHA-1等散列值校验的方法以及用来确认文件的数字签名（PGP）方法
2.4. 加密、签名、证书
加密：公钥加密，私钥解密（保证数据无法被他人获得，但不保证不被篡改）
签名：私钥加密，公钥解密（防止传输内容被篡改，但不保证不被他人获得）
2.4.1. 对称性加密/共享密钥加密
密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；
在互联网上转发密钥时，如果通信被监听那么密钥就会落入攻击者之手，同时就失去了加密的意义，另外还得设法安全地保管接收到的密钥。
2.4.2. 非对称性加密/公开密钥加密
一对非对称的密钥，私有密钥（不能让别人知道）和公开密钥（可以随意发布，任何人都可以获得）
密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。
发送者：用对方的公钥加密，接收者：用自己的私钥解密
2.4.3. HTTPS采用混合加密机制
原因：共享密钥不安全，公开密钥处理速度慢
处理：交换密钥时用公开密钥加密方式，之后的建立通信交换报文使用共享密钥加密方式。
https通信的优点：
1）客户端产生的密钥只有客户端和服务器端能得到；
2）加密的数据只有客户端和服务器端才能得到明文；
3）客户端到服务端的通信是安全的。
2.4.4. 签名、证书
由值得信任的第三方机构（CA,Certificate Authority,数字证书认证机构）颁发，用以证明服务器和客户端是实际存在的
加密模式：
认证模式：
高级模式：
浙公网安备 33010602011771号