计网笔记_3

第3章 传输层

3.1 概述

传输层的工作原理：多路复用/解复用

RDT reliable data transfer

流量控制、拥塞控制

传输服务和协议：位运行在不同主机上的应用进程提供逻辑通信

TCP: Transmission Control Protocol，传输控制协议

UDP：User Datagram Protocol，用户数据报协议

传输层UDP把主机到主机的服务细分为进程到进程，TCP则还是主机到主机。

传输层把下层网络层提供的不可靠的服务变得更可靠。

传输层一个很重要的作用就是复用和解复用，也就是从主机细分到进程的过程：

TCP的PDU叫TCP段segment，也就是在发端，TCP把上层应用层的报文拆成了一个个段（带有socket和四元组）送给下层去传输，这就是复用，而到了收端的传输层，收端的TCP把接收到的这些段做好区分合到一起，就是解复用。

Internet传输层协议：TCP可靠，UDP不可靠

3.2   多路复用和解复用

通过引入port概念，在TCP的四元组，UDP的二元组和cad中，包含必要信息，收端根据源端口号和源IP可以定位到socket，故而可以实现报文的收发。

3.3   无连接传输UDP

UDP被用于：

流媒体传输，注重实时性；

DNS，查询简单；

SNMP简单网络管理协议。

UDP的无连接：通信前不需要握手，每个UDP数据包datagram被单独处理。

UDP有32个比特bit（4个字节byte）的头head，源IP、源端口、长度、校验和各1字节后面才是报文。

为什么要UDP：

不建立连接；发端收端之间没有连接状态，简单；报文段头部开销小；无拥塞控制机制和流量控制机制，顾虑的情况少。

UDP校验和check sum：（差错检测编码）

发端和收端计算校验和判断是否出错

3.4   RDT可靠数据传输 原理

RDT在应用层、传输层、链路层都很重要。

下层提供的服务是UDP不可靠数据传输，协议要使之可靠再向上层提供可靠的服务。

只考虑单向的信息传输（把双向的通信拆成两个单向的过程，每个过程都有发端和收端）

使用有限状态机FSM，Finite State Machine来标记发端和收端。

RDT：

假设下层提供的服务可靠，那么RDT只需要实现复用和解复用就可以了，但是下层提供的服务是不可靠的，所以RDT只能复用解复用是不够的；

RDT协议检错（提高可靠性）流程：

发送端发送packet过去之后就进入等待确认状态，接受方接到对的packet后回复ACK确认，发送方接收到ACK之后就可以发新的packet，接收方接到packet不对就回复NAK，表示没通过校验，此时发送方接收到NAK之后发送旧的packet（重发一遍）。这种协议方式的问题在于ACK和NAK也可能出错，所以再引入序号机制，给packet加入序号，如果接收到的ACK/NAK出了问题，就把packet重新发一遍，因为带了序号，所以即使重复发送了，收端也可以根据序号辨别，如果没重复，接收方将等待的序号在packet带来序号的基础上+1，真的重复了，接收方就把ACK/NAK重新发一遍。

因为有ACK和NAK两种会使情况变得复杂，所以：不区分ACK和NAK，只用ACK，给ACK编码，假设发送packet0，收端接收时出错，那么接收端回复ACK1，相当于使用非packet序号编号的ACK代替了原来的NAK。

而实际通信过程中，分组甚至会丢失，比如packet和ACK都有可能丢失，所以需要引入超时重传机制，顾名思义，通过超时timeout定时器，发送方在等待状态经过了一段超过分组往返的时间（这个时间是自适应计算的），就重新发送分组，接收方也是一样的超时机制，因为分组带有序列，所以不用担心重复。

自此，RDT可以对抗丢失和出错。

但是RDT协议还有问题，发一个等一个，信道利用率太低，传输过程的瓶颈变成了协议本身是万万不可的，所以还要再改进。

怎么改进呢？流水线pipeline协议，一个分组发出去，不等收端回复确认就接着发下一个分组，就可以一直发一直发，但是还有检错重发问题和丢失问题，问题没这么简单，pipeline的实现：

