携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第5天，点击查看活动详情
特别关注TCP/UDP运输层协议
概述和运输层服务
传输层协议位运行在不同主机上的应用进程之间提供了逻辑通信
- 运行不同进程的主机看起来好像直接相连在一起
- 应用进程使用传输层的逻辑通信功能彼此发送报文 无需考虑承载这些报文的物理基础设施的细节
- 运输层协议在端系统实现
运输层和网络层关系
- 网路层提供了主机之间的逻辑通信
- 运输层为运行在不同主机上的进程之间提供了逻辑通信
因特网运输层概述
- UDP 用户数据报协议
- TCP 传输控制协议
- 运输层->报文段 网络层->数据报
- IP 网际协议 尽力而为交付服务 不可靠
- UDP TCP最基本责任 将IP的交付服务拓展为进程的交付服务 运输层的多路复用与多路分解
- TCP 可靠数据传输（流量控制 序号 确认 定时器） 拥塞控制
多路复用和多路分解
- 一个进程有一个或多个套接字
- 多路分解 将运输层报文段中的数据交付到正确的套接字 到应用层
- 多路复用 在源主机从不同套接字中收集数据块 并为每一个数据块封装上首部信息生成报文段
- 多路复用要求
- 套接字有唯一标识符
- 每个报文段有特殊字符来指示该报文段所要交付的套接字
- 源端口号
- 目的端口号
- 0-1023周知端口号 保留给应用层是协议使用
无连接传输UDP
- 最低限度的提供复用分解功能 少量的差错检测
- 约等于直接和IP打交道
- DNS依赖UDP 无需握手
- 特征
- 要求最小的发送速率 不希望过分延迟报文段的传送 能容忍数据丢失
- 无需连接建立 不会引入建立连接的时延
- 无连接状态
- 首部开销消耗小
UDP报文段结构
- 源端口号
- 目的端口号
- 长度
- 校验和
- 报文
UDP校验和
不能保证源和目的之间的所有链路都提供差错检测
校验和->溢出回卷->反码 加起来 全为一 则正确
可靠数据传输原理
依赖于可靠信道 所有数据按照其发送顺序进行交付 可靠数据传输协议
构造可靠数据传输协议
- 经完全可靠信道的可靠数据传输 rdt1.0
- 简单协议 单元数据与分组没差别
- 经具有比特差错信道的可靠数据传输 tdt2.0
- 停等 发送方不会发送新数据直到接收方收到
- 肯定确认与否定确认
- 自动重传
- 差错检测
- 接收方反馈
- 没有考虑到分组受损
- 添加序号 检查序号
- 经具有比特差错的丢包信道的可靠数据传输rdt3.0
- 冗余数据分组
- 倒计数定时器
- 检验和 序号 定时器 肯定否定确认分组
流水线可靠数据传输协议
以不停等方式运行 允许发送方发送多个分组无需等待
解决流水线的差错恢复
- 回退N步
- 选择重传
选择重传
面向连接的传输-TCP
TCP特性 RFC793 RFC1122 RFC1323
- 差错检测
- 重传
- 累计确认
- 定时器
- 序号与确认号
TCP连接
TCP被称为是面向连接的
- 需要握手
- 相互发送某些预备报文段
- 建立确保数据传输的参数
- 初始化与TCP连接相关的许多TCP状态常量
- 点对点的全双工服务
- UDP可以实现多播 TCP不行
- 可以两端同时相互流动
- MTU与MSS
- MTU 最大传输单元 一般1500
- MSS 最大报文段长度 一般1460
- MTU=MSS+TCP/IP的首部长度 一般为40字节
TCP报文段结构
- 序号和确认号
- 报文段的序号是该报文端首字节的字节流编号
- 累计确认 TCP只确认流中至第一个丢失字节为止的字节
- Telnet
- 用于远程登陆的流行的应用层协议
- Telnet不加密 易于受到窃听攻击
- 对客户到服务器的数据的确认被装在在一个承载服务器到客户的数据的报文段中 （捎带）
往返时间的估计与超时
- 需要 TCP 通过采样 RTT 的时间，然后进行加权平均，算出一个平滑 RTT 的值，而且这个值还是要不断变化的，因为网络状况不断地变化。
- 除了采样 RTT，还要采样 RTT 的波动范围，这样就避免如果 RTT 有一个大的波动的话，很难被发现的情况。
RFC6289 建议使用以下的公式计算 RTO：
其中 SRTT 是计算平滑的RTT ，DevRTR 是计算平滑的RTT 与 最新 RTT 的差距。
在 Linux 下，α = 0.125，β = 0.25， μ = 1，∂ = 4。别问怎么来的，问就是大量实验中调出来的。
如果超时重发的数据，再次超时的时候，又需要重传的时候，TCP 的策略是超时间隔加倍。
也就是每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。
超时触发重传存在的问题是，超时周期可能相对较长。那是不是可以有更快的方式呢？
于是就可以用「快速重传」机制来解决超时重发的时间等待
可靠数据传输
因特网的网络层IP服务是不可靠的
- IP不保证数据报的交付
- 不保证数据报的按序交付
- 不保证数据完整性
TCP在IP的尽力而为服务上创建了一种可靠数据传输服务
确保进程从其接受缓存中读出数据流是 [无损坏 无间隙 非冗余 按序的数据流]
- 一些有趣情况
- 确认丢失 重传
- 两个连续报文段ACK丢失 第一个重传 重启定时器 只要第二个报文段的ACK在新的超时发生之前到达 第二个报文段不会重传
- 丢失ACK 但是收到了确认号更大的ACK 说明对方已经收到了确认号-1以及之前的所有字节
- 超时间隔加倍
- 避免持续重传分组 导致网络拥塞更为严重的情况
- 快速重传
- 连续收到3个相同的ACK 在定时器过期之前重传丢失的报文段
流量控制
- 窗口
那么有了窗口，就可以指定窗口大小，窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。
窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。
假设窗口大小为 3 个 TCP 段，那么发送方就可以「连续发送」 3 个 TCP 段，并且中途若有 ACK 丢失，可以通过「下一个确认应答进行确认」
详见小林Coding：
xiaolincoding.com/network/3_t…%A8%E7%AA%97%E5%8F%A3
TCP连接管理
三次握手
- 拓展知识 nmap端口扫描工具
- nmap发送一个特殊的TCP SYN段 可能情况：
- 收到SYN ACK 则返回OK
- 收到RST 说明目标端口没有运行应用程序 直到发往该端口报文段没有被源和目标主机之间的任何防火墙阻挡
- 什么都没有收到 说明被中间防火墙阻挡 无法到达目标主机
拥塞控制原理
拥塞原因与代价
- 当分组的到达速率接近链路容量时 分组经历巨大的排队时延
- 发送方在遇到大时延时锁进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本
- 当一个分组沿一条路径被丢弃时 每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费掉了
拥塞控制方法
- 端到端拥塞控制 通过分组丢失与时延 判断
- 网络辅助的拥塞控制 路由器显式返回拥塞状态
TCP拥塞控制
- 慢启动
- 拥塞避免
- 快速恢复
小林Coding YYDS! 小林Coding 拥塞控制
亚瑟・叔本华「人类的智慧」
自身拥有越丰富，他在别人身上所能发现得到的就越少。
