1 计算机网络概述

1.1 网络概念

1.2 数据交换模式

1.3 网络分类

1.4 网络性能指标

1.5 网络系统结构

1. 概念

2. OSI参考模型

3 网络层

4 传输层

5 会话层

6 表示层

7 应用层

3. TCP/IP参考模型

4. 5层参考模型

5层结构

数据封装

2. 应用层

2.1 体系结构

1. 客户机/服务器结构（Client/Server）

2. P2P结构（peer-to-peer）

3. 混合结构

2.2 进程间通信

1. Socket

2. 寻址

3. 应用层协议

2.3 Web应用

1. HTTP协议

3. Web缓存/代理服务器技术

2.4 Email应用

1. 邮件客户端（user agent）

2. 邮件服务器（mail server）

3. SMTP协议（Simple Mail Transfer Protocol）

4. 邮件访问协议

2.5 DNS应用

1.DNS服务

2.分布式层次数据库

4. DNS记录和新闻格式

2.6 P2P应用

1. BitTorrent

2. 索引设计

2.7 Socket编程

1. Socket API

2. API调用流程

2.8 CDN

3. 传输层

3.1 传输层服务

1. 多路复用/分用

2.数据传输机制可靠

3. 流量控制机制

4. 拥塞控制机制

3.2 Internet传输层协议

1. UDP

2. TCP

4. 网络层

4.1 网络层服务

1. 转发

2. 路由

3. 连接建立

4. 网络层服务模型

4.2 虚电路网络

4.3 数据报网络

4.4 IPv4协议

1. IP数据报格式

2. IP分片

3. IP编址(addressing)

4. CIDR

5. 路由聚合

4.5 DHCP协议

4.6 NAT

4.7 ICMP协议

4.8 IPv6协议

4.9 路由算法

4.10 Internet路由

1. RIP协议

2. OSPF

3.BGP协议

4.11 SDN控制平面

4.12 网络管理与SNMP

5. 数据链路层

比特-toc" style="margin-left:40px;">5.1 差错检测和纠正比特

1. 奇偶校验码

2. Internet校验和

3. 循环冗余校验码

5.2 多路访问控制（MAC）协议

1. 信道划分（channel partitioning）MAC协议

2. 随机访问（random access）MAC协议

3. 轮转（taking turns）MAC协议

5.3 ARP协议

1. MAC地址

2. 地址解析协议

5.4 以太网

以太网帧结构

交换机

VLANs

1 计算机网络概述

接口与协议的区别

接口规定了运行在一个端系统上的程序请求因特网基础设施向运行在另一个端系统上的特定目的地程序交付数据的方式

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

TCP/IP只是一个协议栈，就像操作系统的运行机制一样，必须要具体实现，同时还要提供对外的操作接口。这个就像操作系统会提供标准的编程接口，比如win32编程接口一样，TCP/IP也要提供可供程序员做网络开发所用的接口，这就是Socket编程接口。

1.1 网络概念

网络：许多计算机连在一起
互联网： internet 许多网络连在一起
因特网： Internet 全求最大的互联网

1.2 数据交换方式

电路交换（Circuit Switching）实时性、建立专用路线
报文交换（Message Switching）报文一般比分组长、报文交换的时延较长
分组交换（Packet Switching）高效、迅速时延高
- 路由器存储转发功能

1.3 网络分类

按作用范围分：

新的理解，不单单从网络覆盖的范围来区分广域网、局域网

使用了广域网技术即广域网

使用了局域网技术即局域网

局域网：自己花钱购买设备、自己维护、带宽固定（100M，1000M），距离一般在100m以内
广域网：花钱买服务、花钱买带宽

1.4 网络的性能指标

速率：数字信道上传送数据位数的速率
带宽：数字信道能传送的最高速率 (b/s)
吞吐量(Throughput)：发送端与接收端之间传送数据速率（b/s）瓶颈链路
时延：
- 发送(传输)时延(transmission delay)=分组长度(bit)/链路带宽(bit/s)分组长度(bit)/链路带宽(bit/s)
- 传播时延(propagation delay)=物理链路长度(m)/信号在信道上的传播速率(m/s)物理链路长度(m)/信号在信道上的传播速率(m/s)
- 处理时延：差错检测、确定输出链路，一般<msec
- 排队时延：分组在路由器缓存中排队产生，等待输出链路可用
  - 丢包：分组到达速率超出输出链路容量时，超出部分丢弃
时延带宽积=传播时延×带宽传播时延×带宽 ;又称以比特为单位的链路长度
RTT（Round-Trip Time）往返时间
利用率：
- 信道利用率
- 网络利用率：信道利用率加权平均值

1.5 网络体系结构

