目录
HTTP（HyperText Transfer Protocol）超文本传输协议
HTTP（HyperText Transfer Protocol）超文本传输协议
版本分为 1.0/1.1 （ 最早的标准是 HTTP/0.9 只不过没正式建立,目前HTTP/2.0 制定出来了，但是并不常用）
Web网络基础
网络7层协议（应表会传网数物）
应用层 文件传输，电子邮件，文件服务，虚拟终端 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
TCP/IP（互联网相关的各类协议族的总称 ）
TCP/IP 协议族按层次分别分 为以下 4 层：应用层、传输层、网络层和数据链路层。(以下图片为 网络通信流程)
与 HTTP 关系密切的协议 : IP、TCP 和 DNS
IP（Internet Protocol）网际协议位于网络层
IP 协议的作用是把各种数据包传送给对方。而要保证确实传送到对方 那里，则需要满足各类条件。其中两个重要的条件是 IP 地址和 MAC 地址（Media Access Control Address）。IP 地址指明了节点被分配到的地址，MAC 地址是指网卡所属的固定 地址。IP 地址可以和 MAC 地址进行配对。IP 地址可变换，但 MAC 地址基本上不会更改 。ARP 协议（Address Resolution Protocol） 是一种用以解析地址的协议，根据通信方 的 IP 地址就可以反查出对应的 MAC 地址。
TCP 位于传输层，提供可靠的字节流服务
所谓的字节流服务（Byte Stream Service）是指，为了方便传输，将大 块数据分割成以报文段（segment）为单位的数据包进行管理。而可 靠的传输服务是指，能够把数据准确可靠地传给对方。一言以蔽之， TCP 协议为了更容易传送大数据才把数据分割，而且 TCP 协议能够 确认数据最终是否送达到对方。
TCP 的三次握手，四次挥手[主动关闭（客户端）,被动关闭(服务端)]
若在握手过程中某个阶段莫名中断，TCP 协议会再次以相同的顺序发 送相同的数据包。
SYN: 表示建立连接
ACK: 表示响应
FIN: 表示关闭连接
DNS（Domain Name System）是位于应用层，提供域名到 IP 地址之间的解析服务。
各种协议与 HTTP 协议的关系
与 HTTP 协作的 Web 服 务器
用单台虚拟主机实现多个域名
一台 Web 服务器可搭建多个独立域名的 Web 网站
在互联网上，域名通过 DNS 服务映射到 IP 地址（域名解析）之后访 问目标网站。
可见，当请求发送到服务器时，已经是以 IP 地址形式 访问了。
所以，如果一台服务器内托管了 www.tricorder.jp 和 www.hackr.jp 这 两个域名
当收到请求时就需要弄清楚究竟要访问哪个域名。
在相同的 IP 地址下，由于虚拟主机可以寄存多个不同主机名和域名 的 Web 网站
因此在发送 HTTP 请求时，必须在 Host 首部内完整指 定主机名或域名的 URI。
通信数据转发程序 ：代理、网关、隧 道
HTTP 通信时，除客户端和服务器以外，还有一些用于通信数据转发 的应用程序，例如代理、网关和隧道。
它们可以配合服务器工作。这些应用程序和服务器可以将请求转发给通信线路上的下一站服务 器，
并且能接收从那台服务器发送的响应再转发给客户端。
代理：是一种有转发功能的应用程序，它扮演了位于服务器和客户 端“中间人”的角色，接收由客户端发送的请求并转发给服务器，同时 也接收服务器返回的响应并转发给客户端。也可以针对特定URI访问的控制。
代理有多种使用方法，按两种基准分类。一种是是否使用缓存，另一 种是是否会修改报文。
缓存代理
代理转发响应时，缓存代理（Caching Proxy）会预先将资源的副本 （缓存）保存在代理服务器上。
当代理再次接收到对相同资源的请求时，就可以不从源服务器那里获 取资源，而是将之前缓存的资源作为响应返回。
透明代理
转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理 （Transparent Proxy）。反之，对报文内容进行加工的代理被称为非 透明代理。
网关：是转发其他服务器通信数据的服务器，接收从客户端发送来的请 求时，它就像自己拥有资源的源服务器一样对请求进行处理。有时客 户端可能都不会察觉，自己的通信目标是一个网关。
网关的工作机制和代理十分相似。而网关能使通信线路上的服务器提 供非 HTTP 协议服务，利用网关能提高通信的安全性，因为可以在客户端与网关之间的通信 线路上加密以确保连接的安全。比如，网关可以连接数据库，使用 SQL 语句查询数据。另外，在 Web 购物网站上进行信用卡结算时， 网关可以和信用卡结算系统联动。
隧道：是在相隔甚远的客户端和服务器两者之间进行中转，并保持双方 通信连接的应用程序。
通过隧道的传输，可以和远距离的服务器安全通信。隧道本 身是透明的，客户端不用在意隧道的存在 。例如：特殊情况下，通过SSH隧道连接数据库
保存资源的缓存
缓存是指代理服务器或客户端本地磁盘内保存的资源副本。利用缓存可减少对源服务器的访问，因此节省了通信流量和通信时间。缓存服务器属于代理缓存的一种
缓存的有效期限
即便缓存服务器内有缓存，也不能保证每次都会返回对同资源的请 求。因为这关系到被缓存资源的有效性问题。
当遇上源服务器上的资源更新时，如果还是使用不变的缓存，那就会 演变成返回更新前的“旧”资源了。
即使存在缓存，也会因为客户端的要求、缓存的有效期等因素，向源 服务器确认资源的有效性。
若判断缓存失效，缓存服务器将会再次从 源服务器上获取“新”资源
缓存不仅可以存在于缓存服务器内，还可以存在客户端浏览器中。浏览器缓存如果有效，就不必再向服务器请求相同的资源了，可以直 接从本地磁盘内读取。另外，和缓存服务器相同的一点是，当判定缓存过期后，会向源服务 器确认资源的有效性。若判断浏览器缓存失效，浏览器会再次请求新资源。
HTTP 协议
HTTP概念
HTTP 默认端口号为80
HTTP协议 用于客户端和服务器端之间 的通信，通过请求和响应的交换达成通信，是不保存状态，即无状态（stateless）协议
虽然是无状态协议，但为了实现期望的保持状态功能，于是引入了 Cookie 技术。有了 Cookie 再用 HTTP 协议通信，就可以管 理状态了
HTTP 请求的方法
| 方法 | 说明 | 支持的 HTTP 协议版本 |
| GET | 获取资源（常用） | 1.0、1.1 |
| POST | 传输实体主题（常用） | 1.0、1.1 |
| PUT | 传输文件（报文主体中包含文件内容，保存到对应URI位置。） | 1.0、1.1 |
| HEAD | 获得报文首部（不会返回实体的主体部分） | 1.0、1.1 |
| DELETE | 删除文件(与PUT方法相反，删除对应URI位置的文件) | 1.0、1.1 |
| OPTIONS | 询问支持的方法(查询相应URI支持的HTTP方法) | 1.1 |
| TRACE | 追踪路径 | 1.1 |
| CONNECT | 要求用隧道协议连接代理 | 1.1 |
| LINK | 建立和资源之间的联系（已弃用） | 1.0 |
| UNLINE | 断开连接关系（已弃用） | 1.0 |
GET方法与POST方法的区别
1、get重点在从服务器上获取资源，post重点在向服务器发送数据；
2、get传将数据放在url中传输，是可见的（不安全）post将数据封存在请求实体中传输，是不可见的（安全）；
3、Get传输的数据量小，因为受URL长度限制，但效率较高；Post可以传输大量数据，所以上传文件时只能用Post方式；
4、get方式只能支持ASCII字符，向服务器传的中文字符可能会乱码，post支持标准字符集，可以正确传递中文字符；
HTTP 持久连接
HTTP初始版本 是一次请求一次响应，每进行一次 HTTP 通信就要断开一次 TCP 连接，连接开销较大
为解决上述 TCP 连接的问题，HTTP/1.1 和一部分的 HTTP/1.0 想出了 持久连接（HTTP Persistent Connections，也称为 HTTP keep-alive 或 HTTP connection reuse）的方法。持久连接的特点是，只要任意一端 没有明确提出断开连接，则保持 TCP 连接状态
持久连接使得多数请求以管线化（pipelining）方式发送成为可能。
HTTP管线化（英语：HTTP pipelining）是将多个HTTP请求（request）整批提交的技术，而在发送过程中不需先等待伺服端的回应，效率比持久连接要快。- - 只有 GET 和 HEAD 等要求可以进行管线化
使用 Cookie 的状态管理（解决http无状态的问题）
Cookie 技术通过在请求和响应报文中写入 Cookie 信 息来控制客户端的状态。
Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的 首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器 发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出 去。
服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一 个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前 的状态信息。
HTTP 请求报文和响应报文的内容 如下：
HTTP报文
根据HTTP 请求/响应， 报文分为请求报文，响应报文。
HTTP 报文本身是由多行（用 CR+LF 作换行符）数据构成的字符串文本，HTTP 报文大致可分为报文首部和报文主体两块。
报文结构
请求报文和响应报文的首部内容由以下数据组成
请求行
包含用于请求的方法，请求 URI 和 HTTP 版本。
状态行
包含表明响应结果的状态码，原因短语和 HTTP 版本。
首部字段
包含表示请求和响应的各种条件和属性的各类首部，一般有 4 种首部，分别是：通用首部、请求首部、响应首部和实体首部
编码提升传输效率
HTTP 协议中有一种被称为内容编码的功能也能进行类似（压缩）的操作。
内容编码指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码
常用的内容编码有以下几种：
gzip（GNU zip）
compress（UNIX 系统的标准压缩）
deflate（zlib）
identity（不进行编码）
获取部分内容的范围请求（断点续传）
指定范围发送的请求（Range Request）。 对一份 10 000 字节大小的资源，如果使用范围请求，可以只请求 5001~10 000 字节内的资源。
执行范围请求时，会用到首部字段 Range 来指定资源的 byte 范围
byte 范围的指定形式如下：
5001~10 000 字节
Range: bytes=5001-10000
从 5001 字节之后全部的
Range: bytes=5001
从一开始到 3000 字节和 5000~7000 字节的多重范围
Range: bytes=-3000, 5000-7000
针对范围请求，响应会返回状态码为 206 Partial Content 的响应报文。
另外，对于多重范围的范围请求，响应会在首部字段 ContentType 标明 multipart/byteranges 后返回响应报文。
如果服务器端无法响应范围请求，则会返回状态码 200 OK 和完整的 实体内容。
内容协商返回最合适的内容
同一个网址会有中英文的web页面，它们内容上虽相同，但使用的语言却不同。 当浏览器的默认语言为英语或中文，访问相同 URI 的 Web 页面时， 则会显示对应的英语版或中文版的 Web 页面。这样的机制称为内容协商（Content Negotiation）。内容协商机制是指客户端和服务器端就响应的资源内容进行交涉，然 后提供给客户端最为适合的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准。
包含在请求报文中的某些首部字段（如下）就是判断的基准：
Accept //接受
Accept-Charset //接受字符集
Accept-Encoding //接受编码
Accept-Language //接受语言
Content-Language //实体语言
返回结果的 HTTP 状态码
200：请求被正常处理
204：请求被受理但没有资源可以返回
206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。
301：永久性重定向
302：临时重定向
303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上
304：发送附带条件的请求时，条件不满足时返回，与重定向无关
307：临时重定向，与302类似，只是强制要求使用POST方法
400：请求报文语法有误(请求的参数)，服务器无法识别
401：请求需要认证
403：请求的对应资源禁止被访问
404：服务器无法找到对应资源
500：服务器内部错误
502：网关超时
503：服务器正忙
HTTP 首部
具体结构在报文结构已经解释了
HTTP 首部字段 （实际用途）
首部字段是为了给浏览器和服务器提供报文主体大小、所使用的 语言、认证信息等内容，实际用途被分为以下 4 种类型：
通用首部字段（General Header Fields）
请求首部字段（Request Header Fields）
响应首部字段（Response Header Fields）
实体首部字段（Entity Header Fields）
通用首部字段
| 首部字段名 | 说明 |
|---|---|
| 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 客户端程序的信 |
响应首部字段
| 首部字段名 | 说明 |
|---|---|
| Accept-Ranges | 是否接受字节范围请求 |
| Age | 推算资源创建经过时间 |
| ETag | 资源的匹配信息 |
| Location | 令客户端重定向至指定URI |
| Proxy-Authenticate | 代理服务器对客户端的认证信息 |
| Retry-After | 对再次发起请求的时机要求 |
| Server | HTTP服务器的安装信息 |
| Vary | 代理服务器缓存的管理信息 |
| WWW-Authenticate | 服务器对客户端的认证信息 |
实体首部字段
| 首部字段名 | 说明 |
|---|---|
| Allow | 资源可支持的HTTP方法 |
| Content-Encoding | 实体主体适用的编码方式 |
| Content-Language | 实体主体的自然语言 |
| Content-Length | 实体主体的大小（单位：字节） |
| Content-Location | 替代对应资源的URI |
| Content-MD5 | 实体主体的报文摘要 |
| Content-Range | 实体主体的位置范围 |
| Content-Type | 实体主体的媒体类型 |
| Expires | 实体主体过期的日期时间 |
| Last-Modified | 资源的最后修改日期时间 |
非 HTTP/1.1 首部字段
在 HTTP 协议通信交互中使用到的首部字段，不限于 RFC2616 中定 义的 47 种首部字段。
还有 Cookie、Set-Cookie 和 Content-Disposition 等在其他 RFC 中定义的首部字段，
它们的使用频率也很高。 这些非正式的首部字段统一归纳在 RFC4229 HTTP Header Field
HTTP 首部字段（缓存）
将定义成缓存代理和非缓存代理的行为，分成 2 种类型
端到端首部（End-to-end Header）
分在此类别中的首部会转发给请求 / 响应对应的最终接收目标，且必 须保存在由缓存生成的响应中，另外规定它必须被转发。
逐跳首部（Hop-by-hop Header）
分在此类别中的首部只对单次转发有效，会因通过缓存或代理而不再 转发。HTTP/1.1 和之后版本中，如果要使用 hop-by-hop 首部，需提 供 Connection 首部字段。
下面列举了 HTTP/1.1 中的逐跳首部字段。除这 8 个首部字段之外， 其他所有字段都属于端到端首部。
Connection
Keep-Alive
Proxy-Authenticate
Proxy-Authorization
Trailer
TE
Transfer-Encoding
Upgrade
首部字段的使用（常用）
通用首部
1、Cache-Control
指令的参数是可选的，多个指令之间通过“,”分隔。首部字段 CacheControl 的指令可用于请求及响应时。
例如：Cache-Control: private, max-age=0, no-cache
缓存请求指令
| 指令 | 参数 | 说明 |
|---|---|---|
| no-cache | 无 | 强制向源服务器再次验证 |
| no-store | 无 | 不缓存请求或响应的任何内容 |
| max-age = [ 秒 ] | 必需 | 响应的最大Age值 |
| max-stale( = [ 秒 ]) | 可省略 | 接收已过期的响应 |
| min-fresh = [ 秒 ] | 必需 | 期望在指定时间内的响应仍有效 |
| no-transform | 无 | 代理不可更改媒体类型 |
| only-if-cached | 无 | 从缓存获取资源 |
| cache-extension | - | 新指令标记（token） |
缓存响应指令
| 指令 | 参数 | 说明 |
|---|---|---|
| public | 无 | 可向任意方提供响应的缓存 |
| private | 可省略 | 仅向特定用户返回响应 |
| no-cache | 可省略 | 缓存前必须先确认其有效性 |
| no-store | 无 | 不缓存请求或响应的任何内容 |
| no-transform | 无 | 代理不可更改媒体类型 |
| must-revalidate | 无 | 可缓存但必须再向源服务器进行确认 |
| proxy-revalidate | 无 | 要求中间缓存服务器对缓存的响应有效性再进行确认 |
| max-age = [ 秒 ] | 必需 | 响应的最大Age值 |
| s-maxage = [ 秒 ] | 必需 | 公共缓存服务器响应的最大Age值 |
| cache-extension | - | 新指令标记（token） |
Cache-Control: no-cache
从字面意思上很容易把 no-cache 误解成为不缓存，但事实上 no-cache 代表不缓 存过期的资源，缓存会向源服务器进行有效期确认后处理资源 Cache-Control: no-store 真正地不进行缓存
使用 no-cache 指令的目的是为了防止从缓存中返回过期的资源。 客户端发送的请求中如果包含 no-cache 指令，则表示客户端将不会接 收缓存过的响应。于是，“中间”的缓存服务器必须把客户端请求转发 给源服务器。
如果服务器返回的响应中包含 no-cache 指令，那么缓存服务器不能对 资源进行缓存。源服务器以后也将不再对缓存服务器请求中提出的资源有效性进行确认，且禁止其对响应资源进行缓存操作。
Cache-Control: no-cache=Location
由服务器返回的响应中，若报文首部字段 Cache-Control 中对 no-cache 字段名具体指定参数值，那么客户端在接收到这个被指定参数值的首部字段对应的响应报文后，就不能使用缓存。换言之，无参数值的首部字段可以使用缓存。只能在响应指令中指定该参数。
Cache-Control 扩展 cache-extension token
Cache-Control: private, community="UCI"
通过 cache-extension 标记（token），可以扩展 Cache-Control 首部字 段内的指令。
如上例，Cache-Control 首部字段本身没有 community 这个指令。借助 extension tokens 实现了该指令的添加。如果缓存服务器不能理解 community 这个新指令，就会直接忽略。因此，extension tokens 仅对 能理解它的缓存服务器来说是有意义的。
2、Connection
Connection 首部字段具备如下两个作用：1、管理持久连接 2、控制不再转发给代理的首部字段
HTTP/1.1 之前的 HTTP 版本的默认连接都是非持久连接。
如果想在旧版本的 HTTP 协议上维持持续连接，则需要指定 Connection 首部字段的值为 Keep-Alive。
在客户端发送请求和服务器返回响应内，使用 Connection 首部字 段，可控制不再转发给代理的首部字段
请求首部字段
3、Accept
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.
Accept 首部字段可通知服务器，用户代理能够处理的媒体类型及媒体 类型的相对优先级。
可使用 type/subtype 这种形式，一次指定多种媒 体类型。
4、Range
Range: bytes=5001-10000
对于只需获取部分资源的范围请求，包含首部字段 Range 即可告知服 务器资源的指定范围。
上面的示例表示请求获取从第 5001 字节至第 10000 字节的资源
响应首部字段
5、Accept-Ranges
Accept-Ranges: bytes
首部字段 Accept-Ranges 是用来告知客户端服务器是否能处理范围请 求，以指定获取服务器端某个部分的资源。
可指定的字段值有两种，可处理范围请求时指定其为 bytes，反之则 指定其为 none。
6、Location
Location: http://www.usagidesign.jp/sample.html
使用首部字段 Location 可以将响应接收方引导至某个与请求 URI 位置 不同的资源。
基本上，该字段会配合 3xx ：Redirection 的响应，提供重定向的 URI。
实体首部字段
Allow: GET, HEAD //支持的方法
Content-Encoding: gzip //内容编码方式
Content-Language: zh-CN //支持的语言
Content-Length: 15000 //实体的长度
Content-Location: http://www.hackr.jp/index-ja.html //表示的是报文主体返回资源对 应的 URI
Content-Range: bytes 5001-10000/10000 //响应符合范围的请求。
Content-Type: text/html; charset=UTF-8 //返回的类型
Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY== //MD5 算法生成的值
Expires: Wed, 04 Jul 2012 08:26:05 GMT //资源失效的日期
Last-Modified: Wed, 23 May 2012 09:59:55 GMT //最终修改的时间
安全的 HTTPS(超文本传输安全协议)
HTTPS 是身披 SSL 外壳的 HTTP
HTTPS 默认端口号为443
HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代 替而已。通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通 信，再由 SSL 和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP。
加密的内容 为报文的主体
HTTPS 采用混合加密机制 (对称加密和RSA非对称加密)
RSA 算法非常高意思， 不像之前的算法，双万必须协商一个保密的秘钥。
而是有一对钥匙， 一个是保密的，称为私钥；另一个是公开的，称为公铜。
更有意思的是， 用私钥加密的数据，只有对应的公钥才能解密；用公钥加密的数据， 只有对应的私钥才能解密
HTTPS 流程
HTTP/1.1 使用的认证方式
BASIC 认证（基本认证）
DIGEST 认证（摘要认证）
SSL 客户端认证
FormBase 认证（基于表单认证）
Session 管理及 Cookie 应用 （两者的区别）
基于表单认证的标准规范尚未有定论，一般会使用 Cookie 来管理 Session（会话）。
基于表单认证本身是通过服务器端的 Web 应用，将客户端发送过来 的用户 ID 和密码与之前登录过的信息做匹配来进行认证的。 但鉴于 HTTP 是无状态协议，之前已认证成功的用户状态无法通过协 议层面保存下来。即，无法实现状态管理，因此即使当该用户下一次 继续访问，也无法区分他与其他的用户。于是我们会使用 Cookie 来 管理 Session，以弥补 HTTP 协议中不存在的状态管理功能。
Cookie 与 Session 的区别
cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。
cookie数据存放在客户的浏览器上（数据不能超过4K，只能是字符串，不安全），session数据放在服务器上（数据量为cookie的20倍，多种数据格式，安全）。
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用cookie。建议 敏感信息存放在session中，一般的数据放在cookie
资料来源：图解HTTP、百度百科
1837
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
