前端面试大全服务端

前端面试题大全(服务端)

前端面试题类目分类

  • HTML5 + CSS3
  • JavaScript
  • Vue + Vue3
  • React
  • Webpack
  • 服务端

考点频率 :♥︎ 、 ♥︎ ♥︎、 ♥︎ ♥︎ ♥︎、 ♥︎ ♥︎ ♥︎ ♥︎、 ♥︎ ♥︎ ♥︎ ♥︎ ♥︎

服务端

♥︎ ♥︎ ♥︎ http状态码有哪些

http状态码的作用是服务器告诉客户端当前请求响应的状态,通过状态码就能判断和分析服务器的运行状态

状态码第一位数字决定了不同的响应状态,有如下:

  • 1 表示消息
  • 2 表示成功
  • 3 表示重定向
  • 4 表示请求错误
  • 5 表示服务器错误

1xx

代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束

常见的有:

  • 100(客户端继续发送请求,这是临时响应):这个临时响应是用来通知客户端它的部分请求已经被服务器接收,且仍未被拒绝。客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应
  • 101:服务器根据客户端的请求切换协议,主要用于websocket或http2升级

2xx

代表请求已成功被服务器接收、理解、并接受

常见的有:

  • 200(成功):请求已成功,请求所希望的响应头或数据体将随此响应返回
  • 201(已创建):请求成功并且服务器创建了新的资源
  • 202(已创建):服务器已经接收请求,但尚未处理
  • 203(非授权信息):服务器已成功处理请求,但返回的信息可能来自另一来源
  • 204(无内容):服务器成功处理请求,但没有返回任何内容
  • 205(重置内容):服务器成功处理请求,但没有返回任何内容
  • 206(部分内容):服务器成功处理了部分请求

3xx

表示要完成请求,需要进一步操作。 通常,这些状态代码用来重定向

常见的有:

  • 300(多种选择):针对请求,服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作,或提供操作列表供请求者选择
  • 301(永久移动):请求的网页已永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置
  • 302(临时移动): 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求
  • 303(查看其他位置):请求者应当对不同的位置使用单独的 GET 请求来检索响应时,服务器返回此代码
  • 305 (使用代理): 请求者只能使用代理访问请求的网页。 如果服务器返回此响应,还表示请求者应使用代理
  • 307 (临时重定向): 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求

4xx

代表了客户端看起来可能发生了错误,妨碍了服务器的处理

常见的有:

  • 400(错误请求): 服务器不理解请求的语法
  • 401(未授权): 请求要求身份验证。 对于需要登录的网页,服务器可能返回此响应。
  • 403(禁止): 服务器拒绝请求
  • 404(未找到): 服务器找不到请求的网页
  • 405(方法禁用): 禁用请求中指定的方法
  • 406(不接受): 无法使用请求的内容特性响应请求的网页
  • 407(需要代理授权): 此状态代码与 401(未授权)类似,但指定请求者应当授权使用代理
  • 408(请求超时): 服务器等候请求时发生超时

5xx

表示服务器无法完成明显有效的请求。这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生

常见的有:

  • 500(服务器内部错误):服务器遇到错误,无法完成请求
  • 501(尚未实施):服务器不具备完成请求的功能。 例如,服务器无法识别请求方法时可能会返回此代码
  • 502(错误网关): 服务器作为网关或代理,从上游服务器收到无效响应
  • 503(服务不可用): 服务器目前无法使用(由于超载或停机维护)
  • 504(网关超时): 服务器作为网关或代理,但是没有及时从上游服务器收到请求
  • 505(HTTP 版本不受支持): 服务器不支持请求中所用的 HTTP 协议版本

下面给出一些状态码的适用场景:

  • 100:客户端在发送POST数据给服务器前,征询服务器情况,看服务器是否处理POST的数据,如果不处理,客户端则不上传POST数据,如果处理,则POST上传数据。常用于POST大数据传输
  • 206:一般用来做断点续传,或者是视频文件等大文件的加载
  • 301:永久重定向会缓存。新域名替换旧域名,旧的域名不再使用时,用户访问旧域名时用301就重定向到新的域名
  • 302:临时重定向不会缓存,常用 于未登陆的用户访问用户中心重定向到登录页面
  • 304:协商缓存,告诉客户端有缓存,直接使用缓存中的数据,返回页面的只有头部信息,是没有内容部分
  • 400:参数有误,请求无法被服务器识别
  • 403:告诉客户端进制访问该站点或者资源,如在外网环境下,然后访问只有内网IP才能访问的时候则返回
  • 404:服务器找不到资源时,或者服务器拒绝请求又不想说明理由时
  • 503:服务器停机维护时,主动用503响应请求或 nginx 设置限速,超过限速,会返回503
  • 504:网关超时

♥︎ ♥︎ ♥︎ 你知道哪些http首部字段?

HTTP头字段(HTTP header fields),是指在超文本传输协议(HTTP)的请求和响应消息中的消息头部分

