前端人员应该更加关注并深入了解应用层的知识

# 1. 参考模型

# 1. OSI 参考模型 七层

Open System Interconnection

  1. 物理层 利用物理传输介质为数据链路层提供物理连接。传递的数据是比特流,0101010100。
  2. 数据链路层 定义通过通信媒介互连的设备之间传输的规范;首先,把比特流封装成数据帧的格式,对0、1进行分组。电脑连接起来之后,数据都经过网卡来传输,而网卡上定义了全世界唯一的MAC地址。然后再通过广播的形式向局域网内所有电脑发送数据,再根据数据中MAC地址和自身对比判断是否是发给自己的。
  3. 网络层 寻址和路由; IP ; 广播的形式太低效,为了区分哪些MAC地址属于同一个子网,网络层定义了IP和子网掩码,通过对IP和子网掩码进行与运算就知道是否是同一个子网,再通过路由器和交换机进行传输。
  4. 传输层 为上层协议提供端到端的可靠传输;TCP、UDP 有了网络层的MAC+IP地址之后,为了确定数据包是从哪个进程发送过来的,就需要端口号,通过端口来建立通信
  5. 会话层 建立、断开和维护通信链接
  6. 表示层 数据格式转换、数据压缩和数据加密 HTML、MIME
  7. 应用层 (各种应用程序协议 HTTP、FTP、SMTP、POP3)为应用程序提供网络服务;最高层,面对用户,提供计算机网络与最终呈现给用户的界面 在这里插入图片描述 详细的见 科来网络通讯协议图 http://www.colasoft.com.cn/download/protocols_map.php (opens new window)

# 2. TCP/IP参考模型 四层

ISO制定的OSI参考模型的过于庞大、复杂招致了许多批评。与此对照,由技术人员自己开发的TCP/IP协议栈获得了更为广泛的应用。

有四层五层两种说法 在这里插入图片描述 (知乎上的图,链接见文末)

  1. 数据链路层,也有称作网络访问层、网络接口层。他包含了OSI模型的物理层和数据链路层,把电脑连接起来。
  2. 网络层,也叫做IP层,处理IP数据包的传输、路由,建立主机间的通信。
  3. 传输层,就是为两台主机设备提供端到端的通信。TCP UDP
  4. 应用层,包含OSI的会话层、表示层和应用层,提供了一些常用的协议规范,比如FTP、SMPT、HTTP、DNS等。

在这里插入图片描述 (《图解TCP/IP》中的图)

总结一下就是 物理层通过物理手段把电脑连接起来 数据链路层则对比特流的数据进行分组 网络层来建立主机到主机的通信 传输层建立端口到端口的通信 应用层最终负责建立连接,数据格式转换,最终呈现给用户

# 2. 在浏览器中输入网址之后执行 会发生什么?

(1)从浏览器输入网址后,首先要经过域名解析,因为浏览器并不能直接通过域名找到服务器,而是通过IP地址找到对应的服务器,DNS将域名解析为IP地址; (2)浏览器通过IP地址找到服务器,建立TCP连接,通过三次握手以同步客户端和服务端的序列号和确认号,并交换TCP窗口大小的信息; (3)TCP三次握手结束后,开始发送HTTP请求; (4)服务器处理请求,并返回HTTP响应报文; (5)浏览器拿到响应文本HTML后,解析渲染页面; (6)当数据传送完毕后,断开TCP连接。

在这里插入图片描述

在这里插入图片描述

# 3.URL和URI的区别?

URI(Uniform Resource Identifier) 统一资源标识符 URL(Uniform Resource Locator) 统一资源定位符

URI用字符串标识某一互联网资源,而URL表示资源的位置,URL是URI的子集。

URI的目的就是唯一标识互联网中的一份资源,具体可以用资源名称、资源地址等,但是资源地址是目前使用最广泛的,因此URL就容易和URI混淆。URI相当于抽象类,URL就是这个抽象类的具体实现类。

# 4. 关于HTTP协议

用于客户端与服务端通信的协议

# 4.1 为什么说HTTP协议是无状态协议?

