[root@localhost ~]# telnet smtp.126.com 25
Trying 202.108.5.141...
Connected to smtp.126.com (202.108.5.141).
Escape character is '^]'.
220 126.com Anti-spam GT for Coremail System (126com[071018])
ehlo ###@126.com //###代表你的126邮箱用户名
250-mail
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250 8BITMIME
auth login
334 dXNlcm5hbWU6
###                     //###代表你的126邮箱用户名的base64编码
334 UGFzc3dvcmQ6
###                    //###代表你的126邮箱密码的base64编码
235 Authentication successful
mail from:<###@126.com> //###@126.com代表你的126邮箱地址
250 Mail OK
rcpt to:<###@mail.psychcn.com> //###@mail.psychcn.com
250 Mail OK
data
354 End data with <CR><LF>.<CR><LF>
subject: How to use telnet to send mail
Content-Type: multipart/mixed; boundary=a
--a
Content-Disposition: attachment; filename="1.txt"   //附件
--a
.
250 Mail OK queued as smtp4,jdKowLB7CjgufrJIgl6YIA==.63330S2 1219657375
quit
221 Bye
Connection closed by foreign host.

蒋 莹滢 (jiangyy@cn.ibm.com), 软件工程师, IBM
殷 一鸣 (yinym@cn.ibm.com), 软件工程师, IBM

2009 年 1 月 31 日

随着互联网技术的不断发展，传统的 IPv4 地址已不能满足用户的需要。新一代的 IPv6 协议也日益被广泛的接受和使用，越来越多的软件系统都要求支持 IPv6 网络协议。然而现有网络环境对 IPv6 的支持仍然非常有限，这给软件的开发和测试都带来了一定的困难。本文将介绍如何使用 Apache 在现有的 IPv4 网络中构建模拟的 IPv6 环境。

在 Linux 平台及 IPv4 环境中构建 IPv6 测试环境

1 IPv6简介

IPv6（Internet Protocol Version 6）作为 IPv4 的升级版本，它是作为一共软件升级安装在设备和
操作系统中。为什么需要使用 IPv6，一个最直接的答案就是目前广泛应用的 IPv4 已经无法提供足够的 IP 地址来满足迅速增长的网络。IPv4 采用32位地址长度，只有大约43亿个地址，很快就将被分配完毕。而 IPv6 采用128位的地址长度，几乎可以不受限制的提供地址。当然扩大地址空间只是 IPv6 的众多优势中的重要一项，除此之外，IPv6 还能够提高网络的整体吞吐量、改善服务质量（QoS）、安全性有更好的保证、支持即插即用和移动性、更好实现多播功能等等。

从1992年 IPNG 工作组成立，经历了十几年的发展，虽然 IPv6 离达到与 IPv4 相同的水平仍有距离，但已经有越来越多的支持 IPv6 的设备投入使用，越来越多的软件系统开始支持 IPv6。现在 IPv6 已经可以提供 DNS，Web，Email，Ftp，Telnet 等基本服务。Windows，Sun，Apple 等操作系统也都已经或即将支持 IPv6 协议。IBM 也一直致力于 IPv6 的发展，早在1997年 IBM 就发布了支持 IPv6 的 AIX。如今 DB2，Lotus，Rational，Tivoli 和 WebSphere 也都在逐步支持 IPv6 的应用。

2 在 IPv4 环境中模拟 IPv6 网络

正如上节中所述，目前许多与网络应用相关的软件已经加入了对 IPv6 的支持，更有大量的软件正在处于对 IPv6 支持的开发阶段。但是就开发而言，目前许多开发环境并没有对 IPv6 提供很好的支持，尤其当所开发的应用需要经过较老的路由甚至公共网络时。如果希望通过升级网络设备来支持开发环境，将是一笔不小的花费，有时甚至是不现实的（比如短期内升级公共网络支持 IPv6）。

研究如何在现有的 IPv4 网络环境中模拟出 IPv6 环境，使得开发和测试工作能够顺利进行，显得尤为重要。下面介绍一种在 Linux 平台上通过 Apache 服务器来模拟 IPv6 的 HTTP/HTTPS 网络开发测试环境。

2.1 IPv6 网络要求及现有的网络环境

图1显示了典型的 HTTP 网络应用，如果需要对这样的网络应用提供 IPv6 的支持，开发和测试人员可能会碰到如下三种情形：

客户端和服务器运行于同一个局域网中，如图1-a

客户端和服务器运行于同一个 Intranet 中，它们之间的网络通路需要经过路由，如图1-b

客户端和服务器分别处于不同的地域，它们之间由 Internet 提供连接，如图1-c。

在这三种不同的情形下，IPv6 的网络环境要求是不同的。对于情形1，只需客户端和服务器所运行的操作系统支持 IPv6 即可通过 IPv6 协议进行通信，若需要提供 Global 地址的通信，则可以通过在局域网内的某台机器上运行一个软件 IPv6 路由来支持，因此其针对 IPv6 的开发和测试相对简单。 对于情形2，由于客户端和服务器之间经过运行于 IP 层的路由，因此要求网络通路上经过的所有路由器均支持 IPv6。 这可能是一个不小的挑战，因为很多 Intranet 环境并没有提供支持 IPv6 的路由。对于情形3，这就要求 Internet 提供 IPv6的支持，就短期看来，Internet 提供全面的 IPv6 支持还不太可能。

因此，在情形2和情形3的环境中，网络硬件支持将成为开发和测试支持 IPv6 的网络应用程序的最大障碍，在2.2节中将给出如何运用现有的 IPv4 网络来进行 IPv6 应用程序的开发和测试，同时又保证其在真实的 IPv6 环境中正常运行。

2.2 利用现有 IPv4 网络模拟 IPv6 环境

2.2.1 模拟环境构建的基本原理

