SOAP协议初级指南 (一)
SOAP(Simple Object Access Protocal) 技术有助于实现大量异构程序和平台之间的互操作性，从而使存在的应用能够被广泛的用户所访问。SOAP是把成熟的基于HTTP的WEB技术与XML的灵活性和可扩展性组合在了一起。
这篇文章带你全面回顾对象远程进程调用（ORPC）技术的历程，以帮助你理解SOAP技术的基础，以及它克服存在技术（如CORBA和DCOM）的许多缺陷的方法。随后讲述详细的SOAP编码规则，并把焦点放在SOAP是怎样映射到存在的ORPC概念上的。
引言：
当我在1984年开始把计算作为我的职业的时候，大多数程序员并不关心网络协议。但是在九十年代网络变得无所不在，现在如果有谁使用计算机却不使用某种形式网络连接是很难以想象的。今天，一般的程序员对建立可扩展的分布式应用表现出更大的兴趣，而不再只是关注于用MFC实现个性化的可浮动半透明非矩形的Coolbars了。
程序员通常喜欢用编程模型来思考问题，而很少考虑网络协议。尽管这样做通常是很好的，但在这篇文章中我将讨论的SOAP是一个没有明显的编程模型的网络协议。这并不意味着SOAP的体系结构从根本上会改变你编程的方式。相反，SOAP的一个主要目标是使存在的应用能被更广泛的用户所使用。为了实现这个目的，没有任何SOAP API或SOAP 对象请求代理（SOAP ORB），SOAP是假设你将使用尽可能多的存在的技术。几个主要的CORBA厂商已经承诺在他们的ORB产品中支持SOAP协议。微软也承诺在将来的COM版本中支持SOAP。
DevelopMentor已经开发了参考实现，它使得在任何平台上的任何Java或Perl程序员都可以使用SOAP。
在SOAP后面的指导理念是“它是第一个没有发明任何新技术的技术”。SOAP采用了已经广泛使用的两个协议：HTTP和XML。HTTP用于实现SOAP的RPC风格的传输，而XML是它的编码模式。采用几行代码和一个XML解析器，HTTP服务器（如MS的IIS或Apache）立刻成为了SOAP的ORBs。 因为目前超过一半的Web服务器采用IIS或Apache, SOAP将会从这两个产品的广泛而可靠的使用中获取利益。这并不意味着所有的SOAP请求必须通过Web服务器来路由，传统的Web 服务器只是分派SOAP请求的一种方式。因此Web服务如IIS或Apache对建立SOAP使能的应用是充分的，但决不是必要的。
正如这篇文章将要描述的，SOAP简单地用XML来编码HTTP的传输内容。SOAP最常用的应用是作为一个RPC协议。为了理解SOAP怎样工作，有必要简要回顾一下RPC协议的历史。
RPCs的历史
建立分布式应用的两个主要通信模型是消息传送（经常与队列组合在一起）和请求/响应。消息传递系统允许通信任何一方在任何时间发送消息。请求/响应协议把通信模式限制在请求/响应的双方。基于消息的应用强烈地意识到它们正在与外部的并行进程进行通信，并且需要一个显式的设计风格。基于请求/响应的应用更象一个单进程的应用，因为发送请求的应用或多或少被阻塞直至收到来自另一个进程的响应。这使得请求/响应通信自然地适合于RPC应用。
尽管消息通信和请求/响应各有他们的优点，他们都是可以用对方来实现的。消息系统可以用较底层的请求/响应协议来建立。如微软的Message Queue Server (MSMQ)内部采用了DCE RPC来建立大多数的控制逻辑。RPC系统也可以采用较底层的消息系统来建立。MSMQ提供的关联 ID正是为了这个目的。不管评价如何，大多数的应用仍趋向于使用RPC协议，因为它们广泛的使用，它们更简单的设计，以及更自然的到传统的编程技术的映射。
在八十年代，两个主要的RPC协议是Sun RPC 和DCE RPC。最流行的Sun RPC应用是大多数UNIX系统所使用的Network File System (NFS)。最流行的DCE RPC应用则是Windows NT?，它采用DCE RPC 协议来实现许多系统服务。这两个协议被证明适用于很大范围的应用。但是，在八十年代末期，面向对象技术的风靡使软件界沉迷于在面向对象语言和基于RPC的通信之间建立一个纽带。
在九十年代产生的对象RPC (ORPC) 协议正是试图把面向对象和网络协议联系起来。ORPC 和 RPC 协议的主要不同是ORPC代码化了从通信终端到语言级对象的映射。在每个ORPC请求的头中都有一个cookie，服务器端的程序能用它来定位在服务器进程中的目标对象。通常这个cookie只是一个对数组的索引，但其它技术也经常被使用，如用符号名作为Hash表的键。
目前两个主要的OPRC协议是DCOM 和 CORBA的 Internet Inter-ORB Protocol (IIOP) 或更一般的General Inter-ORB Protocol (GIOP)。DCOM和IIOP/GIOP的请求格式非常相似。两个协议都用一个对象端点ID来确定目标对象，用方法标识符来决定调用哪个方法。
这两个协议主要有两点不同：主要的一点不同是采用IIOP/GIOP时，接口标识符是隐含的，因为一个给定的CORBA对象只实现一个接口（尽管OMG当前正在进行每个对象有多个接口支持的标准化工作）。DCOM与IIOP/GIOP请求的另一个细微差别是在传输体中参数值的格式。在DCOM中，传输体用网络数据表达（NDR）的格式来写，在IIOP/GIOP中，传输体用公共数据表达（CDR）的格式来写。NDR和 CDR分别处理在各种平台上的不同的数据表达。但是在这两种格式之间有一些小的差别，这使它们相互之间并不兼容。
在ORPC与RPC协议之间的另一个重要的不同是通信端点的命名方式。在ORPC协议中，对于ORPC端点的一些可传递的表达方式被要求在网络之间传递对象引用。在CORBA/IIOP，这个表达方式被称为可交互的对象引用（IOR）。IORs包含用紧凑格式表达的寻址信息，使用了它任何CORBA产品都可以决定一个对象端点。在DCOM中，这种表达方式被称为OBJREF，它组合了分布的引用计算和端点/对象标识。CORBA和DCOM都提供了在网络上寻找对象端点的高级机制，但最终这些机制都映射回到了IORs或OBJREFs。
目前的技术存在的问题？
尽管DCOM和IIOP都是固定的协议，业界还没有完全转向其中任何一个协议。没有融合的部分原因是文化的问题所致。而且在当一些组织试图标准化一个或另一个协议的时候，两个协议的技术适用性就被提出质疑。传统上认为DCOM和CORBA都是合理服务器到服务器端的通信协议。但是，二者对客户到服务器端的通信都存在明显的弱点，尤其是客户机被散布在Internet上的时候。
DCOM 和 CORBA/IIOP都是依赖于单个厂商的解决方案来最大优势地使用协议。尽管两个协议都在各种平台和产品上被实现了，但现实是选定的发布需要采用单一厂商的实现。在DCOM的情况下，这意味着每个机器要运行在Windows NT。（尽管DCOM已经被转移到其它平台，但它只在Windows?上获得了广泛的延伸）。在CORBA情况下，这意味着每个机器要运行同样的ORB产品。的确让两个CORBA产品用IIOP相互调用是有可能的，但是许多高级的服务（如安全和事务）此时通常不是可交互的。而且，任何专门厂商为同样的机器的通信所作的优化很难起作用，除非所有的应用被建立在同一个ORB产品上。
DCOM 和CORBA/IIOP都依赖于周密管理的环境。两个任意的计算机使得DCOM或IIOP 在环境之外被成功调用（calls out of the box）的几率是很低的。特别是在考虑安全性的时候尤其是这样。尽管写一个能成功地运用DCOM或IIOP的紧缩包（shrink-wrap）应用是可能的，但这样做要比基于socket的应用要更多地关注细节。这对于乏味但必需的配置和安装管理任务特别适用。
DCOM 和 CORBA/IIOP都依赖于相当高技术的运行环境。尽管进程内的COM似乎特别简单，但COM/DCOM远程处理程序绝对不只是几天就解决的事情。IIOP 是一个比DCOM更容易实现的协议，但两个协议都有相当多的深奥的规则来处理数据排列、类型信息和位操作。这使得一般的程序员在没有领会ORB产品或OLE32.DLL的情况下去构造一个简单的CORBA或DCOM调用也变得很困难。
也许对DCOM和CORBA/IIOP来说，最令人难以忍受的一点是它们不能在Internet 上发挥作用。对DCOM来说，一般用户的iMac 或廉价的运行Windows 95的PC 兼容机要想使用你的服务器执行基于领域认证几乎是不可能的。更糟的是，如果防火墙或代理服务器分隔开了客户和服务器的机器，任何IIOP或DCOM包要通过的可能性是很低的，主要是由于大多数Internet连接技术对HTTP协议的偏爱所致。尽管一些厂商如Microsoft， Iona和Visigenic都已经建立了通道技术，但这些产品很容易对配置错误敏感而且它们是不可交互的。
在一个服务器群落中这些问题并不能影响DCOM或IIOP的使用。因为在服务器群落中主机的数量很少（一般是成百上千，而不是成千上万），这就抵消了DCOM基于ping的生命周期管理的成本。在服务器群落中，所有主机被一个公共管理域管理的机率很大，使得统一的配置变得可能。相对少量的机器也能保持商业ORB产品可控制使用的成本，因为只需要更少量的ORB许可权。如果只有IIOP在服务器群落中被使用，就只需要少量的ORB许可权。最后，在服务器群落中所有主机有直接的IP连接也是可能的，这就消除了与防火墙相关的DCOM和 IIOP问题。
HTTP作为一个更好的RPC
在服务器群落中使用DCOM 和CORBA 是通用的做法，但客户机则使用HTTP进入服务器群落。HTTP与RPC的协议很相似，它简单、配置广泛，并且对防火墙比其它协议更容易发挥作用。HTTP请求一般由Web服务器软件（如IIS和Apache）来处理，但越来越多的应用服务器产品正在支持HTTP作为除DCOM和IIOP外的又一个协议。
象DCOM和IIOP一样，HTTP层通过TCP/IP进行请求/响应通信。一个HTTP的客户端用TCP连接到HTTP服务器。在HTTP中使用的标准端口号是80，但任何其它端口也能被使用。在建立TCP连接后，客户端可以发送一个请求消息到服务器端。服务器在处理请求后发回一个HTTP响应消息到客户端。请求和响应消息都可以包含任意的传输体的信息，通常用Content-Length和Content-Type的 HTTP 头来标记。下面是一个合法的HTTP请求消息：
POST /foobar HTTP/1.1
Host: 209.110.197.12
Content-Type: text/plain
Content-Length: 12
Hello, World
你可能已经注意到HTTP头只是一般文本。这使得用包检查程序或基于文本的Internet工具（如telnet）来诊断HTTP问题变得更容易。HTTP基于文本的属性也使得HTTP更容易适用于在Web开发中流行的低技术水平的编程环境。
HTTP请求的第一行包含三个组件：HTTP方法，请求-URI，协议版本。在前面的例子中，这些分别对应于POST, /foobar, 和 HTTP/1.1。Internet工程任务组(IETF)已经标准化了数量固定的HTTP方法。GET是HTTP用来访问Web的方法。 POST是建立应用程序的最常用的HTTP方法。和GET不一样，POST允许任意数据从客户端发送到服务器端。请求URI (Uniform Resource Identifier)是一个HTTP服务器端软件，它用来识别请求的目标的简单的标识符（它更象一个IIOP/GIOP object_key 或一个DCOM IPID）。关于URIs更多的信息请参照"URIs, URLs, and URNs"。在这个例子中协议的版本是HTTP/1.1， 它表示遵守RFC 2616的规则。HTTP/1.1比HTTP/1.0多增加了几个特性，包括对大块数据传输的支持以及对在几个HTTP请求之间保持TCP连接的支持。
请求的第三行和第四行指定了请求体的尺寸和类型。Content-Length 头指定了体信息的比特数。Content-Type类型标识符指定MIME类型为体信息的语法。HTTP (象 DCE一样) 允许服务器和客户端协商用于编制信息的传输语法。大多数DCE应用采用NDR.。大多数Web应用采用text/html 或其它基于文本的语法。
注意在上面样例中Content-Length头与请求体之间的空行。不同的HTTP头被carriage-return/行码序列划定界限。这些头与体之间用另外的carriage-return/行码序列来划定界限。请求接着包括原始字节，这些字节的语法和长度由Content-Length和Content-Type HTTP 头来识别。在这个例子中，内容是十二字节的普通文本字符串"Hello, World"。
在处理了请求之后，HTTP服务器被期望发回一个HTTP响应到客户端。响应必须包括一个状态代码来表示请求的结果。响应也可以包含任意的体信息。下面是一个HTTP响应消息：
200 OK
Content-Type: text/plain
Content-Length: 12
dlroW ,olleH
在这个例子中，服务器返回状态代码200，它是HTTP中标准的成功代码。如果服务器端不能破解请求代码，它将返回下列的响应：
400 Bad Request
Content-Length: 0
如果HTTP服务器决定到目标URI的请求应该临时转向另外的一个不同的URI，下列响将被返回：
307 Temporarily Moved
Location: http://209.110.197.44/foobar
Content-Length: 0
这个响应告知客户，请求将能够通过重新传递它到在Location头中指定的地址来被满足。
所有的标准状态码和头都在RFC 2616中被描述。它们中很少的内容与SOAP用户直接相关，但有一个明显的例外。在HTTP/1.1，底层的TCP连接在多个请求/响应对之间重用。HTTP Connection头允许客户端或服务器中任何一方关闭底层的连接。通过增加下列HTTP头到请求或响应中，双方都会要求在处理请求后关闭它们的TCP连接：
Connection: close
当与HTTP/1.0软件交互时，为了保持TCP连接，建议发送方加入下列HTTP头到每个请求或响应中：
Connection: Keep-Alive
这个头使缺省的HTTP/1.0协议在每次响应后重新开始TCP连接的行为无法使用。
HTTP的一个优点是它正被广泛的使用和接受。图4表示了一个简单的Java程序，它发送前面表示的请求并从响应中解析出结果字符串。
下面则是一个简单的C程序用CGI来读取来自HTTP请求的字符串并通过HTTP响应把它的逆序串返回。
#include ＜stdio.h＞
int main(int argc, char **argv) {
char buf[4096];
int cb = read(0, buf, sizeof(buf));
buf[cb] = 0;
strrev(buf);
printf("200 OK\r\n");p＞
printf("Content-Type: text/plain\r\n");
printf("Content-Length: %d\r\n", cb);
printf("\r\n");
printf(buf);
return 0;
服务器的实现是用Java servlet，以避免CGI的每个请求一个进程的开销。
一般 来说CGI是花费代价最小的写HTTP服务器端代码的方法。实际上，每一个HTTP服务器端产品都提供了一个更有效的机制来让你的代码处理一个HTTP请求。IIS提供了ASP和ISAPI作为写HTTP代码的机制。Apache允许你用运行在Apache后台程序中的 C或Perl来写模块。大多数应用服务器软件允许你写Java servlet，COM组件，EJB Session beans或基于可携带对象适配器（POA）接口的CORBA servants。
这篇文章带你全面回顾对象远程进程调用（ORPC）技术的历程，以帮助你理解SOAP技术的基础，以及它克服存在技术（如CORBA和DCOM）的许多缺陷的方法。随后讲述详细的SOAP编码规则，并把焦点放在SOAP是怎样映射到存在的ORPC概念上的。
引言：
当我在1984年开始把计算作为我的职业的时候，大多数程序员并不关心网络协议。但是在九十年代网络变得无所不在，现在如果有谁使用计算机却不使用某种形式网络连接是很难以想象的。今天，一般的程序员对建立可扩展的分布式应用表现出更大的兴趣，而不再只是关注于用MFC实现个性化的可浮动半透明非矩形的Coolbars了。
程序员通常喜欢用编程模型来思考问题，而很少考虑网络协议。尽管这样做通常是很好的，但在这篇文章中我将讨论的SOAP是一个没有明显的编程模型的网络协议。这并不意味着SOAP的体系结构从根本上会改变你编程的方式。相反，SOAP的一个主要目标是使存在的应用能被更广泛的用户所使用。为了实现这个目的，没有任何SOAP API或SOAP 对象请求代理（SOAP ORB），SOAP是假设你将使用尽可能多的存在的技术。几个主要的CORBA厂商已经承诺在他们的ORB产品中支持SOAP协议。微软也承诺在将来的COM版本中支持SOAP。
DevelopMentor已经开发了参考实现，它使得在任何平台上的任何Java或Perl程序员都可以使用SOAP。
在SOAP后面的指导理念是“它是第一个没有发明任何新技术的技术”。SOAP采用了已经广泛使用的两个协议：HTTP和XML。HTTP用于实现SOAP的RPC风格的传输，而XML是它的编码模式。采用几行代码和一个XML解析器，HTTP服务器（如MS的IIS或Apache）立刻成为了SOAP的ORBs。 因为目前超过一半的Web服务器采用IIS或Apache, SOAP将会从这两个产品的广泛而可靠的使用中获取利益。这并不意味着所有的SOAP请求必须通过Web服务器来路由，传统的Web 服务器只是分派SOAP请求的一种方式。因此Web服务如IIS或Apache对建立SOAP使能的应用是充分的，但决不是必要的。
正如这篇文章将要描述的，SOAP简单地用XML来编码HTTP的传输内容。SOAP最常用的应用是作为一个RPC协议。为了理解SOAP怎样工作，有必要简要回顾一下RPC协议的历史。
RPCs的历史
建立分布式应用的两个主要通信模型是消息传送（经常与队列组合在一起）和请求/响应。消息传递系统允许通信任何一方在任何时间发送消息。请求/响应协议把通信模式限制在请求/响应的双方。基于消息的应用强烈地意识到它们正在与外部的并行进程进行通信，并且需要一个显式的设计风格。基于请求/响应的应用更象一个单进程的应用，因为发送请求的应用或多或少被阻塞直至收到来自另一个进程的响应。这使得请求/响应通信自然地适合于RPC应用。
尽管消息通信和请求/响应各有他们的优点，他们都是可以用对方来实现的。消息系统可以用较底层的请求/响应协议来建立。如微软的Message Queue Server (MSMQ)内部采用了DCE RPC来建立大多数的控制逻辑。RPC系统也可以采用较底层的消息系统来建立。MSMQ提供的关联 ID正是为了这个目的。不管评价如何，大多数的应用仍趋向于使用RPC协议，因为它们广泛的使用，它们更简单的设计，以及更自然的到传统的编程技术的映射。
在八十年代，两个主要的RPC协议是Sun RPC 和DCE RPC。最流行的Sun RPC应用是大多数UNIX系统所使用的Network File System (NFS)。最流行的DCE RPC应用则是Windows NT?，它采用DCE RPC 协议来实现许多系统服务。这两个协议被证明适用于很大范围的应用。但是，在八十年代末期，面向对象技术的风靡使软件界沉迷于在面向对象语言和基于RPC的通信之间建立一个纽带。
在九十年代产生的对象RPC (ORPC) 协议正是试图把面向对象和网络协议联系起来。ORPC 和 RPC 协议的主要不同是ORPC代码化了从通信终端到语言级对象的映射。在每个ORPC请求的头中都有一个cookie，服务器端的程序能用它来定位在服务器进程中的目标对象。通常这个cookie只是一个对数组的索引，但其它技术也经常被使用，如用符号名作为Hash表的键。
目前两个主要的OPRC协议是DCOM 和 CORBA的 Internet Inter-ORB Protocol (IIOP) 或更一般的General Inter-ORB Protocol (GIOP)。DCOM和IIOP/GIOP的请求格式非常相似。两个协议都用一个对象端点ID来确定目标对象，用方法标识符来决定调用哪个方法。
这两个协议主要有两点不同：主要的一点不同是采用IIOP/GIOP时，接口标识符是隐含的，因为一个给定的CORBA对象只实现一个接口（尽管OMG当前正在进行每个对象有多个接口支持的标准化工作）。DCOM与IIOP/GIOP请求的另一个细微差别是在传输体中参数值的格式。在DCOM中，传输体用网络数据表达（NDR）的格式来写，在IIOP/GIOP中，传输体用公共数据表达（CDR）的格式来写。NDR和 CDR分别处理在各种平台上的不同的数据表达。但是在这两种格式之间有一些小的差别，这使它们相互之间并不兼容。
在ORPC与RPC协议之间的另一个重要的不同是通信端点的命名方式。在ORPC协议中，对于ORPC端点的一些可传递的表达方式被要求在网络之间传递对象引用。在CORBA/IIOP，这个表达方式被称为可交互的对象引用（IOR）。IORs包含用紧凑格式表达的寻址信息，使用了它任何CORBA产品都可以决定一个对象端点。在DCOM中，这种表达方式被称为OBJREF，它组合了分布的引用计算和端点/对象标识。CORBA和DCOM都提供了在网络上寻找对象端点的高级机制，但最终这些机制都映射回到了IORs或OBJREFs。
目前的技术存在的问题？
尽管DCOM和IIOP都是固定的协议，业界还没有完全转向其中任何一个协议。没有融合的部分原因是文化的问题所致。而且在当一些组织试图标准化一个或另一个协议的时候，两个协议的技术适用性就被提出质疑。传统上认为DCOM和CORBA都是合理服务器到服务器端的通信协议。但是，二者对客户到服务器端的通信都存在明显的弱点，尤其是客户机被散布在Internet上的时候。
DCOM 和 CORBA/IIOP都是依赖于单个厂商的解决方案来最大优势地使用协议。尽管两个协议都在各种平台和产品上被实现了，但现实是选定的发布需要采用单一厂商的实现。在DCOM的情况下，这意味着每个机器要运行在Windows NT。（尽管DCOM已经被转移到其它平台，但它只在Windows?上获得了广泛的延伸）。在CORBA情况下，这意味着每个机器要运行同样的ORB产品。的确让两个CORBA产品用IIOP相互调用是有可能的，但是许多高级的服务（如安全和事务）此时通常不是可交互的。而且，任何专门厂商为同样的机器的通信所作的优化很难起作用，除非所有的应用被建立在同一个ORB产品上。
DCOM 和CORBA/IIOP都依赖于周密管理的环境。两个任意的计算机使得DCOM或IIOP 在环境之外被成功调用（calls out of the box）的几率是很低的。特别是在考虑安全性的时候尤其是这样。尽管写一个能成功地运用DCOM或IIOP的紧缩包（shrink-wrap）应用是可能的，但这样做要比基于socket的应用要更多地关注细节。这对于乏味但必需的配置和安装管理任务特别适用。
DCOM 和 CORBA/IIOP都依赖于相当高技术的运行环境。尽管进程内的COM似乎特别简单，但COM/DCOM远程处理程序绝对不只是几天就解决的事情。IIOP 是一个比DCOM更容易实现的协议，但两个协议都有相当多的深奥的规则来处理数据排列、类型信息和位操作。这使得一般的程序员在没有领会ORB产品或OLE32.DLL的情况下去构造一个简单的CORBA或DCOM调用也变得很困难。
也许对DCOM和CORBA/IIOP来说，最令人难以忍受的一点是它们不能在Internet 上发挥作用。对DCOM来说，一般用户的iMac 或廉价的运行Windows 95的PC 兼容机要想使用你的服务器执行基于领域认证几乎是不可能的。更糟的是，如果防火墙或代理服务器分隔开了客户和服务器的机器，任何IIOP或DCOM包要通过的可能性是很低的，主要是由于大多数Internet连接技术对HTTP协议的偏爱所致。尽管一些厂商如Microsoft， Iona和Visigenic都已经建立了通道技术，但这些产品很容易对配置错误敏感而且它们是不可交互的。
在一个服务器群落中这些问题并不能影响DCOM或IIOP的使用。因为在服务器群落中主机的数量很少（一般是成百上千，而不是成千上万），这就抵消了DCOM基于ping的生命周期管理的成本。在服务器群落中，所有主机被一个公共管理域管理的机率很大，使得统一的配置变得可能。相对少量的机器也能保持商业ORB产品可控制使用的成本，因为只需要更少量的ORB许可权。如果只有IIOP在服务器群落中被使用，就只需要少量的ORB许可权。最后，在服务器群落中所有主机有直接的IP连接也是可能的，这就消除了与防火墙相关的DCOM和 IIOP问题。
HTTP作为一个更好的RPC
在服务器群落中使用DCOM 和CORBA 是通用的做法，但客户机则使用HTTP进入服务器群落。HTTP与RPC的协议很相似，它简单、配置广泛，并且对防火墙比其它协议更容易发挥作用。HTTP请求一般由Web服务器软件（如IIS和Apache）来处理，但越来越多的应用服务器产品正在支持HTTP作为除DCOM和IIOP外的又一个协议。
象DCOM和IIOP一样，HTTP层通过TCP/IP进行请求/响应通信。一个HTTP的客户端用TCP连接到HTTP服务器。在HTTP中使用的标准端口号是80，但任何其它端口也能被使用。在建立TCP连接后，客户端可以发送一个请求消息到服务器端。服务器在处理请求后发回一个HTTP响应消息到客户端。请求和响应消息都可以包含任意的传输体的信息，通常用Content-Length和Content-Type的 HTTP 头来标记。下面是一个合法的HTTP请求消息：
POST /foobar HTTP/1.1
Host: 209.110.197.12
Content-Type: text/plain
Content-Length: 12
Hello, World
你可能已经注意到HTTP头只是一般文本。这使得用包检查程序或基于文本的Internet工具（如telnet）来诊断HTTP问题变得更容易。HTTP基于文本的属性也使得HTTP更容易适用于在Web开发中流行的低技术水平的编程环境。
HTTP请求的第一行包含三个组件：HTTP方法，请求-URI，协议版本。在前面的例子中，这些分别对应于POST, /foobar, 和 HTTP/1.1。Internet工程任务组(IETF)已经标准化了数量固定的HTTP方法。GET是HTTP用来访问Web的方法。 POST是建立应用程序的最常用的HTTP方法。和GET不一样，POST允许任意数据从客户端发送到服务器端。请求URI (Uniform Resource Identifier)是一个HTTP服务器端软件，它用来识别请求的目标的简单的标识符（它更象一个IIOP/GIOP object_key 或一个DCOM IPID）。关于URIs更多的信息请参照"URIs, URLs, and URNs"。在这个例子中协议的版本是HTTP/1.1， 它表示遵守RFC 2616的规则。HTTP/1.1比HTTP/1.0多增加了几个特性，包括对大块数据传输的支持以及对在几个HTTP请求之间保持TCP连接的支持。
请求的第三行和第四行指定了请求体的尺寸和类型。Content-Length 头指定了体信息的比特数。Content-Type类型标识符指定MIME类型为体信息的语法。HTTP (象 DCE一样) 允许服务器和客户端协商用于编制信息的传输语法。大多数DCE应用采用NDR.。大多数Web应用采用text/html 或其它基于文本的语法。
注意在上面样例中Content-Length头与请求体之间的空行。不同的HTTP头被carriage-return/行码序列划定界限。这些头与体之间用另外的carriage-return/行码序列来划定界限。请求接着包括原始字节，这些字节的语法和长度由Content-Length和Content-Type HTTP 头来识别。在这个例子中，内容是十二字节的普通文本字符串"Hello, World"。
在处理了请求之后，HTTP服务器被期望发回一个HTTP响应到客户端。响应必须包括一个状态代码来表示请求的结果。响应也可以包含任意的体信息。下面是一个HTTP响应消息：
200 OK
Content-Type: text/plain
Content-Length: 12
dlroW ,olleH
在这个例子中，服务器返回状态代码200，它是HTTP中标准的成功代码。如果服务器端不能破解请求代码，它将返回下列的响应：
400 Bad Request
Content-Length: 0
如果HTTP服务器决定到目标URI的请求应该临时转向另外的一个不同的URI，下列响将被返回：
307 Temporarily Moved
Location: http://209.110.197.44/foobar
Content-Length: 0
这个响应告知客户，请求将能够通过重新传递它到在Location头中指定的地址来被满足。
所有的标准状态码和头都在RFC 2616中被描述。它们中很少的内容与SOAP用户直接相关，但有一个明显的例外。在HTTP/1.1，底层的TCP连接在多个请求/响应对之间重用。HTTP Connection头允许客户端或服务器中任何一方关闭底层的连接。通过增加下列HTTP头到请求或响应中，双方都会要求在处理请求后关闭它们的TCP连接：
Connection: close
当与HTTP/1.0软件交互时，为了保持TCP连接，建议发送方加入下列HTTP头到每个请求或响应中：
Connection: Keep-Alive
这个头使缺省的HTTP/1.0协议在每次响应后重新开始TCP连接的行为无法使用。
HTTP的一个优点是它正被广泛的使用和接受。图4表示了一个简单的Java程序，它发送前面表示的请求并从响应中解析出结果字符串。
下面则是一个简单的C程序用CGI来读取来自HTTP请求的字符串并通过HTTP响应把它的逆序串返回。
#include ＜stdio.h＞
int main(int argc, char **argv) {
char buf[4096];
int cb = read(0, buf, sizeof(buf));
buf[cb] = 0;
strrev(buf);
printf("200 OK\r\n");p＞
printf("Content-Type: text/plain\r\n");
printf("Content-Length: %d\r\n", cb);
printf("\r\n");
printf(buf);
return 0;
服务器的实现是用Java servlet，以避免CGI的每个请求一个进程的开销。
一般 来说CGI是花费代价最小的写HTTP服务器端代码的方法。实际上，每一个HTTP服务器端产品都提供了一个更有效的机制来让你的代码处理一个HTTP请求。IIS提供了ASP和ISAPI作为写HTTP代码的机制。Apache允许你用运行在Apache后台程序中的 C或Perl来写模块。大多数应用服务器软件允许你写Java servlet，COM组件，EJB Session beans或基于可携带对象适配器（POA）接口的CORBA servants。
我来自：向东博客
