首页
Javascript
Html
Css
Node.js
Electron
移动开发
小程序
工具类
服务端

浏览器相关

前端收藏
其他
关于

http请求的完整过程

2018年10月13日 转载自 cnblogs 阅读(323)

关于网络的知识平时可能真正用的比较少,但是有一些点还是需要总结的:

完成一次http请求要大致可以分为7个步骤:

一、TCP三次握手

第一次握手:建立连接。客户端发送连接请求报文段,将SYN位置为1,Sequence Number为x;然后,客户端进入SYN_SEND状态,等待服务器的确认;

第二次握手:服务器收到SYN报文段。服务器收到客户端的SYN报文段,需要对这个SYN报文段进行确认,设置Acknowledgment Number为x+1(Sequence Number+1);同时,自己自己还要发送SYN请求信息,将SYN位置为1,Sequence Number为y;服务器端将上述所有信息放到一个报文段(即SYN+ACK报文段)中,一并发送给客户端,此时服务器进入SYN_RECV状态;

第三次握手:客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1,向服务器发送ACK报文段,这个报文段发送完毕以后,客户端和服务器端都进入ESTABLISHED状态,完成TCP三次握手。

为什么要三次握手

为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。

具体例子:“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。”

二~三、HTTP请求报文

一个HTTP请求报文由请求行(request line)、请求头部(header)、空行和请求数据4个部分组成,下图给出了请求报文的一般格式。

1.请求行

请求行分为三个部分:请求方法、请求地址和协议版本

请求方法

HTTP/1.1 定义的请求方法有8种:GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。

最常的两种GET和POST,如果是RESTful接口的话一般会用到GET、POST、DELETE、PUT。

请求地址

URL:统一资源定位符,是一种自愿位置的抽象唯一识别方法。

组成:<协议>://<主机>:<端口>/<路径>

端口和路径有时可以省略(HTTP默认端口号是80)

如下例:

有时会带参数,GET请求

协议版本

协议版本的格式为:HTTP/主版本号.次版本号,常用的有HTTP/1.0和HTTP/1.1

2.请求头部

请求头部为请求报文添加了一些附加信息,由“名/值”对组成,每行一对,名和值之间使用冒号分隔。

常见请求头如下:

请求头部的最后会有一个空行,表示请求头部结束,接下来为请求数据,这一行非常重要,必不可少。

3.请求数据

可选部分,比如GET请求就没有请求数据。

下面是一个POST方法的请求报文:

  1. POST  /index.php HTTP/1.1    请求行
  2. Host: localhost
  3. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2  请求头
  4. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
  5. Accept-Language: zh-cn,zh;q=0.5
  6. Accept-Encoding: gzip, deflate
  7. Connection: keep-alive
  8. Referer: http://localhost/
  9. Content-Length25
  10. Content-Typeapplication/x-www-form-urlencoded
  11. username=aa&password=1234  请求数据

四~六、HTTP响应报文

HTTP响应报文主要由状态行、响应头部、空行以及响应数据组成。

1.状态行

由3部分组成,分别为:协议版本,状态码,状态码描述。

其中协议版本与请求报文一致,状态码描述是对状态码的简单描述,所以这里就只介绍状态码。

状态码

状态代码为3位数字。
1xx:指示信息--表示请求已接收,继续处理。
2xx:成功--表示请求已被成功接收、理解、接受。
3xx:重定向--要完成请求必须进行更进一步的操作。
4xx:客户端错误--请求有语法错误或请求无法实现。
5xx:服务器端错误--服务器未能实现合法的请求。

下面列举几个常见的:

2.响应头部

与请求头部类似,为响应报文添加了一些附加信息

常见响应头部如下:

3.响应数据

用于存放需要返回给客户端的数据信息。

下面是一个响应报文的实例:

  1. HTTP/1.1 200 OK  状态行
  2. Date: Sun, 17 Mar 2013 08:12:54 GMT  响应头部
  3. Server: Apache/2.2.8 (Win32) PHP/5.2.5
  4. X-Powered-By: PHP/5.2.5
  5. Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/
  6. Expires: Thu, 19 Nov 1981 08:52:00 GMT
  7. Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
  8. Pragma: no-cache
  9. Content-Length: 4393
  10. Keep-Alive: timeout=5, max=100
  11. Connection: Keep-Alive
  12. Content-Type: text/html; charset=utf-8
  13. <html>  响应数据
  14. <head>
  15. <title>HTTP响应示例<title>
  16. </head>
  17. <body>
  18. Hello HTTP!
  19. </body>
  20. </html>

关于请求头部和响应头部的知识点很多,这里只是简单介绍。

通过以上步骤,数据已经传递完毕,HTTP/1.1会维持持久连接,但持续一段时间总会有关闭连接的时候,这时候据需要断开TCP连接。

七、TCP四次挥手

当客户端和服务器通过三次握手建立了TCP连接以后,当数据传送完毕,肯定是要断开TCP连接的啊。那对于TCP的断开连接,这里就有了神秘的“四次分手”。

第一次分手:主机1(可以使客户端,也可以是服务器端),设置Sequence Number,向主机2发送一个FIN报文段;此时,主机1进入FIN_WAIT_1状态;这表示主机1没有数据要发送给主机2了;

第二次分手:主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,Acknowledgment Number为Sequence Number加1;主机1进入FIN_WAIT_2状态;主机2告诉主机1,我“同意”你的关闭请求;