图2 - 图3显示了 IPv6 模拟环境的框图，这里存在两种情形，但具体的配置是类似的。
对于开发客户端 IPv6 应用程序，其框图如图2；而对于开发服务器端 IPv6 应用程序，其框图如图3。其基本原理就是利用代理技术将原来被 IPv4 网络阻断的客户端或服务器端映射到位于同一局域网内的代理服务器上，这样“客户端”与“服务器端”就可以进行基于 IPv6 的网络通信了。 在图2中，我们需要代理服务器与客户端运行于同一局域网中，在客户端看来，此代理服务器是一个具备了 IPv6 支持能力的“服务器”，即使真正的服务器端并没有支持 IPv6 ，也可以进行客户端的开发和测试。在图3中，我们需要一台机器与服务器端运行于同一局域网中，在服务器端看来，此代理服务器是一个具备了 IPv6 支持能力的“客户端”。

下面仅以客户端的IPv6环境为例来讲述整个模拟环境的构建过程。

2.2.2 环境的建立

操作系统平台： Linux，内核需支持 IPv6，2.6以上版本最佳，

推荐使用 RedHat Enterprise Linux 5或SuSE Linux Enterprise Server 10

软件： radvd（Router ADVertisement Daemon），
这是一个运行于 Linux 平台之上的提供 IPv6 路由配置信息的软件，可以替代 IPv6 路由来进行无状态的地址自动配置。

Apache，这是目前应用最为广泛的 Web 服务器，要求版本2.0以上

openssl，运行于 Linux 平台上的提供实现 SSL v2/v3 协议的加解密工具包

2.2.3 启动 radvd

IPv6 的地址获取方式与 IPv4 有所不同。在 IPv4 中，主机 IP 地址的自动配置必须由 DHCP 服务器来支持，这被称为有状态的自动配置（StatefulAutoconfiguration）；而在 IPv6 中，除了 DHCP 的 v6版本，还引入了无状态的自动配置（ StatelessAutoconfiguration ）。这项新技术无需 DHCP 服务器支持，所有支持 IPv6 的路由器都监听各主机发送的自动配置请求包， IPv6 路由器对这类请求包的回复里面包含了一些 IPv6 地址的前缀（ prefix ）信息，主机在收到这样的包以后，可以根据自己的一些已有信息（比如 MAC 地址），生成自己的 IPv6 地址。

本文是在现有的 IPv4 网络环境中模拟 IPv6 环境，自然不存在物理的 IPv6 路由器，但是通过 Linux 平台上的 radvd 工具也可以模拟无状态自动配置，它同样可以监听局域网内各 IPv6 主机发送的自动配置请求并作出响应，这样，这些主机就可以获得各自的 IPv6 地址，并利用这些地址进行相互间的通信。而图X中的客户端正是使用这种方式与代理服务器通信的。

这里以 SLES10 平台上的 radvd-0.9-13.2 为例来说明 radvd 的配置和启动过程。

1. 从 SLES10 的安装光盘中找到 radvd-0.9-13.2.i586.rpm 进行安装

           # rpm -ivh radvd-0.9-13.2.i586.rpm
            

1. 配置运行 radvd 的主机的 IPv6 地址信息

   # ip a a 2002:9ba:b4e:6::1/64 dev ethX

   # ip r a 2002:9ba:b4e:6::/64 dev ethX

这里的 ethX 表示的是此主机监听局域网数据包的网卡设备

1. radvd 安装后其配置文件位于 /etc/radvd.conf ，在这个文件中加入配置信息

interface ethX
            {
            AdvSendAdvert on;
            MinRtrAdvInterval 5;
            MaxRtrAdvInterval 10;
            AdvDefaultPreference low;
            prefix 2002:9ba:b4e:6::/64
            {
            AdvOnLink on;
            AdvAutonomous on;
            AdvRouterAddr off;
            };
            };
            

同上，这里的 ethX 表示的是此主机监听局域网数据包的网卡设备。prefix 段表明了该局

域网配置 IPv6 地址的前缀。

1. 确保系统启动了对 IPv6 数据包的转发功能

   # sysctl -w net.ipv6.conf.all.forwarding=1

1. 启动 radvd

   # /etc/init.d/radvd start

在 radvd 启动成功后，通过 ps 命令可以看到系统中有一个 radvd 的 daemon 进程处于运行状态。若对局域网中的其他主机运行 ifconfig 命令可以看到这些主机已经自动配置了 IPv6 地址，其前缀（ prefix ）与 radvd 配置文件中的值一致。

2.2.4 配置 Apache 服务器

Apache 服务器是整个模拟 IPv6 环境的核心部分，它将监听来自 IPv6 网络连接的数据包，并将其通过 IPv4 网络转发到服务器端。这里使用了 Apache 服务器的 mod_proxy 模块，相信这一模块提供的 Forward Proxy 功能已为大家所熟知，并被广泛采用。这一模块同时还提供了 Reverse Proxy 功能，本文就采用了此技术来实现转发功能。运行 Reverse Proxy 的 Apache 服务器对于客户端而言就是一台实际的 Web 服务器，客户端将从该服务器获取和上传所有的数据，具体的配置方法如下文所述。

大多数的 Linux 平台已经安装了 Apache 服务器，对于已经安装了 Apache 服务器的平台，必须保证其支持 IPv6，并且加载了 mod_proxy和mod_ssl 模块。当然也可以从 Apache 的源代码开始编译一个新的 Apache 服务器。

首先需要确定 Apache 服务器监听 IPv6 地址，一般而言，在 httpd.conf 中有如下一条：

    Listen 80
            

这表明该 Apache 服务器监听所有的主机地址，自然也包括 IPv6 的地址。若原 Apache 服务器配置了监听一些特定的地址，确保这些地址中包含代理服务器与客户端通信使用的 IPv6 地址。

对于代理服务器的配置，这里需要使用 Apache 服务器的 mod_proxy 模块中的 ProxyPass 指示字，在 Apache 配置文件中加入如下的配置语句。

