BlogJava-ゞ沉默是金ゞ-随笔分类-HTTP

How To Avoid javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated Problem Using Apache HttpClient

ゞ沉默是金ゞ — Tue, 14 Aug 2012 10:42:00 GMT

I use Apache’s HttpClient library for all my URL related needs. It is a marvelous library that does most of the job behind the scenes. Compared the Java’s URL class, it is not as easy to use as Apache’s HttpClient. While using this library, a site that I commonly check for updates threw the exception message javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated.

When I checked the site, it seemed that its SSL certificated had expired. The only workaround for this is to create your own TrustManager. This class actually checks if the SSL certificate is valid. The scheme used by SSL is called X.509 and Java has a specific TrustManager for this scheme, called X509TrustManager.

This handy method created by theskeleton is just the perfect solution to have your HttpClient object bypass any SSL related errors and ensures that it accepts all SSL certificates of a site, whether it is expired or not.

public static HttpClient wrapClient(HttpClient base) {
    try {
        SSLContext ctx = SSLContext.getInstance("TLS");
        X509TrustManager tm = new X509TrustManager() {
            public void checkClientTrusted(X509Certificate[] xcs, String string) throws CertificateException { }

            public void checkServerTrusted(X509Certificate[] xcs, String string) throws CertificateException { }

            public X509Certificate[] getAcceptedIssuers() {
                return null;
            }
        };
        ctx.init(null, new TrustManager[]{tm}, null);
        SSLSocketFactory ssf = new SSLSocketFactory(ctx);
        ssf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
        ClientConnectionManager ccm = base.getConnectionManager();
        SchemeRegistry sr = ccm.getSchemeRegistry();
        sr.register(new Scheme("https", ssf, 443));
        return new DefaultHttpClient(ccm, base.getParams());
    } catch (Exception ex) {
        return null;
    }
}

Another way is to recreate the keystore, for the keystore you should have the site in the CN=XXX.
the command as below:
1. Create keystore

keytool -genkey -dname "cn=daXXX.XXX.com,o=,c=" -storepass MB7BROKERpzn -keystore pznKeyStore.jks -alias pznsigned

2. Export the cert
keytool -export -keystore pznKeyStore.jks -alias pznsigned -file pznsslcert.cer
3. Create trust store for client
keytool -genkey -dname "cn=da957203.fmr.com,o=,c=" -storepass MB7BROKERpzn -keystore pznTrustStore.jks -alias pzntrustsigned
4. import the server cert
keytool -import -alias pzntrust -file pznsslcert.cer -keystore pznTrustStore.jks -storepass MB7BROKERpzn
5. use http client to call the server

        try {
           KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
           FileInputStream instream = new FileInputStream(new File(trustfname));
           try {
                trustStore.load(instream, passphrase.toCharArray());
           } finally {
                try { instream.close(); } catch (Exception ignore) {}
           }
           SSLSocketFactory socketFactory = new SSLSocketFactory(trustStore);
           Scheme sch = new Scheme("https", 443, socketFactory);
           httpclient.getConnectionManager().getSchemeRegistry().register(sch);
       } catch (Exception e1) {
           // TODO Auto-generated catch block
           e1.printStackTrace();
       }

ゞ沉默是金ゞ 2012-08-14 18:42 发表评论

How to Create Client/Server Keystores using Java Keytool

ゞ沉默是金ゞ — Tue, 26 Jun 2012 11:15:00 GMT

Here I have described how to create client/server keystores which can be used to secure Axsi2 webservices and invoke Axis2 secured webservices. i.e. It can be easily used with any WSO2 Product to experience security scenarios.More detailed explanation on creating client/server keystores using openssl including Certificate Authority(CA) Requests, can be found at http://wso2.org/library/174.

Java keytool stores the keys and certificates in a keystore, protected by a keystore password. Further, it protects private key again with another password. A Java keystore contains private-public key pair and multiple trusted certificate entries. All entries in a keystore are referred by aliases. Both private key and self signed public key is referred by one alias while any other trusted certificates are referred by different individual aliases.

As the first step, let's create a keystore for server. In order to do it, execute following command in a terminal. "server" in the following command corresponds to the private key/self signed public key certificate alias in the keystore while "server.jks" is the name of the creating keystore file.

keytool -genkey -alias server -keyalg RSA -keystore server.jks

