想过成功,也想过失败。但从未想过放弃……

发布新日志

  • 主要协议表

    2009-12-11 12:31:14

    主要协议表
    应用层(Application Layer) 

    --------------------------------------------------------------------------------

    BOOTP:引导协议 (BOOTP:Bootstrap Protocol)
    DCAP:数据转接客户访问协议 (DCAP:Data Link Switching Client Access Protocol)
    DHCP:动态主机配置协议 (DHCP:Dynamic Host Configuration Protocol)
    DNS:域名系统(服务)系统 (DNS:Domain Name Systems)
    Finger:用户信息协议 (Finger:User Information Protocol)
    FTP:文件传输协议 (FTP:File Transfer Protocol)
    HTTP:超文本传输协议 (HTTP:Hypertext Transfer Protocol)
    S-HTTP:安全超文本传输协议 (S-HTTP:Secure Hypertext Transfer Protocol)
    IMAP & IMAP4:信息访问协议 & 信息访问协议第4版 (IMAP & IMAP4:Internet Message Access Protocol)
    IPDC:IP 设备控制 (IPDC:IP Device Control)
    IRCP/IRC:因特网在线聊天协议 (IRCP/IRC:Internet Relay Chat Protocol)
    LDAP:轻量级目录访问协议 (LDAP:Lightweighted Directory Access Protocol)
    MIME/S-MIME/Secure MIME:多用途网际邮件扩充协议 (MIME/S-MIME/Secure MIME:Multipurpose Internet Mail Extensions)
    NAT:网络地址转换 (NAT:Network Address Translation)
    NNTP:网络新闻传输协议 (NNTP:Network News Transfer Protocol)
    NTP:网络时间协议 (NTP:Network Time Protocol) 
    POP&POP3:邮局协议 (POP & POP3:Post Office Protocol)
    RLOGIN:远程登录命令 (RLOGIN:Remote Login in Unix)
    RMON:远程监控 (RMON:Remote Monitoring MIBs in SNMP)
    RWhois:远程目录访问协议 (RWhois Protocol)
    SLP:服务定位协议 (SLP:Service Location Protocol)
    SMTP:简单邮件传输协议 (SMTP:Simple Mail Transfer Protocol)
    SNMP:简单网络管理协议 (SNMP:Simple Network Management Protocol)
    SNTP:简单网络时间协议 (SNTP:Simple Network Time Protocol)
    TELNET:TCP/IP 终端仿真协议 (TELNET:TCP/IP Terminal Emulation Protocol)
    TFTP:简单文件传输协议 (TFTP:Trivial File Transfer Protocol)
    URL:统一资源管理 (URL:Uniform. Resource Locator)
    X-Window/X Protocol:X 视窗 或 X 协议(X-Window:X Window or X Protocol or X System)


    表示层(Presentation Layer)

    --------------------------------------------------------------------------------

    LPP:轻量级表示协议 (LPP:Lightweight Presentation Protocol)


    会话层(Session Layer)

    --------------------------------------------------------------------------------

    RPC:远程过程调用协议 (RPC:Remote Procedure Call protocol)


    传输层(Transport Layer)

    --------------------------------------------------------------------------------

    ITOT:基于TCP/IP 的 ISO 传输协议 (ITOT:ISO Transport Over TCP/IP)
    RDP:可靠数据协议 (RDP:Reliable Data Protocol)
    RUDP:可靠用户数据报协议 (RUDP:Reliable UDP)
    TALI:传输适配层接口 (TALI:Transport Adapter Layer Interface)
    TCP:传输控制协议 (TCP:Transmission Control Protocol)
    UDP:用户数据报协议 (UDP:User Datagram Protocol)
    Van Jacobson:压缩 TCP 协议 (Van Jacobson:Compressed TCP)


    网络层(Network Layer)

    --------------------------------------------------------------------------------

      路由选择(Routing)
    BGP/BGP4:边界网关协议 (BGP/BGP4:Border Gateway Protocol)
    EGP:外部网关协议(EGP:Exterior Gateway Protocol)
    IP:网际协议 (IP:Internet Protocol)
    IPv6:网际协议第6版 (IPv6:Internet Protocol version 6)
    ICMP/ICMPv6:Internet 信息控制协议 (ICMP/ICMPv6:Internet Control Message Protocol)
    IRDP:ICMP 路由器发现协议 (IRDP:ICMP Router Discovery Protocol)
    Mobile IP: 移动 IP (Mobile IP:IP Mobility Support Protocol for IPv4 & IPv6)
    NARP:NBMA 地址解析协议 (NARP:NBMA Address Resolution Protocol)
    NHRP:下一跳解析协议 (NHRP:Next Hop Resolution Protocol)
    OSPF:开放最短路径优先 (OSPF:Open Shortest Path First)
    RIP/RIP2:路由选择信息协议 (RIP/RIP2:Routing Information Protocol)
    RIPng:路由选择信息协议下一代 (RIPng:RIP for IPv6)
    RSVP:资源预留协议 (RSVP:Resource ReSerVation Protocol)
    VRRP:虚拟路由器冗余协议 (VRRP:Virtual Router Redundancy Protocol)

      组播(Multicast)
    BGMP:边界网关组播协议 (BGMP:Border Gateway Multicast Protocol)
    DVMRP:距离矢量组播路由协议 (DVMRP:Distance Vector Multicast Routing Protocol)
    IGMP:Internet 组管理协议 (IGMP:Internet Group Management Protocol)
    MARS:组播地址解析服务 (MARS:Multicast Address Resolution Server)
    MBGP:组播协议边界网关协议 (MBGP:Multiprotocol BGP)
    MOSPF:组播OSPF (MOSPF:Multicast OSPF)
    MSDP:组播源发现协议 (MSDP:Multicast Source Discovery Protocol)
    MZAP:组播区域范围公告协议 (MZAP:Multicast Scope Zone Announcement Protocol)
    PGM:实际通用组播协议 (PGM:Pragmatic General Multicast Protocol)
    PIM-DM:密集模式独立组播协议 (PIM-DM:Protocol Independent Multicast - Dense Mode)
    PIM-SM:稀疏模式独立组播协议 (PIM-SM:Protocol Independent Multicast - Sparse Mode)

      MPLS 协议(MPLS Protocols)
    CR-LDP:基于路由受限标签分发协议 (CR-LDP: Constraint-Based Label Distribution Protocol)
    GMPLS:通用多协议标志交换协议 (GMPLS:Generalized Multiprotocol Label Switching)
    LDP:标签分发协议 (LDP:Label Distribution Protocol)
    MPLS:多协议标签交换 (MPLS:Multi-Protocol Label Switching)
    RSVP-TE:基于流量工程扩展的资源预留协议 (RSVP-TE:Resource ReSerVation Protocol-Traffic Engineering)


    数据链路层(Data Link Layer)

    --------------------------------------------------------------------------------

    ARP and InARP:地址转换协议和逆向地址转换协议 (ARP and InARP:Address Resolution Protocol and Inverse ARP)
    IPCP and IPv6CP:IP控制协议和IPV6控制协议 (IPCP and IPv6CP:IP Control Protocol and IPv6 Control Protocol)
    RARP:反向地址转换协议 (RARP:Reverse Address Resolution Protocol)
    SLIP:串形线路 IP (SLIP:Serial Line IP)
  • bit、byte、位、字节、汉字的关系

    2009-09-17 12:52:57

    bit、byte、位、字节、汉字的关系


            1 bit     = 1  二进制数据
            1 byte  = 8  bit
            1 字母 = 1  byte = 8 bit
            1 汉字 = 2  byte = 16 bit


    1. bit:位
        一个二进制数据0或1,是1bit;

    2. byte:字节
        存储空间的基本计量单位,如:MySQL中定义 VARCHAR(45)  即是指 45个字节;
        1 byte = 8 bit

    3. 一个英文字符占一个字节;
        1 字母 = 1 byte = 8 bit

    4. 一个汉字占2个字节;
        1 汉字 = 2 byte = 16 bit

    5. 标点符号
        A>.  汉字输入状态下,默认为全角输入方式;
        B>.  英文输入状态下,默认为半角输入方式;

        C>.  全角输入方式下,标点符号占2字节;
        D>.  半角输入方式下,标点符号占1字节;

        故:汉字输入状态下的字符,占2个字节 (但不排除,自己更改了默认设置);
                英文输入状态下的字符,占1个字节 (但不排除,自己更改了默认设置);



    --------------------------------
    补充:
        计算机对各国语言的支持度,可分为以下三个阶段,如图:
  • Web缓存加速指南

    2009-07-28 18:13:13

    这是一篇知识性的文档,主要目的是为了让Web缓存相关概念更容易被开发者理解并应用于实际的应用环境中。为了简要起见,某些实现方面的细节被简化或省略了。如果你更关心细节实现则完全不必耐心看完本文,后面参考文档和更多深入阅读部分可能是你更需要的内容。

    1. 什么是Web缓存,为什么要使用它?
    2. 缓存的类型:
      1. 浏览器缓存;
      2. 代理服务器缓存;
    3. Web缓存无害吗?为什么要鼓励缓存?
    4. Web缓存如何工作:
    5. 如何控制(控制不)缓存:
      1. HTML Meta标签 vs. HTTP头信息;
      2. Pragma HTTP头信息(为什么不起作用);
      3. 使用Expires(过期时间)HTTP头信息控制保鲜期;
      4. Cache-Control(缓存控制) HTTP头信息;
      5. 校验参数和校验;
    6. 创建利于缓存网站的窍门;
    7. 编写利于缓存的脚本;
    8. 常见问题解答;
    9. 缓存机制的实现:Web服务器端配置;
    10. 缓存机制的实现:服务器端脚本;
    11. 参考文档和深入阅读;
    12. 关于本文档;

    什么是Web缓存,为什么要使用它?

    Web缓存位于Web服务器之间(1个或多个,内容源服务器)和客户端之间(1个或多个):缓存会根据进来的请求保存输出内容的副本,例如html页面, 图片,文件(统称为副本),然后,当下一个请求来到的时候:如果是相同的URL,缓存直接使用副本响应访问请求,而不是向源服务器再次发送请求。

    使用缓存主要有2大理由:
    • 减少相应延迟:因为请求从缓存服务器(离客户端更近)而不是源服务器被相应,这个过程耗时更少,让web服务器看上去相应更快;
    • 减少网络带宽消耗:当副本被重用时会减低客户端的带宽消耗;客户可以节省带宽费用,控制带宽的需求的增长并更易于管理。

    缓存的类型

    浏览器缓存

    对于新一代的Web浏览器来说(例如:IE,Firefox):一般都能在设置对话框中发现关于缓存的设置,通过在你的电脑上僻处一块硬盘空间用于存储你已经看过的网站的副本。浏览器缓存根据非常简单的规则进行工作:在同一个会话过程中(在当前浏览器没有被关闭之前)会检查一次并确定缓存的副本足够新。这个缓存对于用户点击“后退”或者点击刚访问过的链接特别有用,如果你浏览过程中访问到同一个图片,这些图片可以从浏览器缓存中调出而即时显现。

    代理服务器缓存

    Web代理服务器使用同样的缓存原理,只是规模更大。代理服务器群为成百上千用户服务使用同样的机制;大公司和ISP经常在他们的防火墙上架设代理缓存或者单独的缓存设备;

    由于带路服务器缓存并非客户端或者源服务器的一部分,而是位于原网络之外,请求必须路由到他们才能起作用。一个方法是手工设置你的浏览器:告诉浏览器使用 那个代理,另外一个是通过中间服务器:这个中间服务器处理所有的web请求,并将请求转发到后台网络,而用户不必配置代理,甚至不必知道代理的存在;

    代理服务器缓存:是一个共享缓存,不只为一个用户服务,经常为大量用户使用,因此在减少相应时间和带宽使用方面很有效:因为同一个副本会被重用多次。

    网关缓存

    也被称为反向代理缓存或间接代理缓存,网关缓存也是一个中间服务器,和内网管理员部署缓存用于节省带宽不同:网关缓存一般是网站管理员自己部署:让他们的网站更容易扩展并获得更好的性能;
    请求有几种方法被路由到网关缓存服务器上:其中典型的是让用一台或多台负载均衡服务器从客户端看上去是源服务器;

    网络内容发布商  (Content delivery networks CDNs)分布网关缓存到整个(或部分)互联网上,并出售缓存服务给需要的网站,SpeederaAkamai就是典型的网络内容发布商(下文简称CDN)。

    本问主要关注于浏览器和代理缓存,当然,有些信息对于网关缓存也同样有效;

    Web缓存无害吗?为什么要鼓励缓存?

    Web缓存在互联网上最容易被误解的技术之一:网站管理员经常怕对网站失去控制,由于代理缓存会“隐藏”他们的用户,让他们感觉难以监控谁在使用他们的网站。
    不幸的是:就算不考虑Web缓存,互联网上也有很多网站使用非常多的参数以便管理员精确地跟踪用户如何使用他们的网站;如果这类问题也是你关心的,本文将告诉你如何获得精确的统计而不必将网站设计的非常缓存不友好。
    另外一个抱怨是缓存会给用户过期或失效的数据;无论如何:本文可以告诉你怎样配置你的服务器来控制你的内容将被如何缓存。

    CDN是另外一个有趣的方向,和其他代理缓存不同:CDN的网关缓存为希望被缓存的网站服务,没有以上顾虑。即使你使用了CDN,你也要考虑后续的代理服务器缓存和浏览器缓存问题。

    另外一方面:如果良好地规划了你的网站,缓存会有助于网站服务更快,并节省服务器负载和互联网的链接请求。这个改善是显著的:一个难以缓存的网站可能需要几秒去载入页面,而对比有缓存的网站页面几乎是即时显现:用户更喜欢速度快的网站并更经常的访问;

    这样想:很多大型互联网公司为全世界服务器群投入上百万资金,为的就是让用户访问尽可能快,客户端缓存也是这个目的,只不过更靠近用户一端,而且最好的一点是你甚至根本不用为此付费。

    事实上,无论你是否喜欢,代理服务器和浏览器都回启用缓存。如果你没有配置网站正确的缓存,他们会按照缺省或者缓存管理员的策略进行缓存。

    缓存如何工作

    所有的缓存都用一套规则来帮助他们决定什么时候使用缓存中的副本提供服务(假设有副本可用的情况下);一些规则在协议中有定义(HTTP协议1.0和1.1),一些规则由缓存的管理员设置(浏览器的用户或者代理服务器的管理员);
    一般说来:遵循以下基本的规则(不必担心,你不必知道所有的细节,细节将随后说明)

    1. 如果响应头信息:告诉缓存器不要保留缓存,缓存器就不会缓存相应内容;
    2. 如果请求信息是需要认证或者安全加密的,相应内容也不会被缓存;
    3. 如果在回应中不存在校验器(ETag或者Last-Modified头信息),缓存服务器会认为缺乏直接的更新度信息,内容将会被认为不可缓存。
    4. 一个缓存的副本如果含有以下信息:内容将会被认为是足够新的
      • 含有完整的过期时间和寿命控制头信息,并且内容仍在保鲜期内;
      • 浏览器已经使用过缓存副本,并且在一个会话中已经检查过内容的新鲜度;
      • 缓存代理服务器近期内已经使用过缓存副本,并且内容的最后更新时间在上次使用期之前;
      • 够新的副本将直接从缓存中送出,而不会向源服务器发送请求;
    5. 如果缓存的副本已经太旧了,缓存服务器将向源服务器发出请求校验请求,用于确定是否可以继续使用当前拷贝继续服务;
    总之:新鲜度校验是确定内容是否可用的最重要途径:

     

    如果副本足够新,从缓存中提取就立刻能用了;
    而经缓存器校验后发现副本的原件没有变化,系统也会避免将副本内容从源服务器整个重新传输一遍。

    如何控制(控制不)缓存

    有很多工具可以帮助设计师和网站管理员调整缓存服务器对待网站的方式,这也许需要你亲自下手对服务器的配置进行一些调整,但绝对值得;了解如何使用这些工具请参考后面的实现章节;

    HTML meta标签和HTTP 头信息

    HTML的编写者会在文档的<HEAD>区域中加入描述文档的各种属性,这些META标签常常被用于标记文档不可以被缓存或者标记多长时间后过期;
    META标签使用很简单:但是效率并不高,因为只有几种浏览器会遵循这个标记(那些真正会“读懂”HTML的浏览器),没有一种缓存代理服务器能遵循这个 规则(因为它们几乎完全不解析文档中HTML内容);有事会在Web页面中增加:Pragma: no-cache这个META标记,如果要让页面保持刷新,这个标签其实完全没有必要。
    如果你的网站托管在ISP机房中,并且机房可能不给你权限去控制HTTP的头信息(如:Expires和Cache-Control),大声控诉:这些机制对于你的工作来说是必须的;
    另外一方面: HTTP头信息可以让你对浏览器和代理服务器如何处理你的副本进行更多的控制。他们在HTML代码中是看不见的,一般由Web服务器自动生成。但是,根据 你使用的服务,你可以在某种程度上进行控制。在下文中:你将看到一些有趣的HTTP头信息,和如何在你的站点上应用部署这些特性。

    HTTP头信息发送在HTML代码之前,只有被浏览器和一些中间缓存能看到,一个典型的HTTP 1.1协议返回的头信息看上去像这样:

    HTTP/1.1 200 OK
    Date: Fri, 30 Oct 1998 13:19:41 GMT
    Server: Apache/1.3.3 (Unix)
    Cache-Control: max-age=3600, must-revalidate
    Expires: Fri, 30 Oct 1998 14:19:41 GMT
    Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
    ETag: "3e86-410-3596fbbc"
    Content-Length: 1040
    Content-Type: text/html


    在头信息空一行后是HTML代码的输出,关于如何设置HTTP头信息请参考实现章节;

    Pragma HTTP头信息 (为什么它不起作用)

    很多人认为在HTTP头信息中设置了Pragma: no-cache后会让内容无法被缓存。但事实并非如此:HTTP的规范中,响应型头信息没有任何关于Pragma属性的说明,而讨论了的是请求型头信息 Pragma属性(头信息也由浏览器发送给服务器),虽然少数集中缓存服务器会遵循这个头信息,但大部分不会。用了Pragma也不起什么作用,要用就使 用下列头信息:

    使用Expires(过期时间)HTTP头信息来控制保鲜期

    Expires(过期时间) 属性是HTTP控制缓存的基本手段,这个属性告诉缓存器:相关副本在多长时间内是新鲜的。过了这个时间,缓存器就会向源服务器发送请求,检查文档是否被修改。几乎所有的缓存服务器都支持Expires(过期时间)属性;

    大部分Web服务器支持你用几种方式设置Expires属性;一般的:可以设计一个绝对时间间隔:基于客户最后查看副本的时间(最后访问时间)或者根据服务器上文档最后被修改的时间;

    Expires头信息:对于设置静态图片文件(例如导航栏和图片按钮)可缓存特别有用;因为这些图片修改很少,你可以给它们设置一个特别长的过期时间,这会使你的网站对用户变得相应非常快;他们对于控制有规律改变的网页也很有用,例如:你每天早上6点更新新闻页,你可以设置副本的过期时间也是这个时间,这样缓存 服务器就知道什么时候去取一个更新版本,而不必让用户去按浏览器的“刷新”按钮。

    过期时间头信息属性值只能是HTTP格式的日期时间,其他的都会被解析成当前时间“之前”,副本会过期,记住:HTTP的日期时间必须是格林威治时间(GMT),而不是本地时间。举例:

    Expires: Fri, 30 Oct 1998 14:19:41 GMT

    所以使用过期时间属性一定要确认你的Web服务器时间设置正确,一个途径是通过网络时间同步协议(Network Time Protocol NTP),和你的系统管理员那里你可以了解更多细节。
    虽然过期时间属性非常有用,但是它还是有些局限,首先:是牵扯到了日期,这样Web服务器的时间和缓存服务器的时间必须是同步的,如果有些不同步,要么是应该缓存的内容提前过期了,要么是过期结果没及时更新。
    还有一个过期时间设置的问题也不容忽视:如果你设置的过期时间是一个固定的时间,如果你返回内容的时候又没有连带更新下次过期的时间,那么之后所有访问请求都会被发送给源Web服务器,反而增加了负载和响应时间;

    Cache-Control(缓存控制) HTTP头信息

    HTTP 1.1介绍了另外一组头信息属性:Cache-Control响应头信息,让网站的发布者可以更全面的控制他们的内容,并定位过期时间的限制。
    有用的 Cache-Control响应头信息包括:

    • max-age=[秒] — 执行缓存被认为是最新的最长时间。类似于过期时间,这个参数是基于请求时间的相对时间间隔,而不是绝对过期时间,[秒]是一个数字,单位是秒:从请求时间开始到过期时间之间的秒数。
    • s-maxage=[秒] — 类似于max-age属性,除了他应用于共享(如:代理服务器)缓存
    • public — 标记认证内容也可以被缓存,一般来说: 经过HTTP认证才能访问的内容,输出是自动不可以缓存的;
    • no-cache — 强制每次请求直接发送给源服务器,而不经过本地缓存版本的校验。这对于需要确认认证应用很有用(可以和public结合使用),或者严格要求使用最新数据的应用(不惜牺牲使用缓存的所有好处);
    • no-store — 强制缓存在任何情况下都不要保留任何副本
    • must-revalidate — 告诉缓存必须遵循所有你给予副本的新鲜度的,HTTP允许缓存在某些特定情况下返回过期数据,指定了这个属性,你高速缓存,你希望严格的遵循你的规则。
    • proxy-revalidate — 和 must-revalidate类似,除了他只对缓存代理服务器起作用

    举例:

    Cache-Control: max-age=3600, must-revalidate

    如果你计划试用Cache-Control属性,你应该看一下这篇HTTP文档,详见参考和深入阅读;

    校验参数和校验

    在Web缓存如何工作: 我们说过:校验是当副本已经修改后,服务器和缓存之间的通讯机制;使用这个机制:缓存服务器可以避免副本实际上仍然足够新的情况下重复下载整个原件。
    校验参数非常重要,如果1个不存在,并且没有任何信息说明保鲜期(Expires或Cache-Control)的情况下,缓存将不会存储任何副本;
    最常见的校验参数是文档的最后修改时间,通过最后Last-Modified头信息可以,当一份缓存包含Last-Modified信息,他基于此信息,通过添加一个If-Modified-Since请求参数,向服务器查询:这个副本从上次查看后是否被修改了。
    HTTP 1.1介绍了另外一个校验参数: ETag,服务器是服务器生成的唯一标识符ETag,每次副本的标签都会变化。由于服务器控制了ETag如何生成,缓存服务器可以通过If-None-Match请求的返回没变则当前副本和原件完全一致。
    所有的缓存服务器都使用Last-Modified时间来确定副本是否够新,而ETag校验正变得越来越流行;
    所有新一代的Web服务器都对静态内容(如:文件)自动生成ETag和Last-Modified头信息,而你不必做任何设置。但是,服务器对于动态内容(例如:CGI,ASP或数据库生成的网站)并不知道如何生成这些信息,参考一下编写利于缓存的脚本章节;

    创建利于缓存网站的窍门

    除了使用新鲜度信息和校验,你还有很多方法使你的网站缓存友好。

    • 保持URL稳定: 这是缓存的金科玉律,如果你给在不同的页面上,给不同用户或者从不同的站点上提供相同的内容,应该使用相同的URL,这是使你的网站缓存友好最简单,也是 最高效的方法。例如:如果你在页面上使用 "/index.html" 做为引用,那么就一直用这个地址;
    • 使用一个共用的库存放每页都引用的图片和其他页面元素;
    • 对于不经常改变的图片/页面启用缓存,并使用Cache-Control: max-age属性设置一个较长的过期时间;
    • 对于定期更新的内容设置一个缓存服务器可识别的max-age属性或过期时间;
    • 如果数据源(特别是下载文件)变更,修改名称,这样:你可以让其很长时间不过期,并且保证服务的是正确的版本;而链接到下载文件的页面是一个需要设置较短过期时间的页面。
    • 万不得已不要改变文件,否则你会提供一个非常新的Last-Modified日期;例如:当你更新了网站,不要复制整个网站的所有文件,只上传你修改的文件。
    • 只在必要的时候使用Cookie,cookie是非常难被缓存的,而且在大多数情况下是不必要的,如果使用cookie,控制在动态网页上;
    • 减少试用SSL,加密的页面不会被任何共享缓存服务器缓存,只在必要的时候使用,并且在SSL页面上减少图片的使用;
    • 使用可缓存性评估引擎,这对于你实践本文的很多概念都很有帮助;

    编写利于缓存的脚本

    脚本缺省不会返回校验参数(返回Last-Modified或ETag头信息)或其他新鲜度信息(Expires或Cache-Control),有些动态脚本的确是动态内容(每次相应内容都不一样),但是更多(搜索引擎,数据库引擎网站)网站还是能从缓存友好中获益的。
    一般说来,如果脚本生成的输出在未来一段时间(几分钟或者几天)都是可重复复制的,那么就是可缓存的。如果脚本输出内容只随URL变化而变化,也是可缓存的;但如果输出会根据cookie,认证信息或者其他外部条件变化,则还是不可缓存的。

    • 最利于缓存的脚本就是将内容改变时导出成静态文件,Web服务器可以将其当作另外一个网页并生成和试用校验参数,让一些都变得更简单,只需要写入文件即可,这样最后修改时间也有了;
    • 另外一个让脚本可缓存的方法是对一段时间内能保持较新的内容设置一个相对寿命的头信息,虽然通过Expires头信息也可以实现,但更容易的是用Cache-Control: max-age属性,它会让首次请求后一段时间内缓存保持新鲜;
    • 如果以上做法你都做不到,你可以让脚本生成一个校验属性,并对 If-Modified-Since 和/或If-None-Match请求作出反应,这些属性可以从解析HTTP头信息得到,并对符合条件的内容返回304 Not Modified(内容未改变),可惜的是,这种做法比不上前2种高效;

    其他窍门:

    • 尽量避免使用POST,除非万不得已,POST模式的返回内容不会被大部分缓存服务器保存,如果你发送内容通过URL和查询(通过GET模式)的内容可以缓存下来供以后使用;
    • 不要在URL中加入针对每个用户的识别信息:除非内容是针对每个用户不同的;
    • 不要统计一个用户来自一个地址的所有请求,因为缓存常常是一起工作的;
    • 生成并返回Content-Length头信息,如果方便的话,这个属性让你的脚本在可持续链接模式时:客户端可以通过一个TCP/IP链接同时请求多个副本,而不是为每次请求单独建立链接,这样你的网站相应会快很多;
    具体定义请参考实现章节。

    常见问题解答

    让网站变得可缓存的要点是什么?

    好的策略是确定那些内容最热门,大量的复制(特别是图片)并针对这些内容先部署缓存。

    如何让页面通过缓存达到最快相应?

    缓存最好的副本是那些可以长时间保持新鲜的内容;基于校验虽然有助于加快相应,但是它不得不和源服务器联系一次去检查内容是否够新,如果缓存服务器上就知道内容是新的,内容就可以直接相应返回了。

    我理解缓存是好的,但是我不得不统计多少人访问了我的网站!

    如果你必须知道每次页面访问的,选择【一】个页面上的小元素,或者页面本身,通过适当的头信息让其不可缓存,例如: 可以在每个页面上部署一个1x1像素的透明图片。Referer头信息会有包含这个图片的每个页面信息;
    明确一点:这个并不会给你一个关于你用户精确度很高的统计,而且这对互联网和你的用户这都不太好,消耗了额外的带宽,强迫用户去访问无法缓存的内容。了解更多信息,参考访问统计资料。

    我如何能看到HTTP头信息的内容?

    很多浏览器在页面属性或类似界面中可以让你看到Expires 和Last-Modified信息;如果有的话:你会找到页面信息的菜单和页面相关的文件(如图片),并且包含他们的详细信息;
    看到完整的头信息,你可以用telnet手工连接到Web服务器;
    为此:你可能需要用一个字段指定端口(缺省是80),或者链接到www.example.com:80 或者 www.example.com 80(注意是空格),更多设置请参考一下telnet客户端的文档;
    打开网站链接:请求一个查看链接,如果你想看到http://www.example.com/foo.html 连接到www.example.com的80端口后,键入:

    GET /foo.html HTTP/1.1 [回车]
    GET /foo.html HTTP/1.1 [return]
    Host: www.example.com [回车][回车] 
    Host: www.example.com [return][return]

    在[回车]处按键盘的回车键;在最后,要按2次回车,然后,就会输出头信息及完整页面,如果只想看头信息,将GET换成HEAD。

    我的页面是密码保护的,代理缓存服务器如何处理他们?

    缺省的,网页被HTTP认证保护的都是私密内容,它们不会被任何共享缓存保留。但是,你可以通过设置Cache-Control: public让认证页面可缓存,HTTP 1.1标准兼容的缓存服务器会认出它们可缓存。
    如果你认为这些可缓存的页面,但是需要每个用户认证后才能看,可以组合使用Cache-Control: public和no-cache头信息,高速缓存必须在提供副本之前,将将新客户的认证信息提交给源服务器。设置就是这样:

    Cache-Control: public, no-cache

    无论如何:这是减少认证请求的最好方法,例如: 你的图片是不机密的,将它们部署在另外一个目录,并对此配置服务器不强制认证。这样,那些图片会缺省都缓存。

    我们是否要担心用户通过cache访问我的站点?

    代理服务器上SSL页面不会被缓存(不推荐被缓存),所以你不必为此担心。但是,由于缓存保存了非SSL请求和从他们抓取的URL,你要意识到没有安全保护的网站,可能被不道德的管理员可能搜集用户隐私,特别是通过URL。
    实际上,位于服务器和客户端之间的管理员可以搜集这类信息。特别是通过CGI脚本在通过URL传递用户名和密码的时候会有很大问题;这对泄露用户名和密码是一个很大的漏洞;
    如果你初步懂得互联网的安全机制,你不会对缓存服务器有任何。

    我在寻找一个包含在Web发布系统解决方案,那些是比较有缓存意识的系统?

    这很难说,一般说来系统越复杂越难缓存。最差就是全动态发布并不提供校验参数;你无发缓存任何内容。可以向系统提供商的技术人员了解一下,并参考后面的实现说明。

    我的图片设置了1个月后过期,但是我现在需要现在更新。

    过期时间是绕不过去的,除非缓存(浏览器或者代理服务器)空间不足才会删除副本,缓存副本在过期之间会被一直使用。
    最好的办法是改变它们的链接,这样,新的副本将会从源服务器上重新下载。记住:引用它们的页面本身也会被缓存。因此,使用静态图片和类似内容是很容易缓存的,而引用他们的HTML页面则要保持非常更新;
    如果你希望对指定的缓存服务器重新载入一个副本,你可以强制使用“刷新”(在FireFox中在reload的时候按住shift键:就会有前面提到恶Pragma: no-cache头信息发出)。或者你可以让缓存的管理员从他们的界面中删除相应内容;

    我运行一个Web托管服务,如何让我的用户发布缓存友好的网页?

    如果你使用apahe,可以考虑允许他们使用.htaccess文件并提供相应的文档;
    另外一方面: 你也可以考虑在各种虚拟主机上建立各种缓存策略。例如: 你可以设置一个目录 /cache-1m 专门用于存放访问1个月的访问,另外一个 /no-cache目录则被用提供不可存储副本的服务。
    无论如何:对于大量用户访问还是应该用缓存。对于大网站,这方面的节约很明显(带宽和服务器负载);

    我标记了一些网页是可缓存的,但是浏览器仍然每次发送请求给服务。如何强制他们保存副本?

    缓存服务器并不会总保存副本并重用副本;他们只是在特定情况下会不保存并使用副本。所有的缓存服务器都回基于文件的大小,类型(例如:图片 页面),或者服务器空间的剩余来确定如何缓存。你的页面相比更热门或者更大的文件相比,并不值得缓存。
    所以有些缓存服务器允许管理员根据文件类型确定缓存副本的优先级,允许某些副本被永久缓存并长期有效;

    缓存机制的实现 - Web服务器端配置

    一般说来,应该选择最新版本的Web服务器程序来部署。不仅因为它们包含更多利于缓存的功能,新版本往往在性能和安全性方面都有很多的改善。

    Apache HTTP服务器

    Apache有些可选的模块来包含这些头信息: 包括Expires和Cache-Control。 这些模块在1.2版本以上都支持;
    这些模块需要和apache一起编译;虽然他们已经包含在发布版本中,但缺省并没有启用。为了确定相应模块已经被启用:找到httpd程序并运行httpd -l 它会列出可用的模块,我们需要用的模块是mod_expires和mod_headers

    • 如果这些模块不可用,你需要联系管理员,重新编译并包含这些模块。这些模块有时候通过配置文件中把注释掉的配置启用,或者在编译的时候增加-enable -module=expires和-enable-module=headers选项(在apache 1.3和以上版本)。 参考Apache发布版中的INSTALL文件;

    Apache一旦启用了相应的模块,你就可以在.htaccess文件或者在服务器的access.conf文件中通过mod_expires设置副本什 么时候过期。你可设置过期从访问时间或文件修改时间开始计算,并且应用到某种文件类型上或缺省设置,参考模块的文档获得更多信息,或者遇到问题的时候向你身边的apache专家讨教。
    应用Cache-Control头信息,你需要使用mod_headers,它将允许你设置任意的HTTP头信息,参考mod_headers的文档可以获得更多资料;
    这里有个例子说明如何使用头信息:

    • .htaccess文件允许web发布者使用命令只在配置文件中用到的命令。他影响到所在目录及其子目录;问一下你的服务器管理员确认这个功能是否启用了。 
    ### 启用 mod_expires
    ExpiresActive On
    ### 设置 .gif 在被访问过后1个月过期。
    ExpiresByType image/gif A2592000
    ### 其他文件设置为最后修改时间1天后过期
    ### (用了另外的语法)
    ExpiresDefault "modification plus 1 day"
    ### 在index.html文件应用 Cache-Control头属性
    <Files index.html>
    Header append Cache-Control "public, must-revalidate"
    </Files>        
    • 注意: 在适当情况下mod_expires会自动计算并插入Cache-Control:max-age 头信息

    Apache 2.0的配置和1.3类似,更多信息可以参考2.0的mod_expiresmod_headers文档

    Microsoft IIS服务器

    Microsoft的IIS可以非常容易的设置头信息,注意:这只针对IIS 4.0服务器,并且只能在NT服务器上运行。
    为网站的一个区域设置头信息,先要到管理员工具界面中,然后设置属性。选择HTTP Header选单,你会看到2个有趣的区域:启用内容过期和定制HTTP头信息。头一个设置会自动配置,第二个可以用于设置Cache-Control头信息;
    设置asp页面的头信息可以参考后面的ASP章节,也可以通过ISAPI模块设置头信息,细节请参考MSDN。

    Netscape/iPlanet企业服务器

    3.6版本以后,Netscape/iPlanet已经不能设置Expires头信息了,他从3.0版本开始支持HTTP 1.1的功能。这意味着HTTP 1.1的缓存(代理服务器/浏览器)优势都可以通过你对Cache-Control设置来获得。
    使用Cache-Control头信息,在管理服务器上选择内容管理|缓存设置目录。然后:使用资源选择器,选择你希望设置头信息的目录。设置完头信息后,点击“OK”。更多信息请参考Netscape/iPlanet企业服务器的手册

    缓存机制的实现:服务器端脚本

    需要注意的一点是:也许服务器设置HTTP头信息比脚本语言更容易,但是两者你都应该使用。
    因为服务器端的脚本主要是为了动态内容,他本身不产生可缓存的文件页面,即使内容实际是可以缓存的。如果你的内容经常改变,但是不是每次页面请求都改变, 考虑设置一个Cache-Control: max-age头信息;大部分用户会在短时间内多次访问同一页面。例如: 用户点击“后退”按钮,即使没有新内容,他们仍然要再次从服务器下载内容查看。

    CGI程序

    CGI脚本是生成内容最流行的方式之一,你可以很容易在发送内容之前的扩展HTTP头信息;大部分CGI实现都需要你写 Content-Type头信息,例如这个Perl脚本:

    #!/usr/bin/perl
    print "Content-type: text/html\n";
    print "Expires: Thu, 29 Oct 1998 17:04:19 GMT\n";
    print "\n";
    ### 后面是内容体...

    由于都是文本,你可以很容易通过内置函数生成Expires和其他日期相关的头信息。如果你使用Cache-Control: max-age;会更简单;

    print "Cache-Control: max-age=600\n";

    这样脚本可以在被请求后缓存10分钟;这样用户如果按“后退”按钮,他们不会重新提交请求;
    CGI的规范同时也允许客户端发送头信息,每个头信息都有一个‘HTTP_’的前缀;这样如果一个客户端发送一个If-Modified-Since请求,就是这样的:

    HTTP_IF_MODIFIED_SINCE = Fri, 30 Oct 1998 14:19:41 GMT 


    参考一下cgi_buffer库,一个自动处理ETag的生成和校验的库,生成Content-Length属性和对内容进行gzip压缩。在Python脚本中也只需加入一行;

    服务器端包含 Server Side Includes

    SSI(经常使用.shtml扩展名)是网站发布者最早可以生成动态内容的方案。通过在页面中设置特别的标记,也成为一种嵌入HTML的脚本;
    大部分SSI的实现无法设置校验器,于是无法缓存。但是Apache可以通过对特定文件的组执行权限设置实现允许用户设置那种SSI可以被缓存;结合XbitHack调整整个目录。更多文档请参考mod_include文档

    PHP

    PHP是一个内建在web服务器中的服务器端脚本语言,当做为HTML嵌入式脚本,很像SSI,但是有更多的选项,PHP可以在各种Web服务器上设置为CGI模式运行,或者做为Apache的模块;
    缺省PHP生成副本没有设置校验器,于是也无法缓存,但是开发者可以通过Header()函数来生成HTTP的头信息;
    例如:以下代码会生成一个Cache-Control头信息,并设置为3天以后过期的Expires头信息;

    <?php
     Header("Cache-Control: must-revalidate");

     $offset = 60 * 60 * 24 * 3;
     $ExpStr = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT";
     Header($ExpStr);
    ?>

    记住: Header()的输出必须先于所有其他HTML的输出;
    正如你看到的:你可以手工创建HTTP日期;PHP没有为你提供专门的函数(新版本已经让这个越来越容易了,请参考PHP的日期相关函数文档),当然,最简单的还是设置Cache-Control: max-age头信息,而且对于大部分情况都比较适用;
    更多信息,请参考header相关的文档
    也请参考一下cgi_buffer库,自动处理ETag的生成和校验,Content-Length生成和内容的gzip压缩,PHP脚本只需包含1行代码;

    Cold Fusion

    Cold Fusion是Macromedia的商业服务器端脚本引擎,并且支持多种Windows平台,Linux平台和多种Unix平台。Cold Fusion通过CFHEADER标记设置HTTP头信息相对容易。可惜的是:以下的Expires头信息的设置有些容易误导;

    <CFHEADER NAME="Expires" VALUE="#Now()#">

    它并不像你想像的那样工作,因为时间(本例中为请求发起的时间)并不会被转换成一个符合HTTP时间,而且打印出副本的Cold fusion的日期/时间对象,大部分客户端会忽略或者将其转换成1970年1月1日。
    但是:Cold Fusion另外提供了一套日期格式化函数, GetHttpTimeSTring. 结合DateAdd函数,就很容易设置过期时间了,这里我们设置一个Header声明副本在1个月以后过期;

    <cfheader name="Expires" value="#GetHttpTimeString(DateAdd('m', 1, Now()))#">

    你也可以使用CFHEADER标签来设置Cache-Control: max-age等其他头信息;
    记住:Web服务器也会将头信息设置转给Cold Fusion(做为CGI运行的时候),检查你的服务器设置并确定你是否可以利用服务器设置代替Cold Fusion。 

    ASP和ASP.NET

    在asp中设置HTTP头信息是:确认Response方法先于HTML内容输出前被调用,或者使用 Response.Buffer暂存输出;同样的:注意某些版本的IIS缺省设置会输出Cache-Control: private 头信息,必须声明成public才能被共享缓存服务器缓存。
    IIS的ASP和其他web服务器都允许你设置HTTP头信息,例如: 设置过期时间,你可以设置Response对象的属性;

    <% Response.Expires=1440 %>

    设置请求的副本在输出的指定分钟后过期,类似的:也可以设置绝对的过期时间(确认你的HTTP日期格式正确)

    <% Response.ExpiresAbsolute=#May 31,1996 13:30:15 GMT# %>

    Cache-Control头信息可以这样设置:

    <% Response.CacheControl="public" %>

    在ASP.NET中,Response.Expires 已经不推荐使用了,正确的方法是通过Response.Cache设置Cache相关的头信息;

    Response.Cache.SetExpires ( DateTime.Now.AddMinutes ( 60 ) ) ;
    Response.Cache.SetCacheability ( HttpCacheability.Public ) ;

    参考MSDN文档可以找到更多相关新年系;

    参考文档和深入阅读

    HTTP 1.1 规范定义

    HTTP 1.1的规范有大量的扩展用于页面缓存,以及权威的接口实现指南,参考章节:13, 14.9, 14.21, 以及 14.25.

    Web-Caching.com

    非常精彩的介绍缓存相关概念,并介绍其他在线资源。

    关于非连续性访问统计

    Jeff Goldberg内容丰富的演说告诉你为什么不应该过度依赖访问统计和计数器;

    可缓存性检测引擎

    可缓存的引擎设计,检测网页并确定其如何与Web缓存服务器交互, 这个引擎配合这篇指南是一个很好的调试工具,

    cgi_buffer库

    包含库:用于CGI模式运行的Perl/Python/PHP脚本,自动处理ETag生成/校验,Content-Length生成和内容压缩。正确地。 Python版本也被用作其他大量的CGI脚本。

  • HTTP协议浅谈

    2009-07-27 17:16:03

    HTTP是一个属于应用层的面向对象的协议,由于其简捷、快速的方式,适用于分布式超媒体信息系统。它于1990年提出,经过几年的
    使用与发展,得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版,HTTP/1.1的规范化工作正在进行之中,而且HTTP-
    NG(Next Generation of HTTP)的建议已经提出。
    HTTP协议的主要特点可概括如下:
    1.支持客户/服务器模式。
    2.简单快速:客户向服务器请求服务时,只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服
    务器联系的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模小,因而通信速度很快。
    3.灵活:HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
    4.无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方
    式可以节省传输时间。
    5.无状态:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则
    它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。

    一、HTTP协议详解之URL篇

        http(超文本传输协议)是一个基于请求与响应模式的、无状态的、应用层的协议,常基于TCP的连接方
    式,HTTP1.1版本中给出一种持续连接的机制,绝大多数的Web开发,都是构建在HTTP协议之上的Web应用。

    HTTP URL (URL是一种特殊类型的URI,包含了用于查找某个资源的足够的信息)的格式如下:
    http://host[":"port][abs_path]
    http表示要通过HTTP协议来定位网络资源;host表示合法的Internet主机域名或者IP地址;port指定一个端口号,
    为空则使用缺省端口80;abs_path指定请求资源的URI;如果URL中没有给出abs_path,那么当它作为请求URI
    时,必须以“/”的形式给出,通常这个工作浏览器自动帮我们完成。
    eg:
    1、输入:
    www.guet.edu.cn
    浏览器自动转换成:http://www.guet.edu.cn/
    2、http:192.168.0.116:8080/index.jsp 

    二、HTTP协议详解之请求篇

        http请求由三部分组成,分别是:请求行、消息报头、请求正文

    1、请求行以一个方法符号开头,以空格分开,后面跟着请求的URI和协议的版本,格式如下:Method Request-
    URI HTTP-Version CRLF  
    其中 Method表示请求方法;Request-URI是一个统一资源标识符;HTTP-Version表示请求的HTTP协议版本;
    CRLF表示回车和换行(除了作为结尾的CRLF外,不允许出现单独的CR或LF字符)。

    请求方法(所有方法全为大写)有多种,各个方法的解释如下:
    GET     请求获取Request-URI所标识的资源
    POST    在Request-URI所标识的资源后附加新的数据
    HEAD    请求获取由Request-URI所标识的资源的响应消息报头
    PUT     请求服务器存储一个资源,并用Request-URI作为其标识
    DELETE  请求服务器删除Request-URI所标识的资源
    TRACE   请求服务器回送收到的请求信息,主要用于测试或诊断
    CONNECT 保留将来使用
    OPTIONS 请求查询服务器的性能,或者查询与资源相关的选项和需求
    应用举例:
    GET方法:在浏览器的地址栏中输入网址的方式访问网页时,浏览器采用GET方法向服务器获取资源,
    eg:GET /form.html HTTP/1.1 (CRLF)

    POST方法要求被请求服务器接受附在请求后面的数据,常用于提交表单。
    eg:POST /reg.jsp HTTP/ (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)
    (CRLF)         //该CRLF表示消息报头已经结束,在此之前为消息报头
    user=jeffrey&pwd=1234  //此行以下为提交的数据

    HEAD方法与GET方法几乎是一样的,对于HEAD请求的回应部分来说,它的HTTP头部中包含的信息与通过
    GET请求所得到的信息是相同的。利用这个方法,不必传输整个资源内容,就可以得到Request-URI所标识的资
    源的信息。该方法常用于测试超链接的有效性,是否可以访问,以及最近是否更新。
    2、请求报头后述
    3、请求正文(略) 

    三、HTTP协议详解之响应篇

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

    HTTP响应也是由三个部分组成,分别是:状态行、消息报头、响应正文
    1、状态行格式如下:
    HTTP-Version Status-Code Reason-Phrase CRLF
    其中,HTTP-Version表示服务器HTTP协议的版本;Status-Code表示服务器发回的响应状态代码;Reason-Phrase
    表示状态代码的文本描述。
    状态代码有三位数字组成,第一个数字定义了响应的类别,且有五种可能取值:
    1xx:指示信息--表示请求已接收,继续处理
    2xx:成功--表示请求已被成功接收、理解、接受
    3xx:重定向--要完成请求必须进行更进一步的操作
    4xx:客户端错误--请求有语法错误或请求无法实现
    5xx:服务器端错误--服务器未能实现合法的请求
    常见状态代码、状态描述、说明:
    200 OK      //客户端请求成功
    400 Bad Request  //客户端请求有语法错误,不能被服务器所理解
    401 Unauthorized //请求未经授权,这个状态代码必须和WWW-Authenticate报                 //头域一起使用 
    403 Forbidden  //服务器收到请求,但是拒绝提供服务
    404 Not Found  //请求资源不存在,eg:输入了错误的URL
    500 Internal Server Error //服务器发生不可预期的错误
    503 Server Unavailable  //服务器当前不能处理客户端的请求,一段时间后,                         //可能恢复正常
    eg:HTTP/1.1 200 OK (CRLF)

    2、响应报头后述

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

    四、HTTP协议详解之消息报头篇

        HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行(对
    于请求消息,开始行就是请求行,对于响应消息,开始行就是状态行),消息报头(可选),空行(只有
    CRLF的行),消息正文(可选)组成。

    HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。
    每一个报头域都是由名字+“:”+空格+值 组成,消息报头域的名字是大小写无关的。

    1、普通报头
    在普通报头中,有少数报头域用于所有的请求和响应消息,但并不用于被传输的实体,只用于传输的消息。
    eg:
    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.
    eg:为了指示IE浏览器(客户端)不要缓存页面,服务器端的JSP程序可以编写如下:response.sehHeader
    ("Cache-Control","no-cache");
    //response.setHeader("Pragma","no-cache");作用相当于上述代码,通常两者//合用
    这句代码将在发送的响应消息中设置普通报头域:Cache-Control:no-cache


    Date普通报头域表示消息产生的日期和时间

    Connection普通报头域允许发送指定连接的选项。例如指定连接是连续,或者指定“close”选项,通知服务
    器,在响应完成后,关闭连接

    2、请求报头
    请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。
    常用的请求报头
    Accept
    Accept请求报头域用于指定客户端接受哪些类型的信息。eg:Accept:image/gif,表明客户端希望接受GIF图象
    格式的资源;Accept:text/html,表明客户端希望接受html文本。
    Accept-Charset
    Accept-Charset请求报头域用于指定客户端接受的字符集。eg:Accept-Charset:iso-8859-1,gb2312.如果在请求消
    息中没有设置这个域,缺省是任何字符集都可以接受。
    Accept-Encoding
    Accept-Encoding请求报头域类似于Accept,但是它是用于指定可接受的内容编码。eg:Accept-Encoding:gzip.deflate.如果请求消息中没有设置这个域服务器假定客户端对各种内容编码都可以接受。
    Accept-Language
    Accept-Language请求报头域类似于Accept,但是它是用于指定一种自然语言。eg:Accept-Language:zh-cn.如果请
    求消息中没有设置这个报头域,服务器假定客户端对各种语言都可以接受。
    Authorization
    Authorization请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时,如果收到服务器
    的响应代码为401(未授权),可以发送一个包含Authorization请求报头域的请求,要求服务器对其进行验证。
    Host(发送请求时,该报头域是必需的)
    Host请求报头域主要用于指定被请求资源的Internet主机和端口号,它通常从HTTP URL中提取出来的,eg:
    我们在浏览器中输入:
    http://www.guet.edu.cn/index.html
    浏览器发送的请求消息中,就会包含Host请求报头域,如下:
    Host:
    www.guet.edu.cn
    此处使用缺省端口号80,若指定了端口号,则变成:Host:www.guet.edu.cn:指定端口号
    User-Agent
    我们上网登陆论坛的时候,往往会看到一些欢迎信息,其中列出了你的操作系统的名称和版本,你所使用的
    浏览器的名称和版本,这往往让很多人感到很神奇,实际上,服务器应用程序就是从User-Agent这个请求报头
    域中获取到这些信息。User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它属性告诉服务器。不
    过,这个报头域不是必需的,如果我们自己编写一个浏览器,不使用User-Agent请求报头域,那么服务器端就
    无法得知我们的信息了。
    请求报头举例:
    GET /form.html HTTP/1.1 (CRLF)
    Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-
    powerpoint,application/msword,*/* (CRLF)
    Accept-Language:zh-cn (CRLF)
    Accept-Encoding:gzip,deflate (CRLF)
    If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)
    If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF)
    User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)
    Host:www.guet.edu.cn (CRLF)
    Connection:Keep-Alive (CRLF)
    (CRLF)

    3、响应报头
    响应报头允许服务器传递不能放在状态行中的附加响应信息,以及关于服务器的信息和对Request-URI所标识
    的资源进行下一步访问的信息。
    常用的响应报头
    Location
    Location响应报头域用于重定向接受者到一个新的位置。Location响应报头域常用在更换域名的时候。
    Server
    Server响应报头域包含了服务器用来处理请求的软件信息。与User-Agent请求报头域是相对应的。下面是
    Server响应报头域的一个例子:
    Server:Apache-Coyote/1.1
    WWW-Authenticate
    WWW-Authenticate响应报头域必须被包含在401(未授权的)响应消息中,客户端收到401响应消息时候,并发
    送Authorization报头域请求服务器对其进行验证时,服务端响应报头就包含该报头域。
    eg:WWW-Authenticate:Basic realm="Basic Auth Test!"  //可以看出服务器对请求资源采用的是基本验证机制。


    4、实体报头
    请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成,但并不是说实体报头域和实体正文要在一起发送,可以只发送实体报头域。实体报头定义了关于实体正文(eg:有无实体正文)和请求所标识的资源的元信息。
    常用的实体报头
    Content-Encoding
    Content-Encoding实体报头域被用作媒体类型的修饰符,它的值指示了已经被应用到实体正文的附加内容的编
    码,因而要获得Content-Type报头域中所引用的媒体类型,必须采用相应的解码机制。Content-Encoding这样用
    于记录文档的压缩方法,eg:Content-Encoding:gzip
    Content-Language
    Content-Language实体报头域描述了资源所用的自然语言。没有设置该域则认为实体内容将提供给所有的语言
    阅读
    者。eg:Content-Language:da
    Content-Length
    Content-Length实体报头域用于指明实体正文的长度,以字节方式存储的十进制数字来表示。
    Content-Type
    Content-Type实体报头域用语指明发送给接收者的实体正文的媒体类型。eg:
    Content-Type:text/html;charset=ISO-8859-1
    Content-Type:text/html;charset=GB2312
    Last-Modified
    Last-Modified实体报头域用于指示资源的最后修改日期和时间。
    Expires
    Expires实体报头域给出响应过期的日期和时间。为了让代理服务器或浏览器在一段时间以后更新缓存中(再次
    访问曾访问过的页面时,直接从缓存中加载,缩短响应时间和降低服务器负载)的页面,我们可以使用Expires
    实体报头域指定页面过期的时间。eg:Expires:Thu,15 Sep 2006 16:23:12 GMT
    HTTP1.1的客户端和缓存必须将其他非法的日期格式(包括0)看作已经过期。eg:为了让浏览器不要缓存页
    面,我们也可以利用Expires实体报头域,设置为0,jsp中程序如下:response.setDateHeader("Expires","0");

    五、利用telnet观察http协议的通讯过程

        实验目的及原理:
        利用MS的telnet工具,通过手动输入http请求信息的方式,向服务器发出请求,服务器接收、解释和接受请求
    后,会返回一个响应,该响应会在telnet窗口上显示出来,从而从感性上加深对http协议的通讯过程的认识。

        实验步骤:

    1、打开telnet
    1.1 打开telnet
    运行-->cmd-->telnet

    1.2 打开telnet回显功能
    set localecho

    2、连接服务器并发送请求
    2.1 open 
    www.guet.edu.cn 80  //注意端口号不能省略

        HEAD /index.asp HTTP/1.0
        Host:www.guet.edu.cn
        
       /*我们可以变换请求方法,请求桂林电子主页内容,输入消息如下*/
        open 
    www.guet.edu.cn 80 
       
        GET /index.asp HTTP/1.0  //请求资源的内容
        Host:www.guet.edu.cn  

    2.2 open www.sina.com.cn 80  //在命令提示符号下直接输入telnet www.sina.com.cn80
        HEAD /index.asp HTTP/1.0
        Host:www.sina.com.cn
     

    3 实验结果:

    3.1 请求信息2.1得到的响应是:

    HTTP/1.1 200 OK                                              //请求成功
    Server: Microsoft-IIS/5.0                                    //web服务器
    Date: Thu,08 Mar 200707:17:51 GMT
    Connection: Keep-Alive                                 
    Content-Length: 23330
    Content-Type: text/html
    Expries: Thu,08 Mar 2007 07:16:51 GMT
    Set-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/
    Cache-control: private

    //资源内容省略

    3.2 请求信息2.2得到的响应是:

    HTTP/1.0 404 Not Found       //请求失败
    Date: Thu, 08 Mar 2007 07:50:50 GMT
    Server: Apache/2.0.54 <Unix>
    Last-Modified: Thu, 30 Nov 2006 11:35:41 GMT
    ETag: "6277a-415-e7c76980"
    Accept-Ranges: bytes
    X-Powered-By: mod_xlayout_jh/0.0.1vhs.markII.remix
    Vary: Accept-Encoding
    Content-Type: text/html
    X-Cache: MISS from zjm152-78.sina.com.cn
    Via: 1.0 zjm152-78.sina.com.cn:80<squid/2.6.STABLES-20061207>
    X-Cache: MISS from th-143.sina.com.cn
    Connection: close


    失去了跟主机的连接

    按任意键继续...


    4 .注意事项:1、出现输入错误,则请求不会成功。
              2、报头域不分大小写。
              3、更深一步了解HTTP协议,可以查看RFC2616,在
    http://www.letf.org/rfc上找到该文件。
              4、开发后台程序必须掌握http协议

     

    六、HTTP协议相关技术补充

        1、基础:
        高层协议有:文件传输协议FTP、电子邮件传输协议SMTP、域名系统服务DNS、网络新闻传输协议NNTP和
    HTTP协议等
    中介由三种:代理(Proxy)、网关(Gateway)和通道(Tunnel),一个代理根据URI的绝对格式来接受请求,重写全部
    或部分消息,通过 URI的标识把已格式化过的请求发送到服务器。网关是一个接收代理,作为一些其它服务
    器的上层,并且如果必须的话,可以把请求翻译给下层的服务器协议。一 个通道作为不改变消息的两个连接
    之间的中继点。当通讯需要通过一个中介(例如:防火墙等)或者是中介不能识别消息的内容时,通道经常被使
    用。
         代理(Proxy):一个中间程序,它可以充当一个服务器,也可以充当一个客户机,为其它客户机建立请求。
    请求是通过可能的翻译在内部或经过传递到其它的 服务器中。一个代理在发送请求信息之前,必须解释并且
    如果可能重写它。代理经常作为通过防火墙的客户机端的门户,代理还可以作为一个帮助应用来通过协议处 
    理没有被用户代理完成的请求。
    网关(Gateway):一个作为其它服务器中间媒介的服务器。与代理不同的是,网关接受请求就好象对被请求的
    资源来说它就是源服务器;发出请求的客户机并没有意识到它在同网关打交道。
      网关经常作为通过防火墙的服务器端的门户,网关还可以作为一个协议翻译器以便存取那些存储在非
    HTTP系统中的资源。
        通道(Tunnel):是作为两个连接中继的中介程序。一旦激活,通道便被认为不属于HTTP通讯,尽管通道可能
    是被一个HTTP请求初始化的。当被中继 的连接两端关闭时,通道便消失。当一个门户(Portal)必须存在或中介
    (Intermediary)不能解释中继的通讯时通道被经常使用。


    2、协议分析的优势—HTTP分析器检测网络攻击
    以模块化的方式对高层协议进行分析处理,将是未来入侵检测的方向。
    HTTP及其代理的常用端口80、3128和8080在network部分用port标签进行了规定

    3、HTTP协议Content Lenth限制漏洞导致拒绝服务攻击
    使用POST方法时,可以设置ContentLenth来定义需要传送的数据长度,例如ContentLenth:999999999,在传送完
    成前,内 存不会释放,攻击者可以利用这个缺陷,连续向WEB服务器发送垃圾数据直至WEB服务器内存耗
    尽。这种攻击方法基本不会留下痕迹。
    http://www.cnpaf.net/Class/HTTP/0532918532667330.html


    4、利用HTTP协议的特性进行拒绝服务攻击的一些构思
    服务器端忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之
    小),此时从正常客户的角度看来,服务器失去响应,这种情况我们称作:服务器端受到了SYNFlood攻击(SYN洪水攻击)。
    而Smurf、TearDrop等是利用ICMP报文来Flood和IP碎片攻击的。本文用“正常连接”的方法来产生拒绝服务攻击。
    19端口在早期已经有人用来做Chargen攻击了,即Chargen_Denial_of_Service,但是!他们用的方法是在两台
    Chargen 服务器之间产生UDP连接,让服务器处理过多信息而DOWN掉,那么,干掉一台WEB服务器的条件就
    必须有2个:1.有Chargen服务2.有HTTP 服务
    方法:攻击者伪造源IP给N台Chargen发送连接请求(Connect),Chargen接收到连接后就会返回每秒72字节的
    字符流(实际上根据网络实际情况,这个速度更快)给服务器。


    5、Http指纹识别技术
       Http指纹识别的原理大致上也是相同的:记录不同服务器对Http协议执行中的微小差别进行识别.Http指纹识
    别比TCP/IP堆栈指纹识别复杂许 多,理由是定制Http服务器的配置文件、增加插件或组件使得更改Http的响应
    信息变的很容易,这样使得识别变的困难;然而定制TCP/IP堆栈的行为 需要对核心层进行修改,所以就容易识
    别.
          要让服务器返回不同的Banner信息的设置是很简单的,象Apache这样的开放源代码的Http服务器,用户可以在
    源代码里修改Banner信息,然 后重起Http服务就生效了;对于没有公开源代码的Http服务器比如微软的IIS或者
    是Netscape,可以在存放Banner信息的Dll文件中修 改,相关的文章有讨论的,这里不再赘述,当然这样的修改的效果
    还是不错的.另外一种模糊Banner信息的方法是使用插件。
    常用测试请求:
    1:HEAD/Http/1.0发送基本的Http请求
    2:DELETE/Http/1.0发送那些不被允许的请求,比如Delete请求
    3:GET/Http/3.0发送一个非法版本的Http协议请求
    4:GET/JUNK/1.0发送一个不正确规格的Http协议请求
    Http指纹识别工具Httprint,它通过运用统计学原理,组合模糊的逻辑学技术,能很有效的确定Http服务器的类型.它
    可以被用来收集和分析不同Http服务器产生的签名。


    6、其他:为了提高用户使用浏览器时的性能,现代浏览器还支持并发的访问方式,浏览一个网页时同时建立
    多个连接,以迅速获得一个网页上的多个图标,这样能更快速完成整个网页的传输。
    HTTP1.1中提供了这种持续连接的方式,而下一代HTTP协议:HTTP-NG更增加了有关会话控制、丰富的内容
    协商等方式的支持,来提供
    更高效率的连接。

  • HTTP协议header头域

    2009-07-27 17:11:40

    HTTP(HyperTextTransferProtocol)是超文本传输协议的缩写,它用于传送WWW方式的数据,关于HTTP协议的详细内容请参考RFC2616。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求,请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应,相应的内容包括消息协议的版本,成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。
      通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行,一个或者多个头域,一个只是头域结束的空行和可选的消息体组成。HTTP的头域包括通用头,请求头,响应头和实体头四个部分。每个头域由一个域名,冒号(:)和域值三部分组成。域名是大小写无关的,域值前可以添加任何数量的空格符,头域可以被扩展为多行,在每行开始处,使用至少一个空格或制表符。

      通用头域
      通用头域包含请求和响应消息都支持的头域,通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展,如果存在不支持的通用头域,一般将会作为实体头域处理。下面简单介绍几个在UPnP消息中使用的通用头域。
      Cache-Control头域
      Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括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。各个消息中的指令含义如下:
      Public指示响应可被任何缓存区缓存。
      Private指示对于单个用户的整个或部分响应消息,不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息,此响应消息对于其他用户的请求无效。
      no-cache指示请求或响应消息不能缓存
      no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。
      max-age指示客户机可以接收生存期不大于指定时间(以秒为单位)的响应。
      min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。
      max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值,那么客户机可以接收超出超时期指定值之内的响应消息。
      Date头域
      Date头域表示消息发送的时间,时间的描述格式由rfc822定义。例如,Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时,换算成本地时间,需要知道用户所在的时区。
      Pragma头域
      Pragma头域用来包含实现特定的指令,最常用的是Pragma:no-cache。在HTTP/1.1协议中,它的含义和Cache-Control:no-cache相同。

      请求消息
      请求消息的第一行为下面的格式:
      MethodSPRequest-URISPHTTP-VersionCRLFMethod表示对于Request-URI完成的方法,这个字段是大小写敏感的,包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。方法GET和HEAD应该被所有的通用WEB服务器支持,其他所有方法的实现是可选的。GET方法取回由Request-URI标识的信息。HEAD方法也是取回由Request-URI标识的信息,只是可以在响应时,不返回消息体。POST方法可以请求服务器接收包含在请求中的实体信息,可以用于提交表单,向新闻组、BBS、邮件群组和数据库发送消息。
      SP表示空格。Request-URI遵循URI格式,在此字段为星号(*)时,说明请求并不用于某个特定的资源地址,而是用于服务器本身。HTTP-Version表示支持的HTTP版本,例如为HTTP/1.1。CRLF表示换行回车符。请求头域允许客户端向服务器传递关于请求或者关于客户机的附加信息。请求头域可能包含下列字段Accept、Accept-Charset、Accept-Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。对请求头域的扩展要求通讯双方都支持,如果存在不支持的请求头域,一般将会作为实体头域处理。
      典型的请求消息:
      GEThttp://class/download.microtool.de:80/somedata.exe
      Host:download.microtool.de
      Accept:*/*
      Pragma:no-cache
      Cache-Control:no-cache
      Referer:http://class/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请求头,响应会以状态码206(PartialContent)返回而不是以200(OK)。
      User-Agent头域
      User-Agent头域的内容包含发出请求的用户信息。

      响应消息
      响应消息的第一行为下面的格式:
      HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF
      HTTP-Version表示支持的HTTP版本,例如为HTTP/1.1。Status-Code是一个三个数字的结果代码。Reason-Phrase给Status-Code提供一个简单的文本描述。Status-Code主要用于机器自动识别,Reason-Phrase主要用于帮助用户理解。Status-Code的第一个数字定义响应的类别,后两个数字没有分类的作用。第一个数字可能取5个不同的值:
      1xx:信息响应类,表示接收到请求并且继续处理
      2xx:处理成功响应类,表示动作被成功接收、理解和接受
      3xx:重定向响应类,为了完成指定的动作,必须接受进一步处理
      4xx:客户端错误,客户请求包含语法错误或者是不能正确执行
      5xx:服务端错误,服务器不能正确执行一个正确的请求
      响应头域允许服务器传递不能放在状态行的附加信息,这些域主要描述服务器的信息和Request-URI进一步的信息。响应头域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-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响应头包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释,产品标识一般按照重要性排序。

      实体
      请求消息和响应消息都可以包含实体信息,实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息,实体头包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。extension-header允许客户端定义新的实体头,但是这些域可能无法未接受方识别。实体可以是一个经过编码的字节流,它的编码方式由Content-Encoding或Content-Type定义,它的长度由Content-Length或Content-Range定义。
      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实体头
      指定服务器上保存内容的最后修订时间。

Open Toolbar