Network on kamuszhou's blog

netstat -s统计输出的所有字段详细解释

Fri, 23 Nov 2018 08:45:32 +0000

今天工作上碰到一个问题需要知道udp的丢包数据。实际上我不相信能简单地得到udp的丢包精确数据。理由是，网卡负载太高时有些包连网卡都没收到，根本不可能来得及汇报给内核。另外，如果是路由器把udp丢了，那udp的目的端机器当然更不可能感知到有丢包了。

这时，同事说netstat -us (–statistic)可以看到udp的丢包。这里的u选项指的是只展示udp相关的统计，s选项自然表示的是统计了。如果不用u选项，则出显示所有统计数据。下面是我的机器上的输出。

Ip:
    203440255187 total packets received
    0 forwarded
    0 incoming packets discarded
    201612429535 incoming packets delivered
    1064529177 requests sent out
    15 fragments dropped after timeout
    3058122492 reassemblies required
    1230296840 packets reassembled ok
    15 packet reassembles failed
Icmp:
    14869220 ICMP messages received
    3965512 input ICMP message failed.
    ICMP input histogram:
        destination unreachable: 6054246
        timeout in transit: 687
        echo requests: 8570532
        echo replies: 243755
    12913011 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 4097869
        time exceeded: 5
        echo request: 244605
        echo replies: 8570532
IcmpMsg:
        InType0: 243755
        InType3: 6054246
        InType8: 8570532
        InType11: 687
        OutType0: 8570532
        OutType3: 4097869
        OutType8: 244605
        OutType11: 5
Tcp:
    111681768 active connections openings
    4186820 passive connection openings
    24951865 failed connection attempts
    55064041 connection resets received
    275 connections established
    1033901799 segments received
    1776166765 segments send out
    12156205 segments retransmited
    6705 bad segments received.
    106348033 resets sent
Udp:
    198894689917 packets received
    472986510 packets to unknown port received.
    1146976531 packet receive errors
    116750744 packets sent
    110301286 receive buffer errors
    0 send buffer errors
UdpLite:
TcpExt:
    423 invalid SYN cookies received
    693 packets pruned from receive queue because of socket buffer overrun
    19 packets pruned from receive queue
    11309370 TCP sockets finished time wait in fast timer
    106 packets rejects in established connections because of timestamp
    10210477 delayed acks sent
    20811 delayed acks further delayed because of locked socket
    Quick ack mode was activated 8856 times
    17118697 packets directly queued to recvmsg prequeue.
    301717551 bytes directly in process context from backlog
    152118951904 bytes directly received in process context from prequeue
    104771733 packet headers predicted
    15179703 packets header predicted and directly queued to user
    218747377 acknowledgments not containing data payload received
    102637644 predicted acknowledgments
    7293 times recovered from packet loss by selective acknowledgements
    Detected reordering 40 times using FACK
    Detected reordering 27 times using SACK
    Detected reordering 1088 times using time stamp
    476 congestion windows fully recovered without slow start
    5287 congestion windows partially recovered using Hoe heuristic
    236 congestion windows recovered without slow start by DSACK
    151673 congestion windows recovered without slow start after partial ack
    1 timeouts after reno fast retransmit
    4 timeouts after SACK recovery
    10540 timeouts in loss state
    7232 fast retransmits
    649 forward retransmits
    1871 retransmits in slow start
    11612658 other TCP timeouts
    TCPLossProbes: 93185
    TCPLossProbeRecovery: 14667
    2431 packets collapsed in receive queue due to low socket buffer
    8814 DSACKs sent for old packets
    3350 DSACKs received
    1 DSACKs for out of order packets received
    90851 connections reset due to unexpected data
    214 connections reset due to early user close
    352 connections aborted due to timeout
    TCPDSACKIgnoredNoUndo: 1571
    TCPSpuriousRTOs: 7
    TCPSackShifted: 94
    TCPSackMerged: 131
    TCPSackShiftFallback: 21183
    TCPTimeWaitOverflow: 1876775
    TCPRcvCoalesce: 15711184
    TCPOFOQueue: 3194
    TCPChallengeACK: 2337394
    TCPSYNChallenge: 13608
    TCPSpuriousRtxHostQueues: 1982796
IpExt:
    InBcastPkts: 46443933
    InOctets: 44312451521655
    OutOctets: 1915626725817
    InBcastOctets: 6827280595

喂，要是转载文章。麻烦贴一下出处 ykyi.net 采集爬虫把链接也抓走

Linux系统级/进程级最多打开文件数,FD文件描述符数

Thu, 22 Nov 2018 11:55:39 +0000

如何增加Linux系统最大文件打开数目呢？

查看系统最大可打开文件数

以下命令查看操作系统级最多可打开文件数,fd数目

$ cat /proc/sys/fs/file-max

我用ubuntu 16输出:

怎么调整系统最大可打开文件数

# sysctl -w fs.file-max=1000000

需要用root用户执行以上命令，设最大为一百万。
但在命令行上修改了这个配置，会在下一次操作系统重启后重置为以前的值。要一劳永逸的改变系统最大打开文件数，需要修改 /etc/sysctl.conf 文件。

fs.file-max = 1000000

在/etc/sysctl.conf文件中增加上述一行。

ulimit命令查看/调整进程级最大文件打开数

$ ulimit -Sn
1024

这个命令查看一个ulimit的软极限值(soft limit)，本用户起的进程的最大文件打开数的限制。我的ubuntu 16显示进程最多开1024个fd。如果要提高每个进程可同时打开的文件数，需要更改这个值。

$ ulimit -Sn 2048
bash: ulimit: open files: cannot modify limit: Invalid argument

但我想把每个进程可同时打开的文件数增加到以前的两倍时，报错了。这是因为，软极限值(soft limit)不能够越过(Hard Limit)。我看了一下Hard limit，也是1024

$ ulimit -Hn
1024

那没办法罗，需要以root用户登录更改Hard Limit。

怎么修改普通用户的硬极限hard Limit

用root账户登录后，编辑 /etc/security/limits.conf文件，假如普通用户名是kamuszhou。

kamuszhou hard nofile 10000
kamuszhou soft nofile 5000

以上配置修改kamuszhou普通用户的最多打开文件数的hard limit为10000，soft limit为5000。
对于ubuntu 16，如果使用图形桌面，还需要修改 /etc/systemd/system.conf 和 /etc/systemd/user.conf。
加上这么一行：

服务器端的tcp有大量TIME_WAIT怎么办

Fri, 20 Oct 2017 06:03:06 +0000

公司的群里讨论tcp的TIME_WAIT的问题。TIME_WAIT这个状态可是面试时经常问的知识点啊。
讨论的问题是：有一个服务器，它对外网提供服务，同时它作为客户端连接很多后端的其它服务器。这位同事连后端其它服务器时用了短tcp连接。结果出现了大量的tcp TIME_WAIT状态，吞吐量上不去，怎么办？

先说结论：

