【计算机网络】三、传输层

概述

为运行在不同主机上的应用进程提供逻辑通信

协议在端系统

发送方：将应用层的报文分成报文段，然后传递给网络层

接收方：将报文段重组成报文，然后传递给应用层

有多个传输层协议可供应用选择：TCP、UDP

传输层与网络层

传输层：进程间的逻辑通信。依赖网络层服务（延时、带宽），增强网络层服务（数据丢失、顺序混乱、加密）

网络层：主机间的逻辑通信

多路复用与解复用

多路复用：从多个套接字接收来自一个或多个进程的报文，根据套接字对应的IP地址和端口号等信息对报文段用头部加以封装（该头部信息用于以后的解复用）

多路解复用：根据报文段的头部信息中的IP地址和端口号将接收到的报文段发给正确的套接字（和对应的应用进程）

多路：多个应用进程借助传输层实现网络传输

无连接的传输：UDP

无连接：无握手，每个UDP报文段独立处理

应用：流媒体、DNS

不可靠传输：丢失、乱序

可靠传输：在应用层改进、应用特定的差错恢复

优势：不建立连接减少延时、不维护连接状态（简单）、报文段头部小（开销小）、无拥塞控制和流量控制

UDP报文段格式

源端口号、目标端口号、长度与校验和均为16位2字节

校验和：

发送端——将报文段的内容视为16比特的整数进行加法和（1的补运算）

接收端——计算校验和并比对校验和字段（相等不代表一定没有差错）

回卷：将最高位减去后结果+1

可靠数据传输（RDT）

数据传输存在比特出错、分组丢失问题

只考虑单向数据传输（双向即为两个单向）

通过有限状态机（FSM）描述发送方（S）和接收方（R）

RDT1.0

在可靠信道上的可靠数据传输

传输层只负责封装/解封装

下层信道可靠——比特不出错、分组不丢失

发送方将数据发送到下层信道，接收方从下层信道接收数据

RDT2.0

具有比特差错的信道

下层信道将分组中的比特翻转（fleet，0变为1，1变为0）

接收方接收数据并校验后显示告诉发送方ACK（确认）或NAK（否定确认）

RDT2.1

发送方处理出错的ACK/NAK

RDT2.0存在问题：ACK/NAK也可能出错，导致重传等

RDT2.1：序号——给packet加上序号（0/1），判断重复；停止等待协议——发送方只发送一个分组，等待接收方的反馈

RDT2.1存在问题：状态数变成两倍（多了序号）；接收方不确定发送方是否正确收到ACK/NAK（确认的确认）

RDT2.2（RDT2.1 NAK free）

功能同RDT2.1，但只使用编号的ACK

RDT2.2：取消NACK——数据出错则返回ACK+上一个packet的序号；重复ACK——当接收方收到重复的ACK时，说明下一个packet发送失败了。接收方会重发当前ACK序号后的报文

RDT2.2存在问题：ACK可能丢失，导致发送方持续等待确认

ACK出错时，会导致数据重传： 

RDT3.0

具有比特差错和分组丢失的信道

发送端超时重传：若规定时间内未收到ACK则重传，通过序列号可处理规定时间过短重传导致的数据重复。链路层的timeout时间确定的，传输层timeout时间是适应式的

  

发送pkt后若为超时并收到ack0，则还是等到超时后再重传

过早超时（图d，ACK延迟到达）也能正常工作，但一半的分组和确认是重复的，效率低下，因此需要设置合理的超时时间

滑动窗口协议

发送窗口

发送缓冲区内容的一个范围（已发送但未确认分组的序号构成的空间）

发送窗口Sw的最大值<=发送缓冲区的值

每发送一个分组，前沿前移一个单位；每收到一个确认，后沿前移一个单位

前沿不能超过发送缓冲区，后沿不能超过前沿

接收窗口

即接收缓冲区

控制分组的接收：收到的分组序号落入窗口内才允许接收，否则丢弃

接收窗口尺寸Rw=1则只能顺序接收，Rw>1可以乱序接收，但提交上层时需按序

收到最低序号分组，才交付所有已收到分组并反馈确认

停止等待协议（Stop-Wait）

RDT3.0及之前采用停止等待协议，即发送方一次只发送一个分组PDU，等待确认后再发送下一个

