远程过程调用服务器（RCP)不可用，怎麽办？急～

症状

在执行下列任一基于服务器的任务时，可能收到“RPC server is unavailable（RPC服务器不可用）”错误信息： • 复制

• Winlogon

• 启用受信任的关系

• 连接到域控制器

• 连接到受信任的域

• 用户身份验证

注意：在成员服务器上运行 Dcpromo 时也可能出现“RPC server is unavailable”错误。如果只有一台 DC，并且该 DC 的网卡上没有启用文件和打印机共享，则会发生此问题。

原因

下列任一原因均可导致发生此问题： • 可能未启动 RPC 服务。

• 无法解析 DNS 或 NetBIOS 名称。

• 无法建立 RPC 通道。

解决方案

要解决此问题，请按照下列步骤操作： 1 单击开始，单击运行，在打开框中键入以下命令行，然后单击确定：

net start rpcss

进行测试，查看这是否解决了问题。如果仍然出现此问题，则继续执行下一步。

2 单击开始，指向程序，指向附件，然后单击命令提示符。

3 在命令提示符处，键入 ping servername，其中 servername 是要测试其连接的服务器、NetBIOS、DNS 或 GUID 名称。

如果其中的一台计算机存在连接问题，请与网络管理员联系以解决问题。如果仍然出现此问题，则继续执行下一步。

4 使用 Microsoft Windows 支持工具（包含在 Windows CD-ROM 上）中包含的 Netdiag 工具确定域控制器是否正常工作。可以使用 MSRPC、DNS、NBT、LDAP 或 TCP 协议执行网络跟踪。

如果域控制器存在问题，请与网络管理员联系以解决问题。如果仍然出现此问题，则继续执行下一步。

5 使用 Windows 支持工具中包含的 Netdom 工具验证网络信任关系，然后重置或建立到服务器的连接。

一、准备知识

1、HTTP Keep-Alive

在Http早期，每个http请求都要求打开一个tcp socket连接，并且使用一次之后就断开这个tcp连接

使用keep-alive可以改善这种状态，即在一次TCP连接中可以持续发送多份数据而不会断开连接。通过使用keep-alive机制，可以减少tcp连接建立次数。

当使用Keep-Alive模式（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。

2、客户端okHttp的连接复用

Okhttp中连接复用正是建立在HTTP Keep-alive基础之上实现的，默认为5分钟，支持5个socket连接并发，也就是五分钟内客户端如果和已连接的服务器通信不需要重新三次握手连接（三次握手确保了服务端和客户端都具备可靠的通信能力，但握手过程耗时）。

3、客户端okHttp请求超时

注意：在250版本之后，读、写、连接超时的默认值是10s。

4、wireshark抓包分析tcp流

5、网络设备的相关参数

TCP连接的超时时间

HTTP连接的超时时间

下面贴出我们在用设备的参数默认值

二、超时现象描述

用户在平板上使用应用的时候，不定期提示超时报错，再重试一次就正常了。

这种报错比较频繁，操作的应用和功能也不固定，已经很大程度地影响了用户体验。

为了很好地理解下文，这里简单描述下局域网的网络拓扑图。

三、网络拓扑图

四、分析超时的规律

超时慢，第一反应是可能局域网的网络慢导致接口访问超时。

1、跑测试脚本，看接口的超时率、丢包、连通稳定性等

主要使用了ping 和 curl 两个命令。

###########################################################

访问并没有超时很严重

2、在笔记本电脑上执行ab压测，看响应时间和吞吐量等指标

###########################################################

上面两步均正常，超时率也在可接受的范围。 无论是在有线还是无线， 平板还是笔记本还是说小型服务器上执行测试脚本，再结合网络硬件设备性能偏上，带宽也百兆，始终都无法定位出是网络慢导致的接口访问超时。

3、在平板上开发测试工具，curl真实接口，有请求和有响应数据量的，模拟响应大小10Kb，请求数据随便造一些。

###########################################################

结果仍然是正常的。

4、我们去kibana分析日志报错，看是否有规律可循。

###########################################################

错误超时情况比较分散，没有集中在某个区域，也没有集中在某个用户，更没有集中在某些接口。

唯一总结的一个结论是：使用得多，超时数量就越多。但是晚上很少人使用的时候，也会报很多超时错误。

按照我们以往对网络的指标要求经验，继续分析网络设备参数方面。

5、更换平板，排除是平板硬件导致的超时报错。

###########################################################

