细说HTTP上篇

HTTP概述

 

        天天，都有数以亿万计的JPEG图片、HTML页面、文本文件、MPEG电影、WAV音频文件、Java小程序和其余资源在因特网上游弋。HTTP能够从遍及全世界的Web服务器上将这些信息快速、便捷、可靠的搬移到人们桌面上的Web浏览器上去。

        HTTP，全称Hyper Text Transport Protocal，即超文本传输协议，定义了浏览器如何向服务器请求文档以及服务器怎样把文档传送给浏览器，它是万维网可以可靠的交换文件（包括文本，声音，图像等多种多媒体文件）的基础。

 

起源 

        超文本传输协议的前身是Xanadu项目，超文本的概念是Ted Nelson在1960年代提出的。1989年，Tim Berners Lee在CERN担任软件咨询师的时候，开发了一套程序，奠基了万维网的基础。1990年12月，超文本在CERN首次上线。1991年夏天，继Telnet等协议以后，超文本转移协议成为了互联网诸多协议的一份子。

 

特色 

        一、支持客户/服务器模式。支持基本认证 和安全认证。

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

 

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

 

        四、HTTP 0.9和1.0使用非持续链接：限制每次链接只处理一个请求，服务器处理完客户的请求，并收到客户的应答后，即断开链接。采用这种方式能够节省传输时间。

HTTP 1.1使用持续链接：没必要为每一个web对象建立一个新的链接，一个链接能够传送多个对象。

 

        五、无状态：HTTP协议是 无状态协议。无状态是指协议对于事务处理没有记忆能力。缺乏状态意味着若是后续处理须要前面的信息，则它必须重传，这样可能致使每次链接传送的数据量增大。

 

 Web客户端和服务器交互过程和模型

        客户端/服务器(client/server)这个术语可追溯到上个千年(20世纪80年代)，表示经过网络链接起来的我的计算机。客户端/服务器也可用于描述两个计算机程序的关系--客户程序和服务器程序。客户向服务器请求某种服务(好比请求一个文件或数据库访问)，服务器知足请求并经过网络将结果传送给客户端。虽然客户端和服务器程序可存在于同一台计算机中，但它们一般都运行在不一样计算机上。一台服务器处理多个客户端请求也是很常见的。

        最多见的Web客户端就是浏览器了，一次请求/响应的模型以下图所示：

        

        这里须要说明的一点是，每次访问一个静态资源，好比一个html文件，一个png图片或者一个文本文档都会向服务器发出一个HTTP请求，每一个HTTP请求都会经历上图的请求/响应模型。好比咱们点开http://www.taobao.com/（淘宝网），咱们会往服务器发送成百上千个HTTP请求，收到来自客户端的请求后，服务器会去寻找相应的资源，若是成功，就将对象，对象类型，对象长度以及其余信息放在HTTP响应中发回客户端。那么问题来了，服务器怎么去寻找相应的资源，凭据是什么？

 

URL与资源

        URL是浏览器寻找信息时所须要的资源位置。经过URL，人类和应用程序才能找到使用并共享因特网上大量的数据资源。URL是人们对HTTP和其余协议的经常使用访问点：在浏览器中输入一串URL，浏览器就会在幕后发送适当的协议报文来获取人们所指望的资源。

 

URL的语法 

    大多数的URL方案的URL语法都创建在这个由9部分的通用格式上：

    <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

    几乎没有哪一个URL中包含了全部这些组件。URL最重要的3个部分是方案(scheme)、主机(host)和路径(path)。

 

   

    目前常见的协议类型有不少种，经常使用的有http，https（更安全的http），mailto（邮件），ftp（文件传输），rtsp（音频视频），file，news，telnet等等

 

HTTP报文

        HTTP报文是在HTTP应用程序之间发送的数据块。这些数据块以一些文本形式的元信息开头，这些信息描述了报文的内容和含义，后面跟着可选的数据部分。

 

报文的组成 

        HTTP报文是简单的格式化数据块。每一条报文都包含一条来自客户端的请求，或者来自服务器的响应。它们有三个部分组成：对报文进行描述的起始行（start line）、包含属性的首部块（header），以及可选的、包含数据的主体部分（body）。

HTTP/1.0 200 OK            //起始行

Content-type:text/plain    //首部
Content-length:19          //首部  

Hi I'm a message!          //主体

报文的语法

 

    全部的HTTP报文能够分为两类：请求报文(request message)和响应报文(response message)。请求报文会向服务器发送一个请求，响应报文会将结果返回个客户端。

               

        请求报文的格式：

<method> <request-UTL> <version>
<headers>

<entity-body>

　　    响应报文格式：

<version> <status><reason-phrase>
<header>

<entity-body>

　　

下面是对格式中各部分的简要描述

　　    一、方法(method)　　GET

　　　　    客户端但愿服务器对资源执行的动做。是一个单独的词，好比GET、HEAD或POST。

　　    二、请求的URL(request-URL)

　　　　    命名了全部请求资源，或者URL路径组件的完整URL。若是直接与服务器进行对话，只要URL的路径组件是资源的绝对路径，一般就不会有什么问题--服务器能够假定　义本身是URL的主机/端口。

　　    三、版本(version)　　HTTP/1.1

　　　　   报文所使用的HTTP版本，其格式以下：

　　　　   HTTP/<major>.<minor>

　　　　   其中主要版本号(major)和次要版本号(minor)都是整数。　　

　　   四、状态码(status)

　　　　  这三个数字描述了请求过程当中所发生的状况。每一个状态码的第一位数字都用于描述状态的通常类别("成功"、"出错"等)。

　　   五、缘由短语(reason-phrase)

　　　　  数字状态码的可读版本，包含行终止序列以前的全部文本。缘由短语只是给人类看的，它不能说明什么。客户端依然采用状态码来判断请求/响应是否成功！

　　　　  例如：HTTP/1.0 200 NOT OK 客户端依然会当请求已成功处理。由于状态码是200。而缘由短语只是说明而已，这对于自定义扩展状态码仍是比较有用的。

　　   六、首部(header)

　　　　  能够有0个或多个首部，每一个首部都包含一个名字，后面跟着一个冒号(:)，而后是一个可选的空格，接着是一个值，最后是一个CRLF。首部是由一个空行(CRLF)结束　的，表示了首部列表的结束和实体主体的开始。

　　    七、实体的主体部分(entity-body)

　　　　   实体的主体部分包含一个由任意数据组成的数据块。并非全部的报文都包含实体的主体部分。如GET请求就不包含实体。