优点：模块化的分层易于系统的更新、维护，任何一层服务的改变对于系统其他层都是透明的

1. 概念

实体（Entity）：交换信息的硬件或软件进程
协议（Protocol）：控制两个对等通信的规则
服务（Service）：下层向上层提供服务，上层需要下层提供的服务来实现本层的功能
服务访问点（SAP）：相邻两层实体间交换信息的地方

2. OSI参考模型

（Reference Model）

1 物理层

编码方式
- 单/双极性不归零码
- 单/双极性归零码 (缺点：无法判断结束信号)
- 曼切斯特编码
- 差分曼切斯特编码（抗干扰更强）
传输模式
- 单工（Simplex）
- 半双工（half-duplex）
- 全双工（full-duplex）
接口特性
- 机械、电气、功能、规程特性
比特同步
- 时钟同步

2 数据链路层

负责结点-结点（node-to-node）数据传输
组帧（Framing）
物理寻址（Physical addressing）
流量控制（Flow control）
- 避免淹没接收端
差错控制（Error control）
- 检测并重传损坏或丢失帧，并避免重复帧
访问(接入)控制（Access control）
- 在任一给定时刻决定哪个设备拥有链路（物理介质控制使用权）

3 网络层

负责源主机到目的主机数据分组（packet）交付：跨越多个网络
逻辑寻址（Logical addressing）：全局唯一，IP地址
路由（Routing）：路径选择
分组转发

4 传输层

负责源-目的（端-端）（进程间）完整报文传输
报文分段与重组
SAP寻址
- 确保将完整报文提交给正确进程，如端口号
连接控制
流量控制
差错控制

5 会话层

对话控制（dialog controlling）
- 建立、维护
同步（synchronization）
- 在数据流中插入“同步点”
最“薄”的一层

6 表示层

处理两个系统间交换信息的语法与语义（syntax and semantics）问题
数据表示转化
- 转换为主机独立的编码
加密/解密
压缩/解压缩

7 应用层

支持用户通过用户代理（如浏览器）或网络接口使用网络(服务)
典型应用层服务
- 文件传输（FTP）
- 电子邮件（SMTP）
- Web（HTTP）
- ......

通信过程

数据封装

增加控制信息：构造协议数据单元（PDU）
- 地址（Address）：标识发送端/接收端
- 差错检测码（Error-detecting code）
- 协议控制（Protocol control）：实现协议功能的附加信息

网络排错

从底层到高层

物理层安全

数据链路层安全：ADSL、无线AP

网络层安全

应用层安全：SQL注入漏洞、上传漏洞

3. TCP/IP参考模型

实际网络的运行方式

IP over Everything

4. 5层参考模型

综合OSI和TCP/IP的优点

5层结构

应用层: 通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程间通信和交互的规则。

FTP, SMTP, HTTP
传输层: 运输层的任务是负责为两个主机中进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文：

TCP, UDP
网络层: 网络层为分组交换网上不同主机提供通信服务。网络层将运输层产生的报文段或用户数据报封装成分组和包进行传送

IP协议、路由协议等
链路层: 两台主机间的数据传输，总是一段一段在数据链路上传送的，这就需要使用专门的链路层协议。在两个相邻节点间的链路上传送帧，每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。相邻网络元素（主机、交换机、路由器等）的数据传输

以太网（Ethernet）、802.11 (WiFi)、 PPP
物理层:比特传输

数据封装

2. 应用层

2.1 体系结构

1. 客户机/服务器结构（Client/Server）

服务器

24小时不间断提供服务

永久性访问地址/域名

利用大量服务器实现可扩展性
客户机

使用服务器提供的服务

间歇性接入网络

可能使用动态IP地址

不会与其他客户机直接通信

2. P2P结构（peer-to-peer）

没有永远在线的服务器
任意端系统/节点之间可以直接通讯
节点间歇性接入网络
节点可能改变IP地址

高度可伸缩，难以管理

3. 混合结构

综合以上两者的优点，规避缺点。如Napster

2.2 进程间通信

1. Socket

客户机进程：发起通信的进程

服务器进程：等待通信请求的进程

同一主机上的进程通信有进程间通信机制，由操作系统提供：管道、消息队列、共享内存、信号量

不同主机间的进程通信：使用套接字（Socket）,也称为网络编程的API

2. 寻址

IP地址
端口号/Port number
- 为主机上每个需要通信的进程分配一个端口号

3. 应用层协议

网络应用需遵循应用层协议
公开协议：由RFC（Request For Comments）定义
私有协议 : 多数P2P共享文件应用
消息类型（type）
消息语法（syntax）
字段语义（semantics）
规则（rules）

2.3 Web应用

1. HTTP协议

