Unix/Linux编程：理解面向连接和无连接协议之间的区别

矫情吗；* 2022-10-08 11:12 91阅读 0赞

网络编程中最基本的概念是**面向连接和无连接协议**。很显然，如果两台计算机要进行通信，就必须以某种形式“连接起来”，那“无连接通信”又是什么意思呢？

答案是：面向连接和无连接都是指协议。也就是说，这些术语指的并不是物理介质本身，而是用来说明如何在物理介质上传输数据的。

如果两者的区别于承载数据的物理介质无关，又和什么有关呢？它们的本质区别在于，**对无连接协议来说，每个分组的处理都独立于其他所有分组，而对面向连接的协议来说，协议实现则维护与后继分组有关的状态信息**

无连接协议中的分组被称为**数据报**，每个分组都是独立寻址，并由应用程序发送的。从协议的角度来看，每个数据报都是一个独立的实体，与在两个相同的对等实体之间传送的其他任何数据报都没有关系

> 注意，这并不是说从应用程序的角度来看，数据报也是独立的。简单的请求/应答协议，就是客户端向服务器发送一条请求，并收到一条应答，如果应用程序实现的功能比简单的请求/应答协议稍微复杂一点，就很可能需要维护数据报之间的状态。但问题的重点在于**状态是由应用程序，而不是由协议来维护的**

通常这就意味着客户端和服务器不会进行长期的对话------客户端发起一条请求，服务器会送一个应答。如果稍后客户端发起另一条请求，协议会认为这是与第一个事务无关的独立事务。

这还意味着协议很可能是不可靠的。也就是说，网络会尽最大努力传输每一个数据报，但并不保证数据报不丢失，不重复、不错序、不延迟，

另一方面，面向连接的协议则维护了分组之间的状态，使用这种协议的应用程序通常都会进行长期的对话。记住这些状态，协议就可以提供可靠的传输。比如，发送端也可以记住哪些数据已经发送出去了但还没有被确认，以及数据是什么时候发送的。如果在某段时间间隔内没有收到确认，发送方可以重传数据。接收端可以记住已经收到了哪些数据，并将重复的数据丢弃。如果分组不是按序到达的，接收端可以将其保存下来，直到逻辑上先于它的分组到达为止。

典型的面向连接协议有三个阶段。

*  第一阶段，在对等实体间建立连接。
 *  第二阶段，数据传输阶段，此时，数据在对等体间进行传输
 *  最后，当对等体完成数据传输时，关闭连接

无连接有那么多缺点，为什么还要用呢？

*  无连接协议是面向连接协议的基础
 *  使用无连接协议可以很方面的支持一对多和多对多通信，而面向连接通常需要多个独立的连接才能做到

我们先来看看TCP/IP协议族。如下TCP/IP是一个基于四层的协议栈  
![在这里插入图片描述][20210621095748573.png]  
栈的底部是链路层，直接与硬件相连。栈的底部是应用程序，比如Telnet、ftp和其他标准的以及用户编写的应用程序。如图所示，TCP和UDP的是构建在IP之上的。因此，IP是构建整个TCP/IP协议族的基础，但IP提供的是一种尽力而为的，不好看的无连接服务。它接收来自其他上层的分组，把它们封装在一个IP分组中，根据路由为分组选择正确的硬件接口，从这个接口将分组发送出去，一旦分组发送出去了，IP就不再关心这个分组了。

这种简单性也是IP的主要优点。因为它对底层的物理介质没有作任何假设，所以在任何能够承载分组的物理链路上都可以运行IP。比如，IP可以运行在简单的串行链路、以太网等上。尽管这些网络技术之间由很大的差异，但IP对它们一视同仁，除了认为它们可以转发分组之外没有对其作任何假设。因为IP可以运行在任何能够承载分组的网络上，所以整个TCP/IP协议族也可以。

现在我们来看看TCP是怎样利用这种简单的无连接服务来提供可靠的面向连接服务的。TCP的分组被称为段(segment)，是放在IP数据报中发送的，因此，根本无法假定这些分组会抵达目的地，更不用说保证分组无损坏而且以原来的顺序到达了。为了提供这种可靠性，TCP向基本的IP服务中添加了三项功能：

*  首先，它为TCP段中的数据提供了校验和。这样有助于确保抵达目的地的数据在传输过程中不会被损坏
 *  第二，它为每字节分配了一个校验和，这样，如果数据抵达目的地时真的错序了，接收端也能按照适当的顺序将其重装起来

> 当然，TCP并没有为每字节都附加一个序列号。实际上，每个TCP段的首部都包含了段中第一字节的序列号。这样，就隐含的知道了段中其他字节的序列号

*  第三，TCP提供了一种确认-重传机制，以确保最终每个段都会被传送出去

