linuxtcp内核

❶ linux系统一般由哪4个部分组成

Linux系统一般有4个主要部分：内核、shell、文件系统和应用程序。内核、shell和文件系统一起形成了基本的操作系统结构，它们使得用户可以运行程序、管理文件并使用系统。

一、Linux内核

内核是操作系统的核心，具有很多最基本功能，如虚拟内存、多任务、共享库、需求加载、可执行程序和TCP/IP网络功能。Linux内核的模块分为以下几个部分：存储管理、CPU和进程管理、文件系统、设备管理和驱动、网络通信、系统的初始化和系统调用等。

二、Linuxshell

shell是系统的用户界面，提供了用户与内核进行交互操作的一种接口。它接收用户输入的命令并把它送入内核去执行，是一个命令解释器。另外，shell编程语言具有普通编程语言的很多特点，用这种编程语言编写的shell程序与其他应用程序具有同样的效果。

三、Linux文件系统

文件系统是文件存放在磁盘等存储设备上的组织方法。Linux系统能支持多种目前流行的文件系统，如EXT2、EXT3、FAT、FAT32、VFAT和ISO9660。

四、Linux应用程序

标准的Linux系统一般都有一套都有称为应用程序的程序集，它包括文本编辑器、编程语言、XWindow、办公套件、Internet工具和数据库等。

(1)linuxtcp内核扩展阅读：

LINUX系统的特点

1、Linux是一款免费的操作系统，用户可以通过网络或其他途径免费获得，并可以任意修改其源代码。这是其他的操作系统所做不到的。

2、在Linux下通过相应的模拟器运行常见的DOS、Windows的程序。这为用户从Windows转到Linux奠定了基础。

3、Linux可以运行在多种硬件平台上，如具有x86、680x0、SPARC、Alpha等处理器的平台。此外Linux还是一种嵌入式操作系统，可以运行在掌上电脑、机顶盒或游戏机上。

❷ 一般优化linux的内核，需要优化什么参数

首先要知道一点所有的TCP/IP的参数修改是临时的，因为它们都位于/PROC/SYS/NET目录下，如果想使参数长期保存，可以通过编辑/ETC/SYSCTL.CONF文件来实现，这里不做详细说明，只针对Linux的TCPIP内核参数优化列举相关参数：

1、为自动调优定义socket使用的内存

2、默认的TCP数据接收窗口大小（字节）

3、最大的TCP数据接收窗口

4、默认的TCP发送窗口大小

5、最大的TCP数据发送窗口

6、在每个网络接口接收数据包的速率比内核处理这些包速率快时，允许送到队列的数据包最大数目

7、定义了系统中每一个端口最大的监听队列长度

8、探测消息未获得相应时，重发该消息的间隔时间

9、在认定tcp连接失效之前，最多发送多少个keepalive探测消息等。

❸ Linux TCP连接参数调优

优化以下tcp参数，除了进一步提升服务器的负载能力之外，还能够防御一定程度的DDoS、CC和SYN攻击然后，在/etc/sysctl.conf文件中，加入下面的几行内容：

最后激和念输入下面的命令，让内核参数生效：

简单棚哗的说明下，上面的参数的含义：

备注：
Linux默认的TIME_WAIT时长一般是60秒（等于2MSL），
定义在内核的include/net/tcp.h文明困件中：

❹ linux 内核怎么实现tcp nat 转换的

1.两个网络接口、一个内，一个外2.NAT转换（内）操作步骤：1.设置
Linux内核
支持ip数据包的转发：echo
"1"
>
/proc/sys/net/
ipv4
/ip_forward2.加载实现NAT功能必要的内核模块：modprobe
ip_tablesmodprobe
ip_nat_ftpmodprobe
ip_nat_ircmodprobe...

❺ 【Linux基础】TCP层的最主要的特点是什么

TCP协议的特点
1）TCP是有序地、面向连接的、可靠的字节流传输层协议
2）其有三次握手连接机制
所谓三次握手是指首先由客户端发起连接请求，服务器接收到连接请求后给予相应答复，客户端接收后并给予答复以建立数据收发双方之间的连接通路。这个机制的存在可以保证数据传输的可靠，因为只有连接建立成功后双方才能相互通信，类似于发送前的探路，只有确定路子通才出发，这样才稳妥。
3）其有应答机制，就是说数据发送给对方后，对方必须应答是否发送成功
4）其有滑动窗口机制，指可以根据网络的好坏，调整发送分组数据的大小

