协议相关 – 第2页 – PHPor 的Blog

测一下tcp的读写buffer有多大

Linux & Unix, TCP/IP No Responses »

3,432

7月 312013

测试办法：

1. 使用nc做一个server

nc -l localhost 8181

CTRL-Z

2. 使用nc做client

nc localhost 8181 </dev/zero

3. netstat -an |grep 8181

tcp   171008      0 127.0.0.1:8181          127.0.0.1:43900         ESTABLISHED -                关闭 (0.00/0/0)
tcp        0 1279872 127.0.0.1:43900         127.0.0.1:8181          ESTABLISHED 22985/nc         未知-4 (107.99/0/0)

1 2	tcp 171008 0 127.0.0.1:8181 127.0.0.1:43900 ESTABLISHED - 关闭 (0.00/0/0) tcp 0 1279872 127.0.0.1:43900 127.0.0.1:8181 ESTABLISHED 22985/nc 未知-4 (107.99/0/0)

171008 就是读buffer的大小（约160KB）， 1279872就是写buffer的大小（约1.2MB）

现在nc client被write给阻塞住了，如果nc client之发送小于 171008 + 1279872 的数据，则现在已经兴高采烈地quit了，然而，server端却连1个字节都没处理呢，如果在把server给杀掉，则这些数据就都算丢弃了。

原文链接：https://phpor.net/blog/post/2032

linux网络编程之shutdown() 与 close()

Linux & Unix, TCP/IP No Responses »

2,977

7月 302013

引言

1. tcp是有read buffer和write buffer的，如何才能确保数据不会死在buffer里，虽然tcp是面向连接的可靠的协议，但是tcp没有可靠到这等程度，有些事情还是需要考应用层来保证的

正文

关于shutdown和close的一些说明：

1. 如果有多个进程共享一个套接字，close每被调用一次，计数减1，直到计数为0时，也就是所用进程都调用了close，套接字将被释放。

2. 在多进程中如果一个进程中shutdown(sfd, SHUT_RDWR)后其它的进程将无法进行通信. 如果一个进程close(sfd)将不会影响到其它进程. 得自己理解引用计数的用法了. 有Kernel编程知识的更好理解了.

3. 只要TCP栈的读缓冲里还有未读取（read）数据，则调用close时会直接向对端发送RST。

4. shutdown与socket描述符没有关系，即使调用shutdown(fd, SHUT_RDWR)也不会关闭fd，最终还需close(fd)。

5. 可以认为shutdown(fd, SHUT_RD)是空操作，因为shutdown后还可以继续从该socket读取数据，这点也许还需要进一步证实。

6. 在已发送FIN包后write该socket描述符会引发EPIPE/SIGPIPE。

7. 当有多个socket描述符指向同一socket对象时，调用close时首先会递减该对象的引用计数，计数为0时才会发送FIN包结束TCP连接。shutdown不同，只要以SHUT_WR/SHUT_RDWR方式调用即发送FIN包。

8. SO_LINGER与close，当SO_LINGER选项开启但超时值为0时，调用close直接发送RST（这样可以避免进入TIME_WAIT状态，但破坏了TCP协议的正常工作方式），SO_LINGER对shutdown无影响。

9. TCP连接上出现RST与随后可能的TIME_WAIT状态没有直接关系，主动发FIN包方必然会进入TIME_WAIT状态，除非不发送FIN而直接以发送RST结束连接。

参考资料：

http://baike.baidu.com/view/569222.htm

http://blog.csdn.net/lgp88/article/details/7176509

http://brad.livejournal.com/2152593.html

http://blog.csdn.net/chinalinuxzend/article/details/1792187

原文链接：https://phpor.net/blog/post/2028

如何spawn多个外部程序并且accept同一个socket

Fastcgi, Linux & Unix No Responses »

4,616

7月 172013

缘起

学习fastcgi的时候，多个fcgi进程的启动和管理是个无法回避的问题；有一个叫做spawn-fcgi的程序，可以启动多个php-cgi进程，并且同时accept同一个socket，因为spawn-fcgi和php-cgi是两个项目中的程序，那么他们是如何配合的如此默契的呢？

资料： http://redmine.lighttpd.net/projects/spawn-fcgi 其中主要是： http://redmine.lighttpd.net/projects/spawn-fcgi/repository/entry/trunk/src/spawn-fcgi.c

分析

从代码来看，spawn-fcgi负责lisent一个socket，然后开始fork指定数量的子进程，每个子进程中先把socket的fd复制到FCGI使用的fd（似乎是约定好的一个fd），然后就把后续的事情通过exec交给外部的进程（如：php-cgi）了

下面看一下PHP中fastcgi的相关逻辑，文件 sapi/cgi/fastcgi.c 中的 int fcgi_init(void)；函数体现了如何识别是否fastcgi的逻辑，大致意思为：如果标准输入为一个socket（不是fileno），则认为是fastcgi，代码片段如下：

