什么是HTTP:html
HTTP(HyperText Transfer Protocol超文本传输协议)是互联网上应用最为普遍的一种网络协议。全部的WWW文件都必须遵照这个标准,为了提供一种发布和接收HTML页面的方法。HTTP定义了信息如何被格式化、如何被传输,以及在各类命令下服务器和浏览器所采起的响应。web
HTTP是客户端浏览器或其余程序与Web服务器之间的应用层通讯协议。在Internet上的Web服务器上存放的都是超文本信息,客户机须要经过HTTP协议传输所要访问的超文本信息。HTTP包含命令和传输信息,不只可用于Web访问,也能够用于其余因特网/内联网应用系统之间的通讯,从而实现各种应用资源超媒体访问的集成。浏览器
关于HTTP协议的详细内容请参考RFC2616。缓存
HTTP协议的主要特色服务器
1.支持客户/服务器模式。
2.简单快速:客户向服务器请求服务时,只需传送请求方法和路径。请求方法经常使用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不一样。因为HTTP协议简单,使得HTTP服务器的程序规模小,于是通讯速度很快。
3.灵活:HTTP容许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4.无链接:无链接的含义是限制每次链接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开链接。采用这种方式能够节省传输时间。
5.无状态:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺乏状态意味着若是后续处理须要前面的信息,则它必须重传,这样可能致使每次链接传送的数据量增大。另外一方面,在服务器不须要先前信息时它的应答就较快。网络
技术架构:架构
HTTP是一个客户端和服务器端请求和应答的标准(TCP)。客户端是终端用户,服务器端是网站。经过使用Web浏览器、网络爬虫或者其它的工具,客户端发起一个到服务器上指定端口(默认端口为80)的HTTP请求。(咱们称这个客户端)叫用户代理(user agent)。应答的服务器上存储着(一些)资源,好比HTML文件和图像。(咱们称)这个应答服务器为源服务器(origin server)。在用户代理和源服务器中间可能存在多个中间层,好比代理,网关,或者隧道(tunnels)。尽管TCP/IP协议是互联网上最流行的应用,HTTP协议并无规定必须使用它和(基于)它支持的层。 事实上,HTTP能够在任何其余互联网协议上,或者在其余网络上实现。HTTP只假定(其下层协议提供)可靠的传输,任何可以提供这种保证的协议均可以被其使用。
一般,由HTTP客户端发起一个请求,创建一个到服务器指定端口(默认是80端口)的TCP链接。HTTP服务器则在那个端口监听客户端发送过来的请求。一旦收到请求,服务器(向客户端)发回一个状态行,好比"HTTP/1.1 200 OK",和(响应的)消息,消息的消息体多是请求的文件、错误消息、或者其它一些信息。HTTP使用TCP而不是UDP的缘由在于(打开)一个网页必须传送不少数据,而TCP协议提供传输控制,按顺序组织数据,和错误纠正。
经过HTTP或者HTTPS协议请求的资源由统一资源标示符(Uniform Resource Identifiers)(或者,更准确一些,URLs)来标识。工具
工做流程:性能
既然HTTP是基于传输层的TCP协议,而TCP协议是面向链接的端到端的协议。所以,使用HTTP协议传输前,首先创建TCP链接,就是所以在谈的TCP连接过程的“三次握手”。如图测试
在Web上,HTTP协议使用TCP协议而不是UDP协议的缘由在于一个网页必须传送不少数据,并且保证其完整性。TCP协议提供传输控制,按顺序组织数据和错误纠正的一系列功能。
一次HTTP操做称为一个事务,其工做过程可分为四步:
一、客户端与服务器须要创建链接。(好比某个超级连接,HTTP就开始了。)
二、创建链接后,发送请求。
三、服务器接到请求后,响应其响应信息。
四、客户端接收服务器所返回的信息经过浏览器显示在用户的显示屏上,而后客户机与服务器断开链接。
创建链接,其实创建在TCP链接基础之上。图解核心工做过程(即省去链接过程)以下:
关于HTTP协议
HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求,请求头包含请求的方法、URL、协议版本、以及包含请求修饰符、客户信息和内容的相似于MIME的消息结构。服务器以一个状态行做为响应,响应的内容包括消息协议的版本,成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。
一般HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行,一个或者多个头域,一个指示头域结束的空行和可选的消息体组成。HTTP的头域包括通用头,请求头,响应头和实体头四个部分。每一个头域由一个域名,冒号(:)和域值三部分组成。域名是大小写无关的,域值前能够添加任何数量的空格符,头域能够被扩展为多行,在每行开始处,使用至少一个空格或制表符。
通用头域:
通用头域包含请求和响应消息都支持的头域,通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通信双方都支持此扩展,若是存在不支持的通用头域,通常将会做为实体头域处理。下面简单介绍几个在UPnP消息中使用的通用头域:
1.Cache-Control头域
Cache-Control指定请求和响应遵循的缓存机制。
2.Date头域
Date头域表示消息发送的时间,时间的描述格式由rfc822定义。
3.Pragma头域
Pragma头域用来包含实现特定的指令,最经常使用的是Pragma:no-cache。
请求消息
请求消息的第一行为下面的格式:
MethodSPRequest-URISPHTTP-VersionCRLFMethod表示对于Request-URI完成的方法,这个字段是大小写敏感的,包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。
1.Host头域
Host头域指定请求资源的Intenet主机和端口号,必须表示请求url的原始服务器或网关的位置。
2.Referer头域
Referer头域容许客户端指定请求uri的源资源地址,这能够容许服务器生成回退链表,可用来登录、优化cache等。
3.Range头域
Range头域能够请求实体的一个或者多个子范围。
4.User-Agent头域
User-Agent头域的内容包含发出请求的用户信息。
响应消息
响应消息的第一行为下面的格式:
HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF
HTTP-Version表示支持的HTTP版本,例如为HTTP/1.1。Status-Code是一个三个数字的结果代码。Reason-Phrase给Status-Code提供一个简单的文本描述。
Status-Code的第一个数字定义响应的类别,后两个数字没有分类的做用。第一个数字可能取5个不一样的值:
1xx:信息响应类,表示接收到请求而且继续处理
2xx:处理成功响应类,表示动做被成功接收、理解和接受
3xx:重定向响应类,为了完成指定的动做,必须接受进一步处理
4xx:客户端错误,客户请求包含语法错误或者是不能正确执行
5xx:服务端错误,服务器不能正确执行一个正确的请求
1.Location响应头
Location响应头用于重定向接收者到一个新URI地址。
2.Server响应头
Server响应头包含处理请求的原始服务器的软件信息。
实体信息
请求消息和响应消息均可以包含实体信息,实体信息通常由实体头域和实体组成。实体头域包含关于实体的原信息,实体头包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD五、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。extension-header容许客户端定义新的实体头,可是这些域可能没法被接受方识别。
1.Content-Type实体头
Content-Type实体头用于向接收方指示实体的介质类型,指定HEAD方法送到接收方的实体介质类型,或GET方法发送的请求介质类型
2.Content-Range实体头
Content-Range实体头用于指定整个实体中的一部分的插入位置,他也指示了整个实体的长度。
3.Last-modified实体头
Last-modified实体头指定服务器上保存内容的最后修订时间。
报文格式:
HTTP报文由从客户机到服务器的请求和从服务器到客户机的响应构成。请求报文格式以下:
请求行 - 通用信息头 - 请求头 - 实体头 - 报文主体
请求行以方法字段开始,后面分别是 URL 字段和 HTTP 协议版本字段,并以 CRLF 结尾。SP 是分隔符。除了在最后的 CRLF 序列中 CF 和 LF 是必需的以外,其余均可以不要。有关通用信息头,请求头和实体头方面的具体内容能够参照相关文件。
以下:
对于其中请求报文详解:
一、请求行
方法字段 + URL + Http协议版本
二、通用信息头
Cache-Control头域:指定请求和响应遵循的缓存机制。
keep-alive 是其链接持续有效
三、请求头
Host头域
Referer头域:容许客户端指定请求URL的资源地址。
User-Agent头域:请求用户信息。【能够看出一些客户端浏览器的内核信息】
四、报文主体
应答报文格式以下:
状态行 - 通用信息头 - 响应头 - 实体头 - 报文主体
状态码元由3位数字组成,表示请求是否被理解或被知足。缘由分析是对原文的状态码做简短的描述,状态码用来支持自动操做,而缘由分析用来供用户使用。客户机无需用来检查或显示语法。有关通用信息头,响应头和实体头方面的具体内容能够参照相关文件。
请求报文相关:
请求行-请求方法
GET 请求获取Request-URI所标识的资源
POST 在Request-URI所标识的资源后附加新的数据
HEAD 请求获取由Request-URI所标识的资源的响应消息报头
PUT 请求服务器存储一个资源,并用Request-URI做为其标识
DELETE 请求服务器删除Request-URI所标识的资源
TRACE 请求服务器回送收到的请求信息,主要用于测试或诊断
CONNECT 保留未来使用
OPTIONS 请求查询服务器的性能,或者查询与资源相关的选项和需求
响应报文相关:
响应行-状态码
HTTP状态码的做用是:web服务器用来告诉客户端,发生了什么事。
状态码位于HTTP Response 的第一行中,会返回一个”三位数字的状态码“和一个“状态消息”。 ”三位数字的状态码“便于程序进行处理, “状态消息”更便于人理解。
1xx:指示信息–表示请求已接收,继续处理
2xx:成功–表示请求已被成功接收、理解、接受
3xx:重定向–要完成请求必须进行更进一步的操做
4xx:客户端错误–请求有语法错误或请求没法实现
5xx:服务器端错误–服务器未能实现合法的请求
下面提供 HTTP 状态码的完整列表。
1、临时响应
1xx(临时响应)
表示临时响应并须要请求者继续执行操做的状态码。
100(继续)请求者应当继续提出请求。服务器返回此代码表示已收到请求的第一部分,正在等待其他部分。
101(切换协议)请求者已要求服务器切换协议,服务器已确认并准备切换。只有在切换新的协议更有好处的时候才应该采起相似措施。
102 Processing由WebDAV(RFC 2518)扩展的状态码,表明处理将被继续执行。
2、成功
2xx (成功)
表示成功处理了请求的状态码。
200(成功)服务器已成功处理了请求。一般,这表示服务器提供了请求的网页。若是是对您的 robots.txt 文件显示此状态码,则表示 Googlebot 已成功检索到该文件。
201(已建立)请求成功而且服务器建立了新的资源。
202(已接受)服务器已接受请求,但还没有处理。
203(非受权信息)服务器已成功处理了请求,但返回的信息可能来自另外一来源。
204(无内容)服务器成功处理了请求,但没有返回任何内容。
205(重置内容)服务器成功处理了请求,但没有返回任何内容。与 204 响应不一样,此响应要求请求者重置文档视图(例如,清除表单内容以输入新内容)。
206(部份内容)服务器成功处理了部分 GET 请求。
3、重定向
3xx (重定向)
要完成请求,须要进一步操做。一般,这些状态码用来重定向。Google 建议您在每次请求中使用重定向不要超过 5 次。您可使用网站管理员工具查看一下 Googlebot 在抓取重定向网页时是否遇到问题。诊断下的网络抓取页列出了因为重定向错误致使 Googlebot 没法抓取的网址。
300(多种选择)针对请求,服务器可执行多种操做。服务器可根据请求者 (user agent) 选择一项操做,或提供操做列表供请求者选择。
301(永久移动)请求的网页已永久移动到新位置。服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置。您应使用此代码告诉某个网页或网站已永久移动到新位置。
302(临时移动)服务器目前从不一样位置的网页响应请求,但请求者应继续使用原有位置来响应之后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码相似,会自动将请求者转到不一样的位置,但您不该使用此代码来告诉某个网页或网站已经移动,由于 Googlebot 会继续抓取原有位置并编制索引。
303(查看其余位置)请求者应当对不一样的位置使用单独的 GET 请求来检索响应时,服务器返回此代码。对于除 HEAD 以外的全部请求,服务器会自动转到其余位置。
304(未修改)自从上次请求后,请求的网页未修改过。服务器返回此响应时,不会返回网页内容。
若是网页自请求者上次请求后再也没有更改过,您应将服务器配置为返回此响应(称为 If-Modified-Since HTTP 标头)。服务器能够告诉 Googlebot 自从上次抓取后网页没有变动,进而节省带宽和开销。
305(使用代理)请求者只能使用代理访问请求的网页。若是服务器返回此响应,还表示请求者应使用代理。
307(临时重定向)服务器目前从不一样位置的网页响应请求,但请求者应继续使用原有位置来响应之后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码相似,会自动将请求者转到不一样的位置,但您不该使用此代码来告诉 Googlebot 某个页面或网站已经移动,由于 Googlebot 会继续抓取原有位置并编制索引。
4、请求错误
4xx(请求错误)
这些状态码表示请求可能出错,妨碍了服务器的处理。
400(错误请求)服务器不理解请求的语法。
401(未受权)请求要求身份验证。对于登陆后请求的网页,服务器可能返回此响应。
403(禁止)服务器拒绝请求。若是您在 Googlebot 尝试抓取您网站上的有效网页时看到此状态码(您能够在 Google 网站管理员工具诊断下的网络抓取页面上看到此信息),多是您的服务器或主机拒绝了 Googlebot 访问。
404(未找到)服务器找不到请求的网页。例如,对于服务器上不存在的网页常常会返回此代码。
若是您的网站上没有 robots.txt 文件,而您在 Google 网站管理员工具"诊断"标签的 robots.txt 页上看到此状态码,则这是正确的状态码。可是,若是您有 robots.txt 文件而又看到此状态码,则说明您的 robots.txt 文件可能命名错误或位于错误的位置(该文件应当位于顶级域,名为 robots.txt)。
若是对于 Googlebot 抓取的网址看到此状态码(在"诊断"标签的 HTTP 错误页面上),则表示 Googlebot 跟随的多是另外一个页面的无效连接(是旧连接或输入有误的连接)。
405(方法禁用)禁用请求中指定的方法。
406(不接受)没法使用请求的内容特性响应请求的网页。
407(须要代理受权)此状态码与 401(未受权)相似,但指定请求者应当受权使用代理。若是服务器返回此响应,还表示请求者应当使用代理。
408(请求超时)服务器等候请求时发生超时。
409(冲突)服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码,以及两个请求的差别列表。
410(已删除)若是请求的资源已永久删除,服务器就会返回此响应。该代码与 404(未找到)代码相似,但在资源之前存在而如今不存在的状况下,有时会用来替代404代码。若是资源已永久移动,您应使用 301 指定资源的新位置。
411(须要有效长度)服务器不接受不含有效内容长度标头字段的请求。
412(未知足前提条件)服务器未知足请求者在请求中设置的其中一个前提条件。
413(请求实体过大)服务器没法处理请求,由于请求实体过大,超出服务器的处理能力。
414(请求的 URI 过长)请求的 URI(一般为网址)过长,服务器没法处理。
415(不支持的媒体类型)请求的格式不受请求页面的支持。
416(请求范围不符合要求)若是页面没法提供请求的范围,则服务器会返回此状态码。
417(未知足指望值)服务器未知足"指望"请求标头字段的要求。
5、服务器错误
5xx(服务器错误)
这些状态码表示服务器在处理请求时发生内部错误。这些错误多是服务器自己的错误,而不是请求出错。
500(服务器内部错误)服务器遇到错误,没法完成请求。
501(还没有实施)服务器不具有完成请求的功能。例如,服务器没法识别请求方法时可能会返回此代码。
502(错误网关)服务器做为网关或代理,从上游服务器收到无效响应。
503(服务不可用)服务器目前没法使用(因为超载或停机维护)。一般,这只是暂时状态。
504(网关超时)服务器做为网关或代理,可是没有及时从上游服务器收到请求。
505(HTTP 版本不受支持)服务器不支持请求中所用的 HTTP 协议版本。
参考: