前段基础第一天

最新推荐文章于 2023-04-11 15:55:14 发布

qq小可爱.

最新推荐文章于 2023-04-11 15:55:14 发布

阅读量391

点赞数

文章标签： html

本文链接：https://blog.csdn.net/m0_63072135/article/details/125724995

版权

https通信过程

1、客户端发起HTTPS请求
用户在浏览器里输入一个https网址，然后连接到服务器的443端口

2、服务端的配置
采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥

3、传送服务器的证书给客户端
证书里其实就是公钥，并且还包含了很多信息，如证书的颁发机构，过期时间等等

4、客户端解析验证服务器证书
这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如：颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书中公钥对该随机值进行非对称加密

5、客户端将加密信息传送服务器
这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了

6、服务端解密信息
服务端将客户端发送过来的加密信息用服务器私钥解密后，得到了客户端传过来的随机值

7、服务器加密信息并发送信息
服务器将数据利用随机值进行对称加密,再发送给客户端

8、客户端接收并解密信息
客户端用之前生成的随机值解密服务段传过来的数据，于是获取了解密后的内容

状态码

200   确定。客户端请求已成功
301   已永久移动。此请求和之后所有的请求都应该转到指定的 URI。
302   对象已移动。对于基于表单的身份验证，此消息通常表示为“对象已移动”。请求的资源临时驻留在不同的 URI。由于重定向有时可能会改变，客户端将来在请求时应该继续使用 RequestURI。只有在 CacheControl 或 Expires 标题字段中指示，此响应才能够缓存。
304   未修改。客户端请求的文档已在其缓存中，文档自缓存以来尚未被修改过。客户端使用文档的缓存副本，而不从服务器下载文档。
307   临时重定向。
308是http的状态返回码，用来表示当前请求的资源已经永久的转移到其他的uri，一般通过返回header的location字段展示。
400   错误的请求。
401   访问被拒绝。IIS 定义了几个不同的401错误，用于指示更为具体的错误原因。这些具体的错误代码在浏览器中显示，但不在 IIS 日志中显示。详见 401状态码。
403   服务器拒绝请求。可以理解为没有权限访问此网站，服务器能够收到请求但拒绝提供服务。IIS 定义了几个不同的403错误，用于指示更为具体的错误原因，详见 403状态码。
404   服务器找不到请求的网页。例如，访问网站中不存在的页面，或者原有页面被移走或删除，则可能会出现该状态码。IIS 定义了几个不同的404错误，用于指示更为具体的错误原因，详见 404状态码。
500   内部服务器错误。很多服务器端错误都可能导致此错误消息。事件查看器日志包含更详细的错误原因。此外，您可以禁用友好 HTTP 错误消息以便收到详细的错误说明。IIS 定义了几个不同的500错误，用于指示更为具体的错误原因，详见 500状态码。
501   页眉值指定了未实现的配置。
503   目前服务器无法使用，一般是因为服务器超载或停止维护。

访问一个URL经历了哪些过程

从大致上来讲经历了

客户端获取URL - > DNS解析 - > TCP连接 - >发送HTTP请求 - >服务器处理请求 - >返回报文 - >浏览器解析渲染页面 - > TCP断开连接

1、概要

从用户在浏览器输入域名开始，到web页面加载完毕，

2、分析
众所周知，打开一个网页的过程中，浏览器会因页面上的css/js/image等静态资源会多次发起连接请求，所以我们暂且把这个网页加载过程分成两部分：

html(jsp/php/aspx) 页面加载(假设存在简单的Nginx负载均衡)
css/js/image等网页静态资源加载(假设使用CDN)

2.1 页面加载
先上一张图，直观明了地让大家了解下基本流程，然后我们再逐一分析。

在这里插入图片描述
2.1.1 DNS解析
什么是DNS解析？当用户输入一个网址并按下回车键的时候，浏览器得到了一个域名。而在实际通信过程中，我们需要的是一个IP地址。因此我们需要先把域名转换成相应的IP地址，这个过程称作DNS解析。

2.1.2 发起TCP请求

浏览器会选择一个大于1024的本机端口向目标IP地址的80端口发起TCP连接请求。经过标准的TCP握手流程，建立TCP连接。

在这里插入图片描述

客户端：

（应用层开始）获取URL，通过负责域名解析的DNS服务获取网址的IP地址，根据HTTP协议生成HTTP请求报文（应用层结束）

