计算机网络——第三章（传输层）

文章中所有图片均来自中科大郑烇教授在b站发布的——“中科大郑烇、杨坚全套《计算机网络（自顶向下方法 第7版，James F.Kurose，Keith W.Ross）》课程”

计算机网络——第三章（网络层）

概述传输层服务

传输层需要完成两个网络进程之间的通信，同时需要结合当前网络的情况，完成拥塞控制

传输层以报文段为单位，主流的有TCP报文段和UDP报文段，报文段也就是将上层的应用数据报文，切割为多个段的形式

传输层的主要工作就是传输，主要是为两个主机提供端到端的通信

在此处的类比，网络层相当于送信的快递员，将一个主机上的数据传送到另一个主机，而传输层主要是进行下面的分发工作，也就是指明自己从对方主机的那个进程来，要到本端主机哪个进程去。这个也就是socket维护的多元组，只需要将收到的传输层报文携带的端口和主机号和本端主机的socket对比就可以找到对应的会话

传输层需要完成上述的工作，有多个协议可以将报文送达，但是需要根据应用的使用场景来对应使用适合自己的协议

复用和解复用：

从不同的套接字中接收数据，给每个数据段封装上对应的tcp/udp报文头部，然后交给网络层的过程

解复用就是通过对应的传输层报文头部信息，和ip对应找到对应的需要找到的socket，交给对应它的过程
tcp：客户端通过和服务器建立socket连接，发送数据到服务器，服务器除去ip层到达传输层，通过对应自身端口，自身ip，对端ip和端口，找到对应的socket，将其交给对应的进程。（这里为啥需要比较自生ip，当时想了很久，其实原因很简单，因为一个主机可能有多个ip，从网络接口进入到网络层，再到传输层，这时候操作系统的对于段报文统一处理的，不同的本端ip虽然是相同的端口对应的可能就是不同服务）
udp：udp主要是通过目标ip和目标端口来觉得交给那个一socket对应的进程

无连接传输UDP

对于实时性较强，但是对于传输的质量要求不高的程序，可以使用udp协议

虽然udp协议的准确性不高，但是因为速度快的特点，成为我们生活中的常用协议

当校验和未通过就丢失报文，双方对于收到的数据做相同的运算对比校验和就可以得到是否发生了传输错误

将数据分为多个16比特，相加，当出现了最高位进一，就将最高位的数据作为最低位的进位数

可靠数据传输原理（RDT）：

也就是如果通过传输层将数据原封不同的传输到对端
发送方通过可靠的数据发送接口（rdt_sent）发送到本侧的传输层，对方通过可靠的数据接收（rdt_rcv）将数据接收到

由此，我们可以看出，数据是否可靠传输，不止是传输层的事，如果网络层提供了可靠数据传输服务，那么就不需要传输层插手了，但是为什么不能使用网络层作为可靠数据传输的层次呢？因为网络层作为寻路的层次，期间数据包需要经过多个网络中的中间节点，如果再网络中需要提供可靠数据传输服务，这就需要在网络层进行重发，既然需要重发，那就需要保存发送的数据，这就导致网络层设备的负担大，一个小小的路由器，需要将每次接收，寻路，发送的数据完整的保留下来，然后如果发送了错误还需要重传，这显然是不现实的

使用有限自动机的方式来表示当发送某个实现需要做出对应的那个动作然后转变到那个状态

可靠数据传输协议1.0

当下层不会发生出错的情况，在这种情况，发送方只需要接收数据和封装数据，然后通过原语将数据传输给下层；接收方只需要接收数据和解封装数据

可靠数据传输协议2.0

当下层可能出现比特反转，进行EDC校验，接收方接收到需要校验，通过这个发送对应的正确包和错误包；发送方保存副本，当收到错误包就重传

发送方发送，等待；接收方接收，校验发送nck/ack；发送方收到nck/ack，重新发送/发送下一个包

但是这个协议还是存在问题，当ack/nak报文出错，这时发送方不能确认是否需要重传，可以采用分组编号的方式，当发送方接收到一个不确定的报文，就将报文重传一遍；然后接收方再次收到上一个报文如果之前发送的是nck就可以再次校验接收，如果之前发送的是ack就再次将ack重新发送一遍，通过这个序号，接收方可以知道是否发送方发送的是一个重复的报文

可靠数据传输协议2.1

需要等待对方确认才能继续发送，这样的协议叫做停止等待协议


正上：当接收到数据包，数据包正确，且具有序号0（提取数据，发送数据，制作ack包checksum，发送nck包），到达状态1
右边下：当在状态1，收到数据包0，就将ack包重发一遍
在停止等待协议中可以使用一位来确定包


