- 综合排序
- 最热优先
- 最新优先
- 来自专栏程序猿杂货铺
浅析一次HTTP请求
图 Http-Request 从上图我们已经看到成功抓包到一次 HTTP 请求和响应了，但是我们看到却有很多TCP请求，接下来我们来分析下这些 TCP 请求是做什么的？ 我们看到第一次请求协商的结果是WS=256,然后再 ACK 阶段扩展因子生效，调整了窗口大小。 HTTP 请求，接着序号5是对 HTTP 请求的一次接收确认，序号6是响应 HTTP 请求，序号7是对响应请求的确认。 以上就是一个 HTTP 完整的请求，整个流程用图表示如下： ? C) Keep-Alive 这里肯定有同学会问，既然这是一次完整的 HTTP 请求，那么是不是每次请求都会有三次握手吗？ 说完 Keep-Alive,我们回到最开始的问题，为啥一次 HTTP 请求会有进行两个端口的握手呢？
1.7K41发布于 2019-09-03 - 来自专栏翎野君
第一次请求
第一次请求 第二次请求 强缓存 可以理解为无须验证的缓存策略。对强缓存来说，响应头中有两个字段 Expires/Cache-Control 来表明规则。 客户端和服务器端通过某种验证机制验证当前请求资源是否可以使用缓存。 浏览器第一次请求数据之后会将数据和响应头部的缓存标识存储起来。再次请求时会带上存储的头部字段，服务器端验证是否可用。 反之返回 200 就相当于重新请求了一遍资源并替换旧资源。 第一次请求之后，浏览器记录这个时间，再次请求时，请求头部带上 If-Modified-Since 即为之前记录下的时间。 ETag与If-None-Match 由服务器端上生成的一段 hash 字符串，第一次请求时响应头带上 ETag: abcd，之后的请求中带上 If-None-Match: abcd，服务器检查 ETag
29510编辑于 2023-05-12 - 来自专栏【腾讯云开发者】
一次网络请求的顿悟之旅
我以前思考过这个问题，从最前面的浏览器到最后的 db 都梳理的一遍，触发了一次技术顿悟，将很多散落的知识点贯通起来了。 浏览器访问 qq.com 时，会先做一次域名解析，把 qq.com 这个域名解析成 IP 地址，然后才能发出 IP 包。 02、TCP、消息分包和协议设计 一次网络请求经过 DNS 解析知道了目的 IP，现在就要发出网络包了。 例如 send 了3条消息，分别是100字节、50字节、80字节，recv 时可能收到的是230字节，就是说一次 recv 收到了3条消息，需要应用逻辑自己对 recv 到的数据进行分析，得出完整的消息 能一次 recv 到多个消息，也可能一次 recv 到一个半消息或半个消息，都是有可能的，这就是流式协议的特点。有的文章讲的粘包也是这个概念。
69921编辑于 2024-08-16 - 来自专栏MongoDB中文社区
一次心跳引发的请求阻塞
导语 腾讯云某线上业务在使用MongoDB过程中，发现在低负载场景下也可能出现写请求阻塞。腾讯CMongo团队结合业务的使用场景，以及MongoDB中“心跳”和“同步源选择”等代码逻辑解决了这个问题。 但是在整体负载非常低的情况下，发现部分写入请求很大概率会出现超时，预期 100ms 内完成的请求可能耗时超过 1s。 ； 主节点更新副本集 majority 同步进度，并释放之前 hold 住的请求，给用户返回结果。 心跳如何导致写请求卡住 MongoDB 定期（默认2秒）交互一次心跳。考虑下面的情形： T0时刻，用户向副本集写入一条数据，并同步到所有节点。 所以新到达主节点的 majority 写入请求会被hold住，触发客户端超时； 副本集触发了新一轮心跳，回归正常。 解决方法 综合上面的分析，可以想到一些简单的办法来规避这个问题。
68310发布于 2020-12-14 - 来自专栏编程技术专栏
一次完整的HTTP请求过程
请求正文 请求行：用于描述客户端的请求方式（GET/POST等），请求的资源名称(URL)以及使用的HTTP协议的版本号 请求头：用于描述客户端请求哪台主机及其端口，以及客户端的一些环境信息等 空行：空行就是 name=XXG&age=23的GET 请求时发送给服务器的数据： [图2] 可以看出请求包含请求行和请求头两部分。 ：请求行、请求头、空格、消息体，比之前的 GET 请求多了一个请求消息，其中 请求头和消息体之间用一个空行分割。 ），这是时候就用上 keep-alive特性了，建立一次HTTP连接，可以请求多个资源，下载资源的顺序就是按照代码里面的顺序，但是由于每个资源大小不一样，而浏览器又是多线程请求请求资源，所以这里显示的顺序并不一定是代码里面的顺序 保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。 自此一次完整的HTTP事务宣告完成.
9.4K31发布于 2019-09-09 - 来自专栏代码宇宙
一次请求 SpringMVC 到底做了什么？
0x0 先看名词 DispactherServlet：SpringMVC 的心脏，所有的请求从这里进入，也从这里出去 HandlerAdapter：请求处理器 HandlerMapping:请求和处理对象间的映射关系 ，可以理解为 地址 /api 对应 @RequestMapping("/api") doDispatch： SpringMVC 处理请求的方法 ModelAndView：视图响应对象，例如我们Controller SpringMVC 支持多视图解析器的重要组件，官方说明：https://spring.io/blog/2013/06/03/content-negotiation-using-views 0x1 一个请求过来 请求进入 DispactherServlet 会被分配给 doDispatch ，所以直接断点 doDispatch 即可 0x01 请求处理器 doDispatch 会匹配相应的 HandlerMapping ModelAndView 中的属性全部传递给 FreeMarker 最后一步生成 Html 并响应到浏览器 0x2 静态资源处理 SpringMVC 在视图处理器如果找不到合适的处理器的情况下，就会视该请求为静态资源请求并使用静态资源解析器解析该请求
33020编辑于 2023-02-23 - 来自专栏deepcc
ajax 请求中多出现一次OPTIONS请求及其解决办法
/plain中的一种）和复杂请求。 而复杂请求发出之前，就会出现一次options请求。 什么是options请求呢？ 它是一种探测性的请求，通过这个方法，客户端可以在采取具体资源请求之前，决定对该资源采取何种必要措施，或者了解服务器的性能。 在ajax中出现options请求，也是一种提前探测的情况，ajax跨域请求时，如果请求的是json，就属于复杂请求，因此需要提前发出一次options请求，用以检查请求是否是可靠安全的，如果options 因此，靠javascript客户端取消options请求是不可能的，只能通过服务端对options请求做出正确的回应，这样才能保证options请求之后，post、put等请求可以被发出。
2.3K40发布于 2018-05-25 - 来自专栏thinkphp+vue
PHP一次请求的生命周期
每一次请求都是循环往复，所以有些繁琐，这是后面为什么会诞生fastcgi的原因。 3.2.fastcgi自动初始化，创建fastcgi主进程和多个cgi解析器进程，等待来着web服务器的请求(只初始化一次，还有个好处，数据库可以持续化连接)。 当给定的SAPI启动时，PHP进入初始化内核子系统，主要对PHP框架，zend引擎的初始化操作，这个阶段一般是在SAPI启动时执行一次。 worder 进程的生命周期如下图： ---- 第二阶段：请求初始化阶段 当一个请求发生时，在处理请求前需要经历的一个阶段 : Nginx 解析一个请求 当符合php脚本请求的规则的时候，会把这个请求交给反向代理中的 worker进程关闭该请求连接，继续等待 accept下一个请求。
1.2K30发布于 2021-04-30 - 来自专栏PT运维技术
一次HTTPS请求缓慢的原因定位
发现有的可以打开，有的无法打开，有的第一次打开很慢，第二次打开很快。 https://www.163.com 4.通过v**访问外部第三方站点: https://v.qq.com,https://api-nusdk.service.boltrend.com/ , 第一次缓慢 路由黑洞，163的服务器协议栈实现了RFC1191 4.通过v**访问外部第三方https://v.qq.com, https://api-nusdk.service.boltrend.com/ , 第一次缓慢 icmp(code=3,type=4)（但可能会由于QOS策略，例如限速导致丢弃ICMP) ，PMTU可以正常完成TCP MSS自适应(需要消耗一定的时间), 站点涉及到多台服务器，每个服务器都需要来一次这个过程 ，第一次会慢， 但centos6/centos7 有MTU的路由缓存(内核于3.6废弃route cache，centos6/centos7的内核<3.6, 缓存时间由NET_IPV4_ROUTE_GC_TIMEOUT
2.3K20编辑于 2022-06-14 - 来自专栏测试开发技术
一次 HTTP 请求到底经历了什么？
我们看到第一次请求协商的结果是 WS=256,然后再 ACK 阶段扩展因子生效，调整了窗口大小。 HTTP 请求，接着 序号5是对 HTTP 请求的一次接收确认， 序号6是响应 HTTP 请求， 序号7是对响应请求的确认。 客户端确认服务端断开请求，进入 TIME-WAIT 状态 我们发现上面的 流程2和 流程3都是由服务端发起的，那么有没有可能合并这两个请求，一次发送给客户端？答案是 可以。 以上就是一个 HTTP 完整的请求，整个流程用图表示如下： C) Keep-Alive 这里肯定有同学会问，既然这是一次完整的 HTTP 请求，那么是不是每次请求都会有三次握手吗？ 说完 Keep-Alive,我们回到最开始的问题，为啥一次 HTTP 请求会有进行两个端口的握手呢？
31121编辑于 2025-12-25 - 来自专栏vivo互联网技术
层层剖析一次 HTTP POST 请求事故
HTTP请求一般经过3个关卡，分别为DNS、Nginx、Web服务器，具体流程如下图： 浏览器发送请求首先到达当地运营商DNS服务器，经过域名解析获取请求 IP 地址 浏览器获取 IP 地址后，发送 JSONP 是将请求序列化成一个string，然后发起一个JS请求，带上string。此做法需要后台支持，并且只能使用GET请求。在当前的业内已经废除此方案。 HTTP请求的相关字段被设置后，则会正常发起请求，后台则通过对这些字段的校验，决定此请求是否是合理的跨域请求。 浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。 因此，实现CORS通信的关键是服务器(服务器端可判断，让哪些域可以请求)。 整体流程如下： 不合理的跨域请求，我们一般认为是侵略性请求，这一类的请求，我们视为XSS攻击。那么广义而言的XSS攻击又是什么呢？
1.5K10编辑于 2022-05-17 - 来自专栏deepcc
jquery ajax 请求中多出现一次OPTIONS请求及其解决办法
ajax的跨域请求问题，但是，在这个过程中，我们会发现，在很多post,put,delete等请求之前，会有一次options请求。 而复杂请求发出之前，就会出现一次options请求。 什么是options请求呢？ 它是一种探测性的请求，通过这个方法，客户端可以在采取具体资源请求之前，决定对该资源采取何种必要措施，或者了解服务器的性能。 在ajax中出现options请求，也是一种提前探测的情况，ajax跨域请求时，如果请求的是json，就属于复杂请求，因此需要提前发出一次options请求，用以检查请求是否是可靠安全的，如果options 因此，靠javascript客户端取消options请求是不可能的，只能通过服务端对options请求做出正确的回应，这样才能保证options请求之后，post、put等请求可以被发出。
1.4K10发布于 2018-07-05 - 来自专栏复盘总结文章集合
解析一次完整的HTTP请求与响应
通过以上步骤我们从TCP/IP模型的角度来理解了一次HTTP请求与响应的过程。 下面这张图更清楚明白： ? 下面具体来看如何进行一步步操作的。 第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认； 第二次握手：服务器收到SYN报文段。 四个基于： 请求与响应：客户端发送请求，服务器端响应数据 无状态的：协议对于事务处理没有记忆能力，客户端第一次与服务器建立连接发送请求时需要进行一系列的安全认证匹配等，因此增加页面等待时间，当客户端向服务器端发送请求 下一次客户端向同样的服务器发送请求时，由于他们之前已经遗忘了彼此，所以需要重新建立连接。 应用层：Http是属于应用层的协议，配合TCP/IP使用。 针对无状态的一些解决策略： 有时需要对用户之前的HTTP通信状态进行保存，比如执行一次登陆操作，在30分钟内所有的请求都不需要再次登陆。于是引入了Cookie技术。
2K40发布于 2019-05-28 - 来自专栏芋道源码1024
完整的一次 HTTP 请求响应过程（一）
那是因为 2MSL 是一份报文存在于网络中最长的时间，超过该时间到达的报文都将被丢弃，而如果客户端最后的确认报文于网络中丢失的话，服务端必将发起超时请求，重新发送第三次挥手动作，此时等待中的客户端就可随即重新发送一份确认请求 有人可能好奇为什么前面的各次请求都没有做超时等待而只最后一次数据发送做了超时等待？ 通过等待一个最长周期，如果这个周期内没有收到服务端的报文请求，那么我们的确认报文必然是到达了服务端了的，否则重复发送一次即可。 慢启动的思想是，刚开始缓慢的发送，比如某个时间段内只发送一次数据报，当收到确认报文后，下一次同样的时间间隔内，将发送两倍速率的两份数据报，并以此类推。 拥塞避免的思想是，每个往返时间段发送的所有数据报全部得到确认后，下一次就增加一个分组的发送，这样缓慢的增长效率是谨慎的。
73220发布于 2019-10-29 - 来自专栏吃猫的鱼个人博客编程笔记
记录一次网站被刷请求次数统计
前言 今天突然收到多吉云的通知，说请求数激增，我的个人生活博客，https://my.404.pub两个小时内cdn请求数量达到两百多万次： 着实离谱，怕不是又惹了何方神圣。 看到后我赶紧上多吉云后台登录，做了一下补救，好在流量并没有消耗很多，只是请求数被刷了两百多万次。 于是赶紧去限制了一下请求的访问限制，防止被一直刷请求次数。 但是，单单这样限制也是会被一直消耗请求次数，不能从根本上解决问题，于是我等时间到了后，去下载了多吉云的日志文件，打算统计一下刷的ip地址然后将它们屏蔽掉。 然后直接开始编写代码，大概思路是通过读取文件内容，统计提取出每个ip出现的次数，然后用降序的方式写入新的result.txt文件，便于我查看哪些ip是频繁发起请求的。 这些都是些高频访问的ip，我会去查一下它们地址，发现都是海外请求，果断直接给屏蔽了。
48950编辑于 2023-10-03 - 来自专栏专注 Java 基础分享
完整的一次 HTTP 请求响应过程（二）
而完整的 DHCP 请求与响应的过程则是这样的： 第一步： DHCP 服务器发现。 第三步： DHCP 请求。这其实是一个选择阶段，客户端主机确认服务器推荐的参数，决定使用，于是依然以广播的形式发送请求向服务器确认。 第四步： DHCP ACK。 这一点算是 DHCP 协议的一个约定了，当某台主机第一次加入某个子网络，它将从 DHCP 服务器获取一个全新的 IP 地址。 OSPF 是基于链路状态路由选择算法进行实现的，所以它也是一个全局性路由选择算法，算法运行一次即可完成全网的路由信息更新。 假设现在我们的路由器 A 运行 OSPF 协议： 第一次迭代完成后，它得到与 B、E 两台路由器相关的子网络的路径计算。
1.1K00发布于 2018-07-31 - 来自专栏咻一咻
一次完整的http请求处理过程
Web服务请求处理步骤 ? 一次完整的http请求处理过程 1、建立连接：接收或拒绝连接请求 2、接收请求：接收客户端请求报文中对某资源的一次请求的过程 3、处理请求：服务器对请求报文进行解析，并获取请求的资源及请求方法等相关信息 HEAD、PUT、DELETE、TRACE、OPTIONS 4、访问资源：服务器获取请求报文中请求的资源web服务器，即存放了web资源的服务器，负责向请求者提供对方请求的静态资源，或动态运行后生成的资源 ，而且一次只处理一个，多个请求被串行响应 多进程I/O模型：并行启动多个进程,每个进程响应一个连接请求 复用I/O结构：启动一个进程，同时响应N个连接请求实现方法：多线程模型和事件驱动多线程模型： 一个进程生成N个线程，每线程响应一个连接请求事件驱动：一个进程处理N个请求 复用的多进程I/O模型：启动M个进程，每个进程响应N个连接请求，同时接收M*N个请求 ?
75330发布于 2020-05-29 - 来自专栏芋道源码1024
完整的一次 HTTP 请求响应过程（二）
而完整的 DHCP 请求与响应的过程则是这样的： 第一步： DHCP 服务器发现。 第三步： DHCP 请求。这其实是一个选择阶段，客户端主机确认服务器推荐的参数，决定使用，于是依然以广播的形式发送请求向服务器确认。 第四步： DHCP ACK。 这一点算是 DHCP 协议的一个约定了，当某台主机第一次加入某个子网络，它将从 DHCP 服务器获取一个全新的 IP 地址。 image OSPF 是基于链路状态路由选择算法进行实现的，所以它也是一个全局性路由选择算法，算法运行一次即可完成全网的路由信息更新。 假设现在我们的路由器 A 运行 OSPF 协议： 第一次迭代完成后，它得到与 B、E 两台路由器相关的子网络的路径计算。
73920发布于 2019-10-29 - 来自专栏专注 Java 基础分享
完整的一次 HTTP 请求响应过程（一）
那是因为 2MSL 是一份报文存在于网络中最长的时间，超过该时间到达的报文都将被丢弃，而如果客户端最后的确认报文于网络中丢失的话，服务端必将发起超时请求，重新发送第三次挥手动作，此时等待中的客户端就可随即重新发送一份确认请求 有人可能好奇为什么前面的各次请求都没有做超时等待而只最后一次数据发送做了超时等待？ 通过等待一个最长周期，如果这个周期内没有收到服务端的报文请求，那么我们的确认报文必然是到达了服务端了的，否则重复发送一次即可。 慢启动的思想是，刚开始缓慢的发送，比如某个时间段内只发送一次数据报，当收到确认报文后，下一次同样的时间间隔内，将发送两倍速率的两份数据报，并以此类推。 拥塞避免的思想是，每个往返时间段发送的所有数据报全部得到确认后，下一次就增加一个分组的发送，这样缓慢的增长效率是谨慎的。
1.2K00发布于 2018-07-31 - 来自专栏Java架构师必看
一次HTTP请求中的缓存「建议收藏」
一个HTTP Request从用户点击的一瞬间,到服务器返回请求,一般会经过以下类型的缓存 (按照由客户端到服务器端的顺序) 1.浏览器端存储: HTML5中的本地存储功能允许在浏览器端保存数据. JavaScript保存一些数据在当前Context也算这种类型. 2.浏览器端文件缓存 HTTP协议中在时间未过期等情况下,不请求服务器数据而直接使用本地的文件 (请参考HTTP协议中关于缓存控制的部分 ) 常用于html JavaScript css等文件的缓存,以减少请求次数 3.HTTP缓存304: HTTP协议中,如果服务器文件未发生变化,不返回用户请求的数据,而只是返回一个304响应 (更多内容请参考 HTTP协议) 不减少请求数量,但是减少了响应的体积 通过控制动态文件的输出内容实现缓存(可以了解一下 Etag 等相关内容) 4.服务器端文件类型缓存 动态页面静态化为html文件; 代理服务器, CDN 之类的解决方案是对较大规模的网站必用的 数据库缓存是一个比较难以控制的范畴,(相比来说 优化索引和数据库设计更为有效) 同时推荐几个Tool Fiddler HttpWatch 用来跟踪http请求的细节
77620编辑于 2022-03-14
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号