三次握手怎么抓包(tcp三次握手和四次挥手)

嗅探器都可以，我用的是omnipeek
如果对抓包嗅探软件不太熟悉的话，试试用国产的科来软件。 www.colasoft.com.cn ，里面有过滤器设置，可以设置为只捕获想要的协议数据包。
用wireshark

finack指的是数据已经传完了，可以断开连接，如果你仔细观察的话，可以看到最后有两个finack的。pshack都是tcp的头部字段，psh指的是不用在等待其他包了，自己就可以单独发送，所以带有pshack的是数据发送的包，传的应该就是你要的数据，当然到底是不是要看源和目的的ip对不对。
第一次握手数据包 客户端发送一个TCP，标志位为SYN，序列号为0， 代表客户端请求建立连接。第二次握手的数据包服务器发回确认包, 标志位为 SYN,ACK. 将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即0+1=1。第三次握手的数据包 客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1。

目录我的操作是这样的，让手机和电脑在同一个局域网内（比如连接同一个 wifi），接着在手机的wifi上设置代理，电脑使用 Charles 做代理，IP 为电脑在局域网 IP，我这边的环境，手机 IP 为 172.17.32.117，电脑 IP 为 172.17.32.19。再设置代理端口为 8888。设置代理后，接下来手机的请求都会通过电脑的网卡代理请求发送出去。其实可以不用这么绕。我之所以多设了一个代理，是因为自己电脑创建的 wifi 热点，手机接收不到。为了让手机的包能经过电脑网络嗅探到才这么处理的。最便捷的方式，就是电脑放个 wifi 热点给手机连接完事。创建后代理连接后，然后使用 Wireshark 嗅探网卡，比如我这里使用的是 etho0 网卡去访问网络的。这时候玩玩手机，打开几个请求，Wireshark 上面就会出现捕捉的大量的包，各种各样的协议都有，有 ARP 寻人启事（寻找 IP 对应的物理地址），有 TCP 连接包，有 HTTP 请求包。这里我设置了一下过滤规则，把对网易的一个https://nex.163.com的一个的请求过滤出来如下：整个完整的 HTTPS 请求的过程如下：接下来把手机称为 A（172.17.32.211），电脑称为 B（172.17.32.19），对完整的过程进行简要分析。作为整个过程的第一个 TCP 包，这里对它做一个详细的剖析，理解一下 TCP 报文的格式和内容。TCP 是传输层协议，负责可靠的数据通信，它在整个体系结构的位置如下：作为传输层协议，主要为上层协议提供三个功能：TCP 协议为 HTTP 和 SSL 协议提供了基础的通信功能。所以 SSL 协议是基于 TCP 的。三次握手的内容有：对每个包进行详细的分析：A 发出一个带 SYN 同步位的包，通知服务端要建立连接。第一次握手，发出的 TCP 包的数据和 Wireshark 解析的结果如下：灰色部分就是 TCP 报文的数据内容，第一个两个字节 0x8c85 = 35973 表示源端口。TCP 报文的格式如下，对应的如上图的灰色部分。非灰色部分分别为 IP 首部和数据帧首部。参考谢希仁版本的 《计算机网络》一书，对照着整个报文格式表，把整个 TCP 报文的二进制信息和相关意义做些说明：到这里的话，TCP 数据报首部固定部分结束，固定部分一共有 20 字节。也就是 TCP 首部，至少要有 20 字节。固定首部后，就是可长度可以变化的选项了：整个所以 TCP 数据包的大小可以这样表示：我们 Wireshark 后面的一长串的信息就指出了该 TCP 报文的一些主要信息：从上面的分析可以看出，这个 SYN 包并没有携带数据，但是按协议这里要消耗一个序号。在发出 SYN 包后，A 端进入SYN-SENT状态。B 收到 SYN 包，发出 SYN + ACK 确认包。这个包，既是确认收到了第一次握手的包，也是一个由 B 端发出的同步包，表示自己准备好了，可以开始传数据了。TCP 报文包相对于第一次握手的包可以窥见一些变化：可以看到，这个包的应答时间戳刚好是第一次握手的发送时间戳。从这里也可以理解到，这个包就是在响应第一次握手的包所以，接收方 A 可以利用这个值来计算这一次RTT，收到第二次握手的包后，计算当前时间戳减去该包的应答时间戳就是一个RTT的延时了。这虽然是 ACK 包，但也是 SYN 包，所以也要消耗一个序号。在发出这个包后，B 端进入 SYN-REVD 状态。A 收到后，再发出一个 ACK 确认包发出的包如下：这里我们产生一个疑问，这里发送端 A 发连接请求信息、接收端 B 发确认信息，又互相同步了序号，是不是已经可以传输数据了？但实际上 A 还要再发一个 ACK 确认报文，如图所示，确认收到了 B 第二次握手发出的包，这个时候，在这个 ACK 包后 A 和 B 才正式进入 ESTABLISHED 状态。这就是第三次握手。这是为什么呢？假设我们用两次握手，然后在第一次握手期间，A 发了第一次握手包后出现了这样的场景：一直没有得到响应而进行超时重传，又发了一次包，然后我们称上一次包为失效包。然后我们可以看到：所以，只有接收端 B 在发送端 A 发出了第三次握手包后，才认为连接已经建立，开始等待发送端 A 发送的数据，才不会因为失效的连接请求报文导致接收端异常。TCP 三次握手的时序图如下：三次握手，有几个重要的任务，一个是同步序号，接收端和发送端都发出同步包来通知对方初始序号，这样子后面接收的包就可以根据序号来保证可靠传输；另一个是让发送端和接收都做好准备。然后就开始传数据了。整个过程都发生在 HTTP 报文发出之前。HTTP 协议就是依靠着 TCP 协议来做传输的管理。TCP 可以认为是它的管家，管理着传输的大大小小的事务，比如要不要保证包顺序一致？什么时候发包？要不要收包？TCP 是很严格的。三次握手在 Java API 层面，对应的就是 Socket 的连接的创建（最终调用的是 native 层的 socket 创建）：这里的 connectTimeout 对应的是三次握手的总时长，如果超时了就会被认为连接失败。比如一个场景，客户端发出一个 SYN 报文后，迟迟没有收到服务端的 SYN + ACK。这时候客户端触发重传机制，每次重传的间隔时间加倍，同样没有收到包。然后如果这段时间超出了连接超时时间的设置，那么建立连接超时就发生了。所以，如果三次握手要花的时间，总是大于这里的 connectTimeout 时间，这个 Socket 就无法建立连接。我们这一次请求的三次握手时间在 180ms 左右。像在 OkHttp 中，如果是三次握手阶段的连接超时，是会有重试机制的。也就是重新建联，重新发出 SYN 报文发起 TCP 连接。重新建联的时候会更换连接的路由，如果已经没有可选择路由的话，那么这个就真的失败了。在 OkHttp 3.9.0 的默认配置中，连接超时的时间为 10000ms = 10s。在 OkHttpClient.Builder 中。实际应用的时候，根据业务场景来调整。这次请求，为了让 Wireshark 抓到手机的包，我使用了电脑作为代理。其实就是客户端 A 使用 HTTP 协议和代理服务器 B 建立连接。和普通的 HTTP 请求一样，需要携带 IP + 端口号，如果有身份验证的时候还会带上授权信息，代理服务器 B 会使用授权信息进行验证。然后代理服务器会去连接远程主机，连接成功后返回 200。Wireshark 抓到的包有这样两条信息，就是在创建代理：请求报文：响应报文：HTTP CONNECT 是在 HTTP1.1 新增的命令，用于支撑 https 加密。因为我采用代理的方式抓包才有这一个步骤。如果是直接抓 PC 机上浏览器发出的 HTTPS 包，不会有这个过程。然后我们思考一下，为什么代理服务器需要这些信息，要连接的主机名和端口号？这是因为后面进行 SSL 加密 HTTP协议，因为代理服务器拿不到加密密钥，是无法获取到 HTTP 首部的，进而无法这个请求是要发到哪个主机的。所以，这里先使用 CONNECT 方法，把主机名和对应的端口号通知代理服务器。这个也被称为 HTTPS SSL 隧道协议。建立这个 SSL 隧道后，这个特殊代理就会对数据进行盲转发。SSL 整个协议实际上分两层，SSL 记录协议和其他子协议（SSL握手协议，SSL改变密码协议，SSL警告协议）：这两层协议的关系，其实就是数据封装的关系，SSL 握手封装协议封装其他上层协议。封装握手协议：封装应用数据协议，比如 HTTP：封装交换密码协议：封装警报协议：所以 SSL 记录协议其实就是一个其他协议的载体，只是提供了一个封装的功能。它的格式为：MAC 就是消息验证码，用来验证数据的完整性，保证中途没有篡改。这个消息验证码比数字签名弱一些，使用的是对称密钥加密摘要。数字签名使用的是非对称密钥加密，有区分公钥私钥。记录协议的主要目的有这几个，为其他 SSL 子协议提供了以下服务：TCP 三次握手结束并且和代理服务器成功连接后，建联成功，客户端 A 就开始发起 SSL 连接，首先会进入 SSL 握手阶段。SSL 握手阶段的主要目的有这么几个：SSL 握手的流程并不是一成不变的，根据实际的应用场景来。主要有三种：SSL 握手的完整的交互过程如下，这里是验证服务端又验证了客户端的情况：我们的请求只验证服务端，所以 7,8,9 是不存在的。现在具体分析每一个阶段的内容。Client Hello作为 SSL 握手的第一个握手包，我们详细分析和理解一下包的内容。下面是 Wireshark 解析好的这个 SSL 协议的数据包：这个包如何解读，按照之前对 SSL 协议的分析，其实分成两个部分：因为是握手过程，密钥还没协商，这里还是使用明文传输，记录协议的数据载体就是明文的 SSL 握手协议。SSL 握手协议的格式为：我们可以从握手协议的数据包中得到这些信息：密码套件随着密码学的发展而发展，而且根据现实应用中，可能会有某些密码被破解，从而导致密码套件可能会导致安全问题，所以一般都会使用当前最新最安全的密码套件。在 Android 系统中，一般情况下，使用 SSLSocket进行连接的时候，会带上系统默认的支持的密码套件。但是这个有个缺点，比如某些密码套件的加密算法被破解或者出现安全漏洞，而且要跟着系统升级反应缓慢。OkHttp 在进行 SSL 握手的时候，会使用 ConnectionSpec 类中带上提供了一系列最新的密码套件。可以从注释上看，这些密码套件在 Chrome 51 和 Android 7.0 以上得到了完全支持。然后，再把这些密码套件和 Android 系统支持的密码套件取交集，提交给服务端。这样，万一哪个密码套件有问题，OkHttp 官方会下降支持。网络库 OkHttp 库会随着版本的迭代，不断地去提供比较新的密码套件，并且放弃那些不安全的密码套件。接入应用即时更新 OkHttp，就不用等待缓慢的系统更新了。如果提供的所有密码套件服务端都不支持，OkHttp 有回退机制，退而求其次，选比较旧的套件。Server Hello服务端收到了客户端的 Hello，通过客户端的配置信息，结合服务端的自身情况，给出了最终的配置信息。Wireshark 解析后的内容如下：具体内容如下：Certificate上面的 Server Hello 已经制定了接下来的非对称加密算法服务端下发证书，客户端验证服务端的身份，并且取出证书携带的公钥，这个公钥是交换加密算法的公钥。也就是在 Server Hello 阶段指定的ECDHE（EC Diffie-Hellman）算法，也是通常说的 DH 加密。这个 Certificate 消息下发了从携带自己公钥的数字证书和 CA 证书的证书链，在 Certificates 字段中：CA 是 PKI 体系的重要组成部分，称为认证机构。那什么是 CA 证书？就是用来 CA 中心发布的，认证该服务单证书的合法性，可以确保该证书来源可靠而不是被中间人替换了。但是 CA 证书也可能被中间人拦截造假？那就再用一个证书来认证它。看起来好像没完没了。实际上到最后有一个根 CA 证书，这个证书存储再浏览器或者操作系统中，是系统直接信任的。服务端证书需要 CA 证书做认证。使用的还是数字签名方式，从数据中摘要一段信息，用 CA 证书的加密。然后验证的时候时候，用 CA 证书的公钥解密，用同样的摘要算法摘要数据部分和解密好的信息进行比较。客户端在验证服务端证书的有效性有这样的一个过程。首先会找到该证书的认证证书，也就是中级 CA 证书。然后找中级 CA 证书的认证证书，可以是另一个中级 CA 证书，也可能是根 CA 证书。这样直到根 CA 证书。接着从根 CA 证书开始往下去验证数字签名。比如有这样的证书链：根 CA 证书-> 中级 CA 证书 -> 服务端证书。用 CA 证书的公钥去验证中级证书的数字签名，再用中级证书的公钥去验证服务器证书的数字签名。任何一个环节验证失败，就可以认为证书不合法。这就是整个证书链的认证过程：查看抓到的包的数据，发现只有两个证书。为服务端证书和中级 CA 证书。根 CA 证书呢？顺藤摸瓜找到它。首先看服务端证书。它内容如下：从这个证书中我们可以窥见这些信息：首先是 signedCertificate 字段的内容，即数字证书的数据：然后是证书颁发机构的签名信息：从上面的 issuer 可以了解到，认证该服务器证书的 CA 证书为GeoTrust SSL CA - G3，我们从 Certificates 找到对应的中级证书的内容如下（中级证书可以有好几级，我们这儿只有一级）：可以得到中级证书名为GeoTrust SSL CA - G3，证书组织为GeoTrust Inc.。认证该 CA 证书的证书呢？还是看 issue 字段，认证证书名为GeoTrust Global CA，组织同样是GeoTrust Inc.。其实这个就是根 CA 证书。在这个请求中没有找到，但在浏览器或者操作系统可以找到。一般的浏览器和系统都会内置该 CA 证书。所以根证书是受浏览器或者操作系统信任的，无需其他证书做担保。如果想要自己的系统再信任某些非通用的权威机构的根 CA 证书，那么就去安装它。比如我的 Windows 系统就安装了GeoTrust Global CA证书：像我们平时使用 Charles 抓 HTTPS 就是这个原理，把 Charles 的 CA 证书安装在手机中，成为受信任的根 CA 证书。基本原理就是，Charles 代理作为 SSL 隧道，并没有透明传输，而是作为一个中间人，拦截了 SSL 握手信息，修改里面的 CA 证书。仿冒手机端和真实服务端建立连接获取主密钥，然后又仿冒服务端和手机客户端建立 SSL 连接，修改服务端证书的 CA 和数字签名，这样 Charles 就可以解析到加密的 HTTP 内容了。修改后的服务端证书如下，可以看到 issuer 被替换成了 Charles 的证书。

