文件名.editorconfig

vue项目

root = true

[*.{js,jsx,ts,tsx,vue}]
indent_style = space
indent_size = 2
trim_trailing_whitespace = true
insert_final_newline = true
charset = utf-8
end_of_line = lf

php项目

root = true

[*.{js,json,php,md}]
indent_style = space
indent_size = 4
trim_trailing_whitespace = true
insert_final_newline = true
charset = utf-8
end_of_line = lf

其他项目

root = true

[*]
charset = utf-8
end_of_line = lf
indent_size = 2
indent_style = space
insert_final_newline = true
trim_trailing_whitespace = true

关于git换行符处理的问题,自己的设置中,global-config中设了core.autocrlf=false,systemwide中将autocrlf设成了true.
关于配置的作用域,systemwide>global>local。local没有配置,global会覆盖systemwide的配置,因此最终生效的是“autocrlf=false”。

这句的意思是“在提交与检出代码的时候均不对换行符进行转换”, 配置说明 :

首先crlf是windows下的换行符,而lf是unix下的换行符。

autocrlf =true 表示要求git在提交时将crlf转换为lf,而在检出时将crlf转换为lf。  
autocrlf = false表示提交和检出代码时均不进行转换  
autocrlf = input 表示在提交时将crlf转换为lf,而检出时不转换  

idea右下角那儿关于文件的换行符,使用的地crlf,,这表明当前使用的是CRLF换行符,而autocrlf又是false,这会使得代码仓库中出现混合换行符,git中另有一个配置项,名叫“safecrlf”默认值是“warn”,因此git在提交时会弹出关于这个问题的提示,如果忽略了它---—在某次操作中顺手将其设为了“不再提示”,这导致后来safecrlf的值就被改为了false.

因此,可以单击右下角这个换行符标志,将其改为“LF”,同时把全局配置改为autocrlf=input,以使仓库中只保留Unix换行符。

另外,git有一个safecrlf,默认是false,可以改成true,表示拒绝提交混合换行符的代码。当然这可能会造成烦人的提示,但对于windows下的特殊情况可以这样设置。它的具体配置含义如下:

safecrlf = true 表示 拒绝提交包含混合换行符的文件
safecrlf = false 表示 允许…
safecrlf = warn 表示警告

Address Block Name RFC Allocation Date Termination Date Source Destination Forwardable Globally Reachable Reserved-by-Protocol
0.0.0.0/8 "This host on this network" [RFC1122], Section 3.2.1.3 1981-09 N/A True False False False True
10.0.0.0/8 Private-Use [RFC1918] 1996-02 N/A True True True False False
100.64.0.0/10 Shared Address Space [RFC6598] 2012-04 N/A True True True False False
127.0.0.0/8 Loopback [RFC1122], Section 3.2.1.3 1981-09 N/A False [1] False [1] False [1] False [1] True
169.254.0.0/16 Link Local [RFC3927] 2005-05 N/A True True False False True
172.16.0.0/12 Private-Use [RFC1918] 1996-02 N/A True True True False False
192.0.0.0/24 [2] IETF Protocol Assignments [RFC6890], Section 2.1 2010-01 N/A False False False False False
192.0.0.0/29 IPv4 Service Continuity Prefix [RFC7335] 2011-06 N/A True True True False False
192.0.0.8/32 IPv4 dummy address [RFC7600] 2015-03 N/A True False False False False
192.0.0.9/32 Port Control Protocol Anycast [RFC7723] 2015-10 N/A True True True True False
192.0.0.10/32 Traversal Using Relays around NAT Anycast [RFC8155] 2017-02 N/A True True True True False
192.0.0.170/32, 192.0.0.171/32 NAT64/DNS64 Discovery [RFC7050], Section 2.2 2013-02 N/A False False False False True
192.0.2.0/24 Documentation (TEST-NET-1) [RFC5737] 2010-01 N/A False False False False False
192.31.196.0/24 AS112-v4 [RFC7535] 2014-12 N/A True True True True False
192.52.193.0/24 AMT [RFC7450] 2014-12 N/A True True True True False
192.88.99.0/24 Deprecated (6to4 Relay Anycast) [RFC7526] 2001-06 2015-03
192.168.0.0/16 Private-Use [RFC1918] 1996-02 N/A True True True False False
192.175.48.0/24 Direct Delegation AS112 Service [RFC7534] 1996-01 N/A True True True True False
198.18.0.0/15 Benchmarking [RFC2544] 1999-03 N/A True True True False False
198.51.100.0/24 Documentation (TEST-NET-2) [RFC5737] 2010-01 N/A False False False False False
203.0.113.0/24 Documentation (TEST-NET-3) [RFC5737] 2010-01 N/A False False False False False
240.0.0.0/4 Reserved [RFC1112], Section 4 1989-08 N/A False False False False True
255.255.255.255/32 Limited Broadcast [RFC8190] [RFC919], Section 7 1984-10 N/A False True False False True

