福州微信公众号开发,网站刚做好怎么做优化,wordpress菜单使用2层,重庆森林壁纸1#xff1a;HTTP基本概念 超文本 传输 协议 2#xff1a;常见状态码 1xx 提示信息 2xx 成功 3xx 重定向 4xx 客户端错误 5xx 服务器错误 3#xff1a;HTTP常见的字段 host 指定服务器的域名 Content-Length 回应的数据长度 Connection 长连接#xff08;Keep-Alive#x… 1HTTP基本概念 超文本 传输 协议 2常见状态码 1xx 提示信息 2xx 成功 3xx 重定向 4xx 客户端错误 5xx 服务器错误 3HTTP常见的字段 host 指定服务器的域名 Content-Length 回应的数据长度 Connection 长连接Keep-Alive Content-Type 响应数据格式text/html; Charsetutf-8 Content-Encoding 数据压缩格式gzip 4get和post的区别 get安全、幂等、可被缓存 post不安全请求的参数只允许 ASCII 字符不幂等大部分实现不可缓存 RFC规范 POST的语义是根据请求负荷报文body对指定的资源做出处理 GET请求可以带body吗 任何请求都可以带 body的 只是因为RFC规范定义的GET请求是获取资源所以根据这个语义不需要用到body 5HTTP缓存技术 强制缓存强缓存指的是只要浏览器判断缓存没有过期则直接使用浏览器的本地缓存决定是否使用缓存的主动性在于浏览器这边。 响应头部相关参数200 状态码但在 size 项中标识的是from disk cacheCache-Control和Expires表示资源在客户端缓存的有效期 协商缓存就是与服务端协商之后通过协商结果来判断是否使用本地缓存。 响应头部相关参数304状态码 If-Modified-Since和Last-Modified资源最后修改时间If-None-Match和ETag唯一标识响应资源 6HTTP/1.1特性 优点简单HTTP 基本的报文格式就是 header body头部信息也是 key-value 灵活和易于扩展各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死允许开发人员自定义和扩充 应用广泛和跨平台从台式机的浏览器到手机上的各种 APP 缺点 无状态双刃剑好服务器不用记忆HTTP的状态减轻服务器的负担。坏没有记忆能力完成有关联性的操作时会非常麻烦解决cookie 明文传输双刃剑好方便阅读。坏被抓包信息裸奔 不安全通信使用明文不验证通信方的身份无法证明报文的完整性解决HTTPS 性能 长连接一次TCP连接多次请求响应 管道网络传输连续发送请求不必等其响应。服务器必须按照接收请求的顺序发送对这些管道化请求的响应。HTTP/1.1管道解决了请求的队头阻塞但是没有解决响应的队头阻塞 队头阻塞当顺序发送的请求序列中的一个请求因为某种原因被阻塞时在后面排队的所有请求也一同被阻塞了会招致客户端一直请求不到数据这也是后续的HTTP/2和HTTP/3在优化HTTP的性能的方向 7HTTP和HTTPS的区别 HTTPS 则解决 HTTP 不安全的缺陷在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议使得报文能够加密传输 HTTP 默认端口号是 80HTTPS 默认端口号是 443 HTTPS 是如何解决上面的三个风险的窃听风险、篡改风险、冒充风险 混合加密对称加密和非对称加密结合密钥、摘要算法数字签名哈希算法非对称双向加解密、数字证书身份验证CA 数字证书认证机构 8HTTPS是如何建立连接的其间交互了什么HTTPS 的应用数据是如何保证完整性的略https://xiaolincoding.com/network/2_http/http_interview.html#https-%E6%98%AF%E5%A6%82%E4%BD%95%E5%BB%BA%E7%AB%8B%E8%BF%9E%E6%8E%A5%E7%9A%84-%E5%85%B6%E9%97%B4%E4%BA%A4%E4%BA%92%E4%BA%86%E4%BB%80%E4%B9%88 9HTTPS 一定安全可靠吗 HTTPS 协议本身到目前为止还是没有任何漏洞的即使你成功进行中间人攻击本质上是利用了客户端的漏洞用户点击继续访问或者被恶意导入伪造的根证书并不是 HTTPS 不够安全 如何避免被中间人抓取数据通过 HTTPS 双向认证 10HTTP/1.1、HTTP/2、HTTP/3 演变 HTTP/1.1 改进长连接的方式改善了短连接造成的性能开销、支持管道网络传输 减少整体的响应时间 瓶颈请求头部未经压缩就发、发送冗长的首部、队头阻塞、没有请求优先级控制、请求只能从客户端开始 服务器只能被动响应 HTTP/2 改进头部压缩、二进制格式、并发传输、服务器主动推送资源 缺点HTTP/2 通过 Stream 的并发能力解决了 HTTP/1 队头阻塞的问题看似很完美了但是 HTTP/2 还是存在“队头阻塞”的问题只不过问题不是在 HTTP 这一层面而是在 TCP 这一层 HTTP/2 是基于 TCP 协议来传输数据的TCP 是字节流协议TCP 层必须保证收到的字节数据是完整且连续的这样内核才会将缓冲区里的数据返回给 HTTP 应用那么当「前 1 个字节数据」没有到达时后收到的字节数据只能存放在内核缓冲区里只有等到这 1 个字节数据到达时HTTP/2 应用层才能从内核中拿到数据这就是 HTTP/2 队头阻塞问题。 HTTP/3 改进HTTP/2 队头阻塞的问题是因为 TCP所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP 大家都知道 UDP 是不可靠传输的但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。 QUIC有以下3个特点 无队头阻塞当某个流发生丢包时只会阻塞这个流其他流不会受到影响因此不存在队头阻塞问题 更快的连接建立QUIC 内部包含了 TLS QUIC 使用的是 TLS/1.3因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商 连接迁移基于 TCP 传输协议的 HTTP 协议由于是通过四元组源 IP、源端口、目的 IP、目的端口确定一条 TCP 连接当移动设备的网络从 4G 切换到 WIFI 时意味着 IP 地址变化了那么就必须要断开连接然后重新建立连接QUIC 协议通过连接 ID 来标记通信的两个端点P 地址变化了只要仍保有上下文信息比如连接 ID、TLS 密钥等就可以“无缝”地复用原连接消除重连的成本没有丝毫卡顿感达到了连接迁移的功能 问答环节 问“https 和 http 相比就是传输的内容多了对称加密可以这么理解吗” 答建立连接时候https 比 http多了 TLS 的握手过程 传输内容的时候https 会把数据进行加密通常是对称加密数据 问“ 我看文中 TLS 和 SSL 没有做区分这两个需要区分吗” 答这两实际上是一个东西。 SSL 是洋文 “Secure Sockets Layer” 的缩写中文叫做「安全套接层」。它是在上世纪 90 年代中期由网景公司设计的。 到了1999年SSL 因为应用广泛已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS是 “Transport Layer Security” 的缩写中文叫做 「传输层安全协议」。 很多相关的文章都把这两者并列称呼SSL/TLS因为这两者可以视作同一个东西的不同阶段。 问“为啥 SSL 的握手是 4 次” 答SSL/TLS 1.2 需要 4 握手需要 2 个 RTT 的时延就是 4 次握手另外 SSL/TLS 1.3 优化了过程只需要 1 个 RTT 往返时延也就是只需要 3 次握手