如果该服务器要处理外网IP的入流量，那最好的办法应该是用tcp长链接改造它与后端服务器的连接。如果用中间件，比如上zeromq那更省心了。
如果不想做改动，并且在应用层确认已经交互已经完成，则可以用shutdown()直接发RST结束tcp会话，而不走正常的4次挥手。查阅shutdown系统调用的文档获知如何发RST。
如果该服务器不需要处理处网IP请求的话，那么，启用port reuse 即打开net.ipv4.tcp_tw_reuse不会有太大问题(如果处理外网请求就有问题，和NAT相关，见https://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux)，或者更好的，把/proc/sys/net/ipv4/tcp_fin_timeout改小，改成1或者2。让TIME_WAIT只保持很短的时间。

首先，需要知道一个tcp会话由 src_ip, src_port, dest_ip, dest_port 四元组确定。
我们公司的IDC环境中，上述的服务器作为客户端再发起tcp连接联后端服务器，则 src_ip 固定了， dest_ip是后端服务器的ip, port是后端服务器监听端口。这样只有 src_port 是可变化的，但port只有16个bits还不能用well-known ports，这样就更少了。

再说，主动关闭时，tcp连接需要进入TIME_WAIT状态，保持两倍MSL时长，是为了处理两种情况：

让当前这个会话的迷路包在网路中消失。这样不会干扰到新建的会话。
确保主动关闭方的FIN-ACK包，如果丢失的话，还能重发。
1981年的TCP RFC上把MSL设成两分钟，https://tools.ietf.org/html/rfc793

Maximum Segment Lifetime, the time a TCP segment can exist in
the internetwork system. Arbitrarily defined to be 2 minutes.

MSL设置这么长，因为以前的网络环境差啊。不过现在因为移动互联网，比较差的网络状态也是非常常见的。但RFC允许实现方减少MSL值。事实上linux的MSL写死在代码中为1分钟并且不可在运行期配置。
如果tcp连接的双方都在性能高速稳定的内网中，这个MSL就太长了。

调试时，还发现如果port用完了，connect的时候内核代码会用自旋锁忙等检查port资源。有linux内核开发基础的开发者都知道spin_lock的时候是不会让出cpu的，于是cpu全被spin_lock吃掉了。一直要等到有port被释放。再后来又发现，如果scoket没有设定SO_REUSEADDR选项，则connect()系统调用会返回EADDRINUSE。

tcp的连接双方都是确定且长期的，用什么tcp短连接呢？？改造吧~~~

用lftp为ftp服务器做镜像

Wed, 27 Sep 2017 11:54:46 +0000

用lftp为ftp服务器做镜像

命令是这样的:

$ lftp -d -u user_name,password ftp_server_host -e "mirror -c -e --parallel=5 / /path/to/mirror"

解释一下这里的选项：

-d 调试模试，看到详细的输出
-u 用户名和密码，用,隔开
-e 让lftp执行lftp自有的一些命令
mirror 执行做镜像命令
-c continue a mirror job if possible 继续做镜像，如果可能的话。难道不用这个选项，做镜像的过程有可能被中断？
-e 如果一个文件在ftp站点上没有，但在本机上有，则删除这个文件
–parallel 并发数
http://ykyi.net
mirror 命令还有一个 -R 参数，这样的话，会put文件到ftp服务器，效果和上例相反。

Tue, 17 Jan 2017 09:35:16 +0000

1. 前言：

ZeroMq aka zmq是最知名的网络消息中间件之一。使有zmq的开源软件中最知名的莫过于Apache基金会下的Storm。我厂内部使用zmq的有即通的yaaf框架。

ZMQ社区在2013年9月发布了zmq4。zmq4最大的新功能即提供了一套安全机制，其中有IP黑白名单，用户名/密码鉴权，ECC(Elliptic Curve Cryptography)证书鉴权，以及通讯的加密(类似TSL)。

本文主要介绍zmq4.0的安全机制。

2. ECC的故事：

这里的ECC不是我厂历史上的电商事业群，而是椭圆曲线加密算法。ECC据说被NSA(美国安全局)操作，在算法中设置了后门。不过好在不是只有一种椭圆曲线，而是有无数种，不同的曲线有不同的优点和缺点，只是其中由NIST(美国标准和技术研究署)推荐的曲线被怀疑设置了后门。

ZMQ使用的椭圆曲线算法是Curve25519 ,它有开源实现而且没有专利保护。zmq用了长度为256bits的密钥，强度相当于RSA 3072比特的密钥长度。

ECDH(Elliptic Curve Diffie-Hellman)则是一个密钥协商协议。非常简单地讲，当A与B在一个不受信任的网络中通讯前，A和B先生成一对公私钥，并且A和B通过某个完全的渠道事先知道对方的公钥，然后A和B在握手阶段协商出一个双方公知的私钥供加密接下来的通讯。

可以理解成zmq设计了一个专门为自己定制的精简的TLS，更多的理论细节在http://curvezmq.org/page:read-the-docs，

作为一个码农，下面用代码介绍使用zmq4的Curve安全机制

3. 证书鉴权,通讯加密,IP 白名单

编译zmq4.x以后，会生成一个名叫curve_keygen的程序，用它可以生成zmq 的证书。证书是一个一般的文本文件，如下是一个curve_keygen生成的zmq证书的例子。

# **** Generated on 2017-01-02 14:24:20 by CZMQ **** # ZeroMQ CURVE **Secret** Certificate # DO NOT PROVIDE THIS FILE TO OTHER USERS nor change its permissions.

metadata email = “kamuszhou@tencent.com” curve public-key = “!Upjrn]2Dk)jQkYREsceBnpgoIL7koE{CVnV1j4D” secret-key = “ZPT#=l/#Rtg:TeLbofh:uPi7#/w(GDZq[0^qPZA1”

原来比特位也有大小端endinness.字节序和比特序的故事

Tue, 13 Sep 2016 11:52:46 +0000

我一直以为大小端endianness只针对字节，不针对比特位。
我一直以为全世界所有的cpu解释bit序都是一样的。

昨天才知道endianness也针对bit。
于是就想不明白了。
因为观察到用 htonl 函数转换endianness后，bit位没有变化，只有字节顺序改了呀。

于是google呀，找到这篇好文：

http://www.linuxjournal.com/article/6788?page=0,0

“Byte and Bit Order Dissection”(字节序和比特序深入剖析)

看了这篇文章，才知道 bit序的翻转是由硬件完成的。原来以前这方面很多概念都没理解对。

HTTP2简单教程

Fri, 03 Apr 2015 08:22:39 +0000

译自：http://qnimate.com/post-series/http2-complete-tutorial/

HTTP1.1是在1999年的时候被引入业界的。从当时到现在，WEB已经发生了相当大的变化。很多人开始用移动设备上网，有些移动环境下网络质量非常不稳定。另外，WEB页面的内容也相当的丰富了。这些都负面影响了WEB页面的加载时间。因此，需要一个新的协议来加速WEB的加载。

HTTP/2和SPDY****的区别：

SPDY是谷歌于2009年创造的协议，旨在WEB延迟以及增强安全性。

HTTP/2是SPDY的一个克隆。谷歌已经停止了继续开发SPDY，并且把工作转移到了HTTP/2上来。

HTTP/2****的目标：

减少加载延时。
减少TCP连接数。
增强的网络安全。
保持和HTTP/1.1的兼容。

HTTP/2****的功能：

多路复用Multiplexing：很多个异步的HTTP请求只使用一个TCP的连接。
服务端PUSH：对于一个请求可能有多个回复。
头部压缩：压缩头部(headers)。
请求分级：对同一个域名的请求可作优先级分级。
二进制协议：HTTP/2是一个二进制协议，而HTTP/1.1是一个文本协议。

HTTP/2解决了HTTP/1.1****的哪些问题：

HTTP管道(HTTP pipelining)：一些HTTP1.1客户端使用了HTTP管道技术来减少TCP连接数。HTTP管道指的是多个HTTP请求被发往同一个TCP连接，而不等待前一个请求的回复。但是服务端发送回复时的顺序和收到的请求的顺序一样。因此，造成了HOL阻塞问题(head-of-line blocking)。HOL Blocking简单地说是一个回复的延迟会使得排在它后面的回复都会延迟。HTTP/2透过引用多路复用(Multiplexing)解决了这个问题。多个HTTP请求和多个HTTP回复都使用同一个TCP连续，而且HTTP回复的顺序不需要保持HTTP请求到达的顺序。
同一个域名的多个TCP连接：在使用HTTP/1.1时，需要对同一个域名起多个TCP连接来增加吞吐量。而使用HTTP/2时，对于每个域名，只充许有一个TCP连接（only one TCP connection per domain is allowed）。所有的请求和回复都通过唯一的一个TCP连接进行。
TCP连接的关闭时间：使用HTTP1.1时，一个TCP连接在请求完成时立刻被关闭。但对于HTTP/2，TCP连接能存活相当成地一段时间。
头部压缩：HTTP/1.1是没有头部压缩的，但HTTP/2引入头部压缩进一步的减少了延时。

HTTP/2如何兼容HTT/1?

HTTP/2客户端在不确定对方服务器是否支持HTTP/2时，会用HTTP/1协议向服务器发送请求时带上Upgrade: HTTP/2.0这个头部。如果对方服务器支持HTTP/2，就会回复HTTP1.1 101，表示切换协议(Switching Protocols status)。而对于老旧的服务器则简单地返回HTTP/1.1的状态。

HTTP/2客户端可以记下哪些服务器支持HTTP/2，这样，下次就可以直接发起HTTP/2请求，而不必再经过一个询问和回复(Upgrade Round Trip).

HTTP/2****中的多路复用是怎么回事？

HTTP/2使用多路复用，多个请求和回复全异步的通过同一个TCP连接收发。

HTTP/2是一个二进制的协议。每一个请求和回复都被分配了一个流标志(Stream ID)，而且请求和回复被切成了很多帧(Frame)，属于同一个请求或回复帧的Stream ID相同。因为有了这个Stream ID和Frame的机制，请求和回复可以在服务器和客户程序两端同时全异步的发送。因此，HTTP2没有了Head-of-line Blocking的问题。

每一个Stream还可以被赋于一个优先级，服务器可以分配更多的系统资源处理高优级的Stream。

HTTP/2还有一个传输层级别的流控。它协商了客户程序和服务器两端最多使用多少个Stream,服务器能处理的最大尺寸的Stream以及整个连接最多处理多少字节，以及数据被发送的速率。

HTTP/2中的服务器推送(Server Push)和承诺(Promise)

当服务器“感觉”到客户程序需要更多的资源时，就会给客户程序发送一个Promise Stream ，提醒客户程序需要什么资源。这些stream比一般的stream的优先级要高。

这项技术在加载网页时非常用户，因为网页的大量css和javascrpit可能通过这种方式发送。而HTTP/1的作法是把css和js都combine到一起。

服务器发送Promise Stream时提醒的资源遵守同源策略(same origin policy)

HTTP/2****中的头部压缩：

HTTP/2的头部压缩和HTTP/1.1中早有的用gzip压缩Body不一样。使用HTTP/2时，在客户程序和服务器两端，都会保存一张表，记录了收到过的头部。它们在发送HTTP时不会重复发送一样的头部，当再次发送相同的头部时，只会发送该头部对应的表的索引号。

Linux 如何知道有哪些硬件，该装哪个驱动

Wed, 23 Jul 2014 03:12:12 +0000

Linux 如何知道有哪些硬件，该装哪个驱动

公司明文不准安装虚拟机了，被查到就是死罪。于是我在自己的笔记本上安装了Debian Linux。

结果无线网卡识别不了~~

次奥~

怎么破呢？

这么破:

# lspci

该命令列出了所有PCI总线上的硬件设备，稍微看看就能看到自己的无线网卡了。

什么是0MQ或ØMQ，或ZeroMQ

Sat, 18 Jan 2014 10:39:00 +0000

ØMQ或者拼写成ZeroMQ,0MQ，是一个高性能异步消息队列库，旨在在分布式可扩展的并行程序中使用。它提供了一个消息队列，但不像面向消息的中间件，即使没有特定的消息经纪人(Message Broker)，0MQ也能正常工作。

这个库在TCP的基础上开发，但能获得比TCP更高的性能，更不用说它提供了各种安全机制和分布式易扩展的特性。

0MQ的API和传统的socket很像。OMQ中的socket描述了一个,多个终端之间的多对多的连接。0MQ还有一个消息模式的概念。基本的0MQ消息模式有：

Request-reply:

用来连接一组客户端和一组服务。这个模式是一个远程过程调用RPC，和多任务分发模式。

Publish-subscribe:

用来连接一组发行端和一组接收端。这是一个数据分发模式。

Push-Pull(Pipeline)

用扇入/扇出模式连接很多结点，通常要分好几个步骤。这是一个多任务并行分布和收集的模式。

Exclusive Pair:

用排它模式连组两个socket。这其实是一个为特殊需求准备的高级底层模式。

每一种模式定义了一个对应的网络拓扑。Request-reply模式定义了所谓的”服务总线”，publish-subscribe定义了数据分发树，push-pull定义了并行管道。这样模式都被精心设计，使他们可以在互联网上被无限扩展。

不想译了,。更多内容见wikipedia。kamuszhou@qq.com 腾讯视频广告

HTTP中的HEAD方法是什么

Wed, 08 Jan 2014 02:29:55 +0000

HTTP中的HEAD方法和GET方法是一样的，除了服务器在响应HEAD方法时不充许活加消息体(message body).服务器用来回复HEAD的响应信息中，在HTTP头部中的元信息需要跟回复GET时一样。这样，一个客户就可以通过HEAD来得到某资源的源信息，而不需要把整个资源都传输一次。

HEAD方法通常被用来测试超链接的可达，和资源是否已经更新。

HEAD方法的主要应用场景是检索资源的元信息meta infomation。用getResponseHeaders()函数可以得到HTTP的头部~

昨天解决了tcpcopy的一个小却很重要的bug.

Wed, 20 Nov 2013 02:48:59 +0000

tcpcopy的基础函数有个bug，流量比较大的时候，内核buffer满了。send系统调用发不完用户缓冲中的数据才会出现。然后加入了tcpcopy的QQ群，和作者稍稍讨论了一点时间。问了关于写论文和tc_session.c过于复杂的问题。

(wangb) 10:00:55
https://github.com//tcpcopy/pull/162
(wangb) 10:01:04
The bug arises when send system call returns with part of data transfered
and part of data still need to be sent again.
(wangb) 10:01:13
常见于压力比较大的场合
(wangb) 10:02:14
当然如果系统参数设置好的话，这样的情况不常见。这也是为啥我这边无法重现的原因所在
(wangb) 10:02:46
当然昨天在开发gryphon，貌似遇到过一次
(wangb) 10:03:06
gryphon给的压力，有时候真不是一般快和大
siu1ooooooo(16236914) 10:03:14
我在tcpcopy上作二次开发。碰到了个bug，最后追踪到了 tc_socket_send函数。
siu1ooooooo(16236914) 10:03:52
流量比较大的时候，内核buffer满了。send系统调用发不完用户缓冲中的数据才会出现。
siu1ooooooo(16236914) 10:05:21
希望能贡献更多代码的。。但是tc_session.c这个模拟tcp状态机的代码太难看懂了。
(wangb) 10:05:49
有些bug，程序员自身很难发现，往往需要依赖于用户的反馈，当然有上面的bug提出，就更好了
tc_session.c这个模拟tcp状态机，其实不仅模拟tcp状态机，而为复杂的是模拟上层应用交互
光模拟tcp状态机，是远远不够的
siu1ooooooo(16236914) 10:07:27
有个想法，把TCP的11个标准状态加入到tc_session中。可不可以做的。.
(wangb) 10:09:13
数据是死的，但测试服务器是活的。应该可以吧，但加入可能会更复杂。tc_session.c这个会进一步改进的，代码需简化和功能需独立，使其易懂
siu1ooooooo(16236914) 10:09:31
🙂
(wangb) 10:10:33
2010～2012.5月，初步探索阶段；2012.5～2014.5，为进一步探索阶段 2014.5～以后，进一步优化
因为tcpcopy刚开始，开发人员是无法知道复杂的互联网的各种应用的特性的，只有积累到一定程度，才能进一步优化。与其说是开发，不如说是探索
siu1ooooooo(16236914) 10:12:10
期待工程paper
siu1ooooooo(16236914) 10:12:43
tcpcopy稳定到了一个版本。先别加功能了。写paper吧
siu1ooooooo(16236914) 10:13:01
投中EI应该问题不大。
siu1ooooooo(16236914) 10:13:55
中了paper，贡献者会迅速增多。
wangb() 10:15:43
其实写过sigcomm论文，但被拒，说应该投USENIX ATC
wangb() 10:16:18
I don’t think that the research contribution of the paper is a good match for Sigcomm. Perhaps it would be a better match for
a more practice-oriented conference like USENIX ATC.
siu1ooooooo(16236914) 10:16:50
后来呢
wangb() 10:17:05
确实，tcpcopy是基于实践的，从实践中摸索爬行的。后来我就先不写论文了
siu1ooooooo(16236914) 10:17:22
嗯。这是个工程实践性很强的探索啊
wangb() 10:17:27
要写论文，必须要有条件
siu1ooooooo(16236914) 10:17:45
喔。
wangb() 10:18:06
从交换机或者其它设备。镜像过来，这样测试系统和在线系统就没有关联，这样的论文是能够中USENIX ATC
的
wangb() 10:19:13
tcpcopy最高端的应用，就是在交换机，利用分光镜或者其它镜像设备，利用高性能硬件，把用户的请求数据包复制给测试系统，可惜我没有这样的条件
wangb() 10:19:38
要是有这样的条件，我肯定要写论文了
siu1ooooooo(16236914) 10:19:55
呃。。没怎么看懂
siu1ooooooo(16236914) 10:21:49
是说复制的流量要非常非常大才能中论文么
siu1ooooooo(16236914) 10:21:59
而非常大的流量需求硬件支持
wangb() 10:22:02
twitter梦想的测试环境，其实完全可以用我们的tcpcopy来实现。交换机上面不是有来来往往的数据包吗？在那上面把请求数据包镜像到测试系统，测试系统搭一个跟在线类似的完整系统，这样测试系统跟在线系统承受类似的压力
wangb() 10:22:17
高端大气，才能中论文
wangb() 10:22:48
屌丝环境，写论文，还不被批啊
siu1ooooooo(16236914) 10:23:14
呃。是。。。明白了。。想起以前学校的事情，懂了。
wangb() 10:24:38
总之，tcpcopy值得你去研究，期望有更多接班人把思想传承下去，代码可以推掉重来
wangb() 10:25:10
只要tcp协议还存在，这个思想，应该是最先进的，无法再先进了
siu1ooooooo(16236914) 10:26:11
需要好多的开发时间啊。..嗯。先上班了啊。多谢wangbin….
wangb() 10:27:16
慢慢来，这方面反正国外没有人做

tcpcopy在视频广告组的二次开发

Wed, 16 Oct 2013 09:01:05 +0000

流量筛选中的 “只导入某频道的流量”功能已经实现了。

技术层面上，实际上是通过指定正则式的方法匹配HTTP请求中的GET方法中的URL来达到过滤的目的。

所以，也可以用ty，ad_type, pf, coverid, oadid, v，plugin等出现在GET方法中的参数编写正则式来过滤流量。

流量筛选中的“地域纬度筛选”暂时没有实现。

因为地域纬度的信息不是以参数形式出现在GET方法的URL中，需要通过IP地址或者cookie的中QQ号信息来判断。

还没最终决定是否实现这个功能。

tcpcopy官方版本主要的应用场景是复制实时流量。所以部署的时候至少两台机器，一台线上机，另一台测试用机。为了方便压力测试，还引入了至少三台机器的高级模式。

部署起来比较麻烦。

如果“视频CPM广告的模拟投放，以及订单效果预估“只是从磁盘中读入以往的流量，针对这种场景，可以探索tcpcopy的单机离线模式，做到方便部署和使用。

部分同学有一个误解.

“将线上的实际访问流量，复制一份保存到本地服务器，用于后续使用”

目前，tcpcopy的官方的版本没有把流量保存下来的功能，保存流量这个目前是用tcpdump的-w选项来做的。

另外，技术上，tcpdump只能在IP层和TCP层指定过滤条件，不能用业务的逻辑过滤流量。第1点提到的流量筛选工作在tcpcopy读入实时流量时，或者从tcpdump存下的文件中读入流量时，在应用层指定过滤条件。

Linux抓包技术简介

Tue, 10 Sep 2013 05:05:03 +0000

Linux抓包技术简介

Author: zausiu@gmail.com

1. 简介

大多数应用常景下，我们在IP层上用AF_INET或AF_INET6作为socket的第一个参数，SOCK_STREAM或SOCK_DGRAM作为socket的第二个参数创建最为常见的IPv4或IPv6的TCP或UDP套接字。这样的套接字满足了绝大多数网络应用常景。

本文简单介绍三种Linux平台下抓包，截获包的技术。它们提供一些更酷的功能。每种技术的水都很深，作者个人水平有限，按照自己的理解做一般的介绍。仅仅旨在起到科谱的作用。

2. RAW SOCKET

参数SOCK_RAW可以作为socket函数的第二个参数传入，这样创建的套接字称为原始套接字。设置Socket的第一个参数可以让指定原始套接字开在数据链路层上或者网络层。

下面的语句创建在数据链路层上的原始socket。

Socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));

