netty4怎么实现分片上传,断点续传

netty4怎么实现分片上传,断点续传,第1张

netty4怎么实现分片上传,断点续传

JAVA WEB文件上传步骤如下:

实现 Web 开发中的文件上传功能,两个操作:在 Web 页面添加上传输入项,在 Servlet 中读取上传文件的数据并保存在本地硬盘中。

1、Web 端上传文件。在 Web 页面中添加上传输入项:<input type="file">设置文件上传输入项时应注意:(1) 必须设置 input 输入项的 name 属性,否则浏览器将不会发送上传文件的数据。(2) 必须把 form 的 enctype 属性设为 multipart/form-data,设置该值后,浏览器在上传文件时,将把文件数据附带在 http 请求消息体中,并使用 MIME 协议对上传文件进行描述,以方便接收方对上传数据进行解析和处理。(3) 表单提交的方式要是 post

2、服务器端获取文件。如果提交表单的类型为 multipart/form-data 时,就不能采用传统方式获取数据。因为当表单类型为 multipart/form-data 时,浏览器会将数据以 MIME 协议的形式进行描述。如果想在服务器端获取数据,那么我们必须采用获取请求消息输入流的方式来获取数据。

3、Apache-Commons-fileupload。为了方便用户处理上传数据,Apache 提供了一个用来处理表单文件上传的开源组建。使用 Commons-fileupload 需要 Commons-io 包的支持。

4、fileuplpad 组建工作流程

(1)客户端将数据封装在 request 对象中。

(2)服务器端获取到 request 对象。

(3)创建解析器工厂 DiskFileItemFactory 。

(4)创建解析器,将解析器工厂放入解析器构造函数中。之后解析器会对 request 进行解析。

(5)解析器会将每个表单项封装为各自对应的 FileItem。

(6)判断代表每个表单项的 FileItem 是否为普通表单项 isFormField,返回 true 为普通表单项。

(7)如果是普通表单项,通过 getFieldName 获取表单项名,getString 获得表单项值。

(8)如果 isFormField 返回 false 那么是用户要上传的数据,可以通过 getInputStream 获取上传文件的数据。通过getName 可以获取上传的文件名

在之前的文章中,我们介绍了在同一个netty程序中支持多个不同的服务,它的逻辑很简单,就是在一个主程序中启动多个子程序,每个子程序通过一个BootStrap来绑定不同的端口,从而达到访问不同端口就访问了不同服务的目的。

但是多个端口虽然区分度够高,但是使用起来还是有诸多不便,那么有没有可能只用一个端口来统一不同的协议服务呢?

今天给大家介绍一下在netty中使用同一端口运行不同协议的方法,这种方法叫做port unification。

在讲解自定义port unification之前,我们来看下netty自带的port unification,比如SocksPortUnificationServerHandler。

我们知道SOCKS的主要协议有3中,分别是SOCKS4、SOCKS4a和SOCKS5,他们属于同一种协议的不同版本,所以肯定不能使用不同的端口,需要在同一个端口中进行版本的判断。

具体而言,SocksPortUnificationServerHandler继承自ByteToMessageDecoder,表示是将ByteBuf转换成为对应的Socks对象。

那他是怎么区分不同版本的呢?

在decode方法中,传入了要解码的ByteBuf in,首先获得它的readerIndex:

我们知道SOCKS协议的第一个字节表示的是版本,所以从in ByteBuf中读取第一个字节作为版本号:

有了版本号就可以通过不同的版本号进行处理,具体而言,对于SOCKS4a,需要添加Socks4ServerEncoder和Socks4ServerDecoder:

对于SOCKS5来说,需要添加Socks5ServerEncoder和Socks5InitialRequestDecoder两个编码和解码器:

这样,一个port unification就完成了,其思路就是通过传入的同一个端口的ByteBuf的首字节,来判断对应的SOCKS的版本号,从而针对不同的SOCKS版本进行处理。

在本例中,我们将会创建一个自定义的Port Unification,用来同时接收HTTP请求和gzip请求。

在这之前,我们先看一下两个协议的magic word,也就是说我们拿到一个ByteBuf,怎么能够知道这个是一个HTTP协议,还是传输的一个gzip文件呢?

