标签：HTTP

共 130 篇相关文章

IT 累计浏览 2,318

HTTP 的 POST 参数提交和上传的不同与 Mojolicious 的实现.

这篇技术文章聚焦于HTTP协议中POST请求的一个常见混淆点：参数提交与文件上传的底层差异。作者从客户端（如浏览器Form表单、curl命令）和服务器端（以Mojolicious框架为例）两个视角，清晰地剖析了依据`Content-Type`区分的三种主要方式。第一种是默认的`application/x-www-form-urlencoded`，适用于常规表单数据提交，参数会经过URL编码。第二种是`multipart/form-data`，专为上传文件或二进制数据设计，它使用随机边界来分隔内容，能有效处理大文件，Mojolicious会智能地将此类文件封装为`Mojo::Upload`对象以便高效处理。第三种则是直接以POST body发送原始内容，参数通过URL传递，这种方式简单直接，但在处理大文件时可能带来显著的内存占用问题。文章通过具体的代码示例（如`Mojo::UserAgent`的提交方式）和真实的HTTP报文片段，直观展示了这三种方式在协议层面的实际区别，以及在Mojolicious服务器端分别如何接收与解析数据，为开发者在不同场景下选择合适的提交方式提供了明确依据。

IT 累计浏览 6,427

计算机网络协议赏析-HTTP

大家每天都在敲击的http://，可能是计算机网络里最“熟悉的陌生人”。这篇文章从这个视角切入，带我们重新认识这位应用层的明星协议。它将HTTP与幕后的TCP/IP协议对比，点明HTTP作为用户直接面对的“台前大腕”的地位。作者没有停留在概念层面，而是清晰地拆解了HTTP工作的四个步骤：从TCP连接建立，到客户端发出请求报文，服务器返回响应报文，最后连接断开。文章的核心价值在于将协议细节“可视化”。它详细展示了一次典型的HTTP请求和响应报文长什么样，并解释了每一行代码的作用——从请求方法、头部字段，到那个容易被忽略但至关重要的空行。同时，文章也系统梳理了那些常见的状态码：从200 OK到404 Not Found，再到500服务器错误，让读者真正读懂这些数字背后的含义。除了基础，文章还延伸到了HTTP 1.0与1.1版本的演进，特别是“持久连接”这一关键改进，并提及了缓存控制等高级用法。整篇文章像一位耐心的向导，将抽象的协议规范转化为具体可感的报文结构，帮助读者建立起对HTTP工作原理的扎实理解。

IT 累计浏览 2,915

底层通讯协议问题排查案例

这篇讲的是作者在处理用户技术支持时，亲历的一系列底层网络通讯协议“踩坑”与排查实录。这些案例看似离奇，根因却往往藏在协议栈的深处或网络环境的微妙配置中。文章详细拆解了五个典型案例：包括NAT环境下TCP时间戳机制导致的连接失败、ISP篡改MTU引发的UDP丢包、中间网络设备异常引起的MSS分片问题、TCP动态窗口无法增长导致的速率极低，以及网卡速率协商错误造成的单向慢传输。每个案例都从具体现象出发，通过抓包分析等手段定位到根本原因，并给出了如调整内核参数（tcp_timestamps、tcp_window_scaling）、修改MSS值、检查网卡状态等明确的解决方法。这不仅是一份实用的故障排查手册，更像是一份网络协议在复杂生产环境中行为特性的观察笔记。作者将枯燥的协议规范（如RFC1323、MTU）与鲜活的一线问题结合，展示了如何从表象层层深挖至协议与环境的交互点。对于需要处理类似网络疑难杂症的开发者或运维人员，文中从现象推导到根因的排查思路，以及那些意想不到的解决方案，都提供了直接的参考和启发。

IT 累计浏览 3,829

Beforeunload打点丢失原因分析及解决方案