接收方没有对于ack/nck包的确认，但是可以通过接收方的动作来判断是否收到了数据包；如果自生发送了ack，对方发送了下一个包，那么对方收到了ack，反之，如果对方发送了当前包，那么对方收到的ack中途错误了；如果自生发送了nck包，无论对方是否正确的收到了nck都会重发，除非中途发送了比特反转，而且反转发送的情况恰好变为了正确ack对于的数据，而且还要恰好通过了校验，这种可能性显然微乎其微。

可靠数据传输协议2.2

接收方没有nck包，使用当前接收到的最后一个正确分组的ack包替代，这样可以保证当接收方收到了冗余的分组ack，可以确认当前发送的数据包错误
当接收方收到错误的数据包，通过发送其他的状态的数据包的正确确认来提示发送方，当前发送数据包错误

可靠数据传输协议3.0

当下层信道存在数据包丢失的情况，如果ack/nck包丢失，使用上面的协议显然会死锁，所以增加超时重传机制来保证数据包不会丢失，接收方当发送一个ack/nck包开始，在一个比较正常往返的时间多一点的时间内，没有收到下一个包就重新发送ack/nck

增加了start_timer，timeout，stop_timer


这又带来的其他问题，超时时间如果合理设置，如果一个包只是在timeout时间外到达，因为是没有nck数据包的，这就导致，接收方接收到对方发送的不同当前状态的ack就重新发送一个上一个数据包，这显示是非常影响效率的。（这个问题在下面会解答）
在停止等待协议中，一个分组从网络中发送的时间如果网络的传输速度上图所示，那么一个8kb的分组只需要主机或中间节点传输8纳秒，而利用率显然是将一个rtt时间（发送到对方的时间）加上使用了的时间，相除得到的就是一次传输网络的利用率，也就是在主机的网口用于工作的时间占一个包完成一个数据传输需要的时间的比率。
显然是因为停止等待协议，导致利用率低下，因为每次传输一个分组，然后网口就进入了等待

可靠数据传输协议4.0

使用流水线协议，也就是即使对方没有确认，自生仍然发送数据包，在此之前需要了解一个滑动窗口的概念

发送缓冲区中的数据分为两类：没有发送的；发送了没有收到确认的。如果数据在滑动窗口的范围内，表示的就是数据发送但是没有收到确认

滑动窗口存在相对滑动（窗口滑动）和真正滑动（内存滑动），只是为了表示方便，我们使用的是相对滑动


发送一个数据，前沿沿向前




滑动窗口的发送端总是向上面那样，但是，接收端因为协议的不同存在区别

GBN协议为接收端滑动窗口为1，SR协议为接收端滑动窗口大于1，当发生和接收端的窗口大小都为1就是停止等待协议了

当接收窗口的大小为1，表示的就是每次只能确认一个数据包，也就是说需要顺序接收；当接收窗口大小大于1，表示可以接收的数据可以有多个，只要满足其中一个序号的就可以接收。

之后接收到了最小序号的数据报，接收窗口才能向后滑动，这就导致如果窗口为1，表示前面的数据都接收到了，也就是累计确认；如果窗口大小大于1，发回的确认包只能表示对方收到了对应数据包，因为存在收到后面没有收到前面



GBN为接收窗口为1，表示为累计确认，如果收到的数据包没有在范围内，抛弃
发送时，发送方在发生第一个数据包时计时，如果再指定时间内，第一个数据包的ack没有回来，可能表示第一个数据包没有被收到（可能存在ack丢失情况），将所有后沿到前沿的数据包重发，因为前面没有接到，后面就一定不可能被接收了。

发生时，每个数据包都有自己的计时器，在指定范围内没有ack就重传

面向连接的TCP协议：

应用将报文通过原语交给传输层，原语通过将报文分为若干个MSS（报文段最大长度）大小的数据段，每个数据段封装上TCP的头部

其中的没有界限，是相对于UDP来说的，因为UDP是基于报文段来传输的，将整个报文段封装为一个IP包，而TCP以流来传输，可以将一个报文段分为多个IP数据包发送，也可以将一个报文段作为一个IP包发送。
因为网络层存在MTU（最大传输单元）的限制，就导致了，当应用进程交付的数据过长，必须将数据报切割
MSS+TCPhead/UDPhead+IPhaed=MTU
TCPhead为20字节，IPhead为20字节 MTU为1500 所以TCPMSS为1460

