发表于：2018-07-02 作者：画师Linty 来源：简书

Web测试基础
I. 如何开展Web测试
Web测试的对象

• Web的页面元素
• Web的业务逻辑
• Web的数据行为

Web测试的要求

• 功能完全实现
• 性能符合标准
• 兼容问题解决

Web测试环境搭建

• 测试环境的概念

在测试执行过程中，测试环境的建立和维护是主要工作之一。测试环境不仅包括被测试的软件系统环境，还包括执行测试用例的自动化环境或测试服务器的客户端环境。
一般公司具有以下三种环境：开发环境，测试环境，生产环境。
测试环境：专门给测试人员使用，确保测试可以隔离和独立进行的一套干净的被测程序运行的环境。

1. 软件：计算机操作系统 Web服务器软件、应用服务器软件 数据库管理系统 支持的编程语言库
2. 硬件：计算机 服务器 终端设备 等
3. 数据：初始化数据、测试用例数据和用来保存各种测试工作中生成的文档和数据的文件服务器、驱动器等
4. 测试工具：浏览器工具、自动化测试工具、自定义的测试工具

Web测试版本部署
将测试版本构建好，并且部署到指定的测试环境中。
II. 理解Web系统
系统架构

1. B/S vs C/S

B/S: Browser/Server 用浏览器查看的应用程序。
C/S: Client/Server 需要额外安装客户端的非单机版的应用程序。

1. B/S和C/S各有千秋，他们都是当前非常重要的计算架构
2. 在适用Internet、维护工作量等方面，B/S比C/S要强得多
3. B/S 架构需要进行浏览器的兼容性测试，需要考虑系统在不同的浏览器里面是否满足需求。
4. C/S 架构需要进行系统的安装、升级与卸载等测试，需要考虑不同的支持的平台等问题。
5. C/S 一般建立在专用的网络上, 小范围里的网络环境， 局域网之间再通过专门服务器提供连接和数据交换服务。
6. B/S 建立在广域网之上的, 不必是专门的网络硬件环境，比C/S更强的适应范围，需要关注服务器的负载与性能测试。

1. 典型三层架构

三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：
o    界面层（User Interface layer），又叫做表示层（Presentation Layer）
o    业务逻辑层（Business Logic Layer）
o    数据访问层（Data access layer）
区分层次的目的即为了“高内聚低耦合”的思想。
在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。

3. 接口介绍

接口一直指的是在应用程序架构中，用来提供标准数据输入和输出的方法和功能程序。主要包括Webservice，WebApi，普通API，SoapAPI，RESTFul API等。

• 接口中实现的方法和要求参数一目了然
• 不用担心大小写问题（有严格的要求）
• 不用担心中文编码问题
• 传递参数可以为对象（哈希表、数组等）

​
​
接口实例：
天气预报接口：
接口URL: http://www.webxml.com.cn/WebServices/WeatherWebService.asmx
网络服务描述语言: http://www.webxml.com.cn/WebServices/WeatherWebService.asmx?wsdl
该接口有5个方法:
- getSupportCity()
- getSupportDataSet()
- getSupportProvince()
- getWeatherbyCityName()
- getWeatherbyCityNamePro()
​

• 通过输入参数，可以调用这些接口，并得到请求的数据。

查询本天气预报Web Services支持的国内外城市或地区信息：
http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getSupportCity?byProvinceName=广东
 
http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getSupportCity?byProvinceName=北京
 
http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getSupportCity?byProvinceName=上海
 
http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getSupportCity?byProvinceName=湖北
 
