浅谈HTTP协议包

我们知道http包主要分为三个部分：

1、请求行

请求方法，GET和POST是最常见的HTTP方法，除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。
URL地址，它和报文头的Host属性组成完整的请求URL。
协议名称及版本号。

2、请求头（hearder）

Accept：指定客户端能够接收的内容类型，可以是文本、图片、视频类型。
Accept-Encoding：指定浏览器支持接收的数据格式，有gzip、br等类型
Accept-Language：执行接收语言，基本上位en、zh
Accept-Charset：指定编码,一般为utf-8
Content-Length：请求的内容长度
Cookie：用来存储一些用户信息以便让服务器辨别用户身份的（大多数需要登录的网站上面会比较常见），比如cookie会存储一些用户的用户名和密码，当用户登录后就会在客户端产生一个cookie来存储相关信息，这样浏览器通过读取cookie的信息去服务器上验证并通过后会判定你是合法用户，从而允许查看相应网页。
Host：指定请求的服务器的域名和端口号
Origin:请求源
Referer: 表示具体在请求源那个网页请求的
User-Agent：告诉HTTP服务器，客户端使用的操作系统和浏览器的名称和版本，内容包含发出请求的用户信息。
Connection:表示连接状态如何，一般的如果就是打开某个页面，，但是要传输数据，比如播放视频等等就要保持tcp连接不关闭，所以要用到keep-alive（长连接）。以前用到的是短连接close。
Sec-Fetch-Dest：表示请求的目的地，即如何使用获取的数据；

Sec-Fetch-Mode：

cors：跨域请求；XMLHttpRequest 或 Fetch 支持跨源请求。
no-cors：并不是代表请求不跨域，而是服务端不设置cors响应头，图片/脚本/样式表这些请求是容许跨域且不用设置跨域响应头的情况使用。
same-origin：同源请求， 表示不跨境，跟cors跟no-cors不一样，cors跟no-cors是要求服务端设置。
navigate：表示这是一个浏览器的页面切换请求(request)。 navigate请求仅在浏览器切换页面时创建，该请求应该返回HTML；
websocket：建立websocket连接；

Sec-Fetch-Site：

cross-site：跨域请求；
same-origin：发起和目标站点源完全一致；
same-site：有几种判定情况，详见说明；
none：如果用户直接触发页面导航，例如在浏览器地址栏中输入地址，点击书签跳转等，就会设置none；

3、响应行

协议名称及版本号

状态码及描述

1**	信息，服务器收到请求，需要请求者继续执行操作
2**	成功，操作被成功接收并处理
3**	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误
200 - 请求成功
301 - 资源（网页等）被永久转移到其它URL
404 - 请求的资源（网页等）不存在
500 - 内部服务器错误

4、响应头

Access-Control-Allow-Credentials：设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。指示是否可以使用凭证进行实际请求。
Access-Control-Expose-Headers：
Access-Control-Allow-Methods: 请求方式
Access-Control-Allow-Origin：对于不需具备凭证（credentials）的请求，服务器会以“*”作为通配符，从而允许所有域都具有访问资源的权限。
```
如需允许所有资源都可以访问您的资源，您可以如此设置：
Access-Control-Allow-Origin: *
如需允许https://developer.mozilla.org访问您的资源，您可以设置：
Access-Control-Allow-Origin: https://developer.mozilla.org
```
- Content-Length:返回的字节大小
- Age：消息头里包含对象在缓存代理中存贮的时长
- Date：时间
- Set-Cookie：设置和页面关联的Cookie，将cookie信息从新发给客户端

Cookie

因为 HTTP 协议是无状态的，即服务器不知道用户上一次做了什么，这严重阻碍了交互式 Web 应用程序的实现。在典型的网上购物场景中，用户浏览了几个页面，买了一盒饼干和两瓶饮料。最后结帐时，由于 HTTP 的无状态性，不通过额外的手段，服务器并不知道用户到底买了什么，所以 Cookie 就是用来绕开 HTTP 的无状态性的“额外手段”之一。服务器可以设置或读取 Cookies 中包含的信息，借此维护用户跟服务器会话中的状态。

在刚才的购物场景中，当用户选购了第一项商品，服务器在向用户发送网页的同时，还发送了一段 Cookie，记录着那项商品的信息。当用户访问另一个页面，浏览器会把 Cookie 发送给服务器，于是服务器知道他之前选购了什么。用户继续选购饮料，服务器就在原来那段 Cookie 里追加新的商品信息。结帐时，服务器读取发送来的 Cookie 即可。

Cookie 另一个典型的应用是当登录一个网站时，网站往往会请求用户输入用户名和密码，并且用户可以勾选“下次自动登录”。如果勾选了，那么下次访问同一网站时，用户会发现没输入用户名和密码就已经登录了。这正是因为前一次登录时，服务器发送了包含登录凭据（用户名加密码的某种加密形式）的 Cookie 到用户的硬盘上。第二次登录时，如果该 Cookie 尚未到期，浏览器会发送该 Cookie，服务器验证凭据，于是不必输入用户名和密码就让用户登录了。

session

但问题是，我们也知道现在的很多网站功能很复杂，而且涉及很多的数据交互，比如说电商网站的购物车功能，信息量大，而且结构也比较复杂，无法通过简单的 cookie 机制传递这么多信息，而且要知道 cookie 字段是存储在 HTTP header 中的，就算能够承载这些信息，也会消耗很多的带宽，比较消耗网络资源。
session 就可以配合 cookie 解决这一问题，比如说一个 cookie 存储这样一个变量 sessionID=xxxx，仅仅把这一个 cookie 传给服务器，然后服务器通过这个 ID 找到对应的 session，这个 session 是一个数据结构，里面存储着该用户的购物车等详细信息，服务器可以通过这些信息返回该用户的定制化网页，有效解决了追踪用户的问题。
session 是一个数据结构，由网站的开发者设计，所以可以承载各种数据，只要客户端的 cookie 传来一个唯一的 session ID，服务器就可以找到对应的 session，认出这个客户。
当然，由于 session 存储在服务器中，肯定会消耗服务器的资源，所以 session 一般都会有一个过期时间，服务器一般会定期检查并删除过期的 session，如果后来该用户再次访问服务器，可能就会面临重新登录等等措施，然后服务器新建一个 session，将 session ID 通过 cookie 的形式传送给客户端。