Linux虚拟网络设备
Tun/Tap
Tun 连接协议栈和用户空间程序, TAP：虚拟网卡，作为虚拟机后端网卡
Bridge
网桥的每个端口与一个网段相连。桥接就是把一台机器上的若干个网络接口连接起来，其结果是，其中一个网口收到的报文会被复制给其他网口并发送出去，从而使得网口之间的报文能够互相转发。Linux 网桥实际上是一个拥有 IP 地址的虚拟接口，其背后的原理是：网桥本身不对数据包做任何处理，只是把来自一个子网的数据包转发至另一子网。Linux bridge 不能跨机连接网络设备
brctl addbr br0 # 创建网桥
brctl addif br0 eth0 # 把网卡 eth0 加入到网桥 br0 中
ifconfig br0 192.168.11.1 # 给网桥设置 IP 地址
QA
tcpdump能否抓到被 iptables封禁的包
tcpdump工作在网络设备层，而iptables工作的 ip, arp 层，故接收网络包时可以抓到，而发送网络包时不可以
分支主题
分支主题
websocket
与Http协议一样都属于应用层的协议，WebSocket在建立握手连接时，数据是通过http协议传输的，但是在建立连接之后，真正的数据传输阶段是不需要http协议参与的
轮询
长轮询
浏览器发起请求到服务器，服务器一直保持连接打开，直到有数据可发送
短轮询
浏览器定时向服务器发送请求，服务器收到请求不管是否有数据到达都直接响应
特点
建立在 TCP 协议之上，服务器端的实现比较容易
数据格式比较轻量，性能开销小，通信高效
可以发送文本，也可以发送二进制数据
没有同源限制，客户端可以与任意服务器通信
与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。
Upgrade: websocket
Connection: Upgrade
网络分析工具
tcpdump
如果网络包已经被网卡丢弃了，那么 tcpdump 是抓不到它的；在发包的时候，如果网络包在协议栈里被丢弃了，比如因为发送缓冲区满而被丢弃，tcpdump 同样抓不到它
案例
1. 查看系统是否存在丢包
nstat -z | grep -i drop
旧版net-tools 与 iproute2工具集对比
netstat 不仅比 ss 慢，而且开销也大。netstat 是通过直接读取 /proc/net/ 下面的文件来解析网络连接信息的；而 ss 使用的是 netlink 方式，这种方式的效率会高很多。netlink 在解析时会依赖内核的一些诊断模块，比如解析 TCP 信息就需要 tcp_diag 这个诊断模块。如果诊断模块不存在，那么 ss 就无法使用 netlink 这种方式了，这个时候它就会退化到和 netstat 一样，也就是使用解析 /proc/net/ 这种方式，当然了，它的效率也会相应变差
网卡
启动流程
分配 Rx, Tx 队列内存
注册中断处理函数
ifconfig 中 Rx dropped 与 overruns区别
dropped
表示这个数据包已经进入到网卡的接收缓存 fifo 队列，并且开始被系统中断处理准备进行数据包拷贝（从网卡缓存 fifo 队列拷贝到系统内存），但由于此时的系统原因（比如内存不够等）导致这个数据包被丢掉，即这个数据包被 Linux 系统丢掉
overruns
表示这个数据包还没有被进入到网卡的接收缓存 fifo 队列就被丢掉，因此此时网卡的 fifo 是满的。为什么 fifo 会是满的？因为系统繁忙，来不及响应网卡中断，导致网卡里的数据包没有及时的拷贝到系统内存，fifo 是满的就导致后面的数据包进不来，即这个数据包被网卡硬件丢掉
RingBuffer 满以后，新来的数据包将被丢弃， 可以通过 ethtool 加大环形队列长度
ethtool
查看环形队列大小：ethtool -g eth0
查看环形队列溢出： ethtool -S eth0
在 ifconfig 体现为 overruns
调整环形队列大小： ethtool -G eth0 rx 4096 tx 4096
查看网卡支持的队列数： ethtool -l eth0
通过伪文件查看真正生效的队列数：ls /sys/class/net/eth0/queues
调整网卡队列数： ethtool -L eth0 combined 32
通过伪文件查看真正生效的队列数：ls /sys/class/net/eth0/queues
ksoftirqd 内核处理线程
机器有几核，就有几个该内核线程，该内核线程包含了所有软中断的处理逻辑。软中断信息可以在 /proc/softirqs 读取
查询环形队列 RingBuffer 对应的硬中断号
cat /proc/interrupts: 最左侧一列即为中断号，通过该中断号可以查看该中断由哪个CPU来处理，cat /proc/irp/53/smp_affinify
哪个核响应的硬中断，那么该硬中断发起的软中断就必须由该核来处理
若网络包的接收频率高而导致个别核的 si 偏高，那么通过加大网卡队列数，并设置队列中断号上的smp_affinity，将各个队列的硬中断打散到不同CPU上即可，这样硬中断后面发起的软中断CPU开销也将由多个核来分担
RPS (Receivce Packet Steering)
google 贡献给 linux kernel 的一个 patch，主要的功能是解决多核情况下，网络协议栈的软中断的负载均衡。这里的负载均衡也就是指能够将软中断均衡的放在不同的 cpu 核心上运行
多核环境网卡终端处理
单核环境
传统的单核环境中，没有太多的额外工作可以做，网卡收到数据后，驱动将中断直接给仅有的CPU
多核环境
轮询(RR)
到达一个数据包，驱动将中断传给0号CPU，再到一个数据包，驱动又将中断传给1号CPU，以此类推。这种方式的一个极大的缺陷就是，容易导致包乱序
多队列、多中断号
网卡支持多个队列，每个队列又有一个独立的中断号。但网卡中的队列数往往是固定不变的，而这个数目如果与CPU个数相统一，那么就工作的很好，如果CPU个数跟它不一样则出现 CPU 倾斜问题
RPS(ReceivePacketSteering)
驱动如果能够将中断分发到各个CPU，并且能保证每个流只用一个CPU来处理，这样就可以保证CPU的cache命中率，岂不是很好? 没错，RPS就是为此而来的。RPS方案预想通过计算包中四元组的hash值来确定这个包要被分配到哪一个CPU上，因为这样可以基本保证分配的均等性和某个流被特定CPU所处理。但是如果计算hash值的任务如果由CPU来做，那么就涉及到CPU去读取报头，这将会导致cache miss，如果每个包都来一次cache miss，结局将是悲剧的。而事实上CPU必将miss，因为这个数据包是全新的、刚刚到达的。所以这个工作万万不能有CPU来做，那么谁来做呢? 您也许想到了，是网卡本身。网卡产生了hash值后，由驱动去读取这个hash值，进而完成后续的中断分发。
off load
TSO (TCP Segmentation offload)
一种利用网卡替代 CPU 对大数据包进行分片，降低 CPU 负载的技术。如果数据包的类型只能是 TCP，则被称之为 TSO。此功能需要网卡提供支持。TSO 是使得网络协议栈能够将大块 buffer 推送至网卡，然后网卡执行分片工作，这样减轻了 CPU 的负荷，其本质实际是延缓分片
故在 IP 层若发送的数据大于 MTU, 那么就不一定会被分片
开启 tso: ethtool -K eth0 tso on
GSO(Generic Segment Offload)
延缓分片技术。它比 TSO 更通用，原因在于它不需要硬件的支持就可以进行分片。
首先查询网卡是否支持 TSO 功能，如果硬件支持 TSO 则使用网卡的硬件分片能力执行分片；如果网卡不支持 TSO 功能，则将分片的执行，延缓到了将数据推送到网卡的前一刻执行
开启 GSO: ethtool -K eth0 gso on
UFO(UDP Fragmentation offload)
LRO(Large Receive Offload )
将网卡接收到的多个数据包合并成一个大的数据包，然后再传递给网络协议栈处理的技术。这样提系统接收数据包的能力，减轻 CPU 负载
GRO(Generic Receive Offload)
LRO 的软件实现，只是 GRO 的合并条件更加的严格和灵活。
RSS (Receive-Side Scaling)
基于多个硬件接收队列执行接收操作，多 CPU 同时处理，提升接收性能。
XPS(Transmit Packet Steering)
和 RSS/RPS 相对应，对于有多队列的网卡，建立 CPU 与 tx queue 的对应关系，而对于只有单队列的网卡，则没有优化作用
https
请求流程
1. 客户端向服务器发起https请求，同时带上自身
支持的加密算法，服务器返回证书（公钥）
2. 客户端接收到证书后验证合法性，验证通过
后生成一个随机码，并使用公钥加密发送给服务器
3. 服务器接收到后使用私钥解密得到客户端的随机码，用随机码key对内容加密，并将结果返回客户端
证书合法性验证
1. 是否在有效期内
2. 证书是否已被吊销
CRL（Certificate Revocation List）即证书撤销名单
浏览器会缓存这份名单，定期做后台更新
OCSP(Online Certificate StatusProtocol)即在线证书状态协议
3. 证书是否是上级CA签发的
历史背景
网景浏览器极大推动了HTTP的发展，网景公司为了解决HTTP的安全
问题，1994年创建了SSL协议，作为浏览器的扩展，主要用于HTTP。
网景公司意识到互联网还有其他的应用协议，如SMTP,FTP，这些协议在实际应用中也面临同样的安全问题，于是开始思考是否有统一的方案解决互联网通信安全问题。基于此考虑，SSL协议逐渐成为一个独立的协议，该协议能够保证网络通信的认证和安全问题，SSL协议有三个版本，SSL v1, SSL v2 SSL v3
1996年， IEIF组织在SSL v3的基础上进一步标准化了该协议，微软为此取名为 TLS v1.0。
SSL
1. SSL Record Protocol
建立在TCP协议之上，为高层协议提供数据封装、压缩和加密等基本功能支持
2. SSL Handshake Protocol
建立在SSL Record Protocol 之上，用于在实际的数据传输开始前，通信双方进行身份认证、密钥协商和交换加密密钥等
密钥套件（参见密码学）
CA签发证书过程
1. CA 将持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行Hash计算，得到一个Hash值
2. CA使用自己的私钥对该Hash值进行加密， 生成 Certificate Signature, 即对证书进行签名
3. 最后将 Certificate Signature 添加到文件中，形成数字证书
客户端校验服务端证书的过程
1. 客户端使用同样的算法获取证书的Hash值H1
2. 一般浏览器及操作系统都已集成CA的公钥信息，浏览器收到证书后可以使用CA公钥解密Certificate Signature内容，得到一个Hash值H2
3. 最后比较 H1 与 H2, 若两者相同则是可信赖的证书，否则不可信
TLS四次握手
1. 客户端向服务器发送一个Client Hello消息，消息包含TLS版本、支持的密码套件、随机数(Client Random, 用于生成会话秘钥)
2. 服务端收到客户端Client Hello消息后的操作流程
1. 首先确认TLS版本号是否支持，然后选择合适的密码套件，以及生成随机数（Server Random）, 接着返回Server Hello消息
2. 向客户端发送Server Certificate消息，里面包含数字证书
3. 向客户端发送Server Hello Done 消息
3. 第三次握手：客户端根据三个随机数生成会话秘钥（Master Secret），这就是对称秘钥，用于后续Http请求响应的数据加解密
1. 客户端基于Server Random及Client Random 生成随机数 pre master. 然后使用服务器的公钥加密该随机数，通过Client Key Exchange 消息传给服务端
2. 客户端生成会话秘钥后向服务器发送 Change Cipher Spec消息，告诉服务端开始使用加密方式发送数据
3. 客户端再发送一个 Encrypted Handshake Message(Finished)消息，将只有所有发送的数据做个摘要，再用会话秘钥（master secret）加密。让服务器做个验证，验证加密通信是否可用及之前握手信息是否有被中途篡改过
4. 服务器第四次握手，验证流程如客户端第三次握手
TLS四次握手流程图
TLS 版本
1.0
1.2
1.3
DH算法
前置知识
底数 a 和模数 p 是离散对数的公共参数，也就说是公开的，b 是真数，i 是对数。知道了对数，就可以用上面的公式计算出真数。但反过来，知道真数却很难推算出对数。
特别是当模数 p 是一个很大的质数，即使知道底数 a 和真数 b ，在现有的计算机的计算水平是几乎无法算出离散对数的，这就是 DH 算法的数学基础
ECDHE算法
在 DHE 算法的基础上利用了 ECC 椭圆曲线特性，可以用更少的计算量计算出公钥，以及最终的会话密钥