字段名 说明 示例
Accept 能够接受的回应内容类型(Content-Types) Accept: text/plain
Accept-Charset 能够接受的字符集 Accept-Charset: utf-8
Accept-Encoding 能够接受的编码方式列表 Accept-Encoding: gzip, deflate
Accept-Language 能够接受的回应内容的自然语言列表 Accept-Language: en-US
Authorization 用于超文本传输协议的认证的认证信息 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control 用来指定在这次的请求/响应链中的所有缓存机制 都必须 遵守的指令 Cache-Control: no-cache
Connection 该浏览器想要优先使用的连接类型 Connection: keep-alive Connection: Upgrade
Cookie 服务器通过 Set- Cookie (下文详述)发送的一个 超文本传输协议Cookie Cookie: $Version=1; Skin=new;
Content-Length 以 八位字节数组 (8位的字节)表示的请求体的长度 Content-Length: 348
Content-Type 请求体的 多媒体类型 Content-Type: application/x-www-form-urlencoded
Date 发送该消息的日期和时间 Date: Tue, 15 Nov 1994 08:12:31 GMT
Expect 表明客户端要求服务器做出特定的行为 Expect: 100-continue
Host 服务器的域名(用于虚拟主机 ),以及服务器所监听的传输控制协议端口号 Host: en.wikipedia.org:80 Host: en.wikipedia.org
If-Match 仅当客户端提供的实体与服务器上对应的实体相匹配时,才进行对应的操作。主要作用时,用作像 PUT 这样的方法中,仅当从用户上次更新某个资源以来,该资源未被修改的情况下,才更新该资源 If-Match: “737060cd8c284d8af7ad3082f209582d”
If-Modified-Since 允许在对应的内容未被修改的情况下返回304未修改 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match 允许在对应的内容未被修改的情况下返回304未修改 If-None-Match: “737060cd8c284d8af7ad3082f209582d”
If-Range 如果该实体未被修改过,则向我发送我所缺少的那一个或多个部分;否则,发送整个新的实体 If-Range: “737060cd8c284d8af7ad3082f209582d”
Range 仅请求某个实体的一部分 Range: bytes=500-999
User-Agent 浏览器的浏览器身份标识字符串 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0
Origin 发起一个针对 跨来源资源共享 的请求 Origin: http://www.example-social-network.com

♥︎ ♥︎ ♥︎ 为什么浏览器要限制TCP的最大个数

建立一个tcp连接需要:1,socket文件描述符;2,IP地址;3,端口;4,内存

1、内存资源: 一个tcp连接最小占用内存为4096+4096 = 8k, 那么对于一个8G内存的机器,在不考虑其他限制下, 最多支持的并发量为:810241024/8 约等于100万, 在实际中,由于linux kernel对一些资源的限制, 加上程序的业务处理,所以,8G内存是很难达到100万连接的

2、CPU资源

♥︎ ♥︎ ♥︎ 说说 HTTP1.0/1.1/2.0 的区别?

一、HTTP1.0

HTTP协议的第二个版本,第一个在通讯中指定版本号的HTTP协议版本

HTTP 1.0 浏览器与服务器只保持短暂的连接,每次请求都需要与服务器建立一个TCP连接

服务器完成请求处理后立即断开TCP连接,服务器不跟踪每个客户也不记录过去的请求

简单来讲,每次与服务器交互,都需要新开一个连接

例如,解析html文件,当发现文件中存在资源文件的时候,这时候又创建单独的链接

最终导致,一个html文件的访问包含了多次的请求和响应,每次请求都需要创建连接、关系连接

这种形式明显造成了性能上的缺陷

如果需要建立长连接,需要设置一个非标准的Connection字段 Connection: keep-alive

二、HTTP1.1

HTTP1.1中,默认支持长连接(Connection: keep-alive),即在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟

建立一次连接,多次请求均由这个连接完成

这样,在加载html文件的时候,文件中多个请求和响应就可以在一个连接中传输

同时,HTTP 1.1还允许客户端不用等待上一次请求结果返回,就可以发出下一次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果,以保证客户端能够区分出每次请求的响应内容,这样也显著地减少了整个下载过程所需要的时间

同时,HTTP1.1HTTP1.0的基础上,增加更多的请求头和响应头来完善的功能,如下:

  • 引入了更多的缓存控制策略,如If-Unmodified-Since, If-Match, If-None-Match等缓存头来控制缓存策略
  • 引入range,允许值请求资源某个部分
  • 引入host,实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点

并且还添加了其他的请求方法:putdeleteoptions

三、HTTP2.0

HTTP2.0在相比之前版本,性能上有很大的提升,如添加了一个特性:

  • 多路复用
  • 二进制分帧
  • 首部压缩
  • 服务器推送
多路复用

HTTP/2 复用TCP连接,在一个连接里,客户端和浏览器都可以同时发送多个请求或回应,而且不用按照顺序一一对应,这样就避免了”队头堵塞”

上图中,可以看到第四步中cssjs资源是同时发送到服务端

二进制分帧

帧是HTTP2通信中最小单位信息

HTTP/2 采用二进制格式传输数据,而非 HTTP 1.x 的文本格式,解析起来更高效

将请求和响应数据分割为更小的帧,并且它们采用二进制编码

HTTP2 中,同域名下所有通信都在单个连接上完成,该连接可以承载任意数量的双向数据流

每个数据流都以消息的形式发送,而消息又由一个或多个帧组成。多个帧之间可以乱序发送,根据帧首部的流标识可以重新组装,这也是多路复用同时发送数据的实现条件

首部压缩

HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对,对于相同的数据,不再通过每次请求和响应发送

首部表在HTTP/2的连接存续期内始终存在,由客户端和服务器共同渐进地更新

例如:下图中的两个请求, 请求一发送了所有的头部字段,第二个请求则只需要发送差异数据,这样可以减少冗余数据,降低开销