HTTP协议是一种无状态协议,协议自身不对请求和响应之间的通信状态进行保存,即对发送过来的请求和响应都不做持久化处理,把HTTP协议设计的如此简单是为了更快地处理大量事务。

为了解决HTTP协议不能保存通信状态的问题,引入了Cookie状态管理。 Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态。 Cookie会根据从服务端发送的响应报文的一个叫Set-Cookie的首部字段,通知客户端保存Cookie。 当下次客户端再往该服务端发送请求时,客户端会自动在请求报文中加入Cookie值发送出去,服务端发现客户端发来的Cookie后,会检查是哪一个客户端发来的连接请求,对比服务器上的记录,最后得到之前的状态信息。

# 4.3 HTTP 协议包括哪些请求方法?

GET:对服务器资源的简单请求 POST:用于发送包含用户提交数据的请求 PUT:传输文件 DELETE:发出一个删除指定文档的请求 HEAD:类似于GET请求,不过返回的响应中没有具体内容,用于获取报文首部 OPTIONS:返回所有可用的方法,检查服务器支持哪些方法 TRACE:发送一个请求副本,以跟踪其处理进程 CONNECT:用于ssl隧道的基于代理的请求

# 4.4 简述HTTP中GET和POST的区别

从原理性看: 根据HTTP规范,GET用于信息获取,而且应该是安全和幂等的 根据HTTP规范,POST请求表示可能修改服务器上资源的请求

从表面上看: GET请求的数据会附在URL后面,POST的数据放在HTTP包体 POST安全性比GET安全性高

1、GET参数通过URL传递,POST放在Request body中。

2、GET请求会被浏览器主动cache,而POST不会,除非手动设置。

3、GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。

4、Get 请求中有非 ASCII 字符,会在请求之前进行转码,POST不用,因为POST在Request body中,通过 MIME,也就可以传输非 ASCII 字符。

5、 一般我们在浏览器输入一个网址访问网站都是GET请求

6、HTTP的底层是TCP/IP。HTTP只是个行为准则,而TCP才是GET和POST怎么实现的基本。GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。但是请求的数据量太大对浏览器和服务器都是很大负担。所以业界有了不成文规定,(大多数)浏览器通常都会限制url长度在2K个字节,而(大多数)服务器最多处理64K大小的url。

7、GET产生一个TCP数据包;POST产生两个TCP数据包。对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。

8、在网络环境好的情况下,发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下,两次包的TCP在验证数据包完整性上,有非常大的优点。但并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次。

传递数据的最大长度

GET 是通过URL提交数据,因此GET可提交的数据量就跟URL所能达到的最大长度有直接关系。

POST理论上讲是没有大小限制的,HTTP协议规范也没有进行大小限制,但实际上POST所能传递的数据量大小取决于服务器的设置和内存大小。

# 4.5 PUT和POST区别

PUT是幂等的,POST不是。

幂等是数学的一个用语,对于单个输入或者无输入的运算方法,如果每次都是同样的结果,则称其是幂等的。也就是说,如果一个网络重复执行多次,产生的效果是一样的,那就是幂等(idempotent)。

PUT请求:如果两个请求相同,后一个请求会把第一个请求覆盖掉。(所以PUT用来改资源) POST请求:后一个请求不会把第一个请求覆盖掉。(所以POST用来增资源)

# 4.6 常见的状态码有哪些?

状态码由3位数字和原因短语组成。

【HTTP】HTTP状态码-返回结果-2XX-3XX-4XX-5XX (opens new window) 在这里插入图片描述

2××成功 200 OK 请求被正常处理 204 No Content 请求已成功处理,但无资源返回。 206 Partial Content 客户端只是请求资源的一部分,服务器只对请求的部分资源执行GET方法,相应报文中通过Content-Range指定范围的资源。

3××重定向 301 Moved Parmanently 永久性重定向 请求的资源已被分配了新的URL。 302 Found 临时重定向 请求的资源被临时定位到新的URL。 303 See Other 与302状态码有相似功能,只是它希望客户端在请求一个URI的时候,能通过GET方法重定向到另一个URI上 304 Not Modified 发送附带条件的请求时,条件不满足时返回,与重定向无关

