博文
RFC中文文档(2010-05-22 14:59:00)
摘要：http://man.chinaunix.net/develop/rfc/default.htm......
tcp长连接和短连接(2010-04-30 10:22:00)
摘要：TCP/IP通信程序设计的丰富多样性 (转)
刚接触TCP/IP通信设计的人根据范例可以很快编出一个通信程
序，据此一些人可能会认为TCP/IP编程很简单。其实不然，
TCP/IP编程具有较为丰富的内容。其编程的丰富性主要体现在
通信方式和报文格式的多样性上。
一。通信方式
主要有以下三大类:
(一)SERVER/CLIENT方式
1.一个Client方连接一个Server方，或称点对点(peer to peer)：
2.多个Client方连接一个Server方，这也是通常的并发服务器方式。
3.一个Client方连接多个Server方，这种方式很少见，主要
用于一个客户向多个服务器发送请求情况。
(二)连接方式
1.长连接
Client方与Server方先建立通讯连接，连接建立后不断开，
然后再进行报文发送和接收。这种方式下由于通讯连接一直
存在，可以用下面命令查看连接是否建立：
netstat –f inet|grep 端口号(如5678)。
此种方式常用于点对点通讯。
2.短连接
Client方与Server每进行一次报文收发交易时才进行通讯连
接，交易完毕后立即断开连接。此种方式常用于一点对多点
通讯，比如多个Client连接一个Server.
(三)发送接收方式
1.异步
报文发送和接收是分开的，相互独立的，互不影响。这种方
式又分两种情况：
(1)异步双工：接收和发送在同一个程序中，有两个不同的
子进程分别负责发送和接收
(2)异步单工：接收和发送是用两个不同的程序来完成。
2.同步
报文发送和接收是同步进行，既报文发送后等待接收返回报文。
同步方式一般需要考虑超时问题，即报文发上去后不能无限等
待，需要设定超时时间，超过该时间发送方不再等待读返回报
文，直接通知超时返回。
实际通信方式是这三类通信方式的组合。比如一般书上提供的
TCP/IP范例程序大都是同步短连接的SERVER/CLIENT程序。有的
组合是基本不用的，比较常用的有价值的组合是以下几种：
同步短连接Server/Client
同步长连接Server/Client
异步短连接Server/Clien......
HTTP协议 - Method Definitions(2009-02-27 15:50:00)
摘要：方法定义（Method Definitions）
通用的HTTP/1.0的方法集将在下面定义，虽然该方法集可以扩展，但并不保证附加的
方法能够被扩展的客户端和服务器端所支持。
8.1 GET
GET方法就是以实体方式得到由请求URI所指定资源的信息。如果请求URI只是一个
数据产生过程，那么最终要在回应实体中返回的是由该处理过程的结果所指向的资源，而不
是返回该处理过程的描述文字，除非那段文字恰好是处理的输出。
如果请求消息包含If-Modified-Since标题域，GET方法的语法就变成“条件GET”，即
“（conditional GET）”。条件GET方法可以对指定资源进行判断，如果它在If-Modified-Since
标题域（见10.9节）中的指定日期后发生了更新，才启动传输，否则不传输。这种条件GET
允许被缓存的实体在不必经过多次请求或不必要的数据传输就能进行刷新，从而有助于降低
网络负载。
8.2 HEAD
HEAD方法与GET几乎一样，区别在于，HEAD方法不让服务器在回应中返回任何实
体。对HEAD请求的回应部分来说，它的HTTP标题中包含的元信息与通过GET请求所得
到的是相同的。通过使用这种方法，不必传输整个实体主体，就可以得到请求URI所指定
资源的元信息。该方法通常用来测试超链接的合法性、可访问性及最近更新。
与条件GET不同，不存在所谓的“条件HEAD”，即"conditional HEAD"。即使在HEAD
请求中指定If-Modified-Since标题域，它也会被忽略。
8.3 POST
POST方法用来向目的服务器发出请求，要求它接受被附在请求后的实体，并把它当作
请求队列（Request-Line）中请求URI所指定资源的附加新子项。POST被设计成用统一的
方法实现下列功能：
o 对现有资源的注释（Annotation of existing resources）；
o 向电子公告栏、新闻组，邮件列表或类似讨论组发送......
SSL密钥协商的形象化比喻(2009-02-26 16:50:00)
摘要：来源
http://www.net130.com/2004/5-28/202246-2.html
我们假设A与B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。
A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH，摘要算法有MD5和SHA。
B：我们用DES－RSA－SHA这对组合好了。
这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书发给A）。
目前没有别的可说的了。
A：（查看证书上B的名字是否无误，并通过手头早已有的CA的证书验证了B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性）
（产生一份秘密消息，这份秘密消息处理后将用作加密密钥，加密初始化向量和hmac的密钥。将这份秘密消息-协议中称为per_master_secret- 用B的公钥加密，封装成称作ClientKeyExchange的消息。由于用了B的公钥，保证了第三方无法窃听）
我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B）
注意，下面我就要用加密的办法给你发消息了！
（将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥）
[我说完了]
B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥，这时双方已经安全的协商出一套加密办法了）
注意，我也要开始用加密的办法给你发消息了！
[我说完了]
A: [我的秘密是...]
B: [其它人不会听到的...] ......
RFC792：Internet 控制信息协议（ICMP）(2009-01-15 15:56:00)
摘要：
不停的积累protocol
1. 介绍
在被称为 Catenet 的系统中，IP 协议被用作主机到主机的数据报服务。网络连接设备称为网关。这些网关通过网关到网关协议（GGP）相互交换用于控制的信息。通常，网关或目的主机将和源主机通信，例如，为报告在数据报过程中的错误。为了这个目的才使用了 ICMP，它使用 IP 做为底层支持，好象它是一个高层协议，而实际上它是 IP 的一部分，每一种 IP 模块必须实现 ICMP。
ICMP 消息在以下几种情况下发送：当数据报不能到达目的地时，当网关的已经失去缓存功能，当网关能够引导主机在更短路由上发送。
IP 并非设计为绝对可靠，这个协议的目的是为了当网络出现问题的时候返回控制信息，而不是使 IP 协议变得绝对可靠，并不保证数据报或控制信息能够返回。一些数据报仍将在没有任何报告的情况下丢失。上层协议必须使用自己的差错控制程序来判断通信是否正确。
ICMP 信息通常报告在处理数据报过程中的错误。若要避免信息无限制地返回，对于 ICMP 消息不会单独成包发送，而且 ICMP 信息只在处理数据报偏移量为 0 时发送。
2. 消息格式
ICMP 消息以基本 IP 头发送。数据的第一个字节是 ICMP 类型域；此域的值决定了了其余数据的格式。任何标记为 " 未使用 " 的域都是为以后的扩展保留的，在传送过程中必须全部是 0 。除非在个别的格式之下，包头域如下格式：
版本： 4
IHL ： Internet 头长度大小以 32 位字为单位。
服务类型： 0 · 总长度：包头长度和数据长度。
标识符（ Identification ）、标志（ Flags ）、段偏移量：在分段时使用。
生存周期：以秒计，此域在每台机器处理数据报时减少，此值必须大于要传送它的网关所消耗的时间。
协议： ICMP = 1
包头校验码： 16 位数据反码和再取反而得。为计算校验码，此域应该为 0 。在将来可以会取代这一域。
源地址：创建 ICMP 信息的网关或主机地址，除非说明，它可以是任何网关地址。
目的地址：信息要发送到的网关或主机地址。
......
HTTP协议--Status Code and Reason Phrase(2009-01-08 10:13:00)
摘要：老忘记这些，就把它给摘了下来
6.1 状态行 （Status-Line）
响应消息的第一行是状态行（stauts-Line），由协议版本以及数字状态码和相关的文本短语组成,各部分间用空格符隔开，除了最后的回车或换行外，中间不允许有回车换行．
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
6.1.1状态码与原因短语 （Status Code and Reason Phrase）
状态码是试图理解和满足请求的三位数字的整数码，这些码的完整定义在第十章。原因短语（Reason-Phrase）是为了给出的关于状态码的文本描述。状态码用于控制条件，而原因短语（Reason-Phrase）是让用户便于阅读。客户端不需要检查和显示原因短语。
状态码的第一位数字定义响应类型。后两位数字没有任何分类角色。第一位数字有五种值：
-1xx: 报告的 - 接收到请求，继续进程.
-2xx 成功 - 步骤成功接收，被理解，并被接受
-3xx 重发 - 为了完成请求,必须采取进一步措施.
-4xx 客户端出错 - 请求包括错的顺序或不能完成.
-5xx 服务器出错 - 服务器无法完成显然有效的请求.
下面列举了为HTTP/1.1定义的态码值，和对应的原因短语（Reason-Phrase）的例子。原因短语在这里例举只是建议性的----它们也许被一个局部的等价体代替而不会影响此协议的语义。
Status-Code ＝
"100" ; 10.1.1节: 继续
&n......