IOS网络篇12之Http概述

http概述主要包括以下几个部分：

 

0 Http概述

1 Http之URL

2 Http请求过程概述

3 Http请求

4 Http响应

5 Http消息报头＋正文

6 Http压缩解压过程

 

 

0 Http概述

ü      http://www.w3.org/Protocols/

    http协议的特点：应用层无状态协议

    用于在客户端和服务器之间传输的超文本文件的协议。

            http1.0 1996发布RFC1945。

    http1.1 1999推出RFC2616，废弃了RFC2068。

            http协议在网络通信中的层次结构：

1 Http之URL

    HTTPURL(URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：http://host[":"port][abs_path]。

三部分组成：协议host主机域名或IP地址＋端口号  abs_path 资源的绝对路径

例如：

        输入：www.guet.edu.cn

        浏览器自动转换：http://www.guet.edu.cn/

        域名解析：http:192.168.0.116:8080/index.jsp

2 Http请求过程概述

        主要由以下四个部分组成：

    （1）客户端与服务器端建立连接

    （2）客户端向服务器端发送请求

    （3）服务器端向客户端回复响应

    （4）断开连接

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

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

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

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

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

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

    CONNECT保留将来使用

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

例如：GetPost请求如下：

GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源，eg:GET/form.htmlHTTP/1.1(CRLF)

POST方法要求被请求服务器接受附在请求后面的数据，常用于提交表单。eg：POST/reg.jspHTTP/(CRLF)

Accept:image/gif,image/x-xbit,...(CRLF)...

HOST:www.guet.edu.cn(CRLF)Content-Length:22(CRLF)

Connection:Keep-Alive(CRLF)Cache-Control:no-cache(CRLF)

 

    Http中回车和换行一般都是一起出现：CRLF

    目前最新的http版本是http1.1

3 Http请求

http请求主要由三部分组成：请求行（RequestLine）＋消息报头（headfield（可选））＋实体（entity body）。Suchas：

其中CRLF＝回车＋换行

请求行：请求方法＋http版本（Request  URI  HTTP-Version  CRLF）

如：GET   http://www.hunantv.com/    HTTP/1.1

 

            报头和正文参见第五部分。

            请求log：

GET http://www.yesky.com/pub/WWW/page.html HTTP/1.1

Connection：close

User-agent：Mozilla/4.0

Accept-Encoding：gzip,compress

Accept-language：en

CR LF

Entity-Body

 

4 Http响应

http响应：状态行（Status-Linehttp响应状态行）＋消息报头（HeaderField）＋实体（entity body）。Suchas

状态行：http版本＋状态码＋状态码描述（HTTP_Version＋Status_CodeReason+Phrase  CRLF）

如：HTTP/1.1   200    OK

常用的状态码以及描述如下：

 

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

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

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

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

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

5xx：服务器端错误--服务器未能实现合法的请求常见状态代码、状态描述、说明：

200 OK//客户端请求成功

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

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

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

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

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

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

 

    报头和正文参见第五部分。

            请求log信息如下：

            HTTP/1.1 200 OK

    Connection:close
 Date: Thu, 13 Oct 2005 03:17:33 GMT
 Server: Apache/2.0.54 (Unix) 
 Last—Nodified:Mon,22 Jun 1998 09;23;24 GMT
 Content—Length:682l

  Content-Type：text/html

5 Http消息报头＋正文

            http消息报头：普通报头、请求报头、响应报头、实体报头

        消息报头格式：名字+“：”+空格+值

5.1普通报头

            作用：有少数报头域用于所有的请求和响应消息，但并不用于被传输的实体，只用于传输的消息。

   （1）Cache-Control：用于指示缓存机制。在http1.0中类似的报头域为pragma。

            缓存指令包括请求缓存指令和

请求时的缓存指令包括：no-cache（用于指示请求或响应消息不能缓存）、no-store、max-age、max-stale、min-fresh、only-if-cached;响应时的缓存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.

例如：想指示浏览器（客户端）不要缓存页面，代码如下：response.sehHeader("Cache-Control","no-cache");

   （2）Data：表明消息产生的时间、日期。

   （3）Connection：连接状态，如close，告诉服务器响应完成后关闭连接。

 

5.2请求报头

            作用：客户端向服务器发送请求，发送请求的附加消息，客户端自身的信息。

（1）     Accept：告诉服务器客户端接受哪些类型的数据，例如：Accept：image/gif。Accept：text/html。

（2）     Accept-Charset：指出客户端使用的字符集，例如：Accept-Charset:iso-8859-1,gb2312。缺省情况下任何字符集都是可以接受的。

（3）     Accept-Encoding：指出客户端使用的内容编码方式，eg：Accept-Encoding:gzip.deflate。缺省情况下任何编码方式都是可以接受的。

（4）     Accept-Language：客户端可以接受的语言类型，eg：Accept-Language:zh-cn（简体中文）。缺省情况下对各种语言都可以接受。en-us美国。

（5）     Authorization：请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（未授权），可以发送一个包含Authorization请求报头域的请求，要求服务器对其进行验证。

（6）     Host：http://www.guet.edu.cn/index.html 这时Host：www.guet.edu.cn，缺省端口号80.

（7）     User-Agent：允许服务器读取客户端的一些信息，如操作系统版本号，浏览器类型等。

（8）     Referer：指出引用页面的URL。

 

5.3响应报头

   （1）Location：响应报头域用于重定向接受者到一个新的位置。

   （2）Server：响应报头域包含了服务器用来处理请求的软件信息，与User-Agent对应的。

   （3）WWW-Authenticate：响应报头域必须被包含在401（未授权的）响应消息中，客户端收到401响应消息时候，并发送Authorization报头域请求服务器对其进行验证时，服务端响应报头就包含该报头域。eg：WWW-Authenticate:Basicrealm="BasicAuthTest!"//可以看出服务器对请求资源采用的是基本验证机制。

 

5.4实体报头

   （1）Content-Encoding：实体正文的附加内容的编码，因而要获得Content-Type报头域中所引用的媒体类型，必须采用相应的解码机制。Content-Encoding这样用于记录文档的压缩方法，eg：Content-Encoding：gzip。

   （2）Content-Language：实体报头域描述了资源所用的自然语言。没有设置该域则认为实体内容将提供给所有的语言阅读。

   （3）Content-Length：实体报头域用于指明实体正文的长度，以字节方式存储的十进制数字来表示。

   （4）Content-Type：实体报头域用语指明发送给接收者的实体正文的媒体类型。eg：Content-Type:text/html;charset=ISO-8859-1Content-Type:text/html;charset=GB2312。

   （5）Last-Modified：实体报头域用于指示资源的最后修改日期和时间。

   （6）Expires：实体报头域给出响应过期的日期和时间，缓存的时候使用。

 

6 Http压缩解压过程

http中可以对内容，即body部分进行编码。可以采用gzip这种数据压缩方式，从而达到数据压缩，加密的效果。

http压缩压缩过程如下：

            （1）浏览器向web服务器发送request，指明：Accept-Encoding: gzip, deflate。告诉服务器，客户端可以接受哪些压缩方式。

            （2）web服务器根据接收到的数据压缩请求，生成原始的responese。包括Content-Type和Content-Length。

            （3）web服务器开始进行数据压缩，并修改Content-Length，增加Content-Encoding:gzip字段。

            （4）客户端根据response发送过来的Content-Encoding:gzip，开始解压。

            内容编码分类：httprequesthead中：Content-Encoding 指明是否有压缩，当没有这个头的时候表示数据没有压缩。

gzip  表明实体采用GNU zip编码 

compress 表明实体采用Unix的文件压缩程序

deflate  表明实体是用zlib的格式压缩的

identity  表明没有对实体进行编码。当没有Content-Encoding header时， 就默认为这种。

gzip, compress, 以及deflate编码都是无损压缩算法，其中gzip效率最高，使用范围也最广。

gzip压缩的优缺点：Gzip压缩是在一个文本文件中找出类似的字符串， 并临时替换他们，使整个文件变小。这种形式的压缩对Web来说非常适合， 因为HTML和CSS文件通常包含大量的重复的字符串，例如空格，标签。但对于图片来说，图像是由一个个的像素点组成的，gzip对这种压缩效果不明显，而且它本身又是有损压缩的所以就效果更不明显了。

            在http请求响应中，响应可以压缩，同样的请求也是可以压缩的。

    抓HTTP包的时候发现很多网站的响应报文是gzip压缩后的数据，存放在一个或多个chunk里面（参见HTTP响应报文中的chunked）。这些gzip数据是不可阅读的，需要进行解压。Deflate压缩算法 Inflate解压算法。