Here is a simple demonstration of using pcap_next() to sniff a packet.

 #include <pcap.h>
 #include <stdio.h>

 int main(int argc, char *argv[])
 {
    pcap_t *handle;            /* Session handle */
    char *dev;            /* The device to sniff on */
    char errbuf[PCAP_ERRBUF_SIZE];    /* Error string */
    struct bpf_program fp;        /* The compiled filter */
    char filter_exp[] = "port 23";    /* The filter expression */
    bpf_u_int32 mask;        /* Our netmask */
    bpf_u_int32 net;        /* Our IP */
    struct pcap_pkthdr header;    /* The header that pcap gives us */
    const u_char *packet;        /* The actual packet */

    /* Define the device */
    dev = pcap_lookupdev(errbuf);
    if (dev == NULL) {
        fprintf(stderr, "Couldn't find default device: %s\n", errbuf);
        return(2);
    }
    /* Find the properties for the device */
    if (pcap_lookupnet(dev, &net, &mask, errbuf) == -1) {
        fprintf(stderr, "Couldn't get netmask for device %s: %s\n", dev, errbuf);
        net = 0;
        mask = 0;
    }
    /* Open the session in promiscuous mode */
    handle = pcap_open_live(dev, BUFSIZ, 1, 1000, errbuf);
    if (handle == NULL) {
        fprintf(stderr, "Couldn't open device %s: %s\n", dev, errbuf);
        return(2);
    }
    /* Compile and apply the filter */
    if (pcap_compile(handle, &fp, filter_exp, 0, net) == -1) {
        fprintf(stderr, "Couldn't parse filter %s: %s\n", filter_exp, pcap_geterr(handle));
        return(2);
    }
    if (pcap_setfilter(handle, &fp) == -1) {
        fprintf(stderr, "Couldn't install filter %s: %s\n", filter_exp, pcap_geterr(handle));
        return(2);
    }
    /* Grab a packet */
    packet = pcap_next(handle, &header);
    /* Print its length */
    printf("Jacked a packet with length of [%d]\n", header.len);
    /* And close the session */
    pcap_close(handle);
    return(0);
 }

Referenced from:https://www.tcpdump.org/pcap.html

libpcap packet capture tutorial
update:2021-11-9

/* ldev.c
   Martin Casado
   
   To compile:
   >gcc ldev.c -lpcap

   Looks for an interface, and lists the network ip
   and mask associated with that interface.
*/
#include <stdio.h>
#include <stdlib.h>
#include <pcap.h>  /* GIMME a libpcap plz! */
#include <errno.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int main(int argc, char **argv)
{
  char *dev; /* name of the device to use */ 
  char *net; /* dot notation of the network address */
  char *mask;/* dot notation of the network mask    */
  int ret;   /* return code */
  char errbuf[PCAP_ERRBUF_SIZE];
  bpf_u_int32 netp; /* ip          */
  bpf_u_int32 maskp;/* subnet mask */
  struct in_addr addr;

  /* ask pcap to find a valid device for use to sniff on */
  dev = pcap_lookupdev(errbuf);

  /* error checking */
  if(dev == NULL)
  {
   printf("%s\n",errbuf);
   exit(1);
  }

  /* print out device name */
  printf("DEV: %s\n",dev);

  /* ask pcap for the network address and mask of the device */
  ret = pcap_lookupnet(dev,&netp,&maskp,errbuf);

  if(ret == -1)
  {
   printf("%s\n",errbuf);
   exit(1);
  }

  /* get the network address in a human readable form */
  addr.s_addr = netp;
  net = inet_ntoa(addr);

  if(net == NULL)/* thanks Scott :-P */
  {
    perror("inet_ntoa");
    exit(1);
  }

  printf("NET: %s\n",net);

  /* do the same as above for the device's mask */
  addr.s_addr = maskp;
  mask = inet_ntoa(addr);
  
  if(mask == NULL)
  {
    perror("inet_ntoa");
    exit(1);
  }
  
  printf("MASK: %s\n",mask);

  return 0;
}

