http请求过程(访问一个页面,发生了怎样的网络请求?)

Host: www.baidu.com

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.84 Safari/537.36

再继续往下看可以看到有一个

Response Headers 和一个 Request Headers,这分别代表响应头和请求头,

请求头里面带有许多请求信息,例如浏览器标识、Cookies、Host 等信息,这是Request 的一部分,服务器会根据请求头内的信息判断请求是否合法,进而作出对应的响应,返回Response,那么在图中看到的 Response Headers 就是 Response 的一部分,例如其中包含了服务器的类型、文档类型、日期等信息,浏览器接受到 Response 后,会解析响应内容,进而呈现网页内容。

详细解释往下看

5. 请求 Request 和响应 Response 都包含了哪些内容?

(1) Request

Request,即请求,由客户端向服务端发出。

可以将 Request 划分为四部分内容:

Request Method、Request URL、Request Headers、Request Body,

即请求方式、请求链接、请求头、请求体。

Request Method

请求方式,请求方式常见的有两种类型,GET 和 POST。

GET 请求: 浏览器中直接输入一个 URL 并回车,这便发起了一个 GET 请求

POST 请求: 表单提交

我们在浏览器中直接输入一个 URL 并回车,这便发起了一个 GET 请求,请求的参数会直接包含到 URL 里,例如百度搜索Python,这就是一个 GET 请求,链接为:https://www.baidu.com/s?wd=Python,URL中包含了请求的参数信息,这里参数 wd 就是要搜寻的关键字。

POST 请求大多为表单提交发起,如一个登录表单,输入用户名密码,点击登录按钮,这通常会发起一个 POST 请求,其数据通常以 Form Data,即表单的形式传输,不会体现在 URL 中。

GET 和 POST 请求方法有如下区别:

GET 方式请求中参数是包含在 URL 里面的,数据可以在 URL 中看到,而 POST 请求的 URL 不会包含这些数据,数据都是通过表单的形式传输,会包含在 Request Body 中

纠正: GET 方式请求提交的数据最多只有 1024 字节,而 POST 方式没有限制。

Http Get方法提交的数据大小长度并没有限制,HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制

理论上讲,POST是没有大小限制的。HTTP协议规范也没有进行大小限制,起限制作用的是服务器的处理程序的处理能力

如:IE对URL长度的限制是2083字节(2K+35)。

下面就是对各种浏览器和服务器的最大处理能力做一些说明.

Microsoft Internet Explorer (Browser)

IE浏览器对URL的最大限制为2083个字符,如果超过这个数字,提交按钮没有任何反应。

Firefox (Browser)

对于Firefox浏览器URL的长度限制为65,536个字符。

Safari (Browser)

URL最大长度限制为 80,000个字符。

Opera (Browser)

URL最大长度限制为190,000个字符。

Google (chrome)

URL最大长度限制为8182个字符。

Apache (Server)

能接受最大url长度为8,192个字符。

Microsoft Internet Information Server(IIS)

能接受最大url的长度为16,384个字符。

通过上面的数据可知,为了让所有的用户都能正常浏览, URL最好不要超过IE的最大长度限制(2083个字符),当然,如果URL不直接提供给用户,而是提供给程序调用,这时的长度就只受Web服务器影响了。

注:对于中文的传递,最终会为urlencode后的编码形式进行传递,如果浏览器的编码为UTF8的话,一个汉字最终编码后的字符长度为9个字符。

因此如果使用的 GET 方法,最大长度等于URL最大长度减去实际路径中的字符数。

误区:

1、首先即使有长度限制,也是限制的是整个 URI 长度,而不仅仅是你的参数值数据长度。

2、HTTP 协议从未规定 GET/POST 的请求长度限制是多少。

3、所谓的请求长度限制是由浏览器和 web 服务器决定和设置的,各种浏览器和 web 服务器的设定均不一样,这依赖于各个浏览器厂家的规定或者可以根据 web 服务器的处理能力来设定。

所以一般来说,

