WEB相关

1.常用的状态码

2XX 成功

200 ok（请求成功）是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。
204 no content （请求成功，但是没有结果返回）
206 partial content （客户端请求一部分资源，服务端成功响应，返回一范围资源）

3XX 重定向

类状态码表示客户端请求的资源发送了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

301 move permanently （永久性重定向）说明请求的资源已经不存在了，需改用新的 URL 再次访问。
302 found （临时性重定向）说明请求的资源还在，但暂时需要用另一个 URL 来访问。
301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。
303 see other （示由于请求对应的资源存在着另一个 URI，应使用 GET
方法定向获取请求的资源）
304 not modified （不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制）

4XX 客户端错误

400 bad request （请求报文存在语法错误）
401 unauthorized （需要认证（第一次返回）或者认证失败（第二次返回））
403 forbidden （表示服务器禁止访问资源，并不是客户端的请求出错）
404 not found （表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端）

5XX 服务器错误

5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

500 internal server error （服务端执行请求时发生了错误）
503 service unavailable （服务器正在超负载或者停机维护，无法处理请求）

2.post 与 get

区别一：
get重点在从服务器上获取资源。
post重点在向服务器发送数据。
区别二：
get传输数据是通过URL请求，以field（字段）= value的形式，置于URL后，并用"?“连接，多个请求数据间用”&"连接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，这个过程用户是可见的。
post传输数据通过Http的post机制，将字段与对应值封存在请求实体中发送给服务器，这个过程对用户是不可见的。
区别三：
Get传输的数据量小，因为受URL长度限制，但效率较高。
Post可以传输大量数据，所以上传文件时只能用Post方式。
区别四：
get是不安全的，因为URL是可见的，可能会泄露私密信息，如密码等。
post较get安全性较高。
区别五：
get方式只能支持ASCII字符，向服务器传的中文字符可能会乱码。
post支持标准字符集，可以正确传递中文字符。
什么时候应该使用GET什么时候应该使用POST
对于信息的获取一般使用get,在以下情况下最好使用post请求:

向服务器发送大量数据
无法使用缓存文件
发送包含未知字符的用户输入时

http头部有哪些信息

答案

3. Http协议有什么组成

请求报文包含三部分：

• 请求行：包含请求方法、URI、HTTP版本信息

• 请求首部字段

• 请求内容实体
  响应报文包含三部分：

• 状态行：包含HTTP版本、状态码、状态码的原因短语

• 响应首部字段

• 响应内容实体

4.网络传输的过程

5. Http协议中有那些请求方式？

• GET： 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器
• POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
• PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。
• HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
• DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
• OPTIONS：查询相应URI支持的HTTP方法。

6.http常见字段

