kk Blog —— 通用基础

https://blog.csdn.net/HD243608836/article/details/111564684

nginx比较强大,可以针对单个域名请求做出单个连接超时的配置. 

比如些动态解释和静态解释可以根据业务的需求配置

1
2
3
4
5

proxy_connect_timeout :后端服务器连接的超时时间_发起握手等候响应超时时间

proxy_read_timeout:连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理（也可以说是后端服务器处理请求的时间）

proxy_send_timeout :后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据

nginx使用proxy模块时，默认的读取超时时间是60s。

1、请求超时

1
2
3
4
5
6
7
8
9
10
11
12
13

http {
    include       mime.types;
    server_names_hash_bucket_size  512;     
    default_type  application/octet-stream;
    sendfile        on;

    keepalive_timeout  65;  #保持
    tcp_nodelay on;
    client_header_timeout 15;
    client_body_timeout 15;
    send_timeout 25;
    include vhosts/*.conf;
}

2、后端服务器处理请求的时间设置（页面等待服务器响应时间）

1
2
3
4
5

location / {
	...
	proxy_read_timeout 150;  # 秒
	...
}

nginx常用的超时配置说明

client_header_timeout

语法 client_header_timeout time

默认值 60s

上下文 http server

说明 指定等待client发送一个请求头的超时时间（例如：GET / HTTP/1.1）.仅当在一次read中，没有收到请求头，才会算成超时。如果在超时时间内，client没发送任何东西，nginx返回HTTP状态码408(“Request timed out”)

client_body_timeout 

语法 client_body_timeout time

默认值 60s

上下文 http server location

说明 该指令设置请求体（request body）的读超时时间。仅当在一次readstep中，没有得到请求体，就会设为超时。超时后，nginx返回HTTP状态码408(“Request timed out”)

keepalive_timeout 

语法 keepalive_timeout timeout [ header_timeout ]

默认值 75s

上下文 http server location

说明 第一个参数指定了与client的keep-alive连接超时时间。服务器将会在这个时间后关闭连接。可选的第二个参数指定了在响应头Keep-Alive: timeout=time中的time值。这个头能够让一些浏览器主动关闭连接，这样服务器就不必要去关闭连接了。没有这个参数，nginx不会发送Keep-Alive响应头（尽管并不是由这个头来决定连接是否“keep-alive”）

两个参数的值可并不相同

1
2
3
4
5
6

    注意不同浏览器怎么处理“keep-alive”头
    MSIE和Opera忽略掉"Keep-Alive: timeout=<N>" header.
    MSIE保持连接大约60-65秒，然后发送TCP RST
    Opera永久保持长连接
    Mozilla keeps the connection alive for N plus about 1-10 seconds.
    Konqueror保持长连接N秒

lingering_timeout

语法 lingering_timeout time

默认值 5s

上下文 http server location

说明 lingering_close生效后，在关闭连接前，会检测是否有用户发送的数据到达服务器，如果超过lingering_timeout时间后还没有数据可读，就直接关闭连接；否则，必须在读取完连接缓冲区上的数据并丢弃掉后才会关闭连接。

resolver_timeout

语法 resolver_timeout time 

默认值 30s

上下文 http server location

说明 该指令设置DNS解析超时时间

proxy_connect_timeout

语法 proxy_connect_timeout time 

默认值 60s

上下文 http server location

说明 该指令设置与upstream server的连接超时时间，有必要记住，这个超时不能超过75秒。

这个不是等待后端返回页面的时间，那是由proxy_read_timeout声明的。如果你的upstream服务器起来了，但是hanging住了（例如，没有足够的线程处理请求，所以把你的请求放到请求池里稍后处理），那么这个声明是没有用的，由于与upstream服务器的连接已经建立了。

proxy_read_timeout

语法 proxy_read_timeout time 

默认值 60s

上下文 http server location

说明 该指令设置与代理服务器的读超时时间。它决定了nginx会等待多长时间来获得请求的响应。这个时间不是获得整个response的时间，而是两次reading操作的时间。

proxy_send_timeout

语法 proxy_send_timeout time 

默认值 60s

上下文 http server location

说明 这个指定设置了发送请求给upstream服务器的超时时间。超时设置不是为了整个发送期间，而是在两次write操作期间。如果超时后，upstream没有收到新的数据，nginx会关闭连接

proxy_upstream_fail_timeout（fail_timeout）

语法 server address [fail_timeout=30s]

默认值 10s

上下文 upstream

说明 Upstream模块下 server指令的参数，设置了某一个upstream后端失败了指定次数（max_fails）后，该后端不可操作的时间，默认为10秒

http://www.downxia.com/zixun/60481.html

在用OBS Studio的时候想要不完全显示自己的显示器画面，只截取一部分，但是不知道如何操作，其实OBS是可以实现的，下面就来教教大家如何在OBS上截取一部分窗口。

操作说明

首先我们按照正常的方法来添加窗口源，选择来源窗口的【加号】，在菜单中选择【显示器采集】。

采集好显示器后，我们在画面上右键，选择【滤镜】，在滤镜中添加【裁剪/填充】即可。

然后在右边中设置裁剪的内容，设置好后关闭，OBS就会显示部分的画面内容啦。

https://www.cnblogs.com/azureology/p/12346292.html

报错

git无法提交，提示

1

! [remote rejected] master -> master (branch is currently checked out)

原因

初始化没有用

1

git--bare init

补救

在服务器上运行

1

git config receive.denyCurrentBranch ignore

https://blog.51cto.com/u_2865456/5040535

很早直接就了解到CSS变量相关的内容，奈何之前使用价值不高（很多主流浏览器不兼容）

最近发现主流浏览器都已经支持了这一变化

这一重要的变化，可能会让你发现，原生CSS从此变的异常强大~，下面看一下如何使用

变量的声明

css的变量声明标识符为：–，即变量名前面加2个连接线

1
2
3
4

body {
  --head_color: #000;
  --head_bar: #F7EFD2;
}

上面代码中，body选择器里面声明了两个变量。它与正常的属性定义上没有什么不同，只是没有默认含义，所以其又叫做CSS自定义属性

这里需要注意的是，其变量名对大小写是敏感的。

变量的引用

变量的引用也很简单，它为我们提供了一个方法专门进行引用，var()函数用于读取变量。

1
2
3

.head {
  color: var(--head_color);
}

这样就引用了，另外，如果你担心变量没有定义，它还提供了默认值的设置方式。

可以使用第二个参数，表示变量的默认值。如果该变量不存在，就会使用这个默认值。

1

color: var(--head_color, #7F583F);

需要注意的是，变量值只能用作属性值，不能用作属性名。

如果变量值是数值，不能与数值单位直接连用。

1
2
3
4
5

.a {
  --gap: 20;
  /* 无效 */
  margin-top: var(--gap)px;
}