NameVirtualHost *:80
            <VirtualHost *:80>
            ServerAdmin webmaster@dummy-host.example.com
            ServerName ipv6-server-proxy
            ProxyRequests off
            <Proxy *>
            Order deny,allow
            Allow from all
            </Proxy>
            ProxyPass /request http://www.server.com/request
            ErrorLog "logs/proxypass-error_log"
            CustomLog "logs/proxypass-access_log" common
            </VirtualHost>
            

这里的 ProxyPass 指示语的含义是所有对此 Apache 服务器的 /request 目录的访问都将转发到 http://www.server.com/request。若此 Apache 服务器的 IPv6 地址为2002:9ba:b4e:6::3，则客户端若访问

http://[2002:9ba:b4e:6::3]/request
            

实际获得的数据将来自于

http://www.server.com/request
            

这样，在客户端看来，与其通信的服务器是一个支持 IPv6 的服务器端，而实际上是 Apache 代理将远程的服务器端映射到了本地的 IPv6 网络。在这种环境下，客户端就可以来开发和测试自身对 IPv6 的支持了，而无需考虑服务器端对此协议的支持。

上述语句添加的位置由 Apache 的配置文件结构决定，目前许多版本的 Apache 采用多个配置文件，即由一个主的配置文件 httpd.conf 来包含其他子项配置文件，如 httpd-vhosts.conf，httpd-ssl.conf 文件等，而不是所有的配置信息全部写在 httpd.conf 文件中。这里推荐将上述配置语句写入 httpd-vhosts.conf 文件中，然后在主配置文件 httpd.conf 文件加入下面这条包含此文件。

Include httpd-vhosts.conf
            

这里默认 httpd-vhosts.conf 与 httpd.conf 在同一目录下，多数情况下要加入 httpd-vhosts.conf 的相对路径。

对于需要使用 HTTPS 连接的应用程序，其 Apache 服务器的配置有所不同，参见下一节2.2.5中的具体介绍。

在配置好以后，即可启动/重启 Apache 服务器来使得刚才的配置生效。

# /etc/init.d/httpd restart
            

2.2.5 利用 openssl 生成 HTTPS 连接所需的认证信息

由于运行 Reverse Proxy 的 Apache 服务器在客户端看来是一台实际的 Web 服务器，因此在进行 HTTPS 连接时，客户端需要验证其 SSL 签名的有效性。这样，我们需要在上述配置好的 Apache 服务器中加入 SSL 认证信息，才能保证客户端的 HTTPS 应用程序能够正常运行。

自签名（self-signed）的 SSL 认证文件的生成

首先是生成根证书文件 ca.crt

# openssl genrsa -des3 -out ca.key 4096
            # openssl req -new -x509 -days 365 -key ca.key -out ca.crt
            

第一步是生成一个根证书的 key 文件，系统会要求输入 pass phase， 记下输入的密码，这一密码会在后面多次用到。而第二步则将使用这个 key 文件来生成根证书，这一步执行时系统会要求输入许多根证书的信息，值得注意的是 Common Name（CN），这一步中输入的 CN 值应与下一步生成服务器证书时输入的不同。

接着需要生成服务器证书签名请求（Certificate Signing Request）文件 server.csr，步骤与生成根证书文件类似。

# openssl genrsa -des3 -out server.key 4096
            # openssl req -new -key server.key -out server.csr
            

同样，在第二步中会要求输入一系列的服务器信息，这里的 Common Name（CN） 应与客户端访问该服务器时使用的地址相同，例如：

客户端使用 http://proxyhost.com/ 访问该服务器时，这里的 CN 应为 proxyhost.com

客户端使用 http://[2002:9ba:b4e:6::3]/ 访问该服务器时，这里的 CN 应为 [2002:9ba:b4e:6::3]

为何需要相同，是因为客户端的 HTTPS 连接程序会验证该服务器提供的证书有效性，若证书中的 CN 与实际客户端访问的主机名不同，客户端会抛出 INVALID_CN 错误。

最后，利用前面生成的根证书文件 ca.crt 来签署（Sign）服务器证书签名请求 server.csr。

# openssl x509 -req -days 365 -in server.csr -CA ca.crt \
            -CAkey ca.key -set_serial 01 -out server.crt
            

将上述生成的四个证书相关文件（ca.crt，ca.key，server.crt，server.key）拷入 Apache 的配置文件夹中，接下来将会把这些文件的路径和一些配置信息加入到 Apache 配置文件中。

Listen 443
            AddType application/x-x509-ca-cert .crt
            AddType application/x-pkcs7-crl    .crl
            SSLPassPhraseDialog  builtin
            SSLSessionCache "shmcb:/usr/local/apache2/logs/ssl_scache(512000)"
            SSLSessionCacheTimeout  300
            SSLMutex  "file:logs/ssl_mutex"
            NameVirtualHost *:443
            <VirtualHost *:443>
            DocumentRoot "apache2/htdocs"
            ServerName ipv6-server-proxy
            ServerAdmin you@example.com
            ErrorLog "ssl-error_log"
            TransferLog "ssl-access_log"
            SSLEngine on
            SSLProtocol -all +TLSv1 +SSLv3
            SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM
            SSLCertificateFile "server.crt"
            SSLCertificateKeyFile "server.key"
            <Directory "/usr/local/apache2/cgi-bin">
            SSLOptions +StdEnvVars
            </Directory>
            BrowserMatch ".*MSIE.*" \
            nokeepalive ssl-unclean-shutdown \
            downgrade-1.0 force-response-1.0
            CustomLog "logs/ssl_request_log" \
            "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
            SSLProxyEngine on
            ProxyRequests off
            <Proxy *>
            Order deny,allow
            Allow from all
            </Proxy>
            ProxyPass /request http://www.server.com/request
            </VirtualHost>
            

这里再次使用了 ProxyPass 来建立代理服务。

正如上一节2.2.4中所述，这里建议将这些配置信息写入 httpd-ssl.conf 中，然后在 httpd.conf 中加入如下一行将其包含。

Include httpd-ssl.conf
            

