大数据与会计个人简历：拿下计网的这些协议后 我就是最靓的仔
大数据与会计个人简历：拿下计网的这些协议后 我就是最靓的仔接下来客户端每次向同一个网站发送请求时，请求头都会带上该 Cookie信息（包含 sessionId ）， 然后，服务器通过读取请求头中的 Cookie 信息，获取名称为 JSESSIONID 的值，得到此次请求的 sessionId。服务器第一次接收到请求时，开辟了一块 Session 空间（创建了Session对象），同时生成一个 sessionId ，并通过响应头的 **Set-Cookie：JSESSIONID=XXXXXXX **命令，向客户端发送要求设置 Cookie 的响应； 客户端收到响应后，在本机客户端设置了一个 **JSESSIONID=XXXXXXX **的 Cookie 信息，该 Cookie 的过期时间为浏览器会话结束；GET /some/page.html HTTP/1.1 响应报文：HTTP/1.1 200 OK Cookie 和 SessionHTTP 协议
这幅图需要注意一下，如果使用 GET 方法，是没有实体体的，如果你使用的是 POST 方法，才会有实体体。当用户提交表单时，HTTP 客户端通常使用 POST 方法；与此相反，HTML 表单的获取通常使用 GET 方法。HEAD 方法类似于 GET 方法，只不过 HEAD 方法不会返回对象。
下面我们来看一下 HTTP 响应报文
可以看到，请求报文和响应报文只有请求头是不同的，其他信息均一致。
请求报文请求行：
GET /some/page.html HTTP/1.1
响应报文：
HTTP/1.1 200 OK
Cookie 和 Session
HTTP 协议是一种无状态协议，即每次服务端接收到客户端的请求时，都是一个全新的请求，服务器并不知道客户端的历史请求记录；Session 和 Cookie 的主要目的就是为了弥补 HTTP 的无状态特性。
Session 是什么客户端请求服务端，服务端会为这次请求开辟一块内存空间，这个对象便是 Session 对象，存储结构为 ConcurrentHashMap。Session 弥补了 HTTP 无状态特性，服务器可以利用 Session 存储客户端在同一个会话期间的一些操作记录。
Session 如何判断是否是同一会话服务器第一次接收到请求时，开辟了一块 Session 空间（创建了Session对象），同时生成一个 sessionId ，并通过响应头的 **Set-Cookie：JSESSIONID=XXXXXXX **命令，向客户端发送要求设置 Cookie 的响应； 客户端收到响应后，在本机客户端设置了一个 **JSESSIONID=XXXXXXX **的 Cookie 信息，该 Cookie 的过期时间为浏览器会话结束；
接下来客户端每次向同一个网站发送请求时，请求头都会带上该 Cookie信息（包含 sessionId ）， 然后，服务器通过读取请求头中的 Cookie 信息，获取名称为 JSESSIONID 的值，得到此次请求的 sessionId。
Session 的缺点Session 机制有个缺点，比如 A 服务器存储了 Session，就是做了负载均衡后，假如一段时间内 A 的访问量激增，会转发到 B 进行访问，但是 B 服务器并没有存储 A 的 Session，会导致 Session 的失效。
Cookies 是什么HTTP 协议中的 Cookie 包括 Web Cookie 和浏览器 Cookie，它是服务器发送到 Web 浏览器的一小块数据。服务器发送到浏览器的 Cookie，浏览器会进行存储，并与下一个请求一起发送到服务器。通常，它用于判断两个请求是否来自于同一个浏览器，例如用户保持登录状态。
HTTP Cookie 机制是 HTTP 协议无状态的一种补充和改良
Cookie 主要用于下面三个目的
- 会话管理
登陆、购物车、游戏得分或者服务器应该记住的其他内容
- 个性化
用户偏好、主题或者其他设置
- 追踪
记录和分析用户行为
Cookie 曾经用于一般的客户端存储。虽然这是合法的，因为它们是在客户端上存储数据的唯一方法，但如今建议使用现代存储 API。Cookie 随每个请求一起发送，因此它们可能会降低性能（尤其是对于移动数据连接而言）。
创建 Cookie当接收到客户端发出的 HTTP 请求时，服务器可以发送带有响应的 Set-Cookie 标头，Cookie 通常由浏览器存储，然后将 Cookie 与 HTTP 标头一同向服务器发出请求。
Set-Cookie 和 Cookie 标头Set-Cookie HTTP 响应标头将 cookie 从服务器发送到用户代理。下面是一个发送 Cookie 的例子
此标头告诉客户端存储 Cookie
现在，随着对服务器的每个新请求，浏览器将使用 Cookie 头将所有以前存储的 Cookie 发送回服务器。
有两种类型的 Cookies，一种是 Session Cookies，一种是 Persistent Cookies，如果 Cookie 不包含到期日期，则将其视为会话 Cookie。会话 Cookie 存储在内存中，永远不会写入磁盘，当浏览器关闭时，此后 Cookie 将永久丢失。如果 Cookie 包含有效期 ，则将其视为持久性 Cookie。在到期指定的日期，Cookie 将从磁盘中删除。
还有一种是 Cookie的 Secure 和 HttpOnly 标记，下面依次来介绍一下
会话 Cookies上面的示例创建的是会话 Cookie ，会话 Cookie 有个特征，客户端关闭时 Cookie 会删除，因为它没有指定Expires 或 Max-Age指令。
但是，Web 浏览器可能会使用会话还原，这会使大多数会话 Cookie 保持永久状态，就像从未关闭过浏览器一样。
永久性 Cookies永久性 Cookie 不会在客户端关闭时过期，而是在特定日期（Expires）或特定时间长度（Max-Age）外过期。例如
Set-Cookie: id=a3fWa; Expires=Wed 21 Oct 2015 07:28:00 GMT;
对 Cookie 的争论
尽管 Cookie 能够简化用户的网络活动，但是 Cookie 的使用存在争议，因为不少人认为它对用户是一种侵权行为。因为结合 Cookie 和用户提供的账户信息，Web 站点可以知道更多关于用户的信息。
Web 缓存Web 缓存(Web cache) 也叫做 代理服务器(proxy server)，它是代表 HTTP 服务器来满足用户需求的网络实体。Web 缓存器有自己的磁盘存储空间，并会在存储空间内保存最近请求过的对象，如下图所示
Web 缓存可以在用户的浏览器中进行配置，一旦配置后，用户首先访问的就不是初始服务器了，需要先访问代理服务器判断请求的对象是否存在，如果代理服务器没有，再由代理服务器来请求初始服务器把对象返回给客户，同时在自己的磁盘空间保存对象。
这里需要注意，客户和初始服务器的架构是 客户-服务器模式，而代理服务器不仅能当服务器使用，也可以当作客户端使用。
代理服务器一般由 ISP(Internet Service Provider)，提供。注意不是老色批。。。ISP 也就是我们常说的运营商，你懂的。
那么为什么需要代理服务器的存在呢？相信你看完上面的描述应该能大致猜到它的作用。
- 首先，代理服务器可以大大减少对客户请求的响应时间，能够更快给用户响应。
- 其次，代理服务器可以减少一个机构接入链路到网络的通信量，降低网络带宽，降低运营商成本。
- 然后，代理服务器可以分担初始服务器的压力，改善应用程序的性能。
通过上面的描述我们知道 HTTP 是可以传输普通文件、音频、视频的，这些传输的信息统称为 MIME 类型。HTTP 在传递视频中，也只是把视频当作对象来传输，而一个对象其实就是一个文件，一个文件都在 HTTP 中都可以用 URL 来表示。当用户在看视频时，客户与服务器建立一个 TCP 连接并发送对该 URL 的 GET 请求，然后服务器响应给客户端时，客户端会缓存一定量的字节数据，当数据超过预先设定的门限时，客户应用程序就开始播放视频。
这种方式有一种局限性就是对每个客户端来说，尽管每个客户端可用的带宽量不同，但所有客户端都收到相同的视频编码。这就造成带宽浪费。这就相当我是一个 2兆的网络和 50 兆的光纤都能收到相同的视频编码，以几乎相同的等待时间开始播放视频，那么我为什么还要花 50 兆光纤的钱呢？
为了改善这一现象，出现了 HTTP 的 DASH，DASH 即 Dynamic Adaptive Streaming HTTP，动态适应流。它的理念是针对不同流量的网络来说，所能够传输的比特数据也不相同。DASH 允许客户使用不同的因特网传输速率可以播放不同编码速率的视频。对于 3G 用户和光纤用户自然会选择以不同的速率传输比特数据，从而最大限度的使用带宽。
CDN随着互联网的接入用户变得越来越多，视频逐渐成为了比特传输的瓶颈和用户的强烈需求。作为一个因特网视频公司，最一开始提供流式服务最直接的方式是建立单一的大规模数据中心。在数据中心内缓存所有视频，并直接从数据中心向世界范围内传播视频。但是这种方式存在三种问题
- 如果客户远离数据中心，那么服务器到客户分组会跨越许多通信链路并且可能通过许多 ISP，这样你的视频播放能快到哪去？
- 每次视频数据都会重新传递给客户端，这样会严重浪费网络带宽，而且视频公司会支付重复的带宽费用
- 单点故障问题，只要视频数据中心宕机或者其他事故，直接导致全球范围内的视频无法播放。
为了应对能够向全世界的用户 24 小时不间断的分发视频，几乎所有的主流视频公司都会使用 内容分发网(Content Distribution Network CDN) 。CDN 管理分布在多个地理位置上的服务器，在每个服务器上缓存各种视频、音频、文件等。
CDN 内容选择策略CDN 管理分布在多个地理位置上的服务器，在它的服务器上存储视频副本，并且所有试图将每个用户请求定向到一个提供最好用户体验的 CDN 位置。那么服务器如何选址呢？事实上有两种服务器安置原则
- 深入，它的主要目标是靠近用户，通过减少端用户和 CDN 集群之间链路和路由器的数量，从而改善了用户感受的时延和吞吐量。
- 邀请做客，这个原则是通过在少量（例如 10 个）关键位置建造大集群来邀请 ISP 来做客，与深入设计原则相比，邀请做客设计通常产生较低的维护和管理开销。
CDN 可以是专用 CDN(private CDN) 即它由内容提供商自己所拥有；另一种 CDN 是 第三方 CDN(third-party CDN)，它代表多个内容提供商分发内容。
下面我们来聊一下 CDN 工作流程，如下图所示
