HTTP无状态协议

看到有篇帖子 有关http 的以下介绍,有几个疑问,
1 HTTP是一个无状态的面向连接的协议 这个连接是知的TCP连接吗?
2 保持连接性 是指的保持TCP连接吗?
3 HTTP两次不同的请求 第一次请求之后,服务器端立即关闭连接、释放资源 这里的关闭连接 是指关闭哪个链接?如果此时 Connection: keep-alive 呢?

无状态是指协议对于事务处理没有记忆能力,服务器不知道客户端是什么状态。从另一方面讲,打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系
HTTP是一个无状态的面向连接的协议,无状态不代表HTTP不能保持TCP连接,更不能代表HTTP使用的是UDP协议(无连接)
从HTTP/1.1起,默认都开启了Keep-Alive,保持连接特性,简单地说,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接
Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间

共收到  4 条回复
8
hooopo 1楼, 1年前  喜欢 

有无状态是和ftp相比的吧

C3eea445243ec881aca2c6a4ce2c1e84
zhangyuan 2楼, 1年前  喜欢 

随手翻《用TCP/IP进行网际互联:第三卷 客户端-服务器编程与应用》:

服务器所维护的与客户交互活动的信息称为状态信息。不保存任何状态信息的服务器称为无状态服务器(stateless server),反之则称为有状态服务器(stateful server)。

面向连接对应的是底层使用TCP,无连接对应的是UDP。

 

HTTP的无状态,指的就是在在应用层这个层次上,服务器没有保存客户端的状态信息吧,客户端必须每次带上自己的状态去请求服务器(比如cookie、session等)。面向连接,就是底层使用TCP。

946dbc66d19ba815ffec20d05f138f73
linjunhalida 3楼, 1年前  喜欢 

keep-alive是连接层上的事情, 上层不会有影响. 只是为了节省建立多次tcp连接的成本.
具体见: http://en.wikipedia.org/wiki/HTTP_persistent_connection

 

 

HTTP无状态协议

 
HTTP协议是无状态协议。
无状态是指协议对于 事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。
客户端与服务器进行动态交互的Web应用程序出现之后,HTTP无状态的特性严重阻碍了这些应用程序的实现,毕竟交互是需要承前启后的,简单的购物车程序也要知道用户到底在之前选择了什么商品。于是,两种用于保持HTTP连接状态的技术就应运而生了,一个是 Cookie,而另一个则是 Session。HTTP本身是一个无状态的 连接协议,为了支持 客户端与服务器之间的交互,我们就需要通过不同的技术为交互存储状态,而这些不同的技术就是Cookie和Session了。
Cookie是通过 客户端保持状态的解决方案。从定义上来说,Cookie就是由服务器发给 客户端的特殊信息,而这些信息以文本文件的方式存放在客户端,然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。让我们说得更具体一些:当用户使用 浏览器访问一个支持Cookie的网站的时候,用户会提供包括用户名在内的个人信息并且提交至服务器;接着,服务器在向 客户端回传相应的 超文本的同时也会发回这些个人信息,当然这些信息并不是存放在HTTP响应体(Response Body)中的,而是存放于HTTP响应头(Response Header);当客户端 浏览器接收到来自服务器的响应之后,浏览器会将这些信息存放在一个统一的位置,对于Windows操作系统而言,我们可以从: [ 系统盘]:\Documents and Settings\[用户名]\Cookies目录中找到存储的Cookie;自此,客户端再向服务器发送请求的时候,都会把相应的Cookie再次发回至服务器。而这次,Cookie信息则存放在HTTP请求头(Request Header)了。
有了Cookie这样的技术实现,服务器在接收到来自客户端浏览器的请求之后,就能够通过分析存放于请求头的Cookie得到客户端特有的信息,从而动态生成与该客户端相对应的内容。通常,我们可以从很多网站的登录界面中看到“请记住我”这样的选项,如果你勾选了它之后再登录,那么在下一次访问该网站的时候就不需要进行重复而繁琐的登录动作了,而这个功能就是通过Cookie实现的。
与Cookie相对的一个解决方案是Session,它是通过服务器来保持状态的。由于Session这个词汇包含的语义很多,因此需要在这里明确一下 Session的含义。首先,我们通常都会把Session翻译成会话,因此我们可以把 客户端浏览器与服务器之间一系列交互的动作称为一个 Session。从这个语义出发,我们会提到Session持续的时间,会提到在Session过程中进行了什么操作等等;其次,Session指的是服务器端为 客户端所开辟的 存储空间,在其中保存的信息就是用于保持状态。从这个语义出发,我们则会提到往Session中存放什么内容,如何根据键值从 Session中获取匹配的内容等。
要使用Session,第一步当然是创建Session了。那么Session在何时创建呢?当然还是在服务器端程序运行的过程中创建的,不同语言实现的应用程序有不同创建Session的方法,而在Java中是通过调用HttpServletRequest的getSession方法(使用true作为参数)创建的。在创建了Session的同时,服务器会为该Session生成唯一的Session id,而这个Session id在随后的请求中会被用来重新获得已经创建的Session;在Session被创建之后,就可以调用Session相关的方法往Session中增加内容了,而这些内容只会保存在服务器中,发到客户端的只有Session id;当客户端再次发送请求的时候,会将这个Session id带上,服务器接受到请求之后就会依据Session id找到相应的Session,从而再次使用之。正式这样一个过程,用户的状态也就得以保持了。
综上所述,HTTP本身是一个无状态的连接协议,为了支持 客户端与服务器之间的交互,我们就需要通过不同的技术为交互存储状态,而这些不同的技术就是Cookie和Session了。
(摘自百度百科,纯属mark)http://baike.baidu.com/view/4551466.htm
HTTP是Hyper Text Transfer Protocol的缩写,顾名思义,这个协议支持着超文本的传输。那么什么是超文本呢?说白了就是使用HTML编写的页面。通常,我们使用客户端浏览器访问服务器的资源,最常见的URL也是以html为后缀的文件。因此,我们可以说超文本是网络上最主要的资源。

        既然HTTP协议的目的在于支持超文本的传输,更加广义一些就是支持资源的传输,那么在客户端浏览器向HTTP服务器发送请求,继而HTTP服务器将相应的资源发回给客户端这样一个过程中,无论对于客户端还是服务器,都没有必要记录这个过程,因为每一次请求和响应都是相对独立的,就好像你在自动售货机前投下硬币购买商品一样,谁都不会也不需要记住这样一个交易过程。一般而言,一个URL对应着唯一的超文本,而HTTP服务器也绝对公平公正,不管你是Michael,还是Jordon,它都会根据接收到的URL请求返回相同的超文本。正是因为这样的唯一性,使得记录用户的行为状态变得毫无意义,所以,HTTP协议被设计为无状态的连接协议符合它本身的需求。
