常见面试题：http篇

1.Http与Https的区别：

• HTTP 的URL 以http:// 开头，而HTTPS 的URL 以https:// 开头
• HTTP 是不安全的，而 HTTPS 是安全的
• HTTP 标准端口是80 ，而 HTTPS 的标准端口是443
• 在OSI 网络模型中，HTTP工作于应用层，而HTTPS 的安全传输机制工作在传输层
• HTTP 无法加密，而HTTPS 对传输的数据进行加密
• HTTP无需证书，而HTTPS 需要CA机构wosign的颁发的SSL证书

2.什么Http协议是无状态协议?怎么解决Http协议无状态协议?

无状态协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，也就是说，当客户端一次HTTP请求完成以后，客户端再发送一次HTTP请求，HTTP并不知道当前客户端是一个”老用户“。
可以使用Cookie来解决无状态的问题，Cookie就相当于一个通行证，第一次访问的时候给客户端发送一个Cookie，当客户端再次来的时候，拿着Cookie(通行证)，那么服务器就知道这个是”老用户“。

3.URI和URL的区别

URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。

Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的
URI一般由三部分组成：
①访问资源的命名机制
②存放资源的主机名
③资源自身的名称，由路径表示，着重强调于资源。

URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。

URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。
采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部分组成：
①协议(或称为服务方式)
②存有该资源的主机IP地址(有时也包括端口号)
③主机资源的具体地址。如目录和文件名等

URN，uniform resource name，统一资源命名，是通过名字来标识资源，比如mailto:java-net@java.sun.com。

URI是以一种抽象的，高层次概念定义统一资源标识，而URL和URN则是具体的资源标识的方式。URL和URN都是一种URI。笼统地说，每个 URL 都是 URI，但不一定每个 URI 都是 URL。这是因为 URI 还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。
在Java的URI中，一个URI实例可以代表绝对的，也可以是相对的，只要它符合URI的语法规则。而URL类则不仅符合语义，还包含了定位该资源的信息，因此它不能是相对的。
在Java类库中，URI类不包含任何访问资源的方法，它唯一的作用就是解析。
相反的是，URL类可以打开一个到达资源的流。

4.常用的HTTP方法有哪些？

• GET： 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器
• POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
• PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。
• HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
• DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
• OPTIONS：查询相应URI支持的HTTP方法。

5.HTTP请求报文与响应报文格式

请求报文包含四部分：
a、请求行：包含请求方法、URI、HTTP版本信息
b、请求首部字段
c、请求内容实体
d、空行

响应报文包含四部分：
a、状态行：包含HTTP版本、状态码、状态码的原因短语
b、响应首部字段
c、响应内容实体
d、空行

常见的首部：

• 通用首部字段（请求报文与响应报文都会使用的首部字段）
  Date：创建报文时间
  Connection：连接的管理
  Cache-Control：缓存的控制
  Transfer-Encoding：报文主体的传输编码方式
• 请求首部字段（请求报文会使用的首部字段）
  Host：请求资源所在服务器
  Accept：可处理的媒体类型
  Accept-Charset：可接收的字符集
  Accept-Encoding：可接受的内容编码
  Accept-Language：可接受的自然语言
• 响应首部字段（响应报文会使用的首部字段）
  Accept-Ranges：可接受的字节范围
  Location：令客户端重新定向到的URI
  Server：HTTP服务器的安装信息
• 实体首部字段（请求报文与响应报文的的实体部分使用的首部字段）
  Allow：资源可支持的HTTP方法
  Content-Type：实体主类的类型
  Content-Encoding：实体主体适用的编码方式
  Content-Language：实体主体的自然语言
  Content-Length：实体主体的的字节数
  Content-Range：实体主体的位置范围，一般用于发出部分请求时使用

6.HTTPS工作原理

一、首先HTTP请求服务端生成证书，客户端对证书的有效期、合法性、域名是否与请求的域名一致、证书的公钥（RSA加密）等进行校验；
二、客户端如果校验通过后，就根据证书的公钥的有效， 生成随机数，随机数使用公钥进行加密（RSA加密）；
三、消息体产生的后，对它的摘要进行MD5（或者SHA1）算法加密，此时就得到了RSA签名；
四、发送给服务端，此时只有服务端（RSA私钥）能解密。
五、解密得到的随机数，再用AES加密，作为密钥（此时的密钥只有客户端和服务端知道）。

7.一次完整的HTTP请求所经历的7个步骤

HTTP通信机制是在一次完整的HTTP通信过程中，Web浏览器与Web服务器之间将完成下列7个步骤：