❻ 一般优化linux的内核，需要优化什么参数

作为高性能WEB服务器，只调整Nginx本身的参数是不行的，因为Nginx服务依赖于高性能的操作系统。

以下为常见的几个Linux内核参数优化方法。

• net.ipv4.tcp_max_tw_buckets

对于tcp连接，服务端和客户端通信完后状态变为timewait，假如某台服务器非常忙，连接数特别多的话，那么这个timewait数量就会越来越大。
毕竟它也是会占用一定的资源，所以应该有一个最大值，当超过这个值，系统就会删除最早的连接，这样始终保持在一个数量级。
这个数值就是由net.ipv4.tcp_max_tw_buckets这个参数来决定的。
CentOS7系统，你可以使用sysctl -a |grep tw_buckets来查看它的值，默认为32768，
你可以适当把它调低，比如调整到8000，毕竟这个状态的连接太多也是会消耗资源的。
但你不要把它调到几十、几百这样，因为这种状态的tcp连接也是有用的，
如果同样的客户端再次和服务端通信，就不用再次建立新的连接了，用这个旧的通道，省时省力。

• net.ipv4.tcp_tw_recycle = 1

该参数的作用是快速回收timewait状态的连接。上面虽然提到系统会自动删除掉timewait状态的连接，但如果把这样的连接重新利用起来岂不是更好。
所以该参数设置为1就可以让timewait状态的连接快速回收，它需要和下面的参数配合一起使用。

• net.ipv4.tcp_tw_reuse = 1

该参数设置为1，将timewait状态的连接重新用于新的TCP连接，要结合上面的参数一起使用。

• net.ipv4.tcp_syncookies = 1

tcp三次握手中，客户端向服务端发起syn请求，服务端收到后，也会向客户端发起syn请求同时连带ack确认，
假如客户端发送请求后直接断开和服务端的连接，不接收服务端发起的这个请求，服务端会重试多次，
这个重试的过程会持续一段时间（通常高于30s），当这种状态的连接数量非常大时，服务器会消耗很大的资源，从而造成瘫痪，
正常的连接进不来，这种恶意的半连接行为其实叫做syn flood攻击。
设置为1，是开启SYN Cookies，开启后可以避免发生上述的syn flood攻击。
开启该参数后，服务端接收客户端的ack后，再向客户端发送ack+syn之前会要求client在短时间内回应一个序号，
如果客户端不能提供序号或者提供的序号不对则认为该客户端不合法，于是不会发ack+syn给客户端，更涉及不到重试。

• net.ipv4.tcp_max_syn_backlog

该参数定义系统能接受的最大半连接状态的tcp连接数。客户端向服务端发送了syn包，服务端收到后，会记录一下，
该参数决定最多能记录几个这样的连接。在CentOS7，默认是256，当有syn flood攻击时，这个数值太小则很容易导致服务器瘫痪，
实际上此时服务器并没有消耗太多资源（cpu、内存等），所以可以适当调大它，比如调整到30000。

• net.ipv4.tcp_syn_retries

该参数适用于客户端，它定义发起syn的最大重试次数，默认为6，建议改为2。

• net.ipv4.tcp_synack_retries

该参数适用于服务端，它定义发起syn+ack的最大重试次数，默认为5，建议改为2，可以适当预防syn flood攻击。

• net.ipv4.ip_local_port_range

该参数定义端口范围，系统默认保留端口为1024及以下，以上部分为自定义端口。这个参数适用于客户端，
当客户端和服务端建立连接时，比如说访问服务端的80端口，客户端随机开启了一个端口和服务端发起连接，
这个参数定义随机端口的范围。默认为32768 61000，建议调整为1025 61000。

• net.ipv4.tcp_fin_timeout

tcp连接的状态中，客户端上有一个是FIN-WAIT-2状态，它是状态变迁为timewait前一个状态。
该参数定义不属于任何进程的该连接状态的超时时间，默认值为60，建议调整为6。

• net.ipv4.tcp_keepalive_time

