一文详解 HTTP 协议

简介: HTTP(HyperText Transfer Protocol)超文本传输协议。其`最初的设计目的是为了提供一种发布和接收HTML页面的方法`。HTTP是一个`客户端(用户)`和`服务端`之间请求和应答的标准。

HTTP(HyperText Transfer Protocol)超文本传输协议。其最初的设计目的是为了提供一种发布和接收HTML页面的方法
HTTP是一个客户端(用户)服务端之间请求和应答的标准。

  • 用户通过Web浏览器其它软件工具,向指定服务器的指定端口(默认端口为80)发起一个HTTP请求。

请求获取该服务器上存储的一些资源,比如:HTML文件、图片、文档 等;

  • HTTP服务器则在指定端口(默认端口为80)监听客户端的请求。

一旦收到客户端请求,服务器会向客户端返回一个状态,比如HTTP/1.1 200 OK;并返回请求内容,如文件、图片等;或对应请求的错误信息。

一、HTTP请求

HTTP请求由三部分组成,分别是:请求行、request-header、request-body

1.1、请求行

请求行格式:Method Request-URI HTTP-Version CRLF
请求行举例:GET /form.html HTTP/1.1 /r/n

Method
HTTP/1.1协议中共定义了八种Method方法来以不同方式操作指定的资源:

Method 方法说明
GET 请求获取由Request-URI所标识的资源
POST 向指定资源提交数据,请求服务器进行处理(例如提交表单或者上传文件)
HEAD 请求获取由Request-URI所标识的资源的响应消息报头
PUT 向指定资源位置上传其最新内容
DELETE 请求服务器删除由Request-URI所标识的资源
TRACE 请求服务器回送收到的请求信息,主要用语测试或诊断
OPTIONS 这个方法可使服务器传回该资源所支持的所有HTTP请求方法。向Web服务器发送OPTIONS请求,可以测试服务器功能是否正常运作
CONNECT 保留将来使用

Request-URI 统一资源标识。例:https://www.baidu.com/
HTTP-Version HTTP的版本。例:HTTP/1.1
CRLF 回车换行。例:/r/n

1.2、request-header

request-header举例:

mob-token: iammobtokeniammobtokeniammobtoken
User-Agent: Demo_Android
Cookie: 
client_i=android#v1.0.0#deviceid#android6.0.1;
client_ursid=xiaxveliang@163.com;
client_urstoken=iamtokeniamtokeniamtoken
Connection: Keep-Alive
Host: demo.com

request-header关键词含义如下表所示:

request-header 含义说明 举例
User-Agent User-Agent的内容包含发出请求的用户信息 User-Agent: Mozilla/5.0 (Linux; X11)
Host 指定请求的服务器的域名和端口号 Host: www.zcmhi.com
Cookie HTTP请求发送时,会把保存在该请求域名下的所有cookie值一起发送给web服务器。 Cookie: $Version=1; Skin=new;
Content-Length 请求的内容长度 Content-Length: 348
Content-Type 请求的与实体对应的MIME信息 Content-Type: application/x-www-form-urlencoded
Accept 指定客户端能够接收的内容类型 Accept: text/plain, text/html
Accept-Charset 浏览器可以接受的字符编码集。 Accept-Charset: iso-8859-5
Accept-Encoding 指定浏览器可以支持的web服务器返回内容压缩编码类型。 Accept-Encoding: compress, gzip
Accept-Language 浏览器可接受的语言 Accept-Language: en,zh
Accept-Ranges 可以请求网页实体的一个或者多个子范围字段 Accept-Ranges: bytes
Authorization HTTP授权的授权证书 Authorization: BasicQWxhZGRpbjpvcGVuIHNlc2FtZQ==
Connection 表示是否需要持久连接。(HTTP 1.1默认进行持久连接) Connection: close
Date 请求发送的日期和时间 Date: Tue, 15 Nov 2010 08:12:31 GMT
From 发出请求的用户的Email From: user@email.com
Expect 请求的特定的服务器行为 Expect: 100-continue
Cache-Control 指定请求和响应遵循的缓存机制 Cache-Control: no-cache
If-Match 只有请求内容与实体相匹配才有效 If-Match: “737060cd8c284d8af7ad3082f209582d”
If-Modified-Since 如果请求的部分在指定时间之后被修改则请求成功,未被修改则返回304代码 If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
If-None-Match 如果内容未改变返回304代码,参数为服务器先前发送的Etag,与服务器回应的Etag比较判断是否改变 If-None-Match: “737060cd8c284d8af7ad3082f209582d”
If-Range 如果实体未改变,服务器发送客户端丢失的部分,否则发送整个实体。参数也为Etag If-Range: “737060cd8c284d8af7ad3082f209582d”
If-Unmodified-Since 只在实体在指定时间之后未被修改才请求成功 If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
Max-Forwards 限制信息通过代理和网关传送的时间 Max-Forwards: 10
Pragma 用来包含实现特定的指令 Pragma: no-cache
Proxy-Authorization 连接到代理的授权证书 Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range 只请求实体的一部分,指定范围 Range: bytes=500-999
Referer 先前网页的地址,当前请求网页紧随其后,即来路
TE 客户端愿意接受的传输编码,并通知服务器接受接受尾加头信息 TE: trailers,deflate;q=0.5
Upgrade 向服务器指定某种传输协议以便服务器进行转换(如果支持) Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Via 通知中间网关或代理服务器地址,通信协议 Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning 关于消息实体的警告信息 Warn: 199 Miscellaneous warning

