做电商需要知道的几个网站/营销型网站重要特点是

1. HTTP是什么？

超文本传输协议

• 协议：HTTP是一个用在计算机世界里面的协议，使用计算机能够理解的语言确立了一种计算机之间交流通信的规范以及错误的处理方式（两者参与）
• 传输：HTTP是一个在计算机世界里面专门用来在两点之间传输数据的约定和规范
• 超文本：文字、图片、视频等的混合体，能够从一个超文本跳转到另外一个超文本

总结：HTTP是一个在计算机世界里面专门用于两点之间传输文字、图片、视频等数据的规范和约定（服务器与服务器之间、服务器与客户端之间）

2. HTTP常见的状态码？

• 1xx 提示信息，协议处理的中间状态

• 2xx 服务器成功处理了客户端的请求

  • 200 成功状态码 如果是非head请求，服务器返回的响应头会没有body数据
  • 204 成功状态码 响应头没有body数据
  • 206 成功状态码 分块下载或者断点续传的标识 标识服务器只返回了部分的body数据

• 3xx 资源位置发生了变动，需要重新发送请求获取资源（重定向）

  • 301 永久重定向 请求资源不存在，需要改用新的URL进行访问（location字段标识指明要跳转的url）
  • 302 临时重定向 暂时需要另外的URL来进行资源访问（location字段标识指明要跳转的url）
  • 304 缓存重定向 重定向到已经存在的缓存文件，不会进行跳转

• 4xx 客户端发送的请求报文有误 服务器无法处理

  • 400 整体概括客户端的请求报文有误
  • 403 服务器禁止访问资源与客户端无关
  • 404 请求资源服务器无法提供，找不到

• 5xx 服务器处理请求时内部发生的错误

  • 500 整体概括服务器的错误
  • 501 客户端请求的功能暂不支持，敬请期待
  • 502 服务器作为网关或者代理时，服务器正常工作但是后端的服务发生了错误
  • 503 服务器繁忙（大学抢课常态）

3. HTTP 常见的字段有哪些？

• Host：客户端发送请求时用来指定服务器的域名
• Content-Length：服务器本次响应的数据长度 解决TCP的粘包问题
• Connection：客户端要求服务器使用 HTTP长连接机制方便其他请求复用
• Content-Type：告诉客户端本次响应的数据是什么格式 （可以用Accept来声明你必须返回什么格式的数据）
• Content-Encoding：服务器返回的数据使用了什么压缩格式 （可以使用Accept-Encoding声明必须返回什么压缩格式）

4. GET和POST有什么区别：

• GET：
  • 从服务器获取指定的资源（静态的文本、图片、音视频等）
  • 请求参数在URL中，只能支持ASCLL字符，浏览器对URL的长度有限制
• POST：
  • 根据请求体body对指定的资源做出处理
  • body的数据格式可以是任意的，只要与服务端协商好就行
  • 浏览器不会对body大小做出限制

5. GET 和POST方法都是安全和幂等的吗？

• 前置知识：
  • 安全：请求方法不会对服务器上的资源造成不好的影响
  • 幂等：多次执行相同的操作，结果都是相同的
• get方法是安全且幂等的，数据可以缓存到浏览器上且可以将get请求保存为书签；post方法相反
• HTTP传输的内容都是明文的，想要避免传输过程中数据被窃取就要使用HTTPS协议，这样所有的HTTP数据就会被加密传输
• 任何请求都是可以带body的，并不是说get请求不能带body，只能post请求带body
• url中的查询参数不是get所独有的，post请求的url中也可以有参数

6. HTTP缓存技术

两种实现方式：强制缓存 协商缓存

• 强制
  • 利用响应头里面的Cache-control字段和Expires字段来实现的
  • 浏览器第一次请求服务器资源是，服务器返回资源同时会在响应头上加上Cache-Control（设置过期时间）；浏览器再次请求时会先通过请求资源的时间与Cache-control的时间进行比较计算是否过期，如果没有则使用缓存相反就重新请求服务器；服务器再次收到请求后，会再次更新响应头里面的Cache-Control的值
• 协商（未命中强制缓存的结果后才执行）
  • 通过服务端告知客户端是否可以使用本地缓存的方式
  • 实现方式有两种：第一种基于时间实现，但容易发生由于时间篡改导致的不可靠的问题；第二种基于一个唯一标识实现
  • ETag的优先级更高：
    1. 没有修改文件内容的情况下文件最后的修改时间可能改变，导致客户端以为文件被改动了
    2. 有些文件是在秒级以内修改的，ETag能够保证这种需求下客户端在1秒内能刷新多次
    3. 有些服务器不能精确获取文件的最后修改时间
  • ETag字段实现协商缓存的过程：
    1. 第一次请求服务器，会在响应头加上一个ETag唯一标识
    2. 再次请求首先检查是否过期，过期之后会在请求头加上一个IF-NONE-MATCH字段值就是ETag唯一标识
    3. 服务器再次收到请求之后，会根据请求头中的ETag唯一标识和当前资源的唯一标识进行比较；值相等返回304，使用缓存；不相等返回200与资源，并在响应头加上一个ETag唯一标识
    4. 客户端收到304的请求响应状态码从本地缓存加载资源，否则就更新资源

