菜鸟面试必知的 http 知识(三)—— 请求和响应报文

篇3介绍了HTTP的请求报文和响应报文,重点是请求方法和状态码(我在面试阿里和腾讯分别被问到过),这其实就是HTTP协议的核心了!

用于HTTP协议交互的信息被称为HTTP报文。请求端的HTTP报文叫做请求报文,响应端的叫做响应报文。HTTP报文大致可分为报文首部报文主体两块,如图1所示。

图1 - 请求报文和响应报文的结构

请求报文和响应报文主要不同在于报文首部分别是请求行和状态行,其含义如下:

  • 请求行:包含用于请求的方法,请求URI和HTTP版本
  • 状态行:包含表明响应结果的状态码,原因短语和HTTP版本
  • 首部字段:包含表示请求和响应的各种条件和属性的各类首部

下面以请求简书博客地址为例,解释请求报文和响应报文

1 - 请求报文

请求报文是由请求方法、请求URI、协议版本、可选的请求首部字段和内容实体组成的。

// 请求报文
GET http://www.jianshu.com/u/d97a1dec9e2d   HTTP/1.1

// 请求首部字段
Host: www.jianshu.com
Proxy-Connection: keep-alive
Accept: application/json
Chrome/57.0.2979.2 Safari/537.36
Referer: http://www.jianshu.com/u/d97a1dec9e2d
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8

// 内容实体
Cookie: ...
name=binjiang&age=100

1.1 - HTTP请求方法

(1). GET:获取资源
 GET方法用来请求访问已被URI识别的资源,指定的资源经服务端解析后返回响应内容。如果资源是文本、图片,就直接返回;如果是接口程序,就返回执行的结果。

(2). POST:传输实体主体
 POST方法用来传输实体的主体,尽管GET方法也可以传输实体的主体,但一般不用GET方法进行传输,而是POST方法。

这是因为GET提交,请求的数据会附在URI之后,而POST提交会把请求的数据放置在内容实体中。因此,GET提交的数据会在地址栏中显示出来,而POST提交,地址栏不会改变。
 同时,GET方法在特定浏览器和服务器对URL长度有限制,这也会导致POST可以传输的内容更多一些。并且POST的安全性要比GET的安全性高。

(3). PUT:传输文件
 PUT方法用来传输文件。但是鉴于HTTP/1.1的PUT方法自身不带验证机制,任何人都可以上传文件,存在安全性,因此一般的web网站不使用该方法。除非配合web应用程序的验证机制或是采用REST标准的网站架构设计。

(4). HEAD:获得报文首部
 HEAD方法和GET方法一样,只是不返回报文主体部分。用于确认URI的有效性及资源更新的日期时间等。

(5). DELETE:删除文件
 DELETE方法用来删除文件,是与PUT相反的方法。同样HTTP/1.1的DELETE方法自身不带验证机制,因此一般的web网站不使用该方法。

(6). OPTIONS:询问支持的方法
 OPTIONS方法用来查询针对URI指定的资源支持的方法。

(7). TRACE:追踪路径
 TRACE方法是让web服务器端将之前的请求通信环回给客户端的方法。客户端通过TRACE方法可以查询发送出去的请求是怎样被加工修改/篡改的。这是因为,请求在连接到目标服务器的中途可能会经过代理中转,TRACE方法就是用来确认连接过程中发生的一系列操作。

(8). CONNECT:要求用隧道协议连接代理
 CONNECT方法要求在与代理服务器通信时建立隧道,实现用隧道协议进行TCP通信。主要使用SSL(Secure Sockets Layer,安全套接层)和TSL(Transport Layer Security,传输层安全)协议把通信内容加密后经网络隧道传输


2 - 响应报文

响应报文是由协议版本、状态码、说明、可选响应首部字段以及实体主体构成。

HTTP/1.1    200    OK
// 响应首部字段
Date: Mon, 13 Mar 2017 04:36:45 GMT
Content-Length: 362
Content-Type: text/html
// 主体
<html>
...

2.1 - HTTP状态码

状态码的作用是当客户端向服务端发送请求后,服务端返回处理结果的状态。因为客户端需要知道服务端返回的是有效的还是错误的数据,如果是错误的数据,是客户端的问题,还是服务端的问题。

类别 原因短语
1XX Informational(信息性状态码) 请求正在处理中
2XX Success 正常处理完毕
3XX Redirection 需要进行附加操作才算完成请求
4XX Client Error 客户端发送的请求数据问题
5XX Server Error 服务端处理请求时出错

