HTTP协议

HTTP协议（HyperText Transfer Protocol，超文本传输协议）是因特网上应用最为广泛的一种网络传输协议，所有的WWW文件都必须遵守这个标准。

HTTP是一个基于TCP/IP通信协议来传递数据（HTML文件、图片文件、查询结果等）。

HTTP工作原理

HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务器即WEB服务器发送所有请求。

Web服务器根据接收到的请求后，向客户端发送响应信息。

HTTP默认的端口号为80，但你也可以改为8080或者其他端口。

HTTP注意事项：

• HTTP是无连接：即限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，就断开连接。采用这种方式可以节省传输时间。

• HTTP是媒体独立的：这意味着，只要客户端和服务端知道如何处理的数据内容，任何类型的数据都可以通过HTTP发送。客户端以及服务器指定使用适合的MIME-type内容类型。

• HTTP是无状态的：HTTP协议是无状态协议。无状态指的是协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则必须重新传递，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要前面的信息时它的应答就比较快。

HTTP协议的通信流程如下：

Web Browser <-(通过HTTP Protocol)-> HTTP Server <–> CGI Program <–> Database

HTTP消息结构

HTTP是基于客户端/服务端（C/S）的架构模型，通过一个可靠的链接来交换信息，是一个无状态的请求/响应协议。

一个HTTP“客户端”是一个应用程序（Web浏览器或其他任何客户端），通过连接到服务器达到向服务器发送一个或多个HTTP请求的目的。

一个HTTP“服务器”同样也是一个应用程序（通常是一个Web服务，比如Apache Web服务器或IIS服务器等），通过接收客户端的请求并向客户端发送HTTP响应数据。

HTTP使用统一资源标识符（Uniform Resource Identifiers，URI）来传输数据和建立连接。

一旦建立连接后，数据消息就通过类似Internet邮件的使用的格式[RFC5322]和多用途Internet邮件扩展（MIME）[RFC2045]来传送。

客户端请求消息

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头（header）、空行和请求数据四个部分组成.以下是请请求报文的一般格式：

httpcopied
请求方式 请求地址（URL） 协议版本
头部字段名：值
...
头部字段名：值

请求数据

服务器响应消息

HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。以下是响应报文的一般格式：

httpcopied
HTTP/1.1 200 OK
Date: Sun, 28 Oct 2018 16:40:25 GMT
Content-Length: 7724
Content-Type: image/jpeg

// 响应正文

HTTP请求方法

根据HTTP标准，HTTP请求可以使用多种请求方法。

HTTP1.0定义了三种请求方法： GET，POST和HEAD方法。

HTTP1.1新增了5种请求方法：OPTIONS、PUT、DELETE、TRACE和CONNECT方法。

根据HTTP协议规范，GET用于信息获取，而且应该是安全的和幂等的。

1. 所谓安全的，意味着该操作用于获取信息而非修改信息。换句话说，GET请求一般不应产生副作用。也就是说，它仅仅是获取资源信息，就像数据库查询一样，不会修改、增加数据，不会影响资源的状态。

   注意：这里的安全的含义仅仅指不会修改信息。

2. 幂等的意味着对同一URL的多个请求应该返回相同的结果。

   幂等（idempotent/idempotence）是一个数学或计算机学概念，常见于抽象代数中。

   幂等有以下几种定于：

   • 对于单目运算，如果一个运算对于在范围内所有的一个数多次进行该运算所得的结果和进行一次运算所得的结果是一样的，那么我们就称该运算是幂等的。比如，绝对值运算就是幂等的，在实数集中abs(a) = abs(abs(a))。

   • 对于双目运算，则要求参与运算的两个值是等值的情况下，如果满足运算结果与参与运算的两个值相等，则称该运算幂等。比如，求两个数的最大值函数max(x, x) = a。

   但在实际应用中，以上2条规定并没有那么严格。比如，新闻站点的头版不断更新，虽然第二次请求会返回不同的信息，该操作仍被认为是安全的和幂等的，因为它总是返回当前的新闻。从根本上说，如果目标是当用户打开一个链接时，他可以确信从自身的角度来看有没有改变资源即可。

根据HTTP规范，POST表示可能修改服务器上的资源的请求。

还是以新闻网站为例，读者对新闻发表自己的评论应该通过POST实现，因为在评论提交后，站点的资源就已经不同了，或者说是资源被修改了。

上面大概说了一下HTTP规范中GET和POST的一些原理性问题，但在实际操作中，很多人却没有按照HTTP规范去做，导致这个问题的原因有很多，比如：

• 很多人贪方便，更新资源时用了GET，因为POST必须要用到FORM（表单），这样会麻烦一点。

• 对资源的增、删、查、改操作，其实都可以通过GET/POST来完成，不需要用到PUT和DELETE。

• 还有就是，早期的Web MVC框架设计者们并没有意识地将URL当作抽象的资源来看待和设计，所以导致一个比较严重的问题是传统的Web MVC框架基本上都只支持GET和POST两种方法，而不支持PUT和DELETE方法。

以上3点典型地描述了老一套的风格（没有严格遵守HTTP规范），随着架构的发展，现在出现REST（Representional State Transfer），一套支持HTTP规范的新风格。可以参考《RESTfull Web Services》。

从表面现象上面看GET和POST的区别：

1. GET请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，参数之间以&相连。如果数据是英文或数字，则原样发送；如果是空格，则转换为+，如果是中文或其它字符，则把字符串用BASE64加密。而POST则是把提交的数据放置在HTTP包的包体中。