这篇技术文章由1688的朱铁根和胡大军撰写，他们从淘宝团队早年发现的“页面跳转前发送的打点请求丢失”现象切入，深入剖析了这一前端数据采集中的经典痛点。作者指出，问题核心在于浏览器页面卸载机制与网络请求时序的冲突：当页面跳转指令发出后，浏览器会迅速销毁当前页面的所有对象，包括用于发送打点请求的Image对象。如果此时打点服务器尚未完成响应，该HTTP请求就会被强制终止，导致数据丢失。为解决这一矛盾，文章并未建议以牺牲用户体验（如延迟页面响应）为代价，而是巧妙地利用了`window.name`属性的特性。在页面卸载前，将打点数据临时附加到`window.name`中；页面刷新加载后，新页面立即读取并发出这个积攒的打点请求。该方案有效规避了`window.name`在页面刷新后依然保留的特性，同时解决了`cookie`或`localStorage`存在的跨域限制问题。实测数据显示，该方案效果显著，在Chrome浏览器中打点回收率平均提升了约13%，在各版本IE浏览器上也取得了稳定的提升，为解决此类前端数据采集问题提供了一种可靠且兼容性良好的工程思路。

IT 累计浏览 1,636

网络传输协议AMF初探

这篇讲的是 AMF（Action Message Format）协议，一种专为高效数据传输设计的二进制格式。与传统的 SOAP/XML 文本传输方式不同，AMF 采用二进制编码，能高度压缩数据，特别适合传递大量资料——数据量越大，传输效率优势越明显。文章梳理了 AMF 的核心特点：它可以直接传输 Flash 内置对象（如 Object、Array、Date），服务器端能自动解析，大幅简化开发流程。作者从 Flash Remoting 的实际选择出发，对比了 AMF 与 SOAP 的关键差异。AMF 不仅比冗长的 XML 更高效，而且因为它专注于支持 ActionScript 数据类型，在浏览器中体积仅需约 4KB（压缩后），而 SOAP 则庞大得多，且存在头部请求不支持的问题。文章还列举了 AMF 协议支持的数据类型及其对应的十六进制值，展示了其结构的紧凑性。在实现层面，文章介绍了 AMF 基于 HTTP 的典型处理流程：从客户端请求、反序列化、服务处理到响应序列化，并提及 PHP、.NET、Python、Ruby 等主流语言都已拥有成熟的 AMF 框架（如 AMFPHP、FluorineFx），开发者可以快速实现 Flash 与后端数据库的通信。总的来说，这篇文章清晰地说明了 AMF 如何通过二进制优化和对 Flash 生态的专注，在特定场景下（尤其是需要高效、轻量交互的 Web 应用中）成为比 SOAP 更具优势的选择。

IT 累计浏览 2,694

UCMQ简介

这篇技术分享的主角是UCMQ，一个由UC Web开源的轻量级HTTP消息队列。作者坦诚，项目的初衷是改进类似HTTPSQS的方案，解决其底层TC存储因数据膨胀导致的内存与性能瓶颈。 UCMQ的核心设计思路是“去TC化”。它摒弃了传统的TC存储，转而采用更高效的日志文件存储方式。其关键在于数据被顺序写入内存映射的文件中，且缓存区域随读写指针移动，这种设计既大幅节省了内存开销，又保证了出色的读写性能。在特性上，它支持标准HTTP协议与长连接，单实例支持多队列动态管理，并能实时监控队列状态。性能测试数据直观展示了其效果：在配备多核CPU和千兆网卡的环境下，无论是长连接还是短连接，其入队列、出队列速度均能稳定超过10000次/秒。文中也详细介绍了其包含控制模块、网络驱动、队列管理和存储模块的内部架构。尽管作者谦虚地称之为“拙劣的开端”，但文中扎实的架构图解与性能数据，已清晰勾勒出这款高性能HTTP MQ的轮廓。

IT 累计浏览 5,026

http keepalive