Did you run the program? If not, run it :-) Assuming it compiled, and ran correctly your output should be something like...

DEV: eth0
NET: 192.168.12.0
MASK: 255.255.255.0
Referenced from:http://yuba.stanford.edu/~casado/pcap/section1.html

报文封装整体结构

mac帧头定义
/数据帧定义，头14个字节，尾4个字节/
typedef struct _MAC_FRAME_HEADER
{
char m_cDstMacAddress[6]; //目的mac地址
char m_cSrcMacAddress[6]; //源mac地址
short m_cType; 　　　　　//上一层协议类型，如0x0800代表上一层是IP协议，0x0806为arp
}__attribute__((packed))MAC_FRAME_HEADER,*PMAC_FRAME_HEADER;

ip头部定义

/IP头定义，共20个字节/
typedef struct _IP_HEADER
{
char m_cVersionAndHeaderLen; 　　//版本信息(前4位)，头长度(后4位)
char m_cTypeOfService; 　　　　　 // 服务类型8位
short m_sTotalLenOfPacket; 　　　　//数据包长度
short m_sPacketID; 　　　　　　　 //数据包标识
short m_sSliceinfo; 　　　　　　　 //分片使用
char m_cTTL; 　　　　　　　　　　//存活时间
char m_cTypeOfProtocol; 　　　　　 //协议类型
short m_sCheckSum; 　　　　　　 //校验和
unsigned int m_uiSourIp; 　　　　　//源ip
unsigned int m_uiDestIp; 　　　　　//目的ip
} __attribute__((packed))IP_HEADER, *PIP_HEADER ;

版本（Version）字段：占4比特。用来表明IP协议实现的版本号，当前一般为IPv4，即0100。

报头长度（Internet Header Length，IHL）字段：占4比特。是头部占32比特的数字，包括可选项。普通IP数据报（没有任何选项），该字段的值是5，即160比特=20字节。此字段最大值为60字节。

服务类型（Type of Service ，TOS）字段：占8比特。其中前3比特为优先权子字段（Precedence，现已被忽略）。第8比特保留未用。第4至第7比特分别代表延迟、吞吐量、可靠性和花费。当它们取值为1时分别代表要求最小时延、最大吞吐量、最高可靠性和最小费用。这4比特的服务类型中只能置其中1比特为1。可以全为0，若全为0则表示一般服务。服务类型字段声明了数据报被网络系统传输时可以被怎样处理。例如：TELNET协议可能要求有最小的延迟，FTP协议（数据）可能要求有最大吞吐量，SNMP协议可能要求有最高可靠性，NNTP（Network News Transfer Protocol，网络新闻传输协议）可能要求最小费用，而ICMP协议可能无特殊要求（4比特全为0）。实际上，大部分主机会忽略这个字段，但一些动态路由协议如OSPF（Open Shortest Path First Protocol）、IS-IS（Intermediate System to Intermediate System Protocol）可以根据这些字段的值进行路由决策。

总长度字段：占16比特。指明整个数据报的长度（以字节为单位）。最大长度为65535字节。

标志字段：占16比特。用来唯一地标识主机发送的每一份数据报。通常每发一份报文，它的值会加1。

标志位字段：占3比特。标志一份数据报是否要求分段。

段偏移字段：占13比特。如果一份数据报要求分段的话，此字段指明该段偏移距原始数据报开始的位置。

生存期（TTL：Time to Live）字段：占8比特。用来设置数据报最多可以经过的路由器数。由发送数据的源主机设置，通常为32、64、128等。每经过一个路由器，其值减1，直到0时该数据报被丢弃。

协议字段：占8比特。指明IP层所封装的上层协议类型，如ICMP（1）、IGMP（2） 、TCP（6）、UDP（17）等。

