wireshark tcp 协议分析

 虽然知道wireshark是抓包神器，只会大概大概用一下，还用一下下tcpdump，略懂一点BPF过滤器，也知道一点怎么用wirkshark过滤相关的报文，可是对于详细的字段的含义，如何查看TCP的交互状况还不是很是的了解。如今，简单分析一下。PS：此次抓包的对象是传说中经过公安局多少多少级认证的本公司开发的交易系统，原本看到他的验证码倾斜的颇有规律，叫的斑斑点点也不是很密集。就想写个小程序练习一下验证码识别，但是我失望了，在wireshark里面竟然没有抓到任何报文，这个东西的验证码竟然是客户端生成的，无语。因而，抓下登陆过程的报文，看看可否破解，相关的TCP报文：crack.pcapng。关于报文分析，有一个很好的E文网站:packetlife。

  废话少说，简单在看看TCP的协议头：
TCP协议头
  这张图片有点过时，保留位是6位，实际的状况是，保留位的后2位已经被使用了。保留位的第5位是Congestion Window Reduced(CWR)，第6位是ECN-Echo(ECN)。TCP协议的其余部分不说，先看看TCP协议的几个不是很了解标志是什么意思。

• CWR(Congestion Window Reduced)
  简单来讲就是网络不是很畅通了，通知对方减小阻塞窗口，发包速度发慢一点。

• ECN（ECN-Echo）
  ECN两个做用，在TCP三次握手时代表TCP端是否支持ECN；在传输数据时，发送方是没法知道网络是否畅通的，可是通过重重的路由后，路由根据网络的状况能够知道是否阻塞，路由会设置在IP层会设置的相应的标志，即接收端发现了拥塞。CWR为发送端缩小拥塞窗口标志，用来通知发送端它已经收到了设置ECN标志，应该减慢发包速度。关于ECN的详细描述请参考：ECN

• URG(Urgent)
  这就是传说中的带外数据。由于TCP是没有消息边界的，假若有一种状况，你已经发送了一些数据，可是此时，你要发送一些数据优先处理，就能够设置这些标志，同时若是设置了这个标志，紧急指针也会设置为相应的偏移。当接受方收到URG数据时，不缓存在接收窗口，直接往上传给上层。具体的使用能够参考TCP带外数据。大致来讲，就是，调用send和recv是要加上MSG_OOB参数。同时接收方要处理SIGURG信号。不过听说这个带外数据在实际上，用得不多。

• PSH（Push）
  简单来讲，就是告诉对方，我发这么多数据了，你能够处理了，不用缓冲在接收窗口了，直接交数据给上层吧。若是设置了SO_NODELAY选项，能够强制设置这个标志，若是设置了这个标志，数据就不缓冲在发送窗口那里，直接发送。

  TCP报文SYN ACK的计算以下：

A -> B SYN J ACK K LEN L B -> A SYN K ACK J+L LEN M A -> B SYN J+L ACK K+M 

  具体看下wireshark抓到的报文：

1. TCP3次握手的部分是帧1到帧3。
   创建链接

   • 第1帧，发送SYN J:
     A -> B seq = 0, win = 8192, len = 0, MSS = 1440, WS = 4, SACK_PERM = 1
     WS(Window Scale), 4表示左移动4位，原来窗口大小是16为，如今是20为，现代扩大了4倍，关于WS，这里有比较详细的描述tcp-windows-and-window-scaling。这里比较疑惑的就是SACK_PERM这个TCP选项。SACK（Select ACKnowledgement）的目的就是当出现大量的报文丢失时增长恢复时间来用的，相似于累计ACK，就是说N多个ACK合成一个SACK。关于SACK，有两个地方描述的比较详细SelectiveAcknowledgements,TCP Selective Acknowledgment。
   • 第2帧，发送SYN K， ACK J+1:
     B -> A seq = 0, ACK = 1, Win = 14600, Len = 0, MSS = 1448, SACK_PERM = 1 WS = 128
     这些含义看第1帧，win = 14600, WS = 128，能够看到这台服务器的窗口很是大，WS也不少，网络性能应该不错的（事实也如此）。
   • 第3帧，发送SYN J+1， ACK K+1:
     A -> B seq = 1, ACK = 1, win = 66608, Len = 0
     这是创建TCP链接的第3次握手，这时win = 66608了，转换为2进制有17位比16位长，由于再第1帧第2帧的交互中已经交互了各类的TCP选项，因此此次的确认不带有TCP选项。

   当这3次交互完成后，链接真正创建，只要服务端accept后，就能够接收和发送数据了。

2. TCP数据传输
   普通数据传输
   截图的是报文的第7帧，这个帧报文在此次抓的报文中相对有表明性点的。这个帧的报文设置了PSH标志，并且是TCP分片传输的报文，由于此帧的报文是第6帧报文分片传输的，从ACK = 125能够看出。传输数据的报文没有什么特别能够说的：~

3. TCP终止链接的4次交换的部分是帧19到帧21（能够发现，这里的交互是有问题的）。
   终止链接

   • 第19帧，发送FIN J, ACK K:
     A -> B seq = 2559, ack = 2361, win = 65812, len = 0
     客户端发起FIN主动关闭链接和上个报文的ACK（应该是接收完了数据，关闭SOCKET），客户端最后应该会变成TIME_WAIT状态。这是第一次交换。
   • 第20帧，发送FIN K， ACK J+1:
     B -> A seq = 2361, ack = 2560, Win = 26240, Len = 37
     此次交换中，除了对客户端的ACK外，同时发送FIN，但同时带有37字节的数据，这37个数据不是咱们期待有的。能够猜想一下，多是服务端里面有37个字节尚未发送，在收到FIN后，把缓存里面的数据所有发送过去。服务端若是忘记的关闭链接，会变成CLOSE_WAIT状态。这里两次的交换合并在一块儿了。
   • 第21帧，发送RST， ACK K+Len:
     A -> B seq = 2560, ACK = 2398, win = 0, Len = 0
     主动关闭一方收到FIN，回应ACK。可是这里却有一个不是咱们期待的RST标志。RST标志代表往已经关闭链接发送数据，这是个错误。这是第四次交换。

   这里的客户端与服务端的交换是有问题的，在第20帧，收到FIN时，不该该再发送数据，这样发送的数据颇有可能收到的就是RST。可是这并不必定是发送数据一方的问题，颇有多是客户端尚未接受完数据就关闭链接了。但能够确定的是，在客户端或服务端某个地方确定存在BUG。

  这个就是某交易系统登陆的报文，报文涉及5次数据交互（请求-应答）。这有5次交换，第1，2次交换，极可能是交换RSA公钥（猜的，由于报文数据有OpenSSL标志：~）。然然后面的还有3次数据交互，并非我期待的一次交互。难道还要同步其余密钥之类的？有空问下相关开发人员。若是是单纯破解报文的话，存在比较大的难度，可是若是是DOS攻击的话，这应该是很是简单的……