这篇讲的是HTTP KeepAlive机制的工作原理与正确配置。作者从早期每个HTTP请求都需要单独建立TCP连接的性能瓶颈出发，解释了KeepAlive如何允许在一个TCP连接上持续传输多份数据，从而显著减少连接建立开销、降低服务器内核调用与TIME_WAIT状态连接数。不过，文章也明确指出KeepAlive并非“免费午餐”，配置不当的长连接反而会导致系统资源被无效占用，其损失可能超过重复建立连接。因此，正确设置`keepalive_timeout`参数至关重要。作者通过编写脚本与`tcpdump`抓包，细致地分析了三种场景：关闭KeepAlive、开启KeepAlive（超时300秒）、以及在同一连接上发送多个请求（超时180秒）。测试清晰地揭示了TCP连接从建立、数据传输到最终释放的完整生命周期。一个关键发现是，`keepalive_timeout`的计时器是在最后一个HTTP响应发送完毕后才开始启动，并在每次收到新请求后重置。这意味着合理的超时设置需要在复用连接提升性能与避免资源长期占用之间取得平衡。

IT 累计浏览 5,109

HTTP 正向代理与反向代理

这篇讲的是代理技术中正向与反向的核心区别。作者从大家最熟悉的“翻墙”场景切入，解释了正向代理由客户端主动设置（比如配置VPN），用于突破访问限制或进行网络管控，就像通过一台能上网的“网管”机器连接外部世界。而反向代理则完全不同，它部署在服务器端，用户毫无感知。文中特别指出，反向代理主要用于两件事：负载均衡，以及通过地理位置优化提升性能——比如电信用户通过代理服务器经内部光纤访问网通资源，速度会快得多。文章用电信用户获取文件的对比例子，清晰说明了反向代理如何通过服务器端的资源整合来改善用户体验。最后总结道，两者最根本的差异在于：正向代理由客户端配置，反向代理则由服务端对服务器间通信进行代理，实现负载分配与访问加速。文末提到作者参考了《HTTP权威指南》，其个人对“防火长城”作用的理解也为我们提供了一个观察网络代理不同角色的有趣视角。

IT 累计浏览 4,574

Nginx 响应 400 的处理

作者从实际生产环境出发，剖析了Nginx返回400 Bad Request的几种隐蔽原因。除了常见的请求头过大，端口探测工具或LVS等负载均衡设备的健康检查也会导致大量400错误，日志里全是空行非常干扰排查。文章深入分析了这类日志的特征：请求里连HTTP方法（如GET）或协议版本（HTTP/1.1）都没有，导致它们根本匹配不到任何常规的location规则。作者尝试用`if`指令过滤协议版本，但发现这无法阻止日志产生。最终，他给出了一个简洁有效的方案：通过配置一个监听默认端口、主机名为空的`server`块，并直接关闭其访问日志（`access_log off`），将这些“无效”请求全部吸收并静默处理。这个方法从源头上解决了日志污染问题，干净利落。

IT 累计浏览 12,110

HTTP协议Keep-Alive模式详解

这篇讲的是HTTP协议中的一个关键性能优化机制——Keep-Alive模式。作者从HTTP“请求-应答”的本质出发，对比了默认断开的普通连接和持久化的Keep-Alive连接。在普通模式下，每一次请求都要单独建立和关闭TCP连接，开销很大。而启用Keep-Alive后，连接会被重用，避免了重复握手的损耗。文章指出，HTTP 1.0默认关闭此特性，需要手动开启；而从1.1开始，这已是默认行为，服务器是否支持决定了实际效果。文章的重点分析了Keep-Alive如何判断消息传输完成。由于连接不会自动断开，不能依赖EOF信号。作者详细解释了两种标准方法：一是通过`Content-Length`头部明确告知数据长度；二是使用`Transfer-Encoding: chunked`进行分块编码传输，尤其适用于动态生成的内容。文中甚至给出了chunk编码的具体格式示例。此外，文章还梳理了RFC标准中消息长度的优先级判定规则，并附录了常见的HTTP头字段解释。可以看出，Keep-Alive并非简单的“保持连接”，而是一套涉及连接复用、数据完整性和协议协商的完整方案，其优势在于节省CPU与内存、支持请求管道化、降低网络拥塞和延迟。理解它，是深入掌握现代HTTP性能调优的基础。

