传输层协议（TCP, UDP）

Posted 2023-05-08

参考技术A

传输层定义了主机应用程序之间端到端的连通性。传输层中最为常见的两个协议分别是传输控制协议TCP（Transmission Control Protocol）和用户数据报协议UDP（User Datagram Protocol）。

为了简化问题说明，本课程以Telnet为例描述相关技术。设备支持通过Telnet协议和Stelnet协议登录。使用Telnet，Stelnet v1协议存在安全风险，建议你使用STelnet v2登录设备。
为了简化问题说明，本课程以FTP为例来描述相关技术。设备支持通过FTP协议，TFTP以及SFTP传输文件。使用FTP，TFTP，SFTP v1协议存在风险，建议使用SFTP v2方式进行文件操作。

TCP是一种面向连接的传输层协议，提供可靠的传输服务。

TCP是一种面向连接的端到端协议。TCP作为传输控制协议，可以为主机提供可靠的数据传输。TCP需要依赖网络协议为主机提供可用的传输路径。

TCP允许一个主机同事运行多个应用进程。每台主机可以拥有多个应用端口，没对端口号，源和目标IP地址的组合唯一地标识了一个会话。端口分为知名端口和动态端口。有些网络服务会使用固定的端口，这类端口称为知名端口，端口号范围为 0~1023 。
比如：FTP，HTTP，Telnet，SNMP服务均使用知名端口。
动态端口范围 1024~65535 ，这些端口号一般不会固定分配给某个服务，也就是说许多服务都可以使用这些端口。只要运行的程序向系统提出访问网络的申请，那么系统就可以从这些端口号中分配一个供该程序使用。

TCP通常使用IP作为网络层协议，这是TCP数据被封装在IP数据包内。TCP数据段由TCP Header（头部）和TCP Data（数据）组成。TCP最多可以有60个字节的头部，如果没有Options字段，正常的长度是20字节。

TCP Header是由如上图标识一些字段组成，这里列出几个常用字段。

注意：

1）主机A（通常也叫客户端）发送一个标识了SYN数据段，标识期望与服务器A建立连接，此数据段的序列号（seq）为a；
2）服务器A回复标识了SYN+ACK的数据段，此数据段的序列号（seq）为b，确认序列号为主机A的序列号加1（a+1），以此作为对主机A的SYN报文的确认。
3）主机A发送一个标识了ACK的数据段，此数据段的序列号（seq）为a+1，确认序列号为服务器A的序列号加1（b+1），以此作为对服务器A的SYN报文段的确认。

TCP是一种可靠的，面向连接的全双工传输层协议。
TCP连接的简历是一个三次握手的过程。

TCP的可靠传输还提现在TCP使用了确认技术来确保目的设备收到了从源设备发来的数据，并且是准确无误的。
确认技术的工作原理如下：
目的设备接收到源设备发送的数据段时，会向源端发送确认报文，源设备收到确认报文后，继续发送数据段，如此重复。
如图所示，主机A向服务器A发送TCP数据段，为描述方便假设每个数据段的长度都是500个字节。
当服务器A成功收到序列号是M+1499的字节以及之前的所有字节时，会以序列号M+1400+1=M+1500进行确认。另外，由于数据段N+3传输失败，所以服务器A未能收到序列号为M+1500的字节，因此服务器A还会再次以序列号M+1500进行确认。

注意：上面说到，数据段 N+3 传输失败，那么第二次确认号M+1500，主机A会将N+3，N+4，N+5全部发送一次。

TCP滑动窗口技术通过动态改变窗口大小来实现对端到端设备之间的数据传输进行流量控制。
如图所示，主机A和服务器A之间通过滑动窗口来实现流量控制。为了方便理解，此例中只考虑主机A发送数据给服务器A时，服务器A通过滑动窗口进行流量控制。

例子中：
主机A向服务器发送4个长度为1024字节的数据段，其中主机的窗口大小为4096个字节。服务器A收到第3个字节之后，缓存区满，第4个数据段被丢弃。服务器以ACK3073（1024*3=3072）响应，窗口大小调整为3072，表明服务器的缓冲区只能处理3072个字节的数据段。于是主机A改变其发送速率，发送窗口大小为3072的数据段。

主机在关闭连接之前，要确认收到来自对方的ACK。

TCP支持全双工模式传输数据，这意味着统一时刻两个方向都可以进行数据的传输。在传输数据之前，TCP通过三次握手建立的实际上是两个方向的连接，一次在传输完毕后，两个方向的连接必须都关闭。
TCP连接的建立是一个三次握手过程，而TCP连接的终止则要经过四次挥别。

