计算机网络概论

基本结构、介绍 web 开发的基本协议、http提及发展史并使用 cdn 作为例子描述如何在 http 协议之外提升网络性能，简要介绍网络安全的基本实现

前言 & 课程介绍

虚拟世界和现实世界的桥梁

通过一个示例简历对计算机网络的整体认识
建立对网络协议分层的认知
分析 HTTP 1、2、3的关系
介绍 CDN 运行的基本原理
了解网络安全的最基本原则

分析方法

自底向上（了解计算机网络基础知识，逐步加深知识点）
- 从简单开始，逐渐变复杂
- 将模块逐步拼凑成一个系统
自顶向下（解释现成网络协议的特性、工作原理）
- 从复杂开始，逐渐变简单
- 从复杂的系统问题入手，拆分为模块问题

蟹堡王帝国

挣一个小目标

三步走战略

在比奇堡开通外卖服务，增加额外收入
在其它城市开分店
在全国开分店并开通外卖服务

通信 -> 蟹老板：我要知道所有店铺的盈收怎么样

外卖

通过电话 -> 如果同时打电话可能导致线路会堵（顾客体验不是很良好），章鱼哥经过分析发现，电话内容几乎都是：谁吃？吃什么？送到哪里？如果客户把这些问题的答案，发给蟹堡王就可以解决线路拥堵的问题，于是章鱼哥找到森迪发明了传真，客户通过传真把订单发到蟹堡王
通过传真 -> 目标明确且不会拥堵

其它城市开启分店

分店
- 北京方恒蟹堡王
- 上海科技绿洲蟹堡王
通信线路（收集分店销售数据）
- 赚了多少钱
- 确定原料数量
- 是否需要新分店
- 促销信息
新的分店
- 中航蟹堡王
- 紫金蟹堡王
- 大钟寺蟹堡王
- 通信线路怎么办？

这些分店的线路连接到北京方恒分店，再通过北京方恒分店转发至蟹堡王总店，促销活动也是通过北京方恒分店转发至北京的其它分店（北京方恒分店相当于北京分店的总分店）

通过转发但是发现顾客不知道北京其它分店到底在哪儿（中航也不知道，所以又问章鱼哥，每次都是这样），为了解放章鱼哥，每次创建新的分店时，每个分店都有一份相关分店的详细地址

蟹堡王全国外卖

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

如果每个都直连蟹堡王的话，成本太高了，于是你就创建一个转发点，通过转发点直连蟹堡王从而降低了成本，全国的分店都需要考虑线路重复的问题

最后经过分析你得到如图所示的线路图：

小结

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

示意图： ISP(Internet Service Provider，互联网服务提供商<联通、移动、电信>)

计算机网络基础

网络组成部分

主机：客户端和服务端，提供信息和接收信息
路由器：转发主机之间的信息
网络协议：负责提供统一的格式，方便路由器或主机这类信息进行编码和解码

网络结构

网络的网络

比奇堡和小区网络：本地网络
北京和上海分店 + 比奇堡：三个本地网络节点的网络
全国通信网络：本地网络的网络
区域网络、城域网络和广域网（外卖）

信息交换方式

电路交换
分组交换
区别：
- 分组交换，把每个信息拆分成很小的报文，有新的信息会加入到分组队列中，如果队列满了会把新的分组丢弃--丢包
- 电路交换，每次都要建立连接，即使不通信也会占用资源，资源利用率低

网络分层

快递员不关心包裹内容
卡车司机不关心车厢里拉的是什么
高速公路不关心开的什么车
具体分层（OSI）
- 物理层
  - 建立、维护、断开物理连接（由底层网络定义协议）
- 数据链路层
  - 建立逻辑连接、进行硬件地址寻址、差错检验等功能（由底层网络定义协议）
  - 将比特组合成字节进而组合成帧，用 MAC 地址访问介质，错误发现但不能纠正
