服务器之间传输数据是如何通信的
服务器之间的通信
通常我们交互除了P2P等协议，⼤多数都是基于C/S架构的通信场景，⽐如FTP, HTTP, DNS等。但是再射⼀⼀些安全协议⽅案的时候通常包括多⽅服务器和⽤户。此时应该如何通信那？⽐如传递命令和传输密钥。
（1）Socket
⼀般情况下⽐如我们设计⼀个后端服务，包括多个服务器：数据库服务器，web服务器，⽂件服务器、缓存服务器等的通信，⼀般是通过socket来设计专门的通信协议，因为⽐较⾼效。⽐如MySQL，MS SQL等也都是有知名的专⽤端⼝号。这个场景⼤多是在⼀个内⽹中，所以通信效率⼀般没问题。
（1）⼤学毕业设计，我是采⽤socket编程来实现客户端与服务器之间的通信，所以当需要服务器之间通信的时候，我也采⽤了socke的⽅法，只不过请求的服务器变成了“客户端”。所以相当于各⽅既是C也是S。只不过主动发起的⼀⽅是C，被动监听的⼀⽅是S。
（2）Socket通讯简单的⽅法是发送⽅⽤1个固定连接发送(⽐如SMTP/POP3等)，或发送⽅每个请求数据包新建⼀个连接发送(⽐如
PHP/Ruby连MySQL)。
（2）Http
服务器和服务器直接同样可以⽤HTTP，特别现在最常⽤的RESTful风格的通信⽅式（webserivces ）。这时通信的时候就不需要浏览器了，⽐如服务器A可以使⽤curl系列命令向服务器B发出HTTP请求，获取数据，格式可以⽤通⽤的JSON或XML。也可以⽤java⾃带的HttpURLConnection，或者Apache的HttpClient等Http客户端来实现。当然低层还是通过Socket实现。
优点是：
1 易于编程，⽬前java提供了多种框架，屏蔽了底层通信细节以及数据传输转换细节。
2 容易控制权限。通过传输层协议https，加密传输的数据，使得安全性提⾼。
3 通⽤性⽐较强，⽆论客户端是架构，java，python 都是可以的。尤其是webservice规范，使得服务变得通⽤。
缺点是：
1 服务器和客户端必须同时⼯作，当服务器端不可⽤的时候，整个数据交互是不可进⾏。
2 当传输数据量⽐较⼤的时候，严重占⽤⽹络带宽，可能导致连接超时。使得在数据量交互的时候，服务变的很不可靠。
（3）RMI
如果⽤socket的话，需要⾃⼰封装协议来处理不同的通讯请求，但效率要⾼些。如果⽤rmi的话，实现要简单，但效率可能要低些。
RMI=socket +object 也⽐较底层。
（4）RPC
RPC 的全称是 Remote Procedure Call，是进程间通信的⼀种⽅式，常见的分布式系统通信可以⽤http，socket或rpc来实现，但rpc相⽐于http性能更⾼，相⽐于纯socket实现会更轻量更容易。⽬前⽐较⽕的微服务架构⼀般是基于rpc框架的，微服务是指开发⼀个单个⼩型的但有业务功能的服务，每个服务都有⾃⼰的处理和轻量通讯机制，可以部署在单个或多个服务器上。基于rpc的微服务架构优点如下：每个微服务都很⼩，这样能聚焦⼀个指定的业务功能或业务需求。微服务能够被⼩团队单独开发，这个⼩团队是2到5⼈的开发⼈员组成。
微服务是松耦合的，是有功能意义的服务，⽆论是在开发阶段或部署阶段都是独⽴的，单个服务⽅便
扩展。⼀般来讲RPC主要分为四个部分，分别是序列化层、函数调⽤层、⽹络传输层和服务器端处理框架，具体实现机制如下：
序列化层：序列化主要作⽤是将结构化对象转为字节流以便于通过⽹络进⾏传输或写⼊持久存储，在RPC框架中，它主要⽤于将⽤户请求中的参数或者应答转化成字节流以便跨机器传输。常⽤的序列化⽅式有xml，json，hessian，pb等。
函数调⽤层：函数调⽤层主要功能是定位要调⽤的函数并执⾏该函数，可以采⽤Java反射机制与动态代理实现函数调⽤。
⽹络传输层：⽹络传输层描述了Client与Server之间消息传输的⽅式。
服务器端处理框架：服务器端处理框架可被抽象为⽹络I/O模型，它描述了客户端与服务器端间信息交互⽅式，它的设计直接决定着服务器端的并发处理能⼒，常见的⽹络I/O模型有阻塞式I/O、⾮阻塞式I/O、事件驱动I/O等，⽽Hadoop RPC采⽤了基于Reactor设计模式的事件驱动I/O模型。
提供⼀台服务器作为调⽤的中转，业务调⽤者和提供者都连接该中⼼服务器，该中⼼服务器⽤于服务的具体调⽤。rpc主要解决的⼀个痛点在于服务调⽤的⾼度透明化。
透明化是指隐藏socket通信细节，⽐如http这种是应⽤层透明，但是rpc站的⾼度⽐应⽤层更⾼，是代
码级的透明。
rpc是站在⽐http更上层的调⽤，也就相当于多了⼀层封装，仅此⽽已，下层可以依赖http、json、或者你⾃⼰定义的元数据协议，任何能清晰描述出“坐标、服务类、服务名、调⽤参数”的whatever都可以。多了这层封装使我们在调⽤的时候不必关注这些底层细节。⽽rpc这层封装其实技术含量很低，反射加强制转换罢了。
rpc试图将远程调⽤包装成本地调⽤，但是⽹络调⽤的情况⽐本地调⽤要复杂的多，并且⽹络调⽤本⾝应该也是⽆状态，幂等性的，和本地调⽤背离，随便举个例⼦，你在本地会⾃然⽽然的写诸如i++，i–这种，但是在rpc上⾯不能这么⽤，⼀旦⽹络情况复杂i++可能会被调⽤多次导致结果就不正确。
总结：
当前的普遍场景是：**对内rpc，对外rest。RPC 更适合集内部通讯。**所以在当前⽹络环境下，并不值得去推⼴和使⽤。
（5）ftp/⽂件共享服务器⽅式
**⽂件共享服务器：**对于⼤数据量的交互，采⽤这种⽂件的交互⽅式最适合不过了。
这种⽅式的优点：
1 在数据量⼤的情况下，可以通过⽂件传输，不会超时，不占⽤⽹络带宽。
2 ⽅案简单，避免了⽹络传输，⽹络协议相关的概念。
这种⽅式的缺点：
1 不太适合做实时类的业务。
2 必须有共同的⽂件服务器，⽂件服务器这⾥⾯存在风险。因为⽂件可能被篡改，删除，或者存在泄密等。
3 必须约定⽂件数据的格式，当改变⽂件格式的时候，需要各个系统都同步做修改。
（6）数据库共享数据⽅式
系统A和系统B通过连接同⼀个数据库服务器的同⼀张表进⾏数据交换。当系统A请求系统B处理数据的时候，系统A Insert⼀条数据，系统B select 系统A插⼊的数据进⾏处理。
curl是什么命令这种⽅式的优点：
1 相⽐⽂件⽅式传输来说，因为使⽤的同⼀个数据库，交互更加简单。
2 由于数据库提供相当做的操作，⽐如更新，回滚等。交互⽅式⽐较灵活,⽽且通过数据库的事务机制，
可以做成可靠性的数据交换。这种⽅式的缺点：
1 当连接B的系统越来越多的时候，由于数据库的连接池是有限的，导致每个系统分配到的连接不会很多，当系统越来越多的时候，可能导致⽆可⽤的数据库连接。
2 ⼀般情况，来⾃两个不同公司的系统，不太会开放⾃⼰的数据库给对⽅连接，因为这样会有安全性影响。
（7）message ⽅式
Java消息服务（Java Message Service）是message数据传输的典型的实现⽅式，是⼀种发布-订阅模式。系统A和系统B通过⼀个消息服务器进⾏数据交换。系统A发送消息到消息服务器，如果系统B订阅系统A发送过来的消息，消息服务器会消息推送给B。双⽅约定消息格式即可。⽬前市场上有很多开源的jms，⽐如 ActiveMQ, OpenJMS 。
这种⽅式的优点：
1 由于jms定义了规范，有很多的开源的消息中间件可以选择，⽽且⽐较通⽤。接⼊起来相对也⽐较简单。
2 通过消息⽅式⽐较灵活，可以采取同步，异步，可靠性的消息处理，消息中间件也可以独⽴出来部署。
这种⽅式的缺点：
1 学习jms相关的基础知识，消息中间件的具体配置，以及实现的细节对于开发⼈员来说还是有⼀点学习成本的。
2 在⼤数据量的情况下，消息可能会产⽣积压，导致消息延迟，消息丢失，甚⾄消息中间件崩溃。
（8）其他协议：
主要是rcp,scp,rsync,ftp,sftp,lftp,wget,curl等Linux服务或命令。
1 rcp
rcp不是⼀种安全的的传输⽂件的⽅式，rcp通过rsh（rsh见下⾯）来执⾏远程命令，要使⽤rcp必须经过⼀些配置，现在rcp已经被scp取代了，常⽤scp来进⾏⽂件传输。
2 scp
scp 命令是 SSH中最⽅便有⽤的命令了，scp就是secure copy，是⽤来进⾏远程⽂件拷贝的。数据传输使⽤ ssh，并且和ssh 使⽤相同的认证⽅式，提供相同的安全保证 。 与rcp 不同的是，scp 在需要进⾏验证时会要求你输⼊密码或⼝令。
3 rsync
rsync是rcp的替代品之⼀，rsync 是⼀款⾼效的远程数据备份和镜象⼯具，可快速地同步多台主机间的⽂件，其具有如下特性：
1. ⽀持链接、所有者、组信息以及权限信息的拷贝；
2. 通过远程 shell（ssh, rsh）进⾏传输；
3. ⽆须特殊权限即可安装使⽤；
4. 流⽔线式⽂件传输模式，⽂件传输效率⾼；
5. ⽀持匿名操作；
需要提及的是 rsync 以其优越的性能优势区别于其它⼏种 Linux ⽂件传输⽅法，其同步⽂件的速度相当快，这主要归功于 rsync 所使⽤的传输算法。简⽽⾔之 rsync 算法能在相当短的时间内计算出需要备份的数据，只对源⽂件与⽬标⽂件的不同之处进⾏传输（增量传输），从⽽降低⽹络中传输的数据量，以此达到快速备份镜像的⽬的。
4 ftp
ftp命令使⽤⽂件传输协议(File Transfer Protocol ,FTP)在本地主机和远程主机之间或者两个远程主机之间进⾏⽂件传输。FTP 协议允许数据在不同⽂件系统的主机之间传输。尽管这个协议在传输数据上提供了⾼适应性，但是它并没有尝试去保留⼀个特定⽂件系统上的⽂件属性（例如⼀个⽂件的保护模式或者修改次数）。⽽且 FTP 协议很少对⼀个⽂件系统的整体结构作假定，也不提供这样的功能，⽐如递归的拷贝⼦⽬录。在使⽤ ftp 命令时，需要注意 FTP 协议的这些特性。当需要保留⽂件属性或者需要递归的拷贝⼦⽬录时，可以使⽤ rcp/scp 等命令。
5 sftp
sftp（安全⽂件传输协议）与 ftp 有着⼏乎⼀样的语法和功能。SFTP 为 SSH的⼀部份，是⼀种传输档
案⾄ Blogger 伺服器的安全⽅式。它并不使⽤ftp守护进程（ftpd或wu-ftpd）来进⾏连接，⽽是有意义地增强系统的安全性。实际上，通过监视⼀些系统中的log⽂件，可以注意到很多攻击是针对于ftpd守护进程的。sftp避免了这些攻击从⽽可以停⽌在wu-ftpd上潜在的危险。SFTP本⾝没有单独的守护进程，它必须使⽤sshd守护进程（端⼝号默认是22）来完成相应的连接操作。使⽤SFTP是⾮常安全的。但是，由于这种传输⽅式使⽤了加密/解密技术，所以传输效率⽐普通的FTP要低得多，如果您对⽹络安全性要求更⾼时，可以使⽤SFTP代替FTP。
6 lftp
lftp 是⼀个功能强⼤的下载⼯具，它⽀持访问⽂件的协议: ftp, ftps, http, https, hftp, fish.(其中ftps和https需要在编译的时候包含openssl库)。llftp⾮常像⼀个shell: 有命令补全，历史记录，允许多个后台任务执⾏等功能，使⽤起来⾮常⽅便。它还有书签、排队、镜像、断点续传、多进程下载等功能。
7 wget
wget 是⼀个经由 GPL 许可的可从⽹络上⾃动获取⽂件的⾃由软件包。它是⼀个⾮交互式的命令⾏⼯具。⽀持 HTTP，HTTPS 和 FTP 协议，⽀持代理服务器以及断点续传功能。 wget 可实现递归下载，即可跟踪 HTML 页⾯上的链接依次下载来创建远程服务器的本地版本，完全重建原始站点的⽬录结构，实现远程⽹站的镜像。在递归下载时，wget 将页⾯中的超级链接转换成指向本地⽂件，⽅便离线
浏览。由于⾮交互特性，wget ⽀持后台运⾏，⽤户在退出系统后，仍可继续运⾏。功能强⼤，设置⽅便简单。
8 curl
curl是对 libcurl 库的⼀个命令⾏⼯具包装。 libcurl 库中提供了相应功能的 API，可以在程序中调⽤。 curl 使⽤ URL 的语法来传输⽂件，它⽀持 FTP, FTPS, HTTP, HTTPS, TFTP, SFTP, TELNET 等多种协议。 curl 功能强⼤，它提供了包括代理⽀持，⽤户认证，FTP 上载，HTTP post，SSL 连接，⽂件续传等许多特性。
基本语法：curl [options … ]
总结：
（1） 传输性能：wget 通过⽀持后台执⾏及断点续传提⾼⽂件传输效率； rsync 则以其⾼效的传输及压缩算法达到快传输的⽬的。
（2） 配置难度：rcp 只需进⾏简单的配置，创建.rhost⽂件以及设置/etc/hosts⽂件中主机名与IP地址列表； wget设置⽅便简单，只需在客户端指定参数执⾏命令即可； rsync 在使⽤前需要对服务端/f 进⾏参数设定，配置内容相对复杂。
（3） 安全性能：ftp、rcp不保证传输的安全性，scp、rsync则均可基于ssh 认证进⾏传输，提供了较强的安全保障。wget 也可通过指定安全协议做到安全传输。
通过上述的对⽐不难发现，每种⽂件传输⽅法基于其⾃⾝的特点与优势均有其典型的适⽤场景：
（1） ftp 作为最常⽤的⼊门式的⽂件传输⽅法，使⽤简单，易于理解，并且可以实现脚本⾃动化；但是需要安装ftp server才可以访问远程ftp server
（2） rcp 相对于ftp可以保留⽂件属性并可递归的拷贝⼦⽬录；
（3） scp 利⽤ssh传输数据，并使⽤与ssh相同的认证模式，相对于rcp提供更强的安全保障；
（4） wget实现递归下载，可跟踪HTML 页⾯上的链接依次下载来创建远程服务器的本地版本，完全重建原始站点的⽬录结构，适合实现远程⽹站的镜像；
（5） curl 则适合⽤来进⾏⾃动的⽂件传输或操作序列，是⼀个很好的模拟⽤户在⽹页浏览器上的⾏为的⼯具；
（6） rsync 更适⽤于⼤数据量的每⽇同步，拷贝的速度很快，相对wget来说速度快且安全⾼效；

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。