网络部分整理

一.知识点部分 -极客时间

1.网络分层

• 只要在网络上跑的包，都是完整的。可以有下层而没有上层，但是绝对不能有上层无下层
• 封装与解封类似于方法调用的入栈和出栈

2.IFCONFIG：命令行

• Windows上为Ipconfig，linux中为Ifconfig

• ip addr add 1.1.1.1

3.DHCP与PXE

• PXE是由Intel设计的协议，它可以使计算机通过网络来启动。协议分为client端和server端，PXE client在bios中，当计算机引导的时候，BIOS将PXE client调入内存执行，并显示出命令菜单，经过用户选择之后，PXE client将放置在远端的os通过网络下载到本地运行。
• DHCP的request使用单播还是广播取决于DHCP offer包中broadcast位的设置值。该位置为0则单播发送，为1则广播发送

4.TCP和UDP的区别

• TCP提供可靠交付。通过TCP连接传输的数据，无差错，无丢失，不重复，并且按序到达。而UDP继承了IP包的特性，不保证不丢失，不保证按顺序到达

• TCP是面向连接的，UDP是无连接的(发送数据之前不需要建立连接

  )

  面向连接和无连接的区别：

  • 虚电路服务(面向连接)：首先建立连接，所有的数据包经过相同的路径，服务质量有较好的保证。使用虚电路号进行标记，易于实现拥塞控制，差错控制由子网负责
  • 数据包服务(面向无连接)：每一个数据包包含目的地址，数据路由相互独立；网络尽最大努力交付，但是不保证不丢失，不保证先后顺序，网络发生拥塞的时候，可能会将一些分组丢弃，很难实现拥塞控制。差错控制和流量控制由主机负责

• TCP是面向字节流的，发送的时候是一个流，没头没尾。IP协议是一个一个的包，而UDP继承了IP的特性，基于数据报的，一个一个的发与收

• TCP有拥塞控制，意识到丢包率严重或者是网络环境很差的时候，会对自己的情况进行调整

• TCP是有状态服务，出去之后会记住在哪，到哪了

• TCP只是支持点对点通信，UDP支持一对一，一对多，多对一，多对多

• TCP的首部开销(20字节)比UDP(8字节)要大

5.Socket相关

• • 在内核中，Socket是一个文件，对应的就有文件描述符。每一个进程都有一个数据结构task_struct，里面指向一个文件描述符数组，来列出这个进程打开的所有文件的文件描述符。文件描述符是一个整数，是这个数组的下标
  • 这个数组的内容是一个指针，指向内核中所有打开的文件的列表，在inode中，指向了Socket在内核中的Socket结构
  • 这个结构中，有发送队列和接收队列。这两个队列中保存的是缓存sf_buff，这个缓存中能够看到完整的包结构

• • epoll来监听是否有事件发生。其中epoll_create创建一个epoll对象，也是一个文件，对应一个文件描述符，同样对应着打开文件列表的一项。在这一项中有一个红黑树，在红黑树里面，要保存这个epoll要监听的所有socket
  • 当epoll_ctl添加一个socket的时候，其实是加入这个红黑树，同时红黑树里面的节点指向一个结构，将这个结构挂在被监听的socket的事件列表中。当一个socket来了一个事件的时候，可以从这个列表中得到epoll对象，并调用call back通知它
  • epoll是linux上的函数，windows中为iocp，如果想跨平台，要么使用兼容好的select，要不就对不同的平台使用不同的调用，kqueue iocp等

6.HTTP相关

• QUIC协议相关

  • 自定义连接机制：QUIC中以一个64位的ID来标志，而且UDP是无连接的，所以当IP或者端口变化的时候，只要是ID不变，就不需要重新建立连接
  • 自定义重传机制：任何一个序列号的包只发送一次，下一次就要加1了。使用offset来进行拼接与判断
  • 无阻塞的多路复用：同一个QUIC连接上可以创建多个stream
  • 自定义流量控制：不但在一个连接上控制窗口，还在一个连接中的每一个stream控制窗口(从offset[窗口的起始位置]到当前的stream所能容纳的最大缓存是真正的窗口大小)
  • 总体来说，QUIC通过基于UDP自定义的类似TCP的连接，重试，多路复用，流量控制技术，进一步提升性能

