计算机网络

蟹堡王帝国

分析方法

自底向上

从简单开始，逐渐变复杂 将模块逐步拼凑成一个系统

自顶向下

从复杂开始，逐渐变简单 从复杂的系统问题入手，拆分为模块问题

三步走战略

1.在比奇堡开通外卖 2.在北京和上海开分店 3.在全国开分店并开通外卖

蟹堡王外卖

章鱼哥：蟹堡王，请问要吃什么 龙虾拉里：为什么我打不通？

谁吃？派大星 吃什么？两个蟹黄堡和一个炸海草 送到哪？比奇堡石头屋

蟹堡王分店

中航蟹堡王 紫金蟹堡王 大钟寺蟹堡王

通信线路怎么办？

转发表格

中航蟹堡王在哪

方恒店员：中航蟹堡王在哪？ 章鱼哥：就在那！在那！

距离大大缩短

蟹堡王外卖

比奇堡居民居住分散 城市中的小区密度较高 小区中每家都直连蟹堡王成本太高

蟹堡王全国

小结

比奇堡外卖 北京和上海分店 全国分店和通信网络

蟹堡王顾客：客户端 蟹堡王分店：服务端 小区转发点和蟹堡王城市转发分店：路由器 转发表格：网络协议

网络基础

网络组成部分

主机：客户端和服务器

路由器

网络协议

网络结构:网络的网络

局域网络、城域网、广域网

信息交换方式

电路交换&分组交换

网络分层

分清职责

物理层

数据链路层

网络层

高速公路不关心开的什么车

运输层

卡车司机不关心车厢里拉的是什么

应用层

快递员不关心包裹内容

协议

协议的存在依赖于连接。

协议定义了两个或多个通信实体之间交换的报文格式和顺序，以及报文发送和/或接受一条报文或其他事件所采取的动作

标头和载荷

收件人、寄件人关注：

收件地址、寄件地址：标头

收件人、寄件人的姓名和电话

包裹内容：载荷

快递公司关注： 收件人、寄件人关注的东西：载荷

该由哪个集散点发出，哪个集散点收(寄件人、收件人上方的信息）：标头

哪个网点派送

TCP协议格式

小结

网络组成部分：由主机、路由器、交换机等组成 网络结构：网络的网络 信息交换方式：电路交换和分组交换 网络分层：分清职责，物理层、链路层、网络层、运输层和应用层 网络协议：标头和载荷

Web中的网络

HTTP链接模型

对头堵塞（Head of Line Blocking)

HTTP1

HTTP2：帧

request=style.css,content='body {
request=main.js,content='console.log('hello world')'
request=style.css,content='color:red;'
request=style.css,content='}'

HTTP2:帧带来的额外好处

• 调整响应传输的优先级
• 头部压缩
• Server Push

队头堵塞，但是在TCP上

• TCP包0：包含了（包含了style.css的第1行内容)的HTTP2的帧
• TCP包1：包含了（包含了main.js的全部内容)的HTTP2的帧
• TCP包2：包含了（包含了style.css的第2行内容)的HTTP2的帧
• TCP包3：包含了（包含了style.css的第3行内容)的HTP2的帧 TCP包1丢包了

3RTT启动

HTTP客户端：我要和大哥说话！

TCP客户端默默对HTTP客户端说，我知道你很急，但你先别急。

TCP客户端：嗨！服务端，你在吗？
TCP服务端：嗨！客户端，我在，你在吗？
TLS客户端：Hello！能给我把钥匙吗？
TLS服务端：Hello！给！你的钥匙！
HTTP客户端：终于到我了，我要index.html！

三倍的延迟

HTTP3：QUIC

• Quick UDP Internet Connection
• 现存网络设备对TCP和UDP支持已经僵化
• UDP不靠谱但是QUIC靠谱
• QUIC可以为除HTP协议以外的应用层协议提供支持

运输层协议

HTTP 3:QUIC-1 RTT

第一次访问
HTTP客户端：我要和大哥说话！
QU1C客户端：嗨！服务端，你在吗？在的话能给我把钥匙吗？
QUIC服务端：嗨！客户端，我在，这是你的钥匙！
HTTP客户端：今天这么快？我要index..html!
QU1C服务端（偷偷地告诉客户端）：这还有把钥匙，下次找我可以不用问，直接用

HTTP:QUIC-0 RTT

QUIC第二次访问
HTTP客户端：我要和大哥说话！
QUC客户端：嗨！服务端，你在吗？后面的话我已经用上次你给我的钥匙加密
过了，HTTP那小子肯定要index..html!
QUIC服务端：嗨！客户端，我在，我知道你要index.html,给你！
HTP客户端：？

CDN

CDN:你无法突破物理极限的
HTTP3快吗？
快！
那从美国到中国，HTTP3要多久？
150ms!
和北京到上海比，还快吗？
好像不够？

CDN:你的钱包够鼓吗？
·流量多少钱一个G?
·1块
·那我在北京给上海的人发一部10G电影得10块？
对！
·发10次一样的电影要100块？
是的！
·我都发到上海了，不能内部共享下吗？

CDN:你，够强大吗？
·我们有几台服务器？
·1台
·他能抗多少流量？
·100G!
·双十一峰值得1000G啊，扛得住吗？
·不一定，可能挂…

CDN:DNS劫持
域名解析一般由网站自己处理
要加速的域名则重定向到CDN厂商的域名解析服务处理
CDN厂商根据来源确定最近的CDN服务器的IP
用户直接访问最近的CDN服务器

拉策略
·默认情况下什么也不做
·谁需要了，先看看仓库有没有
·有，直接给
·没有，你等着，我去买个橘子
(每隔几天)这都啥啊，丢了


推策略
·大哥说今天你存这些，明天存那些
·谁需要了，先看看仓库有没有
·有，直接给
·没有，你等着，我去买个橘子
·大哥说这个、这个还有这个，丢了

WebSocket

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

WebSocket还可以传输二进制文件

小结

HTTP123的演进历史 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 服务端身份验证靠PKI,客户端身份验证靠HTTP协议。

例如登录时携带的Cookie

小结

网络安全三要素：机密性、完整性和身份验证 在没有提前交换秘密信息的前提下，无法在不安全的信道交换秘密信息 PK保证了普通用户不需要“面对面”和根证书机构交换根证书 HTTPS使用PK完成了除客户端身份验证以外的特性，客户端身份验证靠 HTTP协议实现