WSL中安装Docker

HTTP状态码：

• 1xxs - 信息性：服务器正在处理请求。
• 2xxs - 成功信息：请求已经完成，服务器向浏览器提供了预期的响应。
• 3xxs –重定向：你的请求被重定向到了其他地方。服务器收到了请求，但是有某种重定向。
• 4xxs – 客户端错误：客户端发生错误，导致服务器无法处理请求。
• 5xxs – 服务端错误：客户端发出了有效的请求，但是服务器未能正确处理请求。

备注：3xxs类中的304是个奇葩，其不属于重定向信息提示，这个后面会讲到

1xxs状态码

• 100 Continue：表明目前为止，所有的请求内容都是可行的，客户端应该继续请求，如果完成，则忽略它。
• 101 Switching Protocol：该状态码是响应客户端Upgrade标头发送的，并且指示服务器也正在切换协议。
• 103 Early Hints：主要用于与Link链接头一起使用，以允许用户代理在服务器仍在准备响应时开始预加载资源。

备注：在web开发的工作中，我们都会使用封装好的库进行接口请求，而且浏览器的控制台网络中也不会出现这类状态码的提示（我没看到过😢），所以这一大类基本不会接触到，了解一下即可。

2xxs状态码

• 200 OK

  ：请求成功。成功的含义取决于HTTP方法：

  • GET：资源已被提取并在消息正文中传输。
  • HEAD：实体标头位于消息正文中。
  • POST：描述动作结果的资源在消息体中传输。
  • TRACE：消息正文包含服务器收到的请求信息。（方法不安全，一般不用）

说到了HTTP的方法，可以戳HTTP请求方法这个解析教程来了解一下。

• 201 Created：请求已经成功，并因此创建了一个新的资源。这通常是在PUT或POST请求之后发送的响应。
• 202 Accepted：请求已经接收到，但是没有响应，没有结果。意味着不会有一个异步的响应去表明当前请求的结果，预期另外的进程和服务去处理请求，或者批处理。
• 204 No Content：服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。遇到复杂请求时候，浏览器会发送一个OPTION方法进行预处理返回响应。

关于复杂请求和简单请求，可以参考这篇文章CORS非简单请求。

• 205 Reset Content：服务器已经成功处理了请求，但是没有返回任何内容。与204响应不同，返回此状态码的响应要求请求者重置文档视图。

备注：使用的最多的2xxs状态码是200和204，在遇到204状态码的时候，要注意一下自己发的请求是不是复杂请求。如果是复杂请求，那么在得到204返回时，浏览器有没有接受了这个请求的返回，如果没有，要叫后端搞下相关配置了。

4xxs状态码

• 401 Unauthorized：这意味着你的登录凭证无效。服务器不知道你是谁，这时，你需要尝试重新登录。
• 403 Forbidden：服务器已经理解请求，但是拒绝执行它。与401不同，403知道是你登录了，但是还是拒绝了你。
• 404 Not Found：请求失败，你请求所希望得到的资源未在服务器上发现。
• 410 Gone：被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。
• 422 Unprocessable Entity：请求格式良好，但是由于语义错误而无妨遵循。这时候要检查下自己的传参格式语义有没有正确了。
• 429 Too Many Requests：用户在给定的时间内发送了太多请求（“限制请求速率”）。在DDOS攻击中就可以使用到了。

备注：这里要注意的是422，别请求链接一出错，就屁颠屁颠的找后端，先看下后端给过来的API文档中，要传的字段是否都准确跟上了。😂

5xxs状态码

• 500 Internal Server Error：服务器内部错误，服务器遇到了不知道如何处理的情况。比如后端同学写错了model啥的～

• 503 Service Unavailable：服务器没有准备好处理请求。常见的原因是服务器因维护或重载而停机。

• 504 Gateway Timeout：网关超时，服务器未能快速的做出反应。请求接口返回pedding时间过长基本就是这个问题了，囧。

重定向机制：

在HTTP的诸多状态码中，由3开头的3XX这一类状态码表示的含义是一类重定向状态码，服务器会在需要指示浏览器进行重定向的时候返回这些状态码给浏览器，且大多数3XX状态码都会附上Location字段，其中的值则是服务器要求浏览器转向的URL的值。浏览器接受到重定向响应以后，会根据Location字段的值，自动的将请求转向其中的URL。

这一类状态码的值即其具体的含义如下：

301 Moved Permanently：被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用响应返回的若干个URI之一。

302 Found(Previously “Moved temporarily”)：请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。

303 See Other：对当前的请求的响应可以在另一个URI上被找到，而且客户端应该采用GET的方式访问那个链接。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。

304 Not Modified：如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304 响应禁止包含消息体，因此始终以消息头后的第一个空行结尾。请求的时候一般结合If-Modified-Since头部使用。

307 Temporary Redirect：307的意义如上302。与历史上302不同的是在重新发出原始请求时不允许更改请求方法。比如，使用POST请求始终就该用POST请求。

