HTTP详解

发布于 2021-02-10  435 次阅读


一些前置知识

1.客户端与服务器

客户端:收集用户请求信息发送到服务器,等待服务器处理完成后将结果展现给客户。

服务器:接受请求,"读取“数据(从请求中读取需要的处理数据,从储存位置读取相关需要加工的数据...)、处理数据(逻辑加工),并将新的变更数据”写入“某个储存位置(例如:本地内存,缓存,数据库...),向客户端响应本此处理结果。

在我们平时通过浏览器访问百度时,客户端(浏览器)会向服务器(百度的服务器)发送一个请求。服务器接受请求后经过处理,会将你所请求的内容(页面)再向你返回。客户端(浏览器)再对服务器所返回的内容进行处理后向你呈现出来。这就是访问过程中客户端与服务器交互的过程。

2.端口:设备与外界通讯交流的出入口

在上面客户端与服务器交互的基础上,我们可以发现“访问”的过程实际上就是数据信息交换的过程,即客户端发送请求,服务端返回响应。而在这个过程中,端口就为客户端/服务器的发送/接收信息提供了一个出入口。如果把我们的PC想像成一个房子,试想没有门和窗户,我们如何同外界获取联系?所以端口的应用在网络通信当中十分重要。

3.DNS服务器、域名与IP地址

互联网通信实际上就是不同IP地址的主机之间的通信。当我们的电脑接入互联网时,运营商会给PC分配一个IP地址,而后我们通过这个IP同互联网中的其他主机发送或接受数据。服务器的本质便是一台连了网的计算机,被分配了一个固定IP地址。我们可以通过访问IP来对服务器进行数据交换。而在实际生活中我们往往只需要在浏览器的地址栏输入域名即可访问。如我们在访问百度时只需要在浏览器中输入baidu.com(域名),而不是4个8位二进制数字。访问baidu.com的实际过程是DNS会先将我们输入的域名解析到他实际的IP地址上而后在进行访问。但实际上无论我们在浏览器的地址栏输入域名或者他的真实IP都可以达到访问的目的。域名的作用只是方便人们记忆。

4.URL与URL编码

URL:统一资源定位系统(uniform resource locator)

HTTP URL的形式如下:

http(s)://<host>:<port>/<path>?<searchpart>

http:// 意为使用http协议进行数据传输

<host>: 即为你想访问的目标主机的IP或域名(还记得上面提到的两者的联系吗)

<port>: 即为你想要访问的主机的端口号,如果此处端口号省略不填,则会访问http协议下默认的80端口

<path>: 即为你想要访问的目标主机的资源路径,可以访问多级路径,中间使用‘/’分隔

<searchpart>: 即为GET请求方式向目标主机提交的参数(详细的后面会提到)

