网络编程（3）：HTTP协议详解

最新推荐文章于 2024-08-20 00:22:10 发布

luozhiwei_iOS

最新推荐文章于 2024-08-20 00:22:10 发布

阅读量1.2k

点赞数

本文链接：https://blog.csdn.net/luozhiwei_iOS/article/details/56290814

版权

HTTP：WEB的基础
1. HTTP概述
2. URL与资源
3. HTTP报文
4. 连接管理
HTTP结构
1. WEB服务器
2. 代理
3. 缓存
4. 集成点：网关、隧道和中继
5. WEB机器人
6. HTTP-NG
识别、认证与安全
1. 客户端识别与cookie机制
2. 基本认证机制
3. 摘要认证机制
4. 安全HTTP
实体、编码与国际化
1. 实体和编码
2. 国际化
3. 内容协商与转码
内容发布与分发
1. Web主机托管
2. 发布系统
3. 重定向与负载均衡
4. 日志记录与使用情况跟踪
参考文章

备注：本文章主要记录《HTTP权威指南》每章节的重要知识点。

1、HTTP：WEB的基础

1.1HTTP概述

HTTP事务：

一个HTTP事务由一个HTTP请求与一个HTTP响应组成

HTTP方法：

GET: 从服务端向客户端发送命名资源

HEAD: 仅发送命中资源的头部

POST: 将客户端数据发送到服务器网关应用程序

PUT: 将来自客户端的数据存储到一个命名的服务器资源中去

DELETE: 从服务器删除命名资源

TRACE: 用户跟踪报文的传递路径

OPTIONS: 获取制定URL能接受的请求方法

CONNECT: 连接制定的频段。

HTTP状态码：

1xx:信息响应类，表示接收到请求并且继续处理

2xx:处理成功响应类，表示动作被成功接收、理解和接受

3xx:重定向响应类，为了完成指定的动作，必须接受进一步处理

4xx:客户端错误，客户请求包含语法错误或者是不能正确执行

5xx:服务端错误，服务器不能正确执行一个正确的请求

HTTP协议版本：

HTTP/0.9 - 》 HTTP/1.0 -》 HTTP/1.0+ -》 HTTP/1.1 -》 HTTP-NG（又名：HTTP/2.0）

现在1.1是常用版本，HTTP2.0还在研发ing。

WEB的结构组件：

代理：位于客户端和服务器之间的HTTP中间实体。
缓存：HTTP的仓库，可以减少资源的请求距离与请求次数。
网关：用于连接别的协议程序的服务器。
隧道：对HTTP报文进行盲转发的特殊代理。
Agent 代理：发起自动HTTP请求的半智能WEB客户端。

1.2、URL与资源

URI、URL与URN三者之间的区别
URL语法
URL的快捷方式
URL encoding&decoding

URI、URL与URN三者之间的区别：

URI（uniform resource identifier，统一资源表示符）
- URL（uniform resource locator）
- URN（uniform rescue name）

URL与URN都是URI的子集，URI定义了一系列获取资源的地址规范，而两个子集都是在其的基础下构建出来的。目前互联网上基本都使用URL，所以也主要论述URL的相关知识。

URL语法：

URL的主要由9个部分构成的通用格式如下：

主要组件介绍：

scheme（方案）：确定用什么协议来访问服务器，如HTTP、HTTPS、FTP、FILE
user，password（用户名与密码）：部分资源的访问是需要用户名和密码来访问，但现在很少使用。
host、port（主机号与端口）：用于定位目标资源所在的服务器的服务端口号
path（路径）:用来描述资源在服务器的访问路径
param（参数）：部分path的访问是需要补充参数的，param以key=value的形式添加在路径上，如path1；key1=value；key2=value/path2/path3
query：（查询字符串）：查询字符串跟随在path后面以？为起始，格式和param类似，但是以&相互隔离，如path？key1=value1&key2=value2。。。
flag（片段）：某些资源类型，如HTML，除了资源级的访问，还希望能更加细分，于是就引入了flag机制，通过flag可以指定访问资源的某一段，如平时浏览网页时就可以通过flag来分段加载。

scheme的方案种类（提供的访问协议）：

http：
https：
mailto：
ftp：
rtsp 、 rtspu :
file：
news：
telnet：

