tcp三次握手抓包格式分析(TCP三次握手抓包分析)

本文主要内容1、TCP数据包格式TCP数据包格式如下：注意到中间还有几个标志位：数据包格式当中，最重要的是理解序号和确认序号。TCP为什么是稳定可靠的，与序号与确认序号这套机制紧密相关，这也是TCP的精髓。2、TCP的三次握手众所周知，TCP协议是可靠的，而UDP协议是不可靠的。在一些场景中必须用TCP，比如说用户登录，必须给出明确答复是否登录成功等。而有些场景中，用户是否接收到数据则不那么关键，比如网络游戏当中，玩家射出一颗子弹，另外的玩家是否看到，完全取决于当前网络环境，如果网络卡顿，就会有玩家已经被射杀，但界面仍然刷新不出来的情况。这种情形适合UDP。为了保证TCP协议可靠，在建立连接之时就要得到保证。最初两端的TCP进程都处于CLOSED关闭状态，A主动打开连接，而B被动打开连接。（A、B关闭状态CLOSED——B收听状态LISTEN——A同步已发送状态SYN-SENT——B同步收到状态SYN-RCVD——A、B连接已建立状态ESTABLISHED）B服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。若有，则作出响应。3、TCP的传输和确认TCP 传输的可靠性，可以用一句话归结：每收到对方数据，就发送 ACK 进行确定，发送方发送后没有收到 ACK 就隔一段时间重发。就是 A 向 B 发送消息（下面将 TCP 的报文直接看做是消息，消息一词跟 TCP 报文混用），B 收到消息后需要向 A 发送 ACK。这个 ACK 相当于返回结果，没有返回结果，A 就重新发送消息。归纳起来，A 有 3 种消息需要确认。另外 A 也可以发送 RST 消息，代表出错了。出错消息不需要确认。RST 也可以当成返回接口，替代正常的 ACK。返回 ACK，表示消息发送并处理成功，返回 RST 表示消息处理失败。因为通过网络传输，还有第三种结果，就是不确定成功失败。这样归纳起来。就有三种返回结果。这两种具体情况，A 根本识别不了，都只能重发。4、TCP的序号和确认序号A 向 B 发送消息，假如同时发送 a、b、c、d 消息，因为通过网络，这些消息的顺序并非固定的。而 B 返回 ACK 结果，这样就有一个问题，这个结果到底对应了哪个消息？另外当 A 超时重发后，原来的消息延时一段时候，又重新到达了 B，这样 B 就收到两条相同的消息，那么 B 怎么确定这两条消息是相同的呢？为了解决这个对应问题，每一条消息都需要有一个编号，返回结果也应该有一个编号。TCP 的序号可以看成是发送消息的编号，确认序号可以看成是返回结果的编号。有了编号，重复的消息才可以忽略，返回结果(ACK)才可以跟消息对应起来。当建立连接的时候，TCP 选定一个初始序号，之后每发送一个数据包（消息），就将序号递增，保证每发送不同的数据包，数据包的序号都是不同的。TCP 是这样处理的：SYN、FIN 也需要递增序号。不然 A 向 B 重发多个 SYN 或者 FIN, B 根本判断不了 SYN 是否相同，这样就不可以忽略重复的数据包了。当 TCP 发送 ACK 时，相当于返回结果，需要带有确认序号，以便跟发送的消息对应起来。当发送包编号为 a，递增长度为 len。其中 SYN 和 FIN 可以看成是递增长度为 1。这条消息可以这样表示为：现在来回顾三次握手过程。 A 发送序列号x给 B ， B 回复 A 确认号 x+ 1，同时发送序列号 y， A 接收到 B 的回复后，再回复确认号 y+1，同时发送序列号 x+1。给对方的回复一定是接收到的序号加1（或者是数据长度），这样对方才能知道我已经收到了，这样才能保证TCP是可靠的。

field value的意思是首部的长度，这里是以4个字节为单位的，所以4*7刚好就是28个字节了，5*4=20个字节了
楼上正解，接楼上的往下说： TCP三次握手前两个报文需要指出MSS（最大报文长度），这个字段是在TCP选项字段里的，TCP报头由基本20字节和选项字段组成，所以前两个带SYN标志的报文都比20个字节大，至于究竟有多大，要看除了通告MSS之外还有没有使用其他的选项，如seletive ACK， 窗口扩大因子等。后续传输数据的TCP报文一般头长度都是二十字节（如果没有一些扩展选项被使用） 应用程序通过头长度来得知从哪一块起是TCP数据，如果这个指定错误，应用程序无法对数据正确处理。不能更改头长度值。查看一下TCP报头结构，你自然就知道怎么计算了。

[RST]是复位标志，用于复位相应的TCP连接。 此问题详细请百度 “TCP标志位" 复位到重新发送同步请求应该是TCP/IP协议有时间间隔的规定吧，我也不清楚，请查TCP/IP详解。

TCP握手协议 在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接.第一次握手：建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认；SYN：同步序列编号(Synchronize Sequence Numbers)第二次握手：服务器收到syn包,必须确认客户的SYN（ack=j+1）,同时自己也发送一个SYN包（syn=k）,即SYN+ACK包,此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手. 完成三次握手,客户端与服务器开始传送数据
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认。第二次握手：服务器收到syn包，必须确认客户的SYN(ack=j+1)，同时自己也发送一个SYN包(syn=k)，即SYN+ACK包，此时服务器进入SYN_RECV状态。 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据。简版：首先A向B发SYN(同步请求)，然后B回复SYN+ACK(同步请求应答)，最后A回复ACK确认，这样TCP的一次连接(三次握手)的过程就建立了。三次握手我们先明确两个定义：1，client为数据发送方2，server为数据接收方好，下面进行三次握手的总结：1，client想要向server发送数据，请求连接。这时client向服务器发送一个数据包，其中同步位(SYN)被置为1，表明client申请TCP连接，序号为j。2，当server接收到了来自client的数据包时，解析发现同步位为1，便知道client是想要简历TCP连接，于是将当前client的IP、端口之类的加入未连接队列中，并向client回复接受连接请求，想client发送数据包，其中同步位为1，并附带确认位ACK=j+1，表明server已经准备好分配资源了，并向client发起连接请求，请求client为建立TCP连接而分配资源。 3，client向server回复一个ACK，并分配资源建立连接。server收到这个确认时也分配资源进行连接的建立。
A与B建立TCP连接时：首先A向B发SYN（同步请求），然后B回复SYN+ACK（同步请求应答），最后A回复ACK确认，这样TCP的一次连接（三次握手）的过程就建立了！

目录我的操作是这样的，让手机和电脑在同一个局域网内（比如连接同一个 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 的证书。