WireShark

http://www.cnblogs.com/TankXiao/archive/2012/10/10/2711777.html

选择网卡  在菜单栏中的Capture-->Interfaces中也可以选择

设置时间的格式

对某一个tcp端口进行数据抓包,点击绿色的开始按钮后，需要再点击右侧的apply

ip.src==192.168.0.2 and ip.dst==192.168.0.233 and tcp.port==965

风暴英雄的数据抓包

 ip.dst ==24.105.29.30 or ip.dst==24.105.29.76 or ip.dst==223.252.234.20

搜索info列

 https://serverfault.com/questions/192720/how-can-i-search-the-info-column-in-wireshark

抓包结果说明

http://www.xianren.org/net/wireshark-q.html

 tcp segment of a reassembled PDU

https://ask.wireshark.org/questions/58186/tcp-segment-of-a-reassembled-pdu

It means that

• Wireshark/TShark thinks it knows what protocol is running atop TCP in that TCP segment;
• that TCP segment doesn't contain all of a "protocol data unit" (PDU) for that higher-level protocol, i.e. a packet or protocol message for that higher-level protocol, and doesn't contain the last part of that PDU, so it's trying to reassemble the multiple TCP segments containing that higher-level PDU.

For example, an HTTP response with a lot of data in it won't fit in a single TCP segment on most networks, so it'll be split over multiple TCP segments; all but the last TCP segment will be marked as "TCP segment of a reassembled PDU".

6. Sequence number: 2186017225 显示为该包序列号的空际值

• Sequence number: 1 (relative sequence number)，显示为该包序列号的相对值，这个数字用来表示一个TCP片段。这个域用来保证数据流中的部分没有流失（随机生成）

7. Next sequence number: 2186017427

• Next sequence number: 203 (relative sequence number) 
  分析同上，下一个序列号（在实际传输中并未有此数据，是Wireshark 提供的，= Sequence number + TCP Segment Len）

8. Acknowledgment number: 1090536281

• Acknowledgment number: 1 (relative ack number)
• 确认号为1: 这个数字式通信中希望从另外一个设备得到的下一个数据包的序号

TCP参数描述

http://blog.csdn.net/u011414200/article/details/47948401

在TCP层，有个FLAGS字段，这个字段有以下几个标识：SYN, FIN, ACK, PSH, RST, URG

1. SYN(synchronous建立联机) 表示建立连接

2. ACK(acknowledgement 确认) 表示响应

3. PSH(push传送) 表示有 DATA数据传输

4. FIN(finish结束) 表示关闭连接

5. RST(reset重置) 表示连接重置

6. URG(urgent紧急)

7. Sequence number(顺序号码) Acknowledge number(确认号码)

其中，ACK是可能与SYN，FIN等同时使用的，比如SYN和ACK可能同时为1，它表示的就是建立连接之后的响应，如果只是单个的一个SYN，它表示的只是建立连接

• TCP的几次握手就是通过这样的ACK表现出来的， 但SYN与FIN是不会同时为1的，因为前者表示的是建立连接，而后者表示的是断开连接

• RST一般是在FIN之后才会出现为1的情况，表示的是连接重置

• 一般地，当出现FIN包或RST包时，我们便认为客户端与服务器端断开了连接；而当出现SYN和SYN＋ACK包时，我们认为客户端与服务器建立了一个连接

• PSH为1的情况，一般只出现在 DATA内容不为0的包中，也就是说PSH为1表示的是有真正的TCP数据包内容被传递

• TCP的连接建立和连接关闭，都是通过请求－响应的模式完成的

Sequence Number是针对自身的，所在数据段(数据包)的。表示所在数据段的第一个数据字节的序列号, syn（这一步是初始化发送端的ISN( Initial Sequence Number )。理论上，它的数据字段没有任何值，消耗的是一个虚字节）

Seq和Ack的关系（重点）

1. Seq即Sequence Number，为源端（source）的发送序列号；Ack即Acknowledgment Number，为目的端（destination）的接收确认序列号

