· 自定制协议

应用层：负责应用程序之间的数据沟通。

自定制协议：程序员自己订立的协议，自己约定一个应用程序之间的数据格式。

1.序列化

       按照指定的数据格式，将多个数据对象组织成为可以持久化存储或数据传输的二进制数据串。

2.反序列化

       按指定格式将二进制数据串解析得到多个数据对象。

3.需要考量因素

       1）组织&解析效率；

       2）传输效率；

· HTTP协议

一、基本概念

HTTP协议：超文本传输协议。

       1）是一个应用层协议，在传输层使用的是TCP协议；

       2）是一个明文传输协议（以字符串形式组织指定格式数据传输）；

       3）是一个简单的 请求-响应 协议；

默认端口：80

注：http服务器实际上就是一个tcp服务器，只不过上层的数据格式采用的是http的协议格式。

二、HTTP协议格式

1.请求格式

1.1首行（请求行）

       首行格式：请求方法 URL 协议版本\r\n

<1> 请求方法：直观表示请求类型

       GET：主要用于从服务器获取实体资源，没有正文；也可以用于提交数据，但是数据是放在URL中，有长度限制，也不安全。

       POST：主要用于向服务器提交数据，数据放在正文中。

       HEAD：与GET功能类似，但是响应中不要实体数据，只要头部。

       ……

<2> URL：统一资源定位符---我们通常称之为网址

URL： 定位网络中的某个主机上的某个资源，并且定义如何请求。

一个较为完整的URL所包含的要素：

       协议方案名称：//用户名:密码@域名:端口/资源路径？查询字符串#标识符

       http://user:pass@ip:port/path?query_string#id

       http：协议方案名称；

       user:pass：用户名和密码；

       ip：域名最终需要转换为服务器IP地址；

       port：端口，HTTP协议默认使用80端口；

       /path：资源路径；

       query_string：查询字符串，由key=val&key=val形式键值对组成；是客户端提交给服务器的数据；

       id：片段标识符，是超文本数据中的一个标签id。

URL编码：

       query_string提交给服务器的数据中，如果有特殊字符，则会与http协议的间隔符产生歧义，因此查询字符串中不能有特殊字符。如果提交的数据中有特殊字符，就需要URL编码。

1）urlencode-编码：

       将一个特殊字符的每个字节，转换为两个16进制字符，比如‘+’ 转换为"%2B"，并且前缀%修饰用于表示这是经过转码后的数据。

2）urldecode-解码：

       当在URL中遇到%字符，则认为紧随其后的两个字符是需要解码的。将第一个16进制字符转换为数字，乘以16，再加上第二个字符转换后的数据。例：%2B---> 2*16+11=43。

<3> 协议版本：0.9->1.0->1.1->2.0->……

       0.9版本：不是一个完善的版本；

       1.0版本：主要针对0.9版本完善了协议格式，订立了各种请求方法；默认使用短连接。

       1.1版本：主要针对1.0版本进行了一些性能优化

       2.0版本：使用二进制传输，有了更多的性能优化。

★1.1相较于1.0所做的比较典型的性能优化：

       1）缓存控制：资源在本地或者在代理服务器上的缓存管理，大大提高资源的重新获取效率。

       2）对长连接进行了优化，默认使用长连接；

短连接：通信中，一次请求-一次响应则通信结束，断开连接；

             建立连接-发送请求-接收响应-关闭连接-通信结束；

长连接：在一次连接中，可以连续进行多次请求-响应；但是必须要在上一次请求响应之后，才能进行新的请求。

1.1版本对长连接的优化：

管线化：不用等待上次请求收到响应后再去发送下一个请求，可以连续请求；但是需要按序响应；所以存在队头阻塞问题。

2.0版本的优化：

多路复用&主动推送：一次请求的响应中，可以推送多个资源；并且可以连续请求，响应中带有对应请求标识，不需要按序响应---解决了队头阻塞问题，以及避免了重复头部字段的传输。

1.2头部

由一个个key：val\r\n形式的键值对组成，描述正文或请求的详细信息。

       Referer：记录当前请求的来源链接；

       User-Agent：记录客户端的系统及浏览器版本；

       Connection：控制长短链接，close(短连接)、keep-alive(长连接)；

       Content-Length：用于描述正文长度（解决粘包问题）；

       Content-Type：+描述正文编码类型（解决了客户端或服务器如何处理正文问题）；

       Cookie：实现cookie机制---维护http通信状态。

1.3空行

       \r\n，与最后一个头部字段结尾的\r\n组成连续的\r\n\r\n，构成头部结尾标志。

       http客户端or服务器在接收数据时，就是以此为标志，先取出完整的头部信息，然后解析头部，得到各个头部字段，再根据头部字段中的Content-Length确定正文长度，然后再取出指定长度的正文，最后本次请求or响应结束。

1.4正文

       提交给服务器的数据

2.响应格式

2.1首行（响应行）

首行格式：协议版本 响应状态码 状态码描述