完整、独立的请求不要求服务器在处理请求时检索任何类型的应用程序上下文或状态。

为了赋予客户端请求最适合它们的特定内容类型的能力,您的服务的构造应该利用内置的 HTTP Accept Header,其中该 Header 的值为 MIME 类型。 基于 REST 的服务使用的一些常见 MIME 类型如表 1 所示。


表 1. 基于 REST 的服务使用的常见 MIME 类型
MIME-TypeContent-Type
JSONapplication/json
XMLapplication/xml
XHTMLapplication/xhtml+xml

这使得服务可由运行在不同平台和设备上并采用不同语言编写的各种各样的客户端所使用。 使用 MIME 类型和 HTTP Accept Header 是一种称为内容协商 的机制,这种机制允许客户端选择适合于它们的数据格式,并最小化服务与使用服务的应用程序之间的数据耦合。

 

thomescai http://blog.csdn.net/thomescai(转载请保留)

概要:

    之前对这几个概念有点糊涂,查阅了些资料,稍微概括下他们的区别吧。如有错误,请拍~~~

先看图:

TCP/IP是什么?

   TCP/IP是个协议组,可分为三个层次:网络层、传输层和应用层。
   在网络层有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。
   在传输层中有TCP协议与UDP协议。
   在应用层有FTP、HTTP、TELNET、SMTP、DNS等协议。

 

Socket是什么呢?

    Socket是应用层与TCP/IP协议族通信的中间软件抽象层,一组接口,把复杂的TCP/IP协议族隐藏在Socket接口后面。

   所以HTTP就是TCP/IP应用层的协议。Socket是他们的软件抽象层。

短连接:
   连接->传输数据->关闭连接
   HTTP是无状态的,浏览器和服务器每进行一次HTTP操作,就建立一次连接,但任务结束就中断连接。
   也可以这样说:短连接是指SOCKET连接后发送后接收完数据后马上断开连接。
长连接:
    连接->传输数据->保持连接 -> 传输数据-> 。。。 ->关闭连接。
   长连接指建立SOCKET连接后不管是否使用都保持连接,但安全性较差。