http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getSupportCity?byProvinceName=河南
​
查询获得本天气预报Web Services支持的洲、国内外省份和城市信息
http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getSupportDataSet
查询获得本天气预报Web Services支持的洲、国内外省份和城市信息
http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getSupportProvince
查询获得根据城市或地区名称查询获得未来三天内天气情况、现在的天气实况、天气和生活指数
http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getWeatherbyCityName?theCityName=深圳
 
  http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getWeatherbyCityName?theCityName=59493
 
  http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getWeatherbyCityName?theCityName=北京
 
  http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getWeatherbyCityName?theCityName=54511
 
  http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getWeatherbyCityName?theCityName=上海
 
  http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getWeatherbyCityName?theCityName=58367
 
  http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getWeatherbyCityName?theCityName=香港
 
  http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getWeatherbyCityName?theCityName=45005
 
  http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getWeatherbyCityName?theCityName=Chicago
 
  http://www.webxml.com.cn/WebServices/WeatherWebService.asmx/getWeatherbyCityName?theCityName=72530
​
​
Web原理
Web万维网，既是一种网络使用环境又是一些相关技术的总称
技术视角：从技术的角度来看，Web技术包含网站网页的布局设计、代码编写、数据库建立、网络平台选择等相关技术
用户视角：从网络使用环境的角度来看，Web就是我们平常使用浏览器上网时所浏览的网页

1. URL

Uniform Resoure Locator，统一资源定位符。指的是网页的地址等。
URL的格式
schema :// host [ : port] path [query # fragment ]

格式内容	描述
schema	模式，协议
host	主机名，域名，IP地址
port	端口，若端口不是默认，则需要显示写出来。http 80/https 443/ftp 21/20
path	资源路径，相对路径
query	查询字符串
fragment	片段。片段不会发送给服务器

​
URL示例
http://item.jd.com/1866658.html#comment
http://localhost:808/ranzhi/www/sys/index.php
https://www.baidu.com
​
​

2. HTTP

HTTP协议（HyperText Transfer Protocol，超文本转移协议）
是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。
HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。
HTTP协议本身是一个无状态的协议。客户端只需要简单的向服务器端发出请求，客户端和服务器端都没有必要记录彼此过去的行为，每一次请求之间都是独立的。

3. 会话机制

HTTP协议基于TCP协议.
1.建立TCP连接
2.发送请求
3.回送响应
4.断开TCP连接
以在IE浏览器的地址栏中输入https://www.baidu.com/，然后回车。
1. 浏览器从URL中解析出<host>， 若<host>为域名，则需要进行DNS解析
2. 浏览器从URL中解析出<port>， 省略的则为对应协议的默认端口。
3. 根据<schema>建立TCP连接
4. Web浏览器发送HTTP请求，在请求中会包含<path>，<query>。
5. Web服务器接收并处理请求，将请求的结构返回给web浏览器(回送HTTP响应)
6. 断开TCP连接并解析显示页面

1. TCP vs UDP

UDP: 用户数据报协议，User Datagram Protocol，无连接的服务

• 不需要事先建立连接，直接发送数据
• 每个报文都带有完整的目的地址
• 不保证报文传输的可靠性

TCP: 传输控制协议，Transmission Control Protocol，面向连接的服务

• 先建立连接再传输数据，之后再断开连接
• 数据传输过程中，数据包不需要携带目的地址
• 保证数据传输的可靠性

TCP三次握手 开始
TCP四次握手 结束
小结TCP与UDP的区别：

1. TCP是面向连接的服务，先建立连接再传输数据，之后再断开连接；
2. TCP数据传输过程中，数据包不需要携带目的地址；
3. TCP流模式传输数据，保证数据传输的序列正确性和可靠性。
4. UDP是无连接的服务，不需要事先建立连接，直接发送数据；
5. UPD每个数据报文都带有完成的目标地址
6. UPD是数据包模式传输数据，不保证报文传输的可靠性，可能丢包。

相关技术

1. Web客户端

