RH358管理DNS和DNS服务器--DNS问题故障排除

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: RH358管理DNS和DNS服务器--DNS问题故障排除

RH358管理DNS和DNS服务器–DNS问题故障排除

本章节介绍DNS常见的TroubleShooting。

专栏地址:https://blog.csdn.net/qq_41765918/category_11532281.html

1. DNS故障排除

工作名称解析取决于相关设置是否正确:

  • 客户端名称解析和/etc/resolv.conf。

  • 客户端使用的缓存名称服务器的操作。

  • 向缓存名称服务器提供数据的权威名称服务器的操作。

  • 权威名称服务器上的数据。

  • 用于在这些系统之间通信的网络的配置。

这就产生了几个可能的故障点。

2. 确认名称解析问题的来源

DNS是系统最常用的名称解析方法,因此在发生名称解析错误时经常被指责。但这并不是系统解析主机名和IP地址的唯一方式。但是,也可以使用其他方法进行名称解析,包括本地/etc/hosts文件和Zeroconf网络。

系统的/etc/nsswitch.conf文件中的hosts行控制了查找主机名的方式。一个典型的条目如下所示:

hosts:  files  dns  myhostname
  • 首先在本地/etc/hosts文件中查找主机名。

  • 否则,它将执行DNS查找。

  • 如果DNS查找失败,localhost和系统主机名的结果应该使用nss-myhostname(8)进行解析。

可以使用glibc-common包中的getent命令来执行名称解析,按照/etc/nsswitch.conf所规定的主机名解析顺序来镜像大多数应用程序使用的过程。

[user@host ~]$ getent hosts example.com
172.25.254.254 example.com

如果getent的结果与dig产生的结果不同,那么这就清楚地表明,除了DNS之外,还有其他东西对意外的名称解析结果负责。

3. 调查DNS问题

调查DNS问题的最佳工具之一是dig。dig命令执行DNS查找,并提供详细的响应,其中包括关于请求和结果的诊断信息。

在下面的示例中,使用要解析的名称调用dig。默认情况下,它会在A记录中查找该名称:

[user@host ~]$ dig servera.lab.example.com
; <<>> DiG 9.11.4-RedHat-9.11.4-26.P2.el8 <<>> servera.lab.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3241
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;servera.lab.example.com. IN A

;; ANSWER SECTION:
servera.lab.example.com. 3600 IN A 172.25.250.10

;; Query time: 0 msec
;; SERVER: 172.25.250.254#53(172.25.250.254)
;; WHEN: Wed May 13 15:20:31 CDT 2020
;; MSG SIZE rcvd: 68

结果显示,请求的状态为NOERROR,这意味着请求成功完成。有一份记录作为答案。QUESTION SECTION重述查询,ANSWER SECTION显示返回的资源记录: servera.lab.example.com有一个A记录指向172.25.250.10,并且有一个生存时间(TTL),表明答案应该被缓存3600秒

还可以指定要查找的其他资源记录。例如,下面的命令指定要查找同一主机的AAAA记录:

[user@host ~]$ dig AAAA servera.lab.example.com
; <<>> DiG 9.11.4-RedHat-9.11.4-26.P2.el8 <<>> AAAA servera.lab.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61178
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;servera.lab.example.com. IN AAAA

;; ANSWER SECTION:
servera.lab.example.com. 3600 IN AAAA fde2:6494:1e09:1::a
servera.lab.example.com. 3600 IN AAAA fde2:6494:1e09:2::a

;; Query time: 0 msec
;; SERVER: 172.25.250.254#53(172.25.250.254)
;; WHEN: Wed May 13 15:22:01 CDT 2020
;; MSG SIZE rcvd: 101

这个例子返回了主机的两条AAAA记录。如果缺少ANSWER SECTION且ANSWER为0,则查找没有为该名称找到该类型的资源记录。

通常,dig使用/etc/resolv.conf中列出的DNS名称服务器。可以通过在命令行上添加一个@后跟服务器名来指定一个不同的名称服务器。下面的示例在classroom.example.com上查找example.com的MX记录。他的结果还报告了一些关于名称服务器的相关信息,缓存名称服务器也将缓存这些信息。

