HTTP Cookie
HTTP协议本身是无状态,无连接的。
无状态是指,客户每次发起请求,服务器都不认识客户是谁,它只会根据请求返回对应的资源响应。
无连接不是指TCP的无连接,通常指的是HTTP协议本身不在请求和响应之间维护任何状态(这是无状态的含义),而不是指它不使用TCP连接。HTTP的"无连接"特性更多是指每次请求/响应交换都是独立的,且不需要在请求之间维护连接状态。
定义
HTTP Cookie
(也称为
Web Cookie
、浏览器
Cookie
或简称
Cookie
)是服务器发送到
用户浏览器并保存在浏览器上的一小块数据,它会在浏览器之后向同一服务器再次发
起请求时被携带并发送到服务器上。通常,它用于告知服务端两个请求是否来自同一
浏览器,如保持用户的登录状态、记录用户偏好等。
工作原理
当用户第一次访问网站时,服务器会在响应的
HTTP
头中设置
Set-Cookie
字段,用于发送
Cookie
到用户的浏览器。
○
浏览器在接收到
Cookie
后,会将其保存在本地(通常是按照域名进行存
储)。
○
在之后的请求中,浏览器会自动在
HTTP
请求头中携带
Cookie
字段,将之
前保存的
Cookie
信息发送给服务器。
关于Cookie的分类
会话
Cookie
(
Session Cookie
)
:在浏览器关闭时失效。
○
持久
Cookie
(
Persistent Cookie
)
:带有明确的过期日期或持续时间,
可以跨多个浏览器会话存在。
○
如果
cookie
是一个持久性的
cookie
,那么它其实就是浏览器相关的,特
定目录下的一个文件。但直接查看这些文件可能会看到乱码或无法读取的内容,
因为
cookie
文件通常以二进制或
sqlite
格式存储。一般我们查看,直接在浏览
器对应的选项中直接查看即可。
会话级别其实也就是内存级别,浏览器启动了也是了一个程序,把程序关闭了,和它相关的内存数据自然也就被释放了。
安全性
由于
Cookie
是存储在客户端的,因此存在被篡改或窃取的风险。
用途
用户认证和会话管理
(
最重要
)
○
跟踪用户行为
○
缓存用户偏好等
○
比如在
chrome
浏览器下,可以直接访问:
chrome://settings/cookies
认识Cookie
HTTP
存在一个报头选项:
Set-Cookie
,
可以用来进行给浏览器设置
Cookie
值。
○
在
HTTP
响应头中添加,客户端(如浏览器)获取并自行设置并保存
Cookie
。
基本格式:
Set-Cookie: <name>=<value>
其中 <name> 是 Cookie 的名称,<value> 是 Cookie 的值
一个完整的Cookie格式
Set-Cookie: username=peter; expires=Thu, 18 Dec 2024 12:00:00
UTC; path=/; domain=.example.com; secure; HttpOnly
注意:这只是一个Cookie,在username=peter后跟的都是这一条Cookie的属性。
可以设置多个Cookie,那么就要重新加一条,比如 Set-Cookie:passwd=123;XXXXX
时间格式必须遵守
RFC 1123
标准,具体格式样例:
Tue, 01 Jan 2030 12:34:56
GMT
或者
UTC(
推荐
)
。
计算方式:
GMT
基于地球的自转和公转,而
UTC
基于原子钟。
•
准确度:由于
UTC
基于原子钟,它比基于地球自转的
GMT
更加精确。
在实际使用中,
GMT
和
UTC
之间的差别通常很小,大多数情况下可以互换使用。但
在需要高精度时间计量的场合,如科学研究、网络通信等,
UTC
是更为准确的选择。
关于这些属性的说明:
expires=<date>
[
要验证
]
:设置
Cookie
的过期日期
/
时间。如果未指定此属
性,则
Cookie
默认为会话
Cookie
,即当浏览器关闭时过期。(重要)
○
path=<some_path>
[
要验证
]
:限制
Cookie
发送到服务器的哪些路径。默认
为设置它的路径。(重要)
○
domain=<domain_name>
[
了解即可
]
:指定哪些主机可以接受该
Cookie
。默
认为设置它的主机。
○
secure
[
了解即可
]
:仅当使用
HTTPS
协议时才发送
Cookie
。这有助于防止
Cookie
在不安全的
HTTP
连接中被截获。
HttpOnly
[
了解即可
]
:标记
Cookie
为
HttpOnly
,意味着该
Cookie
不能被
客户端脚本(如
JavaScript
)访问。这有助于防止跨站脚本攻击(
XSS
)
注意事项
每个
Cookie
属性都以分号(
;
)和空格( )分隔。
○
名称和值之间使用等号(
=
)分隔。
○
如果
Cookie
的名称或值包含特殊字符(如空格、分号、逗号等),则需要
进行
URL
编码。
在我们手动设置Cookie属性,在设置时间属性的时候,有一个函数是将时间戳转化成为一个struct tm的结构体,里面有年月日等信息,但是在这里转化函数不能用localtime,要用
struct tm *tm = gmtime(&timeout);
因为localtime是默认自带了时区的,gmtime获取的是统一的UTC统一时间。
Cookie的生命周期
如果设置了
expires
属性,则
Cookie
将在指定的日期
/
时间后过期。
○
如果没有设置
expires
属性,则
Cookie
默认为会话
Cookie
,即当浏览器
关闭时过期
安全性的考虑
使用
secure
标志可以确保
Cookie
仅在
HTTPS
连接上发送,从而提高安
全性。
○
使用
HttpOnly
标志可以防止客户端脚本(如
JavaScript
)访问
Cookie
,
从而防止
XSS
攻击。
然而现在一般都不只是单独使用Cookie了,因为Cookie它也可能会将用户的私密信息,比如浏览记录,账号密码,容易被其他人盗取,如果没有进行加密的话,还有导致这些私密的信息被泄露。
信息被泄露,这才是最严重的。
HTTP session
定义
HTTP Session
是服务器用来跟踪用户与服务器交互期间用户状态的机制。由于
HTTP
协议是无状态的(每个请求都是独立的),因此服务器需要通过
Session
来记住用户
的信息。
浅谈原理
因为Cookie把用户信息保存在客户端,所以信息很容易被泄露。于是就有了如上,用户拿着账号和密码进行登录,服务器验证完信息后,会通过算法形成一个唯一的sessionID,这个sessionID指向了一个session对象,这个对象里面保存的就是用户的账号密码,还有各种用户信息,然后在返回给用户的时候,setCookie就只有一个 sessionID了。
那么用户下次访问,就只需要用sessionID给服务器即可,这样就算用户的数据被盗取了,对方也只能冒充用户登录,用户只需要更改密码,原来的sessionID就失效了,最重要的是用户的信息就不会被泄露了。
并且对于用户被冒充这种情况,服务器其实有很多的解决方法,最简单粗暴的方式就是直接让这个sessionID失效即可。服务器可以通过识别该session的行为,比如它的行为突然变得异常,或者是登录位置突然发生了转变,在识别这是一个异常session后,通过直接释放session对象的方式,直接让sessionID失效。
所以总结:
使用session,可以基本解决用户信息被泄露的问题,因为用户此时的信息已经保存在服务器上了;使用session,可以解决大部分用户被冒充登录的问题,因为服务器可以通过检测session的行为或者登录位置来判断是否是非法session,如果是非法的,那么服务器可以直接让该session失效。
拓展
favicon.ico
是一个网站图标,通常显示在浏览器的标签页上、地址栏旁边或收
藏夹中。这个图标的文件名
favicon
是
"favorite icon"
的缩写,而
.ico
是图标的文
件格式。
•
浏览器在发起请求的时候,也会为了获取图标而专门构建
http 请求,也就是连着发送了两次请求。