Session和cookie应该如何去选择适用场景？

大家好，我是阿秀。

直接进入今天正文，不多逼逼。

上期已经更新了 33 问 33 答，那今天再来更新 33 问 33 答好了哈哈，这是整个系列的第八期了，也是计网系列的第二期，计网还有一期就更新完了。

“

本期内容已同步至 github 仓库，欢迎大家 star。

点击文末左侧的阅读原文即可直达仓库地址，仓库地址：https：／／github．com／forthespada／InterviewGuide

PDF 暂时还没更新过来，等下期第九期，也就是计算机网络最后一期，再出 PDF 好了。

下面是本期 33 问 33 答。

34、DNS查询方式有哪些？递归解析

当局部DNS服务器自己不能回答客户机的DNS查询时，它就需要向其他DNS服务器进行查询。此时有两种方式。局部DNS服务器自己负责向其他DNS服务器进行查询，一般是先向该域名的根域服务器查询，再由根域名服务器一级级向下查询。最后得到的查询结果返回给局部DNS服务器，再由局部DNS服务器返回给客户端。

迭代解析

当局部DNS服务器自己不能回答客户机的DNS查询时，也可以通过迭代查询的方式进行解析。局部DNS服务器不是自己向其他DNS服务器进行查询，而是把能解析该域名的其他DNS服务器的IP地址返回给客户端DNS程序，客户端DNS程序再继续向这些DNS服务器进行查询，直到得到查询结果为止。

也就是说，迭代解析只是帮你找到相关的服务器而已，而不会帮你去查。比如说：baidu．com的服务器ip地址在192．168．4．5这里，你自己去查吧，本人比较忙，只能帮你到这里了。

35、HTTP中缓存的私有和共有字段？知道吗？

private 指令规定了将资源作为私有缓存，只能被单独用户使用，一般存储在用户浏览器中。

Cache－Control： private

public 指令规定了将资源作为公共缓存，可以被多个用户使用，一般存储在代理服务器中。

Cache－Control： public

36、GET 方法参数写法是固定的吗？

在约定中，我们的参数是写在 ？ 后面，用 ＆ 分割。

我们知道，解析报文的过程是通过获取 TCP 数据，用正则等工具从数据中获取 Header 和 Body，从而提取参数。

比如header请求头中添加token，来验证用户是否登录等权限问题。

也就是说，我们可以自己约定参数的写法，只要服务端能够解释出来就行，万变不离其宗。

37、GET 方法的长度限制是怎么回事？

网络上都会提到浏览器地址栏输入的参数是有限的。

首先说明一点，HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大多是浏览器和服务器的原因。

浏览器原因就不说了，服务器是因为处理长 URL 要消耗比较多的资源，为了性能和安全（防止恶意构造长 URL 来攻击）考虑，会给 URL 长度加限制。

38、POST 方法比 GET 方法安全？

有人说POST 比 GET 安全，因为数据在地址栏上不可见。

然而，从传输的角度来说，他们都是不安全的，因为 HTTP 在网络上是明文传输的，只要在网络节点上捉包，就能完整地获取数据报文。

要想安全传输，就只有加密，也就是 HTTPS。

39、POST 方法会产生两个 TCP 数据包？你了解吗？

有些文章中提到，POST 会将 header 和 body 分开发送，先发送 header，服务端返回 100 状态码再发送 body。

HTTP 协议中没有明确说明 POST 会产生两个 TCP 数据包，而且实际测试（Chrome）发现，header 和 body 不会分开发送。

所以，header 和 body 分开发送是部分浏览器或框架的请求方法，不属于 post 必然行为。

40、Session是什么？

除了可以将用户信息通过 cookie 存储在用户浏览器中，也可以利用 Session 存储在服务器端，存储在服务器端的信息更加安全。

Session 可以存储在服务器上的文件、数据库或者内存中。也可以将 Session 存储在 Redis 这种内存型数据库中，效率会更高。

41、使用 Session 的过程是怎样的？

过程如下：

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

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

42、Session和cookie应该如何去选择（适用场景）？

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

43、cookies和Session区别是什么？

cookie和Session都是客户端与服务器之间保持状态的解决方案

1，存储的位置不同，cookie：存放在客户端，session：存放在服务端。Session存储的数据比较安全

2，存储的数据类型不同两者都是key－value的结构，但针对value的类型是有差异的cookie：value只能是字符串类型，session：value是Object类型

3，存储的数据大小限制不同cookie：大小受浏览器的限制，很多是是4K的大小， session：理论上受当前内存的限制

4，生命周期的控制cookie的生命周期当浏览器关闭的时候，就消亡了

（1）cookie的生命周期是累计的，从创建时，就开始计时，20分钟后，cookie生命周期结束，

（2）session的生命周期是间隔的，从创建时，开始计时如在20分钟，没有访问session，那么session生命周期被销毁。