序号：将数据报分为多个段，body部分在整个连接通信的偏移量就是序号
确认号：当接收方发送确认号555，表示接收方接收到554及之前的数据，需要将ACK标志位置1

TCP采用的是累计确认的方式，但是有不想单纯的GBN协议，接收方的滑动窗口可以有多个，这样可以成为可以乱序收到数据包，但是依然发送收到的最小序号的ACK，来提示前面的数据没有被收到，但是后面的一些数据自己已经收到了，以此敦促发送方尽快的进行重发

Ha发送序号为42，确认号为79，表示发送的数据是从42开始的，已经收到78及之前的数据
Hb发送序号为79，确认号为43，表示发送的数据是从79开始的，已经收到了42及之前的数据

如何合理的设置TCP的往返延时时间

通过每向前推进一个时刻，将时间乘（1-a）这样保证了之前的时间，对于平均值的影响逐渐变小，得到往返延时的移动平均值，通过这样的方式，可以保证当前测试得到的RTT（sampleRTT）对于estimatedRTT的影响最大，而上一个时刻的时间的影响也就相对于当前较小，以此我们可以推出，上上个时刻的影响对于当前时间影响为(1-a)(1-a)，这样就可以将测试得到的时间较为公正的反映当前网络状况。

在通过这样的滑动方式，算出一个边距值，通过我们的EstimatedRTT加上4倍边距值得到的就是相对合理的超时时间

TCP协议有对GBN，SR协议进行学习；当TCP发送方收到一个最小的ACK确认，和GBD协议一样，将计时器停止，然后如果窗口的前沿不等于后沿，就重新开始一个计时器，作为下一个报文的超时记录
TCP的接收方：如果收到乱序的报文段，可以选择接收也可以选择不接受
TCP只有一个定时器，只将最老的段重发一遍
当超时定时器，但是发送方收到3个该报文的冗余ack，表示接收端收到了多个大于期望的数据包，这是发送方重发一遍该报文

对于上图的有限自动机解读：当从开始进入到状态中，获得一个初始序列号，也就是自己需要发送到对方的序号（为什么要随机，而不是从0开始，在后面讲）将窗口的前后沿设为这个值，当从应用层收到数据，进行tcp的封装，发送到ip层，将前沿前移，如果没有开启计时器就开启。当发生了时间超时，将最小没有被确认的报文重新传输（后沿位置开始的包）。当收到ack数据包且在后沿之后，将后沿的数据设为发送来的确认号，如果这时候前沿后沿相等，停止计时器，否则重新开始一个计时器。


需要明确的是，只有接收方收到了对应的数据报文，才会发送对应的ack确认包，所以接收方完全可以相信如果发送方发送了ack120，前面的所有数据接收方都收到了
接收方当收到一个段的报文，首先不发送ack而是进行一段延时，当下一个段也发来了，才进行ack确认，这样减少了网络上的ack数量，且对端接收工作也少了一半。

快速重传指的就是当发送方收到三个冗余的ack，即使没有到达超时时间也进行重传，因为收到三个冗余ack表示的就是接收方收到了三个后面的段，但是前面的段仍然没有收到

TCP的流量控制主要就是为了防止，当发送端的发送过快，但是接收端的接收窗口（也可以说是接收缓冲区，前面说明了滑动窗口在接收端就是缓冲区大小）不够导致了数据溢出。使用TCP报文中的一个字段接收窗口，来传输。

在正式交换数据之前，tcp需要连接连接

两次握手导致的问题，当发送方发送的第一个建立连接的报文的回复到接收方的时间较晚，导致了发送方的重传，这样如果双方完成通信后断开连接，而这时，发送方的第二个连接报文到达，导致的就是服务器维护了一个半连接。



当加入了第三次握手就可以避免上述的问题


tcp的断开机制是双方独立发起fin报文，表示本方在此处连接中，没有任何数据再发送。较早结束的那一端需要在对方发送了fin包，然后自身确认后等待两个RTT时间，这样是为了保证自身确认断开连接的ack包不会丢失，因为如果丢失服务器将存在一个半连接，因为结束了会话本端的socket就注销了，在收到来自服务器的数据就会丢弃，这两个RTT时间就是为给服务器足够的超时重传时间（因为如果服务器没有收到对于本端fin的确认，到了超时时间就会重发fin报文）
这其实是一个很有意思的问题，两军问题，所以tcp协议不能保证不会出现服务器存在半连接的情况

拥塞控制原理

拥塞控制控制的是网络的通常情况，和流量控制的保证接收端可以完全接收数据不同

