目录

1. HTTP 协议概述

2. URL 与资源

3. HTTP报文

4. 使用Postman 获取数据

5. 基于HTTP协议的文件下载

5.1 文件整体下载

 5.2 文件分段（Range）下载

5.2.1 获取文件的大小

5.2.2 下载分段文件

5.3 文件分块（chunk）下载

---

1. HTTP 协议概述

日常我们使用网络用得最多的无疑是在Web 浏览器（下文统一使用浏览器）上查找资料、看视频、看书、看新闻等等，而在浏览器中只需要输入一些搜索就可以得到想要的信息，这归根于搜索引擎的好处，但是实际上每个网页其实由多个资源组成。我们的浏览器就是一个HTTP 客户端，通过HTTP 协议访问服务器，得到服务器中的HTML 页面、文本文件、图片、音频等资源，并且将这些资源搬运到浏览器（客户端）显示给我们。

HTTP 协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传输协议，它是基于TCP/IP 协议通信的，因此它也是基于<客户端-服务器>模型运作的，是一个应用层协议，可以用它来传输服务器的各种资源，如文本、图片、音频等。

HTTP 协议的特点：

1. 简单：当客户端向服务器请求服务时，只需传送请求方法和路径即可获取服务器的资源，请求方法常用的有GET、HEAD、POST 等，每种方法规定了客户端与服务器通信的类型不同。

2. 快捷：由于HTTP 协议简单，使得HTTP 服务器的程序规模小，因而通信速度很快。

3. 灵活：HTTP 允许传输任意类型的数据对象，传输的类型由Content-Type 加以标记。

4. 无连接：无连接的含义是限制每次连接只处理一个请求，服务器处理完客户的请求，并收到客户的应答后，即断开连接，简单来说就是每进行一次HTTP 通信，都要断开一次TCP 连接，可随着HTTP 的普及，文档中包含大量图片的情况多了起来，每次请求完都要断开TCP 连接，无疑增加通信量的开销，为了解决TCP的连接问题，HTTP1.1 提出了持久连接的方法，即任意一端只要没有明确提出断开连接，则保持TCP 连接状态，这样子就就减少了TCP 连接的重复建立和断开所造成的额外开销，减轻了服务端的负载。注意，在HTTP1.1 版本之后才出现持久连接的方法。

5. 无状态：HTTP 协议是无状态协议，无状态是指协议对于事务处理没有记忆能力，即HTTP 协议无法根据之前的状态进行本次的请求处理，这就意味着如果后续处理需要前面的信息，它必须重传数据，这样的情况可能导致HTTP 协议传输的数据量增大，当然，凡事都有两面性，在另一方面，在服务器不需要先前信息时它的应答就较快，可以减少服务器的资源消耗，其实这种无状态对于用户来说也是不友好的，因此为了解决无状态的问题，引入了Cookie 技术，这是一种可以让服务器知道用户上一次做了什么操作，并且记录下来，它是存储在客户端之中的，比如我们在淘宝上买东西，我们选择了几个商品，但是到了结账会跳转到另一个页面，此时如果服务器不知道我们选择了哪些商品，那怎么能结账成功呢？所以Cookie 就是用来绕开HTTP 的无状态性的“手段”之一，服务器可以设置或读取Cookies 中包含信息，让服务器知道我们选择了什么商品，借此维护用户跟服务器会话中的状态，当然，Cookie 会被加密存储在客户端中，直到过期或者手动清除。

2. URL 与资源

我们可以把整个英特网看做是一个巨大的图书馆，里面的资源应有尽有，并且是对我们是开放的，我们想要找一本书，那么我们就需要直到他存放在哪里，然后去找到它。网络中的资源也是应有尽有，那么怎么样才能在网络的海洋中找到我们想要的资源呢？因此URI（Uniform Resource Identifiers）就被设计出来，用于统一管理资源，就像我们去图书馆找书一样，我们必须通过图书馆的系统，找到书所在的位置，而不是让我们自己一本一本书去找。

URL 全称是Uniform Resource Locator，中文叫统一资源定位符，是互联网上用来标识某一处资源的绝对地址，使用它我们就必然能找到资源，除非资源已经被转移了。URI 是一个通用的概念，由两个子集组成，分别是URL 和URN，URL 是通过资源的位置来标识资源，而URN 更高级一点，只需通过资源名字即可识别资源，与他们所处的位置是无关的，目前暂时还未推广URN。

