3.1 概述和传输层服务
传输服务和协议：
为运行在不同主机上的应用进程提供逻辑通信；
传输协议运行在端系统-发送方:将应用层的报文分成报文段，然后传递给网络层；接收方：将报文段重组成报文，然后传递给应用层；
有多个传输层协议可供应用选择；
网络层服务：主机之间的逻辑通信
传输层服务：进程间的逻辑通信——依赖于网络层的服务：延时、带宽。并对网络层的服务进行增强
可靠的、保序的传输：TCP
-多路复用、解复用
-拥塞控制
-流量控制
-建立连接
不可靠的、不保序的传输：UDP
-多路复用、解复用
-没有为尽力而为的IP服务添加更多的其他额外服务
都不提供的服务：延时保证，带宽保证
3.2 多路复用和解复用
在发送方主机多路复用：从多个套接字接受来自多个进程的报文，根据套接字对应的IP地址和端口号等信息对报文段用头部加以封装（该头部信息用于以后的解复用）
在接收方主机多路解复用：根据报文段的头部信息中的IP地址和端口号将接收到的报文段发给正确的套接字（和对应的应用进程）
多路解复用工作原理：
解复用作用：TCP或者UDP实体采用哪些信息，将报文段的数据部分交给正确的socket，从而交给正确的进程。
主机收到IP数据报：每个数据报有源IP地址和目标地址；每个数据报承载一个传输层报文段；每个报文段有一个源端口号和目标端口号
主机联合使用IP地址和端口号将报文段发送给合适的套接字
3.3 无连接传输UDP
3.4 可靠数据传输（RDT）的原理
RDT在应用层传输层和数据链路层都很重要；是网络Top10问题质疑
信道的不可靠特点决定了可靠数据传输协议rdt的复杂性
渐增式地开发可靠数据传输协议（RDT）的发送方和接收方
只考虑单向数据传输，但控制信息是双向流动的！
双向的数据传输问题实际上是两个单向数据传输问题的总和
使用有限状态机（FSM）来描述发送方和接受方
状态：在该状态下，下一个状态只由下一个事件唯一确定
Rdt1.0：在可靠信道上的可靠数据传输 ：
下层的信道是完全可靠的：没有比特出错；没有分组丢失
发送方和接收方的FSM：发送方将数据发送到下层信道；接收方从下层信道接收数据
Rdt2.0：具有比特差错的信道
下层信道可能会出错：将分组中的比特翻转——用校验和来检测比特差错
问题：怎样从差错中恢复？
-确认（ACK）：接收方显式地告诉发送方分组已被正确接受
-否定确认（NAK）：接收方显式地告诉发送方分组发生了差错，发送发重传分组
rdt2.0中的新机制：采用差错控制编码进行差错检测
- 发送方差错控制编码、缓存
- 接收方使用编码检错
- 接收方的反馈：控制报文（ACK、NAK）：接收方-》发送方
- 发送方收到反馈相应的动作
rdt2.2:无NAK的协议
功能同rdt2.1，但只使用ACK（ack要编号）
接收方对最后正确接收的分布发ACK，以替代NAK。接收方必须显式地包含被正确接收分组的序号
当受到重复的ACK时，发送方与收到NAK采取相同的动作，重传当前分组
为后面的一次发送多个数据单位做一个准备：一次能够发送多个，每一个的应答都有：ACK，NACK；使用对前一个数据单位的ACK，代替本数据单位的NAK，确认信息减少一半，协议处理简单
rdt3.0：具有比特差错和分组丢失的信道
新的假设：下层信道可能会丢失分组（数据或者ACK）
—会死锁；机制还不够处理这种状况
方法：发送方等待ACK一段合理的时间
发送端超时重传，如果到时没有收到ACK，则重传。
问题：如果分组（或ACK）只是被延迟了：重传会导致数据重复，但利用序列号已经可以处理这个问题。接收方必须指明被正确接收的序列号
需要一个倒计数定时器
流水线协议：
流水线：允许发送方在未得到对方确认的情况下一次发送多个分组；
必须增加序号的范围：用多个bit表示分组的序号
在发送方/接收方要有缓冲区：发送方缓冲：未得到确认，可能需要重传。接收方缓存：上层用户取用数据的速率！=接收到的数据速率，接收到的数据可能乱序，排序支付
两种通用的流水线协议：回退N步（GBN）和选择重传（SR）
滑动窗口协议：
发送缓冲区：
-形式：内存中的一个区域，落入缓冲区的分组可以发送
-功能：用于存放已发送，但是没有收到确认的分组
-必要性：需要重发时可用
发送缓冲区的大小：一次最多可以发送多个未经确认的分组
-停止等待协议=1
-流水线协议>1，合理的值，不能很大，链路利用率不能超过100%
发送缓冲区中的分组：
-未发送的：落入发送缓冲区的分组，可以连续发送出去
-已经发送出去的、等待对方确认的分组：发送缓冲区的分组只有得到确认才能删除
接收窗口=1：GBN协议，只能顺序接受（累计确认）
接收窗口》1：SR协议，可以乱序接受
异常情况下的GBN的2窗口互动
发送窗口：
新分组落入发送缓冲区的范围，发送-》前沿移动
超时重发机制让发送端将发送窗口中的所有分组发送出去
来了老分组的重复确认-》后沿不向前滑动-》新的分组无法落入发送缓冲区范围（此时如果发送缓冲区有新的分组可以发送）
接收窗口：
收到乱序分组，没有落入到接收窗口范围，抛弃
（重复）发送老分组的确认，累计确认
选择重传SR：
接收方对每个正确接收的分组，分别发送ACK（非累计确认），因为接受窗口》1，因此可以缓存乱序的分组，最终将分组按顺序交付给上层
发送方只对那些没有收到ACK的分组进行重传0选择性重发，发送方为每个未确认的分组设定一个定时器。
发送窗口的最大值（发送缓冲区）限制发送未确认分组的个数
3.5 面向连接的传输TCP
点对点：一个发送方，一个接收方
可靠的、按顺序的字节流：没有报文边界
管道化（流水线）：TCP拥塞控制和流量控制设置窗口大小
发送和接受缓存
全双工数据：在同一连接中数据流双向流动
面向连接：在数据交换前，通过握手初始化发送方、接收方的状态变量
有流量控制：发送方不会淹没接收方
MSS：最大报文段
TCP序号：报文段首字节的在字节流的编号
确认号：期望从另一方收到的下一个字节的序号；累计确认
TCP往返延时（RTT）和超时：
怎样设置TCP超时？——比RTT长、太早超时、太长报文段丢失
怎样估计RTT？——测量从报文段发出到收到确认的实践，因为存在变化，所以对多个测量值求平均
可靠数据传输：TCP在IP不可靠的服务的基础上建立了rdt，
管道化的报文段——GBN/SR
累计确认——GBN
单个重传定时器——GBN
是否可以接受乱序的，没有规范
通过以下事件触发重传：超时——SR；重复的确认
TCP连接管理：
在正式交换数据之前，发送方和接收方握手建立通信关系：同意建立连接，同一连接参数
Q：在网络中，两次握手建立连接总是可行的吗？
- 变化的延迟，没有丢，但可能超时
- 由于丢失造成的重传
- 报文乱序
- 相互看不到对方
虚假的数据，旧数据当作新数据接受了
TCP：关闭连接
客户端，服务器分别关闭他自己这一侧的连接
一旦收到FIN，用ACK回应
可以处理同时的FIN交换
3.6 拥塞控制原理
拥塞得表现：
1.分组丢失（路由器缓冲区溢出）
2.分组经历比较长的延迟（在路由器的队列中排队）
两个主机经过一个路由器分别发送给两个主机，路由器带宽有限。
- 延迟大
- 为了保证输出，输入在持续增加
- 网络拥塞，重传没有必要的数据，加速拥塞
拥塞控制方法：
1.端到端拥塞控制：
没有来自网络的明显反馈；端系统根据延迟和丢失时间推断是否有拥塞；TCP采用的方法。
2.网络辅助的拥塞控制：路由器提供给端系统以反馈信息，单个bit置位，显示有拥塞。显式提供发送端可以采用的速率。
3.7 TCP拥塞控制
端到端拥塞控制
路由器不向主机提供有关拥塞的反馈信息，是的路由器负担较轻，符合网络核心简单的TCPIP架构原则，
端系统根据自身得到的信息，判断是否发生拥塞，从而采取行动。
拥塞控制的几个问题：
如何检测拥塞：轻微拥塞，拥塞；
控制拥塞：在拥塞发生时如何动作，降低速率；在拥塞缓解时如何动作，增加速率。
拥塞感知：
发送端如何探测到拥塞？
1.某个段超时了：拥塞
超时时间到，某个段的确认没有来，网络拥塞，某个路由缓冲区没空间了。被丢弃，概率大。出错被丢弃了，没有通过某个校验，被丢弃，概率小。一旦超时，就认为拥塞了，有一定误判，但总体控制方向是对的。
2.有关某个段的三次重复ACK：轻微拥塞
段的第一个ack，正常，确认绿段，期待红段。段的第二个重复ack，意味着红段之后的段收到了，乱序到达，一直重复ack，意味后面的段都乱序到达了，说明红段丢失的可能性极大。网络这时还能够进行一定程度的传输，拥塞但情况比第一种好
速率控制方法：
维持一个拥塞窗口的值：CongWin
发送端限制已发送但是未确认的数据量的上限，从而粗略地控制发送方往网络中注入的速率
