面试题-网络

以下所有整理内容都是我从第一次面试开始，将所有遇到的问题整合后的结果。所有的内容都是我在面试中真实遇到的问题，有BAT这样的大厂，也有很多小厂。在面试超过20家之后，遇到的绝大多数问题都开始重复，这份资料给我的面试带来了非常多的便利。现在我将这份资料分享在这里，希望也能够给你带来一些帮助，加油吧少年！

---

1. TCP的三次握手

1.1 TCP三次握手过程

（1）第一次客户端进程向服务器进程发送SYN包，并进入SYS_SEND状态

（2）第二次服务器确认ACK，同时发送SYN包，即ACK+SYN包，并进入SYN_RECV状态

（3）第三次客户端收到ACK+SYN包，向服务器发送确认包ACK，完毕后客户端和服务器进入ESTABLISHED状态。

1.2 为什么是三次握手&四次挥手

如果是两次的话，服务器发送确认ACK就开始维护连接，如果客户端没有收到，那就浪费了服务端的资源。同时两次的话第一次A发SYN和初始序列号给B，B再发SYN和初始序列号和ACK给A，如果A没有收到，那双方的初始序列号就无法同步了

如果四次，那么就造成了浪费，因为在三次结束之后，就已经可以保证A可以给B发信息，A可以收到B的信息； B可以给A发信息，B可以收到A的信息。

1.3 四次挥手（谁先发都可）

（1）第一次客户端给服务器发送FIN包，告诉服务器“我不会发数据了”，但是没收到ACK确认报文前依然可以接收。

（2）第二次服务器发送ACK给客户端。

（3）第三次服务器发送给客户端FIN包，即“我的数据也发完了”。

（4）第四次客户端收到后，发送ACK给服务器，完成四次挥手。

2. OSI七层和TCP/IP四层

2.1 协议

2.2 设备分布

3. TCP如何保证可靠传输

校验和、确认应答+序列号、超时重传、流量控制、拥塞控制

（1）检验和

发送的数据包的二进制相加取反。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。

（2）确认应答+序列号

TCP给发送的每一个包进行编号，接收方对数据报进行排序，把有序数据传给应用层

（3）超时重传

当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

（4）流量控制

TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP使用的流量控制协议是可变大小的滑动窗口协议。

接收方有即时窗口（滑动窗口），随ACK报文发送

（5）拥塞控制

当网络拥塞时，减少数据的发送

发送方有拥塞窗口，发送数据前比对接收方发过来的即时窗口，取小的

4. Socket有哪些类型，以及使用

Soket（套接字）是由ip地址和端口号组成的

套接字的类型有：Internet套接字，Unix套接字，X.25套接字

我用过的是流式套接字和数据报套接字，前者基于的是TCP协议，后者是UDP协议，

（1）流式套接字使用

这种类型是面向连接的，所以服务端起一个ServerSocket实例后调用accept方法进入阻塞，等待客户连接，而客户连接后该方法会返回一个新的socket，使用新的soket与客户端传输数据，这里再开一个线程即可

而客户端就很简单了，创建一个socket实例设置好ip和端口，打开socket的输入输出流进行读写操作就行了，当执行read但是没有数据时，会阻塞在那里，也可以设置超时来限制阻塞时间。

（2）数据报套接字使用

数据报套接字就是服务端起一个DatagramSocket套接字实例和一个DatagramPacket数据报实例，数据报实例可以设置缓冲区，然后套接字实例调receive方法进入阻塞等待接收数据报

客户端也一样，只是数据报要设置上调用服务的ip和端口以及要发送的数据，套接字调用send方法即可。

5. Cookie和Session

session主要解决http协议是无状态的。当访问服务器否个网页的时候，会在服务器端的内存里开辟一块内存，这块内存就叫做session，而这个内存是跟浏览器关联在一起的。

5.1 两者的区别

（1）session存储数据在服务器内存里，cookie在浏览器客户端

（2）session没有数据大小限制，cookie有，单个不能超过4kb，对同一域名下的cookie数量也有限制(20)

（3）session数据安全，cookie相对于不安全。所以cookie一般存少量不太敏感的信息，而session可以存任何大小和类型的数据。

5.2 实际项目中cookie存了哪些信息

在授权中心中，使用cookie存储了jwt类型的用户token信息。

由于无状态登录不需要session，所以就把登录状态存在cookie里了

实现就是在controller的方法里，写了个工具类，即第一次请求认证的时候把response.setCookie(cookie)设置进去就行，其他时候请求认证的时候设置有效时间，就等于是重置一下。

cookie里要有cookie名、cookie值、编码格式，过期时间、所属域名

6. TCP长连接和短连接

长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。

client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三次握手，这需要时间

例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

7. TCP和UDP的比较

	UDP	TCP
是否连接	无连接	面向连接
是否可靠	不可靠传输，不使用流量控制和拥塞控制	可靠传输，使用流量控制和拥塞控制
连接对象个数	支持一对一，一对多，多对一和多对多交互通信	只能是一对一通信
传输方式	面向报文	面向字节流
首部开销	首部开销小，仅8字节	首部最小20字节，最大60字节
适用场景	适用于实时应用（IP电话、视频会议、直播等）	适用于要求可靠传输的应用，例如文件传输

UDP的优势：

在流媒体上，采用TCP，一旦发生丢包，TCP会将后续包缓存起来，等前面的包重传并接收到后再继续发送，延迟会越来越大。基于UDP的协议如WebRTC是极佳的选择。

• 网络带宽需求较小，而实时性要求高；

• 大部分应用无需维持连接；

• 需要低功耗；

• 能够对握手过程进行精简，减少网络通信往返次数；

• 能够对TLS加解密过程进行优化；

• 收发快速，无阻塞。