NETWORK

问题：今天同事安装了一套k8s环境, 结果发现calico网络互相访问不通，同台机器上的pod之间的calico ip都ping不通 分析解决： calico支持三种网络模式，可通过修过calico.yaml进行配置: overlay之ipip overlay之vxlan underlay之BGP overlay — ipip traffic flow   overlay — vxlan traffic flow underlay — BGP traffic flow 本环境用的是CrossSubnet且都在同网段，用的是BGP 下面是node信息：

  查看yks2上的路由：

  可以看到， 172.23.27.0/24 via 10.16.245.47 dev ens3 proto bird 这条路由，172.23.27.0/24这个地址是直接到yks2主机上的

在yks2上ping coredns:

上主机yks2上抓包： 首先抓宿主机网卡：

可以接收到包 看下yks2的路由：

Read more…

TCP三次握手建立连接 Tcp头部:   六个标志位中，我们要用到三个： SYN：SYNchronous，SYN= 1 表示这是一个连接请求或连接接受报文。在建立连接时用来进行同步序号（个人理解是，在建立连接的时候，提醒对方记录本方的起始序号）。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若是同意建立连接，则应响应的报文段中使SYN=1、ACK=1。因此SYN=1表示该报文是一个连接请求报文或者是一个连接请求接收报文。 ACK：ACKnowledgment，确认号只有在该位设置为1的时候才生效，当该位为0是表示确认号无效。TCP规定，在TCP连接建立后所有传送的数据报文段ACK都必须设置为1。 FIN：FINish，当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。   此外我们还需要用到序号和确认号： 序号：占4个字节，它的范围在0-2^32-1，序号随着通信的进行不断的递增，当达到最大值的时候重新回到0在开始递增。TCP是面向字节流的，在一个TCP连接中传送的字节流中的每一个字节都按照顺序编号。整个要传送的字节流的起始号必须在连接建立时设置。首部中的序列号字段指的是本报文段所发送的数据的第一个字节的序号。例如，一个报文序号是301，而携带的数据共有100字节。则表示本次报文中的序号是301，下一个报文的序号是401.重复一下，每一个报文的序号是该报文包含的字节中第一个字节的编号。 确认号：占4个字节，确认号，是对下一个想要接受的字节的期望，这里隐式确认了对上一个数据包的成功接收。如上例，在成功接收了序号为301的数据包，想要接收下一个数据包因为上个数据包包含100字节，所以此时的确认号应该是401，表示希望接收下一个序号是401的数据包。 三次握手过程：   过程描述： 首先由Client发出请求连接即 SYN=1 ACK=0  (请看头字段的介绍)，TCP规定SYN=1时不能携带数据，但要消耗一个序号，因此声明自己的序号是 seq=x。 然后 Server 进行回复确认，即 SYN=1 ACK=1 seq=y，ack=x + 1。 再然后 Client 再进行一次确认，但不用SYN 了，这时即为 ACK=1，seq=x + 1，ack=y + 1。 为什么要进行三次握手（两次确认）： 为什么A还要发送一侧确认呢？这主要是为了防止已失效的连接请求报文突然又传送到了B，因而产生错误。 所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况。A发出连接请求，但因连接请求丢失而未收到确认。于是A再次重传一次连接请求。后来收到了确认建立了连接。数据传输完毕后，就释放了连接。A共发送了两个连接请求的报文段，其中第一个丢失，第二个到达了B。没有“已失效的连接请求报文段”。 现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络节点长时间滞留了，以致延误到连接释放以后的某个时间才到B。本来这是一个已失效的报文段。但是B收到此失效的连接请求报文段后，就误认为是A有发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了。 由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。 采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下，A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求建立连接。 另一种解释： 这个问题的本质是, 信道不可靠, Read more…