前端的计算网络学习宝典！（持续更新）

前端的计算网络学习宝典！

一、状态码

在讲状态码之前，我们来假设一下，有一个饭店，客户端是客人，服务器是厨师，他们之间通过店小二的菜单传输信息，也就是报文。在每个状态码的后面我会加粗我的假设理解。

1xx Informational 信息性状态码

100
100 Continue：服务器已经接收到请求头部，并且客户端应该继续发送请求主体部分。
当客户端发送一个带有 “Expect” 字段且值为 “100-continue” 的请求头部时，表示客户端希望在发送请求主体之前得到确认。
这种情况通常在以下场景中使用：

• 客户端希望在发送较大的请求主体之前，先得到服务器的确认，以确保服务器能够接收和处理该请求。
• 客户端可能希望避免浪费带宽和时间，如果服务器无法处理请求，客户端可以提前得到拒绝回应，而不需要发送整个请求主体。

客人想吃鱼香肉丝，但是想知道厨师会不会炒，于是在菜单上写了，你会不会炒鱼香肉丝（设置Expect为100-continue），店小二给厨师后，厨师说会，店小二又回头告诉顾客100，示意顾客继续点菜。

101
101 Switching Protocols：服务器已经理解了客户端的请求，并将通过协议升级的方式来切换到新的协议。
厨师看懂了菜单，但是这道菜涉及野生保护动物，厨师希望用其他方式来沟通，店小二回来告诉顾客101

2xx Su***ess 成功状态码

200
200 OK：表示请求已经成功，返回内容在响应体中。
顾客在菜单上写下菜，店小二告诉厨师炒好，店小二给顾客端出来，一切都很完美，店小二说200
201
201 Created：表示请求已经成功，且服务器创建了新的资源，并将其URI返回给客户端。
顾客希望厨师会一道新菜，店小二告诉厨师后，厨师学会了，店小二回来告诉顾客201了

202
202 A***epted：表示服务器已经接受了请求，但尚未完成处理。通常用于异步操作，告诉客户端请求已被接受，但还需要时间来完成操作。
顾客点了一道硬菜，厨师需要时间做，于是告诉店小二，你先回去告诉顾客一声，菜我会做但是需要等一会，于是顾客回去说202了
204
204 No Content：表示请求已经成功，但是响应中不包含任何内容。通常用于不需要返回响应主体的请求，如 DELETE 请求。
顾客不想吃红烧肉，它希望厨师忘记红烧肉的做法，店小二传达给厨师，厨师成功忘记了红烧肉的做法，于是店小二回来告诉顾客204了
206
206 Partial Content：表示服务器成功处理了部分 GET 请求，只返回了请求的部分内容。通常用于断点续传或者分块下载。
顾客点了两道菜，厨师做好了一道，叫店小二端出去，店小二端给顾客后后说206

3xx Redirection 重定向状态码

301
301 Moved Permanently：请求的资源已经永久移到了一个新地址，并且未来所有对该资源的请求都应该使用新地址。这通常用于网站重构、资源移动或更改 URL 结构等情况。
302
302 Found：请求的资源暂时被转移到了一个新的地址，但未来可能会发生变化。这通常用于临时重定向，比如服务器暂时性维护、负载均衡等。
303
303 See Other：需要客户端进行进一步的操作才能获取请求的资源。目标资源存在于另一 URI，在重定向过程中使用 GET 方法获取资源。通常用于 POST 请求重定向到 GET 请求的场景。
304
304 Not Modified：客户端缓存的资源为最新的，请求的资源没有被修改过，服务器直接返回 “Not Modified”，告诉客户端可以使用本地缓存的资源。
307
307 Temporary Redirect：跟 302 Found 类似，请求的资源暂时被转移到了一个新的地址，但未来可能会发生变化。与 302 不同的是，307 要求客户端保持请求方法不变，而不是像 302 一样将 POST 请求处理为 GET 请求。

4xx Cilent Error 客户端错误状态码