308 Permanent Redirect：含义同301，不过区别在于这个状态码不会改变请求的方法和实体数据。

在上面的状态码介绍中提到了307和302， 308和301的区别，具体说来，301和302在大多数情况下不会改变请求的方法和实体，不过在某些旧的用户代理上，可能会发生意想不到的改变，除了GET和HEAD方法以外的请求方法在使用301和302进行重定向时可能会被改变成GET方法，并且请求的实体也会被清空。因此，如果需要在使用非GET方法的请求中进行重定向的话，那么307和308是要优于301和302的。

¶客户端实现重定向的一些其他机制

在HTML页面的头部，我们可以通过添加meta标签的方式，来实现重定向。例如：

<meta http-equiv="refresh" content="0;https://www.baidu.com">

我们也可以使用JS来实现重定向：

window.location = "https://www.baidu.com"

keep-alive机制

传统HTTP应用，一次TCP连接，一次request，这样效率非常低下：

• 服务端负载增加，每个请求过来都得占用端口

• 客户端或服务端对客户端连接数的限制（chrome 限制是6个）
  这种情况很多，比如网页加载对于这个case的处理就是使用将静态资源放置到不同Domain或者压缩打包减少数量来提高效率。

http1.1 协议里增加了 keepalive的支持， 并且默认开启。

客户端和服务端在建立连接并完成request后并不会立即断开TCP连接，而是在下次request来临时复用这次TCP连接。但是这里也必须要有TCP连接的timeout时间限制。不然会造成服务端端口被长期占用释放不了。

对于不适用keepalive的request来说，不管是客户端还是服务端都是通过TCP的链接的断开知道request的结束（TCP 挥手时会check 数据包的 seq， 保证数据完整性）。
支持keepalive后，如何知道request结束了呢？
在Http1.1的版本里， 解决方案是request 和reponse里使用contentLength来帮助确认是否收到全部数据。

另一个问题就是在使用keepalive的情况，客户端依然有同时发送多个请求的情况，比如网页加载是需要同时load多个静态资源。比如 浏览器默认最大连接数是6，现在有十个资源同时加载，那么这十个里会有6个并行，4个与前6个串行。

在keepalive里有个问题就是如果能知道每个repose与其对应的request的话，并发的请求可以只需要一次TCP连接，这也就是http2.0实现的多路复用。

cookie和session的区别

Cookie是访问某些网站以后在本地存储的一些网站相关的信息，下次再访问的时候减少一些步骤。
Cookie中一般包括如下主要内容：

1. key：设置的cookie的key。
2. value：key对应的value。
3. max_age/expire_time：设置cookie的过期时间。
4. domain：该cookie在哪个域名中有效。一般设置子域名，比如cms.example.com。
5. path：该cookie在哪个路径下有效。

例如，我们登录某一个网站时需要输入用户名及密码，如果用户名和密码保存为cookie，则下次我们登录该网站的时候就不需要再输入用户密码了。

session是存在服务器的一种用来存放用户数据的类HashTable结构。
浏览器第一次发送请求时，服务器自动生成了一HashTable和一SessionID来唯一标识这个HashTable，并将其通过响应发送到浏览器。浏览器第二次发送请求会将前一次服务器响应中的SessionID放在请求中一并发送到服务器上，服务器从请求中提取出Session ID，并和保存的所有Session ID进行对比，找到这个用户对应的HashTable。

例如，我们浏览一个购物网站，用户将部分商品添加到购物车中，许久以前许多网站都是用服务端session存储购物车内容（现在基本都是用数据库了），就用到了session存储这部分信息。

区别：

¶1.存储位置不同

cookie的数据信息存放在本地。
session的数据信息存放在服务器上。

¶2.存储容量大小不同

cookie存储的容量较小，一般<=4KB。
session存储容量大小没有限制(但是为了服务器性能考虑，一般不能存放太多数据)。

¶3.存储有效期不同

cookie可以长期存储，只要不超过设置的过期时间，可以一直存储。
session在超过一定的操作时间(通常为30分钟)后会失效，但是当关闭浏览器时，为了保护用户信息，会自动调用session.invalidate()方法，该方法会清除掉session中的信息。

¶4.安全性不同

cookie存储在客户端，所以可以分析存放在本地的cookie并进行cookie欺骗，安全性较低。
session存储在服务器上，不存在敏感信息泄漏的风险，安全性较高。

¶5.域支持范围不同

cookie支持跨域名访问。例如，所有a.com的cookie在a.com下都能用。
session不支持跨域名访问。例如，www.a.com 的session在api.a.com下不能用。

¶6.对服务器压力不同

cookie保存在客户端，不占用服务器资源。
session是保存在服务器端，每个用户都会产生一个session，session过多的时候会消耗服务器资源，所以大型网站会有专门的session服务器。

¶7.存储的数据类型不同

cookie中只能保管ASCII字符串，并需要通过编码方式存储为Unicode字符或者二进制数据。
session中能够存储任何类型的数据，包括且不限于string，integer，list，map等。

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达，邮件至 708801794@qq.com