第三次分手:主机2向主机1发送FIN报文段,请求关闭连接,同时主机2进入LAST_ACK状态;

第四次分手:主机1收到主机2发送的FIN报文段,向主机2发送ACK报文段,然后主机1进入TIME_WAIT状态;主机2收到主机1的ACK报文段以后,就关闭连接;此时,主机1等待2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,主机1也可以关闭连接了。

为什么要四次分手

TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式,这就意味着,当主机1发出FIN报文段时,只是表示主机1已经没有数据要发送了,主机1告诉主机2,它的数据已经全部发送完毕了;但是,这个时候主机1还是可以接受来自主机2的数据;当主机2返回ACK报文段时,表示它已经知道主机1没有数据发送了,但是主机2还是可以发送数据到主机1的;当主机2也发送了FIN报文段时,这个时候就表示主机2也没有数据要发送了,就会告诉主机1,我也没有数据要发送了,之后彼此就会愉快的中断这次TCP连接。

© 本文著作权归原作者所有 来源:cnblogs 阅读原文
  • Cookie 的 SameSite 属性

    Chrome 51 开始,浏览器的 Cookie 新增加了一个`SameSite`属性,用来防止 CSRF 攻击和用户追踪。

    发布:2020-04-21 阅读(409)

  • serviceworker运用与实践

    本文首先会简单介绍下前端的常见缓存方式,再引入serviceworker的概念,针对其原理和如何运用进行介绍。然后基于google推出的第三方库workbox,在产品中进行运用实践,并对其原理进行简要剖析。

    发布:2020-04-14 阅读(355)

  • 深入理解浏览器的缓存机制

    缓存可以说是性能优化中简单高效的一种优化方式了。一个优秀的缓存策略可以缩短网页请求资源的距离,减少延迟,并且由于缓存文件可以重复利用,还可以减少带宽,降低网络负荷。 对于一个数据请求来说,可以分为发起网络请求、后端处理、浏览器响应三个步骤。浏览器缓存可以帮助我们在第一和第三步骤中优化性能。比如说直接使用缓存而不发起请求,或者发起了请求但后端存储的数据和前端一致,那么就没有必要再将数据回传回来,这样就减少了响应数据。

    发布:2019-10-31 阅读(349)

  • TCP慢启动,拥塞控制,ECN 笔记

    TCP在连接过程的三次握手完成后,开始传数据,并不是一开始向网络通道中发送大量的数据包,这样很容易导致网络中路由器缓存空间耗尽,从而发生拥塞;而是根据初始的cwnd大小逐步增加发送的数据量,cwnd初始化为1个最大报文段(MSS)大小(**这个值可配置不一定是1个MSS**);每当有一个报文段被确认,cwnd大小指数增长。

    发布:2019-10-12 阅读(321)

  • 成为高手前必懂的TCP干货

    我们在平时的开发过程中,或多或少都会涉猎到网络传输这块。 这篇文章,主要是整理一下 TCP 的一些知识要点,作为一名开发者来说,尽管有那么多的基础设施(框架、组件)帮我们屏蔽了这些细节。当我仍然认为了解它的一些基本原理必有些裨益,尤其是当你在分布式环境上遇到一些棘手问题时,一些原理性的知识可能会让你快速找到答案。

    发布:2019-05-29 阅读(873)

  • Web 性能优化:Preload,Prefetch的使用及在 Chrome 中的优先级

    发布:2019-05-23 阅读(482)

  • 使用WebP图像格式的完整指南

    WebP,或非正式发音为 weppy ,是 Google开发者大约5年前推出的 一种图像格式 。

    发布:2019-02-28 阅读(2091)

  • Life of a Pixel,让你更透彻知道浏览器是如何工作

    感谢Google巢鹏的提供的内容分享。Life of a Pixel这个演讲一开始是Chrome组新人入职的学习资料,给新人一个从高层次去看Chromium如何从HTML / CSS / JS 显示到屏幕的网页。这个演讲一直在更新,所以大家可以通过看这个演讲更新自己对Chromium的理解。

    发布:2018-12-06 来源:mp.weixin.qq.com

  • chrome浏览器忽略证书报错

    本地测试时,简易忽略chrome浏览器的证书问题

    发布:2018-11-13 阅读(1359)

  • http请求的完整过程

    http请求的完整过程

    发布:2018-10-13 阅读(323)

  • IE6/7浏览器兼容querySelectorAll、 querySelector

    IE6/7浏览器兼容querySelectorAll、 querySelector

    发布:2016-05-28 阅读(1026)

  • 关于Preload, 你应该知道些什么?

    preload作为一个新的web标准,旨在提高性能和为web开发人员提供更细粒度的加载控制。Preload使开发者能够自定义资源的加载逻辑,且无需忍受基于脚本的资源加载器带来的性能损失。

    发布:2016-05-23 阅读(376)

  • 网站前后端性能优化的34条经验方法

    网站前后端性能优化的34条经验方法

    发布:2014-08-22 阅读(822)

  • [WEB安全]什么是XSRF?如何防范XSRF攻击!

    CSRF(Cross-site request forgery跨站请求伪造,也被称成为“one click attack”或者session riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS),但它与XSS非常不同,并且攻击方式几乎相 左。XSS利用站点内的信任用户,而XSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比,XSRF攻击往往不大流行(因此对其 进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性

    发布:2013-04-11 阅读(799)

  • http常用状态码

    http常用状态码

    发布:2013-02-15 阅读(864)