HTTP协议学习

这几天对于http的学习，写一篇文章算是对自己的总结，也可以记录一下。

1.HTTP定义：

1） HTTP协议（超文本协议）的定义：

一种详细规定了浏览器和万维网服务器之间的相互通信规则，通过因特网传送万维网文档的数据传送协议。

 

2)   HTTP协议主要特点：

              1.支持客户/服务器模式

              2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

              3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

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

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

 

3）URL（UniformResource Locator）

地址用于描述一个网络上的资源。

基本格式如下：

schema://host[:port#]/path/.../[;url-params][?query-string][#anchor]

 

         scheme              指定低层使用的协议(例如：http, https, ftp)

         host                  HTTP服务器的IP地址或者域名

         port#                HTTP服务器的默认端口是80，这种情况下端口号可以省略。如果使用了别的端口，必须指明，例如http://www.cnblogs.com:8080/

         path                  访问资源的路径

         url-params

query-string      发送给http服务器的数据

anchor-            锚

 

例子，如下图：

图（1-1-1）

2.HTTP消息：

HTTP消息有客户端到服务器的请求消息和从服务器到客户端的响应消息两部分组成。

1、 HTTP请求：

       HTTP请求由三部分组成，分别是：请求行、消息报头（http header）、请求正文（http body）。

在header和body之间有一个空行。

请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本。

其中Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

图（2-1-1）

如图 2-1-1 所示：

       第一行中的Method表示请求方法，Path-to-resoure表示请求资源，HTTP/version-number 表示HTTP协议的版本号。

       当使用”GET” 方法的时候，body是为空的。

       例子：打开百度首页为：

       GET http://www.baidu.com/HTTP/1.1

       Host: www.baidu.com

 

请求方法（所有方法全为大写）有多种，各个方法的解释如下：

GET                     请求获取Request-URI所标识的资源

POST             在Request-URI所标识的资源后附加新的数据

HEAD           请求获取由Request-URI所标识的资源的响应消息报头

PUT               请求服务器存储一个资源，并用Request-URI作为其标识

DELETE        请求服务器删除Request-URI所标识的资源

TRACE          请求服务器回送收到的请求信息，主要用于测试或诊断

CONNECT     保留将来使用

OPTIONS      请求查询服务器的性能，或者查询与资源相关的选项和需求

 

图（2-1 - 2）

2、 HTTP响应：

       在接收和解释请求消息后，服务器返回一个HTTP响应消息。

HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文、状态行格式如下：

HTTP-VersionStatus-CodeReason-PhraseCRLF

其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。

图（2-2-1）

状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：

1xx：指示信息--表示请求已接收，继续处理

2xx：成功--表示请求已被成功接收、理解、接受

3xx：重定向--要完成请求必须进行更进一步的操作

4xx：客户端错误--请求有语法错误或请求无法实现

5xx：服务器端错误--服务器未能实现合法的请求常见

状态代码、状态描述、说明：

200OK                  //客户端请求成功

400BadRequest      //客户端请求有语法错误，不能被服务器所理解

401Unauthorized    //请求未经授权，这个状态代码必须和WWW-Authenticate报//头域一起使用

403Forbidden        //服务器收到请求，但是拒绝提供服务

404NotFound         //请求资源不存在，eg：输入了错误的URL

500InternalServerError  //服务器发生不可预期的错误

503ServerUnavailable    //服务器当前不能处理客户端的请求，一段时间后，//可能恢复正常

eg：HTTP/1.1200OK（CRLF）

2、响应报头,下列描述HTTP/1.1中常用到的头标

