流转服务器 服务器平台有哪些

文件服务器和文件夹直接共享有什么区别

一、主体不同

1、文件服务器：，又称档案伺服器，是指在计算机网络环境中，所有用户都可访问的文件存储设备。

2、共享文件夹：是指某个计算机用来和其它计算机间相互分享的文件夹。

二、特点不同

1、文件服务器：比个人电脑拥有更大的存储容量，并具有一些其他的功能，如磁盘镜像、多个网络接口卡、热备援多电源供应器。

2、共享文件夹：使用P2P模式，文件本身存在用户本人的个人电脑上。大多数参加文件共享的人也同时下载其他用户提供的共享文件。

三、发展不同

1、文件服务器：已进化成带有RAID存储子系统和其他高可用特性的高性能系统。

2、共享文件夹：文件是从FTP服务器站点分享来的，通过用户特别设置的密码来获得其访问权。

参考资料来源：百度百科-文件服务器

参考资料来源：百度百科-共享文件夹

WEB服务器为什么取不到用户的MAC地址

起因是某个同事接到了领导安排下来的一个需求，要在一个Web应用（Java+Tomcat）中，记录用户登录时的IP地址和MAC地址，用于安全审计，于是咨询我如何实现。

第一反应是，这个需求本身是不成立的，根据以往的了解，MAC地址应该是过不了路由器的才对。

以往做开发，都是用engineer的思维：先动手做，遇到问题再解决问题。但这个需求，应当用scientist的思维去思考：首先确定能不能做，然后才是怎么做。

翻查了一些资料，想来证实"为什么WEB服务器，可以获取到客户端的IP地址，但获取不到MAC地址"，看着看着才发现，这是个挺大的命题，够写一篇BLOG了。

PS：由于个人对这块内容了解的不够彻底，本文很可能会有谬误，请读者先不要太当真，另外希望平台组的同事给予指证。

我所认为的结论应该是这样的：

下面一步步解释一下。

先从HTTP说起。

HTTP是一个应用层的协议，它建立在TCP协议之上。

HTTP请求就是用来发送一段文本。关于这段文本如何组织，第一行写什么，第二行写什么，哪里加一个空行，就是HTTP协议所要规范的内容。

举个直接的例子，下面是一个简单的HTTP GET请求，有兴趣可以用telnet模拟一下。

我们可以看到，HTTP的这段请求中，完全找不到客户端的MAC地址，甚至连IP地址都没有描述。

那IP地址是从哪里取到的呢？接下来我们再深入一点，看下一个内容：Socket

HTTP的客户端和服务端，是通过Socket进行连接的。

Socket是什么呢？ Socket是对OSI模型第4层-传输层中的TCP/IP协议的封装。Socket本身并不是协议，而是一个调用接口(API)。Socket和TCP/IP协议没有必然的联系。但通过Socket，我们才能使用TCP/IP协议。应用层不必了解TCP/IP协议细节，直接通过对Socket接口函数的调用完成数据在IP网络的传输。

Socket包含了网络通信必须的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议端口。

所以，因为有了Socket，客户端和服务端完全不需要了解底层细节，直接通过调用Socket来实现就可以了。

这也就是为什么服务器端可以获取到客户端的IP地址的原因，因为Socket中包含了远地主机的IP地址。（当然，通过代理服务器进行访问的除外，这种要依靠HTTP协议的X-Forwarded-For头来确认IP，不在本次的讨论范围中）

那为什么无法获取到客户端的MAC地址呢？很简单，同理，因为Socket中无法取到MAC地址。。。

如果继续发问，为什么Socket中都既然都包含IP地址了，为什么偏偏不包含MAC地址信息呢？看来我们还要更深入一点，看一下OSI模型吧。

首先祭出这张经典的OSI七层模型图，计算机网络的基石，请先盯着看一会儿，认真复习一下

这里还有一张OSI七层模型与TCP/IP四层模型的对照图

