推荐一些socket工具,TCP、UDP调试、抓包工具 推荐一些socket工具,TCP、UDP调试、抓包工具

还记得我在很久很久以前和大家推荐的FiddlerCharles debugger么?他们都是HTTP的神器级调试工具,非常非常的好用。好工具能让你事半功倍,基本上,我是属于彻头彻尾的工具控。

假如有一天,你写“传统”的PHP有些累了,想玩玩socket了,搞搞python、NodeJS、GO之类的新兴语言或框架(当然我不是说这些语言不能写web),或者干脆就用PHP吧,事实上PHP5.4的性能提高的真是相当之多,用PHP 的socket函数就能简单的写一个web socket服务器 (代码在评论里)了,甚至有个很不错的PHP框架—— swoole,他和其他的大多数常见的框架都不同,因为他不依赖http服务器!号称高级开发框架,“目标是向Java框架、Rails On Ruby、Python Django Pylons等一流框架发起挑战”的一种以socket方式运行的PHP框架。还有一个叫nanoserv,……我说这么多就是为了证明PHP也能玩好socket的,所以socket以及TCP、UDP都是平易近人的。

说工具

1、wireshark

这个工具是抓包的神器,我不知道有没有在以前的文章里提及,总之,他是好评如潮,谁用谁知道,我就不班门弄斧的多做蹩脚的介绍了,只说一点,他会自作聪明的按照端口号来解码协议,有的时候被他弄的一塌糊涂,此时选择不解码任何协议即可。

2、sokit

国人写的一个TCP、UDP socket调试辅助工具,非常的好用,基于QT框架,所以在linux和windows下都能用,他能很方便的组装二进制数据包,很方面的模拟分包、粘包。有客户端、服务器、转发器三种模式,转发器实际上就是一个透明代理,原理和Fidder类似,所以可以轻量级的进行抓包,当然不能断点调试的啦。

用这个玩意发现一个小bug,就是在发二进制包的时候[00,88] ,就这个中括号后面多了一个空格,也会被发出去,有一次我在这里栽了跟头,当然在日志中仔细查看能够看到完整的发出的包(这个故事告诉我们,日志很重要)

3、TCP/IP Builder

这个是我早期使用的一个工具,现在有了sokit,基本不使用他了,这个东东的特点是体积小

4、TCP/UDP Socket调试工具 2.3

相比之下,这个工具就没有什么特点了,嗯是的,甚至没有官方主页(工具界面上还带了点小广告),也推荐一下了,如果你觉得适合你的口味的话,至少我用了他一段时间的

5、TCPView

也是Windows下的神器,主要是查看当前的TCP连接、UDP连接状态,也可以断开正在传输数据的连接。她除了平时测试、调试TCP等用到,有的时候还能发现一些莫名奇妙的连接,那么就该查查你的系统了。

6、一些自己写的小脚本、小工具,就不献丑了,何况这些每个人都能自己写。

就是这些了,如果你有牛逼的神器收藏,欢迎与我交流

7. tcpdump
8. ngrep
9. Microsoft Network Monitor
10. Microsoft Research TCP Analyzer

时间: 2024-11-04 00:27:23

推荐一些socket工具,TCP、UDP调试、抓包工具 推荐一些socket工具,TCP、UDP调试、抓包工具的相关文章

socket跟TCP/IP 的关系,单台服务器上的并发TCP连接数可以有多少

常识一:文件句柄限制 在linux下编写网络服务器程序的朋友肯定都知道每一个tcp连接都要占一个文件描述符,一旦这个文件描述符使用完了,新的连接到来返回给我们的错误是“Socket/File:Can'topen so many files”. 这时你需要明白操作系统对可以打开的最大文件数的限制. 进程限制 执行ulimit -n 输出1024,说明对于一个进程而言最多只能打开1024个文件,所以你要采用此默认配置最多也就可以并发上千个TCP连接. 临时修改:ulimit -n1000000,但是

粘包产生的原因 socket 基于tcp实现远程执行命令(解决粘包)low

# 粘包产生的原因 # 粘包问题主要还是因为接收方不知道消息之间的界限,不知道一次性提取多少字节的数据所造成的. # 基于tcp协议的套接字会有粘包现象,而基于udp协议的套接字不会产生粘包现象 # tcp是基于数据流的,于是收发的消息不能为空,这就需要在客户端和服务端都添加空消息的处理机制,防止程序卡住:而udp是基于数据报的,即使你输入的是空内容,那也不是空消息,udp协议会帮你封装上消息头(ip+端口的方式),这样就有了消息办界 # 两种情况下会发生粘包 # 1.发送端需要等缓冲区满才发送

socket使用TCP协议时,send、recv函数解析以及TCP连接关闭的问题

