浏览器输入URL后HTTP请求返回的完整过程
输入网址—浏览器查找域名的IP地址—建立TCP链接—浏览器给Web服务器发送一个HTTP请求(web浏览器向web服务器发送请求命令—web浏览器发送请求头信息)—服务端处理请求— 服务端发回一个HTTP响应(web服务器应答—web服务器发送应答头信息—web服务器向浏览器发送数据)—web服务器关闭TCP连接—浏览器渲染显示HTML
5层网络模型介绍
在网络协议当中,整个网络信息传输的整个过程,都会套用一个经典的5层模型,在这5层模型里面,我们分为应用层,传输层,网络层,数据链路层和物理层
在每台电脑或者服务器上,都是有这么一个相应都层级的关系来维护我们整个网络数据传输的过程
物理层
主要作用是定义物理设备如何传输数据,简单来说,物理层是什么呢?
就是我们电脑的硬件,我们的网卡端口,网线,以及我们网线连出去之后要有条光缆来为我们把数据传输到互联网,可能经过好几千公里的这种情况下把数据传输到对面的服务器上面
所以这些物理的内容是必须要有的,没有物理,我们的软件是没有办法去传输的,所以物理层,就是这些硬件设备相关的东西
数据链路层
在通信的实体间建立数据链路链接,就是说我们物理是可以链接在一起了,两台机器,也要有一个软件服务帮我们通过物理的设备去创建一个电路的链接,也就是说这两边可以传输数据
数据链路层基本上就是我们最基础的电脑传输数据,就是01010101之类的东西
网络层
为数据在结点之间传输创建逻辑链路,逻辑链路包含一些,比如说我们从我的电脑要去访问百度的服务器,那么我们去寻找百度这台服务器它所在的地址,它就是一个逻辑关系,那么这个关系是在网络层为我们去创建的
传输层
为我们提供了可靠的端对端(end-to-end)服务,这个服务就是我们建立起了从我们自己的电脑到百度到服务器之间的这么一个链接之后,它们两端如何去传输数据,它传输数据的方式都是在这一层进行定义的
我们传输的数据有可能很小,有可能很大,那么如果传输数据比较大的时候,我们不能把这么大的数据传输过去,那我们要分包,要分片,这些分片之后,将数据传输到需要的那端最后又要进行一个组装,组装这个过程,如何去组装,如何去传输,都是在传输层进行一个定义的
传输层向高层屏蔽了下层数据通信的细节,因为我们http协议是实现在tcp,ip协议的基础上的,我们http协议要传输一个数据,我们只需要非常简单的
比如说在浏览器里面输入一个url,他就会自动去发送相关的一个数据到服务器端,然后服务器端能够解析这些数据返回给我们的浏览器,然后把页面显示出来
那么我们输入url这个过程,其实涉及到了一系列的数据的拼装以及传输,那么这个过程我们作为浏览器端,我们作为用户,或者我们作为网页的开发者,不需要指导他里面到底是怎么去分片,他怎么去跟服务器创建一个链接的关系,这些内容我们是完全不需要知道的,因为这是传输层他已经帮我们封装掉了,还有就是比如说我们创建一个ajax请求,那么ajax请求也是一个http的请求,我们使用ajax的post的方式去传输一些数据,那么这个数据如果比较大的时候,它也是一次性的传输不完的,那么它如何去进行一个传输,如何能够可靠的把我们想要的信息传输到服务器,服务器返回到信息又如何可靠的让我们拿到,那么这个过程都是传输层这边它已经帮我们去实现掉了,所以http协议层是不需要关心的
应用层
最主要的http协议是在这个层级上去实现的,它为我们应用软件提供了很多服务,我们写网页的时候,使用http协议去发送请求是非常方便的,只要去new一个request请求,然后就可以去把一些数据
比如post,get的方式去发送到服务端,这是应用层在http协议上面,它帮我们实现了http协议,然后我们只需要去使用http协议相关端一些工具,就可以帮我们去传输一些数据
它是构建于tcp协议之上的,所以它传输的方式,都是要落实于tcp,ip协议上面
什么是HTTP协议
协议是指计算机通信网络中两台计算机之间进行通信所必须共同遵守的规定或规则,超文本传输协议(HTTP)是一种通信协议,它允许将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器
HTTP协议永远都是客户端发起请求,服务器回送响应。这样就限制了使用HTTP协议,无法实现在客户端没有发起请求的时候(HTTP2有推送功能)
HTTP协议的主要特点
支持客户/服务器模式
简单快速:客户向服务器请求服务时,只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模小,因而通信速度很快。
灵活:HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记
无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。
无状态:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。同一个客户端的这次请求和上次请求是没有对应关系,对http服务器来说,它并不知道这两个请求来自同一个客户端。 为了解决这个问题, Web程序引入了Cookie机制来维护状态.
HTTP协议的发展历史
HTTP/0.9版本
第一个定稿的http协议是http/0.9版本,在这个版本里面非常非常的简单 只有一个命令,就是GET,就是我们现在经常用到的get请求,post请求,这些统称为http的命令或者叫做方法
没有header等描述数据信息的一些内容 那个时候的请求是非常简单,目的也非常简单,没有那么多不同的数据格式。服务器发送完内容之后,就把tcp链接给关闭了
http/1.0版本
第二个版本就是http/1.0版本,这个版本跟现在普遍使用的1.1其实差不多,它增加了很多命令,比如post, put, header这些命令
增加了status code 和 header相关的内容,code是服务端去处理某个请求之后的状态(查看下面的HTTP状态码),而header对应的就是我们的不管是发送,还是请求的相关的一些数据,它的描述以及我们如何对这部分数据进行操作的方法,
增加了多字符集支持、多部分发送、权限、缓存等内容,那么这些东西能够更好的有利于我们去使用http请求,去实现我们一个web服务。
http/1.1版本
这个版本只是在http/1.0上面增加了一些功能,来优化整个网络链接
支持了持久连接(查看下面的什么是持久连接)。在1.0版本里面,每发送一个http请求就要在客户端,服务端之间创建一个tcp链接,请求发送后服务端返回内容,然后这个tcp链接就关闭掉了,这样成本是相对比较高的。
建立一个http链接的过程当中,我们要3次握手(查看HTTP的三次握手),这部分是在tcp协议里面去做的,我们不需要关心,但是我们要知道,在这个创建的过程它们的消耗是比较高的,延迟也会比较高,所以我们在建完了一个链接之后,它可以不关闭。后续新的http请求可以一直在这个链接里面进行发送的话,这样性能肯定会高很多
增加了pipeline,我们可以在同一个链接里面发送多个请求,在服务端对于进来的请求,都是要按照一个顺序进行一个内容的返回,所以如果前一个请求,它的等待时间非常的长,后一个请求它处理的也比较快,那这个时候,后一个请求,它不能先发送,要第一个请求数据发送完成之后,它才能进行发送,所以这一部分时间就相当于一个串行,一个并行,它里面的性能的差异就体现出来了,而这个问题,在http/2.0版本会进行一个优化
增加了一些http的头和命令,其中一个比较重要的就是host,有了host之后,可以在同一台服务器,我指的服务器是物理服务器,在这个服务器上,我们可以跑多个不同的服务。比如一个nodejs的web服务和java的web服务,然后通过host这个字段,来表示我请求的是这台物理服务器上面,但是我要请求的是里面哪一个软件服务,是node还是java,这是通过host来进行判断的,它增加的好处就是同一个服务器或者同一个集群里面,我们可以部署很多不同的web服务来进行一个使用,这样的话,提高一个我们物理服务的使用效率
http/2.0版本
http2现在还没有普及,但是这是后面的趋势,这是毫无疑问的
在http1里面,我们大部分的传输是以字符串的形式传输,所以它数据都分片方式是不太一样的,在http2里面,我们所有的数据,都是以二进制进行传输的
同一个连接里面发送多个请求就不再按照顺序来进行一个返回处理了,它可以同时返回第一个请求里面的数据,再同时返回第二个请求里面的数据,让整个web应用的传输效率有一个质的提升
头信息压缩以及推送等提高效率的功能,http2整体上就是为了解决http1.1里面它的一些性能低的问题
头信息压缩是什么,在http/1.1里面,我们每一次发送请求和返回请求,它的http头信息都要进行一个完整的发送和返回的,但其实这部分头信息里面很多的内容,比如说它的header的字段,cache这些是以字符串的形式保存,所以它占用带宽的量是比较大的,在http2里面,头信息进行了一个压缩,可以有效的减少我们的带宽使用
第二个是推送的功能,我们知道http请求,我发送了请求,然后你那边响应请求,再返回内容,就是说客户端永远是主动方,服务端永远是被动方,在http2里面我们有了推送这个概念,也就是说服务端是可以主动发起一些数据传输的,那这个时候,它解决了什么问题呢?举一个最简单的例子,我们知道html,我们的web页面,都要求有一些css和js文件,那么都是以连接的方式在html里面显示着,通过浏览器解析之后,再根据连接里面包涵的url地址,我们再去请求对应的css和js文件,这里面就会包涵一个顺序的问题,我们需要先请求到html的文本,然后在浏览器里面运行,解析了这个文本之后,我们才能去发送css请求和js请求,那http2里面有了推送的功能之后,我们在请求html的同时,可以主动把html里面所需要引用到css文件和js文件推送到我们到客户端,这样到话,我们的html,css,和js,它的发送顺序是并行的,而不是串行的,它整体的传输效率和性能肯定是要高非常多的
PS:要弄清楚一点就是http请求跟tcp连接它不是一个概念。在同一个tcp连接里面,我们可以发送很多个http请求,以前的协议版本是不能这么做的,但在现在在http1.1里面,我们是可以这么做了,而且在http2里面是会更大的去优化相关的一些东西来西,来提高我们http协议传输的一些效率,以及服务器的性能,所以这边tcp链接对应的是多个http请求。而一个http请求是肯定在一个tcp链接里面去进行发送的
PS:这就是http协议的历史,其中当然还有https,https是http的安全版本,它实际使用的内容跟http/1.1没有很大的区别
HTTP的三次握手
在讲三次握手之前,希望大家理解一个概念
就是在我们的客户端和我们的服务器之间进行http请求,发送和返回的过程当中,我们是需要去创建一个tcp connection的东西
因为http是不存在连接概念的,它只有一个请求和响应的概念,那么请求和响应都是数据包,它们之间是需要一个传输的通道的,这个传输的通道就在tcp里面
去创建了一个从客户端发起,服务端接收的这么一个连接,这个连接是可以一直保持在那边,然后我们的http请求是在连接这个基础上面去发送的,在tcp连接上面,是可以发送多个http请求的,在不同的版本里面,这个模式是不一样的
在http/1.0里面,这个连接是在http请求创建的时候,就去创建这个tcp连接,然后连接创建完之后,然后请求发送过去,然后服务器响应之后呢,这个tcp连接它就关闭了
在http/1.1里面,这个连接我们可以通过某种方式去申声明这个连接可以一直保持在那边(管线化实现(查看管线化这部分内容)),就是我们这个请求,第一个请求发送之后,这个连接没有关,然后第二个请求进来的时候,它还可以在这个连接上面进行发送,这有什么好处呢?在创建过程当中,是有三次握手这么一个消耗的,三次握手就是代表着有三次网络传输,客户端发送一次,然后服务端返回一次,然后客户端再发送一次,这个时候才创建了tcp连接,然后才能去发送http请求,所以如果把连接一直保持在那边,那么第二个http请求就没有三次握手的开销
在http2里面还有一个好处就是,http2里面tcp连接上面的http请求是可以并发的,就是说我们同一个用户对同一个服务器发起一个网页请求的时候,它只需要一个tcp连接
http的三次握手的过程:
- 首先客户端发起一个我要发送一个数据包的请求,发送到服务端,这里面会有一个标志SYN=1,Seq=X,syn是一个标识,就是我这是一个创建请求的数据包,然后seq等于一个数字,一般来说都是1,然后服务端接收之后,知道了我有一个客户要跟我创建连接了
- 创建这个连接之后,服务端就会开启一个tcp,socket的一个端口,然后这个端口开启了之后,它返回给客户端,它返回的数据里面也是一个SYN=1,ACK=X+1,Seq=Y,然后它会返回一个ACK,ACK就等于第一次发送过来的Seq,就是X,然后+1,然后它再发送一个Seq,这个是服务器端的一个Seq
- 客户端拿到之后,服务端允许我们打开创建这个连接,然后客户端再去发送它的ACK=Y+1,Seq=Z,它再发送一个Seq,等于一个新的数字Z,这就是tcp去创建的一个过程
为什么要进行这样一个三次握手
这是为了防止服务端这边开启一些无用的连接,因为我们知道网络传输是有延迟的,因为我们之间可能隔着非常远的距离,要通过一个光纤,然后各种中间的代理服务器来进行一个传输,在传输的过程当中,比如客户端发送一个SYN=1,创建连接的请求,如果服务端就直接创建了这个连接,然后返回内容给客户端,但是这个数据包因为网络传输的原因,它丢了,丢了以后,客户端就一直没有接收到服务器返回到这个东西,然后客户端可能设置了一个超时时间,关闭了,关闭了之后才发现一个新的创建连接的请求,这个时候服务端是不知道的,如果没有第三次握手,服务端根本不知道客户端有没有接收到我返回到信息,并且没有说要去创建还是关闭这个请求,服务端就开在那边,等着客户端发送实际到请求数据,那么这个时候服务端这个开销就浪费了,因为它不知道这个连接已经创建失败了,可能客户端已经创建新到连接去了,所以呢,我们需要三次握手,让客户端和服务端察觉到我们因为网络原因端一些问题导致数据没有查到,这个端口,这个连接已经关闭了,我们需要一直等在那边的情况,三次握手主要是规避网络传输当中延迟而导致服务器开销的一些问题
接下来看下三次握手数据包的相关内容,Wireshark抓包工具
13789是本机的一个端口,80是服务器端的一个端口,因为有三次握手,客户端和服务器之间有三个来回,只要找到同一个端口的来回,就可以找到这三次握手
如图,这三次是完整的三次握手的过程,第一次握手可以看到发送了一个SYN标示位,为了简单演示,说SYN=1,其实,就是SYN占据了第一个标识位,用图片只是为了更形象的展示这三个过程,返回的时候是一个SYN,再加上一个ACK。最后客户端再发送一个ACK给服务端,作为第一个标识位,这样一个过程就完成了一个三次握手
什么是持久连接
http协议采用“请求-应答”模式,当使用普通模式,即非keep-alive模式时,每个请求/应答客户和服务器都要新建一个连接,完成之后立即断开连接(HTTP协议为无连接的协议)
当使用keep-alive模式(持久连接,连接重用)时,keep-alive功能使客户端到服务端的连接持续有效,当出现对服务器的后续请求时,keep-alive功能避免了建立或者重新建立连接
从HTTP/1.1起,默认都开启了Keep-Alive,保持连接特性,简单地说,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接
Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间
管线化管理
什么是管线化
管线化技术——客户端可以发送多次请求到服务端,而不需要等待上一次请求得到响应的时候才能进行下一次请求。实现并行发送请求
在使用持久连接的正常情况下,请求完一次之后不要断开连接,继续请求,某个连接上消息的传递类似于
请求1->响应1->请求2->响应2->请求3->响应3
管线化就是我们这个通道时持久建立的,不是请求一次响应一次,而是将请求打包一次传输过去然后响应时也打包一次响应过来,某个连接上的消息变成了类似这样
请求1->请求2->请求3->响应1->响应2->响应3
管线化的特点
管线化机制通过持久连接完成,仅HTTP/1.1支持此技术
只有GET和HEAD请求可以进行管线化,而POST则有所限制
初次创建连接时不应启动管线机制,因为对方(服务器)不一定支持HTTP/1.1版本的协议
管线化不会影响响应到来的顺序
HTTP/1.1要求服务器支持管线化,但并不要求服务器也对响应进行管线化处理,只是要求对于管线化的请求不失败即可
开启管线化很可能并不会带来大幅度的性能提升,而且很多服务器端和代理程序对管线化的支持并不好,因此现代浏览器比如Chrome和Firefox默认并没有开启管线化支持
HTTP状态码
Response 消息中的第一行叫做状态行,由HTTP协议版本号, 状态码, 状态消息 三部分组成,状态码用来告诉HTTP客户端,HTTP服务器是否产生了预期的Response
HTTP/1.1中定义了5类状态码, 状态码由三位数字组成,第一个数字定义了响应的类别
1XX 提示信息 - 表示请求已被成功接收,继续处理
2XX 成功 - 表示请求已被成功接收,理解,接受
3XX 重定向 - 要完成请求必须进行更进一步的处理
4XX 客户端错误 - 请求有语法错误或请求无法实现
5XX 服务器端错误 - 服务器未能实现合法的请求
下面几个常见的状态码:
200 OK //客户端请求成功,该请求被成功地完成,所请求的资源发送回客户端
206 Partial Content,客户端发送了一个带有Range(范围)头的GET请求,服务器完成了它,服务器会返回指定范围的资源
301 Moved Permanently,所请求的页面已经转移至新的url
302 Found重定向,新的URL会在response 中的Location中返回,浏览器将会自动使用新的URL发出新的Request
304 Not Modified,代表上次的文档已经被缓存了, 还可以继续使用
400 Bad Request //客户端请求有语法错误,不能被服务器所理解
401 Unauthorized //请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden //服务器收到请求,但是拒绝提供服务
404 Not Found //请求资源不存在,eg:输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求,一段时间后可能恢复正常
URI-URL和URN
URI:统一资源标志符
用来标识互联网上的信息资源,包括URL和URN
URI标识一个事物,URL定位一个事物;然而,位置同样可以标识一个事物,所以,每个URL都是一个 URI,但一个URI并不一定是一个URL。
URL:统一资源定位器
下面此类格式都叫URL
完整的URL地址:http://user:pass@host.com:80/path?query=string#hash http:// 协议 user:pass@ 代表访问资源的身份使用用户名和密码 host.com 用来定位资源的服务器在互联网中的位置(可以是IP 也可以是 域名) :80 端口,每台物理服务器可以跑很多软件的web服务,端口就是监听物理服务器上面某个具体的web服务 /path 路由,web 服务器里面的内容可以通过路由进行定位 ?query=string 搜索参数 #hash 查找文档的某个片段
URN: 永久统一资源定位符
在资源移动之后还能被找到,目前还没有非常成熟的使用方案
HTTP报文的组成部分
请求报头
允许客户端向服务器端传递请求的附加信息以及客户端自身的信息
Accept:请求报头域用于指定客户端接受哪些类型的信息。eg:Accept:image/gif,表明客户端希望接受GIF图象格式的资源;Accept:text/html,表明客户端希望接受html文本
Accept-Charset:请求报头域用于指定客户端接受的字符集。eg:Accept-Charset:iso-8859-1,gb2312.如果在请求消息中没有设置这个域,缺省是任何字符集都可以接受
Accept-Encoding:请求报头域类似于Accept,但是它是用于指定可接受的内容编码。eg:Accept-Encoding:gzip.deflate.如果请求消息中没有设置这个域服务器假定客户端对各种内容编码都可以接受
Accept-Language:请求报头域类似于Accept,但是它是用于指定一种自然语言。eg:Accept-Language:zh-cn.如果请求消息中没有设置这个报头域,服务器假定客户端对各种语言都可以接受
Authorization:请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时,如果收到服务器的响应代码为401(未授权),可以发送一个包含Authorization请求报头域的请求,要求服务器对其进行验证。
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请求报头域,那么服务器端就无法得知我们的信息了。
Referer :头域允许客户端指定请求uri的源资源地址,这可以允许服务器生成回退链表,可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被 追踪。如果请求的uri没有自己的uri地址,Referer不能被发送。如果指定的是部分uri地址,则此地址应该是一个相对地址。
响应报头
允许服务器传递不能放在状态行中的附加响应信息,以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息
Server:响应报头域包含了服务器用来处理请求的软件信息。与User-Agent请求报头域是相对应的。下面是Server响应报头域的一个例子:Server:Apache-Coyote/1.1
Location:响应报头域用于重定向接受者到一个新的位置。Location响应报头域常用在更换域名的时候
WWW-Authenticate:响应报头域必须被包含在401(未授权的)响应消息中,客户端收到401响应消息时候,并发送Authorization报头域请求服务器对其进行验证时,服务端响应报头就包含该报头域。eg:WWW-Authenticate:Basic realm="Basic Auth Test!" //可以看出服务器对请求资源采用的是基本验证机制
HTTP方法
GET:获取资源(请求获取Request-URI所标识的资源),在浏览器的地址栏中输入网址的方式访问网页时,浏览器采用GET方法向服务器获取资源,eg:GET /form.html
POST:传输资源(在Request-URI所标识的资源后附加新的数据),POST方法要求被请求服务器接受附在请求后面的数据,常用于提交表单
HEAD:获得报文首部( 请求获取由Request-URI所标识的资源的响应消息报头)
PUT:更新资源(请求服务器存储一个资源,并用Request-URI作为其标识)
DELETE:删除资源(请求服务器删除Request-URI所标识的资源)
TRACE:请求服务器回送收到的请求信息,主要用于测试或诊断
CONNECT:保留将来使用
OPTIONS:请求查询服务器的性能,或者查询与资源相关的选项和需求
GET和POST的区别
Http协议定义了很多与服务器交互的方法,最基本的有4种,分别是GET,POST,PUT,DELETE. 一个URL地址用于描述一个网络上的资源,而HTTP中的GET, POST, PUT, DELETE就对应着对这个资源的查,改,增,删4个操作。 我们最常见的就是GET和POST了。GET一般用于获取/查询资源信息,而POST一般用于更新资源信息.
- GET提交的数据会放在URL之后,以?分割URL和传输数据,参数之间以&相连,如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的数据放在HTTP包的Body中.
- GET提交的数据大小有限制(因为浏览器对URL的长度有限制),而POST方法提交的数据没有限制.
- GET方式需要使用Request.QueryString来取得变量的值,而POST方式通过Request.Form来获取变量的值。
- GET方式提交数据,会带来安全问题,比如一个登录页面,通过GET方式提交数据时,用户名和密码将出现在URL上,如果页面可以被缓存或者其他人可以访问这台机器,就可以从历史记录获得该用户的账号和密码.而且GET产生的URL地址可以被收藏,而POST不可以
- GET在浏览器回退时是无害的,而POST会再次提交请求
- GET请求会被浏览器主动缓存,而POST不会,除非手动设置
- GET请求只能进行url编码,而POST支持多种编码方式
- GET请求参数会被完整保留在浏览器历史纪录里,而POST中的参数不会被保留
Http指纹识别技术
Http指纹识别的原理大致上也是相同的:记录不同服务器对Http协议执行中的微小差别进行识别.Http指纹识别比TCP/IP堆栈指纹识别复杂许 多,理由是定制Http服务器的配置文件、增加插件或组件使得更改Http的响应信息变的很容易,这样使得识别变的困难;然而定制TCP/IP堆栈的行为 需要对核心层进行修改,所以就容易识别.
要让服务器返回不同的Banner信息的设置是很简单的,象Apache这样的开放源代码的Http服务器,用户可以在源代码里修改Banner信息,然 后重起Http服务就生效了;对于没有公开源代码的Http服务器比如微软的IIS或者是Netscape,可以在存放Banner信息的Dll文件中修 改,相关的文章有讨论的,这里不再赘述,当然这样的修改的效果还是不错的.另外一种模糊Banner信息的方法是使用插件。
常用测试请求:
- HEAD/Http/1.0发送基本的Http请求
- DELETE/Http/1.0发送那些不被允许的请求,比如Delete请求
- GET/Http/3.0发送一个非法版本的Http协议请求
- GET/JUNK/1.0发送一个不正确规格的Http协议请求
Http指纹识别工具Httprint,它通过运用统计学原理,组合模糊的逻辑学技术,能很有效的确定Http服务器的类型.它可以被用来收集和分析不同Http服务器产生的签名