计算机网之应用层（HTTP/1.0与1.1的区别、cookie与session、HTTPS）

3. HTTP续

① HTTP/1.0与HTTP/1.1区别

长连接与短接

• HTTP/1.0中，每进行一次 HTTP 通信就要新建一个 TCP 连接，这种连接叫做短连接（又叫非持续连接）。这时，如果请求的html页面中包含多张图片，除了请求HTML页面资源，还会请求图片资源，这样使得开销很大。
• 虽然浏览器提供了并行的TCP连接，但是这不能很好的解决问题。
• HTTP/1.1中，客户和服务器建立一次TCP连接能进行多次HTTP通信，这种连接叫做长连接（又叫持续连接）。
• 从 HTTP/1.1 开始默认是长连接的，如果需要断开连接，需要由客户端或者服务器端提出断开，使用 Connection : close
• 在 HTTP/1.1 之前默认是短连接的，如果需要使用长连接，则使用 Connection : Keep-Alive。

HTTP/1.1的流水线方式和非流水线方式

• 非流水线方式： 客户在收到前一个响应后才能发出下一个请求。这使得TCP连接经常处于空闲状态，白白浪费了服务器资源。
• 流水线方式： 客户在收到HTTP的响应报文之前就能接着发送新的请求报文。这使得TCP连接的空闲减少，可以减少延迟，提高文档的下载效率。

② cookie

• Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，浏览器之后向同一服务器再次发起请求时会携带上该cookie，用于告知服务端两个请求是否来自同一浏览器。
• 由于之后每次请求都会需要携带 Cookie 数据，因此会带来额外的性能开销（尤其是在移动环境下）。
• Cookie 曾一度用于客户端数据的存储，但现在随着现代浏览器开始支持各种各样的存储方式，Cookie 渐渐被淘汰。
• cookie的使用场景：

1. 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
2. 个性化设置（如用户自定义设置、主题等）
3. 浏览器行为跟踪（如跟踪分析用户行为等）

• cookie的创建过程：

1. 服务器将cookie通过响应报文中的 Set-Cookie 首部字段发送给客户，客户端得到响应报文后把 Cookie 内容保存到浏览器中。

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

2. 客户端之后对同一个服务器发送请求时，会从浏览器中取出 Cookie 信息并通过 Cookie 首部字段发送给服务器。

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

• cookie的分类：会话期cookie和持久性cookie

1. 会话期 Cookie： 浏览器关闭之后它会被自动删除，也就是说它仅在会话期内有效。
2. 持久性 Cookie： 指定过期时间（Expires）或有效期（max-age）之后就成为了持久性的 Cookie。

③ session

• session将用户信息存储在服务器端，这样信息会更加安全。
• Session 可以存储在服务器上的文件、数据库或者内存中。也可以将 Session 存储在 Redis 这种内存型数据库中，效率会更高。
• 使用 Session 维护用户登录状态的过程：

1. 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中。
2. 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID。
3. 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中。
4. 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。

• 使用session ID要注意的问题：

1. 为了不让 Session ID 被恶意攻击者轻易获取，那么就不能产生一个容易被猜到的 Session ID 值。
2. 需要经常重新生成 Session ID。
3. 在对安全性要求极高的场景下，例如转账等操作，除了使用 Session 管理用户状态之外，还需要对用户进行重新验证，比如重新输入密码，或者使用短信验证码等方式。

Cookie 与 Session 选择

• Cookie 只能存储 ASCII 码字符串，而 Session 则可以存储任何类型的数据，因此在考虑数据复杂性时首选 Session。
• Cookie 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将 Cookie 值进行加密，然后在服务器进行解密。
• 对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的。因此，不建议将所有的用户信息都存储到 Session 中。

④ session与cookie的常见问题

1. cookie与session区别

• 存储的地方： 浏览器、服务器；安全性： session的安全性更好
• 二者的配合使用： session如何管理用户登录状态的
• cookie与session的选择

2. 如果浏览器禁用cookie，怎么办？

• 此时无法使用 Cookie 来保存用户信息，只能使用 Session。
• 除此之外，不能再将 Session ID 存放到 Cookie 中，而是使用 URL 重写技术，将 Session ID 作为 URL 的参数进行传递。

3. 如果浏览器禁用cookie，session受影响吗？

4. cookie是如何被传到前端的？

• cookie的创建过程： 服务器的响应报文的Set-Cookie首部字段。

4. HTTPS

① HTTP存在的安全性问题

• 窃听风险： 使用明文进行通信，可能被窃听。（比如，使用WireShark抓包工具可以获取请求和响应报文的内容）
• 篡改风险： 无法证明报文的完整性，可能被篡改。（中间人攻击，请求和响应被随意篡改）
• 冒充风险： 不验证通信方的身份，可能遭遇伪装。（不管是谁发起的请求都会做出响应）
  
  图1 窃听风险
  
  图2 篡改风险
  
  图3 冒充风险
• SSL/TLS协议是为了解决这三大风险而设计的，希望达到以下效果：

1. 加密： 所有信息加密传播，防止被第三方窃听。
2. 认证： 配备身份证书，防止被冒充。
3. 完整性保证： 报文一旦被篡改，通信双方会立刻发现。

