HTTPS协议：
其实就是加密后的HTTP协议–自定制协议/HTTP协议。
https到底是如何进行加密传输的：
通过ssl加密实现–非对称加密算法/对称加密算法+签名证书
数据直接在网络中传输，很容易被劫持，有很大的安全隐患。—对传输过程进行加密
对称加密算法：
如何加密就如何解密–加密算法和解密算法是一样的。
- 优点：加密解密效率比较高。
- 缺点：容易被**，使用时间稍长就会被中间劫持，根据数据规律**出加密算法。
- 解决方法：最好能够每次通信都动态协商一个新的对称加密算法。
非对称加密算法：
加密和解密的方法不同。服务端生成一个公钥和私钥，将公钥传递给客户端，客户端使用公钥进行加密，服务端使用私钥解密。
- 公钥和私钥：通过加密算法-RSA算法，得到的一对**（就是两串数据），公钥用于对数据加密。私钥用于对加密后的数据进行解密。
- 优点：安全性高，不容易被**。
- 缺点：解密效率比较低。
将非对称加密和对称加密结合起来：将客户端与服务端进行动态协商对称加密算法过程使用非对称加密保护起来。然后使用协商后的对称加密算法对数据通信过程进行加密。这样就既保证了安全，也保证了效率。
但是若中间黑客劫持了公钥数据，然后将自己的公钥发送给客户端。因此公钥的传输也是存在安全隐患的。
如何确定发送公钥的这个服务端就是我心目中的那个服务器？如果能解决这个问题，就不怕被劫持了。
签名证书（CA）：进行身份验证，并且传输公钥信息。
公司生成了一对**之后，拿着**去权威机构掏钱颁发一个签名证书，证书中包含了：公钥信息、权威机构信息、当前公司机构的信息、有效时间….
ssl加密过程：
在通信的时候，连接建立成功之后，服务端就会先将证书发送给客户端。客户端根据证书中的机构信息，进行身份验证。
- 若身份验证不通过，则可直接断开连接（当然也可以设置是否信任这个机构）
- 若身份验证通过，然后使用证书中的公钥加密对称加密算法的协商过程，最终使用协商成功的对称加密算法对通信进行加密。
传输层：负责应用程序之间的数据传输。UDP/TCP
UDP：
无连接、不可靠、面向数据报。
协议实现：
- 16位源端口/16位目的端口：描述数据从哪个进程发送到哪个进程–负责实现应用程序间的数据传输
- 16位数据报长度：包含udp报文头部在内的整体报文长度–存储的最大数字为65535
- 16位校验和：二进制反码求和算法，用于校验接收到的数据和发送的数据是否一致。
如何验证数据是否一致：
发送方在发送数据前，校验和为0。从完整报文的第0个字节开始，每个字节进行取反相加。
超过16位的部分取出来，再次跟低16位进行相加，最终得到一个校验和填充到协议字段中。
接受方接收到数据之后，再次从完整报文的第0个字节开始，每个字节进行取反相加，最终得到一个值。
若为0，则表示数据一致。否则，则表示数据不一致。
1.无连接：通信的时候，不需要建立连接，只需要知道对方地址信息，就可以直接发送数据。
2.不可靠：通信过程中，并不保证数据安全可靠以及有序的到达对端。
3.数据报传输：无连接的、不可靠的，有最大传输长度限制的一种传输方式。
4.实现：有最大传输长度限制：udp报文头部中有一个数据报长度字段，最大数字是65535，限制了一个完整的udp报文的长度不能超过64K。
5.对上层程序员编写程序的影响：
- 影响：若sendto传输的数据（应用层的原始数据）：大小大于64k-8（udp报文头部长度是8个字节），则传输会报错。
因此若数据过长，需要程序员在应用层手动将大数据分割成一个个小的数据段（不大于64k-8）进行sendto发送。 - 影响：但是因为udp并不保证数据有序到达。这时候在上层，程序员进行数据分包之后，就要考虑在应用层实现各个数据段的包序管理。
- 影响：udp报文都是整条收发的。因此udp在使用recvfrom获取数据的时候，给予的buffer就要足够大。防止出现数据过长给出的buffer不够二报错，接收失败的情况。
因为udp报文头部中定义了报文长度。因此sendto发送数据的时候，数据一到发送缓冲区就会直接封装udp报文头部，然后发送数据。
（udp的socket发送缓冲区，形同虚设。因此并没有起到数据缓冲的作用）
接受方接受到数据，放到接收缓冲区中，用户recvfrom接收的时候，不会出现接收半条数据或者多条数据的情况，只能是一条完整的数据。
（接受半条数据，就会破坏接收缓冲区中的数据完整性，没有头部长度字段，就没办法解析剩下的数据）
TCP：
面向连接、可靠传输、面向字节流
协议实现：
- 16位源端口/16位目的端口：负责应用程序之间的数据传输
- 32位序号/32位确认序号：实现确认应答机制，以及进行包序管理
- 4位头部长度：表示tcp头部有多长。tcp头部是不定长数据，主要取决于选项数据的大小。以4字节为单位。tcp头部最小20字节，最大60字节（其中选项数据占0-40字节）
- 6位保留位：现在没想好用来干什么，先预留着以后扩展
- 6位标志位：URG/ACK/PSH：优先数据/RST：重置连接报文/SYN/FIN
- 16位窗口大小：用于实现滑动窗口机制，进行流量控制
- 16位校验和：二进制反码求和算法，校验数据接受和发送的一致性
- 16位紧急指针：表示哪些数据是紧急数据（外带数据）
- 0-40字节的选项数据：通常用于协商一些信息
面向连接
tcp协议中的连接管理（连接建立成功才能进行通信）
三次握手：
你在路上看到了一个很面熟的朋友，你需要通过招手的方式来确认对方认不认识自己。
你向他招手（SYN），他看到你向他招手，给你点了点头（ACK）。你看到他对你点头以后确认他认出了自己（进入ESTABLISHED状态）。
但是他不确定你是不是在跟别人打招呼，为了确认，他也向你招了招手（SYN），你看到他向你招手后知道他也在确认你。于是你点了点头（ACK），他看到了你点头以后确定你就是在跟他打招呼（进入ESTABLISHED状态）。然后你们走上前开始交谈。
四次挥手：
你在公司工作了很久以后想要辞职。
你先去找你的上司递交申请，上次审核你的申请（进入TIME_WAIT1状态）。上司要求你把手上的工作交接好，才能让你辞职（FIN）。你点头同意（ACK）。然后开始处理手头的工作（进入TIME_WAIT2状态）。三天的时间（进入TIME_WAIT状态），你把手上的工作都交接好了。找到你的上司说你的工作都已经交接好了（FIN）。你的上司说既然这样的话，那你可以走了（ACK）。你离开公司（进入CLOSE状态）。
握手为什么是三次：
tcp是双向通信，必须确保双方都具有数据收发的能力。假设客户端发送连接请求之后，直接退出了。因此都要给对方发送SYN请求。
挥手为什么是四次：
发送FIN，只是表示不在给对方发送数据。不代表不再接受数据。因此被动关闭方对FIN确认回复之后，依然还有可能要发送数据。主动关闭方还有可能会继续接收数据。也正是因为如此，被动关闭方不能将ACK和FIN合成一个进行发送（因为中间依然有可能有数据通信）
不代表不再接受数据