浏览器功能：发送HTTP请求，接收web服务器的响应并解析成Web页面
浏览器组成：
浏览器引擎
A web browser engine (sometimes called layout engine or rendering engine) is a software component that takes marked up content (such as HTML, XML, image files, etc.) and formatting information (such as CSS, XSL, etc.) and displays the formatted content on the screen
浏览器最重要或者说核心的部分是“Rendering Engine”，可大概译为“渲染引擎”，不过我们一般习惯将之称为“浏览器内核”。负责对网页的标记内容（例如HTML、XML、JavaScript、图片等）和格式化的信息（例如CSS、XSL等）的语法的解释并渲染显示网页。
通常所谓的浏览器内核也就是浏览器所采用的渲染引擎，渲染引擎决定了浏览器如何显示网页的内容以及页面的格式信息。不同的浏览器内核对网页编写语法的解释也有不同，因此同一网页在不同的内核的浏览器里的渲染显示效果也可能不同，这也是网页编写者需要在不同内核的浏览器中测试网页显示效果的原因。

• Trident

Trident(IE内核)：该内核程序在1997年的IE4中首次被采用，是微软在Mosaic代码的基础之上修改而来的，并沿用到IE11，也被普遍称作”IE内核”。Trident实际上是一款开放的内核，其接口内核设计的相当成熟，因此才有许多采用IE内核而非IE的浏览器涌现。
由于IE本身的“垄断性”而使得Trident内核的长期一家独大，微软很长时间都并没有更新Trident内核，这导致了两个后果——一是Trident内核曾经几乎与W3C标准脱节（2005年），二是Trident内核的大量 Bug等安全性问题没有得到及时解决，然后加上一些致力于开源的开发者和一些学者们公开自己认为IE浏览器不安全的观点，也有很多用户转向了其他浏览器，Firefox和Opera就是这个时候兴起的。非Trident内核浏览器的市场占有率大幅提高也致使许多网页开发人员开始注意网页标准和非IE浏览器的浏览效果问题。
IE从版本11开始，初步支持WebGL技术。IE8的JavaScript引擎是Jscript，IE9开始用Chakra，这两个版本区别很大，Chakra无论是速度和标准化方面都很出色。

• Gecko

Gecko(Firefox内核)：Netscape6开始采用的内核，后来的Mozilla FireFox(火狐浏览器) 也采用了该内核，Gecko的特点是代码完全公开，因此，其可开发程度很高，全世界的程序员都可以为其编写代码，增加功能。因为这是个开源内核，因此受到许多人的青睐，Gecko内核的浏览器也很多，这也是Gecko内核虽然年轻但市场占有率能够迅速提高的重要原因。
事实上，Gecko引擎的由来跟IE不无关系，前面说过IE没有使用W3C的标准，这导致了微软内部一些开发人员的不满；他们与当时已经停止更新了的 Netscape的一些员工一起创办了Mozilla，以当时的Mosaic内核为基础重新编写内核，于是开发出了Gecko。不过事实上，Gecko 内核的浏览器仍然还是Firefox (火狐) 用户最多，所以有时也会被称为Firefox内核。此外Gecko也是一个跨平台内核，可以在Windows、 BSD、Linux和Mac OS X中使用。
补充：JavaScript引擎是SpiderMonkey。

• Webkit

Webkit(Safari内核,Chrome内核原型,开源):它是苹果公司自己的内核，也是苹果的Safari浏览器使用的内核。 Webkit引擎包含WebCore排版引擎及JavaScriptCore解析引擎，均是从KDE的KHTML及KJS引擎衍生而来，它们都是自由软件，在GPL条约下授权，同时支持BSD系统的开发。所以Webkit也是自由软件，同时开放源代码。在安全方面不受IE、Firefox的制约，所以Safari浏览器在国内还是很安全的。
限于Mac OS X的使用不广泛和Safari浏览器曾经只是Mac OS X的专属浏览器，这个内核本身应该说市场范围并不大；但似乎根据最新的浏览器调查表明，该浏览器的市场甚至已经超过了Opera的Presto了——当然这一方面得益于苹果转到x86架构之后的人气暴涨，另外也是因为Safari 3终于推出了Windows版的缘故吧。Mac下还有OmniWeb、Shiira等人气很高的浏览器。

• Chromium