在链路容量较大时性能很差，不能充分利用链路的传输能力

此时Sw=Rw=1

流水线协议

流水线：允许发送方在未得到接收方确认的情况下一次发送多个分组

①需增加序号范围：使用多个bit表示分组序号

②需在发送方/接收方设置缓冲区（发送方缓冲负责重传，接收方缓存负责排序交付给上层）

回退N步（GBN，Go-Back-N）

Sw>1 Rw=1

超时重传：发送方只维护最早未确认分组的定时器，超时后将重传该分组及其后的所有分组

丢弃乱序：接收方窗口为1，若收到较大序号的分组则丢弃

选择重传（SR，Selective Repeat）

Sw>1 Rw>1

超时重传：发送方维护所有分组的定时器，超时后只重传某个分组

接收乱序：接收方可以乱序接收分组，当最头部分组整体接收完毕，滑动窗口可以整体后移，并将头部接收到的多个分组整体提交给上层

GBN与SR对比：GBN简单所需资源少，但出错后回退N步开销大；SR出错时代价小，但所需资源多。GBN适合出错率低的传输，SR适合链路容量大的传输

面向连接的传输：TCP

概述

点对点：发送方与接收方

可靠、有序的字节流：没有报文边界

管道化（流水线）：TCP拥塞控制和流量控制设置窗口大小

发送和接收缓存

全双工数据：同一连接中数据流双向流动

MSS：最大报文段大小

面向连接：数据交换前通过握手初始化双方状态

流量控制：发送方不会淹没接收方

报文结构

序号SEQ：报文段首字节在字节流中的编号。双方初始化最初序号，之后每个报文的序号=前一报文序号+MSS

确认序号ACK：表示接收方需要的数据需要从发送方的哪一序号开始，即ACK-1字节的数据已确认（累积确认）

因此，响应ACK=请求SEQ+请求字节数

往返延时RTT与超时

多次发送SampleRTT求指数加权移动平均，从而设置超时时间间隔

​​​​​​​

可靠数据传输

TCP采用流水线传输方式，是GBN和SR的混合体：

可选乱序——针对乱序接收没有规范。可缓存乱序分组，通过分组编号排序，返回ACK仍然是第一个未收到分组的序号（累积确认，GBN）

选择确认：发送方未接收到分组的ACK时，只重新发送单个分组，而不会发送所有分组（SR）

超时重传——只维护最早未确认分组的定时器（GBN）

快速重传——发送方接收到三次（或多次）相同的ACK，表示所对应SEQ大概率丢失，则在定时器到期前重传ACK序号标识的分组

流量控制

接收方通过报文结构中的16位窗口大小向发送方反映接收方的剩余缓存空间

发送方限制未确认的字节<=缓存空间从而实现流量控制，避免淹没接收方

拥塞控制

控制网络拥塞，避免因拥塞导致的分组丢失与延迟

通过丢包率与对应的公式，计算网络拥塞下的发送速率，进而控制滑动窗口大小

控制规则

TCP慢启动：初始滑动窗口为1

每次收到ACK，成倍增加滑动窗口大小，直到上一次阈值后线性增长（每次+1MSS）

每次快速重传，Ws减半

每次超时重传，Ws降为1

联合控制：滑动窗口由流量控制和拥塞控制共同决定。Ws=min(拥塞控制窗口，流量控制窗口)

连接管理（三次握手与四次挥手）

三次握手

客户端发出连接请求->客户端得到服务器对请求的确认，并收到服务器的连接请求->服务器得到客户端对请求的确认

SYN：连接请求/接收报文段

seq：发送的第一个字节的序号。seq序号的初始化是随机的

ACK：确认报文段

ack：确认号。希望收到的下一个数据的第一个字节的序号

1）第一次握手：客户端向服务端发送一个 SYN 报文（SYN = 1），并指明客户端的初始化序列号 ISN(x)，即图中的 seq = x，表示本报文段所发送的数据的第一个字节的序号。此时客户端处于 SYN_Send 状态

SYN-SENT ：在发送连接请求后等待匹配的连接请求

2）第二次握手：服务器收到客户端的 SYN 报文之后，会发送 SYN 报文作为应答（SYN = 1），并且指定自己的初始化序列号 ISN(y)，即图中的 seq = y。同时会把客户端的 ISN + 1 作为确认号 ack 的值，表示已经收到了客户端发来的的 SYN 报文，希望收到的下一个数据的第一个字节的序号是 x + 1，此时服务器处于 SYN_REVD 的状态

