关于HTTPS的七个误解

本文澄清了关于HTTPS常见的七个误解,包括HTTPS的缓存能力、SSL证书的成本、HTTPS站点的IP地址需求等,帮助读者深入了解HTTPS的工作原理和技术细节。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

本文详细讨论了关于HTTPS的七个误解,误解内容包括HTTPS无法缓存、SSL证书很贵、HTTPS太慢等等,以下是原文,希望你可以更透彻地了解HTTPS。

HTTPS的七个误解

误解七:HTTPS无法缓存

许多人以为,出于安全考虑,浏览器不会在本地保存HTTPS缓存。实际上,只要在HTTP头中使用特定命令,HTTPS是可以缓存的。

微软的IE项目经理Eric Lawrence写道:

“说来也许令人震惊,只要HTTP头允许这样做,所有版本的IE都缓存HTTPS内容。比如,如果头命令是Cache-Control: max-age=600,那么这个网页就将被IE缓存10分钟。IE的缓存策略,与是否使用HTTPS协议无关。(其他浏览器在这方面的行为不一致,取决于你使用的版本,所以这里不加以讨论。)”

Firefox默认只在内存中缓存HTTPS。但是,只要头命令中有Cache-Control: Public,缓存就会被写到硬盘上。下面的图片显示,Firefox的硬盘缓存中有HTTPS内容,头命令正是Cache-Control:Public。

HTTPS的七个误解

误解六:SSL证书很贵

如果你在网上搜一下,就会发现很多便宜的SSL证书,大概10美元一年,这和一个.com域名的年费差不多。而且事实上,还能找到免费的SSL证书。

在效力上,便宜的证书当然会比大机构颁发的证书差一点,但是几乎所有的主流浏览器都接受这些证书。

误解五:HTTPS站点必须有独享的IP地址

由于IPv4将要分配完毕,所以很多人关心这个问题。每个IP地址只能安装一张SSL证书,这是毫无疑问的。但是,如果你使用子域名通配符SSL证书(wildcard SSL certificate,价格大约是每年125美元),就能在一个IP地址上部署多个HTTPS子域名。比如,https://www.httpwatch.com和https://store.httpwatch.com,就共享同一个IP地址。

HTTPS的七个误解

另外,UCC(统一通信证书,Unified Communications Certificate)支持一张证书同时匹配多个站点,可以是完全不同的域名。SNI(服务器名称指示,Server Name Indication)允许一个IP地址上多个域名安装多张证书。服务器端,Apache和Nginx支持该技术,IIS不支持;客户端,IE 7+、Firefox 2.0+、Chrome 6+、Safari 2.1+和Opera 8.0+支持。

误解四:转移服务器时要购买新证书

部署SSL证书,需要这样几步:

1. 在你的服务器上,生成一个CSR文件(SSL证书请求文件,SSL Certificate Signing Request)。

2. 使用CSR文件,购买SSL证书。

3. 安装SSL证书。

这些步骤都经过精心设计,保证传输的安全,防止有人截取或非法获得证书。结果就是,你在第二步得到的证书不能用在另一台服务器上。如果你需要这样做,就必须以其他格式输出证书。

比如,IIS的做法是生成一个可以转移的.pfx文件,并加以密码保护。

HTTPS的七个误解

将这个文件传入其他服务器,将可以继续使用原来的SSL证书了。

误解三:HTTPS太慢

使用HTTPS不会使你的网站变得更快(实际上有可能,请看下文),但是有一些技巧可以大大减少额外开销。

首先,只要压缩文本内容,就会降低解码耗用的CPU资源。不过,对于当代CPU来说,这点开销不值一提。

其次,建立HTTPS连接,要求额外的TCP往返,因此会新增一些发送和接收的字节。但是,从下图可以看到,新增的字节是很少的。

HTTPS的七个误解

第一次打开网页的时候,HTTPS协议会比HTTP协议慢一点,这是因为读取和验证SSL证书的时间。下面是一张HTTP网页打开时间的瀑布图。

HTTPS的七个误解

同一张网页使用HTTPS协议之后,打开时间变长了。

HTTPS的七个误解

建立连接的部分,大约慢了10%。但是,一旦有效的HTTPS连接建立起来,再刷新网页,两种协议几乎没有区别。先是HTTP协议的刷新表现:

HTTPS的七个误解

然后是HTTPS协议:

HTTPS的七个误解

某些用户可能发现,HTTPS比HTTP更快一点。这会发生在一些大公司的内部局域网,因为通常情况下,公司的网关会截取并分析所有的网络通信。但是,当它遇到HTTPS连接时,它就只能直接放行,因为HTTPS无法被解读。正是因为少了这个解读的过程,所以HTTPS变得比较快。

误解二:有了HTTPS,Cookie和查询字符串就安全了

虽然无法直接从HTTPS数据中读取Cookie和查询字符串,但是你仍然需要使它们的值变得难以预测。

比如,曾经有一家英国银行,直接使用顺序排列的数值表示session id:

HTTPS的七个误解

黑客可以先注册一个账户,找到这个cookie,看到这个值的表示方法。然后,改动cookie,从而劫持其他人的session id。至于查询字符串,也可以通过类似方式泄漏。

误解一:只有注册登录页,才需要HTTPS

这种想法很普遍。人们觉得,HTTPS可以保护用户的密码,此外就不需要了。Firefox浏览器新插件Firesheep,证明了这种想法是错的。我们可以看到,在Twitter和Facebook上,劫持其他人的session是非常容易的。

咖啡馆的免费WiFi,就是一个很理想的劫持环境,因为两个原因:

1. 这种WiFi通常不会加密,所以很容易监控所有流量。