[user@host ~]$ dig @classroom.example.com mx example.com
; <<>> DiG 9.11.4-RedHat-9.11.4-26.P2.el8 <<>> @classroom.example.com mx
example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17161
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 98551d3793ee3d2c90d490435ebc5cdec91821df16f7ff0d (good)
;; QUESTION SECTION:
;example.com. IN MX

;; ANSWER SECTION:
example.com. 86400 IN MX 10 classroom.example.com.

;; AUTHORITY SECTION:
example.com. 86400 IN NS classroom.example.com.

;; ADDITIONAL SECTION:
classroom.example.com. 86400 IN A 172.25.254.254

;; Query time: 1 msec
;; SERVER: 172.25.254.254#53(172.25.254.254)
;; WHEN: Wed May 13 15:28:23 CDT 2020
;; MSG SIZE rcvd: 124

诊断网络连通性问题

DNS名称解析要正常工作,客户端必须能够与解析名称服务器通信,解析名称服务器必须能够与其他权威的名称服务器通信。

例如,如果dig不能到达/etc/resolv.conf中的任何DNS服务器,则会出现以下错误。这可能是因为名称服务器宕机、客户端上的网络或防火墙出现问题,或者/etc/resolv.conf配置错误。

[user@host ~]$ dig A example.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> A example.com
;; global options: +cmd
;; connection timed out; no servers could be reached

如果涉及防火墙,则必须确保客户端可以通过UDP和TCP连接53端口的名称服务器。即使DNS主要使用UDP协议,当响应的大小超过512字节(4096字节对于DNS解析器和服务器,支持扩展机制的DNS (EDNS)),解析器必须从UDP切换到TCP,并重试查询。

如果允许53/UDP端口上的流量,但不允许53/TCP端口,会看到截断通知,当解析器遇到一个响应大于它可以处理的UDP时,紧随其后的是主机不可到达的错误:

[user@host ~]$ dig @dns.example.com A labhost1.example.com
;; Truncated, retrying in TCP mode.
;; Connection to 172.25.1.11#53(172.25.1.11) for labhost1.example.com failed:
host unreachable.

dig使用tcp或vc选项来帮助确定DNS查询是否使用TCP可以成功。这些选项强制dig使用TCP,而不是默认的先使用UDP,然后只在较大的响应时退回到TCP。

[user@host ~]$ dig +tcp A example.com

解析DNS响应码

如果DNS客户机-服务器通信成功,则dig将生成更多详细的输出,详细说明从DNS服务器接收到的响应的性质。dig输出HEADER部分的status状态字段报告DNS服务器为响应客户机的查询而生成的响应代码。

[user@host ~]$ dig A example.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> A example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30523
…………

NOERROR状态表示查询已成功解析。

如果服务器在执行客户端查询时遇到问题,会显示以下常见错误状态码之一:

DNS状态码

状态码 意义
SERVFAIL 名称服务器在处理查询时遇到问题。
NXDOMAIN 查询的名称在zone中不存在。
REFUSED 由于策略限制,名称服务器拒绝了客户端的DNS请求。

SERVFAIL

造成SERVFAIL返回代码的一个常见原因是DNS服务器无法与授权查询名称的名称服务器进行通信。这可能是因为权威名称服务器不可用。可能是由网络问题引起的,这些问题干扰了缓存DNS服务器和权威名称服务器之间的客户机-服务器通信,例如网络路由问题或网络路径上任何一跳上的防火墙规则。

要确定为什么名称服务器在代表客户端查询执行递归时生成SERVFAIL返回代码,名称服务器管理员需要确定是哪个名称服务器通信导致了失败。在这个场景中,可以使用dig的+trace选项来查看名称服务器的迭代查询的结果,从根名称服务器开始。

NXDOMAIN

