[TOC]

一、概述和传输层服务

传输服务与协议
- 为运行在不同主机上的应用进程提供逻辑通信
- 传输协议运行在端系统
  - 发送方：将应用层的报文分成报文段，然后传递给网络层
  - 接收方：将报文段重组成报文，然后传递给应用层
传输层 VS 网络层
- 网络层服务：主机之间的逻辑通信
- 传输层服务：进程间的逻辑通信
  - 依赖于网络层的服务：延时、带宽
  - 并对网络层的服务进行增强：数据丢失、顺序混乱、加密
  - 有些服务是可以加强的：不可靠 -> 可靠；安全
  - 但有些服务是不可以被加强的：带宽，延迟
Internet传输层协议
- 可靠的、保序的传输：TCP
  - 多路复用、解复用
  - 拥塞控制
  - 流量控制
  - 建立连接
- 不可靠、不保序的传输：UDP
  - 多路复用、解复用
  - 没有为尽力而为的IP服务添加更多的其它额外服务
- 都不提供的服务
  - 延时保证
  - 带宽保证

二、多路复用与解复用

多路复用/解复用
多路解复用工作原理
- UDP和TCP不同
无连接的多路解复用
面向连接（TCP）的多路复用
- TCP套接字：四元组本地标识
  - 源IP地址
  - 源端口号
  - 目标IP地址
  - 目标端口号
- 解复用：接收主机用这四个值来将数据报定位到合适的套接字
- 服务器能够在一个TCP端口上同时支持多个TCP套接字
  - 每个套接字由其四元组标识（有不同的源IP和源PORT）
- Web服务器对每个连接客户端有不同的套接字
  - 非持久对每个请求有不同的套接字

三、无连接传输：UDP

无连接传输：UDP
- UDP：User Datagram Protocol[RFC 768]
- “no frills,” “bare bone”Internet 传输协议
- “尽力而为”的服务，报文段可能：
  - 丢失
  - 送到应用进程的报文段乱序
- 无连接
  - UDP发送端和接收端之间没有握手
  - 每个UDP报文段都被独立地处理
- UDP被用于
  - 流媒体（丢失不敏感，速率敏感、应用可控制传输速率）
  - DNS
  - SNMP
- 在UDP上可行可靠传输
  - 在应用层增加可靠性
  - 应用特定的差错恢复
UDP：用户数据报协议
UDP校验和
- 目标：检测在被传输报文段中的差错(如比特反转)
- 发送方
  - 将报文段的内容视为16比特的整数
  - 校验和：报文段的加法和(1的补运算）
  - 发送方将校验和放在UDP的校验和字段
- 接收方
  - 计算接收到的报文段的校验和
  - 检查计算出的校验和与校验和字段的内容是否相等
  - 发送方将校验和放在UDP的校验和字段

四、可靠数据传输的原理

这一块我感觉老师讲的很细，但我没怎么听明白…

这里面涉及的重点主要是可靠数据是怎么传输的，流水线协议（即允许发送方在未得到对方的确定的情况下，再下一次的发送分组时可以发送多个分组），滑动窗口，超时重传机制等等。

五、面向连接的传输：TCP

TCP概述
- 点到点：一个发送方，一个接收方
- 可靠的、按顺序的字节流而且没有报文边界
- 管道化（流水线）
  - TCP拥塞控制和流量控制设置窗口大小
- 具有发送缓存和接收缓存
- 全双工通信
  - 在同一连接中数据流双向流动
  - MSS:最大报文段大小
- 面向连接
  - 三次握手（四次挥手）
TCP报文段（这一块看书吧）
TCP往返延时（RTT）和超时
- Q:怎样设置TCP超时？
  - 比RTT要长
    - 但RTT是变化的
  - 太短：太早超时
    - 不必要的重传
  - 太长
    - 对报文段丢失反应太慢，消极
- Q:怎样估计RTT？
  - 这里好像有计算公式具体得看书
流量控制：接收方控制发送方，不让发送方发送的太多太快，以至于让接收方的缓冲区溢出
- 流量控制和拥塞控制相似，切勿弄混。
快速重传
- 超时周期往往太长
  - 在重传丢失报文段之前的延时太长
- 通过重复的ACK来检测报文段丢失
  - 发送方通常连续发送大量报文段
  - 如果报文段丢失，通常会引起多个重复的ACK
- 如果发送方收到同一数据的3个冗余ACK，重传最小序号的段
  - 快速重传：在定时器过时之前重发报文段
  - 它假设跟在被确认的数据后面的数据丢失了
    - 第一个ACK是正常的,收到第二个该段的ACK，表示接收方收到一个该段后的乱序段；收到第3，4个该段的ack，表示接收方收到该段之后的2个，3个乱序段，可能性非常大段丢失了

六、拥塞控制原理

拥塞
- 可以把出现网络拥塞的条件写成下列的关系式
  
  对资源的所有需求 > 可用资源
- 拥塞表现
  - 分组丢失（路由器缓冲区溢出)
  - 分组经历比较长的延迟（在路由器的队列中排队）