2. GET方式提交的数据最多只能是1024字节，理论上POST是没有限制的，但是一些服务器比如IIS会作出限制。

• 因为GET是通过URL提交数据，那么GET可提交的数据量就与URL长度有直接的关系。实际上，URL不存在参数上限的问题，HTTP协议规范没有对URL长度进行限制。这个限制是特写的浏览器及服务器对它的限制。注意这个限制是整个URL长度，而不仅仅是你的参数值数据的长度。

• 理论上讲，POST是没有大小限制的，HTTP协议规范也没有进行大小限制，起限制作用的是服务器的处理程序的处理能力。

3. 在PHPT中，用$_GET和$_POST分别获取GET和POST数据，而$_REQUEST则可以获取GET和POST两种请求中的数据。

4. POST的安全性要比GET高。注意：这里所说的安全性和上面GET提到的“安全”是两个不同的概念。这里的安全的含义是真正的Security的含义。比如：通过GET提交数据，用户名和密码将明文出现在URL中，因为登陆页面有可能被浏览器缓存，其他人查看浏览器的记录，就可以拿到你的账号和密码。除此之外，使用GET提交数据还可能会千万Cross-site request forgery攻击。

总结一下，GET是向服务器发索取数据的一种请求，而POST是向服务器提交数据的一种请求。在FORM表单中，Method默认为“GET”，实质上，GET和POST只是发送机制不同，并不是一个取一个发！

PUT：把消息本体中的消息发送到一个URL中，与POST类似，但不常用。

简单地说：通常是用于向服务器发送请求，如果URI不存在，则要求服务器根据请求创建资源，如果存在，服务器就接受请求内容，并修改URI资源的原始版本。

PUT请求的那些封装在Request-URI的实体。如果Request-URI引用一个已存在的资源，则该封装实体应该作为原始服务器上的修改版本。如果Request-URI不是指向一个已存在的资源，并且该URI可被请求的用户定义为资源，则原始服务器可用此URI创建新的资源。如果新的资源被创建，这个原始服务器就必须通过201（Created）响应通知用户代理。如果已有资源被修改，则发送200或者204响应，表示成功完成了该请求。如果Request-URI既没有创建也没有修改资源，则应该给予适当的错误响应来反映问题本质。实体的接受者不能忽略任何不理解或没有实现的Content-*头部（比如Content-Range），并且必须返回501响应

如果请求经过缓存，并且Request-URI标识出一个或多个当前缓存的实体，则那些实体视为过期了，该方法的响应不会被缓存。

POST和PUT的根本区别

POST请求的URI表示处理该封闭实体的资源，该资源可能是个数据接收过程、某种协议的网关、或者接收注解的独立实体。然而，PUT请求中的URI表示请求中封闭的实体-用户代理知道URI的目标，并且服务器无法将请求应用到其他资源。如果服务器希望请求应用到另一个URI，就必须发送一个304响应；用户代码可通过自己的判断来决定是否转为该请求。

HTTP/1.1没有定义一个PUT请求如何影响原始服务器的状态。

PUT请求必须遵守信息传输要求。除非另有说明，PUT请求中的实体头部应该用于PUT创建或修改的资源上。

其实，大部分情况下，我们都只用到了GET和POST。如果想设计一个符合RESTful规范的web应用程序，则这六种方法都会用到：

1. GET：GET可以说是最常见的，它本质就是发送一个请求来获取服务器上的某一个资源。资源通过HTTP头和呈现数据（如HTML文本、图片、视频）返回给客户端。GET请求中，永远不会包含呈现数据。

2. HEAD：HEAD和GET本质是一样的，区别在于HEAD响应不含有呈现数据，而仅仅上HTTP头信息。比如判断某个资源是否存在，使用HEAD的意义就很明确。

3. PUT：这个方法比较少见。HTML表单也不支持这个方法。本质上讲，PUT和POST极为相似，都是向服务器发送数据，但它们之间有一个重要的区别是：PUT通过指定了资源存放的位置，而POST则没有，POST的数据存放位置由服务器自己决定。比如：一个用于提交博文的URL（/addBlog），如果用PUT，则提交的URL会像是这样的：/addBlog/adc123，其中abc123就是这个博文的地址。

4. DELETE：删除某一个资源。基本上也很少见，不过有一些地方，比如amazon的S3云服务器里面就用这个方法来删除资源。

5. POST：向服务器提交数据。这个方法用途广泛，几乎目前所有的提交操作都是靠这个完成。

6. OPTIONS：这个方法很有趣，但是极少使用。它用于获取当前URL所支持的方法。若请求成功，则它会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，比如“GET”、“POST”。

HTTP响应头信息

HTTP状态码

下面是常见的HTTP状态码：

• 200 - 请求成功
• 301 - 资源（网页等）被永久转移到其它URL
• 404 - 请求的资源（网页等）不存在
• 500 - 服务器内部错误

HTTP状态码分类

HTTP状态码由三个十进制的数字组成，第一个十进制数字定义了状态码的类型。

HTTP状态码共分为5种类型：

• 1** 信息，服务器收到请求，需要请求者继续执行操作
• 2** 成功，操作被成功接收并处理
• 3** 重定向，需要进一步的操作以完成请求
• 4** 客户端错误，请求包含的语法错误或无法完成请求
• 5** 服务端错误，服务器在处理请求的过程中发生了错误

HTTP状态码列表：