一、自定义协议和序列化反序列化
代码：
序列化反序列化实现网络版本计算器
二、HTTP协议
1、谈两个简单的预备知识
https://www.baidu.com/ --- 域名 --- 域名解析 --- IP地址
http的端口号为80端口，https的端口号为443
url为统一资源定位符。CSDN
https://mp.csdn.net/mp_blog/creation/editor?spm=1000.2115.3001.4503这就是一个url，所有网络上的资源，都可以用唯一的一个字符串标识，并且可以获取到资源。
网络行为：把别人的东西拿下来，把自己的东西传上去。
少量的情况，提交或者获取的数据本身可能包含和url中特殊的字符冲突的字符，要求BS双方进行编码和解码。
转义规则
2、http请求和响应，格式画出来，两个工具见一见http请求/响应的样子。
请求行内容
3、写一个最简单的httpserver，用浏览器直接测试
代码：
自主http实现
上图为http协议的请求报文的真实格式，每个字段代表什么，可以去自己搜一下。
user_agent :代表了客户机上所对应的浏览器型号等内容。通常表明这是一个很正常的客户端。反爬虫可以去检测这个user_agent。检测客户端是否合法。
4、谈http报文的细节
HTTP的方法
我们日常使用某些网站，我们把我们的数据是通过html中的表单来提交的
如果我们要提交 参数给我们的服务器，我们使用get方法的时候，我们提交的参数是通过url提交的！！
POST方法也可以提交参数，通过正文进行提交。GET方法通过URL进行提参，参数数量是受限的。不私密。POST方法是私密的。
HTTP的状态码
404没有发现要访问的资源
302 临时重定向，301永久重定向，搭配报头中的Location字段来使用。
让服务器指导浏览器，让浏览器访问新的地址
HTTP常见的Header
connection: keep_alive,这是一个长连接。一个巨大的页面是会包含非常多的元素的！每一个元素就是一个资源！一次请求响应一个资源就关闭连接，叫做短链接。建立一个TCP连接，发送和返回多个http的请求和回复，叫做长连接。
Content-type: 内容格式
cookie
http协议本身是无状态的。http对登录用户的会话保持功能。
原理：
浏览器保存cookie文件有两种方式，文件级和内存级。
向我们的浏览器写入cookie，做一个实验。
在回复报文中添加set-cookie字段
cookie被盗取的问题和个人信息泄漏的问题。
解决方案：session ID ,解决了私人信息泄露的问题。
session ID 是服务器端统一管理分配的。
HTTPS解决安全问题
HTTPS 协议讲解
HTTPS也是一个应用层协议
两个观点：
1、攻破的成本大于攻破后的收益，这样的网络协议就是安全的。
2、ssl权威的官方的加密解密方案。
SSL（Secure Sockets Layer）是一种用于在计算机网络上保护数据传输安全的协议，它通过在客户端浏览器和Web服务器之间建立一条SSL安全通道，提供对用户和服务器的认证、对传送的数据进行加密和隐藏、确保数据在传送中不被改变，即数据的完整性。SSL协议主要用来提供对用户和服务器的认证，确保数据传输的安全性，现已成为该领域中全球化的标准。此外，SSL证书是遵守SSL协议，由受信任的数字证书颁发机构（CA）在验证服务器身份后颁发的具有服务器身份验证和数据传输加密功能的数字证书（AI的回答）
基础概念的理解：
什么是加密：把一个明文通过一系列变换变成密文。
什么是解密：把一个密文通过一系列变换变成明文。
密钥：一系列变换的辅助数据称为密钥
常见的加密方式：
对称加密：加密解密所采用的密钥只有一个。特点是算法公开，计算量小，速度快。
需要两个密钥来进行加密和解密。特点是运算速度特别慢。
对公钥进行加密时，只有拥有私钥的人来解密。
数据指纹(数据摘要)使用hash算法转换为固定长度的，非常低概率发生冲突的字符串，具有唯一性。(MD5是典型的哈希算法)称为数据指纹（数据指纹）在经过加密会形成一个数据签名。
讲解思路
我们自己设计一套加密方式
方案一：只是用对称加密：
方案二：只是用非对称加密
非对称加密，用公钥加密的数据可以用私钥解密。用私钥加密的数据只能用公钥解密。
方案三：双方都是用非对称加密
双方互相把公钥发送给对方，都用对方的公钥进行加密。c-s用服务器的私钥解密。s-c 用客户端的私钥解密。貌似没有问题但是这里的效率太慢了并且仍然由安全问题。
方案四：非对称加密 + 对称加密
但是上面的方案，最开始就会受到中间人的攻击呢？
上面的方法就都不安全了。下面的方式为中间人攻击
确实，在⽅案2/3/4中，客⼾端获取到公钥S之后，对客⼾端形成的对称秘钥X⽤服务端给客⼾端的公钥 S进⾏加密，中间⼈即使窃取到了数据，此时中间⼈确实⽆法解出客⼾端形成的密钥X，因为只有服务 器有私钥S' ，但是中间⼈的攻击，如果在最开始握⼿协商的时候就进⾏了，那就不⼀定了，假设hacker已经成功成 为中间⼈
客户端无法验证服务器发来的公钥是否是合法的。、
那么如何保证安全呢？如何验证公钥是合法的呢？
CA证书：CA认证
服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信 息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端 公钥的权威性。
问题又来了，你怎么保证你的证书是权威机构发布且没有被改过呢？
证书里面有一个签名
CA证书的形成就可以用上面的算法来进行。上面的数据就是提交给CA的申请信息。CA使用散列函数。形成签名，CA机构也有自己的公钥和私钥注意这里的私钥和公钥跟之前讲的私钥和公钥毫无关系。用自己的私钥对签名进行加密。和数据附加到一起就形成了CA证书。服务器把证书发送给客户端的时候，client通过CA的公钥对签名进行解密。再按照上图验证的方式对数据和签名进行判断。如果在传输的过程中被修改。数据摘要和散列值会不相同，证书不可信。
方案五：
非对称加密 + 对称加密 + CA证书
所有的客户端只使用CA的公钥去解密我们的数字签名，也就意味着，只有CA能够进行证书的签发，因为只有CA自己具有私钥。所以中间人没资格进行证书的重新形成。如果我们中间人把整个证书都调换了呢？黑客申请真证书，提交信息。证书中的域名是不同的，域名具有唯一性。客户端还是可以识别的。
如何看待HTTPS？
其实是很安全的。但是如果中间人是客户本身。
