URLURL代表统一资源定位符（UniformResourceLocator）。与超文本和HTTP一样，它是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规范和weburl有一些区别（在命名方面），我们会在后面解释的时候尽量区分。schemehttp既是scheme又是protocol。在web中，它还代表协议，表示浏览器必须使用哪种通信协议，通常是HTTP协议或HTTP协议安全版本（即HTTPS）。Web需要这两者之一，但浏览器可以处理其他协议，如mailto:（打开邮件客户端）或`ftp:（处理文件传输），所以当你得到这些协议时不要感到惊讶。`scheme和protocol的区别URL不包含协议，而是包含scheme[[1]](https://en.wikipedia.org/wiki...)。方案可以与协议相关联，但不是必需的。例如，在示例中，http:scheme与HTTP/1.0或1.1协议[[2]](https://www.w3.org/2001/tag/d...)file:关联，但是该方案与任何协议无关。http是scheme，是protocol，file是scheme，不是protocol。常见的scheme和端口对应关系解释如下：在web场景中，经常会用到protocol（例如：location.protocol）。如果看到protocol，可以等同于schemehost。主机地址host可以是ip也可以是域名。在示例中，www.example.com是域名。它指示正在请求哪个Web服务器。IP地址也可以直接使用，但在网络上不常使用，不太方便。一个域名由几个部分组成，可以是一个部分，两个部分，三个部分等等，每一部分都以.分割。不同于我们正常的输入顺序，需要从右到左阅读常见的域名如下：每个域名都有一些提供特定的信息。TLD(en-US)")(Top-LevelDomain，顶级域名)顶级域名可以告诉用户该域名提供的服务类型。最常见的顶级域名(.com,.org,.net)不需要web服务器满足严格的标准，但是一些顶级域确实需要执行更严格的策略。例如：区域性顶级域，例如.cn,.us,.fr或.sh，要求服务器使用给定语言或在指定国家托管。这些TLD通常表明相应的网络服务属于哪个语言或地区。包含.gov的顶级域只能由政府部门使用。.edu可以仅供教育或研究机构使用。顶级域名可以包含拉丁字母和特殊字符。顶级域名最长可达63个字符，但为了方便使用，大多数顶级域名都是两到三个字符。完整的顶级域名列表由ICANN维护。标签（label或component)标签是它遵循TLD。标签由1到63个不区分大小写的字符组成，其中包括字母A-z、数字0-9，甚至还有符号“-”（当然，“-”不应该出现在标签的开头或结尾）标签）。举几个例子，a、97或hello-strange-person-16-how-are-you都是合法的标签。位于TLD前面的SecondaryLevelDomain（二级域名）标签也被认为称为二级域名（SLD）。一个域名可以有多个标签（或组件）。没有强制要求必须使用3个标签来组成域名。例如，www.inf.ed.ac.uk是一个正确的域名。当您拥有“父”部分（例如mozilla.org）时，您还可以创建其他域（有时称为“子域”）（例如developer.mozilla.org）。端口端口：80是端口。它代表用于访问Web服务器上的资源的技术“门”。如果Web服务器使用HTTP协议的标准端口（HTTP为80，HTTPS为443）授予对其资源的访问权限，它通常会被忽略。否则它是强制性的。路径路径/path/to/myfile.html是Web服务器上资源的路径。在web的早期，这样的路径表示web服务器上的物理文件位置。今天，它没有任何物理意义，它只是web服务器中的一个抽象概念，需要注意的是路径查询查询的可理解性？key1=value1&key2=value2是一个查询，也可以称为参数（参数）。这些参数是由&符号分隔的键/值对列表。Web服务器可以使用这些参数在返回资源之前执行其他操作。每个Web服务器都有自己的参数规则，要了解特定Web服务器是否处理参数，唯一可靠的方法是询问Web服务器所有者。Fragment网络中的片段，更常见的称为锚（anchor）#SomewhereInTheDocument，是资源本身的一部分。锚点代表资源中的一种“书签”，告诉浏览器在该“书签”位置显示内容。例如，在HTML文档上，浏览器将滚动到定义锚点的位置；在视频或音频文档上，浏览器将尝试转到锚点表示的时间。值得注意的是#后面的部分（片段）永远不会发送给请求服务器指定的）。例如，给定一个URLhttps://www.example.com:443/foo，“来源”是https://www.example.com:443。具有相同方案、主机和端口组合的网站被认为是“同源”（即相同的协议、域名和端口号），其他都被认为是“跨域”（也称为“跨域””）。同源跨源sourceA和sourceB是否同源https://www.example.com:443https://www.evil.com:443Cross-origin:domainsisdifferenthttps://www.example.com:443https://example.com:443跨域：不同的子域https://www.example.com:443https://login.example.com:443跨域：不同的子域https://www.example.com:443http://www.example.com:443跨域：不同的方案https://www.example.com:443https://www.example.com:80跨域：不同的端口数字https://www.example。com:443https://www.example.com同源：省略端口号https://www.example.com:443https://www.example.com:443同源：url同sitesite”site"是其前面的域部分的TLD组合。在下面的示例中，给定的URL是https://www.example.com:443/foo，“站点”是example.com。但是在很多实际场景中，仅仅使用TLD是不够的，比如：.co.jp或者.github.io，他们的TLD是.jp或者.io，在这个粒度上是无法识别站点的（TLD），并且不能通过算法计算出具体的TLD，所以在TLD的基础上，提出了一个有效的TLD（eTLD），表示有效的TLD定义中包含的内容（见definition（公共后缀列表））。eTLD列表在publicsuffix.org/list上维护。整个站点名称称为eTLD+1。例如，如果URL是https://my-project.github.io，eTLD是.github.io，eTLD+1是my-project.github.io，这被认为是一个“站点”。换句话说，eTLD+1是TLD及其先前域的有效部分。同站和跨站可以参考下表SourceASourceB是否同站https://www.example.com:443https://www.evil.com:443跨站点：域未使用https://www.example.com:443https://login.example.com:443同一站点：子域无关https://www.example.com:443http://www.example.com:443同一站点：方案无关https://www.example.com:443https://www.example.com:80同一站点：端口无关https://www.example.com:443https://www.example.com:443同一站点：完全匹配https://www.example.com:443https://www.example.com同一站点：端口无关（省略时）In总结：只有域名区别是夸张花样同站传统的SameSite其实只涵盖与域名相关的内容（只有域名不同才是跨站），但是在我们的日常工作中，很容易遇到https和https相互切换的情况（比如全局升级到https），这时候很容易留下安全漏洞（HTTP作为弱通道）。例如，SameSite=Lax将在setCookie时设置，以防止跨站点请求伪造(CSRF)。但是，不安全的HTTP流量为网络攻击者提供了篡改cookie的机会，这些cookie随后会在站点的HTTPS上下文中使用。于是，阴谋同地应运而生，阴谋同地有了更严格的定义。在这种情况下，由于方案不匹配，http://www.example.com和https://www.example.com被视为跨站点。来源A和来源B是否规划了同一个站点https://www.example.com:443https://www.evil.com:443跨站：不同域https://www.example.com:443https://login.example.com:443计划相同站点：子域无关https://www.example.com:443http://www.example.com:443跨站点：不同计划https://www.example。com:443https://www.example.com:80计划相同站点：端口独立https://www.example.com:443https://www.example.com:443计划相同站点：完全匹配https://www.example.com:443https://www.example.comPlannedsamesite:portirrelevant(whenomitted)howtodistincting"samesite"vs"crosssite"and"sameorigin"vs"crosssite"Source"之后Chrome76+（尤其是90+版本之后），安全机制不断变化，本地开发会遇到各种神奇的问题（有兴趣或者遇到问题可以私信或者留言），可以通过HTTP请求headerSec-Fetch-Site(metadatarequestheader)来区分。截至2020年4月，Sec-Fetch-Site没有其他浏览器支持。这是更大的FetchMetadataRequestHeaders提议的一部分。请求标头具有以下值之一:cross-sitesame-sitesame-originnone通过检查Sec-Fetch-Site的值，您可以确定请求是否为“同一站点”，“s同源”或“跨站点”，但不幸的是，schemeful-same-site目前不支持在Sec-Fetch-Site请求元数据中获取元数据许多Web应用程序容易受到跨域攻击，例如跨站点请求伪造(CSRF)、跨站点脚本包含(XSSI)、定时攻击、跨源信息泄漏或幽灵攻击。FetchMetadata请求头提供了更强大的防御机制资源隔离策略来保护您的应用程序免受这些常见的跨域攻击。通过在一组Sec-Fetch-*标头中提供有关HTTP请求上下文的信息，它们允许响应服务器在处理请求之前应用安全策略同源请求从您自己的服务器（同源）提供的站点将继续上班。跨站点由于Sec-Fetch-*标头提供的HTTP请求中的附加上下文，服务器可能会拒绝恶意的跨站点请求。Sec-Fetch-SiteSec-Fetch-Site告诉服务器哪个站点发送了请求。浏览器将此值设置为以下之一：同源，如果请求是由您自己的应用程序（例如site.example）发出的同一站点，如果请求是由您网站的子域发出的（例如bar.site.示例）无，如果请求是由用户与用户代理（例如单击书签）的交互明确引起的跨站点，如果请求是由另一个站点发送的（例如evil.example）Sec-Fetch-ModeSec-Fetch-Mode表示请求的模式。这大致对应于请求的类型，并允许您区分资源加载和导航请求。例如，destinationnavigate表示顶级导航请求，而no-cors表示加载图片等资源请求。cors，该请求是CORS协议请求。navigate，通过在HTML文档之间导航发起请求。no-cors，该请求是无cors请求（请参阅ResourcesRequest.mode）。同源，请求与请求的资源来自同一源。websocket，正在请求建立WebSocket连接。Sec-Fetch-DestSec-Fetch-Dest用于说明请求的目的地，也可以看到原始请求的发起者，即在哪里（以及如何）使用获取的数据。Sec-Fetch-Dest这允许服务器根据请求是否适合预期的使用模式来确定是否为请求提供服务。例如，带有音频目标的请求应该请求音频数据，而不是其他类型的资源（例如，包含敏感用户信息的文档）枚举一些公共值（不完全）音频，目标是音频数据。这可能源自HTML
