traffic server文件目录

功能：

Trafficserver的主要功能是缓存，当然你也可以用它来做纯粹的反向代理（像通常用nginx那样）。通常切入一个庞大的系统的最好方式是看如何使用，使用traffic server的主要入口有两个：配置文件和插件。所有使用者都需要配置文件，高级使用者则需要插件。

traffic支持大规模的集群处理，不同于nginx的单点（需要ospf均衡链路来做冗余），所有的配置文件可以做到改动一个通知全部。程序根据功能划分为不同的几个子程序，有服务运行时使用的程序，也有管理使用的。详细见下文。

[root@controller trafficserver]# tree -L 3 bin/ etc/ var/
bin/
├── traffic_cop
├── traffic_crashlog
├── traffic_ctl
├── traffic_layout
├── traffic_line
├── traffic_logcat
├── traffic_logstats
├── traffic_manager
├── traffic_sac
├── trafficserver
├── traffic_server
├── traffic_top
├── traffic_via
├── tspush
├── tstop -> traffic_top
└── tsxs
etc/
└── trafficserver
    ├── body_factory
    │   └── default
    ├── cache.config
    ├── cache.config_1
    ├── cluster.config
    ├── cluster.config_1
    ├── congestion.config
    ├── congestion.config_1
    ├── hosting.config
    ├── hosting.config_1
    ├── icp.config
    ├── icp.config_1
    ├── ip_allow.config
    ├── ip_allow.config_1
    ├── log_hosts.config
    ├── log_hosts.config_1
    ├── logs_xml.config
    ├── logs_xml.config_1
    ├── parent.config
    ├── parent.config_1
    ├── plugin.config
    ├── plugin.config_1
    ├── prefetch.config
    ├── prefetch.config_1
    ├── proxy.pac
    ├── proxy.pac_1
    ├── records.config
    ├── records.config_1
    ├── remap.config
    ├── remap.config_1
    ├── remap.config_2
    ├── snapshots
    ├── socks.config
    ├── socks.config_1
    ├── splitdns.config
    ├── splitdns.config_1
    ├── ssl_multicert.config
    ├── ssl_multicert.config_1
    ├── stats.config.xml
    ├── stats.config.xml_1
    ├── storage.config
    ├── storage.config_1
    ├── storage.config_2
    ├── trafficserver-release
    ├── update.config
    ├── update.config_1
    ├── vaddrs.config
    ├── vaddrs.config_1
    ├── volume.config
    └── volume.config_1
var/
├── log
│   └── trafficserver
│       ├── access.log_controller.19691231.19h00m00s-20171201.00h00m04s.old
│       ├── access.log_controller.20171201.00h35m04s-20171201.02h00m02s.old
│       ├── diags.log
│       ├── error.log
│       ├── manager.log
│       ├── squid.blog
│       ├── squid.blog_controller.19691231.19h00m00s-20171201.00h00m04s.old
│       ├── traffic.out
│       ├── traffic_server.stderr
│       └── traffic_server.stdout
└── trafficserver
    ├── cache.db
    ├── cop.lock
    ├── eventapi.sock
    ├── host.db
    ├── hostdb.config
    ├── manager.lock
    ├── mgmtapi.sock
    ├── processerver.sock
    ├── records.snap
    ├── server.lock
    └── stats.snap

配置文件：

l  缓存Cache.config

n  上游拉取数据拥塞控制：congestion.config

n  缓存分割与上游分配：hosting.config

n  划分不同种类的缓存类型（与hosting.config配合可以实现不同种的数据缓存安排）

n  定义上游的peer：Icp.config

n  定义可以使用cache的白名单：ip_allow.config

n  缓存可以定义多级，定义级别的配置：parent.config

n  缓存持久化：storage.config

l  Log配置

n  将不同上游的log放到不同的log文件中：log_hosts.config

n  定义不同的log格式：logs_xml.config

l  插件管理plugins.config

l  主程序可调整参数：records.config

l  代理：

n  请求和响应的url修改配置：remap.config

l  域名解析：splitdns.config

l  安全：配置多个ssl证书：ssl_multicert.config

插件系统：

标准的面向过程做插件的过程。一个HTTP有个处理流程，包括request头部处理（你可以改url），dns查询（你可以决定去哪个后台获取数据）、从后台或缓存拉取数据、返回内容等。只要是http请求，这个流程就是固定的。因此插件系统就是在这些流程上注册回调函数。这里的回调函数还不是直接调用，还会传递一个event事件参数，用于表示在当前的钩子上发生的事情，使plugin可以更好的处理。

