akka.io包是结合spray-io模型开发的。
I/O 为了达到极端的可伸缩性，必须有一个可以正确匹配的底层传输机制，完全由事件驱动，并且是非阻塞和异步的。该模块提供了一些底层 TCP 以及套接字抽象，可以用于编写自定义的网络通信。从而提高了抽象的层次。
所有Akka I/O api都通过manager对象访问。当使用I/O API时，第一步是获取对合适的manager的引用，manager是处理底层I/O资源(选择器、通道)并为特定事件(如监听传入连接)实例化worker actor。
import akka.io.{ IO, Tcp }
import context.system // implicitly used by IO(Tcp)
val manager = IO(Tcp)//查找TCPmanager并返回它的AactorRef
当manager接收到 I/O 命令以后实例化worker actor，这些worker actor会将自己的在回复上述I/O命令的消息中展现出来。
例如，在manager向TCP manager发送一个Connect命令后，manager会创建一个actor来表示TCP连接，这个connection actor就是种worker actor，它会发送一个Connected消息来声明自己。然后所有与该TCP连接相关的操作都可以通过向这个connection actor发送消息来调用。
DeathWatch and Resource Management
I/O 的worker actor 负责接受命令并且发送事件（入站连接、传入字节或写入的确认）。通常需要一个与用户端对应的actor来listen这些事件。这些worker会监测他们对应的listener actor，如果listener停止，与其对应的worker actor 会释放自己掌握的所有资源。这种设计使得API更加稳健地避免资源泄露。
同样地，也有一个负责处理connection的user actor 监测 worker actor，如果worker actor 意外终止，会得到通知。
Write models (Ack, Nack)
I/O设备的最大吞吐量限制了写入的频率和大小。如果一个应用程序想要推动比设备能够处理更多的数据时，驱动程序必须缓冲字节，直到设备能够写入它们时。有了缓冲，可以处理短时间的密集写入——但没有缓冲区是无限的。为了避免压倒性的设备缓冲器akka提供了两种“流量控制”方式
-
Ack-based：当写入成功时，驱动程序会用Ack通知写入器。 -
Nack-based：当写入失败时，驱动程序会用Nack通知写入器。
当写入完成时，worker会将ack对象发送给写入器。这可以用来实现基于ack的流控制,只有当旧数据被确认才发送新数据。
如果写入(或任何其他命令)失败，则驱动程序会通知发送命令的actor。此消息还将通知编写失败的writer，作为该写入的nack。因为是异步的，失败的写入可能不是最近发送的，如果作者想要重新发送被删除的消息，需要保留一个等待消息的缓冲区。
注意：Ack/Nack只是两种流控制模式，用来表示写入成功/失败，但不是错误处理。即使所有的写入都被确认但也不能够保证数据不丢失。
ByteString
为了保持隔离，actor只需要跟不可变的对象进行联系。ByteString是不可变的字节容器。Akka的I/O系统使用它作为一个高效的、不可变的字节容器。用于JVM上的I/O，例如Array[Byte]和ByteBuffer。
ByteString是一个类似于rope-like的数据结构，它是不可变的，并且提供了快速的连接和切片操作(对I/O来说是完美的)。当两个ByteStrings串联在一起时，它们都存储在结果的ByteString中，而不是复制到新数组中。drop与take这种操作返回ByteString且仍然引用初始的数组，只需改变可见的偏移量和长度。还需要特别注意确保内部数组不能被修改。每当一个潜在的不安全的数组被用来创建一个新的ByteString时，就会创建一个defensive副本。
如果你需要一个ByteString，它只会为它的内容提供必要的内存，那么使用compact方法来获得CompactByteString实例。
如果ByteString只表示原始数组的一部分，那么这将在该切片中复制所有字节。
ByteString继承了IndexedSeq的所有方法，它也有一些新的方法。要了解更多信息，请查阅akka.util.ByteString类和它在ScalaDoc中的对象。
ByteString也有自己的优化构建器和迭代器类ByteStringBuilder和ByteIterator提供了额外的特性。