NXDOMAIN返回码表示没有找到与查询的名称相关的记录。如果这不是预期的结果,并且查询指向的服务器不是该名称的权威,那么服务器的缓存可能包含该名称的反向缓存。用户可以等待服务器将该名称的负缓存过期,或者向服务器管理员提交请求,从服务器缓存中清除该名称。名称从缓存中删除后,服务器将查询权威名称服务器,以接收名称的当前资源记录。

NXDOMAIN返回码可能出现的另一种情况是在查询包含孤立CNAME的CNAME记录时。在CNAME记录中,记录右侧的名称(规范名称)应该指向包含a或AAAA记录的名称。如果这些关联的记录不存在或稍后被删除,则CNAME记录中的规范名称是孤立的。当这种情况发生时,查询CNAME记录中的所有者名称将不再是可解析的,并将导致一个NXDOMAIN返回码。

REFUSED

REFUSED返回码表示DNS服务器存在策略限制,无法完成客户端的查询。策略限制通常在DNS服务器上实现,以限制哪些客户端可以进行递归查询和区域传输请求。导致REFUSED返回码的常见原因有:客户端配置了错误的DNS服务器,或者DNS服务器配置错误导致有效的客户端请求被拒绝。

尽管NOERROR状态表示在解析查询时没有遇到错误,但它不能保证不存在DNS问题。存在这样的情况:DNS响应中的DNS记录可能与预期的结果不匹配。

4. 在缓存名称服务器上处理旧数据

缓存名称服务器可以减少DNS工作负载并提高DNS性能。但是,缓存可能会导致客户端接收到过时的信息。

当DNS应答来自已不在权威服务器上当前的缓存数据,但TTL尚未过期时,就会发生这种情况。这可能是区域管理员在更改资源记录数据之前将TTL设置得过高的结果。

在这些情况下,必须首先确认响应是非权威的缓存数据。查看挖掘输出的标志部分。权威的答案由aa标识的存在表示

[user@host ~]$ dig A example.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> A example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31114
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

来源于缓存数据的DNS响应是不权威的,因此没有aa标志集。答案来自缓存的另一个指示是在后续查询的响应中减少了资源记录的TTL值。缓存数据的TTL持续倒计时到过期,而权威数据的TTL始终保持静态。

权威名称服务器管理员应该在更改之前将记录的TTL设置为低,然后在记录更新时将其设置为正常,这样就不会发生这个问题。当发生这种情况时,管理员通常必须等待每个人缓存中的旧版本过期。如果使用过时的、未过期的记录管理缓存名称服务器,则可以从缓存中清除坏记录。使用Unbound名称服务器时,使用unbound-control flush record-name命令刷新与record-name关联的记录。

5. 识别区域数据的问题

有时,名称解析问题是由于权威名称服务器上的区域配置中的意外行为、遗漏或错误造成的。即使您不管理权威的名称服务器,您也应该能够识别返回到客户机的数据是否是问题所在。在管理区域文件时,诊断这些问题的能力更加重要。

获得不同的答案:Round-robin轮循式DNS

一个名称在DNS中可以有多条记录。这允许您配置轮循DNS,并且通常用作一种简单、低成本的负载均衡机制,以便在多个主机之间分配网络资源负载。

当DNS客户端提交一个包含多个a或AAAA记录的名称查询时,所有记录作为一个集合返回。但是,在集合中返回这些记录的顺序对于每个查询都是不同的。因为客户端通常使用集合中的第一个地址,所以每个响应中记录顺序的更改会有效地导致跨这些轮循DNS记录中的多个IP地址分发网络服务请求。

当错误地创建此配置时,有时会出现问题。例如,权威名称服务器的管理员可能打算更改主机的A记录,但错误地为该主机添加了第二个A记录,而没有删除旧的记录。如果旧的A记录的IP地址在服务器上退役了,但仍然在DNS中,roundrobin DNS的负载分布效应将导致大约一半的客户端(得到过时的A记录的那一半)服务失败。

看到反向查找失败:丢失PTR记录

许多网络服务使用DNS来执行来自客户机的传入连接的反向查找。DNS中缺少PTR记录可能会导致问题,问题的性质取决于服务。缺省情况下,SSHD执行连接客户机ip的反向查找。缺少PTR记录会导致这些连接的建立延迟。

