PHPor 的Blog – 第53页

关于tcp代理与keepalive

关于tcp代理涉及3个实体：

c： client

p： proxy

s： server

c <—–> p <—–> s

c 和 p建立tcp连接， p 和 s 建立tcp连接；

对于tcp来讲，很可能不是http那样ask and answer then close的，很有可能连接上长时间没有数据，那么会出现什么问题呢？

假如 c 和 p 之间的网线短了， c 不可能再关闭这个连接了，那么p如何释放这个连接呢？
1. p 在该连接上设置keepalive，定期检查连接是否断开，一般系统设置的间隔时间为2小时
2. 一定程度上，c也关心这个长时间没有使用的连接是否依然可用，那么，c也可以在该连接上设置keepalive
问题：
1. p 是否会转发c 的keepalive 数据包？
  1. p 是tcp（传输层）的代理，只有接到数据才会转发，没有数据不会转发
  2. keepalive 实际上是一个数据长度为0的ip数据包
  3. 所以： p 不会转发keepalive
2. 既然p不会转发keepalive，那么如果p和 s 之间的链路出现问题，c 将不知道其实连接已经不可用了，然后就会数据发送失败

总结：

p 有必要和c、s keepalive

代理之mitmproxy

偶然一次又发现一个不错的代理： mitmproxy

官方地址： https://mitmproxy.org （需要梯子）

该proxy支持python脚本编程： http://docs.mitmproxy.org/en/stable/scripting/overview.html (程序员就爱这个)

关于http_proxy 与https_proxy

很多程序会自动识别HTTP_PROXY ， HTTPS_PROXY 环境变量，然后决定是否走代理，那么，这两个变量是什么意思呢？

如：

HTTP_PROXY=http://proxy.phpor.net:8888

1	HTTP_PROXY=http://proxy.phpor.net:8888

HTTPS_PROXY=http://proxy.phpor.net:8888

1	HTTPS_PROXY=http://proxy.phpor.net:8888

前者说明：如果访问的地址是http的（不是https的），则使用代理：http://proxy.phpor.net:8888

后者说明：如果访问的地址是https的（不是http的），则使用代理：http://proxy.phpor.net:8888

这里根本不要求HTTPS_PROXY 的代理url一定是https的，也不要求HTTP_PROXY的代理url一定是http的。

但是，需要注意的是，似乎curl并不支持一个类似于https://proxy.phpor.net:8888 的https的地址，即使写作https，curl依然使用http明文的方式向代理发起请求。

有些程序如（curl）不识别HTTP_PROXY ，只能用http_proxy；但是HTTPS_PROXY ，却可以使用大写的(小写的优先）。参考： man curl

wget 总是只识别小写的: http_proxy， https_proxy

优雅切换软连接的方法

对于大访问量的网站，上线代码时一般有两种方式：

对于第一种方法，不好

对于第二种方法，切换软连接也可能会出现问题，尽管速度很快，测试方法：

在一个term中不断地查看a目录下的m文件（a是一个软连接，可能连接到a.1 或 a.2）

# ll a
lrwxrwxrwx 1 root root 3 11月 10 15:27 a -&gt; a.1

# cat a.1/m
m in a.1
# cat a.2/m
m in a.2

# ll a

lrwxrwxrwx 1 root root 3 11月 10 15:27 a -> a.1

# cat a.1/m

m in a.1

# cat a.2/m

m in a.2

命令1：

while :; do cat a/m &gt;/dev/null;done

1	while :; do cat a/m >/dev/null;done

然后在另一个term中执行命令2：

unlink a &amp;&amp; ln -s a.2 a

1	unlink a && ln -s a.2 a

我们发现命令1有一个出错；那么如果才能使得命令1不会感知到变化呢？

命令3：

#ln -s a.2 b &amp;&amp; mv -T b a

1	#ln -s a.2 b && mv -T b a

执行该命令并不会导致命令1出错，不是凑巧没出错吗？做个压力测试吧：

命令4：

i=1;while :; do [ $i = 1 ] &amp;&amp; i=2 || i=1; ln -s a.$i b; mv -T b a; done

1	i=1;while :; do [ $i = 1 ] && i=2 \|\| i=1; ln -s a.$i b; mv -T b a; done

PHP5 升级到PHP7时curl注意事项

（从大量的CLOSE_WAIT发现的问题）

脚本：

<?php
$url = $argv[1];
$mm = array();
function curl($url) {
	global $mm;
	$ch = curl_init();
	curl_setopt($ch, CURLOPT_URL, $url);
	#curl_setopt($ch, CURLOPT_HTTPHEADER, array("Connection: close"));
	curl_exec($ch);
	$mm[] = $ch;
	curl_close($ch);
}
for($i = 0; $i < 1000; $i ++) {
	curl($url);
}

<?php

$url = $argv[1];

$mm = array();

function curl($url) {

global $mm;

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);

#curl_setopt($ch, CURLOPT_HTTPHEADER, array("Connection: close"));

curl_exec($ch);

$mm[] = $ch;

curl_close($ch);

}

