Java计算机网络面试汇总

写在前面：
先声明下，这个面试专题，主要是写给自己的，用来在挤公交的时候学习下，顺便做个分享。。。 我就是个小菜鸡。

计算机网络是校招比较喜欢考察的点，但是和我原来通信专业学习的侧重点不一样。通信学习的主要是IP地址划分，还有一些数据链路层和物理层的知识。而在软件开发这方面，则注重考察应用层和传输层（即HTTP和TCP等）。

五层模型

原来是7层模型的，可以记忆成应表会传网数物，分别对应应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。 后来将应用层、表示层和会话层整合为了应用层。这里主要讲解的是java面试的内容，所以喜欢的同学可以自行查找相关资料。

HTTP相关

http是应用层的协议，同层的协议还有SMTP、FTP等。这层协议的目的是解决如何将数据进行包装。

1. http的状态码

状态码	类别	含义
1XX	Infromational(信息性状态码)	指接收的请求正在处理中
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向）	需要进行附加操作来完成相应的请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误)	服务器处理请求出错

需要记忆的状态码：

• 100 Continue:表示到目前为止都是正常相应，客户端可以急需发送请求或者忽略这个相应
• 200 OK：表示请求成功处理
• 204 No Content：请求处理成功，但是返回的响应报文不包含实体的主体部分
• 403 Forbidden： 请求被禁止，被拒绝
• 404 Not Fount： 服务器无法正常提供信息，或是服务器无法回应
• 503 Service Unavailable：服务器暂时处于超负载或者停机维护，现在无法处理请求

2. 长连接与短链接
   长连接是指只需要简历以此TCP链接，就可以进行多次http通信，即1对多的关系。
   从http1.1 开始就用的是长连接了，在此之前都是短链接；
3. HTTPS
   HTTPS相较于http会更加安全：
   http是超文本传输协议，信息是明文传输；而https则是具有安全性的加密传输协议
   两者是完全不同的连接方式，用的端口也不一样，http是80，https是443
   http连接简单，是无状态的；https是由SSL+HTTP协议构成的可进行加密传输、身份认证

整个过程分为以下几步：

其中4.1步骤保证防止黑客攻击，因为证书存在一个列表，只有合法的证书才在列表中，而黑客无法得到这个合法的证书，浏览器会提示该网页不安全。

1、浏览器发起往服务器的 443 端口发起请求，请求携带了浏览器支持的加密算法和哈希算法。
2、服务器收到请求，选择浏览器支持的加密算法和哈希算法。
3、服务器下将数字证书返回给浏览器，这里的数字证书可以是向某个可靠机构申请的，也可以是自制的。（注释：证书包括以下这些内容：1. 证书序列号。2. 证书过期时间。3. 站点组织名。4. 站点DNS主机名。5. 站点公钥。6. 证书颁发者名。7. 证书签名。因为证书就是要给大家用的，所以不需要加密传输）
4、浏览器进入数字证书认证环节，这一部分是浏览器内置的 TSL 完成的：
4.1 首先浏览器会从内置的证书列表中索引，找到服务器下发证书对应的机构，如果没有找到，此时就会提示用户该证书是不是由权威机构颁发，是不可信任的。如果查到了对应的机构，则取出该机构颁发的公钥。
4.2 用机构的证书公钥解密得到证书的内容和证书签名，内容包括网站的网址、网站的公钥、证书的有效期等。浏览器会先验证证书签名的合法性（验证过程类似上面 Bob 和 Susan 的通信）。签名通过后，浏览器验证证书记录的网址是否和当前网址是一致的，不一致会提示用户。如果网址一致会检查证书有效期，证书过期了也会提示用户。这些都通过认证时，浏览器就可以安全使用证书中的网站公钥了。
4.3 浏览器生成一个随机数 R，并使用网站公钥对 R 进行加密。
5、浏览器将加密的 R 传送给服务器。
6、服务器用自己的私钥解密得到 R。
7、服务器以 R 为密钥使用了对称加密算法加密网页内容并传输给浏览器。
8、浏览器以 R 为密钥使用之前约定好的解密算法获取网页内容。

https的加密算法：
对称加密：就是使用相同的规则进行加密解密，两端通过同一个密钥进行明文的加密和解密，但是这种密钥的传输安全问题又无法得到保障，假设在传输密钥规则的时候被黑客拦截了，黑客知道密钥后也可以直接进行密文解密。因次这种加密算法仍然有弊端存在，在于如何安全的传递密钥。

