计算机网络知识点及例题总结（三）传输层

知识点部分

1.传输层服务

传输层协议为运行在不同Host上的进程提供了一种逻辑通信机制，两个进程之间仿佛是直接连接的，也是一种端到端的连接。
端系统运行传输协议，①发送方传输层：将应用递交的消息分成一个或多个的Segment，并向下传给网络层②接收方传输层：将接收到的segment组装成消息，并向上交给应用层。传输层可为应用提供多种协议：Internet上的TCP，UDP。
网络层VS传输层——区分
网络层提供主机（IP地址）之间的逻辑通信机制
传输层提供应用进程之间的逻辑通信机制
网络层VS传输层——联系
传输层位于网络层之上
传输层依赖于网络层服务
传输层对网络层服务进行增强

传输层协议——TCP服务（可靠，按序的交付服务）
面向连接
可靠的传输
流量控制
拥塞控制
不提供时间/延迟保障
不提供最小带宽保障
传输层协议——UDP协议（不可靠的交付服务）
无连接
不可靠的数据传输
以上两种均不保证延迟，带宽。

2.多路复用与分用

接收端多路分用，发送端多路复用。
多路分用：主机收到IP数据报（报文段）[每个数据报（数据报格式详见下面7）携带源IP地址、目的IP地址；每个数据报携带一个传输层的段Segment；每个段携带源端口号和目的端口号]；主机收到Segment之后，传输层协议提取IP地址和端口号信息，将Segment导向相应的Socket（TCP做更多的处理），网络层不关心端口号。
无连接分用（UDP）：利用端口号创建Socket→UDP报文段中的目的Socket用二元组标识（目的IP地址，目的端口号）→主机收到UDP段（检查报文段中的端口号，将UDP导向绑定在该端口号的Socket）→来自不同源IP地址和/源端口号的IP数据包被导向同一个Socket（SP：源；DP：目的）
面向连接的分用(TCP)：TCP的Socket用四元组标识（源IP地址，源端口号，目的IP地址，目的端口号）→接收端利用所有的四个值将Segment导向合适的Socket→服务器可能支持多个TCP Socket（每个Socket用自己的四元组标识）→Web服务器为每个客户端开不同的Socket

3.UDP协议

提供功能：①基于Internet IP协议（复用/分用，简单的错误校验）
②“Best effort”服务（UDP段可能丢失，非按序到达）
③无连接（发送方和接收方不需要握手，每个UDP段的处理独立于其他段）
应用场景：①流媒体应用（容忍丢失，速率敏感）②DNS，SNMP
在UDP上实现可靠传输：①在应用层上增加可靠机制
②应用特定的错误恢复机制
报文格式如图。

UDP校验和（checksum）：检测UDP段在传输中是否发生错误（比如位翻转）.

发送方
将段的内容视为16-bit整数，
校验和计算：计算所有整数的和，进位与和相加，将得到的值按位求反，得到校验和，发送方将校验和放入校验和字段。
接收方
计算所收到段的校验和
将其与校验和字段进行对比
不相等：检测出错误
相等：没有检测出错误（但可能有错误）

4.可靠数据传输基本原理

可靠：准确（没有位错误）、完整（没有丢包）、有序（分组有序）。
可靠数据传输协议（Rdt）:对应用层，传输层和链路层都很重要；信道不可靠决定rdt复杂。
基本结构—接口：
注意图中四个协议箭头分为单向箭头和双向箭头。

①rdt_send( )
②udt_send( )
③rdt_rcv()
④deliver_data( )

关于设计可靠数据传输协议（rdt）：用FSM刻画rdt。
Rdt1.0:最简单情况，底层信道完全可靠。假定接收方和发送方的数据传输率一致。
发送方rdt_send()接受上层的数据，产生一个分组（make_pkt）发送到信道上；
接收方rdt_rcv()从底层信道接受一个分组，从分组中取出数据（extract），之后将数据传输到较高层。

Rdt2.0:假设底层信道有“比特可能受损”，增加差错检测，接收方反馈，重传。差错检测可以使用检验和，接收方反馈的情况无非就是“肯定确认”（ACK）和“否定确认”（NAK）。当发送方接收到接收方反馈回来的NAK消息时，发送方重传该分组。
此时发送方有两个状态，从上层应用接收数据发出分组后，需要等待ACK或NAK传回才会发送下一个分组，这种在等待ACK和NAK时接受上层数据的情况称之为停等协议。
缺陷：没有考虑到ACK或NAK会受损。

