看看replace_copy_if的一个简单的例子：
std::vector<int> vec;
boost::replace_copy_if(rng, std::back_inserter(vec), pred, new_value);
对于这种写法，如果使用Range Adaptor的话，则可以写成：
std::vector<int> vec;
boost::push_back(vec, rng | boost::adaptors::replaced_if(pred, new_value));
第二种写法有什么好处呢，
1. 更高效率。因为std::back_inserter有额外的内存分配开销。
2. 更灵活。因为第二种写法可以应用更多的适配器，比如： boost::push_back(vec, rng | boost::adaptors::replaced_if(pred, new_value) | boost::adaptors::reversed);
3. 更安全。因为第二种写法没有用unbounded output iterator。
昨晚同白总和adden提到抓包的问题。因为写过相关的代码，遇到过抓包的各种各样的坑，此文分享一些相关的经验。
1. Linux cooked capture
在用tcpdump或wireshark看数据包时，有时会看到数据链路层的的包头称为Linux cooked capture。这不是一个真实的包头，当用tcpdump指定从所有网络介质 -i any 抓包时，所有抓到的包的数据链路层被换成了Linux cooked capture。在wireshark官方网站对Linux cooked capture的解释中: 这是一个在linux上被libpcap抓包库使用的“假协议”(pseudo-protocal)，当从“any”设备在抓包，或者本地的数据链路层包头无效时被使用。更多，见http://wiki.wireshark.org/SLL
2. IP over IP tunnel
wikipedia的示例图显示IP tunnel上的包的结构是：
但实战中用libpcap库从我们的线上机的IP隧道抓包时，pcap_loop或pcap_dispatch或pcap_next函数返回的数据包只有Inner IP header + IP payload，没有Outer IP headr，也没链路层的头部。多么幸运啊！
3. 混乱的RAW_SOCKET，PF_PACKET协议族
这不是工业标准定义的神秘领域，非常之混乱，谨慎进入。如果要写这方面的socket，可供参考。个人经验，用linux原生的socket抓包时，socket()的三的参数如下组合时的神奇效果.
_recv_fd = socket(AF_PACKET, SOCK_DGRAM, htons(ETH_P_IP));
从此socket中读所有的IP包，返回的IP包没有链路层包头,因为第二个参数是SOCK_DGRAM，链路层包头返回时被去掉。第三个参数指定的是IP包。奇怪的是，如果出站的IP包的目的地址不是本机，则出站的IP包不会被抓到。
_recv_fd = socket(AF_PACKET , SOCK_RAW , htons(ETH_P_IP));
和上一个socket的区别是，这个会返回链路层包头。和上一个socket一样，同样只能装到部分出站的包。
_recv_fd = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);
这行代码只可以读入站的包，抓不到出站的包。
_recv_fd = socket(AF_PACKET , SOCK_RAW , htons(ETH_P_ALL));
这行代码可以抓到所有出站，入站的包，数据链路层包头也被返回。
4. 外网进来的IP包有可能很大。
N多年前一般的路由的MTU只有1K多，意味着4K大小的IP会被切成小IP包。现在的网络环境与几年前确实大大提高。从外网入来的IP包会大过4096，当时写程序时放IP包的buffer大小为4096，觉得应该无压力，结果观察到程序崩溃，后定位到是放IP包的缓冲区溢出。后来改成8192，暂时没问题。
copyright ykyi.net
追踪点（Tracepoint）被当成断点(breakpoint)的一种，但有两个不同点需要注意：
1. 当一个追踪点在一个调试会话中被创建时，它并不种入到二进制代码中，直到用户显式地开始追踪实验。这意味着，创建/修改/删除追踪点并不影响程序，直到追踪真正开始。
2. 简单的创建一个追踪点并不是非常有价值，因为它默认不会收集任何信息。重要的是，把操作(Actions)添加到Tracepoint，这样tracepoint被触发的时候，前面自定义的Action就大有用处了。
来自CDT官网的原文：
Create Tracepoints
Tracepoints are handled as a type of breakpoint. There are two differences to note:
copyright ykyi.net
CPRP是Cost Per rating Point的缩写， CPT是cost per thousand的缩写。
举例来说，某一个电视节目的一个商业广告时间槽位(commercial time slot)的价格是$1000，这个电视节目的收视率是10%（program rating），那么CPRP就是$1000除以10，即$100。
而CPT则是广告到达某一个特定人群的花费。
copyright ykyi.net
今天操作git的时候又出错了:
error: Failed connect to github.com:8080; No route to host while accessing https://github.com/zausiu/gryphon/info/refs
fatal: HTTP request failed
之前用公司的http代理上git,
#git config -l
http.proxy=http://web-proxy.oa.com:8080
设置变量GIT_CURL_VERBOSE可以看到详细的出错情况：
#export GIT_CURL_VERBOSE=1
# git pull
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to proxy web-proxy.oa.com port 8080 (#0)
* Trying 10.14.36.100…
* 0x23d67b0 is at send pipe head!
* STATE: CONNECT => WAITCONNECT handle 0x23df5f0; (connection #0)
* No route to host
* Failed connect to github.com:8080; No route to host
* Closing connection #0
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to proxy web-proxy.oa.com port 8080 (#0)
* Trying 10.14.36.100…
* 0x23d67b0 is at send pipe head!
* STATE: CONNECT => WAITCONNECT handle 0x23df5f0; (connection #0)
* No route to host
* Failed connect to github.com:8080; No route to host
* Closing connection #0
error: Failed connect to github.com:8080; No route to host while accessing https://github.com/zausiu/gryphon/info/refs
fatal: HTTP request failed
copyright ykyi.net
测试结果介绍：
tcpcopy在编译期配置成使用NFQueue模式，用Raw Socket抓包。线上机的流量被成功复制并导向测试机。经改动的tcpd初期工作正常。
改动版的tcpd(实际上是一个echo服务器)。测试机上的tcpd把收到的报文被打印到日志文件。但日志文件到6M+大小的时候，就停止打印。目前还没有查到原因，可能是改动后的tcpd的Bug。此时，tcpdump仍然抓到大量从线上机复制来的真实流量到达测试机。tcpcopy应该是工作正常的。
tcpcopy被编译成使用libpcap抓包时不能在线上机上正常工作。tcpdump没有抓到预期从线上机复制到测试机的报文。原因是：线上机10.130.68.100上的真实流量从网络接口tunl0:0进入，从网络接口eth1发出。分析tcpd的日志发现，tcpd使用libpcap只拿到tunl0的IP，没有发现tunl0:0的IP。需要了解IP隧道，和libpcap库的相关知识，有可能解决这个问题。
编译成使用Raw Socket抓包，和Advanced模式时，tcpcopy启动失败，错误日志显示Advanced模式只能使用libpcap库抓包。因此，只有在解决libpcap正确识别tunl0:0网络接口后，才能在线上机上运行tcpcopy。
预备知识：
Tcpcopy可以编译成用libpcap抓包或者使用Raw Socket抓包。Libpcap库是tcpdump使用的抓包库，Raw Socket是操作系统内建的功能。
官方文档建议用libpcap抓包，以获得更高性能和较低丢包率。
Tcpcopy在编译期指定工作模式。tcpcopy目前有两种工作模式，一种使用IPQueue技术或者NFQueue技术。NFQueue技术是用来替代IPQueue技术的。我们目前使用的tlinux，内建了NFQueue内核模块，没有开启IPQueue模块。因为NFQueue是内建的即CONF_XXXXXX = y，而不是编译成模块，即CONF_XXXXX = m, 所以我们在环境中不需要使用modprobe 加载IPQueue或者NFQueue模块。忽略官方文档中提到的modprobe ip_queue。
测试步骤：
使用NFQueue模式：
线上机：10.130.68.100
编译tcpcopy时指定使用NFQueue。不要指定 –enable-pcap，则默认使用raw socket抓包。用pcap抓包时识别不到网络接口tunl0:0，而tunl0:0是真实流量的入口。
# ./configure –enable-nfqueue
#./make
生成的tcpcopy在 src/tcpcopy 目录下。
运行tcpcopy命令，把流量复制到测试机：
# ./tcpcopy -x 80-10.213.243.156
测试机：10.213.243.156
编译tcpcopy时同样指定–enable-nfqueue，不要指定–enable-pcap。然后运行intercept
# ./intercept
使用Advanced模式：
因为暂时未能解决用libpcap识别到网络设备tunel0:0的问题，实际上Advanced模式暂时不能工作。根据以前的使用经验，用Advanced模式时需要注意两点：
1. 在./configure时指定 –enable-advaned 和 –enable-pcap。
2. Advanced模式需要两台测试机，需要设成一条路由把复制后的真实流量导向测试机。需要更改默认路由：删掉当前的默认路由，新的默认路由从正确的网卡指向测试机2的IP。
# route del default
# route add default gw 10.213.243.156 dev eth1