HTTPS深入底层探究【高级篇】
1.数字证书防止假冒服务器。
2.混合加密：非对称加密防止对称秘钥泄露，对称加密防止内容被篡改。
1.服务器有一对公钥和私钥
2.服务器把公钥给了CA认证机构，CA机构用CA密钥对 “CA的一些资料和服务器公钥”进行加密形成CA证书
3.CA机构把CA证书返给服务器，服务器再发送给客户端
4.客户端内置CA公钥，通过CA公钥验证数字证书的合法性，从CA证书中获取服务器的公钥。
1.苹果有三端 苹果服务器 苹果手机 苹果电脑
2.苹果电脑 请求证书颁布机构拿到csr文件 里面包含 公钥M和私钥M
3.苹果服务器有私钥s
4.苹果手机有公钥s
5.两对公钥密钥所以一看就会知道这是双重非对称加密
详细流程：
1.TCP 三次握手
2.TLS 三次握手：
1):client hello: 客户端发送SSL版本、随机数C、支持的加密算法等信息给服务端
2):server hello - server certificate - server hello - done: 服务端发送SSL版本、随机数、(根据客户端的支持的加密算法，选择出最高安全性的）加密方式、公钥、CA证书等信息给客户端
3):finished
3.客户端验证服务端证书（serverTrust）是否合法
1):使用本地CA公钥解密服务端发过来的CA证书 ，来获取到服务器的公钥，
2:)验证这个公钥与服务器直接发过来的公钥相比，看是否合法
4.客户端生成 Pre-master(预主秘钥)，用公钥加密后发给服务端
5.服务端用私钥解密，拿到预主秘钥，这样双方都有 random c + random s + Pre-master， 根据协定的算法生成对称秘钥。之后双方就可以使用对称秘钥加解密。
6.由于非对称加密安全性高、性能差。所以使用非对称获取到预主秘钥后，后续都是对称加密。
参考文章地址
UDP（用户数据报协议
TCP（传输控制协议）
1.形成传输数据的通道。
2.在连接中进行大数据传输（数据大小不受限制）。
3.通过三次握手完成连接，是可靠协议，安全送达。
4.必须建立连接，效率会稍低。
TCP如何保证可靠性：
ACK机制：
ACK延迟机制：
如果每个数据包都响应ACK，数量量会很大。所以有了ACK延迟， 一定时间内如果收到了多个数据包，只按照最后一个正确的数据，发送ACK。
短连接
1.数据请求结束后，立即断开连接。
2.能够及时释放服务器资源。
3.让服务器能够为更多的用户提供服务。
长连接
1.一旦连接建立之后，始终保持连接状态。
2.后续只需发送和接收数据即可，数据响应更及时。
3.长连接对服务器资源占用比较大。
4.对交互响应要求快的应用，例如即时通讯，需要使用长连接。
心跳包
1.是检测长连接的重要技术手段。
2.可以由服务器发送。
定时向客户端发送小数据，根据回执判断客户端是否在线。
3.也可以由客户端发送。
定时向服务器发送小数据，报告客户端当前在线。
1.反序列化：在从服务器接收到数据之后，将二进制数据转换成 NSArray / NSDictionary。
2.序列化：在向服务器发送数据之前，将 NSArray / NSDictionary 转换成二进制的过程。
NSJSONSerialization 类
在实际开发中，获得网络的数组或者字典之后，通常会做字典转模型！反序列化的结果是否可变并不重要
选项选择 0，表示任何附加操作都不做，效率最高！
MD5的加密方案：
三方框架的使用：
青山不改，绿水长流，后会有期，感谢每一位佳人的支持！
linux服务器， webSphere "WASPostParam" Cookie 反序列化拒绝服务，这个漏洞怎么解决？
配置nginx
#cookie_WASPostParam参数置空
if(cookie_WASPostParam != ""){set $cookie_WASPostParam "";}
防止序列化和反序列化被利用绕过安全管理器,有哪些检测方法？
这个反射顺序一反映是安全管理系，是有哪些复制方式？有哪些东西都用来里攻击不对，防止这些东西都不对
反序列化无法连接到远程服务器
无法连接到远程服务器可能的原因：
1、你的客户端参数配置不正确，无法用 SSH 登录到远程服务器；2、虽然你的客户端网络参数设置正确，但是远程服务器处于关闭服务，进行维护状态，你也不能够登录；3、即使以上两条都是正确的，如果你的局域网除了问题，同样还是不能够登录。本地网卡禁用网卡被禁用了服务器就不能连上因特网了，自然无法远程连接上服务器。开启防火墙后，没有在例外上把“远程桌面”的勾打上的话，同样得远程端口将会被防火墙屏掉，导致无法远程。
序列化与反序列化
把对象转换为字节序列的过程称为对象的序列化 。
把字节序列恢复为对象的过程称为对象的反序列化 。
对象的序列化主要有两种用途：
1） 把对象的字节序列永久地保存到硬盘上，通常存放在一个文件中；
2） 在网络上传送对象的字节序列。
在很多应用中，需要对某些对象进行序列化，让它们离开内存空间，入住物理硬盘，以便长期保存。比如最常见的是Web服务器中的Session对象，当有 10万用户并发访问，就有可能出现10万个Session对象，内存可能吃不消，于是Web容器就会把一些seesion先序列化到硬盘中，等要用了，再把保存在硬盘中的对象还原到内存中。
当两个进程在进行远程通信时，彼此可以发送各种类型的数据。无论是何种类型的数据，都会以二进制序列的形式在网络上传送。发送方需要把这个Java对象转换为字节序列，才能在网络上传送；接收方则需要把字节序列再恢复为Java对象。
java.io.ObjectOutputStream代表对象输出流，它的writeObject(Object obj)方法可对参数指定的obj对象进行序列化，把得到的字节序列写到一个目标输出流中。
java.io.ObjectInputStream代表对象输入流，它的readObject()方法从一个源输入流中读取字节序列，再把它们反序列化为一个对象，并将其返回。
只有实现了Serializable和Externalizable接口的类的对象才能被序列化。Externalizable接口继承自 Serializable接口，实现Externalizable接口的类完全由自身来控制序列化的行为，而仅实现Serializable接口的类可以 采用默认的序列化方式 。
对象序列化包括如下步骤：
1） 创建一个对象输出流，它可以包装一个其他类型的目标输出流，如文件输出流；
2） 通过对象输出流的writeObject()方法写对象。
对象反序列化的步骤如下：
1） 创建一个对象输入流，它可以包装一个其他类型的源输入流，如文件输入流；
2） 通过对象输入流的readObject()方法读取对象。
输出如下
输出如下
在序列化时显示指定serialVersionUID作为版本号，凡是实现Serializable接口的类都有一个表示序列化版本标识符的静态变量，如果不显示指定，jvm会隐式给我们随机生成一个serialVersionUID，这个serialVersionUID是根据对象的信息生成的，如果我们对序列化对象有所改动的话，serialVersionUID也会随之改动，再反序列化就会因serialVersionUID不一致而报错、
示例：
序列化和反序列化跟上面一样
反序列化
此时是正常且成功的，但是，我们如果现在在User对象新增一个属性
上面我说，serialVersionUID是根据对象信息生成的，现在对象多了一个属性，信息已经改变，再次生成的serialVersionUID 已经和刚才的不一样了，这时我们再进行反序列化会报如下错误
我们指定serialVersionUID后就可以随意修改了
序列化和反序列化
序列化（serialization）在计算机科学的数据处理中，是指将数据结构或对象状态转换成可取用格式（例如存成文件，存于缓冲，或经由网络中发送），以留待后续在相同或另一台计算机环境中，能恢复原先状态的过程。依照序列化格式重新获取字节的结果时，可以利用它来产生与原始对象相同语义的副本。对于许多对象，像是使用大量引用的复杂对象，这种序列化重建的过程并不容易。面向对象中的对象序列化，并不概括之前原始对象所关系的函数。这种过程也称为对象编组（marshalling）。从一系列字节提取数据结构的反向操作，是反序列化（也称为解编组、deserialization、unmarshalling）。
序列化在计算机科学中通常有以下定义:
序列化与反序列化为数据交换提供了可能，但是因为传递的是字节码，可读性差。在应用层开发过程中不易调试，为了解决这种问题，最直接的想法就是将对象的内容转换为字符串的形式进行传递。具体的传输格式可自行定义，但自定义格式有一个很大的问题——兼容性，如果引入其他系统的模块，就需要对数据格式进行转换，维护其他的系统时，还要先了解一下它的序列化方式。为了统一数据传输的格式，出现了几种数据交换协议，如：JSON, Protobuf，XML。这些数据交换协议可视为是应用层面的序列化/反序列化。
如前所述，序列化和反序列化的出现往往晦涩而隐蔽，与其他概念之间往往相互包容。为了更好了让大家理解序列化和反序列化的相关概念在每种协议里面的具体实现，我们将一个例子穿插在各种序列化协议讲解中。在该例子中，我们希望将一个用户信息在多个系统里面进行传递；在应用层，如果采用 .net 语言，所面对的类对象如下所示：
JSON中的元素都是键值对——key:value形式，键值对之间以":"分隔，每个键需用双引号引起来，值的类型为String时也需要双引号。其中value的类型包括：对象，数组，值，每种类型具有不同的语法表示。
基础类型
对象
数组
说到XML就不得不介绍下SOAP（Simple Object Access protocol），SOAP 是一种被广泛应用的，基于 XML 为序列化和反序列化协议的结构化消息传递协议。SOAP 在互联网影响如此大，以至于我们给基于 SOAP 的解决方案一个特定的名称 --Web service。SOAP 虽然可以支持多种传输层协议，不过 SOAP 最常见的使用方式还是 XML+HTTP。SOAP 协议的主要接口描述语言（IDL）是 WSDL（Web Service Description Language）。SOAP 具有安全、可扩展、跨语言、跨平台并支持多种传输层协议。如果不考虑跨平台和跨语言的需求，XML 的在某些语言里面具有非常简单易用的序列化使用方法，无需 IDL 文件和第三方编译器
实际使用中具体要使用哪个协议，我们可以从上列出的几个特性进行综合考虑
序列化协议一方面要能摆脱语言、平台的束缚；另一方面要在业界耳熟能详应用广泛。比如Java标准的对象序列化实现就不是这一条的好榜样，你要一个C程序员将Java标准序列化实现的数据反序列化成对应结构体是一个很蛋疼的事情。相反，JSON就是一个很好的序列化协议，至少在这一条上算得上是佼佼者了。
序列化协议要能方便开发过程中的调试。做过二进制协议开发的同学一定深有体会，肉眼基本不可辨别序列化后的数据，需要借助一些第三方的工具一点点分析。相对于二进制协议，文本协议就比较和蔼可亲了。
协议要能够经得住时间的考验。一般情况下采用公开流行的协议是不存在这个问题的，因为他们都被成千上万的应用检验过了。特别要小心的是自定义协议，举个反例，比如自定义一个类似于Java标准序列化协议的协议，由于当前业务没有涉及到对象和对象之间的继承关系，所以协议制定者没有考虑对象继承的情况。但是随着业务的发展，系统中出现了继承关系的实体类，某个同事不小心将这种对象的实例序列化，结果可想而知。协议不够成熟，所以自定义协议需要考虑的因数很多。如果自己不是大牛，建议不要自定义序列化协议。
和稳定性差不多，满足通用性条件的协议基本不会出现这个问题。问题还是会出现在自定义协议上。协议的成熟是一个漫长的过程，要经过不断的测试。比如稳定性中出现的那个问题，协议将继承关系的序列化加入，升级之后就能解决问题。但是要做到兼容以前的版本就不那么容易了。协议的制定者也不是圣人，不可能考虑得那么周全，但是一定要有一套可扩展的方案，这样协议才能存活下来，慢慢迭代成稳定版本。
说道性能问题，无非就是时间和空间的博弈。序列化结果数据的大小，直接影响网络传输的带宽和磁盘存储的空间。序列化和反序列化过程所消耗的时间长短，影响系统的性能。几种常用的协议性能的比较网上有很多，这里就不详细介绍了。
0条大神的评论