tcp协议抓包只能用(tcp协议抓包分析代码)

在网络问题的调试中，tcpdump应该说是一个必不可少的工具，和大部分linux下优秀工具一样，它的特点就是简单而强大。它是基于Unix系统的命令行式的数据包嗅探工具，可以抓取流动在网卡上的数据包。 监听所有网卡所有包监听指定网卡的包监听指定IP的包监听指定来源IP监听目标地址IP监听指定端口监听TCP监听UDP监听192.168.1.11的tcp协议的80端口的数据包监听IP之间的包监听除了与192.168.1.4之外的数据包组合示例在HTTP中提取用户头在HTTP中同时提取用户头和主机信息抓取 HTTP GET 流量抓取 HTTP POST 请求流量注意：一个 POST 请求会被分割为多个 TCP 数据包提取 HTTP 请求的主机名和路径从 HTTP 请求中提取密码和主机名从 HTTP 请求中提取Cookie信息通过排除 echo 和 reply 类型的数据包使抓取到的数据包不包括标准的 ping 包可以通过过滤器 ip6 来抓取 IPv6 流量，同时可以指定协议如 TCP发起的出站 DNS 请求和 A 记录响应抓取 DHCP 服务的请求和响应报文https://www.oiox.cn/https://www.chenby.cn/https://cby-chen.github.io/https://weibo.com/u/5982474121https://blog.csdn.net/qq_33921750https://my.oschina.net/u/3981543https://www.zhihu.com/people/chen-bu-yun-2https://segmentfault.com/u/hppyvyv6/articleshttps://juejin.cn/user/3315782802482007https://space.bilibili.com/352476552/articlehttps://cloud.tencent.com/developer/column/93230https://www.jianshu.com/u/0f894314ae2chttps://www.toutiao.com/c/user/token/MS4wLjABAAAAeqOrhjsoRZSj7iBJbjLJyMwYT5D0mLOgCoo4pEmpr4A/ CSDN、GitHub、知乎、开源中国、思否、掘金、、腾讯云、哔哩哔哩、今日头条、新浪微博、个人博客、全网可搜《小陈运维》

抓包，如果能正常访问，理应有发送请求和应答请求两种。如果无法正常访问，那就只有发送请求，对方主机无应答。 你可以在命令提示符使用ping命令，看看有没有丢包。 这种情况多是与防火墙的安全策略有关。
速率不会影响，但进程使用要合适
抓包，如果能正常访问，理应有发送请求和应答请求两种。如果无法正常访问，那就只有发送请求，对方主机无应答。

你好！ 因为你的网卡只能看自己的traffic阿，你怎麽可能用自己网卡去看其他人的traffic呢？你真的想太多了。人家的datatraffic都没通过你的网卡，当然抓不到阿。除非你用hub让人家的电脑从你的hub上走，或是你可以access你们学校的router或switch，不然就是这个结果。 如有疑问，请追问。

采用wireshark时，自动的将网卡改成混杂模式，所以可以抓到所有 数据包 。你看看你选择的网卡有问题么？即便是交换机上没有做碰燃镜像，但也可以抓到自己通讯的数据包。笑答虚你可以举森选择ping命令，看看可以抓到自己的icmp包么？