这里面最需要关注的是4XX和5XX。因为在Web开发和调试过程中,不可避免会出现Bug,返回码可以帮助快速定位到出错点。例如经常会出现的“404 Not Found”错误,表明了服务器上无法找到请求的资源,而服务器本身是正常工作的。“501 Internal Server Error”表明服务器端在执行请求时发生了错误,此时服务器并没有正常工作。


3 - 首部字段含义

  • 通用首部字段(General Header Fields): 请求报文和响应报文两方都会使用的首部;
  • 请求首部字段(Request Header Fields): 从客户端向服务器发送请求报文时使用的首部。补充了请求的附加内容,客户端的信息,响应内容相关的优先级等信息。
  • 响应首部字段(Response Header Fields): 从服务器向客户端返回响应报文时使用的首部。补充了响应的附加内容,也会要求客户端附加额外的内容信息。
  • 实体首部字段(Entity Header Fields): 针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。
3.1 - 通用首部字段
首部字段名 说明
Cache-Control 控制缓存的行为
Connection 逐跳首部,连接的管理
Date 创建报文的日期时间
Pragna 报文指令
Trailer 报文末端的首部一览
Transfer-Encoding 指定报文主体的传输编码方式
Upgrade 升级为其他协议
Via 代理服务器的相关信息
Warning 错误通知
3.2 - 请求首部字段
首部字段名 说明
Accept 用户代理可处理的媒体类型
Accept—Charset 优先的字符集
Accept-Encoding 优先的内容编码
Accept-Language 优先的语言(自然语言)
Authorization Web认证信息
Expect 期待服务器的指定行为
From 用户的电子邮箱地址
Host 请求资源所在服务器
if-Match 比较实体标记(ETag)
if-Modified-Since 比较资源的更新时间
if-None-Match 比较实体标记(与if-Match相反)
if-Range 资源为更新时发送实体Byte的范围请求
if-Unmodified-Since 比较资源的更新时间(与if-Modified-Since相反)
Max-Forwards 最大传输逐跳数
Proxy-Authorization 代理服务器要求客户端的认证信息
Range 实体字节范围请求
Referer 对请求中的URL的原始获取方法
TE 传输编码的优先级
User-Agent HTTP客户端程序的信息
3.3 - 响应首部字段
首部字段名 说明
Accept-Ranges 是否接受字节范围请求
Age 推算资源创建经过时间
ETag 资源的匹配信息
Location 令客户端重定向至指定的URL
Proxy-Authenticate 代理服务器对客户端的认证信息
Rety-After 对再次发起请求的时机要求
Server HTTP服务器的安装信息
Vary 代理服务器缓存的管理信息
WWW-Authenticate 服务器对客户端的认证信息
3.4 - 实体首部字段
首部字段名 说明
Allow 资源科支持的HTTP方法
Content-Encoding 实体主体适用的编码方式
Content-Language 实体主体的自然语言
Content-Length 实体主体的大小(单位:字节)
Content-Location 替代对资源的URL
Content-MD5 实体主体的报文摘要
Content-Range 实体主体的位置范围
Content-Type 实体主体的媒体类型
Expires 实体主体过期的日期时间
Last-Modified 资源的最后修改日期时间

4 - Cookie服务的首部字段

首部字段名 说明 首部类型
Set-Cookie 开始状态管理所有的Cookie信息 响应首部字段
Cookie 服务器接收到的Cookie信息 请求首部字段
4.1 - Set-Cookie字段的属性
属性 说明
NAME=VALUE 赋予Cookie的名称和其值
expires=DATE Cookie的有效期(若不mingque指定则默认为浏览器关闭前为止)
path=PATH 将服务器上的文件目录作为Cookie的适用对象(若不指定则默认为文档所在的目录)
domain=域名 作为Cookie适用对象的域名(若不指定则默认为创建Cookie的服务器的域名)
Scure 仅在HTTPS安全通信时才会发送Cookie
HttpOnly 加以限制,使Cookie不能被JavaScript脚本访问

大家好,我是彬彬酱,目前在腾讯从事Web后端开发。
菜鸟必知的 http 知识专题整理了关于网络的基础知识,适合大家进行入门级学习,这个专题现包含下列文章:
菜鸟必知的 http 知识(一)—— TCP 握手协议
菜鸟必知的 http 知识(二)—— HTTP 协议特点
菜鸟必知的 http 知识(三)—— 请求和响应报文
菜鸟必知的 http 知识(四)—— HTTP 和 HTTPS
菜鸟必知的 http 知识(五)—— 新技术的出现
菜鸟必知的 http 知识(六)—— web的结构组件


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

推荐阅读更多精彩内容