IT 累计浏览 6,704

HTTP KeepAlive，开启还是关闭

这篇文章讨论了HTTP KeepAlive在现代网络环境下的实际价值。作者从传统的认知出发——即开启Keep-Alive可以通过复用TCP连接来减少开销，提升用户体验——但随即结合高带宽低延迟的现实条件和现代浏览器的并行加载策略，对这一观点提出了质疑。文中通过展示一台Nginx服务器的Status数据，给出了一个非常具象的反例：该服务器开启KeepAlive后，平均每个连接只处理了约1.01个请求，几乎没有实现有效的连接复用。由此引出一个关键洞察：KeepAlive的益处并非普适。对于客户端偶尔访问一次的WebService类应用，维持长连接反而会浪费服务器资源，此时关闭它才是更优的选择。作者最终引导读者跳出教条，结合自身服务的实际访问模式（如连接复用率、并发需求等）来重新评估这个配置项，而非盲目地沿用“最佳实践”。

IT 累计浏览 5,342

网络协议简介

这篇讲的是网络协议分层模型和核心协议。作者从经典的OSI七层模型和更实用的TCP/IP四层模型对比出发，梳理了从物理层到应用层的数据流转过程。文章的重点落在对网络层的剖析上。它详细拆解了IPv4和IPv6的数据包报文头结构，比如IPv4的IHL字段如何定义头部长度，IPv6如何通过更简洁的头部和128位地址来优化设计。同时，也点明了ICMP、IPsec等协议在网络层的角色。除了重点讲网络层，文章也覆盖了传输层的TCP/UDP和应用层的HTTP、FTP等常见协议。最后，作者还提到了一个容易被忽略的socks5协议，解释了它在五层和七层模型中不同的定位，以及作为代理协议的实用性。整体上，文章以协议分层为脉络，兼顾了原理细节和实际应用。

IT 累计浏览 4,916

宽带网络运营商劫持网站的技术分析

这是一篇关于宽带运营商劫持用户网页流量的深度技术排查记录。作者从自家网络出现异常弹窗广告入手，发现无论访问大小网站，网页都会被远程注入 iframe，导致浏览器右下角弹出无关的 Flash 广告。文章的核心在于技术分析过程。通过直接发送 HTTP 请求而非依赖浏览器缓存，作者捕获了被篡改的完整响应包，揭示了运营商如何用一个“空壳”页面加载原始网站并侧载第三方广告脚本。更进一步，作者通过 Whois 查询追踪到广告域名（istreamsche.com）指向北京集奥众和公司，并在联系客服时发现，连运营商自家技术人员的办公网络也未能幸免，将问题根源指向了上级运营商或高层决策。面对这种普遍存在的“流量劫持”，文章给出了一个切实可行的用户端解决方案：通过浏览器插件（如 User Agent Switcher）清空或修改发送给网站的 User-Agent 标识。由于大部分网站不依赖此字段进行功能判断，该方法能有效绕过运营商的劫持规则，恢复干净的网页浏览。

IT 累计浏览 17,452

浅析http协议、cookies和session机制、浏览器缓存

这篇讲的是从实际网站数据出发，拆解HTTP协议中几个关键但常被忽略的环节。作者从QQ空间的完整请求与响应头入手，直观展示了HTTP交互的全貌，比如请求行、状态行以及各头域的格式与作用。文章的核心在于实践对比，作者测试了包括CSDN、腾讯、新浪、百度在内的十余家主流网站，深入分析了`Connection`、`Content-Encoding`、`Server`、`Cache-control`等头域的具体表现。例如，为什么腾讯、新浪等部分大型网站会使用`Connection: close`而非默认的长连接？`Server`头域如何暴露了网站使用的服务器信息（如腾讯内部的QZHTTP、淘宝的Tengine），这又带来了哪些安全考量？这些对比都给出了作者的分析。更重要的是，文章并未止步于分析，而是提供了对应的PHP实现代码，比如如何通过`header()`函数设置`Connection`、`Cache-control`、`Last-Modified`，以及如何利用`if-modified-since`实现304缓存判断。整篇文章将理论知识与大站的实际运维策略、具体的编码实践紧密结合，对于想深入理解HTTP机制并应用于开发的读者来说，提供了非常具象的参考。