400
400 Bad Request: 服务器无法理解客户端发送的请求，一般是由于格式或语法错误引起的。
401
401 Unauthorized: 请求需要身份验证，但客户端未提供有效的身份验证凭据。需要在请求头中添加合适的认证信息。
403
403 Forbidden: 客户端没有访问请求资源的权限，服务器拒绝提供对应的响应。一般需要进行身份验证或处理账号权限等问题。
404
404 Not Found: 请求的资源不存在，或者服务器无法找到对应的资源。可能是 URL 路径设置错误，或者是被删除、移动、命名等造成的。
405
405 Method Not Allowed: 请求使用的 HTTP 方法不允许该资源被访问。常见情况是 GET/POST 方法混淆，或者使用了不被允许的 HTTP 方法，比如 DELETE。

Server Error 服务器错误状态码

500
500 Internal Server Error: 服务器遇到了意料之外的状况，无法完成用户请求。这种错误通常是由于代码或服务器配置错误导致的。
501
501 Not Implemented: 服务器不支持请求所使用的功能，返回该状态码表明此项功能未实现或不可用。
502
502 Bad Gateway: 表示一个代理服务器接收到上游服务器的无效响应。这通常发生在服务器和代理之间，代理作为中介服务器时，无法正确的处理上游服务器的响应。
503
503 Service Unavailable: 服务器暂时无法处理请求，通常由于进行维护或过载造成。一般需要等待一段时间后再尝试访问。
504
504 Gateway Timeout: 表示一个代理服务器等待上游服务器响应超时。通常情况下是由于上游服务器过于繁忙或者网络问题造成的。

二、HTTP 1.0 1.1 2 3 的区别

HTTP1.0 和 1.1 的区别

首先 http 1.0是短链接 这就导致每次请求 都需要建立一次 TCP链接 发送一次请求 服务器响应请求之后会断开链接，这就导致了一个问题，第一次响应出现了问题，那么就会导致第二个请求无法发出 ，这就是 请求对头阻塞

请求队头阻塞

持久化连接

为了解决 请求队头阻塞 http1.1 采用了持久化连接 也就是一次TCP链接可以发送多次请求，而且请求可以一次发送多个，按照顺序响应即可，这样就避免了 第二个请求必须等到 第一个响应之后才发送，解决了请求对头阻塞

• http1.1 通过使用持久连接来使多个 http 请求复用同一个 TCP 连接，以此来避免使用非持久连接时每次需要建立连接的时延。
• 通过请求头的 connection: keep-alive 字段来控制
  
  

断点续传

• 在 http1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，http1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分
• 即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
  

缓存方面

• 在 http1.0 中主要使用 header 里的 If-Modified-Since、Expires 来做为缓存判断的标准
• http1.1 则引入了更多的缓存控制策略，例如 Etag、If-Unmodified-Since、If-Match、If-None-Match 等更多可供选择的缓存头来控制缓存策略。

新增host字段

• 用来指定服务器的域名（站点）
• http1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名（hostname）。
• 但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址。因此有了 host 字段，这样就可以将请求发往到同一台服务器上的不同网站。

新增请求方法

如 PUT、HEAD、OPTIONS 等

HTTP1.1 和 HTTP2 的区别

下面的图片可以看到，虽然解决了 请求队头阻塞的问题，但是如果响应一出现的问题 响应二就无法返回，这就导致了响应队头阻塞

为了解决响应对头阻塞，HTTP实现了多路复用，而实现多路复用的前提是HTTP2使用了二进制编码

二进制协议

• HTTP/2 是一个二进制协议。
• 在 HTTP/1.1 版中，报文的头信息必须是文本（ASCII 编码），数据体可以是文本，也可以是二进制。
• HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"，可以分为头信息帧（「Headers帧」）和数据帧（「Data帧」）。 帧的概念是它实现多路复用的基础。
  

多路复用

在已知HHTP2使用二进制协议 把 数据变成了帧，那么只需要给每一帧加上一个唯一标识，然后一起响应给客户端，客户端根据唯一标识在进行组装就解决了响应队头阻塞。 这个唯一标识就是流标识符。

• 单个连接（TCP）可以承载任意数量的双向数据流。HTTP/2 中数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，在后面可以根据帧首部的流标识可以重新组装。
• 不用按照顺序一一发送，这样就避免了"队头堵塞"的问题。

数据流

HTTP/2 使用了数据流的概念，因为 HTTP/2 的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的请求。
二进制帧中有对应的消息的标识，因此可以组装还原。
二进制帧中还有有一些字段，控制着优先级，这样子的话，就可以设置数据帧的优先级，让服务器处理重要资源，优化用户体验。

头信息压缩