• HTTPS中对于端口和ip不加密，建立通信之后，后续的包就可以知道式服务器发来的了

• 各大CA机构的公钥都是默认安装在操作系统中的

• HTTP是怎么转化为HTTPS的？

7.HTTP DNS

• 自己搭建基于HTTP协议的DNS服务器集群，分布在多个地点和多个运营商。当客户端需要DNS解析的时候，直接通过HTTP协议进行请求这个服务器集群，得到就近的地址

• 在客户端的SDK中动态请求服务端，获取HTTPDNS服务器的IP列表，缓存到本地。随着不断地解析域名，SDK也会在本地缓存DNS域名解析的结果

8.云

首先虚拟机要有一张网卡，杜宇qumu-kvm来说，这是通过Linux上的一种TUN/TAP技术来实现的。

虚拟机是物理机上的跑着的一个软件。这个软件可以像其他应用打开文件一样，打开一个称为TUN/TAP的Char Dev。打开了这个字符设备文件之后，在物理机上就可以看到一张虚拟TAP网卡

tun/tap驱动将文件流再次转化为网络包，交给TCP/IP协议栈，最终从虚拟TAP网卡发出来，成为标准的网络包

• 在物理机上，应该有一个虚拟的交换机，在Linux上有命令brctl，可以创建虚拟网桥brctl addbr br0，创建出来之后，将虚拟网卡连接到虚拟网桥上

云中网络的特点

• 共享：桥接 NAT
• 互通：桥接 NAT
• 隔离：VLAN
• 灵活

9.容器

• 容器实现隔离的技术：

  • namespace，每个namespace中的应用看到的是不同的IP地址，用户空间，进程号
  • cgroup，也即指明每台机器都有很多CPU，内存，而一个应用只能用其中的一部分

10.RPC协议

• 对于微服务的架构，API需要一个API网关统一的管理。API网关有多种实现方式，用Nginx或者OpenResty结合Lua脚本是常用的方式。在Spring Cloud体系中，有个组件Zuul也是干这个的。
• 资源的状态应该在最底层的持久化层，一般会使用分布式数据库和elasticsearch
• 持久化层往往吞吐量无法达到系统应用所要求的，因此前面要有一层的缓存层，使用Redis或者memcached将请求拦截一道，不能让所有的请求都进入数据库
• Netty是一个高效的基于异步IO的网络传输框架

11.

二.面经题目整理

1.TCP部分

三次握手的一系列问题与解答

什么是三次握手？

第一次握手：client将SYN置1，随机生成一个初始序列号seq发送给server，进入SYN_SENT状态

第二次握手：Server收到Client的SYN=1之后，知道客户端请求建立连接，将自己的SYN置为1，ACK置为1，产生一个ack number=seq num+1，并随机产生一个自己的初始序列号，发送给客户端；进入SYN_RCVD状态

第三次握手：客户端检查seq number是否为序列号+1，ACK是否为1，检查正确之后将自己的ACK置为1，产生一个ack number=seq number +1，发送给服务器，进入established状态；服务器检查ACK为1和ack number为序列号+1之后，也进入established状态，完成三次握手，连接建立。

TCP连接建立可以是两次握手吗？

不可以，可能会出现失效的连接请求报文又传回到了服务器端。

client发出的第一个连接请求没有丢失，而是在某个网络节点长时间滞留了，以致于到连接释放以后的某个时间才到达server。本来这是一个失效的报文段，但是server会进行确认，同意建立连接

Tcp可以采用四次握手吗？

可以，但是会降低传输的效率

第三次握手的时候，如果客户端的ACK没有送到服务器会怎么样？

由于server没有收到ACK确认，因此会重发之前的SYN+ACK（默认重发五次，之后自动关闭连接）client收到之后hui重新传ACK给server

如果已经建立了连接，但是客户端出现了故障怎么办？

