URI和URL
与URI（统一资源标识符）相比，我们更熟悉URL（统一资源定位符）。URL正是我们使用Web浏览器等访问Web页面时需要输入的网页地址。
统一资源标识符
URI是Uniform Resource Identifier 的缩写。
Uniform
规定统一的格式可方便处理多种不同类型的资源，而不用根据上下文环境来识别资源指定的访问方式。另外，加入新增的协议方案也更容易。
Resource
资源的定义是“可标识的任何东西”，除了文档文件，图像或服务等能够区别于其他类型的，全都可作为资源。资源不仅仅可以是单一的，也可以是多数的集合体。
Identifier
表示可标识的对象。也称标识符。
综上所述：URL就是由某个协议方案表示的资源的定位标识符，协议方案是指访问资源所使用的协议类型名称。
URI用字符串表示某一互联网资源，而URL表示资源的地址。可见URL是URI的子集。
URI格式
表示指定的URI，要使用涵盖全部必要信息的绝对URI，绝对URL以及相对URL。相对URL，是指从浏览器中基本URI出指定打的URL。
例如绝对URI的格式
使用HTTP或HTTPS等协议方案名获取访问资源时要指定协议类型。
登录信息（认证）指定用户名和密码作为从服务器端获取资源时必要的登录信息（身份认证）。为可选项。
服务器地址：使用绝对URI必须指定带访问的服务器地址。地址可以是类似hackr.jp这种DNS可解析的名称，或是192.168.1.1这类IPv4地址名，还可以是[ 0：0:0:0:0:0:1]这样用方括号括起来的IPv6地址名。
服务器端口号：指定服务器连接的网络端口号。可选项，若省略则自动使用默认端口。
带层次的文件路径：指定服务器上的文件路径来定位特指的资源。
查询字符串：针对已指定的文件路径内的资源，可以使用查询字符串传入任意参数，可选项。
片段标识符：使用片段标识符通常可标记出以获取资源中的子资源（文档内的某个位置）。但在RFC中并没有明确规定其使用方法。可选项。
RFC
并不是所有的应用程序都符合RFC
有一些用来指定HTTP协议技术标准的文档，它们被称为RFC（Request for Comments , 征求修正往意见书）。
通常，应用程序会遵照由RFC确定的标准实现。可以说，RFC是互联网的设计文档，要是不按照RFC标准执行，就有可能导致无法通信的状况。比如，一台Web服务器内的应用服务没有遵照RFC的标准实现，那Web浏览器就很可能无法访问这台服务器了。
由于不遵照RFC标准实现就无法进行HTTP协议通信，所以基本上客户端和服务器端都会以RFC为标准来实现HTTP协议。但也存在某些应用程序因客户端或服务器端的不同，而未遵照RFC标准，反而将自成一套的标准扩展的情况。
不按RFC标准来实现，当然也不必来信费力让自己的标准符合其他所有的客户端和服务器端。但设想一下，如果这款应用程序的使用者非常多，那会发生什么情况？不难想象，其他的客户端或服务器端必然都不得不去配合它。