1、先提出一个问题， 可以不进行三次握手直接往服务端发送数据包吗？是不可以的，也是可以的；1）不可以是因为现在的TCP连接标准和规范要求传输数据前先确认两端的状态，有一端状态不OK的话，发数据包有什么用呢；2）说可以是站在网络连接的角度，像 UDP 协议；2、TCP三次握手1）标志位、随机序列号和确认序列号是在数据包的 TCP 首部里面；2）几个状态是指客户端和服务端连接过程中 socket 状态；3）第一次握手，客户端向服务端发送数据包，该数据包中 SYN 标志位为 1，还有随机生成的序列号c_seq，客户端状态改为 SYN-SENT；4）第二次握手，服务端接收到客户端发过来的数据包中 SYN 标志位为 1，就知道客户端想和自己建立连接，服务端会根据自身的情况决定是拒绝连接，或确定连接，还是丢弃该数据包；拒绝连接，会往客户端发一个数据包，该数据包中 RST 标志位为 1，客户端会报 Connection refused；丢弃客户端的数据包，超过一定时间后客户端会报 Connection timeout；确定连接时会往客户端发一个数据包，该数据包中 ACK 标志位为 1，确认序列号 ack=c_seq+1，SYN 标志位为 1，随机序列号 s_seq，状态由 LISTEN 改为 SYN-RCVD；5）第三次握手，客户端接收到数据包会做校验，校验ACK标志位和确认序列号 ack=c_seq+1，如果确定是服务端的确认数据包，改自己的状态为 ESTABLISHED，并给服务端发确认数据包；6）服务端接到客户端数据包，会校验ACK标志位和确认序列号 ack=s_seq+1，改自己的状态为 ESTABLISHED，之后就可以进行数据传输了；7）建立连接时的数据包是没有实际内容的，没有应用层的数据；8）建立连接之后发起的请求数据包，每个数据包都会封装各层协议的头部信息，标志位ACK为1，其他标志位变动；9）网络进程间的通信，一台服务器内部的进程间通信不用这样；3、TCP 连接三次握手抓包1）Socket 在 linux 系统中是一种特殊的文件，因为 linux 系统的理念就是【一切皆文件】，是系统内核级的功能；2）以上定义比较具体，可以抽象来理解，是一个内核级的用于通信的功能层，包含一组接口函数，这些函数实际就是操作 socket 文件句柄文件描述符；一个 TCP 连接由四要素【源IP、源Port、目标IP、目标Port】唯一标识，也即 socket 由这四要素唯一确定；一个 TCP 连接的建立也就是客户端、服务端创建了相对应的一对 socket，客户端和服务端之间的通信也就是这对 socket 间的通信（物理层面是网卡在发送/接收比特流数据）；3）一个服务与另一个服务建立连接，他们的端口是什么呢？客户端发出请求端口号是随机的，服务端是进程监听的端口号；2、socket 主要函数介绍1、进程通信，一个进程只有一个监听 socket，connect socket 是针对一个客户的一个连接的，有很多个； 2、connect 函数内部在发起请求前会找系统随机一个端口号； 3、连接建立后，客户端发起请求传输数据，服务端会直接交给 connect socket 处理，不会交给监听 socket 处理；4、监听 socket 在处理客户端请求时，如果此时其他客户端发请求过来，监听 socket 是没法处理的，此时系统会维护请求队列由 backlog 参数指定；全连接队列（completed connection queue）半连接队列（incomplete connection queue）Linux 内核 2.2 版本之前，backlog 的大小等于全连接队列和半连接队列之和；Linux 内核 2.2 版本之后，backlog 的大小之和全连接队列有关系：半连接队列大小由 /proc/sys/net/ipv4/tcp_max_syn_backlog 文件指定，可以开很大；全连接队列大小由 /proc/sys/net/core/somaxconn 文件和 backlog 参数指定，取两个中的最小值；tomcat acceptCount 就是配置全连接队列大小；3、socket 函数在建立连接和数据传输的大概使用情况4、TCP首部结构1）2的16次方等于 65536，所以系统中端口号的限制个数为 65536，一般1024以下端口被系统占用；2）标志位这里是 6 个，还有其他标志位的，只是这 6 个标志位常用；3）seq 序列号，ack 确认序列号，序列号在数据传输时分包用到。三次握手时 seq 序列号是随机的，没有实际意义；4）TCP 包首部后面接着的是 IP 包首部，再紧接着的是以太网包首部，其实都是加 0101010101 二进制位；几个常用标志位，首先一个标志位占一个 bit 位，只能是二进制中的 1 或 0；1）SYN，简写 S，请求标志位，用来建立连接。在TCP三次握手中收到带有该标志位的数据包，表示对方想与己方建立连接；2）ACK，简写【.】，请求确认/应答标志位，用于对对方的请求进行应答，对方收到含该标志位的数据包，会知道己方存在且可用。也会用在连接建立之后，己方发送响应数据给对方的数据包中；3）FIN，简写 F，请求断开标志位，用于断开连接。对方收到己方的含该标志位的数据包，就知道己方想与它断开连接，不再保持连接；4）RST，简写 R，请求复位标志位，因网络或己方服务原因导致有数据包丢失，己方接收到的数据包序列号与上一个数据包的序列号不衔接，那己方会发送含该标志位的数据包告诉对方，对方接收到含该标志位的数据包就知道己方要求它重新三次握手建立连接并重新发送丢失的数据包，一般断点续传会用到该标志位；还有就是如果对方发过来的数据错了，有问题，己方也会发送含该标志位的数据包；5）PSH，简写 P，推送标志位，表示收到数据包后要立即交给应用程序去处理，不应该放在缓存中，read()/write() 都有缓存区；6）URG，简写 U，紧急标志位，该标志位表示 tcp 包首部中的紧急指针域有效，督促中间层尽快处理；7）ECE，在保留位中；8）CWR，在保留位中；5、TCP 抓包1）服务端会根据自身情况，没有要处理的数据时会把第二次和第三次挥手合并成一次挥手，此时标志位 FIN=1 / ACK=1；2）MSL 是 Maximum Segment Lifetime 缩写，指数据包在网络中最大生存时间，RFC 建议是 2分钟；详细描述：1）客户端、服务端都可以主动发起断开连接；2）第一次挥手，客户端向服务端发送含 FIN=1 标志位的数据包，随机序列号 seq=m，此时客户端状态由 ESTABLISHED 变为 FIN_WAIT_1；3）第二次挥手，服务端收到含 FIN=1 标志位的数据包，就知道客户端要断开连接，服务端会向客户端发送含 ACK=1 标志位的应答数据包，确认序列号 ack=m+1，此时服务端状态由 ESTABLISHED 变为 CLOSE_WAIT；4）客户端收到含 ACK=1 标志位的应答数据包，知道服务端的可以断开的意思，此时客户端状态由 FIN_WAIT_1 变为 FIN_WAIT_2；（第一、二次挥手也只是双方交换一下意见而已）5）第三次挥手，服务端处理完剩下的数据后再次向客户端发送含 FIN=1 标志位的数据包，随机序列号 seq=n，告诉客户端现在可以真正的断开连接了，此时服务端状态由 CLOSE_WAIT 变为 LAST_ACK；6）第四次挥手，客户端收到服务端再次发送的含 FIN=1 标志位的数据包，就知道服务端处理好了可以断开连接了，但是客户端为了慎重起见，不会立马关闭连接，而是改状态，且向服务端发送含 ACK=1 标志位的应答数据包，确认序列号 ack=n+1，此时客户端状态由 FIN_WAIT_2 变为 TIME_WAIT；等待 2 个MSL时间还是未收到服务端发过来的数据，则表明服务端已经关闭连接了，客户端也会关闭连接释放资源，此时客户端状态由 TIME_WAIT 变为 CLOSED；也就是说 TIME_WAIT 状态存在时长在 1~4分钟；7）服务端收到含 ACK=1 标志位的应答数据包，知道客户端确认可以断开了，就立即关闭连接释放资源，此时服务端状态由 LAST_ACK 变为 CLOSED；SYN 洪水攻击（SYN Flood）是一种 DoS攻击（拒绝服务攻击），大概原理是伪造大量的TCP请求，服务端收到大量的第一次握手的数据包，且都会发第二次握手数据包去回应，但是因为 IP 是伪造的，一直都不会有第三次握手数据包，导致服务端存在大量的半连接，即 SYN_RCVD 状态的连接，导致半连接队列被塞满，且服务端默认会发 5 个第二次握手数据包，耗费大量 CPU 和内存资源，使得正常的连接请求进不来；

