Windows系统之间的文件共享是采用什么协议的?

Windows系统之间的文件共享用的是NetBIOS，但NetBIOS不是协议，是接口。

服务器信息块（SMB）协议是一种IBM协议，用于在计算机间共享文件、打印机、串口等。SMB 协议可以用在因特网的TCP/IP协议之上，也可以用在其它网络协议如IPX和NetBEUI 之上。

在一个网络环境中，服务器可以给客户端提供文件系统和文件资源的服务。客户端在访问服务器端的文件资源时，必须先想服务器端发送请求，并得到服务器的许可。

但是由于设计上的原因，Windows 系统无法正确处理畸形SMB请求，本地/远程攻击者可利用此缺陷进行拒绝服务攻击，甚至能够以系统权限在目标系统上执行任意指令。

扩展资料：

在网络环境下，通过FTP实现了在不同操作系统的主机之间相互传输文件，从使用角度看，共享文件系统几乎不用你考虑网络传输和访问的细节，完全可以像访问本地文件一样访问网络上其它服务器文件系统上的文件。这可以在一定程度上解决开始提的问题，即为集群中的多台实际服务器共享同一台物理存储设备。

刚才提到的同一台物理存储设备可以是独立的一台服务器如服务器，也可以是集群中某台实际服务器的磁盘。

-共享文件系统

在多个服务器之间共享数据是目前很多企业开始使用的方法，可以在多台服务器之间得到相应的信息，同时也可以减少服务器的压力，方便开发人员的操作，至于如何实现多台服务器之间的信息共享，有很多方法可以实现，至于哪种方法更安全有效还需要我们继续探索。

在创建上载和操作文件的多步骤表单时，如果应用程序在负载均衡器后面的多个服务器上运行，那么我们需要确保该文件在整个过程执行期间都可用，所以无论哪个服务器在每一步都处理该过程。

当提供用于处理用户上载的文件的某些功能时，该文件在整个执行过程中必须可用于该过程。简单的上传和保存操作不会产生任何问题。但是，如果此外文件必须在保存之前进行操作，并且应用程序在负载均衡器后面的多个服务器上运行，那么我们需要确保该文件可用于每次运行该进程的任何服务器。

例如，多步骤“上传你的用户头像”功能可能要求用户在步骤一上传头像，在步骤二中裁剪，最后在步骤三中保存。文件在步骤上传到服务器之后，该文件必须可用于处理步骤二和三的请求的任何服务器，步骤二和步骤一的请求可能相同或不同。

一种比较不靠谱的方法是将步骤一中上传的文件复制到所有其他服务器，因此该文件将全部可用。但是，这种方法不仅极其复杂，而且也不可行：例如，如果站点在几个地区的数百台服务器上运行，那么就无法实现。

一种可能的解决方案是在负载均衡器上启用“粘性会话”，它将始终为给定会话分配相同的服务器。然后，步骤一、二和三将由同一服务器处理，并且在步骤一上传到该服务器的文件仍将用于步骤二和三，但是，粘性会话不完全可靠：如果在步骤二之间如果服务器崩溃，则负载均衡器必须分配不同的服务器，破坏功能和用户体验。同样，在特殊情况下，始终为会话分配相同的服务器可能会导致来自负担过重的服务器的响应时间变慢。

更合适的解决方案是将文件的副本保存在可供所有服务器访问的存储库中。然后，在步骤一上将文件上载到服务器之后，该服务器将其上传到存储库（或者，可以将文件直接从客户端上传到存储库，绕过服务器）; 服务器处理步骤二将从存储库下载文件，对其进行操作，然后再将其上传到存储库中；最后，服务器处理步骤三将从存储库下载并保存。

其实像国外有人通过AWS S3在多个服务器之间共享数据，在S3上执行最基本的操作：上载，下载和列出文件，每个文件几乎不需要几行代码。解决方案的简单性表明，将云服务集成到应用程序中并不困难，而且也可以由对云不太熟悉的开发人员来完成。

从原理上来说，你现有的环境为多计算机(multi-computer)，而你想要的是共享内存式的共享模式，这是很难做到的。共享内存模式一般对应于多处理器(multi-processor)的结构，其与多计算机是MIMD的两个实例。多计算机一般使用消息传递共享模式，经典的是MPI。你的需求其实很早就有人提出来了，类似于DSM模型，即distributed shared memory，不过那个绝不是靠普通PC机搭出来的，也绝不是走网线的，一定是大厂商定制开发的，所以这个你就别想了。另一种解决方案是靠高层抽象，将消息传递抽象成共享存储，但效率比较低，不过貌似大规模分布式系统已采用这种方案，对小型系统没啥优势的。

综上所述，用于并行计算的多计算机使用共享内存模式很难办到。

以下是外部存储器设备，可以根据用户需求和预算选择。无论使用哪种外部存储设备，都应该注意数据安全和备份的重要性，确保重要数据得到保护和存储。