Kubernetes 定义了一种简单、一致的网络模型，基于扁平网络结构的设计，无需将主机端口与网络端口进行映射便可以进行高效地通讯，也无需其他组件进行转发。该模型也使应用程序很容易从虚拟机或者主机物理机迁移到 Kubernetes 管理的 pod 中。 这篇文章主要深入探索Kubernetes网络模型，并了解容器、pod间如何进行通讯。对于网络模型的实现将会在后面的文章介绍。
网络和操作系统内核，对我来说是既陌生又满是吸引，希望能够拨开层层迷雾找到背后的真相。 在 上一篇文章 中我深入探讨了 Kubernetes 网络模型，这次我想更深入一点：了解数据包在 Kubernetes 中的传输，为学习 Kubernetes 的 eBPF 网络加速做准备，加深对网络和操作系统内核的理解。 文中可能有疏漏之处，还望大家赐教。 在开始之前，我可以用一句话来总结我的学习成果：数据包的流转其实就是一个网络套接字描述符（Socket File Descriptor，中文有点冗长，以下简称 socket fd）的寻址过程。 它不是简单的指 socket fd 的内存地址，还包括它的网络地址。
在 上篇文章 用了整篇的内容来描述网络数据包在 Kubernetes 网络中的轨迹，文章末尾，我们提出了一种假设：同一个内核空间中的两个 socket 可以直接传输数据，是不是就可以省掉内核网络协议栈处理带来的延迟？ 不论是同 pod 中的两个不同容器，或者同节点的两个 pod 间的网络通信，实际上都发生在同一个内核空间中，互为对端的两个 socket 也都位于同一个内存中。而在上篇文章的开头也总结了数据包的传输轨迹实际上是 socket 的寻址过程，可以进一步将问题展开：同一节点上的两个 socket 间的通信，如果可以 快速定位到对端的 socket -- 找到其在内存中的地址，我们就可以省掉网络协议栈处理带来的延迟。
尽管咱们是做Java开发的，但是基本的都会和MySQL打交道，并且面试中MySQL的占比都不少，本文来和大家聊聊，关于MySQL的一些开发规范。
在严选基于webview+APP的混合开发模式下，前端和客户端的协作显得尤为重要。细节、标准与沟通可以说是我过去两年时间做混合开发的主要经验，本文中将从这几个方面展开，来从一个前端的角度讲述混合开发经验。
ByteHouse 是火山引擎上的一款云原生数据仓库，为用户带来极速分析体验，能够支撑实时数据分析和海量离线数据分析；便捷的弹性扩缩容能力，极致的分析性能和丰富的企业级特性，助力客户数字化转型。 本文将从需求动机、技术实现及实际应用等角度，介绍基于不同架构的 ByteHouse 实时导入技术演进。
近日，阿里巴巴大淘宝技术题为《MD-VQA: Multi-Dimensional Quality Assessment for UGC Live Videos》—— 适用于无参考视频质量评价的最新研究成果被计算机视觉领域顶级会议IEEE/CVF Computer Vision and Pattern Recognition Conference 2023（CVPR 2023）成功收录。
