常见的序列化方式
JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式。易于人阅读和编写。同时也易于机器解析和生成。它基于JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一个子集。 JSON采用完全独立于语言的文本格式，但是也使用了类似于C语言家族的习惯（包括C, C++, C#, Java, JavaScript, Perl, Python等）。这些特性使JSON成为理想的数据交换语言。

Protobuf（Google Protocol Buffer ) 是Google公司内部的混合语言数据标准，
它是一种轻便高效的结构化数据存储格式，可以用于结构化数据串行化，或者说序列化。
它很适合做数据存储或 RPC 数据交换格式。可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。目前已经正在使用的有超过 48,162 种报文格式定义和超过 12,183 个 .proto 文件。他们用于 RPC 系统和持续数据存储系统。

知名协议HTTP

知名协议有很多比如http，ftp，dns，smtp，不过我们通常使用还是http协议

http也叫超文本传输协议---是一种简单的请求-响应协议

请求-响应协议：客户端发送一个请求，服务器针对请求进行处理响应，完毕后通信结束

它也是一种明文传输协议：以字符串组织数据格式（非常清楚）

实际上http是运行在tcp之上的，只不过应用层数据格式用的是http协议的格式；早期用于传输html文件，发展至今，可以传输大多数数据。

http协议格式

请求首行

请求方法：表示服务器发送一个什么样的请求（是请求资源还是提交数据）包含三个要素，以\r\n结尾

GET也可以提交少量数据，数据保存在URL中，长度有限制，存在安全隐患

URL：俗称网址，学名统一资源定位符-用于在网络中唯一定位一个资源

格式：协议方案名称 : //用户名：密码@服务器地址或域名：服务器端口/资源路径？查询字符串

身份认证信息-用户名和密码，存在安全隐患，现在很少用了
域名：一个便于记忆的字符串，最终需要进行域名解析得到服务器地址
端口：域名或者ip和端口就定位描述了网络上某一台主机的某个进程（http使用80端口，https使用443端口）
/资源路径：描述定位指定计算机上指定路径下的某个实体资源，/是一个相对根目录，对应服务器指定目录
查询字符串：客户端提交给服务器的少量数据，格式-key=val &key=val......
片段标识符：html中可以让网页欢动到指定位置，一个标签id，#id

urlencode:url编码，如果提交的数据中具有特殊字符，就有可能与url中的间隔符造成歧义，因此需要进行转义---url编码与之对应的是urldecode：url解码

协议版本

0.9版本：不算成熟的版本，只有GET进行超文本数据传输，协议格式不完善

1.0：规范了协议格式，新增支持GET/HEAD/POST方法，支持多媒体数据流的传输

1.1：支持了更多的请求方法以及头部字段，有了长连接管理，以及缓存管理

2.0基于http协议的臃肿，重新进行设计，解决了一些典型问题和性能问题

1.0相较于0.9版本，主要规范了协议格式，支持了更多功能以及数据传输方式

1.1相对于1.0版本，主要在于性能上的改进，以及其他一些特殊功能的添加；比如缓存控制：一些资源在没有改变的情况下不需要重新传输

短连接：http是基于tcp的，短连接就是建立连接，发送请求，得到响应，断开连接，跟不上性能

长连接：在一次连接中可以进行多次请求---有管线化思想

长连接相较于短连接，节省了大量连接建立的时间，而管线化的思想能够连续发送请求同时处理，节省时间，但是必须按照请求顺序相应，而2.0版本的长连接多路复用的思想避免了队头阻塞的问题，每个响应包含对应的请求描述，因此哪个资源准备好了就可以直接响应。

2.0版本相较于1.1做的改动更大

1.1版本做了很多性能提升的操作，比如长连接，缓存控制，分块传输......，但是这种改进是一个阶段性的改动，很多功能都冗余了，因此http协议变的很臃肿.

因此2.0版本推翻重做：

从明文传输改进为二进制传输
支持服务器主动推送数据（一次请求响应多个数据）
多路复用在响应头部添加请求信息，不用按序响应，解决队头阻塞问题
保存以前传输中没有出现的头部字段，相同的头部字段不用每次都重新传输了。

头部字段

典型头部字段