tcp连接状态里，有一个是established状态，只有在这个状态下，客户端和服务端才能通信。正常情况下，当通信完毕，
客户端或服务端会告诉对方要关闭连接，此时状态就会变为timewait，如果客户端没有告诉服务端，
并且服务端也没有告诉客户端关闭的话（例如，客户端那边断网了），此时需要该参数来判定。
比如客户端已经断网了，但服务端上本次连接的状态依然是established，服务端为了确认客户端是否断网，
就需要每隔一段时间去发一个探测包去确认一下看看对方是否在线。这个时间就由该参数决定。它的默认值为7200秒，建议设置为30秒。

• net.ipv4.tcp_keepalive_intvl

该参数和上面的参数是一起的，服务端在规定时间内发起了探测，查看客户端是否在线，如果客户端并没有确认，
此时服务端还不能认定为对方不在线，而是要尝试多次。该参数定义重新发送探测的时间，即第一次发现对方有问题后，过多久再次发起探测。
默认值为75秒，可以改为3秒。

• net.ipv4.tcp_keepalive_probes

第10和第11个参数规定了何时发起探测和探测失败后再过多久再发起探测，但并没有定义一共探测几次才算结束。
该参数定义发起探测的包的数量。默认为9，建议设置2。
设置和范例
在Linux下调整内核参数，可以直接编辑配置文件/etc/sysctl.conf，然后执行sysctl -p命令生效

❼ Linux 升级内核开启 TCP BBR 有多大好处

测试通过一个简单的场景来验证了bbr算法仿祥判对于丢包情况下的带宽的优化宴迟，这个对于一些提供下载服务，并且有一定的丢包率的场景的情况下，能够有很大的改善，所以算法对于技术的改变还是非常大的，很多备改时候就是这种异常情况下的差别，才是真正的差别
关于更多Linux的学习，请查阅书籍《linux就该这么学》。

❽ tcp拥塞控制状态机在linux内核源码的什么位置

公平性

公平性是在发生拥塞时各

源端（或同一源端建立的不同TCP连接或UDP数据报）能公平地共享同一网络资源（如带宽、缓存等）。处于相同级别的源端应该得到相同数量的网络资源。产

生公平性的根本原因在于拥塞发生必然导致数据包丢失，而数据包丢失会导致各数据流之间为争抢有限的网络资源发生竞争，争抢能力弱的数据流将受到更多损害。

因此，没有拥塞，也就没有公平性问题。

TCP层上的公平性问题表现在两方面：

(1)

面向连接的TCP和无连接的UDP在拥塞发生时对拥塞指示的不同反应和处理，导致对网络资源的不公平使用问题。在拥塞发生时，有拥塞控制反应机制的TCP

数据流会按拥塞控制步骤进入拥塞避免阶段，从而主动减小发送入网络的数据量。但对无连接的数据报UDP，由于没有端到端的拥塞控制机制，即使网络发出了拥

塞指示（如数据包丢失、收到重复ACK等），UDP也不会像TCP那样减少向网络发送的数据量。结果遵守拥塞控制的TCP数据流得到的网络资源越来越少，

没有拥塞控制的UDP则会得到越来越多的网络资源，这就导致了网络资源在各源端分配的严重不公平。

网络资源分配的不公平反

过来会加重拥塞，甚至可能导致拥塞崩溃。因此如何判断在拥塞发生时各个数据流是否严格遵守TCP拥塞控制，以及如何“惩罚”不遵守拥塞控制协议的行为，成

了目前研究拥塞控制的一个热点。在传输层解决拥塞控制的公平性问题的根本方法是全面使用端到端的拥塞控制机制。

(2) 一些TCP连接之间也存在公平性问题。产生问题的原因在于一些TCP在拥塞前使用了大窗口尺寸，或者它们的RTT较小，或者数据包比其他TCP大，这样它们也会多占前稿侍带宽。

RTT不公平性

AIMD拥塞窗口更新策

略也存在一些缺陷，和式增加策略使发送方发送数据流的拥塞窗口在一个往返时延(RTT)内增加了一个数据包的大小，因此，当不同的数据流对网络瓶颈带宽进

行竞争时，具有较小RTT的TCP数据流的拥塞窗口增加速率将会快于具有大RTT的TCP数据流，从而将会占有更多的网络带宽资源。

附加说明

