android 上传图片是报错。

1.错误描述
ClientAbortException: java.io.IOException: Broken pipe

可能出现原因：

TCP服务端write数据时，收到SIGPIPE信号（连接已经终止）

场景：

TCP握手尚未结束时，连接已经close；
服务端收到一次read，但write了多次；
连接通道被占满，新连接被拒绝时，client中断了所有连接。
2.分析过程
2.1.初步排查
每次出现该异常时，总是伴随/im/getUsercInfos.json接口的调用。

2.1.1具体现象
异常记录时间=接口请求记录时间(server连接write前记录)-（2至10）ms；
总是ios设备爆出；
总是h端爆出。
2.1.2分析
可能性一:
在请求该接口时，ios设备在某种情况下会中断该请求，导致TCP连接中server端无法向client端write数据。即在server端write之前连接已经close，write时出现异常。
由于只有h端出现，但h、b客户端代码一致，不太可能单独出现，故可能性较低。

可能性二:
在第一次连接已经正常握手，并正常close后，server端在此执行write操作。即对一个对端已经关闭的socket调用两次write，报出SIGPIPE信号，导致异常。
由于只有ios设备有该问题，故可能性较低。

可能性三：
请求接口本身问题或并发调用问题，引起了连接close或连接过多超限导致client端close连接。
目前acceptCount配置100，观察日志，报错时间区间中并没有如此大量的并发请求，且client端收到拒绝信息时，不确定是否会中断所有请求（理论上不会）。故可能性较低。

2.2.细致排查
伴随该异常的接口，入参和出参量较大（猎头端im对话列表1000-3000个是常态），接口处理时间长，且伴随不同程度的连续请求。

2.2.1具体现象
入参传入emNames数量600-4000个，约15000-100000字符长度；
出参返回约60000-500000字符长度；
执行时常约500-4000ms；
2.2.2分析
可能性一:
处理报文过长，client端无法解析/处理过大报文，导致本次及下次请求。
客户端系统对于大报文的处理问题需要测试和调研，故有可能性。

可能性二:
处理时间过长，导致当client端并发请求时，当上次请求尚未完成，下次请求会close上次请求，以本次为准。
调研后发现client端是阻塞请求，但需要进行实际测试，故有可能性。

可能性三:
处理时间过长，在握手过程中client自行中断了连接。
由于执行时间较长，频率较高，客户或设备自己可能触发kill进程或关闭连接等操作，故有可能性。