保留IP地址的分配

互联网上的IP地址统一由一个叫IANA(Internet Assigned Numbers Authority,互联网网络号分配机构)的组织来管理。根据用途和安全性级别的不同,IP地址还可以大致分为两类:公共地址和私有地址。公用地址在Internet中使用,可以在Internet中随意访问。私有地址只能在内部网络中使用,只有通过代理服务器才能与Internet通信。

一个机构网络要连入Internet,必须申请公用IP地址。但是考虑到网络安全和内部实验等特殊情况,在IP地址中专门保留了三个区域作为私有地址,其地址范围如下:

网络类别ip地址范围网络数
a类网10.0.0.0~10.255.255.2551
b类网172.16.0.0~172.31.255.25516
c类网192.168.0.0~192.168.255.255255
使用保留地址的网络只能在内部进行通信,而不能与其他网络互连。因为本网络中的保留地址同样也可能被其它网络使用,如果进行网络互连,那么寻找路由时就会因为地址的不唯一而出现问题。但是这些使用保留地址的网络可以通过将本网络内的保留地址翻译转换成公共地址的方式实现与外部网络的互连。这也是保证网络安全的重要方法之一。

保留的IP地址段不会在互联网上使用,因此与广域网相连的路由器在处理保留IP地址时,只是将该数据包丢弃处理,而不会路由到广域网上去,从而将保留IP地址产生的数据隔离在局域网内部。

  在局域网内计算机数量少于254台的情况下,一般在C类IP地址段里选择IP地址范围就可以了,如从“192.168.1.1”到“192.168.1. 254”。

特殊IP地址
就像我们每个人都有一个身份证号码一样,网络里的每台电脑(更确切地说,是每一个设备的网络接口)都有一个IP地址用于标示自己。我们可能都知道这些地址由四个字节组成,用点分十进制表示以及它们的A,B,C分类等,然而,在总数大约为四十多亿个可用IP 地址里,你知道下面一些常见的有特殊意义地址吗?我们一起来看看吧:

一、0.0.0.0

严格说来,0.0.0.0已经不是一个真正意义上的IP地址了。它表示的是这样一个集合:所有不清楚的主机和目的网络。这里的“不清楚”是指在本机的路由表里没有特定条目指明如何到达。对本机来说,它就是一个“收容所”,所有不认识的“三无”人员,一律送进去。如果你在网络设置中设置了缺省网关,那么Windows系统会自动产生一个目的地址为0.0.0.0的缺省路由。
二、255.255.255.255

限制广播地址。对本机来说,这个地址指本网段内(同一广播域)的所有主机。如果翻译成人类的语言,应该是这样:“这个房间里的所有人都注意了!”这个地址不能被路由器转发。
三、127.0.0.1

本机地址,主要用于测试。用汉语表示,就是“我自己”。在Windows系统中,这个地址有一个别名“Localhost”。寻址这样一个地址,是不能把它发到网络接口的。除非出错,否则在传输介质上永远不应该出现目的地址为“127.0.0.1”的数据包。
四、224.0.0.1

组播地址,注意它和广播的区别。从224.0.0.0到239.255.255.255都是这样的地址。224.0.0.1特指所有主机,224.0.0.2特指所有路由器。这样的地址多用于一些特定的程序以及多媒体程序。如果你的主机开启了IRDP (Internet路由发现协议,使用组播功能)功能,那么你的主机路由表中应该有这样一条路由。
五、169.254.x.x

如果你的主机使用了DHCP功能自动获得一个IP地址,那么当你的DHCP服务器发生故障,或响应时间太长而超出了一个系统规定的时间,Wingdows系统会为你分配这样一个地址。如果你发现你的主机IP地址是一个诸如此类的地址,很不幸,十有八九是你的网络不能正常运行了。
六、10.x.x.x, 172.16.x.x~172.31.x.x, 192.168.x.x

私有地址,这些地址被大量用于企业内部网络中。一些宽带路由器,也往往使用192.168.1.1作为缺省地址。私有网络由于不与外部互连,因而可能使用随意的IP地址。保留这样的地址供其使用是为了避免以后接入公网时引起地址混乱。使用私有地址的私有网络在接入Internet时,要使用地址翻译(NAT),将私有地址翻译成公用合法地址。在Internet上,这类地址是不能出现的。