• HTTP/2 实现了头信息压缩，由于 HTTP 1.1 协议不带状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如 Cookie 和 User Agent ，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。
• HTTP/2 对这一点做了优化，引入了头信息压缩机制。一方面，头信息使用 gzip 或 ***press 压缩后再发送；
  另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就能提高速度了。

服务器推送

• HTTP/2 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送。
• 需要注意的是 http2 下服务器主动推送的是静态资源

HTTP2 和 HTTP3 的区别

• http2看似解决了响应对头阻塞，实际上因为TCP的重传机制，但响应中的一帧出现丢包时，后续的帧不会继续发送，会等到丢失的帧重传结束后才会发送，而且这个问题无法解决，因为TCP是由操作系统决定的，除非重构操作系统，不然想把TCP改造成和http2一样的帧数据流的形式传输是不可能的。
  TCP层面的队头阻塞
  
• http3的出现还有一个原因就是http1.1是不安全的，所以在http2的时候，都会采用 http2 加 TLS或者SSL协议来加密，也就是https，本来就建立连接的TCP已经有三次握手了（1RTT也就是一个来回），使用TLS加密又需要2RTT，
  这样的建立连接成本太高了（TLS1.3简化到1RTT）
  
  为了解决TCP层面的响应队头阻塞和实现http其他实用的功能
  http3对http2和TLS以及TCP进行了一个整合
• HTTP/3基于UDP协议实现了类似于TCP的多路复用数据流、传输可靠性等功能，这套功能被称为QUIC协议。

流量控制、传输可靠性功能:

• QUIC在UDP的基础上增加了一层来保证数据传输可靠性，它提供了数据包重传、拥塞控制、以及其他一些TCP中的特性。
  

集成TLS加密功能:

• 目前QUIC使用TLS1.3，减少了握手所花费的RTT数。

快速握手

• 由于基于UDP，可以实现使用0 ~ 1个RTT来建立连接。
• 首次通信 1-RTT 恢复通信直接就0-RTT了
  

多路复用

• 同一物理连接上可以有多个独立的逻辑数据流，实现了数据流的单独传输，解决了TCP的队头阻塞问题。
  

连接ID

• 可以快速切换 网络 比如 连着wifi切换成流量

三、浏览器输入URl按下回车之后发生了些什么？

1.解析url

2.判断缓存

查看url对于的资源缓存是否过期，没有过期的话直接进行加载就可以了，过期了进行下一阶段。（这里对游览器缓存比较简单，下面有更加详细的教程）

3.DNS解析

我们输入的url要转换成对应的IP地址才能找到服务器的，而把url转换成IP的过程就是DNS解析
首先游览器检查自身缓存，没有检查本地host文件，没有检查DNS解析器缓存，还没有就访问本地DNS服务器，以及检查本地DNS服务器缓存是否有url对于的IP

如果本地DNS服务器没有缓存的话，就会三步走（这个过程是迭代的）

• 第一步去查根域名服务器，根域名服务器会返回顶级域名服务器地址给本地DNS服务器
• 第二步 去查顶级域名服务器地址，顶级域名服务器返回权威域名服务器地址
• 第三步 去查权威域名服务器，返回正确的IP
  接下来本地DNS服务器会缓存这个IP地址，然后通过DNS解析器把IP返回给游览器
  

4.TCP三次握手

• 三次握手：下面是 TCP 建立连接的三次握手的过程，首先客户端向服务器发送一个 SYN 连接请求报文段和一个随机序号，服务端接收到请求后向服务器端发送一个 SYN ACK报文段，确认连接请求，并且也向客户端发送一个随机序号。客户端接收服务器的确认应答后，进入连接建立的状态，同时向服务器也发送一个ACK 确认报文段，服务器端接收到确认后，也进入连接建立状态，此时双方的连接就建立起来了。
  

5.HTTPS握手

• 如果采用的是HTTP协议这个时候以及可以发送请求了，但是如果使用的是 HTTPS 协议，在通信前还存在 TLS 的一个四次握手的过程。
• 首先由客户端向服务器端发送使用的协议的版本号、一个随机数和可以使用的加密方法。
• 服务器端收到后，确认加密的方法，也向客户端发送一个随机数和自己的数字证书。客户端收到后，首先检查数字证书是否有效，如果有效，则再生成一个随机数，并使用证书中的公钥对随机数加密，然后发送给服务器端，并且还会提供一个前面所有内容的 hash 值供服务器端检验。
• 服务器端接收后，使用自己的私钥对数据解密，同时向客户端发送一个前面所有内容的 hash 值供客户端检验。这个时候双方都有了三个随机数，按照之前所约定的加密方法，使用这三个随机数生成一把秘钥，以后双方通信前，就使用这个秘钥对数据进行加密后再传输。