换了新平板，超时接口数还是没下降。

6、观察除了超时错误，是否存在应用使用的卡顿问题，也就是慢接口是否也随之增多。

###########################################################

除了偶尔报超时，使用很顺畅。

7、排除网络设备的参数设置的影响，初步去掉上网行为管理中间设备。

更改网络拓扑图如下：

###########################################################

超时错误并没有什么变化。

8、由于超时错误频繁出现，所以我们一边操作应用，一边使用wireshark抓包记录下来。

观察tcp流的超时到底是超在哪个环节，超时有什么规律。

###########################################################

http连接在126秒后复用的时候，出现超时。再多观察几个，均是如此。

这里需要串联开篇讲的几个知识点。规律就是连接在空闲后120秒，极大概率出现超时。

9、客户端采用okHttp模拟连接复用、连接不复用的对比测试

###########################################################

连接不复用的时候，超时比例大大降低

10、使用siege模拟分别delay 120秒，delay 180秒

//先请求一次， 延迟120秒后再请求一次。

siege -d 120 -r 2 -c 1 -v http://bgptestcom

//先请求一次， 延迟180秒后再请求一次。

siege -d 180 -r 2 -c 1 -v http://bgptestcom

###########################################################

超时现象容易复现，超过120秒，接口就大概率超时。

五、解决超时的办法

超时规律找到了，并且很容易复现，解决方案也自然容易。

1、把客户端okHttp的keep-alive的默认5分钟调整为100秒。

2、更改华为路由器的HTTP连接的超时时间，由120秒延长至300秒以上（大于okHttp的keep-alive的默认5分钟）。

如果你的Bat没有其它作用，可以直接使用VBS来登录和操作

给你一段我所使用的VBS

set sh=WScriptCreateObject("WScriptShell") '建立Shell对象

set objArgs=WScriptArguments '设定VBS的参数集

dim winTitle,IP

if IP = "初始化的IP" then IP = Inputbox("请输入IP地址") '如果初始化IP为空内容，则要求初入IP地址

winTitle="telnet " & IP

shRun winTitle '运行Telnet 至IP

WScriptSleep 1000 '延时1秒钟

xSend "server{enter}" '输入密码

WScriptSleep 1000 '延时1秒钟

xSend "en{enter}server{enter}" '登录交换机

WScriptSleep 1000 '延时1秒钟

xSend "登录后的命令{ENTER}" '进入配置页面

WScriptSleep 1000 '延时1秒钟

xSend "exit{ENTER}exit{ENTER}exit{enter}" '退出配置模式&退出登录&退出telnet

WScriptSleep 1000

xSend "{ESC}"

Function xSend(string) '激活窗口发送函数

shAppActivate winTitle '激活窗口

shSendKeys string '发送内容

End Function

这样做,

首先建立一个文件adat

文件内容,是help mail from

比如,你还想加入其它对话,就一行一行的加到这个文件里就行了,然后保存然后把它保存到C:\,或者你知道的路径

然后直接调用

Private Sub Command1_click

shell "cmd /c telnet smtp126com 25<c:\adat"

end sub

就OK了最主要的是<adat,意思就是把abat的内容,直接输入到telnet 的结果里

Ok如果你还想等到返回值,就这样写

shell "cmd /c telnet smtp126com 21<c:\adat>c:\apitxt"

c:\apitxt就会保存,你telnet的执行过程

如果还不明白,Q我:905906 ,然后给我红旗!

前端时间开发和测试环境遇到一个问题，k8s内部根据服务名称和命名空间访问时连接超时。之间介绍过我们当前的项目架构，相关内容可以参看我的这两篇文章:

kubernetes使用Feign实现服务间调用

从一次k8s容器内域名解析失败了解k8s的DNS策略

当服务之间使用 Fegin 进行访问的时候，我们使用的是 service_name namespace:port 进行访问的，根据k8s的DNS策略，找到相关的服务并进行路由是没有问题的，但是仍然会出现的服务连接超时的问题。最开始我只是通过最简单粗暴的方式解决，那就是重启服务器，但是这并不能从根本上解决问题。

在搭建k8s集群之后因为后期重新加了一台服务器（服务器A，后面统一使用服务器A代指），而这台服务器和其他服务器的ip网段又不同，所以就怀疑是这台服务器的问题，但是服务间连接超时的问题是偶尔性发生的，而且在这台服务器上通过服务名称和 pod 的ip访问是正常的。所以我感觉还是k8s的网络组件有问题。

