前言：
如今看官们对“lz77算法逆向”大致比较关心，同学们都需要知道一些“lz77算法逆向”的相关资讯。那么小编同时在网络上搜集了一些有关“lz77算法逆向””的相关资讯，希望同学们能喜欢，我们快快来学习一下吧！http 常见的状态码有哪些
1XX 表示消息2XX 表示成功3XX 表示重定向4XX 表示客户端错误5XX 表示服务端错误常见的状态码200最喜欢见到的状态码，表示请求成功301永久重定向302临时重定向304自上次请求，未修改的文件400错误的请求401未被授权，需要身份验证，例如 token 信息等等403请求被拒绝404资源缺失，接口不存在，或请求的文件不存在等等500服务器端的未知错误502网关错误503服务暂时无法使用http 状态码中 301，302 和 307 有什么区别301，Moved Permanently。永久重定向，该操作比较危险，需要谨慎操作：如果设置了 301，但是一段时间后又想取消，但是浏览器中已经有了缓存，还是会重定向。302，Fount。临时重定向，但是会在重定向的时候改变 method: 把 POST 改成 GET，于是有了 307307，Temporary Redirect。临时重定向，在重定向时不会改变 methodhttp 状态码 502 和 504 有什么区别502 Bad Gateway The server was acting as a gateway or proxy and received an invalid response from the upstream server. 收到了上游响应但无法解析504 Gateway Timeout The server was acting as a gateway or proxy and did not receive a timely response from the upstream server. 上游响应超时
我自己是一名从事了多年开发的web前端老程序员，目前辞职在做自己的web前端私人定制课程，今年年初我花了一个月整理了一份最适合2019年学习的web前端学习干货，各种框架都有整理，送给每一位前端小伙伴，想要获取的可以关注我的头条号并在后台私信我：前端，即可免费获取。
随着 http2 的发展，前端性能优化中的哪些传统方案可以被替代雪碧图资源文件合并http2 与 http1.1 有什么不同多路复用二进制分帧server push头部压缩
可参考文章 http2 详解[2]
gzip 的原理是什么
gzip 使用了 LZ77 算法与 Huffman 编码来压缩文件，重复度越高的文件可压缩的空间就越大。
可以对图片开启 gzip 压缩吗，为什么
不需要开启，如果开启的话，有可能使图片变的更大。如果你注意一些网站的 img 资源时，就会发现他们都没有开启 gzip
参考:
Don't use gzip for image or other binary files.
Image file formats supported by the web, as well as videos, PDFs and other binary formats, are already compressed; using gzip on them won't provide any additional benefit, and can actually make them larger. To compress images, see Optimize images.
http 的请求报文与响应报文的格式是什么
以 nc 模拟 http 报文如下
$ nc 80GET / HTTP/1.1Host: 200 OKAccept-Ranges: bytesCache-Control: no-cacheConnection: Keep-AliveContent-Length: 14615Content-Type: text/htmlDate: Tue, 10 Dec 2019 02:48:44 GMTP3p: CP=" OTI DSP COR IVA OUR IND COM "P3p: CP=" OTI DSP COR IVA OUR IND COM "Pragma: no-cacheServer: BWS/1.1Set-Cookie: BAIDUID=F0FC6B3A056DEA285F51A1F2F8A170BB:FG=1; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.comSet-Cookie: BIDUPSID=F0FC6B3A056DEA285F51A1F2F8A170BB; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.comSet-Cookie: PSTM=1575946124; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.comSet-Cookie: BAIDUID=F0FC6B3A056DEA287CB2B9422E09E30E:FG=1; max-age=31536000; expires=Wed, 09-Dec-20 02:48:44 GMT; domain=.baidu.com; path=/; version=1; comment=bdTraceid: 1575946124058431156210725656341129791126Vary: Accept-EncodingX-Ua-Compatible: IE=Edge,chrome=1<!DOCTYPE html><!--STATUS OK-->........内容省略http 响应头中的 ETag 值是如何生成的
关于 etag 的生成需要满足几个条件
当文件不会更改时，etag 值保持不变。所以不能单纯使用 inode便于计算，不会特别耗 CPU。这样子 hash 不是特别合适便于横向扩展，多个 node 上生成的 etag 值一致。这样子 inode 就排除了
关于服务器中 etag 如何生成可以参考 HTTP: Generating ETag Header[3]
那么在 nginx 中的 etag 是如何生成的？
nginx 中 ETag 的生成
我在网上找到一些资料与源代码了解到了 etag 的计算方法。由 python 伪代码表示计算方法如下
etag = '{:x}-{:x}'.format(header.last_modified, header.content_lenth)源码: ngx_http_core_modules.c[4]
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 表示为十六进制组合而成。
随手在我的 k8s 集群里找个 nginx 服务测试一下
$ curl --head 10.97.109.49HTTP/1.1 200 OKServer: nginx/1.16.0Date: Tue, 10 Dec 2019 06:45:24 GMTContent-Type: text/htmlContent-Length: 612Last-Modified: Tue, 23 Apr 2019 10:18:21 GMTConnection: keep-aliveETag: "5cbee66d-264"Accept-Ranges: bytes
由 etag 计算 Last-Modified 与 Content-Length，使用 js 计算如下，结果相符
> new Date(parseInt('5cbee66d', 16) * 1000).toJSON()"2019-04-23T10:18:21.000Z"> parseInt('264', 16)612Last-Modified，ETag 与协商缓存我们知道协商缓存有两种方式
Last-Modified/if-Modified-SinceETag/If-None-Match
既然在 nginx 中 ETag 由 Last-Modified 和 Content-Length 组成，那它便算是一个加强版的 Last-Modified 了，那加强在什么地方呢？
** Last-Modified 是由一个 unix timestamp 表示，则意味着它只能作用于秒级的改变**
那下一个问题：如果 http 响应头中 ETag 值改变了，是否意味着文件内容一定已经更改[5]
如果 http 响应头中 ETag 值改变了，是否意味着文件内容一定已经更改
不一定，由服务器中 ETag 的生成算法决定。详见 #112[6]
比如 nginx 中的 etag 由 last_modified 与 content_length 组成，而 last_modified 又由 mtime 组成
当编辑文件却未更改文件内容时，或者 touch file，mtime 也会改变，此时 etag 改变，但是文件内容没有更改。
http 服务中静态文件的 Last-Modified 是根据什么生成的
一般会选文件的 mtime，表示文件内容的修改时间
nginx 也是这样处理的，源码见: ngx_http_static_module.c[7]
r->headers_out.status = NGX_HTTP_OK; r->headers_out.content_length_n = of.size; r->headers_out.last_modified_time = of.mtime;
关于为什么使用 mtime 而非 ctime，可以参考 #116[8]
既然 http 是无状态协议，那它是如何保持登录状态
通过 cookie 或者 Authorization header 来传递凭证，在服务端进行认证
https 是如何保证报文安全的
https 主要解决三个安全问题：
内容隐私防篡改确认对方身份
https 并不是直接通过非对称加密传输过程，而是有握手过程，握手过程主要是和服务器做通讯，生成私有秘钥，最后通过该秘钥对称加密传输数据。还有验证证书的正确性。证书验证过程保证了对方是合法的，并且中间人无法通过伪造证书方式进行攻击。
我们如何从 http 的报文中得知该服务使用的技术栈
一般有两个 response header，有时服务端为了隐蔽自己真实的技术栈会隐蔽这两个字段
X-Powerd-ByServer在发送 http 请求报文时，Host 是必要的吗
是有必要的，因为我们不知道会途径会不会有代理出现， 如果直接到达服务器的话，服务器是可以通过路径知道资源在哪，但是如果通过代理的话，代理无法得知具体服务器是什么地址
http 响应头中如果 content-type 为 application/octet-stream，则代表什么意思
代表二进制流，一般用以下载文件
http 向 https 做重定向应该使用哪个状态码
一般用作 301 的较为多，但是也有使用 302，如果开启了 HSTS 则会使用 307
如知乎使用了 302，淘宝使用了 301
$ curl --head 302 FoundDate: Tue, 24 Dec 2019 00:13:54 GMTContent-Length: 22Connection: keep-aliveServer: NWS_TCloud_IPV6Location: : 0e28d9a1-6aeb-42cd-9f6b-00bd6cf11500$ curl --head 301 Moved PermanentlyServer: TengineDate: Tue, 24 Dec 2019 00:13:58 GMTContent-Type: text/htmlContent-Length: 278Connection: keep-aliveLocation: : cache20.cn1480[,0]Timing-Allow-Origin: *EagleId: 6f3f38a815771464380412555ehttp 响应头中的 Date 与 Last-Modified 有什么不同，网站部署时需要注意什么
LM-Factor 与它俩有关。
简而言之，一个静态资源没有设置 Cache-Control 时会以这两个响应头来设置强制缓存时间，而非直接进行协商缓存。在涉及到 CDN 时，表现更为明显，体现在更新代码部署后，界面没有更新。
http 1.1 中的 keep-alive 有什么作用
在 http 1.1 中，在响应头中设置 keep-alive 可以在一个 TCP 连接上发送多个 http 请求
避免了重开 TCP 连接的开销避免了刷新时重新建立 SSL 连接的开销避免了 QPS 过大时，服务器的连接数过大
在服务器端使用响应头开启 keep-alive
Connection: Keep-AliveKeep-Alive: timeout=5, max=1000
原文链接：
作者：全栈成长之路
标签： #lz77算法逆向