对一台网络上的主机来说,它可以正常接收的合法目的网络地址有三种:本机的IP地址、广播地址以及组播地址。

nginx可以使用变量简化配置与提高配置的灵活性,所有的变量值都可以通过这种方式引用:

$变量名

而nginx中的变量分为两种,自定义变量与内置预定义变量

内置变量

声明 可以在sever,http,location等标签中使用set命令(非唯一)声明变量,语法如下

set $变量名 变量值

注意nginx中的变量必须都以$开头。

可见性

nginx的配置文件中所有使用的变量都必须是声明过的,否则nginx会无法启动并打印相关异常日志

nginx变量的一个有趣的特性就是nginx中没一个变量都是全局可见的,而他们又不是全局变量。比如下面这个例子

location a/ {
  return 200 $a
}

location b/ {
 set $a hello nginx
 return 200 $a
}

由于变量是全局可见的所以nginx启动不会报错,而第一个location中并不知道$a的具体值因此返回的响应结果为一个空字符串。

在不同层级的标签中声明的变量性的可见性规则如下:

location标签中声明的变量中对这个location块可见
server标签中声明的变量对server块以及server块中的所有子块可见
http标签中声明的变量对http块以及http块中的所有子块可见

内置预定义变量

内置预定义变量即无需声明就可以使用的变量,通常包括一个http请求或响应中一部分内容的值,以下为一些常用的内置预定义变量

变量名    定义
$arg_PARAMETER    GET请求中变量名PARAMETER参数的值。
$args    这个变量等于GET请求中的参数。例如,foo=123&bar=blahblah;这个变量只可以被修改
$binary_remote_addr    二进制码形式的客户端地址。
$body_bytes_sent    传送页面的字节数
$content_length    请求头中的Content-length字段。
$content_type    请求头中的Content-Type字段。
$cookie_COOKIE    cookie COOKIE的值。
$document_root    当前请求在root指令中指定的值。
$document_uri    与$uri相同。
$host    请求中的主机头(Host)字段,如果请求中的主机头不可用或者空,则为处理请求的server名称(处理请求的server的server_name指令的值)。值为小写,不包含端口。
$hostname    机器名使用 gethostname系统调用的值
$http_HEADER    HTTP请求头中的内容,HEADER为HTTP请求中的内容转为小写,-变为_(破折号变为下划线),例如:$http_user_agent(Uaer-Agent的值);
$sent_http_HEADER    HTTP响应头中的内容,HEADER为HTTP响应中的内容转为小写,-变为_(破折号变为下划线),例如: $sent_http_cache_control, $sent_http_content_type…;
$is_args    如果$args设置,值为"?",否则为""。
$limit_rate    这个变量可以限制连接速率。
$nginx_version    当前运行的nginx版本号。
$query_string    与$args相同。
$remote_addr    客户端的IP地址。
$remote_port    客户端的端口。
$remote_user    已经经过Auth Basic Module验证的用户名。
$request_filename    当前连接请求的文件路径,由root或alias指令与URI请求生成。
$request_body    这个变量(0.7.58+)包含请求的主要信息。在使用proxy_pass或fastcgi_pass指令的location中比较有意义。
$request_body_file    客户端请求主体信息的临时文件名。
$request_completion    如果请求成功,设为"OK";如果请求未完成或者不是一系列请求中最后一部分则设为空。
$request_method    这个变量是客户端请求的动作,通常为GET或POST。包括0.8.20及之前的版本中,这个变量总为main request中的动作,如果当前请求是一个子请求,并不使用这个当前请求的动作。
$request_uri    这个变量等于包含一些客户端请求参数的原始URI,它无法修改,请查看$uri更改或重写URI。
$scheme    所用的协议,比如http或者是https,比如rewrite ^(.+)$ $scheme://example.com$1 redirect;
$server_addr    服务器地址,在完成一次系统调用后可以确定这个值,如果要绕开系统调用,则必须在listen中指定地址并且使用bind参数。
$server_name    服务器名称。
$server_port    请求到达服务器的端口号。
$server_protocol    请求使用的协议,通常是HTTP/1.0或HTTP/1.1。
$uri    请求中的当前URI(不带请求参数,参数位于a r g s ) , 不 同 于 浏 览 器 传 递 的 args),不同于浏览器传递的args),不同于浏览器传递的request_uri的值,它可以通过内部重定向,或者使用index指令进行修改。不包括协议和主机名,例如/foo/bar.html

nginx配置中$http_host、$host、$host:$proxy_port 简单区别