#ifdef _WIN32
                if ((GetStdHandle(STD_OUTPUT_HANDLE) == INVALID_HANDLE_VALUE) &&
                    (GetStdHandle(STD_ERROR_HANDLE)  == INVALID_HANDLE_VALUE) &&
                    (GetStdHandle(STD_INPUT_HANDLE)  != INVALID_HANDLE_VALUE)) {
                        char *str;
                        DWORD pipe_mode = PIPE_READMODE_BYTE | PIPE_WAIT;
                        HANDLE pipe = GetStdHandle(STD_INPUT_HANDLE);

                        SetNamedPipeHandleState(pipe, &pipe_mode, NULL, NULL);

                        str = getenv("_FCGI_SHUTDOWN_EVENT_");
                        if (str != NULL) {
                                HANDLE shutdown_event = (HANDLE) atoi(str);
                                if (!CreateThread(NULL, 0, fcgi_shutdown_thread,
                                                  shutdown_event, 0, NULL)) {
                                        return -1;
                                }    
                        }    
                        str = getenv("_FCGI_MUTEX_");
                        if (str != NULL) {
                        if (str != NULL) {
                                HANDLE shutdown_event = (HANDLE) atoi(str);
                                if (!CreateThread(NULL, 0, fcgi_shutdown_thread,
                                                  shutdown_event, 0, NULL)) {
                                        return -1;
                                }    
                        }    
                        str = getenv("_FCGI_MUTEX_");
                        if (str != NULL) {
                                fcgi_accept_mutex = (HANDLE) atoi(str);
                        }
                        return is_fastcgi = 1;
                } else {
                        return is_fastcgi = 0;
                }
#else
                errno = 0; 
                if (getpeername(0, (struct sockaddr *)&sa, &len) != 0 && errno == ENOTCONN) {
                        fcgi_setup_signals();
                        return is_fastcgi = 1; 
                } else {
                        return is_fastcgi = 0; 
                }    
#endif

427

428

429

430

431

432

433

434

435

436

437

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

466

467

468

469

470

#ifdef _WIN32

if ((GetStdHandle(STD_OUTPUT_HANDLE) == INVALID_HANDLE_VALUE) &&

(GetStdHandle(STD_ERROR_HANDLE) == INVALID_HANDLE_VALUE) &&

(GetStdHandle(STD_INPUT_HANDLE) != INVALID_HANDLE_VALUE)) {

char *str;

DWORD pipe_mode = PIPE_READMODE_BYTE | PIPE_WAIT;

HANDLE pipe = GetStdHandle(STD_INPUT_HANDLE);

SetNamedPipeHandleState(pipe, &pipe_mode, NULL, NULL);

str = getenv("_FCGI_SHUTDOWN_EVENT_");

if (str != NULL) {

HANDLE shutdown_event = (HANDLE) atoi(str);

if (!CreateThread(NULL, 0, fcgi_shutdown_thread,

shutdown_event, 0, NULL)) {

return -1;

}

str = getenv("_FCGI_MUTEX_");

if (str != NULL) {

HANDLE shutdown_event = (HANDLE) atoi(str);

if (!CreateThread(NULL, 0, fcgi_shutdown_thread,

shutdown_event, 0, NULL)) {

return -1;

}

str = getenv("_FCGI_MUTEX_");

if (str != NULL) {

fcgi_accept_mutex = (HANDLE) atoi(str);

}

return is_fastcgi = 1;

} else {

return is_fastcgi = 0;

}

#else

errno = 0;

if (getpeername(0, (struct sockaddr *)&sa, &len) != 0 && errno == ENOTCONN) {

fcgi_setup_signals();

return is_fastcgi = 1;

} else {

return is_fastcgi = 0;

}

#endif

注意其中 getpeername(…)的使用，如果 errno == ENOTCONN 才可能认为是fastcgi，那么，如果刚好该socket处于连接状态不就不能视为fastcgi环境了吗？或许吧

原文链接：https://phpor.net/blog/post/1983

缘起

如何在不发起一个Http请求的情况下删除一个Httponly的cookie？

探索：

1. 虽然JS无法读取Httponly的cookie，那么JS是否可以设置或删除Httponly的cookie呢？

答案是否定的

2. 使用http-equiv类型的meta标签是可以设置cookie的，那么是否可以cache一个带有http-equiv类型的meta标签的页面来操作cookie呢？

http-equiv类型的meta标签只能设置、删除、修改非Httponly类型的cookie

分析：

分析1：

JS无法访问Httponly的cookie，其中包括三层含义：

无法读取
无法设置和修改
无法删除

如：

无法通过如下方式设置、修改或删除一个已存在的Httponly的cookie：

document.cookie = "test=set_by_js; expires=Thu, 01-Jan-2070 00:00:01 GMT; path=/"

1	document.cookie = "test=set_by_js; expires=Thu, 01-Jan-2070 00:00:01 GMT; path=/"

无法通过如下方式设置、修改或删除一个已存在的Httponly的cookie：

document.cookie = "test=set_by_js; expires=Thu, 01-Jan-2070 00:00:01 GMT; path=/; Httponly"

1	document.cookie = "test=set_by_js; expires=Thu, 01-Jan-2070 00:00:01 GMT; path=/; Httponly"

注意：或许你通过第一种方式在一个Httponly的cookie已存在的情况下设置了一个新的test cookie，那么基本上是因为两个test的domain或path不同；如：一个Httponly的cookie设置在a.test.com域下，而这时通过document.domain=”test.com”，将domain修改为了 test.com；这时候可以通过第一种方式设置一个testcookie，和原有的Httponly的cookie并不冲突

分析2：

HTML中有一个meta标签，其中的一个用法是http-equiv，如，可以通过如下方式设置cookie：

<meta http-equiv="Set-Cookie" content="cookiename=cookievalue; expires=Friday, 12-Jan-2021 18:18:18 GMT； path=/">

1	<meta http-equiv="Set-Cookie" content="cookiename=cookievalue; expires=Friday, 12-Jan-2021 18:18:18 GMT； path=/">

但是，测试发现，似乎无法通过JS创建meta标签的方式来设置cookie

分析3：

测试发现，无法通过meta标签来设置、修改、删除一个Httponly的cookie

原文链接：https://phpor.net/blog/post/1785

IPv6学习

IPv6 No Responses »

4,983

1月 192013

关于WebSocket

HTTP协议 No Responses »

1,787

1月 182013

1. WebSocket rfc 中文翻译： http://blog.csdn.net/stoneson/article/details/8063802

2. http://o0211oo.iteye.com/blog/1671973

原文链接：https://phpor.net/blog/post/1755

Why https？

HTTP协议 No Responses »

2,075

1月 172013

Why https？

保证用户信息的传输安全。包括用户名、密码、cookie、用户保存的服务器端信息等等
很大程度上免遭DNS劫持

Why not https？

更多的cpu资源的消耗
证书校验的时间消耗
证书校验可能因一些问题导致验证失败

原文链接：https://phpor.net/blog/post/1745

关于PHP中http请求的一个细节

HTTP协议, Linux & Unix, TCP/IP No Responses »

2,211

1月 112013

缘起：

使用php的file_get_contents(…) 函数从广州发送一个http请求到北京，该请求的请求头和响应头如下：

GET / HTTP/1.1
Host: phpor.net

HTTP/1.1 200 OK
Date: Fri, 11 Jan 2013 11:11:19 GMT
Server: Apache
Content-Length: 5
Connection: close

hello

GET / HTTP/1.1

Host: phpor.net

HTTP/1.1 200 OK

Date: Fri, 11 Jan 2013 11:11:19 GMT

Server: Apache

Content-Length: 5

Connection: close

hello

现在，从广州到北京的一次数据的往返时间（就是ping的时间）为34ms，请求的执行时间为6ms；因为请求头和相应头都非常小，分别一次tcp数据包就够，这样的话，一次http请求时间为： 34 + 34 + 6 = 74ms ，而实际却稳定在108ms左右，还有大约34ms不知去向

分析

根据这个丢失的时间长度来看，大概是多了一次数据的发送和接收；通过tcpdump抓包发现如下现象：

file_get_contents(…)中实现的http请求，首先把请求行发送出去，收到请求行数据包的ack包后继续发送后续的请求头；这样的话就凭空多出一次网络时间，其各种原因，有时间再看看PHP源码中为何如此实现吧。

测试了一下curl，没有这个问题。

原文链接：https://phpor.net/blog/post/1728

IPv6的检测

Linux & Unix, TCP/IP No Responses »

1,955

1月 092013

看了一下如下脚本：

$ strace -T -e network php a.php
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = -1 EAFNOSUPPORT (Address family not supported by protocol) <0.005651>

1 2	$ strace -T -e network php a.php socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = -1 EAFNOSUPPORT (Address family not supported by protocol) <0.005651>

一次IPv6支持的检测需要5ms+的时间，成本是比较大的，但是，同一个进程中只检测一次，所以对于httpd进程来讲，这个是没有问题的

原文链接：https://phpor.net/blog/post/1725

tcprstat

Linux & Unix, TCP/IP No Responses »

2,221

1月 072013

这是一个可好的东西了，怎么个好法呢。。。

http://www.percona.com/docs/wiki/tcprstat:start

原文链接：https://phpor.net/blog/post/1722

Older Entries Newer Entries