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组合的网站被视为“同源”（即协定、域名、端口号统一），其余所有都被视为“跨源” (也可称之为“跨域”)。
同源和跨源
| 源A | 源B | 是否同源 |
|---|---|---|
| https://www.example.com:443 | https://www.evil.com:443 | 跨源：域不同 |
| https://www.example.com:443 | https://example.com:443 | 跨源：子域不同 |
| https://www.example.com:443 | https://login.example.com:443 | 跨源：子域不同 |
| https://www.example.com:443 | http://www.example.com:443 | 跨源：计划不同 |
| https://www.example.com:443 | https://www.example.com:80 | 跨源：端口号不同 |
| https://www.example.com:443 | https://www.example.com | 同源：端口号省略 |
| https://www.example.com:443 | https://www.example.com:443 | 同源：url统一 |
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 和它之前的域的一部分
同站和跨站
能够参考如下表格
| 源A | 源B | 是否同站 |
|---|---|---|
| https://www.example.com:443 | https://www.evil.com：443 | 跨站：域不必 |
| https://www.example.com:443 | https://login.example.com:443 | 同站：子域无关 |
| https://www.example.com:443 | http://www.example.com:443 | 同站：计划无关 |
| https://www.example.com:443 | https://www.example.com: 80 | 同站：端口无关 |
| https://www.example.com:443 | https://www.example.com:443 | 同站：齐全匹配 |
| https://www.example.com:443 | https://www.example.com | 同站：端口无关（省略时） |
总结来说就是: 只有域名不同 才属于夸大
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因为计划不匹配被视为跨站点。
| 源A | 源 B | 是否有打算的同站 | |
|---|---|---|---|
| https://www.example.com:443 | https://www.evil.com:443 | 跨站：域不同 | |
| https://www.example.com:443 | https://login.example.com:443 | 有打算的同站：子域无关 | |
| https://www.example.com:443 | http://www.example.com:443 | 跨站: 计划不同 | |
| https://www.example.com:443 | https://www.example.com:80 | 有打算的同站：端口无关 | |
| https://www.example.com:443 | https://www.example.com:443 | 有打算的同站：齐全匹配 | |
| https://www.example.com:443 | https://www.example.com | 有打算的同站：端口无关（省略时） |
如何辨别“同站” vs “跨站” 和 “同源” vs “跨源”
Chrome76+ 后（特地是90+版本后），平安机制一直发生变化，本地开发会遇到各种神奇的问题（感兴趣或者遇到问题能够私信活留言），能够通过HTTP request header Sec-Fetch-Site（元数据申请头）进行辨别。
Sec-Fetch-Site截至 2020 年 4 月，尚无其余浏览器反对。这是更大的Fetch Metadata Request Headers 提案的一部分。申请头具备以下值之一：
cross-sitesame-sitesame-originnone
通过查看 的值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...