第六章 传输层 —— tcp/udp

第六章 传输层—— TCP/UDP

6.1 传输层概述

网络层实现了网络环境下主机之间传输信息— IP数据报实际中，从应用需要的是应用程序间的有效数据传送。

数据传输的端点是应用进程，到达主机是不够的。应用进程可能有多个。

应用进程是动态活动的：有产生、活动、消亡；IP 层传输为“尽最大努力的交付服务”，即不提供可靠性保证：

IP 报文可能被丢弃（报文头出错、拥塞发生时、生存期为 0）； IP 报文数据部分不做校验；链路级的差错检测不能涵盖整个传输过程。

IP 提供的是无连接的交付服务。 IP 未为应用传输提供流量控制。在网络层需要进行的拥塞控制与发送端有关。

网络层

A B

A BStation-to-Station Connection

node1

node2

node3

node5 node6

node4

node7

IE

a0

Telnet

ftp

Web

Telneted

ftped

传输层

a1

a2

b0

b1

b2

应用层

链路层

物理层

a0

IE Web

b0End-to-End Connection

Process-to-Process Communication

Node-to-Node Connection

在 TCP/IP 环境中传输层需要解决的问题有：

端—端的传输服务 提供有可靠性保证的服务 寻址 流量控制 复用

网络 / 链路 / 物理层

ftptelnetIE

传输层

ftpWeb telnet

80 2023

163.15.2.6 138.42.3.78 144.45.43.2 163.15.2.1

工作站 D 工作站 C 工作站 B 工作站 A

ftpServer

肚块糷硈絬ftp_Bftp_Cftp_D

163.15.2.6 138.42.3.78 144.45.43.2 163.15.2.1

20

163.15.2.1

163.15.2.1

工作站 D 工作站 C 工作站 B 工作站 A

一般对传输层的要求

运输层为应用层进行通信的两个进程之间提供一个可靠的端到端的服务。

按照 OSI 模型的描述，传输层与网络层最大的区别是传输层提供进程通信能力。从这个意义上讲，网络通信的最终地址就不仅是主机地址了，还包括可以描述进程的某种标识。

在一个网络连接上复用多对进程的通信。 消除网络层的不可靠性；

传输实体——完成传输层功能的硬软件；传输层实体利用网络层提供的服务向高层提供有效、可靠的服务 . 传输层提供两种服务 :面向连接的传输服务 /无连接的传输服务。

6.2 用户数据报协议 UDP ( User Datagram Protocol)

UDP 是一种无连接的数据报传递服务，不保证可靠。 它跟远程的 UDP 实体不建立端到端的连接，而只是将数据报送上网络，或者从网上接收数据报。

无连接服务是邮政系统服务的抽象，每个分组都携带完整的目的地址，各分组在系统中独立传送。

无连接服务不能保证分组的先后顺序，不进行分组出错的恢复与重传，不保证传输的可靠性。

UDP 的作用

UDP 根据端口号对若干个应用程序进行多路复用，并能利用检验和检查数据的完整性。

由于网络通信的最终地址不仅是主机地址，还需包括可以描述进程的某种标识。为此 TCP/IP 协议提出了协议端口的概念，用于标识通信的进程。

协议端口

多数计算机允许同时运行多个应用程序，因此，在一个系统中可能存在多个进程（ Process)/ 任务（ Task)/ 应用程序（ Application Program). 通信的源和目的应该是这些进程。

需要考虑的是：进程是动态的。进程的变化不便通知远方的进程。实际中常从接收方实现的功能来识别目的，而不需要知道实现这个功能的进程。 一个进程完成多个功能时，进程要知道请求方到底要求何种功能的服务

举例 1：

有一封信件是发给某大学一位学生的，而此学生正在球场进行足球赛。

邮递员是否需要认出这个同学？是否必须在这个时刻把信递交这个同学。

解决：邮递员把信投放到这个同学单位信箱中。

举例 2：

外单位需要了解某毕业生在校情况，可发信件到学校人事处（信箱），至于是老张处理该事务还是小李处理，对这个事件无本质的差别。

举例 3：

同一单位需要招聘毕业生，可发信件到学校毕业分配办公室（信箱）。

