Http协议具体解释

一、HTTP协议的URL

HTTP URL (URL是一种特殊类型的URI。包括了用于查找某个资源的足够的信息)的格式例如以下:
http://host[":"port][abs_path]
http表示要通过HTTP协议来定位网络资源;
host表示合法的Internet主机域名或者IP地址;
port指定一个port号。为空则使用缺省port80;
abs_path指定请求资源的URI;
假设URL中没有给出abs_path,那么当它作为请求URI时。
必须以“/”的形式给出,通常这个工作浏览器自己主动帮我们完毕。
eg:
1、输入:www.guet.edu.cn
浏览器自己主动转换成:http://www.guet.edu.cn/
2、http:192.168.0.116:8080/index.jsp 

二、 Http协议的内容

Request and Response messages use the generic message format of RFC 822 [9] for transferring
entities (the payload of the message). Both types of message consist of a start-line, 
zero or more header fields (also known as "headers"), 
an empty line (i.e., a line with nothing preceding the CRLF) 
indicating the end of the header fields, and possibly a message-body.
    generic-message = start-line
             *(message-header CRLF)
             CRLF
             [ message-body ]

http协议请求和响应内容都由三部分组成,各自是:行(请求行和状态行)、报头(消息头)、正文(消息体)
消息头和消息体之间,用CRLF(回车和换行)隔开,表示报头域的结束.

2.1 行(start-line)

(2.1.1) 请求行(Request-Line)

请求行以一个方法符号开头。以空格分开。后面跟着请求的URI和协议的版本号,
格式例如以下:Method Request-URI HTTP-Version CRLF 
当中 Method表示请求方法;
Request-URI是一个统一资源标识符;
HTTP-Version表示请求的HTTP协议版本号,当前使用1.1。
CRLF表示回车和换行(除了作为结尾的CRLF外。不同意出现单独的CR或LF字符)。

请求方法(全部方法全为大写)有多种,各个方法的解释例如以下:
GET 请求获取Request-URI所标识的资源
POST 在Request-URI所标识的资源后附加新的数据
HEAD 请求获取由Request-URI所标识的资源的响应消息报头
PUT 请求server存储一个资源,并用Request-URI作为其标识
DELETE 请求server删除Request-URI所标识的资源
TRACE 请求server回送收到的请求信息。主要用于測试或诊断
CONNECT 保留将来使用
OPTIONS 请求查询server的性能,或者查询与资源相关的选项和需求

应用举例:
GET方法:在浏览器的地址栏中输入网址的方式訪问网页时。浏览器採用GET方法向server获取资源,
eg:GET /form.html HTTP/1.1 (CRLF)

POST方法要求被请求server接受附在请求后面的数据。经常使用于提交表单。
eg:POST /reg.jsp HTTP/ (CRLF) 

(2.1.2) 状态行(Status-Line)

响应的行称为状态行,格式例如以下:HTTP-Version Status-Code Reason-Phrase CRLF
当中。HTTP-Version表示serverHTTP协议的版本号。
Status-Code表示server发回的响应状态代码;
Reason-Phrase表示状态代码的文本描写叙述。
状态代码有三位数字组成。第一个数字定义了响应的类别,且有五种可能取值:
1xx:指示信息--表示请求已接收,继续处理
2xx:成功--表示请求已被成功接收、理解、接受
3xx:重定向--要完毕请求必须进行更进一步的操作
4xx:client错误--请求有语法错误或请求无法实现
5xx:server端错误--server未能实现合法的请求
eg:HTTP/1.1 200 OK (CRLF)

2.2 报头(Message Header)

HTTP头字段包含4类: general-header ; request-header ; response-header ; entity-header .

(2.2.1) 常规头(General Header)

general-header是request、response都可用的, 可是不能用于entity.
通用头域包括请求和响应消息都支持的头域,
包括Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。

Cache-Control
Cache -Control指定请求和响应遵循的缓存机制。
在请求消息或响应消息中设置 Cache-Control并不会改动还有一个消息处理过程中的缓存处理过程。
请求时的缓存指令包含no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached,
响应消息中的指令包含public、private、no-cache、no- store、no-transform、must-revalidate、
proxy-revalidate、max-age。