- 网络层
  - 进行逻辑地址寻址，实现不同网络之间的路径选择
  - 协议有：
    - ICMP(Internet Control Message Protocol)：Internet 控制报文协议，它是 TCP/IP协议簇的一个子协议，用于在 IP主机、路由器之间传递控制消息
    - IGMP(Internet Group Management Protocol)：Internet 组管理协议，是因特网协议家族中的一个组播协议，该协议运行在主机和组播路由器之间，有三个版本(v1、v2、v3)
    - IP(Internet Protocol)：网际互连协议，是TCP/IP体系中的网络层协议
      - IPV4(Internet Protocol Version 4)：又称互联网通信协议第四版，是网际协议开发过程中的第四个修订版本，也是此协议第一个被广泛部署的版本。
      - IPV6(Internet Protocol Version 6)：是互联网工程任务组(IETF)设计的用于替代 IPV4 的下一代 IP 协议，其地址数量号称可以为全世界的每一粒沙子编上一个地址。
- 传输层
  - 定义传输数据的协议端口号，以及流控和差错校验
  - 协议有：
    - 数据包一旦离开网卡即进入网络传输层
    - TCP(Transmission Control Protocol)：是一种面向连接的、可靠的、基于字节流的传输层通信协议，由 IETF 的 RFC 793定义
    - UDP(User Datagram Protocol)：用户数据报协议，Internet 协议集支持一个无连接的传输协议，UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法。
- 会话层
  - 建立、管理、终止会话（在五层模型里面已经合并到了应用层）
  - 对应主机进程，指本地主机与远程主机正在进行的会话
- 表示层
  - 数据的表示、安全、压缩（在五层模型里面已经合并到了应用层）
  - 格式有，JPEG、ASCII、EBCDIC、加密格式等
- 应用层
  - 网络服务与最终用户的一个接口
  - 协议有：
  - HTTP(Hypertext Transfer Protocol)：超文本传输协议，是一个简单的请求-响应协议，它通常运行在 TCP 之上，它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。
  - FTP(File Transfer Protocol)：文件传输协议，是用于在网络上进行文件传输的一套标准协议，它工作在 OSI 模型的第七层(应用层)，TCP 模型的第四次，使用 TCP 传输而不是 UDP，客户在和服务器建立连接前要经过一个“三次握手”的过程，保证客户与服务器之间的连接是可靠的，而且是面向连接，为数据传输提供可靠保证
  - TFTP(Trivial File Transfer Protocol)：简单文件传输协议，是 TCP/IP 协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议，提供不复杂、开销不大的文件传输服务
  - SMTP(Simple Mail Transfer Protocol)：是一种提供可靠且有效的简单邮件传输协议，SMTP是建立在FTP文件传输服务上的一种邮件服务，主要用于系统之间的邮件信息传递，并提供有关来信的通知。
  - SNMP(Simple Network Management Prptocol)：简单网络管理协议的原来名字叫做简单网关监控协议(Simple Gateway Monitoring Protocol)最早是 IETF 的研究小组提出来的，在 SGMP 协议的基础之上，加上新的管理信息结构和管理信息库，从而让 SGMP 更加全面
  - DNS(Domain Name System)：域名系统是互联网的一项服务，它作为将域名和 IP 地址相互映射的一个分布式数据库，能够使人更方便地访问互联网
  - TELNET：Telnet 协议是 TCP/IP 协议族中的一员，是 Internet 远程登录服务的标准协议和主要方式，它为用户提供了在本地计算机上完成远程主机工作的能力。
  - HTTPS(Hypertext Transfer Protocol Secure)：是以安全为目标的 HTTP 通道，在 HTTP 的基础上通过传输加密和身份认证保证了传输过程的安全性。
  - POP3(Post Office Protocol - Version 3)：邮局协议版本3，是 TCP/IP 协议族中的一员，本协议主要用于支持使用客户端远程管理在服务器上的电子邮件
  - DHCP(Dynamic Host Configuration Protocol)：动态主机配置协议是一个局域网的网络协议，指的是由服务器控制一段 IP 地址范围，客户机登录服务器时就可以自动获得服务器分配的 IP 地址和子网掩码。

协议

协议的存在依赖于连接。 01001000 01100101 01101100 01101100 01101111 00101100 00100000 01010111 01101111 01110010 01101100 01100100 00100001(二进制)

72 101 108 108 111 44 32 87 111 114 108 100 33(十进制)

H e l l o , W o r l d ! (注意英文逗号后面还有一个空格，ASCII码)

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

标头(header)和载荷(payloads)

收件人、寄件人关注：

收件地址、寄件地址
收件人、寄件人的姓名和电话
包裹内容快递公司关注：
收件人、寄件人关注的东西
该由那个集散点发出，哪个集散点收
哪个网点派送