许多邮件服务器合并反向DNS查找连接的客户端ip作为防御恶意电子邮件客户端。事实上,许多邮件服务器被配置为拒绝ip的客户端连接,这无法通过DNS中的PTR查询来解析。因此,支持网络服务的管理员需要确保他们理解这些服务不仅对正向DNS查找有需求,而且对反向DNS查找也有需求。

对不存在记录的响应

如果从区域中删除了一条记录,并且在查询该记录时仍然收到响应,那么首先要确认没有从缓存的数据中响应查询。如果答案是经过挖掘输出中aa标志的确认的,那么可能的原因是区域中存在通配符(*)记录。

*.example.com. IN A 172.25.254.254

通配符记录可作为给定类型中不存在名称的所有查询的通配符。在前面的通配符记录存在的情况下,如果先前存在host.example.com的A记录并且它被删除了,对该名称的查询仍然会成功,并且通配符A recoro中的IP地址将在其位置上提供。

在名称中看到FQDN两次以及相关错误

在区域文件中,没有表示为完全限定域名(FQDNs)的主机名通过附加区域的名称自动扩展为FQDNs。表示名字是一个区域文件中的FQDN,它必须以“.”结尾。例如:“www.example.com. ”如果不这样做,可能会导致不同的问题,这取决于所犯错误的记录类型。例如,在NS记录的特定类型数据部分中犯这样的错误可能会使整个区域失去能力,而在MX记录中犯这样的错误可能会导致一个域的电子邮件传递完全停止。

标识循环CNAME记录

应该避免指向CNAME记录的CNAME记录,以减少DNS查找的低效。另一个不受欢迎的原因是可能会创建不可解析的CNAME循环,例如:

test.example.com. IN CNAME lab.example.com.
lab.example.com.  IN CNAME test.example.com.

当一个CNAME记录带有一个孤立的CNAME将导致一个NXDOMAIN状态,循环CNAME记录将返回一个NOERROR状态。

注意:大多数权威的名称服务器保护相同区域的记录之间不发生CNAME循环,但在某些情况下,仍然可以在跨多个区域的CNAME记录链中创建循环。

从权威服务器获得不同的答案

有时,您可能会发现您的主名称服务器在其区域内为DNS查询提供了与其他权威名称服务器不同的答案。这通常是因为您的其他服务器没有来自主服务器的区域的最新版本。

当对这种情况进行故障排除时要问的一些问题包括:

  • 名称服务器是否有受影响的区域的最新版本?查看SOA记录中的序列号。

  • 当您更新主服务器上的区域文件时,是否增加了区域SOA记录中的序列号?

  • 主服务器和其他授权服务器之间的通信是否因网络问题或防火墙而受阻?

  • 主服务器是否配置为允许其他名称服务器执行区域传输?使用BIND,检查主服务器的allow-transfer指令。

  • 其他授权名称服务器是否配置为与该区域的正确主服务器通信?

6. 课本练习(第106页)

[student@workstation ~]$ lab dns-tshooting start

用户报告当从服务器向example.com发起SSH会话时发生问题。当命令失败时,显示以下错误信息:" Could not resolve hostname example.com: Name or service not known"

用户怀疑example.com的DNS名称解析有问题。与网络上的所有其他主机一样,服务器应该使用172.25.250.254作为DNS解析。这些信息通常是从DHCP配置的。

对问题进行故障排除,确定根本原因,应用修复,并验证问题已解决。

1. 查看问题。

[student@workstation ~]$ ssh servera
[student@servera ~]$ ssh example.com
ssh: Could not resolve hostname example.com: Name or service not known
[student@servera ~]$ getent hosts example.com
[student@servera ~]$

2. 确定哪些配置影响名称解析。

# 使用grep命令显示/etc/nsswitch.conf文件中的hosts条目。确定名称服务的使用顺序。
[student@servera ~]$ grep ^hosts: /etc/nsswitch.conf
hosts: files dns myhostname

