00:10.0 
00:43.2 
01:16.5 
01:49.8 
02:23.0 
02:56.2 
03:29.5 
04:02.7 

04：05后

04:36.0 
05:09.3 
05:42.5 
06:15.7 
06:49.0 
07:22.3 
07:55.5 
08:28.7 

09：00后

09:02.0 
09:35.2 
10:08.5 
10:41.8 
11:15.0 
11:48.2 
12:21.5 
12:54.8 

13：00后

阅读剩余部分 -

最近在对bismarck进行升级，主要是从Python2迁移到Python3，并更换爬取方案。

结果出师不利，在将爬取到的商品标题print出来时，抛出错误：

Python2时代最怕就是这个UnicodeEncodeError，没想到到了Python3，又见到它了。

查看第一个字符，发现为'\u8266'，于是测试以下代码：

果然报错

尝试了各种姿势，结果还是没能解决。

最后突发奇想，print不行，那我把其输出到文件捏？

阅读剩余部分 -

前言

在正常的tcp/ip协议中是很难伪造ip的，因为在tcp/ip正式通信之前是有一个三次握手的过程，通过三次握手建立了tcp/ip连接之后再进行正常的通信，所以我之前想用python的scapy库来伪造其他ip的请求包，但是因为三次握手的时候，我的ip是伪造的，我发出去的请求包就没有办法正确的返回找到我，所以无法三次握手就没有tcp/ip正常通信，就失败了。

只要能够在tcp/ip层伪造ip，就是完全的伪造ip，没有任何办法判断，不过我这次的是在http层伪造ip，所以还是可能被发现的，而且也只有在http协议中有用，无法利用在其他地方。

header

那么如何在http层伪造协议呢？我们先来了解一些http请求中的请求头header，比如说我们在chrome中登陆百度，打开chrome的开发者工具，查看network，就能够看到这次请求百度的header请求头。

Requests Headers

可以看到这里有很多的请求参数，在我们打开百度的时候，我们先要向百度服务器发送一个请求，而这个请求包含很多附加的关于我们自己的信息，比如说浏览器信息，cookie，接受数据格式等等，百度服务器收到我们的请求之后，返回给我们百度的页面。

在我们发送http请求之前，就已经先进行了tcp/ip三次握手，然后再发送http请求，三次握手的过程是非常迅速的，可以用抓包工具 wireshark 查看。

所以 header 请求头主要是一些我们发送请求时附带的我们自己的信息，同时，在看到 header 请求头的时候，也会发现在服务器返回数据的时候也会带有一个 header ，这是返回数据格式的一些信息，包括返回数据的格式，大小，时间等。

阅读剩余部分 -

有一段时间没有用了wordpress了，今天有空折腾了一下宝塔面板。在安装玩wordpress后，发现无法直接操作文件，比如无法删除/安装插件和主题，提示需要ftp。实际上这个是因为权限没有给到位，导致wordpress无法读写所在目录。
首先，肯定不能使用chmod +777 -R这种简单粗暴的方法，不仅不安全，还有可能直接影响到部分使用apache的人。详情可以点击这里，查看官方的说明。
既然777行不通，那就使用define(“FS_METHOD”, “direct”);，通过使用FS_METHOD配合tmp来完成，但是等写完配置文件后发现还是不可以，还是权限有问题，具体原因也没有去想了。在查看的时候，想到宝塔面板默认的账户是www，那就一步到位，使用以下的命令实现了功能：

chown -R www:www /www/wwwroot/domain.com

通过直接给www用户权限，让它接手所有文写的读写和执行，而root权限则只给到755。

阅读剩余部分 -

简介

Caddy的proxy可以用于配置:

1. 普通的反向代理
2. 负载均衡:支持多策略,健康检查,故障转移
3. WebSocket代理

开启该指令后,Caddy的proxy中间件会添加一个可用于 {upstream} 的占位符,用于记录哪一个代理的处理的请求.

proxy完整语法格式为:

proxy from to... {

policy name [value]

fail_timeout duration

max_fails integer

max_conns integer

try_duration duration

try_interval duration

health_check path

health_check_port port

health_check_interval interval_duration

health_check_timeout timeout_duration

header_upstream name value

header_downstream name value

keepalive number

without prefix

except ignored_paths...

upstream to

insecure_skip_verify

preset

}

