本文共 8867 字，大约阅读时间需要 29 分钟。
超级猛料更新
About half an hour ago I pushed the latest release of , v0.1.0. This marks the first release of hyper since early March! This delay is not because I’ve been resting on my laurels. In fact, a quick check of the git repository shows that there were almost as many commits between v0.0.4 and v0.1.0 as there were in total up to v0.0.4.
大约半小时前，我推送了的最新版本v0.1.0。 这标志着hyper自3月初以来的首次发布！ 延迟不是因为我一直在桂冠上休息。 实际上，快速检查git存储库显示，v0.0.4和v0.1.0之间的提交几乎与v0.0.4之前的提交总数一样多。
Why the delay? What have I been working on? Why wasn’t I releasing incrementally? This post acts as a long form explanation to bring you up to speed with what’s going on in hyper. If you’re just interested in the highlights, feel free to consult directly.
为什么要延迟？ 我一直在做什么？ 为什么我没有逐步释放？ 这篇文章是一个长篇幅的说明，可让您快速掌握hyper 。 如果您仅对重点内容感兴趣，请随时直接查询 。
First, the bad stuff. This release of hyper abandons support for Python 3.3, instead supporting only Python 3.4. Why did I do this?
首先，不好的东西。 此版本的hyper放弃放弃了对Python 3.3的支持，而仅支持Python 3.4。 我为什么要这样做？
Simple: Python 3.3’s ssl module is not good enough to support HTTP/2. I need features that it does not have: specifically, I need to limit TLS negotiation to TLS v1.2 only. When Python 3.4 came out with that support we immediately moved to add it, expecting that PyOpenSSL would be able to fill the gap for Python 3.3.
简单：Python 3.3的ssl模块不足以支持HTTP / 2。 我需要它没有的功能：具体地说，我需要将TLS协商仅限于TLS v1.2。 当Python 3.4提供了这种支持时，我们立即开始添加它，希望PyOpenSSL能够填补Python 3.3的空白。
Unfortunately, PyOpenSSL was missing NPN support. At the end of March I opened a that added NPN support. I also opened two others needed for hyper, one adding support for ALPN and one adding support for the socket recv_into method. I then blocked my next release of hyper on PyOpenSSL merging my NPN pull request and shipping a new release.
不幸的是， PyOpenSSL缺少NPN支持。 3月底，我打开了一个该添加了NPN支持。 我还打开了hyper需要的另外两个，一个添加了对ALPN的支持，另一个添加了对套接字recv_into方法的支持。 然后，我在PyOpenSSL上阻止了hyper下一个发行版，合并了我的NPN拉取请求并发布了一个新发行版。
As of now this has not happened. PyOpenSSL has fallen into a form of development hell where there does not appear to be sufficient resources to fix that blocks PyOpenSSL’s next release. Until this gets resolved there are unlikely to be future releases of PyOpenSSL.
到目前为止，这还没有发生。 PyOpenSSL已陷入一种发展地狱的形式，那里似乎没有足够的资源来解决阻止PyOpenSSL的下一个发行版 。 在解决此问题之前，不太可能会发布PyOpenSSL 。
A second problem stemming from this is that I no longer get to be excited about one of hyper’s planned marquee features for this release. The truly excellent added support for both CPython 2.7 and PyPy to hyper in March. This support remains in the library, but without PyOpenSSL is unusable.
由此产生的第二个问题是，我不再对hyper计划在此发行版中使用的计划字幕功能之一感到兴奋。 真正优秀的增加了支持两个2.7的CPython和PyPy以hyper三月。 该支持仍保留在库中，但是如果没有PyOpenSSL将无法使用。
hyper continues to have its test suite run on PyPy, CPython 2.7, and CPython 3.3, so when PyOpenSSL is eventually updated it should be a trivial job to re-add support for those Python distributions. I’ll make a big deal of it when it finally happens.
hyper继续在PyPy，CPython 2.7和CPython 3.3上运行其测试套件，因此，在最终更新PyOpenSSL时，重新添加对这些Python发行版的支持应该是一件容易的事。 当它最终发生时，我会做很多事情。
If you want more details, check out .
如果您需要更多详细信息，请查看 。
Onto the good stuff! Each feature has a link to its tracking issue (where applicable) directly after the header if you want more details or to see the code that added it.
好东西！ 如果您想了解更多详细信息或查看添加了此功能的代码，则每个功能都可以在标题后直接找到其跟踪问题的链接（如果适用）。
The development version of hyper has been keeping pace with the HPACK and HTTP/2 draft versions as they appeared. Version 0.1.0 contains support for HTTP/2-14 and HPACK-9. These versions are the current interop drafts, and also represent the Working Group Last Call documents. This means they’ll be kept unchanged for a while so that distributions can get interop experience.
hyper的开发版本一直与出现的HPACK和HTTP / 2草案版本保持同步。 版本0.1.0包含对HTTP / 2-14和HPACK-9的支持。 这些版本是当前的互操作性草稿，并且还代表工作组的上次呼叫文档。 这意味着它们将保持一段时间不变，以便发行版可以获得互操作性经验。
This feature alone makes it a perfect time to download hyper and give it a try!
单独使用此功能，使其成为下载hyper并进行尝试的绝佳时机！
Back when I wrote my announcing hyper I had the following to say about Server Push:
回到当我写我的宣布hyper我对服务器推送有以下说法：
I don’t believe it’s possible to write a pleasant API that correctly handles Server Push without using either an event loop or having hyper spawn its own background threads. Until asyncio becomes a standard, I don’t think hyper should force you to do the first, and it’s obnoxious for a library to spawn its own threads. This means that, for the moment, hyper does not support Server Push.
我不认为有可能编写一个令人愉快的API来正确处理Server Push，而无需使用事件循环或使用超级派生自己的后台线程。 在asyncio成为标准之前，我不认为hyper应该强迫您执行第一个操作，并且库产生自己的线程是令人讨厌的。 这意味着，目前，hyper不支持服务器推送。
I’m delighted to say that this is no longer true! Once again, Alek Storm did the heavy lifting here and deserves huge congratulations. The upshot is that hyper now supports Server Push and has it turned on by default. Check out for usage examples.
我很高兴地说这不再是真的！ Alek Storm再次在这里进行了繁重的工作，应受到巨大的祝贺。 结果是hyper现在支持Server Push，并且默认情况下已将其打开。 查看以获取用法示例。
One of the bits of feedback I got in response to was that I could avoid the overhead of making many syscalls by buffering socket data in userspace.
进行得到的反馈是，我可以通过在用户空间中缓冲套接字数据来避免进行许多系统调用的开销。
I’ve now gone ahead and done that: hyper maintains a 64kB buffer in memory for each connection to ameliorate some of the performance costs. It also avoids copying data for much longer, saving some overheads involved in unnecessarily copying memory around. Both of these changes should cause performance improvements.
我现在继续这样做： hyper为每个连接在内存中维护64kB缓冲区，以改善一些性能成本。 它还避免了将数据复制更长的时间，从而节省了不必要地复制内存所需的一些开销。 这两个更改都将导致性能提高。
For those interested in borrowing the implementation, the buffered socket can be found . You are welcome to use it in your own projects under the same license as hyper.
对于那些对借用实现感兴趣的人，可以在找到缓冲套接字。 欢迎您以与hyper相同的许可在自己的项目中使用它。
hyper by default uses its built-in pure-Python HPACK encoder and decoder, which is reasonably quick and fairly efficient. However, the awesome project contains a C implementation of HPACK that achieves astonishing compression faster than hyper does, while using less memory.
hyper默认情况下使用其内置的纯Python HPACK编码器和解码器，该编码器相当快且相当有效。 但是，令人敬畏的项目包含的C实现，该实现比hyper更快地实现惊人的压缩，同时使用更少的内存。
If you’re concerned about performance, you can now use nghttp2’s encoder and decoder with hyper! Simple install nghttp2 with the Python bindings, and hyper will prefer nghttp2’s encoder and decoder to its own.
如果您担心性能，现在可以将nghttp2的编码器和解码器与hyper ！ 使用python绑定简单安装nghttp2，并且hyper会更喜欢nghttp2的编码器和解码器。
This allows the best of both worlds: zero dependency installation, with optional performance improvements for those who want them.
这实现了两全其美：零依赖安装，并为那些需要它们的用户提供了可选的性能改进。
In future, I’ll probably approach nghttp2’s maintainers to suggest that they replace the Python bindings with a CFFI-based Python module to allow PyPy users to also use nghttp2.
将来，我可能会与nghttp2的维护者联系，建议他们用基于CFFI的Python模块替换Python绑定，以允许PyPy用户也使用nghttp2。
Discussed in part in .
在进行了部分讨论。
I’ve also taken my first step into adding features that are not supported in vanilla httplib, by adding support for HTTP trailers. These are headers sent after a chunk-encoded body, containing metadata that was not known before the request was sent. This is often things like Content-Length.
我还通过添加对HTTP预告片的支持，迈出了添加httplib不支持的功能的第一步。 这些是在块编码主体之后发送的头，其中包含在发送请求之前未知的元数据。 这通常是Content-Length类的东西。
httplib does not support trailers transparently, but hyper does. See for the relevant methods.
httplib不透明地支持预告片，但是hyper支持。 有关相关方法，请参阅 。
I’m aware that many people will not be able to use this method for fear of needing to switch back to vanilla httplib, which does not have it. I plan to start work on the abstraction layer soon, which should help ameliorate these concerns.
我知道许多人由于担心需要切换回没有此功能的普通httplib而无法使用此方法。 我计划尽快在抽象层上开始工作，这应该有助于减轻这些担忧。
We also added a number of smaller features. These are listed below, click on their issue links to see more information.
我们还添加了一些较小的功能。 这些在下面列出，单击其问题链接以查看更多信息。
HTTP20Response objects are context managers. HTTP20Response对象是上下文管理器。 翻译自:
超级猛料更新
转载地址：http://biqwd.baihongyu.com/