配置完成后，即可启动/重启 Apache 服务器来使得刚才的配置生效。

# /etc/init.d/httpd restart
            

客户端 HTTPS 连接的考虑

由于这里采用的是自签名（Self-signed）的方式来生成服务器的认证文件，客户端使用 HTTPS 连接到该代理服务器时，会出现认证错误的提示。这就需要将这里生成的证书加入到客户端的可信站点列表中。具体的添加方式因采用的系统不同而各异。就 Windows 平台的 IE 而言，可以将上述生成的 ca.crt 及 server.crt 文件加入到 IE 的可信站点中，这会影响到所有利用 IE 提供的 wininet 库进行 HTTP 应用开发的程序。

2.2.6 DNS 考虑

在网络应用中，客户端一般使用域名来访问服务器端。在测试 IPv6 的环境中，必须使用 IPv6 的地址来访问，这就需要一个支持 IPv6 的 DNS 域名服务器，对于一定的域名返回其 IPv6 的地址。目前可以使用在 Linux 平台的 BIND 9 来搭建这样的 DNS 服务器。但是其配置相对比较复杂，还可以使用一种相对简便的方法。即利用 Linux 和 Windows 平台均支持的 hosts 文件来配对域名与其相应的 IPv6 地址。这需要在客户端的相应 hosts 文件中加入一些 IPv6 地址的配置信息。

在 Linux 平台上，hosts 文件一般位于 /etc/hosts，在此文件中加入如下一行：

           2002:9ba:b4e:6::3    www.someipv6site.com
            

这样就指定了 www.someipv6site.com 的 IPv6 地址为 2002:9ba:b4e:6::3。而在 Windows 平台上 hosts 文件位于 %WINDIR%\System32\drivers\etc\hosts，其格式与 Linux 平台上相同。

2.3 IPv6 和 IPv4 混合环境兼容性测试

从 IPv4 到 IPv6 的过渡是一个漫长而复杂的过程，不可能在短期内实现完全转换，所以在产品的开发及测试过程中除了考虑 IPv6 网络内的通讯还需要充分考虑现实网络环境中很可能出现的 IPv6 网络和 IPv4 网络的混合环境，这就需要测试应用程序在此环境下的兼容性。 本节将介绍一些需要模拟的情况。

模拟以下3种网络情况首先都需要在现有的 IPv4 局域网环境中选择一台机器作为路由服务器，并按照2.2.3节的描述进行相关配置。这样与该路由连接于同一个 Switch 上的计算机都将会被自动分配一个 IPv6 的地址。如果仍然没有获得 IPv6 的地址，请关闭计算机和路由服务器上的防火墙。然后按照 2.2.4 节中的描述选择一台计算机设置为 ProxyPass。

2.3.1客户端和服务器端均运行于 IPv6 的网络环境

这种情况的验证相对比较简单，只需要在客户端将服务器的地址设为前面配置的 ProxyPass 的 IPv6 的地址便能实现客户端和服务器端 IPv6 到 IPv6 的交互。这就是2.2节介绍的情况。

图 4. 客户端和服务器端均运行于 IPv6 的网络环境

2.3.2 客户端运行于 IPv6 网络，服务端运行于 IPv4 网络

对于客户端和服务器端分别处于 IPv6 和 IPv4 环境的情况，需要在局域网环境中增加代理 (proxy) 作为两者之间的桥梁，该代理与上述路由服务器位于同一个网络之中，因而也拥有 IPv6 的地址和 IPv4 的地址。客户端所设置的目的服务器端地址为 IPv4 的地址，设置的代理地址为该代理的 IPv6 的地址，这样客户通过 IPv6 协议与代理直接进行通讯，而代理接受到客户端所设置的 IPv4 格式的服务器地址后则通过 IPv4 协议与服务端交互，这样便模拟实现了客户端位于 IPv6 网络而服务器端位于 IPv4 网络的情况。

图5客户端运行于 IPv6 网络，服务端运行于 IPv4 网络

2.3.3 客户端运行于 IPv4 网络，服务端运行于 IPv6 网络

模拟位于 IPv4 网络中的客户端与位于 IPv6 网络中的服务器端进行交互需要使用 Proxy 和 ProxyPass 来进行环境搭建。客户端将 ProxyPass 所在的 IPv6 的地址设置为服务器端的地址，将 Proxy 所在的 IPv4 的地址设置为代理的地址，这样客户端与代理之间通过 IPv4 协议进行通讯。代理在获取到客户端所配置的 IPv6 协议的 ProxyPass 地址后将通过 IPv6 协议与 ProxyPass 进行交互。ProxyPass 收到客户端发送的请求后将通过 IPv4 的协议发送给真正的位于 IPv4 网络中的服务器进行处理。这样在客户端就模拟实现了 IPv4 网络到 IPv6 网络的通讯。

图6客户端运行于 IPv4 网络，服务端运行于 IPv6 网络

Server

3 总结

在本文中，我们通过使用现有的 IPv4 网络配合 Linux 平台上的 Apache 服务器，达到了模拟 IPv6 的 HTTP/HTTPS 网络环境的目的，从而可以在有限的硬件资源之下开发和测试网络应用软件对 IPv6 的支持。这项技术还可以应用到其他的网络协议之上，只需使用具备类似于 Apache 服务器转发技术的代理服务器。因此这项技术具有一定的通用性

问题描述:本文举例介绍如何手工从IPv4升级到IPv6。所用的网络包括两个子网，每个子网中有两个节点：路由节点和另一台主机。我们将该网络中每个节点升级到IPv6。

第一步：配置主机为IPv6

在两个子网上的主机中分别执行如下操作：

1. 使用下列命令检查IPv4已经配置：

netstat -ni
命令输出样式如下所示：
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
en0 1500 link#2 0.6.29.4.55.ec 279393 0 2510 0 0
en0 1500 9.3.230.64 9.3.230.117 279393 0 2510 0 0
lo0 16896 link#1 913 0 919 0 0
lo0 16896 127 127.0.0.1 913 0 919 0 0
lo0 16896 ::1 913 0 919 0 0

