- 3、TCP 和 UDP 的区别?
- 4、详细说下 TCP 三次握手的过程?
- 5、为什么两次握手不可以呢,或者四次?
- 6、Server 端收到 Client 端的 SYN 后,为什么还要传回 SYN?为什么要回传ACK?
- 7、详细说下 TCP 四次挥手的过程?
- 8、为什么 TIME-WAIT 状态必须等待 2MSL 的时间呢?
- 9、TCP 协议是如何保证可靠传输的?
- 10、谈谈你对 ARQ 协议的理解?
- 11、谈谈你对滑动窗口的了解?
- 12、谈下你对流量控制的理解?
- 13、TCP 拥塞控制的理解
- 14、什么是粘包?
- 15、TCP 黏包是怎么产生的?
- 16、怎么解决拆包和粘包?
- 17、你对 HTTP 状态码有了解吗?
- 18、HTTP 方法有哪些?
- 19、说下 GET 和 POST 的区别?
- 20、在浏览器中输入 URL 地址到显示主页的过程?
- 21、HTTP报文格式 长连接和短连接的理解
- 22、谈下 HTTP 1.0 和 1.1、2 的主要变化?
- 23、HTTPS 的工作过程?
- 24、HTTP 和 HTTPS 的区别?
- 25、数字签名和数字证书
- 26、Cookie 和Session
- 27、 TCP 半连接队列和全连接队列
1、谈下你对五层网络协议体系结构的理解?
- 1. 应用层
应用层(application-layer)的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多,如域名系统 DNS,支持万维网应用的 HTTP 协议。我们把应用层交互的数据单元称为报文。
- 2. 运输层(TCP/IP协议)
运输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。tcp产生的是报文段,udp是用户数据报。
- 3. 网络层
网络层的任务就是选择合适的网间路由和交换结点, 确保数据及时传送。在发送数据时,网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中,由于网络层使用 IP 协议,因此分组也叫 IP 数据报。
IP 地址分成两种意义:
⼀个是网络号,负责标识该 IP 地址是属于哪个子网的;
⼀个是主机号,负责标识同一子网下的不同主机
这需要配合子网掩码才能算出 IP 地址 的网络号和主机号。那么在寻址的过程中,先匹配到相同的网络号,才会去找对应的主机 。
将子网掩码与IP地址进行二进制形式的按位与运算得到的便是网络地址,将子网掩码二进制按位取反,然后IP地址进行二进制的逻辑与(AND)运算,得到的就是主机地址。
- 4. 数据链路层
数据链路层(data link layer)通常简称为链路层。在两个相邻节点之间传送数据时,数据链路层将网络层交下来的 IP 数据报封装成帧,在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息(如:同步信息,地址信息,差错控制等)。
- 5. 物理层
在物理层上所传送的数据单位是比特。物理层(physical layer)的作用是实现相邻计算机节点之间比特流的透明传送,尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。
2、Linux发送接收网络包
2、简单说下每一层对应的网络协议有哪些?
1.ARP
2.RARP
3.ICMP
3、TCP 和 UDP 的区别?
1.连接
- TCP是面向连接的协议,传输数据前要先建立连接
- UDP不需要建立连接
2.服务对象
- TCP是一对一的两点服务
- UDP支持一对一、一对多、多对多
3.可靠性
- TCP 是可靠交付数据的,数据可以⽆差错、不丢失、不重复、按需到达
- UDP尽最大努力交付,不保证可靠性
4.拥塞控制、流量控制
- TCP 有拥塞控制和流量控制机制,保证数据传输的安全性。
- UDP 则没有,即使网络非常拥堵了,也不会影响 UDP 的发送速率。
5.传输方式
- TCP 是流式传输,没有边界,但保证顺序和可靠。
- UDP 是⼀个包⼀个包的发送,是有边界的,但可能会丢包和乱序
4、详细说下 TCP 三次握手的过程?
第一次握手:发送方向接收方发出连接请求报文段,这时首部中的同步位 SYN=1,选择初始序号 seq=x。这时,发送方进入 SYN-SENT(同步已发送)状态
第二次握手:B接收方收到连接请求报文后,如果同意建立连接,则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1,选择一个初始序号 seq = y和确认号 ack = x + 1
第三次握手:发送方收到接收方的确认后,还要向 B 给出确认。确认报文段的 ACK 置 1,确认号 ack = y + 1,而自己的序号 seq = x + 1。TCP 连接已经建立,发送方进入 ESTABLISHED(已建立连接)状态。
5、为什么两次握手不可以呢,或者四次?
1.为了防止已经失效的连接请求报文段突然又传送到了 B,因而产生错误。比如下面这种情况:A 发出的第一个连接请求报文段并没有丢失,而是在网路结点长时间滞留了,以致于延误到连接释放以后的某个时间段才到达 B。本来这是一个早已失效的报文段。但是 B 收到此失效的链接请求报文段后,就误认为 A 又发出一次新的连接请求。于是就向 A 发出确认报文段,同意建立连接。
对于上面这种情况,如果不进行第三次握手,B 发出确认后就认为新的运输连接已经建立了,并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。
如果采用了三次握手,由于 A 实际上并没有发出建立连接请求,所以不会理睬 B 的确认,也不会向 B 发送数据。B 由于收不到确认,就知道 A 并没有要求建立连接。
2.在经过三次握手之后,客户端和服务端已经可以确认之前的通信状况,都收到了确认信息。所以即便再增加握手次数也不能保证后面的通信完全可靠,所以是没有必要的。
6、Server 端收到 Client 端的 SYN 后,为什么还要传回 SYN?为什么要回传ACK?
1.接收端传回发送端所发送的 SYN 是为了告诉发送端,我接收到的信息确实就是你所发送的信号了(同步)。
2.双方通信无误必须是两者互相发送信息都无误。传了 SYN,证明发送方到接收方的通道没有问题,但是接收方到发送方的通道还需要 ACK 信号来进行验证。
7、详细说下 TCP 四次挥手的过程?
第一次挥手:A 的应用进程先向其 TCP 发出连接释放报文段,并停止再发送数据,A 把连接释放报文段首部的终止控制位 FIN置 1,其序号seq = u,这时 A 进入 FIN-WAIT-1(终止等待1)状态,等待 B 的确认。请注意:TCP 规定,FIN 报文段即使不携带数据,也将消耗掉一个序号。
第二次挥手:B 收到连接释放报文段后立即发出确认,确认号是 ack = u + 1,seq = v,然后 B 就进入 CLOSE-WAIT(关闭等待)状态,这时的 TCP 连接处于半关闭(half-close)状态,即 A 已经没有数据要发送了,但 B 若发送数据,A 仍要接收。
第三次挥手:若 B 已经没有要向 A 发送的数据, B 发出的连接释放报文段使 FIN = 1。假定 B 的序号为 w(在半关闭状态,B 可能又发送了一些数据)。B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入 LAST-ACK(最后确认)状态,等待 A 的确认。
第四次挥手:A 在收到 B 的连接释放报文后,在确认报文段中把 ACK置 1,确认号ack = w + 1,而自己的序号 seq = u + 1。然后进入 TIME-WAIT(时间等待) 状态。
现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL(MSL:最长报文段寿命)后,A 才能进入到 CLOSED 状态,然后结束这次 TCP 连接。
8、为什么 TIME-WAIT 状态必须等待 2MSL 的时间呢?
- 为了保证 A 发送的最后一个 ACK 报文段能够到达 B。这个 ACK 报文段有可能丢失,因而使处在 LAST-ACK 状态的 B 收不到对已发送的 FIN + ACK 报文段的确认。B 会超时重传这个 FIN+ACK 报文段,而 A 就能在 2MSL 时间内(超时 + 1MSL 传输)收到这个重传的 FIN+ACK 报文段。接着 A 重传一次确认,重新启动 2MSL 计时器。最后,A 和 B 都正常进入到 CLOSED 状态。如果 A 在 TIME-WAIT 状态不等待一段时间,而是在发送完 ACK 报文段后立即释放连接,那么就无法收到 B 重传的 FIN + ACK 报文段,因而也不会再发送一次确认报文段,这样,B 就无法按照正常步骤进入 CLOSED 状态。
9、TCP 协议是如何保证可靠传输的?
数据包校验:目的是检测数据在传输过程中的任何变化,若校验出包有错,则丢弃报文段并且不给出响应,这时 TCP 发送数据端超时后会重发数据;
2. 对失序数据包重排序:既然 TCP 报文段作为 IP 数据报来传输,而 IP 数据报的到达可能会失序,因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序,然后才交给应用层;
3. 丢弃重复数据:对于重复数据,能够丢弃重复数据;超时重发:当 TCP 发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段;
6. 流量控制:TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据,这可以防止较快主机致使较慢主机的缓冲区溢出,这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。
10、谈谈你对 ARQ 协议的理解?
- 自动重传请求 ARQ 协议(Automatic Repeat-reQuest,ARQ)
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认,就重传前面发送过的分组(认为刚才发送过的分组丢失了)。因此每发送完一个分组需要设置一个超时计时器,其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求 ARQ。
- 连续 ARQ 协议
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口,凡位于发送窗口内的分组可以连续发送出去,而不需要等待对方确认。接收方一般采用累计确认,对按序到达的最后一个分组发送确认,表明到这个分组为止的所有分组都已经正确收到了。
11、谈谈你对滑动窗口的了解?
TCP 利用滑动窗口实现流量控制的机制。滑动窗口(Sliding window)是一种流量控制技术。早期的网络通信中,通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况,同时发送数据,导致中间节点阻塞掉包,谁也发不了数据,所以就有了滑动窗口机制来解决此问题。
TCP 中采用滑动窗口来进行传输控制,滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。
12、谈下你对流量控制的理解?
TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率,保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。
13、TCP 拥塞控制的理解
拥塞控制和流量控制不同,前者是一个全局性的过程,而后者指点对点通信量的控制。在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。这种情况就叫拥塞。
拥塞控制就是为了防止过多的数据注入到网络中,这样就可以使网络中的路由器或链路不致于过载。拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低网络传输性能有关的所有因素。相反,流量控制往往是点对点通信量的控制,是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率,以便使接收端来得及接收。
为了进行拥塞控制,TCP 发送方要维持一个拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度,并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
TCP 的拥塞控制采用了四种算法,即:慢开始、拥塞避免、快重传和快恢复。
- 慢开始:
慢开始算法的思路是由小到大逐渐增大发送窗口,也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1,每经过一个传播轮次,cwnd 加倍,不能超过门限。
- 拥塞避免:
拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大,即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1。
- 快重传与快恢复:
在 TCP/IP 中,快速重传和快恢复(fast retransmit and recovery,FRR)是一种拥塞控制算法,它能快速恢复丢失的数据包。
有了 FRR,如果接收机接收到一个不按顺序的数据段,它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认,它会假定确认件指出的数据段丢失了,并立即重传这些丢失的数据段。
有了 FRR,就不会因为重传时要求的暂停被耽误。当有单独的数据包丢失时,快速重传和快恢复(FRR)能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时,它则不能很有效地工作。
14、什么是粘包?
- TCP 是基于字节流的,虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块,但是 TCP 把这些数据块仅仅看成一连串无结构的字节流,没有边界;
2. 从 TCP 的帧结构也可以看出,在 TCP 的首部没有表示数据长度的字段。
基于上面两点,在使用 TCP 传输数据时,才有粘包或者拆包现象发生的可能。一个数据包中包含了发送端发送的两个数据包的信息,这种现象即为粘包。
接收端收到了两个数据包,但是这两个数据包要么是不完整的,要么就是多出来一块,这种情况即发生了拆包和粘包。拆包和粘包的问题导致接收端在处理的时候会非常困难,因为无法区分一个完整的数据包。
15、TCP 黏包是怎么产生的?
- 发送方产生粘包
采用 TCP 协议传输数据的客户端与服务器经常是保持一个长连接的状态(一次连接发一次数据不存在粘包),双方在连接不断开的情况下,可以一直传输数据。但当发送的数据包过于的小时,那么 TCP 协议默认的会启用 Nagle 算法,将这些较小的数据包进行合并发送(缓冲区数据发送是一个堆压的过程);这个合并过程就是在发送缓冲区中进行的,也就是说数据发送出来它已经是粘包的状态了。
- 接收方产生粘包
接收方采用 TCP 协议接收数据时的过程是这样的:数据到接收方,从网络模型的下方传递至传输层,传输层的 TCP 协议处理是将其放置接收缓冲区,然后由应用层来主动获取(C 语言用 recv、read 等函数);这时会出现一个问题,就是我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来,而下一个数据又到来并有一部分放入的缓冲区末尾,等我们读取数据时就是一个粘包。(放数据的速度 > 应用层拿数据速度)
16、怎么解决拆包和粘包?
分包机制一般有两个通用的解决方法:
1. 特殊字符控制;
2. 在包头首都添加数据包的长度。
如果使用 netty 的话,就有专门的编码器和解码器解决拆包和粘包问题了。
tips:UDP 没有粘包问题,但是有丢包和乱序。不完整的包是不会有的,收到的都是完全正确的包。传送的数据单位协议是 UDP 报文或用户数据报,发送的时候既不合并,也不拆分。
17、你对 HTTP 状态码有了解吗?
- 1XX 信息
- 100 Continue :表明到目前为止都很正常,客户端可以继续发送请求或者忽略这个响应。
- 2XX 成功
- 200 OK
2. 204 No Content :请求已经成功处理,但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息,而不需要返回数据时使用。
3. 206 Partial Content :表示客户端进行了范围请求,响应报文包含由 Content-Range 指定范围的实体内容。
- 3XX 重定向
- 301 Moved Permanently :永久性重定向;
2. 302 Found :临时性重定向;
3. 303 See Other :和 302 有着相同的功能,但是 303 明确要求客户端应该采用 GET 方法获取资源。
4. 304 Not Modified :如果请求报文首部包含一些条件,例如:If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,如果不满足条件,则服务器会返回 304 状态码。
5. 307 Temporary Redirect :临时重定向,与 302 的含义类似,但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。
- 4XX 客户端错误
- 400 Bad Request :请求报文中存在语法错误。
2. 401 Unauthorized :该状态码表示发送的请求需要有认证信息(BASIC 认证、DIGEST 认证)。如果之前已进行过一次请求,则表示用户认证失败。
3. 403 Forbidden :请求被拒绝。
4. 404 Not Found
- 5XX 服务器错误
- 500 Internal Server Error :服务器正在执行请求时发生错误;
2. 503 Service Unavailable :服务器暂时处于超负载或正在进行停机维护,现在无法处理请求。
18、HTTP 方法有哪些?
- GET:获取资源,当前网络中绝大部分使用的都是 GET;
2. HEAD:获取报文首部,和 GET 方法类似,但是不返回报文实体主体部分;
3. POST:传输实体主体
4. PUT:上传文件,由于自身不带验证机制,任何人都可以上传文件,因此存在安全性问题,一般不使用该方法。
5. PATCH:对资源进行部分修改。PUT 也可以用于修改资源,但是只能完全替代原始资源,PATCH 允许部分修改。
6. OPTIONS:查询指定的 URL 支持的方法;
19、说下 GET 和 POST 的区别?
- 从功能上讲,GET 一般用来从服务器上获取资源,POST 一般用来更新服务器上的资源;
2. 从 REST 服务角度上说,GET 是幂等的,即读取同一个资源,总是得到相同的数据,而 POST 不是幂等的,因为每次请求对资源的改变并不是相同的;进一步地,GET 不会改变服务器上的资源,而 POST 会对服务器资源进行改变;
3. 从请求参数形式上看,GET 请求的数据会附在 URL 之后,即将请求数据放置在 HTTP 报文的 请求头中,以 ? 分割 URL 和传输数据,参数之间以 & 相连。特别地,如果数据是英文字母/数字,原样发送;否则,会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格,转换为+,如果是中文/其他字符,则直接把字符串用 BASE64 加密,得出如:%E4%BD%A0%E5%A5%BD,其中 %XX 中的 XX 为该符号以 16 进制表示的 ASCII);而 POST 请求会把提交的数据则放置在是 HTTP 请求报文的 请求体 中;
4. 就安全性而言,POST 的安全性要比 GET 的安全性高,因为 GET 请求提交的数据将明文出现在 URL 上,而且 POST 请求参数则被包装到请求体中,相对更安全;
5. 从请求的大小看,GET 请求的长度受限于浏览器或服务器对 URL 长度的限制,允许发送的数据量比较小,而 POST 请求则是没有大小限制的。
20、在浏览器中输入 URL 地址到显示主页的过程?
1、查询缓存
我们的浏览器、操作系统、路由器都会缓存一些URL对应的IP地址,统称为DNS高速缓存。这是为了加快DNS解析速度,使得不必每次都到根域名服务器中去查询。
2、递归解析
输入www.baidu.com网址后,首先在高速缓存中查找,没找到去根域名服务器查找,没有再去com顶级域名服务器查找,依次类推,直到找到IP地址,然后把它记录在本地告诉缓存中,供下次使用。
大致过程就是.-> .com ->baidu.com. -> www.baidu.com.
其中.代表根域名服务器。
3、DNS负载均衡
访问baidu.com的时候,每次响应的可能并非是同一个服务器(IP地址不同),一般大公司都有成百上千台服务器来支撑访问,DNS可以返回一个合适的机器的IP给用户,例如可以根据每台机器的负载量,该机器离用户地理位置的距离等等,这种过程就是DNS负载均衡。
- TCP 连接:浏览器获得域名对应的 IP 地址以后,浏览器向服务器请求建立链接,发起三次握手;
3. 发送 HTTP 请求:TCP 连接建立起来后,浏览器向服务器发送 HTTP 请求;
4. 服务器处理请求并返回 HTTP 报文:服务器接收到这个请求,并根据路径参数映射到特定的请求处理器进行处理,并将处理结果及相应的视图返回给浏览器;
5. 浏览器解析渲染页面:浏览器解析并渲染视图,若遇到对 js 文件、css 文件及图片等静态资源的引用,则重复上述步骤并向服务器请求这些资源;浏览器根据其请求到的资源、数据渲染页面,最终向用户呈现一个完整的页面。
6. 连接结束。
21、HTTP报文格式 长连接和短连接的理解
在 HTTP/1.0 中默认使用短连接。也就是说,客户端和服务器每进行一次 HTTP 操作,就建立一次连接,任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源(如:JavaScript 文件、图像文件、CSS 文件等),每遇到这样一个 Web 资源,浏览器就会重新建立一个 HTTP 会话。
而从 HTTP/1.1 起,默认使用长连接,用以保持连接特性。
在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭,客户端再次访问这个服务器时,会继续使用这一条已经建立的连接。
Keep-Alive 不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如:Apache)中设定这个时间。实现长连接需要客户端和服务端都支持长连接。
22、谈下 HTTP 1.0 和 1.1、2 的主要变化?
HTTP/2
HTTP/3
QUIC还面临以下挑战:
1)小地方,路由封杀UDP 443端口( 这正是QUIC 部署的端口);
2)UDP包过多,由于QS限定,会被服务商误认为是攻击,UDP包被丢弃;
3)无论是路由器还是防火墙目前对QUIC都还没有做好准备。
23、HTTPS 的工作过程?
- Client发起一个HTTPS(https:/demo.linianhui.dev)的请求,根据RFC2818的规定,Client知道需要连接Server的443(默认)端口。
- Server把事先配置好的公钥证书(public key certificate)返回给客户端。
- Client验证公钥证书:如果验证通过则继续,不通过则显示警告信息。
- Client使用伪随机数生成器生成加密所使用的会话密钥,然后用证书的公钥加密这个会话密钥,发给Server。
- Server使用自己的私钥(privatekey)解密这个消息,得到会话密钥。至此,Client和Server双方都持有了相同的会话密钥。
- Server使用会话密钥加密“明文内容A”,发送给Client。
- Client使用会话密钥解密响应的密文,得到“明文内容A”。
- Client再次发起HTTPS的请求,使用会话密钥加密请求的“明文内容B”,然后Server使用会话密钥解密密文,得到“明文内容B”。
24、HTTP 和 HTTPS 的区别?
- 开销:HTTPS 协议需要到 CA 申请证书,一般免费证书很少,需要交费;
2. 资源消耗:HTTP 是超文本传输协议,信息是明文传输,HTTPS 则是具有安全性的 ssl 加密传输协议,需要消耗更多的 CPU 和内存资源;
3. 端口不同:HTTP 和 HTTPS 使用的是完全不同的连接方式,用的端口也不一样,前者是 80,后者是 443;
4. 安全性:HTTP 的连接很简单,是无状态的;HTTPS 协议是由 TSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议,比 HTTP 协议安全。
25、数字签名和数字证书
为了避免数据在传输过程中被替换,比如黑客修改了你的报文内容,但是你并不知道,所以我们让发送端做一个数字签名,把数据的摘要消息进行一个加密,比如 MD5,得到一个签名,和数据一起发送。然后接收端把数据摘要进行 MD5 解密,如果和签名一样,则说明数据确实是真的。
对称加密中,双方使用公钥进行解密。虽然数字签名可以保证数据不被替换,但是数据是由公钥加密的,如果公钥也被替换,则仍然可以伪造数据,因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的,CA 证书机构会负责颁发一个证书,里面的公钥保证是真的,用户请求服务器时,服务器将证书发给用户,这个证书是经由系统内置证书的备案的。
26、Cookie 和Session
1,session 在服务器端,cookie 在客户端(浏览器)
2,session 默认被存在在服务器的一个文件里
3,session 的运行依赖 session id,而 session id 是存在 cookie 中的,也就是说,如果浏览器禁用了 cookie ,同时 session 也会失效(但是可以通过其它方式实现,比如在 url 中传递 session_id)
4,session 可以放在 文件、数据库、或内存中都可以。
5,用户验证这种场合一般会用 session
27、 TCP 半连接队列和全连接队列
SYN洪泛攻击——攻击者发送大量TCP报文段,而不完成第三次握手步骤,半连接耗费资源