二、HTTP响应

服务端处理客户端的请求后,会返回一个HTTP响应消息。与HTTP请求类似,HTTP响应也是三个部分组成,分别是:
状态行、response-header、response-body

2.1、状态行

状态行格式: HTTP-Version Status-Code Reason-Phrase CRLF
状态行举例: HTTP/1.1 200 OK /r/n

Status-Code状态码:
状态代码由3位数字组成,表示请求是否被理解或被满足。
状态代码的第一个数字定义了响应的类别,后面两位没有具体的分类

第一个数字有五种可能的取值:

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

状态码举例:

状态码举例 状态描述 详情说明
200 OK 客户端请求成功
301 Moved permanently 重定向
302 Moved temporarily 暂时性重定向
304 not modified 数据未更新
400 Bad Request 由于客户端请求有语法错误,不能被服务器所理解。
401 Unauthonzed 请求未经授权。这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden 服务器收到请求,但是拒绝提供服务。服务器通常会在响应正文中给出不提供服务的原因
404 Not Found 请求的资源不存在,例如,输入了错误的URL
500 Internal Server Error 服务器发生不可预期的错误,导致无法完成客户端的请求
503 Service Unavailable 服务器当前不能够处理客户端的请求,在一段时间之后,服务器可能会恢复正常
511 Network Authentication Required 是一种HTTP协议的错误状态代码,表示客户端需要通过验证才能使用该网络;该状态码不是由源头服务器生成的,而是由控制网络访问的拦截代理服务器生成的;网络运营商们有时候会在准许使用网络之前要求用户进行身份验证、接受某些条款,或者进行其他形式的与用户之间的互动(例如在网络咖啡厅或者机场);他们通常用用户设备的 MAC 地址来进行识别。

2.2、response-header

response-header举例:

Server: xiaxl
Date: Thu, 29 Aug 2019 06:10:55 GMT
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Set-Cookie: XIAXL=xiaxl; Domain=demo.com; Path=/

response-header关键词含义如下表所示:

response-header 解释 示例
Content-Encoding web服务器支持的返回内容压缩编码类型。 Content-Encoding: gzip
Content-Language 响应体的语言 Content-Language: en,zh
Content-Length 响应体的长度 Content-Length: 348
Content-Location 请求资源可替代的备用的另一地址 Content-Location: /index.htm
Content-MD5 返回资源的MD5校验值 Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range 在整个返回体中本部分的字节位置 Content-Range: bytes 21010-47021/47022
Content-Type 返回内容的MIME类型 Content-Type: text/html; charset=utf-8
Accept-Ranges 表明服务器是否支持指定范围请求及哪种类型的分段请求 Accept-Ranges: bytes
Age 当代理服务器用自己缓存的实体去响应请求时,用该头部表明该实体从产生到现在经过多长时间了(以秒计,非负) Age: 12
Allow 对某网络资源的有效的请求行为,不允许则返回405 Allow: GET, HEAD
Date 原始服务器消息发出的时间 Date: Tue, 15 Nov 2010 08:12:31 GMT
Cache-Control Cache-Control首部是在HTTP 1.1新加入字段,替代Http 1.0的Expires,提供了细粒度的缓存策略 Cache-Control no-cache 平台侧通过该字段告知客户端,响应数据不能被复用与缓存。Cache-Control max-age=86400 平台侧通过该字段告知客户端,响应数据在今后的86400秒内可以直接被复用,而不需要从服务端重新获取。
ETag 下次请求时,客户端将该字段内容带到If-Nono-Match中,平台侧用收到此ETag判断客户端缓存数据是否需要更新。 ETag: “737060cd8c284d8af7ad3082f209582d”
Expires 响应过期的日期和时间,Expires首部主要是针对HTTP 1.0版本,HTTP1.1版本用Cache-Control 代替 Expires: Thu, 01 Dec 2010 16:00:00 GMT
Last-Modified 请求资源的最后修改时间 Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
Location 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源
Pragma 包括实现特定的指令,它可应用到响应链上的任何接收方 Pragma: no-cache
Proxy-Authenticate 它指出认证方案和可应用到代理的该URL上的参数 Proxy-Authenticate: Basic
refresh 应用于重定向或一个新的资源被创造,在5秒之后重定向(由网景提出,被大部分浏览器支持)
Retry-After 如果实体暂时不可取,通知客户端在指定时间之后再次尝试 Retry-After: 120
Server web服务器软件名称 Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Set-Cookie 设置Http Cookie Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
Trailer 指出头域在分块传输编码的尾部存在 Trailer: Max-Forwards
Transfer-Encoding 文件传输编码 Transfer-Encoding:chunked
Vary 告诉下游代理是使用缓存响应还是从原始服务器请求 Vary: *
Via 告知代理客户端响应是通过哪里发送的 Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning 警告实体可能存在的问题 Warning: 199 Miscellaneous warning
WWW-Authenticate 表明客户端请求实体应该使用的授权方案 WWW-Authenticate: Basic