在负载不大的情况下，读这个socket可以拿到本机收到的所有数据包。写入这个socket需要程序员负责填充各种包头的数据。

Socket(AF_INET, SOCK_RAW, xxxxx协议号)；

在IP层上创建IPv4的RAW socket，可以拿到各种经由IPv4的数据包，比如ICMP包，IGMP包等。Steven的第三版第28.4节，第二段：“系统收到的UDP包和TCP包不会传给原始套接字”。但读tcpcopy的源代码时，确实用了原始套接字在网络层读UDP和TCP包。难道书上写的过时了。见代码，来自tcpcopy：

#if (TCPCOPY_UDP)

fd = socket(AF_INET, SOCK_RAW, IPPROTO_UDP);

#else

fd = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);

#endif

另外，在IP层上创建的原始套接字有一个选项：IP_HDRINCL，它被开启时，则内核帮助填充IP包头。Linux默认没有开启这个选项。

3. NF_Queue

NF_Queue是用户空间的一个库，需要内核模块NETFILTER_NETLINK_QUEUE的支持。官方网址：http://www.netfilter.org。通过这个库可以在数据包被发往用户空间处理前截获数据包，或者在数据包被发往网卡前截获数据库。截获后，可以修改数据包的内容，并决定是否丢充这个数据库。