常常使用的就是no-cache,表示不缓存。


Date
Date头域表示消息发送的时间,时间的描写叙述格式由rfc822定义。
比如,Date:Mon,31Dec200104:25:57GMT。


Date描写叙述的时间表示世界标准时,换算成本地时间,须要知道用户所在的时区。

Pragma
Pragma头域用来包括实现特定的指令,最经常使用的是Pragma:no-cache。
在HTTP/1.1协议中,它的含义和Cache- Control:no-cache同样。 

(2.2.2) 请求头(Request Header)

请求头域可能包括下列字段Accept、Accept-Charset、Accept-Encoding、
Accept-Language、Authorization、From、Host、If-Modified-Since、
If- Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、
Max-Forwards、 Proxy-Authorization、Range、Referer、User-Agent。

Header 解释 演示样例
Accept指定client可以接收的内容类型Accept: text/plain, text/html
Accept-Charset浏览器能够接受的字符编码集。

Accept-Charset: iso-8859-5
Accept-Encoding指定浏览器能够支持的webserver返回内容压缩编码类型。

Accept-Encoding: compress, gzip
Accept-Language浏览器可接受的语言Accept-Language: en,zh
Host指定请求的server的域名和port号Host: www.zcmhi.com
From发出请求的用户的EmailFrom: user@email.com
Referer先前网页的地址。当前请求网页紧随其后,即来路Referer: http://www.zcmhi.com/archives/71.html
User-AgentUser-Agent的内容包括发出请求的用户信息User-Agent: Mozilla/5.0 (Linux; X11)

(2.2.3) 响应头(Response Header)

响应头域同意server传递不能放在状态行的附加信息,
这些域主要描写叙述server的信息和 Request-URI进一步的信息。
响应头域包括Age、Location、Proxy-Authenticate、Public、
Retry-After、Server、Vary、Warning、WWW-Authenticate。

Header 解释 演示样例
Age从原始server到代理缓存形成的估算时间(以秒计,非负)Age: 12
Location用来重定向接收方到非请求URL的位置来完毕请求或标识新的资源Location: http://www.zcmhi.com/archives/94.html
Proxy-Authenticate它指出认证方案和可应用到代理的该URL上的參数Proxy-Authenticate: Basic
Serverwebserver软件名称Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Retry-After假设实体临时不可取。通知client在指定时间之后再次尝试Retry-After: 120
Vary告诉下游代理是使用缓存响应还是从原始server请求Vary: *
Warning警告实体可能存在的问题Warning: 199 Miscellaneous warning
WWW-Authenticate表明client请求实体应该使用的授权方案WWW-Authenticate: Basic

(2.2.4) 实体头(Entity Header)

实体头域包括关于实体的原信息,实体头包括Allow、Content- Base、Content-Encoding、
Content-Language、 Content-Length、Content-Location、Content-MD5、
Content-Range、Content-Type、 Etag、Expires、Last-Modified、extension-header。

Header 解释 演示样例
Allow对某网络资源的有效的请求行为,不同意则返回405Allow: GET, HEAD
Content-Encodingwebserver支持的返回内容压缩编码类型。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
ETag请求变量的实体标签的当前值ETag: “737060cd8c284d8af7ad3082f209582d”
Expires响应过期的日期和时间Expires: Thu, 01 Dec 2010 16:00:00 GMT
Last-Modified请求资源的最后改动时间Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT

看到这里你可能会非常奇怪,为什么会没有Cookie,Content-Disposition这样的常见的信息头?!


这里我说一下,Content-Disposition不是HTTP标准的一部分。但它在其它RFC文档中定义了(RFC1806)。
而Cookie呢?首先看看Cookie是用来干嘛的:Cookie和Session是为了解决Http协议中无状态的问题
,因为Http的设计者们时就没打算让Http有状态这样的特性。故Cookie这样的东西是肯定不可能
是Http标准中的一部分。

事实上。它们都属于上面所说的:extension-header。


2.3 消息体(Message Body)