（传输层开始）根据TCP协议连接从客户端到服务端（通过三次握手）客户端给服务端发送一个带SYN（同步）标志的数据包给客户端，然后客户端接收到信息再给客户端回传一个带有SYN / ACK（确认）标志的数据包以示传达确认信息，客户求最后端的再传送一个带ACK标志的数据包，代表“握手”结束，连接成功.TCP协议在把请求报文按序号分割成多个报文段（传输层结束）

（网络层开始）根据IP协议（传输数据），ARP协议（获取MAC地址），OSPF协议（选择最优路径），搜索服务器地址，一边中转一边传输数据（网络层结束）

（数据链路层开始）到达后通过数据链路层，物理层负责0,1比特流与物理设备电压高低，光的闪灭之间的互换。数据链路层负责将0,1序列划分为数据帧从一个节点传输到临近的另一个节点，这些节点是通过MAC来唯一标识的（MAC，物理地址，一个中主机会有一个MAC地址）。（数据链路层结束）

服务端

通过数据链路层 - >通过网络层 - >再通过传输层（根据TCP协议接收请求报文并重组报文段） - >再通过应用层（通过HTTP协议对请求的内容进行处理） - >再通过应用层 - >传输层 - >网络层 - >数据链路层 - >到达客户端

客户端

通过数据链路层 - >网络层 - >传输层（根据TCP协议接收响应报文并重组） - >应用层（HTTP协议对响应进行处理） - >浏览器渲染页面 - >断开连接协议四次挥手）

四次挥手

主动方发送标志位：（ACK + FIN）+（发送序号= 200 +确认序号= 500）第一次挥手

被动方接收后发送标志位：ACK +（发送序号=主动方确认序号500 +确认序号=主动方发送序号+1201）第二次挥手

标志位：（ACK + FIN）+（发送序号=主动方确认序号+1 501）第三次挥手

主动方接收后发送标志位：（ACK）+（发送序号=被动方的确认序号201 +确认序号=被动方的发生序号+1502）

在这里插入图片描述

2.1.3 发起HTTP请求
其实这部分又可以称为前端工程师眼中的HTTP，它主要发生在客户端。发送HTTP请求的过程就是构建HTTP请求报文并通过TCP协议中发送到服务器指定端口(HTTP协议80/8080, HTTPS协议443)。HTTP请求报文是由三部分组成: 请求行, 请求报头和请求正文。

响应报头
常见的响应报头字段有: Server, Connection…。

响应报文
服务器返回给浏览器的文本信息，通常HTML, CSS, JS, 图片等文件就放在这一部分。

2.1.4 负载均衡
什么是负载均衡？当一台服务器无法支持大量的用户访问时，将用户分摊到两个或多个服务器上的方法叫负载均衡。

什么是Nginx？Nginx是一款面向性能设计的HTTP服务器，相较于Apache、lighttpd具有占有内存少，稳定性高等优势。

负载均衡的方法很多，Nginx负载均衡、LVS-NAT、LVS-DR等。这里，我们以简单的Nginx负载均衡为例。关于负载均衡的多种方法详情大家可以Google一下。

Nginx有4种类型的模块：core、handlers、filters、load-balancers。

我们这里讨论其中的2种，分别是负责负载均衡的模块load-balancers和负责执行一系列过滤操作的filters模块。

1) 一般，如果我们的平台配备了负载均衡的话，前一步DNS解析获得的IP地址应该是我们Nginx负载均衡服务器的IP地址。所以，我们的浏览器将我们的网页请求发送到了Nginx负载均衡服务器上。

2) Nginx根据我们设定的分配算法和规则，选择一台后端的真实Web服务器，与之建立TCP连接、并转发我们浏览器发出去的网页请求。

Nginx默认支持 RR轮转法和 ip_hash法这2种分配算法。

前者会从头到尾一个个轮询所有Web服务器，而后者则对源IP使用hash函数确定应该转发到哪个Web服务器上，也能保证同一个IP的请求能发送到同一个Web服务器上实现会话粘连。

也有其他扩展分配算法，如：

fair：这种算法会选择相应时间最短的Web服务器

url_hash：这种算法会使得相同的url发送到同一个Web服务器

3) Web服务器收到请求，产生响应，并将网页发送给Nginx负载均衡服务器。

4) Nginx负载均衡服务器将网页传递给filters链处理，之后发回给我们的浏览器。
在这里插入图片描述

