【详解】DNS服务工作原理、正反向解析和主从同步

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
简介:

一、理论部分

二、实验部分

******************************理论部分***************************************

正文:

一、什么是DNS服务.

  DNS服务是互联网的基础性服务之一.全称为Domain Name System(域名系统).DNS是因特网上作为域名和IP地址相互映射的一个分布式数据库,提供将域名转换成对应IP地址的信息条目,能够使用户更方便的通过域名(如baidu.com)去访问互联网,而不用去记住能够被机器直接读取的IP地址。这种将域名转换成ip地址的方法称为域名解析.   

二、企业自建DNS的目的.

  其实互联网上已有现成的DNS服务器,那么企业内部为什么还要自建DNS服务器呢?

  主要原因如下:

  • 节省内网域名解析占用的上网带宽;

  • 方便解析内网服务器IP地址;

  • 内网有域环境,域中的计算机通过内网的DNS定位域控制器(Windows)

    ...

三、DNS基础原理详解.  

1、DNS采用C/S架构,服务器端工作在TCP/UDP协议的53号端口.是应用层的协议. 

2、BIND: Bekerley Internet Name Domain (伯克利因特网名字域系统), ISC (www.isc.org) 

3、对于DNS服务使用TCP和UDP协议的解释:

  a. TCP:面向连接的协议; (每次连接前须三次握手,断开时须四次断开,使得传输一段很小的数据时浪费大量时间,所以dns多使用53/udp).
  b. UDP: User Datagram Protocol(用户数据报文协议), 无连接的协议 

  c. DNS在进行区域传送时使用TCP协议,其它时候则使用UDP协议;

  d. TCP是一种可靠的连接,保证了数据的准确性。
  e. named进程查询时使用的是UDP协议的53号端口发送UDP报文。响应通过UDP报文返回,除非他们大于512K,这种情况使用TCP。服务器之间的"区域传送"则都使用TCP。 

4、区域传送:

  当一个辅助(从)DNS服务器启动时,它需要与主DNS服务器通信,并加载(同步)数据信息,这就叫做区域传送(zone transfer)。   
5、DNS域名:

    根域:全球所有的DNS都要听从于它;

    顶级域名:Top Level Domain:tld;

        .com  .edu  .mil  .gov  .net  .org  ...

        三类:组织域,国家域(.cn, .iq, .hk, .tw, ...),反向域

    二级域名:

        google.com  youtube.com baidu.com ...

    三级域名:

        www.google.com  mail.google.com  stu.google.com 

    最多127级域名

  wKiom1hHunahL73aAABICJQYH-Q721.jpg

6、DNS查询类型

 a. 递归查询

   客户端只发出一次请求一定要得到最终结果;(主机向本地域名服务器的查询一般都是采用递归查询.)    

 b. 迭代查询

  服务器发出多次请求,层层请求后返回最终结果;(本地域名服务器向根域名服务器的查询(域名服务器之间的查询)一般都是采用迭代查询) 


  图解:

  wKioL1hHvRCzc8hFAAII3IZT8N8346.png

  wKioL1hHv7HQ7EgNAADIkuf_fKE664.jpg

7. 名称服务器: 域内负责解析本域内名称的主机;
   根服务器: 指13组服务器,异地多活.

8.  DNS解析类型:

   正向解析: Name --> IP  (绝大多数都能正向解析)

   反向解析: IP --> Name  (部分解析不了,该解析类型常用在邮件服务反向解析,来判断是否为垃圾邮件)

   注:正反向解析是两个不同的名称空间,是两棵不同的解析树; 

9. DNS服务器的类型:    

   主DNS服务器
   辅助(从)DNS服务器 
   缓存DNS服务器 
   转发器