服务器推送

HTTP2引入服务器推送,允许服务端推送资源给客户端

服务器会顺便把一些客户端需要的资源一起推送到客户端,如在响应一个页面请求中,就可以随同页面的其它资源

免得客户端再次创建连接发送请求到服务器端获取

这种方式非常合适加载静态资源

四、总结

HTTP1.0:

  • 浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接

HTTP1.1:

  • 引入了持久连接,即TCP连接默认不关闭,可以被多个请求复用
  • 在同一个TCP连接里面,客户端可以同时发送多个请求
  • 虽然允许复用TCP连接,但是同一个TCP连接里面,所有的数据通信是按次序进行的,服务器只有处理完一个请求,才会接着处理下一个请求。如果前面的处理特别慢,后面就会有许多请求排队等着
  • 新增了一些请求方法
  • 新增了一些请求头和响应头

HTTP2.0:

  • 采用二进制格式而非文本格式
  • 完全多路复用,而非有序并阻塞的、只需一个连接即可实现并行
  • 使用报头压缩,降低开销
  • 服务器推送

♥︎ ♥︎ ♥︎ HTTP2.0的特点

HTTP2.0大幅度的提高了web性能,在HTTP1.1完全语意兼容的基础上,进一步减少了网络的延迟。

  1. 二进制分帧
  2. 多路复用
  3. 首部压缩
  4. 流量控制
  5. 请求优先级
  6. 服务器推送

♥︎ ♥︎ ♥︎ 简述https原理,以及与http的区别

  1. HTTP协议工作在80端口,HTTPS协议工作在443端口
  2. HTTPS需要申请证书(用于验证服务器身份)
  3. HTTP在TCP三次握手建立连接之后即可开始传输数据;HTTPS协议则需要在建立TCP连接之后客户端与服务器在进行SSL加密,确定对话密钥,完成加密后才开始传输数据。
  4. HTTPS协议传输是密文,HTTP协议传输是明文

♥︎ ♥︎ ♥︎ CDN 是什么?描述下 CDN 原理?为什么要用 CDN?

CDN的全称是Content Delivery Network,即内容分发网络 共有云厂商在全世界各地都遍布不计其数都数据中心和服务器, CDN服务简单来讲就是这些厂商将你的服务器上面的文档分发到他们不同地区的服务器的当中, 每个地区可以称为一个节点,这样用户在访问你的网址时, 浏览器发送的请求就会优先绕去离客户最近的节点来获取数据, 这样方便客户更快的速度访问网站。 CDN是构建在现有网络基础之上的智能虚拟网络,依靠部署在各地的边缘服务器, 通过中心平台的负载均衡、内容分发、调度等功能模块,使用户就近获取所需内容, 降低网络拥塞,提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。

♥︎ ♥︎ ♥︎ DNS 查询的过程,分为哪两种,是怎么一个过程

1、分布域名解析:是指分在客户端上维护一个静态的文本文件,其中包含主机名和IP地址的映射。 随着网络规模的扩大,分布式分辨率的有效性越来越低。

2、集中式域名解析:要求网络中有多台DNS服务器,负责维护域名/IP地址映射数据库。 客户端从指定的服务器获取域名的地址信息。一旦客户端指定的DNS服务器不包含相应的数据, DNS服务器就会在网络中进行递归查询,并获取其他服务器上的地址信息。

♥︎ ♥︎ ♥︎ 强缓存和协商缓存的区别

强缓存(本地缓存):直接使用本地的缓存,不用跟服务器进行通信

相关header字段

expires:一个未来时间,代表请求有效期,没有过期之前都使用当前请求。

cache-control

no-cache:不使用本地缓存。向浏览器发送新鲜度校验请求

pubilc:任何情况下都缓存(即使是HTTP认证的资源)

private:只能被终端用户的浏览器缓存,不允许CDN等中继缓存服务器对其缓存

no-store:禁止浏览器缓存数据,也禁止保存至临时文件中,每次都重新请求,多次设置 cache-control,优先级最高

协商缓存:将资源一些相关信息返回服务器,让服务器判断浏览器是否能直接使用本地缓存,整个过程至少与服务器通信一次

相关header字段

Last-Modified/If-Modified-Since(两个都是时间格式字符串)

浏览器第一次发请求,服务器在返回的 respone 的 header 加上 Last-Modified,表示资源的最后修改时间再次请求资源,在 requset 的 header 加上 If-Modified-Since ,值就是上一次请求返回的 Last-Modified 值

服务器根据请求传过来的值判断资源是否有变化,没有则返回 304,有变化就正常返回资源内容,更新 LastModified 的值

304 从缓存加载资源,否则直接从服务器加载资源

Etag/If-None-Match与 Last-Modified/If-Modified-Since 不同的是,返回 304 时,ETag 还是会重新生成返回至浏览器。

♥︎ ♥︎ ♥︎ 为什么from表单提交没有跨域问题,但ajax有跨域问题

浏览器的策略本质是:一个域名下面的JS,没有经过允许是不能读取另一个域名的内容,但是浏览器不阻止你向另外一个域名发送请求。 所以form表单提交没有跨域问题,提交form表单到另外一个域名,原来页面是无法获取新页面的内容,或者说form提交后不需要返回,但是ajax是需要返回的。 而ajax是想要读取响应内容,浏览器是不允许你这么做的。 浏览器的安全策略限制的是js脚本,并不限制src,form表单提交之类的请求, 就是说form表单提交不存在安全问题,ajax提交跨域存在安全问题。


