Java面试题系列（八）——计算机网络

1. 路由器和交换机的区别

• 工作层次不同：交换机比路由器更简单，路由器比交换机能获取更多信息，交换机工作在数据链路层，而路由器工作在网络层
• 数据转发所依据的对象不同。交换机的数据转发依据是利用物理地址或者说MAC地址来确定转发数据的目的地址而路由器是依据ip地址进行工作的
• 传统的交换机只能分割冲突域，不能分割广播域；而路由器可以分割广播域

2. 域名、IP、MAC

• 域名是我们取代记忆复杂的 IP 的一种解决方案
• IP 地址才是目标在网络中所被分配的节点。
• MAC 地址是对应目标网卡所在的固定地址。

3. URL组成

从上面的URL可以看出，一个完整的URL包括以下几部分：

• 协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符
• 域名部分：该URL的域名部分为“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用
• 端口部分：跟在域名后面的是端口，域名和端口之间使用“：”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口80
• 虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”
• 文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”，则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名
• 锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分
• 参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。

4. 从输入URL到页面展示的详细过程

1)  浏览器解析输入：地址栏会根据用户输入，做出如下判断：输入的是非 URL 结构的字符串，则会用浏览器默认的搜索引擎搜索该字符串；输入的是 URL 结构字符串，则会构建完整的 URL 结构，浏览器进程会将完整的 URL 通过进程间通信，即 IPC，发送给网络进程
2)  DNS域名解析：在网络进程接收到 URL 后，并不是马上对指定 URL 进行请求。首先进行DNS 解析域名得到对应的 IP，然后通过 ARP 解析 IP 得到对应的 MAC地址。
3)  浏览器向服务器发起tcp连接，与浏览器建立tcp三次握手。
4)  浏览器向服务器发送HTTP请求，请求数据包
5)  服务器处理请求
6)  服务器响应请求
7)  读取页面内容，浏览器渲染，解析html源码
8)  生成Dom树、解析css样式、js交互
9)  客户端和服务器交互
10)  Ajax异步查询

5. DNS的寻址过程

DNS 解析域名的过程分为以下几个步骤：

1)  浏览器缓存：询问浏览器 DNS 缓存
2)  本地系统缓存：询问本地操作系统 DNS 缓存（即查找本地 host 文件）
3)  路由器缓存
4)  ISP DNS 缓存：询问 ISP（Internet Service Provider）互联网服务提供商（例如电信、移动）的 DNS 服务器
5)  询问根服务器，这个过程可以进行递归和迭代两种查找的方式，两者都是先询问顶级域名服务器查找

6. 网络模型

image.png

7. ARP

  ARP 英文全名为：Address resolution protocol ，地址解析协议，ARP为IP与MAC提供动态映射，过程自动完成。当PC发出通信请求时，根据协议规定，它的目的地址必然是48bit的MAC地址的。MAC并不能和IP直接去通信。那么就需我们的ARP协议来做相应的转换工作。

8. TCP

• tcp为什么要建立连接？
  保证可靠传输。
• TCP为什么可靠一些?
  三次握手，超时重传，流量控制，拥塞控制。
• 哪种应用场景会使用TCP协议，使用它的意义?
  当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议，建立一个 TCP 连接是需要客户端与服务器端达成三个信息的共识。

  1)  Socket：由 IP 地址和端口号组成
  2)  序列号：用来解决乱序问题等
  3)  窗口大小：用来做流量控制

• TCP的数据被封装在一个IP数据报中：

  
  
  image.png

• TCP首部如下图所示：

  
  
  image.png

9. 超时重传、慢启动和拥塞控制、快速重传及恢复

https：//blog.csdn.net/u010710458/article/details/79968648

10. 四种拥塞控制算法

  TCP 通过维护一个拥塞窗口来进行拥塞控制，拥塞控制的原则是：只要网络中没有出现拥塞，拥塞窗口的值就可以再增大一些，以便把更多的数据包发送出去，但只要网络出现拥塞，拥塞窗口的值就应该减小一些，以减少注入到网络中的数据包数。
TCP 拥塞控制算法发展的过程中出现了如下几种不同的思路：