当两个发送端发送速度相同，而路由器有无限长的缓冲，这样随着输入的不断增大，路由器的吞吐量不断增大直到到达R，这时再传来的包就需要存储到缓冲区中，因为缓冲区无限长，就可以一直接收数据
当缓冲区的大小为无限大，随着输入的增加，输出在不断增加，当虽则流量强度的不断增加，因为缓冲区的大小为无限大（分组不丢失），导致排队延时为无限大，这就导致输出中越来越多的分组为重传分组

当路由器的缓存有限，当发生了超时重发机制，发送方重传，这时原来的数据大小为λ_in变为λ_in’ 后者可能比前者大，这样不断的累计，最后导致的就是路由器不断的丢包，发送方不断的发，但是发的都是发过的包，导致接受方接收道的数据大量重复

当我们假设这这样的情况，如果发送方知道路由器缓存大小，这样就可以完美解决发送方一直重发导致一种数据包在路由器缓冲区存在多个的情况了，只需要在缓冲区大小到达一个合理的范围时，发生方才重发数据包
当出现拥塞，可能导致超时定时器超时，而数据只是被堵塞了，重发导致加剧拥塞

当出现拥塞假设是的正上的路由器，因为蓝色从B点来，经过一个路由器，这导致蓝色流量在正上路由器上的流量减少，而红色流量因为直接输入到正上路由器，这导致，当这个路由器有缓冲区空间，容易被红色的流量抢占，这导致蓝色流量经过一次路由器的流量被抛弃，导致上游的传输能力被浪费



网络的中间节点可能根据网络情况修改ATM数据包中的对于网络拥塞情况的部分，到达接收方，通过将这个网络辅助信息和接收方发生给发送方的数据一起返回去，这样发送方可以比较明确的知道网络的具体情况
er求的是整个路径上，可以为发送主机提供的最大传输速率。通过反转的方式，将er字段反转给发送方

TCP拥塞控制原理：

当使用网络辅助信息的方式，对于网络核心的负担较大

tcp将拥塞分为两个等级，轻微拥塞和拥塞；对于不同的拥塞等级给与不同动作

发生超时为拥塞情况，发生3个冗余ack为轻微拥塞情况

congwin的值：在未确认的情况下可以发送多少字节的数据
conwin/RTT的值就是当前可以发送的数据速率

当发生网络拥塞conwin变为1mss大小，进入慢启动（ss）阶段；当发生网络轻微拥塞conwin变为一半，且进入拥塞避免阶段（ca）；在这两个阶段都会增加conwin的值，但是增加的方式不同

这样能保证同时不会导致网络延迟，也给了接收端接收缓冲区一些时间来处理缓冲区中的数据


当进入慢启动，conwin为1，启动的初值低

当成功收到一个ack，conwin的值就加一，这样一个rtt下来，如果ack全部收到conwin值变为2conwin
在ca阶段：每次完成一个rtt，conwin+1
我们举一个例子：当conwin为1，当在指数增长为16的情况下出现丢失，将congwin变为1再次进入ss阶段，当到了8的时候进入cs阶段，当再次出现丢失的情况，再次将这个值的一半作为警戒值，congwin变为1，再次进入ss阶段；如果其中出现3个冗余ack，直接将congwin变为一半，进入cs阶段。

在这样的算法过程中，congwin的值就是在不断的上升，减半，变1这三个过程中的，如上图


Threshold也就是阈值，也就是当出现拥塞情况后，congwin/2得到的值

在这种算法下的发送方的吞吐量

congwin的值大多在w/2和w之间浮动，因为ss阶段增长快速，这里忽略ss阶段，得到的congwin的值就是3/4w，所以得到数据吞吐量就是(3/4W)/RTT

当情况如上图所示

如果一个主机获得的带宽较大也就是横坐标的值，一个获得的带宽较小，也就值纵坐标的值，构成的就是黄色的框，我们忽略慢启动阶段因为速度太快了，这时他们都处在拥塞避免的 阶段(ca)，当他们不断增加1，到达了最大带宽，因为缓冲区的原因，可能在一段时间内超过这个最大值，然后他们的速率变为原来的一半，也就是图中的黄色的点，这样他们的速率变为原来的一半，然后进入拥塞避免阶段，不断conwin+1，最后又到了最大值，又变为一半，通过这样不断的趋近于X=Y，达到公平。
这种情况只在双方都是TCP协议才有效，如果一方是udp，因为udp没有拥塞控制部分，所以tcp肯定吃亏
如果AB的建立TCP连接数不同可能导致带宽分配不均
当BB’之间的往返延时小，也可能导致B带宽增加速率较快