NF_Queue可以用来编写防火墙等安全软件。

Tcpcopy使用NF_Queue丢弃测试中的程序回复给真实客户程序的数据包，使测试中程序回复的报文不影响真实客户程序。

另一个提供类似功能的库是IP_Queue，它已经被废弃。NF_Queue可以完全取代IP_Queue。我们用的tlinux，内核中built-in了NF_Queue模块。

4. libpcap

大名鼎鼎的Libpcap是一个古老的可以工作在所有Unix-like平台上的抓包库，比linux年纪更大。Tcpdump的广泛使用让libpcap成为事实上的行业标准。它可以很方便的编写抓取数据链路层上的数据包，并可以设置过滤条件在内核级别只复制关心的数据包，而数据链路层上的原始套接字会尽最大努力复制所有的包，所以libpcap的工作效率高。而且，pcap使用方便。下面是一个很简单的使用pcap抓到发往80端口的tcp包并打印源IP，目的IP，和目的端口号的程序。非常短，很容易看，起到介绍libpcap的作用。

int main(int argc, char *argv[])

{

pcap_t *handle; // pcap用的句柄，和其它各种句柄一样。

char *dev; // 网络接口名，如eth0, eth1, tunl0 之类

char errbuf[PCAP_ERRBUF_SIZE]; // 存描述出错原因的缓冲

struct bpf_program fp; // pcap用来过滤数据包用

char filter_exp[] = "tcp and dst port 80"; // 过滤字符串，和tcpdump的写法一样

struct pcap_pkthdr header; // pcap自己用的包头

const u_char *packet; // pcap包头后的数据，即抓到的数据

int len_of_iphdr; // ip头的长度

struct in_addr src_ip; // 源IP地址

struct in_addr dst_ip; // 目的IP

const u_char *ip_hdr_addr; // IP头的首地址

const u_char *tcp_hdr_addr; // tcp头的首地址

struct tcphdr *tcp_hdr; // tcp头结构体

u_short dst_port; // 目的端口

// 如果命令行指定网卡名

if (argv[1])

dev = argv[1]; //就用指定的网卡

else

dev = "eth0"; //否则用eth0

}

// 用pcap打开这个网卡

handle = pcap_open_live(dev, BUFSIZ, 0, 1000, errbuf);

if (handle == NULL) { // 打开网卡出错

fprintf(stderr, "Couldn't open device %s: %s\n", dev, errbuf);

return(2);

}

// 编译过滤文件

if (pcap_compile(handle, &fp, filter_exp, 0, net) == -1) {

fprintf(stderr, "Couldn't parse filter %s: %s\n", filter_exp, pcap_geterr(handle));

return(2);

}

// 设置过滤条件

if (pcap_setfilter(handle, &fp) == -1) {

fprintf(stderr, "Couldn't install filter %s: %s\n", filter_exp, pcap_geterr(handle));

return(2);

}

// 抓包

packet = pcap_next(handle, &header);

// 至此packet指向抓到的一个目标端口号是80的数据链路层的包

// 它的包结构是 14字节以太网包头 + 可变IPv4包头 + TCP包头

ip_hdr_addr = (u_char*)(packet + sizeof(struct ethernet_hdr));

src_ip.s_addr = ((struct iphdr*)ip_hdr_addr)->saddr;

dst_ip.s_addr = ((struct iphdr*)ip_hdr_addr)->daddr;

len_of_iphdr = ((struct iphdr*)ip_hdr_addr)->ihl * 4;

tcp_hdr_addr = ip_hdr_addr + len_of_iphdr;

tcp_hdr = (struct tcphdr*)tcp_hdr_addr;

dst_port = tcp_hdr->dest;

// 经过上面的各种指针偏移，下面打印源IP和目标IP和目标端口.

printf("src addr %s\n", inet_ntoa(src_ip));

printf("dst addr %s\n", inet_ntoa(dst_ip));

printf("dst_port %d\n", ntohs(dst_port));

/* And close the session */

pcap_close(handle);

return(0);

}

5. 总结

本文只是一个非常简单的介绍。如需要进阶学习，Stevens的网络编译有更详细地关于Raw Socket的内容，研究NF_Queue技术则需要读源代码和收集散在社区各个角落的资料了，而讲libpcap有两篇很好的文章：