for($i = 0; $i < 1000; $i ++) {

curl($url);

}

对于curl来说：

如果请求头中含有 Connection: close 则，执行完请求之后，curl会主动关闭连接，即使不主动curl_close() 也没有关系
如果请求头中没有Connection: close，则：
1. 如果curl句柄被销毁了，则连接自动关闭
2. 如果句柄没有被销毁（如：被保存到了全局（或其他静态）变量中），则：
  1. PHP5中，curl_close() 可以关闭连接
  2. PHP7中，curl_close() 不会关闭连接（或许他猜测你可能还会用到），如果你不小心把句柄保存起来了，那么会有什么问题呢? 问题：
    服务器端等待足够长时间后要关闭连接，而客户端却不做任何处理，导致连接处于CLOSE_WAIT状态，如果足够多，会导致local port被用完。
    不过，这个问题看似不好解决，也比PHP5中好处理，PHP5中如果调用了curl_close，而且还把curl句柄保存了起来，则可能会出现保存了大量的句柄而自己却不知道（就是所谓的内存泄漏）

HTTP之Connection

HTTP的Connection头是在HTTP/1.1中添加的

tinyproxy源码学习

解析request_line 时，使用sscanf （php中也有该函数）
upstream可以设置upstream代理，如： client要请求phpor.net，tinyproxy中可以配置如果client请求的是phpor.net，则请求proxy.phpor.net，而不是代理请求phpor.net
remove_connection_headers 中定义了上行请求的请求头中包含的connection要去掉，如： connection，proxy-connection

当tinyproxy遇上php的soap

用例：

使用tinyproxy-1.8.3做代理
php访问soap服务时，使用tinyproxy做代理访问http地址（不是https）
http响应数据有点儿多，走的是Transfer-Encoding: chunked

问题：