1)  基于丢包的拥塞控制：将丢包视为出现拥塞，采取缓慢探测的方式，逐渐增大拥塞窗口，当出现丢包时，将拥塞窗口减小，如 Reno、Cubic 等。
2)  基于时延的拥塞控制：将时延增加视为出现拥塞，延时增加时增大拥塞窗口，延时减小时减小拥塞窗口，如 Vegas、FastTCP 等。
3)  基于链路容量的拥塞控制：实时测量网络带宽和时延，认为网络上报文总量大于带宽时延乘积时出现了拥塞，如 BBR。
4)  基于学习的拥塞控制：没有特定的拥塞信号，而是借助评价函数，基于训练数据，使用机器学习的方法形成一个控制策略，如 Remy。

11. 滑动窗口

  滑动窗口（Sliding window）是一种流量控制技术。早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，所以就有了滑动窗口机制来解决此问题。
  滑动窗口协议是用来改善吞吐量的一种技术，即容许发送方在接收任何应答之前传送附加的包。接收方告诉发送方在某一时刻能送多少包（称窗口尺寸）。
  TCP中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为0时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个1字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。

12. TCP和UDP的区别

1） TCP提供面向连接的传输，通信前要先建立连接（三次握手机制）； UDP提供无连接的传输，通信前不需要建立连接。
2） TCP提供可靠的传输（有序，无差错，不丢失，不重复）； UDP提供不可靠的传输。
3） TCP面向字节流的传输，因此它能将信息分割成组，并在接收端将其重组； UDP是面向数据报的传输，没有分组开销。
4） TCP提供拥塞控制和流量控制机制； UDP不提供拥塞控制和流量控制机制。

image.png

13. TCP粘包和拆包

  TCP属于传输层的协议，传输层除了有TCP协议外还有UDP协议。那么UDP是否会发生粘包或拆包的现象呢？答案是不会。UDP是基于报文发送的，从UDP的帧结构可以看出，在UDP首部采用了16bit来指示UDP数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。而TCP是基于字节流的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；另外从TCP的帧结构也可以看出，在TCP的首部没有表示数据长度的字段，基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。

• 解决TCP粘包和拆包的方法：
  • 发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。
  • 发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
  • 可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。

14. tcp连接之半连接攻击和全连接攻击

• 半连接攻击是一种攻击协议栈的攻击方式，坦白说就是攻击主机的一种攻击方式。通过将主机的资源消耗殆尽，从而导致应用层的程序无资源可用，导致无法运行。在正常情况下，客户端连接服务端需要通过三次握手，首先客户端构造一个SYN连接数据包发送至服务端，自身进入SYN_SEND状态，当服务端收到客户端的SYN包之后，为其分配内存核心内存，并将其放置在半连接队列中，服务端接收客户SYN包并会向客户端发送一个SYN包和ACK包，此刻服务端进入SYN_RECV态。客户端收到包之后，再次向服务端发送ACK确认包。至此连接建立完成，双方都进入ESTABLSHED状态。半连接就是通过不断地构造客户端的SYN连接数据包发向服务端，等到服务端的半连接队列满的时候，后续的正常用户的连接请求将会被丢弃，从而无法连接到服务端。此为半连接攻击方式。根据服务端的半连接队列的大小，不同主机的抵抗这种SYN攻击的能力也是不一样。
• 如何来解决半连接攻击？
  • 可以通过拓展半连接队列的大小，来进行补救，但缺点是，不能无限制的增加，这样会耗费过多的服务端资源，导致服务端性能地下。这种方式几乎不可取。
  • 现主要通syncookies或者syn中继机制来防范半连接攻击，不为半连接分配核心内存的方式来防范。syncookies 的原理就是当服务端收到客户端 SYN 包后，不会放到半连接队列里，而是通过 {src_ip， src_port， timestamp} 等计算一个 cookie（也就是一个哈希值），通过 SYN+ACK包返回给客户端，客户端返回一个 ACK 包，携带上这个 cookie，服务端通过校验可以直接把这个连接放入全连接队列。整个过程不需要半连接队列的参与。