IT 累计浏览 4,894

一个登陆认证系统

从代理项目《狂刃》的登录认证需求出发，作者描述了一个在时间压力下临时设计的简化认证协议。该协议基于HTTP，旨在为非Web应用在不安全信道上建立认证流程。核心设计包含游戏服务器（G）、认证平台（E）和客户端（C）三方交互：G生成一次性盐值（salt），C用用户密码对盐值进行加密签名后发送给E验证；E验证通过后，用相同算法生成发给G的认证令牌，最终由C转发给G完成双向确认。这种设计让G和E无需保持通信，只需预共享密码，降低了服务器状态管理的复杂度。文章的重点落在实际部署中的一次“拍脑袋”引发的事故。合作方在未通知的情况下，使用作者用Lua快速编写的调试用认证服务器，对600人进行了压力测试。初期认证大面积失败，排查发现根因在于服务器的网络配置：该服务器配有电信和网通双线IP，而作者最初将服务绑定地址（bind address）默认设为127.0.0.1，合作方在部署时仅将其改为了服务器的其中一个IP，导致部分客户端无法连接。最终将绑定地址改为0.0.0.0才解决了问题。这个意外插曲揭示了一个常见陷阱：内部开发用的快速工具一旦被外部环境直接使用，其默认配置或简化实现可能成为隐形炸弹，即使核心逻辑（如作者后续补上的并发处理）经受住了压力，但外围配置的疏漏同样会导致生产事故。

IT 累计浏览 3,664

总结一下遇到过的网络同步IO导致服务阻塞的问题

这篇讲的是作者在工作中亲身遭遇的两个因同步IO引发服务阻塞的典型问题。第一个场景是fri_svr服务需要向第三方平台（如人人、Facebook）批量拉取用户数据，由于整个HTTP请求/响应周期过长（1s-10s），当并发请求量升高时，按user_id哈希分配的专用线程队列会发生堆积，直接导致服务内存暴涨并无法及时响应前端。第二个场景则发生在使用ICE同步RPC的数据服务上。作者发现，某个线程队列中只要有一个任务（对应某个用户的请求）被意外阻塞，后续同队列的所有任务都会被拖累，导致部分用户响应延迟几分钟。而哈希到其他队列的用户则不受影响。为了解决问题，作者将线程模型从“一个线程对应一个队列”调整为传统的线程池（多线程对应一个队列），从而避免了单点阻塞的连锁反应。但核心挑战在于保证同一用户（拥有相同owner）任务的执行顺序。作者设计了一个线程安全的数据结构：内部维护任务队列和一个KV表来记录每个owner是否正在被处理。任务被取出时，会检查并锁定owner状态，从而确保后续任务不会被乱序执行。作者最后也指出，这种方案会引入额外的check/set开销与线程竞争。如果任务都是执行时间可控的CPU密集型任务，那么最初的一对一线程队列模型可能仍是更优选择。

IT 累计浏览 2,365

urllib2源码解读三（探索OpenerDirector的add_handler）

这篇讲的是 urllib2 源码中 OpenerDirector 的 add_handler 方法如何实现 handler 的自动分类。文章接续了之前对 build_opener 的探讨，深入到 add_handler 的内部，揭示了它并非简单存储，而是根据每个 handler 实例所具有的方法，进行智能归类。核心的实现思路非常巧妙：它不依赖显式的类型标识，而是通过解析 handler 方法名的结构来动态分类。具体来说，代码会遍历 handler 的所有方法，检查方法名是否包含特定模式，例如 `http_error_404` 或 `https_open`。它以第一个下划线为界，前半部分是协议（如 http、https），后半部分是条件（如 open、error_301）。根据这些解析出的信息，handler 会被分别注册到 `handle_open`、`handle_error`、`process_request`、`process_response` 这四个核心字典中，使得后续的网络请求调用链能高效、准确地匹配到对应的处理器。这种基于“约定优于配置”的动态注册机制，让 handler 的功能与协议、状态码紧密绑定，既保持了扩展的灵活性，又确保了内部调用的有序性，是 Python 标准库设计中的一个典型范例。