2. 使用root权限通过下列命令设置IPv6:
autoconf6
3. 运行下列命令：
netstat -ni
命令输出样式如下所示：
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
en0 1500 link#2 0.6.29.4.55.ec 279679 0 2658 0 0
en0 1500 9.3.230.64 9.3.230.117 279679 0 2658 0 0
en0 1500 fe80::206:29ff:fe04:55ec 279679 0 2658 0 0
sit0 1480 link#3 9.3.230.117 0 0 0 0 0
sit0 1480 ::9.3.230.117 0 0 0 0 0
lo0 16896 link#1 2343 0 2350 0 0
lo0 16896 127 127.0.0.1 2343 0 2350 0 0
lo0 16896 ::1 2343 0 2350 0 0
4. 使用下列命令启动匿名进程 ndpd-host：
startsrc -s ndpd-host
此时主机即可使用IPv6。重复上述命令配置每个子网中的主机。

第二步：配置路由节点为IPv6

1. 使用下列命令检查IPv4已经配置：
netstat -ni
2. 使用root权限通过下列命令设置IPv6:
autoconf6
3. 在每个路由节点上配置相应子网的IP地址，命令如下：
# ifconfig en0 inet6 fec0:0:0:aaaa::/64 eui64 alias
# ifconfig en1 inet6 fec0:0:0:bbbb::/64 eui64 alias
4. 使用下列命令激活IPv6的转发功能：
no -o ip6forwarding=1
5. 启动ndpd-router匿名进程：
startsrc -s ndpd-router

第三步： 设置系统引导时自动配置IPv6
新配置的IPv6地址在系统重启时会被删除。若想使之生效，需要执行以下步骤：
1. 编辑文件/etc/rc.tcpip，将下列几行的注释打开：
# Start up autoconf6 process
start /usr/sbin/autoconf6 ""
# Start up ndpd-host daemon
start /usr/sbin/ndpd-host "$src_running"
在下次系统重启时，IPv6的配置信息将自动设置。
第四步：在路由节点设置系统引导时自动配置IPv6

新配置的IPv6地址在系统重启时会被删除。若想使之生效，需要执行以下步骤：

1. 编辑文件/etc/rc.tcpip，将下列几行的注释打开

# Start up autoconf6 process
start /usr/sbin/autoconf6 ""
2. 在其下面加入以下命令：
# Configure site-local addresses for router
ifconfig en0 inet6 fec0:0:0:aaaa::/ eui64 alias
ifconfig en1 inet6 fec0:0:0:bbbb::/ eui64 alias
3. 再将下列行的注释打开：
# Start up ndpd-router daemon
start /usr/sbin/ndpd-router "$src_running"
在下次系统重启时，IPv6将自动生效

1、客户端程序异常。

　　对于这种情况，我们很好处理，因为客户端程序异常退出会在服务端引发ConnectionReset的Socket异常（就是WinSock2中的10054异常）。只要在服务端处理这个异常就可以了。

2、网络链路异常。

　　如：网线拔出、交换机掉电、客户端机器掉电。当出现这些情况的时候服务端不会出现任何异常。这样的话上面的代码就不能处理这种情况了。对于这种情况在MSDN里面是这样处理的，我在这里贴出MSDN的原文：

如果您需要确定连接的当前状态，请进行非阻止、零字节的 Send 调用。如果该调用成功返回或引发 WAEWOULDBLOCK 错误代码 (10035)，则该套接字仍然处于连接状态；否则，该套接字不再处于连接状态。

　　但是我在实际应用中发现，MSDN说的这种处理方法在很多时候根本无效，无法检测出网络已经异常断开了。那我们该怎么办呢？

　　我们知道，TCP有一个连接检测机制，就是如果在指定的时间内（一般为2个小时）没有数据传送，会给对端发送一个Keep-Alive数据报，使用的序列号是曾经发出的最后一个报文的最后一个字节的序列号，对端如果收到这个数据，回送一个TCP的ACK，确认这个字节已经收到，这样就知道此连接没有被断开。如果一段时间没有收到对方的响应，会进行重试，重试几次后，向对端发一个reset，然后将连接断掉。

　　在Windows中，第一次探测是在最后一次数据发送的两个小时，然后每隔1秒探测一次，一共探测5次，如果5次都没有收到回应的话，就会断开这个连接。但两个小时对于我们的项目来说显然太长了。我们必须缩短这个时间。那么我们该如何做呢？我要利用Socket类的IOControl()函数。我们来看看这个函数能干些什么：

使用 IOControlCode 枚举指定控制代码，为 Socket 设置低级操作模式。

命名空间:System.Net.Sockets
程序集:System（在 system.dll 中）

语法

C#
public int IOControl (
IOControlCode ioControlCode,
byte[] optionInValue,
byte[] optionOutValue
)


参数
ioControlCode
一个 IOControlCode 值，它指定要执行的操作的控制代码。

optionInValue
Byte 类型的数组，包含操作要求的输入数据。

optionOutValue
Byte 类型的数组，包含由操作返回的输出数据。

返回值
optionOutValue 参数中的字节数。

如：

socket.IOControl(IOControlCode.KeepAliveValues, inOptionValues, null);

我们要搞清楚的就是inOptionValues的定义，在C++里它是一个结构体。我们来看看这个结构体：

struct tcp_keepalive 
...{ 
    u_long  onoff; //是否启用Keep-Alive
    u_long  keepalivetime; //多长时间后开始第一次探测（单位：毫秒）
    u_long  keepaliveinterval; //探测时间间隔（单位：毫秒）
}; 

在C#中，我们直接用一个Byte数组传递给函数：