♥︎ ♥︎ ♥︎ ♥︎ url从输入到渲染页面的全过程

浏览器构建HTTP Request请求, DNS解析URL地址、生成HTTP请求报文、构建TCP连接、使用IP协议选择传输路线

将请求通过网络传输到服务端

从客户机到服务器需要通过许多网络设备,一般包括集线器、交换器、路由器等

服务器构建HTTP Response响应,响应客户端的请求

将响应体的数据通过网络传输返回给客户端

浏览器渲染页面 解析HTML、CSS、JS,生成RenderTree渲染页面

♥︎ ♥︎ ♥︎ ♥︎ TCP为什么需要三次握手和四次挥手?

一、三次握手

三次握手(Three-way Handshake)其实就是指建立一个TCP连接时,需要客户端和服务器总共发送3个包

主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备

过程如下:

  • 第一次握手:客户端给服务端发一个 SYN 报文,并指明客户端的初始化序列号 ISN(c),此时客户端处于 SYN_SENT 状态
  • 第二次握手:服务器收到客户端的 SYN 报文之后,会以自己的 SYN 报文作为应答,为了确认客户端的 SYN,将客户端的 ISN+1作为ACK的值,此时服务器处于 SYN_RCVD 的状态
  • 第三次握手:客户端收到 SYN 报文之后,会发送一个 ACK 报文,值为服务器的ISN+1。此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后,也处于 ESTABLISHED 状态,此时,双方已建立起了连接

上述每一次握手的作用如下:

  • 第一次握手:客户端发送网络包,服务端收到了
    这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。
  • 第二次握手:服务端发包,客户端收到了
    这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常
  • 第三次握手:客户端发包,服务端收到了。
    这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常

通过三次握手,就能确定双方的接收和发送能力是正常的。之后就可以正常通信了

为什么不是两次握手?

如果是两次握手,发送端可以确定自己发送的信息能对方能收到,也能确定对方发的包自己能收到,但接收端只能确定对方发的包自己能收到 无法确定自己发的包对方能收到

并且两次握手的话, 客户端有可能因为网络阻塞等原因会发送多个请求报文,延时到达的请求又会与服务器建立连接,浪费掉许多服务器的资源

二、四次挥手

tcp终止一个连接,需要经过四次挥手

过程如下:

  • 第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态,停止发送数据,等待服务端的确认
  • 第二次挥手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 +1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT状态
  • 第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态
  • 第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态,服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态

四次挥手原因

服务端在收到客户端断开连接Fin报文后,并不会立即关闭连接,而是先发送一个ACK包先告诉客户端收到关闭连接的请求,只有当服务器的所有报文发送完毕之后,才发送FIN报文断开连接,因此需要四次挥手

三、总结

一个完整的三次握手四次挥手如下图所示:

♥︎ ♥︎ ♥︎ ♥︎ 说一下http缓存策略,有什么区别,分别解决了什么问题?

浏览器每次发起请求时,先在本地缓存中查找结果以及缓存标识,根据缓存标识来判断是否使用本地缓存, 如果缓存有效,则使用本地缓存。

向服务器发起请求并携带缓存标识。根据是否需向服务器发起HTTP请求, 将缓存过程划分为两个部分:强制缓存和协商缓存,强缓优先于协商缓存。

强缓存,服务器通知浏览器一个缓存时间,在缓存时间内,下次请求,直接用缓存,不在时间内,执行比较缓存策略。

协商缓存,让客户端与服务器之间能实现缓存文件是否更新的验证、提升缓存的复用率, 将缓存信息中的Etag和Last-Modified,通过请求发送给服务器,由服务器校验,返回304状态码时,浏览器直接使用缓存。

解决问题

  1. 减少了冗余的数据传输
  2. 减少了服务器的负担,大大提升了网站的性能
  3. 加快了客户端加载网页的速度

♥︎ ♥︎ ♥︎ ♥︎ 为什么说HTTPS比HTTP安全? HTTPS是如何保证安全的?

一、安全特性

在上篇文章中,我们了解到HTTP在通信过程中,存在以下问题:

  • 通信使用明文(不加密),内容可能被窃听
  • 不验证通信方的身份,因此有可能遭遇伪装

HTTPS的出现正是解决这些问题,HTTPS是建立在SSL之上,其安全性由SSL来保证

在采用SSL后,HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能

SSL(Secure Sockets Layer 安全套接字协议),及其继任者传输层安全(Transport Layer Security,TLS)是为网络通信提供安全及数据完整性的一种安全协议

二、如何做

SSL 的实现这些功能主要依赖于三种手段:

  • 对称加密:采用协商的密钥对数据加密
  • 非对称加密:实现身份认证和密钥协商
  • 摘要算法:验证信息的完整性
  • 数字签名:身份验证

对称加密

对称加密指的是加密和解密使用的秘钥都是同一个,是对称的。只要保证了密钥的安全,那整个通信过程就可以说具有了机密性

非对称加密

非对称加密,存在两个秘钥,一个叫公钥,一个叫私钥。两个秘钥是不同的,公钥可以公开给任何人使用,私钥则需要保密

公钥和私钥都可以用来加密解密,但公钥加密后只能用私钥解密,反过来,私钥加密后也只能用公钥解密