tinyproxy代理之后，响应头中 HTTP协议版本号为1.1，没有content-length, 也没有connection: close ，也没有Transfer-Encoding: chunked，对于这种尴尬的情况，client端就不方便处理了； curl会有如下警告： no chunk, no close, no size. Assume close to signal end
真实原因： curl虽然使用HTTP/1.1方式发送请求，但是tinyproxy对于所有http请求都以HTTP/1.0的方式转发(但是添加了Connection: close 头)，最终的openresty（nginx行为也如此）却无视HTTP/1.0，执意返回HTTP/1.1 响应，并且使用Connection: close; tinyproxy直接透传HTTP/1.1 状态行，却丢弃了响应头中的Connection: close;(或许是tinyproxy以为自己总是工作在HTTP/1.0，所以不需要Connection: close 吧）

tinyproxy转发的请求：（发给nginx，nginx再代理转发给后面的openresty）

GET / HTTP/1.0
Host: op-phpor.i.hrbbwx.com
Connection: close
Accept: */*
User-Agent: curl/7.29.0

GET / HTTP/1.0

Host: op-phpor.i.hrbbwx.com

Connection: close

Accept: */*

User-Agent: curl/7.29.0

openresty收到的请求：

GET / HTTP/1.0
Host: op-phpor.i.hrbbwx.com
Connection: close
Accept: */*
User-Agent: curl/7.29.0

GET / HTTP/1.0

Host: op-phpor.i.hrbbwx.com

Connection: close

Accept: */*

User-Agent: curl/7.29.0

openresty响应：

HTTP/1.1 200 OK
Server: openresty/1.9.15.1
Date: Sat, 05 Nov 2016 02:51:16 GMT
Content-Type: text/html; charset=UTF-8
Connection: close

HTTP/1.1 200 OK

Server: openresty/1.9.15.1

Date: Sat, 05 Nov 2016 02:51:16 GMT

Content-Type: text/html; charset=UTF-8

Connection: close

openresty是藏在一个nginx后面的，nginx的响应：

HTTP/1.1 200 OK
Server: nginx/1.7.4
Date: Sat, 05 Nov 2016 02:51:16 GMT
Content-Type: text/html; charset=UTF-8
Connection: close

HTTP/1.1 200 OK

Server: nginx/1.7.4

Date: Sat, 05 Nov 2016 02:51:16 GMT

Content-Type: text/html; charset=UTF-8

Connection: close

分析：

原本HTTP/1.0 是不支持Host头的，但是很多client还是添加了，很多server也不介意（甚至喜欢）HTTP/1.0协议中使用Host头，参考： http://stackoverflow.com/questions/246859/http-1-0-vs-1-1

Connection 头也是http1.1中定义的，但是tinyproxy也用在了HTTP/1.0中了（难道为了兼容一些不守规矩的server端？），在HTTP/1.0和Connection头的暗示下，server端没有使用Content-length 或 Transfer-encoding也可以理解，也或许正式Connection头的存在，server端才选择响应HTTP/1.1

tinyproxy 源码片段：

tiny proxy发送请求：

static int
establish_http_connection (struct conn_s *connptr, struct request_s *request)
{
        char portbuff[7];
        char dst[sizeof(struct in6_addr)];

        /* Build a port string if it's not a standard port */
        if (request->port != HTTP_PORT && request->port != HTTP_PORT_SSL)
                snprintf (portbuff, 7, ":%u", request->port);
        else
                portbuff[0] = '\0';

        if (inet_pton(AF_INET6, request->host, dst) > 0) {
                /* host is an IPv6 address literal, so surround it with
                 * [] */
                return write_message (connptr->server_fd,
                                      "%s %s HTTP/1.0\r\n"
                                      "Host: [%s]%s\r\n"
                                      "Connection: close\r\n",
                                      request->method, request->path,
                                      request->host, portbuff);
        } else {
                return write_message (connptr->server_fd,
                                      "%s %s HTTP/1.0\r\n"
                                      "Host: %s%s\r\n"
                                      "Connection: close\r\n",
                                      request->method, request->path,
                                      request->host, portbuff);
        }
}

static int

establish_http_connection (struct conn_s *connptr, struct request_s *request)

{

char portbuff[7];

char dst[sizeof(struct in6_addr)];

/* Build a port string if it's not a standard port */

if (request->port != HTTP_PORT && request->port != HTTP_PORT_SSL)

snprintf (portbuff, 7, ":%u", request->port);

else

portbuff[0] = '\0';

if (inet_pton(AF_INET6, request->host, dst) > 0) {

/* host is an IPv6 address literal, so surround it with

* [] */

return write_message (connptr->server_fd,

"%s %s HTTP/1.0\r\n"

"Host: [%s]%s\r\n"

"Connection: close\r\n",

request->method, request->path,

request->host, portbuff);

} else {

return write_message (connptr->server_fd,

"%s %s HTTP/1.0\r\n"

"Host: %s%s\r\n"

"Connection: close\r\n",

request->method, request->path,

request->host, portbuff);

}

由于tinyproxy上行的是http/1.0 ,所以会故意将请求头中的connection相关信息去掉，代码如下：

这个函数不仅在process_client_headers 中用到，也在 process_server_headers中用到

解决办法：

如果使用隧道代理的方式，tinyproxy就不会做上述多余的处理了，但是， php的soapclient强制写死的逻辑是：如果方式的是https，则使用隧道代理方式，否则，不走隧道代理方式，可是服务提供的就是http，不是https啊！！！！！！
修复tinyproxy的这个问题，修复方案：
换个proxy

疑问：

如果 content-length 不存在与http 1.0，那么http 1.0中的post请求，post数据长度如何表示？（难道也是关闭连接为止？

Docker 端口映射

问题：

如何在已创建的容器上暴露更多端口？

分析：

一般来讲，我们在构建镜像或创建容器的时候指定容器暴露哪些端口，Docker没有提供其他的方法来暴露容器中的端口；

看看Docker暴露端口的手段发现暴露端口这事儿是通过传统的iptables来实现的，于是乎，只需要添加相应的iptables规则就可以搞定了，如：

to expose the container’s port 8000 on your localhosts port 8001:

 iptables -t nat -A  DOCKER -p tcp --dport 8001 -j DNAT --to-destination 172.17.0.19:8000

1 2	iptables -t nat -A DOCKER -p tcp --dport 8001 -j DNAT --to-destination 172.17.0.19:8000

参考：

http://stackoverflow.com/questions/19897743/exposing-a-port-on-a-live-docker-container

https://www.google.com.hk/?gws_rd=cr,ssl#safe=strict&q=docker+port+mapping+after+run

Docker存储之Devicemapper

问题

docker 容器中创建很大的文件会占用较多的docker存储空间（很正常啊），在容器内部df可以看到容量的变化，在宿主机上docker info也能看到data空间的变化；

当把那个（或那些）很大的文件删除后，在容器内部df可以看到已用容量减小，可用容量变大，但是宿主机上docker info看到的已用空间却没有减少，也就是说，已经分配出去的就收不回来了。

怎么办？

也不是完全回收不了，当把那个容器删除掉，docker info看到的已用空间就会减少了

所以：

必要的时候可以重建容器
不是特别需要的话，不要在容器内部写太多的数据，大数据写到卷上