4××客户端错误 400 Bad Request请求报文语法有误,服务器无法识别 401 Unauthorized 用户认证失败 403 Forbidden 服务器拒绝 404 Not Found服务器上没有找到请求的资源。

5××服务器错误 500 Internal Server Error 服务器内部错误 503 Service Unavailable 服务器正忙

# 4.7 HTTP如何禁用缓存?如何确认缓存?

HTTP/1.1 通过 Cache-Control 首部字段来控制缓存。

禁止进行缓存 no-store 指令规定不能对请求或响应的任何一部分进行缓存。

Cache-Control: no-store

强制确认缓存 no-cache 指令规定缓存服务器需要先向源服务器验证缓存资源的有效性,只有当缓存资源有效时才能使用该缓存对客户端的请求进行响应。

Cache-Control: no-cache

# 4.8 HTTP缓存

强制缓存 当缓存数据库中已有所请求的数据时。客户端直接从缓存数据库中获取数据。当缓存数据库中没有所请求的数据时,客户端的才会从服务端获取数据。在这里插入图片描述

协商缓存 又称对比缓存,客户端会先从缓存数据库中获取到一个缓存数据的标识,得到标识后请求服务端验证是否失效(新鲜),如果没有失效服务端会返回304,此时客户端直接从缓存中获取所请求的数据,如果标识失效,服务端会返回更新后的数据。 在这里插入图片描述 哪些资源可以被缓存——静态资源(js、css、img)

在这里插入图片描述

在这里插入图片描述

# 强制缓存

在这里插入图片描述

Cache-Control (Response Headers)

  • max-age 设置缓存有效时间
  • no-cache 不用本地强制缓存,让服务端处理缓存
  • no-store 不强制缓存,不让服务端处理缓存,直接返回资源
  • private 只能允许最终用户做缓存
  • public 允许中间路由、代理做缓存

Expires (Response Headers) 控制缓存过期,已被Cache-Control代替

# 协商缓存(对比缓存)

服务端缓存策略 服务端判读客户端资源,是否和服务端资源一样 一致返回304,否则返回200和最新的资源 在这里插入图片描述

Last-Modified [资源标识] 资源最后修改时间

在这里插入图片描述 Etag [资源标识] 资源唯一标识(一个字符串,类似人类的指纹) 在这里插入图片描述 在这里插入图片描述

# Last-Modified与Etag的区别

  • 优先使用Etag
  • Last-Modified 只能精确到秒级
  • 如果资源被重复生成,而内容不变,则Etag更精确

# 刷新页面对缓存的影响

  • 正常操作:地址栏输入URL,跳转链接,前进后退等【强制缓存有效,协商缓存有效】
  • 手动刷新:F5,点击刷新按钮,点击菜单刷新【强制缓存失效,协商缓存有效】
  • 强制刷新:CRTL+F5【强制缓存失效,协商缓存失效】

# 总结

在这里插入图片描述

# 4.9 常见HTTP Headers

# 常见Request Headers

  • Accept 浏览器可接收的数据格式
  • Accept-Encoding 浏览器可接收的压缩算法,如gzip
  • Accept-Languange 浏览器可接收的语言,如zh-CN
  • Connection: keep-alive 一次TCP连接重复使用
  • cookie
  • Host 请求域名
  • User-Agent 简称UA 浏览器信息
  • Content-type 发送数据的格式,如application/json

# 常见 Response Headers

  • Content-type 发送数据的格式,如application/json
  • Content-length 返回数据的大小,多少字节
  • Content-Encoding 返回数据的压缩算法,如gzip
  • Set-Cookie 设置Cookie
  • Cache-Control 缓存控制
  • Expires 控制缓存过期
  • Last-Modified 资源最后修改时间
  • Etag 资源唯一标识

HTTP----HTTP缓存机制 (opens new window)

面试精选之http缓存 (opens new window)

# 5. 关于HTTPS

# 5.1 HTTP的缺点有哪些?

  1. 使用明文进行通信,内容可能会被窃听;
  2. 不验证通信方的身份,通信方的身份有可能遭遇伪装;
  3. 无法证明报文的完整性,报文有可能遭篡改。

# 5.2 HTTPS的工作原理

