2022-08-08 11:24 云南大学 Java

关注

计算机网络常见面试题总结

OSI七层和TCP/IP四层的区别和关系

OSI七层：
1. 应用层: 定义应用进程之间的交互和通信规则。HTTP, FTP, SMTP, POP3; 网关
2. 表示层: 信息的语法语义以及它们的关联，如加解密、转换翻译、压缩解压缩
3. 会话层: 不同机器是那个的用户之间建立和管理会话。SSL, TLS, RPC; 网关
4. 传输层: 接受上层数据，必要时把数据进行分割，并把这些数据交给网络层，同时保证消息能够到达对端，负责向两台主机进程之间的通信提供通用的数据传输服务。TCP, UDP; 网关
5. 网络层: 控制子网的运行，选择合适的网络路由和交换节点，确保数据及时传送，如逻辑编址、分组传输、路由选择。IPv4, IPv6; 路由器
6. 数据链路层: 物理寻址，同时将原始比特流转变为逻辑传输线路。PPP, ARP, RARP; 网桥、交换机
7. 物理层: 机械、电子、定时接口通道上的原始比特流传输。IEEE; 网线、网卡
TCP/IP四层
1. 应用层
2. 传输层
3. 网络层
4. 网络接口层

ARP协议

将ip地址转换为mac地址。

查询自己的arp缓存列表
缓存列表中没有，则发送一个目标地址为12个f的arp广播
主机收到广播后会检查自己的ip地址和arp请求的ip是否一致，一致将该映射缓存到自己的arp缓存中并做出响应
arp收到响应后缓存该映射，没有收到响应则查询失败

在浏览器输入www.baidu.com后发生

DNS解析
建立TCP连接
发送HTTP请求
服务端响应HTTP请求，得到html代码
浏览器解析代码，并请求对应的资源css, js, 图片
浏览器对页面进行渲染后展示给用户
连接结束

DNS寻址过程

先检查本地hosts文件是否有对应的映射，有就用
hosts中没有，查找本地DNS解析器缓存中是否有对应的映射，有就用
找TCP/IP设置的首选DNS服务器(本地DNS服务器)，本地DNS服务器收到查询时，如果域名包含在本地配置区域资源中就用，此解析具有权威性
如果此域名不由本地DNS服务器解析但该映射关系已被缓存，那么也使用但此解析不具有权威性
看是否启用转发模式，未启用则会递归进行查找，先发给根域名服务器 . ，得到.com的地址，之后去找.com，如果其不能解析，那么会返回baidu.com的地址，再去找baidu.com，重复操作直至找到www.baidu.com的主机
启用转发模式则会把此请求转移到其上级进行DNS解析，上级解析不了就会继续根据是否启用转发模式把域名交给上级或者根进行解析
最后得到的结果都是发送给本地DNS服务器，再由其发送给客户机

DNS缓存