② HTTP+加密+认证+完整性保护 = HTTPS

• HTTPS 并不是新协议，而是在HTTP层之下提供了一个传输级的密码安全层—— 该层使用SSL协议（Secure Sockets Layer）或者其后继者TLS协议（Transfer Layer Security）。
• 让 HTTP 先和 SSL通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信。
  
• 通过和SSL进行通信，HTTPS便具有了加密、认证、完整性保护。
• 完整性保护： HTTPS 也提供了报文摘要功能，加密之后的报文，遭到篡改之后，也很难重新计算报文摘要。这样就可以实现完整性保护。
• 注意： 如不需要特殊指明是SSL还是TLS，都使用SSL统称二者。

③ HTTPS采用的加密机制：混合加密

• 对称加密（Symmetric-Key Encryption）： 加密和解密使用统一密钥，虽然运算速度快，但是无法将密钥安全的传递给对方。
• 非对称加密（Public-Key Encryption）：加密和解密使用不同的密钥，比如普通内容加密时，公钥加密，私钥解密；数字签名时，私钥加密，公钥解密。虽然可以安全的将公钥传递给对方，但是运算速度慢。
• HTTPS 采用混合的加密机制：

1. 使用非对称密钥加密对称密钥，用于保证传输对称密钥的安全性
2. 之后的通信都是用对称密钥进行加解密，以保证通信效率。

④ SSL证书

• 客户使用服务器的公钥对对称密钥进行加密后发送给服务器，服务器使用私钥进行解密获得对称密钥，这样对称密钥就在客户和服务器之间实现了安全传输。
• 问题：如何保证公钥是服务器的公钥，而不是第三方冒充的？ —— 使用证书
• 数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构，服务器可以向CA申请自己的证书。
• 证书中有服务器的公钥、数字签名，客户收到服务器的证书后，使用公钥验证证书中的数字签名，这样便可以知道公钥是否是正确的而非冒充的。

⑤ SSL如何实现加密的？（SSL的握手）

• 第一步：爱丽丝给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。
• 第二步：鲍勃确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。
• 第三步：爱丽丝确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。
• 第四步：鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premaster secret）。
• 第五步：爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成对话密钥（session key），用来加密接下来的整个对话过程。

⑥ 关于SSL和TLS

• SSL（Secure Socket Layer）是安全套接层，TLS（Transport Layer Security）是传输层安全协议，建立在SSL3.0协议规范，是 SSL3.0 的后续版本。SSL 直到 3.0版本才大规模的部署和应用，当前最新使用的是TLS1.2协议。
• TLS 版本相比于 SSL 变化明显的是支持的加密算法不同。
• SSL最大的问题：慢！

1. 通信慢： HTTPS比HTTP慢2到100倍，因为除了进行TCP连接、HTTP的请求和响应之外，还需要进行SSL通信。
2. 处理速度慢： 由于SSL需要使用CPU和内存等硬件进行加解密运算，比起HTTP会消耗客户和服务器更多的硬件资源，导致负载增强。

为什么一直不使用SSL？

• SSL比较慢，并非所有的内容都进行加密处理，而是在需要信息隐藏时才进行加密处理，这样可以节约资源。
• SSL证书很贵，并不是所有的网站都用得起。

5. 关于HTTP的常见问题

1. HTTP基于TCP还是UDP？HTTP位于体系结构的哪一层？HTTP的三次握手

2. HTTP/1.0和HTTP/1.1的区别

• 短连接和长连接、长连接的两种工作方式：流水线和非流水线

3. 讲述一下HTTP协议

• 超文本传输协议基于TCP（三次握手）、默认端口80、请求报文和响应报文、方法和状态码、常用的首部字段、cookie和session。

4. HTTP访问页面的流程

• 清华大学服务器的例子

5. HTTP和HTTPS的区别？

• HTTP+加密+认证+完整性保证=HTTPS，HTTPS并非协议，而是在HTTP层之下多了传输级的加密安全层——SSL层。
• 展开：HTTP存在的风险，SSL正好能解决这些风险，二者体系结构的差异（多了SSL层）

6. SSL如何实现加密？

• 混合加密机制、SSL的握手（重点讲述）

7. HTTPS如何实现安全性的？

• 通信内容进行加密，防窃听
• 证书，防冒充+公钥的传递
• 完整性保护，提供报文摘要功能，加密后的报文即使被篡改也很难重新计算报文摘要。

8. GET和POST的区别？

• 作用不同： GET用于获取资源，POST用于向服务器添加信息。
• 参数不同： GET的参数通过URL进行传递，如https://baijiahao.baidu.com/s?id=123&wfr=spiderc；POST的参数存储在请求报文的实体主体中。这使得前者，只支持ASCII编码，后者支持标准字符集。
• 安全性： GET方法只是获取资源，不改变服务器状态；PUT方法尝试向服务器添加信息，会改变服务器状态。因此，GET方法是安全的，POST方法不是安全的。
• 幂等性： GET请求连续执行多次，执行的结果是一样的，即GET方法是幂等的；POST方法连续执行多次，服务器状态会发生改变，它不是幂等的。
• 缓存： 请求报文的 HTTP 方法本身是可缓存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可缓存，POST 在多数情况下不可缓存的。