用户通过浏览器请求HTTPS网站,服务器收到请求,选择浏览器支持的加密和hash算法,同时返回数字证书给浏览器,包含颁发机构、网址、公钥、证书有效期等信息。 浏览器对证书的内容进行校验,如果有问题,则会有一个提示警告。 否则,就生成一个随机数X,同时使用证书中的公钥进行加密,并且发送给服务器。 服务器收到之后,使用私钥解密,得到随机数X,然后使用X对网页内容进行加密,返回给浏览器浏览器则使用X和之前约定的加密算法进行解密,得到最终的网页内容 在这里插入图片描述

# 5.3 HTTPS采用的加密方式有哪些?是对称还是非对称?

HTTPS 采用混合的加密机制,使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性,之后使用对称密钥加密进行通信来保证通信过程的效率。 在这里插入图片描述 确保传输安全过程(其实就是rsa原理): Client给出协议版本号、一个客户端生成的随机数(Client random),以及客户端支持的加密方法。 Server确认双方使用的加密方法,并给出数字证书、以及一个服务器生成的随机数(Server random)。 Client确认数字证书有效,然后生成呀一个新的随机数(Premaster secret),并使用数字证书中的公钥,加密这个随机数,发给Server。 Server使用自己的私钥,获取Client发来的随机数(Premaster secret)。 Client和Server根据约定的加密方法,使用前面的三个随机数,生成”对话密钥”(session key),用来加密接下来的整个对话过程。

# 5.4 HTTP和HTTPS的区别

HTTP是超文本传输协议,设计目的是保证客户机与服务器之间的通信

HTTPS=HTTP+加密+认证+完整性保护

HTTPS通过SSL证书验证通信方的身份,并为浏览器和服务器之间的通信进行加密。通常,HTTP直接和TCP通信,当使用SSL时,则HTTP先和SSL通信,再由SSL和TCP通信。

# 5.5 HTTPS的缺点

(1)除了和TCP连接,发送HTTP请求外,还必须和SSL通信,因此通信慢; (2)SSL必须进行加密处理,在服务器和客户端都需要进行加密和解密的运算处理,因此更多地消耗硬件资源,导致负载增强; (3)申请SSL证书需要费用。

# 5.6 SSL中的认证中的证书是什么?

通过使用 证书 来对通信方进行认证。 数字证书认证机构(CA,Certificate Authority)是客户端与服务器双方都可信赖的第三方机构。 服务器的运营人员向 CA 提出公开密钥的申请,CA 在判明提出申请者的身份之后,会对已申请的公开密钥做数字签名,然后分配这个已签名的公开密钥,并将该公开密钥放入公开密钥证书后绑定在一起。 进行 HTTPS 通信时,服务器会把证书发送给客户端。 客户端取得其中的公开密钥之后,先使用数字签名进行验证,如果验证通过,就可以开始通信了。

# 5.7 为什么有的时候刷新页面不需要重新建立 SSL 连接?

TCP 连接有的时候会被浏览器和服务端维持一段时间,TCP 不需要重新建立,SSL 自然也会用之前的。

# 6. DNS的解析过程?域名解析

DNS:将域名和IP地址的映射关系保存在一个分布式的数据库中。 (1)当浏览器拿到输入的网址后,首先会去浏览器的DNS缓存中去查询是否有对应的记录,如果查询到就直接返回IP地址,完成解析; (2)如果浏览器中没有缓存,就会查看操作系统的缓存; (3)如果操作系统中没有缓存,去查看本地host文件(windows下的host文件一般位于“C:\Windows\System32\drivers\etc”); (4)如果本地host文件也没有响应的记录,那就需要求助本地的dns服务器(本地dns服务器的ip地址是114.114.114.114); (5)找到本地的DNS服务器后,它会先查询一遍自己的缓存,若没有记录,再去根域名(.com)服务器查询; (6)当根域名接收到本地DNS的解析后,发现后缀是.com,于是就把负责.com顶级域名的服务器IP地址返回给本地DNS; (7)本地DNS拿着返回的ip地址再去找对应的顶级域名服务器,该服务器将负责该域名的权威服务器ip返回回去; (8)本地DNS又拿着ip去找对应的权威服务器,权威服务器最终将对应的主机ip返回给本地DNS,至此完成了域名的解析。

