HTTP的特点和缺点
特点：无连接、无状态、灵活、简单快速
- 无连接：每一次请求都要连接一次，请求结束就会断掉，不会保持连接。
- 无状态：每一次请求都是独立的，请求结束不会记录连接的任何信息，减少了网络开销。
- 灵活：通过HTTP协议中头部的Content-Type标记，可以传输任意数据类型的数据对象（文本、图片、视频等），非常灵活
- 简单快速：发送请求访问某个资源时，只需要传送请求方法和URL就可以了，使用简单，正由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快
缺点：无状态、不安全、明文传输、队头阻塞
- 无状态：请求不会记录任何连接信息，没有记忆，就无法区分多个请求发起者身份是不是同一个客户端，意味着后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据增大
- 不安全：明文传输可能被窃听不安全，缺少身份认证也可能遭遇伪装，还有缺少报文完整性验证可能遭到篡改
- 明文传输：报文使用是明文，直接将信息暴露给外界，WIFI陷阱就是复用明文传输的特点，诱导你连上热点，然后疯狂抓取你的流量，从而拿到你的敏感信息
- 队头阻塞：开启长连接时，只建立一个tcp连接，同一个时刻只能处理一个请求，那么当请求耗时过长时，其他请求就只能是阻塞状态
HTTP报文组成部分
HTTP报文由请求报文和响应报文组成
请求报文：由请求行、请求头、空行、请求体四部分组成
响应报文：由状态行、响应头、空行、响应体四部分组成
- 请求行：包含HTTP方法，请求地址，HTTP协议以及版本
- 请求头/响应头：一些key:value，来告诉服务端我要哪些内容
- 空行：用来区分首部和实体，因为请求头都是key:value的格式，当解析遇到空行时，服务端就知道下一个不再是请求头部分，就该当作请求体来解析了
- 请求体：请求的参数
- 状态行：包含HTTP协议及版本、数据状态码、状态码英文名称
- 响应体：服务端返回的数据
HTTP请求方法（9种）
| 方法 | 描述 |
|---|---|
| GET | 获取资源 |
| POST | 传输资源，通常会造成服务器资源的修改 |
| HEAD | 获取报文首部 |
| PUT | 更新资源 |
| PATCH | 对PUT的补充，对已知资源部分更新 |
| DELETE | 删除资源 |
| OPTIONS | 列出请求资源支持的请求方法，用来跨域请求 |
| TRACE | 追踪请求/响应路径，用于测试或者诊断 |
| CONNECT | 将连接改为管道方式用于代理服务器 |
GET和POST的区别
- GET提交数据会放在URL之后，POST提交数据是放在body上。
- GET 只支持 ASCII 字符格式的参数，而 POST 方法没有限制。
- GET方法具有幂等性，POST方法不具有。
常见HTTP状态码
1xx：指示信息——表示请求已接收，继续处理
2xx：成功——表示请求已被成功接收
3xx：重定向——表示要完成请求必须进行进一步操作
4xx：客户端错误——表示请求有语法错误或者请求无法实现
5xx：服务端错误——表示服务器未能实现合法的请求
常见状态码：
| 状态码 | 描述 |
|---|---|
| 200 | 请求成功 |
| 206 | 已经完成指定范围的请求（带Range头的GET请求），场景如video、audio播放文件较大，文件分片是 |
| 301 | 永久重定向 |
| 302 | 临时重定向 |
| 304 | 请求资源未修改，可以使用缓存的资源，不用在服务器取 |
| 400 | 请求有语法错误 |
| 401 | 没有权限访问 |
| 403 | 服务器拒绝执行请求，场景如不允许直接访问，只能通过服务器访问时 |
| 404 | 请求资源不存在 |
| 500 | 服务器内部错误，无法完成请求 |
| 503 | 请求未完成，因服务器过载、宕机或维护等 |
连接管理
长连接与短连接
当打开客户端时，客户端会发送很多个HTTP请求，如果每个请求就新建一个tcp连接，对客户端和服务器的压力是很大的。
而长连接就是建立一次tcp连接后便能进行多次HTTP通信，从而节省了tcp连接释放的开销。短连接是每个HTTP请求就会建立一次tcp连接
从HTTP/1.1开始默认是长连接，如果要关闭需要在首部设置“Connection:close”；1.1之前默认是短连接，开启长连接需要设置“Connection: Keep-Alive”。
流水线
默认情况下，HTTP请求是按照顺序发出的，下一个请求只有在当前请求收到响应之后才会发出。由于受到网络因素的影响，下一个请求发出前，可能需要等待很长时间，而流水线是在同一条长连接上连续发出请求，而不用等待响应返回，这样HTTP的速度回快很多，tcp连接的利用率也会高很多。
无状态和cookie
HTTP是一种不保存状态，即无状态协议，HTTP协议自身不对请求和响应之间的通信状态进行保存，也就是HTTP协议对于发送的请求和接受的请求都不做持久化处理，这样可以更快地处理大量事物，确保协议的可伸缩新。
HTTP不保存状态，那么服务端是如果知道请求是那个客户端发送过来的呢？
seesion的形式
- 客户端第一次发送信息到服务器是，服务器为该客户端创建一个session对象，该session包含客户端身份信息，同时为该session生成一个id。
- 服务端将这个id分配给客户端，客户端发送请求时带有此id，服务端就可以区分客户端。
cookie的形式
- 客户端第一次发送信息到服务器时，服务器根据该客户端信息编码加密生成一个cookie。
- 服务端将此cookie发送给客户端，客户端发送请求时带有此cookie，服务端就可以区分客户端。
cookie首部信息
| Name | cookie变量的名字 |
|---|---|
| value | cookie变量的值 |
| domain | 域 |
| path | 域中与cookie相关的路径前缀 |
| expires/max-age | 过期时间/最大存活时间 |
| size | cookie的大小 |
| httpOnly | 值为true/false；限制Cookie只能通过HTTP或HTTPS协议传输，禁止被JavaScript脚本访问 |
| secure | 是否只有在使用ssl连接时才发送这个cookie |
| sameParty | 允许网站指示允许在所有祖先框架属于同一第一方集的上下文中设置或者发送哪些cookie |
| partitionKey | 允许开发人员选择将cookie加入‘分区’存储，每个顶级站点都有一个单独的cookie jar |
| priority | Chrome浏览器规范。cookie优先级，当cookie超出每个域的cookie容量时，优先删除优先级较低的cookie。 |
cookie和session的区别
session方案需要在服务端储存客户端的数据，分布式服务器需要设置单独且唯一的数据中，用资源较大。但是客户端携带的id不包含用户信息，较为安全。
cookie的解决方案不需要在服务器储存客户端的数据，占用资源较小，可拓展性较高；请求携带的cookie含有用户信息，相对没有那么安全；从数据量上看，cookie一般都比session的id大，传输过程中占用较大资源。
http与https
http使用过程中存在安全性问题
- 使用明文通信，内容可能会被窃听
- 不验证通信方的身份，通信方的身份有可能遭遇伪装
- 无法证明报文的完整性，报文有可能遭篡改。
所以引入了https，通过ssl/tls的方式使http变成了安全的https
https发送数据时，request通过ssl/tls层进行处理，然后再通过tcp进行发送；数据接收时，同样也是通过ssl/tls进行处理。相当于在应用层http和传输层tcp之间加多了一层处理。
https是如何处理这些安全问题
- 数据加密
- 数字证书认证
- 通过ssl/tls报文摘要功能检验报文完整性
数据加密
加密方式有两种：对称和非对称
https的数据加密分别利用了这两种加密方式的优点。首先通过非对称加密，传输对称加密所需的密钥，然后使用密钥进行通信加密。这样兼顾了安全性，又有更高的运算速度。这个流程看似完美，但是过程中第一步发送方获取的公开密钥可能被篡改。所以就需要通过数字证书的方式来解决这个问题。
数字证书认证
数字证书认证机构是客户端和服务器双方都信任的第三方机构
- 服务器事先向数字证书机构申请数字证书，数字证书机构对数据做数字签名，然后将数据和数字签名打包在一起，做成数字证书，发送给服务器。
- https通信是，服务器把数字证书发送给客户端。客户端取得其中的数据和数字签名，使用数字证书机构的公开密钥验证数据和数字签名是否合法。
这里数字证书机构的公开密钥不是通过网络获取，而是事先在浏览器内部植入的。浏览器事先会植入常用认证机构的公开密钥。
数字证书中数据可以包含很多信息。比如：服务端的身份信息，可以非对称加密的公开密钥等等
通过这种放松，即能验证通信方身份，也可以实现安全加密。
完整性验证
通过ssl/tls报文摘要功能检验报文完整性
http提供了MD5报文摘要功能，但不是安全的。因为MD5报文摘要的值也是可以被篡改的
https的报文摘要功能之所以安全，是因为它结合了加密和认证这两个操作；加密+摘要检验+认证=数据完整
http和https的区别
http：免费、速度稍快、默认端口80、通信不安全
https：收费、速度稍慢、默认端口443、通信安全
