大家好，我是小秃，人人都有个大厂梦，可落花有意，流水无情，大厂动不动就要用寄网来拷打我😢😢，但千万不要放弃！！！ 你一定可以！！下面我就贴出整理的一部分计网方面的知识供大家学习或者查漏补缺。
部分总结与知识点梳理以及相关图片参考自图解网络介绍 | 小林coding
温馨提示：虽然面试向，但是说了是大厂面试版，所以还是有一定深度，同学们按需食用效率更高哦~
1.网络模型：
（1）TCP/IP四层参考模型
应用层 -> 传输层 -> 网络层 -> 网络接口层
第一层：网络接口层
包括用于协作IP数据在已有网络介质上传输的协议。实际上TCP/IP标准并不定义与ISO数据链路层和物理层相对应的功能。相反，它定义像地址解析协议（Address Resolution Protocol，ARP）这样的协议，提供TCP/IP协议的数据结构和实际物理硬件之间的接口。
第二层：网间层
对应于OSI七层参考模型的网络层。本层包含IP协议、RIP协议（Routing Information Protocol，路由信息协议)，负责数据的包装、寻址和路由。同时还包含网间控制报文协议（Internet Control Message Protocol，ICMP）用来提供网络诊断信息。
第三层：传输层
对应于OSI七层参考模型的传输层，它提供两种端到端的通信服务。其中TCP协议（Transmission Control Protocol）提供可靠的数据流运输服务，UDP协议（User Datagram Protocol）提供不可靠的用户数据报服务。
第四层：应用层
对应于OSI七层参考模型的应用层和表示层。因特网的应用层协议包括Finger、Whois、FTP（文件传输协议）、Gopher、HTTP（超文本传输协议）、Telent（远程终端协议）、SMTP（简单邮件传送协议）、IRC（因特网中继会话）、NNTP（网络新闻传输协议）等。
（2）OSI七层参考模型
应用层 -> 表示层 -> 会话层 -> 传输层 -> -> 网络层 -> 数据链路层 -> 物理层
第一层：物理层
通过电子、机械的方式传输比特流
第二层：数据链路层
将电信号转换为数字信号，并进行一些物理寻址之类的工作，常见协议，ARP mac寻址
第三层：网络层
负责子网的划分，路由的跳转，负责子网的运行 ip协议
第四层：传输层
负责数据的划分以及将数据呈递给网络层，并保证数据的有效传输
第五层：会话层
负责管理同通信会话，代表协议比如安全套接字协议SSL，安全传输协议TLS
第六层：表示层
负责数据的加密与解密工作
第七层：应用层
负责应用程序之间的传输协议，如http,https
2.HTTPS解决HTTP安全问题，以及相应的解决方案
(1)窃取风险
由于HTTP的明文传输，导致信息在网络上实际是 “裸奔状态” ，所以，https通过混合加密的方式进行数据加密传输
混合加密：
https使用对称加密与非对称加密的方式进行数据加密：
- 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
- 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。 以上也是HTTPS使用混合加密通信的原因
- 在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
- 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。
注意：非对称加密方式是可以双向加解密的，可以使用私钥加密公钥解密也可以使用公钥加密私钥解密，方式的不同意味着目的不同：
(1)公钥加密->私钥解密:目的是保证内容传输的安全，因为私钥是保密的，只有持有与公钥对应的私钥的人才可以解析数据
(2)私钥加密->公钥解密：目的是保证消息不被冒充，因为私钥只有与公钥对应的一方才有，并且私钥是保密的，如果使用公钥可以解析数据，说明对方是受信任的私钥持有者
所以非对称加密的用途主要在于通过「私钥加密，公钥解密」的方式，来确认消息的身份，我们常说的数字签名算法，就是用的是这种方式，不过私钥加密内容不是内容本身，而是对内容的哈希值加密。
(2)篡改风险
网络攻击中存在脚本注入的攻击方式，https使用摘要算法保证请求或者回复数据的完整性，防止篡改。具体做法是，通过哈希函数，根据内容生成一个哈希值，这个值针对该内容是唯一的，不能通过其他值推导出来，通信时，客户端或者服务端会将内容与该哈希值一起传输，接收方会根据收到的内容使用相同的算法再生成一次哈希值，如果与传输来的哈希值相同说明数据没于篡改
问题 内容与哈希值被替换的风险
虽然哈希值不可被推导，但是攻击者有可能使用拦截手段拦截请求或者响应，然后将整个内容与哈希值替换，在发送给接收方，那么接收方验证时，哈希值依旧相同。
解决方案：
使用数字签名。数字签名实际上就是使用上面说到的非对称加密中的私钥加密，公钥解密的方式，服务端会向客户端发布公钥，然后每次向客户端发送数据时，生成的哈希值会使用服务器自己的私钥进行加密，传输时，即使攻击者获取了内容与加密的哈希值，他伪造的哈希值并不能使用真正服务器的私钥加密，那么也就通不过客户端的公钥解密
（2）数字证书
根据以上我们知道，使用数字签名可以一定程度上保证数据不被伪造，但是还从在一个问题是，攻击者不可以从服务器获取私钥加密篡改的哈希值，从而不能通过客户端的公钥解密，那么攻击者可以从客户端下手，修改客户端手里拿到的公钥，将其变成自己的私钥对应的公钥那么伪造的数据就可以通过验证，那么针对这样的问题，我们将数字签名扩充成为数字证书，并且将数字证书交由权威机构管理（CA），来进一步避免篡改风险
具体做法：
服务器将自己公钥提交到权威认证机构，机构会使用自己的密钥将服务器的公钥加密生成一个数字签名，然后会将服务器信息、数字签名、服务器公钥生成一个数字证书，然后将该数字证书返回给服务器，然后服务器在每次发送数据时会先将哈希值使用自己的私钥加密，然后将加密数据和数字证书一起发送给客户端，客户端在拿到加密数据与数字证书后，首先会针对数字证书向认证机构求证，认证机构会使用自己的公钥对数字证书中的数字签名进行验证，验证成功后则会告诉客户端，证书没问题，客户端则会使用证书中的公钥对加密数据进行解密
3.HTTPS建立连接的过程，以及交互的数据？
HTTP建立连接的过程，实际上就是增加对端口的监听，主要是TCP的连接建立，而HTTPS的连接建立就是在TCP三次握手之后，增加了TLS的加密层连接，连接主要有RSA算法与EDHE算法，针对RSA主要涉及四次通信
(1)clientHello
客户端发起连接请求，向服务端发送clientHello,数据包括：
- 客户端支持的TLS版本号
- 客户端生成的随机数，为后续生成会话密钥
- 客户端支持的密码套件列表，比如RSA算法
(2)serverHello
- 服务端确认的TLS版本号，如果不支持客户端版本号就关闭通信
- 服务端生成的随机数，为后续生成会话密钥
- 服务端确认支持的密码套件列表
- 服务端的数字证书
(3)客户端回应
客户端收到服务器端的回应以及数字证书后，会使用操作系统或者浏览器中的CA公钥进行数字证书中数字签名的验证，如果验证无误，则会发送如下数据：
- 一个随机数，使用数字证书中的服务器公钥加密
- 加密算法改变通知，表示随后的数据都将使用会话密钥进行通信
- 客户端握手结束通知，表示客户端握手结束，并且会对之前交互的数据使用摘要算法生成一个加密的哈希值用于服务端验证数据完整性
(4)服务器响应
- 加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
- 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。
至此TLS连接结束，接下来使用的就是简单的HTTP协议，只不过内容不在是明文传输的了，而是使用会话密钥加密过的
4.HTTPS如何保证数据完整性的
主要通过两部分来保证数据完整：
(1)握手协议
主要指TLS的四次握手过程，验证数字证书以及生成对称会话密钥来进行数据的加密传输
(2)记录协议
主要通过对数据的分片，压缩，然后加上消息验证码，然后使用对称加密算法加密的方式来防止数据的篡改 其中消息验证码是通过哈希函数计算出的，客户端会针对报文再使用哈希函数生成哈希值与该验证码比较，以防止篡改。
5.EDHE密钥交换算法解析
EDHE密钥交换算法是由DHE算法优化而来，而DHE算法是基于DH算法的。
(1)DH算法
DH算法的核心思想是使用了离散对数，而离散对数是在对数运算的基础上进行了求余运算(mod),公式如下
当模数
P是一个很大的质数时，现有计算机计算能力很难通过逆运算计算出I
基于这一点,DH算法要求事先会确定底数（用G表示）模数（用P表示）,这两个参数是对外公布的，然后客户端与服务端会随机生成一个数作为自己的私钥（客户端用a表示，服务端用b表示），这个私钥需要严格保密，不可泄漏，然后根据离散对数的计算公式，客户端与服务端各自计算出自己的公钥，这个公钥是对外公布的，客户端与服务端会交换各自的公钥，然后客户端与服务端会使用对方的公钥作为底数，自己的私钥作为指数，结合之前确定的模数P，使用离散对数的计算方式计算出一个值（用K表示），这个K就是接下来建立连接之后进行加密通话的会话密钥，因为离散对数的幂运算具有交换性，所以服务端与客户端求得的K是相等的。推导过程如下：
所以接下来的通信就使用会话密钥通信即可，那么攻击者想要窃听通信就得破解会话密钥，破解会话密钥要么使用客户端或服务端任意一方的私钥，但这显然是不可能获得的，那么只能根据离散对数的求出方法，使用公开的底数
G、模数P、公钥A``B来计算破解来进行破解，获得私钥后再破解会话密钥，虽然理论上可行，但是实际计算中，现代计算机几乎处理不了这样的计算量，所以也就无法窃听通信了。
(2)DHE算法
针对DH算法的实现，主要有两种
- static DH算法
- DHE算法
<1> static DH算法
简单讲，static DH 算法就是针对DH算法的思想，对于通信一方的私钥是不变的（一般为服务端），那么也就是说，这一端的公钥也就是不变的了，每次只有客户端的私钥与公钥在改变，那么如果发生窃取，虽然通过公钥加底数模数的方式计算私钥非常难，但是也不无可能，在大量数据的加持下，还是有可能被破解的。因此这种方式不具备前向安全性
<2>DHE算法
DHE算法就是针对static DH算法的前向安全性进行优化，也就是，通信双方的私钥与公钥都是随机不断变化的，那么即使某次通信的通信双方的私钥泄露，那么也只会被窃取这一次的信息，之前与之后的信息安全还是保障的，因为每次连接时使用的会加密参数是独立的
(3)ECDHE算法
ECDHE的出现是为了解决DHE在计算性能上的问题，因为DHE需要对底数进行大量的乘法计算（G^a或G^b）所以在高并发情况下很消耗CPU性能，所以在此基础上，ECDHE使用ECC椭圆曲线的特性去计算公钥，这可以大大减少计算量
- 双方事先确定好使用哪种椭圆曲线，和曲线上的基点 G，这两个参数都是公开的；
- 双方各自随机生成一个随机数作为私钥d，并与基点 G相乘得到公钥Q（Q = dG），此时小红的公私钥为 Q1 和 d1，小明的公私钥为 Q2 和 d2；
- 双方交换各自的公钥，最后小红计算点（x1，y1） = d1Q2，小明计算点（x2，y2） = d2Q1，由于椭圆曲线上是可以满足乘法交换和结合律，所以 d1Q2 = d1d2G = d2d1G = d2Q1 ，因此双方的 x 坐标是一样的，所以它是共享密钥，也就是会话密钥。
这个过程中，双方的私钥都是随机、临时生成的，都是不公开的，即使根据公开的信息（椭圆曲线、公钥、基点 G）也是很难计算出椭圆曲线上的离散对数（私钥）。
6.简述基于ECDHE算法的TLS握手过程（四次握手）
(1)client Hello
客户端发起请求，发送支持的TLS版本号、支持的密码套件列表、随机数（用于后续生成会话密钥）
(2)server Hello
服务端收到客户端的请求后，会发送确认的TLS版本号、确认的密码套件、随机数（后续生成会话密钥）、还会发送自己的数字证书，以上与RSA算法的握手过程完全一致，但是不同的是基于ECDHE算法的TLS握手会在第二次握手发送了证书之后，发送一个server key exchange，这个消息中包含着ECDHE算法需要指定使用的椭圆双曲线模型（也就是确定基点G），以及生成一个私钥保存在本地，服务器使用自己私钥通过ECDHE算法生成椭圆双曲线公钥，为了防止公钥的篡改，服务器会使用RSA签名算法给这个椭圆双曲线公钥做签名，一同发送给客户端，所以本次握手会发送的东西如下：
1.确认的TLS版本号
2.确认的密码套件
3.生成的随机数
4.数字证书
5.生成的双曲线公钥
6.双曲线公钥的签名
(3)客户端响应
客户端收到服务器的数字证书之后会使用CA的根证书公钥进行一个信任链的验证，如果确认证书可靠，就会使用服务器发来的证书中的公钥验证双曲线公钥的签名，验证无误那么就会保留该公钥 此时客户端使用自己的随机数加对方的公钥，计算出一个值X，那么会话密钥就是：
Client Random + Server Random + X
之所以不直接使用计算出的X，是TLS设计者认为通信双方生成的随机数都是不可信的，通过加和可以大大提高随机性
接下来客户端会发送自己变更加密方式的通知，并将自己此前的通信数据做一个摘要，然后将摘要的哈希值使用会话密钥加密后发送给服务端以验证数据完整性，此时客户端已经可以发送数据了，不必等待服务端响应
(4)服务器响应
服务器收到客户端的信息后就会使用这边生成的会话密钥进行摘要的验证，验证无误之后，服务器也会发送变更加密方式的通知，以及将自己这边的通信数据做摘要用会话密钥加密后发送给客户端，至此握手结束
5.HTTP1.1如何优化
(1)使用缓存
如果多次请求相同数据，数据本身不易发生改变，那么可以将数据缓存在磁盘或者浏览器内存中，下次使用直接请求本地数据即可，而不用发送请求
(2)减少请求次数
<1>减少重定向
当资源在服务器中的位置发生改变时，客户端使用旧的url请求资源会触发重定向，服务器会返回新的url,并指示客户端重新请求，如果重定向多了，必然会产生很多无用的请求过程，所以要减少重定向的次数，比如服务器如果使用代理服务器与客户端进行交互，那么可以将重定向在代理服务器与真实服务器之间处理，那么从客户端来看，客户端只发送了一次请求就获得了正确数据。并且代理服务器可以将重定向规则缓存，下一次客户端再使用相同地址请求时，代理服务器自动使用重定向后的url请求数据
<2>合并请求
当需要请求很多数据时，在不使用管道模式的情况下，http1.1需要等到上一个请求的响应才会进行下一个请求，所以存在队头阻塞，浏览器为了避免这种阻塞，会舍弃长连接，依旧为每一个请求都新建TCP连接，那么合并请求就可以减少TCP握手与慢启动的时间损耗。 具体做法是针对多张图片，可以将图片合并成为大图，请求一次大图，再使用css将大图切分；或者将一些小图片使用base64编码直接嵌入HTML文件，那么会和HTML文件一同发送，达到合并请求的目的，使用base64的缺点是有可能会造成文件体积过大，请求分包，增加请求通信次数的情况，加大网络压力
<3>延迟请求
延迟请求也可以叫做按需加载，他的意思是，不必要在第一次进入页面时就加载所有的资源，而是先加载可视区内必要的资源，当后续某些资源需要使用时再加载，以此来加快加载速度
(3)减小请求的体积
当请求资源过大时http会对资源进行分包，多次传输，这也加大了网络传输压力，所以使数据大小尽可能小的在网络上传输也可以优化网络通信
<1>无损压缩
无损压缩是指资源经算法压缩过后，资源质量不变，解压后完全可以恢复原本的样子。适合用在文本文件、程序可执行文件、程序源代码。
进行无损压缩时，会先将空格换行全部清除，其次再使用压缩算法进行处理，客户端支持的压缩算法可以配置在请求头的content-encoding字段中，常用的算法有gzip算法，但相较于谷歌推出的Broti算法，gzip的压缩效率还是差一些，所以可能的情况下可以选择压缩效率更高的Br压缩算法
<2>有损压缩
与无损压缩相对的就是有损压缩，经过此方法压缩，解压的数据会与原始数据不同但是非常接近。
有损压缩主要将次要的数据舍弃，牺牲一些质量来减少数据量、提高压缩比，这种方法经常用于压缩多媒体数据，比如音频、视频、图片。
可以在请求头中的accept字段配置q质量因子来告诉服务器自己期望的数据质量
针对图片，可以使用谷歌推出的webp格式文件，他会有小的体积，缺点就是兼容性上不是很好
