以下示例配置 UDP 出站通道适配器：

UDP 是一种高效但不可靠的协议。Spring Integration 添加了两个属性来提高可靠性：check-length和acknowledge. 当check-length设置为true时，适配器在消息数据之前加上一个长度字段（网络字节顺序中的四个字节）。这使接收方能够验证接收到的数据包的长度。如果接收系统使用的缓冲区太短而无法容纳数据包，则可以截断数据包。标length头提供了一种机制来检测这一点。

从版本 4.3 开始，您可以将 设置port为0，在这种情况下操作系统会选择端口。选择的端口可以通过getPort()在适配器启动并isListening()返回后调用来发现true。

从版本 5.3.3 开始，您可以添加一个SocketCustomizerbean 以DatagramSocket在创建后对其进行修改（例如，调用setTrafficClass(0x10)）。

以下示例显示了一个向数据报包添加长度检查的出站通道适配器：

第二个可靠性改进允许使用应用程序级确认协议。接收方必须在指定时间内向发送方发送确认。

以下示例显示了一个出站通道适配器，它向数据报包添加长度检查并等待确认：

从版本 4.3 开始，您可以将 设置ackPort为0，在这种情况下操作系统会选择端口。

以下示例显示如何使用 Java 配置出站 UDP 适配器：

（或MulticastSendingChannelAdapter用于多播）。

以下示例显示如何使用 Java DSL 配置出站 UDP 适配器：

以下示例显示如何配置基本单播入站 udp 通道适配器。

以下示例显示如何配置基本多播入站 udp 通道适配器：

默认情况下，对入站数据包执行反向 DNS 查找，以将 IP 地址转换为主机名，以便在消息头中使用。在未配置 DNS 的环境中，这可能会导致延迟。lookup-host您可以通过将属性设置为 来覆盖此默认行为false。

从版本 5.3.3 开始，您可以添加一个SocketCustomizerbean 以DatagramSocket在创建后对其进行修改。为接收套接字和为发送确认而创建的任何套接字调用它。

以下示例显示如何使用 Java 配置入站 UDP 适配器：

以下示例显示如何使用 Java DSL 配置入站 UDP 适配器：

从版本 5.0.2 开始，UdpServerListeningEvent当入站适配器启动并开始侦听时会发出 a。当适配器配置为侦听端口 0（即操作系统选择端口）时，这很有用。isListening()如果您需要在启动其他将连接到套接字的进程之前等待，它也可以用来代替 polling 。

( <int-ip:udp-outbound-channel-adapter>)UnicastSendingMessageHandler有destination-expression和socket-expression选项。

您可以将用作硬编码-对destination-expression的运行时替代方案，以确定针对 a 的传出数据报包的目标地址（使用评估上下文的根对象）。表达式必须计算为URI 样式（参见RFC-2396）中的 a 、 a 或a 。您还可以为此表达式使用入站标头。在框架中，当我们在 中接收数据报并将它们转换为消息时，会填充此标头。标头值正是传入数据报的结果。hostportrequestMessageURIStringSocketAddressIpHeaders.PACKET_ADDRESSDatagramPacketMessageMapperUnicastReceivingChannelAdapterDatagramPacket.getSocketAddress()

使用socket-expression，出站通道适配器可以使用（例如）入站通道适配器套接字通过接收数据报的同一端口发送数据报。它在我们的应用程序作为 UDP 服务器工作并且客户端在网络地址转换 (NAT) 后面运行的场景中很有用。此表达式必须计算为 a DatagramSocket。requestMessage用作评估上下文的根对象。不能将socket-expression参数与multicast和acknowledge参数一起使用。以下示例显示如何使用转换为大写并使用套接字的转换器配置 UDP 入站通道适配器：

以下示例显示了 Java DSL 的等效配置：

对于 TCP，底层连接的配置是通过使用连接工厂来提供的。提供了两种类型的连接工厂：客户端连接工厂和服务器连接工厂。客户端连接工厂建立传出连接。服务器连接工厂监听传入的连接。