端口 1 端口 2 端口 k

UDP基于端口的多路复用

进程 A 进程 X

IP 层IP 层

UDP 层

应用层

从某种意义说：协议端口是主机通信的一系列目标点。

UDP 数据报（含伪首部）

UDP

UDPUDP

端口 x 端口 y 端口 z

UDP基于端口的多路复用

IP 层IP 层

UDP 层

应用层

UDPUDP

UDPUDP

UDPUDP

UDPUDP

UDP

UDP 协议实现示意

收到 UDP 数据报的校验和检查

UDP 数据报首部

如果找到一个匹配，则把指向该 PCB 的指针保存在 udp _last_inpcb 中，高速缓存了最后收到的 UDP 数据报的PCB

UDP典型应用DNS ： DNS 用的是 53 端口。域名解析服务。 snmp ：简单网络管理协议，使用 161 端口，是用来管理网络设备的。 聊天软件 Oicq ： Oicq 的程序既接受服务，又提供服务，这样两个聊天的人才是平等的。 oicq 用的是无连接的协议，其服务器使用 8000 端口，侦听是否有信息到来 ;客户端使用 4000 端口，向外发送信息。如果上述两个端口正在使用（有很多人同时和几个好友聊天），就顺序往上加。TFTP: 端口号 69

RPC: 端口号 111

6.3 传输控制协议 TCP （ Transmission Control Protocol ）

TCP 协议是 TCP/IP 协议簇中重要运输层协议。 是面向连接的，可提供可靠的、按序传送数据的服务。 TCP 提供的连接是双向的，即全双工的。

面向连接服务是电话系统服务模式的抽象，即每一次完整的数据传输都要经过建立连接，使用连接，终止连接的过程。 其可望具备流量、差错控制，即提供可靠性传输服务。

一、 TCP初步特征

面向数据流——计算机系统常用形式，如文件操作。 虚电路连接——建立…。解决差错、失序、流量。保证数据正确到达。 有缓冲的传输—有序、大小任意的若干数据块，协议分解 /合并… 全双工——对一个进程，提供两个独立、流向相反的数据流。

TCP 是一种复杂的、提供可靠传输服务的协议。——面向连接的、可靠的、端到端的、基于字节流的传输协议。

TCP

服务

TCP

服务应用

者应用

者网络低层

TCP 目标是通过网络低层，为应用层提供可靠的双向数据流传输。 要克服网络低层可能出现的错误和实际问题。

可靠的传输滑动窗口

流量控制 l可变滑动窗口慢启动 slow start、拥塞避免 congestion voidance 等

连接的管理建立连接：三次握手释放连接：三次握手 + 定时器

端口 / 连接 / 端点

端点（ endpoint ）—— （ host,port ） （ 128.10.2.3,25 ）

连接（ connection ）——（ endpoint ， endpoint ） （ 18.26.0.36, 1069 ） —（ 128.10.2.3,25 ） （ 128.9.0.32, 1184 ） —（ 128.10.2.3,53 ） （ 128.2.254.139,1184 ）—（ 128.10.2.3,53 ）

应该注意到：一个端口可以被多个连接共享

一方面，一个端口可以存在多个连接；为多个连接服务的程序不需要为每个连接提供不同的端口。 另一方面，在 TCP 中可以理解为连接是区分通信的识别，端口是连接的一个组成部分。

二、 TCP 的报文格式

源端口和目的端口：各 16位；序号和确认号：以字节为单位编号，各 32位；TCP 头的长度： 4位，长度单位为 32位字，包含可选项域；6位的保留域；6位的标识位：置 1表示有效

URG ：和紧急指针配合使用，发送紧急数据；ACK ：确认号是否有效；PSH ：指示发送方和接收方将数据不做缓存，立刻发送或接收；RST ：由于不可恢复的错误重置连接；SYN ：用于连接建立指示；FIN ：用于连接释放指示

TCP采用可变发送窗口的方式进行流量控制。窗口的大小是以字节为单位的。 在 TCP 报文段首部的窗口字段写入的数据就是当前设定的接收窗口数值。 发送窗口在连接建立时由双方商定。但在通信的过程中，接收端可根据自己的资源情况，随时动态地调整自己的接收窗口（可增大或减小），然后告诉对方，使对方的发送和自己的接收窗口一致。