查看相关的 pod

这时候发现一个很奇怪的问题，就是一个 calico 节点状态不正确，如下：

定位是哪台服务的：

发现确实是服务器A上的 calico ，个人认为重启应该可以解决，所以就删除了有问题的 pod ，但是重启之后它的状态依然不是 Ready 。另外一个情况也引起了我的注意，就是当出现服务间连接超时的时候，k8s的 coreDNS 恰好会有一个被调度在服务器A上。所以有时候我也会直接删除服务器A上的 coreDNS 以便k8s调度到其他节点上，来解决连接超时的问题。

所以基本上可以肯定就是服务器A部署的网络组件问题，但是一直没时间就一直没有解决这个问题，国庆前正好手头没什么事情，所以决定彻底解决这个问题。查看下服务器A的 calico 日志：

有一段异常信息，如下：

因为自己对k8s了解的也不多，遇到问题只能百度，百度了一下基本上都是说是没有使用真正的网卡的问题，需要修改 calicoyaml :

这里自己走了弯路后来自己才想明白是怎么回事，网上说的修改 calicoyaml 文件，是指部署 calico 时的那个文件。

修改之后重新部署 calico ：

按照上述方法应该就能解决问题了。下面说下我当时的操作（现在回想感觉自己SB）。

因为当时k8s上每个节点都已经部署了 calico ，所以我一开始是想的直接修改服务器A的 calico ，所以我登录到 dashboard ，去修改服务器A上的 calico （对，就是编辑 pod ），但是很遗憾没有生效服务A的 calico 依然不是 Ready 状态。

然后我想网上的方案是不是有问题啊，我检查并对比了下各个服务器的网卡，发现服务器A的网卡(ens32)和其他节点网卡(ens196)不同，并且对比网卡详情发现其他服务器：

即自动协商是关闭状态，所以服务器A也关闭自动协商(感觉自己的胆儿有点肥)：

但是再次查看服务器A的网卡详情没有任何变化(我快要放弃了)

反正解决不了，我就又返回到 dashboard 页面，随便看了 kube-system 命名空间下的其他信息，一下就看到了 calico-node 的 DeamonSets ，内容和 calicoyaml 差不多（差不多，就改改吧），添加内容：

更新之后再去看服务器A的 calico 居然成了 Ready 状态(我靠怎么肥死，懵逼ing)。

自己废了那么大劲，折腾半天原来问题在这里我个人的理解网上的方案是没有问题的，之所以前面修改服务器A上的 calico 不生效，个人猜想会不会是因为 calico 是以 DeamonSets 的运行(k8s小白表示真的不知道怎么回事)。不管怎么样问题算是解决了，虽然不知道为啥，如果有了解的大佬还请给我解释一下，万分感谢

不要做A语言代码修改为B语言代码的无用功。

也不要做用A语言代码直接调用B语言代码库这样复杂、这样容易出错的傻事。

只需让A、B语言代码的输入输出重定向到文本文件，或修改A、B语言代码让其通过文本文件输入输出。

即可很方便地让A、B两种语言之间协调工作。

比如：

A将请求数据写到文件atxt，写完后改名为aatxt

B发现aatxt存在时，读取其内容，调用相应功能，将结果写到文件btxt，写完后删除aatxt，再将btxt改名为bbtxt

A发现bbtxt存在时，读取其内容，读完后删除bbtxt

以上A可以替换为任何一种开发语言或开发环境，B可以替换为任何一种与A不同的开发语言或开发环境。

除非A或B不支持判断文件是否存在、文件读写和文件更名。

但是谁又能举出不支持判断文件是否存在、文件读写和文件更名的开发语言或开发环境呢？

可以将临时文件放在RamDisk上提高效率减少磨损磁盘。

数据的结构很复杂的话，文本文件的格式问题可参考json或xml

用户： 需求发起者。

数据传输过程图：

应用程序： 发起数据的传输交流过程。

过程：

过程：

过程：

过程：

过程：

过程：

过程：

注： OSI参考模型总结 - 小白的博客 - CSDN博客

访问服务器的过程可以通过 windows+R 快捷命令 --> 进入运行界面--->然后通过cmd 命令 --->进入控制台--->然后输入命令 tracert + 访问的域名网址-->查看访问过程。

ping命令来测试网络连接：

物理层常见故障：

硬件连接问题：1接触不良2硬件未连通

数据链路层故障：

1MAC地址冲突不能上网；