标头：记录客户端相应数据
载荷：服务端解析客户端数据并添加具体的分发服务器进行发送信息

HTTP协议示例

本地帧头部

1-4个字节，表示不需要交换机啥的，本地可以访问

IP 协议头部

5-44个字节，表示IP协议的版本（v6），原IP地址，目标IP地址

TCP 协议头部

45-64个字节，包含原端口号，目标端口号，序列号，头部长度

HTTP 协议头部

包含头部和载荷部分，因为示例中是 get 请求，所以并没有载荷 结论： 报文 = 链路层头 + IP协议头 + TCP 协议头 + HTTP 协议头 + HTTP 正文

TCP协议格式

HTTP 1.1 版本及以前版本中，通过对报文的解析，头部和载荷是通过 换行符 和 回车符 划分的，而 TCP 不是，而是通过 data offest 划分

Web 中的网络

HTTP 协议

请求
第一行包含三个要素：请求方式、请求路径、HTTP 版本
响应
第一行(状态行)包含三个要素：HTTP 版本、状态码、重要信息

HTTP 连接模型

HTTP 使用了典型的请求响应模型，客户端只能等待服务端完成响应，才可以再次进行发送请求，网络利用率明显很低，从而导致一条连接无法多路复用，并且多次的请求导致请求头部和响应头部的报文不断地重复增加，无法压缩，导致报文长度越来越长

HTTP 1.0（短链接-shor-lived connection）
- 每个请求都需要建立新的连接，循环之后销毁，之后的新请求需要重新建立连接
HTTP 1.1（长连接-Persistent connection）
- 只要不显示声明使用短链接模型，默认会保持 HTTP 连接一段时间，以实现连接重用
- 队头阻塞：当请求太大时，从而导致后续请求一直在等待状态
HTTP 管线（HTTP 管线-HTTP Pipelining）
- 默认情况下，HTTP 协议是严格按照顺序的，但是 HTTP 管线，允许客户端同时发送多个请求，服务端按顺序响应，但是对于队头阻塞的问题并没有什么帮助，而且还可能导致连接不安全的问题
HTTP 2.0
- 将多个 HTTP 请求拆分到帧里面，每个帧可以携带来自不同 HTTP 的数据，从而在传输过程中标识每个数据包属于哪个请求
- 如图所示：
  - 前三个字节表示帧的长度
  - 第四个字节表示帧的类型（DATA）
  - 第五个字节表示不同帧不同的含义，在传输过程中当前帧的状态
  - 第六个字节，第一位是保留位，后面31个字节是流id
  - 剩余字节就是当前帧的载荷
- 带来的好处：
  - 解决队头阻塞和多路复用的问题
  - 调整响应传输的优先级
  - 头部压缩
  - Server Push
- 3 RTT(Round-Trip Time，往返时间) 启动
  - HTTP 客户端发送请求（暂缓，验证）
  - TCP 向 TCP 服务端发送请求
  - TCP 服务端响应 TCP 客户端请求
  - TLS 客户端向 TLS 服务端发送获取密钥请求
  - TLS 服务端响应 TLS 客户端请求，并返回密钥
  - HTTP 客户端成功发送请求
  - TCP 连接需要一个 RTT
  - TLS 建立需要两个
HTTP 3.0 QUIC
- Quick UDP Internet Connection
- 现存网络设备对 TCP 和 UDP 支持已经僵化
- UDP 不靠谱但是 QUIC 靠谱
  - UDP 不靠谱：没有阻塞控制、没有顺序保证、也没有数据的可靠性
- QUIC 可以为除 HTTP 协议以外的应用层协议提供支持
- QUIC - 1 RTT
  - QUIC 第一次访问
  - HTTP 客户端向 HTTP 服务端发送请求（暂缓，验证）
  - QUIC 客户端向 QUIC 服务端发送请求（俺要钥匙）
  - QUIC 服务端响应 QUIC 客户端的请求（好的，给你）
  - HTTP 客户端成功发送请求
  - QUIC 客户端偷偷地向 HTTP 客户端发送密钥
  - QUIC 连接需要一个 RTT