• 全连接攻击是通过消耗服务端进程数和连接数，只连接而不进行发送数据的一种攻击方式。当客户端连接到服务端，仅仅只是连接，此时服务端会为每一个连接创建一个进程来处理客户端发送的数据。但是客户端只是连接而不发送数据，此时服务端会一直阻塞在recv或者read的状态，如此一来，多个连接，服务端的每个连接都是出于阻塞状态从而导致服务端的崩溃。
• 如何来解决全连接攻击？
  • 可以通过不为全连接分配进程处理的方式来防范全连接攻击，具体的情况是当收到数据之后，在为其分配一个处理线程。具体的处理方式在accept返回之前是不分配处理线程的。直到接收相关的数据之后才为之提供一个处理过程。例如在apache服务中，是通过预创建一定量的子进程作为处理连接继承。所有的自己进程都继承父进程的sockfd，每当有一个连接过来时，只有当accept返回是，才会为该链接分配一个进程来处理连接请求。负责，子进程一直处于等待状态。如果出现值是连接存在，而始终不放数据，该链接的状态是SYN_RECV，在协议栈中，提供一个保活期给该链接，如果超过保活期还没有数据到来，服务端协议栈将会断开该链接。如果没有该保活期，虽然避免了ESTABLESHED状态的数量，但是SYN_RECV的数据量的增长仍旧是不可估算的，所以需要利用保活期来监控该链接是需要清除断开。

15. 协议、协议簇和协议栈

• 协议，通常指某一个协议，一般由某一个或者一组文件如rfc/draft来指定。
• 协议族，是指彼此相互关联的一组协议。
• 协议栈，是指某一组协议的关系以及该组协议的层次结构，一般有清晰的up/down依赖关系和上下行消息交互。

16. 三次握手与四次挥手

• 序列号seq：占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。

• 确认号ack：占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。

• 确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效

• 同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。

• 终止FIN：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接

• PS：ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号。

  
  
  image.png

• 三次握手过程

  
  
  image.png

1)  第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；
2)  第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
3)  第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入Established（TCP连接成功）状态，完成三次握手。

• 四次挥手

  
  
  image.png

1)  客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2)  服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3)  客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4)  服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5)  客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6)  服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

17. 为什么不能用两次握手进行连接？

  3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
  现在把三次握手改成仅需要两次握手，死锁是可能发生的。举个例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
  防止出现失效的连接请求报文段被服务端接收的情况，从而产生错误。

18. 为什么连接的时候是三次握手，关闭的时候却是四次握手？

  因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

19. 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

  虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

20. 如果已经建立了连接，但是客户端突然出现故障了怎么办？

  TCP还设有一个保活计时器，显然客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

21. HTTP1.0、1.1、2.0、3.0的区别

-   HTTP 1.0
1)  短连接：每次发送请求都要重新建立tcp请求，即三次握手，非常浪费性能
2)  无host头域，也就是http请求头里的host，
3)  不允许断点续传，而且不能只传输对象的一部分，要求传输整个对象
-   HTTP 1.1
1)  长连接，流水线，使用connection：keep-alive使用长连接
2)  host头域
3)  由于长连接会给服务器造成压力
-   HTTP 2.0
1)  头部压缩，双方各自维护一个header的索引表，使得不需要直接发送值，通过发送key缩减头部大小
2)  多路复用，使用多个stream，每个stream又分帧传输，使得一个tcp连接能够处理多个http请求
3)  可以使用服务端推送
-   HTTP 3.0
1)  基于google的QUIC协议，而quic协议是使用udp实现的
2)  减少了tcp三次握手时间，以及tls握手时间
3)  解决了http 2.0中前一个stream丢包导致后一个stream被阻塞的问题
4)  优化了重传策略，重传包和原包的编号不同，降低后续重传计算的消耗
5)  连接迁移，不再用tcp四元组确定一个连接，而是用一个64位随机数来确定这个连接
6)  更合适的流量控制

22. HTTP常见状态码

