网络协议 + 性能优化
image.png

物理层：网卡，网线
数据链路层：网桥，交换机
网络层：路由器： 寻址、 路由算法、 连接服务
传输层：监控服务质量

TLS
image.png


渲染页面工作原理
https://developer.mozilla.org/zh-CN/docs/Web/Performance/How_browsers_work
HTTP
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Overview

CDN

请求点到服务器之间的距离越大，中间存在的节点就越多
RTT sender <-> server 的往返时间

一、CDN 服务商在很多城市设立机房
用户发送请求，用户电脑的操作系统会先向 DNS 域名服务器查询域名对应的 ip；
二、DNS 解析
1、用户——->DNS 服务器（接受 requestIP address）->粗略计算离请求节点最近的服务器响应用户请求；
2、CDN 缓存请求资源、缓存的有效性（清除）；
静态资源的 hash 请求；
减轻服务器的静态资源的请求压力；

加速域名：未接受请求的域名增加 CDN 缓存，通过域名配置下发全网；
回源配置：未缓存的资源请求、302（已存在的资源被临时改变了位置，导致用户无法访问到对应的资源，location）
缓存配置
访问控制

DNS

管理识别的域名转换为计算机用于互连通信的数字 IP 地址，从而将用户的访问路由到相应的网站或应用服务器
智能解析
容灾切换
请求统计
全局流量管理（就近接入、高并发负载均摊、应用服务的健康检查，并能够根据健康检查结果实现故障隔离或流量切换）

TCP 连接

什么是 TCP：
TCP 是一种面向连接的单播协议，在发送数据前，通信双方必须在彼此间建立一条连接；
用于保证可靠性和流控制机制的信息，包括 Socket、序列号以及窗口大小叫做连接；
TCP 能保证数据的交付，维持数据包的发送顺序;
传输层有两个传输协议：TCP(传输控制协议)和 UDP(用户数据报协议)。其中，TCP 是一个可靠的面向连接的协议，udp 是不可靠的或者说无连接的协议；
UDP：无序、无连接、有长度、支持多播和广播
TCP：有序、有连接、字节流、双方通信；

TCP 如何在不稳定的网络环境，建立稳定的链接，进行通信—->为什么需要三次握手；

1、阻止无效历史连接
阻止历史的重复连接初始化造成的混乱问题；
发送方判断连接是否有效；
需要连接请求（初始化）syn（1）
2、序列号解决发送的顺序问题
Seq（x）
3、三次是最少通信次数
SYN_SENT SYN=1 seq=x
SYN_RCVD SYN=1 seq=y ACK=1（确认包）ACKnum=x+1
ESTABLISHED ACK=1 ACKnum=y+1
4、四次结束
FIN_WAIT_1 FIN=1，seq=x
CLOSE_WAIT ACK=1，ACKnum=x+1
LAST_ACK FIN=1，seq=y
TIME_WAIT ACK=1，ACKnum=y+1 等待可能出现的要求重传的 ACK 包
CLOSED 服务器接受确认包

SYN —— 用于初如化一个连接的序列号。
ACK —— 确认，使得确认号有效。(seq 不是历史连接)。
RST —— 重置连接（seq 是历史连接），（经常看到的 reset by peer）就是此字段搞的鬼。
FIN —— 该报文段的发送方已经结束向对方发送数据。

keep-alive 活跃性和局限性
1、TCP KeepAlive 监测的方式是发送一个 probe 包，会给网络带来额外的流量；
2、TCP KeepAlive 只能在内核层级监测连接的存活与否，而连接的存活不一定代表服务的可用；

IP

IP 是点对点
TCP/UDP 是端对端

HTTP1、HTTP2、HTTP3