　而Filter的功能可以理解成先把前一步生成的结果处理一遍，再返回给浏览器。比如可以将前面没有压缩的网页用gzip压缩后再返回给浏览器。

2.1.5 浏览器渲染
1) 浏览器根据页面内容，生成DOM Tree。根据CSS内容，生成CSS Rule Tree(规则树)。调用JS执行引擎执行JS代码。

2) 根据DOM Tree和CSS Rule Tree生成Render Tree(呈现树)

3) 根据Render Tree渲染网页

浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树，然后解析CSS文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂，涉及到两个概念: reflow(回流)和repain(重绘)。DOM节点中的各个元素都是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为relow;当盒模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个过程称为repain。页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的，尤其是在移动设备上，它会破坏用户体验，有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。

JS的解析是由浏览器中的JS解析引擎完成的。JS是单线程运行，也就是说，在同一个时间内只能做一件事，所有的任务都需要排队，前一个任务结束，后一个任务才能开始。但是又存在某些任务比较耗时，如IO读写等，所以需要一种机制可以先执行排在后面的任务，这就是：同步任务(synchronous)和异步任务(asynchronous)。JS的执行机制就可以看做是一个主线程加上一个任务队列(task queue)。同步任务就是放在主线程上执行的任务，异步任务是放在任务队列中的任务。所有的同步任务在主线程上执行，形成一个执行栈;异步任务有了运行结果就会在任务队列中放置一个事件；脚本运行时先依次运行执行栈，然后会从任务队列里提取事件，运行任务队列中的任务，这个过程是不断重复的，所以又叫做事件循环(Event loop)。

浏览器在解析过程中，如果遇到请求外部资源时，如图像,iconfont,JS等。浏览器将重复1-6过程下载该资源。请求过程是异步的，并不会影响HTML文档进行加载，但是当文档加载过程中遇到JS文件，HTML文档会挂起渲染过程，不仅要等到文档中JS文件加载完毕还要等待解析执行完毕，才会继续HTML的渲染过程。原因是因为JS有可能修改DOM结构，这就意味着JS执行完成前，后续所有资源的下载是没有必要的，这就是JS阻塞后续资源下载的根本原因。CSS文件的加载不影响JS文件的加载，但是却影响JS文件的执行。JS代码执行前浏览器必须保证CSS文件已经下载并加载完毕。

2.2 网页静态资源加载
以阿里巴巴的淘宝网首页的logo为例，其url地址为 img.alicdn.com/tps/i2/TB1bNE7LFXXXXaOXFXXwFSA1XXX-292-116.png_145x145.jpg

我们清楚地看到了url中有cdn字样。

什么是CDN？如果我在广州访问杭州的淘宝网，跨省的通信必然造成延迟。如果淘宝网能在广东建立一个服务器，静态资源我可以直接从就近的广东服务器获取，必然能提高整个网站的打开速度，这就是CDN。CDN叫内容分发网络，是依靠部署在各地的边缘服务器，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度。

接下来的流程就是浏览器根据url加载该url下的图片内容。本质上是浏览器重新开始第一部分的流程，所以这里不再重复阐述。区别只是负责均衡服务器后端的服务器不再是应用服务器，而是提供静态资源的服务器。

Web优化
上面部分主要介绍了一次完整的请求对应的过程，了解该过程的目的无非就是为了Web优化。在谈到Web优化之前，我们回到一个更原始的问题，Web前端的本质是什么。我的理解是: 将信息快速并友好的展示给用户并能够与用户进行交互。快速的意思就是在尽可能短的时间内完成页面的加载，试想一下当你在淘宝购买东西的时候，淘宝页面加载了10几秒才显示出物品，这个时候你还有心情去购买吗？怎么快速的完成页面的加载呢？优雅的学院派雅虎给出了常用的一些手段，也就是我们熟悉的雅虎34条军规。这34军规实际上就是围绕请求过程进行的一些优化方式。

如何尽快的加载资源？答案就是能不从网络中加载的资源就不从网络中加载，当我们合理使用缓存，将资源放在浏览器端，这是最快的方式。如果资源必须从网络中加载，则要考虑缩短连接时间，即DNS优化部分;减少响应内容大小，即对内容进行压缩。另一方面，如果加载的资源数比较少的话，也可以快速的响应用户。当资源到达浏览器之后，浏览器开始进行解析渲染，浏览器中最耗时的部分就是reflow，所以围绕这一部分就是考虑如何减少reflow的次数。