如图：
1.主机A想终止连接，于是发送一个标识了FIN，ACK的数据段，序列号为a，确认序列号为b。
2.服务器A回应一个标识了ACK的数据段，序列号为b，确认序号为a+1，作为对主机A的FIN报文的确认。
3.服务器A想终止连接，于是向主机A发送一个标识了FIN，ACK的数据段，序列号为b，确认好为a+1。
4.主机A回应一个标识了ACK的数据段，序列号为a+1，确认序号为b+1，作为对服务器A的FIN报文的确认。
以上四次交互完成了两个方向连接的关闭。

TCP断开连接的步骤，这个比较详细：
https://blog.csdn.net/ctrl_qun/article/details/52518479

UDP是一种面向无连接的传输层协议，传输可靠性没有保证。

当应用程序对传输的可靠性要求不高时，但是对传输速度和延迟要求较高时，可以用UDP协议来替代TCP协议在传输层控制数据的转发。UDP将数据从源端发送到目的端时，无需事先建立连接。UDP采用了简单，容易操作的机制在应用程序间传输数据，没有使用TCP中的确认技术或滑动窗口机制，因此UDP不能保证数据传输的可靠性，也无法避免接受到重复数据的情况。

UDP头部仅占8个字节，传输数据时没有确认机制（注意，但是有校验和）。

UDP报文分为UDP报文头和UDP数据区域两个部分。报头由源端口，目的端口，报文长度以及校验和组成。UDP适合于实时数据传输，比如语音和视频通信。相比TCP，UDP的传输效率更高，开销更小，但是无法保证数据传输可靠性。UDP头部的标识如下：
1）16位源端口号：源主机的应用程序使用的端口号。
2）16位目的端口号：目的主机的应用程序使用的端口号。
3）16位UDP长度：是指UDP头部和UDP数据的字节长度。因为UDP头部长度是8字节，所以字段的最小值为8。
4）16位UDP校验和：该字段提供了与TCP校验字段同样的功能；该字段是可选的。

使用UDP传输数据时，由 应用程序 根据需要提供报文到达确认，排序，流量控制等功能。

主机A发送数据包时，这些数据包是以有序的方式发送到网络中的，每个数据包独立地在网络中被发送，所以不同的数据包可能会通过不同的网路径叨叨主机B。这样的情况下，先发送的数据包不一定先到达主机B。因为UDP数据包没有序号，主机B将无法通过UDP协议将数据包按照原来的顺序重新组合，所以此时需要 应用程序 提供报文的到达确认，排序和流量控制等功能（也就是说UDP报文的到达确认，排序和流量控制是应用程序来确定的）。通常情况下，UDP采用实时传输机制和时间戳来传输语音和视频数据。

UDP适合传输对延迟敏感的流量，如语音和视频。
在使用TCP协议传输数据时，如果一个数据段丢失或者接受端对某个数据段没有确认，发送端会重新发送该数据段。
TCP重新发送数据会带来传输延迟和重复数据，降低了用户的体验。对于延迟敏感的应用，少量的数据丢失一般可以被忽略，这是使用UDP传输能够提升用户的体验。

总结：
1.TCP头部中的确认标识位有什么作用呢？
TCP报文头中的ACK标识位用于目的端对已接受到数据的确认。目的端成功收到序列号为x的字节后，会以序列号x+1进行确认。
2.TCP头部中有哪些标识位参与TCP三次握手？
在TCP三次握手过程中，要使用SYN和ACK标识位来请求建立连接和确认建立连接。

TCP 与 UDP 协议简介

传输层位于 OSI 七层模型的第四层（由下往上）。顾名思义，传输层的主要作用是实现应用程序之间的通信。网络层主要是保证不同数据链路下数据的可达性，至于如何传输数据则是由传输层负责。

传输层协议简介

常见的传输层协议主要有 TCP 协议和 UDP 协议。TCP 协议是面向有连接的协议，也就是说在使用 TCP 协议传输数据之前一定要在发送方和接收方之间建立连接。一般情况下建立连接需要三步，关闭连接需要四步。

建立 TCP 连接后，由于有数据重传、流量控制等功能，TCP 协议能够正确处理丢包问题，保证接收方能够收到数据，与此同时还能够有效利用网络带宽。然而 TCP 协议中定义了很多复杂的规范，因此效率不如 UDP 协议，不适合实时的视频和音频传输。

UDP 协议是面向无连接的协议，它只会把数据传递给接收端，但是不会关注接收端是否真的收到了数据。但是这种特性反而适合多播，实时的视频和音频传输。因为个别数据包的丢失并不会影响视频和音频的整体效果。

不同的端口用于区分同一台主机上不同的应用程序。假设你打开了两个浏览器，浏览器 A 发出的请求不会被浏览器 B 接收，这就是因为 A 和 B 具有不同的端口。

协议号用于区分使用的是 TCP 还是 UDP。因此相同两台主机上，相同的两个进程之间的通信，在分别使用 TCP 协议和 UDP 协议时也可以被正确的区分开来。

UDP 首部

