2.计算机网络通信基础

最新推荐文章于 2021-09-26 22:42:44 发布

zisuu

最新推荐文章于 2021-09-26 22:42:44 发布

阅读量737

点赞数

分类专栏： # 计算机网络计算机九阳神功文章标签：操作系统计算机网络

本文链接：https://blog.csdn.net/zisuu/article/details/110293898

版权

计算机九阳神功同时被 2 个专栏收录

16 篇文章 0 订阅

订阅专栏

计算机网络

5 篇文章 0 订阅

订阅专栏

网络通信基础

网络通信偏向于操作系统层面的知识,但是也是计算机网络的基础,是理解好计算机网络的的前提

0.同步,异步 ,阻塞/非阻塞

0.1 进程通信上下文的同步/异步，阻塞/非阻塞

首先强调一点，网络上的很多博文关于同步/异步，阻塞非阻塞区别的解释其实都很经不起推敲。例如怎样理解阻塞非阻塞与同步异步的区别这一高赞回答中，有如下解释（不准确）：

同步/异步关注的是消息通信机制 (synchronous communication/ asynchronous communication) 。
所谓同步，就是在发出一个调用时，在没有得到结果之前，该调用就不返回。
异步则是相反，调用在发出之后，这个调用就直接返回了，所以没有返回结果

阻塞/非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态.
阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。
非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。

粗一看，好像同步/ 非同步， 阻塞/非阻塞 是两种维度的概念，可以分别对待，但是稍微推敲一下就会发现上述的解释根本难以自圆其说。

如果**“同步”** 是发起了一个调用后，没有得到结果之前不返回，那它毫无疑问就是被"阻塞"了（即调用进程处于 “waiting” 状态）。
如果调用发出了以后就直接返回了，毫无疑问，这个进程没有被“阻塞”。

所以，上述的解释是不准确的。让我们看一下《操作系统概念（第九版）》中有关进程间通信的部分是如何解释的：

翻译一下就是：

进程间的通信时通过 send() 和 receive() 两种基本操作完成的。具体如何实现这两种基础操作，存在着不同的设计。
消息的传递有：

阻塞式发送（blocking send）. 发送方进程会被一直阻塞，直到消息被接受方进程收到。
非阻塞式发送（nonblocking send）。发送方进程调用 send() 后，立即就可以其他操作。
阻塞式接收（blocking receive）接收方调用 receive() 后一直阻塞，直到消息到达可用。
非阻塞式接受（nonblocking receive）接收方调用 receive() 函数后，要么得到一个有效的结果，要么得到一个空值，即不会被阻塞。

上述不同类型的发送方式和不同类型的接收方式，可以自由组合。

也就是说， 从进程级通信的维度讨论时，阻塞和同步（非阻塞和异步）就是一对同义词，且需要针对发送方和接收方作区分对待。

0.2 system call 层面

0.2.1 先修知识

用户空间和内核空间
进程切换
系统调用（system call）
中断（interrupt）

进程的阻塞

用户空间和内核空间

操作系统为了支持多个应用同时运行，需要保证不同进程之间相对独立（一个进程的崩溃不会影响其他的进程，恶意进程不能直接读取和修改其他进程运行时的代码和数据）。因此操作系统内核需要拥有高于普通进程的权限，以此来调度和管理用户的应用程序。

于是内存空间被划分为两部分，一部分为内核空间，一部分为用户空间，内核空间存储的代码和数据具有更高级别的权限。内存访问的相关硬件在程序执行期间会进行访问控制（ Access Control），使得用户空间的程序不能直接读写内核空间的内存。

有《微机原理》课程基础同学可以 Google 搜索 DPL, CPL 这两个关键字了解硬件层面的内存访问权限控制细节

进程切换

上图展示了进程切换中几个最重要的步骤：

当一个程序正在执行的过程中，中断（interrupt）或系统调用（system call）发生可以使得 CPU 的控制权会从当前进程转移到操作系统内核。
操作系统内核负责保存进程 i 在 CPU 中的上下文（程序计数器，寄存器）到 PCB 中。
从 PCB 取出进程 j 的CPU 上下文，将 CPU 控制权转移给进程 j ，开始执行进程 j 的指令。

几个底层概念的通俗（不严谨）解释：

