一次完整的url解析

63 阅读 0 评论 42 点赞

我是靠谱客的博主风趣刺猬，最近开发中收集的这篇文章主要介绍一次完整的url解析，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

一切从url地址开始

前端的大多数应用程序都是在浏览器上进行的，所以当我们访问一个网站时首先是从url解析开始的。

当我们在浏览器的地址栏输入一个url地址或点击一个连接时浏览器就开始了对该条地址的解析，我们知道计算机是通过ip地址来确定是那台电脑的，将ip转化为url也更方便我们记忆。

完整的域名解析过程如下:
1、在浏览器中输入www.baidu.com域名，操作系统会先检查自己本地的hosts (C:Windo wsSystem32dri versetc)文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
2、如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。
3、如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/ip参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
4、如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。
5、如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(baidu.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找qq.com域服务器，重复上面的动作，进行查询，直至找到www.baidu.com主机。
注：客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过三次握手，这样DNS服务器负载更低，响应更快。理论上说，客户端也可以指定向DNS服务器查询时用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包

DNS解析出请求地址，浏览器向这个地址发送请求，进行tcp三次握手建立连接，tcp/ip连接建立后，浏览器向服务器发送http请求，服务处理请求并返回相应的资源（如果有缓存就在缓存中去）

完整的tcp三次握手如下：
第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

四次挥手如下：
1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

tcp连接保证了数据的可靠传输，具体表现在如下方面：

1、TCP将每个字节的数据都进行了编号，即为序列号，每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据，下一次你从哪里开始发。
2、超时重传，传输数据时，可能会出现如下问题：
（1）主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B;
（2）主机A在一个特定时间间隔内没有收到B发来的确认应答, 会进行重发。
3、如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等一系列连锁反应。我们就需要流量控制机制，
（1）当接受方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失
（2）通过窗口来控制（窗口大小字段越大, 说明网络的吞吐量越高）
所以，简单来说，就是接收方处理不过来数据的时候，就把窗口缩小,并把窗口值告诉发送端。
4、慢开始、拥塞避免、快重传和快恢复。
（1）慢开始：由小到大逐步增加拥塞窗口数值。
拥塞窗口初始值 = 1至两个发送方最大报文段的数值；
拥塞窗口每次增加量 = min(新收到确认报文的字节数，发送方最大报文段的数值)。
拥塞避免:让拥塞窗口换慢增大。
每经过一个RTT就滑动窗口大小就只加1；
（2）快重传：接收方收到的数据后立即确认，一个数据包回一个确认ACK, 以实现尽早知道当中个别报文的丢失。
例如，当发送过程中M3数据包丢失，接收方只收到了M2与M4数据包时，接收方连续返回3个M2的ACK予发送方（提示发送方漏了M3小兄弟）；
发送方收到3个连续的M2的ACK后，立即重传M3数据包。
快恢复：遇到网络拥塞后，立马减小拥塞窗口。
设置一个ssthresh作为使用拥塞避免算法的起始点，通过这个ssthresh值为滑动窗口最大门限值的一半。
（3）快恢复：遇到网络拥塞后，立马减小拥塞窗口。
设置一个ssthresh作为使用拥塞避免算法的起始点，通过这个ssthresh值为滑动窗口最大门限值的一半。

建立tcp连接后浏览器向服务器发送http/https请求报文

早期的http1.0为了提高系统的效率，HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。但是，这也造成了一些性能上的缺陷。http1.0被抱怨最多的就是连接无法复用。

为了克服HTTP 1.0的这个缺陷，HTTP 1.1支持持久连接,在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减
少了整个下载过程所需要的时间。

// 请求
GET / HTTP/1.1
Host:xxx.xxxx.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2016042316 Firefox/3.0.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9;
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
If-Modified-Since: Mon, 25 May 2016 03:19:18 GMT
//响应
HTTP/1.1 200 OK
Cache-Control: private, max-age=30
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Expires: Mon, 25 May 2016 03:20:33 GMT
Last-Modified: Mon, 25 May 2016 03:20:03 GMT
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Mon, 25 May 2016 03:20:02 GMT
Content-Length: 12173

多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。在 HTTP/1.1 协议中浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞。这也是为何一些站点会有多个静态资源 CDN 域名的原因之一，拿 Twitter 为例，http://twimg.com，目的就是变相的解决浏览器针对同一域名的请求限制阻塞问题。而 HTTP/2 的多路复用(Multiplexing) 则允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。因此 HTTP/2 可以很容易的去实现多流并行而不用依赖建立多个 TCP 连接，HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧，这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。

https
起源：HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。简单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
步骤：
（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。
（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。
（3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。
（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。
（5）Web服务器利用自己的私钥解密出会话密钥。
（6）Web服务器利用会话密钥加密与客户端之间的通信。
~~非对称加密的方式太消耗性能，所以之后都是用会话秘钥加密，不再使用非对称加密~~

发送http请求后，服务器返回响应报文给客户端，客户端开始进行页面解析