1、 proxy_set_header Host $http_host;
不改变请求头 。
2、proxy_set_header Host h o s t ; 如 果 客 户 端 请 求 头 中 没 有 携 带 这 个 头 部 , 那 么 传 递 到 后 端 服 务 器 的 请 求 也 不 含 这 个 头 部 。 这 种 情 况 下 , 使 用 host; 如果客户端请求头中没有携带这个头部,那么传递到后端服务器的请求也不含这个头部。 这种情况下,使用host;如果客户端请求头中没有携带这个头部,那么传递到后端服务器的请求也不含这个头部。这种情况下,使用host变量它 的值在请求包含“Host”请求头时为“Host”字段的值,在请求未携带“Host”请求头时为虚拟主机的主域名;
3、proxy_set_header Host h o s t : host:host:proxy_port;
服务器名可以和后端服务器的端口一起传送:
4、如果某个请求头的值为空,那么这个请求头将不会传送给后端服务器:
proxy_set_header Accept-Encoding “”;
5、用户真实的ip地址转发给后端服务器
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;

在HTTP/1.0中, 响应头必须含有Content-Length; 在HTTP/1.1中引入chunk概念;

分块传输编码(Chunked transfer encoding)是超文本传输协议(HTTP)中的一种数据传输机制,允许HTTP由网页服务器发送给客户端应用( 通常是网页浏览器)的数据可以分成多个部分。分块传输编码只在HTTP协议1.1版本(HTTP/1.1)中提供。

通常,HTTP应答消息中发送的数据是整个发送的,Content-Length消息头字段表示数据的长度。数据的长度很重要,因为客户端需要知道哪里是应答消息的结束,以及后续应答消息的开始。然而,使用分块传输编码,数据分解成一系列数据块,并以一个或多个块发送,这样服务器可以发送数据而不需要预先知道发送内容的总大小。通常数据块的大小是一致的,但也不总是这种情况。

原理

HTTP 1.1引入分块传输编码提供了以下几点好处:

  • HTTP分块传输编码允许服务器为动态生成的内容维持HTTP持久链接。通常,持久链接需要服务器在开始发送消息体前发送Content-Length消息头字段,但是对于动态生成的内容来说,在内容创建完之前是不可知的。
  • 分块传输编码允许服务器在最后发送消息头字段。对于那些头字段值在内容被生成之前无法知道的情形非常重要,例如消息的内容要使用散列进行签名,散列的结果通过HTTP消息头字段进行传输。没有分块传输编码时,服务器必须缓冲内容直到完成后计算头字段的值并在发送内容前发送这些头字段的值。
  • HTTP服务器有时使用压缩 (gzip或deflate)以缩短传输花费的时间。分块传输编码可以用来分隔压缩对象的多个部分。在这种情况下,块不是分别压缩的,而是整个负载进行压缩,压缩的输出使用本文描述的方案进行分块传输。在压缩的情形中,分块编码有利于一边进行压缩一边发送数据,而不是先完成压缩过程以得知压缩后数据的大小。

格式

如果一个HTTP消息(请求消息或应答消息)的Transfer-Encoding消息头的值为chunked,那么,消息体由数量未定的块组成,并以最后一个大小为0的块为结束。

每一个非空的块都以该块包含数据的字节数(字节数以十六进制表示)开始,跟随一个CRLF (回车及换行),然后是数据本身,最后块CRLF结束。在一些实现中,块大小和CRLF之间填充有白空格(0x20)。

最后一块是单行,由块大小(0),一些可选的填充白空格,以及CRLF。最后一块不再包含任何数据,但是可以发送可选的尾部,包括消息头字段。

消息最后以CRLF结尾。

编码的应答

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
 
25
This is the data in the first chunk
 
1C
and this is the second one
 
3
con
 
8
sequence
 
0

编码应答的解释

前两个块的数据中包含有显式的rn字符。

"This is the data in the first chunk\r\n"      (37 字符 => 十六进制: 0x25)
"and this is the second one\r\n"               (28 字符 => 十六进制: 0x1C)
"con"                                          (3  字符 => 十六进制: 0x03)
"sequence"                                     (8  字符 => 十六进制: 0x08)

应答需要以0长度的块( "0rnrn".)结束。

解码的数据

This is the data in the first chunk
and this is the second one
consequence

由于一些HTTP客户端(流媒体播放器)不支持HTTP块传输或者分块压缩, 这种情况下最好在指定了flv_live on;的location中指定chunked_transfer_encoding off,否则HTTP客户端会解析异常。

location / {
        proxy_pass              http://10.0.0.10/;
        proxy_redirect          off;
        proxy_set_header        Host            $http_host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        chunked_transfer_encoding       off;
}