2. WiFi通常使用NAT进行外网和内网的地址转换,所有内网客户端都共享一个外网地址。这意味着,被劫持的session,看上去很像来自原来的登录者。

以Twitter为例,它的登录页使用了HTTPS,但是登录以后,其他页面就变成了HTTP。这时,它的cookie里的session值就暴露了。

HTTPS的七个误解

也就是说,这些cookie是在HTTPS环境下建立的,但是却在HTTP环境下传输。如果有人劫持到这些cookie,那他就能以你的身份在Twitter上发言了。

<think>好的,用户问的是多个URL之间用什么分隔符不容易误解。首先,我得回忆一下URL的标准格式和相关规范。URL本身有一些保留字符,比如分号、逗号、斜杠等,这些字符在URL的不同部分有特定的用途。比如逗号有时会被用在路径或参数中,所以如果用逗号分隔多个URL,可能会导致解析错误。 然后想到常见的分隔符,比如空格、逗号、分号、换行符或者制表符。不过空格可能不太可靠,因为URL本身可能包含编码的空格(比如%20),或者用户可能不小心输入了多个空格,导致解析困难。接下来是逗号,但之前提到的,逗号在URL中可能有特殊含义,特别是在查询参数里,可能会被误解。 分号呢?分号在URL的路径部分有时用来分隔参数,比如在有些RESTful API设计中,但相对少见。不过根据RFC 3986,分号属于保留字符,可以作为分隔符,但实际使用中可能不如其他符号常见。换行符或者制表符作为分隔符的话,可能在文本环境中有效,比如在纯文本文件中,每个URL单独一行,但在某些上下文(比如URL列表作为HTTP头字段的值)中,可能需要特定的分隔符。 再想想,HTTP头中的Link字段用的是逗号分隔,不过每个URL会用尖括号包裹,这样即使有逗号在URL内部,也不会被误解。例如:<url1>, <url2>。这可能是一个可靠的方法,但需要额外的符号包裹URL。 另外,用户可能是在问如何在普通文本中分隔多个URL,比如在电子邮件、文档或者表单输入中。这时候常见的做法可能是用换行符,每个URL单独一行,这样清晰明了,不容易混淆。不过如果必须在一行内分隔,可能需要选择不常用的字符作为分隔符,比如竖线“|”或者分号“;”,前提是确保这些字符不在URL中出现。 不过根据标准,URL中允许的字符是有限的,一些字符如“!”、“$”、“&”、“’”、“(”、“)”、“*”、“+”、“,”、“;”、“=”等在不同的部分有不同用途。比如“&”通常用来分隔查询参数,所以如果在多个URL之间使用“&”作为分隔符,显然不合适。分号虽然属于保留字符,但在实际使用中较少出现在URL路径或参数中,可能相对安全。 再查一下相关资料,例如,在URI的通用格式中,分号有时用于路径参数,但这种情况现在比较少见。因此,使用分号作为分隔符可能比逗号更安全,因为逗号在URL中的出现概率更高,比如在查询字符串中分隔多个值。 此外,有些系统或框架可能有自己的约定。例如,在JavaScript中,split方法可以用分号来分割字符串中的多个URL,只要确保URL内部不含分号即可。或者,如果用户需要将多个URL放在一个参数中传递,通常会进行URL编码,然后用特定的分隔符,但需要客户端和服务器端一致处理。 总结下来,可能的解决方案有: 1. 使用换行符分隔,每个URL单独一行,适合多行文本环境。 2. 使用分号“;”分隔,前提是确认URL内不含分号。 3. 使用竖线“|”或其他不常用字符,但需确保这些字符不在URL中出现。 4. 遵循特定标准,如HTTP头中的做法,用逗号分隔并用尖括号包裹每个URL。 需要根据具体的使用场景来决定最合适的分隔符。如果是在代码或配置文件中,可能需要参考相关规范或框架的建议;如果是在用户输入的文本中,换行符可能是最直观且不易出错的选择。</think>多个URL的分隔符选择需避免与URL内部字符冲突。以下是可靠的分隔方式及注意事项: --- ### **1. 推荐分隔符** #### **(1)换行符(`\n`)** - **优点**:直观清晰,每个URL单独成行,不易混淆。 - **适用场景**:文本文件、表单输入、配置文件等。 - **示例**: ``` https://example.com/page1 https://example.com/page2 ``` #### **(2)分号(`;`)** - **优点**:在URL中较少出现(仅用于路径参数,但极少见),冲突概率低。 - **注意事项**:需确保URL内不含分号。 - **示例**: ``` https://example.com/page1;https://example.com/page2 ``` #### **(3)竖线(`|`)** - **优点**:不属于URL保留字符,安全性较高。 - **注意事项**:需统一约定解析规则。 - **示例**: ``` https://example.com/page1|https://example.com/page2 ``` --- ### **2. 需谨慎使用的分隔符** - **逗号(`,`)**: 常见于URL查询参数(如`?id=1,2,3`),易引发歧义。 - **空格**: URL可能包含编码空格(`%20`),导致解析错误。 - **`&` 或 `?`**: 属于URL保留字符(分隔参数),绝对避免使用。 --- ### **3. 标准化方案(HTTP协议参考)** 在HTTP头(如`Link`字段)中,使用 **逗号分隔 + 尖括号包裹**,避免歧义: ``` Link: <https://example.com/page1>; rel="preload", <https://example.com/page2>; rel="stylesheet" ``` - **优点**:明确区分URL与分隔符。 - **适用场景**:需严格解析的场景(如API、爬虫)。 --- ### **总结** - **优先推荐**:换行符(多行环境)或分号(单行环境)。 - **避免使用**:逗号、空格、`&`、`?`等易冲突字符。 - **复杂场景**:参考HTTP标准,用尖括号包裹URL并用逗号分隔。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值