应用层汇总

HTTP 头部包含哪些信息：三颗星

HTTP 头部本质上是一个传递额外重要信息的键值对。主要分为：通用头部，请求头部，响应头部和实体头部。实体头部：请求/响应报文中实体部分的首部；

通用头：是客户端和服务器都可以使用的头部，可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能，如Date头部。
请求头：是请求报文特有的，它们为服务器提供了一些额外信息，比如客户端希望接收什么类型的数据，如Accept头部。
响应头：便于客户端提供信息，比如，客服端在与哪种类型的服务器进行交互，如Server头部。
实体头：指的是用于应对实体主体部分的头部，比如，可以用实体头部来说明实体主体部分的数据类型，如Content-Type头部。

Keep-Alive 和非 Keep-Alive 区别，对服务器性能有影响吗：三颗星

在早期的 HTTP/1.0 中，浏览器每次 发起 HTTP 请求都要与服务器创建一个新的 TCP 连接，服务器完成请求处理后立即断开 TCP 连接，服务器不跟踪每个客户也不记录过去的请求。然而创建和关闭连接的过程需要消耗资源和时间，为了减少资源消耗，缩短响应时间，就需要重用连接。在 HTTP/1.1 版本中默认使用持久连接，在此之前的 HTTP 版本的默认连接都是使用非持久连接，如果想要在旧版本的 HTTP 协议上维持持久连接，则需要指定 connection 的首部字段的值为 Keep-Alive 来告诉对方这个请求响应完成后不要关闭，下一次咱们还用这个请求继续交流，

对于非 Keep-Alive 来说，必须为每一个请求的对象建立和维护一个全新的连接。对于每一个这样的连接，客户机和服务器都要分配 TCP 的缓冲区和变量，这给服务器带来的严重的负担，因为一台 Web 服务器可能同时服务于数以百计的客户机请求。在 Keep-Alive 方式下，服务器在响应后保持该 TCP 连接打开，在同一个客户机与服务器之间的后续请求和响应报文可通过相同的连接进行传送。甚至位于同一台服务器的多个 Web 页面在从该服务器发送给同一个客户机时，可以在单个持久 TCP 连接上进行。

然而，Keep-Alive 并不是没有缺点的，当长时间的保持 TCP 连接时容易导致系统资源被无效占用，若对 Keep-Alive 模式配置不当，将有可能比非 Keep-Alive 模式带来的损失更大。因此，我们需要正确地设置 keep-alive timeout 参数，当 TCP 连接在传送完最后一个 HTTP 响应，该连接会保持 keepalive_timeout 秒，之后就开始关闭这个链接。

这就好想一个拉肚子的人，需要频繁的使用坑，但是是也会有很多时候，占着茅坑不拉屎

HTTP 长连接短连接使用场景是什么：三个星

HTTP准确来说是应用层协议，连接是在针对传输层而言的，实际应该是HTTP请求或HTTP响应，发起请求通过TCP连接传送请求。
长连接：多用于频繁操作，客户端连接数目较少；持续存在的连接便于频繁的数据交换
短连接：用户数目较多的web网站。

客户端较多的Web网站，若采用长连接，虽然每个客户端只对应一个连接，但有大量的客户端，这样在同一时刻便会有大量的连接存在，从而占用服务端大量的资源；而采用短连接，虽然每个请求就对应一个连接，但这些请求转瞬即逝，因此在同一时刻存在的连接不会比长连接模式多，因此在这种情况下短连接比长连接优。

需要区分TCP长连接和HTTP长连接
HTTP长连接通过Client和Server的一些关闭策略实现
TCP长连接是通过HTTP1.1头部信息KeepAlive实现

应该看是什么形式的吧，感觉文本应该是TCP，视频之类的才是UDP

怎么知道 HTTP 的报文长度：两个星

响应报文是发给客户端看的啊，服务器肯定知道有多少字节，但是在响应报文中有两种表现形式。

    对于小点的文件，直接给出 content-length,也就是本次返回的数据长度
    对于大文件，使用 Transfer-Encoding:chunked 字段，不传输数据长度，客户端只知道是分组传输，这也是订好了协议，客户端收到了会进行组装。然后给一个分组传输编码规则的图

意思就是服务器本身是否知道内容大小, 知道就在响应中返回Content-Length, 否则将内容分块进行发送, 这时候就不知道了。服务器知道长度就返回在响应报文的conten length；不知道就分块传输，最后一个块长度为0；