2交换机与计算机网卡的带宽协商不一致，网速不一致导致网络不通；

3ADSL欠费导致网络不通；

4将计算机错误的连接到VLAN（Virtual Local Area Network）。

注：

网络层故障：

1计算机IP地址设置错误。

2计算机没有设置网关。

3计算机子网掩码配置错误。

4沿途路由器路由表错误。

传输层故障：

表示层故障：

乱码问题（字符集对应错误）

应用层故障：

应用层程序配置问题（浏览器服务器的配置问题导致上网故障等）

物理层安全：

防止非法计算机接入公司网络（包括无线AP）

数据链路层安全：

1设置WiFi密码，属于网络链路层添加秘钥的方法。

2公司内部的交换机可以设置哪个Mac地址可以接入，设置接多少台计算机。

3家里的ASDL拨号上网的需要登入账号密码。

4划分不同的VLAN（Virtual Local Area Network）

网络层安全：

1在路由器上设置ACL控制数据包转发，控制网络。

2在计算机上设置网络安全，设置访问权限。

应用层安全：

发现软件漏洞，增补丁。

TCP用主机的IP地址加上主机上的端口号作为TCP连接的端点，这种端点就叫做套接字（socket）或插口。套接字可以实现将多个客户连接到一个服务器。

它是网络通信中端点的抽象表示，包含进行网络通信必需的五种信息：1连接使用的协议，2本地主机的IP地址，3本地进程的协议端口，4远地主机的IP地址，5远地进程的协议端口。

1域： 套接字通信中使用的网络介质，常见的有AF_INET(因特网络)

2类型：

a 流式套接字（sock_stream）: 用于提供面向连接、有序的、可靠的双向jie节流的链接式数据传输服务，由类型sock_stream指定，他是在AF_INET域中通过TCP/IP链接实现的。

b 数据报套接字（sock_dgram）: 提供了一种无连接的服务，是AF_INET域中通过UDP/IP链接实现的。

c 原始套接字（sock_raw）: 允许对较低层次的协议直接访问，比如IP、ICMP协议，他常用于检验新的协议的实现或者访问现有服务中配置的新设备。网络监听技术很大程度上依赖于socket_raw

3协议: 套接字协议一般采用默认值。即默认参数为0。

1套接字是用于描述IP地址和端口，是一个通信链的句柄。应用程序通常通过"套接字"向网络发出请求或者应答网络请求。

2当前应用进程需要使用网络进行通信时，就会发出系统调用，请求操作系统为其创建“套接字”，以便把网络通信所需要的系统资源分配给该应用进程。

3操作系统为这些资源的总和，用一个叫做套接字描述符的号码表示，并把此号码返回给应用进程，应用进程所进行的网络操作都必须使用这个号码。

4通信完毕后，应用进程通过一个关闭套接字的系统调用通知操作系统回收与该“号码”相关的所有资源。

1连接创建阶段

a套接字被创建后，其端口号和IP地址都是空的，应用进程调用bind(绑定)来指明套接字的本地地址（在服务器端调用bind时就是把熟知端口号和本地IP填写到已创建的套接字中）

b服务器调用bind后 ，还必须调用listen（收听）把套接字设置为被动方式，以便随时接收客户的服务请求。（UDP服务器由于只提供了无限连接服务，不使用listen系统调用）

c客户进程发送连接请求后，服务器紧接着调用accept（接受），以把客户进程发来的连接请求提取出来。（系统调用accept的一个变量就是要指明哪一个套接字发起的连接。）

2数据传输阶段

客户和服务器都在TCP连接上使用send系统调用传送数据，使用recv系统调用接收数据。

3连接释放阶段

一旦客户或者服务器结束使用套接字，就把套接字撤销，此时调用close释放连接和撤销套接字。应用层总结-系统调用和应用编程接口 - 十分残念的博客 - CSDN博客

其过程示意图如下：

网络编程的目的：

直接或间接地通过网络协议与其他计算机进行通讯。

网络编程的问题：

1如何准确的定位网络上一台或多态主机。

2找到主机后，如何快速高效的传输数据。

网络编程的对象：

传输层提供的面向应用的可靠或非可靠的数据传输机制。

网络编程流行模型：

1CS模型（客户端/服务器模型）

2BS模型（浏览器/服务器模型）

参考网络编程--Socket(套接字) - A-祥子 - 博客园

注： 扩展链接内关于TCP/IP的相关知识讲解也相当详细，可以参考浏览一下。