when you execute the above command it will first prompt you to specify a password which is corresponded to the keystore password. Then it will prompt several questions. You can give answers that you wish. At the end it will ask for a password again, which will be used to secure the generated private key.

Enter keystore password:
Re-enter new password:
What is your first and last name?
[Unknown]: Ruchira Wageesha
What is the name of your organizational unit?
[Unknown]: Mashup Server
What is the name of your organization?
[Unknown]: WSO2
What is the name of your City or Locality?
[Unknown]: Ahangama
What is the name of your State or Province?
[Unknown]: Southern
What is the two-letter country code for this unit?
[Unknown]: LK
Is CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK correct?
[no]: yes
Enter key password for
(RETURN if same as keystore password):

Once you successfully completed this, java keytool will create a file named "server.jks". In the same way, you can create a client keystore named "client.jks" with the alias "client" using following command.

keytool -genkey -alias client -keyalg RSA -keystore client.jks

Now, you have two files named client.jks and server.jks. You can view the content of these keystore files using the following command. Replacess "ruchira" with the keystore password you entered while creating the keystore.

keytool -list -v -keystore server.jks -storepass ruchira

This will list something like this.

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: server
Creation date: Jul 8, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Issuer: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Serial number: 4c356225
Valid from: Thu Jul 08 10:59:09 IST 2010 until: Wed Oct 06 10:59:09 IST 2010
Certificate fingerprints:
MD5: 60:0B:48:0D:DB:56:8C:68:8C:2D:94:4A:D6:DA:04:B8
SHA1: A7:CE:57:10:70:87:C1:2C:C0:9D:1D:90:8C:BB:69:B6:66:26:97:13
Signature algorithm name: SHA1withRSA
Version: 3

*******************************************
*******************************************

The next step is, getting server's self signed public key certificate and storing it in client's keystore. And getting and storing client's self signed public key certificate in server's keystore. In order to do that, first we need to export both server and client public key certificates into files. Using the following command, you can export server's public key certificate into server.cert file and client's public key certificate into client.cert file.

keytool -export -file server.cert -keystore server.jks -storepass ruchira -alias server
keytool -export -file client.cert -keystore client.jks -storepass ruchira -alias client

Now you have server.cert and client.cert. You can use following commands to view certificate contents.

keytool -printcert -v -file server.cert
keytool -printcert -v -file client.cert

As the last step, we need to import server.cert into client keystore and client.cert into server keystore. As I mentioned earlier, each entry of a Java Keystore is stored against an alias. So, we need to specify aliases here, which will be used to refer the certificates that we are going to store.

keytool -import -file client.cert -keystore server.jks -storepass ruchira -alias client

Above command will store client's self signed public key certificate(client.cert) in server.jks against the alias "client". So, using "client" alias on server.jks, we can refer client's certificate anytime. Likewise, following command will store server.cert within client.jks against the alias "server".

keytool -import -file server.cert -keystore client.jks -storepass ruchira -alias server

After all, please view the content of both keystore again using following commands.

keytool -list -v -keystore server.jks -storepass ruchira
keytool -list -v -keystore client.jks -storepass ruchira

It will give you something like bellow for server.jks

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: server
Creation date: Jul 8, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Issuer: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Serial number: 4c3562a0
Valid from: Thu Jul 08 11:01:12 IST 2010 until: Wed Oct 06 11:01:12 IST 2010
Certificate fingerprints:
MD5: AB:77:72:F1:0D:09:55:E3:B6:D3:DC:A6:4D:D4:39:36
SHA1: D7:C1:60:5C:7E:34:40:A9:0B:E4:2C:65:6C:E0:79:7C:EE:37:A7:19
Signature algorithm name: SHA1withRSA
Version: 3

*******************************************
*******************************************

Alias name: client
Creation date: Jul 8, 2010
Entry type: trustedCertEntry

Owner: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Issuer: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Serial number: 4c356225
Valid from: Thu Jul 08 10:59:09 IST 2010 until: Wed Oct 06 10:59:09 IST 2010
Certificate fingerprints:
MD5: 60:0B:48:0D:DB:56:8C:68:8C:2D:94:4A:D6:DA:04:B8
SHA1: A7:CE:57:10:70:87:C1:2C:C0:9D:1D:90:8C:BB:69:B6:66:26:97:13
Signature algorithm name: SHA1withRSA
Version: 3

*******************************************
*******************************************

something like below for client.jks

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: server
Creation date: Jul 8, 2010
Entry type: trustedCertEntry