http的长连接:
   HTTP也可以建立长连接的,使用Connection:keep-alive,HTTP 1.1默认进行持久连接。HTTP1.1和HTTP1.0相比较而言,最大的区别就是增加了持久连接支持(貌
似最新的 http1.0 可以显示的指定 keep-alive),但还是无状态的,或者说是不可以信任的。

 

参考资料:

http://blog.csdn.net/xijiaohuangcao/article/details/6105623——《写给那些让我糊里糊涂的HTTP、TCP、UDP、Socket

http://hi.baidu.com/loleafver/blog/item/a222c9d853d4f1e638012fa0.html——《http长连接和短连接》

http://hi.baidu.com/einsof/blog/item/f2f3a84b5d1a30fb82025ca0.html——《什么是短连接、长连接、Socket》

================================================

 

socket

Socket协议的形象描述
  socket的英文原义是“孔”或“插座”。在这里作为4BDS UNIX的进程通信机制,取后一种意思。socket非常类似于电话插座。以一个国家级电话网为例。电话的通话双方相当于相互通信的2个进程,区号是它的网络地址;区内一个单位的交换机相当于一台主机,主机分配给每个用户的局内号码相当于socket号。任何用户在通话之前,首先要占有一部电话机,相当于申请一个socket;同时要知道对方的号码,相当于对方有一个固定的socket。然后向对方拨号呼叫,相当于发出连接请求(假如对方不在同一区内,还要拨对方区号,相当于给出网络地址)。对方假如在场并空闲(相当于通信的另一主机开机且可以接受连接请求),拿起电话话筒,双方就可以正式通话,相当于连接成功。双方通话的过程,是一方向电话机发出信号和对方从电话机接收信号的过程,相当于向socket发送数据和从socket接收数据。通话结束后,一方挂起电话机相当于关闭socket,撤消连接。

详细内容见 百科


通常短连接是这样:连接->传输数据->关闭连接
那什么是长连接?一般长连接相对短连接而言的,长连接在传输完数后不关闭连接,而不断的发送包保持连接等待处理下一个数据包。
such as: 连接->传输数据->保持连接 -> 传输数据-> 。。。 ->关闭连接。

那什么时候用短连接呢?
一般长连接用于少数client-end   to server-end的频繁的通信,例如:数据库的连接用长连接, 如果用短连接频繁的通信会造成socket错误,而且频繁的socket 创建也是对资源的浪费。
而像WEB网站的http服务一般都用短链接,因为长连接对于服务端来说会耗费一定的资源,而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源。( 查看来源)


TCP/IP通信解读长短链接

一。通信方式
主要有以下三大类:
(一)SERVER/CLIENT方式
1.一个Client方连接一个Server方,或称点对点(peer to peer):
2.多个Client方连接一个Server方,这也是通常的并发服务器方式。
3.一个Client方连接多个Server方,这种方式很少见,主要
用于一个客户向多个服务器发送请求情况。

(二)连接方式
1.长连接
Client方与Server方先建立通讯连接,连接建立后不断开,
然后再进行报文发送和接收。这种方式下由于通讯连接一直
存在,可以用下面命令查看连接是否建立:
netstat –f inet|grep 端口号(如5678)。
此种方式常用于点对点通讯。

2.短连接
Client方与Server每进行一次报文收发交易时才进行通讯连
接,交易完毕后立即断开连接。此种方式常用于一点对多点
通讯,比如多个Client连接一个Server.

(三)发送接收方式
1.异步
报文发送和接收是分开的,相互独立的,互不影响。这种方
式又分两种情况:
(1)异步双工:接收和发送在同一个程序中,有两个不同的
子进程分别负责发送和接收
(2)异步单工:接收和发送是用两个不同的程序来完成。
2.同步
报文发送和接收是同步进行,既报文发送后等待接收返回报文。
同步方式一般需要考虑超时问题,即报文发上去后不能无限等
待,需要设定超时时间,超过该时间发送方不再等待读返回报
文,直接通知超时返回。

实际通信方式是这三类通信方式的组合。比如一般书上提供的
TCP/IP范例程序大都是同步短连接的SERVER/CLIENT程序。有的
组合是基本不用的,比较常用的有价值的组合是以下几种:

同步短连接Server/Client
同步长连接Server/Client
异步短连接Server/Client
异步长连接双工Server/Client
异步长连接单工Server/Client

其中异步长连接双工是最为复杂的一种通信方式,有时候经
常会出现在不同银行或不同城市之间的两套系统之间的通信。
比如金卡工程。由于这几种通信方式比较固定,所以可以预
先编制这几种通信方式的模板程序。

