工作杂记-关于IOS通过Safari使用https域名访问的坑

1、背景

为了测试环境与线上环境前端代码的接口访问地址编写统一，我们公司不直接使用ip进行访问，而是统一使用域名进行访问， 在本地开发测试时，通过内网DNS服务器解析到测试环境，当线上环境时，则解析到公网环境。
其他端都没有什么问题，但维度使用iphone通过safari访问时，然后Safari上就一直无法访问网站，Chrome没问题。
Safari上报错内容就是：…连接服务器中断…

2、查找过程

首先根据Safari报错内容找，什么都找不到
然后看Nginx的报错日志error.log，发现报

worker process xxx exited on signal 11

3、解决方案

在ngxin的配置文件中加入

ssl_session_cache    shared:SSL:10m;

重启后解决

4、SSL Session是什么？

网站启用https后，会加剧服务器的负担。每次新的TLS连续都需要握手，以便创建共享的加密密钥，在TCP三次握手之上还需要两个来回。

传统的http使用TCP三次握手建立连接，而SSL和TLS在这个基础上还需要9个握手包，所以这个负担显而易见。

不过，通过重用Session提高https的性能，TLS有几个特点可以抵消额外的握手：重用一个Session。

有两个标准会话重用机制：session IDs (RFC 5246) 和 session tickets (RFC 5077)，使用其中一个技术，一个客户端可以重用之前创建的会话，这个会话是之前和服务器进行握手成功的，这样可以减少一次来回过程。

基于SessionID的会话重用适合现代所有浏览器，FireFox和Chrome甚至还支持 session tickets。

Syntax:ssl_session_cache off | none | [builtin[:size]] [shared:name:size];
默认:
ssl_session_cache none;
Context:http, server
设置存储session参数的缓存的类型和大小。缓存可以是以下任何一种类型：
off
严禁使用session缓存：nginx明确告诉客户端session可能不会被重用。
none
session缓存的使用被禁止：nginx告诉客户端session可能会被重用，但实际上并不会将session参数存储在缓存中。
builtin
在OpenSSL中构建的缓存；仅由一个工作进程使用。缓存大小在session中指定。如果没有给出大小，则等于20480个会话。使用内置高速缓存可能导致内存碎片。
shared
所有工作进程之间共享缓存。缓存大小以字节为单位指定；一兆字节可以存储大约4000个session。每个共享缓存都应该有一个任意名称。具有相同名称的缓存可以用于多个虚拟服务器。
两种类型的缓存可以同时使用：配置案例:
ssl_session_cache builtin:1000 shared:SSL:10m;
但是只使用shared缓存，而不使用built-in缓存性能应该会更高。

目前使用较多的配置是built-in和shared同时使用：

ssl_session_cache builtin:1000 shared:SSL:10m;

但是Nginx官方说只使用shared，性能会更高，配置方法为：ssl_session_cache shared:SSL:10m;

5、 SSL Session的用处

启用 SSL Session 缓存可以大大减少 TLS 的反复验证，减少 TLS 握手的 roundtrip。
虽然 session 缓存会占用一定内存，但是用 1M 的内存就可以缓存 4000 个连接，可以说是非常非常划算的。
对于绝大多数网站和服务，要达到 4000 个同时连接本身就需要非常非常大的用户基数，因此可以放心开启。

虽然还不太清楚和IOS连接不上有啥关联，但先把这个知识mark一下吧