传输层:TCP和UDP
应用层:HTTP和HTTPS
网络层协议
计算机网络体系结构
- Physical,Data Link,Network,Transport,Application
- 应用层:常见协议:
- FTP(21端口):文件传输协议
- SSH(22端口):远程登陆
- TELNET(23端口):远程登录
- SMTP(25端口):发送邮件
- POP3(110端口):接收邮件
- HTTP(80端口):超文本传输协议
- DNS(53端口):运行在 UDP 上,域名解析服务
- 传输层:TCP/UDP
- 网络层:IP、ARP、NAT、RIP…
路由器、交换机位于哪一层?
展开
- 路由器网络层,根据 IP 地址进行寻址;
- 交换机数据链路层,根据 MAC 地址进行寻址
什么是三次握手?
- 第一次握手:客户端行为 :客户端将 SYN 置 1,随机产生一个初始序列号 seq 发送给服务器,进入 SYN_SENT 状态;
- 第二次握手:服务器行为 :服务器收到客户端的 SYN = 1 后,知道客户端请求建立连接,将自己的 SYN 置 1,ACK 置 1,产生一个acknowledge number = sequence number + 1,并随机产生一个自己的初始序列号,发送给客户端,进入 SYN_RCVD 状态;
- 第三次握手:客户端的确认 :客户端检查 acknowledge number 是否为序列号 + 1,ACK 是否为 1,检查正确后将自己的 ACK 置 1,产生一个acknowledge number = 服务器发送的序列号 + 1,发送给服务器,进 ESTABLISHED 状态;服务器的确认 :服务器检查 acknowledge number 是否为序列号 + 1 和 ACK 是否为1后进入 ESTABLISHED 状态,完成三次握手,连接建立。
TCP建立连接可以两次握手吗?为什么?
展开
不可以
可能会出现已失效的请求报文又传送到服务器端。
客户端发出的第一个请求报文并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达服务器端。本来这是一个早已失效的报文段,但服务器端收到此失效的连接请求报文段后,误以为是客户端再次发送的一个新的连接请求,于是就向客户端发出确认报文段,同意建立连接。假设不采用”三次握手“,那么只要服务器端发出确认,新的连接就建立了。 由于客户端没有发出建立连接的请求,因此不会理睬服务器端的确认,也不会向服务器发送数据,但服务器端却以为新的连接已建立,并一直等待客户端发来数据,导致浪费很多服务器资源。
只进行两次握手,服务器无法确认客户端是否接收到第二次握手的报文。如果 SYN-ACK 报文在传输过程中丢失,而客户端又不会发送数据,服务器认为连接已建立并开始发送数据,从而导致数据丢失于服务器资源浪费。
还有就是两次握手会给 SYN flood 攻击提供机会。
可以采用四次握手吗?为什么?
展开
可以。但是会降低传输的效率。
四次握手是指:第二次握手:Server只发送ACK和acknowledge number;而Server的SYN和初始序列号在第三次握手时发送;原来协议中的第三次握手变为第四次握手。出于优化目的,四次握手中的二、三可以合并。
第三次握手中,如果客户端的 ACK 未送达服务器,会怎样?
展开
服务器端:
由于服务器端没有收到 ACK 确认,因此会重发之前的 SYN + ACK (默认重发五次,之后自动关闭连接进入 CLOSED 状态),客户端收到后会重新传 ACK 给服务器。
客户端,两种情况:
- 在服务器进行超时重发的过程中,如果客户端向服务器发送数据,数据头部的 ACK 为 1,服务器接收到数据后会读取 ACK,进入ESTABLISHED 状态。
- 在服务器进入 CLOSED 状态之后,如果客户端向服务器发送数据,服务器会以 RST 包应答。
如果已经建立了连接,但客户端出现了故障怎么办?
展开
服务器每收到一次客户端的请求后都会重新复位一个计时器,时间通常设置为2小时,若2小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒发送一次。若一连发送10个探测报文段仍然没反应,服务器就认为客户端出现故障,接着关闭连接。
初始序列号是什么?
展开
TCP 连接的一方 A,随机选择一个 32 位的序列号(Sequence Number)作为发送数据的初始序列号(Initial Sequence Number,ISN),比如为1000,以该序列号为原点,对要传送的数据进行编号:1001、1002…三次握手时,把这个序列号传送给另一方 B,以便在传输数据时,B 可以确认什么样的数据编号是合法的;同时在进行数据传输时,A 还可以确认 B 收到的每一个字节,如果 A 收到了 B 的确认编号(acknowledge number)是 2001,就说明编号 1001 - 2000 的数据已经被 B 成功接受。
什么是四次挥手?
- 第一次挥手:Client 将 FIN 置 1,发送一个序列号 seq 给 Server,进入FIN_WAIT_1 状态;
- 第二次挥手:Server 收到 FIN 后,将 ACK 置 1,发送 acknowledge = 收到的序列号 + 1 给 Client,进入 CLOSED_WAIT 状态。此时客户端已经没有要发送的数据了,但仍可以接受服务器发来的数据。
- 第三次挥手:Server 将 FIN 置 1,发送一个序列号给 Client,进入LAST_ACK 状态。
- 第四次挥手:Client 收到服务器的 FIN 后,将 ACK 置 1 ,发送 acknowledge number = 收到的序列号 + 1 给 Server,进入 TIME_WAIT 状态;服务器收到后,确认 acknowledge number 后,进入 CLOSED 状态,不再向客户端发送数据。客户端等待2 * MSL(报文段最长寿命)后,也进入 CLOSED 状态。完成四次挥手。
为什么不能把服务器发送的 ACK 和 FIN 合起来,变成三次挥手(CLOSED_WAIT状态意义)?
展开
因为服务器收到客户端断开连接的请求时,可能还有一些数据没有发完,这时先回复 ACK,表示接受到了断开连接的请求。等到数据发送完之后再发 FIN,断开服务器到客户端的数据传送。
如果第二次挥手时服务器的 ACK 没有送达客户端,会怎么样?
展开
客户端没有收到 ACK 确认,会重新发送 FIN 请求。
客户端 TIME_WAIT 状态的意义?
展开
第四次挥手时,客户端发送给服务器的 ACK 有可能丢失,TIME_WAIT 状态就是用来重发可能丢失的 ACK 报文。如果 Server 没有收到 ACK,就会重发 FIN,如果 Client 在 2 * MSL 的时间内收到了 FIN,就会重新发送 ACK 并再次等待 2 * MSL,防止 Server 没有收到 ACK 而不断重发 FIN。
MSL(Maximum Segment Lifetime),指一个片段在网络中最大的存活时间,2 * MSL 就是一个发送和一个回复所需的最大时间。如果直到 2 * MSL,Client 都没有再次收到 FIN,那么 Client 推断 ACK 已经被成功接收,则结束 TCP 连接。
TCP如何实现流量控制?
使用滑动窗口协议实现流量控制。防止发送方发送速率太快,接收方缓存区不够导致溢出。接收方会维护一个接收窗口 receiver window(窗口大小单位是字节),接收窗口的大小是根据自己的资源情况动态调整的,在返回 ACK 时将接收窗口大小放在 TCP 报文中的窗口字段告知发送方。发送窗口大小不能超过接收窗口的大小,只有当发送方发送并收到确认之后,才能将发送窗口右移。
发送窗口的上限为接收窗口和拥塞窗口中的较小值。接收窗口表明了接收方的接收能力,拥塞窗口表明了网络的传送能力。
什么是零窗口(接收窗口为0时会怎样)?
展开
如果接收方没有能力接收数据,就会将接受窗口设置为 0,这时发送方必须暂停发送数据,但是会启动一个持续计时器(persistence timer),到期后发送一个大小为 1 字节的探测数据包,以查看接收窗口状态。如果接收方能够接受数据,就会在返回的报文中更新接收窗口大小,恢复数据传送。
TCP的拥塞控制是怎么实现的?
拥塞控制主要由四个算法组成:慢启动(Slow Start)、拥塞避免(Congestion voidance)、快重传(Fast Retransmit)、快恢复(Fast Recovery) 。
- 慢启动:刚开始发送数据时,先把拥塞窗口(congestion window)设置为一个最大报文段 MSS 的数值,每收到一个新的确认报文之后,就把拥塞窗口加 1 个 MSS。这样每经过一个传输轮次(或者说是没经过一个往返时间 RTT),拥塞窗口的大小就会加倍。
- 拥塞避免:当拥塞窗口的大小达到慢开始门限(slow start threshold)时,开始执行拥塞避免算法,拥塞窗口大小不再指数增加,而是线性增加,即每经过一个传输轮次只增加 1 MMS。
无论在慢开始阶段还是在拥塞避免阶段,只要发送方判断出现拥塞(其根据就是没有收到确认),就要吧慢开始门限 ssthresh 设置为出现拥塞时的发送方窗口值的一般(但不能小于 2)。然后把拥塞窗口 cwnd 重新设置为 1,执行慢开始算法。(这是不使用快重传的情况)
- 快重传:快重传要求接收方在收到一个失序的报文段后就立即发出重复确认 (为了使发送方及早知道有报文段没有到达对方)而不要等到自己发送数据时捎带确认。快重传算法规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。
- 快恢复:当发送方连续收到三个重复确认时,就把慢开始门限减半,然后执行拥塞避免算法。
不执行慢开始算法的原因:因为如果网络出现拥塞的话就不会收到好几个重复的确认,所以发送方认为现在网络可能没有出现拥塞。也有的快重传是把开始时的拥塞窗口 cwnd 值再增大一点,即等于 ssthresh + 3 * MSS。这样做的理由是:既然发送方收到三个重复的确认,就表明有三个分组已经离开了网络。这三个分组不再消耗网络的资源而是停留在接受方的缓存中。可见现在网络中减少了三个分组。因此可以适当把拥塞窗口扩大些。
TCP如何最大利用带宽?
- 拥塞控制:TCP 使用拥塞控制算法(如 TCP Reno,TCP Cubic 等)来调整数据的发送速度,根据网络状况动态调整拥塞窗口的大小。
- 滑动窗口机制:通过调整发送方和接收方之间的窗口大小,TCP 能够确保数据连续发送而不会超出接收方的处理能力。
- 快重传和快回复:在检测丢包时,TCP 能够快速重传丢失的包,并调整窗口大小以快速恢复正常传输速率。
- 选择性确认:这允许接收方只确认已成功接收的数据块,帮助发送方更有效地处理丢包问题,减少不必要的重传。
TCP与UDP的区别?
- 连接性:TCP 是面向连接的,UDP是无连接的;
什么叫无连接?
UDP 发送数据前不需要建立连接,直接发送。
- 可靠性:TCP 是可靠的,UDP不可靠;
什么叫不可靠?
UDP 接收方收到报文后,不需要给出任何确认。(可能丢包,不保证数据完整性)
- 通信方式:TCP 只支持点对点通信,UDP 支持一对一、一对多、多对一、多对多;
- 数据处理方式:TCP 是面向字节流的,UDP 是面向报文的,发送完整数据包;
什么是面向字节流?
面向字节流是指发送数据时以字节为单位,一个数据包可以拆分成若干组进行发送,而 UDP 一个报文只能一次发完。
- 拥塞控制:TCP 有拥塞控制机制,UDP 没有。网络出现的拥塞不会使源主机的发送速率降低,适用于实时性要求高的应用,比如媒体通信,游戏;
- 开销:TCP 首部开销(20 字节)比UDP首部开销(8 字节)要大
- 连接状态:UDP 的主机不需要维持复杂的连接状态表
什么时候选 TCP,什么时候选 UDP?
展开
UDP:对实时性要求比较高的情况,如游戏、媒体通信、实时视频流(直播),即使出现传输错误也可以容忍;
TCP:其他大部分情况下,HTTP 都是用 TCP,因为要求传输的内容可靠,不出现丢失。
HTTP 可以使用 UDP 吗?
展开
HTTP 不可以使用 UDP,HTTP 需要基于可靠的传输协议,而 UDP 不可靠。
注:HTTP 3.0 使用 基于UDP 的 QUIC 协议
面向连接和无连接的区别
展开
无连接的网络服务(数据包服务) – 面向连接的网络服务(虚电路服务)
- 虚电路服务:首先建立连接,所有的数据包经过相同的路径,服务质量有较好的保证;
- 数据包服务:每个数据包含目的地址,数据路由相互独立(路径可能变化);网络尽最大努力交付数据,但不保证不丢失、不保证先后顺序、不保证在时限内交付;网络发生拥塞时,可能会将一些分组丢弃。
TCP如何保证传输的可靠性
- 数据包校验
- 对失序数据包重新排序(TCP 报文具有序列号)
- 丢失重复数据
- 应答机制:接收方收到数据之后,会发送一个确认(通常延迟几分之一秒)
- 超时重发:发送方发出数据之后,启动一个定时器,超时未收到接收方的确认,则重新发送这个数据
- 流量控制:确保接收端能够接收发送方的数据而不会缓冲区溢出
HTTP和HTTPS有什么区别?
- 端口不同:HTTP 使用的是 80 端口,HTTPS 使用 443 端口;
- HTTP(超文本传输协议)信息是明文传输,HTTPS 运行在 SSL(Secure Socket Layer)之上,添加了加密和认证机制,更加安全;
- HTTPS 由于加密解密会带来更大的 CPU 和内存开销;
- HTTPS 通信需要证书,一般需要向证书办法机构(CA)购买
HTTPS的连接过程?
展开
- 加密规则交换:客户端向服务器发送支持的加密规则,包括对称加密、非对称加密和摘要算法。
- 服务器响应:服务器从客户端提供的加密规则中选择一组合适的加密和HASH算法,并将自己的数字证书发送给客户端。证书包含网站地址、公钥以及证书颁发机构等信息。
- 客户端验证:客户端检查服务器证书的有效性,包括证书是否过期,证书颁发机构(CA)是否可靠,以及证书上的域名是否与服务器实际域名匹配。
- 密钥加密传输:验证通过后,客户端生成一个随机密钥,用服务器的公钥加密,然后将加密后的密钥发送给服务器。
- 握手信息加密:客户端使用HASH算法对握手信息进行摘要计算,并使用生成的随机密钥对摘要进行加密,然后将加密后的摘要一起发送给服务器。
- 服务器解密验证:服务器使用私钥解密接收到的随机密钥,再用该密钥解密摘要,并验证握手信息的一致性。
- 握手结束:验证无误后,服务器使用对称密钥加密握手消息回发给浏览器。浏览器解密验证摘要后,握手过程结束。
总结:在HTTPS握手过程中,非对称加密用于密钥交换,对称加密用于后续数据传输,HASH算法用于确保数据完整性。
输入 www.baidu.com,怎么变成 https://www.baidu.comd 的,怎么确定用HTTP还是HTTPS?
展开
一种是原始的 302 跳转,服务器把所有的 HTTP 流量跳转到 HTTPS。但这样有一个漏洞,就是中间人可能在第一次访问站点的时候就劫持。解决方法是引入 HSTS 机制,用户浏览器在访问站点的时候强制使用 HTTPS。
HTTPS 连接的时候,怎么确定收到的包是服务器发来的(中间人攻击)?
展开
- 验证域名、有效期等信息是否正确。证书上都有包含这些信息,比较容易完成验证;
- 判断证书来源是否合法。每份签发证书都可以根据验证链查找到对应的根证书,操作系统、浏览器会在本地存储权威机构的根证书,利用本地根证书可以对对应机构签发证书完成来源验证;
- 判断证书是否被篡改。需要与 CA 服务器进行校验;
- 判断证书是否已吊销。通过 CRL(Certificate Revocation List 证书注销列表)和 OCSP(Online Certificate Status Protocol 在线证书状态协议)实现,其中 OCSP 可用于第 3 步中以减少与 cA 服务器的交互,提高验证效率。
什么是对称加密、非对称加密?区别是什么?
展开
- 对称加密:加密和解密采用相同的密钥。如:DES、RC2、RC4
- 非对称加密:需要两个密钥——公钥和私钥。如果用公钥加密,需要用私钥才能解密。如:RSA
- 区别:对称加密速度更快,通常用于大量数据的加密;非对称加密安全性更高(不需要传送密钥)
数字签字、报文摘要的原理
展开
- 发送者 A 用私钥进行签名,接收者 B 用公钥验证签名。因为除 A 外没有人有私钥,所以 B 相信签名是来自 A。A 不可抵赖,B 也不能伪造报文。
- 摘要算法:MD5、SHA
GET与POST的区别?
- GET 是幂等的,即读取同一个资源,总是得到相同的数据,POST 不是幂等的;
- GET 一般用于从服务器获取资源,而 POST 有可能改变服务器上的资源;
- 请求形式上:GET 请求的数据附在 URL 之后,在 HTTP 请求头中;POST 请求的数据在请求体中;
- 安全性:GET 请求可被缓存、收藏、保留到历史记录,且其请求数据明文出现在 URL 中。POST 的参数不会被保存,安全性相对较高;
- GET 只允许 ASCII 字符,POST 对数据类型没有要求,也允许二进制数据;
- GET 的长度有限制(操作系统或浏览器),而 POST 数据大小无限制。
Session与Cookie的区别?
Session 是服务器端保持状态的方案,Cookie 是客户端保持状态的方案。
Cookie 保存在客户端本地,客户端请求服务器时会将 Cookie 一起提交;Session 保存在服务端,通过检索 Sessionid 查看状态。保存 Sessionid 的方式可以采用 Cookie,如果禁用了 Cookie,可以使用 URL 重写机制(把会话 ID 保存在 URL 中)。
从输入网址到获得页面的过程(越详细越好)?
- 浏览器查询 DNS,获取域名对应的 IP 地址:具体过程包括浏览器搜索自身的 DNS 缓存、搜索操作系统的 DNS 缓存、读取本地的 Host 文件和向本地 DNS 服务器进行查询,如果要查询的域名包含在本地配置区域资源中,则返回解析结果给客户机,完成域名解析(此解析具有权威性);如果要查询的域名不由本地 DNS 服务器区域解析,但该服务器已缓存了此网址映射关系,则调用这个 IP 地址映射,完成域名解析(此解析不具有权威性)。如果本地域名服务器并未缓存该网址映射关系,那么将根据其设置发起递归查询或者迭代查询;
- 浏览器获得域名对应的 IP 地址后,向服务器请求建立链接,发起三次握手;
- TCP/IP 链接建立起来后,浏览器向服务器发送 HTTP 请求;
- 服务器接收到这个请求,并根据路径参数映射到特定的请求处理器进行处理,并将处理结果及相应的视图返回给浏览器;
- 浏览器解析并渲染视图,若遇到对 js 文件、css 文件及图片等静态资源的引用,则重复上述步骤并向服务器请求这些资源;
- 浏览器根据其请求到的资源、数据渲染页面,最终向用户呈现一个完整的页面。
HTTP请求有哪些常见状态码?
- 2xx 状态码:操作成功。200 OK
- 3xx 状态码:重定向。301永久重定向;302 暂时重定向
- 4xx 状态码:客户端错误。400 Bad Request;401 Unauthorized;403 Forbidden;404 Not Found
- 5xx 状态码:服务器错误。500 服务器内部错误;501 服务器不可用
什么是RIP?算法是什么?
RIP(Routing Information Protocol,距离矢量路由协议)。
每个路由器维护一张表,记录该路由器到其它网络的“跳数”,路由器到与其直接连接的网络的跳数是 1,每多进过一个路由器跳数就加 1;更新该表时和相邻路由器交换路由信息;路由器允许一个路径最多包含 15 个路由器,如果跳数为 16,则不可达。交付数据报时优先选取距离最短的路径。
(PS:RIP 是应用层协议)
优缺点
展开
- 实现简单,开销小;
- 随着网络规模扩大,开销也会增大;
- 最大距离为 15,限制了网络的规模;
- 当网络出现故障时,要经过较长时间才能将此信息传递到所有路由器
IP地址的分类?
路由器仅根据网络号 net-id 来转发分组,当分组到达目的网络的路由器之后,再根据主机号 host-id 将分组交付给主机;同一网络上的所有主机的网络号相同。
什么叫划分子网?
当划分子网时,主机号 host-id 的一部分比特被借用来作为子网号 subnet-id。子网掩码是一个位掩码,其中网络号和子网号部分为 1,主机号部分为 0。数据报文传输时,首先根据网络号找到目标网络,数据包被发送到该网络的路由器。路由器再根据网络号和子网号确定具体的子网,然后将数据报发送到相应的子网中的主机。通过将子网掩码与目标地址逐位操作,若结果匹配某个子网的网络地址,数据包就会被发送到该子网。
什么是ARP协议?
ARP 协议(Addres Resolution Protocol)将 IP 地址映射为 MAC 地址。以下是 ARP 的工作流程:
- 检查缓存:当源主机要发送数据包时,首先检查其 ARP 缓存是否已有目标主机的 MAC 地址。
- 发送请求:如果没有找到,则广播 ARP 请求包,询问目标主机的 MAC 地址(同时发送自己的 IP 和 MAC 地址)
- 接收响应:目标主机收到请求后,验证 IP 地址是否匹配。如果匹配,它会将源主机的映射添加到自己的 ARP 缓存,并返回包含其 MAC 地址的 ARP 响应包。
- 更新缓存:源主机收到响应后,更新 ARP 缓存,保存目标主机的 IP 和 MAC地址映射,然后开始数据传输。
- 跨网通信:如果目标主机不在同一局域网,源主机会使用 ARP 找到找到本局域网上的路由器 MAC 地址,将数据包发送给路由器,再由路由器转发到下一个网络。
此过程确保 IP 地址可以正确映射为物理地址,从而在网络中传输数据。
什么是NAT?
NAT(Network Address Translation,网络地址转换)用于让内网中的主机与互联网中的主机通信。NAT 路由器将内网主机的本地 IP 转换为全球 IP 地址。NAT 有两种主要类型:静态转换,即固定不变的全球 IP 地址;动态 NAT 转换,即根据需要分配的全球 IP 地址。
HTTP各版本
- HTTP 0.9 版本
- HTTP 协议的第一个版本,功能简单,已弃用
- 仅支持纯文本数据的传输,虽然支持 HTML,单数不支持图片插入
- 仅支持 GET 请求方式,且不支持请求头
- 无状态,短连接。没有对用户状态的管理;每次请求建立一个 TCP 连接,响应之后关闭 TCP 连接。
- HTTP 1.0 版本
- 支持 POST、GET、HEAD三种方法
- 支持长连接 keep-alive(但默认还是使用短连接:浏览器每一次请求建立一次 TCP 连接,请求处理完毕之后断开)。
- 服务器不跟踪用户的行为也不记录用户过往请求。
- HTTP 1.1 版本
- 新增 PUT、DELETE、CONNECT、TRACE、OPTIONS 方法,是现今使用最多的版本。
- 支持长连接,在一次 TCP 连接中可以发送多个请求或响应,且默认使用长连接。
- 支持宽带优化、断点续传。可以传输对象的部分数据,不必发送整个对象;文件上传下载支持续传。
- 因为长连接产生的问题:队头阻塞。长连接中,发送请求和响应都是串行化的,前面的消息会造成后面的消息也阻塞。解决方法是创建多个 TCP 连接,这样就可以基本保证可用性,浏览器默认的最大 TCP 连接数是 6 个。
- HTTP 2.0 版本
- 二进制分帧,所有帧都是用二进制编码,节省了空间
- 多路复用:HTTP 2.0 中所有的连接都是持久化的。相比 1.1 版本可以不用维护更多的 TCP 连接,在处理并发请求的时候,可以将多个数据流中互不依赖的帧可以乱序发送 ,同时还支持优先级。接收方接收之后可以根据帧头部信息将帧组合起来。(解决了 1.1 版本中的队头阻塞问题)
- 头部压缩:1.1 版本每次传输都需要传输一份首部,2.0 让双方各自缓存一份首部字段表,达到更快传输的目标。
- HTTP 3.0 版本
- 基于 UDP 的 QUIC 多路复用 :在一个 QUIC 中可以并发发送多个 HTTP 请求 Stream,且如果各个 Stream 互不依赖,那么就不会造成 使用 TCP 带来的队头阻塞问题 。这个问题源头上是因为 TCP 连接,TCP 连接的性质决定了重传会影响队后的数据发送,所以干脆选用 UDP 来解决这个方案。
- 0 RRT 建链:RRT 表示 Round-Trip Time,3.0 可以实现 0 RRT 建链。一般来说 HTTPS 协议要建立完整链接包括 TCP 握手和 TLS 握手,总计需要至少 2 - 3 个 RRT,普通的 HTTP 协议也需要至少一个 RRT 才可以完成握手。基于 UDP 的 QUIC 协议可以在第一次发送包的时候直接发送业务数据。但是由于首次连接需要发送公钥数据,所以首次连接并不使用这一方法。
参考
- https://blog.csdn.net/justloveyou_/article/details/78303617
- https://blog.csdn.net/qq_43103529/article/details/120813469
- https://blog.csdn.net/yjxsdzx/article/details/71937886
- https://blog.csdn.net/bad_sheep/article/details/6158676
- https://github.com/wolverinn/Waking-Up/tree/9eae70203055c47cbd067bb88ba6db0bd5f44ad7
- https://www.csview.cn/