快捷搜索:

计算机网之应用层(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]
  1. 客户端之后对同一个服务器发送请求时,会从浏览器中取出 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 在多数情况下不可缓存的。
经验分享 程序员 职场和发展