1
2
3
4
5
6
7
8
9
10
11
主DNS服务器: 维护所负责解析的域内解析库服务器;解析库由管理员维护;
从DNS服务器: 从主DNS服务器或其他的从DNS服务器那里"复制"(区域传送)一份解析库;
从DNS服务器到主DNS服务器处的传送,之间有一系列定义,主要定义在SOA资源记录当中,包括:   
    序列号:解析库的版本号(同步后主从一致);前提是主服务器解析库内容发生变化,其序列号递增(每
次加1);(数字最长不要超过十位);
    刷新时间:从服务器从主服务器请求同步解析库的时间间隔;   
    重试时间间隔:从服务器从主服务器请求同步解析库失败时,再次尝试的时间间隔,重试时间须小于刷
新时间,否则无意义.   
    过期时长:从服务器始终联系不到主服务器时,多久之后放弃从服务器角色,停止提供服务;   
    通知"机制:主服务器发生变化后,会通知从服务器及时更新解析库,即使更新时间没到也会通知从服
务器,避免从服务器落后主服务器太多.

10. 区域传送类型: 

  a. 全量传送:传送整个解析库;
  b. 增量传送:传送解析库发生变化的那部分内容; 

11. 对从服务器及区域传送的理解:

    从服务器要从主服务器同步.首先,从服务器如何知道主服务器已更新解析库? 主要在于序列号,主服务器每更新一次解析库,序列号都会主动加1;
    正常情况下,主从服务器的序列号相同.从服务器通过刷新时间从主服务器处对比序列号并请求同步解析库的时间间隔.还有重试时间间隔和过期时长.

12. 一次完整的查询/解析请求经过的流程:
   Client --> 本地hosts文件 --> DNS Service 
   Local Cache -->DNS Server(Iesursion) --> Server Cache-->Iteration

13. 区域解析库:

   由众多RR组成;
   资源记录: Resource Record, RR 
   记录类型: A, AAAA, PTR, SOA, NS, CNAME, MX等
      SOA: Start Of Authority,起始授权记录,一个区域解析库有且仅能有一个SOA记录,而且必须为解析库的第一条记录;
      A: internet Address, 作用:FQDN --> IP 
      AAAA: FQDN --> IPv6 
      PTR: PointTeR, IP -->FQDN
      NS: Name Server,专用于标明当前区域的DNS服务器 
      CNAME: Canonical Name,别名记录.正式名称
      MX: Mail exchanger, 邮件交换器
                
    资源记录定义的格式:
       语法:name    [TTL]    IN     rr_type    value 
       注意:
         (1) TTL可从全局继承;
         (2) @可用于引用当前区域的名字;
         (3) 同一个名字可以通过多条记录定义多个不同的值;此时DNS服务器会以轮询方式响应;
         (4) 同一个值也会有多个不同的定义名字;通过多个不同的名字指向同一个值进行定义;                    
SOA:
  name:当前区域的名字,例如"baidu.com.";
  value:有多部分组成
      (1)当前区域的主DNS服务器的FQDN,也可以使用当前区域的名字;
      (2)当前区域管理员的邮箱地址;但地址中不能用@符号,一般用.替换,如linuxedu.163.com 
      (3)主从服务协调属性的定义以及否定的答案的统一的TTL.
                        
 例如:

1
2
3
4
5
6
7
baidu.com.   86400   IN   SOA   ns.baidu.com.   nsadmin.baidu.com.(
                                     2015042201     ;序列号  
                                     2H             ;刷新时间 
                                     10M             ;重试时间 
                                     1W             ;过期时间
                                     1D             ;否定答案的TTL值 
                                     )

 注:不带单位,默认为秒钟;
                    
NS:
  name:当前区域的名字;
  value:当前区域的某DNS服务器的名字,例如 ns.baidu.com.; 
  注:一个区域可以有多个NS记录;
 例如:
                          