三、HTTP 举例

这里举两个例子:

  • 一个Http get 请求和响应;
  • 一个Http post 请求和响应;

3.1、Http get 举例

http get 请求抓包数据如下:

GET /demo/getData.do?deviceId=123&userId=xiaxl HTTP/1.1    // 请求行

mob-token: iammobtokeniammobtokeniammobtoken            // request-header
User-Agent: Demo_Android
Cookie: 
client_i=android#v1.0.0#deviceid#android6.0.1;
client_ursid=xiaxveliang@163.com;
client_urstoken=iamtokeniamtokeniamtoken
Connection: Keep-Alive
Host: demo.com

http get 响应抓包数据如下:

HTTP/1.1 200 OK                                            // 响应 状态行

Server: xiaxl                                            // response-header
Date: Thu, 29 Aug 2019 06:10:55 GMT
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Set-Cookie: XIAXL=xiaxl; Domain=demo.com; Path=/

{"code":200}                                            // response-body

3.2、Http post 举例

Http post请求抓包数据如下所示:

POST /demo/postData.do?sign=abc HTTP/1.1                // 请求行

mob-token: iammobtokeniammobtokeniammobtoken            // request-header
User-Agent: Demo_Android
Cookie: 
client_i=android#v1.0.0#deviceid#android6.0.1;
client_ursid=xiaxveliang@163.com;
client_urstoken=iamtokeniamtokeniamtoken
Content-Length: 371
Content-Type: 
application/x-www-form-urlencoded; 
charset=utf-8
Connection: Keep-Alive
Host: demo.com

[{"deviceId":"123","userId":"xiaxl"}]                    // request-body

http post 响应抓包数据如下:

HTTP/1.1 200 OK                                            // 响应 状态行

Server: xiaxueliang                                        // response-header
Date: Thu, 29 Aug 2019 06:09:41 GMT
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Set-Cookie: XIAXL=xiaxl; Domain=demo.com; Path=/

{"code":200}                                            // response-body

3.3、Http Post 文件上传

Http post文件上传请求,抓包数据如下所示:

POST /demo/photoUpload.do HTTP/1.1                        // 请求行

mob-token: iammobtokeniammobtokeniammobtoken            // request-header
User-Agent: Demo_Android
Cookie: 
client_i=android#v1.0.0#deviceid#android6.0.1;
client_ursid=xiaxveliang@163.com;
client_urstoken=iamtokeniamtokeniamtoken
Content-Length: 12345
Content-Type: 
multipart/form-data; 
boundary=f9817fcb-6ad7-4445-9f7b-2ab30578c4ac
Connection: Keep-Alive
Host: demo.com

// body 文件数据 省略...                                    // request-body

Http post文件上传, 响应抓包数据如下:

HTTP/1.1 200 OK                                            // 响应 状态行

Server: xiaxl                                            // response-header
Date: Thu, 29 Aug 2019 06:10:55 GMT
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Set-Cookie: XIAXL=xiaxl; Domain=demo.com; Path=/

{"code":200}                                            // response-body

四、部分知名网站Reponse Header中包含 客户端IP

发现部分知名网站Reponse Header中包含 客户端IP

查看其Response Header数据
在这里插入图片描述

五、参考:

维基百科:超文本传输协议
https://zh.wikipedia.org/wiki/%E8%B6%85%E6%96%87%E6%9C%AC%E4%BC%A0%E8%BE%93%E5%8D%8F%E8%AE%AE

HTTP请求和MIME介绍
https://www.cnblogs.com/Dev0ps/p/8074972.html

HTTP Header 详解
https://kb.cnblogs.com/page/92320/

= THE END =