PS1：SSL和TLS的区别

• SSL 是早期用于加密通信的协议，而 TLS 实质上是 SSL 的继任者。TLS 在设计上修复了 SSL 中的一些安全漏洞，并提供了更强大的加密算法和安全特性。因此，TLS 可以看作是 SSL 的更新版本。通常来说，当人们讨论加密通信时，他们可能会使用“SSL”一词来泛指所有的加密通信，尽管实际上正在使用的可能是 TLS。这是因为人们普遍熟悉 SSL 这个术语，而 TLS 相对较新。
  

PS2：对称加密

PS3：非对称加密

• 非对称加密的方法是，我们拥有两个秘钥，一个是公钥，一个是私钥。公钥是公开的，私钥是保密的。用私钥加密的数据，只有对应的公钥才能解密，用公钥加密的数据，只有对应的私钥才能解密。我们可以将公钥公布出去，任何想和我们通信的客户， 都可以使用我们提供的公钥对数据进行加密，这样我们就可以使用私钥进行解密，这样就能保证数据的安全了。但是非对称加密有一个缺点就是加密的过程很慢，因此如果每次通信都使用非对称加密的方式的话，反而会造成等待时间过长的问题。
  

PS4：SSL证书（解决中间人攻击）

虽然可以通过加密使得数据不在是明文显示，但是我们仍然不能确定连接的对象是否是自己想连接的，中间人同时攻击服务端和客户端，与他们都建立连接，这样不管怎么加密都没有用了，所以需要第三方机构颁发的证书来确认网址的安全性。

PS5：握手过程

在得到会话密钥之前采用的是非对称加密，得到会话密钥之后，因为会话密钥只能由各自的私钥解开，所以后续传输数据就可以一次采用会话密钥，也就是对称加密。

6.返回数据

• 当页面请求发送到服务器端后，服务器端会返回一个 html 文件作为响应，浏览器接收到响应后，开始对 html 文件进行解析，开始页面的渲染过程。

7.页面渲染

• 浏览器首先会根据 html 文件构建 DOM 树，根据解析到的 css 文件构建 CSSOM 树，如果遇到 script 标签，则判端是否含有 defer 或者 async 属性，要不然 script 的加载和执行会造成页面的渲染的阻塞。当 DOM 树和 CSSOM 树建立好后，根据它们来构建渲染树。渲染树构建好后，会根据渲染树来进行布局。布局完成后，最后使用浏览器的 UI 接口对页面进行绘制。这个时候整个页面就显示出来了。

• 根据html文件生成DOM树，dom树不会阻塞html文件解析，因为dom树支持部分解析
  

• CSSOM树，cssom不会阻塞html文件解析，但是会阻塞渲染，没有cssom树是没办法合成渲染树的，而cssom不支持部分解析
  

• 合成渲染树

• 合成渲染树之后不会马上开始渲染，而是根据渲染树的节点元素大小，进行一个计算，这个过程称之为布局，布局完成之后就可开始绘制，也就是根据渲染树的内容在页面按像素绘制出来。
  

8.TCP四次挥手

因为可能存在未发送的数据，所以TCP断开连接是独立的，也就是

• 第一次挥手：客户端告诉服务端自己断开连接了
• 第二次挥手：服务端对客户端说自己知道了
  （前两次挥手客户端对服务端连接关闭）
• 第三次挥手：服务端告诉客户端自己断开连接了
• 第四次挥手：客户端对服务端说自己知道了
  （后两次挥手服务端对客户端连接关闭）
  ！！！前两次挥手和后两次挥手的顺序是可以交换的

TCP四次挥手之后，连接关闭，自此在游览器输入URL按下回车后的全过程到此结束。

四、强缓存和协商缓存

流程图非常的简单一看就会，重点是强缓存和协商缓存的判断

强缓存

服务器返回给游览器的响应头会有两个字段

Cache-Control: max-age=3600
Expires: Tue, 13 Mar 2024 09:00:00 GMT