• 200("OK")：一切正常。实体主体中的文档（若存在的话）是某资源的表示。
• 301("Moved Permanently")：当客户端触发的动作引起了资源URI的变化时发送此响应代码。另外，当客户端向一个资源的旧URI发送请求时，也发送此响应代码。
• 400("Bad Request")：客户端方面的问题。实体主题中的文档（若存在的话）是一个错误消息。希望客户端能够理解此错误消息，并改正问题。
• 404("Not Found") 和410("Gone")：当客户端所请求的URI不对应于任何资源时，发送此响应代码。404用于服务器端不知道客户端要请求哪个资源的情况；410用于服务器端知道客户端所请求的资源曾经存在，但现在已经不存在了的情况。
• 409("Conflict")：当客户端试图执行一个”会导致一个或多个资源处于不一致状态“的操作时，发送此响应代码。
• 500("Internal Server Error")：服务期方面的问题。实体主体中的文档（如果存在的话）是一个错误消息。该错误消息通常无济于事，因为客户端无法修复服务器方面的问题。

23. HTTP请求/响应报文结构

• 一个HTTP请求报文由四个部分组成：请求行、请求头部、空行、请求数据。
• HTTP响应报文也由三部分组成：响应行、响应头、响应体

24. http和https的区别

• https协议要申请证书到ca，需要一定经济成本；
• http是明文传输，https是加密的安全传输；
• 连接的端口不一样，http是80，https是443；
• http连接很简单，没有状态；https是ssl加密的传输，身份认证的网络协议，相对http传输比较安全。

25. 对称加密和非对称加密

• 对称加密： 加密和解密的秘钥使用的是同一个.
  • 特点：密钥较短，破译困难，除了数据加密标准（DES），另一个对称密钥加密系统是国际数据加密算法（IDEA），它比DES的加密性好，且对计算机性能要求也没有那么高.
  • 优点：算法公开、计算量小、加密速度快、加密效率高
  • 缺点：在数据传送前，发送方和接收方必须商定好秘钥，然后 使双方都能保存好秘钥。其次如果一方的秘钥被泄露，那么加密信息也就不安全了。另外，每对用户每次使用对称加密算法时，都需要使用其他人不知道的唯一秘钥，这会使得收、发双方所拥有的钥匙数量巨大，密钥管理成为双方的负担。
  • 常见的对称加密算法有： DES、IDEA、3DES、Blowfish、RC4、RC5、RC6 和 AES
• 非对称加密： 与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥和私有密钥。
  • 特点：公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。
  • 非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公用密钥向其它方公开；得到该公用密钥的乙方使用该密钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的另一把专用密钥对加密后的信息进行解密。甲方只能用其专用密钥解密由其公用密钥加密后的任何信息。
  • 优点：安全
  • 缺点：速度慢
  • 常见的非对称加密算法有： RSA（CA证书）、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）
• Hash算法（摘要算法）
  • Hash算法特别的地方在于它是一种单向算法，用户可以通过hash算法对目标信息生成一段特定长度的唯一hash值，却不能通过这个hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。
  • 常见的摘要算法有： MD2、MD4、MD5、HAVAL、SHA

26. Https建立连接流程

https：//www.cnblogs.com/xiaonian8/p/13761230.html

image.png

27. SSL加密过程

SSL会话主要分为三步：

1)  客户端向服务器端索要并验证证书；
2)  双方协商生成“会话密钥”；对称密钥
3)  双方采用“会话密钥”进行加密通信；

https：//zhuanlan.zhihu.com/p/143347041

image.png

28. 为什么数据传输是用对称加密？

• 非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的。
• 在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。

29. 浏览器如何验证证书的合法性？

1)  验证域名、有效期等信息是否正确：证书上都有包含这些信息，比较容易完成验证；
2)  判断证书来源是否合法：每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证
3)  判断证书是否被篡改：需要与 CA 服务器进行校验；
4)  判断证书是否已吊销：通过CRL（Certificate Revocation List 证书注销列表）和 OCSP（Online Certificate Status Protocol 在线证书状态协议）实现，其中 OCSP 可用于第3步中以减少与 CA 服务器的交互，提高验证效率。

30. 负载均衡反向代理模式