uint dummy = 0;
byte[] inOptionValues = new byte[Marshal.SizeOf(dummy) * 3];
BitConverter.GetBytes((uint)1).CopyTo(inOptionValues, 0);//是否启用Keep-Alive
BitConverter.GetBytes((uint)5000).CopyTo(inOptionValues, Marshal.SizeOf(dummy));//多长时间开始第一次探测
BitConverter.GetBytes((uint)5000).CopyTo(inOptionValues, Marshal.SizeOf(dummy) * 2);//探测时间间隔

具体实现代码：

        public static void AcceptThread()
        ...{
            Thread.CurrentThread.IsBackground = true;
            while (true)
            ...{
                uint dummy = 0;
                byte[] inOptionValues = new byte[Marshal.SizeOf(dummy) * 3];
                BitConverter.GetBytes((uint)1).CopyTo(inOptionValues, 0);
                BitConverter.GetBytes((uint)5000).CopyTo(inOptionValues, Marshal.SizeOf(dummy));
                BitConverter.GetBytes((uint)5000).CopyTo(inOptionValues, Marshal.SizeOf(dummy) * 2);
                try
                ...{
                    Accept(inOptionValues);
                }
                catch ...{ }
            }
        }

        private static void Accept(byte[] inOptionValues)
        ...{
            Socket socket = Public.s_socketHandler.Accept();
            socket.IOControl(IOControlCode.KeepAliveValues, inOptionValues, null);
            UserInfo info = new UserInfo();
            info.socket = socket;
            int id = GetUserId();
            info.Index = id;
            Public.s_userList.Add(id, info);
            socket.BeginReceive(info.Buffer, 0, info.Buffer.Length, SocketFlags.None, new AsyncCallback(ReceiveCallBack), info);
        }

好了，这样就成功了。

   这里子进程就不会产生僵尸进程了。

 在linux下写socket的程序的时候，如果尝试send到一个disconnected socket上，就会让底层抛出一个SIGPIPE信号。
这个信号的缺省处理方法是退出进程，大多数时候这都不是我们期望的。因此我们需要重载这个信号的处理方法。调用以下代码，即可安全的屏蔽SIGPIPE：
    struct sigaction sa;
    sa.sa_handler = SIG_IGN;
    sigaction( SIGPIPE, &sa, 0 );

 楼上正解.
signal设置的信号句柄只能起一次作用,信号被捕获一次后,信号句柄就会被还原成默认值了.

sigaction设置的信号句柄,可以一直有效,值到你再次改变它的设置.

    如:    signal(SIGPIPE,SIG_IGN);
    这时SIGPIPE交给了系统处理。

服务器采用了fork的话，要收集垃圾进程，防止僵尸进程的产生，可以这样处理：
signal(SIGCHLD,SIG_IGN);　交给系统init去回收。
   这里子进程就不会产生僵尸进程了。

http://www.cublog.cn/u/31357/showart_242605.html

好久没做过C开发了，最近重操旧业。
听说另外一个项目组socket开发遇到问题，发送端和接受端数据大小不一致。建议他们采用writen的重发机制，以避免信号中断错误。采用后还是有问题。PM让我帮忙研究下。
UNP n年以前看过，很久没做过底层开发，手边也没有UNP vol1这本书，所以做了个测试程序，研究下实际可能发生的情况了。

测试环境：AS3和redhat 9(缺省没有nc)

先下载unp源码:
wget http://www.unpbook.com/unpv13e.tar.gz
tar xzvf *.tar.gz;
configure;make lib.
然后参考str_cli.c和tcpcli01.c，写了测试代码client.c

#include    "unp.h"

#define MAXBUF 40960
void processSignal(int signo)
{
    printf("Signal is %d\n", signo);
    signal(signo, processSignal);
}
void
str_cli(FILE *fp, int sockfd)
{
    char    sendline[MAXBUF], recvline[MAXBUF];

    while (1) {

        memset(sendline, 'a', sizeof(sendline));
        printf("Begin send %d data\n", MAXBUF);
        Writen(sockfd, sendline, sizeof(sendline));
        sleep(5);

    }
}

int
main(int argc, char **argv)
{
    int                    sockfd;
    struct sockaddr_in    servaddr;

    signal(SIGPIPE, SIG_IGN);
    //signal(SIGPIPE, processSignal);

    if (argc != 2)
        err_quit("usage: tcpcli [port]");

    sockfd = Socket(AF_INET, SOCK_STREAM, 0);

    bzero(&servaddr, sizeof(servaddr));
    servaddr.sin_family = AF_INET;
    servaddr.sin_port = htons(atoi(argv[1]));
    Inet_pton(AF_INET, "127.0.0.1", &servaddr.sin_addr);

    Connect(sockfd, (SA *) &servaddr, sizeof(servaddr));

    str_cli(stdin, sockfd);        /* do it all */

    exit(0);
}

为了方便观察错误输出，lib/writen.c也做了修改，加了些日志：

/* include writen */
#include    "unp.h"

ssize_t        &nbs

p;               /* Write "n" bytes to a descriptor. */ writen(int fd, const void *vptr, size_t n) {     size_t         nleft;      ssize_t         nwritten;     const char    *ptr;      ptr = vptr;      nleft = n;     while (nleft > 0) {         printf("Begin Writen %d\n", nleft);         if ( (nwritten = write(fd, ptr, nleft)) <= 0) {             if (nwritten < 0 && errno == EINTR) {                 printf("intterupt\n");                  nwritten = 0;        /* and call write() again */             }             else                 return(-1);            /* error */         }          nleft -= nwritten;          ptr += nwritten;         printf("Already write %d, left %d, errno=%d\n", nwritten, nleft, errno);     }     return(n); } /* end writen */ void Writen(int fd, void *ptr, size_t nbytes) {     if (writen(fd, ptr, nbytes) != nbytes)          err_sys("writen error"); }

client.c放在tcpclieserv目录下，修改了Makefile，增加了client.c的编译目标

client: client.c                  ${CC} ${CFLAGS} -o $@ $< ${LIBS}

接着就可以开始测试了。

测试1 忽略SIGPIPE信号，writen之前，对方关闭接受进程