• Cache-Control是一个相对时间，上面的例子是只要过去3600秒，这个强缓存就过期了
• Expires是一个绝对时间，意思是在2024年3月13日9点之前这个强缓存都不会过期，再这之后才会过期，但是如果修改本地时间，可能会导致Expires失效
  Cache-Control优先级大于 Expires ，游览器判断强缓存时会先看Cache-Control再看 Expires

协商缓存

• 客户端首次请求资源时，服务器会根据资源内容进行hash，生成信息摘要，通过响应头ETag: xxxxx发送给客户端
• 客户端首次请求资源时，服务器会把资源的最新修改时间，通过响应头Last-Modified:xxxxxx发送给客户端
  也就是响应头中包含

Response:
HTTP/1.1 200 OK
ETag: "abc123"
Last-Modified: Tue, 13 Mar 2024 08:00:00 GMT
Content-Type: text/html

强缓存没有命中的话会先检查是否有Etag，没有Etag会检查有没有Last-Modified
然后发送请求会If-None-Match携带Etag的值，If-Modified-Since会携带Last-Modified的时间，然后服务器进行比对，没有变化返回304也就是协商缓存，产生变化返回新的数据和状态码200：ok

Second Request:
GET /example.html HTTP/1.1
If-None-Match: "abc123"
If-Modified-Since: Tue, 13 Mar 2024 08:00:00 GMT

Etag的优先级大于Last-Modified

五、http和https的区别

HTTPS 要比 HTTPS 多了 secure 安全性这个概念，实际上， HTTPS 并不是一个新的应用层协议，它其实就是 HTTP + TLS/SSL 协议组合而成，而安全性的保证正是 SSL/TLS 所做的工作。

现在主流的版本是 TLS/1.2, 之前的 TLS1.0、TLS1.1 都被认为是不安全的，在不久的将来会被完全淘汰。在 HTTP/3 中使用了TLS/1.3。

区别：

• HTTP 是明文传输协议，HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。
• HTTPS比HTTP更加安全，对搜索引擎更友好，利于SEO,谷歌、百度优先索引HTTPS网页。
• HTTPS标准端口443，HTTP标准端口80。
• HTTPS需要用到SSL证书，而HTTP不用。

六、常见的http请求方法

• GET: 向服务器获取数据；
• POST：将实体提交到指定的资源，通常会造成服务器资源的修改；
• PUT：上传文件，更新数据；
• PATCH：部分修改资源；
• DELETE：删除服务器上的对象；
• HEAD：获取报文首部，与GET相比，不返回报文主体部分；
• OPTIONS：询问支持的请求方法，用来跨域请求；
• CONNECT：要求在与代理服务器通信时建立隧道，使用隧道进行TCP通信；
• TRACE: 回显服务器收到的请求，主要⽤于测试或诊断。

七、请求报文和响应报文的组成以及常见的请求头和响应头

请求报文

请求报⽂有4部分组成：请求⾏、请求头部、空⾏、请求体

请求头

• A***ept:浏览器能够处理的内容类型
• A***ept-Charset:浏览器能够显示的字符集
• A***ept-Encoding：浏览器能够处理的压缩编码
• A***ept-Language：浏览器当前设置的语言
• Cookie：当前页面设置的任何Cookie
• User-Agent：客户端信息
• Range：实体的字节范围请求
• Authorization：web的认证信息
• Host：发出请求的页面所在的域
  • Host用来实现虚拟主机技术
  • 有一台 ip 地址为 61.135.169.125 的服务器，在这台服务器上部署着百度、淘宝，京东的网站。为什么我们访问www.baidu.***时，看到的是 百度 的首页而不是淘宝或京东的首页？原因就是 Host 请求头决定着访问哪个虚拟主机。如果服务器后台解析出Host但是服务器上找不到相应的站点，那么这个连接很可能会被丢弃，从而报错。
• Origin：当前请求资源所在页面
  • 这个参数一般只存在于CORS跨域请求中，普通请求没有这个header
  • 如果有Origin参数，我们可以看到response有对应的header：A***ess-Control-Allow-Origin
• Referer：发出请求的页面的URL
  • 在 www.google.*** 里有一个 www.baidu.*** 超链接，当点击这个链接跳转到baidu的时候，浏览器向baidu发出的请求信息里就有：Referer=http://www.google.***

响应报文