除了被调用，trafficserver还要提供调用方法。这里提供的调用方式可不是一般意义上的函数调用，而是类似远程过程调用。插件通过将自己要被执行的代码（action）发送给server（就连发送都是要指明ip地址和端口的），然后通过查询server返回的接口来获得action执行的状态。这里的action就是traffic server里面的协程概念，整个过程类似golang的go func(){}()关键字操作。

除了这种远程调用，很多函数插件也是可以直接调用的。

协程：

Trafficserver的超高并发自然需要协程的概念（ng也是）。Traffic server自己实现的协程叫做continuation，结构体用TSCont表示。

一个TSCont代表一个异步执行的代码块，这个代码块拥有自己的执行状态，并且可以被

协程是用户空间管理的线程，也就是说调度算法是在用户空间的程序中实现的。可以保存程序执行的状态，可以在某时刻拉出来执行。多个协程在一个操作系统的线程上执行，或者是M个协程在N个线程上执行。如此带来的好处是可以任性的阻塞，不必担心资源的浪费问题。所以协程本质上也是一种应对阻塞调用的方式。其他的重要思想还有异步。貌似操作系统更倾向于异步，而不是倾向于协程。

Trafficserver底层大量基于异步，但向上提供的并发却大量基于协程的概念。

插件类型：

内容变换

内容变换是修改request的内容或者response的内容。由于内容是变长的，所以traffic server定义了vconnection（结构体TSVConn）和vio。Vconnection代表从一个buffer到另一个buffer的连接，经过这个连接的数据可以根据连接指定的变化方法变化。这也就是内容变换的本质。本质上TSVConn是一个continuation，所以也具备协continuation具备的数据通知能力。

而VIO是VConnection两端。一个input一个output，由于可以多个vconnection串行，所以一个vconnection的output vio就可以另一个vconnection的input。Vconnection的本质是变换，VIO的本质是内存buffer。

其他协议插件

这个就比较底层了。一般的插件都是服务于http协议的，你也可以直接跳过http协议支持别的协议，或者是支持http之上的其他协议。课件traffic server对其网络基础结构的信心。

插件提高：

每个插件都必须包含voidTSPluginInit(int argc, const char *argv[])函数，熟悉C的很容易理解，固定的名字和参数对应着固定的符号表符号，当插件被加载的时候，主程序可以直接按照这个符号表去执行就好了，这就是入口。

1.        向主程序注册插件：TSPluginRegister。可以不注册，主要是为了兼容性

2.        向某个全局钩子位置添加钩子回调：TSHttpHookAdd

a)        注册的钩子可以是全局的也可能是trasaction、session相关的。如果是transaction相关的，通过TSHttpTxn txnp = (TSHttpTxn)edata;获得transaction的指针。使用TSHttpTxnHookAdd函数添加transactionhook。

b)        如果是session相关的，使用TSHttpSsnHookAdd进行注册。Plugin中获得session的方法变为TSHttpSsn ssion = (TSHttpSsn)edata;

插件允许发起网络连接，使用TSNetConnect()发起只连接traffic server的http连接，TSHttpConnect()发起向任意地址的http连接。

cache系统：

使用ats无非就是反向代理和缓存两种，其中缓存是ats最重要的功能。要想理解ats的cache架构，理解几个关键字和概念就好了。

还有就是ats的cache可以组成集群，有两种方式：一种是配置共享的，一种是统一缓存的。配置共享的只是保证各个节点的配置是一样的，各个节点的cache还是各自缓存（重复是肯定有的），而统一缓存则是互相协作的，在多个节点之间排序缓存的，在本机找不到会自动去隔壁拉数据。

ats在使用磁盘的时候不使用文件概念，所以可以直接使用裸盘（如果你使用文件，也只有一个大文件），ats会自己安排对磁盘的使用方式和数据的组织。

概念：

代理：Http请求并不一定要全部从server获取，可以在靠近用户的机房缓存。尤其是图片视频等资源，这个缓存过程叫做代理。

新鲜度：代理必须要保证缓存的数据是当前最新的，如何与上游的服务器确认是一个专门的话题。HTTP协议本身有提供一些头部来控制缓存新鲜度。例如max-age、last-modified、expires、date等。ats根据这些头部和用户的配置计算一个对象的新鲜度，决定是否要，什么时候去server段拉取（快要过期的时候去拉取叫fuzz Revalidation）。

