HTTP协议及其POST与GET操作差异

HTTP协议我想任何IT人士都耳熟能详了，大家都能说出个所以然来。但是如果我问你HTTP协议的请求方法有哪些？POST与GET的差 异？GET或POST传送数据量的大小有限制吗？HTTP响应的状态有哪些？以及在C#中你如何使用？如果你不能清楚地回答其中的大部分问题，那么这篇文 章就是为你准备的！大纲如下：

• 1、HTTP概述
  • 1.1、HTTP协议的客户端与服务器的交互
  • 1.2、HTTP消息
  • 1.3、HTTP请求的方法
  • 1.4、HTTP响应的代码
• 2、POST与GET的差异

1、HTTP概述

为了唤醒你对HTTP协议的记忆或使你能够对HTTP协议有所了解，首先简单一下HTTP协议。超文本传输协议 （HTTP ，HyperText Transfer Protocol ）是互联网 上应用最为广泛的一种网络协议 。所有的WWW 文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML 页面的方法。

HTTP的发展是万维网协会（World Wide Web Consortium ）和Internet工作小组（Internet Engineering Task Force ）合作的结果，（他们）最终发布了一系列的RFC ，其中最著名的就是RFC 2616 。RFC 2616 定义了HTTP协议中一个现今被广泛使用的版本——HTTP 1.1。

1.1、HTTP协议的客户端与服务器的交互

HTTP是一个客户端和服务器端请求和应答的标准（TCP ）。客户端是终端用户 ，服务器端是网站 。通过使用Web浏览器、网络爬虫或者其它的工具，客户端发起一个到服务器上指定端口（默认端口 为 80）的HTTP请求。（我们称这个客户端）调用户代理（user agent）。应答的服务器上存储着（一些）资源，比如HTML文件和图像。（我们称）这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个中间层，比如代理，网关，或者隧道（tunnel）。尽管TCP/IP 协议是互联网上最流行的应用，HTTP协议并没有规定必须使用它和（基于）它支持的层。事实上，HTTP可以在任何其他互联网协议上，或者在其他网络上实现。HTTP只假定（其下层协议提供）可靠的传输，任何能够提供这种保证的协议都可以被其使用。

通 常，由HTTP客户端发起一个请求，建立一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端发送过来的请求。一 旦收到请求，服务器（向客户端）发回一个状态行，比如"HTTP/1.1 200 OK"，和（响应的）消息，消息的消息体可能是请求的文件、错误消息、或者其它一些信息。

HTTP使用TCP而不是UDP的原因在于（打开一个）一个网页必须传送很多数据，而TCP 协议提供传输控制，按顺序组织数据，和错误纠正。通过HTTP或者HTTPS协议请求的资源由统一资源标识符 （Uniform Resource Identifiers，或者，更准确一些，URI）来标识。

客户端与服务器端的结构与交互过程可以表示为下面2张图：

图1、Web客户端-服务器端结构（其中web服务器的超文本链接，即通过网站上的一个链接跳转到了其他服务器上）

图2、Web客户端与服务器端的交互

1.2、HTTP消息

客户端与服务器之间的交互用到了两种类型的消息：请求（Request） 和响应（Response） 。

HTTP请求的格式为：

  图3、HTTP请求的格式

HTTP响应的格式为：

图4、HTTP响应的格式

从上面可以看出HTTP的请求和响应消息的首部均包含可变数量的字段，用一个空行（blank line ）将所有首部字段 （header）与消息主体 （body）分隔开来。一个首部字段由字段名和随后的冒号、一个空格和字段值组成，字段名不区分大小写 。

报文头可分为三类：一类应用于请求，一类应用于响应，还有一类描述主体。有一些报文头（例如：Date）既可用于请求又可用于响应。描述主体的报文头可以出现在POST请求和所有响应报文中。HTTP的首部字段如下图所示：

图5、HTTP首部字段

1.3、HTTP请求的方法

HTTP/1.1协议中共定义了八种方法（有时也叫“动作”）来表明Request-URI 指定的资源的不同操作方式：

• OPTIONS
  返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送'*'的请求来测试服务器的功能性。
• HEAD
  向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
• GET
  向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在Web Application 中。其中一个原因是GET可能会被网络蜘蛛 等随意访问。
• POST
  向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
• PUT
  向指定资源位置上传其最新内容。
• DELETE
  请求服务器删除Request-URI 所标识的资源。
• TRACE
  回显服务器收到的请求，主要用于测试或诊断。
• CONNECT
  HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Method Not Allowed）；当服务器不认识或者不支持对应的请求方法的时候，应当返回状态码501（Not Implemented）。

HTTP服务器至少应该实现GET和HEAD方法，其他方法都是可选的。此外，除了上述方法，特定的HTTP服务器还能够扩展自定义的方法。

安全方法

开发者应当意识到他们的软件 代表了用户在因特网 上进行交互，并且应当告知用户，他们正在进行的操作可能对他们自身或者其他人有未曾预料的重要影响。

特别地，对于GET和HEAD方法而言，除了进行获取资源信息外，这些请求不应当再有任何其他意义。也就是说，这些方法应当被认为是“安全的”，即所谓安全的意味着该操作用于获取信息而非修改信息 。客户端应当使用其他“非安全”方法，例如POST、PUT及DELETE来以特殊的方式（通常是按钮而不是超链接 ）使得客户能够意识到可能要负的责任（例如一个按钮带来的资金交易）或者被告知正在请求的操作可能是不安全的（例如某个文件将被上传或删除）。