头部校验和字段：占16比特。内容是根据IP头部计算得到的校验和码。计算方法是：对头部中每个16比特进行二进制反码求和。（和ICMP、IGMP、TCP、UDP不同，IP不对头部后的数据进行校验）。

源IP地址、目标IP地址字段：各占32比特。用来标明发送IP数据报文的源主机地址和接收IP报文的目标主机地址。

可选项字段：占32比特。用来定义一些任选项：如记录路径、时间戳等。这些选项很少被使用，同时并不是所有主机和路由器都支持这些选项。可选项字段的长度必须是32比特的整数倍，如果不足，必须填充0以达到此长度要求。

tcp头部定义

/TCP头定义，共20个字节/
typedef struct _TCP_HEADER
{
short m_sSourPort; 　　　　　　// 源端口号16bit
short m_sDestPort; 　　　　　　 // 目的端口号16bit
unsigned int m_uiSequNum; 　　// 序列号32bit
unsigned int m_uiAcknowledgeNum; // 确认号32bit
short m_sHeaderLenAndFlag; 　　// 前4位：TCP头长度；中6位：保留；后6位：标志位
short m_sWindowSize; 　　　　　// 窗口大小16bit
short m_sCheckSum; 　　　　　 // 检验和16bit
short m_surgentPointer; 　　　　 // 紧急数据偏移量16bit
}__attribute__((packed))TCP_HEADER, *PTCP_HEADER;
/*TCP头中的选项定义

kind(8bit)+Length(8bit，整个选项的长度，包含前两部分)+内容(如果有的话)

KIND =
1表示 无操作NOP，无后面的部分

2表示 maximum segment 后面的LENGTH就是maximum segment选项的长度（以byte为单位，1+1+内容部分长度）

3表示 windows scale 后面的LENGTH就是 windows scale选项的长度（以byte为单位，1+1+内容部分长度）

4表示 SACK permitted LENGTH为2，没有内容部分

5表示这是一个SACK包 LENGTH为2，没有内容部分

8表示时间戳，LENGTH为10，含8个字节的时间戳
*/

源、目标端口号字段：占16比特。TCP协议通过使用"端口"来标识源端和目标端的应用进程。端口号可以使用0到65535之间的任何数字。在收到服务请求时，操作系统动态地为客户端的应用程序分配端口号。在服务器端，每种服务在"众所周知的端口"（Well-Know Port）为用户提供服务。

顺序号字段：占32比特。用来标识从TCP源端向TCP目标端发送的数据字节流，它表示在这个报文段中的第一个数据字节。

确认号字段：占32比特。只有ACK标志为1时，确认号字段才有效。它包含目标端所期望收到源端的下一个数据字节。

头部长度字段：占4比特。给出头部占32比特的数目。没有任何选项字段的TCP头部长度为20字节；最多可以有60字节的TCP头部。

标志位字段（U、A、P、R、S、F）：占6比特。各比特的含义如下：

URG：紧急指针（urgent pointer）有效。
ACK：确认序号有效。
PSH：接收方应该尽快将这个报文段交给应用层。
RST：重建连接。
SYN：发起一个连接。
FIN：释放一个连接。
窗口大小字段：占16比特。此字段用来进行流量控制。单位为字节数，这个值是本机期望一次接收的字节数。
TCP校验和字段：占16比特。对整个TCP报文段，即TCP头部和TCP数据进行校验和计算，并由目标端进行验证。
紧急指针字段：占16比特。它是一个偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。
选项字段：占32比特。可能包括"窗口扩大因子"、"时间戳"等选项。

udp头部定义

/UDP头定义，共8个字节/

typedef struct _UDP_HEADER
{
unsigned short m_usSourPort; 　　　// 源端口号16bit
unsigned short m_usDestPort; 　　　// 目的端口号16bit
unsigned short m_usLength; 　　　　// 数据包长度16bit
unsigned short m_usCheckSum; 　　// 校验和16bit
}__attribute__((packed))UDP_HEADER, *PUDP_HEADER;

