Win10以太网正在识别的解决方法！（亲测可用）
在Windows系统中，网络出现问题以一直是比较棘手的！最近使用Win10系统的用户反应无法连接，以太网下面显示“正在识别”的字样，该怎么办呢？出现这样的情况我们可以通过下面方法进行解决。
Win10以太网正在识别解决方法一：
1、在开始菜单上单击鼠标右键，点击【网络连接】；
2、在以太网上单击右键，选择【禁用】；
3、等待显示“已禁用”后再次单击右键，选择【启用】等待自动获取网络信号！
使用screen在后台跑程序,screen session的状态为Attached
遇到这样的问题
是screen启动后，断开ssh，重连screen session，连不上。
用 screen -ls, 显式当前状态为Attached， 但当前没有用户登陆些会话。screen此时正常状态应该为(Detached)
用screen -r <session-id>，怎么也登不上。
解决办法:
列出状态为Attached的session id。
screen -ls
screen -D -r ＜session-id>
解释：-D -r 先踢掉前一用户，再登陆。
解决 Chrome 浏览器的 ERR_SPDY_PROTOCOL_ERROR 错误
在我访问某个站点时，偶尔会报：
网址为 https://xxxx 的网页可能暂时无法连接，或者它已永久性地移动到了新网址。ERR_SPDY_PROTOCOL_ERROR
当重新刷新页面、重新启动浏览器或者删除浏览器缓存都没有效果的话，那么你可以尝试下面的方法进行修复。
修复 Chrome 报 ERR_SPDY_PROTOCOL_ERROR 的错误
1.直接在浏览器地址栏访问 chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active 如：
2.打开后，在右侧有一个小箭头，点击箭头后会列出有一些下拉选项，然后选择点击 "Flush Sockets" ：
在Linux中让echo命令显示带颜色的字。
echo显示带颜色，需要使用参数-e
格式如下:
echo -e "\033[字背景颜色;文字颜色m字符串\033[0m"
例如:
echo -e "\033[41;37m TonyZhang \033[0m"
其中41的位置代表底色, 37的位置是代表字的颜色
注：
1、字背景颜色和文字颜色之间是英文的“""”
2、文字颜色后面有个m
3、字符串前后可以没有空格，如果有的话，输出也是同样有空格
下面看几个例子：
echo -e "\033[30m 黑色字 \033[0m"
echo -e "\033[31m 红色字 \033[0m"
echo -e "\033[32m 绿色字 \033[0m"
echo -e "\033[33m 黄色字 \033[0m"
echo -e "\033[34m 蓝色字 \033[0m"
echo -e "\033[35m 紫色字 \033[0m"
echo -e "\033[36m 天蓝字 \033[0m"
echo -e "\033[37m 白色字 \033[0m"
echo -e "\033[40;37m 黑底白字 \033[0m"
echo -e "\033[41;37m 红底白字 \033[0m"
echo -e "\033[42;37m 绿底白字 \033[0m"
echo -e "\033[43;37m 黄底白字 \033[0m"
echo -e "\033[44;37m 蓝底白字 \033[0m"
echo -e "\033[45;37m 紫底白字 \033[0m"
echo -e "\033[46;37m 天蓝底白字 \033[0m"
echo -e "\033[47;30m 白底黑字 \033[0m"
Notepad++中设置Windows、Unix、Mac三种行尾换行符格式间的转换
（1）首先，要设置NotePad++能显示换行符，这个才能看到效果， 视图--》显示符号--》显示行尾符。
｛2｝设置行尾符格式：编辑--》档案格式转换--》（可选Windows、Unix、Mac中的一种）
HTTP头域列表与解释 之 request篇
HTTP 头域是HTTP协议中请求(request)和响应(response)中的头部信息,其实就是HTTP通信的操作参数，告诉web服务器和浏览器怎样处理这个通信。HTTP头从一个请求信息或者响应信息的第二行开始（第一行是请求行或者响应行），以两个CR-LF字符组结束（CR：回车符,\r，LF：换行符\n）而每个HTTP头是字符串形式的，用冒号分割的键值对，多个HTTP头之间用CR-LF字符组隔开。
某些http头可以有注释，例如user-agent,server,via。但这些注释会被服务器或者浏览器忽略IETF组织已经将一些核心的HTTP头定义在RFC2616规范中，这些HTTP头是每个基于HTTP协议的软件必须实现的，而其他一些更新和扩展的头域也必须被基于HTTP的软件实现。当然，各个软件也可以定义自己的头域。
另一方面，RFC2616规范中并没有限制每个HTTP头的长度，或者限制HTTP头的数量，但出于性能和安全的考虑，多数服务器都会自己作规定，例如apache2.3 就规定每个HTTP头不能超过8190个字节，每个请求不能超过100个HTTP头。
以下来看看发送一个请求(request)时候，可能包含的各个HTTP头和它的解释。
标准的请求头：
Accept:浏览器（或者其他基于HTTP的客户端程序）可以接收的内容类型（Content-types）,例如 Accept: text/plain
Accept-Charset：浏览器能识别的字符集，例如 Accept-Charset: utf-8
Accept-Encoding：浏览器可以处理的编码方式，注意这里的编码方式有别于字符集，这里的编码方式通常指gzip,deflate等。例如 Accept-Encoding: gzip, deflate
Accept-Language：浏览器接收的语言，其实也就是用户在什么语言地区，例如简体中文的就是 Accept-Language: zh-CN
Accept-Datetime：（这个暂时没搞清楚什么意思）
Authorization：在HTTP中，服务器可以对一些资源进行认证保护，如果你要访问这些资源，就要提供用户名和密码，这个用户名和密码就是在Authorization头中附带的，格式是“username:password”字符串的base64编码，例如：Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==中，basic指使用basic认证方式， QWxhZGRpbjpvcGVuIHNlc2FtZQ==使用base64解码就是“Aladdin:open sesame”
Cache-Control：这个指令在request和response中都有，用来指示缓存系统（服务器上的，或者浏览器上的）应该怎样处理缓存，因为这个头域比较重要，特别是希望使用缓 存改善性能的时候，内容也较多，所以我想在下一篇博文中主要介绍一下。
Connection：告诉服务器这个user agent（通常就是浏览器）想要使用怎样的连接方式。值有keep-alive和close。http1.1默认是keep-alive。keep-alive就是浏览器和服务器 的通信连接会被持续保存，不会马上关闭，而close就会在response后马上关闭。但这里要注意一点，我们说HTTP是无状态的，跟这个是否keep-alive没有关系，不要认为keep-alive是对HTTP无状态的特性的改进。
Cookie：浏览器向服务器发送请求时发送cookie，或者服务器向浏览器附加cookie，就是将cookie附近在这里的。例如：Cookie:user=admin
Content-Length：一个请求的请求体的内存长度，单位为字节(byte)。请求体是指在HTTP头结束后，两个CR-LF字符组之后的内容，常见的有POST提交的表单数据，这个Content-Length并不包含请求行和HTTP头的数据长度。
Content-MD5：使用base64进行了编码的请求体的MD5校验和。例如：Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Type：请求体中的内容的mime类型。通常只会用在POST和PUT方法的请求中。例如：Content-Type: application/x-www-form-urlencoded
nginx反向代理时，X-Forwarded-For 如何设置
当nginx作为反向代理功能时，转发请求到后端服务器
通常需要使用如下命令为转发的请求增加请求头 X-Forwarded-For
proxy_set_header X-Forwarded-For "特定的X-Forwarded-For值"
第一版配置：
proxy_set_header X-Forwarded-For $remote_addr;
#如上配置只能增加负载均衡ip地址，丢失了客户端真实ip和任意中间代理ip
第二版配置
proxy_set_header X-Forwarded-For "$http_x_forwarded_for, $remote_addr";
#如上配置在原有请求头X-Forwarded-For字段的基础上增加了连接nginx的服务器ip地址
第三版配置（最为简单）
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#$proxy_add_x_forwarded_for已经实现了第二版的功能，直接使用该内置变量即可
X-Forwarded-For 和 X-Real-IP 的区别？
做动静分离的时候这里有疑问所以请教度娘
网上摘得，觉得比较有用就记下了
一般来说，X-Forwarded-For是用于记录代理信息的，每经过一级代理(匿名代理除外)，代理服务器都会把这次请求的来源IP追加在X-Forwarded-For中
来自4.4.4.4的一个请求，header包含这样一行
X-Forwarded-For: 1.1.1.1, 2.2.2.2, 3.3.3.3
代表 请求由1.1.1.1发出，经过三层代理，第一层是2.2.2.2，第二层是3.3.3.3，而本次请求的来源IP4.4.4.4是第三层代理
而X-Real-IP，没有相关标准，上面的例子，如果配置了X-Read-IP，可能会有两种情况
// 最后一跳是正向代理，可能会保留真实客户端IP X-Real-IP: 1.1.1.1 // 最后一跳是反向代理，比如Nginx，一般会是与之直接连接的客户端IP X-Real-IP: 3.3.3.3
所以 ，如果只有一层代理，这两个头的值就是一样的
那一般在后端取值（比如nodejs通过nginx代理）是用哪个值呢？我看sf上看一般推荐是用X-Forwarded-For，直接用 X-Real-IP岂不是更方便点？
X-Forwarded-For确实是一般的做法
1. 他在正向(如squid)反向(如nginx)代理中都是标准用法，而正向代理中是没有x-real-ip相关的标准的，也就是说，如果用户访问你的 nginx反向代理之前，还经过了一层正向代理，你即使在nginx中配置了x-real-ip，取到的也只是正向代理的IP而不是客户端真实IP
2. 大部分nginx反向代理配置文章中都没有推荐加上x-real-ip ，而只有x-forwarded-for，因此更通用的做法自然是取x-forwarded-for
3. 多级代理很少见，只有一级代理的情况下二者是等效的
4. 如果有多级代理，x-forwarded-for效果是大于x-real-ip的，可以记录完整的代理链路
按照HTTP 请求头中的 X-Forwarded-For这篇文章的例子，如果在Nginx的反向代理中添加了配置“proxy_set_header X-Real-IP $remote_addr”，X-Real-IP的值为”3.3.3.3“