窗口大小：用于基于可变滑动窗口的流控，指示发送方从确认号开始可以再发送窗口大小的字节流；校验和：为增加可靠性，对 TCP 头，数据和伪头计算校验和；

选项

长度可变的字段。 TCP 只规定了一种选项，即最长报文段MSS(Maximum Segment Size) 。MSS告诉对方的 TCP ：“我的缓冲区所能接收的报文段的最大长度是 MSS”。窗口和 MSS 的区别： MSS 是一个报文的最大长度。而窗口则是所能发送的所有数据总数，它可以是多个报文段，但每个报文段必须满足 MSS 的限制，同时其数据总和不能超过窗口大小。

三、 TCP 的连接与状态机

要使每一方都能够确知对方的存在。 要允许双方协商一些参数（如，最大报文段长度，最大窗口大小，服务质量等）。 能够对运输实体资源（如缓冲区大小，连接表中的项目等）进行分配。

主动打开—被动打开

在客户机 /服务器模式下，连接的建立请求是由客户机发起的，它执行“主动打开”，而服务器执行“被动打开”，并对客户机的连接请求被动响应。 在服务器进程的实现中，首先让服务器执行“被动打开”，告诉其 TCP 要准备接受客户进程的连接请求。然后服务器进程就处于“听 (listen)”的状态，不断检测是否有客户进程要发起连接请求。如有，即作出响应。

第一次：主机 A的 TCP 向主机 B的 TCP 发出连接请求报文，其首部中的比特同步 SYN 置为 1，同时选择一个序号 x, 该序号称为初始序号 ISN(Initial Sequence Number) 。 第二次：主机 B的 TCP 收到连接请求报文后，如同意，则发回确认。在确认报文中将 SYN 置为 1，确认序号为 x+1，同时也为自己选择一个序号 y。 第三次：主机 A的 TCP 收到此报文段后，还要向 B 给出确认，其确认序号为 y+1。 然后客户机 A就可以通知上层应用进程，连接已经建立。 当 B收到 A的确认后也通知上层应用进程，连接已经建立。 “三次握手”是由连接双方的 TCP 完成的，应用程序只要一个简单的 connect 调用即可。比如执行 telnet 命令，当出现 login时连接已建立，建立的过程 TCP 协议实体在后台进行。

A.1037>B.135:s 1415531521:1415531521(0) win 4096 <mss 1024>

B.135>A.1037 : s 1823083521:1823083521(0) ack 1415531522 win 4096 <mss 1024>

A.1037 > B.135 : . ack 1823083522 win 4096

TCPTCP 的有限状态机的有限状态机

int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)

{ if (CFrameWnd::OnCreate(lpCreateStruct) == -1) return -1;

m_pSvrSocket=new CBoxSocket();

if(!m_pSvrSocket->Create(6666))

{ AfxMessageBox("Error creating socket!");

delete m_pSvrSocket;

m_pSvrSocket=NULL;

return -1;

}

m_pSvrSocket->Listen(5);

return 0;

}

利用 TCP 的应用示例

创建插座

void CBoxSocket::OnAccept(int nErrorCode)

{ CBoxSocket* pSock=new CBoxSocket();

if(Accept(*pSock))

{ ConnectedSockets.AddTail(pSock);

m_nCount+=1;

}

else

{ AfxMessageBox("Error Accepting!");

delete pSock;

}

CSocket::OnAccept(nErrorCode);

};接受请求

void CBoxSocket::OnReceive(int nErrorCode)

{ TCHAR buff[2048];

int nRead,pos_Temp;

nRead=Receive(buff,2048);

switch(nRead)

{ case 0: AfxMessageBox("Close!");Close();break;

case SOCKET_ERROR:

AfxMessageBox("Error Receiving!"); break;

default:

buff[nRead]=0;

Send(&my_INT[0], 400,0);

}

CSocket::OnReceive(nErrorCode);

} 收发若干字节

四、 TCP 的流量控制