中美之间的线路质量不是很好，rtt较长且时常丢包。TCP协议是成也丢包，败也丢包；TCP的设计目的是解决不可靠线路上可靠传输的问题，即为了解决丢包，但丢包却使TCP传输速度大幅下降。HTTP协议在传输层使用的是TCP协议，所以网页下载的速度就取决于TCP单线程下载的速度（因为网页就是单线程下载的）。

丢包使得TCP传输速度大幅下降的主要原因是丢包重传机制，控制这一机制的就是TCP拥塞控制算法。

Linux内核中提供了若干套TCP拥塞控制算法，已加载进内核的可以通过内核参数net.ipv4.tcp_available_congestion_control看到。

1. Vegas

1994

年，Brakmo提出了一种新的拥塞控制机制TCP

Vegas，从另外的一个角度来进行拥塞控制。从前面可以看到，敬裂TCP的拥塞控制是基于丢包的，一旦出现丢包，于是调整拥塞窗口，然而由于丢包不一定是由

于网络进入了拥塞，但是由于RTT值与网络运行情况有比较密切的关系，于是TCP

Vegas利用RTT值的改变来判断网络是否拥塞，从而调整拥塞控制窗口。如果发现RTT在增大，Vegas就认为网络正在发生拥塞，于是开始减小拥塞窗

口，如果RTT变小，Vegas认为网络拥塞正在逐步解除，于是再次增加拥塞窗口。由于Vegas不是利用丢包来判断网络可用带宽，而是利用RTT变化来判断，因而可以更精确的探测网络的可用带宽，从而效率更好。然而慧吵Vegas的有一个缺陷，并且可以说致命的，最终影响TCP

Vegas并没有在互联网上大规模使用。这个问题就是采用TCP Vegas的流的带宽竞争力不及未使用TCP Vegas的流，

这是因为网络中路由器只要缓冲了数据，就会造成RTT的变大，如果缓冲区没有溢出的话，并不会发生拥塞，但是由于缓存数据就会导致处理时延，从而RTT变

大，特别是在带宽比较小的网络上，只要一开始传输数据，RTT就会急剧增大，这个在无线网络上特别明显。在这种情况下，TCP

Vegas降低自己的拥塞窗口，但是只要没有丢包的话，从上面看到标准的TCP是不会降低自己的窗口的，于是两者开始不公平，再这样循环下去，TCP

Vegas的效率就非常低了。其实如果所有的TCP都采用Vegas拥塞控制方式的话，流之间的公平性会更好，竞争能力并不是Vegas算法本身的问题。

适用环境：很难在互联网上大规模适用（带宽竞争力低）

2. Reno

Reno是目前应用最广泛且较为成熟的算法。该算法所包含的慢启动、拥塞避免和快速重传、快速恢复机制，是现有的众多算法的基础。从Reno运行机制中很容易看出，为了维持一个动态平衡，必须周期性地产生一定量的丢失，再加上AIMD机制--减少快，增长慢，尤其是在大窗口环境下，由于一个数据报的丢失所带来的窗口缩小要花费很长的时间来恢复，这样，带宽利用率不可能很高且随着网络的链路带宽不断提升，这种弊端将越来越明显。公平性方面，根据统计数据，Reno的公平性还是得到了相当的肯定，它能够在较大的网络范围内理想地维持公平性原则。

Reno算法以其简单、有效和鲁棒性成为主流，被广泛的采用。

但是它不能有效的处理多个分组从同一个数据窗口丢失的情况。这一问题在New Reno算法中得到解决。

基于丢包反馈的协议

近几年来，随着高带宽延时网络（High Bandwidth-Delay proct network）的普及，针对提高TCP带宽利用率这一点上，又涌现出许多新的基于丢包反馈的TCP协议改进，这其中包括HSTCP、STCP、BIC-TCP、CUBIC和H-TCP。

总的来说，基于丢包反馈

的协议是一种被动式的拥塞控制机制，其依据网络中的丢包事件来做网络拥塞判断。即便网络中的负载很高时，只要没有产生拥塞丢包，协议就不会主动降低自己的

发送速度。这种协议可以最大程度的利用网络剩余带宽，提高吞吐量。然而，由于基于丢包反馈协议在网络近饱和状态下所表现出来的侵略性，一方面大大提高了网络的带宽利用率；但另一方面，对于基于丢包反馈的拥塞控制协议来说，大大提高网络利用率同时意味着下一次拥塞丢包事件为期不远了，所以这些协议在提高网络带宽利用率的同时也间接加大了网络的丢包率，造成整个网络的抖动性加剧。