传输控制协议（tcp）
由于维基百科专美与前，无法写的比其更好，所以，贴它的链接在这里：

https://zh.wikipedia.org/wiki/传输控制协议#.E8.BF.90.E4.BD.9C.E6.96.B9.E5.BC.8F

主要学习它的运作方式部分，就能较好的理解操作过程了。

wireshark使用前储备：MTU和MSS
wireshark以太网帧的封包格式为：

Frame=Ethernet Header +IP Header +TCP Header +TCP Segment Data

Ethernet Header =14 Byte =Dst Physical Address（6 Byte）+ Src Physical Address（6 Byte）+Type（2 Byte），以太网帧头以下称之为数据帧。
IP Header =20 Byte（without options field），数据在IP层称为Datagram，分片称为Fragment。
TCP Header = 20 Byte（without options field），数据在TCP层称为Stream，分段称为Segment（UDP中称为Message）。
54个字节后为TCP数据负载部分（Data Portion），即应用层用户数据。

Ethernet Header以下的IP数据报最大传输单位为MTU（Maximum Transmission Unit，Effect of short board），对于大多数使用以太网的局域网来说，MTU=1500。

TCP数据包每次能够传输的最大数据分段为MSS，为了达到最佳的传输效能，在建立TCP连接时双方将协商MSS值——双方提供的MSS值中的最小值为这次连接的最大MSS值。MSS往往基于MTU计算出来，通常MSS=MTU-sizeof(IP Header)-sizeof(TCP Header)=1500-20-20=1460。

这样，数据经过本地TCP层分段后，交给本地IP层，在本地IP层就不需要分片了。但是在下一跳路由（Next Hop）的邻居路由器上可能发生IP分片！因为路由器的网卡的MTU可能小于需要转发的IP数据报的大小。

这时候，在路由器上可能发生两种情况：

（1）如果源发送端设置了这个IP数据包可以分片（May Fragment，DF=0），路由器将IP数据报分片后转发。

（2）如果源发送端设置了这个IP数据报不可以分片（Don’t Fragment，DF=1），路由器将IP数据报丢弃，并发送ICMP分片错误消息给源发送端。

wireshark实战
一个简单的请求示例截图如图：

从左到有依次为no（Frame编号)、Time(时间)、Source（源地址）、Destination(目的地址)、Protocal（协议）、Length（包大小）、Info（详细信息）。

tcp请求与回复的info中包括：端口信息（如63703->8279）表示src.port -> des.port，标志位信息（如SYN、ACK）、Seq信息、Ack信息（注意，这个ack是确认号字段m_uiAcknowledgeNum）、len（上层数据长度）、MSS（mss长度）、WS（窗口大小字段）。

实际操作中，头部为66字节，是因为加了12字节的tcp选项信息。实际MSS为1460.

每条数据的详细信息都可以在选中数据后在下方显示，如图：

从上到下依次为Frame（整个桢信息）、Ethernet II（以太头信息）、Internet Protocal Version(IP头信息)、Transmission Control Protocal（TCP头信息），点开后每一个字段的详细信息都可显示，与协议一致。

结合实践分析tcp运作方式

三次握手：tcp通过三次握手创建链接，如图，

首先63703->8279 发送SYN，Seq=0;然后8279->63703, 发送SYN&&ACK, Seq=0, Ack=1;最后63703->8279 发送ACK,Seq=1，Ack=1。这样就完成了三次握手。

与维基百科中的相关知识，做对照，发现完全符合实践:

1.客户端通过向服务器端发送一个SYN来创建一个主动打开，作为三路握手的一部分。客户端把这段连接的序号设定为随机数A。 首先63703->8279 发送SYN，Seq=0 A=0.

2.服务器端应当为一个合法的SYN回送一个SYN/ACK。ACK的确认码应为A+1，SYN/ACK包本身又有一个随机序号B。 然后8279->63703, 发送SYN&&ACK, Seq=0, Ack=1 B=0