出站通道适配器使用客户端连接工厂，但您也可以将客户端连接工厂的引用提供给入站通道适配器。该适配器接收在出站适配器创建的连接上接收到的任何传入消息。

入站通道适配器或网关使用服务器连接工厂。（事实上​​，没有一个连接工厂就无法运行）。您还可以提供对出站适配器的服务器连接工厂的引用。然后，您可以使用该适配器向同一连接上的传入消息发送回复。

您可以将连接工厂的引用引用到每种类型的最多一个适配器。

Spring Integration 提供了使用java.net.Socket和的连接工厂java.nio.channel.SocketChannel。

以下示例显示了一个使用java.net.Socket连接的简单服务器连接工厂：

以下示例显示了一个使用java.nio.channel.SocketChannel连接的简单服务器连接工厂：

以下示例显示了一个客户端连接工厂，它使用java.net.Socket连接并为每条消息创建一个新连接：

从 5.2 版本开始，客户端连接工厂支持属性connectTimeout，以秒为单位指定，默认为 60。

另请参阅基于注释的配置和使用 Java DSL 处理 TCP 组件。

TCP 是一种流协议。这意味着必须为通过 TCP 传输的数据提供某种结构，以便接收方可以将数据划分为离散的消息。连接工厂配置为使用序列化器和反序列化器在消息有效负载和通过 TCP 发送的位之间进行转换。这是通过分别为入站和出站消息提供反序列化器和序列化器来实现的。Spring Integration 提供了许多标准的序列化器和反序列化器。

ByteArrayCrlfSerializer^*将字节数组转换为字节流，后跟回车符和换行符 ( \r\n)。这是默认的序列化程序（和反序列化程序），可以（例如）与 telnet 作为客户端一起使用。

ByteArraySingleTerminatorSerializer^*将字节数组转换为字节流，后跟单个终止字符（默认为0x00）。

ByteArrayLfSerializer^*将字节数组转换为后跟单个换行符 ( 0x0a) 的字节流。

ByteArrayStxEtxSerializer^*将一个字节数组转换为一个字节流，前面是一个 STX ( 0x02)，后面是一个 ETX ( 0x03)。

将ByteArrayLengthHeaderSerializer字节数组转换为字节流，前面是网络字节顺序（大端）的二进制长度。这是一个高效的反序列化器，因为它不必解析每个字节来查找终止字符序列。它也可以用于包含二进制数据的有效载荷。前面的序列化程序仅支持负载中的文本。长度标头的默认大小是四个字节（一个整数），允许最多 (2^31 - 1) 个字节的消息。但是，length对于最多 255 字节的消息，标头可以是单字节（无符号），对于最多 (2^16 - 1) 字节的消息，标头可以是无符号短（2 字节）。如果您需要任何其他格式的标头，您可以子类化并为andByteArrayLengthHeaderSerializer提供实现readHeaderwriteHeader方法。绝对最大数据大小为 (2^31 - 1) 字节。从版本 5.2 开始，标头值可以包括标头的长度以及有效负载。设置inclusive属性以启用该机制（对于生产者和消费者，它必须设置为相同）。

ByteArrayRawSerializer^*将字节数组转换为字节流，并且不添加额外的消息分界数据。使用这个序列化器（和反序列化器），消息的结束由客户端以有序的方式关闭套接字来指示。使用此序列化程序时，消息接收会挂起，直到客户端关闭套接字或发生超时。超时不会产生消息。当使用此序列化程序且客户端是 Spring Integration 应用程序时，客户端必须使用配置有的连接工厂single-use="true". 这样做会导致适配器在发送消息后关闭套接字。序列化程序本身不会关闭连接。您应该仅将此序列化程序与通道适配器（而不是网关）使用的连接工厂一起使用，并且连接工厂应该由入站或出站适配器使用，但不能同时使用。另请参阅ByteArrayElasticRawDeserializer本节后面的 。但是，从 5.2 版开始，出站网关有了一个新属性closeStreamAfterSend；这允许使用原始序列化器/反序列化器，因为 EOF 被发送给服务器，同时保持连接打开以接收回复。

