HTTP协议介绍
文章目录
-
1、TCP/IP网络模型
-
- 1.1、IP协议
- 1.2、TCP协议
-
2、HTTP协议
-
-
2.1、简介
-
2.2、工作原理
-
2.3、协议版本
-
-
- 2.3.1、HTTP/1.0
-
-
2.3.2、HTTP/1.1
-
2.3.3、Http/2
-
2.3.4、Http/3
-
2.3.5、HTTPS
-
2.4、协议详解
-
-
- 2.4.1、请求信息
-
-
2.4.2、响应信息
-
2.4.3 content-type
-
2.5、认证方式
-
1、TCP/IP网络模型
OSI 七层次网络模型:从下往上依次是物理 Layer 数据链路 Layer 网络 Layer 传输 Layer 会话 Layer 表示 Layer 和应用 Layer
TCP/IP网络模型分为4层,自下而上分别为:
-
网络接口控制协议(Network Interface Control Protocol, NICP)涉及的领域包括:
-
直接映射于 OSI 的物理介质访问(Physical Medium Access)以及以太网数据 Link Layer。
-
负责处理如何在介质上表示信息、如何传输这些信息以及与硬件设备之间的交互细节。
-
网络层:
-
IP层对处理路由转发问题负有责任,并且所有类型的数据如TCP、UDP、ICMP和IGMP都会通过IP数据报进行传输。
-
网络层(IP)采用了尽力而为且无连接的可靠或不可靠的数据报传输机制,并将这些分组发送到数据链路层进行处理,并管理分片与重组逻辑。
-
传输层:
-
负责向所有节点发送数据并建立跨节点的数据传输服务。
-
该层支持两种主要协议:TCP和UDP。
-
其中TCP采用了流量控制机制、拥塞控制算法以及顺序发送的技术手段确保数据传输的可靠性和高效性。
-
当数据包出现丢包时会自动进行重传,并通过网络路径上的后续节点重新排列顺序。
-
TCP基于连接模型并不保留消息边界。
-
相比之下UDP则是一个更为简单的协议体系:
-
它仅在IP层的基础上增加了复用多路访问和数据完整性校验功能而不提供流量或错误控制机制。
-
UDP基于无连接模型并保留消息边界。
-
应用层面:
-
遵循OSI模型中对应的会话层面/表示层面及应用于特定领域的高层面。
-
负责处理指定领域内的详细操作流程,并通常采用TCP/IP或UDP/IP协议实现功能(如HTTP/FTP/DNS/SSH等)。
-
该层面仅关注具体业务逻辑而不涉及数据在网络层次上的传输过程。然而,在此之下(即链路层面/网络层面及传输层面),它们并不具备对该层次结构的理解或操作能力。
1.1、IP协议
作为支撑互联网通信的基础架构,IP被视为一个关键组件。它通过提供可靠的数据分组传输服务,在不同网络设备之间建立连接,并确保数据按原路经传输以完成数据转发任务。需要注意的是,在这一过程中,IP仅提供一种无连接、不可靠的数据包传输服务。
发送端:获取自传输层协议的数据分组(PDU),在其基础上封装上IP头部以形成IP数据报,并将该数据报传递给下一层的链路层协议处理。
接收端从链路层接收PDU,并去除其IP首部;依据其携带的协议标识(TCP、UDP或其他),将数据按协议类型分配到传输层相应的TCP、UDP或其他协议下进行处理
IP主要包含三方面内容:IP编址方案、分组封装格式及分组转发规则。
- 路由器:
运行在网络层上的一台设备处于IP协议栈的核心地位,并负责完成传输层以下的各项任务。该设备配备两个及以上专用端口用于连接不同子网段,并能接收来自任意一个接入端口的IP数据报(分组),将其成功转发至指定的目标端口。具备多路介质访问能力的主机能够执行数据包转发功能,并根据需求选择性地发送至目标子网段中的相应端口;这种特殊的装置通常被称为路由器。
-
IP协议的格式规定如下:
-
一个IP数据报应包含以下内容:
- 其中的首部字段由前20字节构成。
- 其中第5位至第8位为版本字段(共4位),用于区分IPv4和IPv6。
- 第9至第12位为长度字段(共4位),表示该IP首部的实际长度。
- 第13至第18位为标识字段(共6位)。
- 第19-23位为标志字段(共5位)。
- 第24-39位为分片偏移字段(共16 bits)。
- 第40-63 bits 为主数据区的第一部分(共24 bits)。
- 第64-77 bits 为主数据区的第二部分(共13 bits)。
- 第78-91 bits 为主数据区的第三部分(共13 bits)。
- 最后8 bits 为主数据区的最后一部分(校验和)。
-
源端地址由第96-127 bits 表示;
-
目端地址由第128-159 bits 表示;
-
数据选项由后续各选项组成;
-
每个选项的最大长度不超过指定值;
-
校验和位于主数据区之后并单独占用了最后8 bits的位置;
-
数据流量
-
不可见于高层协议的数据包流(Packet Flow),通常来源于多种传输介质如TCP、UDP等。
-
无需关注其在IP层的具体表现。
-
无需深入探讨细节。
-
IP协议转发流程:本节将重点探讨基于网络层的IP协议转发机制。
-
A向网络层发送目的为C的IP数据包。
-
该系统通过路由查找确定下一传输节点。
-
数据包随后立即被转发至节点E。
-
节点E通过路由查找确定其下一个传输节点。
-
随后立即转发至节点F。
-
节点F再次进行路由查找后确认其与目标节点C之间存在直接连接关系。
-
即可直接传输至目标节点C。
1.2、TCP协议
传输控制协议(TCP)负责提供面向连接的可靠数据传输服务。其中,在确保数据完整性方面,TCP依靠校验和来检测潜在的数据损坏;为了保证消息顺序性,在信息传递过程中会利用序列号及相应的确认应答;为应对网络拥塞问题,在发现拥塞时会启动重传机制;此外,在建立与远程主机的连接时会采用专门的连接管理技术;为了优化通信效率,在发送数据流量较大的情况下会采用窗口控制策略以避免过度发送数据流。
三次握手过程:在正式使用之前,先要检测网络是否通畅,具体过程:
- 客户端发起建立TCP连接时,在头部中设置同步位SYN=1、初始序列号seq=x,并发送一个SYN_SENT(同步已发送)控制字。
- 服务器接收到客户端的SYN_SENT控制字后,在同一点上设置SYN=1、ACK=1、ack=y+1、初始序列号seq=y,并切换至SYN_RCVD(同步已接收)状态。
- 接收方在接收到服务器方的ACK报文段后,在其序列号字段中设置ack=y+1、seq=x+1,并切换至ESTABLISHING(正在建立中)状态。
- A在完成上述操作后切换至ESTABLISHED(已经建立)状态。
总结:建立连接时将同步位设置为SYN=1,在接收方确认时将确认位设置为ACK=1(根据TCP规定,在SYN报文段无法传输数据但需占用一个计数器资源;而ACK报文段允许传输数据若无数据传输则计数器资源也不被占用)。
四次挥手过程:挥手就是断开连接的过程,具体过程:
* A的应用进程先向B发送连接释放报文段(终止控制位FIN=1,序号seq=u),并停止发送数据,进入FIN-WAIT-1(终止等待1)状态。
* B收到连接释放报文段后即发出确认报文段(确认位ACK=1,序号seq=v,确认号ack=u+1),然后B进入CLOSE-WAIT(关闭等待)状态。此时A到B方向的连接已经释放,B若要发送数据,A仍要接收。
* A收到来自B的确认后,就进入FIN-WAIT-2(终止等待2)状态,等待B发出的连接释放报文段。
* B若没有要向A发送的数据了,就发送连接释放报文段(终止位FIN=1,序号seq=w,确认号ack=u+1),然后B就进入LAST-ACK(最后确认)状态,等待A的确认。
* A收到B的连接释放报文段后,必须对此发出确认(ACK=1,ack=w+1,seq=u+1)。然后进入TIME-WAIT(时间等待)状态。此时,TCP连接还没有释放掉。必须经过2倍最长报文段寿命(MSL)时间后(通常MSL=2分钟,保证A发送的最后一个ACK报文段能够到达B,防止“已失效的连接请求报文段”出现在本连接中),TCP连接结束。
总结:请求释放连接则置FIN=1,确认释放则置ACK=1。
保活计时器:
- 当客户端主机出现故障时, 服务器会一直处于等待状态. 为此, 需要设置存活计时器. 每当服务器接收到客户端的数据后, 就会重置存活计时器, 通常为两小时. 若在两小时内未接收到客户端的数据, 服务器就会发送一个探测报文段, 并每隔75秒发送一次. 若连续发送9个探测报文段后仍未收到客户的响应, 服务器就会认为客户端出现了故障, 接着关闭该连接.
- 在 Linux 操作系统层级上, 同理也有三个与 Keep-alive 相关的全局配置参数:
- net.ipv4.tcp_keepalive_time = 7200 seconds (2 hours): 探测间隔时间
- net.ipv4.tcp_keepalive_probes = 9: 探测无响应时最多可发送的连续探测次数
- net.ipv4.tcp_keepalive_intvl = 75 seconds: 探测无响应后连续探测的最大间隔
由8个位组成的字段称为控制位。这些自左至右依次为CWR、ECE、URG、ACK、PSH、RST、SYN和FIN。这些标识被称为控制位。FIN标志用于表示断开连接。当值为1时, FIN标志指示不再发送后续数据包。SYN标志当值为1时, 表示希望建立新的连接通道。RST标志当值为1时, 表示必须立即断开当前的TCP连接, 因此必须强制重置连接状态。PSH标志当值为1时, 表示传输的数据应立即提供给上层应用层处理;如果值是0,则可暂时缓存数据以等待后续处理请求。ACK标志当值为1时, 表示接收方确认已收到当前的数据包段,并认为该数据段是有效的(在三次握手过程中, SYN包之外的所有确认应答字段必须设置此标记)。URG(紧急)标记当值设为1时, 表示存在紧急的数据需要传输处理。ECE(拥塞)标记当值设为1时, 表示从发送端到接收端的网络流量出现拥堵情况需引起注意并采取相应措施以避免拥塞问题发生。CWR(确认重传)标记与ECE一起使用于IP协议头部中的ECN(有效窗口大小指示)字段中
2、HTTP协议
2.1、简介
Hypertext Transfer Protocol (HTTP) 是超文本传输协议(HTT)的基础标准。
该协议用于从万维网服务器将超文本数据按需求传递至本地浏览器。
- 每份万维网文件均需遵循此标准。
- 此方案旨在针对 web 浏览器与 web 服务器之间的通信而开发,并同时也具备广泛的应用前景。
- 基于 TCP/IP 协议遵循的形式,则以遵循 TCP/IP 协议的形式传输数据信息。
HTTP协议主要通过TCP协议进行编码,在某些情况下也会采用TLS或SSL协议层进行编码,在这种情况下就被我们称为HTTPS。
- World Wide Web (WWW):全称为"World Wide Web"(世界 wide web),其缩写为www;也被称为Web(网络)、3W(三 Win——赢利、共赢和世界)等。它是一个分布式的超媒体系统。
- Hypertext是一种包含指向其他文档导航链接的文字信息;单个hypertext文档通常由多个信息源构成;而hypertext文档仅包含文字信息;而hypermedia文档则包含了除文字外其他表示形式的信息(如图片、声音、动画和视频等)。
- Uniform Resource Locator (URL):统一资源定位符是"Uniform Resource Locator"(统一资源定位符)的缩写;它实际上是互联网上资源的地址;其格式为<协议>://<主机>:<端口>/<路径>;这样就能给一个文件在整个互联网上定位。
2.2、工作原理
浏览器作为HTTP客户端,通过url发起一个请求时:
通过解析访问的域名确定其对应的IP地址
-
当采用CDN服务时,
DNS返回的是通过CNAME记录指向云服务器负载均衡系统: -
通过解析用户的IP地址,
获取地理位置信息; -
根据用户所在通信运营商的核心网,
选择地理位置相近的核心节点; -
评估这些核心节点当前的负载情况,
并优先选择负载较轻的节点; -
其他因素如节点的"健康状况"、服务能力、带宽限制以及响应时间等;
-
首先创建TCP套接字连接,并向其发送HTTP请求;
-
当web服务器接收到来自客户端的HTTP请求后,则生成响应数据并返回给客户端。
在接收到返回信息后,服务器将通过检查connection的状态来决定下一步操作。若发现connection状态为close,则服务器将主动终止该tcp连接;与此同时,在线客户端也将被迫退出该tcp连接的建立过程。最终我们将该tcp连接标记为已关闭。
当connection处于keepalive状态时,在该连接所持续的时间段内双方能够维持通信。最终,在这段时间结束时客户端接收的内容即为客户端浏览器所接收的纯HTML内容,并将自行解析并展示给用户。这是整个HTTP协议运行的基本流程。
- 单线性机制规定每次连接仅能接收一个请求;服务器完成接通后立即断开连接。
- 该协议在事务处理方面缺乏记忆能力。
- 仅允许客户端发起请求;服务端无法主动推送消息。
2.3、协议版本
2.3.1、HTTP/1.0
在 HTTP/1.0 协议中, 当一个 HTTP 请求接收到服务器的响应后, 会关闭对应的 TCP 连接. 每次这样的操作都会导致重新创建 TCP 连接, 而整个过程反复建立和关闭 TCP 连接相对费时. 为了提高资源利用率, 可以配置头部字段 Connection: keep-alive, 在完成当前 HTTP 请求后, 当前的 TCP 连接不会被切断, 后续的所有 HTTP 请求就可以继续利用该现有 TCP 连接进行通信.
大部分的浏览器对于1.0的支持已经废弃掉了。
2.3.2、HTTP/1.1
主流当前采用的版本号通常是1.1,在该标准中会记录Connection项,默认设置为keep-alive。只有当明确指定Connection: close时才会在处理完该请求后断开TCP连接。
主要通过文本传输机制实现通信中的一次连接通信功能,在这一时间段内仅能处理一个HTTP请求(尽管存在Pipelining技术允许多个请求在传输过程中同时发送;然而,在实际应用中仍面临诸多难以解决的问题;因此,默认情况下浏览器并未启用多线程处理机制)
当浏览器发起页面资源请求时,在同一个TCP连接上会依次处理多个HTTP请求;这使得浏览器的并发能力得以体现
-
缺陷
-
长时间等待 — 首条请求阻塞(Head-Of-Line Blocking)
- 当一个按顺序发送的请求因故被阻塞时,在其后的所有等待请求也会受到影响。
-
非加密传输方案存在安全隐患:即数据未采取加密措施,在传输过程中可能遭到篡改或劫持。
-
该系统不具备向服务端推送消息的能力。
一个Chrome窗口对同一网站的不同子域最多可同时发起六个TCP连接。如果窗口数量多于该限制时会被阻塞。不同浏览器实现该限制的方式有所不同因此:
将同一页面的资源分散至多个子域后可提升单窗口最大连接数
减少单页面发起的网络请求数量
In-line some resources: CSS, base64 images等。
The latter can be merged to reduce the number of resources loaded.
2.3.3、Http/2
基于 SPDY,专注于性能,最大的一个目标是在用户和网站间只用一个连接。
传输方式:在一个域名内建立一个TCP连接作为通道,在此通道上实现所有HTTP请求的数据按流(stream)的形式进行上传,在这个通道上所定义的所有流都是基于同一个IP地址的空间分配机制实现的。其中每一个流都由多个帧(frame)构成,在这些帧中包含着一系列相关的控制信息和用户数据信息等关键字段;其中最重要的字段就是identifier字段;该字段用于标识某一个特定的数据块属于哪个具体的流;当两个或多个frame拥有相同的identifier值时,则表示它们属于同一个特定的数据传输流程;在接收端服务层端点处可以通过解析这些带有相同标识符的信息来恢复出对应的原始数据序列;在一个给定的`TCP连接通道上允许多个不同的数据流同时存在并共用同一个通道带宽资源;这种特性正是使得整个网络通信效率得以显著提升的关键技术基础——即所谓的多路复用机制。
每个视频帧(frame)都包含若干关键参数如长度(length)、类型(type)、标志位(flags)、流标识符(stream identifier)以及承载数据(frame payload)等信息内容。关于帧的类型参数(type),在HTTP/2协议中被明确规定为共10种不同的类型设定。
- HEADERS(包含HTTP头和可选的优先级参数)
- DATA(流的核心内容)
- PRIORITY(流的优先级)
- RST_STREAM(终止流)
- SETTINGS(设置此连接的参数)
- PUSH_PROMISE(服务器推送信息)
- PING(RTT测量工具)
- GOAWAY(断开连接操作)
- WINDOW_UPDATE(流量控制协商模块)
- CONTINUATION(继续传输头部信息块)
frame中的PRIORITY字段不仅用于表示流的权重(1-256)以及相关的依赖关系,并且反映了按照正确的顺序提交请求对用户体验的影响至关重要。
- 客户端利用对象间的依赖关系向服务器告知哪些资源应以高优先级传输。
- 权重协助服务器识别具有共同依赖关系资源的重要程度。
服务器按照依赖逻辑和优先级系数完成带宽分配任务,在关键资源上承担更大的带宽份额。
ps: 服务端针对高优先级资源采用了提供更多带宽的方法,并不确保该资源会实现优先返回;这种做法是为了防止出现线头阻塞的情况。
分路传输使http请求费用降低。
生成一个新的数据流成本不高。
理论上讲, 可以同时发起无数个请求。
然而, 在stream的对象中配置属性streamSettings来限定最大并发数
二进制分帧:
- 未更改HTTP1的核心功能,但仅在传输层采用了二进制分组的技术。
因此,在应用层引入了新的数据传输单元:帧、消息、流。 - 服务器端接收的请求量增加后可提升并发处理能力。最重要的意义在于:
实现了多路通信的基础支撑。
多路复用:
解决了HTTP/1.1的连接阻塞问题,在Web应用开发中被广泛采用。
每个域名对应一条专用连接,在Web应用开发中被广泛采用。
每个流量代表了完整的客户端-服务器通信过程。
数据帧是数据传输的基本单位。
每个数据帧会携带所属流量信息。
流量由多个数据帧组成。
多路复用技术允许在一个TCP连接中同时支持多个数据流量传输。
服务端push推送:
- 当TCP连接建立后, 服务器能够主动发送资源而非由客户端发起请求. 该过程是基于帧中的PUSH_PROMISE字段来实现的, 而且服务端所推送的资源能够被缓存下来.
- 浏览器通过查看PUSH_PROMISE字段来判断该资源是否已经被缓存. 在此过程中, 浏览器会发送RST_STREAM帧以终止后续的数据推送. 实际上只有在需要时才会发送该地址信息, 这样做的目的是为了减少不必要的数据传输.
根据HTTP/2协议的规定,在数据传输过程中,客户端发起的所有数据流都分配了奇数值的stream identifier;而服务器发送的数据流则采用了偶数值作为stream identifier。
头压缩
在HTTP 1.x版本中, HTTP协议由状态行,头部,正文三部分构成,传输过程中正文内容通常会经过gzip压缩,或者以二进制流形式直接传输(如视频,图片等)。而报头及状态行则均为纯文本形式传输。
此外,大量字段冗余现象普遍存在,例如COOKIE, UserAgent等字段占用过多带宽资源,导致网络延迟上升。尤其当请求报头大小超过正文内容时更是如此。
HTTP/2采用了静态与动态编码策略来优化首部压缩:
·静态编码表包含通用的报头名称及其值组合,例如method: GET;
·动态编码表则针对每个TCP连接独立维护特定键值对集合;
·所有不存在于上述两种编码表中的信息则采用哈夫曼(霍夫曼)编码进一步优化体积。
2.3.4、Http/3
HTTP2.0不足:
- 建立连接耗时较长(源自TCP协议的固有机制)
- 队列头阻塞现象主要由以下几个原因引起:一是源于TCP层的丢包及重传机制;二是由于HTTP/1.0协议中的管道式通信机制。
- 在移动互联网领域表现欠佳(主要体现在弱信号环境下),这与信道条件较差密切相关。
HTTP3.0由来:
TCP协议相对缓慢,谷歌决定-基于UDP来开发新一代HTTP协议。
基于UDP框架进行改造的一个新协议继承了TCP的一些优势:QUIC协议(Quick UDP Internet Connections),其名称来源于快速实现数据传输的技术
HTTP/3.0也被称作HTTP Over QUIC这一技术路线,在网络传输层不再依赖传统的TCP传输层协议而是采用了全新的基于UDP传输层协议的新架构。
优劣势:
该问题:QUIC协议采用UDP协议作为其传输层协议的基础,在单个通道内允许多个数据流同时上传输。各数据流之间相互独立;当任一数据流发生丢包时,其影响范围极小,从而有效缓解了队头阻塞现象。
0RTT 建链:RTT Round-Trip Time,也就是数据包一来一回的时间消耗。
- HTTPS 协议用于建立完整链接, 其中包含 TCP 握手和 TLS 握手过程, 通常需要 2 到 3 个 RTT 时间, 普通 HTTP 协议同样需要至少 1 个 RTT 时间才能完成整个握手流程。
- 在 QUIC 协议下, 客户端与服务端在首次连接时通过 1 个 RTT 时间进行密钥交换; 非首次连接则可直接省去密钥交换步骤, 实现无往返时间(0 RTTs)。
连接迁移:
TCP协议通过五元组的形式来表示一条独特的连接通道。在从4G网络切换至Wi-Fi网络的过程中, IP地址会发生变更,在这种情况下需要建立新的TCP连接才能确保数据传输的连续性。
QUIC协议摒弃了传统的五元组机制,并采用64位随机数作为专用标识符,并将该标识符用于标识特定的通信连接。在更换网络或不同基站间切换时无需进行端到端的数据重传操作,这种特性显著提升了业务层面的服务质量。
然而,在TCP协议具有强大影响力的情况下,一系列网络设备对UDP数据包采取了不利于其传输的措施,并进行了阻止,从而直接降低了成功连接率。
Q:如何用UDP协议来实现TCP协议的主要功能?
以UDP主体为基础,在用户空间中转移TCP的重要功能,并通过避开内核层的干预来达成用户态下的TCP协议机制。
2.3.5、HTTPS
增强型HTTP协议基于TLS/HTTP两层架构设计,支持数据加密传输和身份认证功能。
http协议作为超文本传输协议的实现方式,在信息传递过程中采用明文传输方式;而https则基于 TLS 加密技术进行数据的安全交换与存储。默认情况下,默认端口为443
HTTPS协议需要到CA申请证书,一般免费证书很少,需要交费。
为在线通信建立加密连接的标准通信协议...是SSL(Secure Sockets Layer)系统的核心功能。该协议通过相互认证、采用数字签名确保完整性、采用加密技术保证机密性等机制实现客户端与服务器之间的安全通信。
基于SSL 3.0开发的协议被称为 TLS/传输层安全技术委员会 (IETF) 设计。其版本是对SSL的安全增强。两者之间并无显著差异。主要包含两部分:包括 TLS 记录协议以及 TLS 握手协议。
2.4、协议详解
2.4.1、请求信息
请求行:例如GET /images/logo.gif HTTP/1.1(请求方法 空格 url 协议);
* 它主要支持的请求方法有get、post、put、head、delete、options、trace和connect。
* get:获取资源;
* post:传输一些内容;职能偏向于“新增”;
* put则:将文件和内容传输到服务器上;职能更偏向于“更新”(幂等);
* head:只通过报文的头部来做通信;
* delete:删除文件(幂等);
* options:向服务器去请求了解服务器支持哪些方法;
* trace:调试方法,使服务器原样返回客户端请求的任何内容,主要用于测试或诊断。
* connect:希望通过哪些隧道协议来连接。
- GET与POST的区别:
- GET方法将数据放置在URL后端部分,在HTTP消息体中存储的是请求参数。
- GET操作通常受到文件大小限制(最大容量通常被限制在1024字节(主要影响URL长度)),而POST操作不受此限制。
- 数据获取途径存在差异:GET使用Request.QueryString属性来获取变量值;而POST则通过Request.Form属性获取。
- 在GET操作中出现的安全隐患在于其呈现于URL路径上,在历史记录中可查询到相关用户的信息。
请求头:例如Accept-Language: en;
- Host字段表示请求目标服务器的IP地址和端口号。
- Connection字段表明该请求支持长连接(keep alive)功能。
- Content-Length字段定义了响应正文内容的总长度。
- Content-Type字段指定响应正文的数据类型。
- User-Agent字段用于标识发送请求的客户端操作系统和浏览器版本信息。
- Accept-Encoding头指示客户端可接受的数据编码格式。
- Accept-Language头指示客户端能理解的语言种类。
- Cookie字段通常用于实现会话(session)功能。
- Authorization头包含服务器验证用户代理身份所需的凭证信息。
- Range字段定义了可传输的数据块范围(例如bytes=500-600,601-999;bytes=-500;bytes=500-;bytes=0-,-1),但需要注意的是,在某些情况下(如无条件GET请求),服务器可能会忽略此Range头。
空行
请求体(可选)
2.4.2、响应信息
状态行:HTTP-Version 空格 Status-Code 空格 Reason-Phrase CRLF
Code是结果代码,用三个数字表示,主要分为五类:
以1开头的往往表示请求正在处理过程中;
* 100——客户必须继续发出请求
* 101——客户要求服务器根据请求转换HTTP协议版本
以2开头的则表示请求已经成功得到了处理;
- 200号码表示请求已成功处理
- 201号码引导用户获取新文件链接
- 202号码确认请求已接收但未全部处理完毕
- 203号码反映返回数据不完整或信息不确定
- 204号码显示服务器已接收请求但无相应响应内容
- 当前任务已完成要求客户端复位之前浏览的所有文件
- 假设当前任务已完成要求客户端复位之前浏览的所有文件
以3开头表示资源需要进一步的操作,并且往往表示一种重定向连接;
- HTTP 300头信息表明请求资源可以从多个位置获取
- HTTP 301头信息表示当前页面已被永久重定向到指定的URL地址
- 当一个请求指向某网页时,服务器返回HTTP 302头信息,并将 redirect header字段设置为新URL地址;客户端会根据此字段跳转至新位置,并重新发起请求
- 服务器建议客户端通过其他路径访问目标资源
- HTTP 304头信息表示目标资源在过去一段时间内没有发生变更
- HTTP缓存机制已移除不再使用的旧版本代码
- HTTP/1.1 306状态码表明前一版本HTTP中使用的代码不再使用
- 指示客户端临时移除该资源的方法头标志是HTTP/1.1 307 头信息
以4开头表示这个服务器无法处理这个请求;
400——客户端请求有语法错误,不能被服务器所理解
401——请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用
HTTP 401.1 - 未授权:登录失败
HTTP 401.2 - 未授权:服务器配置问题导致登录失败
HTTP 401.3 - ACL 禁止访问资源
HTTP 401.4 - 未授权:授权被筛选器拒绝
HTTP 401.5 - 未授权:ISAPI 或 CGI 授权失败
402——保留有效ChargeTo头响应
403——禁止访问,服务器收到请求,但是拒绝提供服务
HTTP 403.1 禁止访问:禁止可执行访问
HTTP 403.2 - 禁止访问:禁止读访问
HTTP 403.3 - 禁止访问:禁止写访问
HTTP 403.4 - 禁止访问:要求 SSL
HTTP 403.5 - 禁止访问:要求 SSL 128
HTTP 403.6 - 禁止访问:IP 地址被拒绝
HTTP 403.7 - 禁止访问:要求客户证书
HTTP 403.8 - 禁止访问:禁止站点访问
HTTP 403.9 - 禁止访问:连接的用户过多
HTTP 403.10 - 禁止访问:配置无效
HTTP 403.11 - 禁止访问:密码更改
HTTP 403.12 - 禁止访问:映射器拒绝访问
HTTP 403.13 - 禁止访问:客户证书已被吊销
HTTP 403.15 - 禁止访问:客户访问许可过多
HTTP 403.16 - 禁止访问:客户证书不可信或者无效
HTTP 403.17 - 禁止访问:客户证书已经到期或者尚未生效
出现了一个...标识符时,则表示系统已建立可达服务器连接但未能成功获取目标页面内容。此页面内容因缺少相关资源而无法被访问到。例如:用户输入了无效链接。
405——用户在Request-Line字段定义的方法不允许
406——根据用户发送的Accept拖,请求资源不可访问
407——类似401,用户必须首先在代理服务器上得到授权
408——客户端没有在用户指定的饿时间内完成请求
409——对当前资源状态,请求不能完成
410——服务器上不再有此资源且无进一步的参考地址
411——服务器拒绝用户定义的Content-Length属性请求
412——一个或多个请求头字段在当前请求中错误
413——请求的资源大于服务器允许的大小
414——请求的资源URL长于服务器允许的长度
415——请求资源不支持请求项目格式
416表示该请求包含了Range头部字段,在当前资源范围内未提供range指示信息,并且该请求未携带If-Range头部字段
417——当使用代理服务器时,在处理Expect字段时未达到预期值;其中原因之一是后续服务端未能满足请求长度。
以5开头则表示服务器处理这个请求,但是却发生了某些内部错误。
HTTP 500 - 服务器遇到错误,无法完成请求
HTTP 500.100 - 内部服务器错误 - ASP 错误
HTTP 500-11 服务器关闭
HTTP 500-12 应用程序重新启动
HTTP 500-13 - 服务器太忙
HTTP 500-14 - 应用程序无效
HTTP 500-15 - 不允许请求 global.asa
Error 501 - 未实现
HTTP 502 - 网关错误
HTTP 503 错误提示用户当前无法使用服务器,并因以下原因可能导致问题:系统超载或停机维护进行中;预计经过一段时间后服务器将恢复正常工作状态。
Reason-Phrase是个简单的文本描述,解释Status-Code,用于人工理解。
消息报头
- 允許
- 內容碼元
- 內容長度
- 內容類型
- 日期
- 到期日
- 最新修改日期
- 位置信息
- 刷新頻率
- 伺服器身份資訊
- 頋号文件名稱
空行
响应体
2.4.3 content-type
在URL中,“.php”、“htm”等字段定义网络文件类型,“charset=gbk”等字段指定网页字符集代码,则决定浏览器以哪种格式和使用哪种字符集代码来解析这个资源文件。
常见的媒体格式类型如下:
- text/html : HTML编码
- text/plain : 原始文本形式
- text/xml : XML编码
- image/gif : GIF动画图档
- image/jpeg : JPEG图形交换文件
- image/png: PNG位图文件
以application开头的媒体格式类型:
- XHTML文档的标准表示方式:XHTML格式。
- 基于XML的数据表示方法:application/xml。
- 用于聚合和管理 Atom 格式的文件内容:application/atom+xml。
- JavaScript对象表示(JSON)的形式:application/json。
- PDF文件的标准存储和交换方式:application/pdf。
- 微软Word软件中常用的文档存储方式:application/msword。
- 通常用于非文本类型的数据传输和二进制文件操作:application/octet-stream。
- 编码方式上采用表单默认情况下的提交数据编码方法:application/x-www-form-urlencoded。
另外一种常见的媒体格式是上传文件之时使用的:
- multipart/form-data : 需要在表单中进行文件上传时,就需要使用该格式
2.5、认证方式
HTTP请求报头: Authorization
HTTP 响应:响应头信息中包含状态码 401 和未授权(Unauthorized); 报告头(Report Header)中包含认证头(Authenticate header)的基本认证机制,并指定认证.realm为 WallyWorld。
HTTP认证是基于质询/回应(challenge/response)的认证模式。
- 基本认证 basic authentication(HTTP1.0提出的认证方法)
将用户名+冒号+密码经BASE64编码生成的字符串传输至服务端指定的Authorization字段中,并采用Basic数据格式进行编码。
客户端发起GET请求
服务器返回401 Unauthorized状态码,并对WWW-Authenticate认证算法和实现实域进行了配置。
客户端重新发起请求,Authorization指定用户名和密码信息
服务器认证成功,响应200
- 摘要认证 digest authentication(HTTP1.1提出的基本认证的替代方法)
摘要认证过程采用了随机数值结合MD5算法来进行用户账户信息的安全加密操作。当执行第二步骤时服务器返回一个随机字符串nonnce值作为辅助数据字段。随后客户端将向系统提交带有以下计算结果作为摘要验证信息:摘要值等于非ce与HA1以及HA2经过特定运算后的综合结果,并且其中HA1是由该系统利用MD5算法计算得出,并基于 username、realm和 password字段生成;同样地 HA2则由该系统利用 MD5算法计算生成并基于 method参数与其 digestURI路径资源相关联的结果值组合而成
HTTP OAuth Authentication
开放身份认证使得个人用户能够授予一个令牌,并非凭用户名和密码而是凭这个令牌来获取其存储于特定服务者数据中的信息。每个这样的授权请求都会被提交到相应的第三方系统。
HTTP协议中的Token认证机制
在用户首次登录时,服务器会创建一个Token并将该信息发送给客户端机器.在后续的所有访问中,客户端会携带该Token,并不需要再次提供用户名和密码.
