URL

URL 代表着是对立资源定位符（ Uniform Resource Locator ）。和 Hypertext 以及 HTTP 一样，是 Web 中的一个外围概念。它是浏览器用来检索 web 上公布的任何资源的机制。

URL 无非就是一个给定的独特资源在 Web 上的地址。实践上说，每个无效的 URL 都指向一个惟一的资源。这个资源能够是一个 HTML 页面，一个 CSS 文档，一幅图像，等等。而在理论中，也有一些例外，最常见的状况就是一个 URL 指向了不存在的或是被挪动过的资源。因为通过 URL 出现的资源和 URL 自身由 Web 服务器解决，因而 web 服务器的拥有者须要认真地保护资源以及与它关联的 URL。

上面是一个规范的 URL 示例：

http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument

它含有以下几局部：(参考链接：https://url.spec.whatwg.org/#…)

备注：
url 标准和 web url 比拟起来存在一些差别（命名上），前面解说时会尽量做出辨别

scheme 计划

http 是计划也是协定。在 web 中，它也代表了协定，表明了浏览器必须应用何种通信协议协定，通常都是 HTTP 协定或是 HTTP 协定平安版（即 HTTPS）。Web 须要它们二者之一，但浏览器能解决其余协定，比方mailto:（关上邮件客户端）或者 `ftp:（解决文件传输），所以当你这些协定时，不用诧异。`

scheme 和 protocol 的区别

URL 不蕴含协定，但蕴含计划 [[1]](https://en.wikipedia.org/wiki…)。计划能够与协定相关联，但不是必须的。

例如，在示例中，该 http: 计划与 HTTP/1.0 或 1.1 协定 [[2]](https://www.w3.org/2001/tag/d…)file:相关联，但该计划不与任何协定相关联。http是计划和协定，而 file 是计划但不是协定。

常见的 scheme&port 对应关系如下

阐明：
在 web 场景中，更多的会应用 protocal（例如：location.protocol），如果看到协定，能够 等价视为 scheme

host 主机地址

host 能够是 ip 或者域名，在示例中的www.example.com 是域名。它表明正在申请哪个 Web 服务器，也能够间接应用 IP address, 但因为它不太不便，所以不常常在网络上应用。

一个域名蕴含几局部，可能是一部分、两局部、三局部等等，每个局部被 . 宰割，不同于咱们失常的输出程序，它须要 从右到左 进行浏览

常见的域名如下下：

域名的每一部分都提供着特定信息。

TLD (en-US)”)（Top-Level Domain，顶级域名）

顶级域名能够通知用户 域名所提供的的 服务类型 。
最通用的顶级域名（.com, .org, .net）不须要 web 服务器满足严格的规范，但一些顶级域名确须要执行更严格的政策。比方：

• 地区的顶级域名，如 .cn，.us，.fr 或.sh，要求必须提供给定语言的服务器或者托管在指定国家。这些 TLD 通常表明对应的网页服务从属于何种语言或哪个地区。
• 蕴含 .gov 的顶级域名只能被政府部门应用。
• .edu只能为教育或钻研机构应用。

顶级域名既能够蕴含拉丁字母，也能够蕴含特殊字符。顶级域名最长能够达到 63 个字符，不过为了使用方便，大多数顶级域名都是两到三个字符。

顶级域名的残缺列表是 ICANN 保护的。

Label (标签或者组件)

标签都是紧随着 TLD 的。标签由 1 到 63 个大小写 不敏感 的字符组成，这些字符蕴含字母 A -z，数字 0 -9，甚至“-”这个符号（当然，“-”不应该呈现在标签结尾或者标签的结尾）。举几个例子，a，97，或者 hello-strange-person-16-how-are-you  都是非法的标签。

Secondary Level Domain（二级域名）

位于 TLD 后面的标签也被称为二级域名 (SLD)。一个域名能够有多个标签（或者说是组件），没有强制规定必须要 3 个标签来形成域名。例如，www.inf.ed.ac.uk 是一个正确的域名。当领有了“下级”局部(例如 mozilla.org)，你还能够创立另外的域名 (有时被称为 “ 子域名 ”) (例如 developer.mozilla.org).

port 端口

:80 是端口。它示意用于拜访 Web 服务器上的资源的技术“门”。如果 Web 服务器应用 HTTP 协定的规范端口（HTTP 为 80，HTTPS 为 443）来授予其资源的拜访权限，则通常会被疏忽。否则是强制性的。

path 门路

/path/to/myfile.html 是网络服务器上资源的门路。在 Web 的晚期阶段，像这样的门路示意 Web 服务器上的物理文件地位。现在，它没有任何物理意义，仅仅是 Web 服务器中的一个抽象概念，须要关注的是 path 的可了解性

query 查问

?key1=value1&key2=value2 是查问，也可称之为参数（paramters）。这些参数是用 & 符号分隔的键 / 值对列表。在返回资源之前，Web 服务器能够应用这些参数来执行额定的操作。每个 Web 服务器都有本人对于参数的规定，惟一牢靠的形式来晓得特定 Web 服务器是否解决参数是通过询问 Web 服务器所有者。

fragment 片段

在 web 中，更常见的是称之为anchor（锚点）

#SomewhereInTheDocument 是资源自身的一部分。锚点示意资源中的一种“书签”，告知浏览器显示位于该“加书签”地位的内容。例如，在 HTML 文档上，浏览器将滚动到定义锚点的地位；在视频或音频文档上，浏览器将尝试转到锚代表的 工夫。

值得注意的是，#前面的局部（fragment）素来 没有 发送到申请的服务器

origin & site

origin 源

“origin”是 scheme（也称为 协定，例如 HTTP 或 HTTPS 协定）、host 和 port（如果指定）的组合。例如，给定一个 URL https://www.example.com:443/foo，“起源”是https://www.example.com:443。

具备雷同 scheme、host 和port组合的网站被视为“同源 ”（ 即协定、域名、端口号统一 ），其余所有都被视为“ 跨源 ”(也可称之为“ 跨域”)。

同源和跨源

site 站点

“站点”是 TLD 与其之前的域局部的组合。在上面的实例中，给定 URL 为https://www.example.com:443/foo，“站点”为 example.com。

然而很多实在场景下，仅仅应用 TLD 是不够的，例如：.co.jp或者 .github.io，它们的 TLD 是.jp 或者.io，单在这个粒度（TLD）上根本不能标识site，并且无奈通过算法来计算特定 TLD，所以基于 TLD，又提出了effective TLD(eTLD)，它表明了无效的 TLD 定义蕴含哪些（查看定义（公共后缀列表））。eTLDs 列表保护在 publicsuffix.org/list 中。

整个 站点名称 称为 eTLD+1。例如，如果 URL 为 https://my-project.github.io，则 eTLD 为 .github.io 且 eTLD+1 为 my-project.github.io，这被看做“站点”。换句话说，eTLD+1 是无效的 TLD 和它之前的域的一部分

同站和跨站

能够参考如下表格

总结来说就是: 只有域名不同 才属于夸大

schemeful same-site 有打算的同站

传统的 SameSite 实际上只涵盖了域名相干的内容（只有域名不同才属于跨站 ），然而在咱们日常工作中，很容易遇到 https 和 https 相互切换的状况（比方全域降级 https），这个时候很容易留下安全漏洞（HTTP 被用作弱通道），例如：setCookie 时会设置 SameSite=Lax 来避免跨站点申请伪造 (CSRF)。然而，不平安的 HTTP 流量会给网络攻击者提供篡改 cookie 的机会，这些 cookie 随后将用于站点的 HTTPS 场景。

因而 schemeful same-site 应运而生，schemeful same-site 领有更严格的定义。在这种状况下，http://www.example.com和 https://www.example.com 因为计划不匹配被视为跨站点。

如何辨别“同站”vs“跨站”和“同源”vs“跨源”

Chrome76+ 后（特地是 90+ 版本后），平安机制一直发生变化，本地开发会遇到各种神奇的问题（感兴趣或者遇到问题能够私信活留言），能够通过 HTTP request header Sec-Fetch-Site（元数据申请头）进行辨别。

Sec-Fetch-Site截至 2020 年 4 月，尚无其余浏览器反对。这是更大的 Fetch Metadata Request Headers 提案的一部分。申请头具备以下值之一：

• cross-site
• same-site
• same-origin
• none

通过查看 的值 Sec-Fetch-Site，您能够确定申请是“同一站点”、“同源”还是“跨站点”，但遗憾的是 schemeful-same-site 目前在Sec-Fetch-Site 中还不反对

fetch metadata 申请元数据

许多 Web 应用程序容易受到跨域攻打，例如跨站点申请伪造(CSRF)、跨站点脚本蕴含(XSSI)、定时攻打、跨源信息透露 或 Spectre 攻打。

Fetch Metadata 申请头提供了更弱小的防御机制 资源隔离策略 以爱护您的应用程序免受这些常见的跨域攻打。通过在一组Sec-Fetch-* 标头中提供无关 HTTP 申请上下文的信息，它们容许响应服务器在解决申请之前利用安全策略

同源

来自您本人的服务器（同源）服务的站点的申请将持续工作。

跨站

因为 Sec-Fetch-* 标头提供的 HTTP 申请中的附加上下文，服务器可能会回绝歹意跨站点申请。

Sec-Fetch-Site

Sec-Fetch-Site通知服务器哪个站点发送了申请。浏览器将此值设置为以下值之一：

• same-origin，如果申请是由您本人的应用程序提出的（例如site.example）
• same-site, 如果申请是由您网站的子域收回的（例如bar.site.example）
• none, 如果申请是由用户与用户代理的交互（例如点击书签）明确引起的
• cross-site, 如果申请是由另一个网站发送的（例如evil.example）

Sec-Fetch-Mode

Sec-Fetch-Mode批示申请的模式。这大抵对应于申请的类型，并容许您辨别资源负载和导航申请。例如，目的地 navigate 示意顶级导航申请，而 no-cors 示意加载图像等资源申请。

• cors, 该申请是 CORS 协定申请。
• navigate, 该申请由 HTML 文档之间的导航发动。
• no-cors, 该申请是无 cors 申请（请参阅 参考资料Request.mode）。
• same-origin, 该申请与所申请的资源是同一起源。
• websocket, 正在申请建设 WebSocket 连贯。

Sec-Fetch-Dest

Sec-Fetch-Dest用来阐明申请的目的地，也能够看出原始申请的发起者，即在何处（以及如何）应用获取的数据。

Sec-Fetch-Dest
这容许服务器依据申请是否适宜 预期的应用形式 来确定是否为申请提供服务。例如，带有 audio 目的地的申请应该申请音频数据，而不是其余类型的资源（例如，蕴含敏感用户信息的文档）

列举一些常见的值（不齐全）

• audio, 目的地是音频数据。这可能源自 HTML<audio>标记。
• font, 指标是字体。这可能源于 CSS @font-face。
• frame, 指标是一个框架。这可能源自 HTML<frame>标记。
• iframe, 指标是一个 iframe。这可能源自 HTML<iframe>标记。
• script, 指标是一个脚本。这可能源自 HTML<script>标记或对WorkerGlobalScope.importScripts().
• style, 目的地是一种格调。这可能源自 HTML <link rel=stylesheet> 或 CSS @import。

总结

文章到这里就完结了，冀望你看完后对 url、site、origin、 跨域 、 跨站 等知识点有一些新的了解，如果你有任何倡议也欢送随时留言或者私信

referrer

• https://url.spec.whatwg.org
• https://web.dev/fetch-metadata/
• https://developer.mozilla.org…
• https://developer.mozilla.org…
• https://web.dev/same-site-sam…
• https://web.dev/schemeful-sam…