"重放攻击"大家应该听说过吧?重放攻击时黑客常用的攻击方式之一,攻击者发送一个目的主机已接收过的包,来达到欺骗系统的目的,主要用于身份认证过程,破坏认证的正确性。这种攻击会不断恶意或欺诈性地重复一个有效的数据传输,重放攻击可以由发起者,也可以由拦截并重发该数据的敌方进行。攻击者利用网络监听或者其他方式盗取认证凭据,之后再把它重新发给认证服务器。
重放攻击监听http数据传输的截获的敏感数据大多数就是存放在Cookie中的数据。在web安全中的通过其他方式(非网络监听)盗取Cookie与提交Cookie也是一种重放攻击。所以可以看出"Cookie"这个“东东”好像很不安全。
那么今天就以本篇文章详细给大家介绍一下Cookie是什么?Cookie基本原理与实现?Cookie到底存在哪些安全隐患,我们该如何防御,有没有其他技术替代方案?
官方定义:Cookie,有时也用其复数形式Cookies,指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据(通常经过加密)。
通俗理解:Cookie就是服务器端为了保存某些数据,或实现某些必要的功能,当用户访问服务器时,从服务器回传到客户端的一个或多个数据,这些数据因设置的保存时间不同,故保存在浏览器内存中或写入用户PC的硬盘当中,当下次用户再次访问服务器端时,则带着这些文件去与服务器端进行联系,这些数据或写入硬盘当中的数据文件就是Cookie。
详细简介:
众所周知,Web协议(也就是HTTP)是一个无状态的协议(HTTP1.0)。一个Web应用由很多个Web页面组成,每个页面都有唯一的URL来定义。用户在浏览器的地址栏输入页面的URL,浏览器就会向Web Server去发送请求。如下图,浏览器向Web服务器发送了两个请求,申请了两个页面。这两个页面的请求是分别使用了两个单独的HTTP连接。所谓无状态的协议也就是表现在这里,浏览器和Web服务器会在第一个请求完成以后关闭连接通道,在第二个请求的时候重新建立连接。Web服务器并不区分哪个请求来自哪个客户端,对所有的请求都一视同仁,都是单独的连接。这样的方式大大区别于传统的(Client/Server)C/S结构,在那样的应用中,客户端和服务器端会建立一个长时间的专用的连接通道。正是因为有了无状态的特性,每个连接资源能够很快被其他客户端所重用,一台Web服务器才能够同时服务于成千上万的客户端。
但是我们通常的应用是有状态的。先不用提不同应用之间的SSO,在同一个应用中也需要保存用户的登录身份信息。例如用户在访问页面1的时候进行了登录,但是刚才也提到,客户端的每个请求都是单独的连接,当客户再次访问页面2的时候,如何才能告诉Web服务器,客户刚才已经登录过了呢?浏览器和服务器之间有约定:通过使用cookie技术来维护应用的状态。Cookie是可以被Web服务器设置的字符串,并且可以保存在浏览器中。如下图所示,当浏览器访问了页面1时,web服务器设置了一个cookie,并将这个cookie和页面1一起返回给浏览器,浏览器接到cookie之后,就会保存起来,在它访问页面2的时候会把这个cookie也带上,Web服务器接到请求时也能读出cookie的值,根据cookie值的内容就可以判断和恢复一些用户的信息状态。
Cookie文件记录了用户的有关信息,如身份识别号码ID、密码、浏览过的网页、停留的时间、用户在Web站点购物的方式或用户访问该站点的次数等,当用户再次链接Web服务器时,浏览器读取Cookie信息并传递给Web站点。
Cookie文件信息片断以"名/值"对(name-vaiuepairs)的形式储存,一个"名/值"对仅仅是一条命名的数据。例如,访问 www.goto.com网站,则该站点可能会在客户端电脑上产生一个包含以下内容的Cookie文件:UserIDA9A3BECE0563982Dwww.goto.com/。goto.com在电脑上存入了一个单一的"名/值"对,其中的"名"是UserID,"值"是A9A3BECE0563982D。
Cookie文件的存放位置与操作系统和浏览器密切相关,这些文件在Windows机器里叫做Cookie文件,在Macintosh机器里叫做MagicCookie文件。对Windows和IE浏览器而言,Cookies文件的存放位置为:
Cookie的主要功能是实现用户个人信息的记录,它最根本的用途是帮助Web站点保存有关访问者的信息。更概括地说,Cookie是一种保持Web应用程序连续性(即执行状态管理)的方法。
HTTP协议是一种无状态、无连接的协议,不能在服务器上保持一次会话的连续状态信息。随着WWW的不断发展,HTTP的无状态性不能满足某些应用的需求,给Web服务器和客户端的操作带来种种不便。在此背景下,提出HTTP的状态管理机制———Cookie机制,它是对HTTP协议的一种补充,以保持服务器和客户端的连续状态。
以实例阐述技术原理:
假设一个用户在进行网上购物
1) 假定用户第一次访问这个购物网站,用户浏览器这边有一个Cookie文件,里面只有一行信息beay:8734,但是没有任何与这个购物信息有关的信息
2) 用户开始使用常规的http请求消息来访问,服务器收到访问以后,发现这是一个新用户,于是为这个用户创建一个ID为1678,并把这个信息存储在后端的数据库中
3) 服务器收到请求后向浏览器发回响应消息,但是在响应消息里面多了一行信息,就是Set-cookie: 1678,客户浏览器收到响应信息后,把新增的Cookie信息添加到自己的Cookie文件中,意思是:我在这个网站中的ID是1678
4) 当用户第二次再访问这个网站的时候,请求信息中就会带上自己的Cookie信息,服务器收到以后,通过Cookie信息发现是之前访问过的用户,于是做出Cookie-specific action,将http响应信息发回用户浏览器
5) 一周以后再次访问,依然会重复4的步骤
1、Session cookie
也称为内存cookie或者瞬时cookie,只存在用户浏览站点时的内存中。当用户关闭浏览器时,浏览器通常会删除session cookies。不像其他cookies,session cookies没有分配过期时间,作为session cookie浏览器会自己管理它。
2、持久性cookie
不像session cookie在浏览器关闭时就会过期那样,持久性cookie是到一个特定日期过期或者过来一段时间过期。这就意味着,在cookie的整个生命周期(创建cookie时可以指定其生命周期),每次用户访问cookie所属站点时,或者每次用户在其他站点访问cookie所属站点的资源(例如广告)时,cookie所携带的信息都会被发送到服务端。
由于这个原因,持久性cookie有时被称为追踪cookie,因为广告系统可以利用它记录用户在一段时间内的网页浏览习惯信息。当然,使用它也有一些"正当"理由,例如保持用户的登录状态,避免每次访问的再次登录。
如果过期时间到了,或者用户手动删除了,这种cookie会被重置。
3、安全cookie
安全cookie只能通过安全连接传输(例如,https)。不能通过非安全连接传输(例如,http)。这样就不太可能被窃取。在cookie中设置一个Secure标志就可以创建安全cookie。
4、HttpOnly cookie
HttpOnly cookie不能通过客户端api获取到。这种限制减少了通过(XSS)窃取cookie的风险。然而这种cookie也会受到跨站追踪和跨站请求伪造攻击。在cookie中添加HttpOnly可以创建这种cookie。
5、SameSite cookie
chrome51版本引入的一种新类型cookie,只有请求和站点是同源的,才会发送cookie到服务器。这种限制可以缓解攻击,例如跨站请求伪造攻击。在cookie中设置SameSite标识可以创建这种类型的cookie。
6、第三方cookie
正常情况下,cookie的域属性和浏览器地址栏里显示的域是相同的。这种cookie称为第一方cookie。然而第三方cookie不属于浏览器地址栏显示的域中。这种cookie通常出现在web页面有外部站点内容时的情况中,例如广告系统。这就提供了一个潜在的能力来追踪用户的浏览历史,广告系统通常会利用这个来给每个用户推荐相关的广告信息。
例如,假设用户访问了www.example.com,这个站点包含ad.foxytracking.com的广告,当这个广告加载时,会设置一个属于广告所在域(ad.foxytracking.com)的cookie。然后用户访问另一个站点,www.foo.com,这个站点也包含来自ad.foxytracking.com的广告,这个广告也会设置一个属于ad.foxytracking.com域的cookie。最终,所有这些cookie会发送给广告主,当用户加载他们的广告或者访问他们的网站时。然后广告主就可以利用这些cookie统计出用户的浏览记录,当然浏览记录里面的站点必须要包含广告主的广告。也就是广告主可以利用这些cookie知道你访问了那些包含他们广告的站点。
7、Supercookie
supercookie是来自于顶级域名(例如.com)或者有公共后缀(例如.co.uk)的cookie。普通cookie是来自于一个特定域名,例如example.com。
supercookie是一个潜在的安全威胁,所以经常被浏览器默认禁止的。如果浏览器不禁止,控制恶意站点的攻击者可以设置一个supercookie,干扰或者冒充合法的用户向其他共享顶级域名或者公共后缀的站点的请求。例如,来自.com的supercookie可以恶意影响example.com的请求,即便这个cookie并不是来自于example.com。可以用来伪造登录或者修改用户信息。
帮助降低supercookie带来的风险。公共后缀是一个跨厂商的倡议,目标是为了提供一个准确的最新的域名后缀列表。旧版本浏览器可能没有一份最新的列表,会容易受到来自某些域的supercookie的威胁。
"supercookie"的术语有时会被用来描述某些不通过HTTP cookie的追踪技术。两个这样的"supercookie"机制在2011年的微软站点被发现了:机器标识码cookie和ETag cookie,由于媒体的关注,微软禁止了这样的cookie。
8、Zombie cookie
zombie cookie是指被删除后可以自动再创建的cookie。通过把cookie内容存储在多个地方实现,例如flash的,H5的,其他客户端甚至服务端位置。当缺失的cookie被检测到,就会利用存储在这些位置的数据重新创建cookie。
Cookie的目的是为用户带来方便,为网站带来增值,一般情况下不会造成严重的安全威胁。Cookie文件不能作为代码执行,也不会传送病毒,它为用户所专有并只能由创建它的服务器来读取。另外,浏览器一般只允许存放300个Cookie,每个站点最多存放20个Cookie,每个Cookie的大小限制为4KB,因此,Cookie不会塞满硬盘,更不会被用作"拒绝服务"攻击手段。
但是,Cookie作为用户身份的替代,其安全性有时决定了整个系统的安全性,Cookie的安全性问题不容忽视。
1、Cookie欺骗
Cookie记录了用户的帐户ID、密码之类的信息,通常使用MD5方法加密后在网上传递。经过加密处理后的信息即使被网络上一些别有用心的人截获也看不懂。然而,现在存在的问题是,截获Cookie的人不需要知道这些字符串的含义,只要把别人的Cookie向服务器提交,并且能够通过验证,就可以冒充受害人的身份登陆网站,这种行为叫做Cookie欺骗。
非法用户通过Cookie欺骗获得相应的加密密钥,从而访问合法用户的所有个性化信息,包括用户的E-mail甚至帐户信息,对个人信息造成严重危害。
2、Cookie截获
Cookie以纯文本的形式在浏览器和服务器之间传送,很容易被他人非法截获和利用。任何可以截获Web通信的人都可以读取Cookie。
Cookie被非法用户截获后,然后在其有效期内重放,则此非法用户将享有合法用户的权益。例如,对于在线阅读,非法用户可以不支付费用即可享受在线阅读电子杂志。
Cookie截获的手段有以下一些。
(1) 用编程手段截获Cookie。
下面分析其手法,该方法分两步完成:
步骤一:定位需要收集Cookie的网站,对其进行分析并构造URL。 首先打开要收集Cookie的网站,这里假设是http://www.XXX.net,登陆网站输入用户名"<Al>"(不含引号),对数据进行分析抓包,得到如下代码:
将其中"<Al>"更换为:
"<script>alert(document.cookie)</script>"再试,如果执行成功,就开始构造URL:
其中http://www.cbifamily.org/cbi.php是用户能够控制的某台主机上的一个脚本。需要注意的是"%2b"为符号"+"的URL编码,因为"+"将被作为空格处理。该URL即可在论坛中发布,诱使别人点击。
步骤二:编制收集Cookie的PHP脚本,并将其放到用户可以控制的网站上,当不知情者点击了构造的URL后可以执行该PHP代码。该脚本的具体内容如下:
将这段代码放到网络里,则能够收集所有人的Cookie。如果一个论坛允许HTML代码或者允许使用Flash标签,就可以利用这些技术收集Cookie的代码放到论坛里,然后给帖子取一个吸引人的主题,写上有趣的内容,很快就可收集到大量的Cookie。在论坛上,有许多人的密码就是被这种方法盗走的。
(2) 利用Flash的代码隐患截获Cookie。
Flash中有一个getURL()函数。Flash可以利用这个函数自动打开指定的网页,它可能把用户引向一个包含恶意代码的网站。例如,当用户在电脑上欣赏Flash动画时,动画帧里的代码可能已经悄悄地连上网,并打开了一个极小的包含有特殊代码的页面,这个页面可以收集Cookie、也可以做一些其他有害的事情。网站无法禁止Flash的这种作为,因为这是Flash文件的内部功能。
(3)Cookie泄漏网络隐私
Cookie导致网络隐私泄密的主要原因是:商业利益驱动。随着电子商务的兴起和互联网上巨大商机的出现,一些网站和机构滥用Cookie,未经访问者的许可,利用搜索引擎技术、数据挖掘技术甚至是网络欺骗技术搜集他人的个人资料,达到构建用户数据库、发送广告等营利目的,造成用户个人隐私的泄漏。"Cookie信息传递的开放性。Cookie文件具有特殊的传递流程 和文本特性,在服务器和客户端之间传送未经安全加密的Cook-ie文件,易导致个人信息的泄密。
面对Cookie的安全问题,如何才能安全地应用Cookie呢?
(1)加强安全防范意识
Cookie相对来说是无害的,但它能用于跟踪用户,使用Cookie必须意识到其固有的安全弱点。
保存在Cookie中的内容,完全有可能是用户的私人数据。例如,网站为了方便用户,利用Cookie来保存会员的注册信息:电子邮件地址、网站的用户名、用户密码、信用卡号码等,以便用户以后登录该网站时不用重新输入这些数据。如果有人盗取了这样的Cookie文件,他就可以冒充登录网站,这将对用户的个人信息安全构成不可预测的威胁。
因此,只在Cookie中保存一些不重要的数据,如用户首选项或其它对应用程序没有重大影响的信息。如果确实需要在Cook-ie中保存某些敏感信息,就要对其加密,以防被他人盗用。可以对Cookie的属性进行设置, 使其只能在使用安全套接字层(SSL)的连接上传输。SSL并不能防止保存在用户计算机上的Cookie被他人读取或操作,但能防止Cookie在传输途中被他人截获。
(2)配置安全的浏览器
IE和Netscape浏览器的工具栏里,都有禁止Cookie的设置选项,都可以设置当某个站点要在用户的计算机上创建Cookie时,是否给出提示。这样用户就可以选择允许或拒绝创建Cook-ie。需要注意的是,某些网站的应用必须使用Cookie,简单地禁止可能导致无法正常浏览此类网站。
使用IE6会更安全。最新的IE6提供了多种隐私保护功能,包括:查看网站的P3P隐私策略,以了解该网站如何使用个人可识别信息;通过Cookie隐私设置决定是否允许将网站的Cookie保存在计算机上;在访问不符合隐私设置条件的站点时发出隐私警报。用户可以有选择性地设置Cookie。
(3)安装Cookie管理工具
①CookieCrusher
LimitSoftware公司的Crusher适用于Netscape用户,其功能有:管理计算机上已有的Cookie、设置禁止或允许创建Cookie的网站列表、在创建新Cookie与修改已经存在的Cookie时发出警告、禁止第三方网站Cookie、实时控制接受或拒绝来自站点的Cookie、记录Cookie活动日志、编辑Cookie等,并且在网上浏览时,程序独创的分析功能可以自动确定网站要求创建的Cookie的目的,如:判断网站是把Cookie用于存储用户输入的资料还是准备利用Cookie跟踪用户的浏览习惯等。
②CookiePaI
除了浏览器能使用Cookie, 其它的互联网软件也可能使用,如邮件程序等。为了维护网络隐私的安全,同时又能保证一些互联网软件正确地使用Cookie文件,可以安装Kooka-burraSoftware公司的支持多种软件的Cookie管理工具CookiePaI。它专门用于Cookie管理,支持用户查看、删除、编辑已经存在的Cookie,自动地实时控制是否接受Cookie,根据过期时间过滤Cookie,它还能够记录Cookie的活动,编辑拒绝或允许Cookie的网站列表。
(4)删除内存中的Cookies
Cookie的信息并不都是以文件形式存放在硬盘中,还有部分信息保存在内存里。这类Cookie通常是用户在访问某些特殊网站时,由系统自动在内存中生成的。一旦访问者离开该网站,系统又自动将Cookie从内存中删除。对此,需要借助注册表编辑器来修改系统设置,运行Regedit,找到如下键值:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Cur-rentversion\InternetSettings\Cache\SpeciaIPaths\Cookies,这是Cookies在内存中的键值,把这个键值删除。右键单击"Cook-ies",再单击快捷菜单中的"删除"命令确认删除。
(5)使用AAS技术
2002年,美国IngrianNetworks公司发表了可以使Web站点 免受"CookiePoisoning(Cookie篡改)"攻击的平台"ActiveAppIi-cationSecurity(AAS)"。AAS平台能对Cookie内部的重要信息进行加密处理,并附上电子签名。Web服务器每次和客户端进行通信时,将利用电子签名对Cookie的内容进行确认。如果恶意用户删除了电子签名或者更改了信息内容,将会使电子签名和Cookie的内容无法再匹配。这时,AAS便会阻止这条Cookie并拒绝向Web站点返回信息。另外,该平台还对Cookie内容进行了3DES加密,解密需要口令,通过这种方法安全地保存Cookie。WWW服务器和客户端之间的通信还全部利用了SSL连接方式,以确保通信路由的安全。通过综合运用电子签名、加密、SSL连接等技术组成强效的安全方案,可以排除通信路由及数据存储两方面存在的脆弱性,杜绝对Cookie的篡改。
有些可以使用cookie实现的方案也可以使用其他机制实现。
1、JSON Web Tokens
(JWT)是一个自包含的信息包,可以用来存储用户标识以及认证信息。可以被用来代替session cookie。和cookie自动附加到每个HTTP请求的方式不一样,JWTs必须被web应用明确指定附加到那个HTTP请求上。
2、HTTP 认证
HTTP包含基本认证以及摘要认证协议,利用这些协议只有在提供了正确的用户名和密码后才能访问到web页面。如果服务端需要类似的认证信息来确保web页面的访问权限,那么浏览器每次页面请求的时候都要发送这些认证信息。这些认证信息也可以用来追踪用户。
3、IP 地址
有些用户可能会被基于访问页面的电脑IP地址追踪过,服务端知道当前正在运行浏览器的电脑的IP地址,理论上可以对这个IP地址关联一个用户session。
然后IP地址通常不是一个可靠的追踪session或者标识用户的方法。许多电脑设计的时候就是为了让一个单独用户使用的,例如办公PC,家庭PC会在网络地址转换协议下共享一个公共的IP地址。而且某些系统,例如设计的时候就是为了保持匿名性的,利用IP地址追踪用户显然是不合适的,也是不可能的。
4、URL 查询字符串
一个更精确的技术是基于URL中嵌入信息。URL中的查询字符串部分通常就是为了实现这个目的的,当然也可以使用其他部分。Java Servlet和PHP session机制都是使用这种机制,如果cookie被禁止了。这种方法由服务端在web页面的所有链接中追加包含一个独立session标识的查询字符串组成。当用户点击了其中了一个链接,浏览器把查询字符串传给服务端,允许服务端识别用户维持状态。这些类型的查询字符串非常像cookie,都包含任意的信息供服务端选择,都会随请求返回给服务端。然而其中还是有点不同的。由于查询字符串是URL中的一部分,如果URL后面被重复发送了,那么上面附加的相同信息将会被发送到服务端,这样可能会产生混乱。例如,如果用户的偏好信息被放在了查询字符串中,用户把这个url通过邮件发给了另一个用户,那么这些偏好信息就会变成另一个用户的。而且如果相同用户从不同的源多次访问相同的页面,这样不能确保每次使用相同的查询字符串。例如,如果一个用户第一次通过一个页面的内部站点访问了一个页面,然后第二次又通过外部的搜索引擎访问到这个页面,这样查询字符串可能会不同。如果在这种情况下使用cookie,cookie可以是相同的。
使用查询字符串其他缺点就是安全问题。在查询字符串中存储标识session的数据可以导致session固定攻击,referer日志攻击以及其他安全漏洞。把session标识转成HTTP cookie更安全。
5、隐藏的表单字段
另一种回话跟踪是使用隐藏域的web表单。这个技术很像使用url查询字符串去保存信息,也有一些优点和缺点。事实上,如果通过HTTP的GET方法处理表单,那么这种技术就和使用URL查询字符串类似,因为GET方法会把表单字段作为查询字符串追加到URL后面。但是大部分表单都是通过HTTP的POST方法处理,这样表单信息包括隐藏的字段都会在HTTP请求体中发送,这样既不是URL中的一部分,也不是cookie的一部分。
从追踪的角度来看这种方式有两种好处。第一,把追踪信息放在HTTP请求体中而不是URL中意味着它不会被普通用户察觉。第二,当用户复制URL的时候不会复制到session信息。
6、"window.name" DOM 属性
所有的现代浏览器都可以通过js使用DOM属性window.name存储一个相当大的数据(2-23M)。这个数据可以用来代替session cookie也是可以跨域的。这个技术可以和JSON对象一起使用来存储客户端上的复杂session变量集合。
不足就是美国单独的窗口或者tab页刚开始打开的时候会有一个空的window.name属性。而且,这个属性可以用来追踪不同站点的访问者。
在某些方面,这种方法可能比cookie更加方便,因为它的内容不会像cookie那样在每次请求的时候自动的发送给服务端,所以它不易收到网络cookie嗅探攻击。然而如果不采用特殊的方法保护数据,它很容易受到其他攻击,因为数据可以被在同一个窗口或者tab中打开的其他站点获取到。
7、广告主标识码
苹果使用了追踪技术称为"广告主标识码"(IDFA)。这种技术会给每个购买苹果产品的用户分配一个唯一标识。这个唯一标识会被苹果网络广告系统使用,来确定用户正在查看或者回复的广告。
8、ETag
因为浏览器会缓存ETags,然后在后续的请求相同资源时返回,追踪服务器可以简单的复制从浏览器接受的任意ETag来确保ETag长久留存(就像持久化cookie一样)。增加缓存头也可以加强ETag数据的保存。
在某些浏览器中可以通过清理缓存来清楚ETag数据。
9、web 存储
一些web浏览器支持持久化机制,允许页面本地存储信息以后使用。
HTML5标准(绝大多数现代浏览器在某种程度上都支持)包含了一个Javascript API叫做:local storage和session storage。local storage的行为和持久化cookie类似,而session storage的行为和session cookie的行为类似,也就是session storage是绑定在一个单独的tab或者窗口的生命周期中的(也就是页面session),而session cookie是针对整个浏览器的。
IE支持在浏览器历史中持久化信息,在浏览器的收藏夹中,以一个XML格式存储,或者直接在页面中存储到硬盘。
一些web浏览器插件也包含持久化机制。例如Flash有Local shared object,Silverlight有 Isolated storage。
10、浏览器缓存
浏览器缓存也可以用来存储信息,利用这些信息也可以用来追踪用户。这项技术利用的真相是当浏览器判断出来缓存的已经是最新资源时可以利用缓存而不是重新从站点下载。
例如,一个站点托管了一个js文件,这个js文件可以给用户指定一个唯一标识(例如,var userId=3243242)。只要用户访问之后,每次用户再访问这个页面时,这个文件都会从缓存中获取而不是从服务端获取。所以它的内容永远不会变。
天我们就来全面了解一下Cookie(小饼干)以及相关的知识!
相信很多同学肯定听过Cookie这个东西,也大概了解其作用,但是其原理以及如何设置,可能没有做过web的同学并不是非常清楚,那今天猪哥就带大家详细了解下Cookie相关的知识!
一、诞生背景
爬虫系列教程的第一篇:HTTP详解中我们便说过HTTP的五大特点,而其中之一便是:无状态
HTTP无状态:服务器无法知道两个请求是否来自同一个浏览器,即服务器不知道用户上一次做了什么,每次请求都是完全相互独立。
早期互联网只是用于简单的浏览文档信息、查看黄页、门户网站等等,并没有交互这个说法。但是随着互联网慢慢发展,宽带、服务器等硬件设施已经得到很大的提升,互联网允许人们可以做更多的事情,所以交互式Web慢慢兴起,而HTTP无状态的特点却严重阻碍其发展!
交互式Web:客户端与服务器可以互动,如用户登录,购买商品,各种论坛等等
不能记录用户上一次做了什么,怎么办?聪明的程序员们就开始思考:怎么样才能记录用户上一次的操作信息呢?于是有人就想到了隐藏域。
隐藏域写法:<input type="hidden" name="field_name" value="value">
这样把用户上一次操作记录放在form表单的input中,这样请求时将表单提交不就知道上一次用户的操作,但是这样每次都得创建隐藏域而且得赋值太麻烦,而且容易出错!
ps:隐藏域作用强大,时至今日都有很多人在用它解决各种问题!
网景公司当时一名员工Lou Montulli(卢-蒙特利),在1994年将“cookies”的概念应用于网络通信,用来解决用户网上购物的购物车历史记录,而当时最强大的浏览器正是网景浏览器,在网景浏览器的支持下其他浏览器也渐渐开始支持Cookie,到目前所有浏览器都支持Cookie了
二、Cookie是什么
前面我们已经知道了Cookie的诞生是为了解决HTTP无状态的特性无法满足交互式web,那它究竟是什么呢?
上图是在Chrome浏览器中的百度首页的Cookies(Cookie的复数形式),在表格中,每一行都代表着一个Cookie,所以我们来看看Cookie的定义吧!
Cookie是由服务器发给客户端的特殊信息,而这些信息以文本文件的方式存放在客户端,然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息,用于服务器记录客户端的状态。
Cookie主要用于以下三个方面:
三、Cookie原理
我们在了解了Cookie是由服务器发出存储在浏览器的特殊信息,那具体是怎么样的一个过程呢?为了大家便于理解,就以用户登录为例子为大家画了一幅Cookie原理图
用户在输入用户名和密码之后,浏览器将用户名和密码发送给服务器,服务器进行验证,验证通过之后将用户信息加密后封装成Cookie放在请求头中返回给浏览器。
HTTP/1.1 200 OK Content-type: text/html Set-Cookie: user_cookie=Rg3vHJZnehYLjVg7qi3bZjzg; Expires=Tue, 15 Aug 2019 21:47:38 GMT; Path=/; Domain=.169it.com; HttpOnly [响应体]
浏览器收到服务器返回数据,发现请求头中有一个:Set-Cookie,然后它就把这个Cookie保存起来,下次浏览器再请求服务器的时候,会把Cookie也放在请求头中传给服务器:
GET /sample_page.html HTTP/1.1 Host: www.example.org Cookie: user_cookie=Rg3vHJZnehYLjVg7qi3bZjzg
服务器收到请求后从请求头中拿到cookie,然后解析并到用户信息,说明此用户已登录,Cookie是将数据保存在客户端的。
这里我们可以看到,用户信息是保存在Cookie中,也就相当于是保存在浏览器中,那就说用户可以随意修改用户信息,这是一种不安全的策略!
强调一点:Cookie无论是服务器发给浏览器还是浏览器发给服务器,都是放在请求头中的!
四、Cookie属性
下图中我们可以看到一个Cookie有:Name、Value、Domain、Path、Expires/Max-Age、Size、HTTP、Secure这些属性,那这些属性分别都有什么作用呢?我们来看看
1. Name&Value
Name表示Cookie的名称,服务器就是通过name属性来获取某个Cookie值。
Value表示Cookie 的值,大多数情况下服务器会把这个value当作一个key去缓存中查询保存的数据。
2.Domain&Path
Domain表示可以访问此cookie的域名,下图我们以百度贴吧页的Cookie来讲解一下Domain属性。
从上图中我们可以看出domain有:.baidu.com 顶级域名和.teiba.baidu.com的二级域名,所以这里就会有一个访问规则:顶级域名只能设置或访问顶级域名的Cookie,二级及以下的域名只能访问或设置自身或者顶级域名的Cookie,所以如果要在多个二级域名中共享Cookie的话,只能将Domain属性设置为顶级域名!
Path表示可以访问此cookie的页面路径。比如path=/test,那么只有/test路径下的页面可以读取此cookie。
3.Expires/Max-Age
Expires/Max-Age表示此cookie超时时间。若设置其值为一个时间,那么当到达此时间后,此cookie失效。不设置的话默认值是Session,意思是cookie会和session一起失效。当浏览器关闭(不是浏览器标签页,而是整个浏览器) 后,此cookie失效。
提示:当Cookie的过期时间被设定时,设定的日期和时间只与客户端相关,而不是服务端。
4.Size
Size表示Cookie的name+value的字符数,比如有一个Cookie:id=666,那么Size=2+3=5 。
另外每个浏览器对Cookie的支持都不相同
5.HTTP
HTTP表示cookie的httponly属性。若此属性为true,则只有在http请求头中会带有此cookie的信息,而不能通过document.cookie来访问此cookie。
设计该特征意在提供一个安全措施来帮助阻止通过Javascript发起的跨站脚本攻击(XSS)窃取cookie的行为
6.Secure
Secure表示是否只能通过https来传递此条cookie。不像其它选项,该选项只是一个标记并且没有其它的值。
这种cookie的内容意指具有很高的价值并且可能潜在的被破解以纯文本形式传输。
五、Python操作Cookie
1.生成Cookie
前面我们说过Cookie是由服务端生成的,那如何用Python代码来生成呢?
从上图登录代码中我们看到,在简单的验证用户名和密码之后,服务器跳转到/user,然后set了一个cookie,浏览器收到响应后发现请求头中有一个:Cookie: user_cookie=Rg3vHJZnehYLjVg7qi3bZjzg,然后浏览器就会将这个Cookie保存起来!
2.获取Cookie
最近我们一直在讲requests模块,这里我们就用requests模块来获取Cookie。
r.cookies表示获取所有cookie,get_dict()函数表示返回的是字典格式cookie。
3.设置Cookie
上篇我们爬取优酷弹幕的文章中便是用了requests模块设置Cookie
我们就浏览器复制过来的Cookie放在代码中,这样便可以顺利的伪装成浏览器,然后正常爬取数据,复制Cookie是爬虫中常用的一种手段!
六、Session
1.诞生背景
其实在Cookie设计之初,并不像猪哥讲的那样Cookie只保存一个key,而是直接保存用户信息,刚开始大家认为这样用起来很爽,但是由于cookie 是存在用户端,而且它本身存储的尺寸大小也有限,最关键是用户可以是可见的,并可以随意的修改,很不安全。那如何又要安全,又可以方便的全局读取信息呢?于是,这个时候,一种新的存储会话机制:Session 诞生了。
2.Session是什么
Session翻译为会话,服务器为每个浏览器创建的一个会话对象,浏览器在第一次请求服务器,服务器便会为这个浏览器生成一个Session对象,保存在服务端,并且把Session的Id以cookie的形式发送给客户端浏览,而以用户显式结束或session超时为结束。
我们来看看Session工作原理:
对于session标识号(sessionID),有两种方式实现:Cookie和URL重写,猪哥就以Cookie的实现方式画一个Session原理图
联系cookie原理图我们可以看到,Cookie是将数据直接保存在客户端,而Session是将数据保存在服务端,就安全性来讲Session更好!
3.Python操作Session
后面猪哥将会以登录的例子来讲解如何用Python代码操作Session
七、面试场景
1.Cookie和Session关系
2.Cookie带来的安全性问题
八、总结
今天为大家讲解了Cookie的相关知识,以及如何使用requests模块操作Cookie,最后顺便提了一下Cookie与Session的关系以及Cookie存在哪些安全问题。希望大家能对Cookie(小饼干)能有个全面的了解,这样对你在今后的爬虫学习中会大有裨益!
关注微信公众号:安徽思恒信息科技有限公司,了解更多技术内容……
注于Java领域优质技术,欢迎关注
作者:涤生_Woo
本篇文章篇幅比较长,先来个思维导图预览一下。
一张图带你看完本篇文章
1.计算机网络体系结构分层
计算机网络体系结构分层
2.TCP/IP 通信传输流
利用 TCP/IP 协议族进行网络通信时,会通过分层顺序与对方进行通信。发送端从应用层往下走,接收端则从链路层往上走。如下:
TCP/IP 通信传输流
如下图所示:
HTTP 请求
在网络体系结构中,包含了众多的网络协议,这篇文章主要围绕 HTTP 协议(HTTP/1.1版本)展开。
HTTP协议(HyperText Transfer Protocol,超文本传输协议)是用于从WWW服务器传输超文本到本地浏览器的传输协议。它可以使浏览器更加高效,使网络传输减少。它不仅保证计算机正确快速地传输超文本文档,还确定传输文档中的哪一部分,以及哪部分内容首先显示(如文本先于图形)等。 HTTP是客户端浏览器或其他程序与Web服务器之间的应用层通信协议。在Internet上的Web服务器上存放的都是超文本信息,客户机需要通过HTTP协议传输所要访问的超文本信息。HTTP包含命令和传输信息,不仅可用于Web访问,也可以用于其他因特网/内联网应用系统之间的通信,从而实现各类应用资源超媒体访问的集成。 我们在浏览器的地址栏里输入的网站地址叫做URL (Uniform Resource Locator,统一资源定位符)。就像每家每户都有一个门牌地址一样,每个网页也都有一个Internet地址。当你在浏览器的地址框中输入一个URL或是单击一个超级链接时,URL就确定了要浏览的地址。浏览器通过超文本传输协议(HTTP),将Web服务器上站点的网页代码提取出来,并翻译成漂亮的网页。
HTTP请求响应模型
HTTP通信机制是在一次完整的 HTTP 通信过程中,客户端与服务器之间将完成下列7个步骤:
1 建立 TCP 连接
在HTTP工作开始之前,客户端首先要通过网络与服务器建立连接,该连接是通过 TCP 来完成的,该协议与 IP 协议共同构建 Internet,即著名的 TCP/IP 协议族,因此 Internet 又被称作是 TCP/IP 网络。HTTP 是比 TCP 更高层次的应用层协议,根据规则,只有低层协议建立之后,才能进行高层协议的连接,因此,首先要建立 TCP 连接,一般 TCP 连接的端口号是80;
2 客户端向服务器发送请求命令
一旦建立了TCP连接,客户端就会向服务器发送请求命令;
例如:GET/sample/hello.jsp HTTP/1.1
3 客户端发送请求头信息
客户端发送其请求命令之后,还要以头信息的形式向服务器发送一些别的信息,之后客户端发送了一空白行来通知服务器,它已经结束了该头信息的发送;
4 服务器应答
客户端向服务器发出请求后,服务器会客户端返回响应;
例如: HTTP/1.1 200 OK
响应的第一部分是协议的版本号和响应状态码
5 服务器返回响应头信息
正如客户端会随同请求发送关于自身的信息一样,服务器也会随同响应向用户发送关于它自己的数据及被请求的文档;
6 服务器向客户端发送数据
服务器向客户端发送头信息后,它会发送一个空白行来表示头信息的发送到此为结束,接着,它就以 Content-Type 响应头信息所描述的格式发送用户所请求的实际数据;
7 服务器关闭 TCP 连接
一般情况下,一旦服务器向客户端返回了请求数据,它就要关闭 TCP 连接,然后如果客户端或者服务器在其头信息加入了这行代码 Connection:keep-alive ,TCP 连接在发送后将仍然保持打开状态,于是,客户端可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间,还节约了网络带宽。
1.通过请求和响应的交换达成通信
应用 HTTP 协议时,必定是一端担任客户端角色,另一端担任服务器端角色。仅从一条通信线路来说,服务器端和客服端的角色是确定的。HTTP 协议规定,请求从客户端发出,最后服务器端响应该请求并返回。换句话说,肯定是先从客户端开始建立通信的,服务器端在没有接收到请求之前不会发送响应。
2.HTTP 是不保存状态的协议
HTTP 是一种无状态协议。协议自身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个级别,协议对于发送过的请求或响应都不做持久化处理。这是为了更快地处理大量事务,确保协议的可伸缩性,而特意把 HTTP 协议设计成如此简单的。
可是随着 Web 的不断发展,我们的很多业务都需要对通信状态进行保存。于是我们引入了 Cookie 技术。有了 Cookie 再用 HTTP 协议通信,就可以管理状态了。
3.使用 Cookie 的状态管理
Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息,通知客户端保存Cookie。当下次客户端再往该服务器发送请求时,客户端会自动在请求报文中加入 Cookie 值后发送出去。服务器端发现客户端发送过来的 Cookie 后,会去检查究竟是从哪一个客户端发来的连接请求,然后对比服务器上的记录,最后得到之前的状态信息。
Cookie 的流程
4.请求 URI 定位资源
HTTP 协议使用 URI 定位互联网上的资源。正是因为 URI 的特定功能,在互联网上任意位置的资源都能访问到。
5.告知服务器意图的 HTTP 方法(HTTP/1.1)
HTTP 方法
6.持久连接
HTTP 协议的初始版本中,每进行一个 HTTP 通信都要断开一次 TCP 连接。比如使用浏览器浏览一个包含多张图片的 HTML 页面时,在发送请求访问 HTML 页面资源的同时,也会请求该 HTML 页面里包含的其他资源。因此,每次的请求都会造成无畏的 TCP 连接建立和断开,增加通信量的开销。
为了解决上述 TCP 连接的问题,HTTP/1.1 和部分 HTTP/1.0 想出了持久连接的方法。其特点是,只要任意一端没有明确提出断开连接,则保持 TCP 连接状态。旨在建立一次 TCP 连接后进行多次请求和响应的交互。在 HTTP/1.1 中,所有的连接默认都是持久连接。
7.管线化
持久连接使得多数请求以管线化方式发送成为可能。以前发送请求后需等待并接收到响应,才能发送下一个请求。管线化技术出现后,不用等待亦可发送下一个请求。这样就能做到同时并行发送多个请求,而不需要一个接一个地等待响应了。
比如,当请求一个包含多张图片的 HTML 页面时,与挨个连接相比,用持久连接可以让请求更快结束。而管线化技术要比持久连接速度更快。请求数越多,时间差就越明显。
1.HTTP 报文
用于 HTTP 协议交互的信息被称为 HTTP 报文。请求端(客户端)的 HTTP 报文叫做请求报文;响应端(服务器端)的叫做响应报文。HTTP 报文本身是由多行(用 CR+LF 作换行符)数据构成的字符串文本。
2.HTTP 报文结构
HTTP 报文大致可分为报文首部和报文主体两部分。两者由最初出现的空行(CR+LF)来划分。通常,并不一定有报文主体。如下:
HTTP 报文结构
2.1请求报文结构
请求报文结构
请求报文的首部内容由以下数据组成:
请求报文的示例,如下:
请求报文示例
2.2响应报文结构
响应报文结构
响应报文的首部内容由以下数据组成:
响应报文的示例,如下:
响应报文示例
1.请求行
举个栗子,下面是一个 HTTP 请求的报文:
GET /index.htm HTTP/1.1 Host: sample.com
其中,下面的这行就是请求行,
GET /index.htm HTTP/1.1
综合来看,大意是请求访问某台 HTTP 服务器上的 /index.htm 页面资源。
2.状态行
同样举个栗子,下面是一个 HTTP 响应的报文:
HTTP/1.1 200 OK Date: Mon, 10 Jul 2017 15:50:06 GMT Content-Length: 256 Content-Type: text/html <html> ...
其中,下面的这行就是状态行,
HTTP/1.1 200 OK
1.首部字段概述
先来回顾一下首部字段在报文的位置,HTTP 报文包含报文首部和报文主体,报文首部包含请求行(或状态行)和首部字段。
在报文众多的字段当中,HTTP 首部字段包含的信息最为丰富。首部字段同时存在于请求和响应报文内,并涵盖 HTTP 报文相关的内容信息。使用首部字段是为了给客服端和服务器端提供报文主体大小、所使用的语言、认证信息等内容。
2.首部字段结构
3.首部字段类型
首部字段根据实际用途被分为以下4种类型:
4.通用首部字段(HTTP/1.1)
4.1 Cache-Control
通过指定首部字段 Cache-Control 的指令,就能操作缓存的工作机制。
4.1.1 可用的指令一览
可用的指令按请求和响应分类如下:
缓存请求指令
缓存响应指令
4.1.2 表示能否缓存的指令
public 指令
Cache-Control: public
当指定使用 public 指令时,则明确表明其他用户也可利用缓存。
private 指令
Cache-Control: private
当指定 private 指令后,响应只以特定的用户作为对象,这与 public 指令的行为相反。缓存服务器会对该特定用户提供资源缓存的服务,对于其他用户发送过来的请求,代理服务器则不会返回缓存。
no-cache 指令
Cache-Control: no-cache
Cache-Control: no-cache=Location
由服务器返回的响应中,若报文首部字段 Cache-Control 中对 no-cache 字段名具体指定参数值,那么客户端在接收到这个被指定参数值的首部字段对应的响应报文后,就不能使用缓存。换言之,无参数值的首部字段可以使用缓存。只能在响应指令中指定该参数。
no-store 指令
Cache-Control: no-store
当使用 no-store 指令时,暗示请求(和对应的响应)或响应中包含机密信息。因此,该指令规定缓存不能在本地存储请求或响应的任一部分。
注意:no-cache 指令代表不缓存过期的指令,缓存会向源服务器进行有效期确认后处理资源;no-store 指令才是真正的不进行缓存。
4.1.3 指定缓存期限和认证的指令
s-maxage 指令
Cache-Control: s-maxage=604800(单位:秒)
max-age 指令
Cache-Control: max-age=604800(单位:秒)
min-fresh 指令
Cache-Control: min-fresh=60(单位:秒)
min-fresh 指令要求缓存服务器返回至少还未过指定时间的缓存资源。
max-stale 指令
Cache-Control: max-stale=3600(单位:秒)
only-if-cached 指令
Cache-Control: only-if-cached
表示客户端仅在缓存服务器本地缓存目标资源的情况下才会要求其返回。换言之,该指令要求缓存服务器不重新加载响应,也不会再次确认资源的有效性。
must-revalidate 指令
Cache-Control: must-revalidate
使用 must-revalidate 指令,代理会向源服务器再次验证即将返回的响应缓存目前是否仍有效。另外,使用 must-revalidate 指令会忽略请求的 max-stale 指令。
proxy-revalidate 指令
Cache-Control: proxy-revalidate
proxy-revalidate 指令要求所有的缓存服务器在接收到客户端带有该指令的请求返回响应之前,必须再次验证缓存的有效性。
no-transform 指令
Cache-Control: no-transform
使用 no-transform 指令规定无论是在请求还是响应中,缓存都不能改变实体主体的媒体类型。这样做可防止缓存或代理压缩图片等类似操作。
4.1.4 Cache-Control 扩展
Cache-Control: private, community="UCI"
通过 cache-extension 标记(token),可以扩展 Cache-Control 首部字段内的指令。上述 community 指令即扩展的指令,如果缓存服务器不能理解这个新指令,就会直接忽略掉。
4.2 Connection
Connection 首部字段具备以下两个作用:
控制不再转发的首部字段
Connection: Upgrade
在客户端发送请求和服务器返回响应中,使用 Connection 首部字段,可控制不再转发给代理的首部字段,即删除后再转发(即Hop-by-hop首部)。
管理持久连接
Connection: close
HTTP/1.1 版本的默认连接都是持久连接。当服务器端想明确断开连接时,则指定 Connection 首部字段的值为 close。
Connection: Keep-Alive
HTTP/1.1 之前的 HTTP 版本的默认连接都是非持久连接。为此,如果想在旧版本的 HTTP 协议上维持持续连接,则需要指定 Connection 首部字段的值为 Keep-Alive。
4.3 Date
表明创建 HTTP 报文的日期和时间。
Date: Mon, 10 Jul 2017 15:50:06 GMT
HTTP/1.1 协议使用在 RFC1123 中规定的日期时间的格式。
4.4 Pragma
Pragma 首部字段是 HTTP/1.1 版本之前的历史遗留字段,仅作为与 HTTP/1.0 的向后兼容而定义。
Pragma: no-cache
Cache-Control: no-cache Pragma: no-cache
4.5 Trailer
Trailer: Expires
首部字段 Trailer 会事先说明在报文主体后记录了哪些首部字段。可应用在 HTTP/1.1 版本分块传输编码时。
4.6 Transfer-Encoding
Transfer-Encoding: chunked
4.7 Upgrade
Upgrade: TSL/1.0
用于检测 HTTP 协议及其他协议是否可使用更高的版本进行通信,其参数值可以用来指定一个完全不同的通信协议。
4.8 Via
Via: 1.1 a1.sample.com(Squid/2.7)
4.9 Warning
该首部字段通常会告知用户一些与缓存相关的问题的警告。
Warning 首部字段的格式如下:
Warning:[警告码][警告的主机:端口号] "[警告内容]"([日期时间])
最后的日期时间可省略。
HTTP/1.1 中定义了7种警告,警告码对应的警告内容仅推荐参考,另外,警告码具备扩展性,今后有可能追加新的警告码。
5. 请求首部字段(HTTP/1.1)
5.1 Accept
Accept: text/html, application/xhtml+xml, application/xml; q=0.5
5.2 Accept-Charset
Accept-Charset: iso-8859-5, unicode-1-1; q=0.8
Accept-Charset 首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。另外,可一次性指定多种字符集。同样使用 q=[数值] 来表示相对优先级。
5.3 Accept-Encoding
Accept-Encoding: gzip, deflate
Accept-Encoding 首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先顺序,并可一次性指定多种内容编码。同样使用 q=[数值] 来表示相对优先级。也可使用星号(*)作为通配符,指定任意的编码格式。
5.4 Accept-Language
Accept-Lanuage: zh-cn,zh;q=0.7,en=us,en;q=0.3
告知服务器用户代理能够处理的自然语言集(指中文或英文等),以及自然语言集的相对优先级,可一次性指定多种自然语言集。同样使用 q=[数值] 来表示相对优先级。
5.5 Authorization
Authorization: Basic ldfKDHKfkDdasSAEdasd==
告知服务器用户代理的认证信息(证书值)。通常,想要通过服务器认证的用户代理会在接收到返回的 401 状态码响应后,把首部字段 Authorization 加入请求中。共用缓存在接收到含有 Authorization 首部字段的请求时的操作处理会略有差异。
5.6 Expect
Expect: 100-continue
告知服务器客户端期望出现的某种特定行为。
5.7 From
From: Deeson_Woo@163.com
告知服务器使用用户代理的电子邮件地址。
5.8 Host
Host: www.jianshu.com
5.9 If-Match
形如 If-xxx 这种样式的请求首部字段,都可称为条件请求。服务器接收到附带条件的请求后,只有判断指定条件为真时,才会执行请求。
If-Match: "123456"
5.10 If-Modified-Since
If-Modified-Since: Mon, 10 Jul 2017 15:50:06 GMT
5.11 If-None-Match
If-None-Match: "123456"
首部字段 If-None-Match 属于附带条件之一。它和首部字段 If-Match 作用相反。用于指定 If-None-Match 字段值的实体标记(ETag)值与请求资源的 ETag 不一致时,它就告知服务器处理该请求。
5.12 If-Range
If-Range: "123456"
5.13 If-Unmodified-Since
If-Unmodified-Since: Mon, 10 Jul 2017 15:50:06 GMT
首部字段 If-Unmodified-Since 和首部字段 If-Modified-Since 的作用相反。它的作用的是告知服务器,指定的请求资源只有在字段值内指定的日期时间之后,未发生更新的情况下,才能处理请求。如果在指定日期时间后发生了更新,则以状态码 412 Precondition Failed 作为响应返回。
5.14 Max-Forwards
Max-Forwards: 10
通过 TRACE 方法或 OPTIONS 方法,发送包含首部字段 Max-Forwards 的请求时,该字段以十进制整数形式指定可经过的服务器最大数目。服务器在往下一个服务器转发请求之前,Max-Forwards 的值减 1 后重新赋值。当服务器接收到 Max-Forwards 值为 0 的请求时,则不再进行转发,而是直接返回响应。
5.15 Proxy-Authorization
Proxy-Authorization: Basic dGlwOjkpNLAGfFY5
5.16 Range
Range: bytes=5001-10000
5.17 Referer
Referer: http://www.sample.com/index.html
首部字段 Referer 会告知服务器请求的原始资源的 URI。
5.18 TE
TE: gzip, deflate; q=0.5
5.19 User-Agent
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101
6.1 Accept-Ranges
Accept-Ranges: bytes
6.2 Age
Age: 1200
6.3 ETag
ETag: "usagi-1234"
6.4 Location
Location: http://www.sample.com/sample.html
6.5 Proxy-Authenticate
Proxy-Authenticate: Basic realm="Usagidesign Auth"
6.6 Retry-After
Retry-After: 180
6.7 Server
Server: Apache/2.2.6 (Unix) PHP/5.2.5
首部字段 Server 告知客户端当前服务器上安装的 HTTP 服务器应用程序的信息。不单单会标出服务器上的软件应用名称,还有可能包括版本号和安装时启用的可选项。
6.8 Vary
Vary: Accept-Language
6.9 WWW-Authenticate
WWW-Authenticate: Basic realm="Usagidesign Auth"
首部字段 WWW-Authenticate 用于 HTTP 访问认证。它会告知客户端适用于访问请求 URI 所指定资源的认证方案(Basic 或是 Digest)和带参数提示的质询(challenge)。
7. 实体首部字段(HTTP/1.1)
7.1 Allow
Allow: GET, HEAD
7.2 Content-Encoding
Content-Encoding: gzip
7.3 Content-Language
Content-Language: zh-CN
首部字段 Content-Language 会告知客户端,实体主体使用的自然语言(指中文或英文等语言)。
7.4 Content-Length
Content-Length: 15000
首部字段 Content-Length 表明了实体主体部分的大小(单位是字节)。对实体主体进行内容编码传输时,不能再使用 Content-Length首部字段。
7.5 Content-Location
Content-Location: http://www.sample.com/index.html
首部字段 Content-Location 给出与报文主体部分相对应的 URI。和首部字段 Location 不同,Content-Location 表示的是报文主体返回资源对应的 URI。
7.6 Content-MD5
Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==
首部字段 Content-MD5 是一串由 MD5 算法生成的值,其目的在于检查报文主体在传输过程中是否保持完整,以及确认传输到达。
7.7 Content-Range
Content-Range: bytes 5001-10000/10000
针对范围请求,返回响应时使用的首部字段 Content-Range,能告知客户端作为响应返回的实体的哪个部分符合范围请求。字段值以字节为单位,表示当前发送部分及整个实体大小。
7.8 Content-Type
Content-Type: text/html; charset=UTF-8
首部字段 Content-Type 说明了实体主体内对象的媒体类型。和首部字段 Accept 一样,字段值用 type/subtype 形式赋值。参数 charset 使用 iso-8859-1 或 euc-jp 等字符集进行赋值。
7.9 Expires
Expires: Mon, 10 Jul 2017 15:50:06 GMT
7.10 Last-Modified
Last-Modified: Mon, 10 Jul 2017 15:50:06 GMT
首部字段 Last-Modified 指明资源最终修改的时间。一般来说,这个值就是 Request-URI 指定资源被修改的时间。但类似使用 CGI 脚本进行动态数据处理时,该值有可能会变成数据最终修改时的时间。
8. 为 Cookie 服务的首部字段
8.1 Set-Cookie
Set-Cookie: status=enable; expires=Mon, 10 Jul 2017 15:50:06 GMT; path=/;
下面的表格列举了 Set-Cookie 的字段值。
8.1.1 expires 属性
8.1.2 path 属性
Cookie 的 path 属性可用于限制指定 Cookie 的发送范围的文件目录。
8.1.3 domain 属性
8.1.4 secure 属性
Cookie 的 secure 属性用于限制 Web 页面仅在 HTTPS 安全连接时,才可以发送 Cookie。
8.1.5 HttpOnly 属性
8.2 Cookie
Cookie: status=enable
首部字段 Cookie 会告知服务器,当客户端想获得 HTTP 状态管理支持时,就会在请求中包含从服务器接收到的 Cookie。接收到多个 Cookie 时,同样可以以多个 Cookie 形式发送。
9. 其他首部字段
HTTP 首部字段是可以自行扩展的。所以在 Web 服务器和浏览器的应用上,会出现各种非标准的首部字段。
以下是最为常用的首部字段。
9.1 X-Frame-Options
X-Frame-Options: DENY
首部字段 X-Frame-Options 属于 HTTP 响应首部,用于控制网站内容在其他 Web 网站的 Frame 标签内的显示问题。其主要目的是为了防止点击劫持(clickjacking)攻击。首部字段 X-Frame-Options 有以下两个可指定的字段值:
9.2 X-XSS-Protection
X-XSS-Protection: 1
首部字段 X-XSS-Protection 属于 HTTP 响应首部,它是针对跨站脚本攻击(XSS)的一种对策,用于控制浏览器 XSS 防护机制的开关。首部字段 X-XSS-Protection 可指定的字段值如下:
9.3 DNT
DNT: 1
首部字段 DNT 属于 HTTP 请求首部,其中 DNT 是 Do Not Track 的简称,意为拒绝个人信息被收集,是表示拒绝被精准广告追踪的一种方法。首部字段 DNT 可指定的字段值如下:
由于首部字段 DNT 的功能具备有效性,所以 Web 服务器需要对 DNT做对应的支持。
9.4 P3P
P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS IND
首部字段 P3P 属于 HTTP 响应首部,通过利用 P3P(The Platform for Privacy Preferences,在线隐私偏好平台)技术,可以让 Web 网站上的个人隐私变成一种仅供程序可理解的形式,以达到保护用户隐私的目的。
要进行 P3P 的设定,需按以下操作步骤进行:
1. 状态码概述
2. 状态码类别
我们可以自行改变 RFC2616 中定义的状态码或者服务器端自行创建状态码,只要遵守状态码的类别定义就可以了。
3. 常用状态码解析
HTTP 状态码种类繁多,数量达几十种。其中最常用的有以下 14 种,一起来看看。
3.1 200 OK
表示从客户端发来的请求在服务器端被正常处理了。
3.2 204 No Content
3.3 206 Partial Content
表示客户端进行了范围请求,而服务器成功执行了这部分的 GET 请求。响应报文中包含由 Content-Range 首部字段指定范围的实体内容。
3.4 301 Moved Permanently
永久性重定向。表示请求的资源已被分配了新的 URI。以后应使用资源现在所指的 URI。也就是说,如果已经把资源对应的 URI 保存为书签了,这时应该按 Location 首部字段提示的 URI 重新保存。
3.5 302 Found
3.6 303 See Other
3.7 304 Not Modified
3.8 307 Temporary Redirect
临时重定向。该状态码与 302 Found 有着相同的含义。
3.9 400 Bad Request
3.10 401 Unauthorized
3.11 403 Forbidden
表明对请求资源的访问被服务器拒绝了。服务器端没有必要给出详细的拒绝理由,当然也可以在响应报文的实体主体部分对原因进行描述。
3.12 404 Not Found
表明服务器上无法找到请求的资源。除此之外,也可以在服务器端拒绝请求且不想说明理由的时候使用。
3.13 500 Internal Server Error
表明服务器端在执行请求时发生了错误。也可能是 Web 应用存在的 bug 或某些临时的故障。
3.14 503 Service Unavailable
表明服务器暂时处于超负载或正在进行停机维护,现在无法处理请求。如果事先得知解除以上状况需要的时间,最好写入 Retry-After 首部字段再返回给客户端。
1. HTTP 报文实体概述
HTTP 报文结构
大家请仔细看看上面示例中,各个组成部分对应的内容。
接着,我们来看看报文和实体的概念。如果把 HTTP 报文想象成因特网货运系统中的箱子,那么 HTTP 实体就是报文中实际的货物。
我们可以看到,上面示例右图中深红色框的内容就是报文的实体部分,而蓝色框的两部分内容分别就是实体首部和实体主体。而左图中粉红框内容就是报文主体。
通常,报文主体等于实体主体。只有当传输中进行编码操作时,实体主体的内容发生变化,才导致它和报文主体产生差异。
2. 内容编码
内容编码类型:
3. 传输编码
内容编码是对报文的主体进行的可逆变换,是和内容的具体格式细节紧密相关的。
传输编码也是作用在实体主体上的可逆变换,但使用它们是由于架构方面的原因,同内容的格式无关。使用传输编码是为了改变报文中的数据在网络上传输的方式。
内容编码和传输编码的对比
4. 分块编码
分块编码把报文分割成若干已知大小的块。块之间是紧挨着发送的,这样就不需要在发送之前知道整个报文的大小了。分块编码是一种传输编码,是报文的属性。
分块编码与持久连接
若客户端与服务器端之间不是持久连接,客户端就不需要知道它在读取的主体的长度,而只需要读取到服务器关闭主体连接为止。
当使用持久连接时,在服务器写主体之前,必须知道它的大小并在 Content-Length 首部中发送。如果服务器动态创建内容,就可能在发送之前无法知道主体的长度。
分块编码为这种困难提供了解决方案,只要允许服务器把主体分块发送,说明每块的大小就可以了。因为主体是动态创建的,服务器可以缓冲它的一部分,发送其大小和相应的块,然后在主体发送完之前重复这个过程。服务器可以用大小为 0 的块作为主体结束的信号,这样就可以继续保持连接,为下一个响应做准备。
来看看一个分块编码的报文示例:
分块编码的报文
5.多部分媒体类型
MIME 中的 multipart(多部分)电子邮件报文中包含多个报文,它们合在一起作为单一的复杂报文发送。每一部分都是独立的,有各自的描述其内容的集,不同部分之间用分界字符串连接在一起。
相应得,HTTP 协议中也采纳了多部分对象集合,发送的一份报文主体内可包含多种类型实体。
多部分对象集合包含的对象如下:
6. 范围请求
假设你正在下载一个很大的文件,已经下了四分之三,忽然网络中断了,那下载就必须重头再来一遍。为了解决这个问题,需要一种可恢复的机制,即能从之前下载中断处恢复下载。要实现该功能,这就要用到范围请求。
有了范围请求, HTTP 客户端可以通过请求曾获取失败的实体的一个范围(或者说一部分),来恢复下载该实体。当然这有一个前提,那就是从客户端上一次请求该实体到这一次发出范围请求的时间段内,该对象没有改变过。例如:
GET /bigfile.html HTTP/1.1 Host: www.sample.com Range: bytes=20224- ···
实体范围请求示例
上面示例中,客户端请求的是文档开头20224字节之后的部分。
HTTP 通信时,除客户端和服务器外,还有一些用于协助通信的应用程序。如下列出比较重要的几个:代理、缓存、网关、隧道、Agent 代理。
1.代理
代理
HTTP 代理服务器是 Web 安全、应用集成以及性能优化的重要组成模块。代理位于客户端和服务器端之间,接收客户端所有的 HTTP 请求,并将这些请求转发给服务器(可能会对请求进行修改之后再进行转发)。对用户来说,这些应用程序就是一个代理,代表用户访问服务器。
出于安全考虑,通常会将代理作为转发所有 Web 流量的可信任中间节点使用。代理还可以对请求和响应进行过滤,安全上网或绿色上网。
2. 缓存
浏览器第一次请求:
浏览器第一次请求
浏览器再次请求:
浏览器再次请求
Web 缓存或代理缓存是一种特殊的 HTTP 代理服务器,可以将经过代理传输的常用文档复制保存起来。下一个请求同一文档的客户端就可以享受缓存的私有副本所提供的服务了。客户端从附近的缓存下载文档会比从远程 Web 服务器下载快得多。
3. 网关
HTTP / FTP 网关
网关是一种特殊的服务器,作为其他服务器的中间实体使用。通常用于将 HTTP 流量转换成其他的协议。网关接收请求时就好像自己是资源的源服务器一样。客户端可能并不知道自己正在跟一个网关进行通信。
4. 隧道
HTTP/SSL 隧道
隧道是会在建立起来之后,就会在两条连接之间对原始数据进行盲转发的 HTTP 应用程序。HTTP 隧道通常用来在一条或多条 HTTP 连接上转发非 HTTP 数据,转发时不会窥探数据。
HTTP 隧道的一种常见用途就是通过 HTTP 连接承载加密的安全套接字层(SSL)流量,这样 SSL 流量就可以穿过只允许 Web 流量通过的防火墙了。
5. Agent 代理
自动搜索引擎“网络蜘蛛”
Agent 代理是代表用户发起 HTTP 请求的客户端应用程序。所有发布 Web 请求的应用程序都是 HTTP Agent 代理。
来源:简书 链接:https://www.jianshu.com/p/6e9e4156ece3
*请认真填写需求信息,我们会在24小时内与您取得联系。