计算机网络

之前学习计网的笔记，巩固基础
计网-第一章-概述
 计网-第二章-物理层
 计网-第三章-数据链路层
 计网-第四章-网络层

第五章-运输层

计算机网络
第五章-运输层
总结

第五章-运输层

5.1 运输层概述

前几章所学的物理层、数据链路层、网络层它们共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信。

==但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。==进程的英文缩写词为AP。

如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议。
两个主机之间通信实际上是运行在两个主机上的程序进行通信，端到端通信也就是进程之间的通信。

在这里插入图片描述
从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。

当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时，只有位于网络边缘部分的主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到三层（到网络层）的功能。

进程之间通信流程

在学习和研究运输层时，我们可简单认为：运输层直接为应用进程间的逻辑通信提供服务。
“逻辑通信”是指运输层之间的通信好像是沿水平方向传送数据，但事实上，这两条数据并没有一条水平方向的物理连接，要传送的数据是沿着图中上下多次的虚线方向传送的

实际上，进程AP1与AP4之间进行基于网络的通信，进程AP2与AP3之间进行基于网络的通信是：
①在运输层使用不同的端口，来对应不同的应用进程
②然后通过网络层及其下层来传输应用层报文
③接收方的运输层通过不同的端口，将收到的应用层报文，交付给应用层中相应的应用进程
Note：这里端口并不是指看得见、摸得着的物理端口，而是指用来区分不同应用进程的标识符

小结

5.2 运输层端口号、复用与分用的概念

运行在计算机上的进程使用进程标识符PID来标志

因特网上的计算机并不是使用统一的操作系统，不同的操作系统（如windows、Linux、Mac OS）又使用不同的进程标识符

所以，为了运行不同操作系统的计算机的应用进程之间能够进行网络通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识
在这里插入图片描述
发送方的复用和接收方的分用

多个进程（这里的一个端口表示一个进程）利用一个运输层协议（或者称为运输层接口）发送数据称为复用
多个进程（这里一个端口表示一个进程）利用一个运输层协议（或者称为运输层接口）接收时叫做分用

如下图为收发双方的应用进程，在运输层使用UDP协议进行封装称为UDP复用，使用TCP协议进行封装称为TCP复用
运输层使用端口号区分不同的应用进程，无论是使用UDP封装成的用户数据报还是用TCP封装成的TCP报文段，在网络层都要使用IP协议封装成IP数据报，这称为IP复用。

TCP/IP体系的应用层常用协议所使用的运输层熟知端口号

IP数据报首部中协议字段的值表明了IP数据报数据载荷部分封装的是何种协议数据单元。

运输层传输流程

首先：在浏览器输入域名（如：www.porttest.com），按回车浏览—>
然后：用户PC中的DNS客户端进程会发送一个DNS查询请求报文
DNS查询请求报文需要使用运输层的UDP协议。
首部中的源端口字段的值，在短暂端口号49151~65535中挑选一个未被占用的，用来表示DNS客户端进程
首部中的目的端口字段的值：53，是DNS服务器端进程所使用的熟知端口号。

之后，将UDP用户数据报封装在IP数据报中，通过以太网发送给DNS服务器。

DNS服务器收到该IP数据报后，从中解封出UDP用户数据报。
UDP首部中的目的端口号为53，这表明应将该UDP用户数据报的数据载荷部分，也就是DNS查询请求报文，交付给本服务器中的DNS服务器端进程。
DNS服务器端进程解析DNS查询请求报文的内容，然后按其要求查找对应的IP地址。
之后，会给用户PC发送DNS响应报文，DNS响应报文需要使用运输层的UDP协议封装成UDP用户数据报。
其首部中的源端口字段的值设置为熟知端口号53，表明这是DNS服务器端进程所发送的UDP用户数据报，目的端口的值设置为49152，这是之前用户PC中发送DNS查询请求报文的DNS客户端进程所使用的短暂端口号。

将UDP用户数据报封装在IP数据报中，通过以太网发送给用户PC
.用户PC收到该数据报后，从中解封出UDP用户数据报。
UDP首部中的目的端口号为49152，这表明应将该UDP用户数据报的数据载荷部分，也就是DNS响应报文，交付给用户PC中的DNS客户端进程。
DNS客户端进程解析DNS响应报文的内容，就可知道自己之前所请求的Web服务器的域名对应的IP地址。