二.报文格式
通信报文格式多样性更多,相应地就必须设计对应的读写报文的接
收和发送报文函数。

(一)阻塞与非阻塞方式 
1.非阻塞方式
读函数不停地进行读动作,如果没有报文接收到,等待一段时间后
超时返回,这种情况一般需要指定超时时间。
2.阻塞方式
如果没有报文接收到,则读函数一直处于等待状态,直到有报文到达。

(二)循环读写方式
1.一次直接读写报文
在一次接收或发送报文动作中一次性不加分别地全部读取或全部
发送报文字节。
2.不指定长度循环读写
这一般发生在短连接进程中,受网络路由等限制,一次较长的报
文可能在网络传输过程中被分解成了好几个包。一次读取可能不
能全部读完一次报文,这就需要循环读报文,直到读完为止。

3.带长度报文头循环读写
这种情况一般是在长连接进程中,由于在长连接中没有条件能够
判断循环读写什么时候结束,所以必须要加长度报文头。读函数
先是读取报文头的长度,再根据这个长度去读报文.实际情况中,
报头的码制格式还经常不一样,如果是非ASCII码的报文头,还必须
转换成ASCII,常见的报文头码制有:
(1)n个字节的ASCII码
(2)n个字节的BCD码
(3)n个字节的网络整型码
 
TCP客户端向TCP服务端端发送连接请求,TCP接受请求后,SOCKET连接建立。客户端向服务端发送SQL命令,服务端接收并执行,将得到的结果返回请求的客户端,然后断开SOCKET。基本上就是这样一个逻辑了
数据库的长连接是基于socket的长连接之上的,socket好像有个keepalive参数可以控制连接时间,数据库的长连接会一直连下去吗?
一句话,是一样的。 都是保证不主动关闭连接的情况下不会释放连接

 

 

 

 

 

HTTP协议详细介绍

分类: 网络知识   185人阅读  评论(0)  收藏  举报

 

定义

  HTTP超文本传输协议Hypertext Transfer Protocol

HTTP概述

  HTTP的发展是万维网协会(World Wide Web Consortium)和Internet工作小组(Internet Engineering Task Force)合作的结果,(他们)最终发布了一系列的RFC,其中最著名的就是RFC 2616RFC 2616定义了HTTP协议的我们今天普遍使用的一个版本——HTTP 1.1

  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是什么?

  当我们想浏览一个网站的时候,只要在浏览器的地址栏里输入网站的地址就可以了,例如www.baidu.com,但是在浏览器的地址栏里面出现的却是:http://www.baidu.com ,你知道为什么会多出一个“http”吗?

  我们在浏览器的地址栏里输入的网站地址叫做URL (Uniform Resource Locator,统一资源定位符)。就像每家每户都有一个门牌地址一样,每个网页也都有一个Internet地址。当你在浏览器的地址框中输入一个URL或是单击一个超级链接时,URL就确定了要浏览的地址。浏览器通过超文本传输协议(HTTP),将Web服务器上站点的网页代码提取出来,并翻译成漂亮的网页。因此,在我们认识HTTP之前,有必要先弄清楚URL的组成,例如:http://www.baidu.com/china/index.htm。它的含义如下:

  1. http://:代表超文本传输协议,通知baidu.com服务器显示Web页,通常不用输入;

  2. www:代表一个Web(万维网)服务器;

  3. baidu.com/:这是装有网页的服务器的域名,或站点服务器的名称;

  4. China/:为该服务器上的子目录,就好像我们的文件夹;

  5. Index.htmindex.htm是文件夹中的一个HTML文件(网页)。

  我们知道,Internet的基本协议是TCP/IP协议,然而在TCP/IP模型最上层的是应用层(Application layer),它包含所有高层的协议。高层协议有:文件传输协议FTP、电子邮件传输协议SMTP、域名系统服务DNS、网络新闻传输协议NNTPHTTP协议等。

  HTTP协议(HyperText Transfer Protocol,超文本传输协议)是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效,使网络传输减少。它不仅保证计算机正确快速地传输超文本文档,还确定传输文档中的哪一部分,以及哪部分内容首先显示(如文本先于图形)等。这就是你为什么在浏览器中看到的网页地址都是以http://开头的原因。

  自WWW诞生以来,一个多姿多彩的资讯和虚拟的世界便出现在我们眼前,可是我们怎么能够更加容易地找到我们需要的资讯呢?当决定使用超文本作为WWW文档的标准格式后,于是在1990年,科学家们立即制定了能够快速查找这些超文本文档的协议,即HTTP协议。经过几年的使用与发展,得到不断的完善和扩展,目前在WWW中使用的是HTTP/1.0的第六版。

 