服务器每次收到一次客户端的请求都会重新复位一个计时器，时间通常为2小时，若两个小时还没有收到客户端的任何数据，服务器就会发送一个探测报文，以后每隔75秒发送一次。若连续发送10个探测报文仍然没有反应，服务器就认为是客户端发生了故障，接着就关闭连接。

初始序列号是什么？

TCP连接的一方A，随机选择一个32位的序列号作为发送数据的初始序列号

什么是四次挥手？

第一次挥手：client将FIN置为1，发送一个序列号seq给server，进入FIN_WAIT_1状态

第二次挥手：server收到FIN之后，发送一个ACK=1,ack number = 序列号+1，进入CLOSE_WAIT状态。此时客户端已经没有要发送的数据了，但是仍然可以接收服务器发来的数据

第三次挥手：server将FIN置为1，发送一个序列号给client，进入last_ack状态

第四次挥手：client收到服务器的FIN之后，进入TIME_WAIT状态，接着讲ACK置为1，发送一个ack number=序列号+1给服务器；服务器收到之后，确认ack之后变为closed状态，不再向客户端发送数据。客户端等待2*MSL（报文最大寿命）之后，也进入CLOSED状态。完成四次挥手。

为什么不能将服务器发送的ACK和FIN合并起来，变为三次挥手？

因为服务器收到客户端断开连接的请求的时候，可能还有数据没有发送完成，这个时候先回复ACK，表示接收到了断开连接的请求。等到数据发送完毕之后再发送FIN，断开服务器到客户端的数据传送

如果第二次挥手的时候服务器的ACK没有送到客户端，会怎么样？

客户端没有收到ACK确认，会重新发送FIN请求

客户端TIME_WAIT状态的意义是什么？

第四次挥手的时候，客户端发送给服务器的ACK可能丢失，time_wait状态就是用来重发可能丢失的ACK报文。如果server没有收到ACK，就会重发FIN，如果client在2*msl的时间之内收到了FIN，就会重新发送ACK并再次等待2MSL，防止server没有收到ACK而不断的重发FIN

TCP协议端口状态变化

TCP是如何实现流量控制的 ？

使用滑动窗口协议实现流量控制。防止发送方发送速率太快，接收方缓存区不够导致溢出。接收方会维护一个接收窗口 receiver window（窗口大小单位是字节），接受窗口的大小是根据自己的资源情况动态调整的，在返回 ACK 时将接受窗口大小放在 TCP 报文中的窗口字段告知发送方。发送窗口的大小不能超过接受窗口的大小，只有当发送方发送并收到确认之后，才能将发送窗口右移。

接受窗口为0会怎么样？

如果接收方没有能力接收数据，就会将接收窗口设置为0，这时发送方必须暂停发送数据，但是会启动一个持续计数器，到期之后发送一个大小为1字节的探测数据包以查看接收窗口状态。如果接收方可以接受则在返回的报文中更新接收数据的大小，回复数据传送。

拥塞控制：

• 慢启动：刚开始发送数据时，先把拥塞窗口（congestion window）设置为一个最大报文段 MSS 的数值，每收到一个新的确认报文之后，就把拥塞窗口加 1 个 MSS。这样每经过一个传输轮次（或者说是每经过一个往返时间 RTT），拥塞窗口的大小就会加倍

• 拥塞避免：当拥塞窗口的大小达到慢开始门限 (slow start threshold) 时，开始执行拥塞避免算法，拥塞窗口大小不再指数增加，而是线性增加，即每经过一个传输轮次只增加 1MSS.

• 无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限 ssthresh 设置为出现拥塞时的发送方窗口值的一半（但不能小于 2）。然后把拥塞窗口 cwnd 重新设置为 1，执行慢开始算法。（这是不使用快重传的情况）

• 快重传：快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

• 快恢复：当发送方连续收到三个重复确认时，就把慢开始门限减半，然后执行拥塞避免算法。不执行慢开始算法的原因：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方认为现在网络可能没有出现拥塞。

• 慢开始：出现拥塞之后从1开始增加

TCP如何保证传输的可靠性：