网站登录验证的时候,需要提交用户名密码,这里包含了敏感信息,使用GET方式请求的话密码就会暴露在URL里面,造成密码泄露,所以这里最好以POST方式发送。

文件的上传时,由于文件内容比较大,也会选用POST方式。

1、多数浏览器对于POST采用两阶段发送数据的,先发送请求头,再发送请求体,即使参数再少再短,也会被分成两个步骤来发送(相对于GET),也就是第一步发送header数据,第二步再发送body部分。HTTP是应用层的协议,而在传输层有些情况TCP会出现两次连结的过程,HTTP协议本身不保存状态信息,一次请求一次响应。对于TCP而言,通信次数越多反而靠性越低,能在一次连结中传输完需要的消息是最可靠的,尽量使用GET请求来减少网络耗时。如果通信时间增加,这段时间客户端与服务器端一直保持连接状态,在服务器侧负载可能会增加,可靠性会下降。

2、GET请求能够被cache,GET请求能够被保存在浏览器的浏览历史里面(密码等重要数据GET提交,别人查看历史记录,就可以直接看到这些私密数据)POST不进行缓存。

3、GET参数是带在URL后面,传统IE中URL的最大可用长度为2048字符,其他浏览器对URL长度限制实现上有所不同。POST请求无长度限制(目前理论上是这样的)。

4、GET提交的数据大小,不同浏览器的限制不同,一般在2k-8K之间,POST提交数据比较大,大小靠服务器的设定值限制,而且某些数据只能用 POST 方法「携带」,比如 file。

5、全部用POST不是十分合理,最好先把请求按功能和场景分下类,对数据请求频繁,数据不敏感且数据量在普通浏览器最小限定的2k范围内,这样的情况使用GET。其他地方使用POST。

6、GET 的本质是「得」,而 POST 的本质是「给」。而且,GET 是「幂等」的,在这一点上,GET 被认为是「安全的」。但实际上 server 端也可以用作资源更新,但是这种用法违反了约定,容易造成 CSRF(跨站请求伪造)。

REF:

maximum length of HTTP GET request?

http://stackoverflow.com/questions/2659952/maximum-length-of-http-get-request

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.15 Request-URI Too Long

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1 General Syntax

http://www.cnblogs.com/xiaotaomaomao/articles/986070.html

http://www.cnblogs.com/TankXiao/archive/2012/02/13/2342672.html HTTP协议详解

post方式相比get安全,携带数据更大,我准备所有数据都用post方式获取,这样好吗?

http://segmentfault.com/q/1010000000213082

http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html 浅谈CSRF攻击方式

参考原文: https://blog.csdn.net/a460550542/article/details/72511343

=======================================================================

我们平常遇到的绝大部分请求都是 GET 或 POST 请求,另外还有一些请求方式,如 HEAD、PUT、DELETE、OPTIONS、CONNECT、TRACE,我们简单将其总结如下:

方法描述 GET请求指定的页面信息,并返回实体主体。

HEAD类似于 GET 请求,只不过返回的响应中没有具体的内容,用于获取报头。

POST向指定资源提交数据进行处理请求,数据被包含在请求体中。

PUT从客户端向服务器传送的数据取代指定的文档的内容。

DELETE请求服务器删除指定的页面。

CONNECTHTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。

OPTIONS允许客户端查看服务器的性能。

TRACE回显服务器收到的请求,主要用于测试或诊断。

本表参考:http://www.runoob.com/http/http-methods.html。

Request Headers

请求头,用来说明服务器要使用的附加信息,比较重要的信息有 Cookie、Referer、User-Agent等,下面将一些常用的头信息说明如下:

Accept,请求报头域,用于指定客户端可接受哪些类型的信息。

Accept-Language,指定客户端可接受的语言类型。

Accept-Encoding,指定客户端可接受的内容编码。

Host,用于指定请求资源的主机 IP 和端口号,其内容为请求 URL 的原始服务器或网关的位置。从 HTTP 1.1 版本开始,Request 必须包含此内容。