1
2
  baidu.com.   IN    NS      ns1.baidu.com.    // 此处nsx.baidu.com. 可写成 nsx  (注:nsx后面没有点号)
  baidu.com.   IN    NS      ns2.baidu.com.

 注:
   (1)相邻的两个资源记录的name相同时,后续的可省略;
   (2)对NS记录而言,任何一个ns记录后面的服务器名字,都应该在后续有一个A记录; 
                            
MX:
  name: 当前区域的名字;
  value: 当前区域的某邮件服务器(smtp服务器)的主机名;
  注:一个区域内,MX记录可有多个;但每个记录的value之前应该有一个数字(0-99),表示此服务器的优先级;数字越小优先级越高;                           
  例:                         

1
2
   baidu.com.     IN      MX     10       mx1.baidu.com. 
                  IN      MX     20       mx2.baidu.com.

 注:
  (1)对MX记录而言,任何一个MX记录后面的服务器名字,都应该在后续有一个A记录;
                            
A:
  name:其主机的FQDN,例如www.baidu.com. 
  value:主机名对应主机的IP地址;

  例:                   

1
2
3
4
5
  www.baidu.com.    IN      A    1.1.1.1 
  www.baidu.com.    IN      A    1.1.1.2   
                             
  mx1.baidu.com.    IN      A    1.1.1.3 
  mx2.baidu.com.    IN      A    1.1.1.3

  

  注:  避免用户写错名称时给错误答案,可通过泛域名解析进行解析至某特定地址,如下:       

1
2
  *.baidu.com.    IN   A     1.1.1.4 
  baidu.com.      IN   A     1.1.1.4

AAAA:
   name:FQDN 
   value: IPv6                          
PTR:
   name: IP ,有特定格式; 
   value: FQDN

   注: name处的IP有特定格式,需要把IP地址反过来写,1.2.3.4,要写作4.3.2.1;而且有特定后缀:.in-addr.arpa.,所以完整写法为:4.3.2.1.in-addra.arpa.                        例如:                        

1
2
3
4.3.2.1. in -addr.arpa    IN     PTR    www.baidu.com 
简写成:
4    IN     PTR    www.baidu.com.

 注:网络地址及后缀可省略;主机地址依然需要反着写:                            
CNAME:
   name: 别名的FQDN;
   value: 正规名字的FQDN;                            
  例:                       

1
   web.baidu.com.      IN     CNAME    www.baidu.com.

14. 子域授权:

   每个域的名称服务器,都是通过其上级名称服务器在解析库进行授权;  

   类似根域授权tld:           

1
2
3
4
.com.       IN        NS    ns1.com 
.com.       IN        NS    ns2.com 
ns1.com.    IN        A     2.2.2.1 
ns2.com.    IN        A     2.2.2.2

  baidu.com. 在.com的名称服务器上,解析库中添加资源记录;           

1
2
3
4
5
6
  baidu.com.            IN        NS        ns1.baidu.com. 
  baidu.com.            IN        NS        ns2.baidu.com. 
  baidu.com.            IN        NS        ns3.baidu.com. 
  ns1.baidu.com.        IN        A         3.3.3.1  
  ns2.baidu.com.        IN        A         3.3.3.2 
  ns3.baidu.com.        IN        A         3.3.3.3

            
15. BIND的安装配置:     
   dns服务,程序包名bind, 程序名named 
   程序包:
       bind.X86_64  提供服务
       bind-libs   提供库文件
       bind-utils  提供测试服务,测试服务是否ok    

1
2
3
4
5
# rpm -ql bind-utils 
  /usr/bin/dig
  /usr/bin/host
  /usr/bin/nslookup
  /usr/bin/nsupdate

  bind-chroot: /var/named/chroot/
  bind-chroot.x86_64  测试环境不可安装.  安全性.
  

  bind:
     服务脚本: /etc/rc.d/init.d/named 
     主配置文件: /etc/named.conf, /etc/named.rfc1912.zones, /etc/rndc.key 
     解析库文件: /var/named/ZONE_NAME.ZONE   分正向和反向. 
     named守护进程–用来回答查询结果
                                     