数值与单位直接写在一起，必须使用 calc() 函数，将它们连接。

1
2
3
4

.a{
  --gap: 20;
  margin-top: calc(var(--gap) * 1px);
}

作用域

变量只能作用于自身以及后代元素，兄弟元素，祖先元素都不能享用。

所以，如果你的变量是全局享用的，则建议放在 :root 上，例如：

1
2
3

:root {
    --color: red;
}

当然，也可以使用body或者html标签：

1
2
3

body {
    --color: red;
}

CSS变量就像JS的变量，每个类名或者花括号就像一个 function ，里面的变量只有上下文以内可以获取，这就让CSS有了更多可能性。

这使得外部变量稍微改变，整个CSS都可以大大联动，且是实时的。

1
2
3
4

dig @192.58.128.30 +dnssec . A
dig @192.58.128.30 +dnssec . NS

dig @192.58.128.30 +dnssec . DNSKEY

https://blog.csdn.net/huangzx3/article/details/86526068

1 、什么是DNSSEC

DNSSEC（DNS Security Extension）—-DNS安全扩展，主要是为了解决DNS欺骗和缓存污染问题而设计的一种安全机制。

1.1 DNS欺骗&缓存污染

客户端(pc)发起域名（例如:www.baidu.com）请求的时候，如果在本地缓存没有的情况下，会往递归服务器发送域名查询请求（我们也称之为localdns），递归服务器再一层层递归从.到com.再到baidu.com.（即到.的权威服务器–>com.的权威服务器–>baidu.com.的权威服务器)，最终取到www.baidu.com.对应的解析A记录返回给客户端。在整个查询过程中，攻击者可以假冒任何一个应答方：递归服务器–>.的权威服务器–>com.的权威服务器–>baidu.com.的权威服务器，给请求方发送一个伪造的响应（UDP包极其容易伪造），其中响应的解析记录给了一个错误的IP地址或者其他类型的解析记录（比如NXDomain、ServFail或者cname到错误的域名地址去等）。客户端或者是解析服务器在没有经过数据来源正确性校验的情况下接受了伪造的应答，直接将导致客户端无法正常访问网站或者其他资源或者客户端请求重定向到了伪造的网站上去。另外由于DNS当中存在着缓存，这种错误的记录将随着攻击者设定的TTL进行存活缓存，如果是递归服务器受到DNS欺骗那将会导致自身以及大面积的客户端缓存了错误的解析记录（可以通过清除缓存解决）。

2、DNSSEC原理

DNSSEC依靠数字签名来保证DNS应答报文的真实性和完整性。简单来说，权威服务器使用私钥对资源记录进行签名，递归服务器利用权威服务器的公钥对应答报文进行验证。如果验证失败，则说明这一报文可能是有问题的。

例子：

