01-计算机网络基础
01-计算机网络基础
计算机网络（mooc）
1. 计算机网络概述
1.1 计算机网络基本概念
-
什么是计算机网络
-
计算机网络是通信技术和计算机技术紧密结合的产物
-
传统通信系统模型
-
定义
-
计算机网络就是互连的，自治的计算机集合
-
自治：无主从关系
-
互连：互联互通
- 通过物理介质
-
-
-
如果有大量且距离远的计算机该怎么组成计算机网络呢？
-
什么是Internet？
-
从组成细节角度
-
-
计算机设备集合
-
主机hosts运行各种网络应用
- pc
- 手机
- laptop
- 服务器
-
-
通信链路
- 光纤
- 无线电
- 卫星
-
分组交换
- 路由器（routers）
- 交换机（switches）
-
-
从服务角度
- 为网络应用提供基础设施
- 为网络应用提供接口接入互联网
-
-
-
什么是网络协议
-
仅仅有硬件连接，能保证数据有序交付吗？
- NO，需要协议，仅有硬件（主机，通信链路）等只是计算机网络的基础，类比交通系统，硬件仅仅是汽车和道路，但仍然需要交通法规来保障交通正常有序的运行，交通法规就是协议
-
定义
- 是为了进行网络中数据交换而简历的规则标注或约定，约定了通信实体之间所交换的信息的格式，意义，顺序以及针对收到信息或发生的时间所采取的“动作”
-
协议的三要素
-
语法
- 数据与控制信息的结构或者格式
-
语义
- 需要发出何种控制信息
- 完成何种动作以及做出何种响应
-
时序
- 事件顺序
- 双方速度匹配
-
-
特点
- 学习计算机网络的重要形式
- 网络创新的表现形式
-
1.2 计算机网络结构
-
结构划分
-
网络边缘
- 主机
- 网络应用
-
接入网络，物理介质
- 有线无线介质，通信链路
-
网络核心
- 互联的路由器
-
-
网络边缘
-
特点
- 位于网络边缘
- 运行网络应用程序
-
通信方式
-
客户/服务器应用模型（C/S）
- 客户发送请求，接受服务器响应
-
对等（peer-peer，P2P）
- 无专用服务器
- 通信在对等实体中进行qq,BT
-
-
-
接入网络
-
解决的问题
- 如何把网络边缘接入核心网（核心网的边缘路由器，从上面的图可以知道核心网络也是有边缘路由器的）？
-
分类
- 住宅
- 结构公司
-
用户关心
-
带宽（bps）
- 每秒传输多少bit数据
-
接入方式
- 独占/共享
-
-
实例
-
DSL数字用户线路
- 利用已有电话线来接入Internet，用到了频分多路复用技术
-
-
-
网络核心
-
解决的基本问题：如何实现数据从发送端通过网络核心到达接收端？
- 数据交换
-
关键功能
-
路由
- 确定数据从发送端到接受端的传输路径
-
转发
- 将数据从路由器的输入端口交换至正确的输出端口
-
-
-
internet结构
-
几百万的ISP是如何互连到一起的呢？
-
直接互连
- 不适用于大规模网络
-
构建多个大型的ISP
-
-
1.3 网络核心
-
数据交换
-
为什么需要数据交换？
- 主机之间需要通信，而数据交换就是将数据一级级往下传递，如果直连方式，会有N^2的链路问题，所以采用类似ISP功能的交换网络来连通多个主机
-
分类
-
电路交换
-
典型实例
- 电话网络
-
三个阶段
- 建立连接
- 进行通信
- 释放连接
-
特点
-
独占资源
-
-
多路复用技术
-
-
典型多路复用方法
-
频分多路复用（Frequency division multiplexing，FDM）
- 各用户占用不同的带宽资源（此处的带宽是指Hz，而不是bps）
- 用户在分配到一定的带宽后，在通信过程中始终会占用这个频带
-
时分多路复用（Time division multiplexing，TDM）
- 将时间会分为一段段等长的时分复用帧（TDM帧，是一个时间段），每个用户占用TDM帧中的固定序号的时隙
-
波分多路复用（Waelenght division multiplexing，WDM）
- 实际上就是频分复用，只不过在光通信中成为波分复用
-
码分多路复用（Code division multiplexing，CDM）
- 防范应用于无线链路，蜂窝网，卫星通信
- 每个用户分配一个唯一的m bit的码片序列，如01011100，然后使用自己码片来编码数据，各个用户的码片是正交的，所以不会出现信息安全问题
-
-
-
-
报文交换
-
报文
- 发送端发送信息的整体
-
定义
- 就是把整个报文一级级往下传递，直到接收端
-
-
分组交换
-
分组
- 把报文拆分成多个小的数据报，并在小的数据包前加上一些控制信息来保证数据包的发送数序和重组为报文
-
好处
- 可以实现并行传输数据，而报文数据只能串行传输数据
-
-
-
分组交换与报文交换的比较
- 可以实现并行传输数据，而报文数据只能串行传输数据
-
分组交换和电路交换
-
分组交换
-
优点
- 分组交换使网络资源利用率最大化，更适用于突发（随机）数据传输网络，简单无需呼叫连接
-
缺点
-
产生拥塞
- 分组延迟和丢失，需要协议来处理考考数据传输和拥塞色控制
-
-
-
-
1.4 计算机的网络性能
-
速率（数据率，数据传输速率，比特率,bit rate）
-
都是只理想情况下的额定速率或者标称速率
-
单位
- b/s（bps）,kb/s,Mb/s,Gb/s
-
-
带宽
-
通信原意
- 信号具有的频带宽度
-
计网里是指数字信道所能传达的最高数据率，单位:b/s(bps)
-
-
延迟（时延）
-
问题
-
-
时延
- 传输时延
- 排队等待发送的时延
-
丢包
- 如果路由器缓存满的时候，再来的数据包就会被直接丢弃，造成丢包
-
-
-
四组分组时延（一跳，是两个点直接对发，而不是整个通信链路要经过很多路由器这种）
-
结点处理延迟（nodal processing delay）
- 差错检测
- 确定输出链路
- 所需时间通常小于毫秒级
-
排队延迟（queueing delay）
-
等待输出链路可用
-
所需时间取决于路由器的拥塞程度
-
流量强度
- （链路带宽R*分组长度L）/平均分组到达速率a
- 接近0，延迟很低
- 接近1，延迟很大
-
-
-
传输延迟(transmission delay)
- 分组长度L
- 链路贷款R
- 所需时间L/R
-
传播延迟（propagation dealy，物理特性）
- 物理链路长度
- 信号本身的传送速度
- 所需时间d/s
-
-
-
时延带宽积
-
时延带宽积 = 传播时延 X 带宽，单位bit
- 故称为以bit为单位的链路长度，即为这一个物理炼炉中可以塞下多少个bit
-
-
丢包
-
队列缓存容量有限，后发的数据包被丢弃，可能重发也可能不重发数据包
-
丢包率
- 丢包率 = 丢包数/已发分组数
-
-
吞吐率
- 木桶短木板效应
1.5 计算机网络体系机构
-
计算机网络体系机构概述
-
为什么提出计算机网络结构？
- 十分复杂的系统，需要一个结构来让我们理解网络结构，从功能上描述网络体系结构，是抽象的，物理实现先不管
-
概念
- 计算机网络体系结构简称网络体系结构，是一个分层结构，每一层需要遵循网络协议完成本层的功能，计算机网络体系结构就是计算机网络的各层及其协议的集合
-
为什么采用分层结构
-
优点
- 层次清晰
- 模块化，抑郁更新和维护
- 有利于标准化
-
缺点
- 层次越多，效率越低
-
-
基本概念
-
-
实体（entity）
- 表示任何可发送或接收信息的硬件或软件进程
-
协议
- 是控制两个对等（相同层次）实体进行通信的规则的集合，协议是“水平”的
-
服务
- 任一层实体需要使用下层服务，遵循本层的协议，实现本层的功能，向上层提供服务，服务是垂直的
-
透明
- 下层协议的实现对于上层用户是透明的
-
原语
- 同系统的相邻层次的实体通过接口进行交互，通过服务访问点（Service Access Point，SAP），交换源于，指定特定服务
-
-
-
OSI参考模型
-
目的
- 支持异构网络系统的互联互通，当时历史原因各个公司网络都是各有各的网络模型
-
分层
-
- 应用层（Application）
-
- 表示层（Presentation）
-
- 会话层（Session）
-
- 传输层（Transport）
-
- 网络层（Network）
-
- 数据链路层（Datalink）
-
- 物理层（Physical）
-
-
OSI实例
-
从物理角度
-
-
端到端
-
指的是在数据传输之前，在发送端与接收端之间（忽略中间有多少设备）为数据的传输建立一条链路，链路建立以后，发送端就可以发送数据，知道数据发送完毕，接收端确认接收成功。 也就是说在数据传输之前，先为数据的传输开辟一条通道，然后在进行传输。从发送端发出数据到接收端接收完毕，结束。
-
我的理解
- 端到端注重主机与主机的数据传输，而不考虑底层的实现，是对底层的抽象，将底层透明化，是以点对点为基础的
-
-
-
点对点
-
点到点通信是针对数据链路层或网络层来说的，点对点是基于MAC地址和或者IP地址，是指一个设备发数据给与该这边直接连接的其他设备，这台设备又在合适的时候将数据传递给与它相连的下一个设备，通过一台一台直接相连的设备把数据传递到接收端。
-
我的理解
- 点到点注重节点到节点的数据传输，考虑数据传输在底层是怎么实现运作的
-
-
-
在一个网络系统的不同分层中，可能用到端到端传输，也可能用到点到点传输。如Internet网，IP及以下各层采用点到点传输，4层以上采用端到端传输。
-
-
从协议角度
-
-
具体分析
-
非端到端层次
-
物理层
-
功能
- 解决了单一bit的传输问题
-
接口特性
- 机械特性（接口形状）
- 电气特性（电压）
- 功能特性（引脚）
- 规程特性（接口的通信过程，哪个引脚先给信号，哪个引脚再给信号）
-
比特编码
- 调制技术，什么时候0，什么时候1
-
数据率
- 介质和通信系统有关系
-
比特同步
- 发送一个bit的同时接收一个bit
-
传输模式
- 单工
- 半双工
- 全双工
-
-
数据链路层
-
引入
- 物理层虽然解决了单个bit如何传输，但是这些数据应该发送给谁？数据出错怎么纠正？
-
功能
- 指定谁来接收数据（物理寻址），两个由物理链路直接相连的节点之间的数据传输
- 数据发生错误怎么纠正（组帧）
-
解决的问题
-
组帧
- 把网络层发过来的数据加头加尾组成帧，传给物理层，便于接收端根据头尾切分帧
-
物理寻址
-
在帧头出增加发送端和或接收端的物理地址来标识谁是发送端，谁是接收端
-
既然数据链路解决的就是物理链路直接相连的两个节点，直接发布就行了嘛，为什么需要发送端和接收端的物理地址呢？
-
-
流量控制
- 匹配发送端的发送速度和接收端的接收速度，避免淹没接收端（二者速度相一致）
-
差错控制
- 根据相关算法检测损坏或者丢失的帧，并且避免重复帧
-
访问（接入）控制
- 在任意时间决定当前物理链路由谁来使用
-
-
-
网络层
-
引入
- 数据链路层解决了两个物理链路直接相连的节点，那么如果需要经过多个节点呢，跨越多个网络？
-
概念
- 负责源主机到目的主机的数据分组交付
-
功能
-
逻辑寻址
-
引入
- 因为要跨过多个网络，数据链路层的物理地址显然是只适用于局部，而不适用于全局网络
-
概念
- 全局唯一逻辑地址，确保数据能够正确送达目的主机，如ip地址
-
-
路由
- 路径选择，由路由器进行分组发送，直到最后的目的主机
-
分组转发
-
-
-
-
端到端层次
-
传输层
-
引入
-
功能
-
分段和重组
- 发送端分段，接收端重组
-
SAP寻址
-
连接控制
- 不同于电路交换里的连接控制，这是一个逻辑上的连接
-
流量控制
-
差错控制
- 从端角度来进行差错控制
-
-
-
会话层
-
引入
- 接收表示层报文，在报文中添加控制信号，然后传给传输层
-
功能
-
对话控制
- 建立，维护，删除
-
同步
- 如果会话意外中断了，只需要恢复最近的一个同步点
-
-
实际中包含在应用层
-
-
表示层
-
引入
-
处理两个系统之间交换信息的语法和语义（两个不同的计算机系统数据的表示是不一样的）
-
功能
-
数据表示转化
- 转化为与各个主机系统无关的编码
-
加/解密
-
压缩/解压
-
子主题 4
-
-
实际中包含在应用层
-
-
应用层
-
引入
- 不同的网络应用遵从不同的协议，HTTP,FTP,SMTP，支持用户通过用户代理（浏览器等）使用服务
-
-
-
-
-
TCP/IP
-
-
分层
- 应用层
- 运输层
- 网际层
- 网络接口层
-
-
五层参考模型
-
引入
-
分层
-
应用层
- 支持各种网络应用，协议：FTP,SMTP,HTTP
-
传输层
- 进程-进程的数据传输，协议：TCP,UDP
-
网络层
- 源主机到目的主机的数据分组路由与转发，协议：IP协议，路由协议
-
数据链路层
- 相邻网络元素（主机，交换机，路由器）的数据传输，协议：以太网，802.11（WIFI），PPP
-
物理层
- bit传输
-
-
2. 应用层
2.1 网络应用概述
-
网络应用体系结构
- 客户端/服务器模型
- P2P
- 混合结构
-
网络应用的服务需求
- 可靠性
- 带宽
- 时延
-
Internet传输层服务模型
- TCP
- UDP
-
特定网络应用及协议
- HTTP
- SMTP,POP,IMAP
- DNS
- P2P
-
Socket编程
- TCP
- UDP
2.2 网络应用的基本原理
-
网络应用的体系结构
-
引入
-
网络应用的特点
- 需要客户端，服务器端
- 有网络环境
-
-
结构
-
客户机/服务器结构（Client-Server,C/S）
-
服务器
- 24小时对外提供服务
- 永久性访问地址/域名
- 利用大量服务器实现可拓展性
-
客户机
- 使用服务器提供的服务
- 可以使用动态IP地址，
- 不会与其他客户机进行数据传输
- 节点间接性接入网络
-
例子
- Web应用
-
-
点对点结构（Peer-Peer,P2P）
-
特点
- 没有永久在线服务器
- 任意节点直接都可以通信
- 节点间接性接入网络
- 节点可能改变IP地址
-
例子
- 文件共享服务，FTP
-
-
混合结构（Hyber）
-
例子
-
Napster
- 文件传输使用P2P
- 文件搜索访问服务器
-
-
-
-
-
网络应用进程通信
-
同一个主机上的进程通信在操作系统中有所解释
-
不同主机的进程通信是通过信息交换，通过socket
-
信息交换
-
Socket
-
如何寻址进程
- 不同主机的进程之间通信，每个进程必须有标识符，IP:端口号
-
-
应用层协议
-
引入
- 信息交换通过Socket来实现，那么消息本身的格式需要遵循什么样的格式
-
协议的内容
-
消息的类型（type）
- 请求消息
- 响应消息
-
消息的语法（syntax）/格式
- 消息中有哪些字段（field）
- 每个字段是怎么描述的
-
字段的语义（semantics）
- 字段中信息的含义
-
规则（rules）
- 进程何时发送/响应消息
-
-
-
-
网络应用的需求和传输层服务
-
需求
-
可靠性
- 网络电话可以容忍一定数据的丢失
- 文件传输不能丢失一个bit
-
延迟
- 网络游戏，网络电话
-
带宽
- 网络视频要求带宽bps高
- email可以适应任何带宽
-
安全
-
。。。
-
-
Internet（很多网络的一种）提供的服务
-
TCP
- 客户机服务器进程需要建立连接
- 可靠
- 发送方不会发送过快而超过接收方的接收能力
- 当网络负载过重的时候能够限制发送方的发送速度
- 不提供
- 不提供
-
UDP
- 不需要建立连接
- 不可靠
- 不提供
- 不提供
- 不提供
- 不提供
-
-
2.3 WEB应用
-
WEB与HTTP
-
WEB
-
world wide web
-
网页
-
包含多个对象
- HTML
- 图片
- 视频
- 动态脚本
-
url(统一资源定位器)
- 多个对象就需要寻址
- Scheme://hostport/path
-
-
网页相互连接
-
-
-
HTTP协议
-
应用采用C/S结构
-
客户机brower
- 请求
- 接收
- 展示web对象
-
服务器web server
- 响应客户端请求
- 发送对象
-
-
采用的传输层协议
-
TCP
- 服务器在80端口等待客户端请求
- 浏览器发起服务器的TCP连接（创建socket）
- 服务器接收浏览器的TCP连接
- 浏览器与服务器交换HTTP信息
- 关闭TCP连接
-
交互模式
- 请求/响应
-
-
HTTP是无状态协议
- 服务器不维护有关客户端过去所发送的请求
-
-
-
HTTP连接类型
-
非持久性连接(HTTP1.0)
-
每个TCP连接最多允许传输一个对象
-
例子
-
-
响应时间分析
-
名词
-
RTT（round trip time）
- 从客户端发送一个很小的数据包到服务器并从服务器返回至客户端所经历的时间
-
-
响应时间
-
-
发起建立TCP连接
- 1RTT
-
发送HTTP请求到HTTP响应消息的前几个字节到达
- 1RTT
-
响应消息中的文件传输时间
- 文件传输时间
-
总时间
- total=2RTT+文件传输时间
-
-
-
-
问题
- 每个对象需要2个RTT
- 操作系统需要为每个TCP连接开销资源
- 浏览器可能会同时并行多个TCP连接，造成服务器压力
-
-
持久性连接(HTTP1.1)
-
引入
- 非持久性连接的问题
-
每个TCP连接可以传输多个对象
-
分类
-
无流水的持久性连接
- 客户端只有在收到前一个响应的时候才发送新的请求连接
- 每个被引用的对象耗时1个RTT
-
带有流水机制的持久性连接
- HTTP1.1的默认选项
- 客户端只要遇到一个引用对象久尽快发送请求
- 理想情况下，收到所有对象耗时1个RTT
-
-
-
-
HTTP消息格式
-
两类消息
-
HTTP请求消息
-
-
request
-
请求行
-
组成
-
请求方式
-
GET
- 请求参数位于GET请求行中的url中
- 请求url长度有限制
- 不太安全
-
POST
- 请求参数在请求体中
- 请求的url长度没有限制（可以上传文件）
- 相对安全
-
。。。一共有七种
-
-
请求url
- /api/b/v1/billing_management/export_fee_details
-
请求协议/版本
- HTTP/1.1
-
-
示例
- GET /api/b/v1/billing_management/export_fee_details HTTP/1.1
-
-
请求头
-
作用
- 客户端告诉服务器的一些信息
-
组成
-
请求头名称：请求头值（请求头包括很多请求头名称）
-
常见请求头名称
-
User-Agent
- 浏览器告诉服务器，我访问你使用的浏览器版本信息，服务器获取该请求头的信息，解决浏览器的兼容性问题
-
Referer
- 告诉服务器当前请求从哪里来的，可以防止盗链，也可以用作统计工作
-
Accept
- 告诉服务器客户端接受的文本类型
-
Accept-Language
- 告诉服务器客户端可以接受的语言
-
Accept-Encoding
- 告诉服务器我可以接受的压缩文件格式
-
Content-Type(MIME)
-
具体请求中的媒体类型信息
-
格式
-
type/subtype(;parameter)
-
type
- 父类型，常见text,image...
-
subtype
- 子类型，常见html,xml,gif,png
-
parameter
- 参数，charset:utf-8
-
-
实例
- Content-Type: text/html;charset:utf-8
-
常见的媒体格式类型
- text/html ： HTML格式
- text/plain ：纯文本格式
- text/xml ： XML格式
- image/gif ：gif图片格式
- image/jpeg ：jpg图片格式
- image/png：png图片格式
-
常见以application开头的媒体格式类型
- application/xhtml+xml ：XHTML格式
- application/xml ： XML数据格式
- application/atom+xml ：Atom XML聚合格式
- application/json ： JSON数据格式
- application/pdf ：pdf格式
- application/msword ： Word文档格式
- application/octet-stream ： 二进制流数据（如常见的文件下载）
- application/x-www-form-urlencoded ：
-
分析请求的流程
- 首先，客户端构造了一个HttpRequest，里面包含了需要提交到服务器端的数据，客户端提交该HtteRequest（比如通过HttpClient对象提交）。
- 接着，服务器端收到此请求，在服务器端对应的对象为HttpServletRequest
- 然后，服务器端根据请求处理后，生成了一个HttpServletResponse，返回给客户端
- 客户端展现服务器端返回的数据
-
-
-
-
-
请求空行
- 用于分割POST请求的请求行和请求体的，而GET请求由于没有请求体，所以没有请求空行
-
请求体
- 只有POST请求才有请求体，用来封装POST请求的参数
-
-
-
HTTP响应消息
-
request
-
请求行
-
组成
-
请求方式
-
GET
- 请求参数位于GET请求行中的url中
- 请求url长度有限制
- 不太安全
-
POST
- 请求参数在请求体中
- 请求的url长度没有限制（可以上传文件）
- 相对安全
-
。。。一共有七种
-
-
请求url
- /api/b/v1/billing_management/export_fee_details
-
请求协议/版本
- HTTP/1.1
-
-
示例
- GET /api/b/v1/billing_management/export_fee_details HTTP/1.1
-
-
请求头
-
作用
- 客户端告诉服务器的一些信息
-
组成
-
请求头名称：请求头值（请求头包括很多请求头名称）
-
常见请求头名称
-
User-Agent
- 浏览器告诉服务器，我访问你使用的浏览器版本信息，服务器获取该请求头的信息，解决浏览器的兼容性问题
-
Referer
- 告诉服务器当前请求从哪里来的，可以防止盗链，也可以用作统计工作
-
Accept
- 告诉服务器客户端接受的文本类型
-
Accept-Language
- 告诉服务器客户端可以接受的语言
-
Accept-Encoding
- 告诉服务器我可以接受的压缩文件格式
-
Content-Type(MIME)
-
具体请求中的媒体类型信息
-
格式
-
type/subtype(;parameter)
-
type
- 父类型，常见text,image...
-
subtype
- 子类型，常见html,xml,gif,png
-
parameter
- 参数，charset:utf-8
-
-
实例
- Content-Type: text/html;charset:utf-8
-
常见的媒体格式类型
- text/html ： HTML格式
- text/plain ：纯文本格式
- text/xml ： XML格式
- image/gif ：gif图片格式
- image/jpeg ：jpg图片格式
- image/png：png图片格式
-
常见以application开头的媒体格式类型
- application/xhtml+xml ：XHTML格式
- application/xml ： XML数据格式
- application/atom+xml ：Atom XML聚合格式
- application/json ： JSON数据格式
- application/pdf ：pdf格式
- application/msword ： Word文档格式
- application/octet-stream ： 二进制流数据（如常见的文件下载）
- application/x-www-form-urlencoded ： 中默认的encType，form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式）
-
分析请求的流程
- 首先，客户端构造了一个HttpRequest，里面包含了需要提交到服务器端的数据，客户端提交该HtteRequest（比如通过HttpClient对象提交）。
- 接着，服务器端收到此请求，在服务器端对应的对象为HttpServletRequest
- 然后，服务器端根据请求处理后，生成了一个HttpServletResponse，返回给客户端
- 客户端展现服务器端返回的数据
-
-
-
-
-
请求空行
- 用于分割POST请求的请求行和请求体的，而GET请求由于没有请求体，所以没有请求空行
-
请求体
- 只有POST请求才有请求体，用来封装POST请求的参数
-
-
-
-
-
Cookie技术（丰富HTTP功能）
-
引入
- HTTP是无状态的，但是很多应用需要掌握客户端的状态，如网上购物车
-
作用
-
网站为了辨别用户身份，进行session跟踪而存储在用户本地终端上的数据（通常需要加密）
- 所以可以理解为cookie是sessioni的钥匙
-
-
组件
-
HTTP响应消息的set-cookie头部行
- （HTTP的头部行是可以扩展的，因为cookie技术是HTTP后期才有的）
-
HTTP请求消息的cookie头部行
-
保存在客户端主机上的cookie文件，由浏览器管理
-
WEB服务器端的后台数据库，保存cookie
-
-
Cookie原理
-
应用
- 身份认证
- 购物车
- 推荐
-
问题
- 隐私问题
- 最近将要被替代
-
-
WEB缓存技术/代理服务器技术（HTTP性能优化）
-
功能
- 在不访问服务器的前提下满足客户端的HTTP请求，举例：在学校的时候，访问google，可能并没有真正访问谷歌的服务器，而是由学校的代理服务器完成
-
优点
- 缩短客户端请求响应的时间
- 减少服务器的流量开销
- 在大范围内实现有效的内容分发？CDN
-
原理
-
-
用户通过设定浏览器通过缓存进行web访问
-
浏览器像代理服务器发送所有的HTTP请求
- 如果请求对象位于代理服务器中，则由代理服务器返回对象
- 如果请求对象不在代理服务器中，则代理服务器通过向原始服务器发送HTTP请求，然后将HTTP响应返回给客户端，并在代理服务器中保存一份
- 所以代理浏览器既是客户端，又是浏览器
-
-
例子
-
问题
-
如何解决代理服务器中的对象是否为最新的
-
解决
-
条件性请求
-
-
-
2.4 Email应用
-
Email概述
-
构成
-
邮件客户端
- 读写邮件，与邮件服务器首发邮件
-
邮件服务器
-
邮箱
- 分配给用户，并存储发送给该用户的邮件
-
消息队列
- 存储等待发送的邮件
-
-
SMTP（simple mail transfer protocol）
-
邮件服务器之间传递消息所使用的协议
-
客户端
- 发送邮件的服务器
-
服务器
- 接收邮件的服务器
-
-
-
结构
- 并不像web应用那样，我们的浏览器就是客户端，SMTP中，客户端服务器全是邮箱公司的服务器，这样的好处是不要求我们的邮箱处于一直登陆的状态，符合实际需求
-
SMTP的传输层协议
-
TCP
- 进行可靠的email信息传输
- 端口25
-
交互模式
- 命令/响应
-
-
特点
- 使用持久性连接
-
和HTTP对比
-
HTTP
- 拉式pull，客户端从服务器拉取响应
-
SMTP
- 推式push，客户端服务器把消息推送到服务器上
-
都使用命令/响应交互模式
-
命令和状态码都是ASCⅡ码
-
HTTP每个对象封装在独立的响应消息中
-
SMTP多个对象在由多个部分构成的消息中发送
-
-
-
Emial消息格式与POP协议
-
Emial消息格式
-
格式
-
头部行heder
-
to
- 发给谁
-
from
- 来自谁
-
subject
- 题目是什么
-
-
消息体body
- 消息体本身，只能是ASCⅡ字符
-
-
-
MIME（多媒体邮件扩展）
-
引入
- 消息体规定只能是ASCⅡ字符，那么我们平时的中文和多媒体类型是怎么发送的呢
-
解决
- 通过邮件头部增加额外的行以声明MIME内容类型
-
-
-
-
POP协议
-
引入
- 一个网络应用可以使用多个协议
-
access protocol
-
POP，Psot Office Protocol
-
作用
- 从服务器获取邮件
-
-
IMP
-
HTTP
- 使用浏览器访问邮箱
-
-
-
2.5 DNS应用
-
DNS概述
-
DNS：Domain Name Ststem
- 域名解析系统
-
引入
- 互连网上的设备都是唯一IP地址，但是不利于我们记忆，便有了域名，那么域名和IP之间如何映射
-
特点
- 多层命名服务器构成的分布式数据库
- 利用应用层的协议完成域名的解析
-
提供的服务
-
域名向IP地址的翻译
-
主机别名
-
邮件服务器别名
-
负载均衡（web服务器）
- 可以将同一个域名相继映射到不同的闲置服务器
-
-
分布式层析式数据库
-
为什么采用分布式而不是集中式DNS数据库？
- 单节点失败问题
- 流量问题
- 距离问题
- 维护性问题
-
-
代价
- 进行了多次查询，效率低
-
DNS跟域名服务器（第一层）
-
当本地域名解析服务器无法解析域名的时候，会访问根域名服务器
- 如果跟域名服务器不知道域名IP映射，跟域名服务器就回去访问权威域名服务器，并返回映射
- 如果知道域名IP映射，直接返回
-
-
顶级域名服务器TLD（top level domain）（第二层）
- 负责com,org,net,edu等顶级域名和cn,us,uk等国家顶级域名
-
权威域名服务器（第三层）
- 类似校园网，公司网络
-
本地域名解析服务器（不严格属于层级体系）
-
每一个ISP都会有一个本地域名服务器
- 当我们在DNS查询的时候，查询会发送到本地域名服务器，然后由这个本地域名服务器作为代理，将DNS查询转发给上述层级式域名解析系统的跟域名服务器地址
-
-
DNS查询实例
-
- 迭代查询
-
- 递归查询
-
-
-
DNS记录缓存和更新
- 只要域名解析服务器获取到域名IP映射，就立即缓存这一个映射
- 一段时间后，缓存会被删除
- 本地服务器会缓存顶级域名服务器，故跟域名解析服务器并不经常访问
- 更新机制，自己找
-
-
DNS数据库记录和消息格式
-
资源记录（resource record）
-
-
name
-
value
-
type
-
type=A
- name：主机域名
- value：IP地址
-
type=NS
- name：域（edu.cn）
- value：该权威域名解析服务器的主机域名，是个域名
-
type=CNAME
- name：某一真实的域名的别名
- value：真实的域名
-
type：MX
- value是与name相对应的邮件服务器
-
-
ttl
- 关于时间有效性
-
-
-
DNS协议
-
交互模式
- 查询/回复消息
-
消息格式
- 查询回复消息格式是一样的，自己了解
-
传输协议
-
TCP还是UDP？我猜是TCP
- 然而是udp
-
-
-
-
如何注册域名
2.6 P2P应用
-
P2P应用文件分发
-
引入
- 上述三个应用都是C/S架构，
-
特点
- 没有服务器
- 任意端系统之间直接通信
- 节点阶段性接入internet
- 节点可能更换IP地址
- 比较复杂，难于管理
-
bittorrent分析
-
过程
-
-
- 首先客户向tracker中注册，加入torrent，才能获得torrent中结点清单，然后跟其中的多个个结点建立连接
-
- 建立连接之后，就可以从连接的结点中获取文件块chunk，与此同时也需要向这三个节点上传chunk
-
获取chunk
- 任意时刻，不同的结点会拥有不同的chunk
- 接收结点会定期查询每个邻居所拥有的chunk列表
- 结点发送获取chunk请求，顺序是以稀缺度优先
-
发送chunk
- 接收结点将选择四个向他发送chunk速度最快的结点发送chunk，每10秒重新评估top4
- 每30秒向一个其他节点发送chunk，新的结点可能加入top4
-
所以，上传速度越高，可以找到更好的伙伴，更快的获取文件
-
-
特点
- 在传输的过程中，结点可能离开
- 传输完成后，结点可能离开（自私）或者留下继续提供上传服务（无私）
-
-
-
P2P索引系统
-
P2P系统的索引
- 信息到结点位置（IP+端口号）的映射
- 可以理解为索引类似DNS中的数据库一样，发送chunk的结点需要告诉索引（数据库）他的IP和拥有的文件，那么接受chunk的结点就可以访问索引（数据库），获知他可以得到哪些文件，那么这个索引（数据库）就可以有集中式和分布式的区别
-
分类
-
集中式索引
-
内容和文件传输是分布式的，但是内容定位是高度集中的
-
特点
- 单点失效问题
- 性能瓶颈
- 版权问题
-
-
完全分布式索引（洪泛式查询）
-
特点
- 完全分布式架构
- 每个结点只对他自己共享的文件提供所以索引
-
问题
- 那么没有中央处理器，如何查询一个文件的所有资源分布在哪些结点上呢？
-
覆盖网络
- 如果两个节点之间有TCP连接，那么他们构成一条边，一个节点和多个节点连接，而这些节点也和别的节点相互连接，便形成了覆盖网络（逻辑网络）
-
-
层次式覆盖网络
- 一个超级节点和他所维护的小节点建立TCP连接，并维护小节点的索引，小节点之间并没有建立TCP连接，所以一个超级节点可以看做是集中式索引
- 在多个超级结点之间建立TCP连接，他们之间是完全分布式索引，采用洪泛式查询
-
-
2.7 Socket编程
3. 传输层
3.1 传输层服务
-
开篇
-
理解传输层服务的基本理论和基本机制
- 多路复用/分用
- 可靠数据传输机制
- 流量控制机制
- 拥塞控制
-
Internet协议
- UDP
- TCP
-
-
传输层概述
-
传输层协议为运行在不同主机上的进程提供了一种逻辑通信机制
-
逻辑通信机制
- 两个主机仿佛直接连接在一起，我们不需要关心实际是怎么连接的
-
-
传输层协议
-
发送方
- 讲应用层递交的消息分成一个或者多个segment（报文段），并向下传递给网络层
-
接收方
- 将接收到的segment（报文段）组装成消息，并向上交给应用层
-
internet
- TCP
- UDP
-
-
传输层vs网络层
-
传输层
- 依赖网络层提供的服务
- 面向不同主机的进程
- 逻辑通信
-
网络层
- 面向不同的主机
- 逻辑通信
- 向传输层提供服务
-
-
-
3.2 复用和分用
-
多路复用/分用
-
概念
- 如果某层的一个协议对应直接上层的多个实体，则需要多路复用/分用
-
问题
-
为什么需要多路复用/分用
-
-
多路分用（一个报文分为多个）
- host1，3要给host2发送消息，但是由于网络层只有一个IP协议，所以传输层就需要把报文段正确的通过socket传给相应的应用程序
-
多路复用（多个报文合成一个）
- host2中的两个应用程序分别向host1，3发送数据，需要统一经过网络层发送，在发送之前需要经过传输层进行整合发送
-
-
-
多路分用是怎么工作的
-
- 主机从网络层中获取到从网络层发来的IP数据报（datagram）
-
IP数据报（datagram）：网络层的数据报中携带源IP地址，目的IP地址和传输层的段（segment）（网络层不关心端口，只是关心主机的IP地址，但是网络层的数据报中是有端口数据的）
- 传输层数据段（segment）：携带源端口号和目的端口号，以及应用程序的数据(源端口口号是给返回消息提供端口号的)
-
- 主机的传输层收到segment后，传输层协议（UDP/TCP）提取IP地址和端口号信息，将segment导入相应的socket（TCP会做更多的处理）
-
UDP(无连接分用)
-
- 利用目的IP地址+目的端口号二元组创建唯一标识的socket
-
- 主机收到UDP数据段后，根据数据段的端口号导向应用程序的socket
-
- 来自不同IP和/或不同IP的数据包，只要他们的IP地址和端口号相等，都会被导向同一个应用程序的socket
-
-
TCP（面向连接的分用）
-
- 利用源IP地址+源端口号+目的IP地址+目的端口号四元组唯一表示socket
-
- 接收端利用所有的四个值将segment导向合适的socket
-
-
-
3.3 无连接传输协议-UDP
-
UDP，user datagram protocol
-
特点
-
基于Inernet IP协议
- 增加了多路复用/分用
- 增加了简单的错误校验
- 几乎裸露网络层的数据直接交给应用层
-
best effort，最大努力
- 可能丢失数据
- 数据可能非按序到达
-
无连接
- 不需要握手
- 每个UDP数据段和其他数据段是独立的
-
-
UDP为什么存在
- 无需建立连接，延迟低
- 实现简单，无需维护连接状态
- 头部内容少，资源开销小
- 没有拥塞控制：应用能够更好的控制发送时间和速率
-
常见应用
-
流媒体应用
- 可以容忍丢失
- 对带宽较为敏感
-
DNS服务
-
SNMP
-
-
UDP不能传输可靠的数据吗
- 不是的，需要在应用层上实现可靠性机制和错误回复机制，对于应用程序开发难度较大
-
UDP数据段格式
-
-
UDP校验和（checksum）
-
目的
- 检测UDP段在传输中是否发生错误（如位反转）
-
实现
-
发送方
-
- 将数据段的内容视为16bit整数，那么数据段的内容就会被分割为多个16bit的二进制数
-
- 校验和计算：计算所有整数的和，如果有进位，则再与刚才的和相加（以免超出位数），将得到的值按位取饭，得到校验和
-
- 发送方将校验和放入到校验和字段
-
-
接收方
-
- 计算所得到的段的校验和，方法和发送一样
-
- 和校验和字段进行比较
- 不相等，检测出数据出错
- 相等，没有检测出错误（实际上仍可能出现错误）
-
-
-
-
3.4 可靠信息传输的基本原理
-
可靠数据传输（rdt）的概述
-
什么是可靠
- 不错
- 不丢
- 不乱序
-
如何实现
- 依赖于可靠数据传输协议
-
特点
- 对于网络五层模型（除开物理层）都非常重要
-
实现细节
-
-
- 这里的udt_send()并不是真正的udt，因为信道是可靠的，在这里只是想当与大家约定俗成就这么叫做udt_send()而已，后面会真正讨论udt_send()
-
-
-
可靠数据传输的设计
-
研究设计方式
- 渐进形式设计rdt的发送方和接收方
- 只考虑单向数据传输，控制信息双向流动
- 利用有限状态机FSM刻画传输协议
-
有限状态机FSM，Finite State Machine
- event：造成状态发生改变的事件
- action：状态改变时所触发的动作（事件发生时所触发的动作）
- 一个事件有且只能触发一个状态，有且只能改变一种状态
-
rdt1.0
-
可靠信道上的可靠数据传输
-
底层信道完全可靠
- 不会发生错误，如位翻转
- 不会丢弃分组
- 不会乱序
-
数据传输可靠
- 发送方和接收方的有限状态机因为信道是完全可靠的，只要发送就可以接收，所以二者的FSM相互独立，不需交换控制信息
-
-
设计
-
-
sender
-
由于信道是可靠的，所以发送方的信道FSM只有一个状态
-
工作流程
-
- 循环等待应用层的调用rdt_send(data)
-
- packet=make_packet(data)
-
- 传输层调用信道上的udt_send(packet)
- 这里的udt_send()并不是真正的udt，因为信道是可靠的，在这里只是想当与大家约定俗成就这么叫做udt_send()而已，后面会真正讨论udt_send()
-
-
-
receiver
-
由于信道是可靠的，所以接收方的信道FSM只有一个状态
-
工作流程
-
- 循环等待网络层的调用rdt_receive(packet)
-
- data=make_packet(packet)
-
- diliver_data(data)
-
-
-
-
-
-
rdt2.0
-
不可靠信道的可靠数据数传
-
不可靠信道
- 假设只会产生位错误的信道，分组不丢失，不乱序
-
-
实现思想
-
如何检测接收方的数据是错误的？
- 利用前面udp讲过的校验和检测错误（难道不会使用海明校验码？）
-
检测到错误后如何纠正错误？
-
确认机制（Acknowledgements，ACK）
-
接收方显式地告知发送放分组已正确接收，如果没有正确接收分组，则会告诉发送方NAK,此时发送发会重传数据
- 基于这种重传机制的rdt协议被称为ARQ(Automatic Rrepeat reQuest)
-
-
NAK
-
ARQ协议
-
-
rdt2.0引入的新机制
- 差错检测（不只是校验和）
- 接收方反馈控制信息（ACK/NAK）
- 重传
-
-
具体设计
-
sender
-
receiver
-
-
-
rdt2.1
-
rdt2.0的缺陷
-
如果receiver发送的ACK/NAK消息在传输的过程中发生错误怎么办
-
三种解决办法
-
给ACK/NAK增加校验和，检错并就错
-
sender方收到破坏的ACK/NAK时，就无从得知receiver方发生了什么，可以为ACK/NAK增加新的控制消息（新的控制消息也会出错）
-
如果ACK/NAK坏掉了，发送方直接重传，但是容易产生重复分组（最多被采用的方案）
-
解决方案
- sender方给每个分组增加一个序列号
- receiver根据序列号丢弃重复分组（只需要看是不是01010这样的序列）
-
-
-
-
-
rdt2.1具体设计
-
sender
-
recevier
-
-
rdt2.1比较rdt2.0的改进
-
发送方
-
为每个分组增加了序列号
-
两个序列号（0，1）就够用，为什么？
- 因为采用停-等协议
-
-
接收方
- 需要判断分组时候重复，通过当前所在的状态来判断期望收到的分组序列号
- 问题：接收方无法知道ACK/NAK是否被发送方正确收到
-
-
-
rdt2.2
-
无NAK消息协议
- 控制信息状态越多，程序越复杂
-
实现方案
- 取消了NAK，就在ACK信号中加上最后一个被确认消息的序列号，如果发送方收到了接收方发来重复的信息序列号，则证明发送方刚发送的消息接收方并没有收到，发送方则和收到NAK一样，重传
-
-
rdt3.0
-
假设：信道既可能发生错误，也可能丢失分组（比rdt2.X多了一个丢失分组）
-
设计思想
-
此时rdt2.2的“校验和+序列号+ACK+重传”可以解决吗？不能
-
情景一
- 接收方成功接收发送方发来的消息，但是返回给发送发的ACK信息在不可靠信道传输的过程中丢失了， 那么发送方由于无法收到ACK控制信号而只能处于等待ACK信号的状态（停-等协议）
-
情景二
- 如果发送方发送了一个数据包，在不可靠信道中传输的时候丢失了，那么接收方会一只收不到信息而无法发送控制信号ACK，那么发送方由于无法收到ACK控制信号而只能处于等待ACK信号的状态（停-等协议）
-
-
解决方案
-
发送方设置一个合理的“等待时间，timeout“，如果没有收到某个分组的ACK，就重传该分组（发送方只会重传）
-
存在问题
- 如果ACK信号不是丢失而只是由于信道不稳定延迟了一段时间（大于timeout）到达发送方，而此时发送方已经发送了第二个数据包，就会存在发送重复的问题
-
解决
-
由于数据包都有对应的序列号，并且在ACK中显式显示，可以解决发送数据重复问题
- 接收方根据自己接收的数据包是不是010101序列，丢弃掉重复的序列的数据包，并发送发送方最后一次正确接收数据的序列号，发送方根据自己发送的数据序列号和接收到的序列号来判断是否重复发送
-
-
-
-
具体实现
-
发送方
-
接收方
- 老师懒，自己画
-
-
案例分析
-
案例一：正常情况
-
案例二：发送数据丢失
-
案例三：返回ACK丢失
-
案例四：返回ACK延迟大于timeout
-
-
性能分析
-
案例
- 1KB=8Kb是一个分组，类比为车队的长度，1Gbps是链路带宽，类比为车队的速度，那么传输延迟=8Kb/1Gbps，传播延时=15ms、
-
原因
-
结论
- 协议设计的不好就会影响到物理链路的速度，体中物理链路速度为1Gbps,然而实际为33KB/sec
-
-
-
3.5 窗口滑动协议
-
窗口滑动协议概述
-
流水线机制与窗口滑动机制
-
流水线机制
-
-
实现
-
需要更大的序列号范围
-
发送方和/或接收方都需要更大的缓存（以前是发送方用来发送信息后将信息放入缓存，便于二次发送）
-
滑动窗口协议Sliding-window-protocol
-
概述
-
窗口
- 管理那些发出去还没有确认的消息分组
- 允许使用的序列号范围
-
滑动窗口
- 随着协议的运行，窗口在序列号的空间内滑动（确认一个消息序列号，则向下滑动一个序列号）
-
-
滑动窗口协议
- GBN协议
-
-
-
-
-
-
窗口滑动协议
-
GBN:Go-Back-N协议
-
GBN发送方
-
概述
-
特点
-
收到的ACK(n)
- 收到的ACK序列号n（包含n本身）的分组及小于序列号小于n的分组均已正确接收---累计确认的机制
- 如果信道不稳定，可能收到重复的ACK
-
为空中的每一个分组（窗户中尚未被确认的每一个分组）都（这个都字有歧义）设置计时器timer，来处理timeout事件
- 对于某一个序列号为n的分组超时的timeout（即发送方没有收到接收方返回的ACK(n)）：GBN协议采用重传序列号大于等于n 还未收到ACK的所有分组 窗口中所有的尚未收到ack的分组
-
-
实现
-
-
GBN接收方
-
特点
-
接收方的ACK机制
-
发送拥有最高序列号的，已被正确接收的分组的ACK
-
特点
- 可能产生重复的ACK
- 接收方只需要维护一个变量：expectedseqnum，告诉发送方自己期望的序列号
-
-
乱序到达的分组
-
采用了流水线机制就会导致分组不按顺序到达，在停-等协议中则基本不有乱序到达，因为大家都是发一个等一个
-
解决
- 由于GBN协议中接收方不需要保存乱序到达的分组，因为GBN规定如果发来的不是期望的序列号，则发送放直接重发窗口中的所有分组，这也是GBN接收方不需要缓存的原因，所以对于乱序到达的分组，GBN直接丢弃，并且重新确认已经正常接收按需到达的序列号最大的分组
-
-
-
实现
-
-
实例
- 发送方发送的pkt2丢失后，发送方的ACK机制只会发送已经确认的序列号最大的ACK信号，当pkt3到达接收方的时候会被丢弃，并继续发送ACK(1)，由于发送方收到ACK(0),ACK(1)，但是迟迟收不到ACK(2)，便触发了pkt2的timeout，重新发送pkt2及窗口范围内的所有序列号大于2的pkt
-
-
SR:Selective Repeat协议
-
引入
-
GBN有什么缺陷
- 由于接收方没有缓存，重传的时候会重传ACK(n)之后的所有数据分组（累计确认），比较浪费资源
-
-
改进
-
发送方
- 为每个分组设置定时器，只是重传那些没有收到ACK的分组（GBN窗口都是未确认的，SR窗口是有确认和未确认的两种）
-
接收方
- 对每个分组单独进行确认，接收方设置缓存机制，缓存乱序到达的分组。而不是GBN中的累计确认ACK
-
-
-
细节
-
发送方
-
-
- 如果发送方窗口还有可用序列号，则发送分组，如果没有可用的序列号，则拒绝发送分组
-
- 如果序列号为n的分组由于没有收到ACK(n)而触发了timeout，发送方重新发送该分组，并重置计时器
-
- 如果收到的ACK(n)中的n位于发送方窗口中，则将这个分组标记为已经收到ACK，如果是n是最小的未收到ACK的分组序号，则窗口send_base移动到最小的未收到的ACK的分组对应的序列号上
-
-
-
接收方
-
-
- 收到的pkt位于接收方窗口内，则发送ACK(n)，如果pkt是乱序的，则放入缓存中，如果pkt是有序的，则从rcv_base开始将所有连续的pkt传送给应用层并滑动窗口
- 这里的rcvbase和rcvbase+N-1是因为发送方的base和接收方的base不是一个含义，发送方的base是已经发送了但是没有接收的pkt，而接收方的base是期望的但却没有接收的pkt
-
- 收到的pkt的序列号不在窗户内（可能之前的发送的pkt可能丢失了）---这种情况比较少见
-
- 其他情况：忽略
-
-
-
-
实例
-
- 发送方窗口滑动的条件是收到了正确的ACK(n)
- 接收方窗口滑动的条件是从窗口边缘起有长度大于等于1的连续分组
-
-
SR存在的问题
-
问题
-
假设序列号为0，1，2，3，窗口尺寸为3，SR接收方可以分辨如下两个场景吗？
-
- 该情景为发送方成功发送pkt0，1，2，但是ACK(0,1,2,)却都没有收到，导致pkt0发生timeout，所以发送方最后收到的pkt0是第一个循环中的第一个pkt0
-
- 该情景为发送方接收方都正确完成第一个循环，在第二个循环中，pkt3由于信道不稳定丢失，pkt0再次发给接收方
-
-
-
问题本质
- 序列号空间太小，窗口尺寸太大
-
解决问题
- Ns+Nr<=2^k,k为窗口的分组数量
-
-
-
-
3.6 面向连接传输协议-TCP
-
TCP概述
-
特点
-
点对点
- 一个发送方，一个接受方
-
可靠的，按序的字节流机制
-
使用流水线机制来提高性能
- TCP拥塞控制
- 流量控制机制
-
发送方和接受方都有缓存
-
面向连接
- 通信双方在发送数据之前必须建立连接
- 连接的状态只是在连接的两端中维护，连接的沿途结点并不维护状态
- TCP连接包括：两台主机上的缓存，连接状态变量，socket等
-
全双工
- 同一个连接中可以传输双向数据流
-
-
TCP段结构
-
-
sequence number(序列号)
- 指的并不是segment（pkt）中的0,12,3,这里不是按照第一个pkt0，第二个pkt1来编号的，而是按照pkt数据的第一个字节对应的编号，一个pkt中包含很多字节，假设一个pkt包含500B，那么sequence number就会是0，500，1000，1500
- 建立TCP连接的时候，双方随机选择序列号，而且在通信的过程中，双方会交换序列号信息
-
ACK
-
期望接收的下一个字节的序列号
-
累计确认机制：该序列号之前的所有字节均已被正确接收
-
如果TCP收到乱序到达的segment？
- TCP协议中没有规定，由TCP的实现者做出决策
-
-
-
-
TCP可靠数据传输
-
TCP的可靠数据传输用到了前面讲的一些东西
-
概述
-
TCP在IP层提供的不可靠服务基础上实现可靠数据传输服务
-
流水线机制提高性能
-
ACK累积确认
-
TCP使用单一的重传定时器（很多的pkt使用一个timer）
-
通过重传解决丢包等问题
-
触发重传的事件
- 超时timeout
- 收到重复ACK（因为累积确认机制）
-
-
暂不考虑重复ACK，流量控制，拥塞控制
-
-
RTT和超时timeout
-
如何设置定时器的timeout？
-
首先必须大于Round Trip Time
- 但是RTT本身又是变化的
-
如果timeout时间仅大于RTT一点
- 造成很多不必要的重传
-
如果timeout时间大于RTT太多
- 造成对segment丢失不敏感，反应慢
-
-
如何估计RTT的值？
-
估计RTT
- 测量segment从发出到接收到ACK的时间（忽略重传）---SampleRTT(采样RTT)
- 测量多个SampleRTT，求平均值作为RTT的估计值EstimatedRTT
-
-
如何设置timeout的值
-
timeout=
- EstimatedRTT+安全边界，如果RTT变化不大
- EstimatedRTT+较大边界，如果RTT变化较大
-
所以需要测量RTT的变化值：SampleRTT与EstimatedRTT的差值
-
timeout=
-
-
-
TCP发送方事件
-
事件一：从应用层收到数据
- 传输层TCP创建Segment
- 序列号是Segment第一个字节的序列号
- 开启定时器
- 设置超时时间timeout
-
事件二：超时
- 重传引起超时的一个Segment
- 重启定时器
-
事件三：收到ACK
-
如果确认此前未确认的Segment
- 更新sendbase
- 如果窗口中还有未被确认的分组，则重新启动定时器
-
-
TCP发送端伪代码
-
实例
-
基本情况
-
- NextSeqNum=SeqNum+DataSize（SeqNum=seq，NextSeqNum=nextseq）
- 主机A发送seq=92的TCP段，该TCP段含有8B的数据，所以nextseq=92+8=100，故ACK为100（TCP中ACK中的值为期望接收的字节序列号），然而ACK=100丢失了并触发了seq=92的timeout事件，重新发送该TCP段，所以接受方再次发送ACK=100，然后sendbase被设置为100
-
-
流水线机制且timeout时间较小
-
-
主机A连续发送两个TCP段，由于timeout设置的过短，导致ACK消息尚未传达到发送方而出发了timeout事件，此时首先发送seq值最小的TCP段，那么接收方的ACK应该为92+8=100，但是由于TCP采用了累积确认机制，所以ACK在之前已经是120，证明120之前都已经正确接收，所以不需要将ACK改为100，而是直接120
- 证明sendbase（seq）并不是sendbase=y，而是发送方的sendbase是可以自己通过seq和datasize自己计算出来，毕竟发送方也是通过这种方法计算出来nextSeq
-
-
-
堆积的ACK
-
- 主机B发送的两个ACK，其中较小的ACK由于信道不稳定而丢失，主机A只收到较大的ACK,由于采用了累积确认的机制，所以ACK=120之前的所有TCP段已经正确接收，所以ACK=100丢失不会造成任何影响
-
-
-
-
TCP接收方事件
-
-
-
事件一
-
并不立即发送ACK，而是等待大约500ms是否有下一个TCP段发过来，如果没有就直接发送ACK，如果有，就看事件二的处理方式
-
一个按序的且是接收方所期望的TCP段到达，并且之前所有的TCP段都已经被正确的接收并发送了ACK确认
-
事件二
-
一个按序的且是接收方所期望的TCP段到达，并且之前所有的TCP段都已经被正确的接收但是还有一个TCP处于500ms等待期尚未被ACK确认
-
立即发送这两个累积确认ACK(难道只发最大的ACK)，确认TCP段
-
事件三
-
一个乱序到达且seq比期望的seq要大
-
立即发送重复的ACK(累积确认机制)，然后指明所期望的seq
-
-
-
快速重传机制
-
引入
-
平常重传都是触发了timeout，而TCP在实现中，如果发生了超时timeout，那么超时timeout会被设置的为原来的两倍（为什么我也不知道）
- 导致timeout值很大
- 对于丢失的分组需要等待很长的timout时间才能发现分组丢失
-
-
快速重传的实现原理
-
发送方通过检测是否有重复的ACK来判断分组是否丢失
- 发送方采用流水线机制会发送多个分组
- 如果某个分组丢失，可能会引发多个重复的ACK
-
-
实现
- 如果发送方收到同一个段的3个ACK,则认为该数据之后的段已经丢失，则此时即使timeout没有超时，也要启动重传
-
-
-
TCP的流量控制
-
TCP接收方会分有buffer
-
-
RevWindow
-
TCP data in buffer
- 表示部分数据位于TCP的buffer中
-
spare room
- 空闲出来可以用来接收数据的buffer
-
-
问题
- 如果发送方发送速度过快超过应用层处理数据的速度会导致数据淹没接收方，所以需要一个速度匹配机制来控制发送方的发送速度
-
实现
- 假设TCP会将乱序到达的segment丢掉（实际上并不是这么做的）
- 接收方可以通过TCP段（segment），即为ACK,的头部字段中告诉发送方自己的RevWindow的大小告诉发送方，此时发送方就会限制自己的已经发送但是还没有收到ACK的数据不超过接收方的RevWindow的尺寸
-
思考
-
如果接收方告诉发送方自己的RevWindow=0的时候，双方会有怎么样的行为
- 场景一：发送方停止发送数据，但是当接收方RevWindow逐渐开始大于0的时候，接收方无法告诉发送方自己的RevWindow已经大于0了
- 场景二：即使接收方RevWindow=0，发送方仍然需要发送一个很小的数据，以便接收方向发送方更新自己的RevWindow的大小
-
-
-
TCP连接管理
-
引入
- TCP规定发送方和接收方进行通信的时候需要先建立连接，通信结束的时候需要关闭连接
-
概念
- TCP连接管理就是使连接建立和释放都能正常进行
-
建立TCP连接步骤
-
- 初始化TCP变量
- seq
- 启用buffer缓存和流量控制信息
-
-
-
建立连接（三次握手）
-
-
- 客户机向服务器发送SYN报文段
- 该SYN报文段不携带任何数据，将SYN标志位置为1，表示要建立一个TCP连接
- 并选择一个初始的随机的seq，选值的方法有很多，这里采用随机
-
- 服务器收到SYN段并且想要建立该连接会答复一个SYNACK报文段
- 服务器会分配缓存
- 选择初始序列号
-
-
-
-
注意无论是发送方还是接收方都有rdt_rcv(rcvpkt)和udt_send(sndpkt)，但是对于不同的对象，方法和里面的参数是各有不同的含义的
发送方sender
- 对于sender来说，rdt_rcv(rcvpkt)就是sender接收到receiver发送的控制信息rcvpkt，rcvpkt就是receiver发来的控制信息（ACK/NAK）
- 对于sender来说，udt_sernd(sndpkt)就是sender向receiver发送数据sndpkt，sndpkt就是sender要发来的数据
接收方receiver
- 对于receiver来说，rdt_rcv(rcvpkt)就是receiver接收到的sender发送的数据rcvpkt，rcvpkt是sender发来的数据
- 对于receiver来说，udt_send(sndpkt)就是receiver向sender发送控制信息sndpkt（ACK/NAK）,sndpkt就是控制信息
浙公网安备 33010602011771号