现在用户PC中的HTTP客户端进程可以向Web服务器发送HTTP请求报文（和DNS发送和接收流程差不多）

5.3 UDP和TCP的对比

两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元 TPDU (Transport Protocol Data Unit)。

UDP 和 TCP 是TCP/IP体系结构运输层中的两个重要协议。
TCP 传送的数据单位协议是 TCP 报文段(segment)。
UDP 传送的数据单位协议是 UDP 报文或用户数据报。

在这里插入图片描述

5.3.1 用户数据报协议UDP（User Datagram Protocol）

UDP可以发送广播、多播和单播

总的来说：UDP支持一对一，一对多，以及一对全的通信

发送过程
UDP是面向应用报文的：

UDP对应用进程交下来的报文既不合并也不拆分，而是保留这些报文的边界。
换句话说，UDP是面向应用报文的

UDP向上层提供无连接不可靠传输服务

UDP结构

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

使用TCP协议的通信双方，在进行数据传输之前，必须使用“三报文握手”建立TCP连接
TCP连接建立成功之后才能进行数据传输
数据传输结束后，必须使用“四报文挥手”来释放TCP连接。

TCP连接建立成功后，通信双方之间就好像有一条可靠的通信信道，通信双方使用这条基于TCP连接的可靠信道进行通信.。
很显然，TCP仅支持单播，也就是一对一的通信。

传输过程
发送方

TCP会把应用进程交付下来的数据块看作是一连串无结构的字节流, TCP并不知道这些待传送的字节流的含义

并将他们编号，并存储在自己发送缓存中

TCP会根据发送策略，提取一定量的字节构建TCP报文并发送
接收方

一方面从所接受到的TCP报文段中，取出数据载荷部分并存储在接收缓存中；一方面将接收缓存中的一些字节交付给应用进程

TCP不保证接收方应用进程所收到的数据块与发送方发送的数据块，具有对应大小的关系（例如，发送方应用进程交给发送方的TCP共10个数据块，但接收方的TCP可能只用了4个数据块，就把收到的字节流交付给了上层的应用进程，但接收方收到的字节流必须和发送方应用进程发出的字节流完全一样）

接收方的应用进程必须有能力识别收到的字节流，把它还原成有意义的应用层数据

TCP是面向字节流的，这正是TCP实现可靠传输、流量控制、以及拥塞控制的基础

下图只画了一个方向的数据流，但是在实际网络中，基于TCP连接的两端，可以同时进行TCP报文段的发送和接收。

TCP向上层提供面向连接的可靠传输服务

TCP结构

5.3.3 小结

UDP	TCP
无连接	面向连接
支持一对一、一对多、多对一和多对多交互通信	每一条TCP连接只能有两个端点EP，只能是一对一通信
对应用层交付的报文直接打包	面向字节流
尽最大努力交付，也就是不可靠传输；不使用流量控制和拥塞控制	可靠传输，使用流量控制和拥塞控制
首部开销小，仅8字节	首部开销大，最小20字节，最大60字节

5.4 TCP流量控制

在这里插入图片描述

假设：主机A发送的每个TCP数据报文段可携带100个字节数据，图中每个小格子代表100个字节数据的序号，主机A和B建立TCP连接时，B告诉A我的接受宽口为400，因此，A将字节的发送窗口设置为400。
主机B对主机A的流量控制：
主机A将发送窗口内序号1-100的数据封装成一个TCP报文段发送出去，发送窗口内还有300字节可发送,seq是TCP报文段中的序号字段，1代表TCP报文数据段数据载荷的第一个字节的序号是1.DATA表示这是TCP数据报文段，主机A将发送窗口内序号101-200的数据封装成一个TCP报文段发送出去，发送窗口内还有200字节可发送，主机A将发送窗口内序号201-300的数据封装成一个TCP报文段发送出去，但在传输过程中丢失了，发送窗口内还有100字节可发送。
主机B对主机A发送的201号字节以前的数据进行累计确认，并将窗口字段的值调节为300，也就是对主机A进行流量控制，这里ACK代表TCP报文段首部中的标志位，取值1表示这是一个TCP确认报文段，ack是TCP报文段首部中的确认号字段，取值201表示序号201之前的数据已全部正确接收，现在希望收到序号201及其后续数据，rwnd是TCP报文段首部中的窗口字段，取值300代表字节的接收窗口为300
主机A收到主机B的累计确认后将自己的窗口向前滑动，将已发送数据字段移除缓存，并将自己发送窗口调节为300，然后依次将301-400及401-500的数据发送出去，落在发送窗口内数据已经全部发送，现在不能再发送数据了，这时发送窗口内201-300的数据重传计时器超时了，主机A将其重新发送。
主机B对收到的501号以前的值累计确认，并将接受窗口调节为100，进行流量控制。
主机A调节字节的发送窗口为100，并将501-600的数据发送给主机B，且不再发送。
主机B对收到的601号之前的数据累计确认，并将发送窗口调节为0，进行流量控制。
主机A调节自己的发送窗口为0，且不能发送一般的TCP报文段。