以key：val形式的键值对组成，每个键值对以\r\n结尾，关于请求或者正文的关键描述信息
Host：服务器域名或者地址信息
Connection:表示长连接还是短连接长连接：keep-alive 短连接:close
User-Agent：客户端浏览器以及系统版本信息
Accept：客户端告诉服务器我可以接受什么样的数据
Referer：里面包含一个连接，表示的是当前请求的来源页面
Content-Length：描述正文长度(请求或者响应必须完整才能处理，不完整就会出问题；当多个请求或响应连续发送，多个数据连接到一起就无法区别每个数据的起始和结尾，就会存在粘包问题。这个字段可以解决粘包问题，得到正文长度，取出指定长度的正文）
Content-Type：描述了正文类型，决定了对端如何处理正文数据

空行

空行：\r\n，用于间隔头部与正文

头部最后一个字段会以\r\n结尾，加上空行\r\n会组成一个连续的\r\n\r\n,这就是头部结束的标识

或者当头部字段逐个取出，而其中某个字段只有\r\n,则表示这就是空行就是头部结束的标识。

正文

就是提交给服务器的数据（GET请求没有正文，POST提交的数据放在正文中）

http响应格式

首行

明确针对请求的处理结果，包含三个元素，以空格间隔，以\r\n结尾

协议版本：0.9、1.0、1.1、2.0；

状态码	典型状态码以及含义
1xx	101协议切换的响应状态码
2xx	200-成功处理，206断点续传
3xx	301-永久重定向-下次请求直接请求新链接 302-临时重定向-每次请求先请求原链接
4xx	400-表示客户端请求错误；404-没有这个资源
5xx	500-内部错误、502-代理请求错误、504-请求超时

状态码描述：对于状态码的一些文字描述，并不具备实际意义

头部

与请求相同也是由key：val键值对组成，每个键值对以\r\n结尾，用于描述正文或者响应的关键信息

Content-Type：描述正文类型；针对不同的Content-Type对于相同的正文都有不同的处理

Content-Length：描述正文长度

Location：与3xx搭配重定向，描述重定向新链接

Set-Cookie：与请求中的Cookie搭配使用，用于实现http的cookie机制

服务端将客户端的一些信息通过Set-Cookie字段发送给客户端，客户端将这些信息保存到cookie文件中，下次请求服务器的时候将cookie信息从cookie文件中读取出来，通过Cookie字段发送给服务器，服务器收到之后就可以了解客户端的身份状态信息了

很明显，这样一直在服务端与客户端之间一直明文传输客户端的身份以及状态信息，存在安全隐患

因此有了session机制，当客户端发送认证信息到服务器，服务器会为每个客户端创建一个会话，会话信息中包含有客户端的身份以及状态信息，然后将其保存在服务器数据库中，每一个会话都有id，然后将session-id作为Set-Cookie的字段值传输给客户端，客户端在下次请求服务器的时候就会把session_id发送给服务器，服务器通过session-id就能在数据库中找到会话信息进而获取到客户端的状态信息，这样就会比较安全

cookie是客户端客户端状态信息保存在客户端，session是客户端状态信息保存在服务端

空行\r\n-用于间隔头部与正文

正文-响应给客户端的数据

HTTPS协议

https：本质上是对http协议，进行了一层在tcp协议上的SSL加密

与http的不同

https协议需要到ca申请证书，一般免费证书很少，需要交费。
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全

身份验证

引入一个第三方权威机构(双方都信任的机构），双方去权威机构颁发一个证书，在通信前，将证书发送给对方，对方根据证书中的信息判断对方的身份，并且去第三方权威机构进行认证通过后则身份验证成功，然后进行通信（双向身份验证，银行之类的），平时我们的浏览器访问通常只是单向验证（客户端验证服务器）；

数据加密

对称加密

使用相同的密钥进行加密解密。通信前将密钥交给对方，自己使用密钥进行数据加密，对方使用密钥解密，这种情况因为密钥容易被劫持，存在安全隐患

非对称加密

加密和解密使用的密钥不同。生成一对密钥（公钥和私钥），其中公钥用于数据加密，私钥进行数据解密。通信前将公钥传递给对方，对方使用公钥进行数据加密，数据到达后使用私钥进行解密，得到数据。

缺陷：加密解密效率很低，大量的加密运算。

混合加密

先进行非对称加密，通信前，将公钥交给对方，对方拿着公钥加密对称密钥的协商过程，协商完之后，使用协商出来的对称密钥进行通信。

在实际ssl加密中，将身份验证与混合加密进行融合

服务器（需要被验证的一方）,生成一对密钥
服务器带着公钥，去权威机构生成一个证书
通信时，在tcp连接建立成功后，将证书（权威机构，公钥等）首先发送给客户端
客户端收到证书后，进行解析，得到数据后去权威机构进行服务器身份验证
验证成功，客户端使用公钥加密自己所支持的对称加密算法列表以及一个随机数发送给服务器
服务器收到公钥加密的信息后，使用私钥进行解密，得到了客户端支持的算法列表以及随机数
服务器将自己支持的算法列表以及一个随机数发送给客户端
客户端与服务器各自根据算法列表以及自己和对方的随机数生成一个对称密钥
往后的通信就可以使用这个对称密钥加密解密了