一汽启明java面试问题.docxVIP

一汽启明java面试问题

1、OSI七层模型与TCP/IP五层模型

OSI七层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层

TCP/IP五层：物理层、数据链路层、网络层、传输层、应用层

2、常见应用层协议和运输层、网络层协议，以及硬件如路由器之类在哪一层

应用层：HTTP、SMTP、DNS、FTP

传输层：TCP、UDP

网络层：ICMP、IP、路由器、防火墙

数据链路层：网卡、网桥、交换机

物理层：中继器、集线器

3、TCP与UDP区别和应用场景，基于TCP的协议有哪些，基于UDP的有哪些

基于TCP的协议：HTTP、FTP、SMTP

基于UDP的协议：RIP、DNS、SNMP

4、TCP可靠传输的保证，拥塞控制目的和过程

TCP通过：应用数据分割、对数据包进行编号、校验和、流量控制、拥塞控制、ARP协议、超时重传等措施保证数据的可靠传输；

拥塞控制目的：为了防止过多的数据注入到网络中，避免网络中的路由器、链路过载。

拥塞控制过程：TCP发送发将维护一个拥塞窗口的状态变量，该变量随着网络拥塞程度动态变化，通过慢开始、拥塞避免等算法减少网络拥塞的发生。

5、TCP粘包现象原因和解决方法

TCP粘包是指：发送方发送的若干包数据到接收方接收时粘成一包。

发送方原因：

TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量），而Nagle算法主要做两件事：

只有上一个分组得到确认，才会发送下一个分组?收集多个小分组，在一个确认到来时一起发送?Nagle算法造成了发送方可能会出现粘包问题。

接收方原因：

TCP接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

解决粘包问题：

最本质原因在与接收对等方无法分辨消息与消息之间的边界在哪，通过使用某种方案给出边界，例如：发送定长包。如果每个消息的大小都是一样的，那么在接收对等方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。

包尾加上\r\n标记。FTP协议正是这么做的。但问题在于如果数据正文中也含有\r\n，则会误判为消息的边界。

包头加上包体长度。包头是定长的4个字节，说明了包体的长度。接收对等方先接收包体长度，依据包体长度来接收包体。

6、TCP三次握手过程以及每次握手后的状态改变，为什么三次？为什么两次不行？

三次握手过程：

客户端——发送带有SYN标志的数据包——服务端?一次握手?Client进入synsent状态。?

服务端——发送带有SYN/ACK标志的数据包——客户端?二次握手?服务端进入syn_rcvd。

客户端——发送带有ACK标志的数据包——服务端?三次握手?连接就进入Established状态。

为什么三次：

主要是为了建立可靠的通信信道，保证客户端与服务端同时具备发送、接收数据的能力

为什么两次不行？

?

1、防止已失效的请求报文又传送到了服务端，建立了多余的链接，浪费资源。

2、两次握手只能保证单向连接是畅通的。（为了实现可靠数据传输，TCP协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤；如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认）

7、TCP四次挥手过程以及状态改变，为什么四次？CLOSE-WAIT和TIME-WAIT存在的意义？如何查看TIME-WAIT状态的链接数量？为什么会TIME-WAIT过多？解决方法是怎样的？

四次挥手过程：

客户端——发送带有FIN标志的数据包——服务端，关闭与服务端的连接，客户端进入FIN-WAIT-1状态

服务端收到这个FIN，它发回?个ACK，确认序号为收到的序号加1，服务端就进入了CLOSE-WAIT状态

服务端——发送?个FIN数据包——客户端，关闭与客户端的连接，客户端就进入FIN-WAIT-2状态

客户端收到这个FIN，发回ACK报?确认，并将确认序号设置为收到序号加1，TIME-WAIT状态

为什么四次：

因为需要确保客户端与服务端的数据能够完成传输。

CLOSE-WAIT：

这种状态的含义其实是表示在等待关闭

TIME-WAIT：

为了解决网络的丢包和网络不稳定所带来的其他问题，确保连接方能在时间范围内，关闭自己的连接。

如何查看TIME-WAIT状态的链接数量？

netstat-