# 因为首先使用文件,所以请检查/etc/hosts文件的内容,以确定是否有example.com的条目。
[student@servera ~]$ grep [[:space:]]example.com /etc/hosts
[student@servera ~]$

# 因为hosts文件没有条目。查看/etc/resolv.conf文件的内容,以确定正确的name-server条目。name server的IP地址为172.25.250.254。如果您有一个不同的名称服务器IP地址,这很可能是名称解析失败的原因。
[student@servera ~]$ grep ^nameserver /etc/resolv.conf
nameserver 172.25.250.255

[student@servera ~]$ dig @172.25.250.255 A example.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> @172.25.250.255 A example.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

3.修改为正确的配置。

使用NetworkManager服务用正确的name-server条目刷新/etc/resolv.conf文件的内容。

# 验证新条目并确认它解决了名称解析问题。
[student@servera ~]$ sudo systemctl restart NetworkManager
[sudo] password for student: student
[student@servera ~]$

[student@servera ~]$ grep ^nameserver /etc/resolv.conf
nameserver 172.25.250.254

# 验证example.com的名称解析结果。
[student@servera ~]$ getent hosts example.com
172.25.254.254 example.com

[student@servera ~]$ dig example.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el8 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52873
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.            IN    A

;; ANSWER SECTION:
example.com.        86346    IN    A    172.25.254.254

;; Query time: 0 msec
;; SERVER: 172.25.250.254#53(172.25.250.254)
;; WHEN: Thu Jun 10 21:23:05 CST 2021
;; MSG SIZE  rcvd: 56

# 验证从服务器到example.com的SSH连接现在成功了。
[student@servera ~]$ ssh example.com

完成实验。

[student@workstation ~]$ lab dns-tshooting finish

总结

  • 介绍DNS故障排除。
  • 根据响应码调查DNS故障。
  • 如何识别区域数据的问题。
  • 若喜欢金鱼哥的文章,顺手点个赞。也可点个关注,因为后续会不断上干货。