滑动窗口协议slide window

发端和收端加上缓冲区。

如果发端和收端缓冲区一样大=1，那么是平等的协议S-W；

如果发端缓冲区>收端=1，GBN协议Go-Back-N，累积确认；

如果收端缓冲区>发端=1，SR协议Selective Repeat，单独确认。

GBN和SR协议合起来叫pipeline协议。

可以连着发多少个分组的大小，就是缓冲区的大小，分组发完了得呆在缓存区，保持未确认分组状态，以应对检错重发和丢失重发。

发送窗口sending window是缓冲区的子集。

初始状态发送窗口为0，每发一个分组，发送窗口往前滑动一个位置，如此往复，如果一直到缓冲区堆满，第一个发送的分组还没有收到确认，那么就不能再发了，如果之前发的老分组被确认，那么发送窗口的后沿向前滑动，缓冲区再次有空位，可以接着发，所以叫滑动窗口slide window协议。

接收窗口receiving window：（接收窗口=接收缓冲区）

每返回一个ACK，只有在这个ACK的序号在接收窗口中最小（即最早到达的分组）时，接收窗口才可以向前滑动，高序号分组到来时，是保持缓冲的，不可滑动。

因为GBN顺序接收（收端窗口只有1），收端接收的序号不对是直接丢弃不接收的，一旦收端接收，就在证明此前所有的分组都已经收到了，行为上看是累积确认的方式，所以一旦分组超时，就一定是当前发送方缓冲区中最老的分组超时了，所以超时重传机制需要顺序重传整个发端缓冲区的分组；

因为SR乱序接收（收端窗口>1，任性），收端只要分组到了就直接缓冲接收，返回对应packet序号的ACK，并不证明收端收到了此前的packet，行为上看是单独确认，所以如果分组超时，只需要单独重传超时分组本身即可。

GBN和SR协议对比：

GBN出错率比较低，但是出错要整个缓冲区重传，所以如果链路容量大，缓冲区大，重传代价太大，所以用在本身链路较稳定的场合不怎么需要重传的时候比较好；

SR协议比较灵活，只需要重传一个分组就ok。

3.5   TCP

概述：TCP提供点到点的通信（应用进程到应用进程，不提供一对多或多对一）

提供pipeline流水线协议。

TCP按照MSS maximum segment size最大报文段的大小进行拆分，并在头部加上TCP head。之后到网络层之后再加上 IP的头部。

TCP是全双工的，支持同时双向。

TCP报文结构：

16比特源端口号，16比特目的端口号，32比特序号（上层应用层来的报文流按MSS     拆分之后的序号，包含MSS长度的比特意义上的偏移量），32比特确认号（收端返回的ACKx给发端，意味着此前x-1个TCP段都已经收到了，可以发第x个报文，累积确认含义）。

之后是16比特首部长度+保留为用+U/A/P/R/S/F，16比特的接收窗口，16比特校验和（同UDP），16比特紧急数据指针，应用层数据之前最后一部分是32比特的可选项。

TCP协议对往返延时RTT的设置：

无法设定成固定值，所以动态自适应，需要经常测往返延迟，之后取期望加四倍的方差，可以达到99.9以上的概率密度覆盖率。

在超时时间内，如果发端接收到收端返回的连续的（3个）相同的ACK，说明收端已经接收到了后面的连续的多个TCP段，但是因为累积确认，中间一直缺了一个，这时又没到超时时间（因为超时时间的设置一般很保守，平均往返时间+四倍偏差），但发端接到连续的相同的ACK请求之后，直接重发缺的那一段TCP段，这就是快速重传。

TCP的RDT可靠数据传输：

GBN和SR的混合体，只有一个计时器，但是最老的超时了只重发最老的TCP段并重启定时器。如果缓冲区base到next数据全发完了，但没有一个TCP段被确认，这时窗口后沿移动到最前沿，发送窗口长度为0，这种情况下，要关掉计时器。

TCP流量控制：在收端返回ACK请求的时候，把接收窗口receiving window的余量捎带传输给发端，这样发端就知道收端缓冲区的余量，就可以进行流量控制。