先看下HTTP协议,这里我们默认是HTTP1.1,对于HTTP1.1的请求协议,下面是一个例子:

HTTP请求的第一个单词就是HTTP请求的方法名,具体而言有八种方法,分别是:

OPTIONS

返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送'*'的请求来测试服务器的功能性。

HEAD

向服务器索要与GET请求相一致的响应,只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下,就可以获取包含在响应消息头中的元信息。

GET

向特定的资源发出请求。注意:GET方法不应当被用于产生“副作用”的操作中,例如在Web Application中。其中一个原因是GET可能会被网络蜘蛛等随意访问。

POST

向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。

PUT

向指定资源位置上传其最新内容。

DELETE

请求服务器删除Request-URI所标识的资源。

TRACE

回显服务器收到的请求,主要用于测试或诊断。

CONNECT

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

那么需要几个字节来区分这八个方法呢?可以看到一个字节是不够的,因为我们有POST和PUT,他们的第一个字节都是P。所以应该使用2个字节来作为magic word。

对于gzip协议来说,它也有特殊的格式,其中gzip的前10个字节是header,其中第一个字节是0x1f,第二个字节是0x8b。

这样我们用两个字节也能区分gzip协议。

这样,我们的handler逻辑就出来了。首先从byteBuf中取出前两个字节,然后对其进行判断,区分出是HTTP请求还是gzip请求:

对应的,我们还需要对其添加相应的编码和解码器,对于gzip来说,netty提供了ZlibCodecFactory:

对于HTTP来说,netty也提供了HttpRequestDecoder和HttpResponseEncoder还有HttpContentCompressor来对HTTP消息进行编码解码和压缩。

添加了编码和解码器之后,如果你想自定义一些操作,只需要再添加自定义的对应的消息handler即可,非常的方便。

本文的例子可以参考: learn-netty4

您好,对于你的遇到的问题,我很高兴能为你提供帮助,我之前也遇到过哟,以下是我的个人看法,希望能帮助到你,若有错误,还望见谅!。展开全部

Nginx+PHP-fpm组合,以内存占用小,负载能力强壮的特点,成为小内存VPS建站的首选组合。我们一起来探讨一下nginx+php-fpm高负载的优化方法。

先来看看nginx配置参数的优化。nginx是前端接受浏览器端请求的web server, 配置可调的参数如下:

下面是示例nginx配置

user www-data

worker_processes 8

#worker_processes 调至8, 大于8没什么用,小于8,nginx性能发挥不出来

worker_cpu_affinity 01 10 01 10 01 10 01 10

#worker_cpu_affinity 参数可以使nginx充分发挥多核Cpu的性能优势 ,上面的配置是针对双核CPU的配置。01表示第一个核,10表示第二个核,如果是四核cpu,一至四个核分别表示为 0001 0010 0100 1000

error_log /var/log/nginx/error_log crit

pid /var/run/nginx.pid

worker_rlimit_nofile 10240

#worker_rlimit_nofile 是nginx能打开文件的最大句柄数,我们需要把这个数字设大一点。

#linux系统的文件查看数限制查看是用 ulimit -n ,修改这个限制是用 ulimit -HSn 65535

events

{

use epoll

#必须要用高效的event驱动,以获得最大性能

worker_connections 10240

#max_clients = worker_processes * worker_connections/4 (最大连接数的计算公式)

}

http