• 建立TCP连接
  在HTTP工作开始之前，Web浏览器首先要通过网络与Web服务器建立连接，该连接是通过TCP来完成的，该协议与IP协议共同构建 Internet，即著名的TCP/IP协议族，因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议，根据规则， 只有低层协议建立之后才能，才能进行更层协议的连接，因此，首先要建立TCP连接，一般TCP连接的端口号是80。
• Web浏览器向Web服务器发送请求行
  一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令。例如：GET /sample/hello.jsp HTTP/1.1。
• Web浏览器发送请求头
  浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。
• Web服务器应答
  客户机向服务器发出请求后，服务器会客户机回送应答， HTTP/1.1 200 OK ，应答的第一部分是协议的版本号和应答状态码。
• Web服务器发送应答头
  正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。
• Web服务器向浏览器发送数据
  Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。
• Web服务器关闭TCP连接
  一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行代码：Connection:keep-alive

TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。
建立TCP连接->发送请求行->发送请求头->（到达服务器）发送状态行->发送响应头->发送响应数据->断TCP连接

8.常见的HTTP相应状态码

200：请求被正常处理
204：请求被受理但没有资源可以返回
206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。
301：永久性重定向，增加SEO排名
302：临时重定向，禁止POST变为GET
303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上
304：判断是否要更新缓存 请求头部携带if-modified-since自从上次更新距这次多久，发送附带条件的请求时，条件不满足时返回，与重定向无关
307：临时重定向，与302类似，只是强制要求使用POST方法
400：请求报文语法有误，服务器无法识别
401：请求需要认证
403：请求的对应资源禁止被访问
404：服务器无法找到对应资源
500：服务器内部错误
503：服务器正忙

9.HTTP1.1版本新特性

a、默认持久连接节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求
b、管线化，客户端可以同时发出多个HTTP请求，而不用一个个等待响应
c、断点续传
实际上就是利用HTTP消息头使用分块传输编码，将实体主体分块传输。

10.HTTP优化方案

• TCP复用：TCP连接复用是将多个客户端的HTTP请求复用到一个服务器端TCP连接上，而HTTP复用则是一个客户端的多个HTTP请求通过一个TCP连接进行处理。前者是负载均衡设备的独特功能；而后者是HTTP 1.1协议所支持的新功能，目前被大多数浏览器所支持。
  内容缓存：将经常用到的内容进行缓存起来，那么客户端就可以直接在内存中获取相应的数据了。
• 压缩：将文本数据进行压缩，减少带宽
• SSL加速（SSL Acceleration）：使用SSL协议对HTTP协议进行加密，在通道内加密并加速
• TCP缓冲：通过采用TCP缓冲技术，可以提高服务器端响应时间和处理效率，减少由于通信链路问题给服务器造成的连接负担。

11.浏览器缓存

https://www.cnblogs.com/threepigs/p/10547827.html
浏览器缓存可以分成 Service Worker、Memory Cache、Disk Cache 和 Push Cache，那请求的时候 from memory cache 和 from disk cache 的依据是什 么，哪些数据什么时候存放在 Memory Cache 和 Disk Cache中？
浏览器缓存就是把一个已经请求过的资源拷贝一份存储起来，当下次需要该资源时，浏览器会根据缓存机制决定直接使用缓存资源还是再次向服务器发送请求。浏览器缓存最主要的作用是减少网络传输的损耗以及降低服务器压力。

缓存位置

浏览器缓存位置分为四种，其优先级顺序如下：

• Service Worker
• Memory Cache
• Disk Cache
• Push Cache

当上述四个缓存位置中的缓存都没有命中时，则会向服务器发起请求。

• Service Worker
  可以通过谷歌开发者工具中的 Application -> Service Workers 查看当前缓存的资源。
  Service Worker 是运行在浏览器背后的独立线程，一般可以用来实现缓存功能。使用 Service Worker的话，传输协议必须为 HTTPS。因为 Service Worker 中涉及到请求拦截，所以必须使用 HTTPS 协议来保障安全。Service Worker 的缓存与浏览器其他内建的缓存机制不同，它可以让我们自由控制缓存哪些文件、如何匹配缓存、如何读取缓存，并且缓存是持续性的。
  Service Worker 实现缓存功能一般分为三个步骤：首先需要先注册 Service Worker，然后监听到 install 事件以后就可以缓存需要的文件，那么在下次用户访问的时候就可以通过拦截请求的方式查询是否存在缓存，存在缓存的话就可以直接读取缓存文件，否则就去请求数据。
  当 Service Worker 没有命中缓存的时候，我们需要去调用 fetch 函数获取数据。也就是说，如果我们没有在 Service Worker 命中缓存的话，会根据缓存查找优先级去查找数据。但是不管我们是从 Memory Cache 中还是从网络请求中获取的数据，浏览器都会显示我们是从 Service Worker 中获取的内容。