1
2
3
4
5
6
7
8
9
10
11
12
13
[root@localhost named] # pwd
  /var/named
[root@localhost named] # cat named.localhost 
   $TTL 1D
   @    IN    SOA    @   rname.invalid. (
                     0     ; serial
                    1D     ; refresh
                    1H     ; retry
                    1W     ; expire
                    3H )   ; minimum
         NS    @
         A    127.0.0.1
         AAAA    ::1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@localhost named]
[root@localhost named] # cat named.loopback 
$TTL 1D
@    IN SOA    @ rname.invalid. (
                0    ; serial
                1D    ; refresh
                1H    ; retry
                1W    ; expire
                3H )    ; minimum
      NS      @
      A       127.0.0.1
      AAAA    ::1
      PTR     localhost.
[root@localhost named] #

  注:
     (1) 一台物理服务器可同时为多个区域提供解析;
     (2) 必须要有根区域文件:/var/named/named.ca 
     (3) 应该有两个(如果包括ipv6的,应该更多)实现localhost和本地回环地址的解析库; 
                            
  rndc:

     remote name domain controller,默认与bind安装在同一主机,且只能通过127.0.0.1来连接named进程,提供辅助性的管理功能; 
                        953/tcp 
  主配置文件:
     全局配置:options {}  
     日志子系统配置:logging {}
     区域定义: 本机能够为哪些zone进行解析,就要定义哪些zone; 
     zone  "ZONE_NAME"  IN  {}      
                    
      注意:任何服务程序如果期望其能够通过网络被其他主机访问,至少应该监听在一个能够与外部主机通信的IP地址上;


四、各类型服务器配置介绍:

  1. 缓存DNS服务器:

    修改配置文件/etc/named.conf,使DNS服务53号端口监听于外部地址即可; 

   dnssec作用:防止DNS被污染; 配置麻烦,建议测试做实验时关闭dnssec;即改为no 

2. 主DNS名称服务器:
   在缓存名称服务器的基础上加zone的定义即可;
      (1)在主配置文件/etc/named.rfc1912.zones中定义区域
        zone  "ZONE_NAME"  IN {
        type {master|slave|hint|forward};
        file  "ZONE_NAME.zone";  //区域解析库文件路径
         };
      (2)定义区域解析库文件
          出现的内容:
               宏(变量)定义;
               资源定义;  

  反向区域配置:

    区域名称:网络地址反写.in-addr.
      172.16.100. --> 100.16.172.in-addr.arpa.
    
    保留不变的部分当做区域名字
    
    定义区域
       zone "ZONE_NAME" IN {
          type {master|slave|forward};
          file "网络地址.zone"
       };

    注: 不需要MX和A,以及AAAA记录,以PTR记录为主;

        正向区域中的别名记录(CNAME)在反向区域不需要反解.

3.:通过区域传送实现主从同步:

   配置一台正向从DNS服务器:

   定义从区域的方法:
       zone "ZONE_NAME" IN {
           type slave;
           masters { MASTER_IP; };
           file "slaves/ZONE_NAME.zone";
       };    

总结:
    1: 从服务器应该为一台独立的名称服务器;
    2: 主服务器的区域解析库文件中必须有一条NS记录是指向从服务器的;
    3: 从服务器只需要定义区域,而无需提供解析库文件;如果是采用rpm方法安装的,解析库文件应该放置于/var/named/slaves目录中;否则需要改/var/named 目录的权限,不然写不进去.
    4: 主服务器得允许从服务器作区域传送;区域传送对方会获取本区域的所有解析记录,很危险,应选择性开放;
    5: 主从服务器时间应该同步,可通过ntp进行;
    6: bind程序的版本应该保持一致;否则,应该从高,主低,达到兼容性要求;
    7: 一个区域内只能有一个主DNS服务器,但可以有多个从DNS服务器.一主一从或一主多从

