计算机网络面试题
| 主题 | 链接 |
|---|---|
| Java基础知识 | 面试题 |
| Java集合容器 | 面试题 |
| Java并发编程 | 面试题 |
| Java底层知识 | 面试题 |
| Java常用框架 | 面试题 |
| 计算机网络 | 面试题 |
| 数据库 | 面试题 |
| RabbitMQ | 面试题 |
| Redis | 面试题 |
文章目录
- 在浏览器地址栏输入一个URL后回车，执行的全部过程
- tcp、udp、http、https等常用协议
- OSI七层模型
- 三次握手与四次关闭
- 为什么连接的时候是三次握手，关闭的时候却是四次握手？
- 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
- 为什么不能用两次握手进行连接？
- 如果已经建立了连接，但是客户端突然出现故障了怎么办？
- 流量控制和拥塞控制
- tcp粘包与拆包
- HTTP1.0
- HTTP1.1
- HTTPS与HTTP的一些区别
- HTTP 2.0
- http中 get和post区别
- 既然post有这么多优点，那我们为什么要使用get？
- 常见的web请求返回的状态码
- http/3
- cookie 与 session
- cookie被禁用，如何实现session
- 进程间通讯的方式
- 什么是CDN？如果实现？
- 什么是正向代理、反向代理？
在浏览器地址栏输入一个URL后回车，执行的全部过程
参考文档
- 识别URL
- 查找本地hosts文件
2.1. 询问本地域名服务器
2.2. 询问根域名服务器 - 建立TCP连接
- 发起HTTP请求
- 服务器响应HTTP请求， 返回资源文件
- TCP连接释放
- 浏览器渲染页面
tcp、udp、http、https等常用协议
1.HTTP(Hypertext Transfer Protocol) 超文本传输协议(80)
1).无状态(cookie/session keep-alive)
2).无连接
3).基于请求和响应
4).简单灵活
5).通信使用明文
2.HTTPS(Hypertext Transfer Protocol Secure)超文本传输安全协议(443)
1).HTTP+SSL(Netscape的安全套接层)
a).SSL((Secure Sockets Layer) 安全套接层(40-128)
b).TLS(Transport Layer Security) 传输层安全
2).数据加密(SSL);身份认证(CA证书[采用非对称加密])
3.TCP(Transmission Control Protocol)传输控制协议
1).面向连接
2).可靠传输的情况, 应用于文件传输, 重要状态更新等场景
3).传输大量数据
4).传输慢
4.UDP(User Data Protocol)用户数据协议
1).面向非连接
2).高速传输和实时性要求较高的通信领域(可靠性需要应用层控制)
3).传输少量数据
4).传输快
5.Socket(程序通过一个双向的通信连接实现数据的交换，连接的一端称为一个socket)(API)
1).socket本质是编程接口(API),对TCP/IP的封装,TCP/IP也要提供可供程序员做网络开发所用的接口，这就是Socket编程接口
2).连接过程:服务器监听，客户端请求，连接确认
3).优势与劣势
A).优势:
a).传输数据为字节级，传输数据可自定义，数据量小
b).传输数据时间短，性能高
c).适合于客户端和服务器端之间信息实时交互
d).可以加密,数据安全性强
B).劣势:
a).需对传输的数据进行解析，转化成应用级的数据
b).相对于HTTP协议传输，增加了开发量
c).对开发人员的开发水平要求高
4).基于Socket传输的特点其适用于对传输速度，安全性，实时交互，费用等要求高的应用中，如网络游戏，手机应用，银行内部交互等
6.TCP/IP(TCP/IP Protocol Suite)TCP/IP协议族
1).四层模型
a).应用层 有FTP、HTTP、TELNET、SMTP、DNS等协议
b).传输层 有TCP协议与UDP协议
c).网络层 有IP协议、ICMP协议、ARP(地址解析)协议、RARP(反向地址解析)协议和BOOTP协议
d).网络接口层 有FDDI、Ethernet、Arpanet、PDN、SLIP、PPP、IEEE802.1A、IEEE802.2-IEEE802.11
2).五层模型
a).应用层 有FTP、HTTP、TELNET、SMTP、DNS等协议
b).传输层 有TCP协议与UDP协议
c).网络层 有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议
d).数据链路层 有FDDI、Ethernet、Arpanet、PDN、SLIP、PPP
e).物理层 有IEEE802.1A、IEEE802.2- IEEE802.11等协议
7.OSI(Open Systems Interconnection)开发系统互联(七层模型)
1).应用层(为应用程序提供服务) 有FTP、HTTP、TELNET、SMTP、DNS等协议
2).表示层(数据格式转化，数据加密、解密)
3).会话层(建立、管理和维护会话)
4).传输层(建立、管理和维护端到端的连接) 有TCP协议与UDP协议
5).网络层(IP选址及路由选择) 有IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议
6).数据链路层(提供介质访问和链路管理) 有FDDI、Ethernet、Arpanet、PDN、SLIP、PPP
7).物理层(物理层) 有IEEE802.1A、IEEE802.2- IEEE802.11等协议
参考文档
OSI七层模型
三次握手与四次关闭
参考文档
TCP报文结构：
TCP标志位：
TCP三次握手：
- 第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号
- 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
- 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
TCP四次挥手：
- 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
- 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
- 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
- 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
- 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
- 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
为什么连接的时候是三次握手，关闭的时候却是四次握手？
因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
为什么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连接。
为什么不能用两次握手进行连接？
3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
流量控制和拥塞控制
- 流量控制：如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。TCP的流量控制是利用滑动窗口机制实现的，接收方在返回的数据中会包含自己的接收窗口的大小，以控制发送方的数据发送。
- 拥塞控制：拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。
区别：流量控制是为了预防拥塞。如：在马路上行车，交警跟红绿灯是流量控制，当发生拥塞时，如何进行疏散，是拥塞控制。流量控制指点对点通信量的控制。而拥塞控制是全局性的，涉及到所有的主机和降低网络性能的因素。
拥塞解决的两种方法：
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
慢开始+拥塞避免：发送方维持一个拥塞窗口 cwnd ( congestion window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞。发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。
快重传+快恢复：快重传要求接收方在收到一个失序的报文段后就立即发出重复确认。如果没有快速重传和快速恢复，TCP将会使用定时器来要求传输暂停。在暂停这段时间内，没有新的数据包被发送。所以快速重传和快速恢复旨在快速恢复丢失的数据包。
参考文档
tcp粘包与拆包
参考文档
产生tcp粘包和拆包的原因
tcp是以流动的方式传输数据，传输的最小单位为一个报文段（segment）。tcp Header中有个Options标识位，常见的标识为mss(Maximum Segment Size)指的是，连接层每次传输的数据有个最大限制MTU(Maximum Transmission Unit)，一般是1500比特，超过这个量要分成多个报文段，mss则是这个最大限制减去TCP的header，光是要传输的数据的大小，一般为1460比特。换算成字节，也就是180多字节。
tcp为提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了之后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制，来接收数据。
发生TCP粘包、拆包主要是由于下面一些原因：
- 应用程序写入的数据大于套接字缓冲区大小，这将会发生拆包。
- 应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生粘包。
- 进行mss（最大报文长度）大小的TCP分段，当TCP报文长度-TCP头部长度>mss的时候将发生拆包。
- 接收方法不及时读取套接字缓冲区数据，这将发生粘包。
如何解决拆包粘包
既然知道了tcp是无界的数据流，且协议本身无法避免粘包，拆包的发生，那我们只能在应用层数据协议上，加以控制。通常在制定传输数据时，可以使用如下方法：
- 使用带消息头的协议、消息头存储消息开始标识及消息长度信息，服务端获取消息头的时候解析出消息长度，然后向后读取该长度的内容。
- 设置定长消息，服务端每次读取既定长度的内容作为一条完整消息。
- 设置消息边界，服务端从网络流中按消息编辑分离出消息内容。
HTTP1.0
- HTTP1.0规定浏览器和服务器保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）
- 无连接的特性导致最大的性能缺陷就是无法复用连接。每次发送请求的时候，都需要进行一次TCP的连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率非常低。
- 其次就是队头阻塞（head of line
blocking）。由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送。假设前一个请求响应一直不到达，那么下一个请求就不发送，同样的后面的请求也给阻塞了。
HTTP1.1
- 对于HTTP1.1，不仅继承了HTTP1.0简单的特点，还克服了诸多HTTP1.0性能上的问题。
- 首先是长连接，HTTP1.1增加了一个Connection字段，通过设置Keep-Alive可以保持HTTP连接不断开，避免了每次客户端与服务器请求都要重复建立释放建立TCP连接，提高了网络的利用率。如果客户端想关闭HTTP连接，可以在请求头中携带Connection: false来告知服务器关闭请求。
- 其次，是HTTP1.1支持请求管道化（pipelining）。基于HTTP1.1的长连接，使得请求管道化成为可能。管线化使得请求能够“并行”传输。举个例子来说，假如响应的主体是一个html页面，页面中包含了很多img，这个时候keep-alive就起了很大的作用，能够进行“并行”发送多个请求。
HTTPS与HTTP的一些区别
- HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
- HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
- HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
- HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。
HTTP 2.0
- 二进制分帧：HTTP2.0通过在应用层和传输层之间增加一个二进制分帧层，突破了HTTP1.1的性能限制、改进传输性能。
- 多路复用：所有的HTTP2.0通信都在一个TCP连接上完成，这个连接可以承载任意数量的双向数据流。
- 首部压缩：在 HTTP/1 中，HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成。一般而言，消息主体都会经过
gzip 压缩，或者本身传输的就是压缩过后的二进制文件（例如图片、音频），但状态行和头部却没有经过任何压缩，直接以纯文本传输。 - 服务器推送：HTTP/2引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前。一个服务器经常知道一个页面需要很多附加资源，在它响应浏览器第一个请求的时候，可以开始推送这些资源。这允许服务端去完全充分地利用一个可能空闲的网络，改善页面加载时间。
http中 get和post区别
https://www.jianshu.com/p/a9142a4d084f
HTTP协议对GET和POST都没有对长度的限制：HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。
数据长度：
- GET:特定浏览器和服务器对URL长度有限制，例如 IE对URL长度的限制是2083字节(2K+35)
- POST:由于不是通过URL传值，理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。
安全性：
- 通过GET提交数据，用户名和密码将明文出现在URL上，因为登录页面有可能被浏览器缓存，其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了。
- post一般来说都不会被缓存，但有很多抓包工具也是可以窥探到你的数据，真的要安全那就要把传输的信息加密。
- get在HTPP协议中用于获取数据，post在在HTTP协议中用于修改数据。
既然post有这么多优点，那我们为什么要使用get？
- 一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查 ，改 ，增 ，删4个操作。
- get比post更快：post请求的过程，会先将请求头发送给服务器进行确认，然后才真正发送数据；而get请求的过程，会在连接建立后会将请求头和请求数据一起发送。
post请求的过程
- 浏览器请求tcp连接（第一次握手）
- 服务器答应进行tcp连接（第二次握手）
- 浏览器确认，并发送post请求头（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）
- 服务器返回100 continue响应
- 浏览器开始发送数据
- 服务器返回200 ok响应
get请求的过程
- 浏览器请求tcp连接（第一次握手）
- 服务器答应进行tcp连接（第二次握手）
- 浏览器确认，并发送get请求头和数据（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）
- 服务器返回200 ok响应
常见的web请求返回的状态码
2xx - 客户端请求已成功。
200 - 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页
201 - 已创建，请求成功并且服务器创建了新的资源
202 - 已接受，但尚未处理
203 - 非权威性信息，服务器已成功处理了请求，但返回的信息可能来自另一来源
204 - 无内容，服务器成功处理了请求，但没有返回任何内容
205 - 重置内容，服务器成功处理了请求，但没有返回任何内容
206 - 部分内容，服务器成功处理了部分 GET 请求
3xx - 重定向
302 - 对象已移动
304 - 未修改
307 - 临时重定向
404 -Not Found 代表客户端错误，指的是服务器端无法找到所请求的资源
400 -请求无效，服务器不理解请求的语法
403 - 禁止访问 ，服务器拒绝请求
405 - 资源被禁止，禁用请求中指定的方法
406 - 无法接受 ，无法使用请求的内容特性响应请求的网页
407 - 要求代理身份验证 ，此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理
408 - 请求超时，服务器等候请求时发生超时
409 - 冲突，服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息
410 - 已删除，如果请求的资源已永久删除，服务器就会返回此响应。
411 - 需要有效长度， 服务器不接受不含有效内容长度标头字段的请求。
412 - 未满足前提条件， 服务器未满足请求者在请求中设置的其中一个前提条件。
413 - 请求实体过大，服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 - 请求的 URI 过长， 请求的 URI（通常为网址）过长，服务器无法处理。
415 - 不支持的媒体类型， 请求的格式不受请求页面的支持。
416 - 请求范围不符合要求，如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 - 未满足期望值，服务器未满足”期望”请求标头字段的要求
500 - 内部服务器错误，无法完成请求
501 - 未实现 ，服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码
502 - 网关错误 ，服务器作为网关或代理，从上游服务器收到无效响应
503 - 服务不可用，服务器目前无法使用，通常，这只是暂时状态
504 - 网关超时， 服务器作为网关或代理，但是没有及时从上游服务器收到请求
505 - HTTP 版本不受支持， 服务器不支持请求中所用的 HTTP 协议版本
http/3
HTTP/1.x 有连接无法复用、队头阻塞、协议开销大和安全因素等多个缺陷；
HTTP/2 通过多路复用、二进制流、Header 压缩等等技术，极大地提高了性能，但是还是存在着问题的；
QUIC 基于 UDP 实现，是 HTTP/3 中的底层支撑协议，该协议基于 UDP，又取了 TCP 中的精华，实现了即快又可靠的协议。
参考文档
cookie 与 session
所以，总结一下：
- Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中；
- Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。
- 本来 session 是一个抽象概念，开发者为了实现中断和继续等操作，将 user agent 和 server之间一对一的交互，抽象为“会话”，进而衍生出“会话状态”，也就是 session 的概念。
- 而 cookie 是一个实际存在的东西，http 协议中定义在 header 中的字段。可以认为是 session 的一种后端无状态实现。
cookie被禁用，如何实现session
- 经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。
- 还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器
进程间通讯的方式
liunx六大进程间通信方式：管道，消息队列，共享内存，信号量，socket，信号，文件锁
参考文档
什么是CDN？如果实现？
由于用户访问源站业务有性能瓶颈，通过cdn技术把源站的内容缓存到多个节点。用户向源站域名发起请求时，请求会被调度至最接近用户的服务节点，直接由服务节点直接快速响应，有效降低用户访问延迟，提升可用性。
什么是正向代理、反向代理？
正向代理
1、用户发送请求到自己的代理服务器
2、自己的代理服务器发送请求到服务器
3、服务器将数据返回到自己的代理服务器
4、自己的代理服务器再将数据返回给用户
反向代理
1、用户发送请求到服务器（访问的其实是反向代理服务器，但用户不知道）
2、反向代理服务器发送请求到真正的服务器
3、真正的服务器将数据返回给反向代理服务器
4、反向代理服务器再将数据返回给用户