https://developer.mozilla.org/zh-CN/docs/Web/HTTP
HTTP 是应用层的协议，通过 TCP，或者是 TLS－加密的 TCP 连接来发送，理论上任何可靠的传输协议都可以使用
HTTP 是一个 client-server 协议
client - proxy - proxy Server
proxy：有可能是网管、caches
一、HTTP 特性（能控制什么）：
1、HTTP 是无状态的，使用 cookies 建立有状态的会话；
2、缓存 请求头和响应头都支持这个属性
缓存是一种保存资源副本并在下次请求时直接使用该副本的技术。
当 web 缓存发现请求的资源已经被存储，它会拦截请求，返回该资源的拷贝，而不会去源服务器重新下载
cache control
Cache-Control: no-store 没有缓存
Cache-Control: no-cache 缓存但重新验证
Cache-Control: private
Cache-Control: public
Cache-Control: max-age=31536000
Cache-Control: must-revalidate
缓存在考虑使用一个陈旧的资源时，必须先验证它的状态，已过期的缓存将不被使用
Pragma 以向后兼容基于 HTTP/1.0 的客户端
新鲜度：C 端 If-None-Match，If-Modified-Since，S 端返回 304（not modified）继续使用
流程：
A、c1 端发送请求，s 响应 cache 进行缓存 res
B、c2 端有效期内，直接返回；
C、C3 端过了有效期，发送 if-non-match，校验到 S 端；
max-age=N、Expires、Last-Modified

改进资源：
不频繁更新的资源：特殊命名加上版本号（所有饮用的地方，都需要更新链接）
解决：用高频率修改的文件，更新低频率文件

ETags
作为缓存的一种强校验器；
响应头是一个对用户代理(User Agent, 下面简称 UA)不透明
使用 If-None-Match 头来验证缓存

Last-Modified 响应头可以作为一种弱校验器，If-Modified-Since 来验证缓存

Vary 响应头
只有当前的请求和原始（缓存）的请求头跟缓存的响应头里的 Vary 都匹配

3、同源策略 和 CORS 跨域资源共享
https://developer.mozilla.org/zh-CN/docs/Web/Security/Same-origin_policy
限制的行为
1.) Cookie、LocalStorage 和 IndexDB 无法读取
2.) DOM 和 Js 对象无法获得
3.) AJAX 请求不能发送

IE 特性
A：授信范围，高度授信的域名，eg：公司域名
B：端口
源的更改 document.domain（父域和子域都要设置）

X-Frame-Options 响应头：
给浏览器 指示允许一个页面 可否在 , , 或者

允许跨域访问 CORS
允许服务端来指定哪些主机可以从这个服务端加载资源
前端：xhr.withCredentials = true; （携带 cookie）

CORS edas 是如何部署的 edas 访问 edasnext

https://segmentfault.com/a/1190000011145364
专有云有预检、公有云跨域携带 cookie

如何组织跨于访问

A、CSRF token
跨站请求伪造（CSRF）是一种冒充受信任用户，向服务器发送非预期请求的攻击方式
secure token

跨源脚本 API 访问

跨源数据存储访问
localStorage、indexedDB
当你读取 cookie 时，你无法知道它是在哪里被设置的

4、认证 Authenticate
一些页面能够被保护起来，仅让特定的用户进行访问；
设置响应头
5、代理和隧道
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Proxy_servers_and_tunneling
二、基于 HTTP 的 API
XMLHttpRequest
Fetch API
EventSource 接口
server-to-client 接口
A：长期有效连接、支持 CORS
Event 对象

HTTPS 7 次握手

HTTPS：建立链接需要 7 次握手
https://blog.csdn.net/u010285974/article/details/85320788

TCP 解决了数据不乱、不重、不漏，而 TLS 解决了数据的安全问题；

http1.0 2.0 3.0 进化史

https://network.51cto.com/art/202010/628901.htm
HTTP 协议的瓶颈及其优化技巧都是基于 TCP 协议本身的特性；
例如 TCP 建立连接的 3 次握手和断开连接的 4 次挥手以及每次建立连接带来的 RTT 延迟时间；
1.0
1、无状态无连接的协议，每次请求都要建立 TCP 连接；
2、服务器处理完，会立即断开链接；
3、需要利用 cookie、session 识别身份
缺点：
1、无法复用连接：每次都要建立 TCP 连接，降低网络的利用率
2、队头阻塞：下一个请求必须在前一个请求响应到达之前才能发送

1.1
1、增加 Connection 字段，设置 keep-alive 保持 HTTP 连接（维持一段时间）；
2、客户端发送请求携带 Connection：fasle，关闭连接
3、不成熟的管道化：基于长连接，http 请求可以“并行传送”；

  • 服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容。
  • 也就是说，HTTP 管道化可以让我们把先进先出队列从客户端(请求队列)迁移到服务端(响应队列)

