1、TCP 和 UDP 协议有什么区别,分别适用于什么场景?
TCP(Transmission Control Protocol)和UDP(User Datagram Protocol)是两种常用的传输层协议,两者的区别比较如下:
TCP | UDP | |
---|---|---|
可靠性 | 可靠 | 不可靠 |
连接性 | 面向链接 | 无连接 |
报文 | 面向字节流 | 面向报文 |
效率 | 传输效率低 | 传输效率高 |
安全性 | 容易被攻击、安全性不如UDP | 也会被攻击,相对TCP来说安全 |
可靠性 | 可靠,无差错、不丢失、不重复有序的传输 | 不可靠传输,不保证传输有序性 |
双工性 | 全双工 | 一对一、一对多、多对一、多对多 |
流量控制 | 滑动窗口 | 无 |
拥塞控制 | 慢开始、拥塞避免、快重传、快恢复 | 无 |
传输速度 | 慢 | 快 |
应用场景 | 对效率要求低,对准确性要求高或要求有链接的场景 | 对效率要求高、对准确性要求低 |
TCP(Transmission Control Protocol)和UDP(User Datagram Protocol)是两种常用的传输层协议,它们有以下的区别:
1、连接方面
TCP 是面向连接的协议,而 UDP 是无连接的协议。在 TCP 中,发送方和接收方必须先建立连接,然后才能传输数据。UDP 则不需要建立连接,直接发送数据即可。
2、可靠性 TCP 保证数据传输的可靠性,通过序列号、确认应答和重传机制等方式来保证数据的完整性和正确性。UDP 则不保证数据传输的可靠性,因为它不提供确认和重传机制。
3、传输速度 因为 TCP 要保证数据传输的可靠性,所以在传输速度方面相对较慢。而 UDP 则不需要进行复杂的传输控制,因此传输速度更快。
4、传输内容 TCP 是一种面向字节流的协议,将数据看作是一连串的字节流,没有明确的消息边界。UDP 则是面向报文的协议,将数据看作是一系列的报文,每个报文是一个独立的单元,具有明确的消息边界。
基于以上的特点,TCP 和 UDP 适用于不同的场景。TCP 适用于对传输可靠性要求比较高的场景,例如网页浏览、文件传输、邮件等。而 UDP 则适用于对传输可靠性要求较低、传输速度要求较高的场景,例如在线游戏、视频直播等。
TCP 用于在传输层有必要实现可靠传输的情况;而在一方面,UDP 主要用于那些对高速传输和实时性有较高要求的通信或广播通信。TCP 和 UDP 应该根据应用的目的按需使用。
2、如何用 Redis 实现分布式 Session?
回答一:
通过redis中的hash来实现,将token的值作为键,他里面的每一个字段对应着,用户相关的信息,当用户第一次登陆的时候就会生成一个token,在用户下次登陆的时候就会请求头中携带这个token,后端通过校验请求头的token在redis中是否存在,如果存在就直接返回用户的信息,不存在就直接跳转登录页,这个token可以使用uuid的形式来生成避免重复,以及被窃取的风险
回答二:
在分布式系统中,通常会将 Session 存储在 Redis 中来实现分布式 Session,这样就可以在多台服务器之间共享 Session 数据。实现分布式 Session 的方式有多种,其中一种常用的方式是使用 Redis 的数据结构 Hash。具体实现步骤如下:
- 在用户登录成功后,将 Session 数据存储在 Redis 中。
- 将 Redis 中的 Session 数据的 Key 设置为一个全局唯一的 ID,一般使用类似于“session:token”这样的格式,其中 token 是一个随机生成的字符串,用来标识这个 Session 数据。
- 在客户端返回响应的同时,将 Session ID(即 token)以 Cookie 的形式返回给客户端。客户端在后续的请求中都会携带这个 Cookie。
- 在后续的请求中,服务器会从客户端传递过来的 Cookie 中获取 Session ID,然后根据这个 ID 从 Redis 中获取对应的 Session 数据。如果 Redis 中没有找到对应的 Session 数据,那么就表示这个请求无法通过认证。
- 在用户退出登录或 Session 失效时,需要将 Redis 中的对应 Session 数据删除。
可以使用 Redis 的 EXPIRE 命令来设置 Session 数据的过期时间,这样可以自动删除已经过期的 Session 数据。同时,还需要注意保护 Redis 中的 Session 数据不被恶意攻击者窃取,一般可以通过设置 Session 数据的前缀和使用随机的 Session ID 等方式来提高安全性。
回答三:
在分布式系统中,为了保持用户的登录状态,需要使用Session来记录用户信息,但是单机的Session无法满足高并发和负载均衡的需求。Redis可以通过集群、主从复制等技术实现分布式Session,具体实现方式如下:
- 选择一个集中式的缓存服务器(如Redis),将Session信息存储到缓存服务器中。这里可以使用Redis的Hash数据结构存储Session信息,使用Session ID作为Hash的Key,Session对象作为Hash的Value。
- 为了保证Session的有效性,需要给Session设置一个过期时间。在Redis中,可以通过设置Hash的expire时间来实现Session过期。一般情况下,Session过期时间设置为30分钟或者1个小时。
- 在客户端请求到达应用服务器时,应用服务器会读取Session ID,并通过Session ID从缓存服务器中读取Session信息。如果Session已过期,则需要重新生成一个Session ID,并重新创建一个新的Session信息。
- 为了提高性能,可以在应用服务器本地缓存一份Session信息。当应用服务器需要读取Session信息时,先从本地缓存中读取,如果本地缓存中不存在,则从缓存服务器中读取,并将Session信息保存到本地缓存中。这样可以减少对缓存服务器的访问,提高系统性能。
- 在多台应用服务器上部署同一个应用程序时,需要保证Session的一致性。可以使用Redis的集群或主从复制功能来实现Session的共享。
回答四:
在分布式系统中为了保证用户的登陆态,我们会把用户的登录信息存储在「session」里。而session是依赖于「cookie」的,即服务器创建session时会给它分配一个唯一的ID,并且在响应时创建一个cookie用于存储这个「sessionId」。当客户端收到这个cookie之后,就会自动保存这个sessionId,并且在下次访问时自动携带这个sessionId,届时服务器就可以通过这个sessionId得到与之对应的session,从而识别用户的身。
- 第一是「创建令牌(key)」的程序,就是在用户初次访问服务器时,给它创建一个「唯一的身份标识」,并且使用cookie封装这个标识再发送给客户端。那么当客户端下次再访问服务器时,就会自动携带这个身份标识了,这和sessionId的道理是一样的,只是改由我们自己来实现了。另外,在返回令牌之前,我们需要将它存储起来,以便于后续的验证。而这个令牌是不能保存在服务器本地的,因为其他服务器无法访问它。因此,我们可以将其存储在服务器之外的一个地方,那么Redis便是一个理想的场所。
- 第二是「验证令牌」的程序,就是在用户再次访问服务器时,我们获取到了它之前的身份标识,那么我们就要验证一下这个标识是否存在了。验证的过程很简单,我们从Redis中尝试获取一下就可以知道结果。
3、什么是分布式的 CAP 理论?
CAP原则又称CAP定理,指的是在一个分布式系统中,Consistency(一致性)
、 Availability(可用性)
、Partition tolerance(分区容错性)
这三个基本需求,最多只能同时满足其中的2个。
- 一致性 :数据在多个副本之间能够保持一致的特性。
- 可用性:系统提供的服务一直处于可用的状态,每次请求都能获得正确的响应。
- 分区容错性:分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。
CAP三者不可同得,那么必须得做一些权衡。
CA without P
如果不要求P(不允许分区),则C(强一致性)和A(可用性)是可以保证的。但是对于分布式系统,分区是客观存在的,其实分布式系统理论上是不可选CA的。
CP without A
如果不要求A(可用),相当于每个请求都需要在Server之间强一致,而P(分区)会导致同步时间无限延长,如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
AP wihtout C
要高可用并允许分区,则需放弃一致性。一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。文章来源地址https://www.toymoban.com/news/detail-434411.html
t C**文章来源:https://www.toymoban.com/news/detail-434411.html
要高可用并允许分区,则需放弃一致性。一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。
到了这里,关于面试题30天打卡-day19的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!