• Memory Cache
  Memory Cache 即内存中的缓存，其特点是容量小、读取高效、持续性短，会随着进程的释放而释放。
  所以，在内存使用率低、缓存小尺寸资源时，会以 Memory Cache 为优先，否则使用 Disk Cache。
  Memory Cache 也就是内存中的缓存，主要包含的是当前中页面中已经抓取到的资源,例如页面上已经下载的样式、脚本、图片等。读取内存中的数据肯定比磁盘快,内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。 一旦我们关闭 Tab 页面，内存中的缓存也就被释放了。
  那么既然内存缓存这么高效，我们是不是能让数据都存放在内存中呢？
  这是不可能的。计算机中的内存一定比硬盘容量小得多，操作系统需要精打细算内存的使用，所以能让我们使用的内存必然不多。
  当我们访问过页面以后，再次刷新页面，可以发现很多数据都来自于内存缓存，内存缓存中有一块重要的缓存资源是preloader相关指令（例如）下载的资源。总所周知preloader的相关指令已经是页面优化的常见手段之一，它可以一边解析js/css文件，一边网络请求下一个资源。
  需要注意的事情是，内存缓存在缓存资源时并不关心返回资源的HTTP缓存头Cache-Control是什么值，同时资源的匹配也并非仅仅是对URL做匹配，还可能会对Content-Type，CORS等其他特征做校验。
• Disk Cache
  Disk Cache 即磁盘中的缓存，其特点是容量大、读取缓慢、持续性长，任何资源都能存储到磁盘中。
  所以，在内存使用率高、缓存大尺寸资源时，会以 Disk Cache 为优先。
  Disk Cache 也就是存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。
  在所有浏览器缓存中，Disk Cache 覆盖面基本是最大的。它会根据 HTTP Herder 中的字段判断哪些资源需要缓存，哪些资源可以不请求直接使用，哪些资源已经过期需要重新请求。并且即使在跨站点的情况下，相同地址的资源一旦被硬盘缓存下来，就不会再次去请求数据。绝大部分的缓存都来自 Disk Cache。
  浏览器会把哪些文件丢进内存中？哪些丢进硬盘中？关于这点，网上说法不一，不过以下观点比较靠得住：
  1.对于大文件来说，大概率是不存储在内存中的，反之优先
  2.当前系统内存使用率高的话，文件优先存储进硬盘
• Push Cache
  Push Cache 是 HTTP 2.0 中的内容，其缓存时间也很短暂，只在会话（Session）中存在，一旦会话结束就被释放。
  所有的资源都能被推送，并且能够被缓存,但是 Edge 和 Safari 浏览器支持相对比较差
  可以推送 no-cache 和 no-store 的资源
  一旦连接被关闭，Push Cache 就被释放
  多个页面可以使用同一个HTTP/2的连接，也就可以使用同一个Push Cache。这主要还是依赖浏览器的实现而定，出于对性能的考虑，有的浏览器会对相同域名但不同的tab标签使用同一个HTTP连接。
  Push Cache 中的缓存只能被使用一次
  浏览器可以拒绝接受已经存在的资源推送
  你可以给其他域名推送资源
  1.区别
  from memory cache：字面理解是从内存中，其实也是字面的含义，这个资源是直接从内存中拿到的，不会请求服务器一般已经加载过该资源且缓存在了内存当中，当关闭该页面时，此资源就被内存释放掉了，再次重新打开相同页面时不会出现from memory cache的情况
  from disk cache：同上类似，此资源是从磁盘当中取出的，也是在已经在之前的某个时间加载过该资源，不会请求服务器但是此资源不会随着该页面的关闭而释放掉，因为是存在硬盘当中的，下次打开仍会from disk cache
  资源本身大小数值：当http状态为200是实实在在从浏览器获取的资源，当http状态为304时该数字是与服务端通信报文的大小，并不是该资源本身的大小，该资源是从本地获取的
  2.chrome采取措施的准则
  什么时候是from memory cache 什么时候是from disk cache 呢？
  即哪些资源会放在内存当中，哪些资源浏览器会放在磁盘上呢，结果如下下表所示
  
  由此可见样式表一般在磁盘中，不会缓存到内存中去，因为css样式加载一次即可渲染出网页，但是脚本却可能随时会执行，如果脚本在磁盘当中，在执行该脚本需要从磁盘中取到内存当中来，这样的IO开销是比较大的，有可能会导致浏览器失去响应
  3.不同浏览器策略是否一致
  以上的数据及统计都是在chrome浏览器下进行的，在Firefox下并没有from memory cache以及from disk cache的状态展现，相同的资源在chrome下是from disk/memory cache，但是Firefox统统是304状态码，即Firefox下会缓存资源，但是每次都会请求服务器对比当前缓存是否更改，chrome不请求服务器，直接拿过来用，这也是为啥chrome比较快的原因之一吧。

