本科课程：计算机网络（三）
传输层
多路复用
多路分用
传输层的目标：
- provide logical communication between app processes running on different hosts
一、传输层和网络层的关系
network layer：
- logical communication between hosts 主机之间的传输
transport layer：
- logical communication between processes 进程之间的传输
二、传输层的工作流程
transport protocols（TCP、UDP) run in end systems 传输协议工作在端系统
- Send side: breaks app messages into segments, passes to network layer 把应用层的报文分段发送，体现了多路复用
- Receive side: reassembles segments into messages, passes to app layer 再把报文组合起来，发送给应用层，体现了多路分用
三、传输层的多路复用和多路分用
multiplexing at sender 多路复用：
将一个数据包分为多段（在应用层），并为每个数据封装加入头部数据生成一个segment报文段，通过socket接口发送给网络层
demultiplexing at receiver 多路分用:
收到多个报文段，传输层根据头部数据的目标端口号分给不同的socket，再给到相应的进程
1、Connectionless demultiplexing 不建立连接的多路分用（UDP）
UDP protocol is unreliable, unordered delivery
二元组标识：
- destination IP address
- destination port
跟目标的ip地址和端口号有关，跟源地址和端口号无关
2、Connection-oriented demux 面向连接的多路复用（TCP）
TCP protocol is reliable, in-order delivery
四元组标识：
- source IP address
- source port number
- dest IP address
- dest port number
会为每个连接开启不同的socket
服务端有主进程，当外部有报文进来的时候，主进程会创建一个子进程与之通信，所以一个主进程会对应多个socket，每个socket通过四元组属性标识一个源主机（的某个socket）
一般采用多线程机制，线程耗用资源比进程少得多
一个进程对应多个线程，一个线程对应一个socket
四、可靠的数据传输原则
top-10 list of important networking topics
等停协议
reliable data transfer protocol （rdt）可靠数据传输协议
可以令数据在不可靠的信道上进行可靠传输
rdt_send()：接受应用层数据，并发送给rdt协议
udt_send() ：被可靠传输协议调用，在不可靠信道中传输数据
rdt_rcv() ：接收到不可靠信道中数据，并发送给rdt协议
deliver_data()：把data数据抽取出来，并向上传输数据
1、FSM（finite state machines ）有限状态机表示
事件或者操作引起状态1向状态2转变
2、可靠传输协议1.0版本（rdt 1.0）
base on reliable channel 基于可靠传输信道
- no bit errors 不考虑错误
- no loss of packets 不考虑丢包
3、可靠传输协议2.0版本（rdt 2.0）
考虑错误，但不考虑丢包
- checksum to detect bit errors
差错检测，并且发送反馈，如果有错误，发送端重传数据
control message：
- acknowledgements (ACK肯定应答报文): receiver explicitly tells sender that pkt received OK
- negative acknowledgements (NAK否定应答报文): receiver explicitly tells sender that pkt had errors
- sender retransmits pkt on receipt of NAK
收到NAK报文就会重传
FSM 表示
（虚线表示初始状态）
发送方：
wait for call from above //切换状态为等待上层调用
rdt_send(data) //应用层调用
make_pkt(data,checksum) //构建分组报文（加上校验和）
udt_send(sndpkt) //发送
wait for ACK or NAK //切换状态为等待接受应答报文
当有错误时： rdt_rcv() is NAK
udt_send(sndpkt) //重传该分组报文
当没有错误时： rdt_rcv() is ACK
wait for call from above //切换状态为等待上层调用
————————
接受方：
rdt_rcv(rcvpkt) //接收到分组报文
corrupt(rcvpkt) //校验分组报文是否有错
当有错误时：
udt_send(NAK) //发送否定应答报文
当没有错误时：
extract(rcvpkt,data) //进行解包提取出数据
deliver_data(data) //向上层发送数据
udt_send(ACK) //发送肯定应答报文
4、可靠传输协议2.1版本（rdt 2.1）
解决重复接受分组报文→加入分组序号
发送方的FSM
发送方：
rdt_send(data) //应用层调用
make_pkt(0,data,checksum) //构建分组报文（加上校验和以及分组序号0）
udt_send(sndpkt) //发送
wait for ACK or NAK 0 //切换状态为等待接受序号为0的应答报文
当有错误或收到否定应答报文时： rdt_rcv() is NAK or corrupt(rcvpkt)
udt_send(sndpkt) //重传该分组报文
当没有错误时： rdt_rcv() is ACK or corrupt(rcvpkt)
wait for call 1 from above //切换状态为等待上层使用1号分组报文
当使用下一组报文时，序号为1
接收方的FSM
接受方：
Wait for 0 from below //等待接受0号分组报文
rdt_rcv(rcvpkt) //接收到分组报文
corrupt(rcvpkt) //校验分组报文是否有错
has_seq0(rcvpkt) //检查是否是0号分组报文
没有错误且是0号报文：
extract(rcvpkt,data) //进行解包提取出数据
deliver_data(data) //向上层发送数据
make_pkt(ACK,chksum) //构建肯定应答报文报文（加入校检和）
udt_send(ACK) //发送肯定应答报文
Wait for 1 from below //等待接受1号分组报文
有错误：
make_pkt(NAK, chksum) //构建否定应答报文报文（加入校检和）
udt_send(NAK) //发送否定应答报文
分组序号不是预期的：
//丢弃该分组报文
make_pkt(ACK, chksum) //构建确认应答报文报文（加入校检和）
udt_send(ACK) //发送确认应答报文
分组序号是预期的：
extract(rcvpkt,data) //进行解包提取出数据
deliver_data(data) //向上层发送数据
make_pkt(ACK,chksum) //构建肯定应答报文报文（加入校检和）
udt_send(ACK) //发送肯定应答报文
Wait for 0 from below //等待接受0号分组报文
- 发送方两个序号就足够用了
- 发送方需要两个状态机表示
- 不能确定发送方是否正确接受确认/否定报文
5、可靠传输协议2.2版本（rdt 2.2）
只使用ACK肯定报文（NAK-free protocol）
发送方：
rdt_send(data) //应用层调用
make_pkt(0,data,checksum) //构建分组报文（加上校验和以及分组序号0）
udt_send(sndpkt) //发送
wait for ACK or NAK 0 //切换状态为等待接受序号为0的应答报文
收到1号（非预期）的应答报文：
udt_send(sndpkt) //重新发送该报文
收到0号（预期）的应答报文：
wait for call 1 from above //切换状态为等待上层使用1号分组报文
——————————
接受方：
rdt_rcv(rcvpkt) //接收到分组报文
corrupt(rcvpkt) //校验分组报文是否有错
has_seq1(rcvpkt) //检查是否是1号分组报文
分组序号是预期的（1号）：
extract(rcvpkt,data) //进行解包提取出数据
deliver_data(data) //向上层发送数据
make_pkt(ACK1,chksum) //构建肯定应答报文（带序号的ACK1以及加入校检和）
udt_send(ACK1) //发送肯定应答报文
Wait for 0 from below //等待接受0号分组报文
分组序号不是预期的（或重复的）：
make_pkt(ACK1,chksum) //同样使用上面的肯定应答报文
udt_send(ACK1) //重新发送
6、可靠传输协议3.0版本（rdt 3.0）
既考虑有错误，也有丢包
- sender or receiver can also lose packets (data, ACKs)
无论是分组报文还是应答报文都有可能丢包 - add a timer
加入计时器
发送方：
rdt_send(data) //应用层调用
make_pkt(0,data,checksum) //构建分组报文（加上校验和以及分组序号0）
udt_send(sndpkt) //发送
start_timer //开始该报文的一个计时器
wait for ACK or NAK 0 //切换状态为等待接受序号为0的应答报文
收到非预期的（或者重复的）应答报文：
//什么都不做，等待计时器超时
当该报文的计时器超时：
udt_send(sndpkt) //重新发送
start_timer //重新开始一个计时器
收到预期的肯定应答报文：
stop_timer //停止计时器
——————————
接受方：
//跟2.0一样的
//当出现延迟而重复接受分组报文的时候，
因为不能及时收到应答报文，将会重传分组报文，接受方也会重复收到分组报文，因此也会重复发送应答报文
- rdt3.0协议将会占用更多的传输资源
五、流水线传输协议（Pipelined protocols）
- sender allows multiple
流水线技术允许发送方使用滑动窗口技术在收到ACK之前连续发送多个分组。 - range of sequence numbers must be increased
必须增加序号范围，因为每个输送中的分组（不计算重传的）必须有一个唯一的序号，而且也许有多个在输送中未确认的报文 - buffering at sender and/or receiver
协议的发送方和接收方要能缓存多个分组。发送方至少要能缓存那些已发送但没有确认的分组，接收方可能要缓存那些已正确接收的分组
解决流水线的差错恢复有两种滑动窗口协议：回退N步(Go-Back- N，GBN) 和选择重传(Selective Repeat，SR)
1、GBN 回滚（go-back-N）
a.当接收方接受到一个pkt报文时，会对序号为n的分组的确认采取累积确认的方式， 即接受方发送连续的、拥有最高序列号的分组的ACK，表明自己已正确接收到序号≤n的所有分组。
b.重传：发送方每发送一个pkt报文，都会为其设置一个计时器，当计时器超时时将会选择重传该报文
c.产生重复的ACK：乱序到达的分组直接丢弃（接收方无需缓存）重新确认序列号最大的、按序到达的分组
d.缓存：接收到无序的报文时会立即抛弃，接收方没有缓冲区，发送方会设立缓存区保存上层应用发来的数据
- 过于浪费带宽， 许多分组根本没有必要重传
2、SR 选择重传（Selective Repeat）
a.发送方：当从上层接收到数据后，发送方检查下一个可用于该分组的序号，如果序号位于发送方的窗口内，则将数据打包并发送，否则将缓存起来
send_base：基序号（序号最小的已发送报文
nextseqnum：下一个可用的分组序号
b.窗口前移：收到的ACK报文序号等于发送窗口基序号send_base（窗口中最左边的那个序号）, 则整个窗口向前移动到具有最小序号的未确认处
c.缓存：接收到无序的报文时会检查该报文序号是否在接受窗口内（[rcv_base， rcv_base + N-1] ）如果该分组以前没收到过，则缓存该分组，并发送ACK报文。如果该分组序号已经存在，或者是在基序号之前的已接受的分组，也还要重新发送ACK报文。如果是按序到达的（分组序号等于rcv_base基序号），则将以前缓存过的所有连续分组发送给应用。
d.窗口大小：发送方和接收方窗口大小之和应该小于2的k次幂，k是序列号的位数，例如有0，1，2，3四个序号能用两个比特位表示00，01，10，11，k就等于2。如果发送窗口第一个分组没有收到ACK报文的话，就不能往前滑动，必须等到基序号的分组收到ACK报文。
六、传输层的UDP协议
UDP segments may be:
- lost packet
- delivered out-of-order 有可能导致接收方接受报文时无序，这时候应该
UDP used：
- streaming multimedia apps
- DNS
- SNMP
UDP 报文头
length：in bytes of UDP segment, including header 用户数据报的总长度，以字节为单位
checksum：detect “errors” in transmitted segment 检测 UDP 用户数据报在传输中是否有错
UDP中的校验和机制
UDP的校验和 = 伪首部 + 首部 + 数据部分，一起都检验
伪首部：
UDP检验和的计算方法是：
- 按每16位求和得出一个32位的数；
- 如果这个32位的数，高16位不为0，则高16位加低16位再得到一个32位的数；
- 重复第2步直到高16位为0，将低16位取反，得到校验和。
七、传输层的TCP协议
- reliable 可靠的传输
- pipelined 采用流水线协议
- full duplex data 全双工传输
- P2P 点对点传输
- connection-oriented 面向连接的
- flow controlled 使用流量控制解决拥塞问题
1、segment structure 报文结构
source port ：源主机端口号（占用两个字节16位）
dest port ：目标主机端口号（占用两个字节16位）
sequence number ：本报文数据中（application data）的第一个字节在数据流中的序号 ，一般的起始序号是随机生成的（占用四个字节32位）
acknowledgement number ：接收方期望收到的下一个报文数据第一个字节的序号（占用四个字节32位）
head length ：报文首部长度 / 数据偏移地址。（占用4位）偏移地址最长60字节 ？？？
not used：保留字段（占用6位）
URG ：紧急字段，值为1时紧急数据（urg data）有效（占用1位）
ACK ：确认应答，值为1时为确认应答报文（占用1位）
PSH ：立即提交字段，值为1时将尽快提交该报文（占用1位）
RST ：重连字段，重新建立连接（占用1位）
SYN ：同步字段，值为1时表示该报文是连接请求（占用1位）
FIN ：终止标志字段，值为1时释放该连接（占用1位）
receive window ：窗口字段，表示接收方缓存的大小（占用两个字段16位）
checksum ：校验和字段（占用两个字段16位）
Urg data point ：应急数据指针字段，指向应急数据最后一个字节，表明了它的大小，应急数据通常是在数据刚开始的地方（占用两个字段16位）
options：选项字段（长度可变，加入填充字段令其严格等于32位的倍数）
发送方序号seq是42，并且只发送了一个字节”C“，因此接收方返回的ACK是42+1=43，发送方的ACK表示其下一次预期收到的seq序号，即seq=79
同理，发送方收到接收方的报文后，因为还是传输的一个字节，再次发送报文
ACK=B.seq+1，Seq=B.ACK
2、TCP的计时器
- RTT(Round-Trip Time)往返时间：表示从发送端发送数据开始，到发送端收到来自接收端的确认（总共经历的时间。由三个部分决定：链路的传播时间、末端系统的处理时间、路由器的缓存中的排队和处理时间
- TCP定时器超时时间应该大于RTT时间（Round-Trip Time 往返时间）
- 发送多个测试报文确定该网络下的RTT时间（每隔一个时间段不断修正均值）
- 确定RTT时间应该取均值，
EstimatedRTT = (1- a)EstimatedRTT + aSampleRTT，a=0.125
- RTT的安全边界：
DevRTT = (1-B) * DevRTT + B * | SampleRTT - EstimatedRTT |，B=0.25 - 最终的RTT时间是：
TimeoutInterval = EstimatedRTT + 4 * DevRTT - 假如计时器时间太短：
premature timeout, unnecessary retransmissions 过早超时导致不必要的重传 - 假如计时器时间太长：
slow reaction to segment loss 对丢包现象反应过慢
3、reliable data transfer 可靠数据传输
TCP可靠传输建立在不可靠传输链路上：
- pipelined segments 流水线协议
- cumulative acks 累计确认
- single retransmission timer 单一计时器
- select retransfer 选择重传
fast retransmit 快速重传
if sender receives 3 ACKs for same data , resend unacked segment with smallest seq #
绕过计时器超时，一旦有3个重复的ACK应答报文就立即重传该报文
很显然，快速重传的时间比等待计时器快很多
4、flow control 流量控制
receiver “advertises” free buffer space by including rwnd value in TCP header of receiver-to-sender segments
sender won’t overflow receiver’s buffer
在建立连接的三次握手中，发送方会在握手包中附带 receive window 缓冲区大小参数 ，以限制发送方传输的速率
rwnd 参数
接收窗口[rwnd] 参数反映的是接收方当前的接收缓冲区大小，发送方不会同时发送超过这个大小的数据，它在 wireshark 里对应的是 window size value ：
那还有一个参数 calculated window size ，它才是实际的接收方缓冲区大小，是用底下 option 字段中的window scale 参数作为倍数，放大 window size 值的，所以window size value表示报文的值，calculated window size表示放大后的值，也就是实际可用的值
其原因是由于TCP的头部窗口字段只有16bit，最多表示64k,为了表示更大的窗口，使用了可选的放大倍数
cwnd 参数 / 拥塞控制
cwnd参数用于慢启动机制中，表示发送方在得到接收方确认前，最大允许传输的未经确认的数据（拥塞窗口大小），它不出现在TCP报文中，是发送方的内部参数。
cwnd 参数是根据网络情况动态调节的。关于cwnd拥塞窗口介绍在下文的 八-4 中有更详细的介绍。
参考文献：TCP 协议中的 Window Size与吞吐量
5、connection management 连接控制
建立连接（三次握手）
Socket connectionSocket =
welcomeSocket.accept()
再运行客户端发送端口：
Socket clientSocket =
newSocket("hostname","port number");
TCP的三次握手机制：
二次握手的问题：
variable delays //C-S两端不一致的时延
retransmitted messages due to message loss //丢包重传导致资源浪费
message reordering
can’t “see” other side
SYN 同步标识位置1表示这是一个握手包
Seq是该报文的序号，其初始值x、y是随机生成的，防止被攻击
ACK确认标识位置1表示接收方收到报文，ACKnum有效
ACKnum是确认序号，也是下一次期待接受的序号 x+1 （x为接收到报文的Seq加上接收到的报文的长度）
——————————
在wireshark里长这样：
——————————
FSM状态机表示：
关闭连接（四次分手）
当FIN置1时，表示该报文请求关闭连接
发送方在收到接收方的应答报文后不再主动发送数据，而是在一段时间内等待接收方再次发送一个请求关闭的报文，这是防止在关闭过程中有丢包，如果超时了没收到，就会重发带FIN置1的关闭报文。
该计时器的时间是 2 倍的最大报文传输时间
（ timed wait for 2*max segment lifetime）
八、principles of congestion control 拥塞控制
拥塞定义： too many sources sending too much data too fast for network to handle 链路中传输的数据过多，处理不过来
网络拥塞会导致丢包和延迟，表现为：
1、buffer overflow at routers 路由器缓存发生溢出
2、queueing in router buffers 路由器缓存发生排队
“costs” of congestion:
1、more work (retrans) for given “goodput”
2、unneeded retransmissions: link carries multiple copies of pkt
拥塞产生的原因：
- 当A主机向C主机发送数据占用了路由器L1的全部缓存时，D主机向B主机发送的数据将会被阻塞，在路由器L1里被丢弃，造成严重丢包。
- 又或者是当A主机→B主机发送数据占用了链路的全部带宽，导致了D主机→B主机所共用的路由器L1左侧的链路不通，也会造成时延过大。
1、end-end congestion control 端对端拥塞控制
发送方通过判断是否丢包严重 / 时延过大，来确定是否产生了拥塞
2、network-assisted congestion control 网络辅助拥塞控制
路由器向发送方提供网络情况反馈，
2-1、ABR（available bit rate） congestion control 动态带宽速率拥塞控制
- elastic service 弹性的服务
- 当发送方未过载时，不限带宽（use available bandwidth）
- 当发送方阻塞时，将带宽速率降至最低保障速率（throttled to minimum guaranteed rate）
2-2、CBR 恒定的带宽速率
2-3、VBR 可变速率
2-4、UBR 速率未指定
3、RM cells & data cells 资源管理信元和数据信元
RM (resource management) cells：
- 分散在 data cell 中
- 由交换机设置标志位
- NI标志位：没有增量，当交换机预测紧急拥塞时，这些设备典型地设置NI位
- CI标志位：拥塞指示，减少发送流量
- ER标志位：明确信元速率
- EFCI：明确正向拥塞指示，让接收方的CI标志位置1
4、TCP congestion control TCP的拥塞控制
按照拥塞控制方法的不同，现行使用的TCP分为几个版本：Tahoe，Reno，NewReno，Vegas，SACK 等。
下面主要讲的是Reno版本的TCP拥塞控制机制。
通过控制拥塞窗口（发送窗口）的大小来控制发送速率。
- additive increase 加性增
increase cwnd by 1 MSS every RTT until loss detected
每收到一次RTT报文增加一倍的MSS（最大分段大小）发送窗口容量，直到检测到丢包 - multiplicative decrease 乘性减
cut cwnd in half after loss
一旦有丢包就减去一半的发送窗口容量
- cwnd 窗口 >= LastByteSent - LastByteAcked （图中黄色加蓝色的部分，蓝色部分是空闲部分）意思是 cwnd 窗口一定保留有空闲部分
- TCP 发送的速率约等于 cwnd / RTT
TCP拥塞控制机制方法主要分为如下4个阶段：
- Slow-start 慢启动阶段
- Congestion Avoidance 拥塞避免阶段
- Fast Retransmission 快速重传阶段
- Fast Recovery 快速恢复阶段
慢启动机制 & 阻塞控制
虽然流量控制可以避免发送方过载接收方，但是却无法避免过载网络，这是因为接收窗口「rwnd」只反映了服务器个体的情况，却无法反映网络整体的情况。cwnd 参数的初始值往往比较小，然后随着数据包被接收方确认，窗口成倍扩大，所以被称为慢启动
- initially cwnd = 1 MSS 初始cwnd值为一个MSS大小
- double cwnd every RTT 之后成倍增加
- done by incrementing cwnd for every ACK received 在收到ACK应答报文后执行增加操作
- grows exponentially to threshold, then grows linearly 以指数方式增加到一个设定的阈值大小后，将变为线性增加
像下图的蓝色部分：
那么红色部分就是随着「cwnd」的增加，当出现网络过载，丢包后，「cwnd」的大小会减少至一半，即把cwnd增加的阈值。
- 丢包分两种，一是超时，Reno和Tahoe的阈值都减半，拥塞窗口都=1
- 二是三次重复应答，Tahoe阈值减半，拥塞窗口=1
，而Reno阈值减半，拥塞窗口减半
参考文章：Maximum Segment Size，TCP一次传输发送的最大数据段长度
九、TCP throughput 吞吐率计算
- W：window size
十、TCP Fairness 公平性原则
if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K
通过增性加乘性减，两个应用使用的带宽逐渐趋向于相等
- 在每一次丢包后（TCP协议会让他收到三次重复），横坐标纵坐标都减半，然后再以k=1线性增加