腾讯云网络自研路由平台—FCR 云网络厂商在用户接入侧一般采用传统网络设备如路由器、交换机，传统网络设备虽然功能稳定，但是开发周期较长，支持功能无法快速匹配互联网厂商日新月异的应用场景。为了解决上述问题，腾讯云网络在接入时使用了FCR（Fast Cloud Router）作为自己的路由控制平台。 FCR自研路由平台不仅支持BGP、静态路由、BFD等各类路由相关协议，同时还可以提供丰富的路由策略以及百万级的路由管理功能。 平台开放：完全基于开源组件构建，打破了传统设备厂商封闭的产品生
自从上次学习了TCP/IP的拥塞控制算法后，我越发想要更加深入的了解TCP/IP的一些底层原理，搜索了很多网络上的资料，看到了陶辉大神关于高性能网络编程的专栏，收益颇多。今天就总结一下，并且加上自己的一些思考。
UCloud外网网关是为了承载外网IP、负载均衡等产品的外网出入向流量，当前基于Linux内核的OVS/GRE tunnel/netns/iptables等实现，很好地支撑了现有业务。同时，我们也在不断跟踪开源社区的新技术发展，并将之用于下一代外网网关的设计。这些新特性可将系统性能和管理能力再提上一档，满足未来几年的需求。在方案设计研发过程中发现，新特性存在不少缺陷和Bug，为此我们向开源社区回馈了10多个patch，并融入到kernel 5.0版本中，帮助完善kernel功能并提升稳定性。
最近工作中遇到某个服务器应用程序 UDP 丢包，在排查过程中查阅了很多资料，我在排查过程中基本都是通过使用 tcpdump 在出现问题的各个环节上进行抓包、分析在那个环节出现问题、针对性去排查解决问题，对症下药，最后终究能够解决问题。但是这种情况大多是因为服务本身的问题，如果是环境问题、操作系统、甚至硬件的问题，可能从服务本身出发不能解决问题，但是这篇文章另辟蹊径，从外部环境分析可能丢包的原因，看完之后，很受用，部分章节对原文有所修改，下面分享出来供更多人参考。
最近工作中遇到某个服务器应用程序 UDP 丢包，在排查过程中查阅了很多资料，总结出来这篇文章，供更多人参考。
1. rx-checksumming：校验接收报文的checksum。
来自Linux内核文档。之前看过这篇文章，一直好奇，问什么一条网络流会固定在一个CPU上进行处理，本文档可以解决这个疑问。为了更好地理解本文章中的功能，将这篇文章穿插入内。
作为网络领域的开发人员，我们经常要与Linux的数据报文打交道，一定要搞清楚数据报文是从何而来，又是如何离去。以前针对这个主题写过一些文章（主要是从源码角度），这次会更重视流程示意图（在细节上必然有所简化），争取在一篇文章中，就让大家理清数据报文的来龙去脉。
翻译自：Network security for microservices with eBPF
作者Liam，海外老码农，对应用密码学、CPU微架构、高速网络通信等领域都有所涉猎。
简单讲，一个qidsc就是一个调度器。每个出接口都需要某种类型的调度器，默认的调度器为FIFO。Linux下的其他qdisc会根据调度器的规则来重新安排进入调度器队列的报文。
DPDK是一个优秀的收发包kit，但它本身并不提供用户态协议栈，因此由将数据报文注入内核协议栈的需求，也就是KNI（Kernel NIC Interface）。作为用户态和内核的接口，其因为没有系统调用和内存拷贝，因此比传统的tun/tap设备要更高效。
◆DPDK是什么 Intel® DPDK全称Intel Data Plane Development Kit，是intel提供的数据平面开发工具集，为Intel architecture（IA）处理器架构下用户空间高效的数据包处理提供库函数和驱动的支持，它不同于Linux系统以通用性设计为目的，而是专注于网络应用中数据包的高性能处理。具体体现在DPDK应用程序是运行在用户空间上利用自身提供的数据平面库来收发数据包，绕过了Linux内核协议栈对数据包处理过程。 ◆DPDK技术介绍 一、主要特点 1、UIO（L
Docker的技术依赖于Linux内核的虚拟化技术的发展，Docker使用到的网络技术有Network Namespace、Veth设备对、Iptables/Netfilter、网桥、路由等。接下来，我将以Docker容器网络实现的基础技术来分别阐述，在到真正的容器篇章节之前，能形成一个稳固的基础知识网。
现在很多人都在诟病Linux内核协议栈收包效率低，不管他们是真的懂还是一点都不懂只是听别人说的，反正就是在一味地怼Linux内核协议栈，他们的武器貌似只有DPDK。
当服务器的并发TCP连接数以十万计时，我们就会对一个TCP连接在操作系统内核上消耗的内存多少感兴趣。socket编程方法提供了SO_SNDBUF、SO_RCVBUF这样的接口来设置连接的读写缓存，linux上还提供了以下系统级的配置来整体设置服务器上的TCP内存使用，但这些配置看名字却有些互相冲突、概念模糊的感觉，如下（sysctl -a命令可以查看这些配置）：
当服务器的并发TCP连接数以十万计时，我们就会对一个TCP连接在操作系统内核上消耗的内存多少感兴趣。socket编程方法提供了SO_SNDBUF、SO_RCVBUF这样的接口来设置连接的读写缓存，linux上还提供了以下系统级的配置来整体设置服务器上的TCP内存使用，但这些配置看名字却有些互相冲突、概念模糊的感觉，如下（sysctl -a命令可以查看这些配置）： net.ipv4.tcp_rmem = 8192 87380 16777216 net.ipv4.tcp_wmem = 8192 65536
进程作为人类的发明，自然也免不了脱离人类的习性，也有通信的需求。如果进程之间不进行任何通信，那么进程所能完成的任务就要大打折扣。人类的通信方式无外乎对白（通过声音沟通）、打手势、写信、发电报、拥抱等方法。同理，进程也可以通过同样的方式来进行通信。本篇我们就来看看进程的这些交互方式。
之前在介绍netstat的时候说过，netstat是一个非常实用的socket查看命令。但是有人留言它已经被ss（Socket Statistics）替代了，那么这个所谓替代netstat的命令，到底怎么用呢？为什么它能替代netstat？
在当今数字化时代，互联网已经成为了人们生活中不可或缺的一部分。而在互联网的基础之上，TCP协议扮演着关键的角色，它负责着数据在网络中的可靠传输。在TCP连接的建立过程中，我们已经了解了三次握手的过程和原理。然而，连接的建立只是TCP协议的一部分，同样重要的是连接的断开过程。本文将重点探讨TCP连接的断开过程，包括四次挥手的过程和状态变迁，以及为什么挥手需要四次和为什么需要TIME_WAIT状态。通过深入理解TCP连接断开的过程，我们可以更好地理解网络通信的原理
本文主要参考intel发布的vpp-sswan白皮书的内容搭建环境验证strongswan和vpp集成环境。
为什么需要使用负载均衡呢？这是一个必较重要的问题 实际生产环境中某单台服务器已不能负载日常用访问压力时，就需要使用负载均衡，把用户的请求数据分担到（尽可能平均分配）后端所有功能同等的集群的节点上,同样也是为了解决单台服务器故障问题，从而提高用户的访问体验。
一、LB常用解决方案 1、硬件负载均衡解决方案： F5公司： BIG-IP Citrix公司： Netscaler A10公司： A10 Array Redware 2、 Linux: LVS 1. 完成Linux Virtual Server作者 （章文嵩，花名段正明） 2. ipvs工作于netfilter框架上 3. ipvs: 框架，工作在内核中，工作在inpu
Kubernetes网络模型设计的一个基础原则是：每个Pod都拥有一个独立的IP地址，并假定所有Pod都在一个可以直接连通的、扁平的网络空间中。所以不管它们是否运行在同一个Node（宿主机）中，都要求它们可以直接通过对方的IP进行访问。设计这个原则的原因是，用户不需要额外考虑如何建立Pod之间的连接，也不需要考虑如何将容器端口映射到主机端口等问题。
连接跟踪（也叫会话管理）是状态防火墙关键核心，也是很多网元设备必不可少的一部分。各厂商的实现原理基本雷同，只是根据各自的业务进行修改和优化。其中，还有不少厂商干脆是基于Linux内核实现的。下面，我们就来看看Linux内核中连接跟踪的几个要点。
前文《使用TCPDUMP和Wireshark排查服务端CLOSE_WAIT（一）》通过TCPDUMP和Wireshark在利用CentOS7作为服务端、Windows10作为客户端，模拟演示了一个TCP通信的CLOSE_WAIT状态，这篇文章主要利用前文的数据尝试解释Linux服务端产生CLOSE_WAIT状态的原因。
CAN，全称为“Controller Area Network”，即控制器局域网，是国际上应用最广泛的现场总线之一。
Linux内核是高并发服务的关键组件之一。以下是一些可用于优化Linux内核的配置。
我在100ASK_IMX6ULL售后群里，发现很多初学者只有单片机基础，甚至没有单片机基础。在学习Linux时，对很多概念比较陌生，导致不知道学什么，也不知道学了之后有什么用。所以我趁着五一假期，编写此文。
所有的电子产品，所用技术都可以认为要么是单片机，要么是Linux；GUI方面主要是QT/Android，它们都是运行于Linux之上的。
本文列举四个比较经典的 Linux 收包引擎，如果还有其他你觉得ok的可以留言。这四个分别是：
本章节介绍的是一款面向四层网关（如四层负载均衡，L4-LB）的高性能的压测工具dperf。该工具目前已经在github上开源，是一款高性能的压测工具：
在线课堂：https://www.100ask.net/index（课程观看） 论 坛：http://bbs.100ask.net/（学术答疑） 开 发 板：https://100ask.taobao.com/ （淘宝） https://weidongshan.tmall.com/(天猫)
在之前的一篇文章中，作者在配置了SO_REUSEPORT选项之后，使得应用的性能提高了数十倍。现在介绍socket选项中如下几个可以提升服务端性能的选项：
一般我们会认为，要确认互联网上的任意两台主机设备是否建立TCP连接通讯，其实并不容易——攻击者如果不在双方的通讯路径中，就更是如此了。另外如果攻击者并不在通讯路径中，要中途中断双方的这种连接，甚至是篡改连接，理论上也是不大可能的。 不过来自加州大学河滨分校，以及美国陆军研究实验室的研究人员，最近联合发表了一篇论文，题为《Off-Path TCP Exploits: Global Rate Limite Considered Dangerous》。 这篇文章提到Linux服务器的TCP连接实施方案存在高危安全
这个题目是之前在我的QQ群里一个同学在腾讯面试过程中被问到的。当时在群里做了简单的讨论，今天系统的把这个问题分析一遍。
由于系统将CAN设备作为网络设备进行管理，因此在CAN总线应用开发方面，Linux提供了SocketCAN接口，使得CAN总线通信近似于和以太网的通信，应用程序开发接口更加通用，也更加灵活。
前几天，我厂剑英和晓培同学在定位一个TCP通信失败问题时，发现原因是客户端发送的TCP数据过长（1460字节），导致数据包无法成功发送到服务端。但通过抓包发现，在三次握手时，双方协商的MSS就是1460。那么，应该是在这个连接的传输过程中，数据包的传输路径发生了变化，走了不同的中间设备，从而导致协商时的MSS大小已经超过了实际的传输路径限制。因为客户端已经发布，我们通过修改服务端的对外接口的MTU，暂时解决了这样的问题。
日常在给客户做稳定性治理时，像实例级别的不可用、主从切换、重启、性能等维度的场景做的比较多，随着治理的深入，大家慢慢把目光专项应用程序更不可控的场景：网络数据包异常。
传统的Linux内核网络协议栈由于更加注重通用性，其网络处理存在着固有的性能瓶颈，随着10G、25G、40G、100G甚至更高速率的网卡出现，这种性能瓶颈变得更加突出，传统内核网络协议栈已经难以满足高性能网络处理的要求。
通过第一章容器网络基础的学习，我们已经实现了单机容器间的互通、容器访问外部网络及容器对外提供服务。 在实际的应用场景中，为了保证业务的高可用性，我们的容器多是跨宿主机部署的，并且部署在不同宿主机上的容器会进行大量的网络通信。那么，怎么实现容器的跨宿主机通信呢？
许多发行版都为内核提供了模块化或整体式的流量控制(QOS)。自定义的内核可能不会支持这些特性。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
