HTTPD协议详解

http简介

HTTP：全称为HyperText  Transfer Protocol（超文本传输协议），是目前互联网使用最多最广泛的一种协议。在早期的HTTP协议版本（http/0.9）中，http服务仅支持二进制（ASCII）的纯文本文件。而在http/0.9以后的版本中，http协议可以支持MIME机制，使得http协议可以支持多种格式的文本文件，例如视频、图像、语音等等。从而丰富了http协议的发展。

 

什么是MIME？

MIME：全称是Mulitpurpose  Internet  Mail Extension,多用途邮件扩展，MIME是一种协议，早期应用于邮件系统，后来该协议也被应用到了浏览器当中，所以至今我们打开某个网页时，可以出现多种格式的文本信息。这是因为MIME引进了base64编码机制，它能够将非文本信息（如二进制格式的数据）在传输前重新编码为文本格式，接收方能够用相反的机制将其还原为原来的格式，并且可以调用相应的程序来打开此文件。

 

什么是URI和URL？

我们在打开某一个页面时，常常看到有图片、视频及文档等信息，我们把这样每一个信息叫做一个资源或者也可以称作一个web对象。多个资源或者web对象就组成了一个html格式的页面。 而我们常常打开浏览器时，在浏览器上面需要输入网址，才可以访问那个页面的资源。这个网址就是我们常说的URL。

URL：全称Uniform  Record  Locator，统一资源定位符，它不仅定义了资源，还明确指定了资源所在的位置。

URL通常由以下三部分组成：

a、方案（其实简单的理解就是我们常说的访问协议，如http、ftp等）

b、存放资源的主机地址（主机名或ip，有时也包括端口号）

c、资源的具体路径（文件名或目录）

如http://www.baidu.com/a/a.html这就是一个URL。其中方案为http，主机为www.baidu.com，资源路径为/a/a.html。

 

有时候我们也会常常看到URI，那么URI是什么呢？它和URL是什么关系？

URI：全称Uniform Record  Indentifier，全局统一资源标识符，它笼统地定义了资源且是全局的，不限于客户端和服务器端，虽然URI也是用来定义资源的，但是它的定义是抽象的，而URL是具体的定义了这个资源的所在位置，因此URL是URI的子对象或者是子集。

 

但是我们常常在点击某个页面时，浏览器上面显示的不是以.html为后缀的URL，而是以.php为后缀的URL。这是什么原因造成的呢？

这是因为在我们的web服务器上面存的并不是html格式的文件，而是一些脚本文件，当客户端发起请求时，web服务器会调用某个协议来执行这些脚本，这些脚本执行完毕后，就会生成一个html格式的文档，web服务器在将生成的HTML格式的文档返回给客户端。这就是我们为什么看到的是一个html格式的文档，而浏览器上面显示的就是以.php为后缀的URL。而这种脚本文件是通过PHP语言来实现的。而这种机制就是动态网页的实现机制。

对于动态网页来说，既包括静态内容也包括动态内容。

静态内容一般指的是图片等信息，这些静态内容是直接存在服务器是上的。

动态内容需要通过脚本来执行，所以一般的，只有动态内容才会运行脚本，静态内容不会。

 

在有些时候，我们打开某个网页会很快，但打开其他的页面时会很稍微慢一点，这是为什么呢？

这是在http/1.0以后，由于增加了缓存机制，所以当我们第一次打开某个网页时，web服务器会将这个URL缓存在本地，所以第二次打开网页时明显要比第一次快些。因此，建议大家不要随便清理缓存，这样会导致网页加载速度比较慢哦！

 

http的报文格式

由于http是基于tcp协议的，所以在建立http会话的过程中，会经历过三次握手和四次断开。因此，当客户端发起时，服务器必须对该请求给予响应。http协议的端口号是80

http报文的请求格式

<method>  <request-URI>  <version>

<headers>    

<entity-body>

 

http报文的响应格式

<version> <status>  <reason-phrase>

<headers>

<entity-body>

 

其中<method>表示为请求的方法。一般常用的方法有GET、POST、HEAD、DELETE、PUT等等。

<request-URI>表示请求的URI地址。

<version>表示http协议的版本号。

<headers>表示http的首部信息。首部信息一般有多行，每一行使用name:value的形式显示。

<entity-body>表示的是报文主体，报文主体分为请求报文主体和响应报文主体。