C/S结构
请求(命令)/响应交互模式
使用TCP传输服务
- 服务器在80端口等待客户请求
- 浏览器发起TCP连接请求
- 服务器接受TCP连接
- 交换HTTP消息
- 关闭TCP连接
无状态（stateless）
- 服务器不维护任何有关客户端过去所发请求的信息
1.0version 非持久性连接
- 每次传输一个对象
- 任何格式的内容都可以发送，这使得互联网不仅可以传输文字，还能传输图像、视频、二进制等文件
- 有GET、POST、HEAD请求命令
- 响应时间：2RTT+文件发送时间
1.1version 持久性连接
- 每次可传输多个对象
- 支持长连接（persistent connection）和请求的流水线（pipelining），connection字段默认keep-alive
- 错误通知的管理：新增了24个错误状态码
- 带宽优化及网络连接的使用：增加range头域，允许只请求资源的某个部分
- 新增方法：PUT、 PATCH、 OPTIONS、 DELETE
请求消息
响应消息
2.0 version 提升性能
- 多路复用，允许同时通过单一的HTTP/2连接发起多重的请求-响应消息
- 二进制分帧，文本表示形式多样，需要考虑较多场景，二进制比文本更方便健壮
- header压缩，通讯双方各自cache一份header fields表避免重复header传输
- 服务端推送
3.0 version QUIC实现机制
- 基于UDP协议
- 快速重启会话（支持手机网络切换），使用uuid来标识每一次连接，网络环境变化但uuid不变就不需要握手
与HTTPS的区别
- https需要到CA申请证书
- http运行在tcp上，所有传输的数据都是明文的，https运行在SSL/TLS之上，所有传输的内容都经过加密
- http默认端口为80，后者是443
HTTPS工作流程

第一步：客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

第二步：Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

第三步：客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。

第四步：客户端的浏览器根据双方同意的安全等级，建立会话密钥（随机产生），然后利用网站的公钥将会话密钥加密，并传送给网站。

第五步：Web服务器利用自己的私钥解密出会话密钥。

第六步：Web服务器利用会话密钥加密与客户端之间的通信。
Q: 用户访问一个网站的时候背后的过程与步骤是怎样的？

A: 基本流程：

利用DNS协议进行域名解析 --> 建立tcp协议三次握手过程 --> 客户端发出访问网站相应页面请求（发出http协议请求报文） --> 服务端发出相应访问页面的响应信息（发出http响应报文） --> 断开tcp协议四次挥手过程
1. DNS查询顺序：Hosts表-->本地DNS缓存-->上层DNS(迭代、泛洪)
2. 在本机与目标服务器之间的路由过程，包括IP协议、ARP协议、OSPF协议、BGP协议
3. 拿到响应消息了还需要浏览器进行解析渲染

2. Cookie

记录用户状态，有隐私问题

响应消息cookie头部行
请求消息cookie头部行
保存在客户端主机上的cookie文件，由浏览器管理
Web服务器后台数据库

3. Web缓存/代理服务器技术

一般由ISP架设

在不访问服务器的前提下满足客户端的HTTP请求
缩短客户请求的响应时间
减少机构/组织的流量
在大范围内实现有效的内容分发（CDN）

条件性GET方法更新缓存的数据，解决一致性问题

2.4 Email应用

1. 邮件客户端（user agent）

2. 邮件服务器（mail server）

邮箱：储存发给该用户的Email
消息队列（message queue）：存储等待发送的Email

3. SMTP协议（Simple Mail Transfer Protocol）

客户端：发送消息的服务器
服务端：接受消息的服务器
使用TCP进行Email消息的可靠传输
端口25
传输三个阶段
- 握手
- 消息传输
- 关闭
命令/响应交互模式
- 命令command ：ASCII文本
- 响应 response：状态代码和语句

//先去qq邮箱打开smtp，获取授权码 //输入需要进行base64加密 c:telnet smtp.qq.com 25 s:220 xxx.qq.com c:helo host //打招呼 s:250 xxx.qq.com c:AUTH LOGIN //登录认证 s:334 VXNbWU6 //输入账号 c:MTA3MxcS5jb20= s:334 UGFc3d6 //输入授权码 c:dWdwaXF5Y3ZzraWhQ== s:235 Authentication successful c:mail from: <1073788244@qq.com> //来自 s:250 OK c:rcpt to: <1073788244@qq.com> //发往 s:250 OK c:data s:354 End data with <CR><LF>.<CR><LF>. c:here is what i want to send c:. s:250 OK: queued as. c:quit s:221 bye

MIME:多媒体邮件扩展，在头部行增加扩展

4. 邮件访问协议

用于从服务器获取邮件

POP: Post Office Protocol

较简单，认证授权和下载

无状态
IMAP: Internet Mail Access Protocol

更多功能，更复杂

有状态
HTTP

2.5 DNS应用

1.DNS服务

Domain Name System

解决Internet上主机/路由器的识别问题

域名向IP地址的翻译
主机别名
邮件服务器别名
负载均衡：Web服务器

多个IP地址对应一个名字

2.分布式层次式数据库

解决的问题：
- 单点失败问题
- 流量问题
- 距离问题
- 维护性问题
根域名服务器
- 不知道映射访问权威域名服务器
- 全球13个
顶级域名服务器(TLD, top-level domain)
- com, org,net, edu等
权威域名服务器(Authoritative)
- 组织的域名解析服务器
本地域名解析服务器
- 不严格属于层级体系发
- 每个ISP有一个
- 主机进行查询发送给本地进行代理
- 迭代查询：代理进行多次询问
- 递归查询：代理询问一次让其他服务器去找

4. DNS记录和消息格式

1.DNS记录

资源记录（RR，resource records）

format：(name, value, type, ttl)

2.DNS协议与消息

查询（query）和回复（relpy）消息

消息格式相同

同时使用TCP（区域传输时）和UDP（域名解析时）

2.6 P2P应用

文件分发比C/S架构快

1. BitTorrent

文件分为chunk
- 获取：稀缺优先、定期查询邻居持有的chunk列表
- 发送：tit-for-tat
节点可自由加入和离开

Q：为什么运营商会封BT？

A：很简单，影响网络运营商超卖带宽了。ISP尤其是国内ISP最大的问题是，给用户提供网络接入服务，但从不保证服务质量。宣传上的“100M带宽光纤入户”从来不意味着你真的能用上100M带宽。甚至ISP从主观上，会用各种手段限制你，不让你用满这100M带宽。

抛开远端服务器和整体网络链路的因素以外，跑不满100M最主要原因在于ISP超卖，他们手里总共有1000M带宽，就敢给20家住户每家卖100M带宽，然后祈祷这20家不要同时把100M带宽跑满。只要你用任何技术手段，不管是BT CT 还是ET，只要大部分用户能这个技术稳定跑满带宽，ISP就会对这个技术恨得牙痒痒，恨不得封杀了之~除此以外的理由都是借口。链接：https://www.zhihu.com/question/310343843/answer/618352530

2. 索引设计

集中式索引：增设中央服务器
- 单点失效问题
- 性能瓶颈
- 版权问题
洪泛式查询：query flooding
- 覆盖网络（overlay network）： Graph
- 有很大的网络负担
- 查询消息通过已有TCP连接发送
- 节点转发查询消息
- 查询命中反向路经返回
层次式覆盖网络
- 介于集中与洪泛之间
- 节点和超级节点间维持TCP连接：集中
- 某些超级节点之间维持TCP连接：洪泛
- 如：skype

2.7 Socket编程

1. Socket API

标识通信端点（对外）：IP地址+端口号
操作系统/进程管理（对内）：套接字描述符(socket descriptor)

类型：

SOCK_STREAM: TCP协议
SOCK_DGRAM: UDP协议
SOCK_RAW：面向网络层

函数：

WSAStartup() 使用之前调用，初始化socket动态链接库
WSACleanup() 使用之后调用
socket() 创建套接字
closesocket() 关闭套接字，引用为0关闭
bind() 为套接字设置本地端点地址，
- 客户程序一般不必调用
- 服务端使用地址通配符 INADDR_ANY
listen() 仅服务端，TCP连接，置服务器端的流套接字处于监听状态，设置连接请求队列大小
connect() 仅客户端，客户端调用使其与特定计算机的特定端口的套接字进行连接
accept() 服务器端，用于TCP连接，创建一个新的套接字与客户通信，因为TCP连接是点对点的，实现并发的TCP服务器
send() 有连接的方式TCP(客户与服务器)，或调用了connect函数的UDP(客户)套接字
sendto() 无连接方式UDP(服务器)，或未调用connect函数的UDP客户端套接字
recv() 同上
recvfrom() 同上

2. API调用流程

网络字节顺序：实现本地字节顺序与网络字节顺序进行转换

基本服务类型：

循环无连接
循环面向连接
并发无连接：创建子进程处理
并发面向连接

2.8 CDN

内容分发网络

DASH（Dynamic Adaptive Streaming over HTTP）经HTTP的动态适应流

可以压缩生成相同视频的多个版本，每个版本有不同的质量等级。

CDN管理分布在多个地理位置上的服务器，在它的服务器中存储视频（或其他资源）的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的CDN位置

3. 传输层

传输层协议为运行在不同Host上的应用进程提供了一种逻辑通信机制

位于网络层之上

依赖于网络层的服务

对网络层服务进行增强

3.1 传输层服务

1. 多路复用/分用

此处的复用和分用是逻辑上的概念

发送端多路复用：处理来自多个套接字的数据，添加传输头

Q: I/O多路复用技术（multiplexing）是什么？

A：

常见的IO操作，如read和write，通常是阻塞IO，也就是说当你调用read时，如果没有数据收到，那么线程或者进程就会被挂起，直到收到数据。这样在处理大量连接时可能需要很多线程，比如4个核要跑1000个线程，那么每个线程的时间槽非常短，而线程切换非常频繁，大量时间花费在上下文切换。

此时引入非阻塞IO的概念，通过fcntl（POSIX）或ioctl（Unix）设为非阻塞模式，这时，当你调用read时，如果有数据收到，就返回数据，如果没有数据收到，就立刻返回一个错误，如EWOULDBLOCK。这样是不会阻塞线程了，但是你还是要不断的轮询来读取或写入。

于是，我们需要引入IO多路复用的概念。多路复用是指使用一个线程来检查多个文件描述符（Socket）的就绪状态，比如调用select和poll函数，传入多个文件描述符，如果有一个文件描述符就绪，则返回，否则阻塞直到超时。得到就绪状态后进行真正的操作可以在同一个线程里执行，也可以启动线程执行（比如使用线程池）。这样在处理1000个连接时，只需要1个线程监控就绪状态，对就绪的每个连接开一个线程处理就可以了，这样需要的线程数大大减少，减少了内存开销和上下文切换的CPU开销。

接收端多路分解：使用传输头信息交付接收到的段到正确的套接字

注意：服务端一个进程有多个线程，一个线程有多个套接字

UDP的socket用二元组标识
TCP的socket用四元组标识

2.可靠数据传输机制

Q：什么是可靠（reliable）？

A：不错、不丢、不乱

信道的不可靠特性决定了可靠数据传输协议（RDT）的复杂性

接口的结构：

RDT版本

Reliable Data Transfer

Rdt 1.0：可靠信道

Rdt 2.0: 产生位错误的信道

利用校验和检测位错误
确认机制（Acknowledgments，ACK）：正确接收
NAK：告知分组有错，重传分组
基于这种重传机制的rdt协议称为ARQ（Automatic Repeat reQuest）协议
FSM(Finit State Machine)规约

Rdt 2.1: 应对ACK/NAK破坏

发送方为每个分组增加序列号
两个序列号（0，1）就够用了，因为只用记住当前的序列号
接收方判断分组是否重复
发送方
接收方

Rdt 2.2：无NAK消息协议

接收方通过ACK告知最后一个被正确接受的分组
发送方接收到重复ACK之后，重传当前分组
FSM（相比2.1有较大简化）

Rdt 3.0: 信道既可能发送错误，也可能丢失分组

发送方等待“合理”时间，如果没有收到ACK，重传
添加定时器
时延有影响
性能很差
网络协议可能影响物理资源的利用

流水线协议

流水线机制提高资源利用率
需要更大的序列号范围
需要更大的存储空间以缓存分组

滑动窗口协议

Sliding-window protocol

窗口
- 允许使用的序列号范围
- 窗口尺寸为N: 最多有N个等待确认的消息
滑动窗口
- 随着协议的运行，窗口在序列号空间内向前滑动

Go-Back-N（GBN）协议发送方：
- 设置一个计时器
- ACK(n): 确认到序列号n(包含n)的分组均已被正确接收
- 超时Timeout(n)事件：重传序列号大于等于n，还未收到ACK的所有分组
接收方：
- ACK机制：发送拥有最高序列号的、已被正确接收的分组的ACK
  - 可能产生重复的ACK
  - 只需要记住唯一的expectedseqnum
- 乱序到达的分组
  - 直接丢弃-> 没有缓存
  - 重新确认序列号最大的、按序到达的分组
Selective Repeat（SR）协议

发送方

只重传没有接收到ACK的分组
N个连续的序列号
用单个硬件定时器模拟多个逻辑定时器

接收方

对每个分组单独进行确认
设置缓存机制，缓存乱序到达可以

序列号空间大小与窗口尺寸应满足的关系：

发送方窗口尺寸+接收方窗口尺寸≤可用序列号个数(2k,k为序列号使用位数)发送方窗口尺寸+接收方窗口尺寸≤可用序列号个数(2k,k为序列号使用位数)

TCP可靠数据传输

累计确认，返回期望收到的
使用单一重传定时器

定时器时间设置： TimeoutInterval=EstimatedRTT+4∗DevRTTTimeoutInterval=EstimatedRTT+4∗DevRTT

即EstimatedRTT+“安全边界”

EstimatedRTT=(1−α)⋅EstimatedRTT+α⋅SampleRTT(typically,α=0.125)EstimatedRTT=(1−α)⋅EstimatedRTT+α⋅SampleRTT(typically,α=0.125)

DevRTT=(1−β)⋅DevRTT+β⋅|SampleRTT−EstimatedRTT|(typically,β=0.25)DevRTT=(1−β)⋅DevRTT+β⋅|SampleRTT−EstimatedRTT|(typically,β=0.25)
快速重传机制

如果sender收到对同一数据的3个ACK，则假定该数据之后的段已经丢失，在定时器超时之前立即重传。

Q:为什么是三次冗余ACK？

A: 假定通信双方A和B发送4个TCP Segment

TCP segment 乱序有2/5 = 40%的概率会造成A收到三次 duplicated ACK(N);

而如果 N 丢了，则 A 有100%概率会收到三次duplicated ACK(N);

基于以上的统计，当 A 接收到三次 duplicated ACK(N)启动 Fast Retransmit 算法是合理的，即立马 retransmit N，可以起到 Fast Recovery 的功效，快速修复一个丢包对 TCP 管道的恶劣影响

而如果 A 接收到二次 duplicated ACK(N)，则一定说明是乱序造成的，即然是乱序，说明数据都到达了 B，B 的 TCP 负责重新排序而已，没有必要 A 再来启动 Fast Retransmit 算法

3. 流量控制机制

消除发送发使接受方缓存溢出的可能，是一种速度匹配服务，发送发发送速率与接收方的读取速率匹配。

TCP流量控制：

Receiver通过在Segment的头部字段将RcvWindow告诉Sender

rwnd=RcvBuffer−(LastByteRcvd−LastByteRead)rwnd=RcvBuffer−(LastByteRcvd−LastByteRead)
Sender限制自己已经发送的但还未收到ACK的数据不超过接收方的空闲RcvWindow大小

LastByteSent−LastByteAcked≤rwndLastByteSent−LastByteAcked≤rwnd

4. 拥塞控制机制

发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。

MSS（maximun segment size）最大报文段大小，不包括TCP/IP首部的长度，典型值为1460字节

代价：

当分组到达速率接近链路容量时，分组将经历较长的排队时延。
发送方必须执行重传以补偿因为缓存溢出而丢弃(丢失)的分组。
在多跳网络中，当分组被drop时，任何用于该分组的”上游“传输能力全都被浪费掉

控制方法：

端到端拥塞控制：在端到端拥塞控制方法中，网络层没有为传输层拥塞控制提供显式支持。即使在网络中存在拥塞，端系统也必须通过对网络行为的观察(如分组丢失与时延) 来推断拥塞的发生。

TCP 必须通过端到端的方法处理拥塞控制，因为 lP 层不会向端系统提供有关网络拥塞的反馈信息。TCP报文段的丢失(通过超时或 3 次冗余确认而得知)被认为是网络拥塞的一个迹象，TCP会相应地减小其发送窗口长度。具有公平性。
- LastByteSent−LastByteAcked≤CongWinLastByteSent−LastByteAcked≤CongWin
- rate≈CongWinRTTBytes/secrate≈CongWinRTTBytes/sec
- 加性增-乘性减（AIMD）
- Additive Increase：每个RTT将CongWin增大一个MSS--拥塞避免
  - Multiplicative Decrease：发生loss后将CongWin减半
  - 锯齿状

慢启动

cwnd的值以一个MSS开始，并且每当收到一个传输报文段的确认时就增加1MSS（相当于变为2倍）

拥塞避免

也就是每个传输轮次，拥塞窗口cwnd只能线性加一，而不是像慢开始算法时，每个传输轮次，拥塞窗口cwnd按指数增长。

发生超时重传，判断网络可能出现拥塞：

将ssthresh的值更新为发生拥塞时的cwnd的一半
将cwnd的值减小为1，并重新开始执行慢启动算法

快速恢复

发送方一旦收到3个重复确认，就知道现在只是丢失了个别的报文段。于是不启动慢开始算法，而执行快恢复算法

发送方将慢开始ssthresh的值和拥塞窗口cwnd值调整为当前窗口的一半，开始执行拥塞避免算法
也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些，即等于新的ssthresh+3
- 既然发送方收到3个重复的确认，就表明有3个数据报文段已经离开了网络;
- 这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中;
- 可见现在网络中不是堆积了报文段而是减少了3个报文段。因此可以适当把拥塞窗口扩大些。

Q: 何时将指数增长切换为线性增长：

A：当CongWin达到Loss事件前值的1/2时,即到达Threshold

添加变量Threshold，发生loss时将其设置为CongWin达到Loss事件前值的1/2

发生Timeout时，Threshold设置为1/2CongWin，直接将CongWin设为1MSS，

网络辅助的拥塞控制：在网络辅助的拥塞控制中，网络层设备件(即路由器)向发送方提供关于网络中拥塞状态的显式反馈信息。这种反馈可以通过数据报中的某个字段来指示链路中的拥塞情况。这种方法在早期的 IBM SNA 和 ATM 等体系结构中采用。

对于网络辅助的拥塞控制，拥塞信息从网络反馈到发送方通常有两种方式，直接反馈信息可以由网络路由器发给发送方。另一种形式是，路由器标记或更新从发送方流向接收方的分组中的某个字段来指示拥塞的产生(可以理解为对经过一个拥塞路由器的数据报做记号)。一旦接收方收到这个有拥塞标记的分组，就会通知发送方网络发生了拥塞。

3.2 Internet传输层协议

1. UDP

User Datagram Protocol

为什么存在？

无需建立连接

实现简单：无需维护连接状态

头部开销少

没有拥塞控制：应用可更好的控制发送时间和速率

特点：

基于Internet IP协议
- 复用/分用
- 简单的错误校验
“Best effort”服务
- 可能丢失
- 可能非按序到达
- 在应用层增加可靠性机制
无连接
- 发送方和接受方不需要握手
- 每个UDP段的处理独立于其他段

应用：

流媒体（容许错误、速率敏感）
DNS
SNMP

可靠性保证

在应用层添加可靠性保证
与具体应用相关的错误恢复
在http 3.0中使用
http3.0 with google quick

报文格式：

分解示意图：

UDP长度字段包含首部长度

单位：字节

校验和（checksum）：检测UDP段在传输中是否发生错误（如位翻转）

2. TCP

Transmission Control Protocol

特点：

点对点
可靠的、按序的字节流
流水线机制
发送方/接收方缓存
全双工
面向连接
流量控制机制

报文格式：

连接管理

三次握手

三次握手（Three-way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。

握手过程：

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。

第一次握手：客户端给服务端发一个 SYN (同步)报文，并指明客户端的初始化序列号 ISN(Initial sequence number)。此时客户端处于 SYN_SEND 状态。

首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。
服务端得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务器收到客户端的 SYN 报文之后，进行资源分配（可能受到SYN Flood攻击，可以使用SYN cookie进行防御），以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN。同时会把客户端的 ISN + 1 作为ack（确认号）的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。
- 在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。
- 客户端得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ack 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

确认报文段SYN=0，ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。
服务端得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

发送第一个SYN的一端将执行主动打开（active open），接收这个SYN并发回下一个SYN的另一端执行被动打开（passive open）。

在socket编程中，客户端执行connect()时，将触发三次握手。

Q：为什么要进行3次握手，不是2次或更多？

A：假设采用2次握手。如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

四次挥手

TCP 的连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，客户端或服务器均可主动发起挥手动作。

刚开始双方都处于 ESTABLISHED 状态，假如是客户端先发起关闭请求。四次挥手的过程如下：

第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
- 即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。
第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。
- 即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
- 即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。
- 即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。

收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的，服务端通常执行被动关闭，不会进入TIME_WAIT状态。

在socket编程中，任何一方执行close()操作即可产生挥手操作。

Q: 挥手为什么需要四次？

A：因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送（服务器的两次发送不能合并）。故需要四次挥手。

Q：释放连接时，等待2MSL的意义?

A：MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

保证客户端发送的最后一个ACK报文段能够到达服务端。

因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。

防止“已失效的连接请求报文段”出现在本连接中。

客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

进一步解释：

主动断开的一侧为A，被动断开的一侧为B。

第一个消息：A发FIN

第二个消息：B回复ACK

第三个消息：B发出FIN

此时此刻：B单方面认为自己与A达成了共识，即双方都同意关闭连接。

此时，B能释放这个TCP连接占用的内存资源吗？不能，B一定要确保A收到自己的ACK、FIN。

所以B需要静静地等待A的第四个消息的到来：

第四个消息：A发出ACK，用于确认收到B的FIN

当B接收到此消息，即认为双方达成了同步：双方都知道连接可以释放了，此时B可以安全地释放此TCP连接所占用的内存资源、端口号。

所以被动关闭的B无需任何wait time，直接释放资源。

但，A并不知道B是否接到自己的ACK，A是这么想的：

1）如果B没有收到自己的ACK，会超时重传FIN

那么A再次接到重传的FIN，会再次发送ACK，重新计时

2）如果B收到自己的ACK，也不会再发任何消息，包括ACK

无论是1还是2，A都需要等待，要取这两种情况等待时间的最大值，以应对最坏的情况发生，这个最坏情况是：

ACK从A到B最多经过1MSL，超过这个时间B会重发FIN B重发的FIN最多经过1MSL到达A

去向ACK消息最大存活时间（MSL) + 来向FIN消息的最大存活时间(MSL)。

这恰恰就是2MSL( Maximum Segment Life)。

等待2MSL时间，A就可以放心地释放TCP占用的资源、端口号，此时可以使用该端口号连接任何服务器。

TCP的四种计时器

重传计时器(Retransmission Timer)

目的：为了控制丢失的报文段或者丢弃的报文段。这段时间为对报文段的等待确认时间。
创建时间：在TCP发送报文段时，会创建对次特定报文段的重传计时器。
可能发生的两种情况：在截止时间（通常为60秒）到之前，已经收到了对此特定报文段的确认，则撤销计时器；在截止时间到了，但为收到对此特定报文段的确认，则重传报文段，并且将计时器复位。
重传时间：2*RTT（Round Trip Time，为往返时间）

坚持计时器(Persistent Timer)

目的：主要解决零窗口大小通知可能导致的死锁问题
死锁问题的产生：当接收端的窗口大小为0时，接收端向发送端发送一个零窗口报文段，发送端即停止向对端发送数据。此后，如果接收端缓存区有空间则会重新给发送端发送一个窗口大小，即窗口更新。但接收端发送的这个确认报文段有可能会丢失，而此时接收端不知道已经丢失并认为自己已经发送成功，则一直处于等待数据的状态；而发送端由于没有收到该确认报文段，就会一直等待对方发来新的窗口大小，这样一来，双方都处在等待对方的状态，这样就形成了一种死锁问题。如果没有应对措施，这种局面是不会被打破的。为了解决这种问题，TCP为每一个连接设置了坚持计时器。
工作原理：当发送端TCP收到接收端发来的零窗口通知时，就会启动坚持计时器。当计时器的期限到达时，发送端就会主动发送一个特殊的报文段告诉对方确认已经丢失，必须重新发送。【这个特殊的报文段就称为探测报文段，探测报文段只有1个字节的大小，里边只有一个序号，该序号不需要被确认，甚至在计算其他部分数据的确认时该序号会被忽略。】
截止期的设置：设置为重传时间的值。但如果没有收到接收端的响应，则会发送另一个探测报文段，并将计时器的值加倍并复位，直到大于门限值（一般为60秒）。在此之后，发送端会每隔60秒发送一个探测报文段，直到窗口重新打开。

保活计时器(Keeplive Timer)

目的：主要是为了防止两个TCP连接出现长时间的空闲。当客户端与服务器端建立TCP连接后，很长时间内客户端都没有向服务器端发送数据，此时很有可能是客户端出现故障，而服务器端会一直处于等待状态。保活计时器就是解决这种问题而生的。
工作原理：每当服务器端收到客户端的数据时，都将保活计时器重新设置（通常设置为2小时）。过了2小时后，服务器端如果没有收到客户端的数据，会发送探测报文段给客户端，并且每隔75秒发送一个，当连续发送10次以后，仍没有收到对端的来信，则

标签： 555集成电路间歇定时器

锐单商城拥有海量元器件数据手册、 IC替代型号，打造电子元器件IC百科大全！

计算机网络复习笔记

1 计算机网络概述

1.1 网络概念

1.2 数据交换方式

1.3 网络分类

1.4 网络的性能指标

1.5 网络体系结构

1. 概念

2. OSI参考模型

3 网络层

4 传输层

5 会话层

6 表示层

7 应用层

3. TCP/IP参考模型

4. 5层参考模型

5层结构

数据封装

2. 应用层

2.1 体系结构

1. 客户机/服务器结构（Client/Server）

2. P2P结构（peer-to-peer）

3. 混合结构

2.2 进程间通信

1. Socket

2. 寻址

3. 应用层协议

2.3 Web应用

1. HTTP协议

2. Cookie

3. Web缓存/代理服务器技术

2.4 Email应用

1. 邮件客户端 （user agent）

2. 邮件服务器 （mail server）

3. SMTP协议（Simple Mail Transfer Protocol）

4. 邮件访问协议

2.5 DNS应用

1.DNS服务

2.分布式层次式数据库

4. DNS记录和消息格式

2.6 P2P应用

1. BitTorrent

2. 索引设计

2.7 Socket编程

1. Socket API

2. API调用流程

2.8 CDN

3. 传输层

3.1 传输层服务

1. 多路复用/分用

2.可靠数据传输机制

3. 流量控制机制

4. 拥塞控制机制

3.2 Internet传输层协议

1. UDP

2. TCP

按键计数器

最近热搜

历史搜索 清除历史记录

1. 邮件客户端（user agent）

2. 邮件服务器（mail server）

历史搜索清除历史记录