非对称加密：非对称加密拥有一套匹配的公钥和私钥，明文可以使用公钥加密成密文，密文再用私钥进行解密成明文，也可以反过来，用私钥加密，公钥继续解密。
https采用对称和非对称：
通过使用非对称密钥加密方式，传输对称密钥加密方式所需要的secret Key，从而保证安全性；
获取到secret key后，再使用堆成密钥加密方式通信，从而保证了效率。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-K3H8esWY-1597284524765)(https://camo.githubusercontent.com/370d97acbc36633fdd170957bbdcf8f8c91230ff/68747470733a2f2f63732d6e6f7465732d313235363130393739362e636f732e61702d6775616e677a686f752e6d7971636c6f75642e636f6d2f486f772d48545450532d576f726b732e706e67)]

4. HTTP2

与http的区别：

1. http2使用的是二进制传送，http1是文本传送；二进制传送的单位是帧和流，同时流还有id标识

2. http2支持多路复用：因为有流ID，所以通过一个http请求实现多个http请求传输变成可能，可以通过流id来定位到是哪个http请求。

3. http2头部压缩：通过gzip和compress压缩头部后在发送，同时客户端和服务器端同时维护一张头信息表，所有的字段都记录在这张表中；后面每次传输只要将表里面的索引id传输就行，通过索引id查询表头的值；

4. http2支持在未经客户端许可的情况下，主动向客户端推送内容

5. cookie、session、token的异同
   cookie:

Http是无状态的协议，为了让协议尽可能简单，使其能够处理大量事务，引用了cookie：
cookie是服务器发送到用户浏览器并保存再本地的数据。在浏览器之后向同一服务器再次发起时被携带上，以同时服务器两个请求时来自同一个浏览器，即客户端。但是由于cookie数据被请求携带，所以性能开销会大；

session:

session是存储在服务器端，相对cookie而言更安全；session存储在服务器上的文件、数据库或者内存中，也可以存储在redis中，效率更高；

使用redis存储session的请求流程：

• 用户登陆时，提交包含用户名和密码的表单，放入http请求报文中；
• 服务器验证消息信息，正确后会把用户信息存储到redis中，这里的key称之为session ID；
• 服务器返回的相应报文的set-cookie首部字段包含了session ID，客户端收到相应报文后将cookie值存入浏览器中；
• 客户端之后对同一个服务器进行请求时会包含该cookie值，服务器收到之后提取出session ID，从redis中取出数据。

比较
cookie存储信息在浏览器端；session存储信息在服务器端；
cookie只能存储ASCII码字符串，而session则可以存储任何数据类型的数据。
对于大型网站，如果用户所有的信息都存储在session中，那么开销较大。不建议将所有的信息都存在session中；

token
更安全的cookie，在用户第一次登录时，服务端使用SHA256加密算法对数据进行加密。
在下一次浏览器把加密的token带来后，服务器再使用相同的算法对数据进行一次加密，比较两次结果，如果相同则通过。
整个过程只需要服务器端的私钥进行操作。
服务器端不需要存储session数据，是无状态的。

优势：
无状态，可扩展； 支持移动设备； 跨程序调用； 安全高效。

6. HTTP的首部
   当发送请求时：首部主要包括请求行、请求头、请求体。
   其中请求行：包括请求的方法(post、get)、url、以及http的版本号
   请求头：包括一些请求字段，例如：Host请求资源所在的服务器，connection控制不在转发给代理的首部字段（用来管理持久连接）。
   请求体：主要的data信息。

当回复响应时，首部一样，只不过都换成响应行、响应头、响应体。

TCP相关

TCP是传输层的协议，主要是用来保证可靠传输的，类似于卡车，而http就类似于卡车上的货物，IP协议就是高速公路。
在TCP主要考察3个方面：TCP与UDP的区别、TCP如何保证可靠传输以及3次握手和4次挥手

UDP 介绍

UDP（User Data Protocol，用户数据报协议）是无连接的、简单的、面向数据报的传输层协议。也就是 UDP 在发送数据之前，无须建立客户端与服务端的连接，直接发送消息即可。

UDP 的协议头有 8 个字节（64 位），如下图所示：

其中源端口和目标端口是指记录发送方和接收方端口；UDP 包长度是指 UDP 头部加上 UDP 数据的总长度；UDP 校验和用于效验 UDP 的内容是否可靠。
UDP 常见的使用场景有：语音、视频等多媒体通信、DNS（域名转化）、TFTP 等。在TCP主要考察3个方面：TCP与UDP的区别、TCP如何保证可靠传输以及3次握手和4次挥手

1. TCP和UDP的区别：

UDP（用户数据报协议）是无连接的，没有拥塞控制，是面向报文（即对于应用层传下来的报文不合并也不拆分，知识添加到UDP的首部），支持一对一，一对多、多对一和多对多通信。
TCP（传输控制协议）是面向连接的，能提供可靠的交付，有流量控制，拥塞控制，是一种全双工的通信方式，面向的是字节流（即把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），并且TCP连接时点对点的（即1对1）

2. 如何保证可靠传输

• 首先，TCP使用超时重传来实现可靠传输，如果一个已经发送的报文段在超时时间内没有收到确认，那么就重新传输这个报文段。
• TCP利用滑动窗口来实现流量的控制。 窗口是TCP首部的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方公国TCP报文段中的窗口字段告诉发送方自己窗口的大小，发送方根据这个值和其他的信息来设置自己的窗口大小，这个大小是通过滑动来改变的。如果将窗口的字段设为0，则发送方不发送数据。
• TCP拥塞控制：
  产生拥塞的原因：接收方没有收到数据，发送方会重传，如果出现拥塞，分组将会丢失，此时发送方仍然会重传，从而导致拥塞程度跟高。
  与流量控制不同：流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。
  通过4个算法来实现拥塞控制：慢开始，拥塞避免，快重传和快恢复
  发送方需要维护一个拥塞窗口的状态变量，但是实际发送方能发送多少的数据还是发送方窗口决定的。

3. 为什么3次握手和4次挥手
   3次握手的流程，这里就暂且不提了，稍微说一下4次挥手：

四次挥手过程
假设主机A为客户端，主机B为服务器，其释放TCP连接的过程如下：
1） 关闭客户端到服务器的连接：首先客户端A发送一个FIN，用来关闭客户到服务器的数据传送，然后等待服务器的确认。其中终止标志位FIN=1，序列号seq=u。
2） 服务器收到这个FIN，它发回一个ACK，确认号ack为收到的序号加1。
3） 关闭服务器到客户端的连接：也是发送一个FIN给客户端。
4） 客户段收到FIN后，并发回一个ACK报文确认，并将确认序号seq设置为收到序号加1。 首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

• 3次握手的原因：
  第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开链接，防止FIN洪水攻击。
  例如：客户端发送的请求如果在网络中滞留，那么就会间隔很长时间才能够收到服务器端发送的连接确认。客户端等待一个超时重传时间后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器，如果不进行第三次握手，那么服务器就会打开两个连接。如果第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不在进行握手，所以就不会再次打开相同的连接。

• 4次挥手的原因：
  客户端发送了FIN连接释放报文后，服务器收到了这个报文，就进入了close-wait状态，这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送fin连接释放报文。

  如果是三次挥手的话：被动关闭端在收到FIN消息之后，需要同时回复ACK和Server端的FIN消息。如果Server端在该连接上面并没有Pending的消息要处理，那么是可以的，如果Server端还需要等待一段时间才可以关闭另外一个方向的连接，那么这样的三次挥手就不能满足条件。

• 2msl的原因

确保最后一个确认报文能够到达，如果服务端没有收到客户端发来的确认报文（A客户端发送ACK可能会丢失），那么九号虫棍发送连接释放请求报文，客户端等待一段时间是为了防止这种意外发生；

另外一点是为了让本链接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

TCP 滑动窗口

窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。

发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。

TCP 流量控制

流量控制是为了控制发送方发送速率，保证接收方来得及接收。

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

TCP 拥塞控制

如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。

TCP 主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。

发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，注意拥塞窗口与发送方窗口的区别：拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。

为了便于讨论，做如下假设：

• 接收方有足够大的接收缓存，因此不会发生流量控制；
• 虽然 TCP 的窗口基于字节，但是这里设窗口的大小单位为报文段。

1. 慢开始与拥塞避免

发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 …

注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。

如果出现了超时，则令 ssthresh = cwnd / 2，然后重新执行慢开始。

2. 快重传与快恢复

在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。

在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。

在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。

慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。

文章主要参考来自于github上的cs_notes，通过我面试考到的知识点，做了一个常考题目的汇总。
github连接