TCP采用可变发送窗口的方式进行流量控制。窗口的大小是以字节为单位的。在 TCP 报文段首部的窗口字段写入的数据就是当前设定的接收窗口数值。发送窗口在连接建立时由双方商定。但在通信的过程中，接收端可根据自己的资源情况，随时动态地调整自己的接收窗口（可增大或减小），然后告诉对方，使对方的发送和自己的接收窗口一致。这是一种由接收端控制发送端的做法

发送端要发送的数据共 9个报文段，每个报文段 100字节长，而接收端许诺的发送窗口为 500字节。发送窗口当前的位置表示有两个报文段（其字节序号为1-200 ）已经发送过并已收到了接收端的确认。发送端在当前的情况下，可连续发送 5个报文段而不必收到确认。假定发送端已发送了两个报文段但未收到确认，那么它还能发送 3个报文段。发送端在收到接收端发来的确认后，就可将发送窗口向前移动了。

期望接收 201

201重发

期望接收序列 2048

W大小 2048

MSS 的问题

如果太小，则网络的利用率低，比如一次一个字节，利用率只有 1/41。如果太大，超过了路径 MTU，将导致该报文段在 IP层会被分成多个 IP数据包，如果某个包发生错误，整个都要重传，这些都会使开销增大。 原则： MSS 应尽可能大，只要在 IP层传输时不需再分片就行。 由于双方都有 MSS ，传送时取较小者。如果主机未填写该项，则 MSS默认值是 536字节的净负荷，因此在 Internet上的主机都应能接受的报文段长度为 536+20=556字节。

TCP 发报文的时机

汇集到 MSS 数量的字节 发送端应用程序指明要发送（ PUSH ） 发送计时器时间到

问题： 当用户打一字符，就可能导致发送一个 TCP 报文。 1+20 （ TCP首部） +20 （ IP首部） =41字节 响应也要 40字节。

解决办法：推迟发送，捎带应答

Nagle 算法

若数据是逐个字节地到达发送端，那么发送端不是逐个字节的发送数据，而是先将第一个字符发送出去，将后面到达的字符都缓存起来。当收到对第一个字符的确认后，再将缓冲区中的所有字符装成一个报文段发送出去，同时继续对到达的字符进行缓存。只有在收到确认后才继续发送下一个报文段。当字符到达较快而网络速度较慢时，用这样的方法可明显地减少所用的网络带宽。算法还规定，当到达的字符已达窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。在实时性要求较高的情况下不宜采用 Nagle 算法：例如在 Internet 上使用 X-window，要将鼠标移动的信息传到远地主机。若采用 Nagle算法会使用户感到无法忍受。

糊涂窗口综合症

描述：接收端的缓冲区已满，而交互式的应用进程一次只从缓冲区中读取一个字符（这样就在缓冲区产生 1 个字节的空位子），然后向发送端发送确认，并通知窗口大小为 1 个字符（但发送的数据报是 40字节长），接着发送端又发来 1 个字符（但发来的数据报是 41字节长）。接收端发回确认，仍然通知窗口为 1 个字节。这样下去就使网络的效率很低。

解决办法：让接收端等待一段时间，使得或者缓冲区已能有足够的空间容纳一个最长报文段，或者缓冲区已有一半的空间处于空的状态。只要出现这两种中的一种，就发出确认报文，并向发送端通知当前的窗口大小。此外，发送端也不要发送太小的报文段，而是将数据积累成足够大的报文段，或达到接收端缓冲区的空间的一半大小。

超时与重发

TCP必须要适应两方面的巨大差异：

到达不同目的所需的时间差异 到达某一目的因通信负载变化导致的差异

采用自适应算法——该算法记录每一个报文段发出的时间，以及收到相应的确认报文段的时间。这两个时间之差就是报文段的往返时延。将各个报文段的往返时延样本加权平均，就得出报文段的平均往返时延 T 。

数据链路层（ a）和 TCP（ b）中确认到达时间的概率密度

每测量到一个新的往返时延样本，就按下式重新计算一次平均往返时延：

平均往返时延 RTT=

α （旧的往返时延样本 RTT ） + （ 1-α ）（新的往返时延样本）