让我们来看看这张图首先来了解每个部分的意义其他部分解释在这里：为什么建链接要 3 次握手，断链接需要 4 次挥手？另有一些需要注意的地方：Again，使用tcp_tw_reuse和tcp_tw_recycle来解决TIME_WAIT的问题是非常非常危险的，因为这两个参数违反了TCP协议（RFC 1122）SeqNum 的增加是和传输的字节数相关的。上图中，三次握手后，来了两个 Len:1440 的包，而第二个包的 SeqNum 就成了 1441。然后第一个 ACK 回的是 1441，表示第一个 1440 收到了。注意：如果你用 Wireshark 抓包程序看 3 次握手，你会发现 SeqNum 总是为 0，不是这样的，Wireshark 为了显示更友好，使用了 Relative SeqNum ——相对序号，你只要在右键菜单中的 protocol preference 中取消掉就可以看到“Absolute SeqNum”了TCP 要保证所有的数据包都可以到达，所以，必需要有重传机制。比如：发送端发了 1,2,3,4,5 五个包，接收端收到了 1,2 于是返回 ack 3，然后收到了 4（3 没收到）。此时的 TCP 会怎么办？因为正如前面所说的，SeqNum 和 Ack 是以字节数为单位，所以 ack 的时候，不能跳着确认，只能确认最大的连续收到的包，不然，发送端就以为之前的都收到了。有这样一个简单的办法：不回 ack，死等 3。当发送方发现收不到 3 的 ack 超时后，会重传 3。一旦接收方收到 3 后，会 ack 回 4——意味着 3 和 4 都收到了。但是这样有个非常大的 BUG，不回 ACK 那收到的 4,5 也不告诉发送方，这样发送方很有可能会认为 4,5 也没有到。导致 4,5 的重传于是，TCP引入了一种叫Fast Retransmit的算法，不以时间驱动，而以数据驱动重传。也就是说，如果，包没有连续到达，就 ack 最后那个可能被丢了的包，如果发送方连续收到 3 次相同的ack，就重传。Fast Retransmit 的好处是不用等 timeout 了再重传。比如说：我收到了 3 没收到 2，返回 ack2我又收到了 4 但还是没收到 2，返回 ack2但是 TMD 我又收到了 5 就是没收到 2，还是返回 ack2这个时候，不用等 timeout 的发送方就知道了 2 怕是掉了。于是会重新发 2。然后我接收到了我就返回 ack6**快速重传只解决了一个问题：不再需要等 timeout 就可以重新传包了。那重传多少呢？我知道 4 丢了，那要不要重传 5,6,7 呢？ **所以就有了另一个更好的办法：Selective Acknowledgment （SACK）。这种方式需要在 TCP 头里加一个 SACK 的东西，ACK 还是 Fast Retransmit 的 ACK，SACK 则是汇报收到的数据碎版。参看下图：这样，在发送端就可以根据回传的 SACK 知道哪些数据到了，哪些数据没有到。于是就优化了 Fast Retransmit 的算法。当然，这个协议需要两边都支持。在 Linux下，可以通过tcp_sack参数打开这个功能（Linux 2.4后默认打开）。这里还需要注意一个问题——接收方 Reneging，所谓 Reneging 的意思就是接收方有权把已经报给发送端 SACK 里的数据给丢了。这样干是不被鼓励的，因为这个事会把问题复杂化了，但是，接收方这么做可能会有些极端情况，比如要把内存给别的更重要的东西。所以，发送方也不能完全依赖 SACK，还是要依赖 ACK，并维护 Time-Out，如果后续的 ACK 没有增长，那么还是要把 SACK 的东西重传，另外，接收端这边永远不能把 SACK 的包标记为 Ack。注意：SACK 会消费发送方的资源，试想，如果一个攻击者给数据发送方发一堆 SACK 的选项，这会导致发送方开始要重传甚至遍历已经发出的数据，这会消耗很多发送端的资源。详细的东西请参看《 TCP SACK的性能权衡 》Duplicate SACK 又称 D-SACK，其主要使用了 SACK 来告诉发送方有哪些数据被重复接收了。D-SACK 使用了 SACK 的第一个段来做标志下面的示例中，丢了两个 ACK，所以，发送端重传了第一个数据包（3000-3499），于是接收端发现重复收到，于是回了一个SACK=3000-3500，因为 ACK 都到了 4000 意味着收到了 4000 之前的所有数据，所以这个 SACK 就是 D-SACK——旨在告诉发送端我收到了重复的数据，而且我们的发送端还知道，数据包没有丢，丢的是 ACK 包。下面的示例中，网络包（1000-1499）被网络给延误了，导致发送方没有收到 ACK，而后面到达的三个包触发了“Fast Retransmit算法”，所以重传，但重传时，被延误的包又到了，所以，回了一个SACK=1000-1500，因为 ACK 已到了3000，所以，这个 SACK 是D-SACK——标识收到了重复的包。这个案例下，发送端知道之前因为“Fast Retransmit算法”触发的重传不是因为发出去的包丢了，也不是因为回应的 ACK 包丢了，而是因为网络延时了。可见，引入了D-SACK，有这么几个好处：知道这些东西可以很好得帮助TCP了解网络情况，从而可以更好的做网络上的流控。Linux 下的 tcp_dsack 参数用于开启这个功能（Linux 2.4后默认打开）陈皓大神讲的真的非常非常好，我仔仔细细把这篇文章过了一遍。