什么是tcpdump，tcpdump是Linux上一个强大的网络请求采集工具。它可以将网络中传送的数据包完全截获下来提供分析。它支持针对网络层、协议、主机、网络或端口的过滤，并提供and、or、not等逻辑语句来帮助你去掉无用的信息。
- 通过yum直接安装：yum install tcpdump;
- 通过rpm包安装：rpm -ivh tcpdump.rpm；
- 离线安装，需要安装libcap，通过./configure make install 安装相关包链接: tcpdump.
为方便查看，我们一般会选择将tcpdump 根据条件抓取主机上的请求数据包写入cap/pcap 文件，在请求量比较大的服务器或者设置过滤条件不合理，会导致抓到的数据包很庞大，因此抓包前需考虑好分包和磁盘空间，以免造成生产异常。下面开始介绍tcpdump 基本操作。
使用：tcpdump 参数；参数列表可通过help查看。默认tcpdump 命令直接运行，将监视第一个网络接口上所有流过的数据包。
其详细参数如下：
这里列出自己比较常用的命令：
#抓取全量包，以50M分一个包
tcpdump -i any -s0 -C 50 -w /1.cap
#抓50个包，全量
tcpdump -i any -s0 -c 50 -w /1.cap
#抓1分钟包，全量
tcpdump -i any -s0 -G 60 -w /1.cap
#根据目标IP，指定网卡
tcpdump -i eth0 -s0 dst 127.0.0.1 and port 80 -n -w /1.cap
记录该命令以供参考，来源Linux命令大全：
直接启动tcpdump将监视第一个网络接口上所有流过的数据包tcpdump
监视指定网络接口的数据包tcpdump -i eth1
如果不指定网卡，默认tcpdump只会监视第一个网络接口，一般是eth0，下面的例子都没有指定网络接口。
监视指定主机的数据包打印所有进入或离开sundown的数据包。
tcpdump host sundown
指定ip,例如截获所有210.27.48.1 的主机收到的和发出的所有的数据包
tcpdump host 210.27.48.1
打印helios 与 hot 或者与 ace 之间通信的数据包
tcpdump host helios and ( hot or ace )
截获主机210.27.48.1 和主机210.27.48.2 或210.27.48.3的通信
tcpdump host 210.27.48.1 and \ (210.27.48.2 or 210.27.48.3 )
打印ace与任何其他主机之间通信的IP 数据包, 但不包括与helios之间的数据包.
tcpdump IP host ace and not helios
如果想要获取主机210.27.48.1除了和主机210.27.48.2之外所有主机通信的ip包，使用命令：
tcpdump ip host 210.27.48.1 and ! 210.27.48.2
截获主机hostname发送的所有数据
tcpdump -i eth0 src host hostname
监视所有送到主机hostname的数据包
tcpdump -i eth0 dst host hostname
监视指定主机和端口的数据包如果想要获取主机210.27.48.1接收或发出的telnet包，使用如下命令
tcpdump tcp port 23 host 210.27.48.1
对本机的udp 123 端口进行监视 123 为ntp的服务端口
tcpdump udp port 123
监视指定网络的数据包打印本地主机与Berkeley网络上的主机之间的所有通信数据包
tcpdump net ucb-etherucb-ether此处可理解为“Berkeley网络”的网络地址，此表达式最原始的含义可表达为：打印网络地址为ucb-ether的所有数据包
打印所有通过网关snup的ftp数据包
tcpdump ‘gateway snup and (port ftp or ftp-data)’注意：表达式被单引号括起来了，这可以防止shell对其中的括号进行错误解析
打印所有源地址或目标地址是本地主机的IP数据包
tcpdump ip and not net localnet如果本地网络通过网关连到了另一网络，则另一网络并不能算作本地网络。TCP 连接断开简述抓到包后，一般通过嗅探包解析工具进行分析。我们这边采用 Wireshark 进行分析，在此也通过 wireshark 进行讲解。
在讲述 wireshark 分析 tcpdump 前，需要先了解 TCP 协议及其传输数据过程，以便理解数据库含义。
在此仅讲述 tcp 连接、断开过程中的 3 次握手和 4 次挥手过程
tcp 三次握手TCP 提供面向有连接的通信传输。面向有连接是指在数据通信开始之前先做好两端连接工作。所谓三次握手，是指建立一个 TCP 连接时需要客户端和服务端总共发送三个包已确认连接的建立。先来了解下相关名词：
字段
含义
URG
紧急指针是否有效。为1，表示某一位需要优先被处理
ACK
确认号是否有效。一般置为1
PSH
提示接收端应用程序立即从TCP缓冲区把数据读走
RST
对方要求重建连接，复位
syn
请求建立连接，并在其序列号的字段进行序列号的初始设定，建立连接，设置为1
FIN
希望断开连接
三次握手详图如下：
三次握手的过程如下第一次：客户端尝试连接服务器，向服务器发送 syn 包（同步序列编号 Synchronize Sequence Numbers），syn=j，客户端进入 SYN_SEND 状态等待服务器确认。第二次：服务器接收客户端 syn 包并确认（ack=j 1），同时向客户端发送一个 SYN 包（syn=k），即 SYN ACK 包，此时服务器进入 SYN_RECV 状态第三次：客户端收到服务器的 SYN ACK 包，向服务器发送确认包 ACK(ack=k 1），此包发送完毕，客户端和服务器进入 ESTABLISHED 状态，完成三次握手
当三次连接完成后，客户端和服务端便可以开始通信在通信过程中，依旧采用一问一答模式。
tcp四次挥手四次挥手，是指在客户端和服务端断开时，需要发送四个包以进行断开确认四次挥手详图如下：
四次挥手过程如下：第一次：客户端发出释放 FIN=1，自己序列号 seq=u，进入 FIN-WAIT-1 状态。第二次：服务器收到客户端的后，发出 ACK=1 确认标志和客户端的确认号 ack=u 1，自己的序列号 seq=v，进入 CLOSE-WAIT 状态。第三次：客户端收到服务器确认结果后，进入 FIN-WAIT-2 状态。此时服务器发送释放 FIN=1 信号，确认标志 ACK=1，确认序号 ack=u 1，自己序号 seq=w，服务器进入 LAST-ACK（最后确认态）。第四次：客户端收到回复后，发送确认 ACK=1，ack=w 1，自己的 seq=u 1，客户端进入 TIME-WAIT（时间等待）。客户端经过 2 个最长报文段寿命后，客户端 CLOSE；服务器收到确认后，立刻进入 CLOSE 状态。
四次挥手过程理解：
一些补充问题1.为什么连接的时候是三次握手，关闭的时候却是四次握手？
- 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为 seq=u（等于前面已经传送过来的数据的最后一个字节的序号加 1），此时，客户端进入 FIN-WAIT-1（终止等待 1）状态。 TCP 规定，FIN 报文段即使不携带数据，也要消耗一个序号。
- 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u 1，并且带上自己的序列号 seq=v，此时，服务端就进入了 CLOSE-WAIT（关闭等待）状态。TCP 服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个 CLOSE-WAIT 状态持续的时间。
- 客户端收到服务器的确认请求后，此时，客户端就进入 FIN-WAIT-2（终止等待 2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
- 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u 1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为 seq=w，此时，服务器就进入了 LAST-ACK（最后确认）状态，等待客户端的确认。
- 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w 1，而自己的序列号是 seq=u 1，此时，客户端就进入了 TIME-WAIT（时间等待）状态。注意此时 TCP 连接还没有释放，必须经过 2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的 TCB 后，才进入 CLOSED 状态。
- 服务器只要收到了客户端发出的确认，立即进入 CLOSED 状态。同样，撤销 TCB 后，就结束了这次的 TCP 连接。可以看到，服务器结束 TCP 连接的时间要比客户端早一些。
因为当 Server 端收到 Client 端的 SYN 连接请求报文后，可以直接发送 SYN ACK 报文。其中 ACK 报文是用来应答的，SYN 报文是用来同步的。但是关闭连接时，当 Server 端收到 FIN 报文时，很可能并不会立即关闭 SOCKET，所以只能先回复一个 ACK 报文，告诉 Client 端，“你发的 FIN 报文我收到了”。只有等到我 Server 端所有的报文都发送完了，我才能发送 FIN 报文，因此不能一起发送。故需要四步握手。
2.四次挥手过程中为什么等待 2msl？1.为了保证 A 发送的最后一个 ACK 报文段能够到达 B。这个 ACK 报文段有可能丢失，因而使处在 LAST-ACK 状态的 B 收不到对已发送的 FN ACK 报文段的确认。B 会超时重传这个 FIN ACK 报文段，而 A 就能在 2MSL 时间内收到这个重传的 FN ACK 报文段。接着 A 重传一次确认，重新启动 2MSL 计时器。最后，A 和 B 都正常进入到 CLOSED 状态。如果 A 在 TIME-WAIT 状态不等待一段时间，而是在发送完 ACK 报文段后立即释放连接，那么就无法收到 B 重传的 FIN ACK 报文段，因而也不会再发送一次确认报文段。这样，B 就无法按照正常步骤进入 CLOSED 状态。
2.防止之前提到的“已失效的连接请求报文段”出现在本连接中。A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段 B 只要收到了 A 发出的确认，就进入 CLOSED 状态。同样，B 在撤销相应的传输控制块 TCB 后，就结束了这次的 TCP 连接。我们注意到，B 结束 TCP 连接的时间要比 A 早些。
3.为什么不能用两次握手进行连接？3 次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机 S 和 C 之间的通信，假定 C 给 S 发送一个连接请求分组，S 收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S 认为连接已经成功地建立了，可以开始发送数据分组。可是，C 在 S 的应答分组在传输中被丢失的情况下，将不知道 S 是否已准备好，不知道 S 建立什么样的序列号，C 甚至怀疑 S 是否收到自己的连接请求分组。在这种情况下，C 认为连接还未建立成功，将忽略 S 发来的任何数据分 组，只等待连接确认应答分组。而 S 在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
4.如果已经建立了连接，但是客户端突然出现故障了怎么办？TCP 还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为 2 小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔 75 秒钟发送一次。若一连发送 10 个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
wireshark 相关过滤器语法如下：1、抓包过滤器语法和实例
抓包过滤器类型 Type（host、net、port）、方向 Dir（src、dst）、协议 Proto（ether、ip、tcp、udp、http、ICMP、ftp 等）、逻辑运算符（&& 与、|| 或、！非）（1）协议过滤
比较简单，直接在抓包过滤框中直接输入协议名即可。 TCP，只显示 TCP 协议的数据包列表 HTTP，只查看 HTTP 协议的数据包列表 ICMP，只显示 ICMP 协议的数据包列表（2）IP 过滤
host 192.168.1.104 src host 192.168.1.104 dst host 192.168.1.104（3）端口过滤
port 80 src port 80 dst port 80（4）逻辑运算符&& 与、|| 或、！非
wireshark 颜色规则
src host 192.168.1.104 && dst port 80 抓取主机地址为 192.168.1.80、目的端口为 80 的数据包 host 192.168.1.104 || host 192.168.1.102 抓取主机为192.168.1.104 或者192.168.1.102 的数据包 ！broadcast 不抓取广播数据包wireshark提供了着色分析，即不通数据包通过不同颜色标明，也可以已在自定义，通过试图–>着色规则可查看
常见异常项在抓取到的包中，通常会存在这一些异常包说明，常见的TCP错误如下：
Follow TCP
- Tcp previous segment lost（tcp 先前的分片丢失）可能原因，网络拥堵导致丢包
- tcp previous segment not captured（tcp先前分片未捕获）报文没有捕捉到，出现报文的丢失。
- Tcpacked lost segment（tcp 应答丢失）TCP 的重传包迟迟没有到来，可能是发送方关闭了连接，或者是重传包来之前就中断了抓包
- Tcp window update（tcp 窗口更新）是 TCP 通信中的一个状态，它可以发生的原因有很多，但最终归结于发送者传输数据的速度比接收者读取的数据还快，这使得接受端的在缓冲区必须释放一部分空间来装发送过来的数据，然后向发送者发送 Windows Update，告诉给发送者应该以多大的速度发送数据，从而使得数据传输与接受恢复正常
- Tcp dup ack（tcp 重复应答）重复应答#前的表示报文到哪个序号丢失，#后面的是表示第几次丢失
- Tcp keep alive（tcp 保持活动）判断进程存在，网络通畅，但无法判断进程阻塞或死锁等问题
- Tcp retransmission（tcp 重传）超时时间内后端未响应，发起下一次连接请求
- Tcp ACKed unseen segument （tcp 看不见确认应答）报文没有抓全，当前报文是个 ack 的报文，但是，其要进行确认的报文不在。但有时会出现[TCP ACKed unseen segment]和[TCP Previous segment not captured]标记。出现这两个标记意味抓取的TCP握手包和挥手包不完整。由于TCP连接和断开需要分别经历三次握手和四次挥手。如果 Wireshark 在这个过程中开启抓包或者结束抓包，就会导致抓包不完整，出现以上提示信息。
- tcp port numbers reused（tcp 端口重复使用）高并发下tcp连接过快，后端tcp time_wait 回收过慢，RST复位攻击均有可能
- tcp retransmission（tcp 重传）常见为超时、后端未响应重传
- tcp fast retransmission (tcp 快速重传)tcp超时重新发送的机制：发送方送出一个 TCP 片段，然后开始等待并计时，如果 RTO 时间之后还没有收到 ACK 回复，发送方则重新发送。TCP 协议有可能在计时完成之前启动重新发送，也就是利用快速重新发送(fast-retransmission)。快速发送机制如果被启动，将打断计时器的等待，直接重新发送 TCP 片段。
- TCP Previoussegment lost（发送方数据段丢失）
- tcp spurious retransmission(tcp 伪重传)实际上并没有超时，但看起来超时了，导致虚假超时重传的原因有很多种：(1)对于部分移动网络，当网络发生切换时会导致网络延时突增(2)当网络的可用带宽突然变小时，网络 rtt 会出现突增的情况，这会导致虚假超时重传(3)网络丢包（原始和重传的包都有可能丢包）会导致虚假重传超时。
- TCP Out_of_Order(tcp乱序队列)一般来说是网络拥塞，导致顺序包抵达时间不同，延时太长，或者包丢失，需要重新组合数据单元，因为他们可能是由不同的路径到达你的电脑上面。另一个可能是因为 Client 到 Server 间有两条网路路径，像是 Load Balance 之类的架构，因此若两个封包走不同路径，晚送的封包却比早送的到达，就会发生 Out-Of-Order。
- tcp segment of a reassembled PDU在连个连接建立的时候，SYN 包里面会把彼此 TCP 最大的报文段长度(MSS 字段)，在局域网内一般都是 1460.如果发送的包比最大的报文段长度长的话就要分片了，被分片出来的包，就会被标记了“TCP segment of a reassembled PDU”，，看一下，被标记了的包的 SEQ 和 ACK 都和原来的包一致。
当我们过滤到需要的数据包后，可通过follow tcp的方式来跟踪起整个tcp 流程右键数据流即可打开会打开两个窗口，分别为过滤的请求包和数据包中具体信息。
数据包查看打开包后，即可开始具体信息包的结构如下
,
- 第一行：数据包整体概述，
- 第二行：链路层详细信息，主要的是双方的 Mac 地址
- 第三行：网络层详细信息，主要是双方的 IP 地址
- 第四行：传输层的详细信息，主要是双方的端口号。http 数据包，还会有http 请求信息，包括请求header 和body如果包含数据包，则会记录data层级，以16进制记录所传输的数据信息。
