你知道奇怪的移动视口错误（也称为100vh bug）吗？或者如何以正确的方式创建全屏块？
什么是移动视口错误？
你是否曾经在网页上创建过全屏元素？只需添加一行 CSS 并不难： TCP拥塞控制与流量控制区别？
-
拥塞控制就是为了防⽌过多的数据注⼊到⽹络中 这样就可以使⽹络中的路由器或链路不致过载。 拥塞控制所要做的都有⼀个前提，就是⽹络能 够承受现有的⽹络负荷。拥塞控制是⼀个全局性的过程，涉及到所有的主机，所有的路由器， 以及与降低⽹络传输性能有关的所有因素。
-
流量控制往往是点对点通信量的控制 是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得 及接收。
操作系统的功能
介于硬件资源和应⽤程序之间的⼀个系统软件。
操作系统位于硬件资源之上，管理硬件资源。 应⽤程序之下，为应⽤程序提供服务， 同时管理应⽤程序。
进程的概念
我们编译的代码可执⾏⽂件只是储存在硬盘的静态⽂件，运⾏时被加载到内存，CPU执⾏内存中指令，这个运⾏的程序被称为进程。
进程是对运⾏时程序的封装，操作系统进⾏资源调度和分配的基本单位。
并发与并⾏
-
单个核⼼在很短时间内分别执⾏多个进程，称为并发。
-
多个核⼼同时执⾏多个进程称为并⾏。 对于并发来说，CPU需要从⼀个进程切换到另⼀个进程，这个过程需要保存进程的状态信息。
线程的特点
-
线程是轻量级进程(light-weight process)，也有PCB（进程管理块）。
-
从内核⾥看进程和线程是⼀样的，都有各⾃不同的PCB
-
进程可以蜕变成线程
-
在linux下，线程最是⼩的执⾏单位；进程是最⼩的分配资源单位。 实际上，⽆论是创建进程的fork，还是创建线程的pthread_create，底层实现都是调⽤同⼀个 内核函数 clone。
线程的优缺点
优点
-
提⾼程序并发性
-
开销⼩
-
数据通信、共享数据⽅便 缺点
-
库函数，不稳定
-
调试、编写困难、gdb不⽀持
-
对信号⽀持不好
线程通信
线程间的通信⽬的主要是⽤于线程同步。所以线程没有像进程通信中的⽤于数据交换的通信机制。
同⼀进程的不同线程共享同⼀份内存区域，所以线程之间可以⽅便、快速地共享信息。只需要 将数据复制到共享（全局或堆）变量中即可。但是需要避免出现多个线程试图同时修改同⼀份信息。
多线程的好处
主要原因是许多应⽤中同时发⽣多个活动，某些活动随着时间推移⽽阻塞，将这些应⽤程序分解成并发运⾏的多个线程，简化设计模型。
同时多线程有共享同⼀地址空间和可⽤数据的能⼒，这是多进程没有的。
线程⽐进程开销⼩，更容易创建和释放。
多个线程是IO密集型时，多线程可以使这些活动彼此重叠运⾏，可以加快程序执⾏的速度。
无损压缩
无损压缩是指资源经过压缩后，信息不被破坏，还能完全恢复到压缩前的原样，适合用在文本文件、程序可执行文件、程序源代码。
需要对原始资源建立统计模型，利用这个统计模型，将常出现的数据用较短的二进制比特序列表示，将不常出现的数据用较长的二进制比特序列表示，生成二进制比特序列一般是「霍夫曼编码」算法。 gzip， br。
有损压缩
与无损压缩相对的就是有损压缩，经过此方法压缩，解压的数据会与原始数据不同但是非常接近。
有损压缩主要将次要的数据舍弃，牺牲一些质量来减少数据量、提高压缩比，这种方法经常用于压缩多媒体数据，比如音频、视频、图片。
图片一般采用WebP，因为他有较高的压缩比。
对于视频常见的编码格式有 H264、H265 等，音频常见的编码格式有 AAC、AC3。
http优点
-
简单。body + head
-
灵活，易扩展。可以自动设置请求头，为固定死，而且下层协议也可以随之改变。
-
应用广泛，跨平台。天然的跨平台性。
http缺点
-
明文。（两面性）
利：利于开发人员调试
弊：不安全。
-
无状态。（双面性）
利：服务器不需要使用额外的内存来记录状态，减轻了服务器的压力。
弊： 它在完成有关联性的操作时会非常麻烦。
-
不安全
不验证通信方的身份，因此有可能遭遇伪装。
明文传输，可能被拦截。
无法验证报文的完整性。
https的安全性
-
摘要算法：确认数据的完整性。
-
数字证书：确认身份，数据没有冒充。
-
混合加密：数据加密。
TLS握手的秘钥交换算法
因为考虑到性能的问题，所以双方在加密应用信息时使用的是对称加密密钥，而对称加密密钥是不能被泄漏的，为了保证对称加密密钥的安全性，所以使用非对称加密的方式来保护对称加密密钥的协商，这个工作就是密钥交换算法负责的。
主要就是为了生成一个堆成加密的秘钥的。
密码套件格式解析
基本的形式是「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」， 一般 WITH 单词前面有两个单词，第一个单词是约定密钥交换的算法（tls生成堆成加密秘钥），第二个单词是约定证书的验证算法。
下面来看一下例子：
-
由于 WITH 单词只有一个 RSA，则说明握手时密钥交换算法和签名算法都是使用 RSA；
-
握手后的通信使用 AES 对称算法，密钥长度 128 位，分组模式是 GCM；（因为秘钥只能加密一定长度的数据，如果数据过长，需要分组加密在合并。）
-
摘要算法 SHA256 用于消息认证和产生随机数；
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」
-
密钥协商算法使用 ECDHE；
-
签名算法使用 RSA；
-
握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM；
-
摘要算法使用 SHA384；
服务端证明自己的身份
会发送「Server Certificate」给客户端，这个消息里含有数字证书。
RSA算法实现TLS握手的缺陷
使用 RSA 密钥协商算法的最大问题是不支持前向保密。
因为客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到到后，会用私钥解密得到随机数。所以一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。
为了解决这个问题，使用 ECDHE 密钥协商算法。
RSA 和 ECDHE 握手过程的区别
-
RSA 密钥协商算法「不支持」前向保密，ECDHE 密钥协商算法「支持」前向保密；
-
使用了 RSA 密钥协商算法，TLS 完成四次握手后，才能进行应用数据传输，而对于 ECDHE 算法，客户端可以不用等服务端的最后一次 TLS 握手，就可以提前发出加密的 HTTP 数据，节省了一个消息的往返时间；
-
使用 ECDHE， 在 TLS 第 2 次握手中，会出现服务器端发出的「Server Key Exchange」消息，而 RSA 握手过程没有该消息。
HPACK 算法
HTTP / 2专门用于压缩http头部字段的一种高压缩比算法。
客户端和服务器两端都会建立和维护字典，用长度较小的索引号表示重复的字符串，再用 Huffman 编码压缩数据，可达到 50%~90% 的高压缩率。
静态表编码
HTTP/2 为高频出现在头部的字符串和字段建立了一张静态表，它是写入到 HTTP/2 框架里的，不会变化的，静态表里共有 61 组。
动态表编码
静态表只包含了 61 种高频出现在头部的字符串，不在静态表范围内的头部字符串就要自行构建动态表，它的 Index 从 62 起步，会在编码解码的时候随时更新。
所以，使得动态表生效有一个前提：必须同一个连接上，重复传输完全相同的 HTTP 头部。如果消息字段在 1 个连接上只发送了 1 次，或者重复传输时，字段总是略有变化，动态表就无法被充分利用了。
HTTP/2 的推送是怎么实现的
他会主动推送html页面中引入的css,img,js等资源，而不需要客户端再次请求。
客户端发起的请求，必须使用的是奇数号 Stream，服务器主动的推送，使用的是偶数号 Stream。服务器在推送资源时，会通过 PUSH_PROMISE 帧传输 HTTP 头部，并通过帧中的 Promised Stream ID 字段告知客户端，接下来会在哪个偶数号 Stream 中发送包体。
HTTP/2中存在的问题
TCP的对头阻塞
因为 TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且有序的，如果序列号较低的 TCP 段在网络传输中丢失了，即使序列号较高的 TCP 段已经被接收了，应用层也无法从内核中读取到这部分数据，从 HTTP 视角看，就是请求被阻塞了。
TCP, TLS握手的延时
TCP 由于具有拥塞控制的特性，所以刚建立连接的 TCP 会有个慢启动的过程。
网络迁移需要重新连接
TCP报文具有ip地址和端口号，当ip / 端口号改变时，TCP / TLS将会重新握手，不利于移动设备切换网络场景。例如用户从4G网络切换至wifi。
以前在极客时间上学习过网络的一些知识，但是我感觉小林coding总结的真的是太到位了。对面试特别有用。
.my-page {
height: 100vh
}
1vh是视口高度的1% ，正是我们所需要的。但当我们在移动设备上测试时，就会出现问题。移动浏览器的视口可以动态改变，但值保持不变。因此在移动浏览器中vh变成静态值并且不反映视口的实际高度。
在下图中，可以看到移动屏幕的两种状态：
带有隐藏的地址栏
具有可见的地址栏
核心问题是移动浏览器（Chrome 和 Safari）有一个“有用”的功能，地址栏有时可见，有时隐藏，从而改变视口的可见大小。这些浏览器并没有随着视口高度的变化而将高度调整100vh为屏幕的可见部分，而是将100vh地址栏设置为隐藏地址的浏览器高度。结果是，当地址栏可见时，屏幕的底部将被切断，从而违背了100vh最初的目的。
有什么方法可以解决这个问题？
1. CSS + Javascript
使用的解决方案涉及使用CSS 自定义属性和一些Javascript。
简而言之，我们监听resize事件并在每次窗口大小更改时设置--vh自定义属性（窗口高度的1% ）：
核心功能代码：
let vh = window.innerHeight * 0.01
document.documentElement.style.setProperty('--vh', `${vh}px`)
window.addEventListener('resize', () => {
let vh = window.innerHeight * 0.01
document.documentElement.style.setProperty('--vh', `${vh}px`)
})
<div class="module">
<div class="module__item">20%</div>
<div class="module__item">40%</div>
<div class="module__item">60%</div>
<div class="module__item">80%</div>
<div class="module__item">100%</div>
</div>
body {
background-color: #333;
}
.module {
height: 100vh;
height: calc(var(--vh, 1vh) * 100);
margin: 0 auto;
max-width: 30%;
}
.module__item {
align-items: center;
display: flex;
height: 20%;
justify-content: center;
}
.module__item:nth-child(odd) {
background-color: #fff;
color: #F73859;
}
.module__item:nth-child(even) {
background-color: #F73859;
color: #F1D08A;
}
2. 使用 -webkit-fill-available
.my-page {
background-color: #ffffff;
min-height: 100vh;
min-height: -webkit-fill-available;
overflow-y: scroll;
padding-bottom: 50px;
}
此方法chrome浏览器中在某些情况下使用会有问题。
因此引出下文第三种方法。
3. postcss-100vh-fix
当然，你也可以使用第三方库来进行修复，具体使用可查看其官网 postcss-100vh-fix。[3]
它适用于 Chrome（ -webkit-fill-available 在某些情况下只会在 Chrome 中导致问题）、iOS/iPad/MacOS Safari 和 所有其他浏览器 。纯CSS解决方案，无需JS。
body {
height: 100vh;
}
body {
height: 100vh;
}
@supports (-webkit-touch-callout: none) {
body {
height: -webkit-fill-available;
}
}
此方法不适用于部分高度，例如height: 90vh 或height: calc(100vh - 60px)
根据CSS Values 4 规范：视口相对长度[4]，我们可以使用新的视口单位。
有一个dvh单位可以完成全部工作。它始终会适应视口大小。最后，浏览器支持如下：
有了这个很酷的功能，解决方案变得非常简单，只需要一行 CSS：
.my-page {
height: 100dvh
}
可以在此[5]了解更多的动态视口单元信息，如：dvw、dvh、dvi、dvb、dvmin 和 dvmax等。
如今，CSS 发展迅速，对解决前端问题有很大帮助。该dvh单位是制作视口相关高度的最佳选择。这是一个非常简单而强大的 CSS 功能，可以让你的工作变得更加轻松。
406
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
