功能：
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。