4、TCP 连接数：浏览器支持的连接数有限制
5、缓存处理

问题：
一、队头阻塞问题依然明显；
1、每个域名 6 个持久链接；
2、webpack 合并文件
3、雪碧图合并 icon；
4、内链样式，图片写在样式文件；
这些 1.1 优化：打破了 http1.1 缓存的优势；
二、http 独立没有状态，
1、重复发送 useragent 的字段；
2、cookie，authorized 请求头，认证信息

2.0 持久化连接，一个 TCP 连接
1、二进制分帧 Frame（流）改进传输性能，实现低延迟和高吞吐量；

  • 每个流有唯一整数标识符。
  • 为了防止两端流 ID 冲突，客户端发起的流具有奇数 ID，服务器端发起的流具有偶数 ID

2、多路复用(链接共享)— 真并行传输

  • 针对同一域名下的请求有一定数量的限制，超过限制数目的请求会被阻塞。
  • 这也是为何一些站点会有多个静态资源 CDN 域名的原因之一
  • 这些帧可以乱序发送，然后再根据每个帧头部的流标识符(Stream_id)重新封装

3、头部压缩：之前 header 是纯文本，现在是 encoder 二进制，增加 一份 cache 表 header_files
4、服务器推送 Eventsource，是减少请求时间；

5、优先级：html、css、js、image

问题：集中在 TCP 三次连接问题
1、所有的压力集中在底层一个 TCP 连接之上，TCP 分组的队首阻塞；
2、单个 TCP packet 丢失导致整个连接阻塞，无法逃避，等待重传的过程阻塞；

渲染页面的过程

XSS、CSFR 等攻击

跨站脚本(XSS)和跨站点请求伪造(CSRF)

性能优化

初始页面加载的 14Kb 规则
一、解析：通过网络接收的数据转换为 DOM 和 CSSOM 的步骤
二、构建 DOM 树（占用了主线程，5 步骤）
1、处理 HTML 标记并构造 DOM 树、预加载扫描器：不必等到解析器找到对外部资源的引用来请求它；主 HTML 解析器到达请求的资源时，它们可能已经在运行，或者已经被下载
2、构建 CSSOM 树（CSSOM 的总时间通常小于一次 DNS 查找所需的时间）

  • JavaScript 编译：JavaScript 被解释、编译、解析和执行，脚本被解析为抽象语法树；

渲染：样式、布局、绘制、合成
style、解析步骤中创建的 CSSOM 树和 DOM 树组合成一个 Render 树，然后用于计算每个可见元素的布局，然后将其绘制到屏幕上
3、第三步是将 DOM 和 CSSOM 组合成一个 Render 树，计算样式树或渲染树从 DOM 树的根开始构建，遍历每个可见节点，每个可见节点都应用了其 CSSOM 规则；
4、layout、渲染树上运行布局以计算每个节点的几何体，构建渲染树后，开始布局
5、最后一步是将各个节点绘制到屏幕上，第一次出现的节点称为 first meaningful paint。

”Time to Interactive“（TTI）是测量从第一个请求导致 DNS 查找和 SSL 连接到页面可交互时所用的时间——可交互是”First Contentful Paint“之后的时间点，页面在 50ms 内响应用户的交互

https://www.cnblogs.com/dream111/p/13458857.html

项目中的性能优化

发布订阅、slider；
通过config制造不同的UI；
性能优化：大量图片（滚动），前端处理数据（缓存），大量Tab中的DOM；

架构：
1、性能优化（不要局限于前端的性能优化，能不能做中台解决）；
2、组件设计；
3、数据请求缓存（query参数）；
4、虚拟滚动；
5、发布订阅，同步交互；
6、worker、可视化区域检测，IntersectionObserver

掘金性能优化
https://juejin.cn/post/6844903501953237006

页面的生命周期
https://zh.javascript.info/onload-ondomcontentloaded
性能工具
https://juejin.cn/post/6953220613104205855
Har文件分析
http://www.softwareishard.com/blog/har-12-spec/
performance 对象
longtask 没有打印具体那个任务