Chromium（Chrome内核）： 之前基于Webkit开发，现在基于Blink开发。
Blink是一个由Google和Opera Software开发的浏览器排版引擎，Google计划将这个渲染引擎作为Chromium计划的一部分，并且在2013年4月的时候公布了这一消息。这一渲染引擎是开源引擎WebKit中WebCore组件的一个分支，并且在Chrome（28及往后版本）、Opera（15及往后版本）和Yandex浏览器中使用。

• Presto

Presto(Opera前内核) (已废弃)： Opera12.17及更早版本曾经采用的内核，现已停止开发并废弃，该内核在2003年的Opera7中首次被使用，该款引擎的特点就是渲染速度的优化达到了极致，然而代价是牺牲了网页的兼容性。
实际上这是一个动态内核，与前面几个内核的最大的区别就在脚本处理上，Presto有着天生的优势，页面的全部或者部分都能够在回应脚本事件时等情况下被重新解析。此外该内核在执行Javascrīpt的时候有着最快的速度，根据在同等条件下的测试，Presto内核执行同等Javascrīpt所需的时间仅有Trident和Gecko内核的约1/3（Trident内核最慢，不过两者相差没有多大），本文的其中一个修改者认为上述测试信息过于老旧且不完整，因为他曾做过的小测试显示Presto部分快部分慢，各内核总体相当。那次测试的时候因为Apple机的硬件条件和普通PC机不同所以没有测试WebCore内核。只可惜Presto是商业引擎，使用Presto的除开Opera以外，只剩下NDSBrowser、Wii Internet Channle、Nokia 770网络浏览器等，这很大程度上限制了Presto的发展。

1. Web服务器

• Apache

Apache:在Web服务器中，Apache是纯粹的Web服务器，经常与Tomcat配对使用。它对HTML页面具有强大的解释能力，但是不能解释嵌入页面内的服务器端脚本代码（JSP/Servlet）。
Apache源于NCSAhttpd服务器，经过多次修改，成为世界上最流行的Web服务器软件之一。 Apache是自由软件，所以不断有人来为它开发新的功能、新的特性、修改原来的缺陷。Apache的特点是简单、速度快、性能稳定，并可做代理服务器来使用。本来它只用于小型或试验Internet网络，后来逐步扩充到各种Unix系统中，尤其对Linux的支持相当完美。
Apache是以进程为基础的结构，进程要比线程消耗更多的系统开支，不太适合于多处理器环境，因此， 在一个Apache Web站点扩容时，通常是增加服务器或扩充群集节点而不是增加处理器。到目前为止Apache仍然是世界上用的最多的Web服务器，世界上很多著名的网站都是Apache的产物，它的成功之处主要在于它的源代码开放、有一支开放的开发队伍、支持跨平台的应用以及它的可移植性等方面。

• Tomcat

Tomcat:早期的Tomcat是一个嵌入Apache内的JSP/Servlet解释引擎Apache+Tomcat就相当于IIS+ASP。后来的Tomcat已不再嵌入Apache内，Tomcat进程独立于Apache进程运行。 而且，Tomcat已经是一个独立的Servlet和JSP容器，业务逻辑层代码和界面交互层代码可以分离了。因此，有人把Tomcat叫做轻量级应用服务器。

• IIS