URL的快捷方式：

相对URL与绝对URL：

上文提及的都是绝对URL，相对URL实际上就是一个不完整的URL，关系公式如下：

绝对URL = 基础URL + 相对URL

使用相对路径时，系统会设法把相对路径补全为绝对路径来访问资源，使用相对路径有比较多的好处，其中最为重要的一点就是这个路径能适应于不同的系统，只要把基础路径替换掉即可使用。

自动扩展URL：

浏览器能够自动扩展URL，这就是为什么有时候我们仅仅输入网址的一部分就能访问到相应网页的原因。其中主要由以下两种方式实现自动扩展：

主机名扩展：浏览器先分析用户输入的URL，然后根据用户缺少的部分，特别是主机名，按照常用的规则进行补全。
历史扩展：通过输入的url与曾经访问的网页，来匹配缺少的组件，从而补全URL。

URL encoding&decoding:

URL作为网络统一的资源访问器，必然会兼容很多国家不同语言的各种文字编码规范。

对于中文，中文通常不能直接用于URL是的，最好通过url-encoding使用，才能正常在网络上传输。

为了避免安全字符集表示法带来的限制。引入了名为“转义序列”的编码机制。

将所有的不安全的符号，全部通过%（表示转义）+ 在AESii码的十六进制来表示。

具体可以参考:RFC 2396

1.3、HTTP报文

HTTP报文的语法
起始行详解
首部详解
实体详解

HTTP报文就是HTTP程序之间发送、接收、处理的数据块，等于就是HTTP的数据结构。

HTTP使用术语流入（inbound）和流出（outbound）来描述事务处理的方向。

HTTP报文的语法:

HTTP报文的结构：

起始行
首部（Header）
实体（Body）

HTTP报文分两大类：请求报文、响应报文，它们的具体语法如下：

从上图可以得知，具体的差异仅仅是请求行。

请求报文：因为用于发起请求访问资源，所以得阐述用什么方法到哪个服务器获取什么资源，所以它就由 method + request-url + version组成。

响应报文：用于对请求的响应，所以主要需要阐述请求的结果与解析这个结果产生的原因，所有它就由 version + statuts-code + reason-phrase组成。

起始行详解：

从报文的语法可以得出起始行主要由请求的method+request-url与响应的status-code+reason-phrase，以及通用的version来组成。以下挑选部分重点说明一下：

method，7种请求方法如下所示：

GET：从服务器中获取一份文档（不包含实体）。
HEAD：只从服务器获取文档响应的头部（不包含实体）。
POST：向服务器发送需要处理的数据（包含实体）
PUT：将请求的实体直接存储在服务器上（包含实体）
DELETE：删除服务器响应的文件（不包含实体）
TRACE：对经过的代理服务器进行跟踪记录（不包含实体）
OPTIONS：请求服务器告知其支持什么功能（不包含实体）

status-code+reason-phrase：

status-code就是HTTP状态码是给计算机识别错误用的，而reason-phrase原因短语是给人来识别错误。

状态码分类如下：

首部详解：

首部主要有以下五种类型：

通用首部：提供与报文相关的最基础信息。其中包括via（记录报文经过的中间节点，包括代理、网关）、Date、Connection
请求首部：相关字段仅仅出现在请求报文，用于说明是谁或什么在发送请求，请求来源何处，或者客户端的喜好以及能力。如Host（主机号与端口）、User-agent（将发起请求的应用程序告知服务器）等等。
响应首部：相关字段仅仅出现在响应报文，响应首部提供一些额外的信息，如谁在发送报文、响应者的功能，甚至一些特殊指令。如vary、accep-rangs等等。
实体首部：用来描述HTTP实体部分，包括编码、类型、有效期之类的。如content-type、content-location、content-MD5、EXpires等等。
扩展首部：略。

更加具体字段解析，请参考《HTTP权威指南》。

实体详解：

略。

之后章节再说明。

1.4、HTTP连接管理

HTTP与TCP
HTTP连接的处理
HTTP的持久连接的实现

HTTP与TCP：

