本地网络及几个重要网络的概念
本地网络
由光猫、路由器、交换机、电脑等设备并联、串联形成的网络就是本地网络，用户使用电脑，电脑内置网卡，通过有线或无线的方式与光猫、路由器、交换机进行连接，而这就是所谓的“本地连接”，但也泛指网卡连接本地网络的连接协议，在最新的Windows 系统中，本地连接也叫“以太网”。
局域网
局域网的缩写是LAN，local area network，顾名思义，是个本地的网络，只能实现小范围短距离的网络通信。例如我们的家庭网络是典型的局域网。电脑、手机、电视、智能音箱、智能插座都连在无线路由器上，可以互相通信。局域网的通信设备主要是交换机。交换机可以把多个本地的终端连接在一起，帮他们进行数据转发。局域网部署的时候，自己买几台交换机就可以，不需要运营商（电信联通等）提供服务。
因特网
因特网本质上就是把世界各地的局域网连通，咱们在学校刷B站的时候，B站那边有个局域网，学校有个局域网，这两个局域网就是通过因特网连起来的。想要接入因特网，需要向运营商购买1条宽带，电信联通都可以，然后通过这条宽带接入运营商，运营商再接入因特网。
广域网
广域网是相对局域网来讲的，局域网的传输距离比较近，只能是一个小范围的。通过广域网专线。所以为了数据安全，不能连接因特网，需要用一条自己的专用线路来传输数据，这条线路上只有自己人，不会有其他人接入，且距离很远，这个网络就叫 “广域网”广域网的缩写是WAN，Wide Area Network，支持很长距离的传输。这条专线当然不是企业自己搭电线杆架设，而是租用电信联通等运营商架设好的线路，使用费用会比因特网贵很多，带宽也比较小，但是为了安全，就要承担一些必要的成本。
VPN
VPN是虚拟专用网，是在普通的便宜的因特网上通过数据加密、完整性验证、身份验证等多种技术手段构建的安全传输网络，实现类似专线的安全功能。
借鉴一个神奇比喻消化上面的知识（转载传送门）：
想象你住在一个小区里，你和你的邻居之间谁也不认识谁，不知道该怎么找到对方，你们想要互相联系，只能靠写信的方式，你把信写好后交给小区的门房大爷，并且告诉他，这封信要送到1号楼1单元101，然后门房大爷负责把信送到，这个时候，整个小区可以看成一个局域网，因为大家在这个小区里使用的都是私有地址（私有IP），这个地址只有你们小区的门房大爷知道该怎么走，换个人就找不到了。 如果你想要给另外一个小区的某个住户写信，因为每个小区的私有地址命名方式都不一样，假设他们小区的地址是A号楼东座302，这个时候你把信交给门房大爷，他就傻眼了，因为他不认识，所以拒绝为你送信。当然还是有解决方式的，那就是把附近小区的门房大爷全都叫到一块大家开个会，给所有门房大爷统一按照一种方式来命名，比如叫天通苑张大爷、回龙观王大爷等等，这个名字就是公有地址（公有IP），这个名字在所有门房大爷中是唯一的，一人一个不能重名，这个时候门房大爷之间就互相认识了，以后你再想给另外一个小区的住户写信，就需要告诉你们小区的门房大爷，“麻烦您把这封信交给天通苑的张大爷，再让他转交给A号楼东座302”。这个时候，附近这些小区就形成了一个广域网，广域网内包含很多个小区（局域网），小区（局域网）和小区（局域网）之间想要互相通信，就必须靠各自的门房大爷。 过了段时间大家觉得这样还是很不爽，干脆把全世界的门房大爷都叫到一块开个会吧，以后全世界的门房大爷们都统一起一个唯一的名字，这样全世界的人就可以自由通信了，这就叫Internet/互联网。可以说Internet/互联网是最大的广域网，但并不是每个广域网都叫Internet/互联网。 一些特殊需求:你就是想要和天通苑那个A号楼东座302直接通信，不想通过门房大爷，所以你在你家和他家之间拉了条钢丝（专线），你把信写好以后吊在篮子里直接给他送了过去，这种方式效率很快，也很安全，但是成本也很高。或者你可以雇一个专职通信员***（VPN），他只负责给你送信***，信一直放在他身上不需要倒手，由他去向门房大爷问路，并且亲自送过去，这样安全了很多，当然成本同样很高。 再来说一下“广域网由交换机连接”和“广域网需要路由交换和分组转发”这两句话。交换机的功能可以看成是小区和小区之间的路，有些小区之间只有一条路通着，有些小区之间可能有好几条路，这些路有的远有的近。而门房大爷的功能其实就是路由器（严谨的说其实不一定，因为现在具备路由功能的设备很多，不一定是路由器），也就是负责找路，只有他知道小区和小区之间的路怎么走，哪条路最近。所以说广域网（附近多个小区）有交换机（路）连接，并且广域网（附近多个小区）需要路由（门房大爷）选择（走哪条路）和分组转发（把不同的信交个不同的人）
计算机网络基础
电路交换
建立连接--数据传输--释放连接。
电路交换的一个重要特点就是在通话的全部时间内，通话的两个用户始终占用端到端的通信资源，而已被占用的通信线路资源又在绝大部分时间里是空闲的，这造成传输效率往往很低。所以，电路交换的缺点很明显，通信资源利用率低。而优点是数据传输速度快，实时到达。
分组交换
我们把要发送的整块数据称为报文，在发送报文之前，先把较长的报文划分成为一个个更小的等长数据段，在每一个数据段前面，加上一些由必要的控制信息组成的首部(header)，就构成了一个分组(packet)。分组是在互联网中传送数据的单元。分组中的首部包含了诸如目的地址和源地址等重要控制信息，每一个分组才能在互联网中独立地选择传送路径，并被正确地交付到分组传输的终点。 把一个报文划分为几个分组后再利用路由器来进行转发。路由器收到一个分组，先暂时存储一下，检查其首部，查找转发表，按首部中的目的地址，找到合适的接口转发出去，把分组交给下一个路由器。这样一步一步地以存储转发的方式，把分组交付给最终的目的主机。各路由器之间必须经常交换批次掌握的路由信息，以便创建和动态维护路由器中的转发表，使得转发表能够在网络拓扑发送变化时及时更新。
当主机H1向H5发送数据时，H1->A->C->E->H5或H1->A->B->E->H5，根据某个路由器的繁忙程序选择合适的路由把数据传给H5主机(网络拓扑的存在)。需要注意的是，当分组在H1和A之间传送时，只占用H1->A这条链路，其他链路均不占用。当数据在A->B之间传送时，H1->A又可以被其他分组占用。 分组在传输时这样一段一段地占用通信资源，而且省去建立连接和释放连接的开销(路由器会查找转发表，来寻找合适的链路)，因此数据的传输效率更高。
网络分层
七层模型既复杂又不实用，所以采取了TCP/IP五层模型
MAC和IP地址
物理地址是[数据链路层]和物理层使用的地址；IP地址是网络层及其以上层使用的地址。
如图：
连接在通信链路中的设备（主机或路由器）在收到MAC帧时，根据MAC帧的首部中的硬件地址决定收下或丢弃。只有在剥去MAC帧的首部和尾部后把数据上传给[网络层]后，网络层在IP数据报的首部中找到源IP地址和目的IP地址。
既然主机之间的连接最终通过MAC地址连接的为什么还要IP地址呢？
（1）ARP用来寻找同一个局域网中的主机，同一个局域网的ip地址的网络号相同。每个主机的ip地址并不固定，mac地址固定，最终归结于根据目标主机的mac地址寻找。
（2）不同局域网的主机通信时，通过IP地址的网络号可以减少查找的次数，快速找到目标主机
理解：MAC地址就相当于自己的身份（名字，身份证号码）体现的是“我是谁”,IP地址相当于填写的居住地址，学校地址，公司地址等可以改变的体现的是“我在哪里”。
协议（标头和载荷）
Web中的网络
http进化史
http0.9
该版本极其简单，只有一个命令GET GET /index.html 上面指令表示，TCP 连接（connection）建立后，客户端向服务器请求（request）网页index.html，协议规定。
缺点：服务器只能回应HTML格式的字符串，不能回应别的格式。
http1.0
任何格式的内容都可以发送。这使得互联网不仅可以传输文字，还能传输图像、视频、二进制文件。其次，除了GET命令，还引入了POST命令和HEAD命令，丰富了浏览器与服务器的互动手段，而且HTTP请求和回应的格式也变了。除了数据部分，每次通信都必须包括头信息（HTTP header），用来描述一些元数据。
缺点：每一个tcp只能发一次请求，发送数据完毕，连接就断开，如果还想请求其他资源，就必须新建一条新的tcp连接。
http1.1
HTTP1.1 版本发布，它主要升级了两个功能
①持久连接
②管道机制
【同一个TCP连接里面，客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率。】
缺点：虽然1.1版允许复用TCP连接，而且可以同时发送多个请求，但是服务器只有处理完一个回应，才会进行下一个回应。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为"队头堵塞"（Head-of-line blocking）。
http2
HTTP2 专注于性能，最大的一个目标是在用户和网站间只用一个连接。【之前是一个域名可以有6个tcp连接，现在只用一个tcp连接】将请求和响应数据分割为更小的帧，并且它们采用二进制编码。
核心：就是将数据包切开成一片一片的，然后每一片可以乱序传输；浏览器接收到所有的片后，按照片所带的序号，整合为一个完整的数据包
HTTP2还在一定程度上改变了传统的“请求-应答”工作模式，服务器不再是完全被动地响应请求，也可以新建“流”主动向客户端发送消息。比如，在浏览器刚请求HTML的时候就提前把可能会用到的JS、CSS文件发给客户端，减少等待的延迟，这被称为"服务器推送"（ Server Push，也叫 Cache push）
缺点：http2虽然解决了应用层的队头阻塞，但是并没有解决传输层的队头阻塞 只要底层是基于tcp，tcp就需要有确认的流程。【流水的http,铁打的tcp】 在应用层，虽然所有的数据包被切成一片一片，而且这些片的可以乱序传输；但是在tcp层，还是要将上一层的切开的片，整合为一个数据包，依然需要按照顺序去响应，依然遵循“丢包重传”机制，所以tcp层的队头阻塞的问题依然是存在的。而且更严重，因为http2只有一个tcp连接，一旦阻塞了，这个tcp上的所有请求都被阻塞。
http3
http3的核心改变就是：传输层使用的UDP协议，而不是tcp协议。HTTP3使用的是QUIC协议。QUIC在选择在UDP协议之上进行构建。QUIC使用UDP，主要是因为希望能让HTTP/3更容易部署，因为它已经被互联网上的所有设备所知并已实现. QUIC实际上就是在UDP基础上重写了TCP的功能，但是又比TCP更加智能，更高效的实现了TCP的核心功能 因为http/3是基于UDP，所以就自动解决了下面两个问题
1.建立连接时候的三次握手四次挥手
2.队头阻塞（UDP是无序的，无需等待） 疑问： 没有了tcp的三次握手和四次挥手，怎么建立连接的【1RTT甚至0RTT；使用DH密钥交换算法】
Step1：首次连接时，客户端发送 Inchoate Client Hello(CHLO) 给服务端，用于请求连接；
Step2：服务端生成 g、p、a，根据 g、p 和 a 算出 A，然后将 g、p、A 放到 Server Config 中再发送 Rejection 消息给客户端；
Step3：客户端接收到 g、p、A 后，自己再生成 b，根据 g、p、b 算出 B，根据 A、p、b 算出初始密钥 K。B 和 K 算好后，客户端会用 K 加密 HTTP 数据，连同 B 一起发送给服务端；
Step4：服务端接收到 B 后，根据 a、p、B 生成与客户端同样的密钥，再用这密钥解密收到的 HTTP 数据。为了进一步的安全（前向安全性），服务端会更新自己的随机数 a 和公钥，再生成新的密钥 S，然后把公钥通过 Server Hello 发送给客户端。连同 Server Hello 消息，还有 HTTP 返回数据；
Step5：客户端收到 Server Hello 后，生成与服务端一致的新密钥 S，后面的传输都使用 S 加密。
这样，QUIC 从请求连接到正式接发 HTTP 数据一共花了 1 RTT，这 1 个 RTT 主要是为了获取 Server Config，后面的连接如果客户端缓存了 Server Config，那么就可以直接发送 HTTP 数据，实现 0 RTT 建立连接。
补充RTT知识点：
CDN
一般的浏览器发出请求的过程
①用户在浏览器中输入要访问的网址域名。
②浏览器向本地 DNS 服务器请求对域名的解析。
③如果本地 DNS 服务器有域名的解析结果，那么直接响应用户请求，返回该域名对应的 IP 地址。
④如果本地 DNS 服务器没有域名的解析结果，那么则会递归地向 DNS 系统请求解析，随后将该结果返回给用户。
⑤浏览器得到域名解析结果后，其实也就是域名对应的 IP 地址。
⑥随后浏览器向服务器请求内容。
⑦服务器将用户请求内容返回给浏览器。
网站服务器通过公网出口，再通过长途骨干网，最后通过用户的宽带广猫到达用户所在的局域网，最终才到达用户电脑的浏览器。其中长途骨干网的传输是最为耗时的，它需要经过网站服务器所在的机房、骨干网、用户所在城域网、用户所在接入网等，其物理传输距离非常遥远。 在这种情况下，如果传输的数据非常多，访问的用户特别大，那么就会出现很长的延时，影响用户体验。同时，每请求一次数据都需要经过漫长的数据传输，对于长途骨干网来说，都是一次负担。
CDN与DNS结合
①浏览器发起图片 URL 请求，经过本地 DNS 解析，会将域名解析权交给域名 CNAME 指向的 CDN 专用 DNS 服务器。
②CDN 的 DNS 服务器将 CDN 的全局负载均衡设备 IP 地址返回给浏览器。
③浏览器向 CDN 全局负载均衡设备发起 URL 请求。
④CDN 全局负载均衡设备根据用户 IP 地址，以及用户请求的 URL，选择一台用户所属区域的区域负载均衡设备，向其发起请求。
⑤区域负载均衡设备会为用户选择最合适的 CDN 缓存服务器（考虑的依据包括：服务器负载情况，距离用户的距离等），并返回给全局负载均衡设备。
⑥全局负载均衡设备将选中的 CDN 缓存服务器 IP 地址返回给用户。
⑦用户向 CDN 缓存服务器发起请求，缓存服务器响应用户请求，最终将用户所需要偶的内容返回给浏览器。
网络安全PKI
加密传输流程： 假设甲乙双方各拥有非对称加密法的一对公钥和秘钥
①甲用对称密钥加密文件
②甲用公钥加密对称密钥
③乙用私钥解密得到对称密钥
④乙用对称密钥解开文档
一些问题
问题1：既然甲可以用乙的公钥加密其对称密文，为什么不直接用乙的公钥加密其文件呢？这样不仅简单，而且省去了用对称加密算法加密文件的步骤？
不可以这么做。因为非对称密码算法有两个缺点：加密速度慢，比对称加密算法慢10~100倍，因此只可用其加密小数据（如对称密钥），另外加密后会导致得到的密文变长。因此一般采用对称加密算法加密文件，然后用非对称算法加密对称算法所用到的对称密钥。
问题2：通过对称加密算法加密其文件，再通过非对称算法加密其对称密钥，又通过散列算法证明发送者身份和其信息的正确性，这样是否就万无一失了？
回答是否定的。问题在于乙并不能肯定他所用的所谓的甲的公钥一定是甲的，解决办法是用数字证书来绑定公钥与公钥所属人。
数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件，是网络通信中标识通信各方身份信息的一系列数据，它提供了一种在Internet上验证身份的方式，其作用类似于司机的驾驶执照或日常中的身份证，人们可以在交往中用它来识别对方的身份。
最简单的证书包含一个公开密钥，名称以及证书授权中心的数字签名。一般情况下证书还包含有密钥的有效时间、发证机关（证书授权中心）名称、该证书的序列号等信息。它是由一个权威机构—CA机构，又称为证书授权（Certificate Authority）中心发放的。CA机构作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。CA中心为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。CA机构的数字签名使得攻击者不能伪造和篡改证书，CA是PKI的核心，负责管理PKI结构下的所有用户（包括各种应用程序）的证书，把用户的公钥和用户的其他信息捆绑在一起，在网上验证用户的身份。
因为数字证书是公开的，就像公开的电话簿一样，在实践中，发送者（即甲）会将一份自己的数字证书的拷贝连同密文、摘要等放在一起发送给接收者（即乙），而乙则通过验证证书上权威机构的签名来检查此证书的有效性（只需用那个可信的权威机构的公钥来验证该证书上的签名就可以了），如果证书检查一切正常，那么就可以相信包含在该证书中的公钥的确属于列在证书中的那个人（即甲）。
问题3：至此似乎很安全了。但仍存在安全漏洞，例如：甲虽将合同文件发给乙，但甲拒不承认在签名所显示的那一刻签署过此文件（数字签名就相当于书面合同的文字签名），并将此过错归咎于电脑，进而不履行合同，怎么办？
解决办法是采用可信的时钟服务（由权威机构提供），即由可信的时间源和文件的签名者对文件进行联合签名。在书面合同中，文件签署的日期和签名一样均是十分重要的防止文件被伪造和篡改的关键性内容（例如合同中一般规定在文件签署之日起生效）。在电子文件中，由于用户桌面时间很容易改变（不准确或可人为改变），由该时间产生的时间戳不可信赖，因此需要一个第三方来提供时间戳服务（数字时间戳服务（DTS）是网上安全服务项目，由专门的机构提供）。此服务能提供电子文件发表时间的安全保护。
时间戳产生的过程为：用户首先将需要加时间戳的文件用哈希编码加密形成摘要。然后将该摘要发送到DTS，DTS在加入了收到文件摘要的日期和时间信息后再对该文件加密（数字签名），然后送回用户。因此时间戳（time-stamp）是一个经加密后形成的凭证文档，它包含三个部分：需加时间戳的文件的摘要，DTS收到文件的日期和时间，DTS的数字签名。由于可信的时间源和文件的签名者对文件进行了联合签名，进而阻止了文档签名的那一方（即甲方）在时间上欺诈的可能，因此具有不可否认性。
问题4：有了数字证书将公/私钥和身份绑定，又有权威机构提供时钟服务使其具有不可否认性，是不是就万无一失了？不，仍然有问题。乙还是不能证明对方就是甲，因为完全有可能是别人盗用了甲的私钥（如别人趁甲不在使用甲的电脑），然后以甲的身份来和乙传送信息，这怎么解决呢？
解决办法是使用强口令、认证令牌、智能卡和生物特征等技术对使用私钥的用户进行认证，以确定其是私钥的合法使用者。
解决这个问题之前我们先来看看目前实现的基于PKI的认证通常是如何工作的。以浏览器或者其他登记申请证书的应用程序为例说明，在第一次生成密钥的时候会创建一个密钥存储，浏览器用户会被提示输入一个口令，该口令将被用于构造保护该密钥存储所需的加密密钥。如过密钥存储只有脆弱的口令保护或根本没有口令保护，那么任何一个能够访问该电脑浏览器的用户都可以访问那些私钥和证书。在这种场景下，又怎么可能信任用PKI创建的身份呢？正因为如此，一个强有力的PKI系统必须建立在对私钥拥有者进行强认证的基础之上，现在主要的认证技术有：强口令、认证令牌、智能卡和生物特征（如指纹和眼膜等认证）。
以认证令牌举例：假设用户的私钥被保存在后台服务器的加密容器里，要访问私钥，用户必须先使用认证令牌认证（如用户输入账户名、令牌上显示的通行码和PIN等），如果认证成功，该用户的加密容器就下载到用户系统并解密。
