浅谈网络基础架构

本文从网络请求的整个过程出发,详细介绍了URL解析、DNS解析、TCP连接建立,以及服务器处理请求的过程。接着,讨论了网络基础架构中的负载均衡,包括LB的分类(二层至七层)、LVS和Nginx在四层和七层负载均衡中的角色,以及各种负载均衡算法。最后,阐述了统一接入层AServer、VIPServer以及密钥中心在现代网络架构中的作用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

背景

由于平时倾向于关注业务层面的架构与技术,对网络基础架构上的知识了解不多,对其中很多知识点都是一知半解,甚至有些都没有听说过,比如AServer是什么?为什么会有AServer?它的原理是什么?等等,带着这些问题来浅析网络基础架构。

看一次网络请求

网络架构是为了服务网络请求的,那一次网络请求都发生了什么?先回顾一下OSI模型,自上向下分为:应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。
在这里插入图片描述

主要过程

先把主要过程呈现出来,然后再挨个看内部细节。
在这里插入图片描述

1.URL解析

一个合法的URL一定包含协议、域名等信息。如果我们经常访问一个网站,那么浏览器会缓存网站的相关信息。试着输入taobao,如果之前有访问过,那么浏览器会自动联想出 https://www.taobao.com。

2.DNS解析

DNS简单来说是将域名转为IP地址的映射服务,顺序返回通常选择第一个。

MAC查看DNS映射的命令是:cat /etc/resolv.conf

说DNS解析之前得先说下IP地址,它为互联网上的每一个网络、主机分配一个逻辑地址,正如每台电脑都有自己的IP地址一样,服务器也同样如此。

计算机在网络上进行通讯是基于TCP/IP协议的,只能识别如“114.114.114.114”之类的IP地址,并不认识域名,那为什么我们不直接通过IP地址来访问网络服务,减少一层DNS解析仿真速度不是更快吗?自己认为主要是两个原因:

  1. 域名更具备可读性,试想一下如果访问网站都需要输一串数字,那将是多么痛苦的事情。
  2. 域名提高了服务可用性,试想如果直接通过固定IP访问,一旦这个IP挂了,那服务将不可用,但是DNS可以根据探活机制动态更新IP列表,保证一定时间后故障IP会被下掉,客户端可以正常访问。

解析顺序

  1. 浏览器缓存
  2. 操作系统缓存
  3. 本地hosts文件缓存
  4. 路由器缓存
  5. ISP DNS (DNS服务提供商)
  6. 13个根域名服务器,.com -> .cn -> .net …

假设DNS服务器只有一个,那它将面临通信容量大、远距离网络延迟高、维护成本高、可靠性低等问题,所以DNS服务器采用分布式集群方式工作。

服务器层次划分

  1. 根服务器,根域名服务器是最高层次的域名服务器,所有的根域名服务器都知道所有顶级域名服务器的域名和ip。如果本地域名服务器没有缓存相应记录,首先会向根域名服务器发起请求。
  2. 顶级域名服务器,顶级域名服务器管理在该顶级域名服务器注册的所有二级域名,但受到DNS查询就会有相应应答。(可能是给出最后的结果或下一步应当找的域名服务器ip)
  3. 权威域名服务器,权威域名服务器是负责查询域名的解析设置,一般由域名解析服务商提供,权威域名服务器是直接对域名进行解析过程的。
  4. 本地域名服务器,每一个因特网服务提供ISP(电信联通移动)都可以拥有一个本地域名服务器。这种服务器有时也被称为默认域名服务器。本地域名服务器一般离用户较近,一般不超过几个路由的距离。如果要查询的IP同属一个本地ISP时即可直接返回结果地址ip。

域名的结构由标号序列组成,各标号之间用点隔开。类似于这样:“….三级域名.二级域名.顶级域名”。例如 https://www.taobao.com 中

  • 顶级域名:.com
  • 二级域名:taobao
  • 三级域名:www

3.建立TCP连接

HTTP请求为什么要用TCP协议建立连接?

HTTP协议并没有明确要求必须使用TCP协议作为运输层协议,但是因为HTTP协议对可靠性的的要求,默认HTTP是基于TCP协议的。若是使用UDP这种不可靠的、尽最大努力交付的运输层协议来实现HTTP的话,那么TCP协议的流量控制、可靠性保障机制等等功能就必须全部放到应用层来实现。

TCP 三次握手

在这里插入图片描述

seq(序号):TCP连接字节流中每一个字节都会有一个编号,而本字段的值指的是本报文段所发送数据部分第一个字节的序号。
ack(确认号):表示期望收到的下一个报文段数据部分的第一个字节的编号,编号为ack-1及以前的字节已经收到。
SYN:当本字段为1时,表示这是一个连接请求或者连接接受报文。
ACK:仅当本字段为1时,确认号才有效。

连接建立阶段:

  • 第一次握手:客户端的应用进程主动打开,并向服务端发出请求报文段。其首部中:SYN=1,seq=x。
  • 第二次握手:服务器应用进程被动打开。若同意客户端的请求,则发回确认报文,其首部中:SYN=1,ACK=1,ack=x+1,seq=y。
  • 第三次握手:客户端收到确认报文之后,通知上层应用进程连接已建立,并向服务器发出确认报文,其首部:ACK=1,ack=y+1。当服务器收到客户端的确认报文之后,也通知其上层应用进程连接已建立。

CLOSED:关闭状态、LISTEN:收听状态、SYN-SENT:同步已发送、SYN-RCVD:同步收到、ESTAB-LISHED:连接已建立

4.服务器处理请求

服务器处理请求场景比较多,这里只介绍一下常见的处理流程:

  1. 请求静态资源(html, css, js, png…),服务器可能通过NGINX直接将请求转发到静态资源服务器。
  2. API请求,请求到达服务器后可能会经历:反序列化,参数校验,用户鉴权,模型转换,信息填充,
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

森伯416

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值