几乎所有的HTTP协议的通信都是由TCP/IP协议来承载的，而且HTTP是应用层协议，TCP是传输层协议，所以真正实现连接、传输、断开的是TCP协议，但可以通过HTTP协议的配置来定义TCP在实现时的效果。

用TCP套接字编程实现：

TCP性能考虑：

HTTP紧挨着TCP，所以HTTP事务的性能很大程度上取决于底层的TCP通道的性能，而传输数据的延迟的其实还好，造成延迟最严重的部分是TCP的连接的耗时。所以大部分的优化手段都是针对TCP的连接设计的。

影响TCP性能的五个主要要素：

TCP连接建立握手
TCP慢启动拥塞控制
数据聚集的Nagle算法
用于捎带确认的TCP延迟确认算法
TIME_WAIT时延和端口耗尽

所以进行HTTP优化的关键就是尽量去避免太多的TCP连接，尽可能地复用TCP传输通道，因为上面的1、2点都与连理连接相关的。

HTTP连接的处理：

1、Connection首部

可以用connection来主动关闭一个HTTP连接。

2、串行书屋处理延迟

通常一个HTML页面需要发起多个HTTP事务才能实现页面的显示。若串行去实现资源请求，大量的时间都会耗在TCP的连接与慢启动。

现存的几种提高HTTP连接性能的方案：

并行连接：就是发起多起HTTP请求，这样会提高网页的加载速度，但同时多个请求每个连接都会有延迟，并且每个事务都会对带宽资源进行争夺，也有可能并不会提升性能。
持久连接：就是让HTTP连接复用，减少创建的耗损，并且可以引入“并行+持久”的方案。
管道化连接：通过共享TCP连接来发起并发的HTTP请求。

HTTP的持久连接的实现：

通过设置Connection字段与Keep-Alive字段可以控制HTTP为长连接。如下：

Connection：keep-alive

keep-alive：max=5，timeout=120

其中max=5，指明还可以又5个事务复用这个HTTP连接，这不是一个承诺值。

其中timeout = 120，指明这个HTTP连接的生命周期由120s。

但可以通过设置Connection：close来实现关闭一个HTTP连接。

2、HTTP结构

2.1、WEB服务器

WEB服务器需要处理的事务

WEB服务器需要处理的事务：

1、WEB服务器的常规任务

建立连接 = 接收一个客户端连接，或者如果不希望与这个客户端建立连接则可以将其关闭。
接收请求 = 从网络中读取一调HTTP请求报文
处理请求 = 对请求报文进行解析，并采取行动
访问资源 = 访问报文中指定的资源
构建响应 = 创建带有正确首部的HTTP响应报文
发送相应 = 将报文发送会客户端
记录日志 = 将相关事务记录入数据库

2、接收请求报文的连接输入输出结构，一共有如下四种：

单线程IO结构：只建立一条线程，每次执行一个HTTP任务。

多线程IO结构：同时建立多个线程执行HTTP事务。

复用的IO结构：建立一个线程，但分时复用，那个事务需要进行数据处理则到线程中进行计算。

复用的多线程IO结构：原理与复用的IO结构一样，但是多个线程在执行。

上面四种结构，复用的多线程IO结构效率是最好的，以后的软件设计需要这种多线程任务调用也可以考虑这种方案。

3、重定向

WEB服务器有时会返回重定向响应，并且将重定向的URL置于Location中，让客户端能对新的url地址发起新的请求，通常有以下情况需要发起重定向：

永久搬离的资源：资源位置变更，为了兼容之前的URL。
临时搬离的资源：资源位置变更，为了兼容之前的URL。
URL增强：
负载均衡：服务器根据当前负载情况会通过重定向将客户端定向到别空闲的服务器进行服务。
服务器关联：某些服务器可能有用户的信息，所欲需要重定向到该服务中。
规范目录名称

2.2、代理

什么是代理
代理的作用

什么是代理：

1、web代理服务器的概念

WEB代理（proxy）服务器是网络的中间实体。代理是处理服务端与客户端之间，在各个端点回来处理经过它的报文，所以能在代理服务中部署很多的服务，将部分辅助功能从服务器中分离出去。

2、代理服务器的类型

私有代理：只为一个用户进行数据处理

共享代理：为N个用户进行数据处理与转发，集中式代理的成功与效率更好。

3、代理与网关