<1>协议版本：0.9，1.0，1.1，2.0

<2>响应状态码：直观表示处理结果，分为5大类。

       1xx：一些协议切换协商的描述；101-协议切换；

       2xx：请求成功处理；200-成功；

       3xx：重定向--当一个资源的URL发生改变，使用重定向保持原链接依然可用；

               301-永久重定向：之后访问则直接访问重定向后的新地址；

               302-临时重定向：之后访问仍是访问原先的地址；

       4xx：表示客户端错误；

               400：客户端请求错误

               404：请求的资源不存在；

       5xx：表示服务端错误；

               500-服务器内部错误；

               502-网关或代理服务器，请求失败；

               504-网关或代理服务器，请求超时；

<3>状态码描述：对于状态码的一个简单文字描述。

2.2头部

头部字段：key:val\r\n形式的键值对，对于响应以及正文的一些描述；

       Set-Cookie：实现cookie机制---维护http通信状态；

       Location：保存新连接，搭配3xx实现重定向；

2.3空行

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

2.4正文

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

三、HTTP的cookie机制&session会话管理

1.cookie机制

cookie：是服务器通过Set-Cookie字段返回的希望客户端保存的一些数据，在客户端下次请求服务的时候发送给服务器，通常用于HTTP的状态维护。

响应头部：Set-Cookie  请求头部：Cookie  合起来实现了HTTP的cookie机制：

       1.当发起一个用户登录请求，服务器进行登录验证，登录成功后，将用户名以及状态信息等数据作为Set-Cookie字段的值，发送给客户端。

       2.客户端浏览器就会把Set-Cookie中的数据保存到cookie文件中。

       3.在客户端下次请求指定服务器的时候，从cookie文件中读取出cookie内容，然后通过Cookie字段发送给服务器。

cookie机制：维护http协议通信状态的一种机制

       客户端将服务器返回的一些cookie信息保存起来，在下次请求服务器的时候发送给服务器，以此方式维护客户端的通信状态。

注：cookie存在安全隐患，因为它导致不断的将客户端的敏感隐私信息进行传输。解决方法：session会话管理。

2.session会话管理

       1.客户端登陆成功后，服务器会为每个客户端创建一个会话，其中包含了客户端的各项信息，然后将会话session信息保存在服务器的数据库中，将会话ID作为cookie内容发送给客户端。

       2.客户端在下次请求服务器的时候就会把会话ID发送给服务器，服务器通过会话ID查找会话信息，进而获取到客户端的各个状态信息。

3.cookie与session的区别

cookie：

       是将信息保存在客户端本地，每次请求的时候将信息发送给服务器，存在安全隐患。

session：

       是将客户端状态信息保存在服务器，通信的时候以session_id作为cookie进行传递，安全性相对更高。

四、HTTPS协议

1.概述

HTTPS协议：对HTTP协议进行ssl加密后的协议。

默认端口：443

2.HTTPS协议的加密流程

加密包含两个方面：身份验证，加密传输

加密：使用ssl加密。

2.1身份验证

CA验证：使用第三方权威机构进行身份验证

       1）通信双方中，需要被验证身份的一方或两方，先到权威机构颁发一个CA证书；

       2）连接建立之后，双方或需要被验证身份的一方，将自己的CA证书发送给对端；

       3）对端对证书进行解析，先判断证书颁发机构是否是自己信任的权威机构，然后到权威机构进行对方的身份认证。

2.2加密传输

加密传输：让外界无法直接获取到通信内容

1）对称加密

       加密和解密使用相同的密钥，加解密效率高。

缺点：但是密钥的协商过程容易被监听劫持。

2）非对称加密

       加密与解码使用的密钥不同，分为公钥加密和私钥解密；

       公钥：是通信前交给对方的密钥，对方使用公钥进行数据加密；

       私钥：自己收到公钥加密的数据后，使用私钥进行解密（公钥无法解密）；

优点：安全度更高

缺点：加解密效率低

3）混合加密

       ①连接建立后，先使用非对称加密，将自己的公钥发送给对方；

       ②双方使用对方的公钥，对“对称密钥”协商过程进行加密；

       ③对称密钥协商完毕后，往后通信使用对称加密。

2.3 ssl加密流程

若服务器需要被验证身份：

       1）服务器先自己生成一对密钥（公钥和私钥），带着公钥到权威机构颁发CA证书；

       CA证书：权威机构信息、当前机构信息、公钥信息……

       2）连接建立成功后，服务器将自己的CA证书发送给客户端；

       3）客户端对证书进行解析，判断是否是自己的信任机构；

       4）如果是，则去对应的权威机构进行身份验证；

       5）客户端带着证书中的公钥，将 一个随机数+自己支持的对称算法列表 发送给服务器；

       6）服务器收到之后，使用私钥进行解密，给客户端也回复 一个随机数+自己支持的对称算法列表；

       7）双方使用两个随机数以及双方支持的算法列表，计算得到一个对称密钥；