混合加密

HTTPS通信过程中,采用的是对称加密+非对称加密,也就是混合加密

在对称加密中讲到,如果能够保证了密钥的安全,那整个通信过程就可以说具有了机密性

HTTPS采用非对称加密解决秘钥交换的问题

具体做法是发送密文的一方使用对方的公钥进行加密处理“对称的密钥”,然后对方用自己的私钥解密拿到“对称的密钥”

这样可以确保交换的密钥是安全的前提下,使用对称加密方式进行通信

举个例子:

网站秘密保管私钥,在网上任意分发公钥,你想要登录网站只要用公钥加密就行了,密文只能由私钥持有者才能解密。而黑客因为没有私钥,所以就无法破解密文

上述的方法解决了数据加密,在网络传输过程中,数据有可能被篡改,并且黑客可以伪造身份发布公钥,如果你获取到假的公钥,那么混合加密也并无多大用处,你的数据扔被黑客解决

因此,在上述加密的基础上仍需加上完整性、身份验证的特性,来实现真正的安全,实现这一功能则是摘要算法

摘要算法

实现完整性的手段主要是摘要算法,也就是常说的散列函数、哈希函数

可以理解成一种特殊的压缩算法,它能够把任意长度的数据“压缩”成固定长度、而且独一无二的“摘要”字符串,就好像是给这段数据生成了一个数字“指纹”

摘要算法保证了“数字摘要”和原文是完全等价的。所以,我们只要在原文后附上它的摘要,就能够保证数据的完整性

比如,你发了条消息:“转账 1000 元”,然后再加上一个 SHA-2 的摘要。网站收到后也计算一下消息的摘要,把这两份“指纹”做个对比,如果一致,就说明消息是完整可信的,没有被修改

img

数字签名

数字签名能确定消息确实是由发送方签名并发出来的,因为别人假冒不了发送方的签名

原理其实很简单,就是用私钥加密,公钥解密

签名和公钥一样完全公开,任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开,拿到摘要后,再比对原文验证完整性,就可以像签署文件一样证明消息确实是你发的

和消息本身一样,因为谁都可以发布公钥,我们还缺少防止黑客伪造公钥的手段,也就是说,怎么判断这个公钥就是你的公钥

这时候就需要一个第三方,就是证书验证机构

CA验证机构

数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场

CA 对公钥的签名认证要求包括序列号、用途、颁发者、有效时间等等,把这些打成一个包再签名,完整地证明公钥关联的各种信息,形成“数字证书”

流程如下图:

  • 服务器的运营人员向数字证书认证机构提出公开密钥的申请

  • 数字证书认证机构在判明提出申请者的身份之后,会对已申请的公开密钥做数字签名

  • 然后分配这个已签名的公开密钥,并将该公开密钥放入公钥证书后绑定在一起

  • 服务器会将这份由数字证书认证机构颁发的数字证书发送给客户端,以进行非对称加密方式通信接到证书的客户端可使用数字证书认证机构的公开密钥,对那张证书上的数字签名进行验证,一旦验证通过,则证明:认证服务器的公开密钥的是真实有效的数字证书认证机构

  • 服务器的公开密钥是值得信赖的

三、总结

可以看到,HTTPSHTTP虽然只差一个SSL,但是通信安全得到了大大的保障,通信的四大特性都以解决,解决方式如下:

  • 机密性:混合算法
  • 完整性:摘要算法
  • 身份认证:数字签名
  • 不可否定:数字签名

同时引入第三方证书机构,确保公开秘钥的安全性

♥︎ ♥︎ ♥︎ ♥︎ 如何理解UDP 和 TCP? 区别? 应用场景?

一、UDP

UDP(User Datagram Protocol),用户数据包协议,是一个简单的面向数据报的通信协议,即对应用层交下来的报文,不合并,不拆分,只是在其上面加上首部后就交给了下面的网络层

也就是说无论应用层交给UDP多长的报文,它统统发送,一次发送一个报文

而对接收方,接到后直接去除首部,交给上面的应用层就完成任务

UDP报头包括4个字段,每个字段占用2个字节(即16个二进制位),标题短,开销小

特点如下:

  • UDP 不提供复杂的控制机制,利用 IP 提供面向无连接的通信服务
  • 传输途中出现丢包,UDP 也不负责重发
  • 当包的到达顺序出现乱序时,UDP没有纠正的功能。
  • 并且它是将应用程序发来的数据在收到的那一刻,立即按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况,UDP 也无法进行流量控制等避免网络拥塞行为

二、TCP

TCP(Transmission Control Protocol),传输控制协议,是一种可靠、面向字节流的通信协议,把上面应用层交下来的数据看成无结构的字节流来发送

可以想象成流水形式的,发送方TCP会将数据放入“蓄水池”(缓存区),等到可以发送的时候就发送,不能发送就等着,TCP会根据当前网络的拥塞状态来确定每个报文段的大小

TCP报文首部有20个字节,额外开销大

特点如下:

  • TCP充分地实现了数据传输时各种控制功能,可以进行丢包时的重发控制,还可以对次序乱掉的分包进行顺序控制。而这些在 UDP 中都没有。
  • 此外,TCP 作为一种面向有连接的协议,只有在确认通信对端存在时才会发送数据,从而可以控制通信流量的浪费。
  • 根据 TCP 的这些机制,在 IP 这种无连接的网络上也能够实现高可靠性的通信( 主要通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现)