"Programming with Libpcap – Sniffing the network from our own application "用Libpcap编程，在我们的程序中嗅探网络。非常漂亮的pdf文档。

http://recursos.aldabaknocking.com/libpcapHakin9LuisMartinGarcia.pdf

The Sniffer’s Guide to Raw Traffic 嗅探器教程。斯坦福大学的Geek于大概2001年写的。

http://yuba.stanford.edu/~casado/pcap/section1.html

epoll学习报告

Wed, 07 Aug 2013 12:01:31 +0000

epoll学习报告

kamuszhou 周霄 Jul/26/2013

这几天通读了内核中对epoll I/O模型的实现代码，结合网络上很多介绍epoll的文章，对epoll的实现原理已经很熟悉，下面谈谈我的几点体会。下文引用的内核代码来自3.9.6版本的内核，见URL：http://lxr.oss.org.cn/source/fs/eventpoll.c。

一. epoll的边沿触发(ET)的效率高于电平(LT)触发的效率

首先简单介绍一个背景：epoll实现中，把已经有事件发生的文件用一个双链表链接一起，这个双链表是在struct eventpoll结构中的rdllist域。用户空间调用epoll_wait()，陷入内核后就会立即检查这个双链表，如果链表中非空，就通过文件的poll()函数询问文件有无事件发生。如果有事件发生且是用户关心的，就会向用户空间报告，否则就睡眠。

epoll的实现代码中实际上只有两行代码与触发方式有关，如下图所示。

上图所示的代码运行的上下文情况是：用户加入到epoll中的某个文件，只要支持poll()，(可以是socket，FIFO，裸设备，whatever)有关心的事件到达(或可读，或可写，或报错)，内核空间已经把发生的事件复制到了用户空间，但还没有从内核态返回用户空间。在返回用户空间之前代码检查用被epoll监视的这个文件是否是ET触发，如果不是(那就是LT),就把监视的文件重新放回就绪队列，下次epoll_wait()调用的时候会立即重新检查这个文件有否有事件到达。如果这文件的确有事件发生，则epoll_wait()报告给调用者。如果没有，而且其它被监视的文件也没有事件发生，则调用epoll_wait()的task就让出处理器，开始睡觉(TASK_INTERRUPTIBLE)。这段逻辑在static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events, int maxevents, long timeout)中，第1494行。

如果监听的文件开启的是边沿触发(默认)，则不会执行上图中的list_add_tail()逻辑。这就是边沿触发只会向用户报告一次，直到下一个关心事件发生才向用户空间报告的原因。

那么为什么ET触发效率高于LT触发呢？看一个例子，假如客户端监视一个TCP的Socket，服务端这时发来1M数据，客户端的主机网卡驱动缓存足够大，一次性接收到了所有1M数据。下面看两段客户端的接收伪代码(没有写read调用返回时socket被关闭的情况；另socket描述符fd被设为非阻塞)。

上图的代码使用了LT触发，这段代码依赖epoll_wait()通知还有数据可供读取。所以共调用了1024次epoll_wait()，1024次read()，共2048次系统调用才读完1M数据。

上图使用ET触发，epoll_wait()只报告一次，然后代码循环调用1024次read()读完数据，直到第1025次read()返回-1，出错码为EAGAIN(EAGAIN等于EWOULDBLOCK)，于是代码知道已经接收完数据。一共只使用了1026次系统调用就读完了数据。

总结：即使使用电平触发也不要依赖epoll_wait()通知调用者到达事件，需要循环调用IO函数直到被通知EAGAIN，这样就把epoll_wait()的调用次数降到最低，仅管有可能在下次epoll_wait()时会有可能浪费一次文件的poll()调用，但这个很小的开销可以忽略。

二. 为什么epoll支持嵌套调用

读epoll的实现代码发现，一个epoll的文件描述符epfd可以嵌套的加入另一个epoll。这样有什么用呢？

epoll的实现中“平等的”对待每个被监视的文件，它们维护在一棵红黑树之中，假如有十万个文件被监视，那么查找某个文件时就要在这十万个文件中查找。即使红黑树的查找效率是log(n)，文件非常大时也是比较消耗时间的。

那么假如有这样一种情况，如果这十万个文件中只有1000个是活跃的，或者说这1000个文件优先级最高。那么则有一种优化方案是，创建两个epoll，第一个epoll（epfd0）监控100000 – 1000 个文件，第二个epoll (epfd1) 监控1000个高优先级文件以及epfd0。这样的好处是，大多数情况下epoll实现只在1001个元素的红黑树中查找，自然效率提高了。

总结：epoll的嵌套调用给开发者提供了一个在高并发环境下的优化方案。

三. epoll的效率一定比select/poll高吗。

答案是不一定。

Select的缺点大致有：

1. 内核中写死了最多只能监视1024个文件.

2. 每次调用select都要把关心的文件描述符和关心的文件件从一个用户空间的长长的数组拷贝到内核空间.

3. select若使得caller进程进入睡眠后，某个文件有事件到达此进程被唤醒，那么所有被监视的文件全部会被调用poll()询问“你有没有事件到达”，这是一个线性的时间复杂度。

epoll针对select的三个缺点的改进：

1. 监视的文件数由取决于系统中有多少低端内存(x86_64架构中的所有内存都是低端内存)。3.9.6版本的内核实现中，对于每个登录用户，最多使用系统中低端内存的4%用来创建监视用的数据结构。见第1951行代码。max_user_watches = (((si.totalram – si.totalhigh) / 25) << PAGE_SHIFT) / EP_ITEM_COST;

2. 用户只需要把关心的文件对应的数据结构在调用epoll_wait()前用epoll_ctl()一次性传入内存，以后调用epoll_wait()时不需要像select一样拷贝大量数据。

3. 当调用epoll_wait()的caller进程睡眠时，突然有事件到达，caller进程被唤醒，epoll_wait()返回用户空间，内核并不遍历没有监视的文件，而只报告在一个即短时间内发生的事件。下面更详细的描述这个场景，以监视tcp socket举例，大致是：某进程调用epoll_wait()，此时没有任何它关心的事件发生，于是caller进程进入睡眠。处理器调度了其它进程。数据到达时，当前进程被硬件中断，网卡驱动收到数据包，数据包在中断处理函数中被拷入内核，中断处理函数设置中断下半部(Half Bottom)。下半部被处理器调度，调用epoll实现代码注册的回调函数ep_poll_callback()。ep_poll_callback()函数唤醒之前的caller进程，caller进程重新获得CPU，从epoll实现的ep_poll()函数中恢复执行，在3.9.6内核中的第1564行： if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS))。然后，内核代码开始收集已经就绪的文件和发生的事件，发回用户空间。只有从第一次回调函数ep_poll_callback()被驱动的代码调用（caller进程还在睡眠时执行的ep_poll_callback()算第一次）到epoll实现代码走到第586行关闭中断关闭中断的代码 spin_lock_irqsave(&ep->lock, flags);之间发生的事件才会被收集。

对于第3点，这是epoll的优点，但在某种情况下却会是epoll的缺点。网上很多比较poll, select, epoll性能的文章，没来得及仔细看，我个人认为结论是可靠的。结论引入了一个概念active-to-total ratio，设所有被监控的文件数是n，活跃的文件数是m，active-to-total比则是m/n，如果这个比非常高，比如大于0.7，则poll或select的性能要高过epoll，反之则epoll胜出。

对比前文对select的第3个缺点和epoll的改进点3的叙述可以解释这个原因。因为select在返回用户空间前又轮循了所有关心的文件，而这些文件又大部分是有事件发生的，所以select所做的工作并没有浪费，但epoll只收集了一小段时间中发生的事件，于是select较之epoll减少了用户空间和内核空间的频繁切换，从而让select的性能反超epoll。

那么如何改进呢？明白了以上的原因，那么就可以对epoll做出改进，理论上对于active-to-total比较高的应用环境下，可以在epoll的实现中加入与select做法相同逻辑，即退出前询问所有的监控文件，反正active-to-total比很高。或者更好的方案，用一个链表链接活跃的文件，在epoll返回用户空间前遍历这个链表，争取每一个epoll_wait()调用返回尽可能多的事件。

附：epoll的主要数据结构简介.

epoll接口的主要数据结构有struct eventpoll，struct epitem，struct eppoll_entry。