12.强缓存和协商缓存

https://www.jianshu.com/p/1a1536ab01f1

浏览器缓存机制

浏览器缓存(Brower Caching)是浏览器在本地磁盘对用户最近请求过的文档进行存储，当访问者再次访问同一页面时，浏览器就可以直接从本地磁盘加载文档。
浏览器缓存的优点有：
1.减少了冗余的数据传输，节省了网费
2.减少了服务器的负担，大大提升了网站的性能
3.加快了客户端加载网页的速度

浏览器缓存过程

1.浏览器第一次加载资源，服务器返回200，浏览器将资源文件从服务器上请求下载下来，并把response header及该请求的返回时间一并缓存；
2.下一次加载资源时，先比较当前时间和上一次返回200时的时间差，如果没有超过cache-control设置的max-age，则没有过期，命中强缓存，不发请求直接从本地缓存读取该文件（如果浏览器不支持HTTP1.1，则用expires判断是否过期）；如果时间过期，则向服务器发送header带有If-None-Match和If-Modified-Since的请求
3.服务器收到请求后，优先根据Etag的值判断被请求的文件有没有做修改，Etag值一致则没有修改，命中协商缓存，返回304；如果不一致则有改动，直接返回新的资源文件带上新的Etag值并返回200；
4.如果服务器收到的请求没有Etag值，则将If-Modified-Since和被请求文件的最后修改时间做比对，一致则命中协商缓存，返回304；不一致则返回新的last-modified和文件并返回200；
浏览器缓存主要有两类：缓存协商和彻底缓存，也有称之为协商缓存和强缓存

强缓存：不会向服务器发送请求，直接从缓存中读取资源，在chrome控制台的network选项中可以看到该请求返回200的状态码;
协商缓存：向服务器发送请求，服务器会根据这个请求的request header的一些参数来判断是否命中协商缓存，如果命中，则返回304状态码并带上新的response header通知浏览器从缓存中读取资源；
协商缓存和强缓存的共同点和区别
两者的共同点是，都是从客户端缓存中读取资源；区别是强缓存不会发请求，协商缓存会发请求

强缓存和协商缓存的命中和管理

1）浏览器在加载资源时，先根据这个资源的一些http header判断它是否命中强缓存，强缓存如果命中，浏览器直接从自己的缓存中读取资源，不会发请求到服务器。比如某个css文件，如果浏览器在加载它所在的网页时，这个css文件的缓存配置命中了强缓存，浏览器就直接从缓存中加载这个css，连请求都不会发送到网页所在服务器；
2）当强缓存没有命中的时候，浏览器一定会发送一个请求到服务器，通过服务器端依据资源的另外一些http header验证这个资源是否命中协商缓存，如果协商缓存命中，服务器会将这个请求返回，但是不会返回这个资源的数据，而是告诉客户端可以直接从缓存中加载这个资源，于是浏览器就又会从自己的缓存中去加载这个资源；
3）强缓存与协商缓存的共同点是：如果命中，都是从客户端缓存中加载资源，而不是从服务器加载资源数据；区别是：强缓存不发请求到服务器，协商缓存会发请求到服务器。
4）当协商缓存也没有命中的时候，浏览器直接从服务器加载资源数据。
以下行为可能改变缓存的默认处理方式
当ctrl+f5强制刷新网页时，直接从服务器加载，跳过强缓存和协商缓存；
当f5刷新网页时，跳过强缓存，但是会检查协商缓存；

13.同源策略

同源需满足的条件：

• 协议相同
• 域名相同:a.b.c.com a.b.d.com域名相同吗
• 端口相同

非同源受限制的行为：

• cookie localStorage indexDB无法获取
• DOM无法获得
• ajax请求不能发送

14.跨域方法

https://juejin.im/entry/59b8fb276fb9a00a42474a6f
https://blog.csdn.net/liangjielaoshi/article/details/83786388
1） 通过jsonp跨域（缺点：只能实现get一种请求）
2） document.domain + iframe跨域（主域相同，子域不同的跨域应用场景）
3） location.hash + iframe
4） window.name + iframe跨域
5） postMessage跨域
6） 跨域资源共享（CORS）
7） nginx代理跨域
8） nodejs中间件代理跨域
9） WebSocket协议跨域