代理是多个协议的应用程序，是为了部署一些特殊的业务而存在的，如防火墙、WEB缓存。

网关主要协议的转换，若HTTP/FTP，就是实现HTTP流量转FTP流量而部署的。

代理的作用：

儿童过滤器（内容过滤）
文档访问控制：可以在访问资源前进行权限控制，能让不同权限的用户能看到不同的权限数据。
安全防火墙：可以用于限制什么协议的什么数据能通过网络。
web缓存：将常用文档存储为本地副本，并按需提供，较少互联网通信
反向代理：假装成web服务器的设备，它负责接收客户端的请求，并能转发给别的服务器。
内容路由器：根据网络流量状况以及内容将请求特定的服务器，若网络差时能让客户端优先访问web缓存之类的。
转码器：代理服务器在将内容发送给客户端之前，可以修改内容的主体格式，称为转码。如发给的是别的语言的浏览器，则转换成该语种的网页，又或者设备是手机，则转成手机格式。
匿名者：将HTTP报文中header中所有涉及用户隐私的字段都删除。

2.3、缓存

WEB缓存概述与作用
WEB缓存服务器的运作机制
HTTP如何实现缓存操作

WEB缓存概述与作用：

1、WEB缓存的作用：

减少冗余的数据传输，部分数据是重复请求的。
缓解网络瓶颈问题，不需要更多的贷款就能更好地加载页面。
降低原始服务器的要求，让服务器可以更快地响应，避免过载的出现，如发生突发事件，大家都同事访问一个web文档，这时web缓存就能避免瞬时拥塞，避免服务器宕机。
降低了距离时延。

2、WEB缓存的拓扑结构

缓存大概分两种：

私有缓存，通常是浏览器自建立的缓存数据库。
共有代理缓存，通过WEB代理服务器实现，维护区域性网络用户的共同的请求缓存数据库。

WEB缓存服务器的运作机制：

1、WEB缓存服务器对一条HTTP请求的处理流程如下：

接收，从网络中读取抵达的请求报文
解析，对报文进行解析，读取URL和各种首部
查询，查询本地副本是否存在，若没有则获取一份副本，并缓存在本地
新鲜度检测，若查询获得本地副本，则检查本地副本进行新鲜度检查，若不足够新鲜，则询问服务器是否需要更新，若需要则进行更新本地副本
创建响应，用新的首部和已经缓存的主体来构建一条响应报文
发送，将网络响应发回给客户端
日志，创建一条本地日志来描述这个事务

上面的流程其实与WEB服务器处理HTTP请求的流程是十分相似的，因为WEB缓存服务器实际上就是WEB服务器的代理，它替代WEB服务器接收请求并作响应的响应。

2、新鲜度检测

而WEB缓存最大的特点是新鲜度检测这个步骤，这个步骤通过报文的Cache-control、expires字段来检测文件是否过期，若过期则去询问服务器文档是否发生改变，若有则请求服务器重新获取一份文档，若无则更新该文档的cache-control、expires字段。而且新鲜度检查当且近且发生在用户发起请求的时机，这样可以减少无谓的操作。

HTTP如何实现缓存操作：

通过设置各种HTTP header的字段可以设置不同的缓存效果。

如设置缓存时间或等级的Cache-control、Expires，

如优化服务器再验证（新鲜度检查）的If-Modified-Since:Date、If-None-Match。

1、Cache-control与Expires

其中Expres是HTTP1.0的规范已经在逐渐淘汰，而Cache-Controll才是现在的主流的，Cache-Control的完整用法如下所示:

Cache-Control：no-store ,不会缓存在本地，用完立即删除。

Cache-Control：no-cache ,会缓存在本地，但每次使用前都必须经过新鲜度检测。

Cache-Control：must-revalidate ,让服务器严格遵守过期信息。

Cache-Control：max-age ,检测过期时间，若过期则需要进行新鲜度检查并更新缓存。

2、If-Modified-Since:Date与If-None-Match

If-Modified-Since:Date与If-None-Match的本质都是优化WEB缓存新鲜度检查者一块，把检查新鲜度的GET请求与获取新的文档的GET请求进行合并，提高效率。

