看Linux网管员如何进行网络性能优化
IT系统的性能永远是企业IT人员关注热点，而随着Linux系统应用的增多，一些应用方面的问题也随之增多，本文将为你们介绍Linux内核下如何进行网络性能优化。css
首先咱们先看下网络的行为，能够简单划分为3条路径：发送路径、转发路径、接收路径，而网络性能的优化则可基于这3条路径来考虑。本文集中于发送路径和接收路径上的优化方法分析，其中的NAPI本质上是接收路径上的优化，但由于它在Linux的内核出现时间较早，而它也是后续出现的各类优化方法的基础，因此将其单独分析。api
最为基本的 NAPI数组
NAPI 的核心在于：在一个繁忙网络，每次有网络数据包到达时，不须要都引起中断，由于高频率的中断可能会影响系统的总体效率，假象一个场景，咱们此时使用标准的 100M 网卡，可能实际达到的接收速率为 80MBits/s，而此时数据包平均长度为 1500Bytes，则每秒产生的中断数目为：性能优化
80M bits/s / (8 Bits/Byte * 1500 Byte) = 6667 个中断 /s网络
每秒 6667 个中断，对于系统是个很大的压力，此时其实能够转为使用轮询 (polling) 来处理，而不是中断;但轮询在网络流量较小的时没有效率，所以低流量时，基于中断的方式则比较合适，这就是 NAPI 出现的缘由，在低流量时候使用中断接收数据包，而在高流量时候则使用基于轮询的方式接收。框架
如今内核中 NIC 基本上已经所有支持 NAPI 功能，由前面的叙述可知，NAPI 适合处理高速率数据包的处理，而带来的好处则是：socket
一、中断缓和 (Interrupt mitigation)，由上面的例子能够看到，在高流量下，网卡产生的中断可能达到每秒几千次，而若是每次中断都须要系统来处理，是一个很大的压力，而 NAPI 使用轮询时是禁止了网卡的接收中断的，这样会减少系统处理中断的压力；tcp
二、数据包节流 (Packet throttling)，NAPI 以前的 Linux NIC 驱动总在接收到数据包以后产生一个 IRQ，接着在中断服务例程里将这个 skb 加入本地的 softnet，而后触发本地 NET_RX_SOFTIRQ 软中断后续处理。若是包速太高，由于 IRQ 的优先级高于 SoftIRQ，致使系统的大部分资源都在响应中断，但 softnet 的队列大小有限，接收到的超额数据包也只能丢掉，因此这时这个模型是在用宝贵的系统资源作无用功。而 NAPI 则在这样的状况下，直接把包丢掉，不会继续将须要丢掉的数据包扔给内核去处理，这样，网卡将须要丢掉的数据包尽量的早丢弃掉，内核将不可见须要丢掉的数据包，这样也减小了内核的压力。ide
对NAPI 的使用，通常包括如下的几个步骤：函数
一、在中断处理函数中，先禁止接收中断，且告诉网络子系统，将以轮询方式快速收包，其中禁止接收中断彻底由硬件功能决定，而告诉内核将以轮询方式处理包则是使用函数 netif_rx_schedule()，也可使用下面的方式，其中的 netif_rx_schedule_prep 是为了断定如今是否已经进入了轮询模式：
将网卡预约为轮询模式
或者
if (netif_rx_schedule_prep(dev))
__netif_rx_schedule(dev);
二、在驱动中建立轮询函数，它的工做是从网卡获取数据包并将其送入到网络子系统，其原型是：
NAPI 的轮询方法
这里的轮询函数用于在将网卡切换为轮询模式以后，用 poll() 方法处理接收队列中的数据包，如队列为空，则从新切换为中断模式。切换回中断模式须要先关闭轮询模式，使用的是函数 netif_rx_complete ()，接着开启网卡接收中断 .。
退出轮询模式
三、在驱动中建立轮询函数，须要和实际的网络设备 struct net_device 关联起来，这通常在网卡的初始化时候完成，示例代码以下：
设置网卡支持轮询模式
dev -> weight = 64 ;
里面另一个字段为权重 (weight)，该值并无一个很是严格的要求，其实是个经验数据，通常 10Mb 的网卡，咱们设置为 16，而更快的网卡，咱们则设置为 64。
NAPI的一些相关Interface
下面是 NAPI 功能的一些接口，在前面都基本有涉及，咱们简单看看：
netif_rx_schedule(dev)
在网卡的中断处理函数中调用，用于将网卡的接收模式切换为轮询
netif_rx_schedule_prep(dev)
在网卡是 Up 且运行状态时，将该网卡设置为准备将其加入到轮询列表的状态，能够将该函数看作是 netif_rx_schedule(dev) 的前半部分
__netif_rx_schedule(dev)
将设备加入轮询列表，前提是须要 netif_schedule_prep(dev) 函数已经返回了 1
__netif_rx_schedule_prep(dev)
与 netif_rx_schedule_prep(dev) 类似，可是没有判断网卡设备是否 Up 及运行，不建议使用
netif_rx_complete(dev)
用于将网卡接口从轮询列表中移除，通常在轮询函数完成以后调用该函数。
__netif_rx_complete(dev)
Newer newer NAPI
其实以前的 NAPI(New API) 这样的命名已经有点让人忍俊不由了，可见 Linux 的内核极客们对名字的掌控，比对代码的掌控差太多，因而乎，连续的两次对 NAPI 的重构，被戏称为 Newer newer NAPI 了。
与 netif_rx_complete(dev) 相似，可是须要确保本地中断被禁止
Newer newer NAPI
在最初实现的 NAPI 中，有 2 个字段在结构体 net_device 中，分别为轮询函数 poll() 和权重 weight，而所谓的 Newer newer NAPI，是在 2.6.24 版内核以后，对原有的 NAPI 实现的几回重构，其核心是将 NAPI 相关功能和 net_device 分离，这样减小了耦合，代码更加的灵活，由于 NAPI 的相关信息已经从特定的网络设备剥离了，再也不是之前的一对一的关系了。例若有些网络适配器，可能提供了多个 port，但全部的 port 倒是共用同一个接受数据包的中断，这时候，分离的 NAPI 信息只用存一份，同时被全部的 port 来共享，这样，代码框架上更好地适应了真实的硬件能力。Newer newer NAPI 的中心结构体是napi_struct:
NAPI 结构体
* Structure for NAPI scheduling similar to tasklet but with weighting
*/
struct napi_struct {
/* The poll_list must only be managed by the entity which
* changes the state of the NAPI_STATE_SCHED bit. This means
* whoever atomically sets that bit can add this napi_struct
* to the per - cpu poll_list, and whoever clears that bit
* can remove from the list right before clearing the bit.
*/
struct list_head poll_list;
unsigned long state;
int weight;
int ( * poll)(struct napi_struct * , int );
#ifdef CONFIG_NETPOLL
spinlock_t poll_lock;
int poll_owner;
#endif
unsigned int gro_count;
struct net_device * dev;
struct list_head dev_list;
struct sk_buff * gro_list;
struct sk_buff * skb;
};
熟悉老的 NAPI 接口实现的话，里面的字段 poll_list、state、weight、poll、dev、没什么好说的，gro_count 和 gro_list 会在后面讲述 GRO 时候会讲述。须要注意的是，与以前的 NAPI 实现的最大的区别是该结构体再也不是 net_device 的一部分，事实上，如今但愿网卡驱动本身单独分配与管理 napi 实例，一般将其放在了网卡驱动的私有信息，这样最主要的好处在于，若是驱动愿意，能够建立多个 napi_struct，由于如今愈来愈多的硬件已经开始支持多接收队列 (multiple receive queues)，这样，多个 napi_struct 的实现使得多队列的使用也更加的有效。
与最初的 NAPI 相比较，轮询函数的注册有些变化，如今使用的新接口是：
int ( * poll)(struct napi_struct * , int ), int weight)
熟悉老的 NAPI 接口的话，这个函数也没什么好说的。
值得注意的是，前面的轮询 poll() 方法原型也开始须要一些小小的改变：
大部分 NAPI 相关的函数也须要改变以前的原型，下面是打开轮询功能的 API：
struct napi_struct * napi);
/* ...or... */
int netif_rx_schedule_prep(struct net_device * dev,
struct napi_struct * napi);
void __netif_rx_schedule(struct net_device * dev,
struct napi_struct * napi);
轮询功能的关闭则须要使用：
struct napi_struct * napi);
由于可能存在多个 napi_struct 的实例，要求每一个实例可以独立的使能或者禁止，所以，须要驱动做者保证在网卡接口关闭时，禁止全部的 napi_struct 的实例。
函数 netif_poll_enable() 和 netif_poll_disable() 再也不须要，由于轮询管理再也不和 net_device 直接管理，取而代之的是下面的两个函数：
void napi_disable(struct napi * napi);
发送路径上的优化
TSO (TCP Segmentation Offload)
TSO (TCP Segmentation Offload) 是一种利用网卡分割大数据包，减少 CPU 负荷的一种技术，也被叫作 LSO (Large segment offload) ，若是数据包的类型只能是 TCP，则被称之为 TSO，若是硬件支持 TSO 功能的话，也须要同时支持硬件的 TCP 校验计算和分散 - 汇集 (Scatter Gather) 功能。
能够看到 TSO 的实现，须要一些基本条件，而这些实际上是由软件和硬件结合起来完成的，对于硬件，具体说来，硬件可以对大的数据包进行分片，分片以后，还要可以对每一个分片附着相关的头部。TSO 的支持主要有须要如下几步：
一、若是网路适配器支持 TSO 功能，须要声明网卡的能力支持 TSO，这是经过以 NETIF_F_TSO 标志设置 net_device structure 的 features 字段来代表，例如，在 benet(drivers/net/benet/be_main.c) 网卡的驱动程序中，设置 NETIF_F_TSO 的代码以下：
benet 网卡驱动声明支持 TSO 功能
{
struct be_adapter * adapter = netdev_priv(netdev);
netdev -> features | = NETIF_F_SG | NETIF_F_HW_VLAN_RX | NETIF_F_TSO |
NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_FILTER | NETIF_F_HW_CSUM |
NETIF_F_GRO | NETIF_F_TSO6;
netdev -> vlan_features | = NETIF_F_SG | NETIF_F_TSO | NETIF_F_HW_CSUM;
netdev -> flags | = IFF_MULTICAST;
adapter -> rx_csum = true ;
/* Default settings for Rx and Tx flow control */
adapter -> rx_fc = true ;
adapter -> tx_fc = true ;
netif_set_gso_max_size(netdev, 65535 );
BE_SET_NETDEV_OPS(netdev, & be_netdev_ops);
SET_ETHTOOL_OPS(netdev, & be_ethtool_ops);
netif_napi_add(netdev, & adapter -> rx_eq.napi, be_poll_rx,
BE_NAPI_WEIGHT);
netif_napi_add(netdev, & adapter -> tx_eq.napi, be_poll_tx_mcc,
BE_NAPI_WEIGHT);
netif_carrier_off(netdev);
netif_stop_queue(netdev);
}
在代码中，同时也用 netif_set_gso_max_size 函数设置了 net_device 的 gso_max_size 字段。该字段代表网络接口一次能处理的最大 buffer 大小，通常该值为 64Kb，这意味着只要 TCP 的数据大小不超过 64Kb，就不用在内核中分片，而只需一次性的推送到网络接口，由网络接口去执行分片功能。
二、当一个 TCP 的 socket 被建立，其中一个职责是设置该链接的能力，在网络层的 socket 的表示是 struck sock，其中有一个字段 sk_route_caps 标示该链接的能力，在 TCP 的三路握手完成以后，将基于网络接口的能力和链接来设置该字段。
网路层对 TSO 功能支持的设定
int tcp_v4_connect(struct sock * sk, struct sockaddr * uaddr, int addr_len)
{
……
/* OK, now commit destination to socket. */
sk -> sk_gso_type = SKB_GSO_TCPV4;
sk_setup_caps(sk, & rt -> dst);
……
}
代码中的 sk_setup_caps() 函数则设置了上面所说的 sk_route_caps 字段，同时也检查了硬件是否支持分散 - 汇集功能和硬件校验计算功能。须要这 2 个功能的缘由是：Buffer 可能不在一个内存页面上，因此须要分散 - 汇集功能，而分片后的每一个分段须要从新计算 checksum，所以须要硬件支持校验计算。
三、如今，一切的准备工做都已经作好了，当实际的数据须要传输时，须要使用咱们设置好的 gso_max_size，咱们知道，TCP 向 IP 层发送数据会考虑 mss，使得发送的 IP 包在 MTU 内，不用分片。而 TSO 设置的 gso_max_size 就影响该过程，这主要是在计算 mss_now 字段时使用。若是内核不支持 TSO 功能，mss_now 的最大值为“MTU – HLENS”，而在支持 TSO 的状况下，mss_now 的最大值为“gso_max_size -HLENS”，这样，从网络层带驱动的路径就被打通了。
GSO (Generic Segmentation Offload)
TSO 是使得网络协议栈可以将大块 buffer 推送至网卡，而后网卡执行分片工做，这样减轻了 CPU 的负荷，但 TSO 须要硬件来实现分片功能;而性能上的提升，主要是由于延缓分片而减轻了 CPU 的负载，所以，能够考虑将 TSO 技术通常化，由于其本质实际是延缓分片，这种技术，在 Linux 中被叫作 GSO(Generic Segmentation Offload)，它比 TSO 更通用，缘由在于它不须要硬件的支持分片就可以使用，对于支持 TSO 功能的硬件，则先通过 GSO 功能，而后使用网卡的硬件分片能力执行分片;而对于不支持 TSO 功能的网卡，将分片的执行，放在了将数据推送的网卡的前一刻，也就是在调用驱动的 xmit 函数前。
咱们再来看看内核中数据包的分片都有可能在哪些时刻：
一、在传输协议中，当构造 skb 用于排队的时候
二、在传输协议中，可是使用了 NETIF_F_GSO 功能，立即将传递个网卡驱动的时候
三、在驱动程序里，此时驱动支持 TSO 功能 ( 设置了 NETIF_F_TSO 标志 )
对于支持 GSO 的状况，主要使用了状况 2 或者是状况 2.、3，其中状况二是在硬件不支持 TSO 的状况下，而状况 二、3 则是在硬件支持 TSO 的状况下。
代码中是在 dev_hard_start_xmit 函数里调用 dev_gso_segment 执行分片，这样尽可能推迟分片的时间以提升性能：
GSO 中的分片
struct netdev_queue * txq)
{
……
if (netif_needs_gso(dev, skb)) {
if (unlikely(dev_gso_segment(skb)))
goto out_kfree_skb;
if (skb -> next )
goto gso;
} else {
……
}
……
}
接收路径上的优化
LRO (Large Receive Offload)
Linux 在 2.6.24 中加入了支持 IPv4 TCP 协议的 LRO (Large Receive Offload) ，它经过将多个 TCP 数据聚合在一个 skb 结构，在稍后的某个时刻做为一个大数据包交付给上层的网络协议栈，以减小上层协议栈处理 skb 的开销，提升系统接收 TCP 数据包的能力。
固然，这一切都须要网卡驱动程序支持。理解 LRO 的工做原理，须要理解 sk_buff 结构体对于负载的存储方式，在内核中，sk_buff 能够有三种方式保存真实的负载：
一、数据被保存在 skb->data 指向的由 kmalloc 申请的内存缓冲区中，这个数据区一般被称为线性数据区，数据区长度由函数 skb_headlen 给出
二、数据被保存在紧随 skb 线性数据区尾部的共享结构体 skb_shared_info 中的成员 frags 所表示的内存页面中，skb_frag_t 的数目由 nr_frags 给出，skb_frags_t 中有数据在内存页面中的偏移量和数据区的大小
三、数据被保存于 skb_shared_info 中的成员 frag_list 所表示的 skb 分片队列中
合并了多个 skb 的超级 skb，可以一次性经过网络协议栈，而不是屡次，这对 CPU 负荷的减轻是显然的。
LRO 的核心结构体以下：
LRO 的核心结构体
* Large Receive Offload (LRO) Manager
*
* Fields must be set by driver
*/
struct net_lro_mgr {
struct net_device * dev;
struct net_lro_stats stats;
/* LRO features */
unsigned long features;
#define LRO_F_NAPI 1 /* Pass packets to stack via NAPI */
#define LRO_F_EXTRACT_VLAN_ID 2 /* Set flag if VLAN IDs are extracted
from received packets and eth protocol
is still ETH_P_8021Q */
/*
* Set for generated SKBs that are not added to
* the frag list in fragmented mode
*/
u32 ip_summed;
u32 ip_summed_aggr; /* Set in aggregated SKBs: CHECKSUM_UNNECESSARY
* or CHECKSUM_NONE */
int max_desc; /* Max number of LRO descriptors */
int max_aggr; /* Max number of LRO packets to be aggregated */
int frag_align_pad; /* Padding required to properly align layer 3
* headers in generated skb when using frags */
struct net_lro_desc * lro_arr; /* Array of LRO descriptors */
/*
* Optimized driver functions
*
* get_skb_header: returns tcp and ip header for packet in SKB
*/
int ( * get_skb_header)(struct sk_buff * skb, void ** ip_hdr,
void ** tcpudp_hdr, u64 * hdr_flags, void * priv);
/* hdr_flags: */
#define LRO_IPV4 1 /* ip_hdr is IPv4 header */
#define LRO_TCP 2 /* tcpudp_hdr is TCP header */
/*
* get_frag_header: returns mac, tcp and ip header for packet in SKB
*
* @hdr_flags: Indicate what kind of LRO has to be done
* (IPv4 / IPv6 / TCP / UDP)
*/
int ( * get_frag_header)(struct skb_frag_struct * frag, void ** mac_hdr,
void ** ip_hdr, void ** tcpudp_hdr, u64 * hdr_flags,
void * priv);
};
在该结构体中：
dev：指向支持 LRO 功能的网络设备
stats：包含一些统计信息，用于查看 LRO 功能的运行状况
features：控制 LRO 如何将包送给网络协议栈，其中的 LRO_F_NAPI 代表驱动是 NAPI 兼容的，应该使用 netif_receive_skb() 函数，而 LRO_F_EXTRACT_VLAN_ID 代表驱动支持 VLAN
ip_summed：代表是否须要网络协议栈支持 checksum 校验
ip_summed_aggr：代表汇集起来的大数据包是否须要网络协议栈去支持 checksum 校验
max_desc：代表最大数目的 LRO 描述符，注意，每一个 LRO 的描述符描述了一路 TCP 流，因此该值代表了作多同时能处理的 TCP 流的数量
max_aggr：是最大数目的包将被汇集成一个超级数据包
lro_arr：是描述符数组，须要驱动本身提供足够的内存或者在内存不足时处理异常
get_skb_header()/get_frag_header()：用于快速定位 IP 或者 TCP 的头，通常驱动只提供其中的一个实现
通常在驱动中收包，使用的函数是 netif_rx 或者 netif_receive_skb，但在支持 LRO 的驱动中，须要使用下面的函数，这两个函数将进来的数据包根据 LRO 描述符进行分类，若是能够进行汇集，则汇集为一个超级数据包，否者直接传递给内核，走正常途径。须要 lro_receive_frags 函数的缘由是某些驱动直接将数据包放入了内存页，以后去构造 sk_buff，对于这样的驱动，应该使用下面的接口：
LRO 收包函数
struct sk_buff * skb,
void * priv);
void lro_receive_frags(struct net_lro_mgr * lro_mgr,
struct skb_frag_struct * frags,
int len , int true_size,
void * priv, __wsum sum);
由于 LRO 须要汇集到 max_aggr 数目的数据包，但有些状况下可能致使延迟比较大，这种状况下，能够在汇集了部分包以后，直接传递给网络协议栈处理，这时可使用下面的函数，也能够在收到某个特殊的包以后，不通过 LRO，直接传递个网络协议栈：
LRO flush 函数
struct sk_buff * skb,
void * priv);
void lro_receive_frags(struct net_lro_mgr * lro_mgr,
struct skb_frag_struct * frags,
int len , int true_size,
void * priv, __wsum sum);
GRO (Generic Receive Offload)
前面的 LRO 的核心在于：在接收路径上，将多个数据包聚合成一个大的数据包，而后传递给网络协议栈处理，但 LRO 的实现中存在一些瑕疵：
一、数据包合并可能会破坏一些状态；
二、数据包合并条件过于宽泛，致使某些状况下原本须要区分的数据包也被合并了，这对于路由器是不可接收的；
三、在虚拟化条件下，须要使用桥接功能，但 LRO 使得桥接功能没法使用；
四、实现中，只支持 IPv4 的 TCP 协议。
而解决这些问题的办法就是新提出的 GRO(Generic Receive Offload)，首先，GRO 的合并条件更加的严格和灵活，而且在设计时，就考虑支持全部的传输协议，所以，后续的驱动，都应该使用 GRO 的接口，而不是 LRO，内核可能在全部先有驱动迁移到 GRO 接口以后将 LRO 从内核中移除。而 Linux 网络子系统的维护者 David S. Miller 就明确指出，如今的网卡驱动，有 2 个功能须要使用，一是使用 NAPI 接口以使得中断缓和 (interrupt mitigation) ，以及简单的互斥，二是使用 GRO 的 NAPI 接口去传递数据包给网路协议栈。
在 NAPI 实例中，有一个 GRO 的包的列表 gro_list，用堆积收到的包，GRO 层用它来将汇集的包分发到网络协议层，而每一个支持 GRO 功能的网络协议层，则须要实现 gro_receive 和 gro_complete 方法。
协议层支持 GRO/GSO 的接口
__be16 type; /* This is really htons(ether_type). */
struct net_device * dev; /* NULL is wildcarded here */
int ( * func) (struct sk_buff * ,
struct net_device * ,
struct packet_type * ,
struct net_device * );
struct sk_buff * ( * gso_segment)(struct sk_buff * skb,
int features);
int ( * gso_send_check)(struct sk_buff * skb);
struct sk_buff ** ( * gro_receive)(struct sk_buff ** head,
struct sk_buff * skb);
int ( * gro_complete)(struct sk_buff * skb);
void * af_packet_priv;
struct list_head list;
};
其中，gro_receive 用于尝试匹配进来的数据包到已经排队的 gro_list 列表，而 IP 和 TCP 的头部则在匹配以后被丢弃;而一旦咱们须要向上层协议提交数据包，则调用 gro_complete 方法，将 gro_list 的包合并成一个大包，同时 checksum 也被更新。在实现中，并没要求 GRO 长时间的去实现聚合，而是在每次 NAPI 轮询操做中，强制传递 GRO 包列表跑到上层协议。GRO 和 LRO 的最大区别在于，GRO 保留了每一个接收到的数据包的熵信息，这对于像路由器这样的应用相当重要，而且实现了对各类协议的支持。以 IPv4 的 TCP 为例，匹配的条件有：
一、源 / 目的地址匹配；
二、TOS/ 协议字段匹配；
三、源 / 目的端口匹配。
而不少其它事件将致使 GRO 列表向上层协议传递聚合的数据包，例如 TCP 的 ACK 不匹配或者 TCP 的序列号没有按序等等。
GRO 提供的接口和 LRO 提供的接口很是的相似，但更加的简洁，对于驱动，明确可见的只有 GRO 的收包函数了 , 由于大部分的工做实际是在协议层作掉了：
GRO 收包接口
gro_result_t napi_gro_frags(struct napi_struct * napi)
小结
从上面的分析，能够看到，Linux 网络性能优化方法，就像一部进化史，但每步的演化，都让解决问题的办法更加的通用，更加的灵活;从 NAPI 到 Newer newer NAPI，从 TSO 到 GSO，从 LRO 到 GRO，都是一个从特例到一个更通用的解决办法的演化，正是这种渐进但连续的演化，让 Linux 保有了如此的活力。
- 1. 如何进行网站性能优化？
- 2. 如何进行网站性能优化
- 3. Linux性能优化----网络性能
- 4. 前端如何进行网站性能优化
- 5. 如何对网站进行性能优化
- 6. SQL性能优化：如何定位网络性能问题
- 7. 如何对tomcat进行性能优化
- 8. Linux性能优化-网络基础
- 9. 如何进行网站优化
- 10. 网站的优化如何进行
- 更多相关文章...
- • 网站主机 性能 - 网站主机教程
- • XSD 如何使用? - XML Schema 教程
- • 互联网组织的未来：剖析GitHub员工的任性之源
- • 算法总结-广度优先算法
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 如何进行网站性能优化？
- 2. 如何进行网站性能优化
- 3. Linux性能优化----网络性能
- 4. 前端如何进行网站性能优化
- 5. 如何对网站进行性能优化
- 6. SQL性能优化：如何定位网络性能问题
- 7. 如何对tomcat进行性能优化
- 8. Linux性能优化-网络基础
- 9. 如何进行网站优化
- 10. 网站的优化如何进行