UDP 协议最大的特点就是简单，它的首部如下图所示：

包长度表示 UDP 首部的长度和 UDP 数据长度之和。

这个概念同样适用于即将介绍的 TCP 首部。

TCP 首部

和 UDP 首部相比，TCP 首部要复杂得多。解析这个首部的时间也相应的会增加，这是导致 TCP 连接的效率低于 UDP 的原因之一。

其中某些关键字段解释如下：

• 序列号：它表示发送数据的位置，假设当前的序列号为 s，发送数据长度为 l，则下次发送数据时的序列号为 s + l。在建立连接时通常由计算机生成一个随机数作为序列号的初始值。

• 确认应答号：它等于下一次应该接收到的数据的序列号。假设发送端的序列号为 s，发送数据的长度为 l，那么接收端返回的确认应答号也是 s + l。发送端接收到这个确认应答后，可以认为这个位置以前所有的数据都已被正常接收。

• 数据偏移：TCP 首部的长度，单位为 4 字节。如果没有可选字段，那么这里的值就是 5。表示 TCP 首部的长度为 20 字节。

• 控制位：改字段长度为 8 比特，分别有 8 个控制标志。依次是 CWR，ECE，URG，ACK，PSH，RST，SYN 和 FIN。在后续的文章中你会陆续接触到其中的某些控制位。

• 窗口大小：用于表示从应答号开始能够接受多少个 8 位字节。如果窗口大小为 0，可以发送窗口探测。

• 紧急指针：尽在 URG 控制位为 1 时有效。表示紧急数据的末尾在 TCP 数据部分中的位置。通常在暂时中断通信时使用（比如输入 Ctrl + C）。

TCP 握手

TCP 是面向有连接的协议，连接在每次通信前被建立，通信结束后被关闭。了解连接建立和关闭的过程通常是考察的重点。连接的建立和关闭过程可以用一张图来表示：

通常情况下，我们认为客户端首先发起连接。

三次握手建立连接

这个过程可以用以下三句形象的对话表示：

1. （客户端）：我要建立连接了。

2. （服务端）：我知道你要建立连接了，我这边没有问题。

3. （客户端）：我知道你知道我要建立连接了，接下来我们就正式开始通信。

为什么是三次握手

根据一般的思路，我们可能会觉得只要两次握手就可以了，第三步确认看似是多余的。那么 TCP 协议为什么还要费力不讨好的加上这一次握手呢？

这是因为在网络请求中，我们应该时刻记住：“网络是不可靠的，数据包是可能丢失的”。假设没有第三次确认，客户端向服务端发送了 SYN，请求建立连接。由于延迟，服务端没有及时收到这个包。于是客户端重新发送一个 SYN 包。回忆一下介绍 TCP 首部时提到的序列号，这两个包的序列号显然是相同的。

假设服务端接收到了第二个 SYN 包，建立了通信，一段时间后通信结束，连接被关闭。这时候最初被发送的 SYN 包刚刚抵达服务端，服务端又会发送一次 ACK 确认。由于两次握手就建立了连接，此时的服务端就会建立一个新的连接，然而客户端觉得自己并没有请求建立连接，所以就不会向服务端发送数据。从而导致服务端建立了一个空的连接，白白浪费资源。

在三次握手的情况下，服务端直到收到客户端的应答后才会建立连接。因此在上述情况下，客户端会接受到一个相同的 ACK 包，这时候它会抛弃这个数据包，不会和服务端进行第三次握手，因此避免了服务端建立空的连接。

ACK 确认包丢失怎么办

三次握手其实解决了第二步的数据包丢失问题。那么第三步的 ACK 确认丢失后，TCP 协议是如何处理的呢？

正确处理方法是服务端发送 RST 报文，进入 CLOSE 状态。这个 RST 数据包的 TCP 首部中，控制位中的 RST 位被设置为 1。这表示连接信息全部被初始化，原有的 TCP 通信不能继续进行。客户端如果还想重新建立 TCP 连接，就必须重新开始第一次握手。

四次握手关闭连接

这个过程可以用以下四句形象的对话表示：

1. （客户端）：我要关闭连接了。

2. （服务端）：你那边的连接可以关闭了。

3. （服务端）：我这边也要关闭连接了。

4. （客户端）：你那边的连接可以关闭了。

由于连接是双向的，所以双方都要主动关闭自己这一侧的连接。

关闭连接的最后一个 ACK 丢失怎么办

实际上，在第三步中，客户端收到 FIN 包时，它会设置一个计时器，等待相当长的一段时间。如果客户端返回的 ACK 丢失，那么服务端还会重发 FIN 并重置计时器。假设在计时器失效前服务器重发的 FIN 包没有到达客户端，客户端就会进入 CLOSE 状态，从而导致服务端永远无法收到 ACK 确认，也就无法关闭连接。

示意图如下：