如果网页端，PC端，移动端，业务逻辑完全一样（功能一样，UI一样，展示的数据内容一样，多媒体信息，视频，图片统统都是一样的），那么网页端就可以也连C/S的服务器，你现有的C/S的服务器支持一下http/https通信就可以了（有现成的第3方的支持http/https协议的库的）
否则，C/S的服务器 和 B/S的服务器还是分开比较好， PC端和app连C/S的服务器（甚至pc和移动端也分开比较好）， 网页连B/S的服务器。
原因：
一个产品级的项目，需求总是在变的，你永远不知道明天产品部门会提一个什么需求。
比如，很常见的例子：
1、网页端和移动端，需要展示的图片是不一样的，图片大小是不一样的，读的url不一样
2、PC/移动端要接qq/微信渠道分享，但是网页端要接微博分享
3、移动端接微信/支付宝，pc/网页端要接银联等等诸如此类
甚至会出现客户端是不同的版本
比如pc端的，网页端的，都可以实时热更，但是ios的你要过审，如果是同一个服务器，还要考虑老版客户端连新版服务器的兼容性的问题
如果不同的端连的同一个服务器，就导致在这个相同的服务器上，你要做很多if,else的分支，兼容不同的端，不同的版本，不同的逻辑。
你可以单独把那些不变的核心的纯业务逻辑剥离出来，做成单独的核心逻辑服，这个服可以是C/C++写的，提供接口，以tcp方式供其他服调用
pc/移动/网页端，分别接自己的业务服务器，pc/移动端的服务器可能是C/C++的，web端的服务器可能是java/php的
这些业务服务器在需要核心数据的时候，通过tcp，向这个核心逻辑服请求数据
返回后，再各自包装数据，以不同的方式提供给不同的客户端
lz可能关心的 java/php 和 C/C++服务器，如果用tcp通讯，效率怎么样。效率不会差到哪去，而且本身web端对延迟的容忍度，要比pc/移动端要高。java我知道的nio可以。