采用零窗口探测报文段打破下述死锁局面
如果零窗口探测报文在发送过程中如果丢失，还是能打破死锁局面
因为零窗口探测报文段也有重传计时器，重传计时器超时后，零窗口探测报文段会被重传

小结

5.5 TCP的拥塞控制

5.5.1 拥塞控制基本概念

拥塞控制的一般原理：

拥塞控制的前提：网络能够承受现有的网络负荷。
实践证明，拥塞控制是很难设计的，因为它是一个动态问题。
分组的丢失是网络发生拥塞的征兆而不是原因。
在许多情况下，甚至正是拥塞控制本身成为引起网络性能恶化、甚至发生死锁的原因。

如下图：若不对拥塞进行控制，整个网络的吞吐量将随输入负荷的增大而下降。

输入负载：单位时间内输入给网络的分组数量。

吞吐量：单位时间内从网络输出的分组数量。
我们应力争使实际拥塞控制接近理想的拥塞控制。

在这里插入图片描述

网络拥塞往往是由许多因素引起的。例如：
①点缓存的容量太小；
②链路的容量不足；
③处理机处理的速率太慢；
④拥塞本身会进一步加剧拥塞；

5.5.2 TCP得四种拥塞控制算法

在这里插入图片描述

慢开始和拥塞避免

慢开始（slow-start）

目的：用来确定网络的负载能力或拥塞程度。

算法的思路：由小到大逐渐增大拥塞窗口数值。
两个变量：

①拥塞窗口（cwnd）：初始拥塞窗口值：2 种设置方法。窗口值逐渐增大。

1 至 2 个最大报文段（旧标准）

2 至 4 个最大报文段（RFC 5681）

②慢开始门限（ssthresh）：防止拥塞窗口增长过大引起网络拥塞。

拥塞避免（congestion avoidance）
思路：让拥塞窗口 cwnd 缓慢地增大（依次+1缓慢增长），避免出现拥塞。
①每经过一个传输轮次，拥塞窗口 cwnd = cwnd + 1。
②使拥塞窗口 cwnd 按线性规律缓慢增长。
③在拥塞避免阶段，具有 “加法增大” (Additive Increase) 的特点。

如下图：
一开始，设置拥塞窗口cwnd的值为1，慢开始门限（ssthresh）为初始值为16，设置发送窗口swnd=cwnd。

在这里插入图片描述

当执行慢开始算法时，发送方没收到一个对新报文段的确认时就把拥塞窗口+1，然后开始下一轮传输，每经过一个传输轮次，拥塞窗口就加倍，即窗口大小按指数增加。，当拥塞窗口值增长到慢开始门限值时，就改为执行拥塞避免算法。
如果在发送过程中出现部分报文段丢失，这必然会造成发送方对这些丢失报文段的超时重传，即图中的红点部分。发送方一次判断网络可能出现拥塞，需要进行以下工作：
①将慢开始门限值更新为发送拥塞时拥塞窗口的一半。
②将拥塞窗口值减小为1，并重新执行慢开始算法，当拥塞窗口达到慢开始门限就执行拥塞避免算法。

传输轮次：发送方给接收方发送数据报文段后，接收方给发送方发发回相应的确认报文段
一个传输轮次所经历的时间其实就是往返时间，往返时间并非是恒定的数值
使用传输轮次是为了强调把拥塞窗口所允许发送的报文段都连续发送出去，并受到了对已发送的最后一个报文段的确认
拥塞窗口：它会随网络拥塞程度，以及所使用的拥塞控制算法动态变化

快重传和快恢复

在这里插入图片描述

快重传（fast retrasmit）

快恢复（fast recovery）

例题
在这里插入图片描述
小结