中断（interrupt）
CPU 微处理器有一个中断信号位，在每个CPU时钟周期的末尾, CPU会去检测那个中断信号位是否有中断信号到达，如果有，则会根据中断优先级决定是否要暂停当前执行的指令，转而去执行处理中断的指令。（其实就是 CPU 层级的 while 轮询）

时钟中断( Clock Interrupt )
一个硬件时钟会每隔一段（很短）的时间就产生一个中断信号发送给 CPU，CPU 在响应这个中断时，就会去执行操作系统内核的指令，继而将 CPU 的控制权转移给了操作系统内核，可以由操作系统内核决定下一个要被执行的指令。

系统调用（system call）
system call 是操作系统提供给应用程序的接口。用户通过调用 systemcall 来完成那些需要操作系统内核进行的操作，例如硬盘，网络接口设备的读写等。

从上述描述中，可以看出来，操作系统在进行进切换时，需要进行一系列的内存读写操作，这带来了一定的开销：

对于一个运行着 UNIX 系统的现代 PC 来说，进程切换至少需要花费 300 us 的时间

进程阻塞

上图展示了一个进程的不同状态：

New。进程正在被创建.
Running. 进程的指令正在被执行
Waiting. 进程正在等待一些事件的发生（例如 I/O 的完成或者收到某个信号）。
Ready. 进程在等待被操作系统调度。
Terminated. 进程执行完毕（可能是被强行终止的）。

我们所说的 “阻塞”是指进程在发起了一个系统调用（System Call）后，由于该系统调用的操作不能立即完成，需要等待一段时间，于是内核将进程挂起为**等待（waiting）**状态，以确保它不会被调度执行，占用 CPU 资源。

友情提示： 在任意时刻，一个 CPU 核心上（processor）只可能运行一个进程 。

2.2.2 I/O System Call

这里再重新审视 阻塞/非阻塞 IO 这个概念，其实阻塞和非阻塞描述的是进程的一个操作是否会使得进程转变为“等待”的状态，但是为什么我们总是把它和 IO 连在一起讨论呢？

原因是，阻塞这个词是与系统调用 System Call 紧紧联系在一起的，因为要让一个进程进入等待（waiting）的状态, 要么是它主动调用 wait() 或 sleep() 等挂起自己的操作，另一种就是它调用 System Call, 而 System Call 因为涉及到了 I/O 操作，不能立即完成，于是内核就会先将该进程置为等待状态，调度其他进程的运行，等到它所请求的 I/O 操作完成了以后，再将其状态更改回 ready 。

操作系统内核在执行 System Call 时， CPU 需要与 IO 设备完成一系列物理通信上的交互，其实再一次会涉及到阻塞和非阻塞的问题，例如，操作系统发起了一个读硬盘的请求后，其实是向硬盘设备通过总线发出了一个请求，它即可以阻塞式地等待IO 设备的返回结果，也可以非阻塞式的继续其他的操作。在现代计算机中，这些物理通信操作基本都是异步完成的，即发出请求后，等待 I/O 设备的中断信号后，再来读取相应的设备缓冲区。但是，大部分操作系统默认为用户级应用程序提供的都是阻塞式的系统调用（blocking systemcall）接口，因为阻塞式的调用，使得应用级代码的编写更容易（代码的执!行顺序和编写顺序是一致的）。

但同样，现在的大部分操作系统也会提供非阻塞I/O 系统调用接口（Nonblocking I/O system call）。一个非阻塞调用不会挂起调用程序，而是会立即返回一个值，表示有多少bytes 的数据被成功读取（或写入）。

非阻塞I/O 系统调用( nonblocking system call )的另一个替代品是 异步I/O系统调用（asychronous system call）。与非阻塞 I/O 系统调用类似，asychronous system call 也是会立即返回，不会等待 I/O 操作的完成，应用程序可以继续执行其他的操作，等到 I/O 操作完成了以后，操作系统会通知调用进程（设置一个用户空间特殊的变量值或者触发一个 signal 或者产生一个软中断或者调用应用程序的回调函数）。

此处， 非阻塞I/O 系统调用( nonblocking system call ) 和 **异步I/O系统调用（asychronous system call）**的区别是：

一个非阻塞I/O 系统调用 read() 操作立即返回的是任何可以立即拿到的数据，可以是完整的结果，也可以是不完整的结果，还可以是一个空值。
而异步I/O系统调用 read（）结果必须是完整的，但是这个操作完成的通知可以延迟到将来的一个时间点。