缓存控制：可以控制有的不缓存、当上游服务器出现拥塞的时候停止拉取、同一个url缓存不同的版本。

缓存层级：cache本身也是可以分层的，就像CPU的一级缓存、二级缓存的概念。在ats中这个概念叫做parent，每个cache可以有sibling也可以有parent，cache在本地查不到，或者在本地的集群查不到，就可以去parent去查，parent查不到再回源到后台server查询。这些缓存之间还可以使用ICP协议（缓存控制协议）查查询parent或者sibling中的缓存状态，以便更新自己的缓存。

关键字：

l  裸盘：ats的cache支持硬件存储，不但支持文件系统的文件，还支持裸盘。裸盘支持在linux中有被移除的可能，因为直接访问磁盘可以通过O_DIRECT替代。裸盘其实就是不使用文件系统的磁盘，由于没有文件系统自然也没有文件的概念。在内核中是直接走sd驱动，电梯层，到scsi到磁盘的，不需要走文件系统层和缓存层。O_DIRECT也是一样。

l  cache span：一块连续的物理存储空间，一般是一个磁盘。

l  cache volumn：一个逻辑和业务上的存储空间，可以横跨多个cache span。这就像lvm横跨多个物理磁盘划分的逻辑分区。

l  cache strip：位于cache span（volumn）上的一条一条的存储带。数据都是组织在cache strip中。

l  cache ID、cache key：cache key唯一的标示一个缓存对象，一般以url表示，cache ID则是从cache key计算得来的128位的MD5值。

l  directory：在cache strip中的数据是由directory组织的。一个cache strip中有多个directory，每个directory中有多个条目。每一个directory都对应一个cache，由cache id索引。但directory只是cache的一个索引，通过directory可以找到cache在磁盘中的信息和实体。而所有的directory都是加载到内存的，所以如果一次cache查询结果是miss，就不需要磁盘（通过url计算得到cache id，但是查询内存发现该cache id没有对应directory），就可以返回。所以directory的存在让miss过程加速，但是如果找到了directory，每一个cache查询都需要接下来读取磁盘。值得注意的是，内存中只有directory，不包含实体，并且directory的大小是固定的，磁盘大下也是固定的，只要程序启动就会尽可能多的创建最多的directory，所以程序运行的过程中ats的内存需求是不会增加的（因为可以支持的缓存数是固定的，每条缓存在内存中的记录大小也是固定的）。

l  segment、bucket: 并不是strip下面就是并排的一片directory，这些directory也是组织的。4个directory是一个bucket，多个bucket是一个segment。在每个strip的头部都有一个空闲列表，里面是每个segment的directory空闲列表，也就是说又多少个segment在strip的头部就有多少个列表。事实上，cache ID定位的并不是directory，而是bucket，strip的free list也不包含每个bucket的第一个directory，而是顺序的包含第4个、第3个、第2个。如此，来了一个cache object的cache ID（128位），就可以定位到某个bucket，然后查看该bucket的第一个directory是不是used，如果used说明整个bucket都满了（只有后面3个都用完了才会用第1个），这个cache object就添加失败了。否则就会顺序的从4/3/2/1开始使用。所以，综上可以看出，bucket实际上是一个哈希桶，用来出来哈希函数的碰撞情况，只给出了4个，说明只能处理4个cache ID一致的情况。所以segment和bucket这两种组织结构的引入，是为了解决管理问题。

l  content：我们知道directory只是元数据，是要常驻内存的，存储了cache的索引。所以可以根据directory判断一个cache是否存在。如果发现了对应的directory，就得去取directory对应的cache的真实内容，这个内容就是放在content里的，位置由directory指明。directory的数目是动态计算出来的，总大小除以平均一个对象的大小就可以获得，平均一个对象的大小可以通过proxy.config.cache.min_average_object_size进行设置，从而控制directory的数目。content的大小是动态的，也是有限的，所以当content满的时候会自动从开头开始覆盖。但是并不会更新directory。直到下一次读取到directory的时候才会发现内容不存在，从而更新directory。这里可以带来的一个问题是，通过查看directory的统计值得到的结果是不准确的，并且一旦跑满数据量一直满的。

l  fragment：由于ats的并行性，不可能一下子存储太多的连续数据。所以大文件必然要分片（否则并发的来很多大文件缓存请求将无法应对）。我们知道directory里面会指出数据再content中的位置，这里指出的只是该cache的第一个fragment，在这个fragment的头部又很多信息，包括其他的fragment到哪里去找，还包括其他的同名版本的存储directory（例如同一个url的png、jpg版本）