5.6 TCP超时重传时间的选择

如果超时重传时间RTO的值设置得比RTT0的值小，这会引起报文段不必要的重传，使网络负荷增大。

如果超时重传时间RTO的值设置得远大于RTT0的值，这会使重传时间推迟的太长，使网络的空闲时间增大，降低传输效率。

我们不能直接使用某次测量得到的RTT样本来计算超时重传时间RTO

但我们可以利用每次测量得到的RTT样本，计算加权平均往返时间RTT_s

测量到第一个RTT样本时，RTT_s=第一个RTT样本值。
以后每测量得到一个RTT样本，RTT_s为：

RFC6298建议使用下式计算超时重传时间RTO

往返时间RTT的测量比较复杂

TCP超时重传的计算

总结
在这里插入图片描述

5.7 TCP可靠传输的实现

在这里插入图片描述

例题1：

这题要注意的是：TCP规定只能对按序到达的最高序号进行确认
确认序号为：500，表明序号499为止的全部数据已经收到了，希望接收500号及以后的数据。

5.8 TCP的运输连接管理

5.8.1 TCP连接的建立

在这里插入图片描述

TCP 建立连接的过程叫做握手。握手需要在客户和服务器之间交换三个TCP 报文段。称之为三报文握手。
采用三报文握手主要是为了防止已失效的连接请求报文段突然又传送到了，因而产生错误。

TCP的连接建立要解决以下三个问题：
①使TCP双方能够确知对方的存在
②使TCP双方能够协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）
③使TCP双方能够运输实体资源（如缓存大小、连接表中的项目等）进行分配。

TCP使用“三报文握手”建立连接的过程：
下图为两台要基于TCP进行通信的主机。
其中一台主机中的某个应用进程主动发起TCP连接建立，称为TCP客户。
另一台主机中被动等待TCP连接建立的应用进程称为TCP服务器。

我们可以将TCP 建立连接的过程叫做握手。“握手”需要在TCP客户端和服务器之间交换三个TCP报文段。

最初两端的TCP进程都处于关闭状态
一开始，TCP服务器进程首先创建传输控制块，用来存储TCP连接中的一些重要信息。例如TCP连接表、指向发送和接收缓存的指针、指向重传队列的指针，当前的发送和接收序号等

之后，就准备接受TCP客户端进程的连接请求
此时，TCP服务器进程就进入监听状态，等待TCP客户端进程的连接请求。
TCP服务器进程是被动等待来自TCP客户端进程的连接请求，因此称为被动打开连接。

TCP客户进程也是首先创建传输控制块，然后在打算建立TCP连接时向TCP服务器进程发送TCP连接请求报文段
由于TCP连接建立是由TCP客户端主动发起的，因此称为主动打开连接

然后，在打算建立TCP连接时，向TCP服务器进程发送TCP连接请求报文段，并进入同步已发送状态
TCP连接请求报文段首部中：

同步位SYN被设置为1，表明这是一个TCP连接请求报文段

序号字段seq被设置了一个初始值x，作为TCP客户端进程所选择的初始序号
注意：TCP规定SYN被设置为1的报文段不能携带数据，但要消耗掉一个序号

TCP服务器进程收到TCP连接请求报文段后，如果同意建立连接，则向TCP客户进程发送TCP连接请求确认报文段，并进入同步已接收状态
TCP连接请求确认报文段首部中:

同步位SYN和确认为ACK都设置为1，表明这是一个TCP连接请求确认报文段

序号字段seq被设置了一个初始值y，作为TCP服务器进程所选择的初始序号。（随机指定）

确认号字段ack的值被设置成了x+1，这是对TCP客户进程所选择的初始序号（seq）的确认
注意：这个报文段也不能携带数据，因为它是SYN被设置为1的报文段，但同样要消耗掉一个序号

TCP客户进程收到TCP连接请求确认报文段后，还要向TCP服务器进程发送一个普通的TCP确认报文段，并进入连接已连接状态
普通的TCP确认报文段首部中
确认位ACK被设置为1，表明这是一个普通的TCP确认报文段
序号字段seq被设置为x+1，这是因为TCP客户进程发送的第一个TCP报文段的序号为x，所以TCP客户进程发送的第二个报文段的序号为x+1
确认号字段ack被设置为y+1，这是对TCP服务器进程所选择的初始序号的确认
注意：TCP规定普通的TCP确认报文段可以携带数据，但如果不携带数据，则不消耗序号