Accept                 

                            定义客户端可以处理的媒体类型，按优先级排序；在一个以逗号为分隔的列表中，可以定义多种类型和使用通配符。例如：Accept:image/jpeg,image/png,*/*

Accept-Charset      

定义客户端可以处理的字符集，按优先级排序；

在一个以逗号为分隔的列表中，可以定义多种类型和使用通配符。例如：Accept-Charset: iso- 8859-1,*,utf-8

Accept-Encoding 

定义客户端可以理解的编码机制。例如：Accept-Encoding:gzip,compress

Accept-Language 

定义客户端乐于接受的自然语言列表。例如：Accept-Language:en,de

Accept-Ranges     

一个响应头标，它允许服务器指明：将在给定的偏移和长度处，为资源组成部分的接受请求。该头标的值被理解为请求范围的度量单位。例如Accept-Ranges: bytes或Accept- Ranges: nonea

Age                 

                            允许服务器规定自服务器 生成该响应以来所经过的时间长度，以秒为单位。该头标主要用于缓存响应。例如：Age: 30

Allow             

一个响应头标，它定义一个由位于请求URI中的次源所支持的HTTP方法列表。例如：Allow: GET,PUT

Cache-Control   

一 个用于定义缓存指令的通用头标。例如：Cache-Control: max-age=30

Connection           

一个用于表明是否保存socket连接为开放的通用头标。例如：Connection:close或Connection: keep-alive

Content-Base         

一种定义基本URI的实体头标，为了在实体范围内解析相对URLs。

如果没有定义Content-Base头标解析相对URLs，使用Content-LocationURI（存在且绝对）或使 用URI请求。

                           例如：Content-Base: Http://www.myweb.com

Content-Encodin   

一种介质类型修饰符，标明一个实体是如何编码的。例如：Content-Encoding:zip

Content-Language

用 于指定在输入流中数据的自然语言类型。例如：Content-Language: en

Content-Length  

指定包含于请求或响应中数据的字节长度。例如：Content-Length:382

Content-Location   

指定包含于请求或响应中的资源定位（URI）。

                          如果是一绝。对URL它也作为被解析实体的相对URL的出发点。

                   例如：Content-Location: http://www.myweb.com/news

Contern-Type    

标明发送或者接收的实体的MIME类型。例如：Content-Type: text/html

Date           

发送HTTP消息的日期。例如：Date: Mon,10PR 18:42:51 GMT

ETag                      

一种实体头标，它向被发送的资源分派一个唯一的标识符。

对于可以使用多种URL请求的资源，ETag可以用于确定实际被发送的资源是否为同一资源。例如：ETag:"208f-419e-30f8dc99"

Host                     

                            被请求资源的主机名。对于使用HTTP/1.1的请求而言，此域是强制性的。例 如：Host: www.myweb.com

Server       

一种标明Web服务器软件及其版本号的头标。例 如：Server: Apache/2.0.46(Win32)

User-Agent

                   定义用于产生请求的软件类型（典型的如Web浏览器）。

                   例如：User- Agent: Mozilla/4.0(compatible; MSIE 5.5; Windows NT; DigExt)

Via                      

                            一个包含所有中间主机和协议的通用头标，用于满足请求。例 如：Via: 1.0 fred.com, 1.1 wilma.com

Warning            

用于提供关于响应状态补充信息的响应头标。例如：Warning: 99 www.myweb.com Pianoneeds tuning

3、响应正文就是服务器返回的资源的内容

              可以为html等文件或者信息。

 

3.HTTP协议安全认证

HTTP认证 基于 质询 /回应(challenge/response)的认证模式。

 

HTTP请求报头： Authorization

HTTP响应报头： WWW-Authenticate

 

1、基本认证

basicauthentication是由HTTP1.0提出的认证方法：客户端对于每一个realm，通过提供用户名和密码来进行认证的方式，包含密码的明文传递。

 

    基本认证步骤：

     1. 客户端访问一个受http基本认证保护的资源。

     2. 服务器返回401状态，要求客户端提供用户名和密码进行认证。

           401 Unauthorized

           WWW-Authenticate： Basicrealm="WallyWorld"

     3. 客户端将输入的用户名密码用Base64进行编码后，采用非加密的明文方式传送给服务器。

           Authorization: Basic xxxxxxxxxx.

     4. 如果认证成功，则返回相应的资源。如果认证失败，则仍返回401状态，要求重新进行认证。

 

    特记事项：

     1. Http是无状态的，同一个客户端对同一个realm内资源的每一个访问会被要求进行认证。

     2. 客户端通常会缓存用户名和密码，并和authentication realm一起保存，所以，一般不需要你重新输入用户名和密码。

     3. 以非加密的明文方式传输，虽然转换成了不易被人直接识别的字符串，但是无法防止用户名密码被恶意盗用。

 

2、摘要认证

digestauthentication是由HTTP1.1提出的基本认证的替代方法。

        服务器端以nonce进行质询，客户端以用户名，密码，nonce，HTTP方法，请求的URI等信息为基础产生的response信息进行认证的方式，不包含密码的明文传递。

   

    摘要认证步骤：

     1. 客户端访问一个受http摘要认证保护的资源。

     2. 服务器返回401状态以及nonce等信息，要求客户端进行认证。

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Digest

realm="testrealm@host.com",

qop="auth,auth-int",

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",     //服务端产生的随机数

opaque="5ccc069c403ebaf9f0171e9517f40e41"   //服务器产生的有客户下去请求时原样返回。最好是Base64串或十六进制字符串。

 

     3. 客户端将以用户名，密码，nonce值，HTTP方法, 和被请求的URI为校验值基础而加密（默认为MD5算法）的摘要信息返回给服务器。

           认证必须的五个情报：

　　・ realm ： 响应中包含信息

　　・ nonce ： 响应中包含信息

　　・ username ： 用户名

　　・ digest-uri ： 请求的URI，拷贝Request-Line，用于Proxy。

　　・ response ： 以上面四个信息加上密码信息，使用MD5算法得出的字符串。

                  加密后的密码

 

Authorization:Digest

username="Mufasa",　 ←　客户端已知信息

realm="testrealm@host.com",　 ←　服务器端质询响应信息

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",　←　服务器端质询响应信息

uri="/dir/index.html",←　客户端已知信息

qop=auth,　 ←　服务器端质询响应信息

nc=00000001,←　客户端计算出的信息，如果服务器看到同样的计数就是一次重放。

cnonce="0a4f113b",←　客户端计算出的客户端nonce，如果pop设置，才设置，用于双向认证，防止攻击。

response="6629fae49393a05397450978507c4ef1",←　最终的摘要信息 ha3

opaque="5ccc069c403ebaf9f0171e9517f40e41"　 ←　服务器端质询响应信息

     4. 如果认证成功，则返回相应的资源。如果认证失败，则仍返回401状态，要求重新进行认证。

 

    特记事项：

     1. 避免将密码作为明文在网络上传递，相对提高了HTTP认证的安全性。

     2. 当用户为某个realm首次设置密码时，服务器保存的是以用户名，realm，密码为基础计算出的哈希值（ha1），而非密码本身。

     3. 如果qop=auth-int，在计算ha2时，除了包括HTTP方法，URI路径外，还包括请求实体主体，从而防止PUT和POST请求表示被人篡改。

     4. 但是因为nonce本身可以被用来进行摘要认证，所以也无法确保认证后传递过来的数据的安全性。

 

   ※　nonce：随机字符串，每次返回401响应的时候都会返回一个不同的nonce。

   ※　nounce：随机字符串，每个请求都得到一个不同的nounce。

      ※　MD5(MessageDigest algorithm 5，信息摘要算法)

         ① 用户名:realm:密码　⇒　ha1

         ② HTTP方法:URI　⇒　ha2

         ③ha1:nonce:nc:cnonce:qop:ha2　⇒　ha3

 

3、  WSSE(WS-Security)认证　　

        WSSEUsernameToken是扩展HTTP认证

        服务器端以nonce进行质询，客户端以用户名，密码，nonce，HTTP方法，请求的URI等信息为基础产生的response信息进行认证的方式，不包含密码的明文传递。

 

 

    WSSE认证步骤：

     1. 客户端访问一个受WSSE认证保护的资源。

     2. 服务器返回401状态，要求客户端进行认证。

HTTP/1.1401 Unauthorized

WWW-Authenticate:WSSE

realm="testrealm@host.com",

profile="UsernameToken"←　服务器期望你用UsernameToken规则生成回应

注：UsernameToken规则：客户端生成一个nonce，然后根据该nonce，密码和当前日时来算出哈希值。

     3. 客户端将生成一个nonce值，并以该nonce值，密码，当前日时为基础，算出哈希值返回给服务器。

Authorization:WSSE profile="UsernameToken"

X-WSSE:UsernameToken

username="Mufasa",

PasswordDigest="Z2Y......",

Nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

Created="2010-01-01T09:00:00Z"

     4. 如果认证成功，则返回相应的资源。如果认证失败，则仍返回401状态，要求重新进行认证。

 

    特记事项：

     1. 避免将密码作为明文在网络上传递。

     2. 不需要在服务器端作设置。

     3. 服务器端必须保存密码本身，否则无法进行身份验证。

 

思考：对于HTTP的安全认证方面，Openssl开源库方面提供了较为全面的支持。