TCP连接的建立：三次握手。发送连接请求-确认；发端资源置位，确认收端的确认。

即：发到收（请求），收到发（确认），收到发（请求），发到收（确认）。把中间两次收到发的合并到一起，构成了三次握手。

两次握手不行，一旦请求超时，重发请求，收端就会多次建立连接并维护连接状态，浪费资源，而如果后面收端的确认没到，前面一次连接的数据已经传完了，那么发端再接到连接确认的时候就会把已经发过的数据再发一遍，如此重复，造成浪费。

TCP连接的释放（关闭）：对称释放，两端互相给一次释放请求，再互相给一次请求确认，之后在计时器的计时的一段时间内，没有再接收到任何数据，就关闭连接。

这种对称半连接的方式释放连接并不完美，因为任何一次的请求和确认都不可靠，但是只能用这样的一种相对较好的方案。

3.6   拥塞控制原理：

路由的缓冲区有限，即带宽有限，缓冲区满了之后到来的数据包就被丢弃，之后就触发超时重传机制，网络中重传的数据越来越多，网络进入拥塞状态，并且一旦拥塞，情况很可能越来越坏。

而且网络中一般要经过很多路由，因为连接后端的路由的拥塞导致数据被丢失，是损失的最大化。

拥塞控制的方式：

端到端的拥塞控制；

网络辅助信息的拥塞控制：轻量化，RM资源管理resource management信元很小，便于路由的存储转发，而且信元中有些标志位NI no increase in rate（轻度拥塞）和CI congestion indication（拥塞指示），交换机可以对NI和CI标志位进行相应的置位，告诉发端网络的拥塞情况。此外信元中还有ER explicit rate标志位，交换器把可提供带宽的最小值告诉发端，主机系统通过可提供的带宽压缩控制报文。

3.7 TCP拥塞

TCP是典型的端到端的拥塞控制，网络不提供任何辅助信息，降低网络中交换机的压力。

TCP自己判断网络是否拥塞。

两个问题：如何检测拥塞，如何控制。

TCP拥塞检测（拥塞+轻微拥塞）：

检测指针超时，但超时也可能是因为收端检错没通过被丢掉，但是这种情况比因为拥塞被路由丢弃的情况少很多，所以可以笼统地认为是拥塞导致的超时，因此可以通过检测超时判断网络拥塞。

收到连续多个冗余ACK，即没到超时时间但后面的TCP段都到了（一般是后面连续3个），缺了中间一段，连续返回了缺的这一段的期望的ACK，此时根据超时重传机制，发端需要立马重传缺的这一段，这种情况下就可以判断网络即将拥塞，一般是轻微拥塞。

TCP拥塞控制：（和流量控制一并完成）

如何控制发送的速率：rate = CongWin / RTT 。

拥塞控制窗口Congestion window，一旦拥塞，降低拥塞窗口至1个MSS，拥塞避免CA congestion avoid阶段，拥塞控制窗口每次+1。

联合控制的方法：拥塞控制和流量控制一并动作：

发送窗口取min（CongWin， RecvWin）

TCP慢启动SS slow start：

建立开始时，发一个MSS，之后发两个，每次+1，虽然每次只+1，但是RTT往返延迟是两倍，延时是指数级增加的，一旦超时，取一半拥塞控制窗口的大小作警戒值threshold，回到从1个MSS的状态开始ss到警戒值后再线性增加，每次超时都取一半作警戒值，如此往复，直到有一次收到三个冗余ACK（轻微拥塞），此时取一半作警戒值，拥塞窗口取警戒值+3（3个冗余ACK），ss到CongWin + 3的时候再线性增加。

平均吞吐量（大约）： T = (w + w/2) / 2*RTT = (3/4) (w/RTT) , w表示congestion window

TCP的公平性：长期来说，n个主机各获得网络的1/n的带宽。

因为考虑到了拥塞的情况并进行控制（每次 /2 ，所以可能一开始带宽分配不公平，但之后会收敛到相等的情况，所以长期来看大致公平）。