7. 对 Accept 系列字段了解多少？

要保留状态信息。

HTTP 缺点

无状态

所谓的优点和缺点还是要分场景来看的，对于 HTTP 而言，最具争议的地方在于它的无状态。

在需要长连接的场景中，需要保存大量的上下文信息，以免传输大量重复的信息，那么这时候无状态就是 http 的缺点了。

但与此同时，另外一些应用仅仅只是为了获取一些数据，不需要保存连接上下文信息，无状态反而减少了网络开销，成为了 http 的优点。

明文传输

即协议里的报文(主要指的是头部)不使用二进制数据，而是文本形式。

这当然对于调试提供了便利，但同时也让 HTTP 的报文信息暴露给了外界，给攻击者也提供了便利。

WIFI陷阱就是利用 HTTP 明文传输的缺点，诱导你连上热点，然后疯狂抓你所有的流量，从而拿到你的敏感信息。

队头阻塞问题

当 http 开启长连接时，共用一个 TCP 连接，同一时刻只能处理一个请求，那么当前请求耗时过长的情况下，其它的请求只能处于阻塞状态，也就是著名的队头阻塞问题。接下来会有一小节讨论这个问题。

1. 对 Accept 系列字段了解多少？

对于Accept系列字段的介绍分为四个部分: 数据格式、压缩方式、支持语言和字符集。

数据格式

HTTP 灵活的特性，它支持非常多的数据格式，那么这么多格式的数据一起到达客户端，客户端怎么知道它的格式呢？

当然，最低效的方式是直接猜，有没有更好的方式呢？直接指定可以吗？

答案是肯定的。不过首先需要介绍一个标准——MIME(Multipurpose Internet Mail Extensions, 多用途互联网邮件扩展)。它首先用在电子邮件系统中，让邮件可以发任意类型的数据，这对于 HTTP 来说也是

通用的。

因此，HTTP 从MIME type取了一部分来标记报文 body 部分的数据类型，这些类型体现在Content- Type这个字段，当然这是针对于发送端而言，接收端想要收到特定类型的数据，也可以用Accept字

段。

具体而言，这两个字段的取值可以分为下面几类:

压缩方式

当然一般这些数据都是会进行编码压缩的，采取什么样的压缩方式就体现在了发送方的Content- Encoding字段上，同样的，接收什么样的压缩方式体现在了接受方的Accept-Encoding字段上。这个

字段的取值有下面几种：

gzip: 当今最流行的压缩格式 deflate: 另外一种著名的压缩格式

br: 一种专门为 HTTP 发明的压缩算法

// 发送端 Content-Encoding: gzip

// 接收端 Accept-Encoding: gzip

支持语言

对于发送方而言，还有一个Content-Language字段，在需要实现国际化的方案当中，可以用来指定支持的语言，在接受方对应的字段为Accept-Language。如:

// 发送端 Content-Language: zh-CN, zh, en

// 接收端 Accept-Language: zh-CN, zh, en

字符集

最后是一个比较特殊的字段, 在接收端对应为Accept-Charset，指定可以接受的字符集，而在发送端并没有对应的Content-Charset, 而是直接放在了Content-Type中，以charset属性指定。如:

// 发送端 Content-Type: text/html; charset=utf-8

// 接收端 Accept-Charset: charset=utf-8

最后以一张图来总结一下吧: