计算机网络自顶向下方法
计算机网络 自顶向下方法
计算机网络与互联网
由节点和边构成的网络我们称其为计算机网络
从服务的角度看，计算机网络是分布式的应用进程和为分布式应用进程提供服务的基础设施。
一些术语：
节点
主机节点
各种联网的设备，主机 服务器、包括联网的机顶盒，冰箱上运行的应用程序
主机节点和主机上运行的应用程序也被成为网络边缘
数据交换节点：
交换机、路由器等网络交换设备
互联的路由器交换机也被成为网络核心
边
通信链路
光纤、同轴电缆、无线电、卫星
传输速率 就是带宽bps （bit per second）单位是bit 而不是Byte 所以所谓的百兆带宽也就10M多的下载速度= =
接入网链路
主机连接到互联网的链路
主干链路
路由器之间的链路
协议
协议是支撑互联网工作的标准，在通信过程中所要遵守的规则
协议定义了两个或多个通信实体之间交换的报文格式和次序，以及在报文传输或接收或其他事件方面所采取的动作
Internet
Internet是网络的网络，是多个局域网相连得到的大的网络结构
网络结构
网络分为了三个结构
边缘系统，核心系统和接入系统
边缘系统就是上面提到的主机节点以及主机节点上运行的程序 比如Web
核心系统就是上面的数据链路以及路由器以及交换机
接入系统把边缘系统接入到核心系统中从而达到互联的效果,
比如WIfi 再比如接入到家的光纤，卫星 等等 都算作接入网
客户服务器模式
客户端向服务端发送请求接受服务
比如说浏览器—服务器 客户端—服务器
对等（peer-peer）模式
很少甚至没有专门的服务器 在这个模式下 主机既可以是客户端又可以是服务器 我们可以向别人请求数据，别人也可以向我们请求数据（磁力链接= =）
采用网络设施的面向连接服务
在端与系统之间传输数据
握手
在传输数据之前做好准备，两个通信主机之间为连接建立状态
TCP-传输控制协议（Transmission Control Protocol）
是Internet上面向连接的服务
可以可靠的按顺序返回数据对数据做确认如果丢包会重新传输
流量控制
保证数据不会淹没对方
拥塞控制
当网络拥塞时，发送方降低传送速率
+++
笔记：
网络核心：
网络资源（比如带宽）被分成片供个人使用，有按频率分片（Frequency-division-multiplexing），按时间分片(Time-division-multiplexing)，按波长分片(Wave-division-multiplexing)
网络核心的关键功能就是转发和路由
转发 就是将分组从路由器的输入链路转移到输出链路
路由 决定分组采用的源到目标的路径
电路交换
电路交换是在两个端到端之间分配出一条专用的网络供通信使用
端到端之间的资源被分配给从源端到目标端的呼叫叫做Call
电路交换的好处是独享资源，每个呼叫建立起来就能够保证性能，不同于分组交换可能会受到网络拥堵造成的延迟和丢包。
如果建立通讯而没有使用就会造成资源的浪费
通常被传统电话网络使用而不用于计算机当中，因为建立连接时间长，计算机之间的通信具有突发性，如果使用线路交换，浪费的片比较多（即便这个片没有数据传递，其所占据的片也不能被别的呼叫使用）
分组交换
不同于电路交换，分组交换不再分为一个个的专用通道，而是使用全部的信道来通信
主机和主机之间的通讯被分为一个个的单位，而这个的单位我们称其为分组（packet）在每个交换节点间通过存储-转发的方式来进行传输
为什么要使用存储-转发的方式进行传输呢？ 因为如果你拿到一个bit就向其他交换机传输这一比特的话，就会同时占用两条信道，信道也就没有了共享的效果，变成了一个专用信道。
分组交换适合应对突发式的数据传输，因为其资源共享且简单不必建立呼叫，但是过度使用可能会造成网络拥塞（分组延时和丢包）对可靠的传输数据需要协议来约束。也就是拥塞控制。
排队延迟
每台分组交换机都有多条链路相连，对于每条线路，都有一个输出缓存（也叫输出队列）
如果到达速率>链路的传输速率，分组就会排队，等待输出
如果路由器的缓存用完了，分组就会抛弃，也就是丢包
数据报的工作原理
在通信前，无需建立连接，有数据就传输，每个分组都独立路由（路径不同，可能会失序），路由器根据分组的目标地址进行路由，
接入网与物理媒体
住宅接入 Modem
将上网数据调制加载到音频信号上，在电话线上传输，在局域将其中的数据解调出来，反之亦然
在互联网早期，由于专线接入家庭，成本高且收益差，所以使用电话线来做传输 有保证的带宽只有4KHz，在家里接入一个猫（光猫）也就是拨号调制解调器，这样就可以上网冲浪了（为什么叫冲浪呢，因为在音频的信号上 起起伏伏就和冲浪一样）
拨号调制解调器
56kbps的速率接入路由器，不能同时上网打电话，更不能总是在线
采用现有的电话线，但是根据频率，划分出用于音通信的部分，和上行带宽和下行带宽
线缆网络
有线电视信号线缆双向改造，FDM在不同频段传输不同信道的数据，数字电视和上网数据（上下行）
铜芯线缆和光纤网络将各个家庭用户接入到ISP路由器，各个用户共享到线缆头端的接入网络
企业接入网络
被企业和大学采用，端系统直接接到以太网交换机上
无线接入网络
各无线端系统共享无线接入网络（端系统到无线路由器）
通过基站或者接入点
无线LANs
靠路由器来接入互联网 在建筑物内部，11，54Mbps的传输速率
广域无线接入
由运营商提供1~10Mbps
3G，4G，LTE
物理媒体
把互联网连接起来的介质
引导型媒体： 信号沿着固体媒介被导引比如同轴电缆、光纤、双绞线
非引导媒体：
信号自由从传播：无线电
双绞线
两根绝缘铜线
同轴电缆
两根同心的铜导线 双向，有基带电缆和宽带电缆电缆上有多个信道
光缆
光脉冲，每个脉冲表示一个bit，在玻璃纤维中传输
点到点高速传输 10Gbps~100Gbps传输速率
在两个中继器之间可以有很长距离，不受电磁噪声的干扰
无线链路
开放空间传输电磁波，携带需要传输的数据，无需线缆 LAN（WIFI）蜂窝 卫星
Internet结构和ISP
在网络的最中心，一些为数不多的充分连接的大范围网络
ISP即网络服务提供商 比如中国联通、电信
第一层ISP 国家/国际覆盖，速率极高，与大量的第二层ISP和其他客户网络相连
第二层ISP 区域性的ISP
POP高层ISP面对客户的接入点，设计费用结算
IXP 多个ISP对等互联互通的地方
很多内容提供商ICP比如Google Akamai会部署自己的网络，连接自己的数据中心，并且连接很多Local ISP和各级ISP 靠近自己用户
分组交换 延时 吞吐量
丢失和延迟产生的原因：
分组到达链路的速率超过了链路的输出的能力，就会丢失
处理时延
检查分组的首部和决定该分组导向何处需要的时间是处理时延的一部分，此外，包括检查比特级别的差错所需要的时间也是处理时延。
排队时延
在输出链路上等待的时间
排队延迟的长度取决于其路由器上的拥塞程度（前面排了多少分组）
流量强度 = $\frac{分组长度*分组到达队列平均速率}{链路带宽}$
传输延时
R = 链路带宽
L = 分组长度
传输延时 = $\frac{L}{R}$
将分组转发到链路上的延时，也就是储存转发的延时。
传播延时
在物理链路上的传输时间（比如光纤，同轴双绞线之类的）
同样的 传播延时 = $\frac{物理链路长度}{媒介上的传播速度}$
Internet的延时和路由
沿着路径向每个路由器发送探测分组
路由器向发送方返回分组
发送方和回复之间间隔计时
吞吐量
在源端和目标端的速率（$\frac{数据量}{单位时间}$）
瞬间吞吐量 在一个时间点的速率
平均吞吐量 长时间的平均值
协议层次和服务模型
服务
底层实体向上层提供他们之间通信的能力
服务用户
服务提供者
原语
上层使用下层服务的形式，高层使用低层提供的服务，以及低层向高层提供服务都是通过服务访问原语来进行交互的形式
说白了就是底层给的函数接口
服务访问点
上层用下层提供服务通过层间接口的地点
比如邮箱
地址
端口
服务的类型
面向无连接的服务
两个对等层实体在通信前不需要建立一个连接，不预留资源，不需要双方活跃
不可靠，可能重复，可能失序
IP分组 数据包
适合传送零星数据
面向连接的服务
过程：
建立连接 通信 拆除连接
用于大数据块的传输
保序
服务和协议的区别
服务是底层向上层提供他们之间的通信 通过原语来操作
协议是对等实体之间相互通信需要遵守的规则
本层协议的实现选哟下层提供的服务来实现
本层实体通过的协议为上层提供更高级的服务
分层实现的好处：
概念化结构清晰
结构化 模块维护升级方便
Internet协议栈
应用层 网络应用
为人类用户或者其他应用进程提供网络应用服务
FTP HTTP SMTP DNS
传输层 主机之间数据传输
在网络层提供的端到端基础上细分为进程到进程 把不可靠通信变为可靠通信
TCP UDP
网络层 为数据报从源到目标选择路由
主机和主机之间的通信，端到端通信 不可靠
IP 路由协议
链路层 相邻节点之间数据传输
相邻两个网络节点之间的数据传输
可靠或不可靠
物理层 线路上传输bit
物理层的任务是将该帧的一个个比特从一 个节点移动到下一个节点
接受端把物理信号转换为0 1
OSI模型
OSI模型在应用层和传输层之间加入了表示层和和会话层
表示层
允许应用解释传输的数据 加密 压缩 机器相关的表示转换
会话层
数据交换的同步 检查点 恢复
这两层在Internet协议里是 归应用层自己去做的
封装与解封装
在源端会做一个大的封装 每一层都把自己的头加在 传输数据里
各层次协议数据单元
应用层：报文 message
传输层 报文段 segment TCP段 UDP数据报
网络层 分组 packet
数据链路层 帧 frame
物理层 位 bit
应用层
网络应用体系结构
客户服务器模式 client server
服务器 一直运行
有固定的IP地址和周知的端口号
扩展性差
客户端主动和服务器通信
与互联网间歇性连接
对等模式 p2p
没有一个一直运行的服务
任意端系统之间可以通信 每个节点技是客户端又是服务器
参与连接的主机可以间歇性改变IP地址
比如迅雷
进程通信
进程
在主机上运行的应用程序
在同一个主机可以用进程间通信机制通信
不同主机可以通过交换报文来通信
进程为了接受报文 必须有一个标识 SAP
主机 唯一的32位地址
但是仅仅有Ip地址不能唯一的表示意给进程 因为一台设备上同时会有多个进程在运行
使用TCP 或者UDP进行传输
HTTP TCP 80 端口 默认web页面 TCP 25 ftp TCP 2
一个进程用 IP+port表示端节点
层间接口所需要的信息
要传输的报文
对方的应用标识（谁来传的）
对望应用进程标识（传给谁）
报文段
源端口号目标端口号
将IP地址向下交给IP实体 用于封装IP数据段 源IP以及目标IP
socket是本地IP 本地端口和对方 IP 对方端口的一个标识
TCP socket 是一个会话关系
如果Socket 每次传输报文都携带这么多信息 太繁琐 不方便管理
所以使用代号标示通信的双方或单方 socket
Tcp socket
| 源IP | 源端口 | 目标IP目标 | 端口 |
|---|---|---|---|
两个进程之间的通信需要之前建立连接 两个进程的通信会持续一段时间
可以用一个整数 表示 两个应用实体之间的通信关系
就像你经常寄东西 直接给你个标识码 就不用每次都填那么多东西了
穿过层间接口的信息量最小
源IP 源端口 目标IP 目标端口
UDP socket 没有目标IP和端口
因此每次传输数据的时候需要指定对方IP和端口
好处是 不用握手 少了建立连接的延时
应用层协议
运行在不同端系统上的应用进程如何互相交换报文
- 交换的报文类型，请求和应答报文
- 各种报文类型的语法，报文的各个字段的描述
- 字段的语义
- 进程何时发送报文 对报文进行相应
公开协议：
- 允许互操作
- RFC文档定义
- HTTP SMTP
web应用 HTTP协议 Web客户端 HTML
应用层对传输层提供服务的指标
数据丢失率
- 有些应用需要100%可靠传输（文件）
- 有些应用在一定比例的丢失无所谓（直播）
延迟
- 一些应用出于有效性考虑对时间有限制
- 打游戏 电话 上网冲浪
吞吐
安全性
- 机密
- 完整
- 可认证
安全TCP
- TCP & UDP
- 都没有加密
- 明文通过互联网传输，甚至密码
SSL
- 在TCP上面实现，提供加密的TCP连接
- 私密性
- 数据完整性
- 端到端的鉴别
SSL在应用层
- 应用采用SSL库，SSL库使用TCP通信
SSL socket API
- 应用通过API将明文交给socket，SSL将其加密在互联网上传输
Web and Http
HTTP概况
HTTP即Hypertext Transfer Protocol 超文本传输协议
使用TCP
- 客户发起一个与服务器的TCP连接 端口号为80
- 服务器接受客户的TCP连接
- 在浏览器与Web服务器交换HTTP报文
- TCP连接关闭
HTTP是无状态的
服务器并不维护关于客户的任何信息
非持久HTTP
- 最多只有一个对象在TCP连接上发送
- 下载多个对象需要多个TCP链接
- HTTP/1.0使用非持久连接
持久HTTP
多个对象可以在一个TCP链接上传输
HTTP/1.1 默认使用持久HTTP
响应时间模型
往返时间 RTT
一个小的分组从客户端到服务器，再回到客户端的时间
响应时间
- 一个RTT用来发起TCP连接
- 一个RTT用来HTTP请求 等待HTTP响应
- 文件传输时间
$$
2RTT + 传输时间
$$
持久HTTP
非持久HTTP的缺点
每个对象都需要两个RTT
操作系统必须为每个TCP连接分配资源
浏览器通常打开并行TCP连接，以获取引用对象
持久HTTP
- 服务器发送响应后仍保持TCP连接
- 在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送
- 客户端在遇到一个引用对象的时候，就可以尽快发送该对象的请求
非流水方式的持久HTTP
客户端在收到前一个响应后发送新请求
每个引用花费一个RTT
流水方式的持久HTTP（并行处理）
- HTTP/1.1的默认模式
- 客户端遇到一个引用对象就产生一个请求
- 所有引用的对象只花费一个RTT是可能的
HTTP请求报文
HTTP有请求和响应两种格式的报文
提交表单输入
POST
- 网页通常包括表单输入
- 包含在实体主体中的输入被提交到服务器
URL方式
GET
通过请求行的URL进行上载 （就是?xxx=那玩意）
HTTP/1.1
PUT
将实体主题的文件上载到URL规定的路径
DELETE
删除URL规定的文件
其实这俩都可以用POST替代
HTTP响应报文
Cookies
大多数主要的门户网站都使用cookies
- 在HTTP报文中有一个cookies的首部行
- 在HTTP请求报文含有一个cookies的首部行
- 在用户端系统中保留有一个cookies文件 由用户的浏览器管理
- 在Web站点由一个后端数据库
Web缓存
- 缓存既是客户端又是服务器
- 缓存一般由ISP安装
使用Web缓存的好处
- 降低客户端的请求响应时间
- 减少内部接入Internet接入链路的流量
- 采用缓存后较弱的ICP也能有效提供内容
条件GET方法
- 如果缓冲器中的对象拷贝是最新的，就不要发送对象
- 缓冲器 在HTTP请求中指定缓存拷贝日期
- 服务器 如果缓存拷贝陈旧，则响应报文没包含对象
FTP
文件传输协议
向远程主机上传输文件或接受文件
端口号为21
FTP客户端与服务器通过21号端口联系 并使用TCP为传输协议
客户端通过控制连接获得身份确认（账号密码）这玩意比较古老都是明文传输
客户端通过控制连接发送命令浏览远程目录
收到传输命令时 服务器打开一个到客户端的数据连接
一个文件传输完成后服务器关闭连接
服务器打开第二个TCP数据连接用来传输另一个文件
FTP服务器维护用户的状态信息，当前路径 用户账户与控制连接对应
三个主要组成部分
- 用户代理
- 邮件服务器
- 简单邮件传输协议
用户代理
- 撰写编辑阅读邮件
- 比如Outlook
- 输出和输入邮件保存在服务器上
邮件服务器
- 邮箱中管理和维护发给用户的邮件
- 输出报文队列保存待发送邮件
- 邮件服务器之间的SMTP协议发送email报文
- 客户发送邮件
- 接受端邮件服务器
SMTP
交换email报文的协议
- 使用TCP在客户端和服务器之间传送报文
- 端口号为25
- 直接传输从发送方到接收方服务器
- 三个阶段
- 握手
- 传输报文
- 关闭
- 命令 响应
- 命令 ASCII文本
- 响应 状态码和状态信息
- 报文必须为7为ASCII码
邮件服务器有一个队列 会攒一波 定期去发送
SMTP使用持久连接
SMTP 要求报文为7位ASCLII编码
SMTP服务器使用 CRLF CRLF决定报文的尾部
HTTP 拉 pull
SMTP 推 push
两者都是ASCII形式的命令 响应交互
HTTP 每个镀锡那个封装在各自的响应报文中
SMTP 多个对象包含在一个报文中
邮件报文格式
首部行 to
From
Subject
主体 报文只能是ASCII字符
多媒体扩展：
MIME 多媒体邮件扩展
在报文首部用额外行申明MIME的内容类型
使用BASE64编码
Base64 是一种把不在ASCII中的编码改写成ASCII编码的一种格式
SMTP传送到接受方的邮件服务器
邮件访问协议 从服务器访问邮件
POP邮局访问协议
用户身份确认 代理服务器并下载
HTTP：
方便
DNS
IP地址标识主机 路由器
但是IP地址不好记忆 不便于人类使用
人类用户提供要访问机器的字符串名称
由DNS负责转换成为二进制的网络地址
DNS需要解决的问题：
如何命名设备
用有意义的字符串 好记 便于人类使用
剞劂一个平面命名的重名问题 层次化命名
如何完成名字到IP地址的转换
- 分布式的数据库维护和响应名字查询
DNS的总体思路
- 分层的基于域的命名机制
- 若干分布式数据完成名字到IP地址的转换
- 运行在UDP之上端口号为53的应用服务
- 和兴Internet功能 但以应用层协议实现
DNS主要目的
- 实现主机名IP地址的转换
- 其他目的
- 邮件服务器别名到邮件服务器正规名字的转换
- 负载均衡
DNS域名结构
一个层面的命名设备会有很多重名
DNS采用层次树状结构的命名方法
Internet根被分为几百个顶级域
通用的 .com .edu .int .net .orrg
国家的 .cn .us .jp
每个子域下面可花费为若干个子域
树叶是主机
DNS名字空间
域名 从本域往上 直到树根
中间使用“.”间隔不同级别
例如 ustc.edu.cn
域的域名可标识一个域
主机的域名 一个域上的一个主机
域名的管理
一个域管理其下的子域
.jp被划分为 ac.jp co.jp
.cn 被划分为edu.cn com.cn
域与物理网络无关
域遵从组织界限而不是物理网络
一个域的主机可以不在一个网络
一个网路哦哦对主机不一定在一个域
域的划分是逻辑的，而不是物理的
区域
区域的花费由区域管理者自己决定
将DNS名字空间划分为互不相交的区域你没u给区域都是树的一部分
名字服务器
- 每个区域都有一个名字服务器 维护着他所管辖区域的权威信息
- 名字服务允许放置在区域之外 以保证可靠性
TLD服务器
- 顶级域服务器负责顶级域名 比如.com .org .net 和所有国家的域.cn .uk
- Network solutions 公司维护com TLD服务器
- Educause 公司维护edu TLD 服务器
本地名字服务器
- 并不严格属于层次结构
- 每个ISP都有一个本地DNS服务器也称为 默认名字服务器
- 当一个追发起一个DNS查询时查询到其本地DNS服务器
- 起着代理的作用 将查询转发到层次结构中
迭代查询
主机 cis.poly.edu 想知道主机 gaia.cs.umass.edu的IP地址
更服务器返回的不是查询结果而是下个NS的地址
最后由权威名字服务器给出解析结果
当前联络的服务器给出可以联系的服务器的名字
我不知道这个名字 但是可以向则会个服务器请求
DNS协议 报文
DNS协议 查询和响应的报文的报文格式相同
报文首部 标识符 id 16位
flasgs
- 查询 应答
- 希望递归
- 递归可用
- 应答权威
提高性能 缓存
一旦名字服务器 学到了一个映射就将该映射缓存起来
更服务器通常都在本地服务器中缓存着
- 使得根服务器 不用经常被访问
目的 提高效率
可能存在的问题 如果情况变化 缓存结果和权威资源记录不一致
解决方法 TTL（默认两天）
新增一个域
- 在上级域的名字服务器加两条记录 指向这个域 和域名服务器地址
- 在新增子域的名字服务器上运行名字服务器 负责本域名字解析 名字->IP
P2P应用
没有或极少一直运行的服务器
任意端之间可直接通信
Peer节点间歇上网 每次IP地址都有可能变化
- 文件分发
- 流媒体
- VOIP
C/S模式
- 服务器传输 都是由服务器发送给peer 服务器必须顺序传输N个文件拷贝
客户端必须下载一个文件拷贝
$d_{min}$ = 客户端最小的下载速率
下载代开你最小的客户端下载的时间： F/$d_{min}$
采用C-S方法将一个F大小的文件分发给N个客户端耗时
$$
D_{C-S}>max{NF/U_{s}},F/d_{min}
$$
P2P模式
服务器传输： 最少需要上载一份拷贝
- 发送一个拷贝的时间 F/us
客户端 每个客户端必须下载一个拷贝
所有客户端总体下载量NF
- 最大上载带宽是u + $\sum u$
- 除了服务器可以上载 其他所有的peer节点都可以上载
P2P系统与客户端服务器模式不同的是随着请求数量的增加 提供服务的人也增加 性能高 并且可扩展性好
CDN
Content Distribution Networks（内容分发网络）
流化播放 边下边看（有缓存）减少带宽和等待时间
多媒体流化服务 DASH
服务器：
- 将视频文件分割成多个块
- 每个块独立存储，编码与不同码率
- 告示文件： 提供不同的URL
客户端
- 先获取告示文件
- 周期性的测量服务器到客户端的带宽
- 查询告示文件在一个时刻请求一个块 HTTP指定直接范围
- 如果带宽够请求最大码率
- 不同时刻请求不同的编码块
- 智能客户端 动态的决定请求什么视频块
通过CDN 全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验 俗称内容加速服务
enter deep 将CDN服务器深度到接入网
- 更接近用户 数量多，离用户近
- Akamai 1700个位置
bring home 部署在关键位置
- 采用租用线路将服务器连接
TCP
Socket编程
UDP
传输层
传输服务和协议
为用韵在不同主机上的应用进程提供逻辑通信
传输协议运行在端系统
- 发送方将应用层报文分为报文段，然后传递给网络层
- 接收方 将报文段重组成报文 然后传递给应用层
有多个传输层协议可供应用选择：
TCP UDP
网络层提供主机间的逻辑通信
传输层提供进程间的逻辑通信
- 依赖网络层的服务器
- 对网络层的服务进行增强
+++
多路复用和解复用
- 解复用作用： TCP或者UDP实体采用那些信息，将报文段数据部分交给正确的socket 从而交给正确的进程
- 主机收到IP数据报
- 每个数据报有源IP地址和目标地址
- 每个数据报承载一个传输层报文段
- 每个报文段有一个源端口号和目标端口号
- 主机使用IP地址和端口号将报文发送给合适的套接字
无连接传输UDP
UDP socket 没有目标IP和端口
因此每次传输数据的时候需要指定对方IP和端口
好处是 不用握手 少了建立连接的延时
UDP校验和
发送方
- 将报文的内容视为16比特的整数
- 校验和： 报文段的加法和（1的补运算）
- 发送方将校验和放在UDP的校验和字段
接受方：
计算收到的报文段的校验和
检查计算出的校验和与检验的字段内容是否相等
- 不相等 检查到差错
- 相等 没有检查出差错 但是可能还有差错
对两个16bit相加后取反码运算 将其加起来（1变0 0变1）如果溢出就回卷（把溢出位加到最后一位）如果分组没有差错结果应该是16个1
可靠传输的原理
底层的IP协议是不可靠，而实现在不可靠的基础上实现可靠，就是可靠传输 比如TCP
不可靠信道的传输
rdt2.0
就像打电话一样 对方如果和你说一个事情 你听懂了 你就和他说 好 行（肯定确认） 如果你听不懂对方的话 那你就可以要求其给你重新说一遍（否定确认）
这就是自动请求重传协议 ARQ
ARQ需要差错检测 接收方反馈 重传来实现
但是实际上 肯定确认和否定确认也有可能没有成功传输
一个解决办法是当手段哦哦含糊不清的 确认时重新传输当前的数据即可，但是这样可能会造成冗余，因此TCP在数据分组上添加了序号 这样就知道数据有没有被重传。
但是实际上底层的网络层可能也会出现丢包 双方都接受不到对方的消息造成死锁
所以引入一个超时重传机制 发送方如果长时间没有收到ACK那么就重传
需要一个倒计时定时器
rdt3.0的可靠性很好，但是性能并不好 因为他是一个停等协议 当链路比较长的时候，发送方只有很少的时间在工作，这使得效率十分堪忧
流水线协议
流水线：允许发送方在未得到对方确认的情况下一次发送多个分组
- 必须增加序号的范围 用多个bit表示分组的序号
- 在发送方接收方要有缓存区
发送方的缓冲区用于超时重发 接收方的缓冲区是因为发送方发送的速度和接收方提取的速率是不一样的因此需要一个缓存来抵消这种不一致
滑动窗口协议
- 发送缓冲区
- 内存中的一个区域，，落入缓冲区的分组可以发送
- 用于存放已发送，但是没有得到确认的分组
- 需要重发时可用
- 发送缓冲区的大小:一次最多可以发送多少个未经确认的分组
- 停止等待协议=1
- 流水线协议>1，合理的值，不能很大，链路利用率不能够超100%口发送缓冲区中的分组
- 未发送的:落入发送缓冲区的分组，可以连续发送出去;
- 发送缓冲区中的分组
- 未发送的:落入发送缓冲区的分组，可以连续发送出去;
- 已经发送出去的、等待对方确认的分组:发送缓冲区的分组只有得到确认才能删除
和滑动窗口一样 只不过这是一个循环队列 每当发送一个右指针向前 当接受到对方返回的ask的时候左指针向前
GBN
只发送ACK 对顺序接受最高序号的分组
- 可能会产生重复的ACK
对乱序的分组
- 丢弃
- 对顺序接受的最高序号进行确认累积
选择重传：
面向传输的连接TCP
- 点对点:
- 一个发送方，一个接收方
- 可靠的、按顺序的字节流
- 没有报文边界
- 管道化(流水线):
- TCP拥塞控制和流量控制设置窗口大小
- 全双工数据:
- 在同一连接中数据流双向流动
- MSS最大报文段大小
- 发送和接收缓存
- 面向连接
- 在数据交换之前，通过握手初始化发送方和接收方的状态变量
- 有流量控制
- 发送方不会淹没接收方·0
TCP报文段结构
序号
- 报文段首字节的在字节流的编号（从多少开始发 ）
确认号
- 期望从另一方收到的下一个字节的序号（比如说55意思是55之前的我已经收到了希望你从55及之后开始发）
- 累计确认
往返延迟和超时
- 比RTT要长
SampleRTT 测量报文段发出到收到确认的时间
如果有重传 忽略这次测量
SampleRTT会变化 因此估计的RTT应该比较平滑
- 对最近的几个测量值求平均 而不是用当前的SampleRTT
$$
EstimatedRTT=(1-a)EstimatedRTT+asampleRTT
$$
- 指数加权移动平均
- 过去样本的影响呈指数衰减
- 推荐值:a =0.125
因此公式变为
$$
EstimatedRTT=0.875EstimatedRTT + 0.125sampleRTT
$$
EstimtedRTT+安全边界时间
- EstimatedRTT变化大(方差大)→较大的安全边界时间
SampleRTT会偏离EstimatedRTT多远:
$$
DevRTT =(1-β)DevRTT +β|SampleRTT-EstimatedRTT|
$$推荐值 = $β$ = 0.25
超时时间间隔设置为:
$$
TimeoutInterval=EstimatedRTT +4*DevRTT
$$
可靠数据传输
快速重传：
如果在超时重传定时器溢出之前，接收到连续的三个重复冗余ACK（其实是收到4个同样的ACK，第一个是正常的，后三个才是冗余的），发送端便知晓哪个报文段在传输过程中丢失了，于是重发该报文段，不需要等待超时重传定时器溢出，大大提高了效率。这便是快速重传机制。
快速重传机制是GBN和SR协议的混合体
流量控制
通信双方各声明一个窗口（缓存大小），标识自己当前能够的处理能力
接收方控制发送方发，不让发送的太多、太快以至于让接收方的缓冲区溢出
缓存中的可用的空间
$$
=RcvBuffer-[LastByteRcvd-astByteRead]
$$
TCP连接管理
在正式交换数据之前，发送方和接收方握手建立通信关系：
- 同意建立连接
- 同意连接参数
Q:在网络中，2次握手建立连接总是可行吗?
- 变化的延迟(连接请求的段没有丢，但可能超时)
- 由于丢失造成的重传(e.9greq_conn(x))
- 报文乱序
- 相互看不到对方
导致服务器维护了大量的虚假的半连接 每次建立连接都要开辟一片缓存区域 长此以往使得资源耗尽
TCP三次握手
TCP 三次握手过程是怎样的？
TCP 是面向连接的协议，所以使用 TCP 前必须先建立连接，而建立连接是通过三次握手来进行的。三次握手的过程如下图：
- 一开始，客户端和服务端都处于
CLOSE状态。先是服务端主动监听某个端口，处于LISTEN状态
- 客户端会随机初始化序号（
client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把SYN标志位置为1，表示SYN报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于SYN-SENT状态。
- 服务端收到客户端的
SYN报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入client_isn + 1, 接着把SYN和ACK标志位置为1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于SYN-RCVD状态。
- 客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部
ACK标志位置为1，其次「确认应答号」字段填入server_isn + 1，最后把报文发送给服务端，这次报文可以携带客户到服务端的数据，之后客户端处于ESTABLISHED状态。 - 服务端收到客户端的应答报文后，也进入
ESTABLISHED状态。
从上面的过程可以发现第三次握手是可以携带数据的，前两次握手是不可以携带数据的，这也是面试常问的题。
一旦完成三次握手，双方都处于 ESTABLISHED 状态，此时连接就已建立完成，客户端和服务端就可以相互发送数据了
TCP 关闭连接
- 客户端，服务器分别关闭它自己这一侧的连接·发送FIN bit=1的TCP段
- 一旦接收到FIN，用ACK回应接到FIN段，ACK可以和它自己发出的FIN段一起发送
- 可以处理同时的FIN交换
双方都可以主动断开连接，断开连接后主机中的「资源」将被释放，四次挥手的过程如下图：
- 客户端打算关闭连接，此时会发送一个 TCP 首部
FIN标志位被置为1的报文，也即FIN报文，之后客户端进入FIN_WAIT_1状态。 - 服务端收到该报文后，就向客户端发送
ACK应答报文，接着服务端进入CLOSE_WAIT状态。 - 客户端收到服务端的
ACK应答报文后，之后进入FIN_WAIT_2状态。 - 等待服务端处理完数据后，也向客户端发送
FIN报文，之后服务端进入LAST_ACK状态。 - 客户端收到服务端的
FIN报文后，回一个ACK应答报文，之后进入TIME_WAIT状态 - 服务端收到了
ACK应答报文后，就进入了CLOSE状态，至此服务端已经完成连接的关闭。 - 客户端在经过
2MSL一段时间后，自动进入CLOSE状态，至此客户端也完成连接的关闭。
你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。
这里一点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态。
为什么挥手需要四次？
再来回顾下四次挥手双方发 FIN 包的过程，就能理解为什么需要四次了。
- 关闭连接时，客户端向服务端发送
FIN时，仅仅表示客户端不再发送数据了但是还能接收数据。 - 服务端收到客户端的
FIN报文时，先回一个ACK应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送FIN报文给客户端来表示同意现在关闭连接。
从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，因此是需要四次挥手。
拥塞控制原理
为什么有了流量控制还要有拥塞控制
在网络出现拥堵时，如果继续发送大量数据包，可能会导致数据包时延、丢失等，这时 TCP 就会重传数据，但是一重传就会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这个情况就会进入恶性循环被不断地放大….
所以，TCP 不能忽略网络上发生的事，它被设计成一个无私的协议，当网络发送拥塞时，TCP 会自我牺牲，降低发送的数据量。
于是，就有了拥塞控制，控制的目的就是避免「发送方」的数据填满整个网络。
为了在「发送方」调节所要发送数据的量，定义了一个叫做「拥塞窗口」的概念。
拥塞窗口 cwnd是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的。
我们在前面提到过发送窗口 swnd 和接收窗口 rwnd 是约等于的关系，那么由于加入了拥塞窗口的概念后，此时发送窗口的值是swnd = min(cwnd, rwnd)，也就是拥塞窗口和接收窗口中的最小值。
拥塞窗口 cwnd 变化的规则：
- 只要网络中没有出现拥塞，
cwnd就会增大； - 但网络中出现了拥塞，
cwnd就减少；
只要「发送方」没有在规定时间内接收到 ACK 应答报文，也就是发生了超时重传，就会认为网络出现了拥塞。
拥塞控制方法·
- 慢启动
- 拥塞避免
- 拥塞发生
- 快速恢复
慢启动
TCP 在刚建立连接完成后，首先是有个慢启动的过程，这个慢启动的意思就是一点一点的提高发送数据包的数量
慢启动的算法 ：当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1。
这里假定拥塞窗口 cwnd 和发送窗口 swnd 相等，下面举个栗子：
- 连接建立完成后，一开始初始化
cwnd = 1，表示可以传一个MSS大小的数据。 - 当收到一个 ACK 确认应答后，cwnd 增加 1，于是一次能够发送 2 个
- 当收到 2 个的 ACK 确认应答后， cwnd 增加 2，于是就可以比之前多发2 个，所以这一次能够发送 4 个
- 当这 4 个的 ACK 确认到来的时候，每个确认 cwnd 增加 1， 4 个确认 cwnd 增加 4，于是就可以比之前多发 4 个，所以这一次能够发送 8 个。
可以看出慢启动算法，发包的个数是指数性的增长。
那慢启动涨到什么时候是个头呢？
有一个叫慢启动门限 ssthresh （slow start threshold）状态变量。
- 当
cwnd<ssthresh时，使用慢启动算法。 - 当
cwnd>=ssthresh时，就会使用「拥塞避免算法」。
拥塞避免算法
当拥塞窗口 cwnd 「超过」慢启动门限 ssthresh 就会进入拥塞避免算法。
一般来说 ssthresh 的大小是 65535 字节。
那么进入拥塞避免算法后，它的规则是：每当收到一个 ACK 时，cwnd 增加 1/cwnd。
接上前面的慢启动的栗子，现假定 ssthresh 为 8：
- 当 8 个 ACK 应答确认到来时，每个确认增加 1/8，8 个 ACK 确认 cwnd 一共增加 1，于是这一次能够发送 9 个
MSS大小的数据，变成了线性增长。 
拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长，还是增长阶段，但是增长速度缓慢了一些。
就这么一直增长着后，网络就会慢慢进入了拥塞的状况了，于是就会出现丢包现象，这时就需要对丢失的数据包进行重传。
当触发了重传机制，也就进入了「拥塞发生算法」。
拥塞发生
当网络出现拥塞，也就是会发生数据包重传，重传机制主要有两种：
- 超时重传
- 快速重传
当发生了「超时重传」，则就会使用拥塞发生算法。
这个时候，ssthresh 和 cwnd 的值会发生变化：
ssthresh设为cwnd/2，cwnd重置为1（是恢复为 cwnd 初始化值，我这里假定 cwnd 初始化值 1）
接着，就重新开始慢启动，慢启动是会突然减少数据流的。这真是一旦「超时重传」，马上回到解放前。但是这种方式太激进了，反应也很强烈，会造成网络卡顿。
就好像本来在秋名山高速漂移着，突然来个紧急刹车，轮胎受得了吗。。。
发生快速重传的拥塞发生算法
还有更好的方式，前面我们讲过「快速重传算法」。当接收方发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。
TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分，则 ssthresh 和 cwnd 变化如下：
cwnd = cwnd/2，也就是设置为原来的一半;ssthresh = cwnd;- 进入快速恢复算法
快速恢复
快速重传和快速恢复算法一般同时使用，快速恢复算法是认为，你还能收到 3 个重复 ACK 说明网络也不那么糟糕，所以没有必要像 RTO 超时那么强烈。
正如前面所说，进入快速恢复之前，cwnd 和 ssthresh 已被更新了：
cwnd = cwnd/2，也就是设置为原来的一半;ssthresh = cwnd;
然后，进入快速恢复算法如下：
- 拥塞窗口
cwnd = ssthresh + 3（ 3 的意思是确认有 3 个数据包被收到了）； - 重传丢失的数据包；
- 如果再收到重复的 ACK，那么 cwnd 增加 1；
- 如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态；
TCP拥塞
网络层：数据平面
网络层的服务
- 在发送主机和接收主机对之间传送段(segment)
- 在发送端将段封装到数据报中
- 在接收端，将段上交给传输层实体
- 网络层协议存在于每一个主机和路由器
- 路由器检查每一个经过它的IP数据报的头部
网络层的功能
- 转发：将分组从路由器的输入接口转发到合适的输出接口
- 路由： 使用路由算法来决定分组从发送主机到目标接受主机的路径
转发是单个路口的过程
路由是源目标到目的的路径规划的过程
其实好像就算是 控制平面是网络层做的事情 数据平面是网络层的功能
数据平面：
- 本地，每个路由器功能
- 决定从路由器输入端口到达的分组如何转发到输出端口
- 转发功能：
- 传统方式基于目标地址和转发表
- SDN方式 基于多个字段+流表
SDN其实可以理解为有一大堆机器算路由表 然后分发给路由器把控制平面从路由器剥离出来 达到解耦合的目的
控制平面
网络范围内的逻辑
决定数据报如何在路由器之间路由，决定数据报从源到目标主机之间的端到端路径”
2个控制平面方法:
传统的路由算法:在路由器中被实现
software-definednetworking(SDN):在远程的服务器中实现
连接建立
在某些网络架构中是第三个重要的功能O ATM, frame relay,X.25在分组传输之前，在两个主机之间，在通过一些路由器所构成的路径上建立一个网络层连接
- 涉及到路由器
网络层和传输层连接服务区别:
- 网络层:在2个主机之间，涉及到路径上的一些路由器
- 传输层:在2个进程之间，很可能只体现在端系统上(TCP连接)
+++
路由器组成
IP internet Protocol
通用转发SDN
网络层：控制平面
+++
路由选择算法
自治系统内部的路由选择
ISP之间的路由选择 BGP
SDN控制平面
数据链路层和局域网
+++
差错检测和纠正
多点访协议
LANs
网络安全
+++
加密原理
认证
报文完整性
密钥分发和证书
各个层次的安全性
防火墙
攻击和对策
无线和移动网络
+++
软件定义网络
命名数据网络
多媒体网络
TODO：
