图文并茂!深入了解HTTP,你离入门,可能还差这一篇。


无论从事前端还是后端开发,我们都应该了解HTTP,HTTP的知识体系庞大而复杂,可能用几篇博客都无法完全覆盖,所以本篇只对实际应用所能涉及到的知识进行介绍。

什么是HTTP

超文本传输协议(HTTP,HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。--来源:百度百科

基于官方的解释在百度上可以搜到很多,这里不再赘述。重点在于理解它是一种通讯协议,HTTP定义了一种规约,网络上的各种终端基于这种规约,可以进行跨地域,跨技术平台的通讯。

Url

我们知道,想要访问一个网站,需要在浏览器地址栏中输入一串Url,如,我们要访问简书http://www.jianshu.com/
点击回车,稍等片刻便可以看到丰富多彩的页面,整个过程实际上是由浏览器向后台服务器发送了一个HTTP请求。服务器收到请求进行相应处理后生成一个响应,随后返回至浏览器,经过浏览器解析呈现信息内容。


HTTP通过Url(统一资源定位符)建立连接和传输数据,Url标识网络上某一处资源的地址,我们以一个常见的GET请求为例,看看其构成。
Url结构示例

  • 协议部分:访问服务器所使用的协议,如http,https,ftp等;
  • 域名部分:目标主机的域名,本例中域名是“www.process.com”,也可以使用IP地址。通过域名,可以帮助你在浩瀚的网络世界中快速定位你想访问的目标服务器;
  • 资源路径:域名“/”后面的部分,又称虚拟目录。指向是你要访问的目标服务器下某个资源的路径;
  • 访问参数:“?”后面的部分是访问参数,多个参数间使用“&”符连接。

在初步了解Url之后,我们一起来揭开HTTP的神秘面纱。
互联网中,无时不刻不在进行着数据的交换与传输,这些传输以报文的形式进行。报文包含了一次传输所需要的所有信息。之前提到,HTTP是一种通讯协议,报文格式就是协议中的一部分。两端只要遵从相同的协议,就可以进行通讯。

Request请求报文

为了更直观的理解,我用Chrome浏览器自带的抓包工具,抓取一次Request请求,且看下图:


抓取Rquest请求

可以抽象为以下图表结构:


Rquest请求报文
  • 请求行
    包含以下三个部分
    • 请求方法:HTTP/1.1协议定义了8种请求方法 GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。其中,GET、POST最为常用。在主流的Restful架构风格中,常用GET表示获取资源,POST表示新建或更新资源,PUT表示更新资源,DELETE表示删除资源。
    • 请求地址:请求目标资源的访问地址,同Url。
    • 协议版本:注明HTTP协议的版本,本例中使用的是HTTP1.1版本。
  • 请求头
    以键值对的形式,注明向服务器发起请求的附加信息。(ps:关于请求头Header,后面我会专门介绍)
  • 空行
    请求头与请求体中的空行是必须存在的,即便第四部分请求体中没有数据。
  • 请求体
    可用于存放媒体数据,通过请求头中Content-Type属性设置媒体类型信息,可以是HTML,图片,JSON字符串等,本例的请求体中没有数据。

Response响应报文

上文提到,当服务器对接收到的请求进行处理后,会生成一个响应信息返回到浏览器。下面我们来看看响应报文什么样:



同样可以抽象出如下图表结构:



响应报文除了第一行与请求报文不同,其余部分格式一致。所以只对Response响应报文的第一行“状态行”进行说明。
状态行分为协议版本,响应码,响应信息三个部分:
  • 协议版本:概念与请求行中的一致,用于注明HTTP协议的版本。
  • 响应码:每次请求目标服务器,该目标服务器都会返回一个带有状态码的头文件。比如,在访问信息正常的情况下,服务器会返回200。另外还有我们常见的404状态码。(传送门:点我了解更多状态码信息
  • 响应信息:包含服务器返回的响应信息,本例中因为正常访问,响应信息是“OK”。

HTTP Header

无论是请求还是响应,客户端和服务器之间都需要传递附加信息,Header部分作为载体承载这些信息。Header中属性的格式为 属性名: 属性值(注意!冒号后带空格),如:

Content-Type: text/plain    
Cache-Control: no-cache

以下是Header中常见属性:

常见请求头
常见响应头


通俗的讲,这些属性主要用于“带话儿”,在请求时告知服务器,传输的内容的长度,格式,访问者身份信息等,以便进行安全保障。实际上请求头和响应头有很多通用属性,这里不一一列举。(更多内容可以点击:HTTP 头域大全)。

HTTP Entity

请求体可以存放各种媒体类型的数据,根据使用场景不同,请求体的形式也不同,常用的有以下三种

表单提交

我们在提交表单时,form表单的enctype参数指定了HTTP请求的Content-Type,默认情况下enctype = application/x-www-form-urlencoded,如

<form action="/upload" method="post" enctype="application/x-www-form-urlencoded">
  <input type="text" name="param1">
  <input type="text" name="param2">
  <input type="file" name="file">
</form>

请求头中Content-Type: application/x-www-form-urlencoded,浏览器会以x-www-form-urlencoded方式将form表单数据格式化为key1=value1&key2=value2...形式的字符串。如果使用GET请求,字符串会被用“?”拼接到Url后作为QueryString,使用POST请求时,字符串则会被放入请求体,如下图:

POST 请求Form表单提交

文件分割

某些场景下,提交的表单数据可能包括文件,这时可以将enctype设置为multipart/form-data,用于上传文件流,浏览器会按form表单每个字段或文件将请求体分割成多个部分。请求头中Content-Type的属性值为multipart/form-data; boundary={boundary},{}中为定义的内容分隔符。如Content-Type: multipart/form-data; boundary=----hSJb4uI9kw0Snmu9dw,接下来我们看报文结构:

multipart上传

可以看到,请求体中包含一个名为“name”的字段和一个名为hello的txt文件,中间以--{boundary}分割,报文结尾处以“--{boundary}”在加上“--”标注表示结束。
上面提到两种 POST 数据方式,不仅受到原生浏览器支持,服务器也能够良好支持。不过在移动互联网大前端时代,我们可能需要通过更灵活的方式面对复杂的数据结构。

自定类型

在移动开发的场景下,移动端在向服务器传输数据时,可以将数据Bean转化成Json字符串,放入请求体中,以安卓开发时使用retrofit2网络框架请求为例:

//创建参数Bean,设置参数        
Param param = new Param();
param.setParam1(param1);
param.setParam2(param2);
param.setParam3(param3);
Gson gson = new Gson();
//转化Json字符串
String paramStr = gson.toJson(param)
//设置实体Content-Type,将Json字符串放入实体
RequestBody body = RequestBody.create(MediaType.parse("application/json; charset=utf-8"),paramStr);
//发起请求
Observable<DataBean> response = api.sendRequest(body);

最终发送的请求就是

POST http://www.process.com HTTP/1.1 
Content-Type: application/json;charset=utf-8  
~ ~ ~ ~ ~ ~ ~ ~ ~ 空行 ~ ~ ~ ~ ~ ~ ~ ~~ ~
{"param1":"abc","param2":"def","param3":"ghk"}

使用Json可以应对复杂的结构化数据,自定类型除使用Json外,还可以通过将Content-Type属性设置为application/xml,application/zip,来存放更多媒体类型。

HTTP RequestMethod

无论是请求报文还是响应报文,头行格式中都有请求方法属性。在实际项目中,初学者页时常搞不清楚这么多请求方法的区别。先列出8种方法在网上的主流描述,便于直观了解:

序号 方法名 解释
1 GET 请求指定的页面信息,并返回实体主体。
2 POST 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
3 PUT 从客户端向服务器传送的数据取代指定的文档的内容。
4 DELETE 请求服务器删除指定的页面。
5 PATCH 实体中包含一个表,表中说明与该URI所表示的原内容的区别。
6 OPTIONS 允许客户端查看服务器的性能。
7 HEAD 类似于get请求,只不过返回的响应中没有具体的内容,用于获取报头。
8 TRACE 回显服务器收到的请求,主要用于测试或诊断。

在RESTful风格架构盛行之前,我们最多用到的是GET和POST,GET执行简单效率高,但由于GET采用明文拼接请求参数,固安全性较低。POST请求将参数放入实体,相对提高了信息窃取的门槛。另外GET请求会受到Url长度限制,无法应对复杂的数据结构。POST请求则无此问题。
在RESTful风格中,GET,POST,PUT,DELETE,分别被抽象出来对应查,增,改,删四项操作。
至此,本篇内容基本完毕。想深入了解HTTP,需要持续投入时间和精力,本文涉猎的每一个知识点,都可以继续展开。同时,无论你是两眼发蒙的职场鲜肉,还是记忆等待唤醒的研发老司机,笔者都希望能够从中有所收获。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,319评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,801评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,567评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,156评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,019评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,090评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,500评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,192评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,474评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,566评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,338评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,212评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,572评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,890评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,169评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,478评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,661评论 2 335

推荐阅读更多精彩内容