| OSI七层模型 | 功能 | 对应的网络协议 |
|---|---|---|
| 应用层 | 应用层是网络体系中最高的一层，也是唯一面向用户的一层，也可视为为用户提供常用的应用程序，每个网络应用都对应着不同的协议 | HTTP、TFTP, FTP, NFS, WAIS、SMTP |
| 表示层 | 主要负责数据格式的转换，确保一个系统的应用层发送的消息可以被另一个系统的应用层读取，编码转换，数据解析，管理数据的解密和加密，同时也对应用层的协议进行翻译 | Telnet, Rlogin, SNMP, Gopher |
| 会话层 | 负责网络中两节点的建立，在数据传输中维护计算机网络中两台计算机之间的通信连接，并决定何时终止通信 | SMTP, DNS |
| 传输层 | 是整个网络关键的部分，是实现两个用户进程间端到端的可靠通信，处理数据包的错误等传输问题。是向下通信服务最高层，向上用户功能最底层。即向网络层提供服务，向会话层提供独立于网络层的传送服务和可靠的透明数据传输。 | TCP, UDP |
| 网络层 | 进行逻辑地址寻址，实现不同网络之间的路径选择，IP就在网络层 | IP, ICMP, ARP, RARP, AKP, UUCP |
| 数据链路层 | 物理地址（MAC地址），网络设备的唯一身份标识。建立逻辑连接、进行硬件地址寻址，相邻的两个设备间的互相通信 | FDDI, Ethernet, Arpanet, PDN, SLIP, PPP，STP。HDLC,SDLC,帧中继 |
| 物理层 | 七层模型中的最底层，主要是物理介质传输媒介（网线或者是无线），在不同设备中传输比特，将0/1信号与电信号或者光信号互相转化 | IEEE 802.1A, IEEE 802.2到IEEE 802 |
TCP首部包括固定的20个字节以及可变长的部分
UDP首部只有8个字节
(1)第一次握手: Client 将标志位 SYN 置为 1, 随机产生一个值 seq=x, 并将该数据包发送给 Server,Client 进入 SYN_SENT 状态, 等待 Server 确认
(2)第二次握手: Server 收到数据包后由标志位 SYN=1 知道 Client 请求建立连接, Server 将标志位 SYN 和 ACK 都置为 1,ack=x+1, 随机产生一个值 seq=y, 并将该数据包发送给 Client 以确认连接请求, Server 进入 SYN_RCVD 状态
(3)第三次握手: Client 收到确认后, 检查 ack 是否为 x+1,ACK 是否为 1, 如果正确则将标志位 ACK 置为 1,ack=y+1, 并将该数据包发送给 Server,Server 检查 ack 是否为 y+1,ACK 是否为 1, 如果正确则连接建立成功, Client 和 Server 进入 ESTABLISHED 状态, 完成三次握手, 随后 Client 与 Server 之间可以开始传输数据了。seq是序列号，这是为了连接以后传送数据用的，ack是对收到的数据包的确认，值是等待接收的数据包的序列号。在第一次消息发送中，A随机选取一个序列号作为自己的初始序号发送给B；第二次消息B使用ack对A的数据包进行确认，因为已经收到了序列号为x的数据包，准备接收序列号为x+1的包，所以ack=x+1，同时B告诉A自己的初始序列号，就是seq=y；第三条消息A告诉B收到了B的确认消息并准备建立连接，A自己此条消息的序列号是x+1，所以seq=x+1，而ack=y+1是表示A正准备接收B序列号为y+1的数据包。seq是数据包本身的序列号；ack是期望对方继续发送的那个数据包的序列号。
最后一次握手是为了防止已失效的请求报文突然又传到服务器引起错误。
假设采用两次握手建立连接，客户端向服务器发送一个SYN包请求建立连接，因为某些未知的原因没有到达服务器，在某个网络节点产生了滞留，为了建立连接客户端会重发SYN包，这次的数据包正常送达，服务器回复SYN+ACK后建立了连接。但是第一包数据阻塞的网络节点突然恢复，第一包SYN包又送达到服务端，这次服务端会误认为客户端又发起了新的连接，从而在两次握手后进入了等待数据状态。这种情况多了，就可能会导致服务器瘫痪。【此时进入了死锁状态】服务器认为是两个连接，而客户端认为只有一个连接，造成了状态不一致。
如果是三次握手，服务端收不到最后的ACK包，自然就不会认为连接建立成功，所以三次握手本质上来说，就是为了解决网络信道不可靠的问题。
理解版本：
建立一个 TCP 连接需要三次握手，而终止一个 TCP 连接要经过四次挥手（也有将四次挥手叫做四次握手的）。这是由于 TCP 的半关闭（half-close）特性造成的，TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。TCP 连接的释放需要发送四个包（执行四个步骤），因此称为四次挥手(Four-way handshake)，客户端或服务端均可主动发起挥手动作。
1）第一次挥手：客户端发送一个 FIN 报文（请求连接终止：FIN = 1），报文中会指定一个序列号 seq = u。并停止再发送数据，主动关闭 TCP 连接。此时客户端处于 FIN_WAIT1 状态，等待服务端的确认。
FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；
2）第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。
CLOSE-WAIT - 等待从本地用户发来的连接中断请求；
此时的 TCP 处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待 2）状态，
等待服务端发出的连接释放报文段。
FIN-WAIT-2 - 从远程TCP等待连接中断请求；
3）第三次挥手：如果服务端也想断开连接了（没有要向客户端发出的数据），和客户端的第一次挥手一样，发送 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态，等待客户端的确认。
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；
4）第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答（ack = w+1），且把服务端的序列值 +1 作为自己
ACK 报文的序号值（seq=u+1），此时客户端处于 TIME_WAIT（时间等待）状态。
TIME-WAIT - 等待足够的时间以确保远程TCP接收到连接中断请求的确认；
记忆版本：
1）客户端向服务器发送FIN报文，TCP首部中的FIN比特被置位
2) 服务器收到FIN报文，回复ACK，进入close-wait状态。服务端同样发送FIN报文
3）客户端收到FIN，回复ACK，客户端进入time-wait状态，确保服务器能够收到自己发出的ACK
4）服务端收到ACK，连接关闭。
回答1：注意 ！！！这个时候由服务端到客户端的 TCP 连接并未释放掉，需要经过时间等待计时器设置的时间 2MSL（一个报文的来回时间）才会进入 CLOSED状态（这样做的目的是确保服务端收到自己的 ACK 报文。如果服务端在规定时间内没有收到客户端发来的 ACK报文的话，服务端会重新发送 FIN 报文给客户端，客户端再次收到 FIN 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK报文给服端）。服务端收到 ACK 报文之后，就关闭连接了，处于 CLOSED 状态。可以看出，服务器结束连接要比客户端早。
回答2：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
简单地说，是因为TCP是全双工模式，前两次挥手只是关闭了一个方向的数据通道，后两次挥手用于关闭另一个方向的数据通道。
传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议
发送方：发送数据之前计算校验和，并填充至TCP报文首部；接收方：收到数据后，计算检验和，与发送方的校验和比较是否一致，若不一致，则一定传输有误，若校验和一致，也不能说明传输一定成功。若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
1）根据序列号对失序数据包重排序；
2）丢弃重复数据：去掉重复序列号的数据；
TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答，也就是发送ACK报文。这个确认不是立即发送，通常将推迟几分之一秒；
当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
首先，发送方没有收到响应的ACK报文的原因有两点：
1、接收方没有收到数据；
2、接受方成功收到数据，但是发送的ACK报文丢失；
超时重传机制可以解决上述问题，简单理解就是发送数据后等待一段时间，到达预计时间后没有收到ACK报文就会对刚才发送的数据进行重新发送。如果是case1：那么接收方收到第二次重发的数据后，边进行ACK应答；如果是case2，接收方收到数据后发现数据已存在（根据序列号判断），那么直接丢弃，依然发送ACK确认报文；
连接管理就是三次握手和四次挥手的过程，这是保证可靠性的前提；
TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。TCP报文首部有一个窗口，实际上就是接收端接收数据缓冲区的大小。数字越大，证明接收端接收缓冲区的剩余空间越大；接收方收到数据后发送ACK时，会将窗口大小一并发送，发送方根据窗口大小改变发送数据的速度。如果窗口大小为0，那么久停止发送数据。并定期想接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。
开始发送数据时，先发送少量数据探路，观察网络状态，在决定以多打的速度进行传输。这时引入一个拥塞窗口的概念，拥塞窗口初始值为1，每当接收到一个ACK，拥塞窗口就会翻倍，呈现指数级增长。
慢启动机制只是在开始的时候发送少量数据，但是增长速度很快，为了控制拥塞窗口的增长，不能使拥塞窗口单纯的翻倍，要设置一个拥塞窗口的阈值，将慢启动阈值设置为窗口的最大值。
当拥塞窗口等于慢启动阈值时，就会启用拥塞避免算法。
乘法减小：当出现拥塞时，将慢启动阈值设置为原来的一半，然后将拥塞窗口初始化为1，执行慢启动算法。
加法增大：每经过一个往返时间RTT，拥塞窗口+1，让拥塞窗口缓慢增大，按照线性规律增长。
快重传算法要求首先接收方收到一个失序的报文段后就立刻发出重复确认，而不要等待自己发送数据时才进行捎带确认。
接收方成功的接受了发送方发送来的M1、M2并且分别给发送了ACK，现在接收方没有收到M3，而接收到了M4，显然接收方不能确认M4，因为M4是失序的报文段。如果根据可靠性传输原理接收方什么都不做，但是按照快速重传算法，在收到M4、M5等报文段的时候，不断重复的向发送方发送M2的ACK,如果接收方一连收到三个重复的ACK,那么发送方不必等待重传计时器到期，由于发送方尽早重传未被确认的报文段。
1、当发送发连续接收到三个确认时，就执行乘法减小算法，把慢启动开始门限（ssthresh）减半，但是接下来并不执行慢开始算法。
2、此时不执行慢启动算法，而是把cwnd设置为ssthresh的一半， 然后执行拥塞避免算法，使拥塞窗口缓慢增大。
UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。
传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。
实现确认机制、重传机制、窗口确认机制。
如果你不利用linux协议栈以及上层socket机制，自己通过抓包和发包的方式去实现可靠性传输，那么必须实现如下功能：
发送方：包的分片、包确认、包的重发
接收方：包的排序、包的序号确认
目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。
1、HTTP0.9 、HTTP1.0、HTTP1.1采用TCP协议，HTTP3.0采用UDP协议。
2、HTTP0.9、HTTP1.0在每次请求/响应都会创建一个TCP连接。
3、HTTP1.1采用持久连接方式，多个HTTP请求同时使用一个TCP连接。
4、HTTP2.0采用多路复用，客户端和服务器之间只建立一个TCP连接，多个HTTP帧混合在一起在一个TCP上面传送
5、HTTP3.0采用UDP协议，解决了队头阻塞问题。
HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议。底层使用TCP/UDP协议
短连接：浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。
长连接：持久连接方式，多个HTTP请求同时使用一个TCP连接。当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。
HTTP状态码表示客户端HTTP请求的返回结果、标记服务器端的处理是否正常或者是出现的错误，能够根据返回的状态码判断请求是否得到正确的处理很重要。数字中的第一位指定了响应类别，后两位无分类，响应类别有一下5种：
200 OK：表示从客户端发送给服务器的请求被正常处理并返回；
204 No Content：表示客户端发送给客户端的请求得到了成功处理，但在返回的响应报文中不含实体的主体部分（没有资源可以返回）；
206 Patial Content：表示客户端进行了范围请求，并且服务器成功执行了这部分的GET请求，响应报文中包含由Content-Range指定范围的实体内容。
301 Moved Permanently：永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；
302 Found：临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；
301与302的区别：前者是永久移动，后者是临时移动（之后可能还会更改URL）303 See Other：表示请求的资源被分配了新的URL，应使用GET方法定向获取请求的资源；
302与303的区别：后者明确表示客户端应当采用GET方式获取资源304 Not
Modified：表示客户端发送附带条件（是指采用GET方法的请求报文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的请求时，服务器端允许访问资源，但是请求为满足条件的情况下返回改状态码；307 Temporary
Redirect：临时重定向，与303有着相同的含义，307会遵照浏览器标准不会从POST变成GET；（不同浏览器可能会出现不同的情况）；
400 Bad Request：表示请求报文中存在语法错误；
401 Unauthorized：未经许可，需要通过HTTP认证；
403 Forbidden：服务器拒绝该次访问（访问权限出现问题）
404 Not Found：表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用；
500 Inter Server Error：表示服务器在执行请求时发生了错误，也有可能是web应用存在的bug或某些临时的错误时；
503 Server Unavailable：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求；
1、DNS：域名解析协议：通过域名解析获得域名所对应的IP。端口号：53
2、FTP：文件传输协议：用户可通过客户机程序向远程主机上传文件；或从远程主机上下载文件。端口号：21；
3、HTTP：超文本传输协议：最初设计HTTP是为了提供一种发布和接受HTML页面的方法。所有WWW文件都必须遵守这个标准。端口号：80；
4、DHCP：动态主机配置协议：自动分配和管理IP
5、BGP：边界网关协议
6、SMTP：简单邮件传输协议，提供可靠且有效的电子邮件传输的协议。
7、HTTPS：基于安全套接字层的超文本传输协议。SSL/TSL+HTTP
工作层：在OSI网络模型中，HTTP工作于应用层，而HTTPS工作在传输层。
连接端口：HTTP标准端口为80，而HTTPS标准端口为443。
传输方式：HTTP是超文本传输协议，信息是明文传输，而HTTPS是SSL加密传输协议。
工作耗时：HTTP耗时=TCP握手，而HTTPS耗时=TCP握手+SSL握手。
显示形式：HTTP的URL以http://开头，而HTTPS的URL以https://开头。
费用：HTTP无需费用，而HTTPS需要到CA申请证书，一般免费证书较少，需要一定费用。
安全性：HTTP的连接简单，是无状态的；而HTTPS是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全。
1、SSL/TLS
SSL 是洋文“Secure Sockets Layer”的缩写，中文叫做“安全套接层”。它是在上世纪90年代中期，由网景公司设计的。（顺便插一句，网景公司不光发明了 SSL，还发明了很多 Web 的基础设施——比如“CSS 样式表”和“JS 脚本”）为啥要发明 SSL 这个协议捏？因为原先互联网上使用的 HTTP 协议是明文的，存在很多缺点——比如传输内容会被偷窥（嗅探）和篡改。发明 SSL 协议，就是为了解决这些问题。到了1999年，SSL 因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。很多相关的文章都把这两者并列称呼（SSL/TLS），因为这两者可以视作同一个东西的不同阶段。
HTTPS协议 = HTTP协议 + SSL/TLS协议，在HTTPS数据传输的过程中，需要用SSL/TLS对数据进行加密和解密，需要用HTTP对加密后的数据进行传输，由此可以看出HTTPS是由HTTP和SSL/TLS一起合作完成的。
一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。
1.客户端向服务器发起HTTPS请求，连接到服务器的443端口
2.服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。
3.服务器将自己的公钥发送给客户端。
4.客户端收到服务器端的证书之后，会对证书进行检查，验证其合法性，如果发现发现证书有问题，那么HTTPS传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性，关于客户端如何验证数字证书的合法性，下文会进行说明。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。
5.客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
6.服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。
7.然后服务器将加密后的密文发送给客户端。
8.客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。
网络层的ARP协议完成了IP地址与物理地址的映射。首先，每台主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的对应关系。当源主机需要将一个数据包要发送到目的主机时，会首先检查自己ARP列表中是否存在该IP地址对应的MAC地址：如果有，就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。此ARP请求数据包里包括源主机的IP地址、硬件地址、以及目的主机的IP地址。网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个ARP响应数据包，告诉对方自己是它需要查找的MAC地址；源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。
(1).整个流程步骤:
(2)域名解析过程:
浏览器对输入的url进行分析（协议、是IP还是域名、端口、参数）；
然后应用DNS对域名进行解析，获取对应的IP地址【通过DNS域名服务器】；
浏览器构造一个HTTP报文，然后向服务器发送请求；
补充：应用层写入数据，表示层进行格式化编码，会话层标记发送顺序。
将应用层数据作为Tcp报文段的数据部分，为了保证数据传输的可靠性，要对索要传输的数据添加TCP首部；通过TCP协议进行传输；
通过三次握手建立TCP连接；
TCP报文段被封装为IP数据报进行传输；
IP地址通过ARP协议解析出MAC地址，再去访问目的主机的MAC地址。
找到对方的MAC地址后，就将数据封装成帧，然后交付给物理层，物理层通过实际的电路进行传输。
接收端的服务器在链路层接收到数据包，再层层向上直到应用层。这过程中包括在传输层通过TCP协议将分段的数据包重新组成原来的HTTP请求报文。
查找客户端请求的资源，并返回响应报文。
拿到响应报文，浏览器进行解析，将页面显示给用户
客户机提出域名解析请求,并将该请求发送给本地域名服务器。
当本地域名服务器收到请求后,就先查询本地缓存,如果该纪录项,则本地域名服务器就直接把查询结果返回。 【查询本地缓存】
如果本地缓存中没该纪录,则本地域名服务器就直接把请求发给根域名服务器,然后根域名服务器再返回给本地域名服务器一个所查询域(根子域)主域名服务器地址。【请求根域名服务器】
本地服务器再向一步返回域名服务器发送请求,然后接受请求服务器查询自己缓存,如果没该纪录,则返回相关下级域名服务器地址。【查询根域名服务器的下级域名服务器】
重复第四步,直到找到正确纪录。
本地域名服务器把返回结果保存到缓存,以备下一次使用,同时还将结果返回给客户。
队头阻塞
由于HTTP1.0规定下一个请求必须在前一个请求响应到达之后才能发送。假设前一个请求响应一直不到达（网络原因导致迟到或者丢失、服务器崩盘等原因），那么下一个请求就不发送，同样的后面的请求也给阻塞了。
于是http1.1提出了管线化(pipelining)技术，就是一次性发送多个request请求。然而pipelining在接收response返回时，也必须依顺序接收，如果前一个请求遇到了阻塞，后面的请求即使已经处理完毕了，仍然需要等待阻塞的请求处理完毕。这种情况队头阻塞，第一个请求阻塞后，后面的请求都需要等待。
为了解决上述阻塞问题，http2中提出了多路复用（Multiplexing）技术，就是将多个请求复用同一个tcp链接中，将一个TCP连接分为若干个流（Stream），每个流中可以传输若干消息（Message），每个消息由若干最小的二进制帧（Frame）组成。也就是将每个request-response拆分为了细小的二进制帧Frame，这样即使一个请求被阻塞了，也不会影响其他请求。
由三部分组成：
①访问资源的命名机制；
②存放资源的主机名；
③资源自身的名称，由路径表示。
由三部分组成：
①第一部分是协议(或称为服务方式)。
②第二部分是存有该资源的主机IP地址(有时也包括端口号)。
③第三部分是主机资源的具体地址，如目录和文件名等。
URI和URL都定义了资源是什么，但URL还定义了该如何访问资源。URL是一种具体的URI，它是URI的一个子集。URI 是一种语义上的抽象概念，可以是绝对的，也可以是相对的，而URL则必须提供足够的信息来定位，是绝对的。
在Java类库中，URI类不包含任何访问资源的方法，它唯一的作用就是解析。相反的是，URL类可以打开一个到达资源的流。
URI：http://bitpoetry.io/posts/hello.html#intro http:// 是定义如何访问资源的方式。
bitpoetry.io/posts/hello.html 是资源存放的位置
#intro 是资源。 URL是URI的一个子集，告诉我们访问网络位置的方式。
URL应该如下所示： http://bitpoetry.io/posts/hello.html
URN是URI的子集，包括名字(给定的命名空间内)，但是不包括访问方式，如下所示：
bitpoetry.io/posts/hello.html#introURI身份证号 URL 住址协议://地球/中国/浙江省/杭州市/西湖区/525号/张三.
不论是用定位的方式还是用编号的方式，我们都可以唯一确定一个人，都是URl的一种实现。
