前言
p2p(peer to peer)负责以太坊底层节点间的通信，主要包括底层节点发现(discover)和上层协议运行两大部分。
节点发现
节点发现功能主要涉及 Server Table udp 这几个数据结构，它们有独自的事件响应循环，节点发现功能便是它们互相协作完成的。其中，每个以太坊客户端启动后都会在本地运行一个Server，并将网络拓扑中相邻的节点视为Node，而Table是Node的容器，udp则是负责维持底层的连接。这些结构的关系如下图
Server
p2p/server.gotype Server struct { PrivateKey *ecdsa.PrivateKey Protocols []protocol StaticNodes[] *discover.Node newTransport func(net.Conn) transport ntab disvocerTable ourHandshake *protoHandshake addpeer chan *conn ......} PrivateKey - 本节点的私钥，用于与其他节点建立时的握手协商
Protocols - 支持的所有上层协议StaticNodes - 预设的静态Peer，节点启动时会首先去向它们发起连接，建立邻居关系newTransport - 下层传输层实现，定义握手过程中的数据加密解密方式，默认的传输层实现是用newRLPX()创建的rlpx，这不是本文的重点ntab - 典型实现是Table，所有peer以Node的形式存放在TableourHandshake - 与其他节点建立连接时的握手信息，包含本地节点的版本号以及支持的上层协议addpeer － 连接握手完成后，连接过程通过这个通道通知Server Server.listenLoop()
Server的监听循环，启动底层监听socket，当收到连接请求时，Accept后调用setupConn()开始连接建立过程
Server.run()
Server的主要事件处理和功能实现循环
- 进行主动的节点发现，详见之后的节点发现部分
- posthandshake channel 接收已经完成第一阶段的连接，这些连接的身份已经被确认，但还需要验证
- addpeer channel 接收已经完成第二阶段的连接，这些连接已经验证，调用runPeer()运行本节点与Peer连接上的协议
Node
Node唯一表示网络上的一个节点
p2p/discover/node.gotype Node struct { IP net.IP UDP, TCP uint16 ID NodeID sha common.Hash} IP - IP地址
UDP/TCP - 连接使用的UDP/TCP端口号ID - 以太坊网络中唯一标识一个节点，本质上是一个椭圆曲线公钥(PublicKey)，与Server的PrivateKey对应。一个节点的IP地址不一定是固定的，但ID是唯一的。sha - 用于节点间的距离计算 Table
Table主要用来管理与本节点与其他节点的连接的建立更新删除
p2p/discover/table.gotype Table struct { bucket [nBuckets]* bucket refreshReq chan chan struct{} ......} bucket - 所有peer按与本节点的距离远近放在不同的桶(bucket)中，详见之后的节点维护
refreshReq - 更新Table请求通道 Table.loop()
Table的主要事件循环，主要负责控制refresh和revalidate过程。
Table的刷新Peer连接的通知，当收到该通知时启动更新，详见之后的更新邻居关系revalidate.C - 定时重新检查以连接节点的有效性的定时器，详见之后的探活检测 udp
udp负责节点间通信的底层消息控制，是Table运行的Kademlia协议的底层组件
type udp struct { conn conn addpending chan *pending gotreply chan reply *Table} conn - 底层监听端口的连接
addpending －udp用来接收pending的channel。使用场景为：当我们向其他节点发送数据包后(packet)后可能会期待收到它的回复，pending用来记录一次这种还没有到来的回复。举个例子，当我们发送ping包时，总是期待对方回复pong包。这时就可以将构造一个pending结构，其中包含期待接收的pong包的信息以及对应的callback函数，将这个pengding投递到udp的这个channel。udp在收到匹配的pong后，执行预设的callback。gotreply - udp用来接收其他节点回复的通道，配合上面的addpending，收到回复后，遍历已有的pending链表，看是否有匹配的pending。Table - 和Server中的ntab是同一个Table udp.loop()
udp的处理循环，负责控制消息的向上递交和收发控制
- addpending 接收其他线程投递来的pending需求
- gotreply 接收udp.readLoop()投递过来的pending的回复
udp.readLoop()
udp的底层接受数据包循环，负责接收其他节点的packet
- 接受其他节点发送的packet并解析，如果是回复包则投递到udp.loop()
节点维护
以太坊使用Kademlia分布式路由存储协议来进行网络拓扑维护，了解该协议建议先阅读。更权威的资料可以查看。总的来说该协议：
-
使用UDP进行节点间消息通信，有 4 种消息
- ping - 用于探测其他节点是否还存在
- store - 接收者受到后，将信息中key/value对存储在本节点
- findnode - 接受者向发送者返回 k 个它知道的与目标结点距离最近的节点
- findvalue - 和findnode 差不多，区别是如果接收者本地存在与目标结点对应的value，那么就回复这个值给发送者。
- 每个节点根据与邻居节点距离之间的距离(NodeID的差距)，分别放到不同的桶(bucket)中。
本文说的距离，均是指两个节点NodeID的距离，计算方式可见 p2p/discover/node.go的 logdist()方法
源码中由Table结构保存所有bucket，bucket结构如下
p2p/discover/table.gotype bucket struct { entries []*Node replacemenets []*Node ips netutil.DistinctNetSet} - entries 数组中保存经过bond的节点，并且其顺序是越新bond通过了探活检测(Revalidate)的节点位置越靠前。
- replacemenets数组中保存候补节点，如果entries 数组数量满了，之后的节点会被加入该数组
节点可以在entries和replacements互相转化，一个entries节点如果Validate失败，那么它会被原本将一个原本在replacements数组的节点替换。
探活检测(Revalidate)
有效性检测就是利用ping消息进行探活操作。Table.loop()启动了一个定时器（0~10s），定期随机选择一个bucket，向其entries中末尾的节点发送ping消息，如果对方回应了pong，则探活成功。
举个栗子，假设某个bucket， entries最多保存2个节点， replacements最多保存4个节点。初始情况下 entries=[A, B], replacements = [C, D, E]，如果此时节点F加入网络， bond通过，由于 entries已满，只能加入到 replacements = [C, D, E, F]。 此时Revalidate定时器到期，则会对 B进行检测，如果通过，则 entries=[B, A]，如果不通过，则将随机选择 replacements中的一项（假设为D）替换B的位置，最终 entries=[A, D]， replacements = [C, E, F]
更新邻居关系
Table.loop()会定期（定时器超时）或不定期（收到refreshReq）地进行更新邻居关系（发现新邻居），两者都调用doRefresh()方法，该方法对在网络上查找离自身和三个随机节点最近的若干个节点。
节点查找
Table的lookup()方法用来实现节点查找目标节点，它的实现就是Kademlia协议，通过节点间的接力，一步一步接近目标。
邻居初始化
当一个节点启动后，它会首先向配置的静态节点发起连接，发起连接的过程称为Dial，源码中通过创建dialTask跟踪这个过程
dialTask
dialTask表示一次向其他节点主动发起连接的任务
p2p/dial.gotype dialTask struct { flags connFlag dest *discover.Node ......} 在Server启动时，会调用newDialState()根据预配置的StaticNodes初始化一批dialTask， 并在Server.run()方法中，启动这些这些任务。
Dial过程需要知道目标节点(dest)的IP地址，如果不知道的话，就要先使用 recolve()解析出目标的IP地址，怎么解析？就是先要用借助Kademlia协议在网络中查找目标节点。
连接建立
连接建立的握手过程分为两个阶段，在在SetupConn()中实现
第一阶段为：sequenceDiagramNote left of Dialer: Calc tokenNote left of Dialer: Generate Random Prikey\NonceNote left of Dialer: SignDialer->>Receiver: AuthMsgNote right of Receiver: Calc tokenNote right of Receiver: Check SignatureNote right of Receiver: Generate Random Prikey\NonceReceiver->>Dialer: AuthResp
第二阶段为协议握手,互相交换支持的上层协议
sequenceDiagramDialer->>Receiver: protoHandshakeReceiver->>Dialer: protoHandshake
如果两次握手都通过，dialTask将向Server的addpeer通道发送peer的信息
sequenceDiagramparticipant Server.run()participant dialTaskparticipant Remote NodedialTask->>Remote Node:EncHandshakeRemote Node->>dialTask:EncHandshakedialTask->>Server.run(): posthandshakedialTask->>Remote Node:ProtoHandshakeRemote Node->>dialTask:ProtoHandshakedialTask->>Server.run(): addpeerNote over Server.run(): go runPeer()
协议运行
协议运行并不单单指某个特定的协议，准确地说应该是若干个独立的协议同时在两个节点间运行。在提到过，节点间建立连接的时候会经过两次握手，其中的第二次握手，节点间会交换自身所支持的协议。最终两个节点间生效的协议为两个节点支持的协议的交集。
功能主要涉及 Peer protoRW 这几个数据结构，其关系如图
Peer
- rw - 节点间连接的底层信息，比如使用的socket以及对端节点支持的协议(capabilities)
- running - 节点间生效运行的协议簇
Peer.run()负责连接建立后启动运行上层协议，它自身运行在一个独立的go routine，具有自己的事件处理循环，除此之外，它还会额外创建2+n个go routine, 其中2包括一个用于保活的pingLoop() go routine和一个用于接收协议数据的readLoop() go routine ，而 n 为运行于其上的n个协议的go routine，即每个协议调用自己的Run()方法运行在自己单独的go routine
protoRW
Run 每种协议自身的运行入口,以新的go routine形式启动.
总结
- p2p主要由底层节点发现和上层协议运行两部分组成，节点发现负责管理以太坊网络中各个节点间的连接建立,更新和删除，Server是p2p功能的入口，Table负责记录peer节点信息， udp负责底层通信。而在底层的基础上，节点间可以运行多个独立的协议。
- 以太坊使用
Kademlia分布式路由存储协议来进行网络拓扑维护，将不同距离的peer节点放在不同的bucket中。