Microsoft的Web服务器产品为Internet Information Server (IIS)， IIS 是允许在公共Intranet或Internet上发布信息的Web服务器。IIS是目前最流行的Web服务器产品之一，很多著名的网站都是建立在IIS 的平台上。IIS提供了一个图形界面的管理工具，称为 Internet服务管理器，可用于监视配置和控制Internet服务。
IIS是一种Web服务组件，其中包括Web服务器、FTP服务器、NNTP服务器和SMTP服务器， 分别用于网页浏览、文件传输、新闻服务和邮件发送等方面，它使得在网络(包括互联网和局域网)上发布信息成了一件很容易的事。它提供 ISAPI(Intranet Server API)作为扩展Web服务器功能的编程接口;同时，它还提供一个Internet数据库连接器，可以实现对数据库的查询和更新。
微软早期的IIS，就是一个纯粹的Web服务器。后来，它嵌入了ASP引擎，可以解释VBScript和JScript服务器端代码了，这时，它就可以兼作应用服务器。当然，它与J2EE应用服务器根本无法相比，但是，从功能上说，从原理上说，它勉强可以称之为应用服务器。确切地说，它是兼有一点应用服务器功能的Web服务器。
综上：Apache是纯粹的web服务器，而Tomcat和IIS因为具有了解释执行服务器端代码的能力，可以称作为轻量级应用服务器或带有服务器功能的Web服务器。Weblogic、WebSphere因为能提供强大的J2EE功能，毫无疑问是绝对的应用服务器。对于处于中间位置的Tomcat，它可以配合纯Web服务器Apache一起使用，也可以作为应用服务器的辅助与应用服务器一起部署。
应用服务器

• IBM WebSphere

WebSphere Application Server 是一种功能完善、开放的Web应用程序服务器，是IBM电子商务计划的核心部分，它是基于 Java 的应用环境，用于建立、部署和管理Internet 和 Intranet Web应用程序。这一整套产品进行了扩展，以适应Web应用程序服务器的需要，范围从简单到高级直到企业级。
WebSphere 针对以 Web 为中心的开发人员，他们都是在基本 HTTP服务器和 CGI 编程技术上成长起来的。IBM 将提供 WebSphere 产品系列，通过提供综合资源、可重复使用的组件、功能强大并易于使用的工具、以及支持 HTTP 和 IIOP 通信的可伸缩运行时环境，来帮助这些用户从简单的 Web 应用程序转移到电子商务世界。

• Oracle WebLogic

Oracle WebLogic Server 是一种多功能、基于标准的web应用服务器，为企业构建自己的应用提供了坚实的基础。各种应用开发、部署所有关键性的任务，无论是集成各种系统和数据库， 还是提交服务、跨 Internet 协作，起始点都是 Oracle WebLogic Server。由于 它具有全面的功能、对开放标准的遵从性、多层架构、支持基于组件的开发，基于 Internet 的企业都选择它来开发、部署最佳的应用。
Oracle WebLogic Server 在使应用服务器成为企业应用架构的基础方面继续处于领先地位。Oracle WebLogic Server 为构建集成化的企业级应用提供了稳固的基础，它们以 Internet 的容量和速度，在连网的企业之间共享信息、提交服务，实现协作自动化。Oracle WebLogic Server 的遵从 J2EE 、面向服务的架构，以及丰富的工具集支持，便于实现业务逻辑、数据和表达的分离，提供开发和部署各种业务驱动应用所必需的底层核心功能。
III. 理解HTTP协议
基础概念
HTTP协议是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。
HTTP协议的主要特点可概括如下：

1. 支持客户/服务器模式。
2. 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3. 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4. 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5. 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。> HTTP事务: 一次HTTP请求与HTTP响应对。HTTP事务是独立的，不存在上下文关系。

每次HTTP请求都是由两部分组成：

• 发送请求 HTTP请求报文
• 回送响应 HTTP响应报文