2. 在Wireshark Display Filter中，可使用tcp.seq或tcp.ack过滤

3.

在Packet1中，C:5672向S:80发送SYN握手包，Seq=0(relative sequence number)；

在Packet2中，S:80向C:5672发送ACK握手回应包，Ack=1(relative sequence number)，同时发送SYN握手包，Seq=0(relative sequence number)；

在Packet3中，C:5672向S:80发送ACK握手回应包，Seq=1，Ack=1。（C：Client S : Server）

4.

至此，

Seq=1为C的ISN（Initial Sequence Number），后期某一时刻的Seq=ISN+累计发送量(cumulative sent)；

Ack=1为C的IAN（Initial Acknowledge Number），后期某一时刻的Ack=IAN+累计接收量(cumulative received)。

对于S而言，Seq和Ack情同此理

例：Next sequence number: 733 (relative sequence number) ， 
假如我现在的sequence number =1 , 那么这个 733 = 1 + 732 ， 732 正好是我应用的报文大小。

后面的发送报文，假如我的sequence number不是733 ，wireshark就会提示 out of order . 
A–>B Sequenace number =1, Next Sequence Number = 733, Acknowledgement number=1 
B–>A ….. 
A–>B Sequence number =733 这里，sequence number必须为733 ，否则wireshark 报out of order, Next Sequence number= 926 Acknowledge number = 23

SLE和SRE

http://blog.csdn.net/season_hangzhou/article/details/48318599

SLE: Sequence Left Edge of already acknowledged data when Selective Acknowledgments are used. 即已收到tcp数据的左边界。
SRE: Sequence Right Edge of already acknowledged data when Selective Acknowledgments are used. 即已收到tcp数据的右边界。

SACK在数据丢包需要重传时起作用。

比如，服务器已发送的数据为1~34454个包，

但是，客户端只收到了“1~22774，28614~34454”这些序列的包，也就是说“22775~28613”这些包已经丢了。

这个时候，客户端会向服务器请求发送回馈包，说我收到了seq为22774的包，同时也乱序收到了"SLE为28614，SRE为34454"的包。

那么，服务器就知道，接着从seq=22775的包开始发送，发送到seq=28613的包的时候，就不用在发送seq=28614的包了，因为客户端已经收到了。
如果ACK中不带SLE和SRE会怎样呢？那服务器就会重发从"22775"开始之后的所有的包，包括其实客户端已经收到的"28614~34454"序号的包，那就浪费网络带宽了，不是么。

TCP Window

http://blog.sina.com.cn/s/blog_987e00020102wq60.html

[TCP zerowindow]  发送方没法暂时没办法发送数据

TCP包中的“win=”代表接收窗口的大小，即表示这个包的发送方当前还有多少缓存区可以接收数据。

当Wireshark在一个包中发现“win=0”时，就会给它打上“TCP zerowindow”的标志，表示缓存区已满，不能再接受数据了。

比如图8就是服务器的缓存区已满，所以通知客户端不要再发数据了。我们甚至可以在3258～3263这几个包中看出它的窗口逐渐减少的过程，即从win=15872减小到win=1472。

[TCP window Full]  发送方暂时没办法接收数据

当Wireshark在一个包中打上[TCP window Full]标志时，就表示这个包的发送方已经把对方所声明的接收窗口耗尽了。

以图9为例，Britain一直声明它的接收窗口只有65535，意味着Middle East最多能给它发送65535字节的数据而无需确认，即“在途字节数”最多为65535字节。

当Wireshark在包中计算出Middle East已经有65535字节未被确认时，就会发出此提示。至于Wireshark是怎么计算的，请参考本书的《计算“在途字节数”》一文。

[TCP window Full]很容易跟［TCP zerowindow］混淆，实际上它们也有相似之处。

前者表示这个包的发送方暂时没办法再发送数据了，

后者表示这个包的发送方暂时没办法再接收数据了，

也就是说两者都意味着传输暂停，都必须引起重视。