- 这也是网络中top10的问题
- 相关拥塞例子（感觉不重要先不记录了）
拥塞控制方法
- 端到端的拥塞控制
  - 没有来自网络的显式反馈
  - 端系统根据延迟和丢失事件推断是否有拥塞
  - TCP采用的方法
- 网络辅助的拥塞控制
  - 路由器提供给端系统以反馈信息
    - 单个bit置位，显示有拥塞 (SNA, DECbit, TCP/IP ECN, ATM)
    - 显式提供发送端可以采用的速率

七、TCP拥塞控制

端到端的拥塞控制机制
- 路由器不向主机有关拥塞的反馈信息
  - 路由器的负担较轻
  - 符合网络核心的简单的TCP/IP架构原则
- 端系统根据自身得到的信息，判断是否发生拥塞，从而采取动作
TCP拥塞控制：拥塞感知
- 当某个时段超时了（丢失事件）：拥塞
  - 超时时间到，某个段的确认没有来
  - 原因1：网络拥塞（某个路由器缓冲区没空间了，被丢弃）概率大
  - 一旦超时，就认为拥塞了，有一定误判，但是总体控制方向是对的
- 有关某个段的3次重复ACK：轻微拥塞
  - 段的第1个ack，正常，确认绿段，期待红段
  - 段的第2个重复ack，意味着红段的后一段收到了，蓝段乱序到达
  - 段的第2、3、4个ack重复，意味着红段的后第2、3、4个段收到了，橙段乱序到达，同时红段丢失的可能性很大（后面3个段都到了，红段都没到）
  - 网络这时还能够进行一定程度的传输，拥塞但情况要比第一种好
TCP拥塞控制策略
- 慢启动
- AIMD:线性增、乘性减少
- 超时事件后的保守策略
TCP慢启动（只是启动蛮，但速度不慢）
- 连接刚建立, CongWin = 1 MSS
  - 如: MSS = 1460bytes & RTT = 200 msec
  - 初始速率 = 58.4kbps
- 可用带宽可能>> MSS/RTT
  - 应该尽快加速，到达希望的速率
- 当连接开始时，指数性增加发送速率，直到发生丢失的事件
  - 启动初值很低
  - 但是速度很快
- 当连接开始时，指数性增加（每个RTT）发送速率直到发生丢失事件
  - 每一个RTT， CongWin加倍
  - 每收到一个ACK时， CongWin加1（why）
  - 慢启动阶段：只要不超时或 3个重复ack，一个RTT，CongWin加倍
- 总结: 初始速率很慢，但是加速却是指数性的
  - 指数增加，SS时间很短，长期来看可以忽略
TCP拥塞控制：AIMD
- 乘性减
  - 丢失事件后将CongWin降为1，将CongWin/2作为阈值，进入慢启动阶段（倍增直到 CongWin/2）
- 加性增
  - 当CongWin>阈值时，一个 RTT如没有发生丢失事件 ,将CongWin加1MSS: 探测
- 当收到三个重复的ACKs
  - CongWin 减半
  - 窗口（缓冲区大小）之后线性增长
- 当超时事件发生时
  - CongWin被设置成 1 MSS，进入SS阶段
  - 之后窗口指数增长
  - 增长到一个阈值（上次发生拥塞的窗口的一半）时，再线性增加
- 思路
  - 3个重复的ACK表示网络还有一定的段传输能力
  - 超时之前的3个重复的 ACK表示“警报”
感觉自己这一块没有完全的明白，还得再看看书。