4. 检查配置语法是否错误的命令:

     #named-checkconf 
     #named-checkzone 
5. 查看服务器的当前系统状态: # rndc status 
6.测试命令:

  dig的使用
      dig [-t type] name [@SERVER] [query options] 
    
        dig用于测试dns系统,因此不会查询hosts文件进行解析;
    
        查询选项:
            +[no]trace: 跟踪解析过程 
            +[no]recurse: 进行递归解析
            
        测试反向解析:
            dig -x IP @SERVER  
        
        模拟区域传送:  --查看区域中的所有资源记录,比较危险.
            dig -t axfr ZONE_NAME @SERVER  

  资源记录中的某台客户机想解析dns,如果报错,可能是因为防火墙导致的
  解析时,如果将该DNS服务器的IP写入本机/etc/resolv.conf文件下,则之后测试时无需在命令行末尾加该DNS Server IP.

 host命令:
      host  [-t type]  name  [SERVER]      
 nslookup命令:
      nslookup  [-t type]  [name | -]  [server] 
    
      交互式模式:
       nslookup>
        server IP:指明使用哪个DNS server进行查询;
        set q=RR TYPE:指明查询的资源记录类型;
        NAME:要查询的名称; 

rndc命令:
    rndc --> rndc (953/tcp)    
    rndc COMMAND    
        COMMAND:
    -h: 显示详细帮助信息;
            reload:重载主配置文件和区域解析库文件;
            reload zone:重载区域解析库文件;
            retransfer zone:手动启动区域传送过程,而不管序列号是否增加;
            notify zone:重新对区域传送发通知;
            reconfig:重载主配置文件;
            querylog:开启或关闭查询日志;
            trace:递增debug级别;   //y用于调试排错.正常生产环境须关闭;
            trace LEVEL:指定使用的级别;  [ LEVEL 为数字,自己指定 ]            
    关于[querylog:开启或关闭查询日志]的详解:
      开启查询日志可通过查看log查看到查询日志,此项会消耗系统IO,一般只在排查错误时使用,平时无需打开; 

******************************实验部分******************************

                   
实验环境:

 CentOS6.7 x 3, Windows7 x 1

 主机名:

    DNS-master -- 10.68.7.235

    DNS-slave -- 10.68.7.231 

    http -- 10.68.7.234

    Windows-Client -- 10.68.7.236

 实验要求: 

   一. 配置缓存域名服务器

   二. 配置正向解析和反向解析域名服务器

   三. 通过区域传送实现主从同步

   四. 搭建http服务,开启windows主机,配好DNS进行访问:

一、配置缓存域名服务器:

配置主配置文件:

1
[root@DNS-master ~] # yum -y install bind bind-utils bind-lib
1
2
3
4
5
6
7
8
[root@DNS-master ~] # rpm -qa bind*
bind-utils-9.8.2-0.37.rc1.el6.x86_64
bind-libs-9.8.2-0.37.rc1.el6.x86_64
bind-9.8.2-0.37.rc1.el6.x86_64
[root@DNS-master ~] # service named start
Generating  /etc/rndc .key:                                  [  OK  ]
Starting named:                                            [  OK  ]
[root@DNS-master ~] #
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@DNS-master ~] # cp /etc/named.conf{,.bak}
[root@DNS-master ~] # vim /etc/named.conf
  options {
  //       listen-on port 53 { 127.0.0.1; };   // 该行为初始行,使用双斜线注释(因为该配置文件为C或C++写成,所以注释符号用 // 而不用 #).
          listen-on port 53 { 10.68.7.235; 127.0.0.1; };   // 修改初始行为该行,添加本机IP或外部IP,以期望其能够通过网络被其他主机访问;并添加本地回环地址,以便本机能够解析到.本行也可以删除不要,实现效果相同.
  //       listen-on-v6 port 53 { ::1; };
          directory        "/var/named" ;   // 此项定义工作目录,也就是区域解析库文件路径.此项是关键,其他项都是为安全而设定的.推荐将所有与BIND相关的配置文件(除了named.conf和resolv.conf)放在 /var 之下的子目录中。例如 /var/nam
          dump- file        "/var/named/data/cache_dump.db" ;
          statistics- file  "/var/named/data/named_stats.txt" ;
          memstatistics- file  "/var/named/data/named_mem_stats.txt" ;
          allow-query     { any; };   // 此项表示允许谁来查询,any表示任何主机.或者可以直接注释掉,注释掉默认为允许任何主机查询.
          recursion  yes ;   // 此项表示是否允许递归查询.
          
  //       dnssec- enable  yes ;    // 该行及以下几行通通注释掉;最好把 yes 改为no,安全设定,可能会影响后面实验的验证.
  //       dnssec-validation  yes ;
  //       dnssec-lookaside auto;
          
          /* Path to ISC DLV key */
  //       bindkeys- file  "/etc/named.iscdlv.key" ;
          
  //       managed-keys-directory  "/var/named/dynamic" ;
  };
          ...