IT 累计浏览 3,898

urllib2源码解读一（开篇）

作者从某个午饭后刷微博的感悟出发，决定深入阅读Python中一个超高频使用的模块——urllib2的源码。这篇文章是该系列的开篇，为读者勾勒了整个urllib2工作流的全景图。文章重点剖析了三个核心对象：负责构建处理器的`build_opener`、作为流程调度中心的`openerdirector`，以及封装请求细节的`request`对象。其巧妙之处在于`openerdirector`的设计，它利用两个字典（`process_request` 和 `process_response`）对不同协议的Handler进行分类管理，形成了一条清晰的处理链。作者也点出，这背后借鉴了经典的Command设计模式。在补充说明中，作者用更直观的语言复述了从`urllib2.urlopen(url)`调用开始的完整流程：OpenerDirector被构建并注入一系列Handler，生成的Request对象决定请求方法（GET/POST），并最终经过Handler链的处理返回一个类似文件对象的Response。这种从实例到抽象、再回归实例的解读方式，让复杂的框架设计变得易于理解。作者阅读源码的初衷，是想透彻掌握这个日常工具，并从其设计中汲取营养。对于想理解HTTP请求处理机制或学习框架设计的开发者来说，这篇拆解提供了一个很好的思维起点。

IT 累计浏览 11,452

你必须了解的Session的本质

这篇讲的是PHP中Session的本质与安全陷阱。作者从HTTP协议无状态性这一底层特性切入，解释了为什么我们需要Session来维持应用状态。他详细拆解了Cookie作为HTTP扩展的工作原理，以及Session ID如何在客户端与服务器之间传递——无论是通过自动的Set-Cookie头，还是通过URL参数或POST数据。文章特别强调，许多开发者误以为PHP内置的Session机制自动提供了安全性，但事实并非如此。作者通过一个具体的会话劫持攻击示例（攻击者窃取并重放PHPSESSID），清晰地展示了如果仅依赖默认机制，会话数据将面临风险。他指出，安全必须由开发者主动加固，而非框架自动保障。整体上，这篇文章像一份面向PHP开发者的安全指南，从协议基础讲到实战风险，核心观点是：理解Session背后的网络交互细节，是构建安全会话管理的第一步。

IT 累计浏览 3,159

三种代理服务器的区别

这篇讲的是三种代理服务器的区别：标准代理、透明代理与反向代理。作者从它们的工作机制和应用场景出发，做了清晰的对比。标准代理需要用户主动配置浏览器，主要作用是缓存静态内容，为企业或局域网用户节省带宽。透明代理则对用户完全“透明”，无需配置，由网络设备（如路由器）在80端口直接截获HTTP流量进行缓存，这在ISP和简单局域网加速场景中很常见。而反向代理的工作重点完全不同，它面向服务器端，被架设在Web服务器前端，主要目的是缓存服务器生成的动态或静态内容，直接响应大量请求，从而显著减轻后端服务器的负载压力，提升网站整体性能。文章的亮点在于没有止步于理论对比。后半部分详细演示了如何使用Apache搭建一个反向代理服务器，以解决“如何用一台公网服务器（A）代理访问内网其他服务器（B、C）”的实际问题。内容涵盖了模块启用、VirtualHost配置等具体步骤，非常实用。总的来说，这篇既讲清了三种代理的“是什么”和“为什么”，又通过实例说明了“怎么用”，对于理解网络架构和解决服务器部署问题都有参考价值。