Owner: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Issuer: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Serial number: 4c3562a0
Valid from: Thu Jul 08 11:01:12 IST 2010 until: Wed Oct 06 11:01:12 IST 2010
Certificate fingerprints:
MD5: AB:77:72:F1:0D:09:55:E3:B6:D3:DC:A6:4D:D4:39:36
SHA1: D7:C1:60:5C:7E:34:40:A9:0B:E4:2C:65:6C:E0:79:7C:EE:37:A7:19
Signature algorithm name: SHA1withRSA
Version: 3

*******************************************
*******************************************

Alias name: client
Creation date: Jul 8, 2010
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Issuer: CN=Ruchira Wageesha, OU=Mashup Server, O=WSO2, L=Ahangama, ST=Southern, C=LK
Serial number: 4c356225
Valid from: Thu Jul 08 10:59:09 IST 2010 until: Wed Oct 06 10:59:09 IST 2010
Certificate fingerprints:
MD5: 60:0B:48:0D:DB:56:8C:68:8C:2D:94:4A:D6:DA:04:B8
SHA1: A7:CE:57:10:70:87:C1:2C:C0:9D:1D:90:8C:BB:69:B6:66:26:97:13
Signature algorithm name: SHA1withRSA
Version: 3

*******************************************
*******************************************

If everything went well, you might have successfully created server.jks and client.jks which can be used to secure Axis2 Services and access those secured services.

ゞ沉默是金ゞ 2012-06-26 19:15 发表评论

IE下Ajax缓存问题的解决办法

ゞ沉默是金ゞ — Thu, 26 Aug 2010 07:17:00 GMT

今天下午在做要素页面无刷新添加的时候，IE下遭遇Ajax缓存戏弄，因为刚开始并不知道IE有这个坏毛病，折腾了我一下午，终于解决问题。郁闷之余，总结一下解决办法：

在IE下用Ajax请求某一页面，通常会因为缓存的原因而返回上一次的结果，造成混乱，而FF下不会出现这种情况。为了不受缓存影响，可以这样做：

IE访问策略：Internet选项--浏览历史记录--设置-- Internet 临时文件的选项改为每次访问网页时也可以

1: 在AJAX请求的页面后加个随机函数,我们可以使用随机时间函数

在javascript发送的URL后加上t=Math.random()
例如这样:URL+"&"+"t="+Math.random();或者new Date();

2: 在XMLHttpRequest发送请求之前加上XMLHttpRequest.setRequestHeader("If-Modified-Since","0")

一般情况下,这里的XMLHttpRequest不会直接使用
你应该可以找到这样的代码
XXXXX.send(YYYYYY);
那么,就把它变成
XXXXX.setRequestHeader("If-Modified-Since","0");
XXXXX.send(YYYYYY);

实践证明，两种方法都非常有效。

ゞ沉默是金ゞ 2010-08-26 15:17 发表评论

RPC简介

ゞ沉默是金ゞ — Mon, 26 Jul 2010 08:21:00 GMT

由于项目的需要，了解了一下RPC，分享给大家。

RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

基本简介

RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用过程接收答复信息，获得进程结果，然后调用执行继续进行。

目前，有多种 RPC 模式和执行。最初由 Sun 公司提出。IETF ONC 宪章重新修订了 Sun 版本，使得 ONC PRC 协议成为 IETF 标准协议。现在使用最普遍的模式和执行是开放式软件基础的分布式计算环境（DCE）。

协议结构

远程过程调用（RPC^[1]）信息协议由两个不同结构组成：调用信息和答复信息。信息流程如下所示：

　　RPC：远程过程调用流程

　　RPC 调用信息：每条远程过程调用信息包括以下无符号整数字段，以独立识别远程过程：

　　程序号（Program number）

　　程序版本号（Program version number）

　　过程号（Procedure number）

　　RPC 调用信息主体形式如下：

　　struct call_body {

　　unsigned int rpcvers;

　　unsigned int prog;

　　unsigned int vers;

　　unsigned int proc;

　　opaque_auth cred;

　　opaque_auth verf;

　　1 parameter

　　2 parameter . . . }；

　　RPC 答复信息：RPC 协议的答复信息的改变取决于网络服务器对调用信息是接收还是拒绝。答复信息请求包括区别以下情形的各种信息：

　　RPC 成功执行调用信息。.