但它们的差异是If-Modified-Since:Date是通过过期时间来判断文档是否过期，因为若服务器的文件进行修改则其修改时间就会不一致，则会请求相应文档。而If-None-Match是通过实体标签来比对是否修改的。

2.4、集成点：网关、隧道和中继

网关
隧道
中继

网关：

1、网关的主要作用：

协议网关
安全网关
资源网关

2、客户端网关与服务端网关

可以用一个斜杠来分隔客户端和服务端协议，并以此对网关进行描述：

<客户端协议>/<服务端协议>

服务器端网关（server-side gateway）通过HTTP与客户端对话，通过其他协议与服务端通信（HTTP/*）

客户端网关（client-side gateway）通过其他协议与客户端对话，通过HTTP协议与服务器通信（*/HTTP）

3、协议网关

协议网关就是负责协议转换的效果。如HTTP/FTP网关就是把HTTP转成FTP协议流量的网络设备。

4、安全网关

HTTP/HTTPS 服务器端安全网关：通过将组织内所有输入的WEB请求进行加密，直接走SSL通道进行传输HTTPS报文。

HTTPS/HTTP 客户端安全加速器网关：部署在服务器之前，只接收安全的HTTPS流量。

5、资源网关

最常见的网关，应用程序服务器，会将目标服务器与网关结合在一个服务器设备中实现。

客户端通过HTTP报文直接与服务器网关进行通信，然后服务器网关通过通过程序API转发响应的报文信息给应用程序，然后再将应用程序的输出封装成HTTP请求发送回客户端。

隧道：

1、建立HTTP隧道

通过HTTP的Connect方法可以建立隧道。通过Connect方法可以与任意协议的任意服务器建立TCP连接。

CONNECT请求的语法：

{

CONNECT www.baidu.com:443 HTTP/1.0

User-agent:Mozilla/4.0

}

CONNECT响应的语法：

{

HTTP/1.0 200 Connection Established

}

原因短语描述必须为“Connection Established”，但响应中不包括Content Type首部，以为此时连接只是对原始字节进行转接，不再是报文的承载者，所以不需要内容类型。

2、SSL隧道与HTTP/HTTPS网关的对比

HTTP/HTTPS网关的实现方式有如下三个缺点：

客户端到网关之间的连接还是普通非安全的HTTP协议
尽管代理是已认证主体，但客户端无法对远程服务端执行SSL客户端认证
网关要支持完整的SSL实现

而隧道的话，是直接地客户端与服务端进行SSL的HTTP通信，所以无需中间代理。

中继：

中继是没有完全遵循HTTP规范的简单的HTTP代理。中继负责处理HTTP中建立连接的部分，然后对字节进行盲转发。

所以中继只负责建立连接与盲转发的工作。

2.5、WEB机器人

WEB机械人又称“爬虫”、“蜘蛛”、“机器人”。通过递归的方式解析每个页面，并获取每个页面中包含的URL跳转地址与页面资源、文档，对资源文本进行分析整理成自己的数据库，然后按照预先设定的跳转规则自动地浏览网页，这就是WEB机器人。

WEB机器人的最关心的两个技术点：

避免跳转环路，若机器人陷入跳转环路，一来会机器人的工作就会失去意义，二来还会给网络带来负面的影响，如大量浪费某些服务器的资源访问带宽。
如何解析页面与获取资源、将资源整理成服务器，这也就是设计WEB机器人的目的所在。

2.6、HTTP-NG

还没研发成功，略。

3、识别、认证与安全

3.1、客户端识别与cookie机制

HTTP客户端识别实现方案
1. 承载用户信息的HTTP首部
2. 客户端IP地址跟踪，通过用户的IP地址对其进行识别
3. 用户登录，用认证方式来识别用户
4. 胖URL，一种在URL中嵌入识别信息的技术
5. Cookie，强大而高效的持久化身份识别技术

因为HTTP最初是一个匿名的通信协议，但WEB站点希望能提供个性化的接触，若提供个性化的问候、内容推荐、信息管理归档、记录会话等，所以就设计出以上几种HTTP客户端识别方案。

承载用户信息的HTTP首部：

From、User-agent、referee字段都不足以实现可靠的用户识别，仅仅能实现简单的识别。