TCP连接的每一端都维护了一个接收窗口，接收窗口就是可以从对等实体接收的数据序列号范围。最小值表示窗口的左边界，是所期望的下一字节的序列号。最大值表示窗口的有边界，是TCP缓冲区空间能容纳字节的最大编号。使用接收窗口而不是所期望的下一字节计数器，就可以通过流量控制来提高可靠性。流量控制机制可以防止TCP传输的数据使其对等实体的缓冲区空间溢出。

TCP段到达时，序列号在接收窗口范围之外的所有数据都会被丢弃。其中包括先前已经收到的数据(序列号在接收窗口左边的数据)，以及没有缓冲区空间存储的数据(序列号在接收窗口右边的数据)。如果段中第一个可接受的字节不是所期望的下一字节，就说明这个段是错序的，大部分TCP应用程序都会将其放入队列，直到缺少的数据到达为止。如果段中第一个可接受字节是所期望的下一字节，就通知应用程序由数据可读，并在所期望的下一字节序列号上加上段中本次接受的字节数，对其进行更新。此时窗口向右滑动本次接收字节数的长度。最后，TCP向对等实体发送一条ACK，其中携带了它所期望的下一字节序列号。

比如：

*  下图A中，虚线框表示接收窗口显示，所期望的下一字节序列号是4，而TCP希望接收9字节(4-12)。
 *  图B显示的是收到字节4、5、6、7之后的接收窗口。窗口向右滑动了4个序列号。TCP的ACP说明它接下来所期望的是序列号8  
    ![在这里插入图片描述][20210621103542404.png]  
    同样是这种情况，现在从TCP发送端的角度来看。除了接收窗口之外，每个TCP还维护了一个发送窗口。发送窗口被划分为两部分：已经发送但还没被确认的字节，以及可以发送但还没发送的字节。
 *  假设字节1-3已经被确认了。下图A显示的是于上图A中接口窗口相对应的发送窗口
 *  字节4-7发送之后，确认之前，发送窗口如下图B所示。
 *  TCP还可以发送字节8-12而无需等待来自对等实体的ACK。
 *  发送了字节4-7之后，TCP还会启动一个PTO(retransmission timeout重传超时)定时器。如果在定时器超时之前这四个字节没有被确认，TCP就认为它们丢失了，并重传这四个字节。

>  *  很多实现并不记录一个特定的段中发送了哪些字节，因为重传段中包含的字节数可能会比原来的多。比如，如果字节8和9在RTO定时器超时之前发送出去了，这些应用程序还是会重传字节4-9
>  *  我们要注意一个这样的事实：RTO定时器超时并不意味着原来数据没有到达目的地。有可能是ACK丢失了，或者原来的段在网络中延时的时间太长，以至于在其ACK到达之前RTO定时器就超时了。但这不会造成什么问题，因为如何原来的数据确实到达了，那么重传的数据就会出于接收端TCP接收窗口范围之外，会被丢弃

*  字节4-7确认之后，发送端TCP会将其丢弃，并将发送窗口向右移动，如下图C所示

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]

从上可以看出，TCP为应用程序提供了一种可靠的面向连接的服务

另一方面，UDP为应用程序提供了一种不可靠的无连接服务。事实上，UDP只向底层的IP协议添加了两种功能：

*  首先，它提供了一个可选的校验和来检测数据的损坏情况。尽管IP也有检验和，但它只对IP分组首部进行计算，所以，TCP和UDP也都提供了检验和来保护它们自己的首部和数据。
 *  第二，提供了端口的概念

IP地址用来将一个IP数据报传输给一台特定的主机。数据报到达目的主机时，还需要将数据传送给恰当的应用程序。例如，一个UDP分组的目标可能是回声服务，而另一个目标可能是时间查询服务。端口提供了一种将数据多路分解到正确的应用程序的方式。每个TCP和UDP套接字都有一个与之相关的端口。应用程序可以显示的bind设置这个端口，也可以由操作系统为其选择。当分组到达时，内核会搜索套接字列表，查找一个与分组中的协议、地址和端口号相匹配的套接字。如果找到了匹配的套接字，就有指定的协议(UDP/TCP等)来处理数据，并将这些数据提供给所有打开了匹配套接字的应用程序。

> 如果有多个进程或者线程打开了这个套接字，那么其中任何一个都可以读取数据，但读过一次之后，数据对其他进程或者线程来说就不可用了

小结

*  不可靠的无连接数据是构造可靠的面向连接协议的基础。比如，TCP协议就是构建在不可靠的IP协议之上的

[20210621095748573.png]: /images/20221005/e59d4d5e8c8545469931d025f7f0ea7d.png
[20210621103542404.png]: /images/20221005/a7b9c07a21f34e46beeffd0f94d692fa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]: /images/20221005/d6b8ed3d0fec4fe4b5dda9fe0c255393.png