15.TCP三次握手

client----->server:SYN(发起一个TCP连接，同步报文)
server----->client:SYN+ACK(应答报文，表示已创建连接)
client----->server:ACK(应答报文，表示收到已连接)

16.四次挥手

由客户端发起的关闭连接

• client----->server:FIN(请求关闭连接)
• server----->client:ACK(收到了连接，但不会立即关闭，等到报文都发送完再回复一个FIN)
• server----->client:FIN
• client----->server:ACK(收到关闭)

由服务端发起的关闭连接，当http设置了keepalive定时关闭，服务端会在结束数据传送后关闭TCP连接，SYN表示建立连接，FIN表示关闭连接，ACK表示响应，PSH表示有 DATA数据传输，RST表示连接重置

17.get/post区别

• 请求参数：get参数附在URL后面?隔开，POST参数放在包体中
• 大小限制：GET限制为2048字符，post无限制
• 安全问题：GET参数暴露在URL中，不如POST安全
• 浏览器历史记录：GET可以记录，POST无记录
• 缓存：GET可被缓存，post无
• 书签：GET可被收藏为书签，post不可
• 数据类型：GET只能ASCII码，post无限制

18.释放TCP连接

header中的connecton:close
服务器主动关闭TCP连接，客户端被动关闭连接
header中的connecton:keepalive
连接保持一段时间，可以连续发送http请求

19.客户端解析HTML

onload ready区别：
ready表示文档加载完毕，不包括图片
onload表示都加载完毕

20.打开一个网站会建立几次TCP连接？每次HTTP请求不需要重新建立TCP连接吗？

https://segmentfault.com/q/1010000011840551
在同一个页面中，请求比较多的话，可以打开HTTP KeepAlive, 复用连接，避免3次握手带来的开销。
HTTP2.0 进一步优化，通过多路复用技术，允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。也就是可以在在一次传输中发送多个css，js，图片等资源。
1、首先多个HTTP请求并不代表有多个TCP连接，当然这个场景下肯定会有多个TCP连接
2、在一个TCP连接上完成一个HTTP请求后，可以在利用这个TCP的连接在发HTTP请求
3、不用，只在第一次

21.HTTP协议的Keep-Alive 模式

https://www.jianshu.com/p/49551bda6619
因为HTTP 协议采用“请求-应答”模式，当使用普通模式，即非 Keep-Alive 模式时，每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（HTTP 协议为无连接的协议）；当使用 Keep-Alive 模式时，Keep-Alive 功能使客户端到服务器端的连接持续有效。

22.请列举三种禁止浏览器缓存的头字段, 并写出相应的设置值

Expires: 告诉浏览器把回送的资源缓存多长时间 -1或0则是不缓存
Cache-Control: no-cache
Pragma: no-cache

23.tcp/ip／http对应哪一层 七层模型

TCP/IP 四层协议: 应用层、传输层、网络互连层和主机到网络层. http对应应用层
ISO 七层模型: 物理层, 数据链路层, 网络层, 传输层, 会话层, 表示层, 应用层. http对应应用层

24.cookie和session的区别

cookie数据存放在客户的浏览器上，session数据放在服务器上。
cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
考虑到安全应当使用session。
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用COOKIE。
单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
所以建议是：
将登陆信息等重要信息存放为SESSION
其他信息如果需要保留，可以放在COOKIE中

25.浏览器输入url后发生了什么

26.性能优化

27. 浏览器本地存储与服务器端存储之间的区别

其实数据既可以在浏览器本地存储，也可以在服务器端存储。
浏览器端可以保存一些数据，需要的时候直接从本地获取，sessionStorage、localStorage和cookie都由浏览器存储在本地的数据。
服务器端也可以保存所有用户的所有数据，但需要的时候浏览器要向服务器请求数据。
1.服务器端可以保存用户的持久数据，如数据库和云存储将用户的大量数据保存在服务器端。
2.服务器端也可以保存用户的临时会话数据。服务器端的session机制，如jsp的 session 对象，数据保存在服务器上。实现上，服务器和浏览器之间仅需传递session id即可，服务器根据session id找到对应用户的session对象。会话数据仅在一段时间内有效，这个时间就是server端设置的session有效期。
服务器端保存所有的用户的数据，所以服务器端的开销较大，而浏览器端保存则把不同用户需要的数据分布保存在用户各自的浏览器中。
浏览器端一般只用来存储小数据，而服务器可以存储大数据或小数据。
服务器存储数据安全一些，浏览器只适合存储一般数据。