本机服务端：

nc -l -p 30000

本机客户端:
./client 30000
Begin send 40960 data
Begin Writen 40960
Already write 40960, left 0, errno=0
Begin send 40960 data
Begin Writen 40960
Already write 40960, left 0, errno=0
执行到上步停止服务端,client会继续显示:
Begin send 40960 data
Begin Writen 40960
writen error: Broken pipe(32)
结论:可见write之前，对方socket中断，发送端write会返回-1,errno号为EPIPE(32)

测试2 catch SIGPIPE信号，writen之前，对方关闭接受进程

修改客户端代码，catch sigpipe信号

//signal(SIGPIPE, SIG_IGN);         signal(SIGPIPE, processSignal);

本机服务端：

nc -l -p 30000

本机客户端:
make client
./client 30000

Begin send 40960 data
Begin Writen 40960
Already write 40960, left 0, errno=0
Begin send 40960 data
Begin Writen 40960
Already write 40960, left 0, errno=0
执行到上步停止服务端,client会继续显示:
Begin send 40960 data
Begin Writen 40960
Signal is 13
writen error: Broken pipe(32)
结论:可见write之前，对方socket中断，发送端write时，会先调用SIGPIPE响应函数，然后write返回-1,errno号为EPIPE(32)

测试3 writen过程中，对方关闭接受进程

为了方便操作，加大1次write的数据量，修改MAXBUF为4096000

本机服务端：

nc -l -p 30000

本机客户端:
make client
./client 30000

Begin send 4096000 data
Begin Writen 4096000
执行到上步停止服务端,client会继续显示:
Already write 589821, left 3506179, errno=0
Begin Writen 3506179
writen error: Connection reset by peer(104)

结论:可见socket write中，对方socket中断，发送端write会先返回已经发送的字节数,再次write时返回-1,errno号为ECONNRESET(104)

为什么以上测试，都是对方已经中断socket后，发送端再次write，结果会有所不同呢。从后来找到的UNP5.12,5.13能找到答案

The client's call to readline may happen before the server's RST is received by the client, or it may happen after. If the readline happens before the RST is received, as we've shown in our example, the result is an unexpected EOF in the client. But if the RST arrives first, the result is an ECONNRESET ("Connection reset by peer") error return from readline.

以上解释了测试3的现象，write时，收到RST.

What happens if the client ignores the error return from readline and writes more data to the server? This can happen, for example, if the client needs to perform two writes to the server before reading anything back, with the first write eliciting the RST. The rule that applies is: When a process writes to a socket that has received an RST, the SIGPIPE signal is sent to the process. The default action of this signal is to terminate the process, so the process must catch the signal to avoid being involuntarily terminated. If the process either catches the signal and returns from the signal handler, or ignores the signal, the write operation returns EPIPE.

以上解释了测试1，2的现象,write一个已经接受到RST的socket，系统内核会发送SIGPIPE给发送进程，如果进程catch/ignore这个信号，write都返回EPIPE错误.

因此,UNP建议应用根据需要处理SIGPIPE信号，至少不要用系统缺省的处理方式处理这个信号，系统缺省的处理方式是退出进程，这样你的应用就很难查处处理进程为什么退出。

http://blog.csdn.net/shcyd/archive/2006/10/28/1354577.aspx

在Unix系统下，如果send在等待协议传送数据时网络断开的话，调用send的进程会接收到一个SIGPIPE信号，进程对该信号的默认处理是进程终止。
在Unix系统下，如果recv函数在等待协议接收数据时网络断开了，那么调用recv的进程会接收到一个SIGPIPE信号，进程对该信号的默认处理是进程终止。

处理方法：
在初始化时调用signal(SIGPIPE,SIG_IGN)忽略该信号（只需一次）
其时send或recv函数将返回-1，errno为EPIPE，可视情况关闭socket或其他处理

gdb：
gdb默认收到sigpipe时中断程序，可调用handle SIGPIPE nostop print

相关

(1)SIG_DFL信号专用的默认动作:
　　(a)如果默认动作是暂停线程，则该线程的执行被暂时挂起。当线程暂停期间，发送给线程的任何附加信号都不交付，直到该线程开始执行，但是SIGKILL除外。
　　(b)把挂起信号的信号动作设置成SIG_DFL，且其默认动作是忽略信号 (SIGCHLD)。

(2)SIG_IGN忽略信号
　　(a)该信号的交付对线程没有影响
　　(b)系统不允许把SIGKILL或SIGTOP信号的动作设置为SIG_DFL

(3)指向函数的指针--捕获信号
　　(a)信号一经交付，接收线程就在指定地址上执行信号捕获程序。在信号捕 获函数返回后，接受线程必须在被中断点恢复执行。
　　(b)用C语言函数调用的方法进入信号捕捉程序:
　　　　void func (signo)
　　　　int signo;
　　　　func( )是指定的信号捕捉函数，signo是正被交付信号的编码
　　(c)如果SIGFPE,SIGILL或SIGSEGV信号不是由C标准定义的kill( )或raise( )函数所生成，则从信号SIGFPE,SIGILL,SIGSEGV的信号捕获函数正常返回后线程的行为是未定义的。
　　(d)系统不允许线程捕获SIGKILL和SIGSTOP信号。
　　(e)如果线程为SIGCHLD信号建立信号捕获函数，而该线程有未被等待的以终止的子线程时，没有规定是否要生成SIGCHLD信号来指明那个子线程。

每一种信号都被OSKit给予了一个符号名，对于32位的i386平台而言，一个字32位，因而信号有32种。下面的表给出了常用的符号名、描述和它们的信号值。