Rdt2.1:rdt2.0改进，给分组增加***seq，因为停等，所以我们只需要0和1即可编号。因为只有接收方和发送方都确认该分组传输完成了，才会传输下一个分组。只要前后两次分组的编号是不同的即可，不需要管分组编号是否重复。（图示为rdt2.1顺序发送方，接收方）
需要注意的是当接收方接收到的分组是失序的（也就是它正确接受了上一个分组），它返ACK，当然也必须这样返回，因为这就是出现了第一次返回ACK受损。如果序号正确，但是分组受损，那么返回一个NAK消息。如果不返回NAK，而是返回对上一个正确接受分组的ACK，这也能实现一样的效果。因此接收方只返回ACK即可（rdt2.2），如果返回的ACK中的编号是发送方刚才发送的，那么说明接收正确；如果返回的ACK的编号是上次发送方上一次发送的数据编号，那么说明接受错误。

Rdt3.0:假定底层信道既可能产生传输误差，也可能丢失（数据丢失，接收方一直等待无ACK返回），发送方需要在合理时间等待ACK，超出即重传，所以引入定时器。但是rdt3.0的性能很差，这是由于它是一个“停等”协议，它需要停下来等待接收方返回的ACK（如示例分析性能）
RTT=15x2=30(发送方到接收方，接收方返回消息到发送方两个来回)

5.停等协议

详见4中rdt2.0。

6.典型的滑动窗口协议

滑动窗口协议：窗口指允许使用***范围，窗口尺寸为N，则最多有N个等待确认的消息；滑动窗口指随着协议进行，窗口在***空间内向前滑动。

绿色：发送并已经确认；黄色：发送未确认；蓝色可用***；白色为可以使用的***；Base：尚未确认的最小号，nextseqnum：尚未使用但可以用的最小号

典型滑动窗口协议——回退N步协议GBN
GBN协议采取了累积确认，当发送方收到一个对分组n的ACK的时候，即表明接收方对于分组n以及分组n之前的分组全部都收到了。
对于超时的触发，GBN协议会将当前所有已发送但未被确认的分组重传，换句话说，如果当前窗口内都是已发送但未被确认的分组，一旦定时器发现窗口内的第一个分组超时，则窗口内所有分组都要被重传。每次当发送方收到一个ACK的时候，定时器都会被重置。
GBN协议对于接收方则相对比较简单，接收方只需要按序接收分组，对于比当前分组序号还要大的分组则直接丢弃。
缺陷：重传许多分组。

例题：

数据链路层采用后退N帧（GBN）协议，发送方已经发送了编号为0～7的帧。当计时器超时时，若发送方只收到0、2、3号帧的确认，则发送方需要重发的帧数是多少？分别是那几个帧？
答案：4，5，6，7号帧。

典型滑动窗口协议——选择重传协议SR
SR协议允许接收方对于超前分组的到达返回ACK，则发送方就会出现在收到分组n的ACK之前接收到分组n＋1的ACK的情况。
发送方需要做到：为每一个已发送但未被确认的分组都需要设置一个定时器，当定时器超时的时候只发送它对应的分组。当发送方收到ACK的时候，如果是窗口内的第一个分组，则窗口需要一直移动到已发送但未未确认的分组序号。
接收方需要做到：维护一个接收窗口（注意，在之前的协议之中，接收方都只需要维护当前分组的序号即可）。当分组序号在接收窗口之内的时候，返回该分组的ACK并视情况移动接收窗口，而如果分组序号在分组之前（冗余分组），返回该分组的ACK。
注意：接收窗口内不能出现两个分组的相同序号，否则接收方无法辨认需要对一个冗余分组的ACK还是对一个新的分组的ACK，因此，接受窗口长度必须小于或者等于序号空间的一半。

7.TCP段结构（报文段）

源端口号/目的端口号: 表示数据从哪个进程来, 到哪个进程去.
4位首部长度: 表示该tcp报头有多少个4字节(32个bit)
6位保留: 先保留着, 以防万一
16位检验和: 由发送端填充, 检验形式有CRC校验等. 如果接收端校验不通过, 则认为数据有问题. 此处的校验和不光包含TCP首部, 也包含TCP数据部分.
16位紧急指针: 用来标识哪部分数据是紧急数据.
6位标志位：
①URG: 标识紧急指针是否有效
②ACK: 标识确认序号是否有效
③PSH: 用来提示接收端应用程序立刻将数据从tcp缓冲区读走
④RST: 要求重新建立连接. 我们把含有RST标识的报文称为复位报文段
⑤SYN: 请求建立连接. 我们把含有SYN标识的报文称为同步报文段
⑥FIN: 通知对端, 本端即将关闭. 我们把含有FIN标识的报文称为结束报文
***和ACK（与段结构无关）：***指segment中第一个字节的编号，不是segment的编号，建立TCP连接时，双方随机选择***；ACK指希望接收到的下一个字节的***，累计确认，该***之前均已被正确接收到。