HTTP版本：HTTP/0.9 -- HTTP/1.0 -- HTTP/1.1 -- HTTP/2.0
HTTP/1.0：短连接
HTTP/1.1：持久连接
HTTP报文
请求报文
HTTP请求报文：由三部分组成，分别是：请求行、消息报头、请求正文
HTTP请求报文格式:
请求行 起始行(报文的第一行)  必选  对报文进行说明    文本
消息报头  (从第二行开始)     可选  报文属性         文本
[CRLF]
请求正文 (上面是一个空行) 可选  报文携带的数据    文本 二进制
请求行: 向服务器请求一个动作.
method request_URL HTTP_version
请求方法 请求URL HTTP版本号
请求方法（所有方法全为大写）有多种，各个方法的解释如下：
GET 请求获取Request-URI所标识的资源（查）
POST 在Request-URI所标识的资源后附加新的数据（改）
HEAD 请求获取由Request-URI所标识的资源的响应消息报头
PUT 请求服务器存储一个资源，并用Request-URI作为其标识（增）
DELETE 请求服务器删除Request-URI所标识的资源（删）
TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留将来使用
OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求
响应报文
HTTP响应报文也是由三个部分组成，分别是：状态行、消息报头、响应正文
状态行: 告诉浏览器请求被处理的结果怎样.
HTTP_version status_code reason_phrase
HTTP版本 状态码 原因短语
其中，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 //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
消息报头：
HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。
可以看成浏览器与服务器在通信过程中携带的指令与暗号。
给对方提供某种信息或向对方下达某种指令。
每一个报头域都是由名字+“：”+ 空格 + 值 组成，消息报头域的名字是大小写无关的。
消息报头格式:
消息报头名: 值1, 值2, 值3, ...
Accept-Encoding: gzip, deflate
消息报头的第一个字母一般大写.
消息报头的顺序无关紧要.
消息报头一行只能写一个.
消息报头类型:
1.通用消息报头：既可以在请求报文中使用也可以在响应报文中使用的消息报头.
2.请求消息报头：只能在请求报文中使用.
3.响应消息报头：只能在响应报文中使用.
4.实体消息报头：对实体主体的属性的描述.
5.扩展消息报头：不在rfc2616中定义.
通用消息报头
在通用消息报头中，有少数报头域用于所有的请求和响应消息，但并不用于被传输的实体，只用于传输的消息。
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.
Date：通用消息报头域表示消息产生的日期和时间
Connection：通用消息报头域允许发送指定连接的选项。例如指定连接是连续，或者指定“close”选项，通知服务器，在响应完成后，关闭连接
请求报头
请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。
常用的请求报头
Accept
Accept：请求报头域用于指定客户端接受哪些类型的信息。
Accept:image/gif，表明客户端希望接受GIF图象格式的资源；
Accept:text/html，表明客户端希望接受html文本。
Accept-Charset
Accept-Charset：请求报头域用于指定客户端接受的字符集。
Accept-Charset:iso-8859-1,gb2312。如果在请求消息中没有设置这个域，缺省是任何字符集都可以接受。
Accept-Encoding
Accept-Encoding：请求报头域类似于Accept，但是它是用于指定可接受的内容编码。eg：Accept-Encoding:gzip.deflate.如果请求消息中没有设置这个域服务器假定客户端对各种内容编码都可以接受。
Accept-Language
Accept-Language：请求报头域类似于Accept，但是它是用于指定一种自然语言。
Accept-Language:zh-cn.如果请求消息中没有设置这个报头域，服务器假定客户端对各种语言都可以接受。
Authorization
Authorization：请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（未授权），可以发送一个包含Authorization请求报头域的请求，要求服务器对其进行验证。
Host（发送请求时，该报头域是必需的）
Host请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的，
eg：
我们在浏览器中输入：https://www.baidu.com
浏览器发送的请求消息中，就会包含Host请求报头域，如下：
Host：www.baidu.com
此处使用缺省端口号443，若指定了端口号，则变成：Host：www.baidu.com:指定端口号
User-Agent
我们上网登陆论坛的时候，往往会看到一些欢迎信息，其中列出了你的操作系统的名称和版本，你所使用的浏览器的名称和版本，这往往让很多人感到很神奇，实际上，服务器应用程序就是从User-Agent这个请求报头域中获取到这些信息。User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它属性告诉服务器。不过，这个报头域不是必需的，如果我们自己编写一个浏览器，不使用User-Agent请求报头域，那么服务器端就无法得知我们的信息了。
请求报头举例：
GET /extGuetWeb HTTP/1.1
Host: www.guet.edu.cn
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: SERVERID=RealServer2
Connection: keep-alive
响应报头
响应报头允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。
常用的响应报头
Location
Location响应报头域用于重定向接受者到一个新的位置。Location响应报头域常用在更换域名的时候。
Server
Server响应报头域包含了服务器用来处理请求的软件信息。与User-Agent请求报头域是相对应的。下面是
Server响应报头域的一个例子：
Server:Apache-Coyote/1.1
WWW-Authenticate
WWW-Authenticate响应报头域必须被包含在401（未授权的）响应消息中，客户端收到401响应消息时候，并发送Authorization报头域请求服务器对其进行验证时，服务端响应报头就包含该报头域。
响应报头举例：
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 4.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 04 Dec 2015 10:08:41 GMT
Connection: close
Content-Length: 40919
实体报头
请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成，但并不是说实体报头域和实体正文要在一起发送，可以只发送实体报头域。实体报头定义了关于实体正文（eg：有无实体正文）和请求所标识的资源的元信息。
常用的实体报头
Content-Encoding
Content-Encoding实体报头域被用作媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容的编码，因而要获得Content-Type报头域中所引用的媒体类型，必须采用相应的解码机制。Content-Encoding这样用于记录文档的压缩方法，
Content-Encoding:gzip
Content-Language
Content-Language实体报头域描述了资源所用的自然语言。没有设置该域则认为实体内容将提供给所有的语言阅读者。
Content-Language:da
Content-Length
Content-Length实体报头域用于指明实体正文的长度，以字节方式存储的十进制数字来表示。
Content-Type
Content-Type实体报头域用语指明发送给接收者的实体正文的媒体类型。
Content-Type:text/html;charset=ISO-8859-1
Content-Type:text/html;charset=GB2312
Last-Modified
Last-Modified实体报头域用于指示资源的最后修改日期和时间。
Expires
Expires实体报头域给出响应过期的日期和时间。为了让代理服务器或浏览器在一段时间以后更新缓存中(再次访问曾访问过的页面时，直接从缓存中加载，缩短响应时间和降低服务器负载)的页面，我们可以使用Expires实体报头域指定页面过期的时间。
Expires:Thu，15 Sep 2006 16:23:12 GMT
HTTP1.1的客户端和缓存必须将其他非法的日期格式（包括0）看作已经过期。为了让浏览器不要缓存页面，我们也可以利用Expires实体报头域，设置为0。
用telnet模拟发送HTTP请求.
telnet domain/IP port
打开本地回显: ctrl + ]
POST/GET请求
GET请求:
GET方式：是以实体的方式得到由请求URI所指定资源的信息，如果请求URI只是一个数据产生过程，那么最终要在响应实体中返回的是处理过程的结果所指向的资源，而不是处理过程的描述。
GET request_URL HTTP_version
[Host: domain:port]
Header1: v1, v2,...
Header2: v1, v2,...
CRLF
POST请求:
用来向目的服务器发出请求，要求它接受被附在请求后的实体，并把它当作请求队列中请求URI所指定资源的附加新子项，Post被设计成用统一的方法实现下列功能：
1：对现有资源的解释；
2：向电子公告栏、新闻组、邮件列表或类似讨论组发信息；
3：提交数据块；
4：通过附加操作来扩展数据库 。
从上面描述可以看出，Get是向服务器发索取数据的一种请求；而Post是向服务器提交数据的一种请求，要提交的数据位于信息头后面的实体中。
POST request_URL HTTP_version
[Host: domain:port]
Header1: v1, v2,...
Header2: v1, v2,...
Content-Type: type/sub_type
Content-Length: size
CRLF
p1=v1&p2=v2&...
GET与POST发送请求的区别?

