HTTP/HTTPS协议
一、请求报文
GET /index.html HTTP/1.1
HOST: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8,zh-CN;q=0.6,zh;q=0.4
Connection: keep-alive
POST /login HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 36
{"username": "123", "password": "123"}
1、请求方法
| 请求方法 | 说明 |
|---|---|
| GET | 向服务器请求指定资源（读） |
| POST | 向服务器提交数据，请求服务器进行处理（读写） |
| PUT | 向服务器提交文件 |
| HEAD | 获取头部信息（用于确认url有效性和资源更新时间等） |
| DELETE | 删除服务器上的文件 |
| OPTIONS | 查询目标资源支持的通信选项 |
| TRACE | 回显服务器收到的请求（主要用于测试和诊断） |
| CONNECT | 要求与代理服务器通信时建立隧道，实现用隧道协议进行TCP通信 |
GET和POST的区别：
1）GET参数包含在url中（长度受限），POST通过request body传递参数（长度不受限）
2）POST因为要通过request body传递参数，所以请求头部包含更多头部字段，例如content-type
3）POST先将请求头发给服务器，接收到服务器响应的100（Continue）后再将request body发给服务器，服务器接收后响应200（OK）
4）GET请求数据可缓存，POST请求数据不可缓存，所以与服务器交互时若选择使用POST方法请求数据，则每次刷新都会触发一次POST请求
2、版本
| HTTP版本 | 说明 |
|---|---|
| HTTP/0.9 | 只支持GET方法 |
| HTTP/1.0 | 增加了POST，HEAD方法 |
| HTTP/1.1 | 标准版本，增加了PUT方法并允许长连接 |
| HTTP/2.0 | 头部压缩，二进制格式传输（以前用ASCII码），多路复用 |
3、HTTP头部
使用key - value形式详细说明报文，主要分为四类：通用头、请求头、响应头和实体头。
1）通用头
提供与报文相关的基本信息，既可以出现在请求报文中，也可以出现在响应报文中。
| 字段名 | 说明 |
|---|---|
| CacheControl | 控制缓存的行为 |
| Connection | 允许客户端和服务端指定与请求/响应连接有关的选项 |
| Date | 创建报文的时间 |
| Pragma | 兼容1.0和1.1版本的缓存控制字段（类似CacheControl） |
| Transfer-Encoding | 告知接收端传输报文的编码方式 |
| Trailer | 报文末端的首部一览 |
| Upgrade | 用于检测HTTP协议及其他协议是否可使用更高的版本进行通信 |
| Via | 用于追踪客户端与服务器之间的请求和响应报文的传输路径 |
2）请求头
只在请求报文中有意义，用于说明客户端身份和信息，指明服务端地址。
| 字段名 | 说明 |
|---|---|
| Accept | 指明可接受媒体类型 |
| Accept-Charset | 指明可接受字符集 |
| Accept-Encoding | 指明可接受编码 |
| Accept-Language | 指明可接受语言 |
| Authorization | 授权认证信息 |
| From | 客户端电子邮箱地址 |
| Host | 服务器主机名和端口号 |
| If-Match | 如果实体标记与文档当前的实体标记相匹配，就获取这份文档 |
| If-None-Match | 如果提供的实体标记与当前文档的实体标记不相符，就获取文档 |
| If-Modified-Since | 除非在某个指定的日期之后资源被修改过，否则就限制这个请求 |
| If-Unmodified-Since | 除非在某个指定日期之后资源没有被修改过，否则就限制这个请求 |
| If-Range | 允许对文档某个范围进行条件查找 |
| Max-Forward | 将请求转发给其他代理或网关的最大次数 |
| Proxy-Authorization | 与Authorization首部相同，但这个首部实在与代理进行认证时使用 |
| Range | 如果服务器支持范围请求，就请求资源的指定范围 |
| Referer | 告知服务器当前网页链接源 |
| TE | 告诉服务器可以使用哪些扩展传输编码 |
| User-Agent | 将发起请求的应用程序名称告知服务器 |
| Cookie | HTTP请求发送时会把保存在该请求域名下的所有cookie值一起发送给服务器 |
3）响应头
| 字段名 | 说明 |
|---|---|
| Accept-Ranges | 对此资源来说，服务器可接受的范围类型 |
| Age | 响应持续时间 |
| ETag | 资源的匹配信息 |
| Location | 重定向客户端到指定资源位置 |
| Proxy-Authenticate | 代理认证信息 |
| Retry-After | 如果资源不可用，在此日期或时间重试 |
| Server | 服务器应用程序软件的名称和版本 |
| Vary | 代理服务器缓存的管理信息 |
| WWW-Authenticate | 客户端认证信息 |
| Set-Cookie | 发送cookie信息给客户端 |
4）实体头
| 字段名 | 说明 |
|---|---|
| Allow | 资源可支持的HTTP方法 |
| Content-Encoding | 实体主体适用的编码方式 |
| Content-Language | 实体主体的自然语言 |
| Content-Length | 实体主体的大小（单位：字节） |
| Content-Location | 替代对应资源的URI |
| Content-MD5 | 实体主体的报文摘要 |
| Content-Range | 实体主体的位置范围 |
| Content-Type | 实体主体的媒体类型 |
| Expires | 实体主体过期的日期时间 |
| Last-Modified | 资源的最后修改日期 |
二、响应报文
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 128
{"message": "hello world"}
1、状态码
| 状态码 | 类别 | 原因 |
|---|---|---|
| 1XX | 信息性状态码 | 接收的请求正在处理 |
| 2XX | 成功状态码 | 请求正常处理完毕 |
| 3XX | 重定向状态码 | 需要进行附加操作以完成请求 |
| 4XX | 客户端错误状态码 | 服务端无法处理请求 |
| 5XX | 服务端错误状态码 | 服务端处理请求出错 |
2、错误码
| 错误码 | 描述 | 说明 |
|---|---|---|
| 200 | OK | 表示服务端正常处理了客户端请求 |
| 204 | No Content | 无内容（服务器成功处理了请求但未返回内容） |
| 206 | Partial Content | 部分内容（服务器成功处理了部分GET请求） |
| 301 | Moved Permanently | 永久重定向，意思是本地请求的资源已经不存在，使用新的URI再次访问 |
| 302 | Found | 临时重定向，资源暂时还在，但是目前需要用另一个URI访问 |
| 303 | See Other | 与301类似，使用GET和POST请求查看 |
| 304 | Not Modified | 缓存控制，用于 If-Modified-Since 等条件请求，表示资源未修改，可以理解成重定向已到缓存的文件 |
| 307 | Temporary Redirect | 临时重定向，与302类似，使用GET请求重定向 |
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 表示发送的请求需要有通过HTTP认证的认证信息 |
| 403 | Forbidden | 服务器禁止访问资源（原因比如涉及到敏感词汇、法律禁止等） |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 503 | Service Unavailable | 服务器繁忙或不可用，暂时无法响应服务 |
三、Cookie技术
1、概述
由于HTTP属于无状态协议，每次请求都是独立的，对于服务端而言，每次客户端请求都是新的且未知的，而有些时候我们希望服务端能针对性的处理某些客户端的请求，因而诞生了Cookie技术。所谓Cookie技术实为让客户端向服务端发出请求时，携带之前从服务端获取的特定数据，以达到保存状态的效果。
2、应用
主要应用场景：
1）会话状态管理（例如用户登录状态、购物车等）
2）个性化设置（例如自定义设置、主题等）
3）浏览器行为跟踪（例如跟踪分析用户行为等）
目前Cookie技术主要用于会话状态管理，以用户登录-退出为例，Cookie的生命周期如下：
1）前端通过用户登录API向后端传递用户信息，后端核对与数据库信息是否匹配，匹配后在登录API返回头set-cookie中返回记录用户状态的Cookie值userToken
2）浏览器按照set-cookie指明的规则解析并存储收到的userToken信息
3）后续浏览器会自动将userToken加到满足条件（域名/路径）的API请求头Cookie中，这样服务端就知道之前登录过
4）如果退出登录，返回头的set-cookie会要求浏览器删除之前的userToken，后续客户端请求头的Cookie也就不会发送userToken
3、设置Cookie
服务端设置Cookie：
1）在服务端处理HTTP请求时，可以通过设置HTTP响应头中的Set-Cookie字段来发送Cookie信息给客户端
2）Set-Cookie响应头中可以包含多个Cookie，每个Cookie以分号隔开
3）Cookie中包含名称、值及其他属性（如过期时间、路径、域名等）
客户端设置Cookie：
1）客户端发送HTTP请求前从本地存储中读取Cookie信息
2）客户端将获取到的Cookie信息添加到HTTP请求头Cookie字段中
3）Cookie字段中包含服务端发送的Cookie信息，每个Cookie之间用分号隔开
1）Cookie前缀
Cookie前缀是一种在Cookie名称中携带信息的方式，它必须和某些属性同时出现，否则Cookie无法设置成功
| 名称 | 说明 |
|---|---|
| __Secure- | 必须同时设置Secure属性 |
| __Host- | 必须同时设置Path=/和Secure属性，且不能设置Domain属性 |
注：Secure属性设置后可以被人恶意移除，而Cookie名称被人移除前缀，服务器会拒绝该Cookie，从而更具安全性，所以即便设置了Secure属性还需要加上__Secure-前缀
2）Cookie键值对
Cookie键值对是真正携带信息的部分。注意键值对的值部分为非必填，如果有值则需要包含在双引号内（如果值不包含双引号，则会被视为多个键值对，而不是单个键值对）。大多数浏览器支持最大为 4KB 的 Cookie，4KB 是针对 Cookie 单条记录的 Value 值
3）Cookie属性
Cookie 属性可以理解为 Cookie 的配置项，告诉浏览器 Cookie 的一些额外信息，例如什么时候失效
| Cookie属性 | 说明 | 类型 | 默认值 | 示例 |
|---|---|---|---|---|
| Domain | 生效域名（哪些主机地址可以接收Cookie） | String | 当前访问地址中的host部分 | example.com |
| Path | 生效路径（主机下哪些路径可以接收Cookie） | String | / | /docs |
| Expires | 过期时间 | Date | 浏览器会话关闭时间 | Thu, 22 Jul 2021 00:53:13 GMT |
| Max_Age | 有效期（秒） | Number | 1000 | |
| Secure | 仅HTTPS可用 | 无值，出现即设置 | ||
| HttpOnly | 设置了HttpOnly属性的Cookie不能使用JS进行访问 | 无值，出现即设置 | ||
| SamSite | 允许服务器设定Cookie不跟随跨站请求一起发送 | String | Lax | 可能值：Lax、Strict、None |
| SameParty | 允许特定条件跨域共享Cookie | |||
| Priority | 优先级，仅Chrome支持 | Medium | 可能值：Low、Medium、High |
注：Domain限制了接收Cookie的域名，SameSite限制了发送Cookie的域名
4、Cookie的不安全事件
1）CSRF攻击
跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行
一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）
设置SamSite可以防止跨域发送Cookie，抵御CSRF
2）XSS攻击
XSS 攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并
执行攻击者恶意制造的网页程序。攻击成功后，攻击者可能得到 Cookie 从而实现攻击
四、HTTPS协议
HTTPS协议本质上是在HTTP协议基础上增加了一层SSL/TLS协议，以实现安全传输
HTTPS协议主要解决了以下三个问题：
1）身份安全性（避免第三方伪装成服务端与客户端通信）
2）数据安全性（传输过程中数据被加密，第三方即使截获数据也无法得知数据的真实内容）
3）数据完整性（避免数据被传输过程中被篡改）
SSL/TLS握手
注意： HTTPS协议中同时使用了对称加密和非对称加密，下面的叙述中我们将最终用于加密通信数据的对称加密密钥称为工作密钥（关于SSL/TLS握手的讲解要求读者对对称加密、非对称加密、数字证书等概念有基本了解）
SSL握手过程包含了证书认证和工作密钥协商，其解决了身份安全性和数据安全性两大问题，由于工作密钥确认以后只有客户端和服务端知晓且工作密钥唯一，数据传输过程中数据已经被加密，第三方劫持数据后无法解密数据，因而避免了通信数据被篡改，也就解决了数据完整性问题，具体的握手流程如下：
1）客户端发送SSL协议版本号、客户端随机数（R1）给服务端，同时告知服务端当前客户端支持的加密套件（包含密钥交换算法、对称加密算法和摘要算法）
2）服务端响应客户端，反馈双方都支持的加密套件，并给出服务端数字证书及服务端随机数（R2）
3）客户端验证数字证书有效性，详细流程如下：
-
获取数字证书中的有效期、所有者等信息进行校验
-
获取数字证书中的CA（证书颁发机构）信息与系统内置的受信CA进行匹配，确认证书CA合法性
-
客户端依据协商的加密套件对证书信息生成摘要，获取服务端公钥对证书签名（服务端对证书信息的摘要通过私钥加密生成的数据称为证书签名）进行解密，将解密后的摘要与客户端自己生成的摘要进行比对，确认证书有效性
4）客户端生成随机数（R3）并通过公钥加密后发送给服务端
5）服务端使用私钥解密接收到的随机数R3
6）服务端和客户端依据之前协商好的加密套件使用握手流程中生成的三个随机数（R1、R2、R3）生成工作密钥，后续通信过程中客户端和服务端都依据协商好的加密套件中的对称加密算法，使用工作密钥对通信数据进行加密
Reference
https://blog.csdn.net/new9232/article/details/128500110
https://zhuanlan.zhihu.com/p/45173862
https://www.cnblogs.com/an-wen/p/11180076.html
https://zhuanlan.zhihu.com/p/275695831
https://zhuanlan.zhihu.com/p/481603665
https://zhuanlan.zhihu.com/p/27395037
https://zhuanlan.zhihu.com/p/108031456
https://blog.csdn.net/gx11251143/article/details/104360375