(特别的,在URL中还可以通过#来标记锚点,下次再打开页面时边会自动跳转到你上次阅读的部分)

例如:https://www.baidu.com/s?ie=UTF-8&wd=helloword

可以参考上面的对号入座。使用https协议发送GET请求访问www.baidu.com根目录下的s文件夹。并且提交的参数有两个,分别是ie=UTF-8和wd=helloword。(关于GET请求以及参数传递本文后面会提到,读者不必在此处纠结)

URL编码

浏览器会自动将地址栏中你所输入的URL中汉字和部分字符进行打包编码,目的是统一一个编码规范,防止传输过程中的编码乱码现象。有时有些场景也能起到安全的作用。

url编码就是一个字符ascii码的十六进制。不过稍微有些变动,需要在前面加上“%”。比如“\”,它的ascii码是92,92的十六进制是5c,所以“\”的url编码就是%5c。

对于一些非法字符,比如汉字,他们没有所对应的ASCII码,对于Unicode字符,RFC文档建议使用utf-8对其进行编码得到相应的字节,然后对每个字节执行百分号编码。如"中文"使用UTF-8字符集得到的字节为0xE4 0xB8 0xAD 0xE6 0x96 0x87,经过Url编码之后得到"%E4%B8%AD%E6%96%87

例如在浏览器地址栏中输入:编码,所得到的的URL将会是:https://www.baidu.com/s?ie=UTF-8&wd=%E7%BC%96%E7%A0%81

不难发现新得到的URL中的“编码”二字是经过URL编码后的


HTTP协议简介

超文本传输协议(英文:HyperText Transfer Protocol,缩写:HTTP)是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。HTTP的发展是由蒂姆·伯纳斯-李于1989年在欧洲核子研究组织(CERN)所发起。HTTP的标准制定由万维网协会(World Wide Web Consortium,W3C)和互联网工程任务组(Internet Engineering Task Force,IETF)进行协调,最终发布了一系列的RFC,其中最著名的是1999年6月公布的 RFC 2616,定义了HTTP协议中现今广泛使用的一个版本——HTTP 1.1。2014年12月,互联网工程任务组(IETF)的Hypertext Transfer Protocol Bis(httpbis)工作小组将HTTP/2标准提议递交至IESG进行讨论,于2015年2月17日被批准。 HTTP/2标准于2015年5月以RFC 7540正式发表,取代HTTP 1.1成为HTTP的实现标准。

HTTP工作过程

我们人类交流的前提是能够使用同一个约定好的语言。而上面提到的客户端发送请求,服务器返回响应也是一样的。它们之间交流的语言便是HTTP协议。HTTP协议定义Web客户端如何从Web服务器请求Web页面,以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文,请求报文包含请求的方法、URL(域名或IP)、协议版本、请求头部和请求数据。服务器以一个状态行作为响应,响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。


HTTP大致的工作流程:

1.客户端接入Web服务器

一个HTTP客户端,通常是浏览器,与Web服务器的HTTP端口(默认为80)建立一个TCP连接。

2.客户端发送HTTP请求

通过TCP,客户端向Web服务器发送一个文本的请求报文,一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

3. 服务器接受请求并返回HTTP响应

Web服务器解析请求,定位请求资源。服务器将资源复本写到TCP会话,由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。

4. 释放连接TCP连接

若connection 模式为close,则服务器主动关闭TCP连接,客户端被动关闭连接,释放TCP连接;若connection 模式为keepalive,则该连接会保持一段时间,在该时间内可以继续接收请求;

5. 客户端浏览器解析HTML内容

客户端浏览器首先解析状态行,查看表明请求是否成功的状态代码。然后解析每一个响应头,响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML,根据HTML的语法对其进行格式化,并在浏览器窗口中显示。


HTTP协议性质

请求-响应 的模式

HTTP协议规定,请求只能从客户端发出,由服务端响应并返回。即没有客户端的请求,服务器不会做出响应

无状态保存

HTTP是一种不保存状态,即无状态(stateless)协议。HTTP协议 自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个 级别,协议对于发送过的请求或响应都不做持久化处理。

特别的,无状态保存使得请求/响应模式变得更加的简洁,也使得服务器能够在短时间内处理更多的客户端请求。但是随着Web发展,许多场景下“无状态保存”也会造成诸多不便。比如我们登陆了某购物网站,在我们点进一个商品详情页面后由于协议并不会储存之前的通信状态,所以我们还需要重新进行登陆,这无疑已经与当初设计该协议时的“简洁高效”背道而驰了。截止目前HTTP/1.1版本无保存状态依旧沿用,为了适应更多的应用场景,我们引入了session与cookie的应用,使得我们在相当一段时间内仍然保留着之前的登陆凭证或访问状态。

无连接

与上一条无状态保存类似,无连接是指如果在服务器响应了客户端请求之后就会断开TCP连接,如果想再次发送请求就要重新建立连接。但是到了HTTP /1.1的版本,TCP连接会在客户端上一次的请求后的一段较短的时间内保持连接。如果在这段时间内客户端没有再次发送请求,那么就会断开本次TCP连接。


HTTP请求方法

HTTP/1.1协议中共定义了八种方法(也叫“动作”)来以不同方式操作指定的资源:

1.GET

向指定的资源发出“显示”请求。比如我们访问baidu.com时想向其发送参数a=1时,可以直接在地址栏输入baidu.com?a=1 使用GET方法应该只用在读取数据,而不应当被用于产生“副作用”的操作中,例如在Web Application中。其中一个原因是GET可能会被网络蜘蛛等随意访问。

2.HEAD

与GET方法一样,都是向服务器发出指定资源的请求。只不过服务器将不传回资源的本文部分。它的好处在于,使用这个方法可以在不必传输全部内容的情况下,就可以获取其中“关于该资源的信息”(元信息或称元数据)。

3.POST

向指定资源提交数据,请求服务器进行处理(例如提交表单或者上传文件)。与GET的显示传送不同,POST请求方式提交参数只能通过HTTP请求的数据部分提交,并不在URL中体现。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源,或二者皆有。

4.PUT

向指定资源位置上传其最新内容。

5.DELETE

请求服务器删除Request-URI所标识的资源。

6.TRACE

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

7.OPTIONS

这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用'*'来代替资源名称,向Web服务器发送OPTIONS请求,可以测试服务器功能是否正常运作。

8.CONNECT

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接(经由非加密的HTTP代理服务器)。

注意事项:

方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候,服务器应当返回状态码405(Method Not Allowed),当服务器不认识或者不支持对应的请求方法的时候,应当返回状态码501(Not Implemented)。

HTTP服务器至少应该实现GET和HEAD方法,其他方法都是可选的。当然,所有的方法支持的实现都应当匹配下述的方法各自的语义定义。此外,除了上述方法,特定的HTTP服务器还能够扩展自定义的方法。例如PATCH(由 RFC 5789 指定的方法)用于将局部修改应用到资源

在我们日常的访问当中,主要以GET、POST为主


参数传递

GET提交的数据会放在URL之后,也就是请求行里面(显式传输),以?分割URL和传输数据,参数之间以&相连,如baidu.com?a=123

POST方法是把提交的数据放在HTTP包的请求体中(隐式传输)。常见于账号密码表单的提交等。

GET提交的数据大小有限制,因为浏览器对URL的长度有限制(还记得上面讲的GET显式传输直接是通过“域名”+“?”+参数的吗),而POST方法提交的数据没有限制。(因为是通过HTTP请求体传输,而服务器对请求体的长度基本没有限制)


HTTP状态码

在我们平时浏览网页中经常见到的“404 NOT FOUND”,“403 FORBIDEN”等等。这些都是服务器对我们请求作出响应的一个状态码。

所有HTTP响应的第一行都是状态行,依次是当前HTTP版本号,3位数字组成的状态代码,以及描述状态的短语,彼此由空格分隔。

状态代码的第一个数字代表当前响应的类型:

1xx消息——请求已被服务器接收,继续处理

2xx成功——请求已成功被服务器接收、理解、并接受

3xx重定向——需要后续操作才能完成这一请求

4xx请求错误——请求含有词法错误或者无法被执行

5xx服务器错误——服务器在处理某个正确请求时发生错误

虽然 RFC 2616 中已经推荐了描述状态的短语,例如"200 OK","404 Not Found",但是WEB开发者仍然能够自行决定采用何种短语,用以显示本地化的状态描述或者自定义信息。

具体每个状态码对应的意义参考:https://baike.baidu.com/item/HTTP%E7%8A%B6%E6%80%81%E7%A0%81/5053660?fr=aladdin

HTTP请求报文

其整体结构分为三部分:请求行、请求头部、请求体(请求数据)

其中请求行包括:请求方法,URL,以及http(s)协议版本

请求头部包括了诸多信息,如浏览器的类型和版本(User-Agent),发送的参数的类型(Content-Type),客户端IP地址(Client-IP),跳转页面的信息(Referer),如果是POST请求还需要加上Content-Length等等等等。都是通过键值对的形式填写,例如:

Referer : https://www.baidu.com/

意为是从 https://www.baidu.com/跳转到该页面的。

下面演示一下使用浏览器访问www.baidu.com是发送的请求包

请求头部内的信息包括了主机的域名,浏览器的类型和版本号,编码格式,cookie等等

HTTP响应报文

响应报文由状态行,响应头部与响应正文组成。大致组成与请求报文大同小异,此处不再赘述。

其中响应正文部分为经服务器解析后的数据或未经解析的html代码。前者直接会在浏览器页面上呈现,后者则会经过浏览器解析后呈现出来。

暂时总结出来了这么多,后续想起来了再随缘更~~~~~~⁄(⁄ ⁄•⁄ω⁄•⁄ ⁄)⁄

参考来源:

https://www.cnblogs.com/an-wen/p/11180076.html

https://www.cnblogs.com/imyalost/p/6139191.html

http://www.blogjava.net/zjusuyong/articles/304788.html


业精于勤,荒于嬉;行成于思,毁于随