计算机网络面试题

主题	链接
Java基础知识	面试题
Java集合容器	面试题
Java并发编程	面试题
Java底层知识	面试题
Java常用框架	面试题
计算机网络	面试题
数据库	面试题
RabbitMQ	面试题
Redis	面试题

在浏览器地址栏输入一个URL后回车，执行的全部过程

参考文档

1. 识别URL
2. 查找本地hosts文件
   2.1. 询问本地域名服务器
   2.2. 询问根域名服务器
3. 建立TCP连接
4. 发起HTTP请求
5. 服务器响应HTTP请求， 返回资源文件
6. TCP连接释放
7. 浏览器渲染页面

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三次握手：

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

TCP四次挥手：

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连接的时间要比客户端早一些。

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

因为当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请求的过程

1. 浏览器请求tcp连接（第一次握手）
2. 服务器答应进行tcp连接（第二次握手）
3. 浏览器确认，并发送post请求头（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）
4. 服务器返回100 continue响应
5. 浏览器开始发送数据
6. 服务器返回200 ok响应

get请求的过程

1. 浏览器请求tcp连接（第一次握手）
2. 服务器答应进行tcp连接（第二次握手）
3. 浏览器确认，并发送get请求头和数据（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）
4. 服务器返回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、反向代理服务器再将数据返回给用户