‘壹’ WEB请求处理之浏览器响应
当我们使用浏览器进行浏览操作的时候，会产生一系列的数据请求。现在浏览器和服务器之间的数据交互是基于B/S架构的，而这种架构是建立在HTTP请求的基础上的，当我们在浏览器的地址栏中输入一个网页的地址后，会触发一些列事件，如下图所示:
以上就是我们访问网页时会触发的一系列事件,也是web请求处理的基本流程，接下来对几个概念详细介绍.
TCP协议是OSI七层协议中传输层的一项协议,它是一种面向连接的可靠交付的数据传输协议，和UDP用户数据报协议不同的是，它需要建立连接，并且需要无差错和可靠地交付数据。通过TCP建立连接，需要经过三次握手，关闭TCP连接需要四次挥手。
OSI七层模型中TCP处于的层级位置如图所示
TCP建立连接是为了可靠地传输数据，因此建立过程比较复杂，以确保可靠地传输数据。具体流程如下图所示:
TCP四次挥手
当数据传输成功后需要关闭连接，这就是TCP四次挥手。四次挥手比握手还要复杂，具体流程如下图所示:
在这个过程中，为什么会涉及到四次挥手呢，这是因为在客户端发送主动关闭连接请求时，服务器端收到关闭请求并返回确认收到请求报文，但是服务器不会立即关闭，因为在这个时间段内可能还会有数据传送，服务器端会继续传送数据给客户端，当没有数据传送时，服务器端会主动发送报文给客户端请求关闭,等待客户端返回确认时服务器端就进入了close状态。
从上面的OSI七层模型中我们可以看到HTTP处于七层协议中的应用层，也就是最接近用户的一层。它主要是处理WEB数据请求，它是无状态无连接的协议。无状态是指上一次传送的数据是没有存储下来的，下一次操作获取不到上次的数据。无连接是指需要请求数据时才会建立连接，否则处于无连接状态。在WtEB请求处理过程中，我们主要是关心HTTP请求头和响应头还有就是状态码.
下面是使用FIDDLER抓包工具抓取的请求包
CONNECT www..com:443 HTTP/1.1
Host: www..com:443
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36
人们习惯记忆域名，但机器间互相只认IP地址，域名与IP地址之间是多对多的关系，一个ip地址不一定只对应一个域名，且一个域名可以对应多个ip地址，它们之间的转换工作称为域名解析，域名解析需要由专门的域名解析服务器来完成，整个过程是自动进行的。
由于DNS域名解析有些复杂，本文章就不就过多的讲解。
总结：以上就是web请求处理中浏览器响应的相关知识，由于涉及到的 知识太多因此没哟很详细的将解，只将解了部分的重要内容，待到以后学习加深，进一步完善。
‘贰’ Web响应时间很长
错别字太多
Web响应时间很长无非几个方面的问题：
1.主机硬件低配而装了高配操作系统，比如win7,小马拉大车喽
一般属这种情况的话，运行大多软件都会慢，如果运行别的软件不慢，仅是web慢，skip这一条，看第三条.（新买的东芝笔记本电脑，估计配置应该还不错吧，可以看下一条了）
2.主机内软件安装的不合适，比如中病毒了、或者是安了几套杀毒软件（同时安装)等等原因，系统CPU被这些软件过度占用，如果这样，杀毒、卸载不必要的软件。
比如360，就建议停用一下，看看是否响应速度会变快。
3.如果前两条都不符合，则问题集中在web方面，
3.1所访问的具体某个网站慢，判断很容易，看看访问别的web速度快不快，如果有快有慢，那问题可以结题了。如果都慢，请看下一条。
3.2检查下DNS设置的是否合适，建议选用与你上网线路较近的DNS
‘叁’ http请求和响应
当浏览器向Web服务器发出请求时，它向服务器传递了一个数据块，也就是请求信息，HTTP请求信息由3部分组成：
l 请求方法URI协议/版本
l 请求头(Request Header)
l 请求正文
下面是一个HTTP请求的例子：
GET/sample.jspHTTP/1.1
Accept:image/gif.image/jpeg,*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=jinqiao&password=1234
（1）请求方法URI协议/版本
请求的第一行是“方法URL议/版本”：GET/sample.jsp HTTP/1.1
以上代码中“GET”代表请求方法，“/sample.jsp”表示URI，“HTTP/1.1代表协议和协议的版本。
根据HTTP标准，HTTP请求可以使用多种请求方法。例如：HTTP1.1目前支持7种请求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。
GET 请求获取由Request-URI所标识的资源。
POST 在Request-URI所标识的资源后附加新的数据。
HEAD 请求获取由Request-URI所标识的资源的响应消息报头。
OPTIONS 请求查询服务器的性能，或查询与资源相关的选项和需求。
PUT 请求服务器存储一个资源，并用Request-URI作为其标识。
DELETE 请求服务器删除由Request-URI所标识的资源。
TRACE 请求服务器回送收到的请求信息，主要用语测试或诊断。
在Internet应用中，最常用的方法是GET和POST。
URI完整地指定了要访问的网络资源，通常只要给出相对于服务器的根目录的相对目录即可，因此总是以“/”开头，最后，协议版本声明了通信过程中使用HTTP的版本。
‘肆’ 如何定位Web应用响应慢原因
运用听云Server解决Web应用过程响应慢，并且定位到具体代码，我们首先登陆听云Server控制台，点击需要查看的应用，进入Web应用过程模块。（听云Server中Web应用过程指：应用程序中处理一次独立的Web访问请求的过程，完整的web应用过程是从应用程序收到请求到响应的整个过程）
Web应用过程功能模块是将当前应用以Web应用过程的维度来展示详细的应用性能数据，包括以下几个功能：
“Web应用过程一览”列出当前应用所有的Web应用过程，并且可以按照耗时百分比、响应时间、吞吐率、Apdex、错误率进行排序。
“TOP5最耗时Web应用过程堆叠图”展示了耗时百分比最大的前5个Web应用过程其墙钟时间比在选定时间内的变化趋势。（墙钟时间比指的是Web应用过程在图表横坐标粒时间度下的总耗时时间/图表横坐标粒度时间）
“Web应用过程响应时间与吞吐率图”展示了应用的平均响应时间和每分钟请求次数在选定时间内的变化趋势。当请求的响应时间大于设定的阈值时会被显示在慢应用追踪列表中。（可在设置中对Web过程跟踪阈值进行设定，例如设置为500毫秒，那么所有响应时间大于500毫秒的请求都会被显示在慢应用过程追踪列表中，具体值根据自己的需求设置即可）
对于Web应用过程响应慢，我们选择按照“响应时间”进行排序，响应时间由长到短排列，选择时间较长的优先进行解决。
点击该Web应用过程进行数据钻取，查看其详细的性能分解。可以看到Web应用过程性能分解堆叠图，显示了这个Web应用过程中各个组件在选定时间内的平均响应时间的变化趋势。
“性能分解表格”展示了其中各个组件的详细性能信息，包括的信息有代码段、性能分类、耗时百分比、调用次数、平均响应时间，排列顺序是按照平均响应时间由长到短进行排序的。
“响应时间和吞吐率图”展示了该Web应用过程在选定时间内平均响应时间和每分钟请求次数的变化趋势。
“慢应用追踪列表”显示了该应用下响应时间大于设定阈值的请求，同样还是按照响应时间由长到短进行排序。
点击其中响应时间较长的请求进行慢应用追踪，跳转至应用过程慢追踪页面。
摘要中可以看到各个组件的响应耗时百分比图，下面还列出了各个最慢组件详细的调用次数、持续时间、响应耗时占比数据。
接下来重点查看追踪详情，可以看到各个代码段的持续时间、时间占比和时间偏移量，其中持续时间长时间占比高的就是响应时间长的代码段，则需要对该代码段进行重点的优化和修改，从而解决Web应用过程响应慢的问题。
后面的相关SQL展示了其中的SQL操作以及其调用次数和总耗时。
拓补图展示了相关的调用关系方便更加全面的分析问题，特别说明的是只有发生跨应用调用的应用过程慢追踪才会展示拓补图。