为什么客户端和服务器不支持ssl协议或者加密算法？

客户端和服务器确实不支持一般ssl协议或加密套件。

>

>

1、更换其他CA机构签发的证书，保证其CA根证书的在特定设备上已默认信任。

2、手动在受影响的设备上安装该CA根证书及中间证书，并配置为信任状态。

3、客户端App预置该CA根证书，并通过客户端代码配置信任该证书。

ssl协议支持哪几个加密算法：

1、RSA

RSA作为一种国际通用算法，是建立在大整数因子分解的假设基础上的。假定没有整数分解的有效算法，则认为RSA密文的完全解密是不可行的。用户创建并发布RSA的两个大质数的乘积和作为其公钥的次要值。关键要素必须保密。每个人都可以使用公钥加密信息，但是只有理解关键要素的人才能对信息进行解码。现在基本每款SSL证书都支持RSA算法。

2、ECC

ECC算法于2004年投入使用，ECC算法是在有限域上，椭圆曲线密码学依赖于椭圆曲线的代数结构。假定发现随机椭圆曲线元素与公知基点有关的离散对数是不现实的。与RSA算法相比，ECC算法的优势在于密钥较小，提高了速度和安全性。不利之处是，并非所有服务和应用程序都能与基于ECC的SSL证书进行互 *** 作。

ECC算法成为了新一代算法趋势主流，加密速度更快，效率更高，更安全，抗攻击性更强，但在兼容性上不及RSA广泛。

我们还是从计算机的网络层说起，主要是分为7个层分别是物理层，数据链路层，网络层，传输层，会话层，表示层，应用层。

数据之间的交互主要在传输层这一块。通常用到的底层协议有TCP和UDP这两种协议。通过中间层SOCKET协议，进行包装，再往上就是我们经常用到的>

>

上面这个就是我们网站的>

同时我们的实时聊天软件，比如今日头条的聊天软件就是通过TCP，SOCKET来进行通信的，这种是面向连接的长链接方式，双向通信。响应指定封包协议和解包协议，通过socket的处理，去监听两端的端口，分别获取各自的数据，和发送各自的数据。实现双向通信。具体过程如下：

>客户端步骤

1创建套接字

2向服务器发送连接请求（connect）

3通信（send/recv)

4关闭套接字

>服务器端步骤

1创建用于监听的套接字（socket）

2将套接字绑定到本地地址和端口上（bind）

3将套接字设为监听模式（listen）

4等待客户请求（accept），此处要不断的调用accept

5通信（send/receive），完成后返回4

6关闭套接字（closesocket)

谢谢阅读，欢迎关注。

TCP报文首部中有标识位，共6个
URG：紧急指针（urgent pointer）有效。
ACK：确认序号有效。
PSH：接收方应该尽快将这个报文交给应用层。
RST：重置连接。
SYN：发起一个新连接。
FIN：释放一个连接。
RST一般是在FIN之后才会出现为1的情况，表示的是连接重置。一般地，当出现FIN包或RST包时，我们便认为客户端与服务器端断开了连接。所以在客户端不知道的情况下，协议栈最有可能返回SYN

服务器初始化
(1)调用socket,建立文件描述符
(2)调用bind,将文件描述符与ip/port链接起来。若端口号已被占用，则bind失败
(3)调用listen，声明该文件描述符是服务器的一个文件描述符，为以后的accept作准备
(4)调用accept,并处于阻塞状态，等待客户端链接
创建链接
(1)调用socket，建立文件描述符
(2)调用connect，向服务器发起链接请求。
(3)connect会发送一个请求SYN段并阻塞等待服务器应答(第一次)
(4)服务器收到SYN，会给客户端发送一个确认应答的同时发送一个请求(SYN+ACK)，表示赞成创建链接(第二次)
(5)客户端收到客户端发的SYN+ACK段，代表客户端链接已创建成功，进入ESTABLISHED状态，从connect()。客户端再向服务器发送一个ACK段，服务器收到后则服务器端链接也创建成功，服务器也进入ESTABLISHED状态。
a98328b87f4c48d3b44670f231eaa59agif
数据传输
(1)链接创建成功后，在同一链接、同一时刻，通讯双方可同时写数据(全双工)
(2)服务器端从accept()返回后调用read()开始读数据，若没有数据则阻塞等待
(3)客户端调用write()向服务器发送数据请求，客户端收到以后调用read()处理请求，此过程服务器调用read()阻塞等待
(4)服务器调用write()将处理好的请求发送给客户端，再次调用read()等待下一个请求
(5)客户端收到后从read()返回，发送下一条请求，如此循环下去web
断开链接
(1)没有数据处理了，则客户端调用close()关闭链接，给服务器端发送一个断开链接请求FIN段(第一次)
(2)服务器收到客户端的FIN段，给客户端发送一个确认应答ACK段代表赞成断开链接，客户端收到ACK段并调用read()返回0，代表客户端链接已断开(第二次)
(3)read()返回0以后，服务器知道客户端已断开链接，它也调用close()关闭链接，给客户端发送一个断开链接请求FIN段(第三次)
(4)客户端接收到服务器端发送的FIN段，给服务器一个确认应答ACK段，代表赞成断开链接。客户端进入TIME_WAIT状态，服务器收到客户端的ACK后则服务器断开链接。
a98328b87f4c48d3b44670f231eaa59agif 服务器
总结：
1为何是三次握手而不是两次或四次握手？
(1)若是是两次握手，则客户端发送链接请求SYN，服务器端接收链接请求并给客户端发送一个ACK进入ESTABLISHED状态，服务器端认为链接创建成功。有可能服务器端发送的ACK在传输过程当中丢了，客户端没有收到ACK从而认为链接没有创建成功。客户端认为链接没有创建成功则会不停的发送链接请求，而服务器认为链接成功则须要文虎相应的资源来管理链接，但这个链接无心义，服务器在维护的时候会浪费服务器资源。形成空间与时间上的浪费，从而形成内存泄漏的问题。四次握手问题同二次握手。
(2)三次握手的最后一次传送数据有可能也会形成丢包问题，可是此时客户端认为链接创建成功而服务器认为链接创建没成功，对服务器没有太大的消耗。客户端给服务器端发送数据，服务器端不进行接收。
三次握手已经知足需求就不须要更屡次的握手。
(3)创建链接是双方的事情，双方都须要创建链接再互相确认，有点像四次握手。可是由于由于TCP能捎带应答，因此服务器向客户端的请求创建链接的SYN以及对客户端的ACK能够一块儿发送，从而致使了三次握手。
2为何是四次挥手？
释放链接是两方的事情，双方发送断开链接请求后还须要确认，并且服务器对客户端的ACK以及FIN不能合并，因此是四次挥手
服务器端对客户端的FIN及ACK不能合并是由于客户端断开链接代表客户端没有数据发送给服务器了，不带表服务器没有数据发给客户端，则服务器向客户端发送ACK以后到服务器发送FIN之间有时间间隔，因此两步骤不能合并
3为何有TIME_WAIT状态？
如服务器端将最后一个断开链接请求发送以后，客户端收到FIN后给服务器端发送一个确认应答ACK，但在传输过程当中可能会丢包，这个ACK没有被服务器收到。当服务器在必定时间内没有收到ACK时会从新发送请求，因此客户端须要一个TIME_WAIT时间等待，解决丢包重传问题。一个TIME_WAIT的时间是2MSL。
哪一方先断开链接就先进入TIME_WAIT等待时间。socket
相关资源：基于Tcp协议的服务器与客户端通信之客户端_tcp客户端与服务器通信

---