计算机网络笔记 | 青训营笔记1、前言 & 课程介绍目标：建立对计算机网络的整体认知，对计算机网络中的各种概念(网

1、前言 & 课程介绍

目标：
- 建立对计算机网络的整体认知，对计算机网络中的各种概念(网络分层、网络协议、网络应用等)有初步的理解。进而可以在后续的实际工作中能高效解决网络问题。
这节课会:
- 通过一个示例建立对计算机网络的整体认识
- 建立对网络协议分层的认知
- 分析HTTP 123的关系
- 介绍CDN运行的基本原理
- 了解网络安全的最基本原则
这节课不会:
- 详细描述如何开发一个基于HTTP协议(或者其他协议)的网络应用
- 深入介绍课程中所涉及协议的规范(Specification) 内容和实现细节
分析方法
- 自底向上
  - 从简单开始，逐渐变复杂
  - 将模块逐步拼凑成一个系统
- 自顶向下
  - 从复杂开始，逐渐变简单
  - 从复杂的系统问题入手，拆分为模块问题

2、蟹堡王帝国

小目标
- 蟹老板想挣一个小目标”
三步走战略
- 1.在比奇堡开通外卖
- 2.在北京和上海开分店
- 3.在全国开分店并开通外卖
蟹堡王外卖
- 章鱼哥:蟹堡王，请问要吃什么
- 龙虾拉里:"为什么我打不通?"
蟹堡王外卖
- 谁吃? ---派大星
- 吃什么? ---两个蟹黄堡和一个炸海草
- 送到哪? ---比奇堡石头屋
北京和上海分店
- 分店
  - 北京方恒蟹堡王
  - 上海科技绿洲蟹堡王
- 通信线路
  - 赚了多少钱
  - 确定原料数量
  - 是否需要新分店
  - 促销信息
新的分店
- 中航蟹堡王
- 紫金蟹堡王
- 大钟寺蟹堡王
- 通信线路怎么办?
转发表格
- 来自中航蟹堡王发往比奇堡蟹堡王内容今日销售数据:1000个蟹黄堡
- 来自比奇堡蟹堡王发往中航妮堡王内容明日促销信息:全场8折
中航蟹堡王在哪
- 方恒店员:中航蟹堡王在哪?
- 章鱼哥:就在那!在那!
蟹堡王外卖
- 比奇堡居民居住分散
- 城市中的小区密度较高
- 小区中每家都直连蟹堡王成本太高
小结
- 比奇堡外卖
- 北京和上海分店
- 全国分店和通信网络

3、计算机网络基础

网络组成部分
- 主机:客户端和服务端
- 路由器
- 网络协议
网络结构:网络的网络
- 比奇堡和小区网络:本地网络
- 北京和上海分店+比奇堡:三个本地网络节点的网络
- 全国通信网络:本地网络的网络
- 区域网络、城域网和广域网
电路交换&分组交换
网络分层
- 快递员不关心包裹内容
- 卡车司机不关心车厢里拉的是什么
- 高速公路不关心开的什么车
协议
- 协议的存在依赖于连接。
- 01001000 01100101 01101100 01101100 01101111 00101100 00100000 01010111 01101111 01110010 0110110001100100 00100001
- 72101 108 108 111 44 32 87 111 114 108 10033
- Helloworld!
- 协议定义了在两个或多个通信实体之间交换的报文格式和顺序，以及报文发送和/或接受一条报文或其他事件所采取的动作。
标头和载荷
- 收件人、奇件人关注:
  - 收件地址、奇件地址
  - 收件人、寄件人的姓名和电话
  - 包裹内容
- 快递公司关注:
  - 收件人、寄件人关注的东西
  - 该由哪个集散点发出，哪个集散点收
  - 哪个网点派送
- HTTP协议示例
- HTTP协议示例:链路层-本地帧头部
- HTTP协议示例：运输层-IP协议头部
- HTTP协议示例：应用层-IP协议头部
- TCP协议格式
- 小结
  - 网络组成部分: 由主机、路由器、交换机等组成
  - 网络结构: 网络的网络
  - 信息交换方式: 电路交换和分组交换
  - 网络分层: 分清职责，物理层、链路层、网络层、运输层和应用层
  - 网络协议: 标头和载荷

4、web 中的网络

HTTP协议
HTTP连接模型
HTTP1.1 无法多路复用
HTTP2：帧
- 前三个字节: 载荷长度
- 第四个字节: 类型
- 第五个字节: 类型对应的 Flags
- 第六到第九字节: 第1位:保留位第2-32位:流ID
- 随后的8192 字节: 载荷
HTTP2: 帧带来的额外好处
- 调整响应传输的优先级
- 头部压缩
- Server Push
HTTP2:队头堵塞，但是在TCP上
- TCP包0:包含了(包含了stylecss的第1行内容)的HTTP2的帧
- TCP包1:包含了(包含了mainjs的全部内容)的HTTP2的帧
- TCP包2:包含了(包含了stylecss的第2行内容)的HTTP2的帧
- TCP包3:包含了(包含了stylecss的第3行内容)的HTTP2的帧
- TCP 包1丢包了!
HTTP2:3RTT启动
- HTTP 客户端:我要和大哥说话!
- TCP 客户端默默对HTTP客户端说，我知道你很急，但你先别急。
- TCP客户端:嗨!服务端，你在吗?
- TCP 服务端:嗨!客户端，我在，你在吗?
- TLS客户端:Hello!能给我把钥匙吗?
- TLS服务端:Hello!给!你的钥匙!
- HTTP 客户端:终于到我了，我要index.html!
HTTP 3:QUIC
- Quick UDP Internet Connection
- 现存网络设备对TCP和UDP支持已经僵化
- UDP 不靠谱但是QUIC靠谱
- QUIC可以为除HTTP协议以外的应用层协议提供支持
HTTP3:QUIC-1RTT
- QUIC 第一次访问
- HTTP 客户端:我要和大哥说话!
- QUIC客户端:嗨!服务端，你在吗?在的话能给我把钥匙吗?
- QUIC 服务端:嗨!客户端，我在，这是你的钥匙!
- HTTP 客户端:今天这么快?我要index.html!
- QUIC 服务端(偷偷地告诉客户端):这还有把钥匙，下次找我可以不用问，直接用
HTTP:QUIC-0RTT
- QUIC 第二次访问
- HTTP 客户端:我要和大哥说话!
- QUIC客户端:嗨!服务端，你在吗?后面的话我已经用上次你给我的钥匙加密过了，HTTP那小子肯定要indexhtml!
- QUIC 服务端:嗨!客户端，我在，我知道你要indexhtml，给你!
- HTTP 客户端:?
CDN:你无法突破物理极限的
- HTTP 3快吗?
- 快!
- 那从美国到中国，HTTP 3要多久?
- 150 ms!
- 和北京到上海比，还快吗?
- 好像不够?
CDN:你的钱包够鼓吗?
- 流量多少钱一个G?
- 1块
- 那我在北京给上海的人发一部10G电影得10块?
- 对!
- 发10次一样的电影要100块?
- 是的!
- 我都发到上海了，不能内部共享下吗?
CDN:你，够强大吗?
- 我们有几台服务器?
- 1台
- 他能抗多少流量?
- 100 G!
- 双十一峰值得1000G啊，扛得住吗?
- 不一定，可能挂……
CDN:还得是我
- 北京
- 上海
- 广州
- 成都
- 长沙
- 兰州
- 长春

CDN:最多跳两次!

跳数	城市
0	北京、上海、广州、成都、长沙、兰州、长春
1	天津、石家庄、沈阳、呼和浩特、南京、杭州、澳门、香港、南宁、福州、南昌、武汉、贵阳、拉萨、重庆、西安、西宁、银川、哈尔滨
2	太原、济南、郑州、乌鲁木齐、台北、昆明、海口、合肥

CDN:DNS劫持
- 域名解析一般由网站自己处理
- 要加速的域名则重定向到CDN厂商的域名解析服务处理
- CDN厂商根据来源确定最近的CDN服务器的IP
- 用户直接访问最近的CDN服务器
CDN:近了!近了吗?
- 上海:4621+157.8=619.9 KM
- 广州:686.6 KM
- 选上海还是广州?
- 这人装福建人怎么办?
CDN:地主家也没有余粮了
- 拉策略
  - 默认情况下什么也不做
  - 谁需要了，先看看仓库有没有
  - 有，直接给
  - 没有，你等着，我去买个橘子
  - (每隔几天)这都啥啊，丢了
- 推策略
  - 大哥说今天你存这些，明天存那些
  - 谁需要了，先看看仓库有没有
  - 有，直接给
  - 没有，你等着，我去买个橘子
  - 大哥说这个、这个还有这个，丢了

WebSocket

有状态的持久连接
服务端可以主动推送消息
用WebSocket发送消息延迟比HTTP低

服务端代码：

const { WebSocketServer } = require('ws');
const wss = new websocketserver({ port: 8080 });
wss.on('connection', function connection(ws){
	//有新连接时监听来自客户端的消息
	ws.on('message', function message(data) {
		//1打印收到的消息，再把消息原封不动地发回给客户端
		console.log('received: %s', data);
		ws.send(data);
	});
});

客户端代码

const WebSocket = require('ws');
const ws = new WebSocket('ws://localhost:8080');
ws.on('open', function open() {
	//1当连接建立时，向服务端端发送一条消息
	ws.send('something');
});
ws.on('message', function message(data) {
	//当收到来自服务端的消息时，打印出来
	console.log('received: %s', data);
});

小结
- HTTP123的演进历史
- CDN解决了HTTP协议之外的问题
- WebSocket从HTTP协议升级而来

5、网络安全

网络安全: ----> 三要素
- 机密性:攻击者无法获知通信内容
- 完整性:攻击者对内容进行篡改时能被发现
- 身份验证:攻击者无法伪装成通信双方的任意一方与另一方通信
网络安全: ----> 对称加密和非对称加密
- 对称加密:加密、解密用同样的密钥
- 非对称加密:加密、解密使用不同的密钥(公钥和私钥)而且公钥加密只能用私钥解密、私钥加密只能用公钥解密
网络安全: ----> 密码散列函数(哈希函数)
- 输入:任意长度的内容
- 输出:固定长度的哈希值
- 性质:找到两个不同的输入使之经过密码散列函数后有相同的哈希值，在计算上是不可能的
网络安全: ----> 机密性
- 加密需要加密算法和密钥等信息(统称为秘密信息)
- 网络是明文的，不安全
- 怎么在不安全的信道交换秘密信息?
网络安全: ----> 完整性和身份验证
- 完整性和身份验证相互关联。
  - 蟹老板向银行发起了转账请求
  - 银行需要确认
    - 这个请求真的是蟹老板发起的
    - 目标账户和转账金额没有被篡改
网络安全: ----> 如何实现机密性
- 已知:网络是明文的
- 如果双方可以通过明文通信商量出秘密信息，那么攻击者也可以
- 所以想要通过明文通信交换秘密信息，通信双方需要先有秘密信息
网络安全: ----> 如何实现完整性
- 密码散列函数性质:找到两个不同的输入使之经过密码散列函数后有相同的哈希值，在计算上是不可能的
- 有明文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 KeyInfrastructure
- 所以想要实现身份验证，通信双方需要先有秘密信息，即根证书中的公钥
网络安全: ----> HTTPS
- 把 HTTP 的明文换成密文，再验证身份，即 HTTPS。
- HTTPS=HTTP+TLS
- TLS=身份验证+加解密
- 身份验证靠 PKI
- 服务端身份验证靠PKI，客户端身份验证靠HTTP协议。
小结
- 网络安全三要素:机密性、完整性和身份验证
- 在没有提前交换秘密信息的前提下，无法在不安全的信道交换秘密信息
- PKI保证了普通用户不需要“面对面和根证书机构交换根证书
- HTTPS使用PKI完成了除客户端身份验证以外的特性，客户端身份验证靠 HTTP 协议实现
参考文献和书籍推荐
- 计算机网络(原书第7版)，机械工业出版社
- HTTP 权威指南，人民邮电出版社
- 密码编码学与网络安全(第6版)，电子工业出版社
- web.dev/performance…
- calendar.perfplanet.com/2020/head-o…

计算机网络 笔记 | 青训营笔记

1、前言 & 课程介绍

2、蟹堡王帝国

3、计算机网络基础

4、web 中的网络

5、网络安全

计算机网络笔记 | 青训营笔记