一台支持dnssec的递归服务器向支持dnssec的权威服务器发起paypal.com.的A记录请求，它除了得到A记录以外还得到了同名的RRSIG记录，其中包含了paypal.com.这个ZONE的权威数字签名，它使用paypal.com.的私钥来签名。为了验证这一签名是否正确，递归服务器再次向paypal.com.权威查询其公钥，即请求paypal.com.的dnskey类型的记录。递归服务器就可以使用公钥来验证收到的A记录是否是真实且完整的。但是注意：这种状态下，这台权威服务器可能是假冒的，递归服务器请求这台假冒的权威服务器，那么对于解析结果的正确性和完整性的验证上认为是正确的，但其实这个解析结果是假冒的，怎么发现？DNSSEC需要一条信任链，即必须要有一个或者多个相信的公钥，这些公钥被称为信任锚。理想情况下，假设dnssec已经实现了全部署，那每个递归服务器只需要保留根域名服务器的dnskey。

如下：

3、DNSSEC的资源记录

为了实现资源记录的签名和验证，DNSSEC增加了四种类型的资源记录:RRSIG（Resource Record Signature）、DNSKEY(DNS Public Key)、DS(Delegation Signer)、NSEC(Next Secure)

3.1 RRSIG记录

RRSIG资源记录存储的是对资源记录集合（RRSets）的数字签名。如下：

3.2 DNSKEY记录

DNSKEY资源记录存储的是公开密钥，下面是一个DNSKEY的资源记录的例子：

在实践中，权威域的管理员通常用两个密钥配合完成对区数据的签名。一个是Zone-Signing Key(ZSK)，另一个是Key-Signing Key(KSK)。ZSK用于签名区数据，而KSK用于对ZSK进行签名。这样做的好处有二：

（1）用KSK密钥签名的数据量很少，被破解（即找出对应的私钥）概率很小，因此可以设置很长的生存期。这个密钥的散列值作为DS记录存储在上一级域名服务器中而且需要上级的数字签名，较长的生命周期可以减少密钥更新的工作量。

（2）ZSK签名的数据量比较大，因而破解的概率较大，生存期应该小一些。因为有了KSK的存在，ZSK可以不必放到上一级的域名服务中，更新ZSK不会带来太大的管理开销（不涉及和上级域名服务器打交道）。

如下：

3.3 DS记录

DS（Delegation Signer）记录存储DNSKEY的散列值，用于验证DNSKEY的真实性，从而建立一个信任链。DNSKEY存储在资源记录所有者所在的权威域的区文件中，但是DS记录存储在上级权威域名服务器中，比如paypal.com的DS RR存储在.com的区中。如下：

3.4 NSEC记录

NSEC记录是为了响应那些不存在的资源记录而设计的。为了保证私有密钥的安全性和服务器的性能，所有的签名记录都是事先生成的。服务器显然不能为所有不存在的记录事先生成一个公共的“不存在”的签名记录，因为这一记录可以被重放（Replay）；更不可能为每一个不存在的记录生成独立的签名，因为它不知道用户将会请求怎样的记录。

4、DNSSEC请求过程

下面是针对paypal.com.的一个解析过程，抓包过程有丢包，但是不影响对于dnssec解析过程的大致理解

解析过程中关于DNSSEC的请求过程大致如下：

过程图如下所示：

5、DNSSEC中的DLV

DLV–DNSSECLookasideValidation

1、localdns在其上层zone权威服务器查找被验证ZONE的DS记录

2、如果不存在，向DLV注册机构发出一个对DLV记录的请求

3、如果成功，DLV资源记录被当做这个ZONE的DS记录

4、localdns进行真实性可完整性验证

DLV是一个DNS服务器,提供DNSSEC签名认证的信任链一个解决方案，递归服务器配置的信任锚点是DLV，就可以认证域，进而认证权威域授权的信任的权威域。

递归服务器的配置：当设置了dnssec-lookaside,它为验证器提供另外一个能在网络区域的顶层验证DNSKEY的方法

1
2
3
4

dnssec-lookaside "." trust-anchor dlv.cnnic.cn
trusted-keys {
	dlv.cnnic.cn 256 3 5 "qWmA7OpfdqvqMtLCzZTm982aTaeC6tTRiPUOFDVMXEkIuM14T8Tw6jg2qmX7JUtriYHAGwIQ+9jzYyRziSFdijaO2elgh90NMW0jIcjZ+3cHehpETCEUar813SHN38biRu4UL0EQ/X5C5LJyh1djaw8eZFXxaLyT8fcJedBZtYE=";
}

6、DNSSEC的一些设想

6.1 DNSSEC与防域名劫持

dnssec并没有办法在域名劫持上起到很好的作用，如果发生域名劫持则无法得到真正的解析结果，因为数字签名校验是没有校验通过的。实际上较多localdns在各个yys手上，各个yys可以对localdns进行相应的改造，则域名劫持会依然存在。

6.2 DNSSEC可能导致解析失败

响应中也有RRSIG记录，会直接导致UDP包的大小超过512字节，那么可能造成部分localdns解析失败，因为根据之前对于线上的观察，部分localdns并不支持超过512字节大小的UDP包，从而可能直接导致响应失败。