针对TCP/IP四层模型中各层的典型协议进行解析
应用层：应用层负责应用程序之间的沟通---程序员自己定义数据的组织格式
应用层协议：如何将多个数据对象组织成为一个二进制数据串进行传输（自定制协议---程序员自己定制的数据格式；知名协议---HTTP）
自定制协议：程序员自定制数据格式，定制的同时需要考虑传输性能、解析性能以及调试便捷性，如何组织更加适用当前的应用场景。
序列化：将数据对象按照指定协议进行组织实现持久化存储或者网络通信传输的二进制数据串的过程
反序列化：按照指定协议，将二进制数据串解析得到各个数据对象的过程
序列化方式：结构体二进制序列化，json，protobuf...
HTTP协议：超文本传输协议---html、xml...
前情信息：http是一个明文字符串传输协议；http在传输层基于tcp协议实现；http是一个简单的请求-响应协议
http协议格式（http数据结构，http协议实现）：
首行：请求行、响应行（对于请求与响应的简单关键描述）
头部：对于请求或响应或正文的一些关键描述，由一个个键值对组成---key:val，每个键值对以\r\n结尾
空行：\r\n，间隔头部与正文；\r\n\r\n---头部结尾
正文：客户端提交给服务端，或者服务端响应给客户端的数据
首行-请求行：请求方法，URL（URI），协议版本\r\n
请求方法：
GET：从服务端获取实体资源，要求服务器返回一个完整的实体资源；请求没有正文，也可以提交数据，但是提交的数据没有在正文中而是在URL中（GET提交数据不安全，URL长度有限制）
HEAD：从服务端获取实体资源，功能与GET类似，但是响应时不返回正文实体，只要头部信息
POST：向服务端提交数据，请求有正文，数据放在正文中
URL：网址---统一资源定位符（用于定位网络中某个主机上的某个资源）；URI：统一资源标识符
组成：协议名称://用户名:密码@域名:端口/资源路径?查询字符串#片段表示符
域名：服务器的别名---最终访问服务器需要经过域名解析得到服务器IP
资源路径：这个路径是一个相对根目录
查询字符串：提交给服务器的数据，由一个个key=val形式的键值对组成，键值对之间以&符号作为间隔
urlencode：编码-用户请求的资源路径，或者查询字符串中存在特殊字符，则有可能与url中的特殊字符冲突。因此需要将特殊字符每个字节转换为16进制数字字符，并前缀%（+ -> %2b）
urldecode：解码-遇到%则认为紧随其后的两个字符进行了编码，将这两个字符转换为数字，第一个数字左移4位加上第二个数字
协议版本：0.9，1.0，1.1，2
0.9：最早期的版本，只支持GET方法，并且协议还没有当前的规范，只支持超文本数据传输
1.0：规范了http协议格式，并且新增支持GET，HEAD，POST请求方法，支持各种多媒体资源传输，简单的缓存控制
1.1：更多的是对1.0版本进行性能的优化，支持了更多请求方法以及特性（支持长连接，更加完善的缓存控制，分块传输...），但是依然存在缺陷，比如管线化传输的队头阻塞问题
2.0：因为http协议的庞大冗余，因此2.0不是新增特性，而是重新定义http协议（使用二进制数据传输；支持主动推送资源；服务器进行长连接响应，不需要按序进行解决队头阻塞...）
首行-响应行：协议版本，响应状态码，状态码描述\r\n
响应状态码：直观的向客户端反馈处理结果
1xx：一些描述信息，101-协议切换状态码
2xx：表示本次请求正确处理，200-请求成功
3xx：重定向-表示本次请求的资源移动到了新的链接处，但是原链接依然可用，301-永久移动 / 302-临时移动
4xx：表示客户端错误，404-服务端无法根据客户端的请求找到资源（网页）
5xx：表示服务器错误，502-代理服务器没有收到正确响应，504-超时
状态码描述：就是针对状态的文字描述
头部：关于请求或者响应，或者正文的一些描述字段
组成：key:val\r\nkey:val\r\n
典型头部字段：
Connection：长短连接控制（keep-alive / close）
Referer：记录本次请求的来源连接
Content-Type：用于表示正文的数据格式
Content-Length：用于表示正文的长度-http解决粘包问题的关键字段
Location：用于指定重定向的新链接地址，与3xx搭配使用
cookie与session：涉及的头部字段请求头Cookie，响应头Set-Cookie
http是一个无状态协议
（1）一个客户端登录之后，服务端验证登录，成功后通过Set-Cookie字段设置cookie信息（用户信息，状态...）返回给客户端
（2）客户端收到响应后，将Set-Cookie字段的cookie信息保存起来，下次请求服务器的时候从cookie文件中读取出cookie信息，通过Cookie字段发送给服务器
cookie是一个维护http通信状态的技术，但是存在安全隐患
解决方案：session
session是服务端针对每个客户端所建立的会话，当客户端登陆成功后，创建会话，在会话中记录客户端用户信息及状态...，通过Set-Cookie字段将session_id返回给客户端
session_id每次请求都会发生变化，并且用户的隐私信息一直保存在服务器上防止泄漏
cookie与session的区别：
cookie是维护http通信状态的技术，将关键信息保存在客户端，每次请求服务器时，读取出来发送给服务端（有安全隐患）
session是解决cookie安全隐患的技术，将关键信息保存在服务器，将session_id发送给客户端，作为cookie保存起来，往后请求传输session_id即可，解决了cookie泄密的风险
空行：\r\n
是与头部最后一个字段的结尾\r\n组成连续的\r\n\r\n作为特殊标志作为http头部结尾的标志
正文
http是一个应用层协议，只是应用程序如何沟通的一种数据格式约定，在传输层是基于tcp实现的
http客户端实际上就是一个tcp客户端，http服务器实际上就是一个tcp服务端，只不过http客户端与服务端的通信使用的是http协议来约定数据格式而已
简单的http服务器的搭建：
（1）搭建tcp服务端
（2）获取新建连接
（3）使用新建连接，等待接收数据（http协议的请求数据）
（4）接收过程：先接收http头部，解析头部（Content-Length确定正文长度）
（5）接收指定长度的正文
（6）根据请求方法以及资源路径确定客户端的请求目的
（7）进行具体对应的业务处理
（8）组织http协议格式的响应数据，对客户端进行回复
（9）如果是短连接，则直接关闭套接字；如果是长连接，则继续等待接收数据
注意：http服务器编写完毕之后
虚拟机记得关闭防火墙：sudo systemctl stop firewalld
云服务器：记得设置安全组策略，开启对应端口
HTTPS协议：并不是一个新的协议，而是在HTTP协议基础上进行了一层加密，https协议就是基于ssl进行加密实现加密传输
https加密流程、ssl加密流程：
目的：实现数据的安全传输
安全传输：需要考虑两个问题
1.身份验证问题：防止伪装
2.数据加密问题：防止监听
身份验证实现：
CA认证：通信双方在通信前先到权威机构请求给自己颁发一个CA证书（权威机构信息，自己的信息...），通信双方建立连接后，在通信之前先将证书发送给对方，收到对方的证书后，查看这个权威机构是否是自己信任的权威机构，如果是，则到权威机构进行这个公司的身份验证，验证通过后进行通信，不通过可以自行选择是否添加信任。
但是身份验证通过，通信依然有可能被监听，存在风险，因此需要加密传输。
加密传输实现：
1.对称加密：加解密使用相同的密钥
优点：加解密效率高
缺点：密钥一旦被劫持则加密形同虚设
2.非对称加密：加密和解密使用不同的密钥
思路：通信中，每一端在通信前都可以生成一对密钥（公钥和私钥），在通信前，将公钥发送给对方，对方使用收到的公钥进行加密数据然后传输，自己收到数据后，使用私钥进行解密。
实现算法：RSA加密算法
优点：安全度更高
缺点：加解密效率低下
3.混合加密：通信双方先使用非对称加密保护对称密钥协商过程。对称密钥协商完毕后，使用对称密钥加密传输。
https加密流程：（将CA认证与混合加密合在一起使用）
（1）服务器先生成一对密钥（公钥和私钥），到权威机构使用公钥请求颁发一个证书（权威机构，本身机构，公钥信息，过期时间...）
（2）通信双方建立连接后，服务器将证书发送给客户端
（3）客户端对证书进行解析，根据信息进行身份验证
（4）身份验证通过后，使用公钥加密（一个随机数+自己支持的对称加密算法列表）发送给服务器
（5）服务器收到数据使用私钥进行解密，并且给客户端回复一个随机数+自己支持的对称加密算法列表
（6）双方通过自己的随机数与对方发送过来的随机数配合对称加密算法列表进行计算得到一个对称密钥
（7）往后通信使用对称密钥进行通信
![linux-svn卸载与安装[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)