响应报⽂有4部分组成：响应⾏、响应头、空⾏、响应体

响应头

• Date：表示消息发送的时间
• Location：令客户端重定向的URI
• Server：服务器信息
• Allow：资源可支持http请求的方法
• Connection：浏览器与服务器之间连接的类型
• Connection: keep-alive：复用TCP链接
• Connection: close：不复用TCP链接
• Content-type:表示后面的文档属于什么MIME类型
• application/x-www-form-urlencoded：浏览器的原生 form 表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据。该种方式提交的数据放在 body 里面，数据按照 key1=val1&key2=val2 的方式进行编码，key 和 val 都进行了 URL转码。
• multipart/form-data：该种方式也是一个常见的 POST 提交方式，通常表单上传文件时使用该种方式。
• application/json：服务器消息主体是序列化后的 JSON 字符串。
• text/xml：该种方式主要用来提交 XML 格式的数据。
• Expires：过期的绝对时间
• Cache-Control：过期的相对时间
  • Cache-Control: max-age=315360000 过期的相对时间
  • Cache-Control: no-cache 缓存协商
  • Cache-Control: no-store 不产生任何缓存
  • Cache-Control: public 可以被所有用户缓存（包括终端和CDN等中间代理服务器）
  • Cache-Control: private 只能被浏览器缓存（不允许中继缓存服务器进行缓存）
• set-cookie：设置cookie
  • max-age和expires设置过期时间
  • HttpOnly无法通过document.cookie访问
  • Secure 只能使用https发送 cookie

八、OSI七层模型、TCP/IP五层协议

这里简单放个图片，想深入了解的B站去搜视频看！

• OSI七层模型
• TCP/IP五层协议
  就是在OSI七层模型上进行的一个整合
  
  

九、 GET 和 POST 的区别

• 长度限制
  首先http对get和post是没有做区别限制的 只是请求方法的不同
  但是因为url是一个整体 游览器会为其单独开辟一块内存 当url信息传输到后端之后也会单独开辟一块内存 可能会导致栈溢出 所以游览器对url的长度做出了限制 而get请求是通过url传递数据 这就导致了get请求有长度限制
  同理 其实get请求是可以带body请求体的 但同样游览器会自动屏蔽get请求的请求体 所以get请求的数据只能放在url中 导致了get请求存在长度限制 一般为2K 而post可以放在body请求体中携带数据 所以post 没有数据的长度限制
• 安全性
  因为get请求的数据暴露在url中 相对post而言不安全 ，但其实使用http get和post都是不安全的，post的数据在每一个网络结点都是明文的也是不安全的
  缓存
• get请求会被游览器缓存 但是post不会
  个体请求参数会被保存到游览器历史中但是post不会
• 编码方式
  因为get通过url传递参数 所以只能进行url编码 也就是只接受ASCII字符 但是post没有限制，编码传输的方式很对
  

十、POST 和 PUT 的区别？

• PUT请求是向服务器端发送数据，从而修改数据的内容，但是不会增加数据的种类等，也就是说无论进行多少次PUT操作，其结果并没有不同。（可以理解为时更新数据）
• POST请求是向服务器端发送数据，该请求会改变数据的种类等资源，它会创建新的内容。（可以理解为是创建数据）

十一、PUT和PATCH都是给服务器发送修改资源, 有什么区别?

• PUT和PATCH都是更新资源, 而PATCH用来对已知资源进行局部更新

比如我们有一篇文章的地址https://www.jianshu.***/articles/820357430，这篇文章的可以表示为:

article = {
    author: 'dxy',
    creationDate: '2019-6-12',
    content: '我写文章像蔡徐坤',
    id: 820357430
}

当我们要修改文章的作者时，我们可以直接发送PUT https://www.jianshu.***/articles/820357430，这个时候的数据应该是:

{
    author:'蔡徐坤',
    creationDate: '2019-6-12',
    content: '我写文章像蔡徐坤',
    id: 820357430
}

这种直接覆盖资源的修改方式应该用put，但是你觉得每次都带有这么多无用的信息，那么可以发送PATCH https://www.jianshu.***/articles/820357430，这个时候只需要:

{
    author:'蔡徐坤'
}

十二、OPTIONS请求方法及使用场景

• OPTIONS方法是用于请求获得由Request-URI标识的资源在请求/响应的通信过程中可以使用的功能选项。