　　RPC 的远程实现不是协议第二版，返回 RPC 支持的最低和最高版本号。

　　在远程系统中，远程程序不可用。

　　远程程序不支持被请求的版本号。返回远程程序所支持的最低和最高版本号。

　　请求的过程号不存在。通常是呼叫方协议或程序差错。

　　RPC答复信息形式如下：

　　enum reply_stat stat

　　{MSG_ACCEPTED = 0,

MSG_DENIED = 1 }；

工作原理

运行时,一次客户机对服务器的RPC调用,其内部操作大致有如下十步：

　　1.调用客户端句柄；执行传送参数

　　2.调用本地系统内核发送网络消息

　　3.消息传送到远程主机

　　4.服务器句柄得到消息并取得参数

　　5.执行远程过程

　　6.执行的过程将结果返回服务器句柄

　　7.服务器句柄返回结果，调用远程系统内核

　　8.消息传回本地主机

　　9.客户句柄由内核接收消息

10.客户接收句柄返回的数据

RPC OVER HTTP

　　Microsoft RPC-over-HTTP 部署(RPC over HTTP)允许RPC 客户端安全和有效地通过Internet 连接到RPC 服务器程序并执行远程过程调用。这是在一个名称为RPC-over-HTTP 代理，或简称为RPC 代理的中间件的帮助下完成的。

　　RPC 代理运行在IIS 计算机上。它接受来自Internet 的RPC 请求，在这些请求上执行认证，检验和访问检查，如果请求通过所有的测试，RPC 代理将请求转发给执行真正处理的RPC 服务器。通过RPC over HTTP，RPC 客户端不和服务器直接通信，它们使用RPC 代理作为中间件。

ゞ沉默是金ゞ 2010-07-26 16:21 发表评论

Java获取客户端真实IP地址的两种方法

ゞ沉默是金ゞ — Wed, 07 Jul 2010 03:01:00 GMT

在JSP里，获取客户端的IP地址的方法是：request.getRemoteAddr（），这种方法在大部分情况下都是有效的。但是在通过了 Apache，Squid等反向代理软件就不能获取到客户端的真实IP地址了。

如果使用了反向代理软件，将http://192.168.1.110：2046/ 的URL反向代理为 http://www.blogjava.net/dashi99 / 的URL时，用request.getRemoteAddr（）方法获取的IP地址是：127.0.0.1　或　192.168.1.110，而并不是客户端的真实IP。

经过代理以后，由于在客户端和服务之间增加了中间层，因此服务器无法直接拿到客户端的IP，服务器端应用也无法直接通过转发请求的地址返回给客户端。但是在转发请求的HTTP头信息中，增加了X－FORWARDED－FOR信息。用以跟踪原有的客户端IP地址和原来客户端请求的服务器地址。当我们访问http://www.blogjava.net/dashi99 时，其实并不是我们浏览器真正访问到了服务器上的index.jsp文件，而是先由代理服务器去访问http://192.168.1.110：2046/index.jsp ，代理服务器再将访问到的结果返回给我们的浏览器，因为是代理服务器去访问index.jsp的，所以index.jsp中通过 request.getRemoteAddr（）的方法获取的IP实际上是代理服务器的地址，并不是客户端的IP地址。

于是可得出获得客户端真实IP地址的方法一：

public String getRemortIP(HttpServletRequest request) {
if (request.getHeader("x-forwarded-for") == null) {
return request.getRemoteAddr();
}
return request.getHeader("x-forwarded-for");
}

可是当我访问http://www.blogjava.net/dashi99 时，返回的IP地址始终是unknown，也并不是如上所示的127.0.0.1　或　192.168.1.110了，而我访问http://192.168.1.110：2046/index.jsp 时，则能返回客户端的真实IP地址，写了个方法去验证。原因出在了Squid上。squid.conf 的配制文件　forwarded_for 项默认是为on，如果 forwarded_for 设成了 off 　则：X-Forwarded-For： unknown

于是可得出获得客户端真实IP地址的方法二：

public String getIpAddr(HttpServletRequest request) {
       String ip = request.getHeader("x-forwarded-for");
       if(ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
           ip = request.getHeader("Proxy-Client-IP");
       }
       if(ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
           ip = request.getHeader("WL-Proxy-Client-IP");
       }
       if(ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
           ip = request.getRemoteAddr();
       }
       return ip;
   }

