共 72 篇相关文章
这篇讲的是如何通过自建本地DNS服务器，来规避GFW对DNS查询的干扰，从而恢复部分网站的访问。文章首先解释了问题根源：GFW会拦截并污染常见的UDP协议DNS请求，导致解析结果错误。而一个有效的对策是利用TCP协议的DNS查询，因为它目前不易被干扰。 作者推荐的具体方案是，使用开源软件Unbound在本地搭建一个DNS服务器。该服务器监听本地，接收程序发出的UDP请求，并将其转换为TCP查询转发给上游公共DNS（如8.8.8.8），从而绕过污染。文章给出了在Windows系统上的详细配置步骤，包括安装、修改配置文件、重启服务，并最终将系统DNS指向本地127.0.0.1，操作性很强。 对于更进一步的安全需求，文章末尾还提到了一个升级思路：可以结合SSL加密，在境外服务器上部署Unbound作为上游，实现查询流量的端到端加密，提供了更彻底的解决方案。
这篇讲的是TCP性能优化背后的原理与可操作的调优方法。作者以《High Performance Browser Networking》一书为依托，将看似晦涩的流量控制、慢启动和拥塞避免机制，用通俗的比喻讲得清晰明白。例如，用“吃几碗饭”比喻接收窗口（rwnd）的限制，用拳击试探比喻拥塞窗口（cwnd）的增长。 文章深入浅出地解释了网络吞吐量受限的核心逻辑：传输性能由rwnd和cwnd中较小的值决定。针对百兆网络却跑不满速的常见问题，作者给出了具体解决方案——根据带宽延迟乘积（BDP）来计算合理的rwnd大小，并介绍了Linux内核中的自动调优机制与关键参数。 对于网页加载等短连接场景，文章通过生动的类比（博尔特百米起跑）和数据对比，揭示了cwnd初始值设置对效率的巨大影响，并引用了Google的研究结论，建议将其调整为10个MSS大小。从原理到实践，文章提供了一套可落地的优化思路。
这篇讲的是“socket”这个在编程中无处不在的术语，究竟是从哪里冒出来的。作者从大家熟悉的中文译名“套接字”和“插口”入手，追溯了这个术语的权威出处。 文章引用了两本经典著作的不同视角：《Java TCP/IP Socket 编程》从应用编程接口的角度，强调socket是让程序通过网络互通的关键抽象；而《TCP/IP详解》则直接指出了它的技术本质——一个IP地址加一个端口号，并明确其来源是RFC793这份最早的TCP规范文档。 最硬核的部分是文章贴出了RFC793中对socket的原始定义。这里清楚地说明，socket是为了解决“单台主机上多个进程如何同时使用TCP”这个问题而设计的。一个socket（由网络地址和主机端口组合而成）可以被多个连接复用，这个设计思想一直沿用至今。 所以，这篇文章不仅仅是解释一个名词，更是一次对网络编程基石概念的考古。它把我们日常使用的工具，与几十年前协议设计者最初的那个简洁而巧妙的构想连接了起来。
这篇文章从一次生产环境的运维问题切入，详细剖析了Linux内核从2.6.18升级到2.6.32后，系统TIME_WAIT状态连接数显著增多的根因。作者的核心工作是对两个版本内核的代码进行diff，精准定位到了`net/ipv4/inet_timewait_sock.c`文件中的一处关键变更。 问题的核心在于`inet_twdr_hangman`函数里，一行负责轮转回收槽位的代码`twdr->slot = ...`的位置被移动了。在旧版本中，无论当前槽位（slot）的timewait块是否被完全清理，该自增操作都会执行；而在新版本中，它被放入了一个条件分支，仅当当前槽位被成功清空时才执行。这个看似微小的时序调整，改变了内核回收timewait块的调度逻辑，最终导致了回收变慢和积压。 文章不仅给出了结论，更通过分析`inet_timewait_death_row`数据结构与`inet_twdr_hangman`的定时回收机制，完整还原了问题发生的底层路径。对于需要理解TCP连接生命周期管理，或是面临类似内核升级后网络连接数异常的工程师来说，这篇深入源码实现的排障手记提供了非常具体的思路和技术细节。
这篇讲的是HTTP KeepAlive机制的工作原理与正确配置。作者从早期每个HTTP请求都需要单独建立TCP连接的性能瓶颈出发，解释了KeepAlive如何允许在一个TCP连接上持续传输多份数据，从而显著减少连接建立开销、降低服务器内核调用与TIME_WAIT状态连接数。 不过，文章也明确指出KeepAlive并非“免费午餐”，配置不当的长连接反而会导致系统资源被无效占用，其损失可能超过重复建立连接。因此，正确设置`keepalive_timeout`参数至关重要。 作者通过编写脚本与`tcpdump`抓包，细致地分析了三种场景：关闭KeepAlive、开启KeepAlive（超时300秒）、以及在同一连接上发送多个请求（超时180秒）。测试清晰地揭示了TCP连接从建立、数据传输到最终释放的完整生命周期。一个关键发现是，`keepalive_timeout`的计时器是在最后一个HTTP响应发送完毕后才开始启动，并在每次收到新请求后重置。这意味着合理的超时设置需要在复用连接提升性能与避免资源长期占用之间取得平衡。
这篇讲的是一个线上 Erlang 服务器遇到的具体困惑：为什么按预期，客户端发送第 4 字节就该阻塞，实际上却到了第 7 字节才阻塞？作者从这个问题出发，深入剖析了 gen_tcp 的发送缓冲区与水位线（high_watermark/low_watermark）机制。 文章指出，理解的关键在于 ERTS 内部 port 的消息队列模型。发送数据（send）实质是向 port 发消息，当队列数据达到高水位线时，port 进入“忙碌”状态，调用者进程会被挂起，直到数据降至低水位线。文章结合参数设置详细推演了缓冲区与水位线的实际交互过程，并澄清了一个常见误解：高水位线更多是一个“软”限制，用于流程控制，而非精确的阻塞点；最终发送端的阻塞，很大程度上取决于接收端的 recv 行为。 作者通过源码与机制分析，将配置选项、内部数据流与观察到的行为串联起来，为理解 Erlang 网络编程中的流量控制提供了清晰的视角。
作者从Fiddler和Charles这些HTTP调试神器聊起，引出了对socket及TCP/UDP调试工具的需求。文章没有停留在理论，而是直接推荐了几款作者亲测的实战工具，并点明了它们各自的长处。 Wireshark依然是底层抓包分析的王者，但文章特意提醒了它可能按端口号自动解码协议带来的小烦恼。而国产工具sokit则更像一把“瑞士军刀”，作者重点介绍了它基于QT的跨平台特性、方便的二进制包组装能力，以及模拟分包/粘包和轻量级抓包的实用功能，甚至分享了自己曾因一个空格导致发送数据异常的真实小故事，这恰恰凸显了详细日志的重要性。 除此之外，文章还对比了体积小巧的TCP/IP Builder，以及能直观监控系统所有连接、帮助排查异常进程的Windows工具TCPView。整体来看，这篇推荐就像一份从实战出发的工具清单，帮助开发者根据具体场景——是深度抓包分析、快速调试协议，还是监控连接状态——选择最顺手的兵器。
这篇讲的是如何在Erlang的TCP服务器（基于gen_tcp）中，从底层实现上来限制单个数据包的大小，以防范潜在的安全风险和资源耗尽问题。 文章从两种包接收模式入手。对于同步接收（{active, false}），作者指出，当使用gen_tcp:recv时，实际上内核会为接收分配一个缓冲区。通过源码可以看到，这个缓冲区大小存在一个硬编码的上限：TCP_MAX_PACKET_SIZE（64MB），一旦请求超过此限制，就会直接返回ENOMEM错误。这可以看作是系统级的防线。 而对于更常见的异步消息投递（{active, true}），控制则发生在协议解析层面。通过inet:setopts设置的packet_size选项，会在数据解析时被检查。文章通过追踪tcp_remain等函数的源码揭示了这一机制：当解析器发现包头声明的长度超过了设定的psize值，这个数据包就会被判定为无效。 核心巧妙之处在于，这两种机制一个在缓冲区分配时卡住，一个在协议解析时拦截，共同构成了对包大小的纵深防御。文章通过解读底层C驱动代码，让读者清晰地看到这些看似简单的应用层选项是如何被严格实现的，对于需要定制或深入理解Erlang网络编程的开发者来说，提供了扎实的内部视角。
这篇讲的是 Erlang/OTP 中 `gen_tcp` 模块几个缓冲区参数之间的常见混淆。很多开发者看到 `buffer`、`sndbuf` 和 `recbuf` 这三个选项时容易困惑：它们到底是什么关系？文档的简要说明往往不足以理清头绪。 作者选择直接深入 C 驱动层源码（`inet_drv.c`）来寻找答案。通过分析 `inet_set_opts` 函数的实现，文章揭示了核心事实：`sndbuf` 和 `recbuf` 设置的是内核 Socket 层的发送与接收缓冲区大小，这符合常规理解。而 `buffer` 选项则完全不同，它设置的其实是 Erlang VM 内部、应用层用于暂存从 Socket 读上来的原始数据的缓冲区大小提示（`desc->bufsz`）。 文章一个巧妙的发现是，源码中存在自动调整逻辑：当显式设置 `sndbuf` 或 `recbuf` 后，`buffer` 的值会被自动更新为两者中的较大值，以确保应用层缓冲区足够容纳内核传上来的数据。但其影响范围仅限于接收路径——因为发送数据可以利用队列，无需类似的额外缓冲。 通读全文，它厘清了一个关键结论：这三个参数分属不同层级，`buffer` 专注于控制 Erlang 侧接收数据的临时缓存大小，其默认值和动态扩容策略都围绕接收场景设计，而不直接影响内核的 Socket 缓冲区。对于需要精细调优 TCP 通信性能的开发者，理解这层区别至关重要。
这篇讲的是作者从自己推荐HTTP调试工具的过往经验出发，引出了对Socket、TCP/UDP调试及抓包工具的系统推荐。作者作为一名“工具控”，不仅介绍了像Wireshark这样公认的网络抓包神器——它功能强大但偶尔会“自作聪明”地按端口号解码协议，也重点安利了一款国人开发的跨平台工具sokit，它能方便地模拟分包粘包，支持客户端、服务器、代理三种模式，不过作者也分享了一个在发送二进制数据包时因空格导致发送异常的小坑。 文章还列举了TCP/IP Builder、TCPView等其他几款各有侧重的工具。其中，TCPView尤其适合用于监控系统当前的TCP/UDP连接状态，甚至能帮助排查一些异常连接。作者最后也坦言，对于简单的调试需求，自己动手写脚本同样便捷。 这些工具基本覆盖了从数据包捕获、协议分析到连接状态监控的常见场景，适合在不同环节辅助开发者进行Socket通信的调试与排查。
这篇讲的是网络协议中那位“低调的幕后英雄”——UDP。作者从它和TCP的兄弟关系切入，点明两者虽同处传输层，但性格迥异：UDP更像随性的文科生，不追求严格顺序，换取了简单与高效，因此在语音、视频、DNS查询等对延迟敏感但能容忍少量丢包的场景下大显身手。 文章的核心是“赏析”其精巧的8字节包头。与TCP冗长的20字节头部相比，UDP头只包含源/目的端口、长度和校验和，这直观体现了它的设计哲学：轻量化、低开销。作者还特别解释了“用户数据报长度”字段的含义，并引用了一个极其实用的结论：在以太网环境下，UDP数据载荷最好控制在1472字节以内，以避免IP分片带来的风险；而在复杂的互联网环境中，这个安全值则建议在548字节左右。 这些从底层协议特性推导出的具体数字建议，让这篇赏析不止停留在概念层面，为实际的网络编程提供了清晰的参考尺度。
这篇讲的是一台Nginx/PHP服务器时不时出现HTTP服务卡住的排查故事。作者的排查思路很清晰：先从应用层入手，通过查看Nginx日志中PHP的响应时间与Strace跟踪，排除了PHP的嫌疑。接着转向Nginx本身，确认其默认已关闭Nagle算法。随后检查了Linux内核的tcp_timestamps等参数，也排除了配置问题。 在思路陷入僵局后，作者决定使用tcpdump抓包。面对原始日志的晦涩，他巧妙地借助Wireshark进行可视化分析，从中发现了大量“TCP Dup ACK”和“TCP Out-Of-Order”标志，这直接指向了网络层可能存在的丢包。最终，通过使用`ping -f`命令发起洪水请求，屏幕上不断出现的丢包点直观地证实了网络状况确实不佳。 文章将问题根源定位为网络丢包，但并未止步于此，而是将更底层的物理原因（如网线、网卡或带宽）留给了更专业的运维人员。整个排查过程层层递进，展示了从应用层到内核层再到网络层的完整诊断链条。
这篇讲的是网络协议分层模型和核心协议。作者从经典的OSI七层模型和更实用的TCP/IP四层模型对比出发，梳理了从物理层到应用层的数据流转过程。 文章的重点落在对网络层的剖析上。它详细拆解了IPv4和IPv6的数据包报文头结构，比如IPv4的IHL字段如何定义头部长度，IPv6如何通过更简洁的头部和128位地址来优化设计。同时，也点明了ICMP、IPsec等协议在网络层的角色。 除了重点讲网络层，文章也覆盖了传输层的TCP/UDP和应用层的HTTP、FTP等常见协议。最后，作者还提到了一个容易被忽略的socks5协议，解释了它在五层和七层模型中不同的定位，以及作为代理协议的实用性。整体上，文章以协议分层为脉络，兼顾了原理细节和实际应用。
这篇讲的是如何解决高并发下PHP服务器因频繁创建TCP短连接导致的端口耗尽问题。作者从观察到的真实案例切入——服务器因大量TIME_WAIT状态堆积，耗尽了可用端口，导致新建连接失败。常见的“缩短2MSL时间”的方案治标不治本，因此他引导读者思考更优的解法。 文章核心对比了Nginx与PHP-FPM之间的两种通信方式：默认的TCP socket和Unix Domain Socket（UDS）。作者结合一个WebGame的架构实例指出，当Nginx与PHP-FPM部署在同一台服务器时，使用TCP socket（尤其是短连接模式）会因经过完整的网络协议栈而产生不必要的系统开销，并引发上述的端口问题。相比之下，Unix Domain Socket绕过了TCP/IP层，直接在内核中通过文件套接字通信，大幅降低了连接建立与销毁的开销，从根本上避免了端口竞争。 文章最终给出的结论很明确：对于同机部署的Nginx与PHP-FPM，切换到Unix Domain Socket通常是更优的选择，它能提升效率并彻底解决因短连接导致的资源瓶颈。这对运维和后端开发人员优化本地服务通信有直接的参考价值。
这篇技术文章深入剖析了Linux内核网络栈中一个精巧的机制：TCP Small Queue (TSQ)。作者从一个常见疑问出发——既然已经有了`tcp_wmem`限制TCP层队列，为何还需要TSQ？以此引出关键：数据包从TCP层到网卡要经过多个队列，TSQ旨在更全面地控制排队延迟。 文章的核心在于对两个内核函数的源码级解读。其一是`tcp_wfree`，作为网络套接字缓冲区的析构函数，它巧妙地在缓冲区即将被丢弃时“截胡”，检查特定标志位后将套接字重新加入TSQ队列调度。其二是`tcp_tasklet_func`，它处理队列中的套接字，并根据其是否被用户进程持有来决定立即发送或推迟至`release_sock()`。 TSQ的巧妙之处在于，它没有直接维护一个可计算长度的独立队列，而是“寄生”于内核网络路径的关键节点（如缓冲区释放和套接字关闭）来间接判断队列空间是否充裕，以此实现动态的发送限速。这种设计展现了对TCP内部运作机制的深刻洞察。
这篇赏析从TCP报文段的格式图入手，逐一拆解了其包头结构的每个细节。作者没有停留在表面介绍，而是深入每个字段的设计意图，比如通过序号和确认号如何协同实现可靠传输，SYN、ACK、FIN等标志位在连接生命周期中扮演的角色，以及窗口大小字段对流量控制的精妙调节。 文章特别聚焦于TCP头部中那些容易被忽略却至关重要的部分，如校验和字段如何保障数据完整性，紧急指针在特定场景下的应用。通过图解和实例，它展示了这些字段如何共同支撑起TCP的“面向连接”和“可靠”两大核心特性，
作者在本文中深入探讨了tcp-proxy在实际应用中遇到的几个典型小问题，这些经验源于作者的近期排查过程。文章首先提到了代理连接不稳定的故障，根因分析指向了TCP keepalive设置与后端服务超时不匹配，导致连接被意外终止；作者通过调整sysctl参数中的net.ipv4.tcp_keepalive_time和net.ipv4.tcp_keepalive_intvl值，并结合应用层心跳机制解决了这一问题。其次，针对代理转发时出现的随机
这篇讲的是面试中关于TCP Flag的一个经典问题。面试者被要求介绍TCP flags时，特别提到了SYN和FIN在ACK确认时需要占用一个字节的数据，而其他标志如PSH、RST、URG等则不需要。面试者猜测是因为其他标志“不重要”，但这背后其实揭示了TCP协议设计的深层逻辑。 TCP协议中的标志位用于控制连接状态，每个标志都扮演特定角色。SYN用于建立连接时同步序列号，FIN用于释放连接，它们在ACK过程中必须占用数据字节，以确保可靠传输并避免确认丢失。相比之下，PSH（推动数据）、RST（重置连接）等标志通常不需要这种机制，因为它们的语义更多依赖即时处理而非额外的数据确认。关键差异在于：SYN和FIN直接影响连接的生命周期，需要更强的可靠性保障；而其他标志则更多是辅助性控制，对数据完整性的要求相对灵活。 文章从这个常见的面试场景出发，深入浅出
这篇讲的是一个名为 Chaos 的新生代网络事件库。作者从自身在异步编程方面的积累出发，介绍 Chaos 是一个基于 Linux 平台、使用 C++ 按 reactor 模式开发的网络库，目前专注于 TCP 协议，并仅在 x86_64 架构下提供编译支持，遵循 3-clause BSD 开源协议。 在设计上，作者坦言 Chaos 的接口风格深受 boost asio 的影响，后者在异步编程模型上的清晰思路给了他很大启发。不过，这也引出了一个有趣的开发哲学：作者并没有深入研读 asio 的源码。他解释说，一方面是 boost 重度模板化的代码可读性颇具挑战，更重要的是，他希望避免在“先入为主”的设计中丧失独立思考的机会。 因此，Chaos 的诞生更像是一次主动的实践与重构。作者希望通过亲身探索，在吸收优秀设计思想的同时，构建出属于自己的网络编程解决方案。文章作为系列的开篇，为我们揭示了这个新项目背后的技术选型与思考起点。
这篇讲的是作者在C语言服务器上实现WebSocket连接的完整实践。作者从项目需要实时通信的需求出发，决定尝试在轻量级的C服务器上直接集成WebSocket支持，而非依赖现成的Node.js或Go生态。 文章详细拆解了其中的核心挑战：如何用C底层处理WebSocket的帧封装、握手升级以及持久连接的管理。作者重点分享了对WebSocket协议握手过程的解析与响应构建，以及如何利用epoll实现高效的非阻塞I/O处理，确保在单线程模型下也能支撑大量并发长连接。 实践中遇到的一个典型问题是粘包处理，作者通过设置明确的帧边界解析状态机来解决。最终，这个基于C的实现达到了预期的低延迟和高吞吐量性能，资源占用也远低于解释型语言方案。对于想深入理解网络协议细节、或在资源受限环境中构建高性能服务的开发者，这篇文章提供了一个清晰的实战参考。
