南北双线，100M独享，九江机房独立机柜，1年8W RMB（相当于只付了电费）
服务器，联想，奥运备用服务器，1台2K RMB（比普通家用电脑还便宜啊啊啊）
真的是白菜价了。。。
好吧，一般人找不到这颗白菜就是了= =
Archive for the ‘Web’ category
这年头什么都白菜价了么。。。
August 28th, 2009
[转]HTTP协议详解
June 18th, 2009Author :Jeffrey
引言
HTTP是一个属于应用层的 面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW 中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。
HTTP协议的主要特点可概括如下：
1.支持客户/服务器模式。
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
一、HTTP协议详解之URL篇
http（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。
HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：
http://host[":"port][abs_path]
http 表示要通过HTTP协议来定位网络资源；host表示合法的Internet主机域名或者IP地址；port指定一个端口号，为空则使用缺省端口 80；abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作 浏览器自动帮我们完成。
eg:
1、输入：www.guet.edu.cn
浏览器自动转换成：http://www.guet.edu.cn/
2、http:192.168.0.116:8080/index.jsp
二、HTTP协议详解之请求篇
http请求由三部分组成，分别是：请求行、消息报头、请求正文
1、请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：Method Request-URI HTTP-Version CRLF
其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。
请求方法（所有方法全为大写）有多种，各个方法的解释如下：
GET 请求获取Request-URI所标识的资源
POST 在Request-URI所标识的资源后附加新的数据
HEAD 请求获取由Request-URI所标识的资源的响应消息报头
PUT 请求服务器存储一个资源，并用Request-URI作为其标识
DELETE 请求服务器删除Request-URI所标识的资源
TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留将来使用
OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求
应用举例：
GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源，eg:GET /form.html HTTP/1.1 (CRLF)
POST方法要求被请求服务器接受附在请求后面的数据，常用于提交表单。
eg：POST /reg.jsp HTTP/ (CRLF)
Accept:image/gif,image/x-xbit,… (CRLF)
…
HOST:www.guet.edu.cn (CRLF)
Content-Length:22 (CRLF)
Connection:Keep-Alive (CRLF)
Cache-Control:no-cache (CRLF)
(CRLF) //该CRLF表示消息报头已经结束，在此之前为消息报头
user=jeffrey&pwd=1234 //此行以下为提交的数据
HEAD方法与GET方法几乎是一样的，对于HEAD请求的回应部分来说，它的HTTP头部中包含的 信息与通过GET请求所得到的信息是相同的。利用这个方法，不必传输整个资源内容，就可以得到Request-URI所标识的资源的信息。该方法常用于测 试超链接的有效性，是否可以访问，以及最近是否更新。
2、请求报头后述
3、请求正文(略)
三、HTTP协议详解之响应篇
在接收和解释请求消息后，服务器返回一个HTTP响应消息。
HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文
1、状态行格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。
状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：
1xx：指示信息–表示请求已接收，继续处理
2xx：成功–表示请求已被成功接收、理解、接受
3xx：重定向–要完成请求必须进行更进一步的操作
4xx：客户端错误–请求有语法错误或请求无法实现
5xx：服务器端错误–服务器未能实现合法的请求
常见状态代码、状态描述、说明：
200 OK //客户端请求成功
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报 //头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后， //可能恢复正常
eg：HTTP/1.1 200 OK （CRLF）
2、响应报头后述
3、响应正文就是服务器返回的资源的内容
四、HTTP协议详解之消息报头篇
HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。
HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。
每一个报头域都是由名字+“：”+空格+值 组成，消息报头域的名字是大小写无关的。
1、普通报头
在普通报头中，有少数报头域用于所有的请求和响应消息，但并不用于被传输的实体，只用于传输的消息。
eg：
Cache-Control 用于指定缓存指令，缓存指令是单向的（响应中出现的缓存指令在请求中未必会出现），且是独立的（一个消息的缓存指令不会影响另一个消息处理的缓存机制），HTTP1.0使用的类似的报头域为Pragma。
请求时的缓存指令包括：no-cache（用于指示请求或响应消息不能缓存）、no-store、max-age、max-stale、min-fresh、only-if-cached;
响应时的缓存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.
eg：为了指示IE浏览器（客户端）不要缓存页面，服务器端的JSP程序可以编写如下：response.sehHeader(”Cache-Control”,”no-cache”);
//response.setHeader(”Pragma”,”no-cache”);作用相当于上述代码，通常两者//合用
这句代码将在发送的响应消息中设置普通报头域：Cache-Control:no-cache
Date普通报头域表示消息产生的日期和时间
Connection普通报头域允许发送指定连接的选项。例如指定连接是连续，或者指定“close”选项，通知服务器，在响应完成后，关闭连接
2、请求报头
请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。
常用的请求报头
Accept
Accept请求报头域用于指定客户端接受哪些类型的信息。eg：Accept：image/gif，表明客户端希望接受GIF图象格式的资源；Accept：text/html，表明客户端希望接受html文本。
Accept-Charset
Accept-Charset请求报头域用于指定客户端接受的字符集。eg：Accept-Charset:iso-8859-1,gb2312.如果在请求消息中没有设置这个域，缺省是任何字符集都可以接受。
Accept-Encoding
Accept-Encoding请求报头域类似于Accept，但是它是用于指定可接受的内容编码。eg：Accept-Encoding:gzip.deflate.如果请求消息中没有设置这个域服务器假定客户端对各种内容编码都可以接受。
Accept-Language
Accept-Language请求报头域类似于Accept，但是它是用于指定一种自然语言。eg：Accept-Language:zh-cn.如果请求消息中没有设置这个报头域，服务器假定客户端对各种语言都可以接受。
Authorization
Authorization请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（未授权），可以发送一个包含Authorization请求报头域的请求，要求服务器对其进行验证。
Host（发送请求时，该报头域是必需的）
Host请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的，eg：
我们在浏览器中输入：http://www.guet.edu.cn/index.html
浏览器发送的请求消息中，就会包含Host请求报头域，如下：
Host：www.guet.edu.cn
此处使用缺省端口号80，若指定了端口号，则变成：Host：www.guet.edu.cn:指定端口号
User-Agent
我 们上网登陆论坛的时候，往往会看到一些欢迎信息，其中列出了你的操作系统的名称和版本，你所使用的浏览器的名称和版本，这往往让很多人感到很神奇，实际 上，服务器应用程序就是从User-Agent这个请求报头域中获取到这些信息。User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它 属性告诉服务器。不过，这个报头域不是必需的，如果我们自己编写一个浏览器，不使用User-Agent请求报头域，那么服务器端就无法得知我们的信息 了。
请求报头举例：
GET /form.html HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF)
Accept-Language:zh-cn (CRLF)
Accept-Encoding:gzip,deflate (CRLF)
If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)
If-None-Match:W/”80b1a4c018f3c41:8317″ (CRLF)
User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)
Host:www.guet.edu.cn (CRLF)
Connection:Keep-Alive (CRLF)
(CRLF)
3、响应报头
响应报头允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。
常用的响应报头
Location
Location响应报头域用于重定向接受者到一个新的位置。Location响应报头域常用在更换域名的时候。
Server
Server响应报头域包含了服务器用来处理请求的软件信息。与User-Agent请求报头域是相对应的。下面是
Server响应报头域的一个例子：
Server：Apache-Coyote/1.1
WWW-Authenticate
WWW-Authenticate响应报头域必须被包含在401（未授权的）响应消息中，客户端收到401响应消息时候，并发送Authorization报头域请求服务器对其进行验证时，服务端响应报头就包含该报头域。
eg：WWW-Authenticate:Basic realm=”Basic Auth Test!” //可以看出服务器对请求资源采用的是基本验证机制。
4、实体报头
请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成，但并不是说实体报头域和实体正文要在一起发送，可以只发送实体报头域。实体报头定义了关于实体正文（eg：有无实体正文）和请求所标识的资源的元信息。
常用的实体报头
Content-Encoding
Content- Encoding实体报头域被用作媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容的编码，因而要获得Content-Type报头域中所 引用的媒体类型，必须采用相应的解码机制。Content-Encoding这样用于记录文档的压缩方法，eg：Content- Encoding：gzip
Content-Language
Content-Language实体报头域描述了资源所用的自然语言。没有设置该域则认为实体内容将提供给所有的语言阅读
者。eg：Content-Language:da
Content-Length
Content-Length实体报头域用于指明实体正文的长度，以字节方式存储的十进制数字来表示。
Content-Type
Content-Type实体报头域用语指明发送给接收者的实体正文的媒体类型。eg：
Content-Type:text/html;charset=ISO-8859-1
Content-Type:text/html;charset=GB2312
Last-Modified
Last-Modified实体报头域用于指示资源的最后修改日期和时间。
Expires
Expires 实体报头域给出响应过期的日期和时间。为了让代理服务器或浏览器在一段时间以后更新缓存中(再次访问曾访问过的页面时，直接从缓存中加载，缩短响应时间和 降低服务器负载)的页面，我们可以使用Expires实体报头域指定页面过期的时间。eg：Expires：Thu，15 Sep 2006 16:23:12 GMT
HTTP1.1的客户端和缓存必须将其他非法的日期格式（包括0）看作已经过期。eg：为了让浏览器不要缓存页面，我们也可以利用Expires实体报头域，设置为0，jsp中程序如下：response.setDateHeader(”Expires”,”0″);
五、利用telnet观察http协议的通讯过程
实验目的及原理：
利用MS的telnet工具，通过手动输入http请求信息的方式，向服务器发出请求，服务器接收、解释和接受请求后，会返回一个响应，该响应会在telnet窗口上显示出来，从而从感性上加深对http协议的通讯过程的认识。
实验步骤：
1、打开telnet
1.1 打开telnet
运行–>cmd–>telnet
1.2 打开telnet回显功能
set localecho
2、连接服务器并发送请求
2.1 open www.guet.edu.cn 80 //注意端口号不能省略
HEAD /index.asp HTTP/1.0
Host:www.guet.edu.cn
/*我们可以变换请求方法,请求桂林电子主页内容,输入消息如下*/
open www.guet.edu.cn 80
GET /index.asp HTTP/1.0 //请求资源的内容
Host:www.guet.edu.cn
2.2 open www.sina.com.cn 80 //在命令提示符号下直接输入telnet www.sina.com.cn 80
HEAD /index.asp HTTP/1.0
Host:www.sina.com.cn
3 实验结果：
3.1 请求信息2.1得到的响应是:
HTTP/1.1 200 OK //请求成功
Server: Microsoft-IIS/5.0 //web服务器
Date: Thu,08 Mar 200707:17:51 GMT
Connection: Keep-Alive
Content-Length: 23330
Content-Type: text/html
Expries: Thu,08 Mar 2007 07:16:51 GMT
Set-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/
Cache-control: private
//资源内容省略
3.2 请求信息2.2得到的响应是:
HTTP/1.0 404 Not Found //请求失败
Date: Thu, 08 Mar 2007 07:50:50 GMT
Server: Apache/2.0.54 <Unix>
Last-Modified: Thu, 30 Nov 2006 11:35:41 GMT
ETag: “6277a-415-e7c76980″
Accept-Ranges: bytes
X-Powered-By: mod_xlayout_jh/0.0.1vhs.markII.remix
Vary: Accept-Encoding
Content-Type: text/html
X-Cache: MISS from zjm152-78.sina.com.cn
Via: 1.0 zjm152-78.sina.com.cn:80<squid/2.6.STABLES-20061207>
X-Cache: MISS from th-143.sina.com.cn
Connection: close
失去了跟主机的连接
按任意键继续…
4 .注意事项：1、出现输入错误，则请求不会成功。
2、报头域不分大小写。
3、更深一步了解HTTP协议，可以查看RFC2616，在http://www.letf.org/rfc上找到该文件。
4、开发后台程序必须掌握http协议
1、基础：
高层协议有：文件传输协议FTP、电子邮件传输协议SMTP、域名系统服务DNS、网络新闻传输协议NNTP和HTTP协议等
中 介由三种：代理(Proxy)、网关(Gateway)和通道(Tunnel)，一个代理根据URI的绝对格式来接受请求，重写全部或部分消息，通过 URI的标识把已格式化过的请求发送到服务器。网关是一个接收代理，作为一些其它服务器的上层，并且如果必须的话，可以把请求翻译给下层的服务器协议。一 个通道作为不改变消息的两个连接之间的中继点。当通讯需要通过一个中介(例如：防火墙等)或者是中介不能识别消息的内容时，通道经常被使用。
代理(Proxy)：一个中间程序，它可以充当一个服务器，也可以充当一个客户机，为其它客户机建立请求。请求是通过可能的翻译在内部或经过传递到其它的 服务器中。一个代理在发送请求信息之前，必须解释并且如果可能重写它。代理经常作为通过防火墙的客户机端的门户，代理还可以作为一个帮助应用来通过协议处 理没有被用户代理完成的请求。
网关(Gateway)：一个作为其它服务器中间媒介的服务器。与代理不同的是，网关接受请求就好象对被请求的资源来说它就是源服务器；发出请求的客户机并没有意识到它在同网关打交道。
网关经常作为通过防火墙的服务器端的门户，网关还可以作为一个协议翻译器以便存取那些存储在非HTTP系统中的资源。
通道(Tunnel)：是作为两个连接中继的中介程序。一旦激活，通道便被认为不属于HTTP通讯，尽管通道可能是被一个HTTP请求初始化的。当被中继 的连接两端关闭时，通道便消失。当一个门户(Portal)必须存在或中介(Intermediary)不能解释中继的通讯时通道被经常使用。
2、协议分析的优势—HTTP分析器检测网络攻击
以模块化的方式对高层协议进行分析处理，将是未来入侵检测的方向。
HTTP及其代理的常用端口80、3128和8080在network部分用port标签进行了规定
3、HTTP协议Content Lenth限制漏洞导致拒绝服务攻击
使 用POST方法时，可以设置ContentLenth来定义需要传送的数据长度，例如ContentLenth:999999999，在传送完成前，内 存不会释放，攻击者可以利用这个缺陷，连续向WEB服务器发送垃圾数据直至WEB服务器内存耗尽。这种攻击方法基本不会留下痕迹。
http://www.cnpaf.net/Class/HTTP/0532918532667330.html
4、利用HTTP协议的特性进行拒绝服务攻击的一些构思
服务器端忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求（毕竟客户端的正常请求比率非常之小），此时从正常客户的角度看来，服务器失去响应，这种情况我们称作：服务器端受到了SYNFlood攻击（SYN洪水攻击）。
而Smurf、TearDrop等是利用ICMP报文来Flood和IP碎片攻击的。本文用“正常连接”的方法来产生拒绝服务攻击。
19 端口在早期已经有人用来做Chargen攻击了，即Chargen_Denial_of_Service，但是！他们用的方法是在两台Chargen 服务器之间产生UDP连接，让服务器处理过多信息而DOWN掉，那么，干掉一台WEB服务器的条件就必须有2个：1.有Chargen服务2.有HTTP 服务
方法：攻击者伪造源IP给N台Chargen发送连接请求（Connect），Chargen接收到连接后就会返回每秒72字节的字符流（实际上根据网络实际情况，这个速度更快）给服务器。
5、Http指纹识别技术
Http指纹识别的原理大致上也是相同的：记录不同服务器对Http协议执行中的微小差别进行识别.Http指纹识别比TCP/IP堆栈指纹识别复杂许 多,理由是定制Http服务器的配置文件、增加插件或组件使得更改Http的响应信息变的很容易,这样使得识别变的困难；然而定制TCP/IP堆栈的行为 需要对核心层进行修改,所以就容易识别.
要让服务器返回不同的Banner信息的设置是很简单的,象Apache这样的开放源代码的Http服务器,用户可以在源代码里修改Banner信息,然 后重起Http服务就生效了；对于没有公开源代码的Http服务器比如微软的IIS或者是Netscape,可以在存放Banner信息的Dll文件中修 改,相关的文章有讨论的,这里不再赘述,当然这样的修改的效果还是不错的.另外一种模糊Banner信息的方法是使用插件。
常用测试请求：
1：HEAD/Http/1.0发送基本的Http请求
2：DELETE/Http/1.0发送那些不被允许的请求,比如Delete请求
3：GET/Http/3.0发送一个非法版本的Http协议请求
4：GET/JUNK/1.0发送一个不正确规格的Http协议请求
Http指纹识别工具Httprint,它通过运用统计学原理,组合模糊的逻辑学技术,能很有效的确定Http服务器的类型.它可以被用来收集和分析不同Http服务器产生的签名。
6、其他：为了提高用户使用浏览器时的性能，现代浏览器还支持并发的访问方式，浏览一个网页时同时建立多个连接，以迅速获得一个网页上的多个图标，这样能更快速完成整个网页的传输。
HTTP1.1中提供了这种持续连接的方式，而下一代HTTP协议：HTTP-NG更增加了有关会话控制、丰富的内容协商等方式的支持，来提供
更高效率的连接。
原文链接：http://blog.csdn.net/gueter/archive/2007/03/08/1524447.aspx
几大出租房网站操作体验
April 17th, 20091. 58
其他的不做评论，在我把标题处理的只剩中文时仍然提示我“标题含特殊符号”，我就不懂了。发布失败
上传图片没有取消按钮，一度导致我中途卡住，无法进行操作，而且最多只能传4张
验证码直接显示，很容易就超时错误了，为啥不点击时再显示
2.赶集
体验很棒！发布信息的按钮做的很突出！58的发布按钮我就找了N久才找到！
小区选择的提示建议做的很到位，除了不支持多个字的首字母。
那个图片的高级上传相比其他网站做的很棒！不过直接显示高级也没什么的吧，普通上传完全可以取消嘛，而且就算有也可以不采用弹出窗口的形式嘛
3.焦点
差！
选小区，几百个小区在下拉菜单里，想找死人啊，更可怕的是从头找到尾没找到自己的小区。。。。
而且在FF,Chrome下JS效果完全没用，无法填房租。。。。发布失败
我说焦点怎么这么爱用下拉。。。楼层都来下拉。。。还最多99层。。。无语
那个视频难道有几个人传的吧。。。发布完了还得手机验证。。。彻底无语
mantis无法发送邮件至gmail的解决办法
March 13th, 20091. gmail采用的是SSL，在config.inc.php里配置
$g_phpMailer_method = 2;
$g_smtp_host = ’ssl://smtp.gmail.com:465′;
$g_smtp_username = ‘address@mydomain.com’;
$g_smtp_password = ‘myPassword’;
2. 更新class.phpmailer.php, SmtpConnect() function fixed to deal with both the protocol and port being in the host string (it assumes only one colon in the host string)
3. 确认php开启openssl扩展，重新开启扩展的话记得重启web server
参考http://www.mantisbt.org/bugs/view.php?id=8369
MSN Messenger协议 原作：bhw98
March 5th, 2009前 言
MSN Messenger 是Microsoft开发的聊天工具，目前在国内拥有很大的用户群。使用MSN Messenger可以与他人进行文字聊天，语音对话，视频会议等即时交流，还可以通过此软件来查看联系人是否联机等。该软件的最新版本是6.1。
1999年，Microsoft向IETF提交了一份”MSN Messenger Service 1.0 Protocol”草案，这是最初版本的MSN Messenger协议。在以后几年，该公司不再公开有关MSN Messenger协议的升级、修改细节的官方文档。但无论是开发第三方的聊天客户端软件(如Gaim, MyIM等)，还是做协议分析，必须对其通信协议有深入了解。正因为如此，有一些民间人士对这些协议开展了研究(见本文的”相关资源“一节)。
当我们还在感叹”这世界，变化快”的时候，MSN Messenger的协议已经到了第10版，简称MSNP10，对应于MSN Messenger 6.1。MSN Messenger 6.0则使用MSNP9。现在Microsoft强迫MSN Messenger用户升级到6.0或6.1版，因为服务器对MSNP8以下的版本不再支持。本文及后续文章所描述的MSN Messenger协议主要针对MSNP9/MSNP10。
1. 连 接
MSN Messenger协议建立在TCP/IP之上。除了文件传输和语音聊天是直接的”点对点”通信之外，其它所有的情形全部通过服务器进行。
在逻辑上，一共有三种类型的服务器，各司其职：
XXX[<SP>TrID<SP>PARAM1<SP>PARAM2…]<CRLF>
其中，<SP>是空白字符，<CRLF>是回车换行，XXX是一个3字符的命令串，TrID是一个流水号，PARAMx是 参数，[ ]内是可选项。最简单的命令没有流水号和参数。为了方便起见，下面讨论时用” “代表<SP>，”\r\n”代表<CRLF>，”\x??”代表一个值为0x??字节。红色表示由客户端发出，蓝色表示由服务 器发出。一个MSN Messenger命令的例子如下：
USR 18 TWN I example@hotmail.com\r\n
3. 错 误
无论是由于客户端发出的命令无效，参数无效，还是其他什么原因，服务器可以返回一个错误。格式为
XXX[<SP>TrID]<CRLF>
其中，XXX是一个3位数字的串。如
ADD 21 AL non_existent@passport.com non_existent@passport.com\r\n 205 21\r\n
上例中，non_existent@passport.com是一个不存在的账号。
4. 消 息
MSN Messenger消息符合MIME 1.0标准，由消息头与消息体组成。通常使用UTF-8编码，消息头中也需要URL编码格式，消息体则直接用二进制数据。
一个MSN Messenger消息的例子如下：
MIME-Version: 1.0\r\n Content-Type: text/plain; charset=UTF-8\r\n X-MMS-IM-Format: FN=%E5%AE%8B%E4%BD%93; EF=; CO=0; CS=86; PF=0\r\n \r\n bhw98\xE4\xBD\xA0\xE5\xA5\xBD\xEF\xBC\x81
经简单分析可知，”%E5%AE%8B%E4%BD%93″是”宋体”的UTF-8加URL编码，而”bhw98\xE4\xBD\xA0\xE5\xA5\xBD\xEF\xBC\x81″是”bhw98你好！”的UTF-8编码。
命令一览
| 命令 | 来源 | 去向 | 说明 | 备注 |
| ACK | SS | Client | 确认，做出肯定回答。 | acknowledgement |
| ADD | Client | NS | 发出添加新联系人到列表的请求。 | add user |
| NS | Client | 返回添加新联系人请求的应答。 | ||
| ADG | Client | NS | 发出添加新联系人组请求。 | add group |
| NS | Client | 返回添加新联系人组请求的应答。 | ||
| ANS | Client | SS | 接受聊天连接请求。 | answer |
| BLP | Client | NS | 设置对尚未列入明确允许/禁止的联系人列表的保密策略。 | block list privacy |
| NS | Client | 返回设置保密策略请求的应答。 | ||
| BYE | SS | Client | 通知客户端结束会话。 | bye |
| CAL | Client | SS | 发出建立聊天连接的请求。 | call |
| SS | Client | 返回建立聊天连接请求的应答。 | ||
| CHG | Client | NS | 发出改变状态的请求。 | change state |
| NS | Client | 返回改变状态的应答。 | ||
| CHL | NS | Client | 服务器发出验证要求。 | challenge |
| SS | Client | |||
| CVR | Client | NS | 发出客户端的OS、语言、MSN Messenger版本等信息。 | client version |
| Client | SS | |||
| NS | Client | 返回推荐的MSN Messenger版本、升级软件需要的下载地址等信息。 | ||
| SS | Client | |||
| FLN | NS | Client | 通知有联系人列表中的用户下线。 | off-line |
| GTC | Client | NS | 设置当有联系人列表中的用户状态改变时给出的提示。 | greeting to changes? |
| NS | Client | 返回设置请求的应答。 | ||
| INF | Client | NS | 询问服务器所支持的认证方式。 | information? |
| Client | SS | |||
| NS | Client | 返回服务器所支持的认证方式。 | ||
| SS | Client | |||
| ILN | NS | Client | 当客户端登录或添加联系人到列表时，通知列表中的联系人的状态。 | initial online state |
| IRO | SS | Client | 当有新用户加入聊天连接时，通知客户端该连接中的用户名单。 | initial roster information |
| JIO | SS | Client | 通知客户端已经同另外的用户建立了聊天连接。 | jion |
| LSG | Client | NS | 发出获取联系人组列表的请求。 | list groups |
| NS | Client | 返回获取联系人组列表请求的应答。 | ||
| LST | Client | NS | 发出获取联系人列表的请求。 | list |
| NS | Client | 返回获取联系人列表请求的应答。 | ||
| MSG | Client | SS | 发送消息到其他用户(聊天对象)。 | message |
| NS | Client | 传递服务器(系统) 的消息到客户端。 | ||
| SS | Client | 传递其他用户(聊天对象)的消息到客户端。 | ||
| NAK | SS | Client | 做出否定回答。 | negative acknowledgement |
| NLN | NS | Client | 通知客户端联系人上线或改变状态。 | on-line |
| OUT | All | All | 结束客户端-服务器的连接。 | out |
| PNG | Client | NS | 测试TCP连接状态。 | ping |
| Client | SS | |||
| PRP | Client | NS | 发出设置个人电话号码的请求。 | personal phone number |
| NS | Client | 返回设置请求的应答 | ||
| PNG | Client | NS | 测试TCP连接状态。 | ping |
| Client | SS | |||
| QNG | NS | Client | 返回测试TCP连接状态的应答。 | quiz ping? |
| SS | Client | |||
| QRY | Client | NS | 客户端回答服务器的验证要求。 | quiz reply? |
| Client | SS | |||
| REA | Client | NS | 发出修改用户昵称的请求。 | rename nickname |
| NS | Client | 返回修改用户昵称请求的应答。 | ||
| REG | Client | NS | 发出修改联系人组的请求。 | rename group |
| NS | Client | 返回修改联系人组请求的应答。 | ||
| REM | Client | NS | 发出从联系人列表中删除用户的请求。 | rename user |
| NS | Client | 返回删除用户请求的应答。 | ||
| RMG | Client | NS | 发出删除联系人组的请求。 | remove group |
| NS | Client | 返回删除联系人组请求的应答。 | ||
| RNG | NS | Client | 通知客户端有人要建立聊天连接。 | ring |
| SYN | Client | NS | 客户端-服务器同步。 | synchronization |
| NS | Client | |||
| URL | Client | NS | 发出获取MSN服务URL的请求。 | URL |
| NS | Client | 返回获取URL请求的应答。 | ||
| USR | All | All | 声明、传递、鉴别用户身份。 | user |
| VER | Client | DS | 协商MSN Messenger协议版本。 | version |
| Client | NS | |||
| DS | Client | |||
| NS | Client | |||
| XFR | DS | Client | 向客户端分配NS（通知客户端转向连接指定的NS）。 | transfer |
| Client | NS | 发出分配SS的请求。 | ||
| NS | Client | 返回分配SS请求的应答。 |
MSN Messenger协议–错误代码一览
| 代码 | 含义 | 可能的命令 | 错误示例 | 备注 |
| 200 | 非法命令 | ABC 18\r\n 200 18\r\n |
||
| 201 | 非法参数 | CHG 19 FLN 0\r\n 201 19\r\n ADD 20 AL aaa@bbb@ccc aaa@bbb@ccc\r\n 201 20\r\n |
||
| 205 | 用户不存在 | ADD | ADD 21 AL none@hotmail.com none@hotmail.com\r\n 205 21\r\n |
|
| 206 | 缺少域名 | |||
| 207 | 已经登录 | USR | USR 20 TWN I example@hotmail.com\r\n 207 20\r\n USR 21 TWN S 8d30fc782aa25ec9e1293fdda13cab42\r\n 207 21\r\n |
|
| 208 | 非法用户名 | CAL | CAL 2 @@hotmail.com\r\n 208 2\r\n |
|
| 209 | 非法用户昵称 | REA | REA 18 one@hotmail.com kill%20microsoft\r\n 209 18\r\n |
|
| 210 | 用户太多 | ADD | ADD 23 FL one@hotmail.com one@hotmail.com 0\r\n 210 23\r\n |
最大150 |
| 215 | 用户已在列表中 | ADD | ADD 36 FL one@hotmail.com one@hotmail.com 2\r\n ADD 36 825 FL one@hotmail.com one@hotmail.com 2\r\n ADD 37 FL one@hotmail.com one@hotmail.com 2\r\n 215 37\r\n |
|
| CAL | CAL 5 two@hotmail.com\r\n CAL 5 RINGING 213697\r\n CAL 6 two@hotmail.com\r\n 215 6\r\n |
|||
| 216 | 用户不在列表中 | REM | REM 14 FL three@hotmail.com\r\n 216 14\r\n |
|
| REA | REA 48 three@hotmail.com three\r\n 216 48\r\n |
|||
| CAL | CAL 2 three@hotmail.com\r\n 216 2\r\n |
|||
| 217 | 用户不在线 | CAL | CAL 2 two@hotmail.com\r\n 217 2\r\n |
|
| 218 | 已在指定模式 | BLP | BLP 17 BL\r\n BLP 17 151 BL\r\n BLP 18 BL\r\n 218 18\r\n |
|
| GTC | GTC 19 A\r\n GTC 19 152 A\r\n GTC 20 A\r\n 218 20\r\n |
|||
| 219 | 用户已经在相反的列表中 | ADD | ADD 15 AL four@hotmail.com four@hotmail.com\r\n ADD 15 AL 56 four@hotmail.com four\r\n ADD 16 BL four@hotmail.com four@hotmail.com\r\n 219 16\r\n |
|
| 223 | 用户组太多 | ADG | ADG 28 new%20group 0\r\n 223 28\r\n |
最大30 |
| 224 | 非法组号 | ADD | RMG 24 3\r\n RMG 24 11506 3\r\n ADD 25 FL five@hotmail.com 3\r\n 224 25\r\n |
|
| REM | RMG 24 3\r\n RMG 24 11506 3\r\n REM 25 FL five@hotmail.com 3\r\n 224 25\r\n |
|||
| REG | RMG 24 3\r\n RMG 24 11506 3\r\n REG 25 3 New%20Name 0\r\n 224 25\r\n |
|||
| RMG | RMG 24 3\r\n RMG 24 11506 3\r\n RMG 25 3\r\n 224 25\r\n |
|||
| 225 | 用户不在组中 | REM | REM 26 FL six@hotmail.com 3\r\n 225 26\r\n |
|
| 229 | 组名太长 | ADG | ADG 27 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 0\r\n 229 27\r\n |
最大60 |
| 230 | 不能删除组0 | RMG | RMG 28 0\r\n 230 28\r\n |
|
| 300 | 缺少必要的参数 | |||
| 302 | 尚未登录 | |||
| 500 | 服务器内部错误 | |||
| 540 | 验证应答错误 | |||
| 600 | 服务器忙 | |||
| 707 | 无法建立连接 | |||
| 910 | 服务器忙 | |||
| 911 | 身份验证失败 |
?过去的MSN Messenger版本(MSNP8以下)，简单地使用MD5等Hash算法对用户身份进行认证。MSNP9/MSNP10使用一种 TWN(Tweener)认证方式，通过SSL/TLS连接到login.passport.com和loginnet.passport.com等服务 器，借助于HTTP协议输入账号和密码，认证通过后，才能取得“入场券”。
真正意义上的身份认证，发生在客户端与通知服务器(NS)之间。客户端登陆NS时，首先交换版本信息。双方均支持MSNP8以上版本时，才能进行认证过程。如果客户端版本较低，不支持TWN，咋办？服务器会将你一脚揣出去，信不信？
好了，废话少说，现在拿一个成功认证的例子看看。在下面的例子中，账号是“example@passport.com”，密码是“password”。
VER 4 MSNP10 MSNP9 CVR0 \r\n
VER 4 MSNP9 CVR0 \r\n
CVR 5 0×0804 winnt 5.0 i386 MSNMSGR 6.1.0203 MSMSGS example@passport.com \r\n
CVR 5 6.0.0602 6.0.0602 5.0.0527 http://download.microsoft.com/download/d/4/f/d4f560d5-6dc6-4901-b149-a568415561d7/SETUPNT.EXE http://messenger.msn.com/cn \r\n
USR 6 TWN I example@passport.com \r\n
USR 6 TWN Slc=1033,id=507,tw=40,fs=1,ru=http%3A%2F%2Fmessenger%2Emsn%2Ecom,ct=1073355862,kpp=1,kv=5,ver=2.1.0173.1, tpf=ed1c2f217a21c191c61251eb8b73bb60 \r\n
(此时通过SSL进行身份认证，获得“入场券”)
USR 7 TWN S t=4m1wWfEupDgUNb53qys5gJdw8OTJEtT82fcuDbS3U672gTymOOs6cgKeafj7WjgZNcufAQggxqHRRXko02DoflZA$$ &p=4QXNnX9rFDDgki9ZqvqPZGDGJa2Mrd5H13Zfl0NNjh4I78qPyfpzmkZPZEe0nxJTkzZSNDYtk!57cVqiYVfO86KgCRYWhi2kudS0M !7bdi82EDA1FYp3WboHD!sCQ17OZh7lPQI7fozrgsSMZwgSzRi2FNTPxf13oDNIfDCKCG!2guDvZKEpk78A$$ \r\n
USR 7 OK example@passport.com example@passport.com 1 0 \r\n第一回合(TrID=4)，双方协商MSN版本号。客户端说“我能支持MSNP9和MSNP10”，NS说“行，就MSNP9吧”。
第二回合(TrID=5)，客户端报告本机信息：OS = Windows 2000 (NT 5.0), 语言 = 简体中文，MSN Messenger版本 = 6.1.0203, 账号 = example@passport.com。NS给出了推荐的版本号，能够使用的最老的版本号，新版本下载地址，官方网站地址等信息。
第三回合(TrID=6)，客户端要求身份认证(I = Initial)，NS则给出所需要的一长串信息(S = Subsequent)。其中tpf相当于challenge，参与Hash运算，能保证每次认证返回的串是不同的。
第四回合(TrID=7)，客户端出示从认证服务器得到的“入场券”，NS放行(OK)。
第三、四回合之间，通过SSL的认证过程如下：
首先在HTTPS端口443向login.passport.com发送一个GET请求，将账号、密码和NS给定的一长串信息送出
GET /login2.srf HTTP/1.1 \r\n
Authorization: Passport1.4 OrgVerb=GET,OrgURL=http%3A%2F%2Fmessenger%2Emsn%2Ecom,sign-in=example%40passport.com,pwd=password, lc=1033,id=507,tw=40,fs=1,ru=http%3A%2F%2Fmessenger%2Emsn%2Ecom,ct=1073355862,kpp=1,kv=5,ver=2.1.0173.1, tpf=ed1c2f217a21c191c61251eb8b73bb60 \r\n
Host: login.passport.com \r\n \r\n根据情况，会重定向到不同的URL。本例中，重定向到”https://loginnet.passport.com/login2.srf?lc=1033″，服务器应答
HTTP/1.1 302 Found \r\n Server: Microsoft-IIS/5.0 \r\n
Date: Mon, 22 Dec 2003 21:10:05 GMT \r\n
PPServer: H: LAWPPLOG5C006 \r\n
Connection: close \r\n
Content-Type: text/html \r\n
Expires: Mon, 22 Jun 2003 21:09:05 GMT \r\n
Cache-Control: no-cache \r\n
cachecontrol: no-store \r\n Pragma: no-cache \r\n
P3P: CP=”DSP CUR OTPi IND OTRi ONL FIN” \r\n
Authentication-Info: Passport1.4 da-status=redir \r\n
Location: https://loginnet.passport.com/login2.srf?lc=1033 \r\n
\r\n … …然后，重新向指定的URL发出请求，得到如下响应
HTTP/1.1 200 OK \r\n
Server: Microsoft-IIS/5.0 \r\n
Date: Mon, 22 Dec 2003 21:10:07 GMT \r\n
PPServer: H: LAWPPIIS6B061 \r\n
Connection: close \r\n Content-Type: text/html \r\n
Expires: Mon, 22 Dec 2003 21:09:07 GMT \r\n
Cache-Control: no-cache \r\n
cachecontrol: no-store \r\n
Pragma: no-cache \r\n
P3P: CP=”DSP CUR OTPi IND OTRi ONL FIN” \r\n
Set-Cookie: … … \r\n
Authentication-Info: Passport1.4 da-status=success,tname=MSPAuth,tname=MSPProf,tname=MSPSec, from-PP=’t=4m1wWfEupDgUNb53qys5gJdw8OTJEtT82fcuDbS3U672gTymOOs6cgKeafj7WjgZNcufAQggxqHRRXko02DoflZA$$ &p=4QXNnX9rFDDgki9ZqvqPZGDGJa2Mrd5H13Zfl0NNjh4I78qPyfpzmkZPZEe0nxJTkzZSNDYtk!57cVqiYVfO86KgCRYWhi2kudS0M !7bdi82EDA1FYp3WboHD!sCQ17OZh7lPQI7fozrgsSMZwgSzRi2FNTPxf13oDNIfDCKCG!2guDvZKEpk78A$$’, ru=http://messenger.msn.com \r\n
Content-Length: 0 \r\n
\r\n
开始时直接向loginnet.passport.com发出正确的请求，也是可以的。不难看出，在服务器认证成功的返回信息中，Authentication-Info字段的from-PP串值，就是所谓的“入场券”。
如果认证失败，服务器返回401错误
HTTP/1.1 401 Unauthorized \r\n … …这样，就无法拿到“入场券”，自然不能在第四回合中输入合法的串。