它们中的每一个都是 的子类AbstractByteArraySerializer，它同时实现org.springframework.core.serializer.Serializer和org.springframework.core.serializer.Deserializer。为了向后兼容，使用任何子类AbstractByteArraySerializer进行序列化的连接也接受String首先转换为字节数组的 a。这些序列化器和反序列化器中的每一个都将包含相应格式的输入流转换为字节数组有效负载。

为了避免由于表现不佳的客户端（不遵守配置的序列化程序协议的客户端）而导致内存耗尽，这些序列化程序会施加最大消息大小。如果传入消息超过此大小，则会引发异常。默认的最大消息大小为 2048 字节。maxMessageSize您可以通过设置属性来增加它。如果您使用默认序列化器或反序列化器并希望增加最大消息大小，则必须将最大消息大小声明为具有maxMessageSize属性集的显式 bean，并将连接工厂配置为使用该 bean。

本节前面标有^*的类使用中间缓冲区并将解码的数据复制到正确大小的最终缓冲区。从版本 4.3 开始，您可以通过设置一个poolSize属性来配置这些缓冲区，以让这些原始缓冲区被重用，而不是为每条消息分配和丢弃，这是默认行为。将该属性设置为负值会创建一个没有边界的池。如果池是有界的，您还可以设置poolWaitTimeout属性（以毫秒为单位），之后如果没有可用的缓冲区，则会引发异常。它默认为无穷大。这样的异常会导致套接字关闭。

如果您希望在自定义反序列化器中使用相同的机制，您可以扩展AbstractPooledBufferByteArraySerializer（而不是它的超类AbstractByteArraySerializer）并实现doDeserialize()而不是deserialize(). 缓冲区会自动返回到池中。 AbstractPooledBufferByteArraySerializer还提供了一个方便的实用方法：copyToSizedArray().

5.0 版添加了ByteArrayElasticRawDeserializer. 这类似于ByteArrayRawSerializer上面的解串器端，除了不需要设置 a maxMessageSize。在内部，它使用 aByteArrayOutputStream让缓冲区根据需要增长。客户端必须按顺序关闭套接字以发出消息结束的信号。

使用MapJsonSerializerJackson在 a和 JSONObjectMapper之间进行转换。Map您可以将此序列化程序与 aMessageConvertingTcpMessageMapper和 a结合使用，MapMessageConverter以 JSON 格式传输选定的标头和有效负载。

最终的标准序列化器是org.springframework.core.serializer.DefaultSerializer，您可以使用它通过 Java 序列化来转换可序列化对象。 org.springframework.core.serializer.DefaultDeserializer提供用于包含可序列化对象的流的入站反序列化。

如果您不希望使用默认的序列化器和反序列化器 ( ByteArrayCrLfSerializer)，则必须在连接工厂上设置serializer和属性。deserializer以下示例显示了如何执行此操作：

使用java.net.Socket连接并在线上使用 Java 序列化的服务器连接工厂。

有关连接工厂可用属性的完整详细信息，请参阅本节末尾的参考资料。

默认情况下，对入站数据包执行反向 DNS 查找，以将 IP 地址转换为主机名，以便在消息头中使用。在未配置 DNS 的环境中，这可能会导致连接延迟。lookup-host您可以通过将属性设置为 来覆盖此默认行为false。

另请参阅基于注释的配置和使用 Java DSL 处理 TCP 组件。

如果您的数据不是标准反序列化器支持的格式，您可以实现自己的；您还可以实现自定义序列化程序。

要实现自定义序列化器和反序列化器对，请实现org.springframework.core.serializer.Deserializer和org.springframework.core.serializer.Serializer接口。

当反序列化器检测到消息之间关闭的输入流时，它必须抛出一个SoftEndOfStreamException; 这是向框架发出的信号，表明收盘是“正常的”。如果在解码消息时关闭了流，则应该抛出一些其他异常。

从 5.2 版开始，SoftEndOfStreamException现在是 aRuntimeException而不是扩展IOException.