l  SPDY：用户与同一个IP的http通信，无论是不是同一个网站，都复用一个tcp连接。这在大部分情况下是没用的，但是在用户使用的代理的时候就用户大了。因为用户的所有http请求都是发到代理去的，使用这个协议可以一整天都只使用一个tcp连接跑http，每个网战的http流只是tcp流里面的一个stream。这对提供代理效率和减轻代理和客户端负担有很大的提高。

集群

多个cache可以配置为集群，完整的集群模式包含配置文件统一，和节点数据的交互。集群中的每个节点的配置文件是一样的，所以配置文件中不要出现本机的IP。在配置为集群模式后（这个需要每台机器单独配置），对任何一个节点的配置修改会被自动的同步到其他节点。同步配置使用多播，交换数据使用单播。

源代码与架构：

核心代码在iocore里面，iocore里面按照大功能分为了如下的几个模块。

这就要从trafficserver的架构说起了。这几个目录几乎就是traffic server的关键字：异步(aio)、缓存(cache)、集群支持(cluster)、域名解析(dns)、事件系统(eventsysytem)、上游配置(hostdb)、网络(net)。

网络与nginx的对比：http://www.cnblogs.com/liushaodong/archive/2013/02/26/2933535.html

除了提供核心程序功能，程序需要入口，入口一般是一个启动server的主程序和若干的管理程序，管理程序都在cmd目录下，每一个目录是一个管理程序：

主程序位于proxy目录下的Main.cc（.cc后缀的是C++文件的glibc后缀表示）。

常用命令

主程序名称是traffic_server，

traffic_manager：为traffic_ctl提供服务

traffic_cop：独立的监控程序，监控traffic_server和traffic_manager的职责和内存交换空间使用情况，发现异常重启进程。

traffic_crashlog：由traffic_server进程启动，在traffic_server崩溃的时候打印一个崩溃报告到log目录。

traffic_ctl：在线配置一些traffic_server可以配置的参数

traffic_logcat：将trafficserver的二进制log文件转变成可读的ASCII log

traffic_logstats：trafficserver的log分析工具

traffic_via：可以配置proxy.config.http.insert_request_via_str、proxy.config.http.insert_response_via_str两个参数使得所有的数据的http头部都携带VIA信息（表示cache状态，可以看出是从哪里拿来的），wget这个文件就会在http头部看到这个信息，而这个信息是被traffic server编码过的，使用traffic_via命令可以将这个信息解码就可以看到缓存的获取路径。

traffic_sac：standalonecollator。日志收集器，用在traffic server集群中。可以用来收集各个节点的日志集中到本机进行处理。一个节点可以不安装traffic server，只安装sac可以发挥更大的日志能力。

tspush：不需要用户请求可以直接使用这个命令将内容投递到traffic server的cache中，使用这个命令需要打开proxy.config.http.push_method_enabled 选项

tsxs：插件编译程序。用来编译和安装插件。

traffic_top：一个方便的查看当前trafficserver内部状态的程序。要编译这个必须要有libncurses5-dev库，否则会静悄悄不安装。

架构

Trafficserver虽然大部分情况跑在linux上，但是却是跨平台的。一般的操作系统都提供了网络访问的方式，但是并没有提供大量并发网络访问的方式（或许日后操作系统的API可以直接提供这个功能），所以处理大量并发需要程序自己来（有的编程语言内部封装了这部分逻辑，例如golang，就省了程序的事了）。目前处理这个问题的最常用办法就是上层抽象协程。

除了网络访问，操作系统一般也不提供特别易用的事件系统、dns系统、缓存系统、集群系统等接口。然而这些都是traffic server核心功能所要依赖的底层服务。Traffic server的应对办法是将这些服务封装，主要逻辑全部基于封装的服务，而不是操作系统的API（这里就不得不说操作系统和glibc的API不与时俱进了。。。还得别人还得自己搞）。

HTTP事务流程：

必须要理解的是trafficserver是个程序，主要的业务是无数的transaction，每个transaction都是一个用户的http连接处理，不仅包含了用户的tcp连接，还包含了traffic server与后端的通信和本地操作等。一个transaction只是用户一个tcp连接上执行的一次事务，还有一个session概念，是一个client和server之间tcp概念上的连接。一个session可以包括很多个transaction。对用户来说，一个request和response是一个transaction。