文章首发于公众号”CODING技术小馆“,如果文章对您有帮助,可关注我的公众号。
文章首发于公众号”CODING技术小馆“,如果文章对您有帮助,可关注我的公众号。
文章首发于公众号”CODING技术小馆“,如果文章对您有帮助,可关注我的公众号。

目录
相关文章
|
4月前
|
数据采集 数据可视化 API
QUIC协议优化:HTTP/3环境下的超高速异步抓取方案
本文介绍了一种基于QUIC和HTTP/3的异步爬虫方案,用于抓取知乎热榜数据并生成趋势图。通过HTTPX与aioquic结合实现高性能连接复用,配合代理IP绕过反爬限制,提取标题、热度等信息。利用Python代码示例展示了异步抓取流程,并借助Matplotlib绘制话题热度变化图表。分析显示突发热点生命周期短,而深度话题热度更稳定。此方案可优化内容运营策略,快速捕捉潜在爆款话题。
180 4
QUIC协议优化:HTTP/3环境下的超高速异步抓取方案
|
2月前
|
缓存 监控 搜索推荐
301重定向实现原理全面解析:从HTTP协议到SEO最佳实践
301重定向是HTTP协议中的永久重定向状态码,用于告知客户端请求的资源已永久移至新URL。它在SEO中具有重要作用,能传递页面权重、更新索引并提升用户体验。本文详解其工作原理、服务器配置方法(如Apache、Nginx)、对搜索引擎的影响及最佳实践,帮助实现网站平稳迁移与优化。
436 68
|
1月前
HTTP协议中请求方式GET 与 POST 什么区别 ?
GET和POST的主要区别在于参数传递方式、安全性和应用场景。GET通过URL传递参数,长度受限且安全性较低,适合获取数据;而POST通过请求体传递参数,安全性更高,适合提交数据。
338 2
|
2月前
|
存储 网络协议 安全
HTTP 协议及会话跟踪机制详解
本文详解了 HTTP 协议的核心知识,包括其定义(超文本传输协议,基于 TCP,规定客户端与服务器通信规则)及与 HTTPS 的区别(安全性、端口、资源消耗)。 介绍了 GET 与 POST 请求的差异(参数限制、安全性、应用场景),以及 Restful 风格(通过 URL 定位资源,请求方式决定操作)。列举了常见 HTTP 状态码(如 200 成功、404 资源未找到),对比了转发与重定向的区别(服务器端一次请求 vs 客户端两次请求)。 还阐述了会话跟踪机制:Cookie 基于客户端存储,通过Set-Cookie和Cookie头实现,安全性较低;Session 基于服务端存储,依赖 C
237 1
|
1月前
|
缓存 网络协议 UED
深度解析HTTP协议从版本0.9至3.0的演进和特性。
总的来说,HTTP的演进是互联网技术不断发展和需求日益增长的结果。每一次重要更新都旨在优化性能,增进用户体验,适应新的应用场景,而且保证了向后兼容,让互联网的基础架构得以稳定发展。随着网络技术继续进步,我们可以预期HTTP协议在未来还会继续演化。
337 0
|
2月前
|
XML 安全 网络架构
深度对比SOAP与HTTP协议:详细理解它们的工作原理和差异
在设计服务和系统交云策略时,考虑到上述差异是至关重要的。SOAP适合需要高安全性、可靠性和事务支持的企业级应用。而HTTP适合Web界面浏览、RESTful服务和需要快速响应的轻量级通信。根据具体需求和上下文,开发者可以选择合适的协议以实现最优的系统性能和用户体验。
295 0
|
3月前
|
缓存
HTTP协议深度剖析:常见请求头信息讲解
这就是HTTP请求头背后的工作原理,希望通过比作“邮差”和“标签”,可以让你对这个繁琐技术更有感触,更得心应手。尽管这些信息可能很琐碎,但了解了它们的含义和工作方式,就等于揭开了HTTP协议神秘的面纱,掌控了网络交流的核心。你还等什么,赶快动手尝试一下吧!
130 17
|
2月前
HTTP协议中常见的状态码 ?
HTTP协议状态码分为1xx、2xx、3xx、4xx、5xx五类。常见状态码包括:101(切换协议)、200(请求成功)、302(重定向)、401(未认证)、404(资源未找到)、500(服务器错误)。
272 0
|
3月前
HTTP协议探究:常用方法一网打尽
总的来说,HTTP协议的命令犹如一把钥匙,解锁了互联网世界的大门。它是规则,也是工具,了解了它,就等于掌握了互联网的一把通行证。我们每天都在用,也常常无视它,但是只有深刻理解了它,才能更好地运用它。如此,我们的互联网世界旅程就会变得更加顺畅,更加有趣。
110 14