🚩NetWork - 计算机网络
都将会
收录于 InterviewOSI 七层模型？
应用层：为计算机用户提供服务 HTTP
七层负载均衡：【Nginx 的 server/udp】读取报文数据部分，根据数据内容做出负载均衡决策，更灵活
表示层：数据加密解密
会话层：管理应用程序之间的会话
传输层：通用的数据传输服务 TCP/UDP
四层负载均衡：【Nginx 的 upstream】通过 ip+port，转发到真实服务器，性能好
网络层：路由和寻址
数据链路层：帧编码和差错校验
VLAN：逻辑划分数据，将一个物理局域网划分为多个虚拟局域网，每个 VLAN 都是一个独立的广播域。
物理层：透明传输比特流
TCP/IP 四层模型？
- 应用层（Application Layer）：提供应用程序之间的通信和数据交换，包括DNS（基于 UDP）、HTTP、FTP、SMTP等协议。
- 传输层（Transport Layer）：负责提供端到端的数据传输，包括TCP（传输控制协议）和UDP（用户数据报协议）。
- 网络层（Network Layer）：处理网络间的数据传输和路径选择，包括IP（网际协议）和ICMP（Internet控制消息协议）。
- 链路层（Link Layer）：负责物理网络之间的数据传输，包括以太网、Wi-Fi等。
请求转发（Forward）和重定向（Redirect）的区别？
转发（Forward）：
- 服务器行为
- 地址栏路径不变
- 服务器收到请求后，直接访问目标地址的URL，把那个URL的响应内容返回给浏览器
- 事情未做完，数据共享
- 如：有些网页转发天气预报信息
重定向（Redirect）：
- 客户端行为
- 地址栏路径改变
- 服务端根据逻辑,发送一个状态码,告诉浏览器重新去请求那个地址，所以地址栏显示的是新的URL
- 事情已做完，数据不共享
- 如：用户未登录，重定向到登录页面。
为什么要三次握手？
为什么不能两次？
为了防止已失效的连接请求报文段突然又传送到了服务端，导致资源建立无意义的连接。 假设不采用“三次握手”，那么只要server对一个早已失效的报文段发出确认，新的连接就建立了。但此时的client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样server的很多资源就白白浪费掉了。采用三次握手的话，server由于收不到确认的时候，就知道client并没有要求建立连接，这就有效的防止了服务器端的一直等待而浪费资源。
为什么不用四次？
因为握手的目的是为了证明服务端和客户端都具有接收和发送数据的能力，在第二次握手时，服务端发送的ack=seq+1证明了客户端的网络联通性，并且发送了自己的seq，只需要等待第三次握手的ack=seq+1就能证明服务端的网络联通性，可以三次做到的，就不用第四次了，节约资源。
HTTPS 的原理？
HTTPS和HTTP的区别？
- HTTPS 增加了传输层安全协议（Transport Layer Security，TLS）
- 端口不同：http 是 80 端口，https 是 443 端口
- 使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，可以防止”中间人“攻击。一般免费证书较少，因而需要一定费用。
两个阶段？
分成证书验证阶段（非对称加密）和数据传输阶段（对称加密，保证效率）
使用 HTTPS 会被抓包吗？
会，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。
为什么 HTTPS 协议需要 9 倍时延才能完成通信？
HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。
- TCP 协议需要通过三次握手建立 TCP 连接保证通信的可靠性（1.5-RTT）；
- TLS 协议会在 TCP 协议之上通过四次握手建立 TLS 连接保证通信的安全性（2-RTT）；
- HTTP 协议会在 TCP 和 TLS 上通过一次往返发送请求并接收响应（1-RTT）；
浏览器输入url之后发生了什么？
- 通过 DNS 将域名解析为ip地址
- 通过ip和端口号向服务器发送GET请求
- 如果配置了Nginx，可能会发生负载均衡，转发到其他ip地址
- 传输层进行TCP三次握手
- 获得响应数据，加上js代码渲染页面
- 传输完成后四次挥手断开连接
get请求和post请求的区别？
HTTP本质上都依赖 TCP/IP 连接，GET一般用于获取/查询资源信息，而POST一般用于更新资源信息，在表现上有所区别：
- GET产生一个TCP数据包：浏览器会把header和data一并发送出去，服务器响应200（返回数据）
- 为什么删除不能用get请求？因为通过历史记录或书签，很容易在没有意识到的情况下重新输入GET请求。如果GET是破坏性的，可能会导致意外的数据丢失。
- POST产生两个TCP数据包
- 浏览器先发送header，服务器响应100 continue
- 浏览器再发送data，服务器响应200 ok（返回数据）。
你了解 Java 应用开发中的注入攻击吗？
- SQL注入：or 1=1
- 操作系统命令注入：Java 语言提供了类似 Runtime.exec(…) 的 API
- XML 注入攻击：Java 核心类库提供了全面的 XML 处理、转换等各种 API，而 XML 自身是可以包含动态内容的
如何保证安全：
- 运行时安全机制。可以简单认为，就是限制 Java 运行时的行为，不要做越权或者不靠谱的事情。从原则上来说，Java 的 GC 等资源回收管理机制，都可以看作是运行时安全的一部分，如果相应机制失效，就会导致 JVM 出现 OOM 等错误，可看作是另类的拒绝服务。
- Java 提供的安全框架 API，这是构建安全通信等应用的基础。加密算法、HTTPS
- JDK 集成的各种安全工具。尽量使用较新版本的 JDK，并使用推荐的安全机制和标准
公钥和私钥？
假设 (public key,private key) 代表一个账户
- 通信：拿对方的公钥加密，发送信息，对方收到后拿自己的密钥解密。
- 签名：拿自己的密钥加密，其他人拿自己的公钥验证。
TCP 协议
TCP 头部一般包含以下字段：
- 源端口号（Source Port）：16 位，用于标识发送端口号。
- 目的端口号（Destination Port）：16 位，用于标识接收端口号。
- 序列号（Sequence Number）：32 位，用于标识该数据段的序列号，用于保证数据的有序传输。
- 确认号（Acknowledgment Number）：32 位，用于标识期望接收的下一个数据段的序列号。
- 数据偏移（Data Offset）：4 位，用于标识 TCP 头部的长度，以 4 字节为单位。
- 保留（Reserved）：6 位，保留未使用。
- 标志位（Flags）：6 位，用于标识 TCP 的状态，包括 URG、ACK、PSH、RST、SYN、FIN 等。
- 窗口大小（Window Size）：16 位，用于标识接收方能够接收的数据量大小。
- 校验和（Checksum）：16 位，用于检验 TCP 头部和数据的正确性。
- 紧急指针（Urgent Pointer）：16 位，用于标识 TCP 数据中的紧急数据的位置。
- 选项（Options）：可选，用于传输一些额外的信息，例如最大段大小（MSS）、时间戳（Timestamp）等。
流量控制和拥塞控制的区别？
TCP 流量控制和拥塞控制的最大区别在于它们的控制对象和目的不同。
- TCP 流量控制的控制对象是接收方，其目的是控制发送方向接收方发送数据的速率，以避免接收方缓冲区溢出。TCP 流量控制是通过滑动窗口机制，动态调整窗口大小来控制发送方的发送速率，以保证接收方可以顺利接收数据。
- TCP 拥塞控制的控制对象是网络，其目的是控制发送方发送数据的速率，以避免网络拥塞和数据丢失。TCP 拥塞控制是通过检测网络拥塞情况，动态调整拥塞窗口大小来控制发送方的发送速率，以保证网络的可靠性和稳定性。
因此，TCP 流量控制和拥塞控制的最大区别在于它们的控制对象和目的不同。TCP 流量控制是为了保证接收方的数据接收效率和可靠性，而 TCP 拥塞控制是为了保证网络的可靠性和稳定性。
大量的CLOSE_WAIT、TIME_WAIT状态
- CLOSE_WAIT：客户端关闭连接之后，服务器没有发送 ACK 信号（没有调用 close 函数关闭连接），一直占用资源。
- e.g. 创建数据库连接后没有关闭连接。
- TIME_WAIT：原本的作用是保证被动关闭连接方能被正确关闭。在长连接的应用中，根据大多数 Web 服务的实现，不管哪一方禁用了 HTTP Keep-Alive，都是由服务端主动关闭连接，那么此时服务端上就会出现 TIME_WAIT 状态的连接。