http响应头中的ETag是如何生成的
关于 etag 的生成需要满足几个条件，至少是宽松满足
- 当文件更改时，
etag值必须改变。 - 尽量便于计算，不会特别耗 CPU。这样子利用摘要算法生成 (MD5, SHA128, SHA256) 需要慎重考虑，因为他们是 CPU 密集型运算
- 必须横向扩展，分布式部署时多个服务器节点上生成的
etag值保持一致。这样子inode就排除了
关于服务器中 etag 如何生成可以参考 HTTP: Generating ETag Header
nginx 中 ETag 的生成
nginx中的Tage的生成由 last_modified 与 content_length 拼接而成
etag = header.last_modified + header.content_lenth;
可见源码位置，并在以下贴出: ngx_http_core_modules.c(opens in a new tab)
etag->value.len = ngx_sprintf(etag->value.data, ""%xT-%xO"", r->headers_out.last_modified_time, r->headers_out.content_length_n)- etag->value.data;
总结：nginx 中 etag 由响应头的 Last-Modified 与 Content-Length 表示为十六进制组合而成。
由 etag 计算 Last-Modified 与 Content-Length，使用 js 计算如下，结果相符
> new Date(parseInt('5cbee66d', 16) * 1000).toJSON()"2019-04-23T10:18:21.000Z"> parseInt('264', 16)612
Nginx 中的 ETag 算法及其不足
协商缓存用来计算资源是否返回 304，我们知道协商缓存有两种方式
Last-Modified/if-Modified-SinceETag/If-None-Match
既然在 nginx 中 ETag 由 Last-Modified 和 Content-Length 组成，那它便算是一个加强版的 Last-Modified 了，那加强在什么地方呢？
Last-Modified 是由一个 unix timestamp 表示，则意味着它只能作用于秒级的改变，而 nginx 中的 ETag 添加了文件大小的附加条件
如果 http 响应头中 ETag 值改变了，是否意味着文件内容一定已经更改
答案：不能。
因此使用 nginx 计算 304 有一定局限性：在 1s 内修改了文件并且保持文件大小不变。但这种情况出现的概率极低就是了，因此在正常情况下可以容忍一个不太完美但是高效的算法。
http中get和post的方法区别
- GET在浏览器回退时是无害的，而POST会再次提交请求。
- GET产生的URL地址可以被Bookmark，而POST不可以。
- GET请求会被浏览器主动cache，而POST不会，除非手动设置。
- GET请求只能进行url编码，而POST支持多种编码方式。
- GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
- GET请求在URL中传送的参数是有长度限制的，而POST么有。
- 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
- GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
- GET参数通过URL传递，POST放在Request body中。
http2和http1.1有什么改进
- 二进制分帧
- 请求多路复用 (Stream/Frame)
- 头部压缩: (HPack)
- 服务端推送: (PUSH_PROMISE)
可参考文章 http2 详解