友好性

BIC-TCP、

HSTCP、STCP等基于丢包反馈的协议在大大提高了自身吞吐率的同时，也严重影响了Reno流的吞吐率。基于丢包反馈的协议产生如此低劣的TCP友好

性的组要原因在于这些协议算法本身的侵略性拥塞窗口管理机制，这些协议通常认为网络只要没有产生丢包就一定存在多余的带宽，从而不断提高自己的发送速率。

其发送速率从时间的宏观角度上来看呈现出一种凹形的发展趋势，越接近网络带宽的峰值发送速率增长得越快。这不仅带来了大量拥塞丢包，同时也恶意吞并了网络

中其它共存流的带宽资源，造成整个网络的公平性下降。

3. HSTCP(High Speed TCP)

HSTCP(高速传输控制协议)是高速网络中基于AIMD(加性增长和乘性减少)的一种新的拥塞控制算法,它能在高速度和大时延的网络中更有效地提高网络的吞吐率。它通过对标准TCP拥塞避免算法的增加和减少参数进行修改，从而实现了窗口的快速增长和慢速减少，使得窗口保持在一个足够大的范围，以充分利用带宽，它在高速网络中能够获得比TCP

Reno高得多的带宽，但是它存在很严重的RTT不公平性。公平性指共享同一网络瓶颈的多个流之间占有的网络资源相等。

TCP发送端通过网络所期望的丢包率来动态调整HSTCP拥塞窗口的增量函数。

拥塞避免时的窗口增长方式： cwnd = cwnd + a(cwnd) / cwnd

丢包后窗口下降方式：cwnd = (1-b(cwnd))*cwnd

其中，a(cwnd)和

b(cwnd)为两个函数，在标准TCP中，a(cwnd)=1，b(cwnd)=0.5，为了达到TCP的友好性，在窗口较低的情况下，也就是说在非

BDP的网络环境下，HSTCP采用的是和标准TCP相同的a和b来保证两者之间的友好性。当窗口较大时（临界值LowWindow=38），采取新的a

和b来达到高吞吐的要求。具体可以看RFC3649文档。

4. westwood

无线网络中，在大量研究的基础上发现tcpwestwood是一种较理想的算法，它的主要思想是通过在发送端持续不断的检测ack的到达速率来进行带宽估计，当拥塞发生时用带宽估计值来调整拥塞窗口和慢启动阈值，采用aiad(additive increase and

adaptive decrease)拥塞控制机制。它不仅提高了无线网络的吞吐量,而且具有良好的公平性和与现行网络的互操作性。存在的问题是不能很好的区分传输过程中的拥塞丢包和无线丢包，导致拥塞机制频繁调用。

5. H-TCP

高性能网络中综合表现比较优秀的算法是：h-tcp，但它有rtt不公平性和低带宽不友好性等问题。

6. BIC-TCP

BIC-TCP的缺点：首先就是抢占性较强，BIC-TCP的增长函数在小链路带宽时延短的情况下比起标准的TCP来抢占性强，它在探测阶段相当于是重新启动一个慢启动算法，而TCP在处于稳定后窗口就是一直是线性增长的，不会再次执行慢启动的过程。其次，BIC-TCP的的窗口控制阶段分为binary

search increase、max probing，然后还有Smax和Smin的区分，这几个值增加了算法上的实现难度，同时也对协议性能的分析模型增加了复杂度。在低RTT网络 和低速环境中，BIC可能会过于“积极”，因而人们对BIC进行了进一步的改进，即CUBIC。是Linux在采用CUBIC之前的默认算法。

7. CUBIC

CUBIC在设计上简化了BIC-TCP的窗口调整算法，

在BIC-TCP的窗口调整中会出现一个凹和凸(这里的凹和凸指的是数学意义上的凹和凸，凹函数/凸函数)的增长曲线，CUBIC使用了一个三次函数(即

一个立方函数)，在三次函数曲线中同样存在一个凹和凸的部分，该曲线形状和BIC-TCP的曲线图十分相似，于是该部分取代BIC-TCP的增长曲线。另