8.TCP连接管理（三次握手，四次挥手）

①三次握手建立连接
第一次: 客户端（发起者）- - > 服务器 服务器知道了客户端要建立连接了（SYN=1 seq=x）
第二次: 服务器 - - > 客户端 客户端知道服务器收到连接请求了 （SYN=1 ACK=1 seq=y ack=x+1）
第三次: 客户端 - - > 服务器 服务器知道客户端收到了自己的回应（ACK=1 seq=x+1 ack=y+1）
此时，可以认为客户端与服务器建立了连接，可以开始数据传输。
详细过程：刚开始, 客户端和服务器都处于 CLOSE 状态.
此时, 客户端向服务器主动发出连接请求, 服务器被动接受连接请求.
1, TCP服务器进程先创建传输控制块TCB, 时刻准备接受客户端进程的连接请求, 此时服务器就进入了 LISTEN（监听）状态
2, TCP客户端进程也是先创建传输控制块TCB, 然后向服务器发出连接请求报文，此时报文首部中的同步标志位SYN=1, 同时选择一个初始*** seq = x, 此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定, SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
3, TCP服务器收到请求报文后, 如果同意连接, 则发出确认报文。确认报文中的 ACK=1, SYN=1, 确认序号是 x+1, 同时也要为自己初始化一个*** seq = y, 此时, TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据, 但是同样要消耗一个序号。
4, TCP客户端进程收到确认后还, 要向服务器给出确认。确认报文的ACK=1，确认序号是 y+1，自己的***是 x+1.
5, 此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。
②四次挥手关闭连接
数据传输完毕后，双方都可以释放连接.
此时客户端和服务器都处于ESTABLISHED状态，客户端主动断开连接，服务器被动断开连接.

Step1:客户端向服务器发送FIN通知关闭
Step2:服务器收到FIN，发送确认ACK
Step3:客户端收到FIN，回复ACK。进入“等待”，如果收到FIN会重发ACK
Step4:服务器收到ACk，连接关闭

9.TCP拥塞控制基本原理和方法

拥塞：太多发送，主机发送了太多数据或者发送速度他快，以至于网络无法处理。
拥塞表现：分组丢失（路由器缓存溢出），分组延迟过大（在路由器缓存中排队）
拥塞原因：资源的需求＞可用资源
拥塞控制作用：拥塞控制就是防止过多的数据包进入网络，这样可以使网络中的路由器或者链路不至于过载。拥塞控制的前提就是网络能够承受现有的网络负荷。
TCP拥塞控制基本原理：让每个发送方根据感受的网络拥塞程度来限制其向连接发送流量的速率。CongWin(拥塞窗口).

AIMD加性增—乘性减
原理：逐渐增加发送速率，谨慎探测可用带宽，直到发生丢失loss。
AI：每个RTT将CongWin增大一个MSS（最大报文长度）即拥塞避免。
MD:发生loss将CongWin减半。
拥塞避免的思路：
（1）最初让拥塞窗口按照指数级增长（慢启动），这样可以提高发送数据吞吐量；
（2） 当拥塞窗口大小到达慢启动门限后，改成线性增长(AI)，目的减少拥塞窗口的增长速度；
（3）当发送端检测的网络拥塞时，立即把拥塞窗口减小变为1，把慢启动门限调整为出现拥塞时拥塞窗口的一半目的是可以减少向网络中注入的数据量。
（4）重新开始指数级增长和线性增长。

例题：

重传超时时间：最初默认为6s，之后通过报文的往返时延加上偏差确认。
设CongWin=W，时延RTT，最大报文长度MSS（1byte=8bits），吞吐率throughput(bps或吞吐量=吞吐率x时间，即1s时间传输的数据量)。超时后，CongWin=W/2，吞吐率=W/2RTT。
平均窗口大小：We=0.75W，平均吞吐率=0.75W/RTT，丢包率L=2*10^(-10)