三、区别

UDPTCP两者的都位于传输层,如下图所示:

两者区别如下表所示:

TCP UDP
可靠性 可靠 不可靠
连接性 面向连接 无连接
报文 面向字节流 面向报文
效率 传输效率低 传输效率高
双共性 全双工 一对一、一对多、多对一、多对多
流量控制 滑动窗口
拥塞控制 慢开始、拥塞避免、快重传、快恢复
传输效率
  • TCP 是面向连接的协议,建立连接3次握手、断开连接四次挥手,UDP是面向无连接,数据传输前后不连接连接,发送端只负责将数据发送到网络,接收端从消息队列读取
  • TCP 提供可靠的服务,传输过程采用流量控制、编号与确认、计时器等手段确保数据无差错,不丢失。UDP 则尽可能传递数据,但不保证传递交付给对方
  • TCP 面向字节流,将应用层报文看成一串无结构的字节流,分解为多个TCP报文段传输后,在目的站重新装配。UDP协议面向报文,不拆分应用层报文,只保留报文边界,一次发送一个报文,接收方去除报文首部后,原封不动将报文交给上层应用
  • TCP 只能点对点全双工通信。UDP 支持一对一、一对多、多对一和多对多的交互通信

两者应用场景如下图:

可以看到,TCP 应用场景适用于对效率要求低,对准确性要求高或者要求有链接的场景,而UDP 适用场景为对效率要求高,对准确性要求低的场景

♥︎ ♥︎ ♥︎ ♥︎ 如何理解OSI七层模型?

一、是什么

OSI (Open System Interconnect)模型全称为开放式通信系统互连参考模型,是国际标准化组织 ( ISO ) 提出的一个试图使各种计算机在世界范围内互连为网络的标准框架

OSI 将计算机网络体系结构划分为七层,每一层实现各自的功能和协议,并完成与相邻层的接口通信。即每一层扮演固定的角色,互不打扰

二、划分

OSI主要划分了七层,如下图所示:

68747470733a2f2f7374617469632e7675652d6a732e636f6d2f65623162323137302d623631652d313165622d616239302d6439616538313462323430642e706e67

应用层

应用层位于 OSI 参考模型的第七层,其作用是通过应用程序间的交互来完成特定的网络应用

该层协议定义了应用进程之间的交互规则,通过不同的应用层协议为不同的网络应用提供服务。例如域名系统 DNS,支持万维网应用的 HTTP 协议,电子邮件系统采用的 SMTP 协议等

在应用层交互的数据单元我们称之为报文

表示层

表示层的作用是使通信的应用程序能够解释交换数据的含义,其位于 OSI 参考模型的第六层,向上为应用层提供服务,向下接收来自会话层的服务

该层提供的服务主要包括数据压缩,数据加密以及数据描述,使应用程序不必担心在各台计算机中表示和存储的内部格式差异

会话层

会话层就是负责建立、管理和终止表示层实体之间的通信会话

该层提供了数据交换的定界和同步功能,包括了建立检查点和恢复方案的方法

传输层

传输层的主要任务是为两台主机进程之间的通信提供服务,处理数据包错误、数据包次序,以及其他一些关键传输问题

传输层向高层屏蔽了下层数据通信的细节。因此,它是计算机通信体系结构中关键的一层

其中,主要的传输层协议是TCPUDP

网络层

两台计算机之间传送数据时其通信链路往往不止一条,所传输的信息甚至可能经过很多通信子网

网络层的主要任务就是选择合适的网间路由和交换节点,确保数据按时成功传送

在发送数据时,网络层把传输层产生的报文或用户数据报封装成分组和包,向下传输到数据链路层

在网络层使用的协议是无连接的网际协议(Internet Protocol)和许多路由协议,因此我们通常把该层简单地称为 IP 层

数据链路层

数据链路层通常也叫做链路层,在物理层和网络层之间。两台主机之间的数据传输,总是在一段一段的链路上传送的,这就需要使用专门的链路层协议

在两个相邻节点之间传送数据时,数据链路层将网络层交下来的 IP 数据报组装成帧,在两个相邻节点间的链路上传送帧

每一帧的数据可以分成:报头head和数据data两部分:

  • head 标明数据发送者、接受者、数据类型,如 MAC地址
  • data 存储了计算机之间交互的数据

通过控制信息我们可以知道一个帧的起止比特位置,此外,也能使接收端检测出所收到的帧有无差错,如果发现差错,数据链路层能够简单的丢弃掉这个帧,以避免继续占用网络资源

物理层

作为 OSI 参考模型中最低的一层,物理层的作用是实现计算机节点之间比特流的透明传送

该层的主要任务是确定与传输媒体的接口的一些特性(机械特性、电气特性、功能特性,过程特性)

该层主要是和硬件有关,与软件关系不大

三、传输过程

数据在各层之间的传输如下图所示:

  • 应用层报文被传送到运输层
  • 在最简单的情况下,运输层收取到报文并附上附加信息,该首部将被接收端的运输层使用
  • 应用层报文和运输层首部信息一道构成了运输层报文段。附加的信息可能包括:允许接收端运输层向上向适当的应用程序交付报文的信息以及差错检测位信息。该信息让接收端能够判断报文中的比特是否在途中已被改变
  • 运输层则向网络层传递该报文段,网络层增加了如源和目的端系统地址等网络层首部信息,生成了网络层数据报
  • 网络层数据报接下来被传递给链路层,在数据链路层数据包添加发送端 MAC 地址和接收端 MAC 地址后被封装成数据帧
  • 在物理层数据帧被封装成比特流,之后通过传输介质传送到对端
  • 对端再一步步解开封装,获取到传送的数据