在讲述这三个数据结构前先提一下struct file。Unix设计初期希望它的设计遵从“一切皆文件”的理念。在Linux内核中，每个抽象的文件对应一个内核struct file结构体。Struct file结构体中有一个void *private_data域。不同的文件类型会在private_data域中存放特定的信息。Struct file中另一个域f_op是函数指针的列表，它记录了对应该文件的操作。所有epoll文件的f_op都指向static const struct file_operations eventpoll_fops，因此可以代码判断一个文件是不是epoll如下：

static inline int is_file_epoll(struct file *f)

{

return f->f_op == &eventpoll_fops;

}

每次成功调用epoll_create时就会创建一个struct file的结构体，和一个struct eventpoll。Struct file中的private_data指向struct eventpoll。eventpoll维护了这个epoll的重要信息。其中比较重要的几个字段有：一个循环列表struct list_head rdllist链接了该epll中已经可以读写或者有出错的文件描述符。一个红黑树的根结点struct rb_root rbr，eventpoll维护了一棵红黑树，树中的结点是struct epitem。

每个被加入到epoll中被关注的文件描述符都对应一个struct epitem结构体。所有加入到同一个epoll中对应的所有epitem都挂在红黑树上。该红黑树的根结构保存在struct eventpoll中。epitem中记录了对应的文件的文件描述符和文件指针。

struct eppoll_entry是用来挂接到设备文件中的结构体。设备驱动在得知自己可读或可写或有错误时通过这个结构体通知有事件发生。每个eppoll_entry都指向一个epitem，一个epitem可能对应多个eppoll_entry。eppoll_entry中的域wait_queue_t wait就是被用来挂接到设备文件中的等待队列。设备文件通过wait可以拿到eppoll_entry，再通过eppoll_entry拿到epitem，再拿到eventpoll。

Linux如何设置IPv6地址

Sun, 01 Jul 2012 08:46:32 +0000

IPv6最终全面取待IPv6是不可逆的潮流。本文则讲一下在Linux下如何配置IPv6地址。当然本文假设你使用静态IP（不必是公共IPv6地址或公共IPv4地址，可以是私有IPv4地址）。本文不适用使用DHCP获取地址的情况。

首先，你要确保你使用的Linux的内核已经支持IPv6。当前比较新的Linux都已经内建IPv6了。

用root用户登录，运行：

# lsmod | grep ipv6

看看系统有没有已经加载了IPv6模块。如果没有，尝试用以下命令加载：

# /sbin/modprobe ipv6

第二，你需要有你的静态IP地址。

**IPv4地址如何转成IPv6地址呢？**如果你的IP是一个IPv4地址，那么可以换算得到IPv6的地址形式。比较简单的作法可以去到 http://grox.net/utils/ipv6.php。在左边的下拉列表中选择: IPv4 to 6to4 Address，在右边的编辑框中填上你的IPv4地址。点击: Calculate 则得到了你的IPv4地址的IPv6转化格式。

配置IPv6地址

一般的Linux发行版用 /etc/network/interfaces 文件配置网卡。如果没有这个文件，那么请注意 /etc/network 目录下其它文件或者目录。

假如要配置的Linux的静态IPv4地址是 192.168.1.10，这个IPv4地址转换成对应的IPv6地址则是 2002:c0a8:10a:: 。再提醒一下，上文提到过如何把IPv4地址转成IPv6地址。

网关的IPv4地址是 192.168.1.1，这个IPv4地址转成对应的IPv6的地址是:2002:c0a8:0101:: 。

那么 /etc/network/interfaces 文件应该配置成如下：

#IPV6 static configuration(我是注释)
iface eth0 inet6 static
pre-up modprobe ipv6
address 2002:c0a8:10a::
netmask 64
gateway 2002:c0a8:0101::

注意 “pre-up” 命令。这一行保证系统在启动的时候加载支持ipv6的模块。
最后重新启发动网络，如下：

# /etc/init.d/networking restart

你现在可以使用你的IPv6地址了。

测试IPv6地址：

检测路由：

# ip -6 route show

如果IPv6工作正常的话，应该会有如下的提示。

2002:c0a8:0100/64 dev eth0 proto kernel scope link src 2002:c0a8:10a

traceroute failed.Specify protocal traceroute used manually to fix it.

Wed, 20 Jun 2012 14:37:16 +0000

Today, I ran the traceroute program on a machine running FreeBSD. It failed once and again.

Traceroute complained:

traceroute: sendto: Permission denied.

So I tried to ping. Ping failed, too. I then checked out the configuration of the firewall, which actually denied the pass through of ICMP packet. So I set it to allow ICMP pacakges to pass through the firewall. Ping worked as I expected. But traceroute still failed.

Unix网络编程第13章 Daemon Processes and the inetd Superserver 笔记

Mon, 26 Dec 2011 16:59:47 +0000

# The syslogd daemon runs in an infinite loop that calls select, waiting for any one of its three descriptors to be readable. it reads the log message and does what the configuration file says to do with that message. If the daemon receives the SIGHUP signal, it rereads its configuration file. So, what are the three descriptors that the select system call is waiting for ? 1. A unix domain socket is created and bound to the pathname /var/run/log (/dev/log on some systems). 2. A udp socket is created and bound to port 514(the syslog service). 3. The pathname /devklog is opened. Any error messages from within the kernel appears as input on this device. Newer implementation disable the creation of the UDP socket, unless specified by the administrator, as allowing anyone to send UDP datagrams to this port opens the system up to denial-of-service attacks, where some one could fill up the filesystem.

Unix网络编程第十二章 IPv4 and IPv6 Interoperability

Mon, 26 Dec 2011 13:28:35 +0000

# Ethernet header contains a type fileld of 0x0800, which identifies the frame as an IPv4 frame.

# 若支持dual-stack的server既有IPv4又有IPv6。则IP层让server透明地既可处理IPv4又可处理IPv6.该server需要绑定到wildcard且未设置IPV6_V6ONLY socket option.

# UNP Page359 Figure 12.5 Summary of interoperability between IPv4 and IPv6 clients and servers.

# 尽可能用IPv6, since an IPv6 client can still communicate with IPv4 servers, and vice versa.

Unix网络编程第11章 Name and Address Conversions 笔记

Mon, 26 Dec 2011 12:48:53 +0000

# gethostbyname 和 gethostbyaddr 用来在 IPv4 地址和 hostname 之间转换. getservbyport 和 getservbyname 则是与服务相关。gethostbyname出错时不设errno而是设h_errno，并有hstrerror()函数。

# FQDN的全称是: Fully Qualified domain name. 技术上说必须以点号(period)终止.

# AAAA 被称为 “quad A” rcord, 给出了从hostname到Ipv6地址的映射。 PTR用来把IP地址到hostname.

# Entries in the DNS are known as Resource Records(RRs).

# 一个点分十进制(dotted-decimal)IPv4的地址前加 0::ffff:就是 IPv6的字符串形式。

# 与getpeername对应的函数不是gethostname而是getsockname.

# getaddrinfo函数的host参数指定为dotted-decimal IPv4或 IPv6 hex string,会使得只有IPv4或IPv6的addrinfo返回。

# 不给UDP套接字设置SO_REUSEADDR选项。We do not set the SO_REUSEADDR socket option for the UDP socket because this socket option can allow multiple sockets to bind the same UDP port on hosts that support multicasting. Since there is nothing like TCP’s TIME_WAIT state for a UDP socket, there is no need to set this socket option when the server is started.

Unix 网络编程第十章 SCTP Client/Server Example

Mon, 19 Dec 2011 11:25:57 +0000

这一章的内容还是满少的。也就是给出一个SCTP的简单例子。所以也没有太多需要做笔记的。

什么是 head-of-line blocking.

Head-of-line blocking occurs when a TCP segment is lost and a subsequent TCP segment arrives out of order. That subsequent segment is held until the first TCP segment is retransmitted and arrives at the receiver.

怎么更改SCTP连接的stream的数量。

SCTP连接的streams的数量是在association的握手之前协商好的。对于FreeBSD的KAME实现，SCTP的outbound streams默认为10。这个值可以用setsocket函数更改。与SCTP_INITMSG scoket option相关，设置struct sctp_initmsg结构体。

也可以用sendmsg函数发送ancillary数据来到达同样的目标。但发送ancillary data只对one-to-many形式的sctp socket有效。

怎么结束一个SCTP连接。

可以设置sctp_sndrcvinfo结构的sinfo_flags值的MSG_EOF flag来关闭一个sctp连接gracefully. This flag forces an association to shut down after the message being sent is acknowledged.