3.最后，客户端再发送一个ACK。当服务端受到这个ACK的时候，就完成了三路握手，并进入了连接创建状态。此时包序号被设定为收到的确认号A+1，而响应则为B+1。 最后63703->8279 发送ACK,Seq=1，Ack=1。这样就完成了三次握手。

数据传输：69和70是一个http请求，因为包过长，切分成两个tcp包。75和76分别对这两个包进行ack响应，告知已经收到。81则对请求做了业务上的响应返回。而82则是对81的ack响应。（未贴出数据：69：Seq=1,Ack=1,Len=1448 ; 70:Seq=1449,Ack=1,Len=112 ; 81:Seq=1, Ack=1561, Len=123）。分析上述几条数据我们发现，Seq的递增主要是看上一条发送数据的Len，如Seq70 = Seq69 + Len69。而一条数据的ack信息的ack值也是看请求数据的seq和len。如75是对69的ack，则Ack75=Seq69+Len69。这一规律也符合协议规定。具体见维基百科数据传输举例。当然，也有选择确认（Selective Acknowledgement）的示例，就不贴出来了。

选择确认：TCP报文的接收者为了确保可靠性，在接收到一定数量的连续字节流后才发送确认。

Wireshark（前称Ethereal）是一个网络封包分析软件。网络封包分析软件的功能是撷取网络封包，并尽可能显示出最为详细的网络封包资料。Wireshark使用WinPCAP作为接口，直接与网卡进行数据报文交换。作为一个免费的软件，真的非常好用。

参考资料：

1. 传输控制协议,维基百科，https://zh.wikipedia.org/wiki/传输控制协议#.E5.BB.BA.E7.AB.8B.E9.80.9A.E8.B7.AF

2.TCP通信流程解析，CSDN博客，http://blog.csdn.net/phunxm/article/details/5836034

3.IP头、TCP头、UDP头详解以及定义，CSDN博客,http://blog.csdn.net/mrwangwang/article/details/8537775#comments

Referenced from:https://www.cnblogs.com/shenpengyan/p/5912567.html

tcpkill工作原理分析 - 网易数帆 - 博客园
update:2021-11-9
服务器上突然出现了许多来自未知ip的网络连接与流量，我们需要第一时间切断这些可能有害的网络连接。除了iptables/ipset, blackhole routing这些常规手段，我们还可以借助一些更轻量级的小工具来临时处理这些情况，如tcpkill。

tcpkill使用简介
tcpkill是一个网络分析工具集dsniff中的一个小工具。在Debian/Ubuntu上可以直接通过dsniff包安装：

 aptitude install dsniff

tcpkill使用的语法和tcpdump几乎一致：

tcpkill [-i interface] [-1...9] expression
其中第一个参数 -i 指定网卡设备。

第二个参数指定“kill”的强制等级，越高越强，默认为3，我们在后面了解tcpkill的工作原理后会知道这个参数的具体作用。

第三个参数则是匹配需要kill的tcp连接通配表达式，语法与tcpdump使用的pcap-filter完全一样。

如果我们需要使用tcpkill临时禁止服务器与主机10.0.0.1的tcp连接，可以在服务器上输入命令：

 tcpkill host 10.0.0.1

tcpkill会一直阻止主机10.0.0.1与服务器的网络连接，直到你结束这个tcpkill进程为止。

tcpkill原理分析
在使用tcpkill时，会发现一件奇怪的事情，运行tcpkill命令后并不会马上中断匹配的tcp连接，只有当该连接有新的tcp包发送接收时，tcpkill才会“kill”这个tcp连接。这个奇怪的现象燃起了我们的好奇心，于是探索一下tcpkill到底是如何工作的。

下面以Linux下的nc命令为例。

我们在两个主机hostA与hostB间通过nc命令建立一个tcp连接：

hostA在本地tcp 5555端口监听

hostA$ nc -l -p 5555
hostB通过本地6666端口连接hostA的5555端口