Cookie,也常用复数形式 Cookies,是网站为了辨别用户进行 Session 跟踪而储存在用户本地的数据。Cookies 的主要功能就是维持当前访问会话,例如我们输入用户名密码登录了某个网站,登录成功之后服务器会用 Session 保存我们的登录状态信息,后面我们每次刷新或请求该站点的其他页面时会发现都是保持着登录状态的,在这里就是 Cookies 的功劳,Cookies 里有信息标识了我们所对应的服务器的 Session 会话,每次浏览器在请求该站点的页面时都会在请求头中加上 Cookies 并将其发送给服务器,服务器通过 Cookies 识别出是我们自己,并且查出当前状态是登录的状态,所以返回的结果就是登录之后才能看到的网页内容。

Referer,此内容用来标识这个请求是从哪个页面发过来的,服务器可以拿到这一信息并做相应的处理,如做来源统计、做防盗链处理等。

User-Agent,简称 UA,它是一个特殊字符串头,使得服务器能够识别客户使用的操作系统及版本、浏览器及版本等信息。在做爬虫时加上此信息可以伪装为浏览器,如果不加很可能会被识别出为爬虫。

Content-Type,即 Internet Media Type,互联网媒体类型,也叫做 MIME 类型,在 HTTP 协议消息头中,使用它来表示具体请求中的媒体类型信息。例如 text/html 代表 HTML 格式,image/gif 代表 GIF 图片,application/json 代表 Json 类型,

更多对应关系可以查看此对照表:http://tool.oschina.net/commons。

Request Body

即请求体,一般承载的内容是 POST 请求中的 Form Data,即表单数据,而对于 GET 请求 Request Body 则为空。


(2)Response

Response,即响应,由服务端返回给客户端。

Response 可以划分为三部分,Response Status Code、Response Headers、Response Body。

Response Status Code

响应状态码,此状态码表示了服务器的响应状态,

200 则代表服务器正常响应,

404 则代表页面未找到,

500 则代表服务器内部发生错误。

Response Headers

响应头,其中包含了服务器对请求的应答信息,如 Content-Type、Server、Set-Cookie 等,下面将一些常用的头信息说明如下:

Date,标识 Response 产生的时间。

Last-Modified,指定资源的最后修改时间。

Content-Encoding,指定 Response 内容的编码。

Server,包含了服务器的信息,名称,版本号等。

Content-Type,文档类型,指定了返回的数据类型是什么,如text/html 则代表返回 HTML 文档,application/x-javascript 则代表返回 JavaScript 文件,image/jpeg 则代表返回了图片。

Set-Cookie,设置Cookie,Response Headers 中的 Set-Cookie即告诉浏览器需要将此内容放在 Cookies 中,下次请求携带 Cookies 请求。

Expires,指定 Response 的过期时间,使用它可以控制代理服务器或浏览器将内容更新到缓存中,如果再次访问时,直接从缓存中加载,降低服务器负载,缩短加载时间。

Resposne Body

即响应体,最重要的当属响应体内容了,响应的正文数据都是在响应体中,如请求一个网页,它的响应体就是网页的 HTML 代码,请求一张图片,它的响应体就是图片的二进制数据。所以最主要的数据都包含在响应体中了

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数前端工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Web前端开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上前端开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:前端)

最后

资料过多,篇幅有限,需要文中全部资料可以点击这里获取前端面试资料PDF完整版!

自古成功在尝试。不尝试永远都不会成功。勇敢的尝试是成功的一半。

mg-L7MLLnc3-1712419808122)]

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:前端)

最后

[外链图片转存中…(img-MBtpDAn9-1712419808122)]

[外链图片转存中…(img-z5OrRxX8-1712419808122)]

资料过多,篇幅有限,需要文中全部资料可以点击这里获取前端面试资料PDF完整版!

自古成功在尝试。不尝试永远都不会成功。勇敢的尝试是成功的一半。

  • 13
    点赞
  • 22
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值