# 7. ARP协议的工作过程 解析地址

解析地址,根据通信方的IP地址反查出对应的MAC地址 在这里插入图片描述

# 8. 关于TCP协议

# 8.1 TCP的三次握手

tree-way handshaking SYN synchronize 同步 ACK acknowledgement 确认

  1. 刚开始客户端处于 closed 的状态,服务端处于 listen 状态。
  2. 第一次握手:客户端给服务端发一个 SYN 报文,并指明客户端的初始化序列号 ISN(c)。此时客户端处于 SYN_Send 状态。
  3. 第二次握手:服务器收到客户端的 SYN 报文之后,会以自己的 SYN 报文作为应答,并且也是指定了自己的初始化序列号 ISN(s),同时会把客户端的 ISN + 1 作为 ACK 的值,表示自己已经收到了客户端的 SYN,此时服务器处于 SYN_REVD 的状态。
  4. 第三次握手:客户端收到 SYN 报文之后,会发送一个 ACK 报文,当然,也是一样把服务器的 ISN + 1 作为 ACK 的值,表示已经收到了服务端的 SYN 报文,此时客户端处于 establised 状态。
  5. 服务器收到 ACK 报文之后,也处于 establised 状态,此时,双方以建立起了链接。 在这里插入图片描述

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

# 8.2 TCP的四次挥手

在这里插入图片描述

  1. 刚开始双方都处于 establised 状态,假如是客户端先发起关闭请求:
  2. 第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于CLOSED_WAIT1状态。
  3. 第二次挥手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 + 1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT2状态。
  4. 第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
  5. 第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT 状态。
  6. 需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态。

在这里插入图片描述 client端向server发送FIN包,进入FIN_WAIT_1状态,这代表client端已经没有数据要发送了server端收到之后,返回一个ACK,进入CLOSE_WAIT等待关闭的状态,因为server端可能还有没有发送完成的数据等到server端数据都发送完毕之后,server端就向client发送FIN,进入LAST_ACK状态client收到ACK之后,进入TIME_WAIT的状态,同时回复ACK,server收到之后直接进入CLOSED状态,连接关闭。但是client要等待2MSL(报文最大生存时间)的时间,才会进入CLOSED状态。

# 为什么握手要3次?挥手要4次?

  1. 为什么握手要3次? 因为TCP是双工传输模式,不区分客户端和服务端,连接的建立是双向的过程。如果只有两次,无法做到双向连接的建立,从建立连接server回复的SYN和ACK合并成一次可以看出来,他也不需要4次。

  2. 挥手为什么要四次? 因为挥手的ACK和FIN不能同时发送,因为数据发送的截止时间不同。

# 8.3 为什么要等待2MSL的时间才关闭?

为了保证连接的可靠关闭。如果server没有收到最后一个ACK,那么就会重发FIN。为了避免端口重用带来的数据混淆。如果client直接进入CLOSED状态,又用相同端口号向server建立一个连接,上一次连接的部分数据在网络中延迟到达server,数据就可能发生混淆了。

# 8.4 简述TCP与UDP的区别

TCP和UDP是OSI模型中的运输层中的协议。 TCP提供可靠的通信传输,而UDP则常被用于让广播和细节控制交给应用的通信传输。

  1. TCP TCP是一种面向连接的传输层协议,在传输数据之间必须先建立连接,数据传输结束后要释放链接。TCP提供可靠传输,它的可靠性体现在传输数据之前会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传输完断开连接。

  2. UDP UDP是无连接的,在传输数据之前不需要先建立连接,远程主机在收到UDP报文之后,不需要给出任何确认,虽然不可靠,但是高效,可用于即时通信。

  3. 区别

    1. TCP是面向有连接型,UDP是面向无连接型即发送数据前不需要建立链接;
    2. TCP支持传输可靠性的多种措施,包括保证包的传输顺序、重发机制、流量控制和拥塞控制;UDP仅提供最基本的数据传输能力。无法保证可靠
    3. TCP是一对一传输,UDP支持一对一、一对多、多对一和多对多的交互通信;
    4. TCP是面向字节流的,即把应用层传来的报文看成字节流,将字节流拆分成大小不等的数据块,并添加TCP首部;UDP是面向报文的,对应用层传下来的报文不拆分也不合并,仅添加UDP首部;
    5. TCP数据传输,UDP数据传输

