前端上传大型文件或超长数据的解决办法

Posted 2023-04-11

参考技术A 我们设计的上传文件大约在500m左右

我第一反应是blob，在html5中添加了blob类型用来定义前端较大数据，之前使用过blob流传输视频再使用html5中<video>标签读取blob流，所以blob可以作为这种文件传输的载体，那如何提交呢，使用可formdata提交blob数据，这种方式可以承受较大数据量的文件，但在使用formdata传输的过程中，浏览器会卡死，无法操作。

还是舍友提醒，可采用数据分割的方式，一部分一部分上传。后经百度得知，文件分割要防止数据丢失进行大小校验，以及防止外部入侵，进行分段前端加密，后端校验。

百度发布了一款分割上传的组件web upload，可包含文件分割，大小校验等功能。

网站为： http://fex.baidu.com/webuploader/getting-started.html

佩服我们大学宿舍的技术氛围，出差回来的火车上跟大学舍友在微信上聊了两三个小时的技术，，，那天刚好是大学生开学那几天，路上好多大学生，好怀念自己的大学生活，好怀念与大学舍友谈天说地或技术探讨到深夜的日子

说了几个前端的问题，总结记录一下吧

其中只有一个我会的，，，先说这个问题，其他的我学习完再分享，留坑。。。。。。

nginx解决超长字符串请求

一、问题发现
1.可能因为base64字符太长，导致后端处理时出错，表现为前端请求报400错误；
2.前端传数据到后端时可能base64字符串中的特殊字符被替换，例如+被替换成空格，表现为上传的图片不完整
二、问题解决
1.问题1解决方法：
1.1.在配置文件中设置server.max-http-header-size（最大http请求头大小），其默认值为8KB，通常图片的base64会超过默认值，但是也不是越大越好（我设置2MB，然后前端再限制一下图片的大小或者压缩图片），大了反而有大问题，详情请看server.max-http-header-size的坑
2.问题2解决方法：
2.1.前端对base64字符串编码之后再传给后端处理，后端不需要解码，因为接收base64字符串时springmvc会进行一次解码
2.2.也可以通过将被替换的字符手动换回来，不过不推荐使用，你不知道究竟还有没有其他特殊字符被替换
String replace = base64.replace(" ", “+”);
MultipartFile multipartFile = BASE64DecodedMultipartFile.base64ToMultipart(replace);

nginx如何解决超长请求串
nginx是一个强大的http服务器，但是在使用过程中发现，当遇到超长的post请求或者get请求时，nginx会返回413、400、414等状态码，这是因为请求串长度超过了nginx默认的缓存大小或者请求串大小，那么我们需要怎么样来解决这些问题呢？
针对POST请求，我们可以调整如下两个配置项来解决：
client_body_buffer_size
语法：client_body_buffer_size the_size
默认值：8k/16k
使用字段：http, server, location
这个指令可以指定连接请求使用的缓冲区大小。
如果连接请求超过缓存区指定的值，那么这些请求或部分请求将尝试写入一个临时文件。
默认值为两个内存分页大小值，根据平台的不同，它可能是8k或16k

client_max_body_size
语法：client_max_body_size size
默认值：client_max_body_size 1m
使用字段：http, server, location
这个指令指定允许客户端请求的最大的单个文件字节数，它出现在请求头部的Content-Length字段。
如果请求大于指定的值，客户端将收到一个"Request Entity Too Large" (413)错误。
需要记住，浏览器并不知道怎样显示这个错误。

同时针对post请求还需要注意下面这个参数的配置，如果不打开这个选项当请求串大于client_body_buffer_size大小时，需要手动去读取存储在磁盘的请求，这里需要注意的是存入磁盘的请求是一个完整的请求并不是大于client_body_buffer_size的部分
client_body_in_single_buffer
语法：client_body_in_single_buffer
默认值：off
使用字段：http, server, location这个指令(0.7.58版本)指定将一个完整的连接请求放入缓冲区，当使用$request_body时推荐使用这个指令以减少复制操作。
如果无法将一个请求放入单个缓冲区，将会被放入磁盘。

针对get请求，我们可以通过修改另外两个配置来解决请求串超长的问题：client_header_buffer_size 语法：client_header_buffer_size size 默认值：1k 使用字段：http, server 这个指令指定客户端请求的http头部缓冲区大小绝大多数情况下一个头部请求的大小不会大于1k不过如果有 来自于wap客户端的较大的cookie它可能会大于1k，Nginx将分配给它一个更大的缓冲区，这个值可以在 large_client_header_buffers里面设置。 large_client_header_buffers 语法：large_client_header_buffers number size 默认值：large_client_header_buffers 4 4k/8k 使用字段：http, server 指令指定客户端请求的一些比较大的头文件到缓冲区的最大值，如果一个请求的URI大小超过这个值，服务 器将返回一个"Request URI too large" (414)，同样，如果一个请求的头部字段大于这个值，服务器 将返回"Bad request" (400)。 缓冲区根据需求的不同是分开的。 默认一个缓冲区大小为操作系统中分页文件大小，通常是4k或8k，如果一个连接请求将状态转换为 keep-alive，这个缓冲区将被释放。

那么有人就会觉得奇怪了，为什么修改http header的大小就能解决get请求串过长的问题呢， 这就要从http协议的get请求说起了，其实GET提交，请求的数据会附在URL之后（就是把数据放置在 HTTP协议头中）。

大家看到没，其实get请求的参数就是存放在http header中的，所以修改header的大小限制 当然可以解决请求串过长的问题啦。此外还有给大家澄清一点啦，HTTP协议没有对传输的数据大小进行限 制，HTTP协议规范也没有对URL长度进行限制，我们日常生活中遇到的长度限制都是各个浏览器或者http 请求工具自己干的。