WEB 页面解析的总体流程
客户端(浏览器)发起页面请求,主机对 地址中的DNS 域名进行解析,找到对应的 IP 地址,请求发送到 服务端,服务器根据请求内容发送响应给客户端,客户端收到响应,将内容渲染成网页。
1、域名解析的过程
1.1、名词解释
(1) 域名:网络是基于TCP/IP协议进行通信和连接的,每一台主机都有唯一且固定的IP地址,从而区分因特网上数量庞大的主机。IP地址是数字型的,数字较多不方便记忆,于是人们又发明了域名地址,采用字符型结构。域名地址是域的自然语言名称,它与数字式IP地址存在一一对应的关系。IP地址如同电脑的身份证号码,而域名地址则相当于电脑的姓名,方便人们记忆和使用。域名一般由两个或两个以上的词构成,中间用“.”进行分隔,其结构是:四级域名.三级域名.二级域名.一级域名。
(2) DNS:域名系统(英语:Domain Name System,缩写:DNS)是互联网的一项服务。它作为将域名和IP地址相互映射的一个分布式数据库,能够使人更方便地访问互联网。DNS使用TCP和UDP端口53。当前,对于每一级域名长度的限制是63个字符,域名总长度则不能超过253个字符。
DNS 服务器的分层结构
DNS 服务器采用分布式、分层的方式部署在世界各地。按照层级从高到低,DNS 服务器分为:根域名服务器
(Root DNS Servers)、顶级域名服务器
(TLD DNS Servers)、权威域名服务器
(Authoritative DNS Servers),层级关系如下图:
根域名服务器
:世界上有 13 个根域名服务器
,准确来说是 13 组服务器群组,服务器组中的每一个根域名服务器
都有所有顶级域名服务器
(com, org, gov …)的 IP 地址。顶级域名服务器
:为顶级域名如 com、org、net 等提供域名解析服务,每一个顶级域名都有相应的顶级域名服务器
,存放其所有子域名的 IP 地址。权威域名服务器
:各种组织机构,如企业、学校、政府组织等都需为其提供网络服务的主机取一个合适的域名,如 百度公司的 baidu.com,而主机的 IP 地址和域名的对应关系就保存至其权威域名服务器
中。一般大公司和学校都会部署自己的权威域名服务器
。
(3) 域名解析:即域名到IP地址的转换过程。域名的解析工作由DNS服务器完成。DNS查询有两种方式:递归和迭代。DNS客户端设置使用的DNS服务器一般都是递归服务器,它负责全权处理客户端的DNS查询请求,直到返回最终结果。而DNS服务器之间一般采用迭代查询方式。
递归查询:本机向本地域名服务器发出一次查询请求,就静待最终的结果。如果本地域名服务器无法解析,自己会以DNS客户机的身份向其它域名服务器查询,直到得到最终的IP地址告诉本机。
迭代查询:本地域名服务器向根域名服务器查询,根域名服务器告诉它下一步到哪里去查询,然后它再去查,每次它都是以客户机的身份去各个服务器查询。
1.2、流程介绍
(1) 浏览器输入域名之后,首先会检查浏览器缓存中是否缓存过该域名对应的IP地址
用户通过浏览器浏览过某网站之后,浏览器就会自动缓存该网站域名对应的地址,当用户再次访问的时候,浏览器就会从缓存中查找该域名对应的IP地址,因为缓存不仅是有大小限制,而且还有时间限制(域名被缓存的时间通过属性来设置),所以存在域名对应的找不到的情况。当浏览器从缓存中找到了该网站域名对应的地址,那么整个解析过程结束,如果没有找到,将进行下一步骤。对于的缓存时间问题,不宜设置太长的缓存时间,时间太长,如果域名对应的发生变化,那么用户将在一段时间内无法正常访问到网站,如果太短,那么又造成频繁解析域名。
(2) 如果在浏览器缓存中没有找到IP,那么将继续查找本机系统是否缓存过IP
如果第一个步骤没有完成对域名的解析过程,那么浏览器会去系统缓存中查找系统是否缓存过这个域名对应的地址。其实操作系统也有一个域名解析的过程,通过hosts文件设置,用户可以将任何域名解析到任何能够访问的IP地址。正是因为有这种本地DNS解析的规程,所以有黑客就可能通过修改用户的域名来把特定的域名解析到他指定的IP地址上,导致这些域名被劫持。
(3) 向本地域名解析服务系统发起域名解析的请求
以上两步的解析是在本机上完成的,如果本机无法解析域名,那么系统只能请求本地域名解析服务系统进行解析,本地域名系统一般都是本地区的域名服务器,比如你连接的校园网,那么域名解析系统就在你的校园机房里,如果你连接的是电信、移动或者联通的网络,那么本地域名解析服务器就在本地区,由各自的运营商来提供服务。对于本地域名解析服务器,一般都缓存了地区内部域名解析请求的结果,如果缓存命中则返回相应的结果,当然缓存时间也受域名失效时间控制。大约80%的域名解析到这里就结束了,所以本地域名解析系统主要承担了域名的解析工作。
(4) 向根域名解析服务器发起域名解析请求
如果本地域名解析系统的缓存中没有所需要查找到域名,则将会向根域名服务器发起解析请求。
(5) 根域名服务器返回给本地域名服务器一个所查询的主域名服务器(gTLD Server)地址
根域名是不负责解析域名的,它只负责管理所有的顶级域名。比如:你要解析的网址是:www.xxx.com,根域名服务器是不知道这个域名的IP地址的,但是它知道这个IP在它管理的.com
域名下,根域名服务器会向请求方发送.com
域名服务器的地址,引导请求方继续查询。
(6) 本地域名服务器LDNS再向上一步返回的gTLD服务器发送请求
因为域名服务器之间会有大量的数据需要处理,所以DNS服务器之间一般采用迭代查询方式。本地域名解析服务器向gTLD服务器发起请求。
(7) gTLD服务器接收请求并返回Name Server服务器
指定的域名由指定的Name Server服务器进行解析。
(8) Name Server服务器返回IP地址给本地服务器
服务器查找域名对应的地址,将地址连同值返回给本地域名服务器。
(9) 本地域名服务器缓存解析结果
本地域名服务器缓存解析后的结果,缓存时间由TTL值控制。
(10) 返回解析结果给用户
解析结果将直接返回给用户,用户系统将缓存该地址,用户根据TTL值缓存在本地系统缓存中,域名解析过程结束。
1.3、域名解析记录
-
A(Address)记录:用来指定主机名(或域名)对应的IP地址记录。
-
CNAME(别名)记录:即别名记录。这种记录允许您将多个名字映射到另外一个域名。通常用于同时提供WWW和MAIL服务的计算机。例如,有一台计算机名为“host.mydomain.com”(A记录)。它同时提供WWW和MAIL服务,为了便于用户访问服务。可以为该计算机设置两个别名(CNAME):WWW和MAIL。这两个别名的全称就 http://www.mydomain.com/和“mail.mydomain.com”。实际上他们都指向 “host.mydomain.com”。
-
MX 记录: 邮件交换记录。它指向⼀个邮件服务器,⽤于电⼦邮件系统发邮
件时根据 收信⼈的地址后缀来定位邮件服务器。如:用户所用的邮件是以域名mydomain.com为结尾的,则需要在管理界面中添加该域名的MX记录来处理所有以@mydomain.com结尾的邮件。 -
NS(Name Server)记录:解析服务器记录。⽤来表明由哪台服务器对该域名进⾏解析。这⾥的NS
记录只对⼦域名⽣效。例如用户希望由12.34.56.78这台服务器解析news.mydomain.com,则需要设置news.mydomain.com的NS记录。 -
TXT记录:⼀般指为某个主机名或域名设置的说明
2、web 页面请求的流程
2.1、Web中间件
2.1.1、Nginx
Nginx 性能稳定、功能丰富、运维简单、处理静态文件速度快且消耗系统资源极少。
1、相比 Apache,用 Nginx 作为 Web 服务器:使用资源更少,支持更多并发连接,效率更高。
2、作为负载均衡服务器:Nginx 既可在内部直接支持 Rails 和 PHP,也可支持作为 HTTP 代理服务器对外进行服务。Nginx 用 C 编写而成, 不论是系统资源开销还是 CPU 使用效率都比 Perlbal 要好的多。
3、作为邮件代理服务器:Nginx 同时也是一款非常优秀的邮件代理服务器(最早开发这个产品的目的之一,是作为邮件代理服务器)。
4、反向代理可以根据url将请求转向于不同用途的集群,比如图片请求,转向图片服务器集群;视频请求,转身视频服务器集群。
nginx是一款轻量级的web服务器/反向代理服务器/电子邮件代理服务器,安装非常简单,配置文件也很简洁(还支持 perl 语法)。Nginx 支持平滑加载新配置,还能够在不间断服务的情况下进行软件版本升级。
#代理
在Java设计模式中,代理模式是这样定义的:给某个对象提供一个代理对象,并由代理对象控制原对象的引用。
可能大家不太明白这句话,在举一个现实生活中的例子:比如我们要买一间二手房,虽然我们可以自己去找房源,但是这太花费时间精力了,而且房屋质量检测以及房屋过户等一系列手续也都得我们去办,再说现在这个社会,等我们找到房源,说不定房子都已经涨价了,那么怎么办呢?最简单快捷的方法就是找二手房中介公司(为什么?别人那里房源多啊),于是我们就委托中介公司来给我找合适的房子,以及后续的质量检测过户等操作,我们只需要选好自己想要的房子,然后交钱就行了。
代理简单来说,就是如果我们想做什么,但又不想直接去做,那么这时候就找另外一个人帮我们去做。那么这个例子里面的中介公司就是给我们做代理服务的,我们委托中介公司帮我们找房子。
- 正向代理
弄清楚什么是代理了,那么什么又是正向代理呢?
这里我再举一个例子:大家都知道,现在国内是访问不了 Google的,那么怎么才能访问 Google呢?我们又想,美国人不是能访问 Google吗(这不废话,Google就是美国的),如果我们电脑的对外公网 IP 地址能变成美国的 IP 地址,那不就可以访问 Google了。你很聪明,VPN 就是这样产生的。我们在访问 Google 时,先连上 VPN 服务器将我们的 IP 地址变成美国的 IP 地址,然后就可以顺利的访问了。
这里的 VPN 就是做正向代理的。正向代理服务器位于客户端和服务器之间,为了向服务器获取数据,客户端要向代理服务器发送一个请求,并指定目标服务器,代理服务器将目标服务器返回的数据转交给客户端。这里客户端是要进行一些正向代理的设置的。
- 反向代理
反向代理和正向代理的区别就是:正向代理代理客户端,反向代理代理服务器。
反向代理,其实客户端对代理是无感知的,因为客户端不需要任何配置就可以访问,我们只需要将请求发送到反向代理服务器,由反向代理服务器去选择目标服务器获取数据后,在返回给客户端,此时反向代理服务器和目标服务器对外就是一个服务器,暴露的是代理服务器地址,隐藏了真实服务器IP地址。
下面我们通过两张图来对比正向代理和方向代理:
理解这两种代理的关键在于代理服务器所代理的对象是什么,正向代理代理的是客户端,我们需要在客户端进行一些代理的设置。而反向代理代理的是服务器,作为客户端的我们是无法感知到服务器的真实存在的。
2.1.2、Apache
1、Apache 是 LAMP 架构最核心的 Web Server,开源、稳定、模块丰富是 Apache 的优势。但 Apache 的缺点是有些臃肿,内存和 CPU 开销大,性能上有损耗,不如一些轻量级的 Web 服务器(譬如:Nginx、Tengine等)高效,轻量级的 Web 服务器对于静态文件的响应能力来说远高于 Apache 服务器。
2、Apache 做为 Web Server 是负载 PHP 的最佳选择,如果流量很大的话,可以采用 Nginx 来负载非 PHP 的 Web 请求。Nginx 是一个高性能的 HTTP 和反向代理服务器,Nginx 以其稳定、丰富功能集、示例配置文件和低系统资源的消耗而闻名。Nginx 现能支持 PHP 和 FastCGI,也支持负载均衡和容错,可和 Apache 配合使用,是轻量级的 HTTP 服务器的首选。
3、Web 服务器缓存也有多种方案,Apache 提供了自己的缓存模块,也可以使用外加的 Squid 模块进行缓存,这两种方式均可有效提高 Apache 的访问响应能力。Squid Cache 是一个 Web 缓存服务器,支持高效缓存,可作为网页服务器的前置 cache 服务器缓存相关请求以提高 Web 服务器速度。把 Squid 放在 Apache 的前端来缓存 Web 服务器生成动态内容,而 Web 应用程序只需要适当地设置页面实效时间即可。如访问量巨大,则可考虑使用 memcache 作为分布式缓存。
4、PHP 的加速可使用 eAccelerator 加速器,eAccelerator 是一个自由开放源码的 PHP 加速器。它会优化动态内容缓存,提高 PHP 脚本缓存性能,使 PHP 脚本在编译状态下,对服务器的开销几乎完全消除。它还可对脚本起优化作用,以加快其执行效率。 使 PHP 程序代码执效率可提高 1-10 倍。
2.1.3、IIS
IIS是Internet Information Services的缩写,意为互联网信息服务,是由微软公司提供的基于 运行Microsoft Windows的互联网基本服务。 最初是Windows NT版本的可选包,随后内置在Windows 2000、Windows XP Professional和 Windows Server 2003一起发行,但在Windows XP Home版本上并没有IIS。 IIS是一种Web(网页)服务组件,其中包括Web服务器、FTP服务器、NNTP服务器和SMTP服务器, 分别用于网页浏览、文件传输、新闻服务和邮件发送等方面,它使得在网络(包括互联网和局域网) 上发布信息成了一件很容易的事。 IIS最经典的版本是IIS6.0,最常见于Windows Server 2003系统中;IIS7.0则常见于 Windows Server 2008中。 目前(2017年)最新的版本是IIS10.0,常见于Windows Server 2016中。
2.1.4、Tomcat
Tomcat(Apache Tomcat)是Apache 软件基金会(Apache Software Foundation)的Jakarta 项目中的一个核心项目,由Apache、Sun和其他公司及个人共同开发而成。
Tomcat 服务器是一个免费的开放源代码的Web 应用服务器,属于轻量级应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用,是开发和调试JSP 程序的首选。
对于一个初学者来说,可以这样认为,当在一台机器上配置好Apache 服务器,可利用它响应HTML(标准通用标记语言下的一个应用)页面的访问请求。
实际上Tomcat是Apache 服务器的扩展,但运行时它是独立运行的,所以当你运行tomcat 时,它实际上作为一个与Apache 独立的进程单独运行的。
当配置正确时,Apache 为HTML页面服务,而Tomcat 实际上运行JSP 页面和Servlet。另外,Tomcat和IIS等Web服务器一样,具有处理HTML页面的功能。
另外它还是一个Servlet和JSP容器,独立的Servlet容器是Tomcat的默认模式。不过,Tomcat处理静态HTML的能力不如Apache服务器。
2.2、Nginx的请求处理阶段
Nginx 处理请求的过程一共划分为 11 个阶段,按照执行顺序依次是 post-read、server-rewrite、find-config、rewrite、post-rewrite、preaccess、access、post-access、try-files、content 以及 log。
POST_READ
读取HTTP头部,读取并解析内容
server-rewrite
在URL与location匹配之前修改请求的URL(重定向),在server块中的请求地址重写
find-config
配置查找阶段,根据请求的URL匹配location表达式;不支持nginx模块注册处理程序,而是由ngx_http_core_module模块来完成当前请求与location配置之间的匹配
rewrite
location块追踪的请求地址重写阶段,当rewrite指令用于location中则运行;ngx_lua模块中的set_by_lua指令和rewrite_by_lua指令也在这里
post-rewrite
请求地址重写提交阶段,防止递归修改URL造成死循环;由ngx_http_core_module模块实现
preaccess
访问权限检查准备阶段,http模块进入处理阶段,ngx_limit_req(访问控制的频率)和ngx_limit_zone(访问的并发率控制)也会运行
access
访问权限检查执行阶段,ngx_access和nginx_auth_request,ngx_lua的access-by_lua执行在这个阶段,配置指令多是执行访问控制性质的任务,比如检查用户的访问权限,检查用户的IP地址合法性
post-access
访问权限检查提交阶段,如果请求不被允许访问Nginx服务器,该阶段用于返回错误的响应
try-files
配置项try-files处理阶段,如果http访问的静态文件try-files配置项可以使这个请求顺序地访问多个静态文件,直至符合条件
content
内容产生阶段,大部分HTTP模块会执行,所有请求处理阶段中的重要阶段这个阶段的指令通常用来生成HTTP响应的内容
log
日志模块处理阶段,记录日志
2.3、Apache的请求处理阶段
1、Post-Read-Request阶段: 在正常请求处理流程中,这是模块可以插入钩子的第一个阶段。对于那些想很早进入处理请求的模块来说,这个阶段可以被利用。
2、URI Translation阶段 : Apache在本阶段的主要工作:将请求的URL映射到本地文件系统。模块可以在这阶段插入钩子,执行自己的映射逻辑。mod_alias就是利用这个阶段工作的。
3、Header Parsing阶段 : Apache在本阶段的主要工作:检查请求的头部。由于模块可以在请求处理流程的任何一个点上执行检查请求头部的任务,因此这个钩子很少被使用。mod_setenvif就是利用这个阶段工作的。
4、Access Control阶段 : Apache在本阶段的主要工作:根据配置文件检查是否允许访问请求的资源。Apache的标准逻辑实现了允许和拒绝指令。mod_authz_host就是利用这个阶段工作的。
5、Authentication阶段 : Apache在本阶段的主要工作:按照配置文件设定的策略对用户进行认证,并设定用户名区域。模块可以在这阶段插入钩子,实现一个认证方法。
6、Authorization阶段 : Apache在本阶段的主要工作:根据配置文件检查是否允许认证过的用户执行请求的操作。模块可以在这阶段插入钩子,实现一个用户权限管理的方法。
7、MIME Type Checking阶段 : Apache在本阶段的主要工作:根据请求资源的MIME类型的相关规则,判定将要使用的内容处理函数。标准模块mod_negotiation和mod_mime实现了这个钩子。
8、FixUp阶段 : 这是一个通用的阶段,允许模块在内容生成器之前,运行任何必要的处理流程。和Post_Read_Request类似,这是一个能够捕获任何信息的钩子,也是最常使用的钩子。
9、Response阶段 : Apache在本阶段的主要工作:生成返回客户端的内容,负责给客户端发送一个恰当的回复。这个阶段是整个处理流程的核心部分。
10、Logging阶段 : Apache在本阶段的主要工作:在回复已经发送给客户端之后记录事务。模块可能修改或者替换Apache的标准日志记录。
11、CleanUp阶段 : Apache在本阶段的主要工作:清理本次请求事务处理完成之后遗留的环境,比如文件、目录的处理或者Socket的关闭等等,这是Apache一次请求处理的最后一个阶段。
3、HTTP协议
HTTP (HyperText Transfer Protocal,超文本传输协议) 是应用层协议,使用 TCP 协议进行数据传输,常用端口号为 80,用于实现 Web 客户端 和 Web 服务器之间的通信。HTTP 协议规定了客户端和服务端之间通信的报文格式以及数据交换的流程。
HTTP是一种无状态协议,与WEB浏览器之间不会建立永久连接;当服务器返回响应后,就会关闭与服务器之间的连接,只有在重新发起请求的时候才会重新建立连接(服务器不主动连接,连接由客户端发起)
计算机主要通过浏览器的URL进行HTTP请求发送。
3.1、URL
URL(Uniform Resource Locator),即统一资源定位符,是专为标识Internet网上资源位置而设置的一种编址方式,我们平时所说的网页地址指的即是URL。互联网上的每个文件都有一个唯一的URL,它包含的信息指出文件的位置以及浏览器应该怎么处理它。
协议://用户名:密码@子域名.域名.顶级域名(服务器IP):端口号/目录/文件名.文件后缀?参数=值
在linux中可以使用curl
命令发送HTTP请求:
#访问HTTP响应数据
curl http://www.baidu.com
#回显HTTP响应头部数据
curl http://www.baidu.com -I
从curl
命令的结果,可以认为浏览器的作用是渲染HTTP响应信息包
3.2、HTTP协议的结构
HTTP报文由客户机到服务器的请求和从服务器到客户机的相应构成。
① 请求报文的组成:
请求行 + 信息头 + 请求头 + 实体头 + 报文主体
请求行的格式如下:
Method [分隔符] Request - URL [分隔符] HTTP-Version CRLF
解释说明:
(1)Method 表示完成Request - URL的方法,该字段是大小写敏感的,据RFC2616标准(现行的HTTP/1.1)得知,通常有以下8种方法:
方法 | 描述 |
---|---|
HEAD | HEAD方法跟GET方法相同,只不过服务器响应时不会返回消息体 |
PUT | 把消息本体中的消息发送到一个URL,跟POST类似 |
TRACE | 是用来调用一个远程的请求信息应用程序层的循环后退 |
CONNECT | HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。 |
DELETE | 请求服务器删除Request-URI所标识的资源 |
GET | 由客户端请求服务端获取Request-URI所标识的资源的方法 |
POST | 由客户端向服务端提交Request-URI所标识的资源后附加新的数据 |
OPTIONS | 请求获得由Request-URI标识的资源在请求/响应的通信过程中可以使用的功能选项 |
(2)[分隔符]为空格
(3)Request - URL: 遵循URL格式,此字段为星号(*)时,说明请求并不用于某个特定的资源地址,而是用于服务本身。
(4)HTTP-Version:表示支持的HTTP版本,如HTTP/1.1
(5)CRLF:表示换行回车符
HTTP的头包括通用的信息头、请求头、响应头、实体头4部分,每个头域由一个域名、冒号和值域3部分组成。域名是大小写无关的;域值前可以添加任何数量的空格,每个HTTP请求可以包含多个HTTP头域。
HTTP报文主体则包含了HTTP请求的内容,对于get方法,报文主体为空,对于post方法,报文主体则包含需要发送给服务器的数据。
② 响应报文的组成:
状态行 + 信息头 + 响应头 + 实体头 + 报文主体
解释说明:
(1)状态行由状态码和原因分析两部分组成,其中,状态码由3位数字组成,表示请求是否被理解或被满足,用来支持自动操作;原因分析是对原文的状态码作简单的描述,用于供用户使用。
③HTTP状态码
分类 | 分类描述 |
---|---|
1** | 信息,服务器收到请求,需要请求者继续执行操作 |
2** | 成功,操作被成功接收并处理 |
3** | 重定向,需要进一步的操作以完成请求 |
4** | 客户端错误,请求包含语法错误或无法完成请求 |
5** | 服务器错误,服务器在处理请求的过程中发生了错误 |
HTTP状态码列表
状态码 | 状态码英文名称 | 中文描述 |
---|---|---|
100 | Continue | 继续。客户端应继续其请求 |
101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议,例如,切换到HTTP的新版本协议 |
200 | OK | 请求成功。一般用于GET与POST请求 |
201 | Created | 已创建。成功请求并创建了新的资源 |
202 | Accepted | 已接受。已经接受请求,但未处理完成 |
203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器,而是一个副本 |
204 | No Content | 无内容。服务器成功处理,但未返回内容。在未更新网页的情况下,可确保浏览器继续显示当前文档 |
205 | Reset Content | 重置内容。服务器处理成功,用户终端(例如:浏览器)应重置文档视图。可通过此返回码清除浏览器的表单域 |
206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
300 | Multiple Choices | 多种选择。请求的资源可包括多个位置,相应可返回一个资源特征与地址的列表用于用户终端(例如:浏览器)选择 |
301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URI,返回信息会包括新的URI,浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
304 | Not Modified | 未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
306 | Unused | 已经被废弃的HTTP状态码 |
307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
400 | Bad Request | 客户端请求的语法错误,服务器无法理解 |
401 | Unauthorized | 请求要求用户的身份认证 |
402 | Payment Required | 保留,将来使用 |
403 | Forbidden | 服务器理解请求客户端的请求,但是拒绝执行此请求 |
404 | Not Found | 服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
405 | Method Not Allowed | 客户端请求中的方法被禁止 |
406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
407 | Proxy Authentication Required | 请求要求代理的身份认证,与401类似,但请求者应当使用代理进行授权 |
408 | Request Time-out | 服务器等待客户端发送的请求时间过长,超时 |
409 | Conflict | 服务器完成客户端的 PUT 请求时可能返回此代码,服务器处理请求时发生了冲突 |
410 | Gone | 客户端请求的资源已经不存在。410不同于404,如果资源以前有现在被永久删除了可使用410代码,网站设计人员可通过301代码指定资源的新位置 |
411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 |
412 | Precondition Failed | 客户端请求信息的先决条件错误 |
413 | Request Entity Too Large | 由于请求的实体过大,服务器无法处理,因此拒绝请求。为防止客户端的连续请求,服务器可能会关闭连接。如果只是服务器暂时无法处理,则会包含一个Retry-After的响应信息 |
414 | Request-URI Too Large | 请求的URI过长(URI通常为网址),服务器无法处理 |
415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
416 | Requested range not satisfiable | 客户端请求的范围无效 |
417 | Expectation Failed | 服务器无法满足Expect的请求头信息 |
500 | Internal Server Error | 服务器内部错误,无法完成请求 |
501 | Not Implemented | 服务器不支持请求的功能,无法完成请求 |
502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时,从远程服务器接收到了一个无效的响应 |
503 | Service Unavailable | 由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
504 | Gateway Time-out | 充当网关或代理的服务器,未及时从远端服务器获取请求 |
505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本,无法完成处理 |
3.3、实例说明
无论是请求报文还是响应报文,虽然分别由以上五个部分组成,但是在一定情况下有些并不是必须要的,但是对于:General-header(通用头部)、请求头(客户端->服务器[Request Header])、响应头(服务端->客户端[Response Header]) 这三部分是必须要有的。于是拿一个实例来对这三部分的内容进行说明记录:
(1)General-header(通用头部)
Request URL: http://115.148.141.110:8980/v1/purchase/list # 请求的URL地址(包含请求类型、请求域名、请求端口、请求地址)
Request Method: POST # 请求方式
Status Code: 200 OK # 响应的状态码、结果
Remote Address: 127.0.0.1:8899 # 请求的远程地址
Referrer Policy: no-referrer-when-downgrade # referrer策略(五种方法)
(2)请求头(客户端->服务器[Request Header])
POST /v1/purchase/list HTTP/1.1 # 请求方式、请求地址、请求所使用的协议和版本
Host: 115.157.151.673:8180 # 目标主机地址和端口号
Connection: keep-alive # 维护客户端和服务端的连接关系
Content-Length: 68 # 描述HTTP消息实体的传输长度
Accept: application/json, text/javascript, */*; q=0.01 #发送端(客户端)希望接受的数据类型、q 是权重系数,范围 0 =< q <= 1,q 值越大,请求越倾向于获得其“;”之前的类型表示的内容
Origin: http://apptest.zhidianlife.com:8007 # 浏览器在referrer字段中只显示源网站的源地址(即协议、域名、端口),而不包括完整的路径
Authorization: c81e7286507f4aa4b6179f4c381b4c64 # 请求所需的认证信息
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36 # 携带当前的用户代理信息,一般包含浏览器、浏览器内核和操作系统的版本型号信息。
Content-Type: application/json # 请求实体,文档类型
Referer: http://apptest.zhidianlife.com:8007/procurement/order?_t=756512&_winid=w9290 # 常用于同源限制策略,表示请求发起来源的URI,也就是当前页面资源的父页面。通过追踪Referer可得出资源页面之间复杂的跳转链。
Accept-Encoding: gzip, deflate # 客户端接收编码类型,一些网络压缩格式: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9 # 客户端接收的语言类型 、中文
(3)响应头(服务端->客户端[Response Header])
HTTP/1.1 200 OK # 请求协议以及本版、请求状态码
Date: Tue, 02 Jul 2019 14:07:31 GMT # 服务端响应客户端的内容过期时间
Content-Type: application/json; charset=utf-8 # 服务端发送的类型及采用的编码方式
Server: Kestrel # WEB 服务器 服务端的Web服务端名
Vary: Origin # WEB服务器用该头部的内容告诉 Cache 服务器,在什么条件下才能用本响应所返回的对象响应后续的请求
Access-Control-Allow-Credentials: true # 允许运行客户端携带证书式访问
Access-Control-Allow-Origin: http://apptest.zhidianlife.com:8007
Content-Length: 33310 # 允许指定的域名、地址访问
4、潜在的安全问题
DNS 解析的安全问题:
-
DNS域名劫持,攻击者通过对域名解析服务器的攻击或伪造,把目标网站的域名解析到错误(黑客准备)的页面,从而达到攻击者的某种目的。
防范措施:进行IP地址和MAC地址的绑定;使用域名系统的安全协议;对DNS数据包进行监测;使用IP进行访问等。
-
DNS 缓存投毒,通过利用网民ISP端的DNS缓存服务器的漏洞进行攻击或控制,从而改变该ISP内的用户访问域名的响应结果;或者通过利用用户权威域名服务器上的漏洞,如当用户权威域名服务器同时可以被当作缓存服务器使用,黑客可以实现缓存投毒,将错误的域名纪录存入缓存中,从而使所有使用该缓存服务器的用户得到错误的DNS解析结果。
-
DNS拒绝服务攻击,利用DNS软件版本漏洞攻击;利用僵尸网络中大量的被控主机,伪装成被攻击主机,在特定时间点上,连续向多个允许递归查询的DNS服务器发送大量的DNS查询请求,迫使其提供应答服务,经DNS服务器放大后的大量应答数据发送到被攻击主机,形成攻击流量,导致其无法提供正常服务甚至瘫痪。
相关文章分享:真的黑客能让你分分钟开进沟里,但他们不屑于此
HTTP的安全问题:
- Http的通信是明文的,存在被窃听的风险
- 无法确认通信双方身份,有可能会被人伪造
- 无法验证报文的完整性,无法验证是否被篡改过
5、WAF和CDN
- WAF
WAF(Web Application Firewall)称为web应用防火墙,是通过执行一系列针对HTTP,HTTPS的安全策略,来专门对web应用提供保护的一款产品,对来自Web应用程序客户端的各类请求进行内容检测和验证,确保其安全性与合法性,对非法的请求予以实时阻断,为Web应用提供防护。通俗的说,WAF类似于地铁站的安检,对于HTTP请求进行快速安全检查,通过解析HTTP数据,在不同的字段分别在特征、规则等维度进行判断,判断的结果作为是否拦截的依据从而决定是否放行。
WAF 可以用来屏蔽常见的网站漏洞攻击,如SQL注入,XML注入、XSS等。一般针对的是应用层而非网络层的入侵,从技术角度应该称之为Web IPS。其防护重点是SQL注入。
Web防火墙产品部署在Web服务器的前面,串行接入,不仅在硬件性能上要求高,而且不能影响Web服务,所以HA功能、Bypass功能都是必须的,而且还要与负载均衡、Web Cache等Web服务器前的常见的产品协调部署。
- CDN
这个url中有cdn字样。什么是CDN? 如果我在广州访问淘宝,跨省的通信必然造成延迟,如果淘宝在广东建立一个服务器,静态资源我可以直接从就近的广东服务器获取,必然能提高整个网站的打开速度,这就叫做CDN。CDN叫做内容分发网络,是依靠部署在各地的边缘服务器,使用户就近获取所需内容,降低网络拥塞,提高访问速度。