HTTP相关知识

---

HTTP知识点总结

HTTP的报文是什么样子的

HTTP 协议的请求报文和响应报文的结构基本相同
由三大部分组成： 1.起始行（start line）：描述请求或响应的基本信息；
2.头部字段集合（header）：使用 key-value 形式更详细地说明报文；
3.消息正文（entity）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据。

HTTP报文如图

起始行

（1）请求方法：是一个动词，如 GET/POST，表示对资源的操作；
（2）请求目标：通常是一个 URI，标记了请求方法要操作的资源；
（3）版本号：表示报文使用的 HTTP 协议版本。

状态行

（1）版本号：表示报文使用的 HTTP 协议版本；
（2）状态码：一个三位数，用代码的形式表示处理的结果，比如 200 是成功，500 是服务器错误；
（3）原因：作为数字状态码补充，是更详细的解释文字，帮助人理解原因。

头部字段请求报文和响应报文差不多

常用头字段

四大头字段

（1）通用字段：在请求头和响应头里都可以出现；
（2）请求字段：仅能出现在请求头里，进一步说明请求信息或者额外的附加条件；
（3）响应字段：仅能出现在响应头里，补充说明响应报文的信息；
（4）实体字段：它实际上属于通用字段，但专门描述 body 的额外信息。

使用头字段的注意点：

1.字段名不区分大小写，例如“Host”也可以写成“host”，但首字母大写的可读性更好；
2.字段名里不允许出现空格，可以使用连字符“-”，但不能使用下划线“_”。例如，“test-name”是合法的字段名，而“test name”“test_name”是不正确的字段名；
3.字段名后面必须紧接着“:”，不能有空格，而“:”后的字段值前可以有多个空格；
4.字段的顺序是没有意义的，可以任意排列不影响语义；
5.字段原则上不能重复，除非这个字段本身的语义允许，例如 Set-Cookie。

HTTP报文结构总结

1.HTTP 报文结构就像是“大头儿子”，由“起始行 + 头部 + 空行 + 实体”组成，简单地说就是“header+body”；
2.HTTP 报文可以没有 body，但必须要有 header，而且 header 后也必须要有空行，形象地说就是“大头”必须要带着“脖子”；
3.请求头由“请求行 + 头部字段”构成，响应头由“状态行 + 头部字段”构成；请求行有三部分：请求方法，请求目标和版本号；
4.状态行也有三部分：版本号，状态码和原因字符串；头部字段是 key-value 的形式，用“:”分隔，不区分大小写，顺序任意，除了规定的标准头，也可以任意添加自定义字段，实现功能扩展；
5.HTTP/1.1 里唯一要求必须提供的头字段是 Host，它必须出现在请求头里，标记虚拟主机名。

应该如何理解请求方法

请求头里的请求方法

请求方法：客户端发出了一个“动作指令”，要求服务器端对 URI 定位的资源执行这个动作。

八种常见方法，单词都必须是大写的形式

1.GET:获取资源，可以理解为读取或者下载数据
2.HEAD:获取资源的元信息；

HEAD 方法与 GET 方法类似，也是请求从服务器获取资源，服务器的处理机制也是一样的，但服务器不会返回请求的实体数据，只会传回响应头，也就是资源的“元信息”。

3.POST：向资源提交数据，相当于写入或上传数据；
4.PUT：类似 POST；
5.DELETE：删除资源；
6.CONNECT：建立特殊的连接隧道；
7.OPTIONS：列出可对资源实行的方法；
8.TRACE：追踪请求 - 响应的传输路径。

安全与幂等