还可以给sinfo_flags设置 MSG_ABORT。这样就会立即发送一个ABORT给peer端。任何还没来得及发送出的数据会被丢弃。

Unix网络编程.第九章笔记

Sat, 17 Dec 2011 08:58:14 +0000

# TCP 协议在1981年标准化，而SCTP协议则是在2000年由IETF组织标准化。IETF： Internet Engineering Task Force 互联网工程任务组成立于1985年。

# SCTP支持两种类型的socket. one to one(为了方便现有的tcp程序迁移到sctp) 和 one to many.

# sctp的sctp_bindx可以绑定多个地址，并且可以动态增删。但动态增删不影响已经存在的associations.不过各个unix分支不一定支持这个特性。

# sctp_getpaddrs和sctp_getladdrs分别是getpeername和gethostname的sctp版。They are designed with the concept of a multihoming aware transport protocol.

# sctp传输的报文是有边界的。sctp在传输层支持传输超大的message.

Unix网络编程.第七章笔记

Thu, 15 Dec 2011 06:33:56 +0000

1. 有一个 Generic Socket Option：SO_BROADCAST 用来开启是否充许广播。2. 仅有TCP支持SO_DEBUG。Kernel把详细的发送包的接收包信息存在一个环路buffer里。可以用trpt查看它。3. SO_ERROR套接字选项只能被取得，不能被设置。如果进程阻塞在select调用里，不论是读还是写，select都会返回conditions set。如果进程使用signal-driven I/O，则SIGIO信号会被发到这个进程或者它所在的进程组。进程用getsockopt得到so_error后，so_error就会被重置为0.如果so_error不为，此时调用 read 或者 write 就会立即返回-1，errno被置为so_error的值。

4. SO_KEEPALIVE在一个tcp连接没有任何收发达两个小时时会发一个prob给对方。两个钟喔。好长的时间啊！！！Richard Stevens认为SO_KEEPALIVE应该改叫 make-dead。大多Unix的kernel把这个两小时时长存为一个系统级的变量。这意味着如果你用某种方法改变了这个时长，会影响这个操作系统的所有socket.Richard Stevens认为想把这个时长改短的想法是错误理解了这个选项的意义。

5. SO_LINGER仅仅适用于面向连接的socket，比如TCP和SCTP，因此不适用UDP。

Struct linger{

int l_onofff;

int l_linger;

};

L_onoff为零是，close的behavior就是默认情况：close立即返回，kernel继续发送缓冲区内未发送的数据。当l_onoff不为零，而l_linger为，TCP协议则会立即终止连接，发送RST给peer端，这样做避免了TCP的TIME_WAIT状态，这样的坏处是: leaves open the possibility of another incarnation of this connection being created within 2MSL seconds and having old duplicate segments from the just-terminated connection being incorrectly delivered to the new incarnation.对于SCTP, 也会发送一个ABORT chunk给peer.第三种情况：如果l_onoff为真，l_linger不为0.则close不会立即返回，会最多等待指定的时长，在这段时间里kernel发送缓冲区内的数据给peer。如果在这段时间内发送完则close返回0.如果没有发送完毕，close就会返回EWOULDBLOCK，send buffer里的数据会被丢弃。

6. MSL: maximum segment lifetime.

7. 因此close默认情况下立即返回，即使用SO_LINGER设置等待时间也在理论上存在close先于发送缓冲区的数据被peer端acknowleded的情况。因此一个更好的解决方案是用shutdown系统调用with a second argument of SHUT_WR。在调用shutdown后，用read调用直到read返回，即收到peer端的FIN。

8. UDP没有congestion control，如果发得太快，不仅仅peer端来不及收。A fast sender can overwhelm its own network interface, causing datagrams to be discarded by the sender itself.

9. 因为tcp在三次握手阶段的SYN segment里交换窗口大小(windows scale)。所以tcp的接收缓冲大小必须在shank hands之前就设置好。Connected socket从listening socket继承这个选项。

10. TCP的套接字缓冲区大小至少需要是4倍MSS的大小。这里指的套接字缓冲，如果是针对单向的传输，比如单向传一个文件，指的是发送方的发送缓冲和接收方的接收缓冲。如果是双向的传输，则指的是双方的接收和发送缓冲。为什么tcp套接字的缓冲区需要至少是4倍MSS的大小呢？这是因为tcp的快恢复(fast recovery)算法。快恢复算法定义：如果接收端连续收到三个同样的ACK，就认为有packet丢失了。而接收端在segment丢失后，每收到新的segment就不停地重发一个重复的ack给sender。如果窗口大小小于4个segments,就不会有三个重复的ACK,所以快恢复算法就没办法工作了。

11. What is bandwidth-delay product.

A: The capacity of the pipe is called the bandwidth-delay product and we calculate this by multiplying the bandwidth(in bits/sec) times the RTT(in seconds), converting the result from bits to bytes. 即网速乘上RTT.

12. UDP没有send buffer，但有一个send buffer size.只要socket的buffer size大于LO_WATER，就永远是可写的。

13. SO_REUSEADDR有四种用途。好难写。见Unix Network Programming Section 7.5 影印版第211页啦。

14. It's Ok for the MSS to be different in each direction.

15. Nagle算法是为了减少small package的数量.The algorithm states that if a given connection has outstanding data, then no small packets will be sent on the connection in response to a user write operation until the existing data is acknowledged. Small package 指的是任何比MSS小的package.

16. Delayed ACK algorithm: This algorithm causes TCP to not send an ACK immediately when it receives data; instead, TCP will wait some small amount of time (typically 50-200ms)and only then send the ACK.

17. SCTP有一个SCTP_AUTOCLOSE套接字选项。This option allows us to fetch or set the autoclose time for an SCTP endpoint. The autoclose time is the number of seconds an SCTP association will remain open when idle.即SCTP association能够保持空闲状态的最长时间。超时就会被关闭。

Unix网络编程.第五，六章笔记.

Sat, 10 Dec 2011 13:56:00 +0000

# Unix世界里经常看到的 pst 是 pseudo terminal 的意思啊。

# ps -t pts/6 -o pid,ppid,tty,stat,args,wchan

ps 命令的进程状态。 S表示进程在睡眠，I表示进程在等待输入，O表示进程在等待输出。当进程在S状态时，wlan指示了更详细的状态信息。

# SIGSTOP 和 SIGKILL 两个posix信号不可以被caught.

# 缺省情况下，Unix的信号是不排在队列中的。这意味着多个相同signal到达的时候如果没有来得及处理，就只会记下一个signal.如果需要稳定的信号支持，就要使用RealTime Posix接口。

# init 进程的PID是 1.

# 可以用sigprocmask函数block和unblock信号。This let us protect a critical region of code by preventing certain signals from being caught while that region of code is executing.

# 对于 Unix System V 和 Unix98, the child of a process does not become a zombie if the process sets the disposition of SIGCHLD to SIG_IGN. unfortunately, tis works only under System V & Unix98. Posix明确指票这个行为是未定义的。The portable way to handle zombies is to catch SIGCHILD & call wait or waitpid.

fsockopen真好用,PHP的高级别网络函数！

Mon, 01 Nov 2010 16:42:36 +0000

今天用Burp工具分析了一个网站的大致功能后打算写程序把该网站我感兴趣的内容全抓下来。
一开始用java写了一小段，但哥对Java不熟悉哇，而且哥觉得Java的那么多流的类，如果仅仅操作文本文件，就显得封装的太厚了。又想，用C/C++写。虽然用C/C++写的最多代码，但事实上C/C++的字符串操作一想起来就嫌烦，而且正则式也烂得可以，数组不支持用字符串索引也真够麻烦，虽然可用C++的std::map容器。最后决定用PHP写…PHP真是太好用了~~~犹赞超强大的正则式，同perl的正则式有得一拼啊。如果换用标准C字符串函数和GNU的一个超难用的C正则式库，那要写死人啊~~~

最开始的思维定势就是要先开一个socket(N多参数要填入), 省略bind(操作系统自已选一个本地端口绑定)，第二步 connect 到主机，第三步往 socket 里写东西… 虽然只几个简单函数，但要填的几个参数也真够难记的。嘿，偶像发现事实上PHP提供了high-level的socket函数 fsockopen()。哇，太方便了。

fsockopen()
returns a file pointer which may be used together with the other file functions (such as fgets(), fgetss(), fwrite(), fclose(), and feof())
fsocketopen返回一个文件指针，然后就可以用常用的文件函数操作它啦！！！和操作文本一件一样~~~ 比 Java 的 java.io.socket 类还要方便~~虽然java也抽象的不错，但我就是嫌流对象封装太厚了。人生苦短，何必自找麻烦呢。
用完以后用 fclose 把它fsockopen返回的文件指针关掉！