为了方便理解，再放上一张更直观的，每一层对应的数据型式和主要协议的示意图

通过上图大体可以知道：

下面举个栗子，当我们在浏览器中打开一个链接后，看看OSI各层倒底发生了什么：

这里撇开DNS解析之类东西，只说一下HTTP报文的发送

首先来看一下发送端（浏览器所在的主机）。参照第一张OSI模型图，按照从上向下的顺序来看。应用层数据其实只有那么几行文本，然后往下，每过一层，都要被加上首部/尾部。这个过程就像是一层一层的穿衣服。

HTTP请求文本：

数据发出去后，再看一下数据在网络上的流转。

数据一般要经过交换机、路由器等网络设备，层层转发，这些设备所做的事情就像是：脱掉一件或几件衣服，做一些修修补补，然后再重新穿回去。

通过上面这张图，我们就可以理解，MAC地址在本地网络下的重要作用了。也理解了，本地网络下，是可以查出每个节点的MAC地址的。

经过路由器后，为了能到达下一跳，数据链路层中的MAC地址就被篡改了，下面这张图很能说明问题：

最后看一下接收端（WEB服务器所在的主机）。参照第一张OSI模型图，按照从下至上的顺序来看，它要做的事情是：将衣服一件一件全部脱掉，最后WEB服务器就取到了最初的应用层数据。

所以，当一个以太网帧到达目的主机后，其中的MAC地址早已经不是原来客户端的MAC了，操作系统的Socket自然也无法获取原始的MAC地址了。

上面已经证明了，WEB服务端，是无法获取客户端的MAC地址的。

那么，能不能通过一些trick来绕道实现呢？

想了想，大概可以有如下的思路：

那么这个思路可不可行呢？

最后的最后，不禁思考，获取MAC的意义在哪里呢？

如果单纯是为了取证和审计，我想意义是不大的，甚至不如直接记录IP地址。

因为：

所以，一般的安全管控要求下，还是只记录IP吧。

如何利用ffmpeg拉RTSP流转推RTMP服务器

如何借助ffmpeg实现RTSP流的高效转推至RTMP服务器？

在探索网络视频传输的多样可能性时，当浏览器无法直接播放RTSP流时，ffmpeg这个强大的工具就能大显身手。它的命令行指令，如魔术般地将视频流进行转换，确保无缝接入各种平台。下面，让我们深入了解如何通过ffmpeg实现RTSP到RTMP的高效转推过程。

首先，你需要准备ffmpeg命令，它的一站式解决方案如下：

ffmpeg.exe-i"rtsp地址"-vcodec copy-acodec copy-f flv"rtmp地址"

在这个命令中，"rtsp地址"是你要拉取的源视频流，它通常是网络摄像头或者其他支持RTSP协议的设备提供的。而"rtmp地址"则是你想要推送到的RTMP服务器的地址，比如EasyDSS这样的Web直播点播平台。ffmpeg通过-vcodec copy和-acodec copy保持视频和音频的原始质量，-f flv指定输出格式为Flash Video（FLV），这对于RTMP服务器的兼容至关重要。

要成功实现RTSP到RTMP的转换，确保两点至关重要：一是rtsp地址的准确性，二是ffmpeg版本的兼容性。对于EasyDSS这样的平台，其官方技术博客通常会提供详细的指南和示例，帮助开发者更好地理解和利用ffmpeg的这些特性。

在实际操作中，你可能需要根据具体的环境调整参数，比如调整视频码率、音频码率，或者添加其他高级选项。同时，为了保证流畅的直播体验，网络状况和服务器配置也需匹配。总之，ffmpeg为RTSP到RTMP的转推提供了强大的底层支持，掌握好它的使用方法，将使你的直播解决方案更加稳定和高效。

总的来说，ffmpeg就像一个视频流传输的瑞士军刀，为你的实时流媒体项目提供了强大的转码和推送能力。只需熟练掌握其命令行参数，就能轻松实现RTSP到RTMP的无缝对接，让在线内容无处不在。