hostB$ nc hostA 5555 -p 6666
此时在hostA上已经可以观察到一条与hostB的ESTABLISHED连接

hostA$ netstat -anp|grep 5555tcp        0      0 hostA:5555    hostB:6666     ESTABLISHED 19638/nc
在hostA上通过tcpdump也可以观察到3次握手已经完成

hostA# tcpdump -i eth1 port 5555IP hostB.6666 > hostA.5555: Flags [S], seq 750827752, ...IP hostA.5555 > hostB.6666: Flags [S.], seq 1191909671, ack 750827753, ...IP hostB.6666 > hostA.5555: Flags [.], ack 1, win 115, ...
如果此时运行tcpkill命令尝试“kill”这个tcp连接

hostA# tcpkill -1 -i eth1 port 5555tcpkill: listening on eth1 [port 5555]
会发现hostA与hostB上的nc命令并没有受到任何影响而退出，hostA上观察到该tcp连接还是ESTABLISHED状态，tcpdump与tcpkill也没有任何新的输出。

hostA$ netstat -anp|grep 5555tcp        0      0 hostA:5555    hostB:6666     ESTABLISHED 19638/nc
运行tcpkill命令后，建立好的tcp连接并没有受到任何影响。

如果我们此时在hostB的nc上输入任意字符发送，则会发现这时tcp连接中断，nc发送失败退出。

hostB$ nc hostA 5555 -p 6666a<CR>(exit)
hostB$
hostA上的nc监听进程也因为连接中断而退出

hostA$ nc -l -p 5555(exit)
hostA$
netstat已经观察不到这个tcp连接，而tcpdump此时则捕获了一个新tcp rst包：

hostA# tcpdump -i eth1 port 5555IP hostB.6666 > hostA.5555: Flags [S], seq 750827752, ...IP hostA.5555 > hostB.6666: Flags [S.], seq 1191909671, ack 750827753, ...IP hostB.6666 > hostA.5555: Flags [.], ack 1, win 115, ...IP hostA.5555 > hostB.6666: Flags [R], seq 1191909672, ...
此时tcpkill的输出

hostA# tcpkill -1 -i eth1 port 5555tcpkill: listening on eth1 [port 5555]hostB:6666 > hostA:5555: R 1191909672:1191909672(0) win 0hostA:5555 > hostB:6666: R 750827755:750827755(0) win 0
相信看到这里，已经可以明白tcpkill的工作原理，实际上就是通过双向fake tcp rst包重置目标连接双方的网络连接，和某墙的原理一样。

而之所以tcpkill不会马上中断目标tcp连接，是因为伪造tcp rst包时，需要填入正确的sequence number，这需要通过拦截双方的tcp通信才能实时得到。所以运行tcpkill后，只有目标连接有新tcp包发送/接受才会导致tcp连接中断。

最后分析一下tcpkill第二个参数的具体作用。manpage里的说明比较模糊，只能看出和receive window有关：

-1...9 Specify the degree of brute force to use in killing a connection. Fast connections may require a higher number in order to land a RST in the moving receive window. Default is 3.

直接看源代码(只有100多行)

