HTTP协议-复习（转）

一、概念
 二、HTTP报文
 1.请求方法
 2.请求报文
 3.响应报文
 三、无连接和无状态
 1.无连接
 2.无状态

一、概念

超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是互联网上应用最为广泛的一种网络协议。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。通过HTTP或者HTTPS协议请求的资源由统一资源标识符（Uniform Resource Identifiers，URI）来标识。HTTP构建于TCP/IP协议之上，默认端口是80；HTTP是无连接无状态的。

HTTP 协议是基于请求与响应的：

image

二、HTTP报文

1.请求方法

HTTP1.1目前支持7种请求方法。

GET
GET方法是默认的HTTP请求方法，日常用GET方法来提交表单数据，然而用GET方法提交的表单数据只经过了简单的编码，同时它将作为URL的一部分向WEB服务器发送。因此，如果使用GET方法来提交表单数据就存在安全隐患。
如：https://www.google.co.jp/search?q=http协议&oq=http协议
POST
主要向服务器提交数据，尤其是大批量数据。POST方法克服了GET方法的一些缺点。通过POST提交数据时，数据不是作为URL请求的一部分而是作为标准数据传送给服务器，克服了GET中信息无法保密和数据量太小的缺点。
HEAD
请求获取有Request-URI所标识的资源的响应消息报头。
OPTIONS
请求查询服务器的性能，或查询与资源相关的选项和需求。
PUT
请求服务器存储一个资源，并用Request-URI作为标识。
DELETE
请求服务器删除由Request-URI标识的资源。
TRACE
请求服务器回送收到的请求信息，主要用于测试或诊断。

2.请求报文

image

请求报文由三个部分组成：

请求行
请求行由请求方法、URL和HTTP协议版本组成，用空格分隔。如：GET /index.html HTTP/1.1
请求头

image

请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息。例如：

1.  User-Agent：产生请求的浏览器类型。
2.  Accept：客户端可识别的内容类型列表。
3.  Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。

请求正文
请求头和请求正文之间是一个空行，这个行非常重要，它表示请求头已经结束，接下来的是请求正文。请求正文中可以包含客户提交的查询字符串信息。
下面是一个典型的请求报文：

1.  GET /sample.jsp HTTP/1.1

3.  Accept:image/gif.image/jpeg,*/*
4.  Accept-Language:zh-cn
5.  Connection:Keep-Alive
6.  Host:localhost
7.  User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
8.  Accept-Encoding:gzip,deflate

10. username=jinqiao&password=1234

3.响应报文

image

响应报文也由三部分组成：

状态行
状态行由协议版本、数字形式的状态代码、及相应的状态描述，各元素之间以空格分隔。如： HTTP/1.1 200 OK

状态码由三个数字组成，第一个数字定义了响应的类别：

1xx：指示信息--表示请求已接收，继续处理。 
2xx：成功--表示请求已被成功接收、理解、接受。 
3xx：重定向--要完成请求必须进行更进一步的操作。 
4xx：客户端错误--请求有语法错误或请求无法实现。 
5xx：服务器端错误--服务器未能实现合法的请求。

常见的状态码如下：

image

200 OK 客户端请求成功 
301 Moved Permanently 请求永久重定向 
302 Moved Temporarily 请求临时重定向 
304 Not Modified 文件未修改，可以直接使用缓存的文件。 
400 Bad Request 由于客户端请求有语法错误，不能被服务器所理解。 
401 Unauthorized 请求未经授权。这个状态代码必须和WWW-Authenticate报头域一起使用 
403 Forbidden 服务器收到请求，但是拒绝提供服务。服务器通常会在响应正文中给出不提供服务的原因 
404 Not Found 请求的资源不存在，例如，输入了错误的URL 
500 Internal Server Error 服务器发生不可预期的错误，导致无法完成客户端的请求。 
503 Service Unavailable 服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常。

响应头
与请求头部类似，为响应报文添加了一些附加信息
常见响应头部如下：
[图片上传失败...(image-18ce8-1520145241188)]
响应正文
用于存放需要返回给客户端的数据信息。
一个典型的响应报文如下：

1.  `HTTP/1.1  200 OK　　状态行`
2.  `Date:  Sun,  17  Mar  2013  08:12:54 GMT　　响应头部`
3.  `Server:  Apache/2.2.8  (Win32) PHP/5.2.5`
4.  `X-Powered-By: PHP/5.2.5`
5.  `Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/`
6.  `Expires:  Thu,  19  Nov  1981  08:52:00 GMT`
7.  `Cache-Control:  no-store,  no-cache, must-revalidate, post-check=0, pre-check=0`
8.  `Pragma:  no-cache`
9.  `Content-Length:  4393`
10.  `Keep-Alive: timeout=5, max=100`
11.  `Connection:  Keep-Alive`
12.  `Content-Type: text/html; charset=utf-8`
13.  `　　空行`

15.  `<html>　　响应数据`
16.  `<head>`
17.  `<title>HTTP响应示例<title>`
18.  `</head>`
19.  `<body>`
20.  `Hello HTTP!`
21.  `</body>`
22.  `</html>`

三、无连接和无状态

HTTP有两个重要的特点就是无连接和无状态。怎么理解呢？

1.无连接

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

然而随着互联网的发展，一台服务器同一时间处理的请求越来越多，如果依然采用原来的方式，将会在建立和断开连接上花费大部分时间。
HTTP/1.0：持久连接被提出来；即当一个TCP连接服务器多次请求：客户端会在请求Header中携带Connection:Keep-Alive;向服务器请求持久连接，如果服务端允许就会在响应报文中加上相同的字段。
HTTP/1.1时代：持久连接称为了默认的连接方式；同时持久连接的弊病也展现出来，即所有的连接都是串行的，HOLB；当某一个请求阻塞时就会导致同一条连接的后续请求被阻塞；
为了解决这一问题：提出了pipellining的概念；客户端发起一次请求时不必等待响应便直接发起第二个请求；服务端按照请求的顺序一次返回结果。

我们知道 HTTP 协议采用“请求-应答”模式，当使用普通模式，即非 Keep-Alive 模式时，每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（HTTP协议为无连接的协议）；当使用 Keep-Alive 模式（又称持久连接、连接重用）时，Keep-Alive 功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive 功能避免了建立或者重新建立连接。

HTTP Keep-Alive 简单说就是保持当前的TCP连接，避免了重新建立连接。
HTTP 长连接不可能一直保持，例如 Keep-Alive: timeout=5, max=100，表示这个TCP通道可以保持5秒，max=100，表示这个长连接最多接收100次请求就断开。
HTTP是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive没能改变这个结果。另外，Keep-Alive也不能保证客户端和服务器之间的连接一定是活跃的，在HTTP1.1版本中也如此。唯一能保证的就是当连接被关闭时你能得到一个通知，所以不应该让程序依赖于Keep-Alive的保持连接特性，否则会有意想不到的后果。
使用长连接之后，客户端、服务端怎么知道本次传输结束呢？两部分：1. 判断传输数据是否达到了Content-Length 指示的大小；2. 动态生成的文件没有 Content-Length ，它是分块传输（chunked），这时候就要根据 chunked 编码来判断，chunked 编码的数据在最后有一个空 chunked 块，表明本次传输数据结束。

2.无状态

无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即我们给服务器发送 HTTP 请求之后，服务器根据请求，会给我们发送数据过来，但是，发送完，不会记录任何信息。HTTP 是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive 没能改变这个结果。