1
2
3
4
[root@DNS-master ~] # service named restart
Stopping named:                                            [  OK  ]
Starting named:                                            [  OK  ]
[root@DNS-master ~] #
1
2
3
4
5
6
7
8
9
10
[root@DNS-master ~] # ss -tunlp |grep 53
udp    UNCONN     0      0            10.68.7.235:53                    *:*       users :(( "named" ,2510,513))
udp    UNCONN     0      0              127.0.0.1:53                    *:*       users :(( "named" ,2510,512))
udp    UNCONN     0      0                    ::1:53                   :::*       users :(( "named" ,2510,514))
tcp    LISTEN     0      3                    ::1:53                   :::*       users :(( "named" ,2510,22))
tcp    LISTEN     0      3            10.68.7.235:53                    *:*       users :(( "named" ,2510,21))
tcp    LISTEN     0      3              127.0.0.1:53                    *:*       users :(( "named" ,2510,20))
tcp    LISTEN     0      128                  ::1:953                  :::*       users :(( "named" ,2510,24))
tcp    LISTEN     0      128            127.0.0.1:953                   *:*       users :(( "named" ,2510,23))
[root@DNS-master ~] #

以上配置完即为缓存名称服务器的配置:
监听外部地址即可;     
二. 配置主域名服务器的正向解析:  

在缓存DNS服务器的基础上添加zone定义

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[root@DNS-master ~] # vim /var/named/yangbin.com.zone 
$TTL 1D 
$ORIGIN yangbin.com.
@       IN   SOA        ns1.yangbin.com   admin.yangbin.com. (
                                         2016120701
                                         2H
                                         5M
                                         7D
                                         1D
  )
         IN    NS    ns1.yangbin.com.
         IN    NS    ns2.yangbin.com.
         IN    MX 10 mx1.yangbin.com.
         IN    MX 20 mx2.yangbin.com.   // 该处几行.yangbin.com.可省略。省略后后面没有小数点.  
ns1     IN    A     10.68.7.235
ns2     IN    A     10.68.7.231
mx1     IN    A     10.68.7.232
mx2     IN    A     10.68.7.233
www     IN    A     10.68.7.234   // 这些域名对应的IP,即主机不存在也没关系.也可以一个名称对应多个IP.
web     IN    CNAME www

注:

$TTL 1D: 

   此处可用1D或1d或86400,该时间可自定义,时间越短,缓存有效期就越短,向服务器发起查询请求的次数也就越多,缓存时间越短,服务器压力越大,生成缓存生效的时间越快,反之亦然.

$ORIGIN keeny.xin.: 

   此处的宏表示当之后所写的名称为相对名称时,会自动在后边补上keeny.xin. ,当然此项也可省略不写,系统会自动这么做.