1.安全：请求方法不会“破坏”服务器上的资源，即不会对服务器上的资源造成实质的修改。
2.“幂等”实际上是一个数学用语，被借用到了 HTTP 协议里，意思是多次执行相同的操作，结果也都是相同的，即多次“幂”后结果“相等”。
GET和HEAD是安全的，因为只读取取不修改，GET和HEAD也是幂等的，因为多次执行GET和HEAD操作后，结果是相同的
POST/PUT/DELETE都是不安全的
POST 和 PUT 的幂等性质：
POST 是“新增或提交数据”，多次提交数据会创建多个资源，所以不是幂等的；而 PUT 是“替换或更新数据”，多次更新一个资源，资源还是会第一次更新的状态，所以是幂等的。

请求方法小结：

请求方法是客户端发出的、要求服务器执行的、对资源的一种操作；
请求方法是对服务器的“指示”，真正应如何处理由服务器来决定；
最常用的请求方法是 GET 和 POST，分别是获取数据和发送数据；
HEAD 方法是轻量级的 GET，用来获取资源的元信息；
PUT 基本上是 POST 的同义词，多用于更新数据；
“安全”与“幂等”是描述请求方法的两个重要属性，具有理论指导意义，可以帮助我们设计系统。

URI相关知识

1.URI 是用来唯一标记服务器上资源的一个字符串，通常也称为 URL；
2.URI 通常由 scheme、host:port、path 和 query 四个部分组成，有的可以省略；
3.scheme 叫“方案名”或者“协议名”，表示资源应该使用哪种协议来访问；
4.“host:port”表示资源所在的主机名和端口号；path 标记资源所在的位置；
5.query 表示对资源附加的额外要求；
6.在 URI 里对“@&/”等特殊字符和汉字必须要做编码，否则服务器收到 HTTP 报文后会无法正确处理。

状态码相关知识

1.状态码在响应报文里表示了服务器对请求的处理结果；
2.状态码后的原因短语是简单的文字描述，可以自定义；
3.状态码是十进制的三位数，分为五类，从 100 到 599；
4.2××类状态码表示成功，常用的有 200、204、206；
5.3××类状态码表示重定向，常用的有 301、302、304；
6.4××类状态码表示客户端错误，常用的有 400、403、404；
7.5××类状态码表示服务器错误，常用的有 500、501、502、503。

HTTP有哪些特点

1.HTTP 是灵活可扩展的，可以任意添加头字段实现任意功能；
2.HTTP 是可靠传输协议，基于 TCP/IP 协议“尽量”保证数据的送达；
3.HTTP 是应用层协议，比 FTP、SSH 等更通用功能更多，能够传输任意数据；
4.HTTP 使用了请求 - 应答模式，客户端主动发起请求，服务器被动回复请求；
5.HTTP 本质上是无状态的，每个请求都是互相独立、毫无关联的，协议不要求客户端或服务器记录请求相关的信息。

HTTP的优点与缺点

1.HTTP 最大的优点是简单、灵活和易于扩展；
2.HTTP 拥有成熟的软硬件环境，应用的非常广泛，是互联网的基础设施；

它并不限定某种编程语言或者操作系统，所以天然具有“跨语言、跨平台”的优越性。

3.HTTP 是无状态的，可以轻松实现集群化，扩展性能，但有时也需要用 Cookie 技术来实现“有状态”；

因为服务器没有“记忆能力”，所以就不需要额外的资源来记录状态信息，
不仅实现上会简单一些，而且还能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。
而且，“无状态”也表示服务器都是相同的，没有“状态”的差异，所以可以很容易地组成集群，让负载均衡把请求转发到任意一台服务器，
不会因为状态不一致导致处理出错，使用“堆机器”的“笨办法”轻松实现高并发高可用。

4.HTTP 是明文传输，数据完全肉眼可见，能够方便地研究分析，但也容易被窃听；
5.HTTP 是不安全的，无法验证通信双方的身份，也不能判断报文是否被篡改；

HTTP不安全的三个方面：
(1)数据被窃听
(2)身份被冒用
(3)数据被篡改

6.HTTP 的性能不算差，但不完全适应现在的互联网，还有很大的提升空间。

HTTP的实体数据「body」

(1)HTTP如何确定文件格式？