下图展示了同步I/O 与异步 I/O 的区别（非阻塞 IO 在下图中没有绘出）.

注意，上面提到的 非阻塞I/O 系统调用( nonblocking system call ) 和 异步I/O系统调用 都是非阻塞式的行为（non-blocking behavior）。他们的差异仅仅是返回结果的方式和内容不同。

0.3 总结

同步(阻塞),异步(非阻塞)在进程级层面是一对同义词

但是在system Call 层面,有所区别

1 socket入门

1.1 socket简介

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。
你会使用它们吗？
前人已经给我们做了好多的事了，网络间的通信也就简单了许多，但毕竟还是有挺多工作要做的。以前听到Socket编程，觉得它是比较高深的编程知识，但是只要弄清Socket编程的工作原理，神秘的面纱也就揭开了。
一个生活中的场景。你要打电话给一个朋友，先拨号，朋友听到电话铃声后提起电话，这时你和你的朋友就建立起了连接，就可以讲话了。等交流结束，挂断电话结束此次交谈。生活中的场景就解释了这工作原理，也许TCP/IP协议族就是诞生于生活中，这也不一定。

图3

先从服务器端说起。服务器端先初始化Socket，然后与端口绑定(bind)，对端口进行监听(listen)，调用accept阻塞，等待客户端连接。在这时如果有个客户端初始化一个Socket，然后连接服务器(connect)，如果连接成功，这时客户端与服务器端的连接就建立了。客户端发送数据请求，服务器端接收请求并处理请求，然后把回应数据发送给客户端，客户端读取数据，最后关闭连接，一次交互结束。

1.2 socket基本操作

bind

linsten,connect

accept

read,write

close

1.3 socket和tcp的关系

1.3.1、socket中TCP的三次握手建立连接详解

我们知道tcp建立连接要进行“三次握手”，即交换三个分组。大致流程如下：

客户端向服务器发送一个SYN J
服务器向客户端响应一个SYN K，并对SYN J进行确认ACK J+1
客户端再想服务器发一个确认ACK K+1

只有就完了三次握手，但是这个三次握手发生在socket的那几个函数中呢？请看下图：