HTTP是怎样工作的

  既然我们明白了URL的构成,那么HTTP是怎么工作呢?我们接下来就要讨论这个问题。

  一次HTTP操作称为一个事务,其工作过程可分为四步:

  首先客户机与服务器需要建立连接。只要单击某个超级链接,HTTP的工作就开始了。

  建立连接后,客户机发送一个请求给服务器,请求方式的格式为:统一资源标识符(URL)、协议版本号,后边是MIME信息包括请求修饰符、客户机信息和可能的内容。

  服务器接到请求后,给予相应的响应信息,其格式为一个状态行,包括信息的协议版本号、一个成功或错误的代码,后边是MIME信息包括服务器信息、实体信息和可能的内容。

  客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上,然后客户机与服务器断开连接。

  如果在以上过程中的某一步出现错误,那么产生错误的信息将返回到客户端,有显示屏输出。对于用户来说,这些过程是由HTTP自己完成的,用户只要用鼠标点击,等待信息显示就可以了。

  许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。最简单的情况可能是在用户代理和服务器之间通过一个单独的连接来完成。在Internet上,HTTP通讯通常发生在TCP/IP连接之上。缺省端口是TCP 80,但其它的端口也是可用的。但这并不预示着HTTP协议在Internet或其它网络的其它协议之上才能完成。HTTP只预示着一个可靠的传输。

  这个过程就好像我们打电话订货一样,我们可以打电话给商家,告诉他我们需要什么规格的商品,然后商家再告诉我们什么商品有货,什么商品缺货。这些,我们是通过电话线用电话联系(HTTP是通过TCP/IP),当然我们也可以通过传真,只要商家那边也有传真。

  以上简要介绍了HTTP协议的宏观运作方式,下面介绍一下HTTP协议的内部操作过程。

  在WWW中,客户服务器是一个相对的概念,只存在于一个特定的连接期间,即在某个连接中的客户在另一个连接中可能作为服务器。基于HTTP协议的客户/服务器模式的信息交换过程,它分四个过程:建立连接、发送请求信息、发送响应信息、关闭连接。这就好像上面的例子,我们电话订货的全过程。

  其实简单说就是任何服务器除了包括HTML文件以外,还有一个HTTP驻留程序,用于响应用户请求。你的浏览器是HTTP客户,向服务器发送请求,当浏览器中输入了一个开始文件或点击了一个超级链接时,浏览器就向服务器发送了HTTP请求,此请求被送往由IP地址指定的URL。驻留程序接收到请求,在进行必要的操作后回送所要求的文件。在这一过程中,在网络上发送和接收的数据已经被分成一个或多个数据包(packet),每个数据包包括:要传送的数据;控制信息,即告诉网络怎样处理数据包。TCP/IP决定了每个数据包的格式。如果事先不告诉你,你可能不会知道信息被分成用于传输和再重新组合起来的许多小块。

  也就是说商家除了拥有商品之外,它也有一个职员在接听你的电话,当你打电话的时候,你的声音转换成各种复杂的数据,通过电话线传输到对方的电话机,对方的电话机又把各种复杂的数据转换成声音,使得对方商家的职员能够明白你的请求。这个过程你不需要明白声音是怎么转换成复杂的数据的。

 

HTTP的含义及其作用

  HTTP是超文本传输协议,是客户端浏览器或其他程序与Web服务器之间的应用层通信协议。在Internet上的Web服务器上存放的都是超文本信息,客户机需要通过HTTP协议传输所要访问的超文本信息。HTTP包含命令和传输信息,不仅可用于Web访问,也可以用于其他因特网/内联网应用系统之间的通信,从而实现各类应用资源超媒体访问的集成。

 

