PPTP协议大体上可以分为两部分：控制层连接和隧道，下面简要介绍两部分的功能。如果要详细了解PPTP协议请阅读RFC文档。
一、 Control Connection Protol
控制层连接是基于TCP建立的，PPTP Server监听TCP1723端口，等待Client的连接请求。
控制层的主要功能包括：
1. 彼此交换基本信息；
2. 负责创建、维护、删除Session；
3. 负责创建、维护、删除Tunnel；
4. 更新通信参数；（Set-Link-Info）
5. 维护控制层自身的连接状态。（Echo-Request、Echo-Reply）
其中需要注意的是控制层自身的状态维护。PPTP连接双方在一段时间内（60秒）如果没有收到任何控制层信息，就会发Echo-Request查询控制层连接状态，接收方会应答Echo-Reply。如果发送方在60秒内还没有收到应答就会断开控制层连接。
其实控制层真的是没什么好说的，看上去挺多东西，其实本身很简单。如果要了解控制层的工作过程，请参照上一篇：PPTP(1)--连接过程。
二、 Tunnel Protol
看了上面的叙述不难发现，控制层本身不负责传输有效载荷。那么真正的应用层数据是怎么传输的呢？答案是Tunnel。
RFC里给出的Tunnel的定义是这样的"A tunnel is defined by a PNS-PAC pair"。简单说就是一对CS就是一个tunnel。那么tunnel到底是怎么工作的呢？
在发送端，要把一个数据包发出去，需要首先把packet发到VPN的虚拟网卡，虚拟网卡把它变成GRE frame，然后发往IP层再次进行路由。数据包这次会被发往物理网络，并最终抵达PPTP Server端。
在接收端，从物理网卡上收到frame之后交给IP层，IP对其解包之后转发给VPN虚拟网卡，虚拟网卡再解包把它变成普通IP packet再次发往IP层，这次IP层知道是VPN对端发来的数据，直接交给TCP/UDP并最终抵达应用层。
通 过上面的过程你就可以理解为什么叫tunnel了。在应用层看来，Server和Client是直接点对点连接的，他们之间的媒介就是GRE。而这个 GRE的底层并不是真正的点对点连接，而是建立在物理网络上的一个Tunnel，保护其中传输的数据，所以称之为隧道。与控制层相比，tunnel的结构 要复杂得多。我们来看一下数据在tunnel的传输过程。
上图描述了数据在发送端的处理过程，下面解释一下每一个step在干什么。（接收端的处理过程完全相反）
1. 应用层调用TCP/UDP发送message；
2. TCP/UDP调用IP发送packets；
3. packets被路由到VPN的miniport；
4. Miniport调用PPP协议发包；
5. packets被封装成PPP包；
6. PPP包被发往PPTP；
7. PPP包被封装成GRE包；
8. GRE调用IP协议发送packets；
9. 新的packets被路由到物理网卡；
10. 调用网卡驱动发frame。
怎么样，挺乱的吧。其实际过程还要更乱一些。需要特别注意的是，最终从网卡上发 出去的数据包被IP层封装过两次。第一次封装是在PPTP虚拟网络之上的，第二次封装是在物理网络之上的。注意看下面的图，在黄色部分已经有一次网络层的 封装了，然后在GRE外围还会有一次网络层封装。
看到这里你可能会有一大堆问题，我最希望你能想到这几个问题：
1. 为什么要经过两次网络层？
2. 同一个数据包为什么两次经过网络层被路由到了不同的地方？
3. 为什么连上VPN之后很多网页都不能正常访问了？
这些都是比较本质的问题，要搞清楚这几个问题，我们需要深入到操作系统和协议栈的底层去好好研究一下VPN的本质，请参照一下篇：PPTP(3)--PPTP的路由。
另外，pptp tunnel还实现了一大堆别的东西，其中最复杂的就是滑动窗口协议。其中实现了，超时、确认、重传、流量控制、拥塞控制。这些东西虽然复杂，但并不是最关键的东西，不需要过多地注意。