URL(UrI的子集,统一资源定位符)实现的具体方法

URL首先是一种方法，定位到一个网络资源的具体方法。是属于URI（统一资源标识符）的一个子集，同时URL 还在不断的进化，因为资源的移除导致无法找到资源是一个头疼的问题，现在正在朝着解决这个“问题”的目标前进。

需要注意的是这里有三个名字需要注意：

URN(统一资源名)

URL(统一资源定位)

URI(统一资源标识)

URI包含了URL,URN2种形式。

区别：

URI、URL和URN

编辑

统一资源定位符（Uniform Resource Locator，URL）,统一资源名称（Uniform Resource Name，URN）是URI的子集。

Web上地址的基本形式是URI,它有两种形式：

一种是URL，这是目前URI的最普遍形式。

另一种就是URN，这是URL的一种更新形式，URN不依赖于位置，并且有可能减少失效连接的个数。但是其流行还需假以时日，因为它需要更精密软件的支持。

 

URI与URL

URL是Uniform Resource Locator的缩写，译为"统一资源定位符"。URL是一种URI，它标识一个互联网资源，并指定对其进行操作或获取该资源的方法。可能通过对主要访问手段的描述，也可能通过网络“位置”进行标识。例如，http://www.wikipedia.org/这个URL，标识一个特定资源（首页）并表示该资源的某种形式（例如以编码字符表示的，首页的HTML代码）是可以通过HTTP协议从www.wikipedia.org这个网络主机获得的。主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。

最大的缺点是当信息资源的存放地点发生变化时，必须对URL作相应的改变。因此人们正在研究新的信息资源表示方法，例如：URI(Universal Resource Identifier)即"通用资源标识" [2]  、URN（Uniform Resource Name）即"统一资源名"和URC（Uniform Resource Citation）即"统一资源引用符"等。

URI还在进一步的研究当中。研究的方向就是弥补URL的缺点。

URI与URN

URI可被视为定位符（URL），名称（URN）或两者兼备。统一资源名（URN）如同一个人的名称，而统一资源定位符（URL）代表一个人的住址。换言之，URN定义某事物的身份，而URL提供查找该事物的方法。URN仅用于命名，而不指定地址。

用于标识唯一书目的ISBN系统是一个典型的URN使用范例。例如，ISBN 0486275574(urn:isbn:0-486-27557-4)无二义性地标识出莎士比亚的戏剧《罗密欧与朱丽叶》的某一特定版本。为获得该资源并阅读该书，人们需要它的位置，也就是一个URL地址。在类Unix操作系统中，一个典型的URL地址可能是一个文件目录，例如file:///home/username/RomeoAndJuliet.pdf。该URL标识出存储于本地硬盘中的电子书文件。因此，URL和URN有着互补的作用。

URN是基于某名字空间通过名称指定资源的URI。人们可以通过URN来指出某个资源，而无需指出其位置和获得方式。资源无需是基于互联网的。例如，URNurn:ISBN0-395-36341-1 指定标识系统（即国际标准书号ISBN）和某资源在该系统中的唯一表示的URI。它可以允许人们在不指出其位置和获得方式的情况下谈论这本书。

 

 

通俗的方式来讲解：url 和 url  的区别（来源知乎某位哥）；

统一资源标志符URI就是在某一规则下能把一个资源独一无二地标识出来。
拿人做例子，假设这个世界上所有人的名字都不能重复，那么名字就是URI的一个实例，通过名字这个字符串就可以标识出唯一的一个人。
现实当中名字当然是会重复的，所以身份证号才是URI，通过身份证号能让我们能且仅能确定一个人。
那统一资源定位符URL是什么呢。也拿人做例子然后跟HTTP的URL做类比，就可以有：

动物住址协议://地球/中国/浙江省/杭州市/西湖区/某大学/14号宿舍楼/525号寝/张三.人

可以看到，这个字符串同样标识出了唯一的一个人，起到了URI的作用，所以URL是URI的子集。URL是以描述人的位置来唯一确定一个人的。
在上文我们用身份证号也可以唯一确定一个人。对于这个在杭州的张三，我们也可以用：

身份证号：123456789

来标识他。
所以不论是用定位的方式还是用编号的方式，我们都可以唯一确定一个人，都是URl的一种实现，而URL就是用定位的方式实现的URI。

回到Web上，假设所有的Html文档都有唯一的编号，记作html:xxxxx，xxxxx是一串数字，即Html文档的身份证号码，这个能唯一标识一个Html文档，那么这个号码就是一个URI。
而URL则通过描述是哪个主机上哪个路径上的文件来唯一确定一个资源，也就是定位的方式来实现的URI。
对于现在网址我更倾向于叫它URL，毕竟它提供了资源的位置信息，如果有一天网址通过号码来标识变成了http://741236985.html，那感觉叫成URI更为合适，不过这样子的话还得想办法找到这个资源咯…

 

 

 

 

 

介绍URI的具体表现形式：

1.解析输入的URL地址