大部分URL 都会遵循URL 的语法，一个URL 的组成有多个不同的组件，一个URL的通用格式如下

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

当然，绝大部分的URL 是不会包含所有组件的内容的.

URL 组件

scheme(方案)	指定访问服务器获取资源时使用哪种协议，有HTTP、HTTPS、FTP、SMTP 等协议。
user(用户)	某些方案访问资源时候需要指定用户名，才有权限获取资源。
password(密码)	用户名后面可能需要密码进行验证，用户名与密码直接使用 “:” 冒号分隔连接。
host(主机)	资源宿主服务器的主机名或者IP 地址（点分十进制）。
port(端口)	资源宿主服务器正在监听的端口号，很多方案都有默认的端口号，而无需我们自己填写，比如HTTP 默认使用80 端口，HTTPS 默认使用443 端口。端口不是一个URL 必须的部分，如果省略端口部分，将采用默认端口。
path(路径)	服务器本地资源的路径。类似于电脑中的文件路径一样，使用“/”将路径与端口隔离。从域名后的第一个“/”开始到最后一个“/”为止，虚拟目录也不是一个URL 必须的部分，在路径之后是需要一个文件名，这就是URL 指定的资源。文件名部分也不是一个URL 必须的部分，如果省略该部分，则使用默认的文件名
params(参数)	某些方案会使用这个组件来输入参数，可以拥有多个参数，使用“;”符号与路径分隔开。
query(查询）	某些方案会使用这个组件传递参数以激活应用程序，查询组件的内容没有通用的格式，用“?”字符与其他组件分隔开
frag(片段)	一小片或者一部分资源的名字，引用对象时，不会将片段组件内容传输给服务器，这个字段是在客户端内部使用的，通过“#”字符与其他组件分隔开。

比如：https://blog.csdn.net/XieWinter，它就是一个URL，这是最简单的一个URL 格式，通过其可以访问相应的资源。

3. HTTP报文

HTTP 报文是由3 个部分组成，分别是：对报文进行描述的“起始行”，包含属性的“首部”，以及可选的“数据主体”，对于请求报文与应答报文，只有“起始行”的格式是不一样的。

http 请求报文

<method> <request-url> <version>                    // 起始行
<headers>                                           // 首部

<entity-body>                                       // 数据主体

http 应答报文

<version> <status> <reason-phrase>                  // 起始行
<headers>                                           // 首部

<entity-body>                                       // 数据主体

起始行和首部就是由行分隔的 ASCII 文本组成，每行都以由两个字符组成的行终止序列作为结束，其中包括一个回车符（ASCII 码 13）和一个换行符（ASCII 码 10）， 这个行终止序列可以写做 CRLF。

这两种HTTP 报文的各个部分简单描述:

• 方法（method）：HTTP 请求报文的起始行以方法作为开始，方法用来告知服务器要做些什么，常见的方法有GET、POST、HEAD 等，比如“GET /forum.php HTTP/1.1” 使用的就是GET 方法。
• 请求URL（request-URL）：指定了所请求的资源。
• 版本（version）：指定报文所使用的HTTP 协议版本，其中<major>指定了主要版本号， <minor>指定了次要版本号，它们都是整数，其格式如下：

HTTP/<major>.<minor>

• 状态码（status）：这是在HTTP 应答报文中使用的，状态码是在每条响应报文的起始行中返回的一个数字码，描述了请求过程中所发送的情况，比如成功、失败等，不同的状态码有不同的含义

200 常见的返回OK，404错误等，206 状态码将会文件分段下载中使用。

• 原因短语（reason-phrase）：这其实是给我们看的原因短语，因为数字是不够直观，它只是状态码的一个文本形式表达而已。 
• 首部（header）：HTTP 报文可以有0 个、1 个或者多个首部，HTTP 首部字段向请求和响应报文中添加了一些附加信息，从本质上来说，它们是一个<名字：值>对，每个首部都包含一个名字，紧跟着一个冒号“:”，然后是一个可选的空格，接着是一个值，最后以CRLF 结束，比如“Host: blog.csdn.net”就是一个首部。
• 数据主体（entity-body）：这部分包含一个由任意数据组成的数据块，其实这与我们前面所讲的报文数据区域是一样的，用于携带数据，HTTP 报文可以承载很多类型的数字数据：图片、视频、音频、HTML 文档、软件应用程 序等。

4. 使用Postman 获取数据

既然了解了HTTP 协议与HTTP 报文的相关知识，我们就来使用Postman 软件了解一下HTTP 协议的传输过程。

官网：https://www.getpostman.com/

安装后打开软件，就可以使用软件进行测试HTTP 协议，可以很直观看到发送的HTTP 报文是什么，也能很直观看到响应的数据。

可以简单注册一下，就可以记录发送的命令，相当不错。

或者

查看发送HTTP 请求报文

  Postman 功能很强大，只是用到其最简单的功能。

5. 基于HTTP协议的文件下载

5.1 文件整体下载

文件整体下载比较简单，只需要知道资源的位置下载就可以。

 5.2 文件分段（Range）下载

在嵌入式设备或者资源有限的设备中，可能需要下载的文件的大小，自身资源不能一次性的满足，需要分段下载才行。文件分段下载的前提条件是，支持文件分段下载，否则，即便采用分段获取的，下载的也是整个文件大小，比如GitHub上面的就会下载整个文件的大小。

文件下载的流程如下：

• 获取文件的大小
• 下载各分段文件
• 文件拼接
• 文件完整性检查

5.2.1 获取文件的大小

因为需要分段下载，因此，首先需要知道文件的大小，才方便计算分段，当然，不分段也不是不可以，但处理起来，没有先获取文件大小规范。

可以直接获取资源链接的网站，检查响应的消息头字段中是否存在 如下字段，存在则支持，否则，不支持

Accept-Ranges: bytes

这就需要用到消息头字段添加 Range 字段

Range: bytes=0-1024 获取最前面1025个字节
Range: bytes=-500   获取最后500个字节
Range: bytes=1025-  获取从1025开始到文件末尾所有的字节
Range: 0-0          获取第一个字节
Range: -1           获取最后一个字节

请求成功后服务器会返回状态码206, 并返回如下字段指示返回结果, 0-1024指示返回分段范围, 7877指示文件总大小
Content-Range: bytes 0-1024/7877

因此采用如下，获取文件大小：

Range: 0-0          获取第一个字节

示例：

5.2.2 下载分段文件

分段下载分为两种，一种就是一次请求一个分段，一种就是一次请求多个分段。

下面两种都会有介绍，但是，实际上，除非为了多线程多段下载（PC下载软件 Internet Download Manager ），否则，在嵌入式开发中一般还是采用一次请求一个分段。

根5.2.1 可知文件大小，如示例文件大小为 3700512 字节。

具体怎么分段，根据设备资源来分配，原理是一样都。

假如分三段 0-999999，1000000-1999999，2000000-3700511

一次请求一个分段

• 第一段消息头字段添加

Range: bytes=0-999999 获取最前面1000000个字节

 

 

• 第二段消息头字段添加

Range: bytes=1000000-1999999 获取第二个1000000个字节

 

 

• 末段消息头字段添加

Range: bytes=2000000-3700511 获取最后一段
或另一种方式

Range: bytes=2000000- 获取最后一段             // 这种更好些

 

 一次请求多个分段

 至此，文件下载完成，文件的拼接，如果是 类似都 xxx.bin文件，那么保存的时候，同一块地址连续保存就完成来拼接来。因为这里主要也是想表达通过http 服务分段下载文件，来升级程序，实现 FOTA 功能 ,其它方法暂不多说；

文件下载完成后，需要校验文件都完整性，否则不完整都程序，一旦升级将造成死机的情况。

5.3 文件分块（chunk）下载

Transfer-Encoding: chunked 表示输出的内容长度不能确定，普通的静态页面、图片之类的基本上都用不到这个。但动态页面就有可能会用到，但也注意到大部分asp,php,asp.net动态页面输出的时候大部分还是使用Content-Length，没有使用Transfer-Encoding: chunked。

Transfer-Encoding: chunked使用，就不必申请一个很大的字节数组了，可以一块一块的输出，更科学，占用资源更少。

这在http协议中也是个常见的字段，用于http传送过程的分块技术，原因是http服务器响应的报文长度经常是不可预测的，使用Content-length的实体搜捕并不是总是管用。分块技术的意思是说，实体被分成许多的块，也就是应用层的数据，TCP在传送的过程中，不对它们做任何的解释，而是把应用层产生数据全部理解成二进制流，然后按照MSS（Maxitum Segment Size 最大分段大小，一般客户端资源有限，大小受其限制）的长度切成一分一分的，一股脑塞到tcp协议栈里面去，而具体这些二进制的数据如何做解释，需要应用层来完成，所以在这之前，一块整体应用层的数据需要等它分成的所有TCP  segment到达对方，重新组装后，应用程序才使用自己的解码方法还原它们。

HTTP1.1采用了持久的连接，也就是一次TCP的连接不马上释放，允许许多的请求跟响应在一个TCP的连接上发送，所以客户机与服务器需要某种方式来标示一个报文在哪里结束和在下一个报文在哪里开始。简单的方法是使用呢content-length，但这只有当报文长度可以预先判断的时候才起作用，而对于动态的内容或者在发送数据前不能判定长度的情况下，可以使用分块的方法来传送编码。

Web服务器有时生成HTTPResponse无法在Header就确定消息大小的，这时一般来说服务器将不会提供Content-Length的头信息，而采用Chunked编码动态的提供body内容的长度。进行Chunked编码传输的HTTP Response会在消息头部设置：Transfer-Encoding: chunked表示Content Body将用Chunked编码传输内容。

 

 

 Chunked编码使用若干个Chunk串连而成，由一个标明长度为0的chunk标示结束。每个Chunk分为头部和正文两部分，头部内容指定下一段正文的字符总数（十六进制的数字）和数量单位（一般不写），正文部分就是指定长度的实际内容，两部分之间用回车换行(CRLF)隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容，是一些附加的Header信息（通常可以直接忽略）。

 

chunk编码其实是一种动态数据传输协议，针对大数据可以动态传输，网页可以动态显示。

chunk编码格式如下：

[chunk size][\r\n][chunk data][\r\n][chunk size][\r\n][chunk data][\r\n][chunk size = 0][\r\n][\r\n]

chunk size是以十六进制的ASCII码表示，比如33 37 35，计算成长度应该是：0x375(885)，表示从回车之后有连续的885字节的数据。

chunk数据以0长度的chunk块结束。

分块传输的前提条件是，服务器支持该方式！！！且为http1.1协议。

 

注：本节没有详细介绍HTTP及其消息头字段，只是从FOTA都角度，来说明相关都东西，深入都需要查询相关协议。

要点：

HTTP与FTP

P2P

无论是 HTTP 的方式，还是 FTP 的方式，都有一个比较大的缺点，就是难以解决单一服务器的带宽压力， 因为它们使用的都是传统的客户端服务器的方式。

后来，一种创新的、称为 P2P 的方式流行起来。P2P就是peer-to-peer。资源开始并不集中地存储在某些设备上，而是分散地存储在多台设备上。这些设备我们姑且称为 peer。

P2P定义

• 下载一个文件可以使用 HTTP 或 FTP，这两种都是集中下载的方式，而 P2P 则换了一种思路，采取非中心化下载的方式
• P2P 也是有两种，一种是依赖于 tracker 的，也即元数据集中，文件数据分散；另一种是基于分布式的哈希算法，元数据和文件数据全部分散

• 首先简述HTTP下载和FTP下载的区别：

  我们先要知道，使用Web浏览器时,这两个协议之间的差异几乎不会对使用的方便性及下载时间产生影响。不过,两者却拥有各自不同的结构。

  HTTP下载

• HTTP是一种为了将位于全球各个地方的Web服务器中的内容发送给不特定多数用户而制订的协议。也就是说,可以把HTTP看作是旨在向不特定多数的用户“发放”文件的协议。
• HTTP使用于从服务器读取Web页面内容。Web浏览器下载Web服务器中的HTML文件及图像文件等,并临时保存在个人电脑硬盘及内存中以供显示。
• 使用HTTP下载软件等内容时的不同之处只是在于是否以Web浏览器显示的方式保存,还是以不显示的方式保存而已。结构则完全相同。因此,只要指定文件,任何人都可以进行下载。

• FTP下载

  FTP即文件传输协议

  FTP 采用两个 TCP 连接来传输一个文件。

• 控制连接：服务器以被动的方式，打开众所周知用于 FTP 的端口 21，客户端则主动发起连接。该连接将命令从客户端传给服务器，并传回服务器的应答。常用的命令有：list——获取文件目录；reter——取一个文件；store——存一个文件。
• Peer-to-peer 是一类允许一组用户互相连接并直接从用户硬盘上获取文件的网络
• Peer-to-peer网络是一个运行于个人电脑上的应用，通过网络在用户间分享文件。P2P网络通过连接个人电脑分享文件而不是通过中央服务器
• P2P是一种分布式网络，网络的参与者共享他们所拥有的一部分硬件资源（处理能力、存储能力、网络连接能力、打印机等），这些共享资源需要由网络提供服务和内容，能被其它对等节点（peer）直接访问而无需经过中间实体。在此网络中的参与者既是资源（服务和内容）提供者（server），又是资源（服务和内容）获取者（client）
• 数据连接：每当一个文件在客户端与服务器之间传输时，就创建一个数据连接。

• 另一方面,FTP是为了在特定主机之间“传输”文件而开发的协议。因此,在FTP通信的起始阶段,必须运行通过用户ID和密码确认通信对方的认证程序，

  FTP下载和HTTP下载的区别之一就在与此。

  FTP 的两种工作模式：

  每传输一个文件，都要建立一个全新的数据连接。FTP 有两种工作模式，分别是主动模式（PORT）和被动模式（PASV），这些都是站在 FTP 服务器的角度来说的。

P2P特点

1. 无中央服务器，打破了C/S模式
2. 用户之间互联并分享文件。

BitTorrent

想要下载一个文件的时候，你只要得到那些已经存在了文件的 peer，并和这些 peer 之间，建立点对点的连接，而不需要到中心服务器上，就可以就近下载文件。

一旦下载了文件，你也就成为 peer 中的一员，你旁边的那些机器，也可能会选择从你这里下载文件，所以当你使用 P2P 软件的时候，例如 BitTorrent，往往能够看到，既有下载流量，也有上传的流量，也即你自己也加入了这个 P2P 的网络，自己从别人那里下载，同时也提供给其他人下载。

可以想象，这种方式，参与的人越多，下载速度越快，一切完美。

种子（.torrent）文件

但是有一个问题，当你想下载一个文件的时候，怎么知道哪些 peer 有这个文件呢？ 这就用到种子啦，也即咱们比较熟悉的.torrent 文件。.torrent 文件由两部分组成，分别是：announce（tracker URL）和文件信息。(tracker谷歌翻译为跟踪器)

 文件信息里面有这些内容：

• info 区：这里指定的是该种子有几个文件、文件有多长、目录结构，以及目录和文件的名字
• Name 字段：指定顶层目录名字
• 每个段的大小：BitTorrent（简称 BT）协议把一个文件分成很多个小段，然后分段下载
• 段哈希值：将整个种子中，每个段的 SHA-1 哈希值拼在一起

工作过程：

1. 下载时，BT 客户端首先解析.torrent 文件，得到 tracker 地址，然后连接 tracker 服务器。
2. tracker 服务器回应下载者的请求，将其他下载者（包括发布者）的 IP 提供给下载者。
3. 下载者再连接其他下载者，根据.torrent 文件，两者分别对方告知自己已经有的块，然后交换对方没有的数据。

此时不需要其他服务器参与，并分散了单个线路上的数据流量，因此减轻了服务器的负担。

这个过程也可以看出，这种方式特别依赖 tracker。tracker 需要收集下载者信息的服务器，并将此信息提供给其他下载者，使下载者们相互连接起来，传输数据。

虽然下载的过程是非中心化的，但是加入这个 P2P 网络的时候，都需要借助 tracker 中心服务器，这个服务器是用来登记有哪些用户在请求哪些资源。

所以，这种工作方式有一个弊端，一旦 tracker 服务器出现故障或者线路遭到屏蔽，BT 工具就无法正常工作了。

去中心化网络（DHT）

为了向彻底去中心化迈步前进，后来就有了一种叫作DHT（Distributed Hash Table）的去中心化网络。

每个加入这个 DHT 网络的人，都要负责存储这个网络里的资源信息和其他成员的联系信息，相当于所有人一起构成了一个庞大的分布式存储数据库。

有一种著名的 DHT 协议，叫Kademlia 协议。这个和区块链的概念一样，很抽象。

任何一个 BitTorrent 启动之后，它都有两个角色。一个是peer，监听一个 TCP 端口，用来上传和下载文件，这个角色表明，我这里有某个文件。另一个角色DHT node，监听一个 UDP 的端口，通过这个角色，这个节点加入了一个 DHT 的网络。

迅雷离线下载的原理是什么？

答：离线下载，即利用服务器“替”网友的电脑下载的方式。具高速、不用挂机的优点而颇受欢迎。如果用户要下载一些电影或者游戏资源，往往要长时间挂机，不仅浪费时间而且消耗大量的带宽。 离线下载其实就是下载工具的服务器代替用户先行下载，多用于冷门资源。比如，用户的正常下载最大速度能达到200KB/S，但是某个资源是冷门资源，下载速度只能达到10KB/S，用户就得下很久，如果用户使用离线下载技术，就可以让服务商的服务器代替用户下载，用户就可以关掉下载工具或者机器，节约时间和电费。等到离线下好了，用户再从下载工具的服务器上以200KB/S（理论上会员等级越高越快，但最高速度仍然受限制于你的本身宽带）的速度下到自己的电脑上。即使对于热门资源，离线下载也能省却许多挂机等待的时间，最重要的是能够腾出电脑宽带做其他的事情。 

操作过程：（1）用户通过客户端或Web界面提交一个下载请求。 （2）公司服务器端接受请求，服务器首先查询用户提交的下载链接是否被下载过；如果没有，开启多线程实施下载（或用迅雷自己特有的P2P方式）；如果有，直接把已下载的数据文件（或只是文件的链接）放入用户服务器端的在线空间。 （3）下载完成后，用户在线登录到在线空间，取回下载的文件。其间也可以采用迅雷自己的P2P方式，从已下载或正在下载相同文件的用户那里取得数据。 （4）离线下载多针对冷门资源，或资源少的文件。待服务器端不是替用户下载完成后，用户还需要利用下载软件从服务器上下载文件。相比直接下载，增加了下载资源速度，节约了时间。

简单来说，就是如果要下载的资源已经存在于迅雷的服务器中，那么直接用P2P的方式从迅雷的服务器中取回。如果下载的资源尚未下载，那么可以将下载任务交由服务器代为完成（委托模式啊，哈哈），由于服务器的带宽性能等远胜于普通用户，所以下载效率更高，最重要的是服务器是365 * 7 * 24小时在线的，可以用时间堆死它。

 

 

 

delphi压缩后使用http协议base64上传下载6G超大文件

注：服务端软件，使用高勇出品GYRestServer系列。欢迎使用，加QQ群咨询：174483085

一、知识点：

1、Delphi自带的压缩解压单元system.zlib.pas中核心函数的使用

2、服务端http协议ContentType(mime-type)相关列表类型的注册

3、Base64编码的规则

4、为何要分块断点续传，并使用TFileStream文件流替代内存流TMemoryStream

5、Buffer.size对Base64分块断点续传的影响

6、优化上传下载的速度与并发性能的综合考虑

二、直接看视频了解核心关键内容

        从本博客资源下载：

delphi压缩后并使用http协议base64上传下载6G超大文件的演示即核心代码概要.mp4-Delphi文档类资源-CSDN下载知识点：1、Delphi自带的压缩解压单元system.zlib.pas中核心函数的使用；2、服务端更多下载资源、学习资料请访问CSDN下载频道.https://download.csdn.net/download/pulledup/46210881        或从本人百度网盘下载：

                链接： https://pan.baidu.com/s/1Zpxfe5fJruuJW68x3dDTSw
                提取码：iqvo 

三、其它的补充说明

3.1、优化上传下载的速度与并发性能的综合考虑

        参考本博客博文：

浅谈服务器http并发数的影响因素_pulledup的博客-CSDN博客https://blog.csdn.net/pulledup/article/details/121383350

3.2、服务端http协议ContentType(mime-type)相关列表类型的注册

        参考本博客博文：

delphi MimeType for Restful及delphi mime-type和文件扩展名对照表_pulledup的博客-CSDN博客delphi MimeType for Restful MimeType是你让编写的应用Restful化编程所必须的。delphi支持哪些MimeType，如何知道这些MimeType与文件扩展名的对应关系，以及它们是文本种类、二进制种类还是未定义的。一、先上代码 : 已附上面源码下载。由于代码引用了跨平台的文件存取，使用源码注意事项：1、在FormCre...https://blog.csdn.net/pulledup/article/details/105774767delphi XE应用Restful时Rest组件的delphi XE ContentType即delphi XE mime type怎样获取和表达_pulledup的博客-CSDN博客delphi XE应用Restful时Rest组件的delphi XE ContentType即delphi XE mime type怎样获取和表达一、usesREST.Types;//var //DefaultRESTRequestParameterKind: TRESTRequestParameterKind = TRESTRequestParameterKind.pkGETor...https://blog.csdn.net/pulledup/article/details/105749158

3.3、Buffer.size对Base64分块断点续传的影响

         为何使用Base64？

        如果你仅仅是上传下载，而无需下载后H5加载，可以不必非得使用TBase64Encoding来编解码。可参考本博客博文：

Delphi处理高速文件上传下载的代码及思路_pulledup的博客-CSDN博客Delphi处理高速文件上传下载的代码及思路 上传和下载是一对方向不同的概念，下面对应的客户端和服务器代码：掉个头，它就是下载；再掉个头，它就是上传。一、思路 1、将大文件：分段（即常说的“断点”上传或下载）上传或下载 2、分别上传或下载这些分段 3、将上传或下载后的各“分段”文件流合并还原 4、关于加速（网上你经常看到“高速”上传或下载）：若多线程分别上传或下载这些分段，即可提速。 你们去使用 高勇老师的代码，它是完全...https://blog.csdn.net/pulledup/article/details/108660481

        否则，请使用Base64，它可以对html和URL进行编解码。请直接使用高勇出品GYRestServer系列及其配套客户端GYRestClient.pas中的相关代码进行客制化。

         Base64内容传输时需要注意的事项：

//http分块上传或下载时，需注意:
            block := (6*25)*7 * 1024 * 1;//=1050KB
              //:来超2021-11-19：提升服务器并发性能:拷贝分块大小,delphi默认32kb
            //block := 1024 * 1024 * 1;//:拷贝分块大小,每次拷贝1M:
              //:(一次上传,最多不能超过25M,似乎超过了,就没有响应)
              //:Buffer不正确会对Base64分段产生无规律的不可预期的影响:
              //:Base64----4组每组6位编码----块:6位字节的整数倍--以替换8位1组的二进制
                //:W3C标准:  https://datatracker.ietf.org/doc/html/rfc2045
              //:delphi默认buffer.size=32k，太小了：
                //:1.1、客户会感觉太慢了
                //:1.2、某些服务器也可能做了限制:不允许连续发小包给它,它人为你是在http攻击
              //:buffer.size=N个KB，太大了：
                //:2.1、客户端内存不允许：上限好像是忘了65535KB? 32768KB? 总之最好不要超过1M
                //:2.1、服务器并发时，
                  //:内存(取决于服务器内存的大小)
                  //:磁盘(取决服务器硬盘通道即单位时间IO速度)、
                  //:网路带宽(取决你服务器的带宽)
                    //:它们受不了大的“冲击波"

        Base64 内容传输的W3C标准说明：

rfc2045        rfc2045        rfc2045

3.4、为何需使用TFileStream文件流替代内存流TMemoryStream

        并发时，压缩解压也好、上传下载也好，或使用内存流TMemoryStream，内存的开销太大、而且内存很昂贵，使用文件流TFileStream替代内存流，会有效避免此问题。

        用Delphi自带的system.zlib.pas库单元函数压缩解压时，要特别注意：

        3.4.1、必要期待你能用常用的压缩解压工具，去打开system.zlib压缩文件，因为它是Delphi专用的压缩格式，加了密的；不过这样也很安全；

        3.4.2、无论压缩环节还是解压环节均不要TStream.CopyFrom

        因为这样，会丢失字节。而应当老实的用字节数组，逐个字节的读取或写入。