青训营前端｜计算机网络概论
前言&课程介绍
课程目标
建立对计算机网络的整体认知，对计算机网络中的各种概念（网络分层、网络协议、网络应用等）有初步的理解。进而可以在后续的实际工作中能高效解决网络问题。
分析方法
自底向上
- 从简单开始，逐渐变复杂
- 将模块逐步拼凑成一个系统
自顶向下
- 从复杂开始，逐渐变简单
- 从复杂的系统问题入手，拆分为模块问题
蟹堡王帝国
三步走战略
- 在比奇堡开通外卖
- 在北京和上海开分店
- 在全国开分店并开通外卖
蟹堡王外卖
所有比奇堡居民给章鱼哥打电话订餐很可能拥挤占线，于是大家都共同将订餐信息填在表格（协议）中发给蟹堡王，可以大大提高效率。
| 谁吃 | 派大星 |
|---|---|
| 吃什么？ | 两个蟹黄堡和一个炸海草 |
| 送到哪？ | 比奇堡石头屋 |
北京和上海分店
分店
- 北京方恒蟹堡王
- 上海科技绿洲蟹堡王
通信线路
- 赚了多少钱
- 确定原料数量
- 是否需要新分店
- 促销信息
转发表格
| 来自 | 北京方恒蟹堡王 |
|---|---|
| 发往 | 比奇堡蟹堡王 |
| 内容 | 今日销售数据：1000 个蟹黄堡 |
| 来自 | 比奇堡蟹堡王 |
|---|---|
| 发往 | 北京方恒蟹堡王 |
| 内容 | 明日促销信息：全场8折 |
新的分店
- 中航蟹堡王
- 紫金蟹堡王
- 大钟寺蟹堡王
- 通信线路怎么办？
（城域网）
中航蟹堡王在哪
- 方恒店员：中航蟹堡王在哪？
- 章鱼哥：就在那！在那！
（CDN备份，可以近距离调用）
蟹堡王全国
为了构建全国的通信线路，同时节约通信时间与成本，按照以下方式构建。
- 各城市蟹堡王与各自省会城市蟹堡王连接
- 各省会蟹堡王与北京或上海蟹堡王连接
- 再由北京上海蟹堡王与比奇堡蟹堡王连接
小区中蟹堡王外卖
- 城市中的小区密度较高
- 小区中每家都直连蟹堡王成本太高
小结
- 蟹堡王顾客：客户端
- 蟹堡王分店：服务端
- 小区转发点和蟹堡王城市转发分店：路由器
- 转发表格：网络协议
计算机网络基础
网络组成部分
- 主机：客户端和服务端
- 路由器
- 网络协议
网络结构：网络的网络
- 比奇堡和小区网络：本地网络
- 北京和上海分店+比奇堡：三个本地网络节点的网络
- 全国通信网络：本地网络的网络
区域网络、城域网和广域网
信息交换方式
电路交换
分组交换
网络分层
- 快递员不关心包裹内容
- 卡车司机不关心车厢里拉的是什么
- 高速公路不关心开的什么车
分清职责，物理层、链路层、网络层、运输层和应用层
网络协议
协议的存在依赖于连接
协议定义了在两个或多个通信实体之间交换的报文格式和顺序，以及报文发 送和/或接受一条报文或其他事件所采取的动作。
标头和载荷
Web中的网络
HTTP
CDN
CDN服务器分布
CDN服务器选择
DNS劫持
- 域名解析一般由网站自己处理
- 要加速的
域名则重定向到 CDN 厂商的域名解析服务处理 - CDN 厂商根据来源确定最近的 CDN服务器的
IP - 用户直接访问最近的 CDN服务器
CDN服务器内容管理策略
-
拉策略
- 默认情况下什么也不做
- 谁需要了，先看看仓库有没有
- 有，直接给
- 没有，你等着，我去买个橘子
- （每隔几天）这都啥啊，丢了
-
推策略
- 大哥说今天你存这些，明天存那些
- 谁需要了，先看看仓库有没有
- 有，直接给
- 没有，你等着，我去买个橘子
- 大哥说这个、这个还有这个，丢了
WebSocket
- 有状态的持久连接
- 服务端可以主动推送消息
- 用 WebSocket 发送消息延迟比 HTTP 低
小结
- HTTP 1、2、3 的演进历史
- CDN 解决了 HTTP 协议之外的问题
- WebSocket 从 HTTP 协议升级而来
网络安全
网络安全三要素
- 机密性：攻击者无法获知通信内容
- 完整性：攻击者对内容进行篡改时能被发现
- 身份验证：攻击者无法伪装成通信双方的任意一方与另一方通信
对称加密和非对称加密
- 对称加密：加密、解密用同样的密钥
- 非对称加密：加密、解密使用不同的密钥（公钥和私钥），而且公钥加密只能用私钥解密、私钥加密只能用公钥解密
密码散列函数（哈希函数）
- 输入：任意长度的内容
- 输出：固定长度的哈希值
- 性质：找到两个不同的输入使之经过密码散列函数后有相同的哈希值， 在计算上是不可能的
信息交换
在不完全的信道交换秘密信息
机密性
- 加密需要加密算法和密钥等信息（统称为秘密信息）
- 网络是明文的，不安全
完整性和身份验证
完整性和身份验证相互关联
-
蟹老板向银行发起了转账请求
-
银行需要确认
- 这个请求真的是蟹老板发起的
- 目标账户和转账金额没有被篡改
如何实现机密性
- 已知：网络是明文的
- 如果
双方可以通过明文通信商量出秘密信息，那么攻击者也可以 - 所以
想要通过明文通信交换秘密信息，通信双方需要先有秘密信息
如何实现完整性
- 密码散列函数性质：找到两个不同的输入使之经过密码散列函数后有 相同的哈希值，在计算上是不可能的
- 有明文 m，密码散列函数 H
- 计算 H(m) 获得哈希值h
- 将 m 和 h 组合成新信息m + h
- 接收方拆分 m + h，重新计算 H(m) 得 h'，对比 h'和 h
- 有明文 m，密码散列函数 H以及一个
密钥s - 计算 H(
m + s) 获得哈希值h - 将 m 和 h 组合成新信息 m + h
- 接收方拆分 m + h，重新计算 H(
m + s) 得h'，对比h'和上h - 所以想要实现完整性，通信双方需要先有秘密信息
如何实现身份验证
- 数字签名：对明文内容的哈希值使用私钥加密，验证者使用公钥验证
- 数字签名（指纹）= 私钥加密（密码散列函数（原文））
- 消息 = 原文+ 数字签名
- 一般用于对公开内容（如包含公钥的证书）进行数字签名，防止篡改
- 可信的人验证蟹老板的公钥
- 那谁验证可信的人的公钥？
根证书是证书链的尽头- 验证的一连串证书称为
证书链 - 分发证书、验证证书的基础设施称为
PKI, Public Key Infrastructure - 所以想要实现身份验证，通信双方需要先有秘密信息，即根证书中的公钥
HTTPS
- 把 HTTP 的明文换成密文，再验证身份，即 HTTPS
- HTTPS = HTTP + TLS
- TLS =
身份验证+ 加解密 身份验证靠 PKI
- 服务端身份验证靠 PKl，客户端身份验证靠 HTTP 协议。
小结
- 网络安全三要素：机密性、完整性和身份验证
- 在没有提前交换秘密信息的前提下，无法在不安全的信道交换秘密信息
- PKI 保证了普通用户不需要“面对面"和根证书机构交换根证书
- HTTPS 使用 PKI 完成了除客户端身份验证以外的特性，客户端身份验证靠 HTTP 协议实现
参考文献和书籍推荐
- 计算机网络（原书第7版），机械工业出版社
- HTTP 权威指南，人民邮电出版社
- 密码编码学与网络安全（第6版），电子工业出版社
- web.dev/performance…
- calendar.perfplanet.com/2020/head-o…