（1）反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。
（2）反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。
（3）反向代理负载均衡能以软件方式来实现，如apache mod_proxy、netscape proxy等，也可以在高速缓存器、负载均衡器等硬件设备上实现。反向代理负载均衡可以将优化的负载均衡策略和代理服务器的高速缓存技术结合在一起，提升静态网页的访问速度，提供有益的性能；由于网络外部用户不能直接访问真实的服务器，具备额外的安全性（同理，NAT负载均衡技术也有此优点）。
（4）其缺点主要表现在以下两个方面：

• 反向代理是处于OSI参考模型第七层应用层，所以就必须为每一种应用服务专门开发一个反向代理服务器，这样就限制了反向代理负载均衡技术的应用范围，现在一般都用于对web服务器的负载均衡。
• 针对每一次代理，代理服务器就必须打开两个连接，一个对外，一个对内，因此在并发连接请求数量非常大的时候，代理服务器的负载也就非常大了，在最后代理服务器本身会成为服务的瓶颈。
  一般来讲，可以用它来对连接数量不是特别大，但每次连接都需要消耗大量处理资源的站点进行负载均衡，如search等。

31. 网络编程相关的类

• InteAddress类：InetAddress将IP地址以对象的形式进行封装，可以更方便的操作和获取其属性。
• URL和URLConnection类：通过URL我们可以访问Internet上的各种网络资源，比如最常见的WWW，FTP站点。 URL可以被认为是指向互联网资源的“指针”，通过URL可以获得互联网资源相关信息，包括获得URL的InputStream对象获取资源的信息，以及一个到URL所引用远程对象的连接URLConnection。创建一个和URL的连接，需要如下几个步骤：
  • 创建URL对象，并通过调用openConnection方法获得URLConnection对象；
  • 设置URLConnection参数和普通请求属性；
  • 向远程资源发送请求；
  • 远程资源变为可用，程序可以访问远程资源的头字段和通过输入流来读取远程资源返回的信息。
• URLDecoder和URLEncoder：这两个类可以别用于将application/x-www-form-urlencoded MIME类型的字符串转换为普通字符串，将普通字符串转换为这类特殊型的字符串。使用URLDecoder类的静态方法decode()用于解码，URLEncoder类的静态方法encode()用于编码。
• Socket和ServerSocket类：Socket通常用来实现客户方和服务方的连接。
• DatagramSocket类：用来支持数据报通信，DatagramSocket用于在程序之间建立传送数据报的通信连接， DatagramPacket则用来表示一个数据报。

32. WebSocket 长连接实现

  WebSocket是HTML5新增的协议，它的目的是在浏览器和服务器之间建立一个不受限的双向通信的通道，比如说，服务器可以在任意时刻发送消息给浏览器。实时通讯的最优方案。
  之前有两个替代方案，不过都不能完全满足需求。一个是轮询，一个是comet。简单理解，轮询就是通过js设置一个定时器不断查询接口，但是这样做会造成一个问题，定时器频率太慢相当于延时会很长，频率太快又会给服务器带来很大的压力；而comet可以理解为一次请求如果没有超过预定时间或者没有返回数据，就会一直保持链接状态，在服务器挂起一个线程，这就代表着也要消耗服务器资源，而且，一个HTTP连接在长时间没有数据传输的情况下，链路上的任何一个网关都可能关闭这个连接，而网关是我们不可控的，这就要求Comet连接必须定期发一些ping数据表示连接“正常工作”。

image.png

-   注意事项：
1)  正常ajax访问服务器地址可以通过http或https，而WebSocket访问服务器地址要通过ws。
2)  可以在通过在地址后面加一个?加其他要传递的参数。类似于get的请求方式。如：ws：//127.0.0.1：5000?id=213
3)  通过send方法向服务器发送数据时，我们只能传递字符串，所以在发送数据前如果数据结构比较复杂就需要JSON.stringify()方法将参数转为字符串，同时也需要用JSON.parse()方法将服务端发送的数据解析出来。

33. TCP协议下的socket

image.png

34. Tomcat底层原理

Tomcat通过监听端口，获取数据，然后解析数据，根据请求url找到对应的Servlet实现类，然后通过反射执行Servlet实现类中的方法。