[

图1、socket中发送的TCP三次握手

从图中可以看出，当客户端调用connect时，触发了连接请求，向服务器发送了SYN J包，这时connect进入阻塞状态；服务器监听到连接请求，即收到SYN J包，调用accept函数接收请求向客户端发送SYN K ，ACK J+1，这时accept进入阻塞状态；客户端收到服务器的SYN K ，ACK J+1之后，这时connect返回，并对SYN K进行确认；服务器收到ACK K+1时，accept返回，至此三次握手完毕，连接建立。

总结：客户端的connect在三次握手的第二个次返回，而服务器端的accept在三次握手的第三次返回。

1.3.2、socket中TCP的四次握手释放连接详解

上面介绍了socket中TCP的三次握手建立过程，及其涉及的socket函数。现在我们介绍socket中的四次握手释放连接的过程，请看下图：

[

图2、socket中发送的TCP四次握手

图示过程如下：

某个应用进程首先调用close主动关闭连接，这时TCP发送一个FIN M；
另一端接收到FIN M之后，执行被动关闭，对这个FIN进行确认。它的接收也作为文件结束符传递给应用进程，因为FIN的接收意味着应用进程在相应的连接上再也接收不到额外数据；
一段时间之后，接收到文件结束符的应用进程调用close关闭它的socket。这导致它的TCP也发送一个FIN N；
接收到这个FIN的源发送端TCP对它进行确认。

这样每个方向上都有一个FIN和ACK。

2 五大io 模型

1.阻塞IO模型

最传统的一种IO模型，即在读写数据过程中会发生阻塞现象。

当用户线程发出IO请求之后，内核会去查看数据是否就绪，如果没有就绪就会等待数据就绪，而用户线程就会处于阻塞状态，用户线程交出CPU。当数据就绪之后，内核会将数据拷贝到用户线程，并返回结果给用户线程，用户线程才解除block状态。

典型的阻塞IO模型的例子为：data = socket.read();

如果数据没有就绪，就会一直阻塞在read方法。

2.非阻塞IO模型

当用户线程发起一个read操作后，并不需要等待，而是马上就得到了一个结果。如果结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦内核中的数据准备好了，并且又再次收到了用户线程的请求，那么它马上就将数据拷贝到了用户线程，然后返回。

所以事实上，在非阻塞IO模型中，用户线程需要不断地询问内核数据是否就绪，也就说非阻塞IO不会交出CPU，而会一直占用CPU。典型的非阻塞IO模型一般如下：

while(true){

data = socket.read();

if(data!= error){

处理数据

break;

}

}

但是对于非阻塞IO就有一个非常严重的问题，在while循环中需要不断地去询问内核数据是否就绪，这样会导致CPU占用率非常高，因此一般情况下很少使用while循环这种方式来读取数据。

3.多路复用IO模型

多路复用IO模型是目前使用得比较多的模型。Java NIO实际上就是多路复用IO。

在多路复用IO模型中，会有一个线程不断去轮询多个socket的状态，只有当socket真正有读写事件时，才真正调用实际的IO读写操作。因为在多路复用IO模型中，只需要使用一个线程就可以管理多个socket，系统不需要建立新的进程或者线程，也不必维护这些线程和进程，并且只有在真正有socket读写事件进行时，才会使用IO资源，所以它大大减少了资源占用。

在Java NIO中，是通过selector.select()去查询每个通道是否有到达事件，如果没有事件，则一直阻塞在那里，因此这种方式会导致用户线程的阻塞。

也许有朋友会说，我可以采用多线程+ 阻塞IO 达到类似的效果，但是由于在多线程 + 阻塞IO 中，每个socket对应一个线程，这样会造成很大的资源占用，并且尤其是对于长连接来说，线程的资源一直不会释放，如果后面陆续有很多连接的话，就会造成性能上的瓶颈。

而多路复用IO模式，通过一个线程就可以管理多个socket，只有当socket真正有读写事件发生才会占用资源来进行实际的读写操作。因此，多路复用IO比较适合连接数比较多的情况。

另外多路复用IO为何比非阻塞IO模型的效率高是因为在非阻塞IO中，不断地询问socket状态时通过用户线程去进行的，而在多路复用IO中，轮询每个socket状态是内核在进行的，这个效率要比用户线程要高的多。

不过要注意的是，多路复用IO模型是通过轮询的方式来检测是否有事件到达，并且对到达的事件逐一进行响应。因此对于多路复用IO模型来说，一旦事件响应体很大，那么就会导致后续的事件迟迟得不到处理，并且会影响新的事件轮询。

4.信号驱动IO模型

在信号驱动IO模型中，当用户线程发起一个IO请求操作，会给对应的socket注册一个信号函数，然后用户线程会继续执行，当内核数据就绪时会发送一个信号给用户线程，用户线程接收到信号之后，便在信号函数中调用IO读写操作来进行实际的IO请求操作。这个一般用于UDP中，对TCP套接口几乎是没用的，原因是该信号产生得过于频繁，并且该信号的出现并没有告诉我们发生了什么事情

5.异步IO模型

异步IO模型才是最理想的IO模型，在异步IO模型中，当用户线程发起read操作之后，立刻就可以开始去做其它的事。而另一方面，从内核的角度，当它受到一个asynchronous read之后，它会立刻返回，说明read请求已经成功发起了，因此不会对用户线程产生任何block。然后，内核会等待数据准备完成，然后将数据拷贝到用户线程，当这一切都完成之后，内核会给用户线程发送一个信号，告诉它read操作完成了。也就说用户线程完全不需要关心实际的整个IO操作是如何进行的，只需要先发起一个请求，当接收内核返回的成功信号时表示IO操作已经完成，可以直接去使用数据了。

也就说在异步IO模型中，IO操作的两个阶段都不会阻塞用户线程，这两个阶段都是由内核自动完成，然后发送一个信号告知用户线程操作已完成。用户线程中不需要再次调用IO函数进行具体的读写。这点是和信号驱动模型有所不同的，在信号驱动模型中，当用户线程接收到信号表示数据已经就绪，然后需要用户线程调用IO函数进行实际的读写操作；而在异步IO模型中，收到信号表示IO操作已经完成，不需要再在用户线程中调用iO函数进行实际的读写操作。

注意，异步IO是需要操作系统的底层支持，在Java 7中，提供了Asynchronous IO。简称AIO

前面四种IO模型实际上都属于同步IO，只有最后一种是真正的异步IO，因为无论是多路复用IO还是信号驱动模型，IO操作的第2个阶段都会引起用户线程阻塞，也就是内核进行数据拷贝的过程都会让用户线程阻塞。

两种高性能IO设计模式

在传统的网络服务设计模式中，有两种比较经典的模式：

一种是多线程，一种是线程池。

对于多线程模式，也就说来了client，服务器就会新建一个线程来处理该client的读写事件，如下图所示：

这种模式虽然处理起来简单方便，但是由于服务器为每个client的连接都采用一个线程去处理，使得资源占用非常大。因此，当连接数量达到上限时，再有用户请求连接，直接会导致资源瓶颈，严重的可能会直接导致服务器崩溃。

因此，为了解决这种一个线程对应一个客户端模式带来的问题，提出了采用线程池的方式，也就说创建一个固定大小的线程池，来一个客户端，就从线程池取一个空闲线程来处理，当客户端处理完读写操作之后，就交出对线程的占用。因此这样就避免为每一个客户端都要创建线程带来的资源浪费，使得线程可以重用。

但是线程池也有它的弊端，如果连接大多是长连接，因此可能会导致在一段时间内，线程池中的线程都被占用，那么当再有用户请求连接时，由于没有可用的空闲线程来处理，就会导致客户端连接失败，从而影响用户体验。因此，线程池比较适合大量的短连接应用。

因此便出现了下面的两种高性能IO设计模式：Reactor和Proactor。

在Reactor模式中，会先对每个client注册感兴趣的事件，然后有一个线程专门去轮询每个client是否有事件发生，当有事件发生时，便顺序处理每个事件，当所有事件处理完之后，便再转去继续轮询，如下图所示：

从这里可以看出，上面的五种IO模型中的多路复用IO就是采用Reactor模式。注意，上面的图中展示的是顺序处理每个事件，当然为了提高事件处理速度，可以通过多线程或者线程池的方式来处理事件。Java NIO使用的就是这种

在Proactor模式中，当检测到有事件发生时，会新起一个异步操作，然后交由内核线程去处理，当内核线程完成IO操作之后，发送一个通知告知操作已完成，可以得知，异步IO模型采用的就是Proactor模式。Java AIO使用的这种

3 多路复用io模型详解

3.0 基础

基础

在讲解之前，我们需要先知道计算机是如何接受网络数据的。简单来讲，就是当网络数据到达网卡的时候，网卡会通过中断控制器向CPU发送中断信号，CPU接受到中断信号的时候会根据接受到的中断向量号调用提前在中段描述符表中注册好的中断处理程序，中断处理程序会保存当前正在执行的程序的上下文，然后将网卡的中的数据复制到内核缓冲区，在等待空闲的时间将内核缓冲区的数据复制到用户缓冲区中供用户进程处理。

而我们知道，对于服务端建立socket的过程如下：
//创建socket
int s = socket(AF_INET, SOCK_STREAM, 0);   
//绑定
bind(s, ...)
//监听
listen(s, ...)
//接受客户端连接
int c = accept(s, ...)
//接收客户端数据
recv(c, ...);
//将数据打印出来
printf(...)
当和客户端成功完成3次握手后，便会调用recv阻塞等待接收客户端发送过来的数据。

实际上，当某个进程A执行到创建socket语句的时候，操作系统就会创建一个由文件系统管理的socket对象。socket包含了发送缓冲区、接收缓冲区、等待队列等。其中发送缓冲区和接收缓冲区就是我们TCP流量控制中用到的滑动窗口，而TCP本身就是全双工的，既可以发送数据，又可以接收数据，因此会有2个缓冲区。而等待队列指向的是所有等待该socket事件的进程。

image.png

当程序执行到recv的时候，操作系统会将进程A从工作队列移动到该socket的等待队列中（传个引用），进程B、C继续调度执行，A进程被阻塞

image.png

当socket接收到数据，操作系统便会将在该socket的等待队列上的进程重新放回工作队列中，由内核调度器继续调度执行，该进程变成运行状态，继续执行代码，由于socket的接收缓冲区已有了数据，recv便可接收返回的数据。

那么当数据到来的时候，操作系统如何知道是哪一个socket呢？一个进程又是如何监听多个socket的数据呢？

因为一条TCP连接对应一个四元组，TCP首部的信息中含有接收方的端口号信息，而一个socket对应着一个端口号，因此可以根据TCP头部的信息找到对应的socket，将数据复制到socket的接收缓冲区中；而进程正是通过IO多路复用的形式来监听多个socket（select和epoll）。

3.1 select

如下的代码中，准备一个数组fds，存放需要监视的所有socket，然后调用select，如果fds中所有的socket都没有数据，select会阻塞，直到有一个socket收到数据，select返回，唤醒进程，用户可以遍历fds，通过FD_ISSET判断哪个socket收到了数据，然后做出处理。
int s = socket(AF_INET, SOCK_STREAM, 0);  
bind(s, ...)
listen(s, ...)

int fds[] =  存放需要监听的socket

while(1){
int n = select(..., fds, ...)
for(int i=0; i < fds.count; i++){
if(FD_ISSET(fds[i], ...)){
   //fds[i]的数据处理
}
}
}
加入进程A同时监视如下图的sock1、sock2、sock3，调用select后操作系统会将进程A分别加入这3个socket的等待队列中。

当任何一个socket收到数据后，中断处理程序唤醒线程，加入工作队列

然后A继续执行，只需遍历一遍socket列表，就可以得到就绪的socket。

但是简单的方法往往有缺点，主要是：
其一，每次调用select都需要将进程加入到所有监视socket的等待队列，每次唤醒都需要从每个队列中移除。这里涉及了两次遍历，而且每次都要将整个fds列表传递给内核，有一定的开销。正是因为遍历操作开销大，出于效率的考量，才会规定select的最大监视数量，默认只能监视1024个socket。
其二，进程被唤醒后，程序并不知道哪些socket收到数据，还需要遍历一次。
那么，有没有减少遍历的方法？有没有保存就绪socket的方法？这两个问题便是epoll技术要解决的。

补充说明：本节只解释了select的一种情形。当程序调用select时，内核会先遍历一遍socket，如果有一个以上的socket接收缓冲区有数据，那么select直接返回，不会阻塞。这也是为什么select的返回值有可能大于1的原因之一。如果没有socket有数据，进程才会阻塞。

3.2 EPOLL

如下图所示，当某个进程调用epoll_create方法时，内核会创建一个eventpoll对象（也就是程序中epfd所代表的对象）。eventpoll对象也是文件系统中的一员，和socket一样，它也会有等待队列。

创建eventpoll对象后，可以通过epoll_ctl添加或者删除需要监听的socket。以添加socket为例，如下图，如果通过epoll_ctl添加sock1、sock2和sock3的监视，内核会将eventpoll添加到这三个socket的等待队列中。

image.png

当socket收到数据后，中断程序会操作eventpoll对象，而不是直接操作进程。

当socket收到数据后，中断程序会给eventpoll的“就绪列表”添加socket引用。如下图展示的是sock2和sock3收到数据后，中断程序让rdlist引用这两个socket。

所以eventpoll相当于一个中间层，位于socket和进程之间，socket的数据通过改变eventpoll的就序列表来改变进程状态。

假设计算机中正在运行进程A和进程B，在某时刻进程A运行到了epoll_wait语句。如下图所示，内核会将进程A放入eventpoll的等待队列中，阻塞进程。

image.png

当socket接收到数据，中断程序一方面修改rdlist，另一方面唤醒eventpoll等待队列中的进程，进程A再次进入运行状态（如下图）。也因为rdlist的存在，进程A可以知道哪些socket发生了变化。

image.png

3.3 poll

和epoll没有本质上的区别,就是没有socket数量的限制(用链表存储)

zisuu

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
1
评论
2.计算机网络通信基础

网络通信基础网络通信偏向于操作系统层面的知识,但是也是计算机网络的基础,是理解好计算机网络的的前提0.同步,异步 ,阻塞/非阻塞0.1 进程通信上下文的同步/异步，阻塞/非阻塞首先强调一点，网络上的很多博文关于同步/异步，阻塞非阻塞区别的解释其实都很经不起推敲。例如怎样理解阻塞非阻塞与同步异步的区别这一高赞回答中，有如下解释（不准确）：同步/异步关注的是消息通信机制 (synchronous communication/ asynchronous communication) 。
复制链接

扫一扫