可是，如果通过了多级反向代理的话，X-Forwarded-For的值并不止一个，而是一串Ｉｐ值，究竟哪个才是真正的用户端的真实IP呢？

答案是取X-Forwarded-For中第一个非unknown的有效IP字符串。

如：X-Forwarded-For：192.168.1.110， 192.168.1.120， 192.168.1.130， 192.168.1.100用户真实IP为： 192.168.1.110

ゞ沉默是金ゞ 2010-07-07 11:01 发表评论

什么是RFC?

ゞ沉默是金ゞ — Wed, 07 Jul 2010 01:34:00 GMT

RFC及RFC编辑者

　　Request For Comments (RFC)，是一系列以编号排定的文件。文件收集了有关因特网相关资讯，以及UNIX和因特网社群的软件文件。目前RFC文件是由Internet Society（ISOC）所赞助发行。

　　基本的因特网通讯协定都有在RFC文件内详细说明。RFC文件还额外加入许多的论题在标准内，例如对于因特网新开发的协定及发展中所有的记录。因此几乎所有的因特网标准都有收录在RFC文件之中。

　　RFC(Request For Comments)-意即“请求评议”，包含了关于Internet的几乎所有重要的文字资料。如果你想成为网络方面的专家，那么RFC无疑是最重要也是最经常需要用到的资料之一，所以RFC享有网络知识圣经之美誉。通常，当某家机构或团体开发出了一套标准或提出对某种标准的设想，想要征询外界的意见时，就会在Internet上发放一份RFC，对这一问题感兴趣的人可以阅读该RFC并提出自己的意见；绝大部分网络标准的指定都是以RFC的形式开始，经过大量的论证和修改过程，由主要的标准化组织所指定的，但在RFC中所收录的文件并不都是正在使用或为大家所公认的，也有很大一部分只在某个局部领域被使用或并没有被采用，一份RFC具体处于什么状态都在文件中作了明确的标识

　　RFC由一系列草案组成，起始于1969年（第一个RFC文档发布于1969年4月7日，参见“RFC30年”，RFC2555”），RFC文档是一系列关于Internet（早期为ARPANET）的技术资料汇编。这些文档详细讨论了计算机网络的方方面面，重点在网络协议，进程，程序，概念以及一些会议纪要，意见，各种观点等。

　　“RFC编辑者”是RFC文档的出版者，它负责RFC最终文档的编辑审订。“RFC编辑者”也保留有RFC的主文件，称为RFC索引，用户可以在线检索。在RFC近30年的历史中，“RFC编辑者”一直由约翰•普斯特尔（Jon Postel）来担任，而现在“RFC编辑者”则由一个工作小组来担任，这个小组受到“因特网社团”（Internet Society）的支助。

　　RFC编辑者负责RFC以及RFC的整体结构文档，并维护RFC的索引。Internet协议族的文档部分（由Internet工程委员会“因特网工程师任务组”IETF以及IETF 下属的“因特网工程师指导组”IESG 定义），也做为RFC文档出版。因此，RFC在Internet相关标准中有着重要的地位。

　　RFC编辑者的职责是由Internet 中的大家提议形成的，所出版的语言也就和Internet一样。IETF和ISOC是代表了世界各地的国际性组织，英语是IETF的第一工作语言，也是IETF的正式出版语言。RFC 2026 "The Internet Standards Process -- Revision 3" 允许RFC翻译成其他不同的语言。但是不能保证其翻译版本是否正确。因此，RFC编辑不对非英语的版本负责，而只是指明了哪里有非英语的版本，将这些信息列在WEB页上。

RFC处理过程

　　一个RFC文件在成为官方标准前一般至少要经历4个阶段【RFC2026】：英特网草案、建议标准、草案标准、因特网标准。

　　第一步RFC的出版是作为一个Internet 草案发布，可以阅读并对其进行注释。准备一个RFC草案，我们要求作者先阅读IETF的一个文档"Considerations for Internet Drafts". 它包括了许多关于RFC以及Internet草案格式的有用信息。作者还应阅读另外一个相关的文档RFC 2223 "Instructions to Authors"。