看个例程:

$fp = fsockopen(“udp://127.0.0.1”, 13, $errno, $errstr); if (!$fp) { echo “ERROR: $errno – $errstr \n”; } else { fwrite($fp, “\n”); echo fread($fp, 26); fclose($fp); } ?>

上面的例程从本机的UDP时间服务器里读取当时的时间和日期。如果你本机开了标准的时间服务的话~~~

tcpdump基础教程

Sun, 31 Oct 2010 05:34:49 +0000

英文原文出自： A tcpdump Tutorial and Primer
翻译: ykyi.net

Tcpdump是信息安全专业人士最重要的一个网络分析工具。对这个工具有一个深入的理解对于每一个喜欢透彻理解tcp/ip协议栈的人来话都是必须的。但很多人选择一个更高级别的工级，比如Ethereal Wireshark，但是我认为这是一个错误！

不应该机械的反复记忆概念而应该做到真正的理解，因为对tcp/ip协议簇保持清醒的认知非常的重要。如果对该协议簇能够完全精通，那你调试网络的能力则能比同行们高出几个档次。但是，要学精神tcp/ip协议簇，只有不够的实践剖析它们才能做到。

当你使用某种工具来显示网络中的原始流量信息时，人类，而不是机器，就要承担起分析这些流量的重任了。用这种方法就可以不断地加深对tcp/ip的理解。并且，用这种学习方法的时候，我在任何可能的情况下都强烈主张使用tcpdump而不是其它工具。

选项
下面将列出一些用例子的选项，这样可以在你使用这个工具时对你有很大的帮助。这些选项很容易淡忘或与其它类型的滤镜(Filter,笔者认为这里的滤镜实际上指的是其它网络工具)混淆。比如, ethereal。所以，希望这篇文章可以作为一个参考文档，我就是这样使用它的。

首先，我要先介绍几个我认为很方便的tcpdump的选项。第一个是 -n, 这样的话域名就不会被解析了，而是用数字IP的形式显示地址(译者注: 同netstat的-n是一样的喔)。第二个是 -X, 这样就会同时把包的内容以ASCII码和十六制的形式显示。最后一个是 -S, 它个选项会显示绝对序号而不是相对序号。因为当包被隐藏起来的话，你也不会看到奇怪的序号。请谨记，tcpdump较之其它工具的优势之一就是可以与包(packets)手工交互。

值得注意的是，tcpdump默认只会从packet中取出前96个字节。如果你想要多一些的话，那就需要需要把 -s xxxx 加上。这里的xxxx是你确切想要抓取的总字节数。如果我使用这个选项的话，我通常会把这个数字设定为1514而得到所有的数据。下面是一个简短的列表列出我经常使用的选项。

-i any: 监听所有的介面。这样你就知道是不是有流量产生。
-n: 不要解决主机名，以IP数字形式显示主机。
-nn: 不要解析主机名或端口名字。

-A: 以ASCII字符显示包的数据。
-X: 同时以十六进制和ASCII字符显示包的数据。
-XX: 同-X,但也会显示 Ethernet头部。
-v, -vv, -vvv: 详细，更详细，再详细些！冗余输出得到的包信息。
-c: 抓取 x 个包后就停下。
-S: 打印绝对序号。
-e: 同时得到Ethernet头部。
-q: 显示少一点协议信息。
-E: 用提供的密钥解密 IPSEC 流量。
-s: 设置显示前多少个字节的包内容（snaplength）。

tcpdump 4.0的snaplength的长度从68字节改成了96字节，这样你就可以看到多些内容了。但仍然看不到所有的内容，指定 -s 1514 得到包的所有内容。

http://ykyi.net
一些基本的应用
根据我要查看的不同流量，我使用不同的选项组合，如下:

1.Basic communication // see the basics without many options
tcpdump -nS

Burp套件教程(Burp Suite)

Thu, 28 Oct 2010 17:01:40 +0000

原文来自http://portswigger.net/burp/
ykyi.net 翻译

使用Burp套件(Burp Suite)
当启动Burp Suite以后，Burp的代理服务器就在本地的loopback介面上的8080端口上开始运行啦！通过设定浏览器使用这个Burp代理服务器，所有的WEB流量就可以被截获，窥视，修改。默认设置下，对非媒体资源(non-media)的请求将被截获而且显示出来(默认的设置可以在Burp Proxy的OPTION选项里修改）。所有的穿过Burp代理服务器的WEB流量将被自动分析并添加到站点地图里，这样就可以知道访问过的网站的内容和功能了。对于Burp的收费Professional版，默认情况下，所有的请求还会自动被Burp Scanner分析从而确定易受攻击的部分。

在你就要刻苦大干一场之前，你需要完美地定义出你的工作的Target Scope(Burp的术语名词，不译出)。最简单的办法就是先浏览目标网站，然后定位相关主机和目录，再使用context菜单项把URL们添加到Target Scope里。中央范围配置(Central Scope Configuration)可以用来配置各个Burp工具。

当你浏览目录WEB网站或程序的时候，你就能对截获的请求和响应进行手工编辑，或者你也可以完全关闭拦截功能。在拦截功能被关闭的情况下，每一条请求和响应仍然被记在历史记录里，所有的WEB内容也会被添加到站点地图里。

除了可以用代理修改拦截下面的讯息，你也可以把迅息发送到其它Burp工具。这样就可以完成各种各样的不同的功能，比如：

》你可以通过把请求发给Repeater来手动调节对WEB程序的测试，也可以不断地重发每个请求。
》对于Professional版，可以把请求发给Scanner，就可以完成主动和被动漏洞扫描。
》你可以把请求发给Intruder，就可以发起一个用户自定义的自动测试来确定一些常见的漏洞。
》如果你发现响应中有会话令牌或者其它本应该是不可预测的ID号，你就可以把这个响应发给Sequencer来测试这个令牌的随机性。
》可以把请求或响应中被模糊化处理的数据发给Decoder来尝试自动解析出明文。
》对于Professional版，你可以使用各种Engagement工具来提高你的工作效率。
对于代理的历史记录，站点地图中的主机·目录·文件以及Burp工具的任何显示请求和响应的地方你都可以执行以上任何操作。

中央日志功能(central logging function)记录下来每个Burp工具的所有的响应和请求。每个Burp工具都可以在单独的窗口中运行也可以在TAB WINDOW下运行。每个工具和整个套件的配置可以被保存下来重复使用。对于Professional版，你还可以保存每个工具的状态，这样你就可以随心所欲的重新载入之前保存的状态。

Network on kamuszhou's blog

netstat -s统计输出的所有字段详细解释

Linux系统级/进程级最多打开文件数,FD文件描述符数

查看系统最大可打开文件数

怎么调整系统最大可打开文件数

ulimit命令查看/调整进程级最大文件打开数

怎么修改普通用户的硬极限hard Limit

服务器端的tcp有大量TIME_WAIT怎么办

用lftp为ftp服务器做镜像

用lftp为ftp服务器做镜像

1. 前言：

2. ECC的故事：

3. 证书鉴权,通讯加密,IP 白名单

原来比特位也有大小端endinness.字节序和比特序的故事

HTTP2简单教程

Linux 如何知道有哪些硬件，该装哪个驱动

什么是0MQ或ØMQ，或ZeroMQ

HTTP中的HEAD方法是什么

昨天解决了tcpcopy的一个小却很重要的bug.

tcpcopy在视频广告组的二次开发

Linux抓包技术简介

epoll学习报告

Linux如何设置IPv6地址

配置IPv6地址

测试IPv6地址：

traceroute failed.Specify protocal traceroute used manually to fix it.

Unix网络编程 第13章 Daemon Processes and the inetd Superserver 笔记

Unix网络编程 第十二章 IPv4 and IPv6 Interoperability

Unix网络编程 第11章 Name and Address Conversions 笔记

Unix 网络编程 第十章 SCTP Client/Server Example

Unix网络编程.第九章笔记

Unix网络编程.第七章笔记

Unix网络编程.第五，六章笔记.

fsockopen真好用,PHP的高级别网络函数！

tcpdump基础教程

Burp套件教程(Burp Suite)

Unix网络编程第13章 Daemon Processes and the inetd Superserver 笔记

Unix网络编程第十二章 IPv4 and IPv6 Interoperability

Unix网络编程第11章 Name and Address Conversions 笔记

Unix 网络编程第十章 SCTP Client/Server Example