文档分级模板库
Tika可自动对各种格式的文档进行分析，调用其parse方法得到的结果为xhtml sax类型（跟html很像)，得到的这种格式的内容很容易能获取到其标题，副标题，内容等信息(根据各种label定位即可)。
Tika使用Apache POI提供的库进行office文档的分析，使用Apache PDFBox进行pdf分析，使用标准的javax.swing.text.rtf进行rtf文档分析，使用ICU(检测文档编码方式的工具)分析text文档。
文件截获
应用层协议
-
- 请求报文格式：
<request-line>
<headers>
<blank line>
[<request-body>]
request-line由请求方法、URL和HTTP协议版本3个字段组成，他们之间用空格隔开。其中，请求方法有GET,POST,HEAD,PUT,DELETE,OPTIONS,TRACE几种。 URL由相对url和请求参数和请求值构成。
headers由关键字/值对组成，每行一对，关键字和值用英文冒号”:“分隔。它有4类:通用头，请求头，响应头和实体头。常用的有：
Host：要请求的主机名，如Host:www.google.cn
connection：连接方式(close 或 keep-alive)。Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。
Accept-Language：客户端可接受的自然语言。如zh-ch
Accept-Encoding：客户端可接受的编码压缩格式，如gzip, deflate
User-Agent：产生请求的浏览器类型。浏览器UA字串的标准格式为：浏览器标识 (操作系统标识; 加密等级标识; 浏览器语言) 渲染引擎标识 版本信息。如Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld)
Content - Length：表示请求消息正文的长度。
Pragma：指定“no - cache”值表示服务器必须返回一个刷新后的文档，即使它是代理服务器而且已经有了页面的本地拷贝。
最后一个请求头部之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头部。
响应报文格式:
<status-line> <headers> <blank line> [<response-body>]
status-line由HTTP协议版本、服务器返回的响应状态码和响应状态码的文本描述组成。
headers里面有个Content-type指明了内容的格式，如text/html;charset=ISO-8859-1
response-body即为响应的内容
参照响应状态码的说明，要获取html传输的数据,只需要处理状态码为OK的响应报文，抽取其中的response-body即可。控制指令可以忽略。
ftp报文
ftp报文控制指令有其专属的规范，见1，主要关注PORT命令和RETR命令。PORT ip,port指明客户端希望服务器往哪里发数据，RETR file指明要请求哪个文件。
根据2中的代码，可以看到对于传输的文件，ftp并不添加任何头，直接就是将文件用socket传输。
根据以上认识，当截获的ftp命令包为RETR命令时，截获发送到前述ip:port的数据包即为发送的文件。
电子邮件运作方式
- 邮件传输采用SMTP协议
- 邮件接收(从mailbox或邮件服务器查看或接收邮件)采用:
- POP3:当客户端收到邮件后，默认删除mailbox里的内容
- IMAP:收到邮件后，不删除mailbox内容，需要限制每个用户mailbox容量。
stmp报文(邮件传输)
主要的两条命令为DATA和354号应答。前者指明后面将发送邮件内容，后者指明发送方可以开始邮件输入，跟在这两个包后面的来自发送方(发起连接的一方)的数据包即为邮件内容。
- 发送
- 发送到收件方mailbox（发送附件):
- 发送
S stands for client, R stands for server，sentence after the number explains the number.
S: MAIL FROM:<[email protected]> //发件人
R: 250 OK
S: RCPT TO:<[email protected]> //收件人
R: 250 OK
S: DATA //
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: FROM: [email protected]
TO: [email protected]
SUBJECT: this is a test
Date: Fri, 8 Jan 2010 16:12:30
X-Mailer: shadowstar's mailer
MIME-Version: 1.0
Content-type: multipart/mixed; boundary=\"#BOUNDARY#\"
--#BOUNDARY# // 正文
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: quoted-printable
邮件正文……….
--#BOUNDARY# // 附件
Content-Type: application/octet-stream; name=att.txt
Content-Disposition: attachment; filename=att.txt
Content-Transfer-Encoding: base64
附件正信息(base64 编码)…..
S: .
R: 250 OK
发送到收件客户端(以下命令替代MAIL FROM)
SEND FROM：只发送到对方邮件客户端，对方不活跃时失败 SOML FROM：收件客户端活跃时发送到客户端，不活跃时发送到mailbox SAML FROM：肯定发送到对方mailbox，客户端活跃时也发送到客户端
考虑到我们只需要检测发出去的包，所以没有详细看POP3/IMAP。
应用层协议识别
许多应用层协议都有自己缺省的端口号，用这个端口号可以加以区别:
FTP的端口是 21
pop3\smtp 的端口号是 110/25
HTTP通信用的端口号是80
其中,ftp需要根据初始的数据包来确定之后使用的端口。它有两种工作模式，positive/passive，均开始于客户端向服务器21号端口发起连接。对于positive,服务器固定使用20号端口建立连接进行数据传输，而客户端则使用PORT命令附加的地址和端口；对于passive模式而言,客户端先用N(N>1024)端口与服务器连接，并发送PASV命令，服务器收到后发送PORt p 告诉客户机跟它哪个端口建立连接，客户机便用N+1号窗口跟p建立连接。
根据上面的描述，通过一开始发往21号端口的数据包的交流信息便可以定位出之后的哪条连接是ftp传输文件的连接了并从而能解释该数据报了。
Xplico
Xplico主要作用是捕获网络应用层数据并显示出来，这指的是通过捕获Internet网络流量来提取各种网络应用中所包含的数据,并从中分析出各种不同的网络应用。例如Xplico可以实时解析通过网关的流量,也可以pcap文件中解析出IP流量数据,并解析每个邮箱(包括POP、IMAP和SMTP协议),解析HTTP内容，以及VOIP应用等。
简单的用法:
实时解析经过某个以太网接口(e.g.eth0)的数据包
./xplico -m rltm -i eth0
解析已捕获的pcap文件
./xplico -m pcap -f test.pcap
需解决的问题是pcap文件获得途径和如何在源程序中直接调用某个接口实现该功能。
xplico采用libpcap作为捕获网络包的接口,libcap捕获的是以太帧,故而xplico分析的pcap文件亦为链路层数据包。xplico源码中的prot.c包含了解析各种协议格式的控制过程，主要方法为PktDissector。经试验，对于官网给的ftp包，其解析结果为一些bin文件，不具有可读性(这里由于不知道传得是什么所以不好下结论)；对于http包，其解析结果包含请求的文件(这里为一些图片)和类似于上面描述http的报文格式的文件，没有把内容抽离开；对于POP3包，结果只是一些kml文件(用来描述主机地理位置，其他协议的数据包也有)。
- 我觉得只需参考xplico的协议识别过程，目前看来其应用层协议解析也没有很细，更多的是将报文归类后直接展示报文。
- 考虑再看看capanalysis
数据链路层协议
-
PPP帧以标志字符01111110开始和结束，地址字段长度为1字节，内容为标准广播地址11111111，控制字段为00000011。协议字段长度为2个字节，其值代表其后的数据字段所属的网络层协议，如：0x0021代表IP协议，0xC021代表LCP数据，0x8021代表NCP数据等。数据字段包含协议字段中指定的协议的数据报，长度为0～1500字节。CRC字段为整个帧的循环冗余校验码，用来检测传输中可能出现的数据错误。
根据第4、5个字节即可知道载荷该用什么协议解析。
传输层协议
TCP报文
tcp 头从第 128bits 的 4bits 指示了有效载荷的起始位置
UDP报文
udp 头从第 64bits 开始是数据内容，第 32bits 开始的 2 个 Bytes 标记了数据报首部和实际数据内容的总长度。
网络层协议
ip报文
ip 头从 4bits 开始的 4bits 指示报头长度，16bits 开始的 16bits 指示报文总长，51bits 开始的13bits 指示该 IP 包在该组分片包中位置，接收端靠此来组装还原 IP 包。
根据上次文档中提到的设置网卡为混杂模式截获经过该中间层的数据包后，可根据上述描述的协议信息进行数据包的协议解析以提取出最终的有效内容。其中，该用哪个应用层协议来解析tcp包中的数据部分仍然疑惑。另外，如何重组数据链路层的帧，ip层的包也待了解。
ip分包重组
ipv4头部从第32bit开始的32bits记录了分片信息。其中第32~47bits标示了该分片属于哪个数据包(一个数据包可能被分成多个分片进行网络帧转发),第48bit标示是否在它之后还有该数据包的分片，1代表有；第49bit标示是否允许分片，0代表允许；第51~63bits代表该分片在数据段中的相对位置，以8Bytes为偏移单位。
根据以上头部信息便可以重组出被分包的某个数据报。
IP分片只有第一个带有传输层或ICMP首部，其余的分片只有IP头。
至此可以得到一个网络层的数据包。
tcp分段重组
udp一般不分段，数据包太大则在ip层分片传输;tcp一般执行分段，在ip层一般不用分片。tcp头的32~64bits标示了本tcp报文的序号，根据这个序号重组报文即可。tcp头的第143bit标示了报文的结束。
至此可以得到传输层的数据包。
路由转发过程
以下省略arp寻址过程，并且专门讨论有内外网数据传输的情况。
考虑以下情景，内网中一台主机A发送数据给另一个网段的主机B，则过程如下:
- 1.A根据其网关的mac地址将数据包发送到网关
- 2.网关接收数据包，对数据链路层的帧头进行拆包，从获得的ip包包头中获取ip地址，根据路由表转发
- 3.转发的数据包保留源和目的ip地址，将源mac地址替换为转发出的端口的mac地址，目的mac替换为路由表显示的下一跳的ip对应的mac地址。
- 4.下一跳接收数据包，重复2,3步操作直至B收到数据包。
内网要跟外网交互，需要通过网关，网关含有至少两个网卡，一个跟内网通信，一个跟外网通信。
根据以上信息，截获数据包后，只需修改数据包的源(改为内网网卡)与目标(改为外网网卡)mac地址，转发出去即可。
以太帧转发
自己理解可以使用如下:
fd=socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
sendto(fd,&req,sizeof(req),0,(struct sockaddr*)&addr,sizeof(addr)
其中，req即为数据包的内容(现在的理解是接收到的包除去以太帧头的部分),addr即为远端目的地址，其格式参看连接1的sockaddr_ll。
另外怀疑可以使用SOCK_DRAM类型的socket来使其自动添加以太网头，待尝试。
NAT转换
内网连接外网还要通过nat地址转换将内网地址转换为公网地址,当IP包经过NAT网关时，NAT Gateway会将IP包的源IP转换为NAT Gateway的公共IP并转发到公共网，此时IP包中已经不含任何私有网IP的信息。如果内网主机发出的请求包未经过NAT，那么当Web Server收到请求包，回复的响应包中的目的地址就是私网IP地址，在Internet上无法正确送达，导致连接失败。NAT Gateway在收到响应包后，就需要判断将数据包转发给谁。此时如果子网内仅有少量客户机，可以用静态NAT手工指定；但如果内网有多台客户机，并且各自访问不同网站，这时候就需要连接跟踪（connection track）。
捕获数据包后要能使网络正常运转，这部分貌似也得做...