- QUIC - 0 RTT
  - QUIC 第二次访问
  - HTTP 客户端向 HTTP 服务端发送请求（暂缓，验证）
  - QUIC 客户端向 QUIC 服务端发送请求（密钥已经给过了）
  - QUIC 服务端响应 QUIC 客户端的请求（直接响应了 HTTP 的报文）
  - HTTP 客户端请求立马得到响应
  - 因为第一次 QUIC 被访问的时候已经给了密钥，所以后续访问不需要再进行密钥发送，0 RTT

CDN(Content Delivery Network，内容分发网络)

CDN 暂时无法满足的条件
- 无法脱离物理的极限（近距离的连接比远距离连接快，而且物理设备有限制存在）
- 你的钱包够鼓吗（如果远距离连接的话，需要经过很多网络节点，不仅延迟高，还浪费很多资源）
- 你够强大吗（一个服务器的流量是有限的，大型的网站通常百万以上的请求，我这小身板可能顶不住）
CDN 服务器
- 只要在六个城市内部署服务器，用户可以在最多两跳内访问全国服务器
DNS(Domain Name System，域名系统) 劫持
- 域名解析一般由网站自己处理
- 要加速的域名则重定向到 CDN 厂商的域名解析服务处理
- CDN 厂商根据来源确定最近的 CDN 服务器的 IP
- 用户直接访问最近的 CDN 服务器
如何选择一台 CDN 服务器呢？
- 在上述中，一般都是访问 CDN 厂商提供的最近服务器的 IP
- 但是并不都是最近的最好，没多一根路由器节点们都会增加一次转发延迟
- 不同的负载，具体的地点（访问位置），都会影响用户访问的速度
通常维护 CDN 都是采用维护部分的策略
- 拉策略（用户之间 CDN 拷贝）
  - 默认情况下什么也不做
  - 用户访问了，先去仓库查询有没有
  - 没有向总服务器发送请求
    - 再将请求返回内容保存至服务器
  - 有的话直接返回
- 推策略（网站之间 CDN 拷贝）
  - 先存放一些到仓库
  - 用户访问了，先去仓库查询有没有
  - 没有向总服务器发送请求
    - 再将请求返回内容保存至服务器
  - 有的话直接返回
一般 CDN 服务器都有流量限制，每过一段时间都会采用一定的策略进行空间的清理，如 LRU 策略

WebSocket

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

WebSocket 示例

服务端代码

const { WebSocket } = require("ws");

const wsServer = new WebSocketServer({ port: 8080 });

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

服务端中先开放连接的端口 8080，接着监听是否有客户端连接有则打印客户端发送的消息 something，并将客户端的消息返还给客户端 ws.send(data);。

客户端代码

const WebSocket = require("ws");

const ws = new WebSocket('ws://localhost:8080');

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

客户端中先声明一个 WebSocket 客户端地址为 ws://localhost:8080，如果连接服务端成功，就向服务端发送一条消息 something，同样接收服务端返回的消息 something。

升级为 WebSocket

网络安全

网络安全三要素

机密性：攻击者无法获取通信内容
完整性：攻击者对内容进行篡改时能被发现
身份验证：攻击者无法伪装成通信双方的任意一方与另一方通信
可以通过加密方式以及签名加证书

加密方式

单向加密
- 也叫做不可逆加密，对明文的加密产生一个密文，并不能通过密文，解出来对应的明文
对称加密
- 对称加密，用一个密钥，对明文进行加密，同理，同这把密钥，也可以对密文进行解密，也就是说加密和解密，可以用同一个密钥，这种加密方式就是 对称加密
非对称加密：
- 我们知道，对称加密使用同一把密钥，相反，非对称加密，使用公钥和私钥进行加密解密，可以使用私钥加密，公钥进行解密，同理，也可以使用公钥加密，私钥进行解密

密码散列函数（哈希函数）

输入：任意长度的内容
输出：固定长度的哈希值
性质：找到两个不同的输入使之经过密码散列函数后有相同的哈希值，在计算上是不可能的

机密性

网络是明文的，不安全
怎样才能在不安全的信道中，安全的通信呢？
- 对连接之间的信息通过加密方式进行加密，再双方都获得对方的密钥进行加密解密
- 通过对称加密、非对称加密、密码散列函数

完整性

有明文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 = HTTPS + TLS
TLS = 身份验证 + 加解密
服务端身份验证靠 PKI，客户端身份验证靠 HTTP 协议

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