浏览器缓存(chrome:://dns/)、系统缓存(hosts)、路由器缓存、IPS服务器缓存、根域名服务器缓存、顶级域名服务器缓存、住域名服务器缓存

Web性能优化技术

DNS查询优化
客户端缓存
优化TCP连接
避免重定向
网络边缘的缓存
条件缓存
压缩和代码极简化
图片优化

网络安全

XSS攻击以及CSRF攻击。

XSS攻击：跨站脚本攻击，在web页面中嵌入恶意script代码，浏览页面时脚本代码会被执行
CSRF攻击：通过伪装来自受信任用户的请求来利用受信任的网站

HTTP

http1 2 的区别

HTTP1.1

持久化连接：一个网页打开后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已建立的连接（有一个保持时间）
错误响应状态码：增加了24个错误响应状态码(409请求的资源于当前的资源状态发生冲突，410服务器上的某个资源被永久删除)
请求管道化
增加缓存处理(Entity tag, if-Unmodified-Since, if-Match, if-None-Match)
增加host字段、支持断点传输(range头域能够节约带宽)

HTTP2.0

二进制分帧：通信的基本单位为帧
多路复用：允许单一连接发起多重请求-响应信息，但对同一域名下有数量限制
首部压缩
服务器推送：一条请求可以获得多条响应

HTTP和HTTPs的区别

HTTPs需要CA证书，一般需要收费
HTTP信息明文传送，HTTPs信息基于SSL加密传输
HTTP默认端口80，HTTPs默认端口443
HTTP连接简单，无状态，HTTPs课进行加密传输、身份认证，安全

HTTPs协议数据传输流程

浏览器将支持的加密算法信息发送给服务器
服务器选择一套浏览器支持的加密算法，将验证身份的信息以证书的形式回发给浏览器
浏览器收到证书后验证其合法性，并结合证书公钥加密信息发送给服务器
服务器用私钥解密信息，验证哈希，加密响应消息回发浏览器
浏览器解密信息并进行验证

HTTP常见响应状态码

1xx: 请求已被接受，正在处理
2xx: 请求被成功处理，200正常处理，204请求处理成功但没有资源返回给客户端，206范围请求
3xx: 请求重定向，需要进一步处理，301永久302临时304缓存
4xx: 客户端错误，400请求有语法错误，401发送的请求需要有通过HTTP认知的认证信息，403请求被拒绝，404找不到页面
5xx: 服务端错误，500服务器内部错误，503服务暂时不可用

GET与POST区别

GET用于获取资源，不会引起资源改变，POST用于创建资源，会引起资源改变
GET请求幂等，POST请求不幂等
GET请求参数附在URL后面，POST请求参数在请求体中
GET请求参数有长度限制(受限于URL长度)，POST没有
POST相对于GET更安全
GET能被缓存，POST不能
GET只接受ascii格式参数，POST无限制

Session和Cookie的区别

session：通过服务器记录用户的状态，cookie：保存用户信息

Session在服务端，Cookie在客户端
Session可以存任意Java对象，Cookie只能是字符串
Session无大小限制，但由于需要消耗服务器资源，因此一般只存重要数据；Cookie上限4k大小，一个站点在浏览器上最多保存20个
Session无法跨域，即便是同一父域名下的子域名都不可以；Cookie可以跨域
Session依赖session_id，而session_id存在cookie中，如果浏览器禁用了cookie，session也会失效，解决办法，将session_id拼接到url中
用户验证一般会用session

TCP/UDP

RTT和RTO

RTT：发送一个数据包到收到对应ACK所话费的时间
RTO：重传时间间隔，根据RTT计算，经过RTO未收到对方的回应将重新发送该数据包

TCP和UDP的区别

TCP	UDP
是否连接	面向连接	无连接
是否可靠	可靠	不可靠
连接对象的个数	一对一	一对一、一对多、多对一、多对多
传输方式	字节流	数据报文
首部开销	最小20字节，最大60	开销小，仅8字节
传输效率	慢	快
所需资源	多	少
适用场景	要求可靠传输的应用	实时应用

基于TCP和UDP的协议

TCP: HTTP, HTTPs, FTP, POP3, SMTP, Telent(远程登录协议), SSH(安全外壳协议)
UDP: DHCP(动态主机配置协议), NTP(网络时间协议), BOOTP(引导程序协议), DNS

TCP如何实现消息可靠传输

校验和、序列号、确认应答、超时重传、连接管理、流量控制、拥塞控制。

应用数据被分割为TCP认为最合适发送的数据块
TCP给每一个包进行编号，接受方对包进行排序，把有序数据传送给应用层
校验和：发送的数据段被当作16位的整数，把这些数相加，溢出位补在最后，取反得到校验和。发送方在发送数据前计算校验和并将该字段填充在首部，接收方得到数据后重新计算校验和并比较，如果校验和有差错，那么会丢弃此报文段并不确认收到
序列号：对数据进行编号，即seq字段，可以用于去重、确认应答、排序。
确认应答：接受方接收报文后能发送ACK报文，其中的确认序列号ack告诉发送方下次从哪个位置传。
超时重传：发送方在发送数据之后，没有收到ACK报文，那么会对数据进行重传。
连接管理：三次握手、四次挥手。
流量控制：防止发送方发送数据过快导致接受方来不急接受，大量数据丢包，接收方在ACK报文中将自己的可用窗口大小放在窗口字段中，即可变大小的滑动窗口协议。
拥塞控制：拥塞控制算法。
1. 慢开始：初始时不知道网络情况，cwnd值为1，每经过一个传播轮次，cwnd翻倍
2. 拥塞避免：每经过一个往返时间RTT，cwnd加一
3. 快重传与快恢复(FRR)：快重传是收到三个重复的ACK就假定数据段丢失，那么重传丢失的数据段；快恢复则是发送方收到n(n >= 3)个相同的ACK确认后，将拥塞阈值减半，将拥塞窗口设置为阈值 + n，直到收到了新的ACK后再将拥塞窗口重置为阈值大小
ARQ协议：每发完一个分组就停止发送，等待对方确认，收到确认后发送下一个分组

流量控制何时会死锁，如何避免

何时会死锁：发送方收到接受方窗口为0的应答便会停止发送，等待接受方的下一个窗口不为0的应答，那么若是这个窗口不为0的应答在传输过程中丢失，那么发送方就会一直等待下去，接受方会认为发送方已经接收到了这个应答，就会等待发送方发送新的数据，这样双方相互等待，形成死锁。
如何避免：发送方在收到窗口为0的应答后会启动一个计时器，时间一到便会主动发送报文询问接受着的窗口大小，为0则重置计时器并继续等待，没收到表示丢失了，此时计时器重置并且重新发送窗口探测报文

ARQ协议

停止等待ARQ: 发完了一个分组就等待ACK，超时还没有收到ACK就重新发送，收到重复分组就丢弃，但还需要发送确认.
1. 正常情况：发送、接受、发送，，，
2. 出现差错：发送一个分组后需要设置超时计时器，重传时间大于平均往返时间(自动重传ARQ)
3. 确认丢失和确认迟到：
  - 确认丢失：确认消息丢失了，即发送方发送了数据，接收方收到数据并发送确认消息，但该消息丢失了，那么发送方因为没有接收到确认消息，因此重传数据，接收方此时做两件事，一是丢弃此数据(因为之前已经发来过了)，二是发送确认消息(表示已经收到了这个分组)
  - 确认迟到：确认消息在传输中迟到了，但是并没有丢失。即发送方发送数据，接收方收到数据并发送确认消息，但此消息迟到了，那么发送方因为没有接收到确认消息，因此重传数据，之后接受方继续发送确认消息(一共发了两个)，那么接受方会丢弃后一个数据包，发送方会丢弃后一个确认包
连续ARQ: 发送方发送窗口中的分组可以连续发送而无需等待确认，接收方采用累计确认，对按序到达的最后一个分组发送确认，失败时Go-Back-N。

TCP协议如何提高传输效率

滑动窗口、快重传、延迟应答、捎带应答。

滑动窗口：一次发送多条数据，设置窗口大小为无须等待应答而可以继续发送数据的最大值，即接收方消息缓冲中的剩余值。
快重传：丢包时需要对数据进行重传，那么可能出现两种情况的包丢失，第一是发送方的数据包丢失，那么发送方此时会接收到多个相同的ACK，收到三个ACK时会立即重传对应的数据包，第二种是接收方的ACK报文丢失，那么此时不影响，不需要丢包，因为可以通过后续的ACK报文进行确认。
延迟应答：接受方消费速度比较快时，如果稍微延迟应答时间，那么接收方的窗口中的部分数据可能已经被消费了，那么这时的窗口值会变大，下次发送方也能发送更多的数据。
捎带应答。

TCP拥塞控制

慢启动、拥塞避免、快速重传、快速恢复

三次握手和四次挥手

三次握手

客户端发送SYN = 1, seq = m，不包含数据的报文，客户端进入SYN-SEND状态
服务端发送SYN = 1, ACK = 1, seq = n, ack = m + 1，不包含数据的报文，服务端进入SYN-RECV状态
客户端再发送ACK = 1, seq = m + 1, ack = n + 1，不包含数据的报文，进入ESTABLISHED状态，服务端在收到此报文后也进入ESTABLISHED状态

SYN Flood隐患以及解决措施

原因：
1. 服务端收到客户端的SYN，回复SYN-ACK时未收到ACK确认
2. 服务端不断重试至超时，Linux默认等待63s才断开连接
隐患：

恶意程序向服务器发送SYN数据包，然后下线，服务器需要等待63s才能断开连接，攻击者就可以将服务器的SYN队列耗尽导致正常连接无法建立
防护措施：
1. SYN队列满后，通过tcp_syncookies参数会发SYN Cookie
2. 若是正常连接则客户端会回发SYN Cookie，直接建立连接

四次挥手

客户端关闭连接，发送FIN = 1, ack = m，不包含数据的报文，进入FIN-WAIT-1状态
服务端发送ACK = 1, seq = v, ack = m + 1，通知主机应用程序关闭，进入CLOSE-WAIT状态(可能服务端还要继续往客户端发数据)，客户端在接收到此报文后进入FIN-WAIT-2状态
服务端在将数据传输完之后，关闭连接，发送FIN = 1, ACK = 1, seq = n, ack = m + 1的报文，进入LAST-ACK状态
客户端发送ACK = 1, seq = m + 1, ack = n + 1的报文，进入TIME-WAIT状态

为什么需要三次握手

第一次确保客户端啥也不知道，服务端知道客户端发送正常、服务端接受正常，第二次客户端知道客户端发送接受正常、服务端发送接收正常，第三次服务端也知道客户端发送接受正常、服务端发送接收正常。
如果两次握手，那么只要服务器发送确认包都会建立连接，如果此时客户端不响应该链接，那么就会浪费资源，三次握手，服务端没有收到客户端的再次确认，就会知道客户端没有真正要求建立请求，那么就不会浪费资源(考虑场景，第一次握手，网络传输较慢，客户端以为丢包，再次发了第一次握手，之后服务端对第二个包进行了响应，之后第一个包终于传到了，那么此时建立第二次握手，如果握手只有两次，那么此时服务端资源被浪费，如果是三次握手，客户端不会响应后到的第一次的请求，不会进行第三次握手的传输，服务端资源不会被浪费)

为什么需要四次挥手

任何一方都可以在数据传送结束后发出释放连接的通知，待对方确认后进入半关闭状态，另一方也没有数据需要发送时，再发出连接释放通知，对方确认后完全关闭连接

为什么客户端最后要等待2MSL

MSL: 最长报文段寿命

保证最后一个ACK报文能够到达服务器，假如最后一次的报文丢包了，那么服务端会认为是客户端没有收到第三次挥手的包，然后重发此包，那么在客户端等待2MSL的时候就能接收到这个重发的包，并给出回应的第四次挥手的包，并重启2MSL计时器
防止已经失效的连接请求报文段出现在本连接中(等待的2MSL时间中，之前失效的连接请求会全部从网络中消失，防止之前的旧连接请求对新连接造成影响)