Category: Network

Network 网络

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

今天工作上碰到一个问题需要知道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 采集爬虫把链接也抓走

这里面确实有两个疑似表示udp的丢包数的数据：

Udp:
    1146976531 packet receive errors
    110301286 receive buffer errors

于是，当然首先是看linux man page。结果netstat的man手册里居然没有这些字段的介绍。
跟住，问google。没想到，答案就是netstat -s的输出并没有准确的文档(pooly documented)。
这里有个贴子问了相同的问题 https://www.reddit.com/r/linux/comments/706wsa/detailed_explanation_of_all_netstat_statistics/
简单地说，回贴人告诉他，“别用netstat，而是用nstat和ip tools”“这是个不可能的任务，除非看完成吨源代码”。
blablabla …
事实上，看了google到的一些贴子后，还是大概知道了真相。

    1146976531 packet receive errors

这一句对应关于UDP的一个RFC标准的文档 中定义的字段 udpInErrors。

“The number of received UDP datagrams that could not be
delivered for reasons other than the lack of an application
at the destination port.”
udpInErrors表示操作系统收到的不能被投递的UDP包，不能投递的原因除了没有应用程序开启了对应的端口。

而这一行

    110301286 receive buffer errors

这一行对应 nstat -a -z (下文会再提到nstat)输出中的 UdpRcvbufErrors 字段。我没有找到RFC关于UdpRcvbufErrors字段的定义。
IBM官网上有个网页简单介绍了UdpRcvbufErrors： Number of UDP buffer receive errors. （UDP的缓冲收到错误的次数）。
再结合这篇文章: 为何udp会被丢弃Why do UDP packets get dropped。我非常有信心的认为 UdpRcvbufErrors 表示的是操作系统的内核tcp栈给udp socket分配的缓冲出错（缓冲满）的次数。至于网卡自己的缓冲，和操作系统的缓冲是两回事。网卡的缓冲出错不会被计入这个计数。udp经过的路由的丢包数当然只能够查看对应的路由器的统计数据了。

另外，因为netstat已经被废弃，不建议使用。而是用 nstat 和 ss 这两个新命令代替。
nstat的输出相当于netstat -s的输出。但nstat会输出比netstat -s更多的字段信息，且绝大多数字段名对应到RFC标准中用的字段名。

可任意转载本文，但需要注明出处！！！谢谢

Why do UDP packets get dropped: https://jvns.ca/blog/2016/08/24/find-out-where-youre-dropping-packets/
1: https://tools.ietf.org/html/rfc4113
2: https://www.ibm.com/support/knowledgecenter/STXNRM_3.13.4/coss.doc/deviceapi_response_2.html

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

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

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

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

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

我用ubuntu 16输出:

573738

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

# 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。
加上这么一行：

DefaultLimitNOFILE=10000

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

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

先说结论：
1. 如果该服务器要处理外网IP的入流量，那最好的办法应该是用tcp长链接改造它与后端服务器的连接。如果用中间件，比如上zeromq那更省心了。
2. 如果不想做改动，并且在应用层确认已经交互已经完成，则可以用shutdown()直接发RST结束tcp会话，而不走正常的4次挥手。查阅shutdown系统调用的文档获知如何发RST。
3. 如果该服务器不需要处理处网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时长，是为了处理两种情况：
1) 让当前这个会话的迷路包在网路中消失。这样不会干扰到新建的会话。
2) 确保主动关闭方的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服务器做镜像

用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服务器，效果和上例相反。

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"

 

字段很好理解，最重要的是public-key和secret-key字段。

下面是一段客户端的相关代码片断(使用官方的czmq库，czmq是官方维护的High-level C库封装了底层的C API接口)：

 // 创建一个DEALER类型的zmq socket
  zsock_t* dealer = zsock_new(ZMQ_DEALER);
  assert (dealer_ != NULL)

  // 假设路径~/my.cert存了客户端的证书，证书里需要既有公钥又有私钥，载入证书再应用这个证书到socket句柄上。然后就可以销毁证书句柄了
  zcert_t* my_cert = zcert_load("~/my.cert");
  assert (my_cert != NULL);
  zcert_apply(my_cert, dealer_);
  zcert_destroy(&my_cert);

  // 设置服务器的公钥
  zsock_set_curve_serverkey(dealer, "I7[{YV4[}q[9a)]b&d>bisoT]UXa/7b$Tp:6yoyq");

  // 连接在本机监听8888端口的服务器
  zsock_connect(dealer, "%s", "tcp://localhost:8888");