客户端IP地址跟踪，通过用户的IP地址对其进行识别：

早起的WEB曾经尝试使用IP地址作为唯一的标识符来使用，但这个方案也有不少缺点：

IP地址对应的是设备而不是用户，无法处理多个用户在同一个机器上操作的场景
为了提供安全性与应用稀缺的地址的情况，一个组织的内网都是公用一个公共IP地址来与外网进行通行的，这种情况也无法处理
对于移动设备，特别如手机、平板电脑，每次IP地址都是随机分配的

所以IP地址的方案也不大可行。

用户登录，用认证方式来识别用户：

通过要求用户输入用户名与密码来进行认证（登陆）来显式地询问用户身份。

HTTP包含一种内建机制，可以通过WWW-Authenticate首部和Authorization首部向WEB站点传送用户信息。大致流程如下：

（a）客户端发起一个请求

（b）服务端返回401 login required，需要填写www-authenticate字段，网页显示登陆页面

（c）用户输入完后，转化成authorization字段

（d）验证成功。

胖URL，一种在URL中嵌入识别信息的技术：

有些站点会为每个用户生成特点版本的URL来跟踪用户的身份。改动后包含用户信息的URL称为胖URL（fat URL）。

通过生成用户ID，并将用户ID添加到URL中，如亚马逊、淘宝、CSDN技术博客、简书等网站经常使用这个技术。

Cookie，强大而高效的持久化身份识别技术：

Cookie是当前识别用户，实现持久化会话的最好方式。

1、Cookie的类型主要分为会话cookie与持久cookie：

会话cookie：是临时的，只为了记录当前页面，用户的定制化效果，一旦页面关闭，cookie也会删除。
持久cookie：是永存存储在系统的硬盘里面，适合用于网页的二次访问使用。

2、Cookie的工作机理：

（a）客户端发送请求到服务器。

（b）因为是首次访问，服务器通过set-cookie设置给当前访问的客户端打上标签。

（c）以后客户端的每次访问，都必须得带上已经设置好的cookie，服务端通过获取cookie来识别用户。

3、Cookie的首部

4、Cookie与会话跟踪

可以用Cookie在用户与某个Web站点进行多项事务处理时对用户进行跟踪。下面我们用Amazon购物网站为例子说明Web服务器如何通过一系列的充电箱、URL重写以及cookie设置来附加标识信息。

（a）首先用户访问www.amazon.com网站

（b）服务器将客户端重定向到一个电子商务软件的URL上

（c）对重定向重新发起一个URL请求

（d）服务端用set-cookie设置两个会话cookie。

（e）客户端根据cookie内容，拼接成一个胖URL，并重新发起请求

（f）服务器重定向到home。html，并附加两个ubid身份标识

（g）重定向到home.html，并将四条cookie都添加到header中，以后对该网站发起请求均会附加上这四条cookie信息

（h）服务器返回带有用户个性化设置的网页。

5、Cookie与缓存

略。

6、Cookie与隐私安全性

略。

3.2、基本认证

基本认证机制
基本认证的缺陷

基本认证机制：

基本认证与摘要认证都是HTTP定义的两个官方的认证协议，下面来概要说明基本认证的具体流程与实现。

基本认证是基于HTTP提供的“质询/响应认证框架”实现的，其具体流程如下图所示：

下图说明了质询/响应认证框架的流程中，具体是如何实现的：

可以看出主要是服务器通过WWW-Authenticate字段来告知客户端需要认证，且当前认证的安全域是哪个。

然后客户端用authorization字段将用户名与密码发送出去。

最后认证成功的话，服务端还会返回authentication字段来告知相应的附加信息。

下图为一个认证的具体事例：

基本认证缺陷：

基本认证通过网络直接发用用户名与密码，这些用户名与密码要么使用明文，要么使用简单的base64等可逆编码，容易被破解。但可以通过基本认证+SSL的方式来提高安全性。
没有什么措施来防止重放攻击
一些不良的习惯容易造成消极影响，如不同的安全域采用统一的密码
没有提供针对代理和中间人的节点的防护设置
假冒服务器容易骗过基本认证。

这一切说明，基本认证只适合用于友好的环境，又或者隐私保护需求不强的环境里。

3.3、摘要认证