目录
相关文章
|
13天前
|
存储 弹性计算 缓存
阿里云服务器ECS通用型实例规格族特点、适用场景、指标数据解析
阿里云服务器ECS提供了多种通用型实例规格族,每种规格族都针对不同的计算需求、存储性能、网络吞吐量和安全特性进行了优化。以下是对存储增强通用型实例规格族g8ise、通用型实例规格族g8a、通用型实例规格族g8y、存储增强通用型实例规格族g7se、通用型实例规格族g7等所有通用型实例规格族的详细解析,包括它们的核心特点、适用场景、实例规格及具体指标数据,以供参考。
阿里云服务器ECS通用型实例规格族特点、适用场景、指标数据解析
|
17天前
阿里云服务器带宽价格参考:选择1M、3M、5M、10M宽带价格解析
阿里云服务器1M、3M、5M、10M宽带需要多少钱?单说阿里云服务器宽带多少钱,而不确定云服务器实例规格及cpu和内存配置的话,是没办法具体说多少钱的,因为云服务器的价格受很多因素影响。本文将详细解析阿里云服务器在选择1M、3M、5M、10M不同带宽下的价格差异,以供大家参考。
阿里云服务器带宽价格参考:选择1M、3M、5M、10M宽带价格解析
|
7天前
|
存储 数据挖掘 数据库
服务器数据恢复—raid磁盘故障导致数据库数据损坏的数据恢复案例
存储中有一组由3块SAS硬盘组建的raid。上层win server操作系统层面划分了3个分区,数据库存放在D分区,备份存放在E分区。 RAID中一块硬盘的指示灯亮红色,D分区无法识别;E分区可识别,但是拷贝文件报错。管理员重启服务器,导致离线的硬盘上线开始同步数据,同步还没有完成就直接强制关机了,之后就没有动过服务器。
|
26天前
|
存储 弹性计算 运维
自动化监控和响应ECS系统事件
阿里云提供的ECS系统事件用于记录云资源信息,如实例启停、到期通知等。为实现自动化运维,如故障处理与动态调度,可使用云助手插件`ecs-tool-event`。该插件定时获取并转化ECS事件为日志存储,便于监控与响应,无需额外开发,适用于大规模集群管理。详情及示例可见链接文档。
|
1月前
|
存储 安全 算法
服务器数据恢复—Raid磁盘阵列的安全性分析及常见故障
出于尽可能避免数据灾难的设计初衷,RAID解决了3个问题:容量问题、IO性能问题、存储安全(冗余)问题。从数据恢复的角度讨论RAID的存储安全问题。 常见的起到存储安全作用的RAID方案有RAID1、RAID5及其变形。基本设计思路是相似的:当部分数据异常时,可通过特定算法将数据还原出来。以RAID5为例:如果要记录两个数字,可以通过再多记录这两个数字的和来达到记录冗余性的目的。例如记录3和5,同时再记录这2个数字的和8。在不记得到底是几和5的情况下,只需要用8-5就可以算出这个丢失的数字了,其余情况依此类推。
|
8天前
|
存储 Oracle 关系型数据库
服务器数据恢复—存储硬盘故障导致映射到服务器上的卷挂载不上的数据恢复案例
一台存储上有一组由16块FC硬盘组建了一组raid。存储前面板上的对应10号和13号硬盘的故障灯亮起,存储映射到redhat linux操作系统服务器上的卷挂载不上,业务中断。
|
1月前
|
弹性计算 开发框架 数据可视化
阿里云虚拟主机和云服务器有什么区别?多角度全解析对比
阿里云虚拟主机与云服务器ECS的主要区别在于权限与灵活性。虚拟主机简化了网站搭建流程,预装常用环境,适合初级用户快速建站;而云服务器提供全面控制权,支持多样化的应用场景,如APP后端、大数据处理等,更适合具备技术能力的用户。尽管虚拟主机在价格上通常更优惠,但随着云服务器价格的下降,其性价比已超越虚拟主机,成为更具吸引力的选择。
|
29天前
|
域名解析 监控 负载均衡
智能DNS解析:自动选择最快服务器的奥秘
【9月更文挑战第7天】智能DNS解析是一种根据用户网络环境和服务器负载动态选择最佳服务器的技术,显著提升了访问速度与稳定性。本文详细介绍了其工作原理,包括实时监控、数据分析和路由选择,并探讨了自动选择最快服务器背后的算法策略,如负载均衡、地理位置识别及实时测试。附带示例代码帮助理解其基本实现过程。
63 0
|
2月前
|
API C# 开发框架
WPF与Web服务集成大揭秘:手把手教你调用RESTful API,客户端与服务器端优劣对比全解析!
【8月更文挑战第31天】在现代软件开发中,WPF 和 Web 服务各具特色。WPF 以其出色的界面展示能力受到欢迎,而 Web 服务则凭借跨平台和易维护性在互联网应用中占有一席之地。本文探讨了 WPF 如何通过 HttpClient 类调用 RESTful API,并展示了基于 ASP.NET Core 的 Web 服务如何实现同样的功能。通过对比分析,揭示了两者各自的优缺点:WPF 客户端直接处理数据,减轻服务器负担,但需处理网络异常;Web 服务则能利用服务器端功能如缓存和权限验证,但可能增加服务器负载。希望本文能帮助开发者根据具体需求选择合适的技术方案。
68 0
|
2月前
|
Java 数据库 API
JSF与JPA的史诗级联盟:如何编织数据持久化的华丽织锦,重塑Web应用的荣耀
【8月更文挑战第31天】JavaServer Faces (JSF) 和 Java Persistence API (JPA) 分别是构建Java Web应用的用户界面组件框架和持久化标准。结合使用JSF与JPA,能够打造强大的数据驱动Web应用。首先,通过定义实体类(如`User`)和配置`persistence.xml`来设置JPA环境。然后,在JSF中利用Managed Bean(如`UserBean`)管理业务逻辑,通过`EntityManager`执行数据持久化操作。
38 0

相关产品

  • 云解析DNS
  • 推荐镜像

    更多
    下一篇
    无影云桌面