{

include /etc/nginx/deny.iplist

include /etc/nginx/mime.types

default_type application/octet-stream

server_name_in_redirect off

server_names_hash_bucket_size 128

server_tokens off

client_header_buffer_size 32k

#client头buffer可以调为32K

large_client_header_buffers 4 32k

client_max_body_size 8m

sendfileon

tcp_nopush on

keepalive_timeout 65

tcp_nodelayoff

client_body_timeout 10

client_header_timeout 10

send_timeout 60

output_buffers 1 32k

postpone_output 1460

open_file_cache max=1000 inactive=20s

open_file_cache_valid30s

open_file_cache_min_uses 2

open_file_cache_errors on

fastcgi_connect_timeout 300

fastcgi_send_timeout 300

fastcgi_read_timeout 300

fastcgi_buffer_size 32k

fastcgi_buffers 4 32k

fastcgi_busy_buffers_size 32k

fastcgi_temp_file_write_size 32k

gzip on

gzip_buffers 4 16k

gzip_http_version 1.0

gzip_comp_level 2

gzip_types text/plain application/x-javascript text/css application/xml

gzip_proxied expired no-cache no-store private auth

proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=staticfilecache:80m inactive=1d max_size=2500m

proxy_temp_path /var/lib/nginx/proxy

proxy_connect_timeout 300

proxy_read_timeout 120

proxy_send_timeout 120

proxy_buffer_size 16k

proxy_buffers 4 16k

upstream wordpressnginx

{

server 127.0.0.1:6000 weight=1 fail_timeout=120s

}

include /etc/nginx/sites-enabled/*

}

上面的配置里面,有多处设及到buffer和timeout的地方。我们可以根据需要,慢慢调大这些参数,buffer自然是大点好,但不要太大。16K是标准配置,可以增加到32,往上加更大也不是不行,但 要考虑到你系统内存大不大,够不够用。timeout是超时,如果服务器很繁忙,不妨增加超时等待时间,以避免频繁出现502错误。

gzip是必须开启的,reverse proxy在允许的情况下,也尽量开启,一 是可以提升响应效率,二是降低服务器压力,gzip开启后更可以节省服务器带宽。

nginx主要的配置如上所述。

现在看一下php-fpm的配置。

[global]

pid = run/php5-fpm.pid

process_control_timeout = 5

[www]

listen = /dev/shm/php-cgi.sock

listen.allowed_clients = 127.0.0.1

user = www-data

group = www-data

pm = static

pm.max_children = 7

#这个决定了 php-fpm的总进程。我们要想同时响应更多的并发数,这个数值要尽可能大,比如500,1000

pm.max_requests = 10000

#并发数越大,这个最大请求数应该越大,并发数小,这个数值也应该越小。它表示,php-fpm进程响应了10000个并发请求之后,就自动重启一下进程。

request_terminate_timeout = 30

#表示等待30秒后,结束那些没有自动结束的php脚本,以释放占用的资源。

env[HOSTNAME] = $HOSTNAME

env[PATH] = /usr/local/bin:/usr/bin:/bin

env[TMP] = /tmp

env[TMPDIR] = /tmp

env[TEMP] = /tmp

小内存的vps虽然经过使用php-fpm+nginx,提升了系统的效率,可以同时响应较多的并发请求,但是当并发数上来了,比如从100上升到10000,小内存肯定响应不过来,cpu也会 因为太忙,而导致系统负载变得很高很高,这个时候,我们就要考虑升级硬件配置了。

内存越大越好,CPU核心频率越高越好,CPU核越多越好。硬盘最好是SSD+RAID10。这样性能不仅高,数据安全也有保障。

上面所提到的各个配置参数,设及到数值的,不妨自己 多试着调小,调大参数,然后重启下nginx或者php-fpm进程,看看效果怎么样。

下面介绍一个比较好的压力测试工具,siege.

debian和ubuntu用户可以通过apt-get install siege来安装siege.

siege是一个跟ab.exe相似的http压力测试软件。

我们可以用siege来测试我们的网站和服务器性能。

siege -r 100 -c 10

-r 是 repeat , -r 100是重复100次测试

-c 10是表示模拟10个用户同时并发连接

最后面是要测试的URL地址。

测试过程中可以随时按CTRL+C中止进程,siege会生成一个报告给我们。

我们可以同时根据siege的测试结果和监视服务器的负载情况,对系统压力状况进行一个深入了解和分析。接下来可以帮助我们判断该如何进行下一步操作,是继续优化配置,还是升级硬件。非常感谢您的耐心观看,如有帮助请采纳,祝生活愉快!谢谢!


欢迎分享,转载请注明来源:夏雨云

原文地址:https://www.xiayuyun.com/zonghe/392088.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-05-18
下一篇2023-05-18

发表评论

登录后才能评论

评论列表(0条)

    保存