面试方面:
- 网络考点
- 操作系统考点
- 软技能
- java考点
- 框架考点
- 缓存考点
这里面的不包含所有的面试考点,涵盖了大多数的高频考点;
计算机网络面试核心导航
- 一. 网络基础知识讲解
- 二. TCP的三次握手
- 三. TCP的四次挥手
- 四. TCP与UDP的区别
- 五. TCP的滑动窗口
- 六. HTTP协议
- 七. HTTP和HTTPS的区别?
- 八. Socket简介
一. 网络基础知识讲解
1.1 网络协议
- 当前世面上主要存在的几种协议: 四层, 五层 , 七层
- OSI开放式协议是主流协议[七层]
1.2 七层协议:
- 第一层 物理层:
- 机械、电子、定时接口通信道上的原始比特流传输
- 功能:以二进制数据形式在物理媒体上传输数据
- 第二层 数据链路层:
- 物理寻址,同时将原始比特流变为逻辑传输线路
- 功能: 传输有地址的帧以及错误检测功能
- 第三层 网络层:
- 控制子网的运行,如逻辑编址,分组传输、路由选择;
- 功能:为数据包选择路由
- 第四层 传输层:
- 接收上一层的数据,在必要的时候把数据进行分隔,并将这些数据交给网络层,且保证这些数据段有效到达对端;
- 提供端对端的接口
- 第五层 会话层
- 不同机器上的用户之间建立及管理会话
- 功能:解除或建立与别的接点的联系
- 第六层 表示层
- 信息的语法语义以及它们之间的关联,如加密解密、转换翻译、压缩解压密;
- 功能: 数据格式化,代码转换,数据加密
- 第七层 应用层
- 功能: 文件传输、电子邮件、文件服务、虚拟终端
TCP/IP不是完全遵从OSI七层模型,但它是OSI的一个实现;
平时的HTTP,HTTPS等的请求协议就是应用层;而TCP、UDP则是传输层,IP等为网络层等等;
TCP/IP的发送消息步骤是:先自上而下,后自下而上处理数据头部;发送消息的先从应用层封装,一直到底层然后开始发送;而接收方则是底层先开始接收,然后接收到后从链路层开始层层网上;如图所示:
二. TCP的三次握手
2.1传输控制协议TCP简介
- 在TCP/IP中,IP负责定位接收方位置,而TCP则负责传输的可靠性;
- TCP传输协议的特点:
- 面向连接的、可靠的、基于字节流的传输层通信协议;
- 将应用层的数据流分割成报文段并发送给目标节点的TCP层;
- 数据包都有序号,对方收到则发送ACK确认,未收到则重传
- 使用校验和来检验数据在传输过程中是否有误;
进程号PID在一台计算机中是唯一的,但是在两台计算机通信过程中,只能使用端口号,因为可能PID会重复;
2.2 TCP标志: TCP Flags
- URG: 紧急指针标志
- ACK: 确认序号标志
- PSH: push 标志
- RST: 重置连接标志
- SYN: 同步序号,用于建立连接过程
- FIN: finish标志,用于释放连接
2.3 TCP三次握手的流程详解:
- 第一次握手: 建立连接时,客户端发送SYN包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;
- 第二次握手: 服务器收到SYN包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;
- 第三次握手: 客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手;
“握手” 是为了建立连接;
2.4 为什么需要三次握手才能建立连接?
- 为了初始化Sequence Number的初始值
- 首次握手的隐患: SYN超时
- 问题起因分析:
- Server收到Client的SYN,回复SYN-ACK的时候未收到ACK确认
- Server不断重试直至超时,Linux默认等待63秒才断开连接
- 问题起因分析:
可能会因此收到攻击,恶意用户模拟发送数据然后下线,而没有接收方则会等待63秒才断开连接,会一直消耗SYN的队列;
2.5 首次握手的隐患-- 连接超时
- 如果收到攻击怎么防护呢?
- SYN队列满后,通过tcp_syncookies参数回发SYN Cookie
- 若为正常连接则Client会回发SYN Cookie,直至建立连接;
2.6 建立连接后,Client出现故障怎么办
- 保活机制:
- 向对方发送保活探测报文,如果未收到响应则继续发送;
- 尝试册数达到保活探测数认为收到响应则中断连接;
三. TCP的四次挥手
3.1 为什么要四次挥手?
- “挥手”是为了终止连接
3.2 TCP四次挥手的流程图:
3.3 四次挥手的解析:
- TCP采用四次挥手来释放连接
- 第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态;
- 第二次挥手:Server收到FIN后,发送一个ACK给Client,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态;
- 第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态;
- 第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态,完成四次挥手;
简单来讲,客户端第一次挥手是自己中断到服务端的数据传送,然后告诉服务端;第二次挥手是服务端接收到信息后进入等待关闭状态;第三次挥手是服务端关闭到客户端的数据传送,然后告诉客户端;第四次挥手是客户端进入超时关闭,然后通知服务端,服务端接收到后立即关闭;
3.4 为什么客户端不直接关闭,要有TIME_WAIT状态?
- 原因:
- 确保有足够的时间让对方收到ACK包
- 避免新旧连接混淆
3.5 为什么需要四次握手才能断开连接
- 原因:
- 因为全双工,发送方和接收方都需要FIN报文和ACK报文;而每次的操作都是双方各执行一次,所以四次握手实际上是每个各执行两次;
3.6 服务器出现CLOSE_WAIT状态的原因?
- 原因:
-
对方关闭socket连接,我方忙于读或写,没有及时关闭连接
- 检查代码,特别是释放资源的代码
- 检查配置,特别是处理请求的线程配置;
-
如果: CLOSE_WAIT的数量达到上千,很有可能造成通道堵塞,新请求无法接受,抛出too many open files错误,并导致Nginx,Tomcat等的崩溃;
-
四. TCP与UDP的区别
4.1 UDP的简介:
- 面向非连接
- 不维护状态,支持同时向多个客户端传输相同的消息;
- 数据包报头只有8个字节(TCP有20个),额外开销较小
- 吞吐量只受限于数据生成速率,传输速率以及机器性能
- 尽最大努力交付,不保证可靠交付,不需要位置复杂的链接状态表
- 面向报文,不对应用程序提交的报文信息进行拆分或者合并
UDP的速度很快,它只受限于机器的计算性能以及网络带宽速度的影响;它对于TCP而言,更快,但是容易丢失数据;存在一定的丢包率,不能保证所有数据一定会到达;
4.2 TCP和UDP的区别
结论:
- 面向连接vs 无连接
- 可靠性
- 有序性
- 速度
- 量级
五. TCP的滑动窗口
5.1 为什么要使用滑动窗口协议?
- 如果过多的源同时以很快的速度发送大量的数据包,而此时接收方并没有如此高的接收数据的能力,因此极易导致网络的拥塞。所以,为了控制发送方的发送速度,防止发送方并考虑到受发送缓冲区大小的制约等,要求对发送方已发出但尚未经确认的帧的数目加以限制,同时使网络的传输效率得到提高,滑动窗口协议应运而生,它使得发送方可以在未收到确认的情况下,同时发送多个数据分组,由此大大提升了网络吞吐量。
- 在任何基于自动重发请求进行错误控制的通信协议中,接收方必须确认收到的数据包。 如果发送方在合理的时间内没有收到确认,则重发数据。没有听到确认的发送方不知道接收方是否实际接收到分组(数据可能在传输中丢失或损坏)。 如果错误检测显示损坏,则数据包将被接收方忽略,并且不会发送确认。 因为网络传输的时延,将有大量时间被用于等待确认,导致传输效率低下。
5.2 RTT和RTO
- RTT: 发送一个数据包到收到对应的ACK,所花费的时间(相当于发送一次数据到接收的时间)
- RTO: 重传的时间间隔
5.3 滑动窗口原理:
图中可以看到,主要分为3个部分,第一部分为发送且已接收;第二部分为未发送且可发送;第三部分为未发送且溢出发送不了;
当第二部分的一部分数据已经发送过且确认过了,滑动窗口就会向右移动,将缓冲区的数据重新填充,溢出的数据则又在可发送的范围内;
六. HTTP协议
6.1 超文本传输协议HTTP主要特点
- 支持客户/服务器模式: 请求/响应
- 简单快速:请求方法有GET,POST等,方式简单,程序小,速度快;
- 灵活:允许传输任意类型的对象
- 无连接:限制每次连接只处理一个请求,处理完成后就断开连接
- 无状态:协议对事务处理没有记忆能力,对同一个url请求没有上下文关系,每次的请求都是独立的,服务器中没有保存客户端的状态,必须带上状态去访问服务器;
6.2 HTTP请求结构
6.3 HTTP响应结构
6.4 请求/响应的步骤:
- 客户端连接到WEB服务器
- 发送HTTP请求
- 服务器接收请求并返回HTTP响应
- 释放连接TCP连接
- 客户端浏览器解析HTML内容
6.5 在浏览器地址栏键入URL,按下回车之后经历的流程
- 答:
- DNS解析:逐层查询缓存是否存在该地址对应ip: 从近到远: 浏览器缓存,系统缓存,路由器缓存,IPS服务器缓存,域名服务器缓存,顶级域名服务器缓存,如果中间查到了则直接返回,不再继续查询
- TCP连接
- 发送HTTP请求
- 服务器处理请求并返回HTTP报文
- 浏览器解析渲染页面
- 连接结束
6.6 HTTP状态码
-
五种可能的取值:
- 1xx: 指示信息–表示请求已接收,继续处理
- 2xx: 成功-- 表示请求已被成功接收、理解、接受;
- 3xx: 重定向-- 要完成请求必须进行进一步的操作;
- 4xx: 客户端错误–请求有语法错误或请求无法实现;
- 5xx: 服务器端错误-- 服务器未能实现合法的请求;
-
常见状态码:
- 200 OK : 正常返回信息
- 400 Bad Request: 客户端请求有语法错误,不能被服务器所理解
- 401 Unauthorized: 请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用
- 403 Forbidden: 服务器收到请求,但是拒绝提供服务
- 404 Not Found: 请求资源不存在,eg,输入了错误的URL
- 500 Internal Server Error : 服务器发送不可预期的错误
- 503 Server Unavailable: 服务器当前不能处理客户端的请求,一段时间后可能恢复正常
6.7 GET请求和POST请求的区别
- 从三个层面来回答:
- HTTP报文层面:GET将请求信息放在URL,POST放在报文体中;
- 数据库层面: GET符合幂等性和安全性,POST不符合;
- 其他层面:GET可以被缓存,被存储,而POST不行;
GET请求直接将请求路径等在URL地址中,容易造成部分信息暴露,相对来讲"不安全";且体积有限制,POST不限制大小;
数据库方面,GET请求多用于查询,所以一般不会造成数据的改变,而POST的请求多用于修改添加等操作,数据库的相关数据会变化;
GET请求的数据被缓存可以减轻服务器压力;
6.8 Cookie和Session 的区别?
-
Cookie简介:
- 是由服务器发给客户端的特殊信息,以文本的形式存放在客户端
- 客户端再次请求的时候,会把Cookie回发
- 服务器接收到后,会解析Cookie生成与客户端相对应的内容
-
Session简介
- 服务器端的机制,在服务器上保存的信息
- 解析客户端请求并操作session id ,按需保存状态信息
-
Session的实现方式:
- 使用cookie来实现
- URL回写 [如果cookie被禁用,则通过此方式实现]
6.9 总结:Cookie和Session的区别?
- Cookie数据存放在客户的浏览器上,Session数据放在服务器上
- Session相对于Cookie更安全
- 若考虑减轻服务器负担,应当使用Cookie;
七. HTTP和HTTPS的区别?
7.1 SSL(Security Sockets Layer,安全套接层)
- 为网络通信提供安全以及数据完整性的一种安全协议
- 是操作系统对外的API,SSL3.0后更名为TLS
- 采用身份验证和数据加密保证网络通信安全和数据的完整性;
7.2 加密的方式:
- 对称加密: 加密和解密都使用同一个**
- 非对称加密: 加密使用的**和解密使用的**是不相同的;
- 哈希算法: 将任意长度的信息转换为固定长度的值,算法不可逆;
- 数字签名: 证明某个消息或者文件是某人发出/认同的;
7.3 HTTPS数据传输流程:
- 浏览器将支持的加密算法信息发送给服务器;
- 服务器选择一套浏览器支持的加密算法,以证书的形式回发给浏览器
- 浏览器验证证书合法性,并结合证书加密信息发送给服务器
- 服务器使用私钥解密信息,验证哈希,加密响应消息回发浏览器;
- 浏览器解密响应消息,并对消息进行验真,之后进行加密交互数据;
7.4 总结: HTTPS与HTTP区别?
- HTTPS 需要到CA申请证书,HTTP不需要
- HTTPS密文传输,HTTP明文传输
- 连接方式不同,HTTPS默认使用443端口,HTTP使用80端口
- HTTPS=HTTP+加密+认证+完整性保护,较HTTP安全;
7.5 HTTPS真的很安全吗?
- 浏览器默认填充http://,请求需要进行跳转,有被劫持的风险;
- 可以使用HSTS(HTTP Strict Transport Security)优化;
八. Socket简介
8.1 Socket流程:
Socket是对TCP/IP协议的抽象,是操作系统对外开放的接口