...intmain(int argc, char *argv[]){
    ...    / 通过libpcap抓取所有符合条件的包，回调函数为tcp_kill_cb /
    pcap_loop(pd, -1, tcp_kill_cb, (u_char *)&sock);

    ...
}static voidtcp_kill_cb(u_char user, const struct pcap_pkthdr pcap, const u_char *pkt){
    ...    / 只处理tcp包 /
    ip = (struct libnet_ip_hdr )pkt;    if (ip->ip_p != IPPROTO_TCP)        return;    / 不处理tcp syn/fin/rst包 */
    tcp = (struct libnet_tcp_hdr )(pkt + (ip->ip_hl << 2));    if (tcp->th_flags & (TH_SYN|TH_FIN|TH_RST))        return;            / 伪造ip包 */
    libnet_build_ip(TCP_H, 0, 0, 0, 64, IPPROTO_TCP,
            ip->ip_dst.s_addr, ip->ip_src.s_addr,
            NULL, 0, buf);    / 伪造tcp rst包 /
    libnet_build_tcp(ntohs(tcp->th_dport), ntohs(tcp->th_sport),            0, 0, TH_RST, 0, 0, NULL, 0, buf + IP_H);    / fake tcp rst包的sequence number即为抓到的包的ack number /
    seq = ntohl(tcp->th_ack);

    ...    / 这里Opt_severity即为tcpkill的第二个参数 /
    win = ntohs(tcp->th_win);    for (i = 0; i < Opt_severity; i++) {
        ip->ip_id = libnet_get_prand(PRu16);
        seq += (i * win);
        tcp->th_seq = htonl(seq);

        libnet_do_checksum(buf, IPPROTO_TCP, TCP_H);                    / 发送伪造的tcp rst包 /
        if (libnet_write_ip(*sock, buf, sizeof(buf)) < 0)
            warn("write_ip");

        fprintf(stderr, "%s R %lu:%lu(0) win 0n", ctext, seq, seq);
    }
}
从上面可以看出，tcpkill的第二个参数，实际上就是沿tcp连接窗口滑动而发送的tcp rst包个数。将这个参数设置较大主要是为了应对高速tcp连接的情况。

参数的大小从中断tcp连接的原理上没有区别，只是发送rst包数量的差异，通常情况下使用默认值3已经完全没有问题了。所以使用tcpkill时请不要像网络上某些中文教程中一样不适当的使用参数 -9 。
Referenced from:https://www.cnblogs.com/163yun/p/9895464.html

tcpdump输出的时候,看到Flags[S],Flags[.],Flags[S.],Flags[P]

tcpdump -i lo tcp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
17:25:17.944030 IP localhost.http > localhost.39740: Flags [F.], seq 1095695913, ack 4186916696, win 512, options [nop,nop,TS val 932462 ecr 927461], length 0
17:25:17.944106 IP localhost.http > localhost.39738: Flags [F.], seq 2896031688, ack 35398580, win 512, options [nop,nop,TS val 932462 ecr 927458], length 0
17:25:17.987834 IP localhost.39738 > localhost.http: Flags [.], ack 1, win 1535, options [nop,nop,TS val 932506 ecr 932462], length 0
17:25:17.987860 IP localhost.39740 > localhost.http: Flags [.], ack 1, win 1535, options [nop,nop,TS val 932506 ecr 932462], length 0
17:25:18.542714 IP localhost.39738 > localhost.http: Flags [F.], seq 1, ack 1, win 1535, options [nop,nop,TS val 933061 ecr 932462], length 0
17:25:18.542754 IP localhost.http > localhost.39738: Flags [.], ack 2, win 512, options [nop,nop,TS val 933061 ecr 933061], length 0
17:25:18.542932 IP localhost.46984 > localhost.9614: Flags [S], seq 3512844352, win 65495, options [mss 65495,sackOK,TS val 933061 ecr 0,nop,wscale 7], length 0
17:25:18.542951 IP localhost.9614 > localhost.46984: Flags [R.], seq 0, ack 3512844353, win 0, length 0

 Tcpflags are some combination of S (SYN), F (FIN), P (PUSH), R (RST), U (URG), W (ECN CWR), E
       (ECN-Echo)  or  `.' (ACK), or `none' if no flags are set.  Data-seqno describes the portion of sequence space covered by the data in this packet (see example be‐
       Iptype, Src, dst, and flags are always present.  The other fields depend on the contents of the packet's TCP protocol header and are output only if appropriate.
       Some offsets and field values may be expressed as names rather than as numeric values. For example tcp[13] may be replaced with tcp[tcpflags]. The following  TCP
                   tcpdump -i xl0 'tcp[tcpflags] & tcp-push != 0'