# 8.5 TCP怎么保证传输过程的可靠性?

  1. 校验和:发送方在发送数据之前计算校验和,接收方收到数据后同样计算,如果不一致,那么传输有误。
  2. 确认应答,序列号:TCP进行传输时数据都进行了编号,每次接收方返回ACK都有确认序列号。
  3. 超时重传:如果发送方发送数据一段时间后没有收到ACK,那么就重发数据。连接管理:三次握手和四次挥手的过程。
  4. 流量控制:TCP协议报头包含16位的窗口大小,接收方会在返回ACK时同时把自己的即时窗口填入,发送方就根据报文中窗口的大小控制发送速度。
  5. 拥塞控制:刚开始发送数据的时候,拥塞窗口是1,以后每次收到ACK,则拥塞窗口+1,然后将拥塞窗口和收到的窗口取较小值作为实际发送的窗口,如果发生超时重传,拥塞窗口重置为1。这样做的目的就是为了保证传输过程的高效性和可靠性。

# 8.6 TCP对应的典型的应用层协议

FTP:文件传输协议; SSH:远程登录协议; HTTP:web服务器传输超文本到本地浏览器的超文本传输协议。 UDP对应的典型的应用层协议:

DNS:域名解析协议; TFTP:简单文件传输协议; SNMP:简单网络管理协议。

# 9. 关于地址与端口

# 9.1 IP地址分为哪几类?简单说一下各个分类

在这里插入图片描述 IPv6 -- 采用128bit,首部固定部分为40字节。

# 9.2 IP地址、MAC地址、端口号的区别

以太网用MAC地址 MAC地址用于识别数据链路中互连的节点。 MAC地址指网卡所属的固定地址(具有唯一性)

IP协议用IP地址 IP地址指明了节点被分配到的地址

TCP/UDP用端口号

在这里插入图片描述

# 9.3 端口及对应的服务

在这里插入图片描述

# 9.4 有哪些私有(保留)地址?

A类:10.0.0.0 - 10.255.255.255 B类:172.16.0.0 - 172.31.255.255 C类:192.168.0.0 - 192.168.255.255

# 10. 负载均衡有哪些实现方式?

  1. DNS:这是最简单的负载均衡的方式,一般用于实现地理级别的负载均衡,不同地域的用户通过DNS的解析可以返回不同的IP地址,这种方式的负载均衡简单,但是扩展性太差,控制权在域名服务商。
  2. Http重定向:通过修改Http响应头的Location达到负载均衡的目的,Http的302重定向。这种方式对性能有影响,而且增加请求耗时。
  3. 反向代理:作用于应用层的模式,也被称作为七层负载均衡,比如常见的Nginx,性能一般可以达到万级。这种方式部署简单,成本低,而且容易扩展。
  4. IP:作用于网络层的和传输层的模式,也被称作四层负载均衡,通过对数据包的IP地址和端口进行修改来达到负载均衡的效果。常见的有LVS(Linux Virtual Server),通常性能可以支持10万级并发。

按照类型来划分的话,还可以分成DNS负载均衡、硬件负载均衡、软件负载均衡。其中硬件负载均衡价格昂贵,性能最好,能达到百万级,软件负载均衡包括Nginx、LVS这种

# 11. WebSocket协议

WebSocket协议:5分钟从入门到精通 (opens new window)

HTML5开始提供的一种浏览器与服务器进行全双工通讯的网络技术,属于应用层协议。它基于TCP传输协议,并复用HTTP的握手通道。

优点 支持双向通信,实时性更强。 更好的二进制支持

# 12. 什么是 JWT

JSON Web Token(简称 JWT)是目前最流行的跨域认证解决方案。 是一种认证授权机制。

JSON Web Token 入门教程http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html (opens new window)

# 13. Web存储与身份认证

# 13.1 cookie、localStorage和sessionStorage