但是，不能想当然地认为服务器不会在处理某个GET请求时不会产生任何副作用。事实上，很多动态资源会把这作为其特性。这里重要的区别在于用户并没有请求这一副作用，因此不应由用户为这些副作用承担责任。

幂等方法

假 如在不考虑诸如错误或者过期等问题的情况下，若干次请求的副作用与单次请求相同或者根本没有副作用，那么这些请求方法就能够被视作“幂等”的。 GET，HEAD，PUT和DELETE方法都有这样的幂等属性，同样由于根据协议，OPTIONS，TRACE都不应有副作用，因此也理所当然也是幂等 的。

假如某个由若干个请求做成的请求串行产生的结果在重复执行这个请求串行或者其中任何一个或多个请求后仍没有发生变化，则这个请求串行 便是“幂等” 的。但是，可能出现若干个请求做成的请求串行是“非幂等”的，即使这个请求串行中所有执行的请求方法都是幂等的。例如，这个请求串行的结果依赖于某个会在 下次执行这个串行的过程中被修改的变量。

1.4、HTTP响应的代码

 服务器程序响应的第一行叫状态行。状态行以HTTP版本号开始，后面跟着3位数字表示响应代码，最后是易读的响应短语。根据第一位可以把响应分成5类：

图6、HTTP响应代码

2、POST与GET的差异

一般在浏览器中输入网址访问资源都是通过GET 方式；在FORM 提交中，可以通过Method 指定提交方式为GET 或者POST ，默认为GET 提交

Http 定义了与服务器交互的不同方法，最基本的方法有4 种，分别是GET ，POST ，PUT ，DELETE

URL 全称是资源描述符，我们可以这样认为：一个 URL 地址，它用于描述一个网络上的资源，而 HTTP 中的 GET ， POST ， PUT ， DELETE 就对应着对这个资源的查 ，改 ，增 ，删 4 个操作。到这里，大家应该有个大概的了解了， GET 一般用于获取 / 查询 资源信息，而 POST 一般用于更新 资源信息 ( 个人认为这是 GET 和 POST 的本质区别，也是协议设计者的本意，其它区别都是具体表现形式的差异 ) 。

有了以上对HTTP 请求的了解和示例，我们再来看两种提交方式的区别：

   （1 ）GET 提交，请求的数据会附在URL 之后（就是把数据放置在HTTP 协议头中），以? 分割URL 和传输数据，多个参数用& 连接；例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD 。如果数据是英文字母/ 数字，原样发送，如果是空格，转换为+ ，如果是中文/ 其他字符，则直接把字符串用BASE64 加密，得出如： %E4%BD%A0%E5%A5%BD ，其中％XX 中的XX 为该符号以16 进制表示的ASCII 。

　　POST 提交：把提交的数据放置在是HTTP 包的包体中。上文示例中红色字体标明的就是实际的传输数据

     因此，GET 提交的数据会在地址栏中显示出来，而POST 提交，地址栏不会改变

    (2) 传输数据的大小：首先声明：HTTP 协议没有对传输的数据大小进行限制，HTTP 协议规范也没有对URL 长度进行限制。

而在实际开发中存在的限制主要有：

GET: 特定浏览器和服务器对URL 长度有限制，例如IE 对URL 长度的限制是2083 字节(2K+35) 。对于其他浏览器，如Netscape 、FireFox 等，理论上没有长度限制，其限制取决于操作系统的支持。

因此对于GET 提交时，传输数据就会受到URL 长度的限制。

POST: 由于不是通过URL 传值，理论上数据不受限。但实际各个WEB 服务器会规定对post 提交数据大小进行限制，Apache 、IIS6 都有各自的配置。

(3) 安全性：

.POST 的安全性要比GET 的安全性高。注意：这里所说的安全性和上面GET 提到的“ 安全” 不是同个概念。上面“ 安全” 的含义仅仅是不作数据修改，而这里安全的含义是真正的Security 的含义，比如：通过GET 提交数据，用户名和密码将明文出现在URL 上，因为(1) 登录页面有可能被浏览器缓存， (2) 其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET 提交数据还可能会造成Cross-site request forgery 攻击

（4 ）Http get,post,soap 协议都是在http 上运行的
1 ）get ：请求参数是作为一个key/value 对的序列（查询字符串）附加到URL 上的
        查询字符串的长度受到web 浏览器和web 服务器的限制（如IE 最多支持2048 个字符），不适合传输大型数据集同时，它很不安全
2 ）post ：请求参数是在http 标题的一个不同部分（名为entity body ）传输的，这一部分用来传输表单信息，因此必须将Content-type 设置为:application/x-www-form-urlencoded 。post 设计用来支持web 窗体上的用户字段，其参数也是作为key/value 对传输。
      但是：它不支持复杂数据类型，因为post 没有定义传输数据结构的语义和规则。
3 ）soap ：是http post 的一个专用版本，遵循一种特殊的xml 消息格式
       Content-type 设置为: text/xml   任何数据都可以xml 化