如前所述， TCP 套接字可以是“一次性的”（一个请求或响应）或共享的。在大容量环境中，共享套接字与出站网关的性能不佳，因为套接字一次只能处理一个请求或响应。

为了提高性能，您可以使用协作通道适配器而不是网关，但这需要应用程序级别的消息关联。有关详细信息，请参阅TCP 消息相关性。

Spring Integration 2.2 引入了缓存客户端连接工厂，它使用共享套接字池，让网关使用共享连接池处理多个并发请求。

您可以配置支持故障转移到一台或多台其他服务器的 TCP 连接工厂。发送消息时，工厂会遍历其所有配置的工厂，直到可以发送消息或找不到连接。最初，使用配置列表中的第一个工厂。如果随后连接失败，则下一个工厂将成为当前工厂。以下示例显示如何配置故障转移客户端连接工厂：

当与共享连接 ( singleUse=false) 一起使用时，连接工厂有两个与故障回复相关的属性：

基于上述配置考虑以下场景：假设clientFactory1无法建立连接，但clientFactory2可以。当该failCF getConnection()方法在通过后被调用时refreshSharedInterval，我们将再次尝试使用clientFactory1;进行连接。如果成功，连接clientFactory2将被关闭。如果closeOnRefresh是false，则“旧”连接将保持打开状态，并且如果第一个工厂再次失败，将来可能会重复使用。

设置refreshSharedInterval为仅在该时间到期后尝试与第一个工厂重新连接；Long.MAX_VALUE如果您只想在当前连接失败时恢复到第一个工厂，请将其设置为（默认）。

设置closeOnRefresh为在刷新后关闭“旧”连接实际上会创建一个新连接。

从 5.3 版开始，这些默认设置为Long.MAX_VALUE，true因此工厂仅在当前连接失败时尝试故障恢复。要恢复到以前版本的默认行为，请将它们设置为0和false。

另请参阅测试连接。

Spring Integration 5.0 版本引入了这个连接工厂。它将一个连接绑定到调用线程，并且每次该线程发送消息时都会重用相同的连接。这一直持续到连接关闭（由服务器或网络）或直到线程调用该releaseConnection()方法。连接本身由另一个客户端工厂实现提供，必须将其配置为提供非共享（一次性）连接，以便每个线程都获得一个连接。

以下示例显示如何配置 TCP 线程亲和连接工厂：

网关自动关联消息。但是，对于容量相对较小的应用程序，您应该使用出站网关。当您将连接工厂配置为对所有消息对使用单个共享连接 ('single-use="false"') 时，一次只能处理一条消息。新消息必须等到收到对前一条消息的回复。当为每条新消息配置连接工厂以使用新连接（'single-use="true"'）时，此限制不适用。虽然此设置可以提供比共享连接环境更高的吞吐量，但它会带来为每个消息对打开和关闭新连接的开销。

因此，对于大量消息，请考虑使用一对协作的通道适配器。但是，为此，您需要提供协作逻辑。

Spring Integration 2.2 中引入的另一个解决方案是使用 a CachingClientConnectionFactory，它允许使用共享连接池。

要实现大容量吞吐量（避免使用网关的陷阱，如前所述），您可以配置一对协作的出站和入站通道适配器。您还可以使用协作适配器（服务器端或客户端）进行完全异步通信（而不是使用请求-回复语义）。在服务器端，消息关联由适配器自动处理，因为入站适配器添加了一个标头，允许出站适配器在发送回复消息时确定使用哪个连接。

在客户端，如果需要，应用程序必须提供自己的关联逻辑。您可以通过多种方式做到这一点。

如果消息有效负载具有一些自然关联数据（例如事务 ID 或订单号）并且您不需要保留原始出站消息中的任何信息（例如回复通道标头），则关联很简单，并且将是在任何情况下都在应用程序级别完成。

如果消息payload有一些自然相关的数据（比如交易ID或者订单号），但是需要保留原始出站消息的一些信息（比如回复通道头），可以保留一份原始的出站消息（可能通过使用发布-订阅通道）并使用聚合器重新组合必要的数据。