　　一旦文档有了一个ID号后，你就可以向rfc-editor@rfc-editor.org发送e-mail ，说你觉得这个文档还可以，能够作为一个有价值或有经验的RFC文档。RFC编辑将会向IESG请求查阅该文档并给其加上评论和注释。你可以通过RFC队列来了解你的文档的进度。一旦你的文档获得通过，RFC编辑就会将其编辑并出版。如果该文档不能出版，则会有email通知作者是什么原因。作者有48个小时来校对RFC编辑的意见。我们强烈建议作者要检测拼写错误和丢字的错误，应该确保有引用，联系和更新相关的信息。如你的文档是一个MIB，我们则要你对你的代码作最后一次检测。一旦RFC文档出版，我们就不会对其进行更改，因此你应该对你的文档仔细的检查。

　　有时个别的文档会被正从事同一个项目的IETF工作组收回，如是这种情况，则该作者会被要求和IETF进行该文档的开发。在IETF中, Area Directors (ADs) 负责相关的几个工作组。这些工作者所开发的文档将由ADs 进行校阅，然后才作为RFC的出版物。

　　如要获得关于如何写RFC文档和关于RFC的Internet标准制定过程的更多详细信息，请各位参见：

　　RFC 2223 "Instructions to RFC Authors"。

　　RFC 2026 "The Internet Standards Process -- Revision 3"。

　　实际上，在Internet上，任何一个用户都可以对Internet某一领域的问题提出自己的解决方案或规范，作为Internet草案（Internet Draffs，ID）提交给Internet工程任务组（IETF）。草案存放在美国、欧洲和亚太地区的工作文件站点上，供世界多国自愿参加的IETF成员进行讨论、测试和审查。最后，由Internet工程指导组（IESG）确定该草案是否能成为Internet的标准。

　　如果一个Internet草案在IETF的相关站点上存在6个月后仍未被IESG建议作为标准发布，则它将被从上述站点中删除。事实上，在任何时候，一个Internet 草案都有可能被新的草案版本所替换掉，并重新开始6个月的存放期。

　　如果一个Internet草案被IESG确定为Internet的正式工作文件，则被提交给Internet体系结构委员会（IAB），并形成具有顺序编号的RFC文档，由Internet协会（ISOC）通过Internet向全世界颁布。每个Internet标准文件在被批准后都会分配一个独立于RFC的永久编号，这就是STD编号。有一个不断被更新的文件RFC-INDEX.TXT按照RFC的编号来索引所有的文件，对于因特网标准文件还列出了其相应的STD编号。

　　RFC文档必须被分配RFC编号后才能在网络上发布。例如，RFC2026的内容是“Internet标准进程-修订版3”、RFC1543的内容为“RFC作者指导”等等。需要时，可以复制或打印这些联机文档。用户也可以通过遍布全世界的数个联机资料数据库中获得RFC文档。例如，可以使用路径名RFC/RFCnnnn.TXT通过FTP的方式从ds.internic.net站点获得RFC，其中“nnnn”指的是RFC的编号。在这里，使用FTP登录时，所用的用户名和口令分别为“anonymous”和你的电子邮件地址。此外，用户还可以通过Internet网络信息中心（InterNIC）的目录服务功能、电子邮件、WWW等方式获得RFC文档.

　　作为标准的RFC又分为几种，第一种是提议性的，就是说建议采用这个作为一个方案摆出来，Draft是已经有一部分在用了，希望被采用为正式的标准，还有一种就是完全被认可的标准，这种是大家都在用，而且是不应该改变的。还有一种就是现在的最佳实践法，它相当于一种介绍。这些文件产生的过程是一种从下往上的过程，而不是从上往下，也就是说不是一个由主席，或者由工作组负责人的给一个指令，说是要做什么，要做什么，而是有下边自发的提出，然后在工作组里边讨论，讨论了以后再交给刚才说的工程指导委员会进行审查。但是工程指导委员会只做审查不做修改，修改还是要打回到工作组来做。IETF工作组文件的产生就是任何人都可以来参加会议，任何人都可以提议，然后他和别人进行讨论，大家形成了一个共识就可以产出这样的文件。

RFC的历史

　　RFC文件格式最初作为ARPA网计划的基础起源于1969年。如今，它已经成为IETF、Internet Architecture Board (IAB)还有其他一些主要的公共网络研究社区的正式出版物发布途径。

　　最初的RFC作者使用打字机撰写文档，并在美国国防部国防前沿研究项目署（ARPA）研究成员之间传阅。1969年12月，他们开始通过ARPANET途径来发布新的RFC文档。第一份RFC文档由洛杉矶加利福尼亚大学（UCLA）的Steve Crocker撰写，在1969年4月7日公开发表的RFC 1。当初Crocker为了避免打扰他的室友，是在浴室里完成这篇文档的。

