2.1.1两将军问题
如图 2-6 所示，两支友军分别 由 Al将军和 A2将军带领，两军约定上午 10点同时攻击山谷中的敌军。正常情况下，Al将军派通信兵经过敌军占领 的山谷通知 A2将军千上午 10点进攻敌军（图 2-6中的第 1步），然后A2将军安排通信兵告知 Al将军确认信息已经收到
（图 2-6中的第2步）。但是A2将军还需要等待 Al 将军的确认信息，否则 A2将军不知道“ Al将军是否收到 A2将军的确认信息（第 2步的信息）”,所以还需要执行第 3步“ Al将军派通信兵通知A2将军，第 2 步确认已经收到“。
图 2-6两 将军问题
如果没有发生异常（如通信兵被敌军俘获），通过上述三步的通信，Al 将军和 A2将军基本达成“ 上午 10点进攻敌军”的计划 。但是战线 封锁、路况不好会导致通信兵传递信息超时，或者通信兵被俘获／击 毙会导致传递的信息 石沉大海，因此需要超时 重传机制保障通信正常 。通过两将军问题，采用固定次数的消息 确认，解决通信网 络不 可靠时的共识问题。同时，也可以解释 TCP/IP通信中的三次握手设计 。
2.1.1 拜占庭将军问题
在两将军问题中，如果通信兵被敌军俘获并且 叛变 ，将会传 递错误的信息给Al将军和A2将军，从而更难达成共识 。为了解决通信中传递错误信息的问题，业界提出了 拜占庭将军问题。
如图 2-7所示，6支军队分别 由 6位拜占庭将军 ( Al~A6) 率领，他们共同围攻城池内的敌军。各支军队的行动策 略为进攻／撤退两 种，如果部分军队进攻 、部分军队撤退可 能会造成灾难性后果 ，因此 Al~ A6将军必须通过投票来达成共识 ，即所有军队一起进攻或所有军队一起撤退 。因为各位将军分处 城市的不同方向，他们只能通过通信兵互相联系 。在投票过程中，每位将军都将投票给出进攻还是撤退 的信息，然后通过通信兵分别通知其他将军， 从而根据自己 的投票和其 他将军送来的信息，每位将军就可知道共同的投票结果并决定行动策略。
拜占庭将军 的难题在于拜占庭故障 ，即通信兵可能被敌军 俘获并且叛变 ，从而传递错误信息，还有将军也有可能成为叛徒。例如，错误消息让将军判断出3人以上要求进攻，但实际上并没有这么多进攻的投票，最终导致误判 。
图2-7 拜占庭将军间题
在分布式系统中，典型的拜占庭故障 ，就是某台服务器 的进程因 CPU繁忙、内存申请超时、网络拥塞 、磁盘响应慢等原因出现工作状态不正常，却继续带 病工作的亚健康状态 。在非安全网络中，通过伪装来窃取信息，也是安全中要预防的典型的拜占庭故障。分布式系 统为了解决拜占庭故障，可以采用以下解决方案。
· 根据分 布式系统的服务器总数，限定发生拜占庭 故障的服务器数，来确保解决该问题。例如，服务器总数为 N, 那么发生拜占庭故障 的服务器数不能超 过 1/3*N（服务器总数的 1/3)，剩下的服务器还能通过多数派达成共识。
· 根据数 字签 名识别伪装的服务器，或者根据序 列号识别亚健康服务器 的错误消息，并及时将它们隔离。通过防护手段，尽早地隔离系统中的不稳定因素，从而支撑共识的达成。
1999年， MiguelCastro与 BarbaraLiskov在论文 P ractica l Byzantine Fault Tolerance andProactiveRecovery中通过高性能的运算方法，提升了拜占庭故障 的容错和恢复性能