典型 α取 7/8 （ 0.9)— 每个新估计的 90％来自前一个估计，而 10%则取自新的测量。

进一步问题：

原报文和重发报文得到的 ACK 可能得到两种不同的结果，采用后者导致 RTT逐步趋小

Karn 算法

在计算平均往返时延时，只要报文段重发了，就不采用器往返时延样本。这样得出的平均往返时延和重发时间就会比较准确。 Karn 算法的修正： 新的重发时间 =r(旧的重发时间） 系数 r 的典型值是 2

五、 TCP 的拥塞控制

拥塞—一个或多个路由器负载过重，出现严重时延。 极端情况： 到达过载路由器的报文不断增加，路由器开始拒绝（丢弃）报文。 进而，被丢弃的报文开始重传，拥塞加剧。

拥塞的判别

由于通信线路带来的误码而使得分组丢失的概率很小（远小于 1%）。因此，只要出现分组丢失或延迟过长而引起超时重发，就意味着在网络中的某个地方出现了拥塞。

拥塞控制与流量控制的区别

拥塞是网络环境下所特有的问题。而一般流量控制是源、目的的配合问题。 一般流量控制的本质是收端主导发送速度。而拥塞需要源端做出判断和调整。 拥塞的瓶颈在传输过程各个环节，一般流量控制的瓶颈在收端。

共同之处是源端要调整发送速度（发送量）

发送端的主机在发送数据时，既要考虑到接收端的接收能力，又要使网络不要发生拥塞。

TCP 的拥塞控制算法

慢启动算法 拥塞避免算法 快重传 快恢复

发送窗口大小 发送窗口 =Min[通知窗口，拥塞窗口 ] 通知窗口：接收端根据其接收能力许诺的窗口值，是来自接收端的流量控制。接收端将通知窗口的值放在 TCP 报文的首部中，传送给发送端。 拥塞窗口：是发送端根据网络拥塞情况得出得窗口值，是来自发送端的流量控制。 在未发生拥塞的稳定情况下，接收端通知的窗口和拥塞窗口是一致的。

发送方维护两个窗口：可变发送窗口和拥塞窗口，按两个窗口的最小值发送；拥塞窗口遵循慢启动（ slow start）算法和拥塞避免算法

慢启动（ slow start ）算法 拥塞窗口 (congestion window) ，记为 cwnd 拥塞窗口被初始化为 1 个报文段（即另一端通告的报文段大小）。 每收到一个 ACK ，拥塞窗口就增加一个报文段（ cwnd 以字节为单位，但是慢启动以报文段大小为单位进行增加）。 发送方取拥塞窗口与通告窗口中的最小值作为发送上限。 发送方开始时发送一个报文段，然后等待 ACK 。当收到该 ACK 时，拥塞窗口从 1增加为 2 ，即可以发送两个报文段。当收到这两个报文段的 ACK 时，拥塞窗口就增加为 4 。这是一种指数增加的关系。

Host A

one segment

RTT

Host B

time

two segments

four segments

当收到报文段 5的 ACK后，拥塞窗口增加为 3。此时尽管可发送多达 3个报文段，可是在下一个 ACK收到之前，只发送了 2个报文段。

拥塞避免算法 与慢启动类似，只是将拥塞窗口每次增加 1个报文段大小，而不是以指数增加。这样可以减慢数据包进入网络的速率。 慢启动门限（ ssthresh ）：初始化为 64个报文段大小（ 65535 字节）。每次发生拥塞时，拥塞窗口减半。它作为下次拥塞控制中慢启动和拥塞避免阶段的分界点。 cwnd < ssthresh 采用慢启动 cwnd > ssthresh 采用拥塞避免

加速递减：指每出现一次超时，就将慢启动门限窗口值减半。若超时频繁出现，则门限窗口减小的速率是很快的。

ssthresh=16

ssthresh=12 24/2

cwnd

拥塞避免算法和慢启动算法需要对每个连接维持两个变量：

一个拥塞窗口 cwnd和一个慢启动门限 ssthresh。这样得到的算法的工作过程如下：

1) 对一个给定的连接，初始化 cwnd为 1个报文段， ssthresh为 65535个字节。