　　在1970年代，很多后来的RFC文档同样来自UCLA，这不仅得益于UCLA的学术质量，同时也因为UCLA是ARPANET第一批Interface Message Processors (IMPs)成员之一。

　　由Douglas Engelbart领导的，位于Stanford Research Institute的Augmentation Research Center (ARC)是四个最初的ARPANET结点之一，也是最初的Network Information Centre，同时被社会学家Thierry Bardini记录为早期大量RFC文档的发源地。

　　从1969年到1998年，Jon Postel一直担任RFC文档的编辑职务。随着美国政府赞助合同的到期，Internet Society(代表IETF)，和南加州大学（USC）Information Sciences Institute的网络部门合作，（在IAB领导下）负责RFT文档的起草和发布工作。Jon Postel继续担任RFC编辑直到去世。随后，由Bob Braden接任整个项目的领导职务，同时Joyce Reynolds继续在团队中的担任职务。

　　庆祝RFC的30周年的RFC文件是RFC 2555。

RFC文件的架构

　　RFC文件只有新增，不会有取消或中途停止发行的情形。但是对于同一主题而言，新的RFC文件可以声明取代旧的RFC文件。RFC文件是纯 ASCII文字档格式，可由电脑程式自动转档成其他档案格式。RFC文件有封面、目录及页首页尾和页码。RFC的章节是数字标示，但数字的小数点后不补零，例如4.9的顺序就在4.10前面，但9的前面并不补零。RFC1000这份文件就是RFC的指南。

RFC文件的产生

　　RFC文件是由Internet Society审核后给定编号并发行。虽然经过审核，但RFC也并非全部严肃而生硬的技术文件，偶有恶搞之作出现，尤其是4月1日愚人节所发行的，例如RFC 1606: A Historical Perspective On The Usage Of IP Version 9 （参见IPv9）、RFC 2324: “超文本咖啡壶控制协议”（Hyper Text Coffee Pot Control Protocol, 乍有其事的写了HTCPCP这样看起来很专业的术语缩写字）。以及如前面所提到纪念RFC的30周年庆的RFC文件。

一些相关网址

　　截至2001年中期，公布的RFC大约有3000余篇，以下是几个较为稳定的RFC网址，以及几个重要的标准化组织的网站网址

　　http://www.rfc.net RFC的官方站点，可以检查RFC最及时的更新情况

　　http://www.ietf.org 最重要的Internet组织之一

　　http://sunsite.dk RFC查询非常强大(可以以FTP登录下载全部RFC文档)

　　http://www.iso.ch ISO-国际标准化组织

　　http://standards.ieee.org IEEE-电气与电子工程师协会

　　http://web.ansi.org ANSI-美国国家标准化组织

　　http://www.itu.int ITU-国际电信同盟

　　中文网站:

　　http://www.cnpaf.net/ 中国协议分析网

　　http://www.cangfengzhe.com/cdrfc/list_67.html 中文RFC集合

RFC发展历程

　　1969年,S·Crocker首先建立了RFC机制,其目的是建立一种快速共享Internet网络研究思想的方式,最初RFC是以书面形式分发的,后来有了FTP、Email,RFC就以在线电子文本的形式提供,当然现在通过WWW在很多站点可以很方便地访问RFC文档。 RFC一直以来主要是用于Internet的标准化,RFC是Internet开放性的产物,任何人都可以访问RFC,Internet这一致力于信息共享的网络首先共享的就是以RFC形式出现的涉及其自身研究、设计和使用的信息。这一独特的方式对于Internet的发展、完善具有相当关键的作用。发展到现在,RFC文档已不仅仅是关于Internet标准的文档了,而且也不局限于TCP/IP范围,它几乎包含了与计算机通信有关的任何内容,全面反映Internet研究、发展的过程。 RFC主要是IAB、IETF、IESG、ISOC的工作成果,主要由IETF起草,由IAB指导下的RFC 编辑(Editor)直接负责RFC的发表。每一个RFC文档有一个编号,这个编号永不重复,也就是说,由于技术进步等原因,即使是关于同一问题的RFC,也要使用新的编号,而不会使用原来的编号,时至今日,RFC编号已经排到2200多,在查找RFC时,一定要注意最新的RFC。

RFC的分类

　　RFC文档大致可以分为以下几类。