• from 被代理的请求的路径
• to 代理的断点,可以是多个,支持 http/https/quic/srv/unix/quic, 如果是 srv:// 或者 srv+https:// 则被认为是一个服务定位器,Caddy将通过SRV DNS去解析
• policy 负载均衡策略,必须有多个后端.如果后端是服务定位器则不可以,可选的有random, least_conn, round_robin, first, ip_hash, uri_hash 和 header, 默认为random
• fail_timeout 失败了的请求记住多久.如果在这期间达到了max_fails,则被考虑为挂掉了,不会再有请求发送过去,除非失败的请求被忘记了.默认为0,总是可用.
• max_fails 如果fail_timeout为0则无效,默认为1
• max_conns 每一个后端的最大请求数,默认0,没有限制,如果达到了返回502错误.
• try_duration 第一个上游失败了,挂起外面来的请求多久
• try_interval 某一个上游服务器挂了之后等待多久切换下一个上有服务器,默认250ms. 设置为0并且设置了duration可能占满cpu
• health_check 设置一个路径,Caddy将定期发出请求,如果返回200和399就认为正常,否则就不正常,然后提前定义的interval间隔里他就是被考虑不正常的.
• health_check_port 设置一个额外的检查端口,如果是服务定位器就无效
• health_check_interval 健康检查间隔,默认30s
• health_check_timeout 检查超时时间,默认60s
• header_upstream 传递到后方的头,可以多个,也可以用请求占位符
• header_downstream 修改返回的响应头
• keepalive 保持多少和后端之间闲置的连接,设置为0关闭keepalive
• without 去掉的前缀(/api/foo without /api 将访问 /foo. )
• except设置不代理的路径
• upstream 基本等同于to配置
• insecure_skip_verify 重载后端TLS认证,禁用HTTPS的安全功能
• preset 支持的有websocket和transparent

阅读剩余部分 -

在 http 头中有一个字段：X-Forwarded-For，该字段是一个 HTTP 扩展头部。HTTP/1.1（RFC 2616）协议并没有对它的定义，它最开始是由 Squid 缓存代理软件引入，用来表示 HTTP 请求端真实 IP。如今它已经成为事实上的标准，被各大 HTTP 代理、负载均衡等转发服务广泛使用，并被写入 RFC 7239（Forwarded HTTP Extension）标准之中。

假设一个场景，你的网站使用了 CDN 加速， CDN 会隐藏掉你源站的真实 IP， 当请求到达时，会先请求到 CDN 边缘节点，而后转发到源站，此时你可以把 CDN 当做是一个代理服务器，事实上，它也确实是一个代理服务器。

字段介绍

X-Forwarded-For 请求头格式非常简单，就这样：

X-Forwarded-For: client, proxy1, proxy2

其内容由英文逗号 + 空格隔开的多个部分组成，最开始的是离服务端最远的设备 IP，然后是每一级代理设备的 IP。

如果一个 HTTP 请求到达服务器之前，经过了三个代理 Proxy1、Proxy2、Proxy3，IP 分别为 IP1、IP2、IP3，用户真实 IP 为 IP0，服务端最终会收到以下信息：

X-Forwarded-For: IP0, IP1, IP2

阅读剩余部分 -

本文将对Caddy的29个标准HTTP指令做一个汇总，并简要的描述每个指令的作用．

所有的指令的详细介绍都可以在 https://caddyserver.com/docs/ 路径下查看,如查看 proxy 的详细介绍可访问 https://caddyserver.com/docs/proxy

阅读剩余部分 -

## Caddy 是什么？ Caddy 是一个多功能的 HTTP web服务器，并且使用Let’s Encrypt提供的免费证书，自动让网站升级到HTTPS

Every Site on HTTPS Caddy is a general-purpose HTTP/2 web server that serves HTTPS by default. Fork Caddy On Github

为什么要使用 Caddy

1. 安全 Caddy 是一个默认使用https协议的web服务器
2. 无依赖 Caddy 使用 Go 语言编写，编译好的二进制文件能够运行在任何支持Go语言的平台，不需要自己安装任何库。
3. 使用简单 Caddy 的配置简单，不管你是新的web开发者，还是专业人士，都能够快速上手

安装以及运行

1. 下载 Caddy download 在官网上选择指定的平台，下载指定平台的运行包。 这里以 CentOS 7.0 x64 为例。 选择 Linux 64-bit，然后点 DOWNLOAD。 通过ftp将下载好的包上传到服务器，或者复制出下载地址直接在服务端 wget https://caddyserver.com/download/linux/amd64。 使用 wget 的模式下载下来的文件名是 amd64。 tar -xzvf amd64 解压， 解压后文件如下。  我们可以直接运行 ./caddy，这样就启动了一个静态的web服务器，根目录为当前目录，端口为 2015，可以通过你服务器的ip地址加上:2015 进行访问了。 如果你访问的时候，报404异常，在你当前目录下添加一个 index.html 文件即可。

阅读剩余部分 -