“多用途互联网邮件扩展”（Multipurpose Internet Mail Extensions），简称为 MIME。MIME通常用在电子邮件系统中，让电子邮件可以发送 ASCII 码以外的任意数据。
MIME 是一个很大的标准规范，但 HTTP 只“顺手牵羊”取了其中的一部分，用来标记 body 的数据类型，这就是我们平常总能听到的“MIME type”。

MIME type

1.text：即文本格式的可读数据，我们最熟悉的应该就是 text/html 了，表示超文本文档，此外还有纯文本 text/plain、样式表 text/css 等。
2.image：即图像文件，有 image/gif、image/jpeg、image/png 等。
3.audio/video：音频和视频数据，例如 audio/mpeg、video/mp4 等。
4.application：数据格式不固定，可能是文本也可能是二进制，必须由上层应用程序来解释。常见的有 application/json，application/javascript、application/pdf 等，另外，如果实在是不知道数据是什么类型，像刚才说的“黑盒”，就会是 application/octet-stream，即不透明的二进制数据。

Encoding type:告诉数据是用的什么编码格式

1.gzip：GNU zip 压缩格式，也是互联网上最流行的压缩格式；
2.deflate：zlib（deflate）压缩格式，流行程度仅次于 gzip；
br：一种专门为 HTTP 优化的新压缩算法（Brotli）。

与MIME type相关的头字段是 Accept 和 Content-Type；

Accept 字段标记的是客户端可理解的 MIME type，可以用“,”做分隔符列出多个类型，让服务器有更多的选择余地，例如下面的这个头：

Accept: text/html,application/xml,image/webp,image/png

服务器则会在响应报文里用头字段 Content-Type 告诉实体数据的真实类型：

Content-Type: text/html
Content-Type: image/png

(2)数据编码表示实体数据的压缩方式，相关的头字段是 Accept-Encoding 和 Content-Encoding；

例子：

Accept-Encoding: gzip, deflate, br
Content-Encoding: gzip

(3)语言类型表示实体数据的自然语言，相关的头字段是 Accept-Language 和 Content-Language；

Accept-Language: zh-CN, zh, en
Content-Language: zh-CN

（4）字符集表示实体数据的编码方式，相关的头字段是 Accept-Charset 和 Content-Type；

Accept-Charset: gbk, utf-8
Content-Type: text/html; charset=utf-8

客户端需要在请求头里使用 Accept 等头字段与服务器进行“内容协商”，要求服务器返回最合适的数据；

Accept 等头字段可以用“,”顺序列出多个可能的选项，还可以用“;q=”参数来精确指定权重。