http协议基础

  HTTPHyperText Transfer Protocol)是超文本传输协议的缩写,它用于传送WWW方式的数据,关于HTTP协议的详细内容请参考RFC2616HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求,请求头包含请求的方法、URL、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应,相应的内容包括消息协议的版本,成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。

  通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行,一个或者多个头域,一个指示头域结束的空行和可选的消息体组成。HTTP的头域包括通用头,请求头,响应头和实体头四个部分。每个头域由一个域名,冒号(:)和域值三部分组成。域名是大小写无关的,域值前可以添加任何数量的空格符,头域可以被扩展为多行,在每行开始处,使用至少一个空格或制表符。

  通用头域

  通用头域包含请求和响应消息都支持的头域,通用头域包含Cache-ControlConnectionDatePragmaTransfer-EncodingUpgradeVia。对通用头域的扩展要求通讯双方都支持此扩展,如果存在不支持的通用头域,一般将会作为实体头域处理。下面简单介绍几个在UPnP消息中使用的通用头域。

  Cache-Control头域

  Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cacheno-storemax-agemax-stalemin-freshonly-if-cached,响应消息中的指令包括publicprivateno-cacheno-storeno-transformmust-revalidateproxy-revalidatemax-age。各个消息中的指令含义如下:

  Public指示响应可被任何缓存区缓存。

  Private指示对于单个用户的整个或部分响应消息,不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息,此响应消息对于其他用户的请求无效。

  no-cache指示请求或响应消息不能缓存

  no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。

  max-age指示客户机可以接收生存期不大于指定时间(以秒为单位)的响应。

  min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。

  max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值,那么客户机可以接收超出超时期指定值之内的响应消息。

  Date头域

  Date头域表示消息发送的时间,时间的描述格式由rfc822定义。例如,Date:Mon,31Dec200104:25:57GMTDate描述的时间表示世界标准时,换算成本地时间,需要知道用户所在的时区。

  Pragma头域

  Pragma头域用来包含实现特定的指令,最常用的是Pragma:no-cache。在HTTP/1.1协议中,它的含义和Cache-Control:no-cache相同。

  请求消息

  请求消息的第一行为下面的格式:

MethodSPRequest-URISPHTTP-VersionCRLF