• 数据包校验
• 对失序的数据包重新排序
• 丢弃重复数据
• 应答机制：接收方收到数据之后，会发送一个确
• 超时重发：发送方发出数据之后，启动一个定时器，超时没有收到接收方的确认，则重新发送这个数据
• 流量控制：确保接收端能够接受发送方的数据而不会缓冲区溢出

TCP粘包：

• 发送方：默认使用 Nagle 算法（主要作用：减少网络中报文段的数量），将多次间隔较小、数据量较小的数据，合并成一个数据量大的数据块，进行发送；
• 接收方：TCP 将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。如果 TCP 接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

怎么解决？

• 发送方：关闭Nagle算法
• 接收方：在应用层进行处理。将所有的数据全部读完之后再进行分组。分组可以通过规定开始符合结束符的方法；也可以在每组数据前加上数据长度

HTTPS的连接过程：

• 客户端向服务器发送请求，同时发送客户端支持的一套加密规则（包括对称加密、非对称加密、摘要算法）；
• 服务器从中选出一组加密算法与 HASH 算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥（用于非对称加密），以及证书的颁发机构等信息（证书中的私钥只能用于服务器端进行解密）；
• 客户端验证服务器的合法性，包括：证书是否过期，CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的 “发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配；
• 如果证书受信任，或者用户接收了不受信任的证书，浏览器会生成一个随机密钥（用于对称算法），并用服务器提供的公钥加密（采用非对称算法对密钥加密）；使用 Hash 算法对握手消息进行摘要计算，并对摘要使用之前产生的密钥加密（对称算法）；将加密后的随机密钥和摘要一起发送给服务器；
• 服务器使用自己的私钥解密，得到对称加密的密钥，用这个密钥解密出 Hash 摘要值，并验证握手消息是否一致；如果一致，服务器使用对称加密的密钥加密握手消息发给浏览器；
• 浏览器解密并验证摘要，若一致，则握手结束。之后的数据传送都使用对称加密的密钥进行加密

输入www.baidu.com之后怎么变为https://www.baidu.com?

• 原始的302跳转，服务器将所有的HTTP流量跳转到HTTPS，但是可能会受到中间人的劫持
• 引入HSTS机制，用户浏览器在访问站点的时候强制使用HTTPS

对称加密和非对称加密：

• 对称算法：加解密使用相同的密钥，例如DES
• 非对称加密：公钥加密私钥解密，例如RSA

区别：

• 对称加密速度快，适合于大量数据的加密
• 非对称加密安全性更高

数字签名，报文摘要的原理：

发送着A用私钥进行签名，接收者使用公钥验证签名。因为除了A之外其他人没有私钥，所以B相信签名是来自A。A不能抵赖，B也buneng伪造报文

算法：MD5,SHA

GET和POST的区别：

• GET是幂等的，即多次读取同一个资源，总是得到相同的数据
• GET一般用于从服务器获取资源，而POST可能改变服务器的资源
• 请求形式上：GET请求的数据在URL之后，在HTTP请求头中；而POST请求的数据在请求体重
• 安全性：GET请求可以被缓存，收藏，保留到历史纪录。而POST的参数不会被保存，安全性较高
• GET只允许ASCII码，POST对数据类型没有要求，也允许二进制数据
• GET的长度有限制(操作系统或者是浏览器，而POST数据大小无所谓)

Session和Cookie的区别：

Session是服务器保持状态的方案，Cookie是客户端保持状态的方案

Cookie保存在客户端本地，客户端请求服务器的时候会将Cookie一起提交。Session保存在服务端，通过检索sessionID来查看状态。

保存SessionID可以使用cookie，如果禁用了cookie，可以使用URL重写机制(将会话ID保存在URL中)

RIP算法是什么？

• 每个路由器维护一张表，记录该路由器到其它网络的” 跳数 “，路由器到与其直接连接的网络的跳数是 1，每多经过一个路由器跳数就加 1；更新该表时和相邻路由器交换路由信息；路由器允许一个路径最多包含 15 个路由器，如果跳数为 16，则不可达。交付数据报时优先选取距离最短的路径。

2.其他协议部分