对于前两种情况中的任何一种，如果负载没有自然相关数据，您可以在出站通道适配器上游提供一个转换器，以使用此类数据增强负载。这样的转换器可以将原始有效负载转换为包含原始有效负载和消息头的某些子集的新对象。当然，来自标头的活动对象（例如回复通道）不能包含在转换后的有效负载中。

如果您选择这样的策略，则需要确保连接工厂具有适当的序列化器-反序列化器对来处理此类负载（例如DefaultSerializerand DefaultDeserializer，它使用 java 序列化，或自定义序列化器和反序列化器）。TCP Connection FactoriesByteArray*Serializer中提到的选项（包括默认选项）不支持此类有效负载，除非转换后的有效负载是 a或。ByteArrayCrLfSerializerStringbyte[]

从 5.4 版开始，多个出站通道适配器和一个TcpInboundChannelAdapter可以共享同一个连接工厂。这允许应用程序支持请求/回复和任意服务器→客户端消息传递。有关详细信息，请参阅TCP 网关。

TCP 是一种流协议。 Serializers并Deserializers在流中划分消息。在 3.0 之前，只有消息有效负载 (String或byte[]) 可以通过 TCP 传输。从 3.0 开始，您可以传输选定的标头以及有效负载。replyChannel但是，不能序列化“活动”对象，例如标头。

通过 TCP 发送标头信息需要一些额外的配置。

第一步是提供ConnectionFactory一个MessageConvertingTcpMessageMapper使用该mapper属性的对象。此映射器委托给任何MessageConverter实现，以将消息与某个可以由配置的和反序列化的对象相互serializer转换deserializer。

Spring Integration 提供了一个MapMessageConverter，它允许指定添加到Map对象的标头列表以及有效负载。生成的 Map 有两个条目：payload和headers。该headers条目本身是 aMap并包含选定的标题。

第二步是提供一个串行器和一个解串器，可以在 aMap和某种线格式之间进行转换。这可以是自定义的Serializer或Deserializer，如果对等系统不是 Spring Integration 应用程序，您通常需要它。

Spring Integration 提供了一个MapJsonSerializer将 a 转换为MapJSON 和从 JSON 转换的方法。它使用 Spring Integration JsonObjectMapper。JsonObjectMapper如果需要，您可以提供自定义。默认情况下，序列化程序会0x0a在对象之间插入换行符 ( )。有关更多信息，请参阅Javadoc。

您还可以Map通过使用DefaultSerializerand来使用 , 的标准 Java 序列化DefaultDeserializer。

以下示例显示了使用 JSON 传输 、 和 标头correlationId的sequenceNumber连接工厂的配置：sequenceSize

使用上述配置发送的消息，有效负载为“某事”，将出现在网络上，如下所示：

不再使用池大小属性。以前，它在未指定任务执行器时指定默认线程池的大小。它还用于设置服务器套接字上的连接积压。不再需要第一个函数（参见下一段）。第二个函数被backlog属性替换。

以前，当使用 NIO 的固定线程池任务执行器（这是默认值）时，可能会出现死锁并且处理将停止。当缓冲区已满，从套接字读取的线程试图向缓冲区添加更多数据，并且没有线程可用于在缓冲区中腾出空间时，就会出现问题。这仅发生在池规模非常小的情况下，但在极端条件下也可能发生。从 2.2 开始，有两个变化消除了这个问题。首先，默认的任务执行器是一个缓存的线程池执行器。其次，添加了死锁检测逻辑，如果发生线程饥饿，则不是死锁，而是抛出异常，从而释放死锁的资源。

CallerRunsPolicy当您将固定线程池与（CALLER_RUNS使用<task/>命名空间时）一起使用并且队列容量较小时，您应该牢记一些重要的注意事项。

如果您不使用固定线程池，则以下内容不适用。

