Streaming HTTP responses【翻译】

原文:Streaming HTTP responses

标准的应答和Content-Length头

由于HTTP 1.1遵守一个连接为多个HTTP请求和应答服务开放的规则,因此服务器在应答时必须发送相应的Content-Length HTTP头。

默认情况下,当你发送一个简单的结果,如:

public Result index() {
return ok("Hello World");
}

你没有指定 Content-Length头。是因为你发送的内容很有名,因此Play可以为你计算内容的长度并生产相应的头。

注意:对于基于文本的内容,这不像看起来那样简单,由于Content-Length头必须用根据把字符转换为字节的编码计算。

为了可以正确的计算Content-Length头,Play必须解析整个应答数据并把它的内容加载到内存。

文件服务

如果对于简单内容来说,可以把整个内容加载进内容,那么对于大数据集怎么办呢?比如我们想给客户端发送一个大文件。

Play提供了易于使用的助手来提供本地文件服务这样的普通任务:

public Result index() {
return ok(new java.io.File("/tmp/fileToServe.pdf"));
}

此外,这个助手也会根据文件名计算 Content-Type头。并且他也添加Content-Disposition头指定Web浏览器应该怎样处理这个应答。默认是使用Content-Disposition: attachment; filename=fileToServe.pdf.让Web浏览器下载这个文件。

分块应答

现在,流文件内容的处理还行,由于我们在流之前可以计算内容长度。但是动态计算没有可用的内容长度的内容会如何?

对于这种类型的应答,我们不得不使用分块传输编码

分块传输编码是HTTP 1.1版在Web服务器的一系列块的服务内容的数据传输机制。这使用了Transfer-Encoding HTTP 应答头替代 Content-Length头,该协议将需要另外的需求。由于不使用 Content-Length 头,服务器在开始传送应答到客户端(通常是Web浏览器)之前不需要知道内容的长度。 Web服务器可以在知道内容的所有长度之前开始动态的生成传送应答内容。

每一个块的大小都是在块本身发送之前发送,因此当客户端完成对块数据的接受时可以告知服务端,数据传输是由最后一块长度是0的块终止。
https://en.wikipedia.org/wiki/Chunked_transfer_encoding

好处是我们可以实时提供数据,意味着我们按照它们的接受能力尽可能快的发送数据块。缺点是由于Web浏览器不知道内容的长度,因此就不能正确的显示下载进度条。

比如,我们有一个服务器,这个服务器提供了一个计算一些数据的动态InputStream 。我们可以让Paly直接用分块相应把这个内容转为流:

public Result index() {
InputStream is = getDynamicStreamSomewhere();
return ok(is);
}

你也可以设置你自己的分块响应构建器:

public Result index() {
// Prepare a chunked text stream
Source<ByteString, ?> source = Source.<ByteString>actorRef(256, OverflowStrategy.dropNew())
.mapMaterializedValue(sourceActor -> {
sourceActor.tell(ByteString.fromString("kiki"), null);
sourceActor.tell(ByteString.fromString("foo"), null);
sourceActor.tell(ByteString.fromString("bar"), null);
sourceActor.tell(new Status.Success(NotUsed.getInstance()), null);
return null;
});
// Serves this stream with 200 OK
return ok().chunked(source);
}

Source.actorRef 方法创建一个实现了Akka Streams Source 的ActorRef。然后你可以通过发送信息到Actor的方式发布内容到流。另一种可选的反射是创建一个ActorPublisher 的Actor并使用Stream.actorPublisher创建它。
我们可以检查服务器发送的HTTP响应:

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Transfer-Encoding: chunked

4
kiki
3
foo
3
bar
0

我们获得了三个块和一个最终关闭响应的空块。
关于更多使用 Akka Streams的信息,你可以参考Akka Streams文档.

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容

  • 本文整理自MIN飞翔博客 [1] 1. 概念 协议是指计算机通信网络中两台计算机之间进行通信所必须共同遵守的规定或...
    HoyaWhite阅读 2,708评论 2 20
  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 135,099评论 19 139
  • 一、概念(载录于:http://www.cnblogs.com/EricaMIN1987_IT/p/3837436...
    yuantao123434阅读 8,519评论 6 152
  • 深入浅出HTTP协议(WEB开发和面试必备) 1.基础概念篇 a.简介 HTTP是Hyper Text Trans...
    半世韶华忆阑珊阅读 1,249评论 0 7
  • Http协议详解 标签(空格分隔): Linux 声明:本片文章非原创,内容来源于博客园作者MIN飞翔的HTTP协...
    Sivin阅读 5,260评论 3 82