Tcp协议本身是可靠的,并不等于应用程序用tcp发送数据就一定是可靠的.不管是否阻塞,send发送的大小,并不代表对端recv到多少的数据. 在阻塞模式下, send函数的过程是将应用程序请求发送的数据拷贝到发送缓存中发送并得到确认后再返回.但由于发送缓存的存在,表现为:如果发送缓存大小比请求发送的大小要大,那么send函数立即返回,同时向网络中发送数据;否则,send向网络发送缓存中不能容纳的那部分数据,并等待对端确认后再返回(接收端只要将数据收到接收缓存中,就会确认,并不一定要等待应用程序调

Linux下TCP网络编程与基于Windows下C#socket编程间通信

一.linux下TCP网络编程基础,需要了解相关函数 Socket():用于套接字初始化. Bind():将 socket 与本机上的一个端口绑定,就可以在该端口监听服务请求. Listen():使socket处于被动的监听模式,并为该  socket  建立一个输入数据队列,将到达的服务器, 请求保存在此队列中,直到程序处理他们. Accept():让服务器接收客户的连接请求. Connect():客户端使用connect函数来配置 socket并与远端服务器建立一个 TCP 连接. Clos

Linux下TCP网络编程与基于Windows下C#socket编程之间通信

一.linux下TCP网络编程基础,需要了解相关函数 Socket():用于套接字初始化. Bind():将 socket 与本机上的一个端口绑定,就可以在该端口监听服务请求. Listen():使socket处于被动的监听模式,并为该  socket  建立一个输入 数据队列,将到达的服务器, 请求保存在此队列中,直到程序处理他们. Accept():让服务器接收客户的连接请求. Connect():客户端使用connect函数来配置 socket并与远端服务器建立一个 TCP 连接. Clo

[转]socket使用TCP协议时,send、recv函数解析以及TCP连接关闭的问题

Tcp协议本身是可靠的,并不等于应用程序用tcp发送数据就一定是可靠的.不管是否阻塞,send发送的大小,并不代表对端recv到多少的数据. 在阻塞模式下, send函数的过程是将应用程序请求发送的数据拷贝到发送缓存中发送并得到确认后再返回.但由于发送缓存的存在,表现为:如果发送缓存大小比请求发送的大小要大,那么send函数立即返回,同时向网络中发送数据;否则,send向网络发送缓存中不能容纳的那部分数据,并等待对端确认后再返回(接收端只要将数据收到接收缓存中,就会确认,并不一定要等待应用程序调

网络通信中TCP出现的黏包以及解决方法 socket 模拟黏包

粘包问题概述 1.1  描述背景 采用TCP协议进行网络数据传送的软件设计中,普遍存在粘包问题.这主要是由于现代操作系统的网络传输机制所产生的.我们知道,网络通信采用的套接字(socket)技术,其实现实际是由系统内核提供一片连续缓存(流缓冲)来实现应用层程序与网卡接口之间的中转功能.多个数据包被连续存储于连续的缓存中,在对数据包进行读取时由于无法确定发生方的发送边界,而采用某一估测值大小来进行数据读出,若双方的size不一致时就会使数据包的边界发生错位,导致读出错误的数据分包,进而曲解原始数据

《TCP/IP详解卷2:实现》笔记--TCP:传输控制协议

传输控制协议,即TCP,是一种面向连接的传输协议,为两端的应用程序提供可靠的端到端数据流传输服务,它完全不同于 无连接的.提供不可靠数据传输服务的UDP协议. 下图描述了各TCP函数与其他内核函数之间的关系,带阴影的椭圆分别表示我们将要讨论的9个主要的TCP函数. 1.TCP的protosw结构 下图列出了TCPprotosw结构的成员变量,它定义了TCP协议与系统内其他协议之间的交互接口. 2.TCP的首部 tcphdr结构定义了tcp首部.下图给出了tcphdr结构的定义和TCP首部. 大多

netty的Udp单播、组播、广播实例+Java的Udp单播、组播、广播实例

网络上缺乏netty的udp的单播.组播案例,经过一番学习总结之后终于把这两个案例调通,下面把这两个案例的代码放在这里分享一下. 首先推荐博文: http://colobu.com/2014/10/21/udp-and-unicast-multicast-broadcast-anycast/#Netty%E4%B8%8E%E5%8D%95%E6%92%AD%EF%BC%8C%E7%BB%84%E6%92%AD netty的Udp单播.组播.广播实例+Java的Udp单播.组播.广播实例, 这些代

他们在工具的选择上投入了过多的时间精力,却忽略了应该用工具解决的问题

大坑3:对早期产品技术选型过分纠结 今年5月14.15两天,我作为PHP创始人Rasmus的随身翻译,去北京国际会议中心参加了第2届PHP全球开发者大会.虽然我对自己的英语比较有信心,但当得知Rasmus原籍是欧洲之后,也担心这哥们的口音太重,我听不懂,所以提前在网上搜了一些他的资料,看看听听,稍作了解. 在会议的宣传文案2里,我看到Rasmus的介绍是这么写的: 编程语言PHP的创始人,编写了PHP的头两个版本,并参与PHP后续版本的开发.2002年9月至2009年11月6日间,在Yahoo!