Method表示对于Request-URI完成的方法,这个字段是大小写敏感的,包括OPTIONSGETHEADPOSTPUTDELETETRACE。方法GETHEAD应该被所有的通用WEB服务器支持,其他所有方法的实现是可选的。GET方法取回由Request-URI标识的信息。HEAD方法也是取回由Request-URI标识的信息,只是可以在响应时,不返回消息体。POST方法可以请求服务器接收包含在请求中的实体信息,可以用于提交表单,向新闻组、BBS、邮件群组和数据库发送消息。

  SP表示空格。Request-URI遵循URI格式,在此字段为星号(*)时,说明请求并不用于某个特定的资源地址,而是用于服务器本身。HTTP-Version表示支持的HTTP版本,例如为HTTP/1.1CRLF表示换行回车符。请求头域允许客户端向服务器传递关于请求或者关于客户机的附加信息。请求头域可能包含下列字段AcceptAccept-CharsetAccept-EncodingAccept-LanguageAuthorizationFromHostIf-Modified-SinceIf-MatchIf-None-MatchIf-RangeIf-RangeIf-Unmodified-SinceMax-ForwardsProxy-AuthorizationRangeRefererUser-Agent。对请求头域的扩展要求通讯双方都支持,如果存在不支持的请求头域,一般将会作为实体头域处理。

  典型的请求消息:

  GET http://download.microtool.de:80/somedata.exe

  Host: download.microtool.de

  Accept: */*

  Pragma: no-cache

  Cache-Control: no-cache

  Referer: http://download.microtool.de/

  User-Agent: Mozilla/4.04[en](Win95;I;Nav)

  Range: bytes=554554-

  上例第一行表示HTTP客户端(可能是浏览器、下载程序)通过GET方法获得指定URL下的文件。

  Host头域

  Host头域指定请求资源的Intenet主机和端口号,必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域,否则系统会以400状态码返回。

  Referer头域

  Referer头域允许客户端指定请求uri的源资源地址,这可以允许服务器生成回退链表,可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被追踪。如果请求的uri没有自己的uri地址,Referer不能被发送。如果指定的是部分uri地址,则此地址应该是一个相对地址。

  Range头域

  Range头域可以请求实体的一个或者多个子范围。例如,

  表示头500个字节:bytes=0-499

  表示第二个500字节:bytes=500-999

  表示最后500个字节:bytes=-500

  表示500字节以后的范围:bytes=500-

  第一个和最后一个字节:bytes=0-0,-1

  同时指定几个范围:bytes=500-600,601-999

  但是服务器可以忽略此请求头,如果无条件GET包含Range请求头,响应会以状态码206PartialContent)返回而不是以200OK)。

  User-Agent头域

  User-Agent头域的内容包含发出请求的用户信息。

  响应消息

  响应消息的第一行为下面的格式:

  HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF

  HTTP-Version表示支持的HTTP版本,例如为HTTP/1.1Status-Code是一个三个数字的结果代码。Reason-PhraseStatus-Code提供一个简单的文本描述。Status-Code主要用于机器自动识别,Reason-Phrase主要用于帮助用户理解。Status-Code的第一个数字定义响应的类别,后两个数字没有分类的作用。第一个数字可能取5个不同的值:

  1xx:信息响应类,表示接收到请求并且继续处理

  2xx:处理成功响应类,表示动作被成功接收、理解和接受

  3xx:重定向响应类,为了完成指定的动作,必须接受进一步处理

  4xx:客户端错误,客户请求包含语法错误或者是不能正确执行

  5xx:服务端错误,服务器不能正确执行一个正确的请求

  响应头域允许服务器传递不能放在状态行的附加信息,这些域主要描述服务器的信息和Request-URI进一步的信息。响应头域包含AgeLocationProxy-AuthenticatePublicRetry-AfterServerVaryWarningWWW-Authenticate。对响应头域的扩展要求通讯双方都支持,如果存在不支持的响应头域,一般将会作为实体头域处理。

  典型的响应消息:

  HTTP/1.0200OK

  Date:Mon,31Dec200104:25:57GMT

  Server:Apache/1.3.14(Unix)

  Content-type:text/html

  Last-modified:Tue,17Apr200106:46:28GMT

  Etag:"a030f020ac7c01:1e9f"

  Content-length:39725426

  Content-range:bytes554554-40279979/40279980

  上例第一行表示HTTP服务端响应一个GET方法。

  Location响应头

  Location响应头用于重定向接收者到一个新URI地址。

  Server响应头

  Server响应头包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释,产品标识一般按照重要性排序。

  HTTP-运作方式

  HTTP协议是基于请求/响应范式的。一个客户机与服务器建立连接后,发送一个请求给服务器,请求方式的格式为,统一资源标识符、协议版本号,后边是MIME信息包括请求修饰符、客户机信息和可能的内容。服务器接到请求后,给予相应的响应信息,其格式为一个状态行包括信息的协议版本号、一个成功或错误的代码,后边是MIME信息包括服务器信息、实体信息和可能的内容。

  许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。最简单的情况可能是在用户代理(UA)和源服务器(O)之间通过一个单独的连接来完成。

  当一个或多个中介出现在请求/响应链中时,情况就变得复杂一些。中介由三种:代理(Proxy)网关(Gateway)和通道(Tunnel)。一个代理根据URI的绝对格式来接受请求,重写全部或部分消息,通过URI的标识把已格式化过的请求发送到服务器。网关是一个接收代理,作为一些其它服务器的上层,并且如果必须的话,可以把请求翻译给下层的服务器协议。一个通道作为不改变消息的两个连接之间的中继点。当通讯需要通过一个中介(例如:防火墙等)或者是中介不能识别消息的内容时,通道经常被使用.

  实体

  请求消息和响应消息都可以包含实体信息,实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息,实体头包括AllowContent-BaseContent-EncodingContent-LanguageContent-LengthContent-LocationContent-MD5Content-RangeContent-TypeEtagExpiresLast-Modifiedextension-headerextension-header允许客户端定义新的实体头,但是这些域可能无法接受方识别。实体可以是一个经过编码的字节流,它的编码方式由Content-EncodingContent-Type定义,它的长度由Content-LengthContent-Range定义。

  Content-Type实体头

  Content-Type实体头用于向接收方指示实体的介质类型,指定HEAD方法送到接收方的实体介质类型,或GET方法发送的请求介质类型Content-Range实体头

  Content-Range实体头用于指定整个实体中的一部分的插入位置,他也指示了整个实体的长度。在服务器向客户返回一个部分响应,它必须描述响应覆盖的范围和整个实体长度。一般格式:

  Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth

  例如,传送头500个字节次字段的形式:Content-Range:bytes0-499/1234如果一个http消息包含此节(例如,对范围请求的响应或对一系列范围的重叠请求),Content-Range表示传送的范围,Content-Length表示实际传送的字节数。

  Last-modified实体头

  Last-modified实体头指定服务器上保存内容的最后修订时间。

  例如,传送头500个字节次字段的形式:Content-Range:bytes0-499/1234如果一个http消息包含此节(例如,对范围请求的响应或对一系列范围的重叠请求),Content-Range表示传送的范围,Content-Length表示实际传送的字节数。

  Last-modified实体头

 

http协议结构

  HTTP报文由从客户机到服务器的请求和从服务器到客户机的响应构成。请求报文格式如下:

  请求行 - 通用信息头 - 请求头 - 实体头 - 报文主体

  请求行以方法字段开始,后面分别是 URL 字段和 HTTP 协议版本字段,并以 CRLF 结尾。SP 是分隔符。除了在最后的 CRLF 序列中 CR  LF 是必需的之外,其他都可以不要。有关通用信息头,请求头和实体头方面的具体内容可以参照相关文件。

  应报文格式如下:

  状态行 - 通用信息头 - 响应头 - 实体头 - 报文主体

状态码元由3位数字组成,表示请求是否被理解或被满足。原因分析是对原文的状态码作简短的描述,状态码用来支持自动操作,而原因分析用来供用户使用。客户机无需用来检查或显示语法。有关通用信息头,响应头和实体头方面的具体内容可以参照相关文件。

 

HTTP错误代码详细介绍

  "100" : Continue

  "101" : witching Protocols

  "200" : OK

  "201" : Created

  "202" : Accepted

  "203" : Non-Authoritative Information

  "204" : No Content

  "205" : Reset Content

  "206" : Partial Content

  "300" : Multiple Choices

  "301" : Moved Permanently

  "302" : Found

  "303" : See Other

  "304" : Not Modified

  "305" : Use Proxy

  "307" : Temporary Redirect

  HTTP 400 - 请求无效

  HTTP 401.1 - 未授权:登录失败

  HTTP 401.2 - 未授权:服务器配置问题导致登录失败

  HTTP 401.3 - ACL 禁止访问资源

  HTTP 401.4 - 未授权:授权被筛选器拒绝

  HTTP 401.5 - 未授权:ISAPI  CGI 授权失败

  HTTP 403 - 禁止访问

  HTTP 403 -  Internet 服务管理器 (HTML) 的访问仅限于 Localhost

  HTTP 403.1 禁止访问:禁止可执行访问

  HTTP 403.2 - 禁止访问:禁止读访问

  HTTP 403.3 - 禁止访问:禁止写访问

  HTTP 403.4 - 禁止访问:要求 SSL

  HTTP 403.5 - 禁止访问:要求 SSL 128

  HTTP 403.6 - 禁止访问:IP 地址被拒绝

  HTTP 403.7 - 禁止访问:要求客户证书

  HTTP 403.8 - 禁止访问:禁止站点访问

  HTTP 403.9 - 禁止访问:连接的用户过多

  HTTP 403.10 - 禁止访问:配置无效

  HTTP 403.11 - 禁止访问:密码更改

  HTTP 403.12 - 禁止访问:映射器拒绝访问

  HTTP 403.13 - 禁止访问:客户证书已被吊销

  HTTP 403.15 - 禁止访问:客户访问许可过多

  HTTP 403.16 - 禁止访问:客户证书不可信或者无效

  HTTP 403.17 - 禁止访问:客户证书已经到期或者尚未生效

  HTTP 404.1 - 无法找到 Web 站点

  HTTP 404 - 无法找到文件

  HTTP 405 - 资源被禁止

  HTTP 406 - 无法接受

  HTTP 407 - 要求代理身份验证

  HTTP 410 - 永远不可用

  HTTP 412 - 先决条件失败

  HTTP 414 - 请求 - URI 太长

  HTTP 500 - 内部服务器错误

  HTTP 500.100 - 内部服务器错误 - ASP 错误

  HTTP 500-11 服务器关闭

  HTTP 500-12 应用程序重新启动

  HTTP 500-13 - 服务器太忙

  HTTP 500-14 - 应用程序无效

  HTTP 500-15 - 不允许请求 global.asa

  Error 501 - 未实现

HTTP 502 - 网关错误

 

协议版本号

  超文本传输协议已经演化出了很多版本,它们中的大部分都是向下兼容的。在RFC 2145中描述了HTTP版本号的用法。客户端在请求的开始告诉服务器它采用的协议版本号,而后者则在响应中采用相同或者更早的协议版本。

  0.9

  已过时。只接受 GET 一种请求方法,没有在通讯中指定版本号,且不支持请求头。由于该版本不支持POST 方法,所以客户端无法向服务器传递太多信息。

  HTTP/1.0

  这是第一个在通讯中指定版本号的 HTTP 协议版本,至今仍被广泛采用,特别是在代理服务器中。

  HTTP/1.1

  当前版本。持久连接被默认采用,并能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求,以便降低线路负载,提高传输速度。

  HTTP/1.1相较于 HTTP/1.0 协议的区别主要体现在:

  缓存处理

  带宽优化及网络连接的使用

  错误通知的管理

  消息在网络中的发送

  互联网地址的维护

  安全性及完整性

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值