下面是服务端的相关代码片断：

   // 创建一个ROUTER zmq socket
   zsock_t* router_sk = zsock_new(ZMQ_ROUTER);
   assert(router_sk != NULL);

  /* CZMQ4库封装了一个actor服务器模型,详细的官方接口说明在http://api.zeromq.org/CZMQ3-0:zactor 其中zactor_new用来创建一个actor，回调函数填zauth。zauth是CZMQ定义好的一个回调函数，里面做了很多鉴权的准备工作。照抄就行。通过向actor通讯设置如何鉴权。*/
   zactor_t* auth = zactor_new(zauth, NULL);

   // 打印详细的鉴权相关日志
   zstr_send(auth, "VERBOSE");
   // 必须调用这个函数与actor同步。下同
   zsock_wait(auth);

   // 这里开启白名单，允许”127.0.0.1”和"127.0.0.2"访问本服务。如果用黑名单也类似，但第二个参数设为”DENY”
   zstr_sendx(auth, "ALLOW", "127.0.0.1", "127.0.0.2", NULL);
   zsock_wait(auth);

   /* 假设 ~/cert目录夹下面存放了客户端的证书(只有公钥) 下面的代码让只有拥有证书的客户端才能连接服务*/
   zstr_sendx(auth, "CURVE", "~/cert", NULL);
   zsock_wait(auth);

   // router_sk 这个zmq套接字是作为服务端使用的
   zsock_set_curve_server(router_sk, 1);

  // 加载服务端自己的证书，这个证书文件里需要既有公钥也有私钥
   zcert_t* my_cert = zcert_load("~/server.cert");
   assert(my_cert != NULL);
   zcert_apply(my_cert, router_sk);
   zcert_destroy(&my_cert);

   // router套接字监听8888端口
   int ret = zsock_bind(router_sk, "%s", "tcp://localhost:8888");
   assert(ret != -1);

 至此，服务端只接受来自127.0.0.1并且拥有正确证书的客户端的连接，而且通讯通道被加密。

4. Notice & Bug

a. 在实战过程中，发现一个czmq4库的bug，如果一个zmq socket作为server端并使用curve鉴权，就必须调用bind()，而不能调connect()，否则进程会崩溃。但是在zmq的世界中，server端的socket也是可以调connect的。在czmq4的官方github页面上找到有人已经报告了这个bug，可能下个版本会修复吧。

https://github.com/zeromq/czmq/issues/1470

b. czmq4实现的reactor模型不支持监控zactor对象.

c. czmq4有很多函数的参数个数是不确定的，这些函数的最后一个参数并须填NULL，否则编译期检查不到错误在运行期会崩溃。

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

我一直以为大小端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简单教程

译自：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的目标：

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

 

HTTP/2的功能：

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

 

HTTP/2解决了HTTP/1.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请求到达的顺序。
  2. 同一个域名的多个TCP连接：在使用HTTP/1.1时，需要对同一个域名起多个TCP连接来增加吞吐量。而使用HTTP/2时，对于每个域名，只充许有一个TCP连接（only one TCP connection per domain is allowed）。所有的请求和回复都通过唯一的一个TCP连接进行。
  3. TCP连接的关闭时间：使用HTTP1.1时，一个TCP连接在请求完成时立刻被关闭。但对于HTTP/2，TCP连接能存活相当成地一段时间。
  4. 头部压缩：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时不会重复发送一样的头部，当再次发送相同的头部时，只会发送该头部对应的表的索引号。

copyright ykyi.net

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

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

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

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

次奥~

怎么破呢？

这么破:

# lspci

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

05:00.0 Network Controller: Atheros Communication Inc. AR9287 Wireless Network Adaptor (PCI-Express)(rev 01)

注意前面的坐标05:00.0，再到/sys下面找对应哪个驱动：

find /sys | grep drivers.*05:00.0

/sys/bus/pci/drivers/ath9k/0000:05:00.0

其实，还有更简单的办法：

#lspci -v 

就搞定了。

用lsmod 和 dmesg | grep ath9k 可以看到网卡对应模块的一些信息.

再编辑 /etc/network/interface

auto wlan0

iface wlan0 inet dhcp

wpa-ssid Tencent-FreeWiFi

wpa-psk xxxxxx

最后： iwconfig wlan up

搞定！！！

什么是0MQ或ØMQ，或ZeroMQ

Ø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 腾讯视频广告

copyright ykyi.net

HTTP中的HEAD方法是什么

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

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

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

copyright ykyi.net