<status>表示的是响应报文的状态码。

<reason-phase>:用来描述响应的结果或者理解成用来描述状态码的文本信息。

 

http协议版本

http0.9：只能传输html文档；
http1.0：支持多媒体数据的处理，保持连接。有缓存功能；
http1.1：支持更多的请求方法，更加精细的缓存控制，支持持久连接；

 

http的请求方法

http的请求方法大概有如下这些：

GET、HEAD、PUT、POST、DELETE、OPTIONS、TRACE等等。常用的请求方法及其功能有如下几种：

请求的方法类型该方法的用途
GET请求获取一个资源，该资源需要服务器发送。
HEAD和GET方法相似，只不过服务不需要发送资源，只返回响应首部信息。
PUT与GET方法相反，用于上传信息，向服务器写入文档。用于发布系统。
POST支持HTML表单提交，表单中有用户填入的数据，这些数据会上传至服务器，并存储到某个位置。
DELETE请求删除URL指向的资源。
OPTIONS探测服务器端对某资源所支持的请求方法。
TRACE追踪资源所经过的代理、防火墙和网关。

 

 

http的响应状态码

http的状态码主要分为这几类：

1xx:表示纯信息。
2xx:表示成功状态码（例如：200、201、202...）

        200：表示ok，响应成功。
3xx:表示重定向类的状态码（例如301，302，304），表示该资源不在此处，重定向到其他服务器或其他位置去了。

        301：Moved  Permanebtly，表示永久重定向。在响应报文中使用"Location:URL"的方式来指定该资源所在的位置，然后在向该资源现在所在的服务器发起请求。以后客户端在请求该资源时，直接请求Location中指定资源的位置，不在向本服务器发起请求，这就是所谓的永久重定向。

        302：Found，表示临时重定向。在响应报文中使用"Location:URL"的方式来指定该资源临时存放的位置，然后在向该资源现在所在的位置发起请求。当客户端下次请求该资源时，仍然向本服务器发起请求。由于是临时重定向，因此资源位置并不是固定的。

        304：Not modify，资源没有被修改，用于http条件式缓存机制中。

4xx:表示客户端错误类状态码（例如403，404）。

        401：服务器端拒绝客户端请求，说明请求时需要提供用户名和密码。

        403：Forbidden，请求被服务器拒绝。可能由于没有权限导致的。

        404：Not Found，服务器端无法找到请求的URL，该资源可能不在该服务器上。

        405：Method Not Allow，不允许使用此方法来请求响应的URL。
5xx:表示服务器端错误类状态码。

        500：Internet Server Error，服务器内部错误。

        502：Bad Gateway，代理服务器从上游收到一条伪响应。

        503：Service  Unavailable，服务器此时无法提供服务，但是将来可能有用。

 

 

http报文首部

http的报文首部包括：通用报文首部、请求报文首部、响应报文首部这三大类。

通用首部：通用首部既可以用于请求报文首部中又可以用于响应报文首部中。
        Connection：定义C/S之间关于请求/响应的有关选项；
        Via：显示了报文经过的中间节点（代理或网关）；
        Cache-Control：缓存指示；
        Pragma ：另一种随报文传送指示的方式，但并不专用于缓存；

 

请求报文首部
       Cilent-IP：请求端IP；
       Host：请求的主机名和端口号，在虚拟主机环境下用于不同的虚拟主机；
       Referer：指明了请求当前资源的原始资源的URL，即当前资源从哪个URL跳转过来的。
       User-Agent：用户代理，客户端使用什么工具发出的请求；

       Accept首部：用户标明客户自己更倾向于支持使用的能力；
       Accept：指明服务器能发送哪些媒体类型；
       Accept-Charset：客户端支持使用的字符集；
       Accept-Encoding：客户端支持使用的编码方式；
       Accept-Language：客户端支持使用的语言；

       条件请求首部：
       Expect：允许客户端列出某请求要求服务器的行为；
       If-Modified-Since：是否在指定的时间以来修改过此资源；
       If-None-Match

       跟安全相关的请求首部：
       Authorization：客户端提交给服务端的认证数据，如账号和密码及认证算法；
       Cookie：客户端发送给服务器端身份标识,这样服务器端就可以判断该客户端之前是否访问过。
       Cookie2