符号名　　信号值 描述　　　　　　　　　　　　　　　　是否符合POSIX
SIGHUP　　1　　　在控制终端上检测到挂断或控制线程死亡　　是
SIGINT　　2　　　交互注意信号　　　　　　　　　　　　　　是
SIGQUIT　 3　　　交互中止信号　　　　　　　　　　　　　　是
SIGILL　　4　　　检测到非法硬件的指令　　　　　　　　　　是
SIGTRAP　 5　　　从陷阱中回朔　　　　　　　　　　　　　　否
SIGABRT　 6　　　异常终止信号　　　　　　　　　　　　　　是
SIGEMT　　7　　　EMT 指令　　　　　　　　　　　　　　　　否
SIGFPE　　8　　　不正确的算术操作信号　　　　　　　　　　是
SIGKILL　 9　　　终止信号　　　　　　　　　　　　　　　　是
SIGBUS　　10　　 总线错误　　　　　　　　　　　　　　　　否
SIGSEGV　 11　　 检测到非法的内存调用　　　　　　　　　　是
SIGSYS　　12　　 系统call的错误参数　　　　　　　　　　　否
SIGPIPE　 13　　 在无读者的管道上写　　　　　　　　　　　是
SIGALRM　 14　　 报时信号　　　　　　　　　　　　　　　　是
SIGTERM　 15　　 终止信号　　　　　　　　　　　　　　　　是
SIGURG　　16　　 IO信道紧急信号　　　　　　　　　　　　　否
SIGSTOP　 17　　 暂停信号　　　　　　　　　　　　　　　　是
SIGTSTP　 18　　 交互暂停信号　　　　　　　　　　　　　　是
SIGCONT　 19　　 如果暂停则继续　　　　　　　　　　　　　是
SIGCHLD　 20　　 子线程终止或暂停　　　　　　　　　　　　是
SIGTTIN　 21　　 后台线程组一成员试图从控制终端上读出　　是
SIGTTOU　 22　　 后台线程组的成员试图写到控制终端上　　　是
SIGIO　　 23　　 允许I/O信号 　　　　　　　　　　　　　　否
SIGXCPU　 24　　 超出CPU时限　　　　　　　　　　　　　　 否
SIGXFSZ　 25　　 超出文件大小限制　　　　　　　　　　　　否
SIGVTALRM 26　　 虚时间警报器　　　　　　　　　　　　　　否
SIGPROF　 27　　 侧面时间警报器　　　　　　　　　　　　　否
SIGWINCH　28　　 窗口大小的更改　　　　　　　　　　　　　否
SIGINFO　 29　　 消息请求　　　　　　　　　　　　　　　　否
SIGUSR1 　30　　 保留作为用户自定义的信号1　　　　　　　 是
SIGUSR2 　31　　 保留作为用户自定义的信号　　　　　　　　是

注意：Linux信号机制基本上是从Unix系统中继承过来的。早期Unix系统中的信号机制比较简单和原始，后来在实践中暴露出一些问题，因此，把那些建立在早期机制上的信号叫做"不可靠信号"，信号值小于SIGRTMIN(Red hat 7.2中，SIGRTMIN=32，SIGRTMAX=63)的信号都是不可靠信号。这就是"不可靠信号"的来源。它的主要问题是：进程每次处理信号后，就将对信号的响应设置为默认动作。在某些情况下，将导致对信号的错误处理；因此，用户如果不希望这样的操作，那么就要在信号处理函数结尾再一次调用signal()，重新安装该信号。

另外，我再做一些补充，产生RST响应以至于系统发出SIGPIPE信号，应该分为两种情况:

1. 客户端到服务端之间网络断掉，或者服务端断电等，物理连接断掉了，这种情况下客户端不会退出，send函数正常执行，不会感觉到自己出错。因为由于物理网络断开，服务端不会给客户端回应错误消息，没有RST响应，自然也不会产生SIGPIPE信号。但是当服务端再恢复正常的时候，对客户端send来的消息会产生RST响应，客户端就收到SIGPIPE信号了，程序退出，但是这时send函数是能够返回 -1的。可以进行异常处理。

2.客户端到服务端的网络能通，服务程序挂掉，客户端程序会马上退出，因为服务端能正常返回错误消息，客户端收到，SIGPIPE信号就产生了。不过我不确定此时服务端返回是的RST响应，抓包来看没有RST标志。水平有限，只写到这了。

文章出处：http://www.diybl.com/course/6_system/linux/Linuxjs/20081020/150832.html

　　产生原因：
1。常连接并且当连接一直处于IDLE状态导致SERVER CLOSE时，CLIENT编程缺陷，没有向SERVER 发出FIN和ACK包
2。APACHE1.1和APACHE1.2增加了linger_close()函数，前面的帖子有介绍，这个函数可能引起了这个问题（为什么我也不清楚）
　　解决办法：
1。对FIN_WAIT_2状态增加超时机制，这个特性在协议里没有体现，但在一些OS中已经实现
如：LINUX、SOLARIS、FREEBSD、HP-UNIX、IRIX等
2。不要用linger_close()编译
3。用SO_LINGER代替，这个在某些系统中还能很好地处理
4。增加用于存储网络连接状态的内存mbuf，以防止内核crash
5。DISABLE KEEPALIVE

[编辑本段]

端口号

TCP与UDP对于端口号的使用规定

[编辑本段]

端口分类

[编辑本段]

怎样查看端口

[编辑本段]

端口号很多是奇数的原因

上一段测试代码：

#include <sys/socket.h>
#include <net/if.h>
struct ifreq interface;
struct socket sock;
/* Management net interface name */
#define IFNAME "eth1"
 
/* Acquire socket here ... */
 
strncpy(interface.ifr_ifrn.ifrn_name, IFNAME, \
IFNAMSIZ);
if (setsockopt(sock, SOL_SOCKET, SO_BINDTODEVICE, \
(char *)&interface, sizeof(interface)) < 0) {
perror("SO_BINDTODEVICE failed");
/* Deal with error... */
}

参考：
http://blog.chinaunix.net/u/270/showart_234383.html
http://tuxology.net/2008/05/15/forcing-connections-through-a-specific-interface/

文章出处：DIY部落(http://www.diybl.com/course/6_system/linux/Linuxjs/20090314/161536.html)