2) TCP 输出例程的输出不能超过 cwnd和接收方通告窗口的大小。

拥塞避免是发送方使用的流量控制，而通告窗口则是接收方进行的流量控制。前者是发送方感受到的网络拥塞的估计，而后者则与接收方在该连接上的可用缓存大小有关。

3) 当拥塞发生时（超时或收到重复确认）， ssthresh被设置为当前窗口大小的一半（ cwnd和接收方通告窗口大小的最小值，但最少为 2个报文段）。此外，如果是超时引起了拥塞，则 cwnd被设置为 1个报文段（这就是慢启动）。

4) 当新的数据被对方确认时，就增加 cwnd，但增加的方法依赖于是否正在进行慢启动或拥塞避免。如果 cwnd 小于或等于 ssthresh，则正在进行慢启动，否则正在进行拥塞避免。

慢启动一直持续到以前拥塞发生时位置的一半时候才停止（因为前面记录了在步骤 2中给我们制造麻烦的窗口大小的一半），然后转为执行拥塞避免。

快重传和快恢复 接收端在接到失序的 TCP 报文，需要发重复的 ACK。

M1 A2

M2 A3

M3 ？（可能是丢失，也可能是停滞在路上）

M4 A3

M5 A3

M6

此前，重复的 ACK往往被作为拥塞的判断依据

当发方连续收到三个（或以上） A3 时，发方可以意识到： M3 可能丢失；并意识到有 M4 、 M5… 被收到。 另一方面，收到 1 、 2 个 A3 ，还可以认为可能是 A3失序。

处理：当连续收到 3 个重复的 ACK ，则立即重发 M3 ，而不必等到 M3 的超时再重发——即快重传。

进一步，接下来执行的不是慢启动算法而是拥塞避免算法—快恢复。 依据是：除 M3外，其他的都得以成功传送。

在这种情况下没有执行慢启动的原因是由于收到重复的 ACK不仅仅告诉我们一个分组丢失了。由于接收方只有在收到另一个报文段时才会产生重复的 ACK，而该报文段已经离开了网络并进入了接收方的缓存。也就是说，在收发两端之间仍然有流动的数据，而我们不想执行慢启动来突然减少数据流。

快恢复算法通常按如下过程进行实现：

1) 当收到第 3 个重复的 ACK 时，将 ssthresh设置为当前拥塞窗口cwnd的一半。重传丢失的报文段。设置 cwnd为 ssthresh加上 3倍的报文段大小（ MSS ）。

2) 每次收到另一个重复的 ACK 时， cwnd增加 1 个报文段大小并发送 1 个分组（如果新的 cwnd允许发送）。

3) 当下一个确认新数据的 ACK 到达时，设置 cwnd为 ssthresh（在第 1步中设置的值）。这个 ACK 应该是在进行重传后的一个往返时间内对步骤 1 中重传的确认。另外，这个 ACK也应该是对丢失的分组和收到的第 1 个重复的 ACK 之间的所有中间报文段的确认。这一步采用的是拥塞避免，因为当分组丢失时我们将当前的速率减半。

ssthresh=16

ssthresh=12 24/2

cwnd

快恢复

慢启动

六、拥塞控制——路由器早期丢弃（ RED ）

路由器的尾部丢弃策略（ tail drop polocy) ：当路由器队列满时，拒绝接受后续报文，导致报文丢弃。 这会导致大量源站点转入慢启动——又称全局同步。 此时，网络通信量大幅度降低，进而又恢复上来。

因此，路由器的丢弃策略是网络拥塞控制的重要因素。

路由器早期丢弃（ RED—— Random Early Drop ）是避免全局同步的较好方法。

平均队列长 LAV < 最小门限 Thmin : 丢弃概率 p=0

平均队列长 LAV > 最小门限 Thmin : 丢弃概率 p=1

其他： 0< p < 1

平均队列长度 —— 瞬时队列长度

最大门限 THmax

最小门限 THmin

到达报文

报文转出

平均队列长 LAV

路由器早期丢弃可以使少量源站点转入慢启动，从而避免全局同步。对网络拥塞的避免是比较有益的。