代理请求首部：
       Max-Forword ：在通往后端服务器的路径上，将请求转发给其他代理或网关的最大次数-与TRACE方法一同使用
       Proxy-Authorization ：与Authorization首部相同，但这个首部是在与代理进行认证时使用的
       Proxy-Connection ：与Connection首部相同，但这个首部是在与代理建立连接时使用的

 

响应报文首部：
       Age：响应持续的时间
       Server：向客户端标明服务器程序名称和版本

       public：服务器支持某资源的请求方法列表

       协商首部：
       Accept-Ranges：对当前资源来讲，服务器所能够接受的范围类型；
       Vary： 服务器查看的其他首部的列表，可能会使响应发生变化；也就是说，这是一个首部列表，服务器会根据这些首部的内容挑选出最合适的资源版本发送给客户端。

        跟安全相关的响应首部

        Proxy-Authenticate 来自代理服务器对客户端的质询列表；
        Set-Cookie：服务器端在某客户端第一次请求时发给的令牌；
        Set-Cookie2：
        WWW-Authenication：质询，即要求客户端提供账号和密码；

        实体首部：
        Location：资源的新位置；
        Allow：允许对此资源使用的请求方法；

        内容首部：
        Content-Encoding：      实体使用的编码方式
        Content-Language：     实体所使用的语言
        Content-Length：           实体的长度或尺寸
        Content-type ：              实体的类型
        Content-Range：           实体的字节范围
        Content-Location：       资源实际所处的位置

        缓存首部：
        ETag：与实体有关的实体标签；
        Expires：实体内容过期标签；
        Last-Modified：实体内容上一次的修改时间；

 

 

 

例如：请求报文：
GET / HTTP/1.1
Host: www.xsl.com

Connection: keep-alive

 

响应报文：
HTTP/1.1 200 OK
X-Powered-By: PHP/5.2.17
Vary: Accept-Encoding,Cookie,User-Agent
Cache-Control: max-age=3, must-revalidate
Content-Encoding: gzip
Content-Length: 6931

上面两个报文的第一行通常称为“起始行（start  line）”；后面的标签格式内容称作为首部域（Header field），每个首部域都有名称（name）和值（value）组成，有多个值可以使用逗号隔开。另外，响应报文通常还有一个称作为body的信息主体，即响应给客户端的内容。

 

 

web服务器的工作流程 

web服务器是如何工作的呢？

web服务器的主要操作：

1、建立连接---接受或拒绝客户端的连接请求

2、接受请求---通过网络读取HTTP请求报文

3、处理资源---解析请求报文并作出相应的动作

4、访问资源---访问请求报文中的相应资源

5、构建响应---使用正确的首部生成HTTP响应报文

6、发送响应---向客户端发送生成的响应报文

7、记录日志---把已经完成的HTTP事务记录进日志文件

 

 


Web服务器处理请求的几种架构：

1、单线程web服务器(Single-threaded web servers)

此种架构方式中，web服务器只生成一个进程或线程，因此一次只处理一个请求，结束后读取并处理下一个请求。在某请求处理过程中，其它所有的请求将被忽略，因此，在并发请求较多的场景中将会出现严重的必能问题。

 

2、多进程/多线程web服务器

此种架构方式中，web服务器生成多个进程或线程并行处理多个用户请求，进程或线程可以按需或事先生成。有的web服务器应用程序为每个用户请求生成一个单独的进程或线程来进行响应，不过，一旦并发请求数量达到成千上万时，多个同时运行的进程或线程将会消耗大量的系统资源。

 

3、I/O多路复用web服务器

为了能够支持更多的并发用户请求，越来越多的web服务器正在采用多路复用的架构——同步监控所有的连接请求的活动状态，当一个连接的状态发生改变时(如数据准备完毕或发生某错误)，将为其执行一系列特定操作；在操作完成后，此连接将重新变回暂时的稳定态并返回至打开的连接列表中，直到下一次的状态改变。由于其多路复用的特性，进程或线程不会被空闲的连接所占用，因而可以提供高效的工作模式。这种结构下，一个线程处理多个请求。

 

4、多路复用多线程web服务器

将多进程和多路复用的功能结合起来形成的web服务器架构，其生成多个线程，每一个线程响应多个请求。避免了让一个进程服务于过多的用户请求，并能充分利用多CPU主机所提供的计算能力。由于一个进程生成多个线程，这些生成的线程之间的资源是共享的，因此会产生资源。