SYN-RECEIVED：在收到和发送一个连接请求后等待对连接请求的确认

3）第三次握手：客户端收到服务器端响应的 SYN 报文之后，会发送一个 ACK 报文，也是一样把服务器的 ISN + 1 作为 ack 的值，表示已经收到了服务端发来的的 SYN 报文，希望收到的下一个数据的第一个字节的序号是 y + 1，并指明此时客户端的序列号 seq = x + 1（初始为 seq = x，所以第二个报文段要 +1），此时客户端处于 Establised 状态。

服务器收到 ACK 报文之后，也处于 Establised 状态，至此，双方建立起了 TCP 连接

ESTABLISHED：代表一个打开的连接，数据可以传送给用户

为什么要三次握手？

三次握手的本质是，双方都要发出连接请求，交换自己的序列seq，并确认对方能够正常接收做出应答。本来是两个往返需要四次，服务器这边将应答和请求合并了，所以只需要三次

两次握手行不行？

两次握手相当于省略了第三次应答，服务器没法确认对方收到了自己的序列号。本来服务器在接收到对方第一次请求的时候进入的是半开状态，还没建立连接。两次握手意味着接收到对方请求后，服务器就直接进入了连接状态，能直接发送数据。这时候对方没接收到第二次的应答，没协商好seq序号就发送消息，会产生错乱。

第三次握手丢失了会怎样？

服务器在发出第二次握手后，会进入半开 SYN_REVD 的状态。等待第三次握手，如果第三次握手没有达到，会触发超时重传。例如间隔时间为 1s，2s，4s，8s…

SYN 洪泛攻击？

SYN 攻击就是 Client 在短时间内伪造大量不存在的 IP 地址，并向 Server 不断地发送 SYN 包，Server 则回复确认包，并等待 Client 确认，由于源地址不存在，因此 Server 需要不断重发直至超时，这些伪造的 SYN 包将长时间占用半连接队列，导致正常的 SYN 请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪

四次挥手

FIN ：连接终止位

seq：发送的第一个字节的序号

ACK：确认报文段

ack：确认号。希望收到的下一个数据的第一个字节的序号

1）第一次挥手：客户端发送一个 FIN 报文（请求连接终止：FIN = 1），报文中会指定一个序列号 seq = u。并停止再发送数据，主动关闭 TCP 连接。此时客户端处于 FIN_WAIT1 状态，等待服务端的确认。

FIN-WAIT-1：等待远程TCP的连接中断请求，或先前的连接中断请求的确认；

2）第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。

CLOSE-WAIT - 等待从本地用户发来的连接中断请求；

此时的 TCP 处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待 2）状态，等待服务端发出的连接释放报文段。

FIN-WAIT-2：从远程TCP等待连接中断请求；

3）第三次挥手：如果服务端也想断开连接了（没有要向客户端发出的数据），和客户端的第一次挥手一样，发送 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态，等待客户端的确认。

LAST-ACK：等待原来发向远程TCP的连接中断请求的确认；

4）第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答（ack = w+1），且把服务端的序列值 +1 作为自己 ACK 报文的序号值（seq=u+1），此时客户端处于 TIME_WAIT （时间等待）状态。

TIME-WAIT：等待足够的时间以确保远程TCP接收到连接中断请求的确认。此时由服务端到客户端的 TCP 连接并未释放掉，需要经过时间等待计时器设置的时间 2MSL（一个报文的来回时间） 后才会进入 CLOSED 状态（这样做的目的是确保服务端收到自己的 ACK 报文。如果服务端在规定时间内没有收到客户端发来的 ACK 报文的话，服务端会重新发送 FIN 报文给客户端，客户端再次收到 FIN 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文给服务端）。服务端收到 ACK 报文之后，就关闭连接了，处于 CLOSED 状态

由于 TCP 的半关闭（half-close）特性，TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

其实建立连接和释放连接都需要四次。双方的请求加双方的应答。但是建立连接可以合并应答和请求。而释放连接，可能服务器还有需要发送的数据，没法合并，只能先应答，发完剩下的组后，再请求关闭