admin.yangbin.com.: 表示管理员的邮箱,@符号用点号.代替;

在主配置文件/etc/named.rfc1912.zones中定义区域: 

1
2
3
4
5
6
7
8
[root@DNS-master ~] # vim /etc/named.rfc1912.zones 
  ...
结尾添加:
  zone  "yangbin.com"  IN {
         type  master;
         file  "/var/named/yangbin.com.zone" ;
         allow-update { none; }
  };



本文转自 羽丰1995 51CTO博客,原文链接:http://blog.51cto.com/13683137989/1880492
相关文章
|
8天前
|
存储 缓存 算法
HashMap深度解析:从原理到实战
HashMap,作为Java集合框架中的一个核心组件,以其高效的键值对存储和检索机制,在软件开发中扮演着举足轻重的角色。作为一名资深的AI工程师,深入理解HashMap的原理、历史、业务场景以及实战应用,对于提升数据处理和算法实现的效率至关重要。本文将通过手绘结构图、流程图,结合Java代码示例,全方位解析HashMap,帮助读者从理论到实践全面掌握这一关键技术。
47 13
|
27天前
|
运维 持续交付 云计算
深入解析云计算中的微服务架构:原理、优势与实践
深入解析云计算中的微服务架构:原理、优势与实践
59 1
|
3天前
|
网络协议 安全 网络安全
探索网络模型与协议:从OSI到HTTPs的原理解析
OSI七层网络模型和TCP/IP四层模型是理解和设计计算机网络的框架。OSI模型包括物理层、数据链路层、网络层、传输层、会话层、表示层和应用层,而TCP/IP模型则简化为链路层、网络层、传输层和 HTTPS协议基于HTTP并通过TLS/SSL加密数据,确保安全传输。其连接过程涉及TCP三次握手、SSL证书验证、对称密钥交换等步骤,以保障通信的安全性和完整性。数字信封技术使用非对称加密和数字证书确保数据的机密性和身份认证。 浏览器通过Https访问网站的过程包括输入网址、DNS解析、建立TCP连接、发送HTTPS请求、接收响应、验证证书和解析网页内容等步骤,确保用户与服务器之间的安全通信。
25 1
|
1月前
|
运维 持续交付 虚拟化
深入解析Docker容器化技术的核心原理
深入解析Docker容器化技术的核心原理
47 1
|
28天前
|
存储 供应链 算法
深入解析区块链技术的核心原理与应用前景
深入解析区块链技术的核心原理与应用前景
53 0
|
1月前
|
JavaScript 前端开发 API
Vue.js响应式原理深度解析:从Vue 2到Vue 3的演进
Vue.js响应式原理深度解析:从Vue 2到Vue 3的演进
57 0
|
1月前
|
API 持续交付 网络架构
深入解析微服务架构:原理、优势与实践
深入解析微服务架构:原理、优势与实践
32 0
|
1月前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
76 2
|
2天前
|
存储 设计模式 算法
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务,它涉及算法与对象间职责的分配。行为型模式分为类行为模式和对象行为模式,前者采用继承机制来在类间分派行为,后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象行为模式比类行为模式具有更大的灵活性。 行为型模式分为: • 模板方法模式 • 策略模式 • 命令模式 • 职责链模式 • 状态模式 • 观察者模式 • 中介者模式 • 迭代器模式 • 访问者模式 • 备忘录模式 • 解释器模式
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
|
2天前
|
设计模式 存储 安全
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式,前者采用继承机制来组织接口和类,后者釆用组合或聚合来组合对象。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象结构型模式比类结构型模式具有更大的灵活性。 结构型模式分为以下 7 种: • 代理模式 • 适配器模式 • 装饰者模式 • 桥接模式 • 外观模式 • 组合模式 • 享元模式
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析

相关产品

  • 云解析DNS
  • 推荐镜像

    更多