外，CUBIC中最关键的点在于它的窗口增长函数仅仅取决于连续的两次拥塞事件的时间间隔值，从而窗口增长完全独立于网络的时延RTT，之前讲述过的HSTCP存在严重的RTT不公平性，而CUBIC的RTT独立性质使得CUBIC能够在多条共享瓶颈链路的TCP连接之间保持良好的RTT公平性。

CUBIC is a congestion control protocol for TCP (transmission control protocol) and thecurrent default TCP algorithm in Linux.

The protocol modifies the linear window

growth function of existing TCP standards to be a cubic function in

order to improve the scalability of TCP over fast and long distance

networks. It also achieves more equitable bandwidth allocations among

flows with different RTTs (round trip times) by making

the window growth to be independent of RTT – thus those flows grow

their congestion window at the same rate. During steady state, CUBIC

increases the window size aggressively when the window is far from the

saturation point, and the slowly when it is close

to the saturation point.This feature allows

CUBIC to be very scalable when the bandwidth and delay proct of the

network is large, and at the same time, be highly stable and also fair

to standard TCP flows.

8. STCP

STCP，Scalable tcp。

STCP算法是由 Tom Kelly于 2003年提出的 ,通过修改 TCP的窗口增加和减少参数来调整发送窗口大小 ,以适应高速网络的环境。该算法具有很高的链路利用率和稳定性，但该机制窗口增加和 RTT成反比 ,在一定的程度上存在着

RTT不公平现象 ,而且和传统 TCP流共存时 ,过分占用带宽 ,其 TCP友好性也较差。

❾ Linux TCP/IP协议栈封装方式及核心数据结构代码实现分析~

这个不是一两句讲清楚的，推荐做法：
1.《Linux源码分析》或《Linux源码情景分析》里面有详细描述，这两本书网上很瞎握多下载的枝神清
2.如果想弄明白原理的话推猛前荐看TCP／IP详解

❿ 嵌入式Linux内核和网络协议栈的特点,和代表性产品有哪些

首先，嵌入Linux内核是可定制的内核：
1 Linux内核的配置系统
2 Linux内核的模块机制
3 Linux内核的源代码开放
4 经裁减的 Linux内核最小可达到 150KB以下，尤其适合嵌入式领域中资源受限的实际情况。
其次，它的性能优越：Linux 系统内核精简、高效和稳定，能够充分发挥硬件的功能，因此它比其他操作系统的运行效率更高。
再者，它有良好的网络支持：
1 支持 TCP/IP 协议栈
2 提供对包括十兆位、百兆位及千兆位的以太网，还有无线网络、Tokenring（令牌环）和光纤甚至卫星的支持
3 对现在依赖于网络的嵌入式设备来说是很好的选择。

至于网络协议的话，有很多种，就目前主流的3种网络协议是：NetBEUI、IPX/SPX及其兼容协议、TCP/IP，而其他的像Lwip、ZigBee、Sip等很多。
1 NetBEUI的前身是NetBIOS，这一协议是IBM1983年开发完成的，早期的微软OS产品中都选择该协议作为通信协议。它是一套用于实现仅仅在小型局域网上PC见相互通信的标准。该网络最大用户数不能超过30个，1985年，微软对其改进，增加了SMB(Server Message Blocks，服务器消息块)的组成部分，以降低网络的通信阻塞，形成了现在的NetBEUI通信协议。
特点：体积小、效率高、速度快、占用内存少。
2 IPX/SPX及其兼容协议：它的全称是“Internwork Packet Exchange/Sequence Packet Exchange”即网际包交换/顺序包交换。
特点：体积较大、能够连接多种网络、具有强大的路由功能，适合大型网络的使用。windows网络中无法直接使用该协议。
3 TCP/IP是国际互联网Internet采用的协议标准，早期用于ARPANet网络，后来开放用于民间。
特点：灵活性，支持任意规模的网络，可以连接所有的计算机，具有路由功能，且TCP/IP的地址是分级的，容易确定并找到网上的用户，提高了网络代换的利用率。

而其他的像Lwip协议栈的特点：
（1）支持多网络接口的IP转发
（2）支持ICMP协议
（3）包括实验性扩展的UDP
（4）包括阻塞控制，RTT估算和快速恢复和快速转发的TCP
（5）提供专门的内部回调接口用于提高应用程序性能
（6）可选择的Berkeley接口API
（7）在最新的版本中支持ppp

不知道这些是不是你想要的。