mirror of
https://github.com/NohamR/knowledge-kit.git
synced 2026-05-25 12:27:15 +00:00
docs: SSL/TLS
This commit is contained in:
@@ -27,18 +27,17 @@ Mach 异常都在 host 层被 `ux_exception` 转换为相应的 unix 信号,
|
||||
有2种解决办法:
|
||||
|
||||
- Ignore the signal globally with the following line of code.(在全局范围内忽略这个信号 。缺点是所有的 `SIGPIPE` 信号都将被忽略)
|
||||
|
||||
|
||||
```objective-c
|
||||
signal(SIGPIPE, SIG_IGN);
|
||||
```
|
||||
|
||||
- Tell the socket not to send the signal in the first place with the following lines of code (substituting the variable containing your socket in place of `sock`)(告诉 socket 不要发送信号:SO_NOSIGPIPE)
|
||||
|
||||
|
||||
```c++
|
||||
int value = 1;
|
||||
setsockopt(sock, SOL_SOCKET, SO_NOSIGPIPE, &value, sizeof(value));
|
||||
```
|
||||
|
||||
|
||||
`SO_NOSIGPIPE` 是一个宏定义,跳过去看一下实现
|
||||
|
||||
@@ -51,9 +50,9 @@ Mach 异常都在 host 层被 `ux_exception` 转换为相应的 unix 信号,
|
||||
其中:**EPIPE** 是 socket send 函数可能返回的错误码之一。如果发送数据的话会在 Client 端触发 RST(指Client端的 FIN_WAIT_2 状态超时后连接已经销毁的情况),导致send操作返回 `EPIPE`(errno 32)错误,并触发 `SIGPIPE` 信号(默认行为是 **Terminate**)。
|
||||
|
||||
> What happens if the client ignores the error return from readline and writes more data to the server? This can happen, for example, if the client needs to perform two writes to the server before reading anything back, with the first write eliciting the RST.
|
||||
>
|
||||
>
|
||||
> The rule that applies is: When a process writes to a socket that has received an RST, the SIGPIPE signal is sent to the process. The default action of this signal is to terminate the process, so the process must catch the signal to avoid being involuntarily terminated.
|
||||
>
|
||||
>
|
||||
> If the process either catches the signal and returns from the signal handler, or ignores the signal, the write operation returns EPIPE.
|
||||
|
||||
UNP(unix network program) 建议应用根据需要处理 `SIGPIPE`信号,至少不要用系统缺省的处理方式处理这个信号,系统缺省的处理方式是退出进程,这样你的应用就很难查处处理进程为什么退出。对 UNP 感兴趣的可以查看:http://www.unpbook.com/unpv13e.tar.gz。
|
||||
@@ -146,8 +145,10 @@ if (self.socket == NULL) {
|
||||
```
|
||||
|
||||
### 2. 设备无可用空间问题
|
||||
|
||||

|
||||
最早遇到这个问题,直观的判断是某个接口所在的服务器机器,出现了存储问题(因为查了代码是网络回调存在 Error 的时候会调用我们公司基础),因为不是稳定必现,所以也就没怎么重视。直到后来发现线上有商家反馈这个问题最近经常出现。经过排查该问题该问题 `Error Domain=NSPOSIXErrorDomain Code=28 "No space left on device"` 是系统报出来的,开启 Instrucments Network 面板后看到显示 Session 过多。为了将问题复现,定时器去触发“切店”逻辑,切店则会触发首页所需的各个网络请求,则可以复现问题。工程中查找 NSURLSession 创建的代码,将问题定位到某几个底层库,HOOK 网络监控的能力上。一个是 APM 网络监控,确定 APMM 网路监控 Session 创建是收敛的,另一个库是动态域名替换的库,之前出现过线上故障。所以思考之下,暂时将这个库发布热修代码。之前是采用“悲观策略”,99%的概率不会出现故障,然后牺牲线上每个网络的性能,增加一道流程,而且该流程的实现还存在问题。思考之下,采用乐观策略,假设线上大概率不会出现故障,保留2个方法。线上出现故障,马上发布热修,调用下面的方法。
|
||||
|
||||
```
|
||||
+ (BOOL)canInitWithRequest:(NSURLRequest *)request {
|
||||
return NO;
|
||||
@@ -158,6 +159,7 @@ if (self.socket == NULL) {
|
||||
// 代理网络请求
|
||||
}
|
||||
```
|
||||
|
||||
问题临时解决后,后续动态域名替换的库可以参考 WeexSDK 的实现。见 [WXResourceRequestHandlerDefaultImpl.m](https://github.com/apache/incubator-weex/blob/master/ios/sdk/WeexSDK/Sources/Network/WXResourceRequestHandlerDefaultImpl.m#L37)。WeexSDK 这个代码实现考虑到了多个网络监听对象的问题、且考虑到了 Session 创建多个的问题,是一个合理解法。
|
||||
|
||||
```
|
||||
@@ -174,7 +176,7 @@ if (self.socket == NULL) {
|
||||
delegateQueue:[NSOperationQueue mainQueue]];
|
||||
_delegates = [WXThreadSafeMutableDictionary new];
|
||||
}
|
||||
|
||||
|
||||
NSURLSessionDataTask *task = [_session dataTaskWithRequest:request];
|
||||
request.taskIdentifier = task;
|
||||
[_delegates setObject:delegate forKey:task];
|
||||
@@ -183,7 +185,9 @@ if (self.socket == NULL) {
|
||||
```
|
||||
|
||||
### NSURLProtocol 主意事项
|
||||
|
||||
使用 NSURLProtocol 的时候,如果是代理 NSURLSession 的网络请求,则需要重写 protocolClasses 方法。但是在你往给方法设置 protocolClasses 的时候可能全局也有其他 SDK、工具类也做了修改。这样子需要注意不能丢弃别人的,也不能丢弃自己的。参考 OHHTTPStubs 在注册 NSURLProtocol 子类的处理
|
||||
|
||||
```
|
||||
+ (void)setEnabled:(BOOL)enable forSessionConfiguration:(NSURLSessionConfiguration*)sessionConfig
|
||||
{
|
||||
|
||||
Reference in New Issue
Block a user