01 前言&课程介绍
- 本课程笔记来自掘金字节内部课-前端初级训练营
- 计算机网络概论 - 掘金 (juejin.cn)
- 字节前端训练营 - 计算机网络概论.pptx - 飞书云文档 (feishu.cn)
目标
计算机网络的整体认知，各种概念的初步了解
- 计算机网络的整体认识
- 网络分层协议认知
- HTTP 1 2 3的关系
- CDN运行的基本原理
- 了解网络安全的最基本原则
分析方法
- 自底向上
- 从简单开始逐步复杂
- 从模块拼凑网络
- 自顶向下
- 从复杂到简单
- 分解模块
02 蟹堡王帝国
- 顾客：客户端
- 分店：服务端
- 小区转发点和城市转发点：路由器
- 转发表格：网络协议
- ISP：网络业务提供商
03 计算机网络基础
网络组成部分
-
由主机、路由器、交换机组成
-
主机：客户端与服务端 提供信息或者接收信息
-
路由器：转发主机之间的信息
-
网络协议：提供统一的格式，方便编码与解码
-
区域网络 城域网 广域网
信息交换方式
- 电路交换 电话
- 顾客要和章鱼哥先连接
- 就算不说话，还是占用
- 安排更多前台，可以提高效率，但是浪费严重
- 分组交换 传真机
- 不会建立电路连接，也不会预留资源给带宽
- 接收时，放入输出队列中，按照顺序输出
- 队列满时，发生丢包
- 大的报文分割后变为小的报文，不同路径送达后由软件拼凑
网络分层
- 计算机分为五层
- 物理层，电路层，网络层，运输层，应用层
- 只关心自身逻辑，上层调用者不需要关注下层具体实现和问题，只需要调用
- 分层目的: 职责清晰，降低各层的使用成本
网络协议内容概述
协议
- 协议的存在依赖于连接
- 协议定义了在两个或者多个通信实体之间交换的报文格式和顺序，以及保温发送和//或接受一条报文或者其他事件所采取的动作。
标头与载荷
- 标头：快递运单
- 载荷：内容
- 每一层将上一层的标头与载荷视为载荷，再添加自己的标头
协议内容简要分析
一个wireshark捕获的本地回环网络中的包的简要分析
- 报文内容=链路层头部+IP头部+TCP头部+HTTP头部+HTTP内容
- 上述图片中，左侧是wireshark分析结果，右侧是原始报文内容，十六进制表示
- 链路层头部是前面四个字节
- NULL/LOOPback 表示是本地帧，源地址与目标地址都是本机，不需要经过别的交换机
- 内容为 Family:IPV6(24) 括号中的24表示采用IPV6
- 第三行表示IP，源地址与目标地址都是::1表示使用本机地址
- IP协议的头部对应于 第5个字节到第44个字节
- 包含IP协议，源地址，目标IP地址，载荷等等
- 第四行是TCP协议层
- TCP协议再向后计算20个字节
- 包含源版本号，目标版本号，序列号，头部长度，载荷信息，载荷长度信息
- 第五行是HTTP协议
- 分为头部与载荷两个部分
- GET请求没有载荷
- 最后才是HTTP的真实内容
- 链路层头部是前面四个字节
- 注意：在HTTP1.1及之前的内容中，头部与载荷是使用两个换行符和回车符分割的，TCP协议与IP协议不同
- TCP协议中，头部与内容的分割使用 Data Offset部分进行分割，这一部分的位置固定，永远是13字节处，TCP协议报文格式见上图
04 web中的网络
web中的网络受到诸多因素的影响
HTTP协议
- 红色表示 请求，蓝色 表示响应
- 请求
- 第一行是 请求方法 资源路径 协议
- 后面是头部，头部名称：头部值
- 头部使用冒号分割，头部名称不区分大小写
- 头部与正文之间使用空格分开，GET请求没有正文
- 响应
- 第一行：HTTP协议 状态码 状态信息 状态信息可以自定义
- 响应头部与请求头部类似
- 响应头部与正文按照空格分开，此实例中，正文是一个HTML文档
HTTP1 连接模型
HTTP 1.x 存在的问题
- HTTP1.1和HTTP1.0队头堵塞问题与无法完成多路复用导致的资源浪费问题
HTTP队头堵塞（HTTP Head-of-Line Blocking）指的是在HTTP/1.x协议中，由于每个TCP连接只能同时处理一个请求，多个请求需要通过排队等待TCP连接空闲，而排在前面的请求处理时间过久，会导致排在其后面的请求也需要等待，从而造成后续请求的延迟，降低整体性能。 具体来说，由于HTTP/1.x协议中的请求和响应必须按顺序发送和接收，如果一个请求的响应时间过长，那么后面的请求将需要等待，直到前面的请求处理完成，即使后面的请求可以更快地处理完成。这种情况下，前面的请求就会阻塞后面的请求，从而导致后续请求的延迟。 为了解决HTTP队头堵塞问题，HTTP/2协议引入了多路复用（Multiplexing）技术，允许多个请求和响应同时在一个TCP连接上进行，从而提高了请求和响应的并发性和效率。
HTTP 1.x 模型
上图中展示了HTTP协议版本中的几种连接
- 图一：短生命周期连接，一发一收，可以使用keep connection 保持连接，效率很低
- 图二：持久连接，在一段时间内 keep-alive
- 图三：管线连接：发送多个请求，服务端按照顺序进行响应，无法解决队头堵塞，可能存在安全问题，性能提升不高
HTTP Pipelining是一种HTTP请求的发送方式，它允许客户端在同一个TCP连接上同时发送多个HTTP请求，而无需等待之前的请求的响应。这样可以降低请求的延迟和提高网络带宽的利用率。 在HTTP/1.x协议中，由于需要按顺序发送请求和接收响应，因此客户端必须等待一个请求的响应才能发送下一个请求。这种方式会造成请求的延迟，尤其是在高延迟或带宽受限的网络中。 而在HTTP Pipelining中，客户端可以在同一个TCP连接上同时发送多个HTTP请求，而无需等待之前的请求的响应。服务器也可以按照请求的顺序依次响应请求，避免HTTP队头阻塞（HTTP Head-of-Line Blocking）问题，提高了请求的效率和吞吐量。同时，由于只需要维护一个TCP连接，也减少了TCP连接的数目，降低了服务器的负担。 需要注意的是，虽然HTTP Pipelining可以提高网络性能，但它也存在一些问题。比如，如果一个请求的响应时间过长，那么后面的请求也需要等待，这就会导致HTTP队头阻塞问题。此外，在HTTP Pipelining中，如果一个请求发送失败，那么后续的请求也会失败。因此，需要谨慎使用HTTP Pipelining，结合实际情况进行使用。 总的来说，HTTP Pipelining是一种优化HTTP请求的方式，它可以提高请求的效率和吞吐量，但也需要注意潜在的问题。
- HTTP1.x缓解队头堵塞的方式是：建立多个TCP连接，将多个请求分散在多个TCP连接上，可以缓解，但是建立多条的成本巨大，HTTPS消耗巨大，TLS每次链接需要重新协商。请求数量超过连接数量时，还是需要排队的。
- TCP连接数量不能无条件增长，用户与服务端带宽是一定的，TCP数量越多，每个TCP连接的带宽越小，收发越慢，所以浏览器会限制在一个域名下的连接数量，一般是6
HTTP 1.x 多路复用问题
- 如果一个HTTP响应按照交错发送，客户端无法收取正常内容，受到的内容会像上图中第三部分一样。
HTTP 2 ：帧
HTTP2 结构
- HTTP2采用帧分散多个请求的数据，每个帧可以携带多个HTTP请求的数据
在HTTP/2协议中，数据通过帧（Frame）的形式进行传输，每个帧包含一个帧头（Frame Header）和一个帧体（Frame Payload）。
帧头包含以下内容：
- 长度（Length）：指定帧体的长度，占用3个字节。
- 类型（Type）：指定帧的类型，占用1个字节。常见的帧类型包括数据帧（DATA）、头部帧（HEADERS）、设置帧（SETTINGS）等。
- 标志（Flags）：指定帧的标志位，占用1个字节。标志位用于传递一些控制信息，如是否压缩、是否结束等。
- 流标识符（Stream Identifier）：指定数据流的标识符，占用4个字节。多个帧可以共享同一个流标识符，以便于将多个帧关联到同一个数据流。
（帧体）载荷，也就是帧的长度
帧体则是实际的数据，它的格式和内容取决于帧的类型和标志。
通过使用帧，HTTP/2协议可以将数据拆分为多个小块进行传输，从而提高传输的效率和可靠性。同时，多个数据流也可以共享同一个TCP连接，避免了多个TCP连接带来的额外开销和复杂度。
需要注意的是，理解HTTP/2帧的具体格式和内容对于深入理解HTTP/2协议是非常重要的。同时，也需要注意HTTP/2协议相对于HTTP/1.x协议的一些变化和特点，如多路复用、头部压缩等。
- 如上，通过帧头，可以分析出帧属于哪个数据流，从而区分帧数据哪个请求，从而在浏览器中重组为完整的HTTP响应
- 分析一个具体的HTTP2 响应，如上图绿色部分，HTTP info中分成了很多的部分，不再是一来一回的这种样子
- 分析data部分
- 前三个字节 载荷长度 当前帧的载荷总长
- 第四个字节 类型 0 表示data类型的帧
- 第五个字节 data帧对应的标志位，0表示当前data帧还没有结束
- 第六个字节 保留位
- 往后31个字节 流ID
- 往后的payload字节长度，是载荷内容
HTTP 2 好处
- 多路复用（HTTP1不算真正的多路复用）
- 多路复用（Multiplexing）是指在同一个TCP连接上同时传输多个数据流（Stream），从而实现并发传输的技术。
- 解决队头堵塞问题
- 调整响应传输的优先级
- 头部压缩
- Sever Push
HTTP 3
为什么发展HTTP 3
- 为什么发展HTTP 3？
- 快
- TCP协议层如果发生TCP丢包，即使丢失帧不影响后面的帧包，TCP也还是会丢弃后面的包，要求服务端重传丢失的包先，所以造成堵塞
- HTTPS成为主流之后，由于TLS/SSL具有双倍延迟，更需要快
- TCP不知道自己上面传的什么，所以无法改造TCP来适应新的上层传输
- 快
HTTP/2协议在某些方面取得了显著的进步，例如多路复用、头部压缩、服务器推送等，这些特性使得HTTP/2比HTTP/1.x更加高效、可靠和安全。但是，HTTP/2仍然基于TCP协议，而TCP协议存在一些固有的缺陷，例如队头阻塞（Head-of-Line Blocking）和慢启动（Slow Start），这些缺陷会导致HTTP/2在高延迟和不稳定的网络环境下性能下降。
为了解决这些问题，出现了HTTP/3协议，它使用基于QUIC（Quick UDP Internet Connections）协议的传输层协议，而不是基于TCP协议。QUIC协议旨在解决TCP协议存在的一些固有缺陷，例如队头阻塞和慢启动，同时也支持多路复用、安全性、可靠性等特性，从而提高了HTTP/3的性能和效率。
具体来说，HTTP/3相对于HTTP/2的改进包括：
1. 使用QUIC协议代替TCP协议，解决TCP协议的固有缺陷，例如队头阻塞和慢启动，从而提高了HTTP/3在高延迟和不稳定的网络环境下的性能和效率。
2. 优化了头部压缩算法，使得HTTP/3在头部压缩方面更加高效和可靠。
3. 增加了一些安全特性，例如0-RTT加密和源地址验证，可以提高HTTP/3在安全性方面的表现。
综上所述，HTTP/3在一些方面相对于HTTP/2有了明显的进步，特别是在性能和可靠性方面。虽然HTTP/2已经相当成熟，但HTTP/3仍然值得关注和研究，也有可能成为未来HTTP协议的主流。
- 上图展示了HTTP的慢启动
HTTP 3：QUIC
- QUIC将TLS作为自身的的一部分，解决了TCP和TLS需要各自握手的问题
- 吸取HTTP2流概念，解决了TCP队头堵塞问题
- 引入新的进制实现连接1RTT或者0RTT的特性
- 为什么不直接开发新的运输层协议？
- 为了兼容现有的设备
- QUIC还可以承载除了HTTP之外的应用层协议，虽然现在没有其他的协议
- QUIC在UDP的基础上 实现拥塞控制、丢包重传
QUIC-1 RTT
-
上图是一个示例过程
-
QUIC将原本属于TCP和TLS的握手过程组合起来了，因此实现1RTT连接
-
-
在二次访问中，由于之前预留的密钥，就可以实现0RTT
-
其他内容访问后文材料
CDN：如何进一步提升web性能
- HTTP之外存在很多因素影响性能
- 物理极限
- 传输花销
- 承载能力
- CDN是什么
CDN是指内容分发网络（Content Delivery Network），它是一种分布式的网络架构，旨在提高互联网内容的传输速度和性能。CDN通过在全球各个地点部署服务器节点，将静态和动态内容缓存到最接近用户的边缘节点，使用户可以更快地从离他们最近的节点访问内容，从而加快了互联网内容的传输速度和可靠性。
CDN的基本工作原理如下：
1. CDN服务提供商在全球各地部署服务器节点，这些节点分布在不同的地理位置，覆盖了全球大部分地区。
2. 当用户发起请求访问某个网站时，请求会被路由到离用户最近的CDN边缘节点。
3. 如果请求的内容已经缓存在该节点中，那么该节点将直接返回缓存的内容给用户，从而实现快速响应。
4. 如果请求的内容没有缓存在该节点中，那么该节点会向源站服务器发送请求，获取内容并缓存到本地节点中，然后再返回该内容给用户。
通过使用CDN服务，网站可以将静态和动态内容分发到全球各地，从而减少了服务器的负担，同时也提高了用户访问网站的速度和性能。CDN服务还可以在一定程度上缓解DDoS攻击、提高网站的安全性和可靠性。
需要注意的是，CDN并不适用于所有的网站和内容，对于一些动态和实时内容，如在线视频和游戏等，CDN的效果可能不如预期。此外，CDN服务还需要考虑成本和管理等问题，因此需要在实际应用中根据具体情况进行选择和使用。
- 任播技术：允许动态共享IP，如谷歌的8.8.8.8公共DNS服务器
任播（Anycast）是一种用于路由选择的技术，它将同一个IP地址分配给多个目的地，然后将流量路由到最近的目的地。这种技术可以提高网络服务的可靠性、可用性和性能，是分布式服务和内容分发网络的常用技术之一。
任播的好处有以下几点：
1. 提高网络服务的可靠性和可用性。任播技术将同一个IP地址分配给多个目的地，如果其中一个目的地出现故障或不可用，流量会被自动路由到其他可用的目的地。这样就可以避免单点故障和服务中断，提高网络服务的可靠性和可用性。
2. 提高网络服务的性能和响应速度。任播技术可以将流量路由到距离用户最近的目的地，从而减少了数据传输的延迟和丢包率，提高了网络服务的性能和响应速度。
3. 改善网络负载均衡。任播技术可以将流量分散到多个目的地，从而实现更好的网络负载均衡，避免网络拥塞和瓶颈，提高了网络服务的可扩展性和容错性。
4. 改善网络安全性。任播技术可以帮助防止DDoS攻击，因为攻击者很难确定目标的确切位置，从而难以集中攻击。任播技术还可以提高网络的安全性和可靠性，减少网络攻击和故障的影响。
总的来说，任播技术是一种可靠、高效、安全的网络技术，可以帮助提高网络服务的可靠性、可用性和性能，对于分布式服务和内容分发网络等应用场景具有重要的意义。
- DNS
- 域名解析一般由网站自己处理
- 需要加速的由CDN厂商解析后根据来源解析到最近的CDN服务器IP
- DNS劫持这个名字用在这里不知道合适不，这本来是描述一种网络攻击技术
DNS是域名系统（Domain Name System）的缩写，也称为域名解析系统。它是一个互联网的基础设施，用于将人类可读的域名（如www.example.com）转换为计算机可理解的IP地址（如192.0.2.1）。DNS可以帮助用户更轻松地访问互联网上的各种网站、应用和服务。
DNS工作原理的简单描述如下：
1. 用户发起DNS查询请求，请求解析一个域名的IP地址。
2. 用户计算机将查询请求发送给本地域名解析器（Local DNS Resolver）。
3. 如果本地域名解析器已经缓存了该域名的IP地址，那么它直接返回缓存的结果给用户计算机，查询结束。
4. 如果本地域名解析器没有缓存该域名的IP地址，那么它向根域名服务器（Root Name Server）发起查询请求。
5. 根域名服务器返回一个包含顶级域名服务器（Top-Level Domain Server）的IP地址的响应给本地域名解析器。
6. 本地域名解析器向顶级域名服务器发起查询请求。
7. 顶级域名服务器返回一个包含权限域名服务器（Authoritative Name Server）的IP地址的响应给本地域名解析器。
8. 本地域名解析器向权限域名服务器发起查询请求。
9. 权限域名服务器返回该域名的IP地址给本地域名解析器。
10. 本地域名解析器将查询结果缓存，并将IP地址返回给用户计算机，查询结束。
需要注意的是，DNS查询过程中可能会涉及多个DNS服务器和多个网络节点，因此查询的响应时间和稳定性会受到多种因素的影响，如网络延迟、DNS服务器负载等。对于一些需要高可用性和低延迟的应用和服务，采用CDN等技术可以帮助提高DNS查询的性能和可靠性。
- 一个例子
用户向wedio.douyin.com 发起访问
提交到上层DNS解析器
上层发现是douyin的，转交给douyin域名解析服务器
douyin发现是CDN加速域名，于是不返回IP地址，而是返回一个新的DNS地址，新的DNS地址是CDN管理的
本地DNS向新的DNS地址发起请求
CDN的DNS与用户DNS确定离得最近的在哪里，返回最近的CDN服务器IP
浏览器与最近的IP建立连接
- 如何选择CDN最近的？
- 地理位置？
- 太糙了，不太合适
- 用户指定了其他的CDN服务器
- 其他因素
- 全国CDN备份太浪费了
- 具体策略一般是分别存一些分为两种
- 对于冷门内容使用拉策略，对于热门内容和推广内容使用推策略
- 地理位置？
WebSocket：HTTP的升级
简单概念
- web socket的简单了解
WebSocket是一种在单个TCP连接上进行全双工通信的协议。它允许客户端和服务器之间建立持久性的连接，并在数据传输方面提供了更好的性能和效率。
与HTTP协议不同，WebSocket协议在连接建立后使用二进制帧进行数据传输，同时支持文本和二进制数据的传输。这意味着，WebSocket协议可以更快地传输大量数据，同时也可以更好地支持实时数据和流式数据的传输。
WebSocket协议的工作流程如下：
1. 客户端向服务器发送一个HTTP请求，请求升级协议为WebSocket协议。
2. 如果服务器支持WebSocket协议，那么它将返回一个HTTP响应，表示连接已升级成功。
3. 建立WebSocket连接后，客户端和服务器之间可以进行任意数量的数据传输。客户端可以通过JavaScript API向服务器发送消息，服务器可以向客户端发送消息。
4. WebSocket连接可以保持长时间打开状态，直到客户端或服务器关闭连接。
WebSocket协议的优点是：
1. 更快的数据传输：由于WebSocket协议在连接建立后直接使用底层TCP连接进行数据传输，因此可以避免HTTP协议中的握手和头部等多余信息，从而提高了数据传输速度和效率。
2. 支持实时数据和流式数据：WebSocket协议可以更好地支持实时数据和流式数据的传输，从而适用于在线游戏、聊天室、股票行情等需要高效数据传输和实时更新的应用场景。
3. 更少的网络开销：WebSocket协议在建立连接后可以保持长时间打开状态，避免了频繁的TCP连接建立和关闭，从而减少了网络开销。
需要注意的是，WebSocket协议并不适用于所有的网络应用场景。对于一些需要安全性和可靠性保障的应用，如在线银行、电子商务等，仍需采用HTTPS等更安全的协议。
来自GPT（彩蛋
补充：全双工通信
全双工通信是指在通信双方之间建立的连接中，允许两个方向上的数据同时传输。也就是说，通信双方可以同时发送和接收数据，而不需要等待对方的响应或传输完成。
全双工通信可以提高通信的效率和性能，特别适用于需要大量数据传输和实时响应的应用场景。例如，视频会议、在线游戏、实时语音通话等应用中，需要双方可以同时发送和接收数据，以确保实时性和流畅性。
与全双工通信相对的是半双工通信和单工通信。半双工通信只允许通信双方在不同的时间段内交替地发送和接收数据，例如对讲机中的通信。而单工通信只允许通信双方在一个方向上传输数据，例如广播电台。
需要注意的是，在全双工通信中，通信双方之间需要建立持久性的连接，以便在数据传输过程中能够实时传输和接收数据。例如，WebSocket协议就是一种可以在单个TCP连接上进行全双工通信的协议，能够提供更好的数据传输效率和性能。
- 特性
- 有状态的持久连接
- 服务端可以主动推送消息（HTTP中服务端只能被动回复请求
- 消息延迟更低（握手方式特别，从HTTP升级，先需要HTTP握手
- 只需要学会应用的目的即可
websocket 编程
- 主要通过消息机制实现
WebSocket 与 HTTP
- 请求头：客户端在HTTP连接中添加内容
- 上图中的upgrade及前面的web-socket表明需要申请升级连接
- 响应头：服务端响应升级
- 使用101 switching protocols 选中websocket协议表示同意升级协议
- 请求头域响应头均包含了 websocket 头部与内容（Line-based text data）
- 应用层只需要关注内容部分即可
- websockets也可以传输二进制文件
05 网络安全
如何在明文传输中实现安全？
网络安全的三要素
- 机密性 无法获得
- 加密算法与密钥为秘密信息
- 问题：如何在不安全的信道中协商出秘密信息
- 完整性 无法篡改
- 与身份验证关联
- 身份验证 无法假冒
- 加密方式
- 对称加密
- 非对称加密 一般是公私钥体系
- 密码散列函数（哈希函数）
- 输入：任意长度
- 输出：固定长度的哈希值
- 性质：在计算上，无法找到两个不同输入经过哈希之后得到相同的哈希值
- 并不用于加密
- 原始信息已经丢失
- 机密性实现
- 没讲似乎
- 据我所知应该是采用DH的密钥协商算法
- 完整性的实现
- 上面的方法是有问题的，全是明文有可能直接被全部更改（没太理解，hash算法如果是秘密的，为什么还存在问题？因为一般情况下Hash算法是公开的）
- 正确方法
- 身份验证的实现
- 数字签名方法（基础是非对称加密算法）
- 实现身份验证：一般情况下，由于非对称加密的效率问题，采用以下组合方法
- 发送者将明文内容hash之后，采用私钥加密，收方接受明文与私钥加密后的明文hash，将加密hash采用公钥解密，如果解密值和自己对明文的hash是一样的，说明这个私钥是对的，也说明对方是对的
- 数字签名的前提：公钥真的是对的人的公钥，如何确定？
- 现实世界中，操作系统中内置的就是这个证书链的大哥
- 数字签名方法（基础是非对称加密算法）
HTTPS
HTTPS的流程：
- 使用PKI对服务器提供的证书进行验证
- 使用验证后的证书中的公钥，与服务器进行对称加密 算法与密钥
- 使用协商好的对称加密算法及密钥，对明文进行加密
问题：如何验证客户端身份？
- 客户端验证身份通过HTTP应用层次解决
- 客户端登陆账户密码后，服务端将密码验证信息通过HTTPS传输给客户端
- 下次客户端访问时，带上密码验证信息（一般是Cookies），服务端就知道客户端身份了
- 也可以使用客户端证书：麻烦，没人用
小结
（更像是上面笔记内容的补充）
小结
参考
- 计算机网络
- HTTP权威指南
- 密码编码学与网络安全 第六版
- Introduction to HTTP/2 (web.dev)
- Web Performance Calendar » Head-of-Line Blocking in QUIC and HTTP/3: The Details (perfplanet.com) 队头堵塞