The message-body (if any) of an HTTP message is used to carry the entity-body associated 
with the request or response. The message-body differs from the entity-body only when a 
transfer-coding has been applied, as indicated by the Transfer-Encoding header field.
(message-body = entity-body
           | entity-body encoded as per Transfer-Encoding )

消息头和消息体之间是一个空行,这个行很重要。它表示消息头已经结束,接下来的是消息体。
通常情况下Post方式请求的消息体,内容格式:param1=value1¶m2=value2
响应的消息体常见有html和json的消息体,
json格式:{"key1":"value1","key2":"value2"}
html格式:
<!DOCTYPE html>
<html lang="zh-cn">
...
...
</html>

三、 參考资料

(1) 状态码具体信息
(2) 很多其它消息头的信息
(3) Http/1.1 Document
(4) RFC Archives
原创转自:http://beadlechen.github.io/

转载于:https://www.cnblogs.com/yfceshi/p/7110000.html

<think>嗯,用户现在想了解HTTP协议具体内容和工作原理。我之前已经给出了一些关于字节流的回答,但现在需要转向HTTP协议。根据用户提供的引用内容,我需要整合这些信息,同时参考之前的回答结构,确保符合系统级指令的要求。 首先,用户的问题明确要求详细讲解HTTP协议的工作原理和具体内容。我需要先明确HTTP的基本定义,作为应用层协议,基于TCP,使用客户端-服务器模型。然后要分步骤解释工作原理,比如建立连接、发送请求、处理请求、返回响应、关闭连接等。这部分要结合用户提供的引用内容,特别是引用[1]和引用[2]中提到的无状态和Cookie技术,以及HTTPS的相关内容。 接下来是协议具体内容,包括请求报文和响应报文的格式。这里需要详细说明请求行、请求头、请求体,以及状态行、响应头、响应体。要举例子,比如GET和POST请求的区别,状态码的分类。这部分可以引用用户提供的引用[4]中的请求头字段,如Host、User-Agent、Accept等,说明它们的作用。 然后要讨论HTTP的无状态性及其解决方案,比如Cookie和Session。这里要结合引用[2]中的内容,解释为什么需要Cookie来管理状态,以及Session的工作原理。同时要提到HTTPS,引用[3]中的SSL层,说明其如何保证安全,端口号的变化等。 还需要比较HTTP的不同版本,特别是1.1和2.0的区别,以及HTTP/3的改进,这样用户能了解协议的发展。这部分可能需要结合我的知识,因为用户提供的引用中没有提到版本差异,但这是常见内容,需要补充。 在回答过程中,要确保使用中文,行内公式用$...$,独立公式用$$...$$,不过HTTP协议可能较少涉及数学公式,但要注意代码块的使用。例如,展示请求报文和响应报文的示例时用代码块格式。 同时,需要检查是否引用了用户提供的引用,比如在解释无状态时引用[2],HTTPS引用[3],请求头引用[4]。确保每个引用都正确标注,例如[^1]、[^2]等,但用户提供的引用中已经有这些标记,需要正确对应。 用户可能对HTTP的工作流程、无状态的影响、Cookie的作用以及HTTPS的安全性有更深层的疑问,所以在相关部分要详细说明。此外,生成的问题需要围绕这些内容,比如如何防止中间人攻击、Cookie与Session的区别、HTTP/2的优点等。 最后,确保结构清晰,分章节讲解,使用标题和子标题,代码块和表格来增强可读性。回答要真实可靠,参考用户提供的引用内容,并适当补充必要的信息,比如版本比较和状态码分类,以提供全面的解答。</think>#### 一、HTTP协议核心定义 **HTTP(超文本传输协议)**是面向**客户端-服务器模型**的应用层协议,通过TCP/IP实现可靠数据传输,核心特性包括: - **无状态协议**:服务器不保留客户端历史请求信息 - **明文传输**:默认不加密(HTTPS通过SSL/TLS加密实现安全性)[^3] - **请求-响应模型**:客户端主动发起请求,服务器被动响应 $$ \text{通信流程} = \text{TCP连接} \rightarrow \text{HTTP请求} \rightarrow \text{HTTP响应} \rightarrow \text{连接关闭} $$ #### 二、工作原理详解(四阶段模型) ##### 1. **连接建立阶段** - **TCP三次握手**:客户端与服务器建立可靠连接(默认端口80) ```text 客户端 → SYN → 服务器 客户端 ← SYN+ACK ← 服务器 客户端 → ACK → 服务器 ``` - **HTTPS增强**:额外进行SSL/TLS握手(端口443),交换数字证书建立加密通道 ##### 2. **请求发送阶段** **标准请求报文结构**: ```http GET /index.html HTTP/1.1 ← 请求行(方法+URI+版本) Host: www.example.com ← 请求头(元数据) User-Agent: Mozilla/5.0 Accept: text/html,application/xhtml+xml (空行) ← 分隔符 name=value&age=30 ← 请求体(POST方法特有) ``` **关键请求方法对比**: | 方法 | 幂等性 | 请求体 | 典型场景 | |---------|--------|--------|---------------------| | GET | 是 | 无 | 获取资源 | | POST | 否 | 有 | 提交表单数据 | | PUT | 是 | 有 | 完整更新资源 | | DELETE | 是 | 无 | 删除资源 | ##### 3. **服务器处理阶段 - **解析请求头**:根据`Host`定位虚拟主机,`Accept-*`判断响应格式[^4] - **路由处理**:Web服务器(如Nginx)将请求转发给后端应用 - **动态生成**:应用服务器(如Tomcat)执行PHP/Java/Python代码生成内容 ##### 4. **响应返回阶段 **标准响应报文结构**: ```http HTTP/1.1 200 OK ← 状态行(版本+状态码+描述) Content-Type: text/html; charset=UTF-8 Content-Length: 1024 Set-Cookie: sessionID=abc123 ← 状态管理关键字段 (空行) <!DOCTYPE html> ← 响应体(实际内容) <html>...</html> ``` **状态码分类体系**: | 类别 | 范围 | 典型状态码 | 含义 | |-------|--------|------------------|-------------------| | 1xx | 100-199 | 101 Switching Protocols | 协议切换通知 | | 2xx | 200-299 | 200 OK / 201 Created | 请求成功 | | 3xx | 300-399 | 301 Moved Permanently | 重定向 | | 4xx | 400-499 | 404 Not Found | 客户端错误 | | 5xx | 500-599 | 500 Internal Server Error| 服务器错误 | #### 三、关键技术实现 ##### 1. **无状态解决方案** - **Cookie机制**:服务器通过`Set-Cookie`头向客户端写入标识信息 ```text 客户端 → 登录请求 → 服务器 客户端 ← Set-Cookie: userID=123 ← 服务器 客户端 → Cookie: userID=123 → 后续请求[^2] ``` - **Session技术**:服务器端存储用户状态,通过Cookie传递Session ID ##### 2. **安全增强方案** - **HTTPS加密流程**: ```mermaid graph LR A[客户端HTTPS请求] --> B[SSL/TLS握手] B --> C[证书验证] C --> D[协商加密算法] D --> E[对称密钥交换] E --> F[加密数据传输] ``` #### 四、协议演进对比 | 版本 | 核心改进 | 典型特性 | |-----------|-----------------------------------|----------------------------| | HTTP/1.0 | 基础协议规范 | 短连接,每个请求新建TCP连接 | | HTTP/1.1 | 持久连接/管线化 | Keep-Alive机制,支持chunk传输 | | HTTP/2 | 二进制分帧/头部压缩 | 多路复用,服务器推送 | | HTTP/3 | 基于QUIC协议 | 0-RTT连接,解决队头阻塞问题 | --- #### 五、经典问题解析 **Q:GET与POST方法本质区别是什么?** A:两者的**根本区别**在于语义而非技术实现: - GET是**安全幂等**操作,用于获取资源(可缓存、有长度限制) - POST是**非幂等**操作,用于提交数据(不可缓存、无长度限制) **Q:如何防止HTTP明文传输被窃听?** A:实施三步安全策略: 1. 全站启用HTTPS(HSTS策略) 2. 配置强加密套件(如TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) 3. 定期更新SSL证书 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值