Accept: text/html,application/xml;q=0.9,*/*;q=0.8

内容协商的结果

Vary: Accept-Encoding,User-Agent,Accept

这个 Vary 字段表示服务器依据了 Accept-Encoding、User-Agent 和 Accept 这三个头字段，然后决定了发回的响应报文。

HTTP的大文件传输方法

(1)压缩 HTML 等文本文件是传输大文件最基本的方法；

用了上次提到的Accept-Encoding头字段与Content-Encoding响应头，常见格式有gzip，deflate，br；

(2)分块传输可以流式收发数据，节约内存和带宽，使用响应头字段“Transfer-Encoding: chunked”来表示，分块的格式是 16 进制长度头 + 数据块；

注意：
1.“Transfer-Encoding: chunked”和“Content-Length”这两个字段是互斥的，也就是说响应报文里这两个字段不能同时出现，一个响应报文的传输要么是长度已知，要么是长度未知（chunked）
2.分块传输的编码规则「采用明文」

1.每个分块包含两个部分，长度头和数据块；
2.长度头是以 CRLF（回车换行，即\r\n）结尾的一行明文，用 16 进制数字表示长度；
3.数据块紧跟在长度头后，最后也用 CRLF 结尾，但数据不包含 CRLF；
4.最后用一个长度为 0 的块表示结束，即“0\r\n\r\n”。

(3)范围请求可以只获取部分数据，即“分块请求”，实现视频拖拽或者断点续传，使用请求头字段“Range”和响应头字段“Content-Range”，响应状态码必须是 206；

1.Accept-Ranges:bytes 表名服务器支持范围请求
2.范围请求，可以只播放某一段
3.Range的格式

“0-”表示从文档起点到文档终点，相当于“0-99”，即整个文件；
“10-”是从第 10 个字节开始到文档末尾，相当于“10-99”；
“-1”是文档的最后一个字节，相当于“99-99”；
“-10”是从文档末尾倒数 10 个字节，相当于“90-99”。

(4)可以一次请求多个范围，这时候响应报文的数据类型是“multipart/byteranges”，body 里的多个部分会用 boundary 字符串分隔。

范围请求请求代码：

点击查看代码

GET /16-2 HTTP/1.1
Host: www.chrono.com
Range: bytes=0-9, 20-29

范围请求响应代码：

点击查看代码

HTTP/1.1 206 Partial Content
// boundary代表分隔在下面有所体现
Content-Type: multipart/byteranges; boundary=00000000001
Content-Length: 189
Connection: keep-alive
Accept-Ranges: bytes


--00000000001
Content-Type: text/plain
Content-Range: bytes 0-9/96

// this is
--00000000001
Content-Type: text/plain
Content-Range: bytes 20-29/96

ext json d
--00000000001--

HTTP的连接管理

短连接

(1)是什么？

因为客户端与服务器的整个连接过程很短暂，不会与服务器保持长时间的连接状态，所以就被称为“短连接”（short-lived connections） (2)有什么缺点？
每次进行请求-应答时，都需要TCP“三次握手”建立连接，四次挥手断开链接，传输效率低的吓人。
ps:定义往返时间(round trip time，简称RTT)

(3)怎么解决？

建立长连接。
用的是“成本均摊”的思路，既然 TCP 的连接和关闭非常耗时间，那么就把这个时间成本由原来的一个“请求 - 应答”均摊到多个“请求 - 应答”上。
短连接与长连接的对比图

长连接

(1)是什么？

针对短连接暴露出的缺点，HTTP 协议就提出了“长连接”的通信方式，也叫“持久连接”（persistent connections）、“连接保活”（keep alive）、“连接复用”（connection reuse）。

(2)有什么缺点？

如果TCP 连接长时间不关闭，服务器必须在内存里保存它的状态，这就占用了服务器的资源。如果有大量的空闲长连接只连不发，就会很快耗尽服务器的资源，导致服务器无法为真正有需要的用户提供服务。

(3)怎么解决？

在客户端，可以在请求头里加上“Connection: close”字段，告诉服务器：“这次通信后就关闭连接”。

(4)Nginx中的例子

服务器端通常不会主动关闭连接，但也可以使用一些策略。
拿 Nginx 来举例，它有两种方式：
1.使用“keepalive_timeout”指令，设置长连接的超时时间，如果在一段时间内连接上没有任何数据收发就主动断开连接，避免空闲连接占用系统资源。
2.使用“keepalive_requests”指令，设置长连接上可发送的最大请求次数。比如设置成 1000，那么当 Nginx 在这个连接上处理了 1000 个请求后，也会主动断开连接。

队头阻塞

(1)是什么？ 由 HTTP 基本的“请求 - 应答”模型所导致的。
因为 HTTP 规定报文必须是“一发一收”，这就形成了一个先进先出的“串行”队列。队列里的请求没有轻重缓急的优先级，只有入队的先后顺序，排在最前面的请求被最优先处理。
所以如果队首处理的太慢了，后面的资源都无法处理

(2)怎么解决？ 1.“并发连接”（concurrent connections），也就是同时对一个域名发起多个长连接，用数量来解决质量的问题。
但这种方式也存在缺陷。如果每个客户端都想自己快，建立很多个连接，用户数×并发数就会是个天文数字。服务器的资源根本就扛不住，或者被服务器认为是恶意攻击，反而会造成“拒绝服务”。
2.“域名分片”（domain sharding）技术，还是用数量来解决质量的思路。
HTTP 协议和浏览器不是限制并发连接数量吗？好，那我就多开几个域名。

HTTP中的重定向

1.重定向是服务器发起的跳转，要求客户端改用新的 URI 重新发送请求，通常会自动进行，用户是无感知的；
2.301/302 是最常用的重定向状态码，分别是“永久重定向”和“临时重定向”；
3.响应头字段 Location 指示了要跳转的 URI，可以用绝对或相对的形式；
4.重定向可以把一个 URI 指向另一个 URI「比如此网站短期维护」，也可以把多个 URI 指向同一个 URI「比如多个淘宝分站指向主站」，用途很多；
5.使用重定向时需要当心性能损耗，还要避免出现循环跳转。

HTTP中的Cookie机制

前言：HTTP 是“无状态”的，这既是优点也是缺点。优点是服务器没有状态差异，可以很容易地组成集群，而缺点就是无法支持需要记录状态的事务操作。

什么是Cookie

答：储存在用户本地终端上的数据

Cookie的工作过程

Cookie工作流程，需要用到响应头字段：
"Set-Cookie"和请求头字段"Cookie"
1、客户端第一次请求时，没有cookie信息，服务器收到后响应报文里返回cookie信息。在头字段Set-Cookie中以key-value键值对存储
2、客户端收到响应后，若Set-Cookie字段不为空，则将Cookie信息存在本地（一般是浏览器中），下一次请求时会将存储的Cookie信息放到头字段Cookie中发送给服务器，多个键值对中间用“;”隔开
3、服务器再一次收到请求后，通过Cookie字段就能识别出该次请求的身份信息

工作过程：

注意：
Cookie是浏览器内部绑定的

Cookie的属性

设置 Cookie 的生存周期(有效期) 有两个属性
1.“Expires”俗称“过期时间”，用的是绝对时间点，可以理解为“截止日期”（deadline）。
2.“Max-Age”用的是相对时间，单位是秒，浏览器用收到报文的时间点再加上 Max-Age，就可以得到失效的绝对时间。
3.两个都有的时候一般以Max-Age为标准
设置 Cookie 的作用域 有两个属性：
1.“Domain”指定了 Cookie 所属的域名
2."Path"指定了 Cookie 所属的路径，一般不限制Path，直接用一个‘/’比较省事
Cookie 的安全性 属性“HttpOnly”会告诉浏览器，此 Cookie 只能通过浏览器 HTTP 协议传输，禁止其他方式访问。
这样就防止了JS脚本读取Cookie。

HTTP的缓存控制

服务器的缓存控制
pre:缓存是优化系统性能的重要手段，HTTP 传输的每一个环节中都可以有缓存；

缓存流程：
1.浏览器发现缓存无数据，于是发送请求，向服务器获取资源；
2.服务器响应请求，返回资源，同时标记资源的有效期；
3.浏览器缓存资源，等待下次重用。

看到图中的max-age了吗？
它表示资源的有效期。
它之所以存在，是因为服务器的资源会不断的更新，所以我不会一直保留着这个资源

响应报文的其他属性：
1.no-store：不允许缓存，用于某些变化非常频繁的数据，例如秒杀页面；
2.no-cache「找最新的」：它的字面含义容易与 no-store 搞混，实际的意思并不是不允许缓存，而是可以缓存，但在使用之前必须要去服务器验证是否过期，是否有最新的版本；
3.must-revalidate「看过期没」：又是一个和 no-cache 相似的词，它的意思是如果缓存不过期就可以继续使用，但过期了如果还想用就必须去服务器验证。

用法流程图

条件请求
1.验证资源是否失效需要使用“条件请求”，常用的是“if-Modified-Since”和“If-None-Match”，收到 304 就可以复用缓存里的资源；
2.验证资源是否被修改的条件有两个：“Last-modified”和“ETag”，需要服务器预先在响应报文里设置，搭配条件请求使用；
(1)ETag 是“实体标签”（Entity Tag）的缩写，是资源的一个唯一标识，主要是用来解决修改时间无法准确区分文件变化的问题。
(2)ETag有强有弱：
弱 ETag 在值前有个“W/”,标记仅需要在语义上没有变化即可但内部可能会有部分发生了改变（例如 HTML 里的标签顺序调整，或者多了几个空格）。
强 ETag 要求资源在字节级别必须完全相符.

HTTP的代理服务

代理是什么？

HTTP 代理就是客户端和服务器通信链路中的一个中间环节，为两端提供“代理服务”；

代理的作用

1.负载均衡：
当一台服务器的性能达到极限时，我们可以使用服务器集群来提高网站的整体性能。那么，在服务器集群中，需要有一台服务器充当调度者的角色，用户的所有请求都会首先由它接收，调度者再根据每台服务器的负载情况将请求分配给某一台后端服务器去处理。
那么在这个过程中，调度者如何合理分配任务，保证所有后端服务器都将性能充分发挥，从而保持服务器集群的整体性能最优，这就是负载均衡问题。
2.健康检查：使用“心跳”等机制监控后端服务器，发现有故障就及时“踢出”集群，保证服务高可用；
3.安全防护：保护被代理的后端服务器，限制 IP 地址或流量，抵御网络攻击和过载；
4.加密卸载：对外网使用 SSL/TLS 加密通信认证，而在安全的内网不加密，消除加解密成本；
5.数据过滤：拦截上下行的数据，任意指定策略修改请求或者响应；

代理相关字段

代理服务器需要使用字段“Via”标记自己的身份，多个代理会形成一个列表；

1.Via 字段解决了客户端和源服务器判断是否存在代理的问题，追加的是代理主机名（或者域名）

如果想要知道客户端的真实 IP 地址，可以使用字段“X-Forwarded-For”和“X-Real-IP”；

2.“X-Forwarded-For”的字面意思是“为谁而转发”，形式上和“Via”差不多，追加的是请求方的 IP 地址。

3.“X-Real-IP”是另一种获取客户端真实 IP 的手段，它的作用很简单，就是记录客户端 IP 地址，没有中间的代理信息，相当于是“X-Forwarded-For”的简化版。如果客户端和源服务器之间只有一个代理，那么这两个字段的值就是相同的。

代理协议

“代理协议”可以在不改动原始报文的情况下传递客户端的真实 IP。

PROXY TCP4 1.1.1.1 2.2.2.2 55555 80\r\n
GET / HTTP/1.1\r\n
Host: www.xxx.com\r\n
\r\n

第一行文本就是代理协议，这一行文本其实非常简单，开头必须是“PROXY”五个大写字母，然后是“TCP4”或者“TCP6”，表示客户端的 IP 地址类型，再后面是请求方地址、应答方地址、请求方端口号、应答方端口号，最后用一个回车换行（\r\n）结束。

HTTP的缓存代理

缓存代理服务

代理服务收到源服务器发来的响应数据后需要做两件事。第一个当然是把报文转发给客户端，而第二个就是把报文存入自己的 Cache 里。下一次再有相同的请求，代理服务器就可以直接发送 304 或者缓存数据，不必再从源服务器那里获取。这样就降低了客户端的等待时间，同时节约了源服务器的网络带宽。

源服务器的缓存控制

src:
1.“private”表示缓存只能在客户端保存，是用户“私有”的，不能放在代理上与别人共享。
2.而“public”的意思就是缓存完全开放，谁都可以存，谁都可以用。
3.“must-revalidate”是只要过期就必须回源服务器验证，
4.而新的“proxy-revalidate”只要求代理的缓存过期后必须验证，客户端不必回源，只验证到代理这个环节就行了。
5.服务器用“s-maxage”,客户端仍然使用“max-age”。

客户端的缓存控制

src:
1.max-stale”的意思是如果代理上的缓存过期了也可以接受，但不能过期太多，超过 x 秒也会不要。
2.“min-fresh”的意思是缓存必须有效，而且必须在 x 秒后依然有效。

其他问题 Purge:
1.过期的数据应该及时淘汰，避免占用空间；
2.源站的资源有更新，需要删除旧版本，主动换成最新版（即刷新）；
3.有时候会缓存了一些本不该存储的信息，例如网络谣言或者危险链接，必须尽快把它们删除。

HTTP面试题

在CSDN上写的HTTP总结

HTTP面试题总结 (opens new window)

HTTP是什么？

答：
HTTP(Hyper Text Transfer Protocol)，是超文本传输协议。
这个名词可以划分为三个部分--“超文本”,“传输”,“协议”
首先看协议，协议是你与我之间，我与他之间的一个约定和规范
传输则需要两个对象，分别是请求方和响应方，数据在这两者之间传输，但应该注意的是，请求方和响应方中间也有可能存在中间人，也就是代理，可以有一个中间人，也可以有无穷多个中间人。
那超文本是什么呢？
不妨先看看文本是什么。文本，顾名思义，就是有意义的文字，音频，视频。
那超越文本的超文本是什么呢？
超文本就是超越了这些文本的文本，是文字，音频，视频的集合体，同时其中存在着超链接，可以从一个文本跳转到另一个文本。
所以，HTTP是一个用在计算机世界里的协议，它确立了一种计算机之间交流通信的规范，以及相关的各种控制和错误处理方式。

Cookie和Cache的异同

(1)相同点：
都会保存到浏览器中，并可以设置过期时间。
(2)不同点：

1. Cookie 会随请求报文发送到服务器，而 Cache 不会，但可能会携带 if-Modified-Since（保存资源的最后修改时间）和 If-None-Match（保存资源唯一标识） 字段来验证资源是否过期。
   
2. Cookie 在浏览器可以通过脚本获取（如果 cookie 没有设置 HttpOnly），Cache 则无法在浏览器中获取（出于安全原因）。
   
3. 用途不同。Cookie 常用于身份识别，Cache 则是由浏览器管理，用于节省带宽和加快响应速度。
   
4. Cookie 的 max-age 是从浏览器拿到响应报文时开始计算的，而 Cache 的 max-age 是从响应报文的生成时间（Date 头字段）开始计算。
   

HTTPS是什么？SSL/TLS又是什么

什么是安全？

安全有四个特性：
(1)机密性：
机密性（Secrecy/Confidentiality）是指对数据的“保密”，只能由可信的人访问，对其他人是不可见的“秘密”，简单来说就是不能让不相关的人看到不该看的东西。
(2)完整性：
完整性（Integrity，也叫一致性）是指数据在传输过程中没有被篡改，不多也不少，“完完整整”地保持着原状。
(3)身份验证：
身份认证（Authentication）是指确认对方的真实身份，也就是“证明你真的是你”，保证消息只能发送给可信的人。
(4)不可否认：
不可否认（Non-repudiation/Undeniable），也叫不可抵赖，意思是不能否认已经发生过的行为，不能“说话不算数”“耍赖皮”。

什么是 HTTPS？

HTTP是：
“HTTP over TCP/IP”
HTTPS是：
“HTTP over SSL/TLS”

什么是SSL/TLS

1.SSL 即安全套接层（Secure Sockets Layer）

2.SSL 发展到 v3 时已经证明了它自身是一个非常好的安全通信协议，于是互联网工程组 IETF 在 1999 年把它改名为 TLS（传输层安全，Transport Layer Security），正式标准化，版本号从 1.0 重新算起，所以 TLS1.0 实际上就是 SSLv3.1。