对于 NIO 连接，存在三种不同的任务类型。I/O 选择器处理在一个专用线程上执行（检测事件、接受新连接以及使用任务执行器将 I/O 读取操作分派给其他线程）。当一个 I/O 读取器线程（读取操作被分派到该线程）读取数据时，它会移交给另一个线程来组装传入的消息。大型消息可能需要多次读取才能完成。这些“汇编程序”线程可以在等待数据时阻塞。当发生新的读取事件时，读取器确定此套接字是否已经有一个汇编器，如果没有，则运行一个新的。当组装过程完成时，组装线程返回到池中。

当池耗尽、CALLER_RUNS拒绝策略正在使用以及任务队列已满时，这可能会导致死锁。当池为空且队列中没有空间时，IO 选择器线程接收OP_READ事件并使用执行器调度读取。队列已满，因此选择器线程自己启动读取过程。现在它检测到这个套接字没有汇编器，并且在它进行读取之前，触发了一个汇编器。同样，队列已满，选择器线程成为汇编器。汇编器现在被阻塞，等待读取数据，这永远不会发生。连接工厂现在已死锁，因为选择器线程无法处理新事件。

为了避免这种死锁，我们必须避免选择器（或读取器）线程执行组装任务。我们希望为 IO 和组装操作使用单独的池。

该框架提供了一个CompositeExecutor，它允许配置两个不同的执行器：一个用于执行 IO 操作，一个用于消息组装。在这种环境下，IO线程永远不可能成为汇编线程，也不会发生死锁。

此外，任务执行器应配置为使用AbortPolicy( ABORTwhen using <task>)。当一个 I/O 任务无法完成时，它会被延迟一小段时间并不断重试，直到它可以完成并分配一个汇编程序。默认情况下，延迟为 100 毫秒，但您可以通过设置readDelay连接工厂的属性来更改它（read-delay使用 XML 命名空间进行配置时）。

以下三个示例展示了如何配置复合执行器：

不管你是否使用NIO，都需要ssl-context-support在连接工厂上配置属性。该属性引用了一个 <bean/> 定义，该定义描述了所需密钥存储的位置和密码。

SSL/TLS 对等点分别需要两个密钥存储：

建立密钥存储之后，下一步是向TcpSSLContextSupportbean 指示它们的位置，并向连接工厂提供对该 bean 的引用。

以下示例配置 SSL 连接：

该类DefaultTcpSSLContextSupport还有一个可选protocol属性，可以是SSL或TLS（默认值）。

密钥库文件名（前两个构造函数参数）使用 SpringResource抽象。默认情况下，文件位于类路径上，但您可以使用file:前缀覆盖它（改为在文件系统上查找文件）。

从 4.3.6 版本开始，当你使用 NIO 时，你可以ssl-handshake-timeout在连接工厂上指定一个（以秒为单位）。在 SSL 握手期间等待数据时使用此超时（默认为 30 秒）。如果超时，则停止进程并关闭套接字。

从版本 5.0.8 开始，您可以配置是否启用主机验证。从 5.1 版本开始，默认启用；禁用它的机制取决于您是否使用 NIO。

主机验证用于确保您连接的服务器与证书中的信息匹配，即使证书是受信任的。

使用 NIO 时，DefaultTcpNioSSLConnectionSupport例如配置 .

第二个构造函数参数禁用主机验证。然后将connectionSupportbean 注入 NIO 连接工厂。

不使用 NIO 时，配置位于TcpSocketSupport：

同样，构造函数参数禁用主机验证。

在许多情况下，前面描述的配置就是启用 TCP/IP 上的安全通信所需的全部内容。但是，Spring Integration 提供了许多策略接口来允许自定义和修改套接字工厂和套接字：

要在使用 SSL 时启用客户端证书身份验证，该技术取决于您是否使用 NIO。当您不使用 NIO 时，提供自定义TcpSocketSupport实现来后处理服务器套接字：

（当您使用 XML 配置时，通过设置socket-support属性来提供对 bean 的引用）。

使用 NIO 时，提供自定义TcpNioSslConnectionSupport实现来对 进行后处理SSLEngine，如以下示例所示：

（当您使用 XML 配置时，从版本 4.3.7 开始，通过设置nio-connection-support属性来提供对您的 bean 的引用）。