7. HTTP/1.1相比HTTP/1.0提高了什么性能？

• 提高：
  • 使用长连接的方式改善了1.0短连接造成的性能开销
  • 支持管道网络传输，可以同时发送多个请求，减少整体的响应时间
• 不足：
  • 请求头响应头未经过压缩就发送，如果首部信息越多延迟就会越大(只能够压缩请求体的数据)
  • 发送冗长的首部，频繁的返送相同的首部造成的浪费较多
  • 服务器是按照请求的顺序响应的，如果服务器响应慢就会产生客户端队头阻塞的现象 【HTTP层的队头阻塞】
  • 没有请求优先级的控制
  • 请求只能从客户端开始，服务器只能被动响应

8. HTTP/2做了什么优化？

• 基于HTTPS的，所以他的安全性是有保障的
• 头部压缩
  • 使用HPACK算法，在服务端和客户端同时维护一张头部信息表，所有字段都会存入这个表，生成一个索引号，如果有相同的字段直接发送索引号提高速度
  • 如果你发送的头是一样的或者相似的，协议会帮助消除重复的部分
• 二进制格式
  • 所有的报文都是二进制格式分为头部帧和数据帧，不在需要像1版本那样还要将其转为二进制，可以直接解析二进制报文，增加了数据传输的效率
• 并发传输
  • 解决了1版本中的队头阻塞的问题
  • 一个TCP连接里面可以有多个流，并且一个流里面可以有多个数据帧
  • 针对不同的HTTP请求用唯一的流ID来进行区分，接收端根据这个ID有序组装HTTP的消息并且可以并行交错地发送请求和响应（乱序发送）
• 服务器主动推送资源
  • 客户端和服务端都可以建立起Stream流，客户端建立的流必须是奇数，服务端必须是偶数（主动推送的）
  • 客户端请求发送获取html，1版本还需要再次请求css文件，而当前版本服务端会主动的推送css文件减少了消息传递的次数
• 不足：
  • 2版本是基于TCP协议来传输数据的，TCP是字节流协议，必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里面的数据返回给HTTP应用（当前一个字节数据没有到达时 丢包，后面到达的字节数据只能存在缓冲区中等到这一个字节重传且到达之后，应用层才能够从缓冲区拿到数据） 【TCP层的队头阻塞】

9. HTTP3做了哪些优化

• 将TCP传输改为了UDP传输并配合QUIC协议实现TCP的可靠性传输
• QUIC协议特点
  • 无队头阻塞
    • 也是跟2版本的多路复用的概念类似，在同一个连接上并发传输多个流，当某个流发生丢包的时候只会阻塞这一个流，其他的流不会收到影响与2相反，多个流之间相互独立 只要数据一到达应用层就可以直接读取
  • 更快的连接建立
    • 1版本和2版本中的TCP和TLS没有结合在一起，所以在连接的时候需要分别进行握手，可能会存在3次的RTT或者2次的RTT
    • QUIC协议里面握手过程只需要1RTT来确认双方的连接ID，3版本的QUIC协议不是与TLS分层的，包含了它在里面并且使用的时TLS1.3因此只需要1个RTT就可以完成连接的建立和密钥的协商 会话恢复的时候有效负载数据与第一个数据包一起发送可以实现0RTT的效果
  • 连接迁移（基于连接ID实现）
    • 当移动网络切换的时候必须进行断开重新建立连接，建立连接的过程2版本需要进行TCP三次握手和TLS四次握手的过程并且还要考虑TCP慢启动的减速过程这里就会产生较高的连接迁移成本
    • QUIC协议没有使用四元组的方式来绑定连接，而是通过连接ID来标记通信两端的，因此网络变化之后只要互相保留了这个连接ID那么就能实现无缝的复用原连接没有丝毫卡顿
    • QUIC是新的协议很多设备不知道什么是QUIC只会当作UDP，并且有的网络设备是会丢UDP包的，如果网络设备无法识别这是一个QUIC包那么就会当作UDP包然后被丢弃

10. SSL/TLS的握手过程

• TLS1.2
  • 需要2个RTT往返时延，也就是4次握手
• TLS1.3
  • 只需要1个RTT往返时延，也就是3次握手