　　1.STD RFC

　　按照RFC1311的定义,STD RFC是指那些已经或者致力于成为Internet标准的RFC。只有经过完全Internet标准化过程的RFC才可以有STD编号,STD编号是不变的,而其涉及到的 RFC文档可能不只一个,其RFC编号也会更新。如STD13(Domain Name System)就涉及RFC1 034和RFC1035。 STD的标准化过程要经过几个步骤,首先由IETF起草标准(也可能是其他组织和个人, 但一般都是和IETF共同完成的),形成Internet Draft(ID),ID没有RFC编号。如果ID在6个月内IESG没有建议成为RFC,则取消此ID。成为RFC后,还要经过一系列的审查、修订、测试等才能最终成为Internet标准。

　　2.BCP RFC

　　由于Internet应用领域广泛,各种不同的组织有不同的使用目的和使用规则,IETF除了建议STD以外,也有必要对于Internet的使用和管理提供一些一般性的指导,同时也为I ETF、IAB、IESG提供一种渠道,以便推动某一方面的工作,反映其技术趋向,反映这些组织本身的工作进展。于是,1995年以RFC1818定义了BCP,即Best Current Practice。BCP同时有一个BCP编号和一个RFC编号,一旦约定了一个BCP编号,就不会再变,而其RFC编号则可能会经过修订不断更新。例如反映Internet标准化工作程序的BCP9的RFC编号就从RFC16 02上升到RFC2026,相应地就废弃了RFC1602。 BCP在发表以前,以电子邮件的形式广泛征求IETF的意见,经过IESG的审查,通过后即正式发表。但是BCP本身不是Internet标准。

　　3.FYI RFC

　　FYI是For Your Information的简写,1990年发表的RFC1150(FYI1)定义了FYI,FYI也同时有一个FYI编号和一个RFC编号,FYI编号是固定的。FYI主要是提供有关Internet的知识性内容。如FYI4(RFC1594),"Answers to Commonly asked New Internet User Quest ions"。所有的FYI在提交到RFC编辑以前,必须先经过IETF的User Services WorkingGro up审查。

　　4.其他RFC

　　除了STD、BCP、FYI以外还有其他一些RFC。从RFC899开始,所有以99结尾的RFC都是对此前99个RFC的一个概括。如RFC1999就是对RFC1900到RFC1999的一个简单概括。除了上述分类以外,还有一些描述RFC的方法。与Internet标准化过程(Internet Standards Process)有关的规范可以分为两类,即 Technical Specification(TS),Applicability Statement(AS)。TS是对协议、规则、格式、实用程序的描述。AS是描述在何种环境,以及怎样在Internet中使用TS;AS所涉及的并不一定全是Internet标准,比如IEEE、ITU、ISO组织的一些标准,大家所熟悉的ASCII标准就是一例。AS应该对其涉及的TS规定相应的级别"Requirement Level",这些"Require ment Level"如下: ·Required(Req),相当于必须实现,如IP、ICMP; ·Recommended(Rec),鼓励使用,如TELNET; ·Elective(Elc),可选择的; ·Limited Use,只限于特定的用户,一般说来用于对一些新的协议做试验; ·Not Recommended,不要使用,很可能是过时的。 "Maturity Level"也是用来描述TS和AS的一种方式,它反映这些标准是否成熟。对于致力于成为STD的TS和AS有三种"Maturity Level"。 ·Proposed Standard,基本成熟,但还需要进一步的试验证实其可行性。除非是用来验证该协议的可行性,不要将其视为标准实现。 ·Draft Standard,需要两个独立的,而且具有相互操作性的实例验证该协议的每一个方面。可以将其视为最终的标准草案; ·Internet Standard,最终的Internet标准,同时赋予一个STD编号。除此之外的TS和AS分为以下几种"Maturity Level"。 ·Experimental,一般是反映一些研究和开发的成果,只应将此看作是一般性的信息。 ·Informational,反映与Internet标准有关的一般性信息。有些也是有关非Intern et组织开发的一些协议,但必须得到协议开发者的许可。 ·Historic,是一些被新的标准取代或者是已经过时废弃不用的标准。 STD1(RFC2200)——Internet Official Protocol Standards,定期更新,反映最新的 Internet标准。另外,对于关注Internet的人来说,应该经常注意查阅BCP9的最新内容。

ゞ沉默是金ゞ 2010-07-07 09:34 发表评论