在这里插入图片描述

  1. 安全性: Session 比 Cookie 安全,Session 是存储在服务器端的,Cookie 是存储在客户端的。
  2. 存取值的类型不同:Cookie 只支持存字符串数据,想要设置其他类型的数据,需要将其转换成字符串,Session 可以存任意数据类型。
  3. 有效期不同: Cookie 可设置为长时间保持,比如我们经常使用的默认登录功能,Session 一般失效时间较短,客户端关闭(默认情况下)或者 Session 超时都会失效。
  4. 存储大小不同: 单个 Cookie 保存的数据不能超过 4K,Session 可存储数据远高于 Cookie,但是当访问量过多,会占用过多的服务器资源。

# 13.3 Token 和 Session 的区别

  1. Session 是一种记录服务器和客户端会话状态的机制,使服务端有状态化,可以记录会话信息。而 Token 是令牌,访问资源接口(API)时所需要的资源凭证。Token 使服务端无状态化,不会存储会话信息。

  2. Session 和 Token 并不矛盾,作为身份认证 Token 安全性比 Session 好,因为每一个请求都有签名还能防止监听以及重放攻击,而 Session 就必须依赖链路层来保障通讯安全了。如果你需要实现有状态的会话,仍然可以增加 Session 来在服务器端保存一些状态。

  3. 所谓 Session 认证只是简单的把 User 信息存储到 Session 里,因为 SessionID 的不可预测性,暂且认为是安全的。而 Token ,如果指的是 OAuth Token 或类似的机制的话,提供的是 认证 和 授权 ,认证是针对用户,授权是针对 App 。其目的是让某 App 有权利访问某用户的信息。这里的 Token 是唯一的。不可以转移到其它 App上,也不可以转到其它用户上。Session 只提供一种简单的认证,即只要有此 SessionID ,即认为有此 User 的全部权利。是需要严格保密的,这个数据应该只保存在站方,不应该共享给其它网站或者第三方 App。所以简单来说:如果你的用户数据可能需要和第三方共享,或者允许第三方调用 API 接口,用 Token 。如果永远只是自己的网站,自己的 App,用什么就无所谓了。

# 14. 什么是Restful API

传统methods

  • GET 获取服务器数据
  • POST 向服务器提交数据

现代methods

  • GET 获取数据
  • POST 新建数据
  • PATCH/PUT 更新数据
  • DELETE删除数据

传统API:把每个URL当作一个功能 Restful API: 把每个URL当作一个唯一的资源

用 URL 定位资源,用 HTTP 动词(GET,POST,DELETE,PUT)描述操作 尽量不用URL参数,用method表示操作类型

① url参数

传统API :/api/list?pageIndex=2 Restful API :/api/list/2

② method表示操作类型

  1. 传统API POST请求 /api/create-blog POST请求 /api/update-blog?id=100 GET请求 /api/get-blog?id=100
  2. Restful API POST请求 /api/blog PATCH请求 /api/blog/100 GET请求 /api/blog/100

# 15. 协议英文全称

# HTTP

HyperText Transfer Protocol 超文本传输协议

# HTTPS

HTTP Secure 超文本传输安全协议 HTTP over SSL

# URL

Uniform Resource Locator 统一资源定位符

# URI

Uniform Resource Identifier 统一资源标识符

# FTP

File Transfer Protocol 文件传输协议

# DNS

Domain Name System 域名系统

# TCP

Transmission Control Protocol 传输控制协议

# UDP

User Data Protocol 用户数据报协议

# NIC

Network Interface Card 网络适配器,网卡

# IP

Internet Protocol 网际协议

# MAC

Media Access Control Address 媒体存取控制位址

# ARP

Address Resolution Protocol 地址解析协议

# SSL

Secure Socket Layer 安全套接层

# TLS

Transport Layer Security,安全传输层协议

# 参考

关于网络面试题你只要知道这12题就够了 (opens new window) 大厂面试题之计算机网络重点篇(附答案) (opens new window) 计算机网络面试题(含答案) (opens new window) 吐血整理!计算机网络超高频面试题汇总 (opens new window)

《图解TCP/IP(第5版)》 《图解HTTP》 《网络是怎样连接的》

上次更新: 2022/4/22 16:19:50