TCP服务器进程收到该确认报文段后也进入连接已建立状态
现在，TCP双方都进入了连接已建立状态，它们可以基于已建立好的TCP连接，进行可靠的数据传输

为什么TCP客户进程最后还要发送一个普通的TCP确认报文段？能否使用“两报文握手”建立连接？
通过下图的“两报文握手”我们可以发现这并不多余，这是为了防止已失效的连接请求报文段突然又传送到了TCP服务器，因而导致错误。
在这里插入图片描述
例题

小结

5.8.2 TCP连接释放

TCP 连接释放过程比较复杂。数据传输结束后，通信的双方都可释放连接。

TCP 连接释放过程是“四报文挥手”。
TCP 连接的建立采用客户服务器方式。

主动发起连接建立的应用进程叫做TCP客户 (client)。

被动等待连接建立的应用进程叫做TCP服务器 (server)。

任何一方都可以在数据传送结束后发出连接释放的通知

现在TCP客户进程和TCP服务器进程都处于连接已建立状态
TCP客户进程的应用进程通知其主动关闭TCP连接
TCP客户进程会发送TCP连接释放报文段，并进入终止等待1状态
TCP连接释放报文段首部中
终止位FIN和确认为ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认
序号seq字段的值设置为u，它等于TCP客户进程之前已传送过的数据的最后一个字节的序号加1
确认号ack字段的值设置为v，它等于TCP客户进程之前已收到的、数据的最后一个字节的序号加1
请注意：TCP规定终止位FIN等于1的报文段即使不携带数据，也要消耗掉一个序号

TCP服务器进程收到TCP连接释放报文段后，会发送一个普通的TCP确认报文段并进入关闭等待状态
普通的TCP确认报文段首部中
确认位ACK的值被设置为1，表明这是一个普通的TCP确认报文段
序号seq字段的值设置为v，它等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1，这也与之前收到的TCP连接释放报文段中的确认号匹配
确认号ack字段的值设置为u+1，这是对TCP连接释放报文段的确认

TCP服务器进程应该通知高层应用进程，TCP客户进程要断开与自己的TCP连接
此时，从TCP客户进程到TCP服务器进程这个方向的连接就释放了
这时的TCP连接属于半关闭状态，也就是TCP客户进程已经没有数据要发送了
但如果TCP服务器进程还有数据要发送，TCP客户进程仍要接收，也就是说从TCP服务器进程到TCP客户进程这个方向的连接并未关闭。

TCP客户进程收到TCP确认报文段后就进入终止等待2状态，等待TCP服务器进程发出的TCP连接释放报文段
若使用TCP服务器进程的应用进程已经没有数据要发送了，应用进程就通知其TCP服务器进程释放连接
由于TCP连接释放是由TCP客户进程主动发起的，因此TCP服务器进程对TCP连接的释放称为被动关闭连接。

TCP服务器进程发送TCP连接释放报文段并进入最后确认状态
该报文段首部中
终止位FIN和确认位ACK的值都被设置为1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认
序号seq字段的值为w，这是因为在半关闭状态下，TCP服务器进程可能又发送
确认号ack字段的值为u+1，这是对之前收到的TCP连接释放报文段的重复确认

TCP客户进程收到TCP连接释放报文段后，必须针对该报文段发送普通的TCP确认报文段，之后进入时间等待状态
该报文段首部中
确认为ACK的值被设置为1，表明这是一个普通的TCP确认报文段
序号seq字段的值设置为u+1，这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据，但要消耗掉一个序号
确认号ack字段的值设置为w+1，这是对所收到的TCP连接释放报文段的确认
TCP服务器进程收到该报文段后就进入关闭状态，而TCP客户进程还要进过2MSL后才能进入关闭状态

TCP客户进程在发送完最后一个确认报文后，为什么不直接进入关闭状态？而是要进入时间等待状态？
在这里插入图片描述
答：首先，因为时间等待状态以及处于该状态2MSL时长，可以确保TCP服务器进程可以收到最后一个TCP确认报文段而进入关闭状态
另外，TCP客户进程在发送完最后一个TCP确认报文段后，在经过2MSL时长，就可以使本次连接持续时间内所产生的所有报文段都从网络中消失，这样就可以使下一个新的TCP连接中，不会出现旧连接中的报文段