• 通过这个方法，客户端可以在采取具体资源请求之前，决定对该资源采取何种必要措施，或者了解服务器的性能
  OPTIONS请求方法的主要用途有两个：

• 获取服务器支持的所有HTTP请求方法；

• 用来检查访问权限。例如：在进行 CORS 跨域资源共享时，对于复杂请求，就是使用 OPTIONS 方法发送嗅探请求，以判断是否有对指定资源的访问权限。

十三、HTTP状态码304是多好还是少好？

服务器为了提高网站访问速度，对之前访问的部分页面指定缓存机制，当客户端在此对这些页面进行请求，服务器会根据缓存内容判断页面与之前是否相同，若相同便直接返回304，此时客户端调用缓存内容，不必进行二次下载。

状态码304不应该认为是一种错误，而是对客户端有缓存情况下服务端的一种响应。

搜索引擎蜘蛛会更加青睐内容源更新频繁的网站。通过特定时间内对网站抓取返回的状态码来调节对该网站的抓取频次。若网站在一定时间内一直处于304的状态，那么蜘蛛可能会降低对网站的抓取次数。相反，若网站变化的频率非常之快，每次抓取都能获取新内容，那么日积月累，的回访率也会提高。

产生较多304状态码的原因：

• 页面更新周期长或不更新
• 纯静态页面或强制生成静态html

304状态码出现过多会造成以下问题：

• 网站快照停止；
• 收录减少；
• 权重下降。

十四、URI、URL、URN

URI

Uniform Resource Identifier，统一资源标识符

它具有两种形式：URN(统一资源名)，URL(统一资源定位符)，也就是说URL和 URN是它的子集

URL

Uniform Resource Locator，统一资源定位符

• protocol: 协议
• host: 资源的域信息（可以是 IP 可以是域名）
• port: 端口号
• path: 路径
• query: 查询字符串，查询参数
• fragment: 片段，哈希或者叫锚点，用户前端文档定位或者路由

URN

Uniform Resource Name，统一资源名称

永久定位资源，不论资源的位置怎么移动，访问同一个URN都能定位到

十五、对 WebSocket 的理解

WebSocket是HTML5提供的一种浏览器与服务器进行全双工通讯的网络技术，属于应用层协议。它基于TCP传输协议，并复用HTTP的握手通道。浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接， 并进行双向数据传输。

WebSocket 的出现就解决了半双工通信的弊端。它最大的特点是：服务器可以向客户端主动推动消息，客户端也可以主动向服务器推送消息。

WebSocket原理：客户端向 WebSocket 服务器通知（notify）一个带有所有接收者ID（recipients IDs）的事件（event），服务器接收后立即通知所有活跃的（active）客户端，只有ID在接收者ID序列中的客户端才会处理这个事件。

WebSocket 特点的如下：

• 支持双向通信，实时性更强可以发送文本，也可以发送二进制数据‘’
• 建立在TCP协议之上，服务端的实现比较容易
• 数据格式比较轻量，性能开销小，通信高效
• 没有同源限制，客户端可以与任意服务器通信
• 协议标识符是ws（如果加密，则为wss），服务器网址就是 URL
• 与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。

十六、前端即时通讯

• 短轮询: 每隔一段时间客户端就发出一个请求, 去获取服务器最新的数据, 一定程度上模拟实现了即时通讯
  • 优点: 兼容性强,实现简单
  • 缺点: 延迟性高, 非常消耗服务器资源
• 长轮询:
  • 优点: 兼容性好, 和段轮询比资源浪费较小
  • 缺点: 服务器hold连接会消耗资源, 返回数据顺序无保证, 难于管理维护
• 长连接:
  • 优点: 兼容性好, 消息即时到达, 不发无用请求
  • 缺点: 服务器维护长连接消耗资源
• 服务端推送
  • 优点: 基于HTTP2, 因此不需要太多改造就能使用, 使用方便
  • 缺点: 基于文本传输效率没有websocket高, 不是严格的双向通信, 客户端向服务端发送请求无法复用之前的连接, 需要重新发出独立的请求
• websocket:
  • Websocket是一个全新的、独立的协议, 基于TCP协议
• Web Worker:
  • Web Worker的作用, 就是为 JavaScript创造多线程环境, 允许主线程创建Worker 线程, 将一些任务分配给后者运行

十七、TCP和UDP的区别