开始界面 wireshark是捕获机器上的某一块网卡的网络包，当你的机器上有多块网卡的时候，你需要选择一个网卡。点击Caputre->Interfaces.. 出现下面对话框，选择正确的网卡。然后点击"Start"按钮, 开始抓包Wireshark 窗口介绍WireShark 主要分为这几个界面1. Display Filter(显示过滤器)，用于过滤2. Packet List Pane(封包列表)， 显示捕获到的封包， 有源地址和目标地址，端口号。 颜色不同，代表3. Packet Details Pane(封包详细信息), 显示封包中的字段4. Dissector Pane(16进制数据)5. Miscellanous(地址栏，杂项)使用过滤是非常重要的， 初学者使用wireshark时，将会得到大量的冗余信息，在几千甚至几万条记录中，以至于很难找到自己需要的部分。搞得晕头转向。过滤器会帮助我们在大量的数据中迅速找到我们需要的信息。过滤器有两种，一种是显示过滤器，就是主界面上那个，用来在捕获的记录中找到所需要的记录一种是捕获过滤器，用来过滤捕获的封包，以免捕获太多的记录。 在Capture -> Capture Filters 中设置保存过滤在Filter栏上，填好Filter的表达式后，点击Save按钮， 取个名字。比如"Filter 102",Filter栏上就多了个"Filter 102" 的按钮。过滤表达式的规则表达式规则1. 协议过滤比如TCP，只显示TCP协议。2. IP 过滤比如 ip.src ==192.168.1.102 显示源地址为192.168.1.102，ip.dst==192.168.1.102, 目标地址为192.168.1.1023. 端口过滤tcp.port ==80,端口为80的tcp.srcport == 80,只显示TCP协议的愿端口为80的。4. Http模式过滤http.request.method=="GET", 只显示HTTP GET方法的。5. 逻辑运算符为 AND/ OR常用的过滤表达式封包列表(Packet List Pane)封包列表的面板中显示，编号，时间戳，源地址，目标地址，协议，长度，以及封包信息。 你可以看到不同的协议用了不同的颜色显示。你也可以修改这些显示颜色的规则，View ->Coloring Rules.封包详细信息 (Packet Details Pane)这个面板是我们最重要的，用来查看协议中的每一个字段。各行信息分别为Frame: 物理层的数据帧概况Ethernet II: 数据链路层以太网帧头部信息Internet Protocol Version 4: 互联网层IP包头部信息Transmission Control Protocol:传输层T的数据段头部信息，此处是TCPHypertext Transfer Protocol:应用层的信息，此处是HTTP协议TCP包的具体内容从下图可以看到wireshark捕获到的TCP包中的每个字段。看到这， 基本上对wireshak有了初步了解， 现在我们看一个TCP三次握手的实例三次握手过程为这图我都看过很多遍了， 这次我们用wireshark实际分析下三次握手的过程。打开wireshark, 打开浏览器输入 h t t p : / / w w w . c r 1 7 3 .c o m在wireshark中输入http过滤， 然后选中GET /tankxiao HTTP/1.1的那条记录，右键然后点击"Follow TCP Stream",这样做的目的是为了得到与浏览器打开网站相关的数据包，将得到如下图图中可以看到wireshark截获到了三次握手的三个数据包。第四个包才是HTTP的， 这说明HTTP的确是使用TCP建立连接的。第一次握手数据包客户端发送一个TCP，标志位为SYN，序列号为0， 代表客户端请求建立连接。 如下图第二次握手的数据包服务器发回确认包, 标志位为 SYN,ACK. 将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即0+1=1, 如下图步骤阅读第三次握手的数据包客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1, 如下图: 就这样通过了TCP三次握手，建立了连接