1. 参数附件的位置不同

POST: 将参数附加到请求报文的实体主体之中。p1=v1&p2=v2&...&pn=vn
GET: 将参数附加到请求报文的请求行的请求URL之后。GET URL?p1=v1&p2=v2&...&pn=vn

2. 发送数据的大小限制不同

POST: HTTP协议没有对实体主体的大小进行控制，一般可以看作无限制。应用程序可以控制发送数据的大小。
GET: HTTP协议本身没有对请求行的长度进行控制，但是浏览器和操作系统对其进行了控制。一般不能发送很大的数据.

3. 从安全性的角度考虑

GET请求不会修改服务器上的数据，仅仅用于获取服务器的文档，相对更安全。但是GET附件的参数会显示在URL中，这点不安全。

4. 从收藏页面的角度考虑

GET请求可以将请求参数与请求URL一起保存，有利于收藏.
CURL工具
Cookie/Session
Session 与 Cookie 的作用都是为了保持访问用户与后端服务器的交互状态。它们有各自的优点，也有各自的缺陷，然而具有讽刺意味的是它们的优点和它们的使用场景又是矛盾的。例如，使用 Cookie 来传递信息时，随着 Cookie 个数的增多和访问量的增加，它占用的网络带宽也很大，试想假如 Cookie 占用 200 个字节，如果一天的 PV 有几亿，它要占用多少带宽？所以有大访问量的时候希望用 Session，但是 Session 的致命弱点是不容易在多台服务器之间共享，所以这也限制了 Session 的使用。
理解 Cookie
Cookie 的作用我想大家都知道，通俗地说就是当一个用户通过 HTTP 协议访问一个服务器的时候，这个服务器会将一些 Key/Value 键值对返回给客户端浏览器，并给这些数据加上一些限制条件，在条件符合时这个用户下次访问这个服务器的时候，数据又被完整地带回给服务器。
这个作用就像您去超市购物时，第一次给您办张购物卡，这个购物卡里存放了一些您的个人信息，下次您再来这个连锁超市时，超市会识别您的购物卡，下次直接购物就好了。
当初 W3C 在设计 Cookie 时实际上考虑的是为了记录用户在一段时间内访问 Web 应用的行为路径。由于 HTTP 协议是一种无状态协议，当用户的一次访问请求结束后，后端服务器就无法知道下一次来访问的还是不是上次访问的用户，在设计应用程序时，我们很容易想到两次访问是同一人访问与不同的两个人访问对程序设计和性能来说有很大的不同。例如，在一个很短的时间内，如果与用户相关的数据被频繁访问，可以针对这个数据做缓存，这样可以大大提高数据的访问性能。Cookie 的作用正是在此，由于是同一个客户端发出的请求，每次发出的请求都会带有第一次访问时服务端设置的信息，这样服务端就可以根据 Cookie 值来划分访问的用户了。
理解 Session
前面已经介绍了 Cookie 可以让服务端程序跟踪每个客户端的访问，但是每次客户端的访问都必须传回这些 Cookie，如果 Cookie 很多，这无形地增加了客户端与服务端的数据传输量，而 Session 的出现正是为了解决这个问题。
同一个客户端每次和服务端交互时，不需要每次都传回所有的 Cookie 值，而是只要传回一个 ID，这个 ID 是客户端第一次访问服务器的时候生成的，而且每个客户端是唯一的。这样每个客户端就有了一个唯一的 ID，客户端只要传回这个 ID 就行了，这个 ID 通常是 NANE 为 JSESIONID 的一个 Cookie。
Session 与 Cookie
虽然 Cookie 和 Session 都可以跟踪客户端的访问记录，但是它们的工作方式显然是不同的，Cookie 通过把所有要保存的数据通过 HTTP 协议的头部从客户端传递到服务端，又从服务端再传回到客户端，所有的数据都存储在客户端的浏览器里，所以这些 Cookie 数据可以被访问到，就像我们前面通过 Firefox 的插件 HttpFox 可以看到所有的 Cookie 值。不仅可以查看 Cookie，甚至可以通过 Firecookie 插件添加、修改 Cookie，所以 Cookie 的安全性受到了很大的挑战。
相比较而言 Session 的安全性要高很多，因为 Session 是将数据保存在服务端，只是通过 Cookie 传递一个 SessionID 而已，所以 Session 更适合存储用户隐私和重要的数据。