♥︎ ♥︎ ♥︎ ♥︎ 如何理解TCP/IP协议?

一、是什么

TCP/IP,传输控制协议**/**网际协议,是指能够在多个不同网络间实现信息传输的协议簇

  • TCP(传输控制协议)

一种面向连接的、可靠的、基于字节流的传输层通信协议

  • IP(网际协议)

用于封包交换数据网络的协议

TCP/IP协议不仅仅指的是TCP IP两个协议,而是指一个由FTPSMTPTCPUDPIP等协议构成的协议簇,

只是因为在TCP/IP协议中TCP协议和IP协议最具代表性,所以通称为TCP/IP协议族(英语:TCP/IP Protocol Suite,或TCP/IP Protocols)

二、划分

TCP/IP协议族按层次分别了五层体系或者四层体系

五层体系的协议结构是综合了 OSI 和 TCP/IP 优点的一种协议,包括应用层、传输层、网络层、数据链路层和物理层

五层协议的体系结构只是为介绍网络原理而设计的,实际应用还是 TCP/IP 四层体系结构,包括应用层、传输层、网络层(网际互联层)、网络接口层

如下图所示:

五层体系

应用层

TCP/IP 模型将 OSI 参考模型中的会话层、表示层和应用层的功能合并到一个应用层实现,通过不同的应用层协议为不同的应用提供服务

如:FTPTelnetDNSSMTP

传输层

该层对应于 OSI 参考模型的传输层,为上层实体提供源端到对端主机的通信功能

传输层定义了两个主要协议:传输控制协议(TCP)和用户数据报协议(UDP)

其中面向连接的 TCP 协议保证了数据的传输可靠性,面向无连接的 UDP 协议能够实现数据包简单、快速地传输

网络层

负责为分组网络中的不同主机提供通信服务,并通过选择合适的路由将数据传递到目标主机

在发送数据时,网络层把运输层产生的报文段或用户数据封装成分组或包进行传送

数据链路层

数据链路层在两个相邻节点传输数据时,将网络层交下来的IP数据报组装成帧,在两个相邻节点之间的链路上传送帧

物理层

保数据可以在各种物理媒介上进行传输,为数据的传输提供可靠的环境

四层体系

TCP/IP 的四层结构则如下表所示:

层次名称 单位 功 能 协 议
网络接口层 负责实际数据的传输,对应OSI参考模型的下两层 HDLC(高级链路控制协议)PPP(点对点协议) SLIP(串行线路接口协议)
网络层 数据报 负责网络间的寻址数据传输,对应OSI参考模型的第三层 IP(网际协议) ICMP(网际控制消息协议)ARP(地址解析协议) RARP(反向地址解析协议)
传输层 报文段 负责提供可靠的传输服务,对应OSI参考模型的第四层 TCP(控制传输协议) UDP(用户数据报协议)
应用层 负责实现一切与应用程序相关的功能,对应OSI参考模型的上三层 FTP(文件传输协议) HTTP(超文本传输协议) DNS(域名服务器协议)SMTP(简单邮件传输协议)NFS(网络文件系统协议)

三、总结

OSI 参考模型与 TCP/IP 参考模型区别如下:

相同点:

  • OSI 参考模型与 TCP/IP 参考模型都采用了层次结构
  • 都能够提供面向连接和无连接两种通信服务机制

不同点:

  • OSI 采用的七层模型; TCP/IP 是四层或五层结构
  • TCP/IP 参考模型没有对网络接口层进行细分,只是一些概念性的描述; OSI 参考模型对服务和协议做了明确的区分
  • OSI 参考模型虽然网络划分为七层,但实现起来较困难。TCP/IP 参考模型作为一种简化的分层结构是可以的
  • TCP/IP协议去掉表示层和会话层的原因在于会话层、表示层、应用层都是在应用程序内部实现的,最终产出的是一个应用数据包,而应用程序之间是几乎无法实现代码的抽象共享的,这也就造成 OSI 设想中的应用程序维度的分层是无法实现的

♥︎ ♥︎ ♥︎ ♥︎ 说一下 GET 和 POST 的区别?

GETPOST,两者是HTTP协议中发送请求的方法

GET

GET方法请求一个指定资源的表示形式,使用GET的请求应该只被用于获取数据

POST

POST方法用于将实体提交到指定的资源,通常导致在服务器上的状态变化或副作用

本质上都是TCP链接,并无差别

但是由于HTTP的规定和浏览器/服务器的限制,导致他们在应用过程中会体现出一些区别

一、区别

w3schools得到的标准答案的区别如下:

  • GET在浏览器回退时是无害的,而POST会再次提交请求。
  • GET产生的URL地址可以被Bookmark,而POST不可以。
  • GET请求会被浏览器主动cache,而POST不会,除非手动设置。
  • GET请求只能进行url编码,而POST支持多种编码方式。
  • GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。
  • GET请求在URL中传送的参数是有长度限制的,而POST没有。
  • 对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
  • GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。
  • GET参数通过URL传递,POST放在Request body中

参数位置

貌似从上面看到GETPOST请求区别非常大,但两者实质并没有区别

无论 GET 还是 POST,用的都是同一个传输层协议,所以在传输上没有区别

当不携带参数的时候,两者最大的区别为第一行方法名不同

POST /uri HTTP/1.1 \r\n

GET /uri HTTP/1.1 \r\n

当携带参数的时候,我们都知道GET请求是放在url中,POST则放在body

GET 方法简约版报文是这样的

GET /index.html?name=qiming.c&age=22 HTTP/1.1
Host: localhost

POST 方法简约版报文是这样的

POST /index.html HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded

name=qiming.c&age=22

注意:这里只是约定,并不属于HTTP规范,相反的,我们可以在POST请求中url中写入参数,或者GET请求中的body携带参数

参数长度

HTTP 协议没有BodyURL 的长度限制,对 URL 限制的大多是浏览器和服务器的原因

IEURL长度的限制是2083字节(2K+35)。对于其他浏览器,如Netscape、FireFox等,理论上没有长度限制,其限制取决于操作系统的支持

这里限制的是整个URL长度,而不仅仅是参数值的长度

服务器处理长 URL 要消耗比较多的资源,为了性能和安全考虑,会给 URL 长度加限制

安全

POST GET 安全,因为数据在地址栏上不可见

然而,从传输的角度来说,他们都是不安全的,因为 HTTP 在网络上是明文传输的,只要在网络节点上捉包,就能完整地获取数据报文

只有使用HTTPS才能加密安全

数据包

对于GET方式的请求,浏览器会把http headerdata一并发送出去,服务器响应200(返回数据)

对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok

并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次

♥︎ ♥︎ ♥︎ ♥︎ 对WebSocket的理解?应用场景?

一、是什么

WebSocket,是一种网络传输协议,位于OSI模型的应用层。可在单个TCP连接上进行全双工通信,能更好的节省服务器资源和带宽并达到实时通迅

客户端和服务器只需要完成一次握手,两者之间就可以创建持久性的连接,并进行双向数据传输

从上图可见,websocket服务器与客户端通过握手连接,连接成功后,两者都能主动的向对方发送或接受数据

而在websocket出现之前,开发实时web应用的方式为轮询

不停地向服务器发送 HTTP 请求,问有没有数据,有数据的话服务器就用响应报文回应。如果轮询的频率比较高,那么就可以近似地实现“实时通信”的效果

轮询的缺点也很明显,反复发送无效查询请求耗费了大量的带宽和 CPU 资源

二、特点

全双工

通信允许数据在两个方向上同时传输,它在能力上相当于两个单工通信方式的结合

例如指 A→B 的同时 B→A ,是瞬时同步的

二进制帧

采用了二进制帧结构,语法、语义与 HTTP 完全不兼容,相比http/2WebSocket 更侧重于“实时通信”,而HTTP/2 更侧重于提高传输效率,所以两者的帧结构也有很大的区别

不像 HTTP/2 那样定义流,也就不存在多路复用、优先级等特性

自身就是全双工,也不需要服务器推送

协议名

引入wswss分别代表明文和密文的websocket协议,且默认端口使用80或443,几乎与http一致

ws://www.chrono.com
ws://www.chrono.com:8080/srv
wss://www.chrono.com:445/im?user_id=xxx
握手

WebSocket 也要有一个握手过程,然后才能正式收发数据

客户端发送数据格式如下:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
  • Connection:必须设置Upgrade,表示客户端希望连接升级
  • Upgrade:必须设置Websocket,表示希望升级到Websocket协议
  • Sec-WebSocket-Key:客户端发送的一个 base64 编码的密文,用于简单的认证秘钥。要求服务端必须返回一个对应加密的“Sec-WebSocket-Accept应答,否则客户端会抛出错误,并关闭连接
  • Sec-WebSocket-Version :表示支持的Websocket版本

服务端返回的数据格式:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=Sec-WebSocket-Protocol: chat
  • HTTP/1.1 101 Switching Protocols:表示服务端接受 WebSocket 协议的客户端连接
  • Sec-WebSocket-Accep:验证客户端请求报文,同样也是为了防止误连接。具体做法是把请求头里“Sec-WebSocket-Key”的值,加上一个专用的 UUID,再计算摘要

优点

  • 较少的控制开销:数据包头部协议较小,不同于http每次请求需要携带完整的头部
  • 更强的实时性:相对于HTTP请求需要等待客户端发起请求服务端才能响应,延迟明显更少
  • 保持创连接状态:创建通信后,可省略状态信息,不同于HTTP每次请求需要携带身份验证
  • 更好的二进制支持:定义了二进制帧,更好处理二进制内容
  • 支持扩展:用户可以扩展websocket协议、实现部分自定义的子协议
  • 更好的压缩效果:Websocket在适当的扩展支持下,可以沿用之前内容的上下文,在传递类似的数据时,可以显著地提高压缩率

二、应用场景

基于websocket的事实通信的特点,其存在的应用场景大概有:

  • 弹幕
  • 媒体聊天
  • 协同编辑
  • 基于位置的应用
  • 体育实况更新
  • 股票基金报价实时更新
Donate
  • Copyright: Copyright is owned by the author. For commercial reprints, please contact the author for authorization. For non-commercial reprints, please indicate the source.
  • Copyrights © 2022-2023 alan_mf
  • Visitors: | Views:

请我喝杯咖啡吧~

支付宝
微信