目录
传输层服务和协议
传输层 vs. 网络层
Internet传输层协议
多路复用和多路分用
接收端进行多路分用:传输层依据头部信息将收到的 Segment交给正确的Socket， 即不同的进程.
发送端进行多路复用:从多个Socket接收数据，为每 块数据封装上头部信息，生成 Segment，交给网络层
分用如何工作？
udp无连接分用
重点，只要目的端口号相同，来自不同源IP地址和/或源端口号的 IP数据包被导向同一个接收端Socket
tcp面向连接的分用
重点接收端socket，通过四个参数决定socket，即使目标端口号相同，只要来源ip或者来源端口不同，就用不同的socket。
UDP协议
udp做了什么
基于Internet IP协议：
- 复用/分用
- 简单的错误校验(链路层协议很多，不一定会有校验；即使网络层校验，但在路由器也有可能发生错误，所以传输层也需要校验)
udp几乎是把ip层暴露给了应用层，这就是它的特点。
udp服务模型
尽力而为，Best effort”服务，UDP段可能丢失，也可能非按序到达。
因为ip层就是可能丢失和非按序，udp在ip上做的事很少。
面向连接？无连接？
面向连接就是，客户端服务端要维护关于 连接状态的信息，比如握手的哪个阶段、断开连接到第几步了。
无连接就是双端不用维护状态信息，想发送数据就发送，不用提前向对方打招呼，不想发送就停止，也不用告诉对方我不发了。
无连接特点
- UDP发送方和接收方之间不需要握手
- 每个UDP段的处理独立于其他段，每个段单独处理，段和段直接处理没关系，因为都不按序发送。
UDP价值
- 无需建立连接 (减 少延迟,速度快，所以dns就用了udp)
- 实现简单：无需维 护连接状态，用起来没有tcp复杂
- 头部开销少，数据更少
- 没有拥塞控制: 应用可更好地控制发 送时间和速率
用途
- 常用于流媒体应用：因为容忍丢失，速率敏感
- DNS
- SNMP
在UDP上实现可靠数据传输？
- 在应用层增加可靠性机制
- 应用特定的错误恢复机制
udp段结构
UDP校验和(checksum)
发送方将段内容计算一个校验和，接收方也计算，校验是否相同。
可靠数据传输原理
什么是可靠？
错：传输中，1变成0；丢：数据丢失；乱：一个分组，重复发送，分辨不出来。
因为信道不可靠，所以传输协议需要考虑可靠。
rdt:可靠性传输协议
可靠数据传输协议基本结构:接口
发送方，应用层调用rdt_send,箭头是单向，意味着数据一次性交给tcp，tcp不会再调用上层应用层。
t接收方cp调用deliver_data()，箭头单向，意味着数据一次性交给应用层。
发送方tcp调用udt_send,箭头双向，以为tcp和ip间互相作用，控制传输，后面会讲控制传输速度。
接收方，rdt_rcv，ip调用tcp接受数据，也是双向作用，发送方接收方共同努力，才能控制流量。
Rdt,可靠数据传输协议
学习设计一个可靠传输协议
Rdt 1.0: 可靠信道上的可靠数据传输
状态机描述：
发送方：
- 只有一个状态，等待上层调用
- 上层调用rdt_send(可靠传输)发送方法
- 将数据做成包
- 调用udt_send(虽然名字是udt不可靠传输，但这里认为信道是可靠的)把数据发送到信道。
接收方：
- 只有一个状态，等待下层调用=
- 下层调用rdt_rcv，可靠传输接受数据
- 将包extract解析
- 把数据data传给上传deliver。
学习状态机
以rdt1.0状态机为例，一个圆圈是一个状态，箭头线代表转变为其他状态，如果箭头指向本圆圈，代表继续本状态。
箭头线上的注释，由横线上下方各有内容，横线上方是调用方的操作(发送方上传调用rdt_send)，下方是本层的操作步骤(传输层封装包并调用信道)。
Rdt 2.0: 产生位错误的信道
注意概念，ACK,NAK,ARQ
发送方两个状态:
等待上层调用
- 上层调用可靠传输rdt_send
- 将数据用校验和封装为数据包snkpkt
- 调用不可靠信道udt_send==》变为等待状态。
等待ACK或NAK:
- 可靠传输接受数据rdt_rcv,如果是NAK数据，调用udt_send，重发数据，并且继续进入等待ACK/NAK状态
- 如果接受数据是ACK，则传输层不需要操作，状态变为等待上传调用状态。 rdt_rck横线下方是^,代表传输层不需要操作。
接收方一个状态:
- 等待下层调用:可靠传输接受数据rdt_rcv，如果数据检测校验和有错误corrupt(rcvpkt)，则发送NAK消息udt_send(NAK)要求重传。如果数据校验没错notcorrupt，则解析数据extract,上传到应用层deliver_data,发送ACK数据确认数据正确。
Rdt 2.1和2.2
Rdt 2.0有什么缺陷？
如果ACK/NAK消息发生错误/被破坏(corrupted)会怎么样?ACKNAK消息错误则无法保证可靠传输。有以下几个方法:
- 为ACK/NAK增加校验和，检错并纠错
- 发送方收到被破坏ACK/NAK时不知道接收方发生了什么，添加额外的控制消息
- 如果ACK/NAK坏掉，发送方重传
- 不能简单的重传：产生重复分组。如果接收方已经正确接收数据，但ACK发送错误，导致发送方重复发送数据
采用分组重传，如何解决重复分组问题？
- 序列号(Sequence number): 发送方给每个分组增加序列号
- 接收方丢弃重复分组
发送方状态，随分组数量增加:
- 分组序列号0，等待上层调用传输0分组状态:上层调用rdt_send，传输层将数据校验和封装为包，调用udt_send传输，状态转变为等待0分组的ACK/NAK
- 等待分组0的ACK/NAK消息状态:如果接受到消息并且 (校验错误或是NAK消息)，则调用udt_send 重发分组，继续进入等待ACK/NAK状态；
- 等待分组0的ACK/NAK消息状态:如果接受到消息，并且消息正确，并且是ACK消息，则没有操作，状态进入等待分组1发送状态
接收方状态，随分组数量增加:
- 等待下层传输分组0，如果接收到数据，且校验和错误，就发送NAK，继续等待分组0
- 等待下层传输分组0，如果接收到数据，且校验和正确，且接收到了分组1，则发送ACK。 为什么接收到非期待的分组数据，要发送ACK？接受刅的分组1可能就是重复分组，(2.1解决重复分组用序号)，发送ACK让发送方继续发送个下个分组0，如果发送了NAK，发送方还会发送分组1，这样永远接受不到分组0.
- 等待下层传输分组0，如果接受到数据，且校验和正确，且接收到分组0，则解析包中数据，传递给上层应用，发送ACK消息，状态进入等待分组1
两个序号01够用，序号交替使用。
接收方通过序号解决了重复分组问题，如果序号相同，接收方丢弃，但会发送ACK。
但接收方不知道ACK/NAK是否发送方正确收到，这种事情不能无限校验下去，否则就无线套娃了。
Rdt 2.2: 无NAK消息协议
接受方上次收到0，这次等待1，如果1没正确收到，则发送ACK(0)，发送方就会重发1.
- 发送方发送分组0后，进入等待ACK0状态，如果收到的数据校验和错误或者是ACK1，则重传分组0
- 发送方发送分组0后，进入等待ACK0状态，如果收到的数据校验和正确，并且是ACK0，则进入发送分组1的状态。
- 接受方等待分组1，如果校验和正确，并且分组序号是1，则解析数据给上传应用，并且进入等待分组0状态
- 接受方等待分组0，如果接受数据的校验和错误或者分组序号是1，则发送ACK(1)，等待发送方重传分组0
Rdt 3.0
之前只考虑信道错误，即数据包发生数据错误，没有考虑分组丢失问题。
这个状态机有些疑问：
- 发送方等待上层调用发送0，如果收到rcvpkt包，什么也不做继续等待，是什么意思
- 发送分组0，开启计时器，状态进入等待ACK0
- 等待ACK0，如果接受数据校验和错误，或者是ACK1，什么也不做？不应该重发0分组吗？这个问题下面解释
- 等待ACK0，如果超时，则重发分组0，并且重新计时。
- 等待ACK0，如果校验和正确，序号是0的ACK，则停止计时，状态进入等待发送1分组。
a正常情况，b发送方分组1丢失，超时重传1.
c,接收方发送的ACK1丢失，发送方超时没收到ACK，则重发分组1.
d接收方发送ACK1延迟了，发送方超时重传分组1，发送方会先后两次收到ACK1,发送方在等待ACK0的时候，收到了ACK1，此时发送方什么也不会做！！！除非等待ACK0超时，会重传0。
在rdt2.2之前，发送方假设等待ACK0时，若收到ACK1,会重传分组0，但rdt3.0不重传，因为等待ACK0超时会自动重传，收到ACK1还会继续等待ACK0直到超时重传。如果收到收到ACK1也重传就会重复发送！！！
Rdt 3.0性能分析
意思一个分组很快就能发送出去0.008ms，但在链路上时间需要15ms，等待ACK又需要是15ms，发送方一个分组发出去需要30ms后才能发送第二个分组。
我看着不是rdt3.0的问题，凡是需要等到上个分组的ACK，才能发送个下个分组，这类协议的共同问题。停等协议的公共问题，按道理rdt2.2这些也有这问题。
流水线机制与滑动窗口协议
rdt3.0以前每发一个分组就要等待ACK，流水线同时发送一些分组，然后等待这些分组的ack，如果发送三个，效率就是rdt3.0的3倍
流水线协议
滑动窗口协议
绿色的是已经发送方已经发送并且收到正确ACK的分组，黄色base开始是发送但没有正确收到ACK的分组，蓝色是还可以发送的分组数量，因为要控制正在发送的分组数量即window size为n，最多有n个等待确认的消息
Go-Back-N协议
发送方：
- send_base窗口开始的序列号，nextseqnum是可用发送的分组起始序号，N是最多能发送的没收到ACK分组数量。
- ACK(n)代表n序号之前的分组都正确接收了，跟rdt3.0之前不同，不光代表n这组被正确接收
- 超时后，假设正确接收的ACK最大n是10，会把10以后未收到ACK的全部重发，(这里会很浪费资源)
发送方状态机:
- 最上面开始，上层调用rdt_send发送数据，如果netxtsequm<base+N,这代表窗口还没用满，还可以发送，则使用netxtsequm后的序号制作数据包make_pkt，并调用不可靠信道传输udt_send,此时如果base==netxtsequm则开启计时器(这是什么意思？base代表没有正确接收的分组起始序号，在发送netxtsequm过程中，base分组有可能接收到ACK，所以此时base的值会改变，即窗口往右移，如果窗口起始位置移动到netxtsequm位置，就得重新计时)
- 如果netxtsequm>base+N，代表窗口满了，不能发送，就调用refuse_data拒绝发送
- 如果超时，则把base-netxtsequm中的分组全部重发
- 如果接受到正确的ACK，则调整base，base的值从ACK(n)包中获得，getacknum(rcvplkt)是接收方正确接受的分组序号，base就得在此上+1。如果右移后base==netxtsequm，代表全部分组都正确接受了ACK，就停止计时；如果不相等，则重新开始计时，为什么要重新开始？因为计时的时间不能还是之前base的开始时间，新发的分组还没到规定超时时间，就得重发
接收方状态机:
- 接受到数据校验合正确，并且是期待的序号，就把数据解析，传给应用层，期待序号expectedseqnm++，expectedseqnm-1是正确接受的分组最高序号
- 如果乱序到达的分组，就直接丢弃，GBN协议接受方不缓存，假设接受到456879分组，则expectedseqnm变为7，发送ACK(6),代表6之前的正确接受，7后的乱序到达需要发送方重发
发送方发送分组2丢失，即使成功发送345，接受方也接受到345，但因为2没接受，所以是乱序，接收方依然ACK(1)，接收方把345丢弃了，当发送方base=2超时没接到ACK(2以后的数字），重发2以后的分组。
如果发送方收到ACK023，虽然没收到1，ACK(n)代表n之前的全部正确接受，所以只会把4以后的重发。
Selective Repeat协议
GBN有什么缺陷？重发乱序的全部分组，浪费资源。
SR协议新特点:
发送方窗口:黄色是已发送、没接收到ACK的分组，绿色是已发送、已正确接受ACK的分组，蓝色是可用的剩余窗口大小。
接受方窗口:灰色是期待接受、但没收到的分组，红色乱序接受到了、并且已经ACK的分组，蓝色是可用的剩余接受窗口大小。
发送方:
- 上层调用数据传输，如果窗口有可用的序号n可用于发送，则发送分组n
- 如果分组n超时，则重新发送分组n，并重新计时
- 如果收到分组n的ACK。则标记n为已正确接收分组。如果n是窗口的起始序号，则窗口右移一位。
接收方:
- 当收到分组n，发送ACK(n)表示已收到；如果n是乱序的，则缓存分组n；如果不是乱序，则将分组n以及后面可以连上的分组，一起解析传给上层应用，并且将窗口右移
- 如果收到分组序号，不是在窗口范围内的序号，也要发送ACK，这个为什么没明白？
- 其他情况忽略分组。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
