wireshark
点Main Toolbar的倒数第三个按钮。或者点View菜单的Coloring Rules（倒数第三个），可以看到对应的颜色规则。
绿色背景（黑字）的是HTTP包，灰色背景（黑字）的是TCP包。
黑色背景的比较多，黑底红字的是TCP错误包或者校验和错误的包。
wireshark导出数据：
导出解码后的报文内容，包含详细报文和简单数据信息， "Save as Type" 为 "Plain Text"
仅导出指定的数据信息摘要，Export as CSV (Comma Separated Values) File
访问www.baidu.com的流程
对于直接通过Ethernet联网的机器，Wireshark Capture Filter为"hostwww.baidu.com"；对于通过PPP over Ethernet（PPPoE）联网的机器，Wireshark Capture Filter为"pppoes and hostwww.baidu.com"。
三次握手建立TCP连接的流程如下：
C(Browser) S(www.baidu.com) CLOSED LISTEN SYN-SENT →<SEQ=0><CTL=SYN> → SYN-RECEIVED ESTABLISHED← <SEQ=0><ACK=1><CTL=SYN,ACK> ← SYN-RECEIVED ESTABLISHED→ <SEQ=1><ACK=1><CTL=ACK> → ESTABLISHED
S调用socket的listen函数进入监听状态；C调用connect函数连接S：[SYN]，S调用accept函数接受C的连接并发起与C方向上的连接：[SYN,ACK]。C发送[ACK]完成三次握手，connect函数返回；S收到C发送的[ACK]后，accept函数返回。
关于Seq和Ack
Seq即Sequence Number，为源端（source）的发送序列号；Ack即Acknowledgment Number，为目的端（destination）的接收确认序列号。在Wireshark Display Filter中，可使用tcp.seq或tcp.ack过滤。
在Packet1中，C:5672向S:80发送SYN握手包，Seq=0；在Packet2中，S:80向C:5672发送ACK握手回应包，Ack=1，同时发送SYN握手包，Seq=0；在Packet3中，C:5672向S:80发送ACK握手回应包，Seq=1，Ack=1。
至此，Seq=1为C的ISN，后期某一时刻的Seq=ISN+累计发送量(cumulative sent)；Ack=1为C的IAN，后期某一时刻的Ack=IAN+累计接收量。对于S而言，Seq和Ack情同此理。
2．TCP获取网站数据流程
对百度的完整抓包建立在不使用缓存的基础上。如若主机存有百度站点的cookie和脱机缓存（Offline Cache），则不会再请求地址栏图标favicon.ico；请求/js/bdsug.js?v=1.0.3.0可能回应“HTTP/1.1 304 Not Modified”。可在浏览器打开百度首页后，Ctrl+F5强制刷新，不使用缓存，也可参考《浏览器清除缓存方法》。
以下为访问百度过程，wireshark抓包数据。对于直接通过Ethernet联网的机器，Wireshark Capture Filter为"host www.baidu.com"；对于通过PPP over Ethernet（PPPoE）联网的机器，Wireshark Capture Filter为"pppoes and host www.baidu.com"。以下抓包示例直接通过Ethernet联网访问百度的过程。可点击下面的图片超链接下载pcap文件，使用wireshark软件打开查看。
为方便起见，以下将客户端（浏览器）简称为C，将服务器（百度后台）简称为S。
连接建立后，下一步发送（“GET / HTTP/1.1”）请求（Request）HTML页面，这里“/”表示S的默认首页，“GET”为HTTP Request Method；“/”为Request-URI，这里为相对地址；HTTP/1.1表示使用的HTTP协议版本号为1.1。
以下为HTTP GET请求数据包（Packet4）。
4 192.168.89.125:5672→220.181.6.175:80 HTTP 417 GET / HTTP/1.1
HTTP GET报文长=417-54=363个字节，其中Next sequence number: 364(relative sequence number)表示，若在规定的时间内收到S响应Ack=364，表明该报文发送成功，可以发送下一个报文（Seq=364）；否则重传（TCP Retransmitssion）。序列号确认机制是TCP可靠性传输的保障。
S（http）收到HTTP GET报文（共363个字节），向C（amqp）发送TCP确认报文（Packet5）。
5 220.181.6.175:80→ 192.168.89.125:5672 TCP 60 http > amqp [ACK] Seq=1 Ack=364 Win=6432 Len=0
这里Seq=1,为S的ISN，意为已发送过SYN。Packet2中，Ack=1为S的IAN。这里的Ack-IAN=364-1=363表示S已经从C接收到363个字节，即HTTP GET报文。同时，Ack=364也是S期待C发送的下一个TCP报文序列号（上面分析的Next sequence number）。
接下来，S向C发送Http Response，根据HTTP协议，先发响应头（Response Header），再发百度首页HTML文件。
Http Response Header报文（Packet6）如下。
6 220.181.6.175:80→ 192.168.89.125:5672 TCP 465 [TCP segment of a reassembled PDU]
其部分内容如下：
HTTP/1.1 200 OK …… Content-Length: 2139 Content-Type: text/html;charset=gb2312 Content-Encoding: gzip
S响应C的“GET / HTTP/1.1”请求，先发送带[PSH]标识的411个字节的Http Response Header（Packet 6）。
TCP头部[PSH]标识置位，敦促C将缓存的数据推送给应用程序，即先处理Http Response Header，实际上是一种“截流”通知。相应C的socket调用send时在IPPROTO_TCP选项级别设置TCP_NODELAY为TRUE禁用Nagle算法可以“保留发送边界”，以防粘连。
GET条件请求时,客户端会提供给服务器一个If-Modified-Since请求头,其值为服务器上次返回的Last-Modified响应头中的日期值,还会提供一个If-None-Match请求头,值为服务器上次返回的ETag响应头的值:
服务器会读取到这两个请求头中的值,判断出客户端缓存的资源是否是最新的,如果是的话,服务器就会返回HTTP/304 Not Modified响应,但没有响应体.客户端收到304响应后,就会从缓存中读取对应的资源.
另一种情况是,如果服务器认为客户端缓存的资源已经过期了,那么服务器就会返回HTTP/200 OK响应,响应体就是该资源当前最新的内容.客户端收到200响应后,就会用新的响应体覆盖掉旧的缓存资源.
只有在客户端缓存了对应资源且该资源的响应头中包含了Last-Modified或ETag的情况下,才可能发送条件请求.如果这两个头都不存在,则必须无条件(unconditionally)请求该资源,服务器也就必须返回完整的资源数据.
尽管握手协商的MSS为1460，但服务器或者代理平衡服务器，每次发送过来的TCP数据最多只有1420个字节。可以使用ping -f -l size target_name命令向指定目标target_name发送指定字节量的ICMP报文，其中-l size指定发送缓冲区的大小；-f则表示在IP数据报中设置不分片DF（Don’t Fragment），这样便可探测出到目标路径上的MTU。
执行“ping -f -l 1452 www.baidu.com”的结果如下：
220.181.6.18的 Ping统计信息:
数据包:已发送 = 4，已接收 = 4，丢失 = 0 (0%丢失)
执行“ping -f -l 1453 www.baidu.com”的结果如下：
需要拆分数据包但是设置 DF。
220.181.6.18的 Ping统计信息:
数据包:已发送 = 4，已接收 = 0，丢失 = 4 (100%丢失)
从以上ping结果可知，在不分片时，从本机出发到百度的路由上能通过的最大数据量为1452，由此推算出MTU{local,baidu}=sizeof(IP Header)+ sizeof(ICMP Header)+sizeof(ICMP Data Portion)=20+8+1452=1480。
S调用socket的send函数发送2139个字节的Http Response Content（Packet 7、Packet 9），在TCP层将分解为两段（segment）后再发出去。
7 220.181.6.175:80→ 192.168.89.125:5672 TCP 1474
[TCP segment of a reassembled PDU]
由“Content-Length: 2139”可知，HTML文件还有2139-(1474-54)=719个字节。但此时，C已经发送了确认报文（Packet8）。
8 192.168.89.125:5672→ 220.181.6.175:80 TCP 54 amqp > http [ACK] Seq=364 Ack=1832 Win=65535 Len=0
Seq-ISN=364-1=363，表示C已经发出了363个字节，上边已经收到了S的确认。Ack-IAN=1832-1=(465-54)+(1474-54)，表示C至此已经接收到S发来的1831个字节。
接下来，C收到HTML文件剩余的719个字节，报文（Packet9）如下。
9 220.181.6.175:80→ 192.168.89.125:5672 HTTP 773 HTTP/1.1 200 OK
至此，C收到S发送过来的全部HTTP响应报文，即百度首页HTML内容(text/html)。
Packet6、Packet7和Packet9的ACK都是364，这是因为这三个segment都是针对Packet4的TCP响应。S将百度首页HTML文件（一个完整的HTTP报文）按照MSS分段提交给TCP层。在Wireshark中可以看到Packet9的报文中有以下reassemble信息：
[Reassembled TCP segments (2555 bytes): #6(411),#7(1420),#9(719)] [Frame: 6, payload: 0-410(411 bytes)] [Frame: 7, payload: 411-1830(1420 bytes)] [Frame: 9, payload: 1831-2549(719 bytes)]
C（amqp）接收到百度首页的HTML文件后，开始解析渲染。在解析过程中，发现页面中含有百度的logo资源baidu_logo.gif，并且需要bdsug.js脚本。
<img src="http://www.baidu.com/img/baidu_logo.gif" width="270" height="129" usemap="#mp">
{d.write('<script src=http://www.baidu.com/js/bdsug.js?v=1.0.3.0><//script>')}
于是上面那个连接（C:5672）继续向S请求logo图标资源，报文（Packet10）如下。
10 192.168.89.125:5672→ 220.181.6.175:80 HTTP 492 GET /img/baidu_logo.gif HTTP/1.1
与此同时，C（jms）新建一个连接（TCP 5673）向S请求js脚本文件。报文（Packet11）如下。
11 192.168.89.125:5673→ 220.181.6.175:80 TCP 62 jms > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1
（Packet12）Packet13、Packet14、Packet16和Packet17为对Packet10的TCP响应（它们的Ack=802），在逻辑上它们是一个完整的TCP报文。其Http Response Content为图片文件baidu_logo.gif。我们在Wireshark中可以看到Packet17的报文中有以下reassemble信息：
[Reassembled TCP segments (1801 bytes): #13(312),#14(1420),#16(28) ,#17(41)] [Frame: 13, payload: 0-311(312 bytes)] [Frame: 14, payload: 312-1731(1420 bytes)] [Frame: 16, payload: 1732-1759(28 bytes)] [Frame: 17, payload: 1760-1800(41 bytes)]
Packet11-Packet19-Packet20完成新连接的三次握手。然后，C（jms）发送“GET /js/bdsug.js?v=1.0.3.0 HTTP/1.1”报文（Packet21），以获取bdsug.js脚本文件。
21 192.168.89.125:5673→ 220.181.6.175:80 HTTP 465 GET /js/bdsug.js?v=1.0.3.0 HTTP/1.1
（Packet22）Packet23、Packet24、Packet26和Packet27为对Packet21的TCP响应（它们的Ack=412），在逻辑上它们是一个完整的TCP报文。其Http Response Content为脚本文件bdsug.js。我们在Wireshark中可以看到Packet27的报文中有以下reassemble信息：
[Reassembled TCP segments (3897 bytes): #23(310),#24(1420),#26(1420) ,#27(747)] [Frame: 23, payload: 0-309(310 bytes)] [Frame: 24, payload: 310-1729(1420 bytes)] [Frame: 26, payload: 1730-3149(1420 bytes)] [Frame: 27, payload: 3150-3896(747 bytes)]
通常，浏览器会自动的搜索网站的根目录，只要它发现了favicon.ico这个文件，就把它下载下来作为网站地址栏图标。于是，C（amqp）还将发起“GET /favicon.ico HTTP/1.1”请求网站地址栏图标，见报文Packet29。
3．TCP四次挥手关闭连接
经Packet28确认收到了完整的japplication/javascript文件后，链路1（本地端口5673）使命结束，S关闭该链路，进入四次挥手关闭双向连接。
（Packet30）Packet31和Packet32为对Packet29的TCP响应（它们的Ack=1201）。经Packet33确认收到了完整的image/x-icon文件后，链路2（本地端口5672）使命结束，S关闭该链路，进入四次挥手关闭双向连接。
为什么握手是三次，而挥手是四次呢？这是因为握手时，服务器往往在答应建立连接时，也建立与客户端的连接，即所谓的双向连接。所以，在Packet2中，服务器将ACK和SYN打包发出。挥手，即关闭连接，往往只是表明挥手方不再发送数据（无数据可发），而接收通道依然有效（依然可以接受数据）。当对方也挥手时，则表明对方也无数据可发了，此时双向连接真正关闭。
wireshark查找String
edit——find packet——String
参考这里