http://www.baidu.cn:80/index.html?lx=teacher#video

• 传输协议（把信息在客户端和服务器端进行传递，类似于快递小哥）

  • http 超文本传输协议（传输的内容除了文本，还有可能是其它类型：二进制编码、BASE64码、文件流等等）

  • https 比HTTP更加安全的传输协议（传输通道设置加密算法SSL），一般支付类网站都是HTTPS协议

  • ftp 资源上传协议，一般应用于把本地文件直接上传到服务器端

• 域名 zhufengpeixun.cn

  • 一级域名 www.baidu.cn

  • 二级域名 video.baidu.cn

  • 三级域名 webG.video.buidu.cn

  • 常用域名性质：.com国际 / .cn中国 / .gov政府 / .org官方 / .net系统 / .io博客 / .vip ...

• 端口号 （根据端口号，找到当前服务器上指定的服务）

  • 0~65535之间

  • 不同协议有自己默认的端口号（也就是自己不用写，浏览器会帮我们加上）

    • http => 80

    • https => 443

    • ftp => 21

    • 除这几个在书写的时候可以省略，其余的不能省

• 请求资源的路径和名称

  • /stu/index.html

    • 一般情况下，如果我们访问的是index.html等，可以省略不写（因为服务端一般会设置index.html为默认文档，当然可以自定义）

  • 伪URL

    • SEO优化   https://item.jd.com/100006038463.html 

    • 数据请求的接口地址 /user/list

• 问号传参部分 ?xxx=xxx

  • 客户端基于GET系列请求，把信息传递会服务器，一般都会基于问号传参的模式

  • 页面之间跳转，信息的一些通信也可以基于问号传参的方式（单页面中组件和组件跳转之间的信息通信，也可能基于问号传参）

  • 关于传递的内容需要进行编码处理（处理特殊字符和中文）

    • encodeURI / decodeURI

    • encodeURIComponent / decodeURIComponent

    • escape / unescape

    • ...

• 设置哈希HASH #xxx

2.DNS解析

网站中，每发送一个TCP请求，都要进行DNS解析（一但当前域名解析过一次，浏览器一般会缓存解析记录，缓存时间一般在1分钟左右，后期发送的请求如果还是这个域名，则跳过解析步骤 =>这是一个性能优化点）

真实项目中，一个大型网站，他要请求的资源是分散到不同的服务器上的（每一个服务器都有自己的一个域名解析）

• WEB服务器（处理静态资源文件，例如：html/css/js等 的请求）

• 数据服务器（处理数据请求）

• 图片服务器 （处理图片请求）

• 音视频服务器

• ...... 这样导致，我们需要解析的DNS会有很多次

优化技巧：DNS Prefetch 即 DNS 预获取

让页面加载（尤其是后期资源的加载）更顺畅更快一些

<meta http-equiv="x-dns-prefetch-control" content="on">
<link rel="dns-prefetch" href="//static.360buyimg.com">
<link rel="dns-prefetch" href="//misc.360buyimg.com">
<link rel="dns-prefetch" href="//img10.360buyimg.com">
<link rel="dns-prefetch" href="//img11.360buyimg.com">
<link rel="dns-prefetch" href="//img12.360buyimg.com">
.......

3.基于TCP的三次握手，够建客户端和服务器端的连接通道

只有建立好连接通道，才能基于HTTP等传输协议，实现客户端和服务器端的信息交互

4.发送HTTP请求

基于HTTP等传输协议，客户端把一些信息传递给服务器

• HTTP请求报文（所有客户端传递给服务器的内容，统称为请求报文）

  • 谷歌控制台NetWork中可以看到

  • 请求起始行

  • 请求首部（请求头）

  • 请求主体

• 强缓存 和 协商缓存（性能优化：减少HTTP请求的次数）

  • 强缓存 ( Cache-Control 和 Expires )

  • 协商缓存 ( Last-Modified 和 Etag )

5.服务器接受到请求，并进行处理，最后把信息返回给客户端

• HTTP响应报文（所有服务器返回给客户端的内容）

  • 响应起始行

  • 响应首部（响应头）

    • date存储的是服务器的时间

    • ...

  • 响应主体

  • 服务器返回的时候是：先把响应头信息返回，然后继续返回响应主体中的内容（需要的信息大部分都是基于响应主体返回的）

6.断开TCP链接通道 （四次挥手）

• 当客户端把请求信息发送给服务器的时候，就挥第一次手：客户端告诉服务器端，我已经把请求报文都给你了，你准备关闭吧

• 第二次挥手：由服务器发起，告诉浏览器，我接收完请求报文，我准备关闭，你也准备吧；

• 第三次挥手：由服务器发起，告诉浏览器，我响应报文发送完毕，你准备关闭吧；

• 第四次挥手：由浏览器发起，告诉服务器，我响应报文接收完毕，我准备关闭，你也准备吧；

Connection: Keep-Alive 保持TCP不中断（性能优化点，减少每一次请求还需要重新建立链接通道的时间）

7.客户端渲染服务器返回的结果