• Host：客户端发送请求时，用来指定服务器的域名
• Content-Length 字段：表明本次回应的数据长度
• Connection 字段：用于客户端要求服务器使用 TCP 持久连接，以便其他请求复用。HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。Connection: keep-alive一个可以复用的 TCP 连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段。
• Content-Type ：字段用于服务器回应时，告诉客户端，本次数据是什么格式。Content-Type: text/html;
• charset=utf-8，上面的类型表明，发送的是网页，而且编码是UTF-8。客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。Accept: */*上面代码中，客户端声明自己可以接受任何格式的数据。
• Content-Encoding 字段：说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式Content-Encoding: gzip上面表示服务器返回的数据采用了 gzip 方式压缩，告知客户端需要用此方式解压。客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。Accept-Encoding: gzip,

7.什么是Http协议无状态协议？怎么解决Http协议无状态协议？

• 无状态协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息
• 无状态协议解决办法： 通过1、Cookie 2、通过Session会话保存。

8. http缓存

两种类型：即强缓存（也叫本地缓存）和协商缓存
区别：

机制
缓存行为主要由缓存策略决定，而缓存策略由内容拥有者设置。这些策略主要通过特定的HTTP头部来表达。 当一个用户发起一个静态资源请求的时候，浏览器会通过三个阶段来获取资源：

本地缓存阶段：先在本地查找该资源，如果有发现该资源，而且该资源还没有过期，就使用这一个资源，完全不会发送http请求到服务器；

协商缓存阶段：如果在本地缓存找到对应的资源，但是不知道该资源是否过期或者已经过期，则发一个http请求到服务器,然后服务器判断这个请求，如果请求的资源在服务器上没有改动过，则返回304，让浏览器使用本地找到的那个资源；

缓存失败阶段：当服务器发现请求的资源已经修改过，或者这是一个新的请求(在本来没有找到资源)，服务器则返回该资源的数据，并且返回200， 当然这个是指找到资源的情况下，如果服务器上没有这个资源，则返回404。

缓存状态码
200 OK (from cache) 是浏览器没有跟服务器确认，直接用了浏览器缓存； 304 Not Modified 是浏览器和服务器多确认了一次缓存有效性，再用的缓存。 304 Not Modified 比 200 OK (from cache) 慢，指的是浏览器还向服务器确认了下 “If-Not-Modified”，才用的缓存。
参考

8. httpx.x

http1.0

是一种无状态、无连接的应用层协议,每个请求都会新创建一个tcp连接,完成后关闭服务端不跟踪也不记录过去的请求(无状态),但正因频繁创建连接,由于tcp的慢启动(为了不给网络造成拥堵,在首次进行tcp请求的时候,会限制服务端和客户端之间交互数据量的上限,大概为14kb,之后以指数级增长),服务端接受请求,处理完,发送完响应之后就会将tcp连接关闭,这造成了很大的资源浪费,而且http1.0在一个请求接收到响应之后才会接着发送下一个,这也造成了head of line blocking(队头阻塞),现在的浏览器为了解决这个问题,采用了一个页面可以建立多个tcp连接的方式来进行

http1.1

继承了http1.0的特点,同时改善了http的一些问题,首先是长连接,http1.1新增加了connecion字段,里面可以设置keey-Alive(保持连接)或者close(关闭长连接),避免了每次请求都会新建连接,提高了网络的利用率
http1.1还增加了Host字段,用来明确表示浏览器要服务器上的哪一个WEB站点,这才实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点,同时还支持了断点续传
http1.1的管道:可以发送很多请求到服务端,但是服务端必须要按顺序返回响应,由此可以看出http1.1的管道只是把客户端的请求序列变成了服务端的响应序列,还是有问题,很多浏览器并不是很支持
http1.1还增加了缓存,断点续传

http2.0

采用了二进制分帧(frame),在应用层和传输层之间增加了一个二进制分帧层,也就是把http1.x的header和body使用帧(frame)进行了封装
这里明确几个概念:流(stream) : 已经建立上连接的双向字节流(也就是一个请求和其对应的响应) 消息:与逻辑消息对应的完整的一系列数据帧 帧(frame):http2.0进行通信的最小单位,每个帧都会包含一个头部,这个头部会包含当前帧所处的流
多路复用:所有的HTTP2.0通信都在一个TCP连接上完成，这个连接可以承载任意数量的双向数据流,每个数据流都以消息的方式进行发送,这个发送可以使乱序的,然后在通过每个帧头部的流标识符进行组装,同时每个数据流都可以设置优先级,可见http2.0真正实现了并行发送数据,这个是给予二进制分帧来实现的,接下来上一张图片,展示一下一个在一个流中分帧传输的实例

头部压缩:就是和服务端约定头部的数据的编码,来将头部进行压缩后发送,这样就可以增加请求头的容量
小结：这里讲的稍微有一点多,这里给一个总结

http1.0:无连接,无状态,一次请求一个tcp连接
http1.1:持久连接,请求管道化(有一些缺陷) ,增加了host字段,缓存,断点续传
http2.0 : 二进制分帧(多路复用的实现基础), 多路复用,头部压缩

HTTP/2 存在的问题

我们知道，传统 Web 平台的数据传输都基于 TCP 协议，而 TCP 协议在创建连接之前不可避免的需要三次握手，如果需要提高数据交互的安全性，即增加传输层安全协议（TLS），还会增加更多的握手次数。 HTTP 从 1.0 到 2.0，其传输层都是基于 TCP 协议的。即使是带来巨大性能提升的 HTTP/2，也无法完全解决 TCP 协议存在的固有问题（慢启动，拥塞窗口尺寸的设置等）。此外，HTTP/2 多路复用只是减少了连接数，其队头的拥塞问题并没有完全解决，倘若 TCP 丢包率过大，则 HTTP/2 的表现将不如 HTTP/1.1。

HTTP/3

队头阻塞问题（HTTP3为什么用UDP）

队头阻塞 就是：一个数据包影响了一堆数据包，它不来大家都走不了。

队头阻塞问题可能存在于HTTP层和TCP层，在HTTP1.x时两个层次都存在该问题。

HTTP2.0协议的多路复用机制解决了HTTP层的队头阻塞问题，但是在TCP层仍然存在队头阻塞问题。

TCP协议在收到数据包之后，这部分数据可能是乱序到达的，但是TCP必须将所有数据收集排序整合后给上层使用，如果其中某个包丢失了，就必须等待重传，从而出现某个丢包数据阻塞整个连接的数据使用。

QUIC协议是基于UDP协议实现的，在一条链接上可以有多个流，流与流之间是互不影响的，当一个流出现丢包影响范围非常小，从而解决队头阻塞问题。

QUIC 协议

QUIC（Quick UDP Internet Connections），直译为快速 UDP 网络连接，是谷歌制定的一种基于 UDP 的低延迟传输协议。其主要目的是解决采用传输层 TCP 协议存在的问题，同时满足传输层和应用层对多连接、低延迟等的需求。该协议融合了 TCP, TLS, HTTP/2 等协议的特性，并基于 UDP传输。该协议带来的主要提升有：

低延迟连接。当客户端第一次连接服务器时，QUIC 只需要 1 RTT（Round-Trid Time）延迟就可以建立安全可靠的连接（采用 TLS 1.3 版本），相比于 TCP + TLS 的 3 次 RTT 要更加快捷。之后，客户端可以在本地缓存加密的认证信息，当再次与服务器建立连接时可以实现 0 RTT 的连接建立延迟。

QUIC 复用了 HTTP/2 协议的多路复用功能，由于 QUIC 基于 UDP，所以也避免了 HTTP/2存在的队头阻塞问题。

基于 UDP 协议的 QUIC 运行在用户域而不是系统内核，这使得 QUIC 协议可以快速的更新和部署，从而很好地解决了 TPC 协议部署及更新的困难。

QUIC 的报文是经过加密和认证的，除了少量的报文，其它所有的 QUIC 报文头部都经过了认证，报文主体经过了加密。只要有攻击者篡改 QUIC 报文，接收端都能及时发现。

具有向前纠错机制，每个数据包携带了除了本身内容外的部分其他数据包的内容，使得在出现少量丢包的情况下，尽量地减少其它包的重传次数，其通过牺牲单个包所携带的有效数据大小换来更少的重传次数，这在丢包数量较小的场景下能够带来一定程度的性能提升。

HTTP/3

HTTP/3 是在 QUIC 基础上发展起来的，其底层使用 UDP 进行数据传输，上层仍然使用 HTTP/2。在 UDP 与 HTTP/2 之间存在一个 QUIC 层，其中 TLS 加密过程在该层进行处理。HTTP/3 主要有以下几个特点：

① 使用 UDP 作为传输层进行通信；

② 在 UDP 之上的 QUIC 协议保证了 HTTP/3 的安全性。QUIC 在建立连接的过程中就完成了 TLS 加密握手；

③ 建立连接快，正常只需要 1 RTT 即可建立连接。如果有缓存之前的会话信息，则直接验证和建立连接，此过程 0 RTT。建立连接时，也可以带有少量业务数据；

④ 不和具体底层连接绑定，QUIC 为每个连接的两端分别分配了一个唯一 ID，上层连接只认这对逻辑 ID。网络切换或者断连时，只需要继续发送数据包即可完成连接的建立；

⑤ 使用 QPACK 进行头部压缩，因为 在 HTTP/2 中的 HPACK 要求传输过程有序，这会导致队头阻塞，而 QPACK 不存在这个问题。

9.https与http

Http与Https的基本概念和他们的区别
http的中文叫做超文本传输协议,它负责完成客户端到服务端的一系列操作,是专门用来传输注入HTML的超媒体文档等web内容的协议,它是基于传输层的TCP协议的应用层协议
https:https是基于安全套接字的http协议,也可以理解为是http+ssl/tls(数字证书)的组合

http和https的区别

HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头
HTTP 是不安全的，而 HTTPS 是安全的
HTTP 标准端口是 80 ，而 HTTPS 的标准端口是 443
在 OSI 网络模型中，HTTPS的加密是在传输层完成的,因为SSL是位于传输层的,TLS的前身是SSL,所以同理
HTTP无需认证证书,而https需要认证证书
小结：简单来说http是用来进行html等超媒体传输的,但是http不安全,为了安全,使用证书SSL和HTTP的方式进行数据传输,也就是HTTPS

http 工作原理

HTTP（Hyper Text Transfer Protocol: 超文本传输协议） 是一种简单的请求 - 响应协议，被用于在 Web 浏览器和网站服务器之间传递消息。HTTP 使用 TCP（而不是 UDP）作为它的支撑运输层协议。其默认工作在 TCP 协议 80 端口，HTTP 客户机发起一个与服务器的 TCP 连接，一旦连接建立，浏览器和服务器进程就可以通过套接字接口访问 TCP。客户机从套接字接口发送 HTTP 请求报文和接收 HTTP 响应报文。类似地，服务器也是从套接字接口接收 HTTP 请求报文和发送 HTTP 响应报文。其通信内容以明文的方式发送，不通过任何方式的数据加密。当通信结束时，客户端与服务器关闭连接。

HTTPS工作原理

服务器端的公钥和私钥，用来进行非对称加密

客户端生成的随机密钥，用来进行对称加密

一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。
1.客户端向服务器发起HTTPS请求，连接到服务器的443端口

2.服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。

3.服务器将自己的公钥发送给客户端。

4.客户端收到服务器端的证书之后，会对证书进行检查，验证其合法性，如果发现发现证书有问题，那么HTTPS传输就无法继续。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。

5.客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。

6.服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。

7.然后服务器将加密后的密文发送给客户端。

8.客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

对称加密

这种方式加密和解密同用一个密钥。加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。

以对称加密方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落人攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

非对称加密

使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

特点：
是信息传输一对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信。

缺点：
公钥是公开的，所以针对私钥加密的信息，黑客截获后可以使用公钥进行解密，获取其中的内容；
公钥并不包含服务器的信息，使用非对称加密算法无法确保服务器身份的合法性，存在中间人攻击的风险，服务器发送给客户端的公钥可能在传送过程中被中间人截获并篡改；
使用非对称加密在数据加密解密过程需要消耗一定时间，降低了数据传输效率；

对称加密+非对称加密(HTTPS采用这种方式)

使用对称密钥的好处是解密的效率比较快，使用非对称密钥的好处是可以使得传输的内容不能被破解，因为就算你拦截到了数据，但是没有对应的私钥，也是不能破解内容的。就比如说你抢到了一个保险柜，但是没有保险柜的钥匙也不能打开保险柜。那我们就将对称加密与非对称加密结合起来,充分利用两者各自的优势，在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。

具体做法是：发送密文的一方使用对方的公钥进行加密处理“对称的密钥”，然后对方用自己的私钥解密拿到“对称的密钥”，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信。所以，HTTPS采用对称加密和非对称加密两者并用的混合加密机制。
参考

RSA加密算法（公私钥如何产生）

RSA算法是一种非对称的加密算法，它通常是先生成一对RSA密钥，其中之一是保密密钥（私钥），由用户保存；另一个为公开密钥（公钥），
可对外公开；要加密传输内容时，比如A要给B传输信息，此时A先用B的公钥将内容加密后传输，B收到A传输过来的信息后用自己的私钥解密.该过程中，只要B不泄露自己的私钥，那么就算第三方截取到了该信息，没有B的私钥也无法解密获得内容信息.
参考

数字签名

数字签名有两种功效：
能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
数字签名能确定消息的完整性,证明数据是否未被篡改过。

数字签名如何生成

将一段文本先用Hash函数生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文文一起传送给接收者。接下来就是接收者校验数字签名的流程了。

校验数字签名流程（如何验证未被篡改）

接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

什么是数字证书

它是由一个权威机构——CA证书授权(Certificate Authority)中心发行的，人们可以在互联网交往中用它来识别对方的身份。即以数字证书为核心的加密技术可以对网络上传输的信息进行加密和解密、数字签名和签名验证，确保网上传递信息的机密性、完整性，以及交易实体身份的真实性，签名信息的不可否认性。当然在数字证书认证的过程中，数字证书认证中心（CA）作为权威的、公正的、 可信赖的第三方，其作用是至关重要的。数字证书也必须具有唯一性和可靠性。

数字证书的原理

数字证书采用公钥密码体制，即利用一对互相匹配的密钥进行加密、解密。每个用户拥有一把仅为本人所掌握的私有密钥（私钥），用它进行解密和签名；同时拥有一把公共密钥（公钥）并可以对外公开，用于加密和验证签名。当发送一份保密文件时，发送方使用接收方的公钥对数据加密，而接收方则使用自己的私钥解密，这样，信息就可以安全无误地到达目的地了，即使被第三方截获，由于没有相应的私钥，也无法进行解密。通过数字的手段保证加密过程是一个不可逆过程，即只有用私有密钥才能解密。在公开密钥密码体制中，常用的一种是RSA体制。

用户也可以采用自己的私钥对信息加以处理，由于密钥仅为本人所有，这样就产生了别人无法生成的文件，也就形成了数字签名。采用数字签名，能够确认以下两点： （1）保证信息是由签名者自己签名发送的，签名者不能否认或难以否认； （2）保证信息自签发后到收到为止未曾作过任何修改，签发的文件是真实文件。

数字证书的作用

数字证书可用于发送安全电子邮件、访问安全站点、网上证券、网上招标采购、网上签约、网上办公、网上缴费、网上税务等网上安全电子事务处理和安全电子交易活动。数字证书的格式一般采用X.509国际标准。

数字证书认证机构（CA）的业务流程

• 服务器的运营人员向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;
• CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
• 如信息审核通过，CA会向申请者签发认证文件-证书。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。 其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名;
• 客户端 Client 向服务器 Server 发出请求时，Server 返回证书文件;
• 客户端 Client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。
• 客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。

数字证书的功能

一、信息保密性交易中的商务信息均有保密的要求。如信用卡的帐号和用户名被人知悉，就可能被盗用，订货和付款的信息被竞争对手获悉，就可能丧失商机。而CA中心颁发的数字安全证书保证了电子商务的信息传播中信息的保密。
二、身份确定性网上交易的双方很可能素昧平生，相隔千里。要使交易成功首先要能确认对方的身份，对商家要考虑 客户端不能是骗子，而客户也会担心网上的商店不是一个玩弄欺诈的黑店。因此能方便而可靠地确认对方身份是交易的前提。对于为顾客或用户开展服务的银行、信用卡公司和销售商店，为了做到安全、保密、可靠地开展服务活动，都要进行身份认证的工作。而CA中心颁发的电子签名可保证网上交易双方的身份，银行和信用卡公司可以通过CA认证确认身份，放心的开展网上业务。
三、不可否认性由于商情的千变万化，交易一旦达成是不能被否认的。否则必然会损害一方的利益。例如订购黄金， 订货时金价较低，但收到订单后，金价上涨了，如收单方能否认受到订单的实际时间，甚至否认收到订单的事实，则订货方就会蒙受损失。因此CA中心颁发的数字安全证书确保了电子交易通信过程的各个环节的不可否认性，使交易双方的利益不受到损害。
四、不可篡改性交易的文件是不可被修改的，如上例所举的订购黄金。供货单位在收到订单后，发现金价大幅上涨了，如其能改动文件内容，将订购数1吨改为1克，则可大幅受益，那么订货单位可能就会因此而蒙受损失。 因此CA中心颁发的数字安全证书也确保了电子交易文件的不可修改性，以保障交易的严肃和公正。

10.WebSocket

Websocket是基于Http协议的，或者说借用了Http协议来完成一部分握手，在一次websocket握手中，消息头Header中，Connection字段为Upgrade，Upgrade字段为websocket，这个地方就是websocket核心，说明要使用websocket协议。
Ajax和long poll都是轮询，只是ajax异步，而long poll使用的是阻塞同步，但是共同点都体现在http协议的被动，只能客户端主动联系，服务器不能主动联系。当http协议升级到websocket之后，http这种无状态协议的弊端就被websocket协议给弥补了，也就是说服务端可以给客户端推送消息了。

11. Cookie干嘛用，和Session的区别

Cookie和session都是应对http协议是个无状态协议的办法。因为http协议无状态，所以每次回话结束，都不会存储上次回话的信息，而如果能够保存此会话就会省去大量的查库操作。
Cookie存在客户端，客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
Session和cookie的功能类似，存储在服务器中，类似一个用户表，当用户访问网站，会先访问session，如果session中存有用户信息，则可以跳过一些操作。Session会随着用户的信息更新而更新，存储在服务器的内存中。Session有自己的有效期。

12. URI、URL和URN之间的区别

URI全名为Uniform Resource Indentifier（统一资源标识），用来唯一的标识一个资源，是一个通用的概念，URI由两个主要的子集URL和URN组成

URL全名为Uniform Resource Locator（统一资源定位），通过描述资源的位置来标识资源

URN全名为Uniform Resource Name（统一资源命名），通过资源的名字来标识资源，与其所处的位置无关，这样即使资源的位置发生变动，其URN也不会变化

HTTP规范将更通用的概念URI作为其资源标识符，但是实际上，HTTP应用程序处理的只是URI的URL子集

13.从输入URL到页面加载发生了什么

1）首先在地址栏输入一个url，查找一下有没有历史记录，有没有缓存，如果有就展示页面。
2）DNS解析。首先浏览器会查看本地硬盘的hosts文件，看看其中有没有和这个域名对应的规则，如果有就直接使用Hosts文件里面的Ip地址。如果没有找到对应的IP地址，浏览器会发出一个DNS请求到本地DNS服务器。本地DNS服务器会首先查询缓存记录，如果有就直接返回结果，此过程是递归查询，如果没有，本地服务器向DNS服务器进行查询，根DNS服务器没有记录具体的域名和IP地址的对应关系，而是告诉本地DNS服务器，你可以到昱服务器上去继续查询，并给出服务器地址，这里采用的是迭代查询。最后，本地服务器向域名的解析服务器发出请求，这时就能收到一个域名和IP地址对应关系，本地DNS服务器就把IP地址返回给用户，同时进行缓存。
3）建立TCP连接（三次握手）。首先，客户端将SYN设置为1，随机产生一个seq=j的数据包发送到服务器，客户端A进入SYN-SENT状态，等待服务器端B的确认；其次，服务端B收到数据包后给客户端一个响应，此时SYN=1,ACK=1，随机产生一个seq=k，ack=j+1；并将该数据包发送给客户端A确认连接，服务器进入SYN_RCVD状态。最后，客户端A收到确认后，客户端A给服务器端一个确认，此时ACK=1,seq = j+1,ack = k+1，服务端和客户端进入ESTABLISHED状态。然后就可以开始传输数据了。
常考：三次握手是为了防止已失效的连接请求报文端突然又传送到服务器端，因而产生错误。
4）客户端发送HTTP请求。（包括请求头）
5）服务器处理请求。后端从固定的端口接收到TCP报文开始，它会对TCP连接进行处理，对HTTP协议进行解析，并按照报文格式进一步封装成HTTP Request对象，供上层使用。客户端不是直接通过HTTP协议访问某网站应用服务器，而是先请求到Nginx，Nginx再请求应用服务器，然后将结果返回给客户端，这里Nginx的作用是反向代理服务器。
6）服务器返回HTTP响应。（状态行，响应头，响应正文）
7）浏览器展示HTML。解析html以构建dom树（自上而下加载，并在加载过程中进行解析渲染，在解析过程中，如果遇到请求外部资源时，如图片、外链的CSS、iconfont等，请求过程是异步的，并不会影响html文档进行加载。） -> 构建render树 -> 布局render树 -> 绘制render树.在这个过程中可能会引起重流和重绘，因为他们会消耗性能，所以我们要减少reflow和repain。在加载过程中遇到js时，会挂起渲染的线程，不仅要等文档中js文件加载完毕，还要等待解析完毕，才可以恢复HTML文档的渲染线程。所以我们要尽量把js放到尾部。

8）断开TCP连接（四次挥手）。
现在A和B都处于ESTABLISHED状态，A应用进程先向TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接，此时报文首部FIN=1，其序号seq=u，这时A处于FIN_WAIT-1状态，等待B确认。
B收到释放连接报文段后即发出确认，确认号ack=u+1,而这个报文段的字号是v，此时B进入CLOSE_WAIT状态。此时A到B的连接就释放了，TCP处于半关闭状态，即A已经没有数据要发送了，但若B要发送数据，A仍要接收，说明B到A没有关闭。
A收到来自B的确认后，就进入FIN_wait-2状态，等待B发出的连接释放报文段。若B已经没有向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的释放报文段FIN=1，此时B进入LAST_ACK状态，等待A确认。
A在收到B的释放报文段后，必须对此发出确认。确认报文段中ACK=1，此时A进入到TIME-WAIT状态，此时TCP连接还没有释放掉，在经过2MSL（最长报文段寿命）后，A才进入closed。
可能会问：为什么A在TIME-WAIT状态必须等待2MSL的时间呢？
（1）为了保证A发送的最后一个ACK报文段能够到达B。
（2）为了防止已失效的请求报文段出现在本连接中。

NOTE:B结束TCP连接的时间要比A早一些。B只要收到A的确认，就进入closed状态，同样，B在撤销相应的传输控制块TCB后，就结束了这次TCP连接。

14. 跨域

14.1 什么是跨域

一个url是由：协议、域名、端口 三部分组成。当一个请求url的协议、域名、端口三者之间的任意一个与当前页面url不同被称为跨域。
原因：
由于浏览器的同源策略限制。它会阻止一个域的js脚本和另外一个域的内容进行交互，如果缺少了同源策略，浏览器很容易受到攻击，比如一个恶意网站的页面通过iframe嵌入了银行的登录页面（二者不同源），如果没有同源限制，恶意网页上的javascript脚本就可以在用户登录银行的时候获取用户名和密码。
同源策略的限制：
无法读取非同源网页的cookie、localstorage等
无法接触非同源网页的DOM和js对象
无法向非同源地址发送Ajax请求

14.2 跨域的解决

• nginx反向代理解决跨域（前端常用）
  服务器之间不存在跨域问题，可以用nginx反向代理解决跨域，
  客户端请求代理服务器，代理服务器将请求转发给内部网络上的服务器；并将从服务器上得到的结果返回给客户端。

• cookie：设置document.domain共享cookie。

• DOM获取：（父子页面通信）H5引入了一个API，这个API为windows对象新增了一个window.postMessage方法，允许跨窗口通信，无论这两个窗口是否同源。
  window.opener.postMessage(content,origin)
  content是消息的具体内容，origin是协议 + 域名 + 端口

• JSONP：JSONP是服务器无客户端跨源通信的常用方法。基本思想是网页通过添加一个<script>元素，向服务器请求json数据，这种做法不受同源政策的限制，服务器收到请求后，将数据放在一个指定名字的回调函数里面传回来。（只能发GET请求）

• WebSocket：WebSocket是一种通信协议。使用ws://（非加密）和wss://（加密）作为协议前缀。该协议不实行同源政策，只要服务器支持，就可以通过它进行跨源通信。

• CORS
  跨域资源共享（Cross-origin resource sharing),CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，只要服务器实现了CORS接口，就可以跨源通信。
  浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）
  （1) 请求方法：HEAD GET POST
  （2）HTTP的头信息是：Accept 、Accept-Language、 Content-Language、 Last-Event-ID
  （3）Content-Type：是application/x-www-form-urlencoded、multipart/form-data、text/plain属于非简单请求。

  对于简单请求，浏览器在发出CORS请求时会在头信息之中增加一个Origin字段。服务器的返回会多出3个字段：

  Access-Control-Allow-Origin(必须) 允许跨域的源

  Access-Control-Allow-Credentials(可选) 表示是否允许发送Cookie。默认情况下，Cookie可以包含在请求中，一起发给服务器如果服务器不需要浏览器发送Cookie，删除该字段即可。

  Access-Control-Expose-Headers(可选) CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：
  Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。如指定Access-Control-Expose-Headers: FooBar，则可通过getResponseHeader(‘FooBar’)获取FooBar字段的值。

  非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。
  非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。
  "预检"请求用的请求方法是OPTIONS，表示这个请求是用来询问的。头信息里面，关键字段是Origin，表示请求来自哪个源。
  浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。

RPC

RPC概念

RPC 即远程过程调用（Remote Procedure Call Protocol，简称RPC），像调用本地服务(方法)一样调用服务器的服务(方法)。通常的实现有 XML-RPC , JSON-RPC , 通信方式基本相同, 所不同的只是传输数据的格式.RPC是分布式架构的核心，

按响应方式分如下两种：

同步调用：客户端调用服务方方法，等待直到服务方返回结果或者超时，再继续自己的操作

异步调用：客户端把消息发送给中间件，不再等待服务端返回，直接继续自己的操作。

同步调用的实现方式有WebService和RMI。Web Service提供的服务是基于web容器的，底层使用http协议，因而适合不同语言异构系统间的调用。RMI实际上是Java语言的RPC实现，允许方法返回 Java 对象以及基本数据类型，适合用于JAVA语言构建的不同系统间的调用。

异步调用的JAVA实现版就是JMS(Java Message Service)，目前开源的的JMS中间件有Apache社区的ActiveMQ、Kafka消息中间件，另外有阿里的RocketMQ。

RPC架构里包含如下4个组件:

客户端(Client)：服务调用方

客户端存根(Client Stub)：存放服务端地址信息，将客户端的请求参数打包成网络消息，再通过网络发送给服务方

服务端存根(Server Stub)：接受客户端发送过来的消息并解包，再调用本地服务

服务端(Server)：真正的服务提供者。

具体实现步骤：

服务调用方（client）(客户端)以本地调用方式调用服务；

client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；在Java里就是序列化的过程

client stub找到服务地址，并将消息通过网络发送到服务端；

server stub收到消息后进行解码,在Java里就是反序列化的过程；

server stub根据解码结果调用本地的服务；

本地服务执行处理逻辑；

本地服务将结果返回给server stub；

server stub将返回结果打包成消息，Java里的序列化；

server stub将打包后的消息通过网络并发送至消费方

client stub接收到消息，并进行解码, Java里的反序列化；

服务调用方（client）得到最终结果。

RPC框架的目标就是把2-10步封装起来，把调用、编码/解码的过程封装起来，让用户像调用本地服务一样的调用远程服务。要做到对客户端（调用方）透明化服务， RPC框架需要考虑解决如下问题：

通讯问题 : 主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。

寻址问题 ： A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。

序列化与反序列化 ： 当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给B服务器。 同理，B服务器接收参数要将参数反序列化。B服务器应用调用自己的方法处理后返回的结果也要序列化给A服务器，A服务器接收也要经过反序列化的过程。

REST

REST即表述性状态传递（Representational State Transfer，简称REST），是一种软件架构风格。REST通过HTTP协议定义的通用动词方法(GET、PUT、DELETE、POST) ，以URI对网络资源进行唯一标识，响应端根据请求端的不同需求，通过无状态通信，对其请求的资源进行表述。

Rest架构的主要原则：
网络上的所有事物都被抽象为资源

每个资源都有一个唯一的资源标识符

同一个资源具有多种表现形式(xml,json等)

对资源的各种操作不会改变资源标识符

所有的操作都是无状态的

其中表述性状态，是指(在某个瞬间状态的)资源数据的快照，包括资源数据的内容、表述格式(XML、JSON)等信息。

其中无状态通信，是指服务端(响应端)不保存任何与特定HTTP请求相关的资源，应用状态必须由请求方在请求过程中提供。要求在网络通信过程中，任意一个Web请求必须与其他请求隔离，当请求端提出请求时，请求本身包含了响应端为响应这一请求所需的全部信息。

REST使用HTTP+URI+XML /JSON 的技术来实现其API要求的架构风格：HTTP协议和URI用于统一接口和定位资源，文本、二进制流、XML、JSON等格式用来作为资源的表述。

举例：

在Restful之前的操作： 请求的地址对应具体的业务操作
http://127.0.0.1/user/query/1 GET 根据用户id查询用户数据
http://127.0.0.1/user/save POST 新增用户
http://127.0.0.1/user/update POST 修改用户信息
http://127.0.0.1/user/delete GET/POST 删除用户信息

RESTful用法： 请求类型决定操作
http://127.0.0.1/user/1 GET 根据用户id查询用户数据
http://127.0.0.1/user POST 新增用户
http://127.0.0.1/user PUT 修改用户信息
http://127.0.0.1/user DELETE 删除用户信息

RESTful风格的体现，在你使用了get请求，就是查询；使用post请求,就是新增的请求；使用put请求，就是修改的请求；使用delete请求，就是删除的请求。这样做就完全没有必要对crud做具体的描述。

满足REST约束条件和原则的架构，就被称为是RESTful架构。就像URL都是URI(统一资源标识)的表现形式一样，RESTful是符合REST原则的表现形式。